Управление правами доступа в корпоративных web-системах

Информационная инфраструктура многих крупных организаций - это нередко набор слабо связанных между собой островков информационных систем (ИС), созданных в разных подразделениях и филиалах и реализованных на разных платформах. Например, в головном офисе компании функционирует интранет-система, построенная на WebSphere Application Server, в отделе поддержки установлена система управления услугами HP ServiceDesk, система заказов работает на основе php-скриптов и базы данных mySQL, а в филиалах есть свои web-системы на основе Apache, IIS. Знакомая картина, не правда ли? При этом у каждого такого островка свой круг пользователей и собственный набор правил доступа к ресурсам. Разумеется, организации, чтобы обеспечить возможность эффективной работы своих сотрудников с частями общей ИС, размещенными в разных департаментах, необходимо устранить электронные границы между ними.

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

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

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

Как это делается

Для решения задач разграничения доступа к различным ИС создан целый класс продуктов - системы управления доступом (Access Management Systems, AMS). Оговоримся сразу, что сфера их применения выходит за рамки web-систем, однако в данной статье мы хотели бы остановиться на возможностях AMS для web-приложений.

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

Информационные базы
Данные о пользователях размещены в хранилище User Store, информация о правах доступа - в Policy Store. Эти хранилища могут быть реализованы в виде каталога LDAP (например, Sun Java Systems Directory Server, IBM Directory Server, Windows Active Directory или Novell eDirectory) либо реляционной базы данных (Oracle, MS SQL). Основной компонент системы управления учетными записями - сервер авторизации Policy Server. Он производит аутентификацию пользователей на основе данных из User Store и авторизацию на основе Policy Store. Модули Policy Server написаны практически для всех платформ: Windows, Linux, Solaris, AIX, HP-UX. Наиболее широко применяются серверы авторизации, построенные на базе продуктов IBM Tivoli Access Manager, Netegrity Siteminder, HP OpenView Select Access, RSA ClearTrust. Рассмотрим механизм их работы на примере Netegrity Siteminder и Tivoli Access Manager, архитектуры которых во многом схожи.

Агенты
Запросы к web-серверу или серверу приложений перехватываются специальной программой-агентом, которая, обращаясь к Policy Server, проверяет, аутентифицирован ли пользователь и имеет ли он право на доступ к данному ресурсу. Если все условия выполнены, агент транслирует запрос на родительский web-сервер или сервер приложений. Такие агенты разработаны для web-серверов Microsoft IIS, Apache, IBM HTTP, iPlanet и серверов приложений IBM WebSphere, BEA WebLogic и Jboss. Если же используется web-сервер, для которого нет WebAgent, запросы перехватываются реверсивным прокси-сервером, разрешения проверяются сервером авторизации и при наличии у пользователя соответствующих прав транслируются на web-сервер.

Механизм поддержки сессий
При первом обращении к ресурсам, защищаемым AMS, происходит аутентификация пользователя. Если она прошла успешно, в память браузера или на диск клиентской станции записывается фрагмент данных с информацией о пользовательской сессии (cookie), после чего cookie предоставляется агентам системы для подтверждения аутентификации пользователя. Разумеется, набор cookie хранится в зашифрованном виде, а ключи шифрования, которые использует Policy Server, помещаются в централизованное хранилище Key Store, также представляющее собой каталог LDAP или базу данных SQL.

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

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

Усиленная аутентификация
Помимо базовой аутентификации (имя пользователя и пароль) могут применяться HTML-формы, где, кроме имени и пароля, запрашиваются дополнительные атрибуты пользователей, например идентификационный номер сотрудника. Для усиления защиты используются также сертификаты Х.509, токены SecurlD, протоколы шифрования SSL/TLS и устройства, совместимые с PKCS #7. При аутентификации можно присваивать пользователю уровень доступа, точнее, вес схемы аутентификации. Тогда повторная аутентификация потребуется только при обращении к ресурсам с более высоким весом схемы.

Персона и доступ

Существует несколько способов управления доступом пользователей. Самый простой, используемый в большинстве ОС и web-серверов, - это списки доступа. Однако такой способ авторизации не всегда удовлетворяет бизнес-требованиям, поскольку схема "кому и что" не всегда применима. Часто возникает вопрос: кому, когда, откуда и на каких условиях нужно предоставить доступ. В таких случаях в AMS используется ролевой механизм контроля доступа Role Based Access Control List. В нем определяются такие параметры сеанса пользователя, как время доступа, откуда может осуществляться доступ, а также более сложные правила бизнес-логики, реализуемые в прикладных модулях.

Сервисы саморегистрации
Согласно статистике западных аналитических компаний, до 80% запросов в Help Desk поступает от сотрудников, которые не могут войти в систему или хотят сменить пароль. В системы управления доступом могут быть встроены сервисы саморегистрации и смены пароля (хотя обычно эти функции относятся к системам управления учетными записями).

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

Индивидуальная настройка среды
Особо стоит отметить, что при аутентификации web-сервер или приложение получает довольно много информации о пользователе из записи о нем в LDAP-каталоге или другом хранилище. Данная информация передается агентом серверу приложений для персонализации среды пользователя. Кроме того, в журналах посещений записывается дополнительная информация о пользователях, в том числе о тех, кто не прошел аутентификацию, поскольку в браузер таких пользователей передается cookie с уникальным номером. Впоследствии эти данные используются для анализа работы сервера Business Intelligence.

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

Самое изящное решение проблемы управления пользователями в гетерогенной среде - то, которое реализовано по схеме однократной регистрации (Single Sign-On, SSO). Множество реализаций SSO можно подразделить на два типа: для сеансов web-приложений (WebSSO), где пользователь вводит пароль при первом обращении к web-приложению, и Desktop SSO, когда пользователь вводит свои данные только при входе в настольную операционную систему.

Однодоменная модель WebSSO
Поскольку для передачи информации об аутентификации при схеме WebSSO (рис. 2) используется механизм cookie, то проблем с аутентификацией внутри одного домена второго уровня (company.com) не возникает.

Для каждого запроса внутри домена выдается cookie с информацией о пользовательской сессии. Однако данный механизм не работает, если AMS обслуживает несколько пространств доменных имен, например companyl.com и company2.com. Механизм cookie в целях безопасности передает ответы агентам внутри доменов второго уровня и выше (рис. 3).

Многодоменная модель WebSSO
Для однократной регистрации между двумя доменами второго уровня применяются механизмы междоменной аутентификации (Cross Domain SSO, CDSSO), которые могут быть реализованы в двух моделях: Push и Pull.

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

В модели Pull один из доменов выделен в сети для аутентификации - он называется Cookie Provider, а набор доменов, защищаемых AMS, носит название e-Community, при этом один или несколько серверов домена Cookie Provider назначаются исполнителями запросов аутентификации из всех остальных доменов. Такой(ие) сервер(ы), естественно, именуется (именуются) главным(и) сервером(ами) аутентификации - Master Authentication Server (MAS), и все запросы на данную процедуру из e-Community будут перенаправляться на MAS (рис. 4). В такой Pull-реализации CDSSO, если агент не получает cookie от браузера, при обращении пользователя к ресурсам для его аутентификации инициируется запрос к MAS. Если в MAS cookie тоже не предоставляется (т.е. пользователь еще не аутентифицирован), то происходит аутентификация пользователя методом аутентификации MAS. После этого в браузер пользователя помещаются cookie от MAS, затем пользователь специальной командой перенаправляется в начальный домен, где ему по представленным параметрам также создается cookie. Все дальнейшие запросы к ресурсам данного домена осуществляются на базе cookie этого домена. Если пользователю нужны ресурсы другого домена, агент целевого домена инициирует переход на MAS, где уже есть cookie, и cookie пользователя создается из целевого домена без повторной аутентификации.

Данный способ заметно сложнее первого в реализации, зато избавляет от «навязанных» переходов. При этом у каждого домена могут быть свои Policy Server и User Store. Между хранилищами пользователей выполняется отображение (mapping) с использованием схем "один к одному", "один ко многим", "многие к одному", "многие ко многим".

В качестве примера реализации Desktop SSO может быть рассмотрена схема, где MAS реализован на агенте для Internet Information Server, а клиенты пользуются браузером Internet Explorer. Тогда при обращении к ресурсам запросы на аутентификацию будут переданы серверу MASTIS, который произведет аутентификацию на основании учетной записи Windows, при помощи механизма SPNEGO, по протоколу Kerberos или NTLM - в зависимости от версии клиентской ОС. Заметим, что существует и схема расширенной регистрации SSO, которой могут пользоваться партнеры и клиенты компании. Здесь применяются федеративные сервисы на базе SAML (Security Assertion Markup Language) - основанного на XML стандарта безопасности (иногда эту схему называют федеративной SSO). SAML дает возможность партнерам обмениваться информацией об аутентификации пользователей по каналам HTTP SSL. Особенность данной реализации в том, что у бизнес-партнера или клиента может отсутствовать система управления доступом. В этом случае необходимо лишь установить SAML-агента, причем необязательно от того же производителя, что и основная AMS. После аутентификации на сайте (SAML-producer) пользователь получает с этого сайта SAML Artifact для доступа к другим сайтам партнеров (SAML-consumer). Механизм федеративной SSO поддерживается Tivoli Access Manager, Netegrity Siteminder и HP OpenView Select Access.

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

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