Стратегический взгляд на Identity Management

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

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

«Границы» Identity Management

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

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

Identity Management можно разделить на шесть поднаправлений:

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

Следует заметить, что границы Identity Management остаются несколько размытыми. Не существует единого мнения о том, какие поднаправления входят или не входят в его рамки. В частности, многие производители, предлагающие свои программные решения в этой области, на деле решают лишь часть указанных вопросов. (Приведенный выше список основан на наработках консалтинговой группы Net2S.)

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

Однократная регистрация

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

Чаще всего под единой системой аутентификации понимают систему «однократной регистрации» (Single Sign-On, SSO). Предназначение такой системы — снятие необходимости многократно вводить пароли (или аутентифицироваться каким-либо иным способом) при работе с различными приложениями. Вместо ввода нескольких паролей пользователь вводит один пароль или использует какой-либо способ физической аутентификации (смарт-карты, отпечатки пальцев, криптографические калькуляторы и т. д.).

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

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

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

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

Второй подход заключается во внедрении системы «билетов». В общих чертах такая система работает следующим образом: при первой регистрации пользователь получает электронный билет, подтверждающий его право на вход в определенные системы. Впоследствии сами системы могут на основании этого билета «впустить» пользователя без дополнительной аутентификации. Такие системы применяются в первую очередь для Web-приложений, где в качестве билета используется аппарат cookie, хранимый в браузере пользователя. Другая распространенная реализация этого подхода — механизм Kerberos, реализованный, в частности, в Windows 2000. Такой способ требует настройки сервера (а в случае с Kerberos и клиента) для работы с билетами.

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

На сегодняшний день возможности по реализации SSO присутствуют в том или ином виде в большинстве портальных решений (ибо им чаще всего требуется обеспечить доступ одновременно к нескольким приложениям заднего плана). Лидерами рынка Web-средств SSO являются Netegrity SiteMinder и Oblix NetPoint, а из средств автоматического заполнения паролей стоит отметить Novell Secure Login и Evidian AccessMaster SSO.

Система каталогов предприятия

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

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

Протокол LDAP за последнее время стал стандартом для хранения данных о пользователях. Все большее число приложений поддерживает использование внешнего каталога LDAP для аутентификации пользователей. Этому способствовало, в частности, принятие LDAP как стандарта для каталогов сетевых операционных систем Windows и Netware. Соответствующие каталоги (Microsoft Active Directory и Novell eDirectory) применяются как для аутентификации при входе в систему, так и для аутентификации большинства корпоративных приложений, предлагаемых соответственно Microsoft и Novell. Централизованный каталог помимо прочего дает в распоряжение пользователей все рабочие станции в сети, на которые у них есть права, без отдельных затрат на администрирование каждой из них.

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

С помощью единого каталога несколько приложений (а в идеале все корпоративные приложения) используют одну и ту же учетную запись в каталоге для аутентификации; благодаря этому отпадает необходимость отдельно администрировать данные о пользователях в различных системах. К сожалению, далеко не все приложения поддерживают внешние каталоги LDAP. Более того, иногда (скажем, по соображениям безопасности или по историческим причинам) в одной организации продолжают употреблять сразу несколько каталогов LDAP. В таких случаях на помощь приходят метакаталоги — средства, позволяющие осуществлять интеллектуальную синхронизацию между разнородными хранилищами данных. При помощи метакаталога существующие хранилища данных о пользователях могут быть объединены в единую систему каталогов, в которой заведение, редактирование и удаление учетной записи производятся одним действием (точнее, эти изменения проводятся в одной из соединенных систем, а метакаталог распространяет их на остальные системы). Единственной тонкостью при синхронизации является невозможность — в большинстве случаев — синхронизировать пароли, хранящиеся в каталогах, ибо они зашифровываются при помощи односторонней функции в момент записи.

Следует заметить, что каталог LDAP может быть единственным хранилищем данных, имеющих отношение к конкретному пользователю, но может и не являться таковым. Например, Active Directory содержит исчерпывающую информацию о пользователе сетевой операционной системы. В качестве обратного примера можно рассмотреть почтовые серверы наподобие Microsoft Exchange 2000: для аутентификации используется каталог LDAP (та же Active Directory), но собственно электронная почта хранится в соответствующих хранилищах почтовых ящиков.

Помимо уже упомянутых каталогов, распространены также Sun ONE Directory Server, IBM SecureWay и OpenLDAP. Лидерами на относительно новом рынке метакаталогов являются такие продукты, как Novell DirXML, MaXware DSE и Critical Path Meta-Directory. Более сложной альтернативой метакаталогам являются решения по автоматизации администрирования (provisioning), включающие в себя, вдобавок к средствам синхронизации, средства контроля потоков работ. Этот еще более новый рынок представлен в первую очередь продуктами Business Layers Day One, IBM/Tivoli Account Provisioning и Novell Nsure Resources.

Единая система авторизации

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

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

Администрирование прав доступа можно упростить при структуризации пользователей в группы и роли. Эти понятия сходны, но все же различаются: под группой понимают явно указанный список пользователей, в то время как обладание той или иной ролью определяется динамически (например, на основе какого-то атрибута в каталоге). Тем самым отпадает необходимость внесения отдельного пользователя во все требуемые списки доступа: достаточно лишь выделить этому пользователю определенную роль или причислить его к определенной группе. Группы и роли могут быть организованы в иерархию подгрупп и подролей с наследованием прав доступа вниз по иерархии.

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

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

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

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

Во-вторых, ответ на запрос об авторизации может зависеть от ряда обстоятельств:

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

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

Итак, полная централизация всех механизмов авторизации — задача весьма непростая. Перечислим лишь главные сложности.

• Отдельные системы должны тем или иным способом поддерживать управление авторизацией «извне». Реально такое делегирование возможно при помощи специализированных модулей расширения (plug-in).
• Центральная система, управляющая авторизацией, должна понимать и поддерживать семантику прав доступа каждой из управляемых систем.

На практике создание подобной централизованной системы обычно включает в себя некоторый объем собственной разработки. В качестве основы может использоваться Kerberos, позволяющий передавать информацию о правах доступа в момент авторизации, или продукт наподобие Baltimore SelectAccess, Sun ONE Identity Server или Evidian AccessMaster.

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

На рисунке показан интерфейс Baltimore SelectAccess, реализующий упомянутую выше матричную структуру.

Единая система персонализации

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

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

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

Альтернативой портальному решению можно считать средства управления рабочими станциями наподобие Microsoft Systems Management Server или Novell ZENWorks. При помощи таких решений состояние рабочей станции контролируется централизованно и настраивается в зависимости от того, кто использует компьютер в данный момент.

Единая система аудита доступа

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

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

На практике подобные системы можно рассматривать как часть системы единой авторизации.

Унификация данных о пользователях

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

Для решения этой задачи применяется описанная выше техника построения единой системы каталогов. Хранилища данных о пользователях либо консолидируются воедино (так что на пользователя приходится одна учетная запись с верными значениями всех описательных атрибутов), либо синхронизируются при помощи метакаталога. Заметим, что при использовании метакаталога разные атрибуты могут иметь разные авторитетные источники; так, адрес электронной почты может копироваться из почтового сервера, а должность — из системы управления кадрами.

Единая система делегированного управления данными о пользователях

Создание единой системы управления данными о пользователях и их правами позволит централизовать управление всем, что касается отдельного пользователя. Однако это не означает, что все административные задачи должны выполняться одним администратором (или даже одной группой администраторов).

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

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

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

Применение Identity Management

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

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

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

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

Внедрение Identity Management — долгосрочный проект, способный принести реальный выигрыш. Обдумывать и планировать внедрение таких систем нужно заранее, то есть уже сегодня.

Предыдущая новость:
Соответствовать требованиям рынка Следующая новость:
Единый взгляд Открытых Технологий