Бизнес цели

• Снижение затрат на управление доступом и повышение эффективности работы персонала;
• Повышение уровня информационной безопасности;
• Упрощение создания и модернизации бизнес-приложений;
• Расширение бизнеса за счет предоставления доступа к WEB-ресурсам компании через интернет;
• Унификация бизнес-правил предоставления доступа к разнородным информационным ресурсам компании;
• Снижение рисков несанкционированного доступа.

Актуальность решения

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

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

Описание решения

Каждой автоматизированной системе свойственно наличие следующих  компонентов и механизмов или их аналогов.

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

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

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

Централизованная система управления доступом

Логика работы «ресурсной службы» приложения при этом меняется. Возможны два варианта ее функционирования:

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

При использовании обоих вариантов контроллер политик играет роль связующего звена с центральной системой управления доступа.

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

Политики в каталоге, как правило, включают в себя списки контроля доступа. Списки контроля доступа содержат данные о ресурсе, к которому ограничивают доступ, УЗП (или группы УЗП) и наборы атрибутов, определяющих для каждой УЗП (группы УЗП) права доступа к ресурсу.

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

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

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

К самой системе при этом предъявляются требования открытости и масштабируемости  архитектуры, поскольку она является одной из наиболее критичных систем предприятия. Поэтому предполагается строить ее на базе открытых стандартов и протоколов. Организация модели доступа на базе предлагаемой архитектуры позволяет поддерживать использование современных методов аутентификации и авторизации (X.509 Certificates, NTLM, Kerberos, TAI, Basic Authentication и др.).

В настоящее время практически все автоматизированные системы строятся на основе Web-сервисов. Описываемое решение имеет встроенные механизмы интеграции с приложениями, построенными на базе Web-технологий.

Реализация решения на базе линейки продуктов IBM Tivoli

Для реализации механизмов по управлению доступом используется IBM Tivoli Access Manager (ITAM). Данный продукт реализует единый каталог пользователей и базу политик предоставления доступа.

Политики доступа в Tivoli Access Manager реализуется с помощью следующих механизмов:

• списков контроля доступа. Списки контроля доступа реализуют разграничение доступа к ресурсу на уровне прав пользователей и групп пользователей;
• политик защищаемого объекта. Разграничение прав доступа на уровне свойств объекта и параметров доступа (таких как время доступа, IP-адрес компьютера с которого осуществляется доступ и т.п.)
• правила авторизации. Правила авторизацию позволяют настроить специальные условия доступа, основанные на дополнительных атрибутах. Правила авторизации реализуются в системе при помощи XSLT преобразований (при этом атрибуты поступают на вход правила в виде специального в формате XML).

В состав Tivoli Access Manager входит набор готовых контроллеров политик для типовых защищаемых ресурсов (серверов Web-приложений, UNIX-операционных систем, приложений .NET и др.). Данные компоненты представляют собой некоторую надстройку («плагин») над защищаемой системой.

Защита Web приложений возможна также с использованием специального компонента WebSeal, который представляет собой реверсивный proxy-сервер и реализует защиту доступа к данным на уровне фильтрации запросов HTTP.

Запрос авторизации также может передаваться при помощи API функций, реализованных в Tivoli Access Manager в виде Java классов и библиотек C. Данный механизм позволяет интегрировать в единую систему предоставления доступа приложения сторонних производителей и упрощает разработку новых приложений.

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

Данных механизм реализуется при помощи продукта IBM Tivoli Identity Manager. IBM Tivoli Identity Manager позволяет посредством специальных программных адаптеров централизованно осуществлять наполнение каталогов автоматизированных систем. Логика работы ресурсных служб самих систем при этом не меняется.

Совместное использование продуктов Tivoli Access Manager и Tivoli Identity Manager позволяет построить единую систему аутентификации и авторизации пользователей (на базе продукта Tivoli Access Manager) и организовать централизованное управление всеми автоматизированными системами (на базе продукта Tivoli Identity Manager). При этом Tivoli Access Manager является управляемой системой по отношению к Tivoli Identity Manager наравне с остальными автоматизированными системами предприятия.