Identity Management - стратегический аспект интеграции приложений

Управление учётными записями

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

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

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

В качестве консолидированного хранилища учётных записей, как правило, используются каталоги LDAP. Такие каталоги, как Microsoft Active Directory или Novell eDirectory, представляют собой современные варианты доменных систем, управляющих ресурсами локальных сетей (выросшие, соответственно, из доменов Windows NT или Novell NDS). Такие каталоги поддерживают протокол LDAP наряду с остальными протоколами, обеспечивающими собственно управление сетевыми ресурсами. С другой стороны, «чистые» каталоги LDAP, вроде Sun ONE Directory Server, IBM SecureWay, Oracle Internet Directory или свободно распространяемого OpenLDAP, зачастую подходят для хранения учётных записей в не меньшей степени. Универсальность протокола LDAP означает, что производитель корпоративного приложения должен потратить совсем немного усилий для того, чтобы обеспечить поддержку всех популярных каталогов LDAP. Оба типа каталогов LDAP могут быть использованы в качестве консолидированного хранилища учётных записей.

В каталоге LDAP каждому пользователю соответствует одна учётная запись, в которой хранятся параметры, необходимые для работы различных приложений – то есть каталог обеспечивает единую точку администрирования учётных записей, по крайней мере, для приложений, поддерживающих LDAP. Все каталоги LDAP позволяют создать распределённую архитектуру с репликацией данных, а также позволяют разграничить права доступа к объектам каталога, что позволяет осуществлять делегированное администрирование: учётной записью сотрудника подразделения может управлять администратор из того же подразделения. Более того, при обеспечении каталога понятным интерфейсом администрирование может быть делегировано, например, сотрудникам отдела кадров.

На практике полная консолидация хранилищ учётных записей удаётся довольно редко, поскольку не все приложения поддерживают LDAP, а иногда решение сохранить отдельные хранилища продиктовано организационными соображениями. В этом случае имеет смысл синхронизировать данные учётных записей между различными хранилищами. Приложения, обеспечивающие синхронизацию учётных записей, называются метакаталогами. На настоящий момент на рынке наиболеераспространены метакаталоги Novell DirXML, MaXware DSE и Sun ONE Directory Server. Метакаталог отслеживает изменения во всех подключенных к нему системах и на основании этих изменений проводит изменения в других подключенных системах. Например, при создании учётной записи нового сотрудника в базе данных, используемой отделом кадров, метакаталог может автоматически создать для этого сотрудника учётную запись в домене локальной сети и «ящик» электронной почты.

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

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

Управление аутентификацией

Работа с многообразием несвязанных систем неудобна не только администраторам; она также причиняет определённые неудобства конечным пользователям - разные пароли (а иногда и разные имена для входа в систему) в разных приложениях, а также необходимость вводить пароль при переходе от приложения к приложению. Эти неудобства преодолеваются при помощи создания единой системы аутентификации и системы однократной регистрации (Single Sign-On, SSO). Первая из этих задач может быть решена при помощи внедрения единого каталога LDAP – в этом случае у пользователя имеется единственное имя для доступа к приложениям и единственный пароль; похожий результат может быть достигнут при внедрении метакаталога (заметим, что не все метакаталоги в состоянии синхронизировать пароли, так что эта задача может требовать использования специальных средств, таких, как P-Synch). Заметим,что это - не единственный способ создания единой системы аутентификации (см. ниже).

Существующие на сегодня системы SSO можно условно разделить на два типа. Системы первого типа не требуют внесения изменений в сами приложения и обеспечивают автоматический ввод имени пользователя и пароля в момент, когда соответствующее приложение их запрашивает. Примерами таких систем являются Novell SecureLogin и Evidian AccessMaster.

Реализация SSO второго типа накладывает определённые условия на сами приложения – они должны уметь получать информацию о пользователе без отдельного запроса на ввод пароля. Например, SSO для веб-приложений может быть реализовано при помощи cookies, помещаемых в клиентский веб-браузер: cookie помещается при первоначальной аутентификации, а последующие приложения используют его для проверки личности пользователя. Такой подход реализуется в продуктах Netegrity SiteMinder и Oblix NetPoint. В качестве другого примера можно назвать технологию Kerberos, получившую особенно широкое распространение после своего включения в Windows 2000: «билет» Kerberos, получаемый при входе в ОС, может использоваться для входа в приложения, поддерживающие Kerberos, что происходит незаметно для пользователя.

Авторизация, аудит доступа и персонализация

Упомянем кратко о других аспектах взаимодействия с пользователями, управлением которых занимается Identity Management. Это создание единой системы авторизации, создание единой системы аудита доступа к информационным ресурсам и единой системы персонализации. Первые два вопроса, очевидно, должны восприниматься как две стороны одной задачи, причём весьма сложной: в настоящий момент большинство приложений хранят права доступа к своим информационным ресурсам в собственном формате, причём у разных приложений может быть разная семантика прав доступа (например, «есть доступ/нет доступа» у веб-страницы, и «чтение/редактирование» у файла).

Наконец, понятие персонализации (допускающее различные варианты трактовки) обычно подразумевает персонализацию внешнего вида веб-приложения (и реализуется средствами самого приложения на основе учетной записи пользователя, как правило, в каталоге LDAP) или персонализацию рабочей станции пользователя (что реализуется, например, средствами Microsoft Active Directory или Novell ZENWorks).

Состояние рынка на сегодня

Направление Identity Management является относительно молодым – самому термину Identity Management сейчас около трех лет. За исключением технологии каталогов LDAP, возникшей в начале (и достаточно широко распространившейся к концу) 1990-х, это можно сказать и о соответствующих продуктах и технологиях.

В настоящий момент большинство крупных и средних фирм и организаций на западном рынке либо уже внедрили единую систему каталогов LDAP, либо находятся на стадии её развёртывания. Наблюдается также высокий (и растущий) интерес к метакаталогам и системам SSO, хотя из-за молодости этих технологий степень их проникновения пока что относительно невелика.

Российский рынок следует за западным с характерным запозданием; здесь достаточно распространены каталоги, управляющие сетевыми ресурсами (в первую очередь, Active Directory), а о метакаталогах и SSO до последнего времени практически не говорилось.

Выигрыши от внедрения решений Identity Management

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

Василий Шабат / Открытые технологии

Короткая ссылка на материал: //cnews.ru/link/a524