Управление идентификацией: Управляйте жизненным циклом идентификаций

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

Дарен Маар-Елия

Адаптированная выдержка из книги «Protecting Critical Data by Managing the Active Directory Identity Lifecycle» (Realtime Publishers).

Управление идентификациями, в конечном счете, сводится к управлению доступом к вашим корпоративным ресурсам. При обращении к ресурсам пользователи проходят аутентификацию под своими идентификационными данными, а затем используют свойства своих идентификационных данных (например, членство в группах), для получения доступа к ресурсам в рамках своих полномочий.

В типичной организации среднего или крупного размера можно обнаружить следующие источники идентификаций:

• Active Directory
• Другие службы каталогов
• Системы отдела кадров
• Базы данных
• Собственные бизнес-приложения (line-of-business, LOB)
• Веб-приложения Software as a Service (SaaS) от сторонних поставщиков
• Учетные записи локальных систем под управлением Windows, Linux или Unix

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

В Windows используются группы безопасности, в базах данных, таких как Oracle, используются собственные роли, строенные в базу данных, а в бизнес-приложениях используются другие механизмы. В последнее время начали доминировать SaaS-приложения — это означает, что теперь вы должны предоставлять доступ как к внутренним, так и внешним приложениям.

Важно провести четкую границу между аутентификацией и авторизацией. Некоторые продукты поддерживают интеграцию с Active Directory при аутентификации (например, через Kerberos), но, тем не менее, используют свои собственные механизмы авторизации, которые не обращаются напрямую к механизмам авторизации Active Directory, таким как группы безопасности. Такой тип смешанной интеграции, может быть, будет полезен в ваших процессах заведения пользователей, а может быть — нет.

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

Сокращайте количество хранилищ идентификаций

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

Имеются продукты сторонней разработки и встроенные средства, позволяющие использовать Active Directory как основной механизм аутентификации для Linux, Unix и Mac. В этих решениях обычно задействуется архитектура Pluggable Authentication Modules (PAM), поддерживаемая этими ОС, чтобы позволить Active Directory выступать в роли сферы (realm) аутентификации Kerberos для этих систем, почти так же, как это делается в Windows-системах.

По сути, с помощью многих из этих механизмов можно «присоединить» компьютеры с Linux, Unix или Mac к Active Directory точно так же, как если бы это были настольные компьютеры или серверы под управлением Windows. Вместо входа в системы с Unix или Linux под локальной учетной записью можно будет использовать учетную запись Active Directory, чтобы пользователи проходили аутентификацию и, в конечном счете, предоставлять им доступ к ресурсам Unix с помощью групп Active Directory.

Все приложения, выполняемые на таких компьютерах с ОС, отличной от Windows, применяющих PAM для аутентификации и авторизации при доступе пользователей к локальным учетным записям, смогут использовать интеграцию с Active Directory для поддержки аутентификации и авторизации при доступе к учетным записям Active Directory. И снова, ситуация зависит от приложений, тем не менее это означает, что как только вы интегрировали базовую ОС, вы получаете некоторую степень интеграции с Active Directory.

Кроме того, многие приложения и прикладные платформы сторонних производителей в той или иной форме поддерживают аутентификацию и авторизацию в Active Directory. В частности, это пакеты приложений, такие как SAP и серверы веб-приложений Java от Oracle Corp. и IBM Corp. Даже базы данных Oracle поддерживают интеграцию аутентификации и авторизации с Active Directory с помощью различных методов интеграции — от прямого использования Kerberos до интеграции с собственной LDAP-службой каталогов Oracle.

Преимущества идентификации

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

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

Эти решения могут иметь свои собственные службы каталогов, где агрегируются все данные такого рода из всех подсоединенных системах. Часто их называют метакаталогами. Решение может просто отслеживать соответствие данных в подсоединенных системах, сопоставляя ключевые поля одной системы полям другой системы.

Цель такого сопоставления — найти поле, которое уникально идентифицирует пользователя во всех хранилищах идентификаций. Это гарантирует, что Джон Смит в Active Directory — это тот же Джон Смит, которого только что принял на работу отдел кадров, и тот же Джон Смит, который согласно идентификациям, хранящимися в метакаталоге, имеет доступ к определенным приложениям. А когда Джон Смит уволится из организации, его идентификатор пользователя отключат в системе отдела кадров, Active Directory и хранилищах, специфичных для приложениях, выполнив лишь одну операцию.

Сокращайте риски

Система управления жизненным циклом идентификаций, в самом деле, важна. Для построения системы, которая отслеживает, кто работает в организации и к чему он имеет доступ, имеются реалистичные, связанные с практикой причины: риски утечки данных, несоответствия законодательству и нарушения функционирования предприятия.

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

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

Как же ввести в действие правильный план управления идентификациями, чтобы не потерять данные? Это просто — если тщательно следить за тем, какие пользователи получают полномочия на доступ к вашим системам, и использовать правильные процессы, предоставляющие доступ только к тем данным, которые нужны для работы, вероятность того, что данные попадут в чужие руки, существенно снижается.

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

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

Риски несоответствия законодательству: наряду с рисками утечки данных заслуживают внимания риски организаций, связанные с государственным регулированием. Такие законы как закон Сарбейнса-Оксли (Sarbanes-Oxley Act, SOX), закон о передаче и защите данных учреждений здравоохранения (Health Insurance Portability and Accountability Act, HIPAA), стандарты безопасности в отрасли платежных карт (Payment Card Industry, PCI) и другие нормативы в той или иной степени явно определяют, какие методы использовать для защиты клиентов и данных, не подлежащих разглашению.

Все эти законы указывают, какие данные необходимо защитить. За серьезные нарушения при защите таких данных предусмотрена строгая финансовая и уголовная ответственность. Если ваша организация обязана соблюдать эти законы и у вас нет целостного плана по предотвращению разнообразных рисков, связанных с похищением данных, вы напрашиваетесь на проблемы. Наличие целостного плана управления идентификациями, дополняющего другие методики управления, поможет вам лучше контролировать, кто имеет доступ к вашим системам.

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

Наверное, вы любой ценой хотели бы избежать ситуации, когда администратор, привилегии которого гораздо больше, чем его роль, что-нибудь меняет не на том сервере и не в то время и делает неработоспособными системы вашего предприятия. Существует бессчетное множество анекдотов про администраторов, которые имеют доступ Domain Admins к Active Directory — то есть, по сути неограниченное право на чтение и запись большинства объектов Active Directory — и нечаянно удаляют учетную запись службы критически важного приложения или по ошибке переносят объекты из одного организационного подразделения (organizational unit, OU) в другое.

Это может привести к тому, что к OU будут применяться другие групповые политики (Group Policy) и поведение OU существенно изменится. Во всех этих примерах ошибки возникает риск длительного простоя из-за того, что когда потребовалось завести пользователя, кто-то не соблюдал политику и предоставил пользователю гораздо больше прав, чем ему нужно или чем позволяли его навыки.

Групповые политики — еще одна область, для которой актуальна хорошая система управления тем, кто имеет доступ и может вносить изменения. Изменения групповых политик могут существенно повлиять на работу организации. При внесении таких изменений будет гораздо лучше, если ведется строгий контроль за моделью делегирования групповых политик. Обычно для этого требуется обеспечить, чтобы нужные пользователи находились в нужных группах Active Directory, члены которых имеют право на модификацию объектов групповых политик (Group Policy Objects).

Предоставляйте разрешения

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

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

Дарен Маар-Елия (Darren Mar-Elia) — является обладателем звания Policy MVP по групповым политикам, создателем популярного сайта, посвященного групповым политикам — gpoguy.com и соавтором руководства Microsoft Windows Group Policy Guide (Microsoft Press, 2005). Он также является техническим директором и сооснователем компании SDM Software Inc. С ним можно связаться по адресу Darren@gpoguy.com.

Дополнительную информацию об этой и других книгах издательства Realtime Publishers см. на сайте Realtime Publishers.