Работая над данной статьей, я решил посмотреть на реализацию централизованной базы данных прав доступа с разных сторон и посвятить статью не только снижению типовых рисков информационной безопасности, но и тренду развития технологий такого хранилища, как с точки зрения исторической ретроспективы, так и исходя из зрелости и размеров ИТ-инфраструктуры.

Для простоты изложения я буду пользоваться терминологией «база данных прав доступа», «хранилище прав доступа» или просто «база данных», «хранилище», подразумевая под этим ресурсы, которые содержат в себе совокупность всей информации, используемой при авторизации и аутентификации в информационных системах.

«Базовый» вариант

Самым доступным и распространенным вариантом хранилища прав доступа по сути является его реализация в виде LDAP-совместимой службы каталогов. Практически каждый крупный разработчик общесистемного программного обеспечения имеет свою версию службы каталогов: Novell eDirectory, Apple Open Directory, RedHat Directory Server, Oracle Directory Server, есть открытая реализация в виде OpenLDAP. Но самым часто встречаемым — конечно является Microsoft Active Directory. Объективно говоря, служба каталогов является прародителем технологий по централизованному управлению доступом к информационным ресурсам и безусловно имеет ряд преимуществ. По сути это единое штатное с точки зрения базовой ИТ-инфраструктуры хранилище учетных записей и прав пользователей, с возможностью указания различных свойств учетных записей, характеризующих, в том числе, позицию сотрудника в компании, его служебные и личные данные. Это также единый центр управления доступом к информационным ресурсам, который позволяет объединить не только процедуры авторизации к различным информационным системам, но и создать общий сервис аутентификации, что значительно облегчает жизнь бизнес-пользователям, потому что достаточно запомнить один логин и пароль. Недостатки такого варианта весьма очевидны. Во-первых, такая реализация помимо базового функционала организации доступа к операционной системе и файловым сервисам, работает только для тех информационных систем, которые имеют штатную возможность интеграции со службой каталогов, например MS Active Directory. В противном случае, необходима доработка, которая требует серьезных дополнительных затрат и привлечение компании-разработчика информационной системы, который не всегда рад таким задачам. Во-вторых, это отсутствие интеграции службы каталогов с кадровой информационной системой и как следствие невозможность автоматизированного управления доступом на основе кадровых событий: прием/перевод/отпуск/увольнение. Ну и в третьих, это отсутствие механизма предоставления доступа по заявке, который позволяет автоматизировать процесс согласования и назначения прав. Тем не менее вариант реализации централизованной базы данных прав доступа на основе LDAP-совместимой службы каталогов является самым бюджетным и не требует дополнительных затрат, при этом обеспечивает снижение рисков неправомерного доступа за счет централизованного хранения, управления и контроля прав доступа. Поэтому многие компании при выборе внедряемых информационных систем в качестве критерия используют наличие штатной возможности интеграции с LDAP. Но подходит такой вариант чаще для небольших компаний, где задача обеспечения информационной безопасности осуществляется, как правило, средствами основных инфраструктурных решений, а эффективность более масштабной автоматизации управления доступом далеко не очевидна.

«Классический» вариант

Реализация централизованной системы управления доступом на базе IDM-решений в наши дни уже стала обыденностью. Ролевая модель, назначение и отзыв прав, создание и блокирование учетных записей, аудит прав доступа, все эти термины все чаще употребляются в контексте функционала IDM-систем. Поэтому вариант централизованной базы данных прав в рамках популярных IDM-продуктов я назвал бы «классическим». Такая реализация имеет свои весомые преимущества. К основным из них можно отнести следующие функциональные возможности:

• полную автоматизацию управления учетными записями и правами на основе ролевой модели и кадровых событий;
• реализацию циклов согласования заявок на доступ и автоматическое назначение согласованных прав;
• автоматический аудит прав доступа в информационных системах и анализ расхождений;
• управление жизненным циклом ресурсов и ролей.

Однако такая полнота управления и контроля прав доступа в информационных системах невозможна без глубокой интеграции с ними, поэтому одна из важнейших и зачастую не простых задач при внедрении IDM — это разработка необходимых коннекторов для целевых и кадровых систем. Нельзя, конечно, назвать это недостатком, скорее — ограничением в применении IDM-решений, потому что пока это — единственный способ построить комплексную систему управления доступом к информационным ресурсам. Как правило, такая реализация централизованного хранилища прав доступа применяется в средних и крупных компаниях. При этом тренд развивается в сторону доступности IDM-систем для компаний и с меньшим количеством сотрудников. С точки зрения снижения рисков информационной безопасности, связанных с доступом в корпоративные системы, пока это самое эффективное решение.

«Эксклюзивный» вариант

Несмотря на то, что бурный рост классического IDM-рынка произошел только в последние 2−3 года, среди компаний-потребителей есть немало «первопроходцев». Зачастую это очень крупные организации, которые «обожглись» (что часто бывает с пионерами рынка) на этой теме, и теперь в части требований к IDM-решениям имеют собственное мнение. Нередко упомянутые организации имеют опыт эксплуатации нескольких систем управления доступом от разных производителей, поэтому видят идеальное решение как совокупность преимуществ разных IDM-продуктов с исключением их недостатков. Бывает, что таким образом рождаются очень интересные идеи, одну из которых я хотел бы представить как «эксклюзивный» вариант реализации централизованной базы данных прав доступа.

Основная идея такой реализации заключается в независимости хранилища прав доступа от производителя систем управления доступом к информационными ресурсам, что обеспечивает их взаимозаменяемость. При этом такая база данных должна содержать не только учетные записи и права доступа, но и все остальные типовые для IDM-системы сущности как:

• сведения о сотрудниках;
• организационно-штатная структура компании;
• данные по информационным системам и состав прав доступа к ним;
• конфликтные роли и полномочия;
• типы заявок на доступ и сценарии их согласования;
• историю согласования доступа и т. п.

Несомненно, здесь присутствует серьезная задача по интеграции такой базы данных с IDM-решениями, но это не идет в сравнение с глобальными изменениями в случае замены одной «классической» реализации на другую.
Безусловно, такой вариант будет эффективен только для большой организации с разветвленной инфраструктурой, где количество пользователей составляет несколько десятков тысяч и больше, а количество основных информационных систем значительно больше 10. Внедрение IDM в такой организации серьезный долгосрочный проект, в рамках которого главными задачами являются правильное построение ролевой модели и управление ее жизненным циклом, интеграция с информационными системами, определение бизнес-процессов управления доступом и т. д. Основной риск таких проектов, который может свести к минимуму всю проделанную работу, это переход на новое IDM-решение. К сожалению, действительность нам демонстрирует, что вероятных причин такого перехода немало. Это могут быть политические и экономические санкции, уход с рынка иностранных производителей, поглащения нишевых игроков глобальными и снятие с поддержки их решений и т. п. Поэтому жизнь сама толкает больших заказчиков на разные страховочные варианты, одним из которых является идея независимого от производителя IDM-системы базы данных прав доступа в информационные системы.
Конечно, далеко не каждый производитель готов адаптировать свое решение под такую схему работы, и в этом есть определенные недостатки. Но наличие такого структурированного хранилища, уже заполненного реальными данными, может позволить заказчику значительно сократить бюджеты и временные рамки проекта даже при переходе на новое IDM-решение или при разработке собственной реализации. Посмотрим, найдет ли распространение такой вариант в перспективе.

Вместо заключения

Конечно, в статье приведены далеко не все возможные варианты и здесь допускаются различные комбинации и «полутона». К тому же фантазия в части «эксклюзивных» вариантов совсем не ограничена. Но нужно объективно оценивать свои возможности и необходимость кастомизированных реализаций, чтобы проект не оказался «провальным» и не отбил надолго охоту заниматься данной темой, что в наши дни, к сожалению, встречается не так редко. Лучшее, как говорится, враг хорошего.

Олег Губка, директор департамента по работе с клиентами компании Аванпост