ISSP \ Домен 02. Управление доступом. Часть 2

В этой части рассмотрены следующие вопросы:

• Идентификация и аутентификация
• Управление идентификацией
• Каталоги
• Роль каталогов в Управлении идентификацией
• Управление паролями
• Синхронизация паролей
• Система самообслуживания для сброса паролей
• Сброс паролей с дополнительной помощью
• Функциональность единого входа
• Управление учетными записями
• Инициализация
• Обновление профиля
• Интеграция
• Управление доступом и языки разметки

Обновлено: 19.03.2010

3.1. Идентификация и аутентификация

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

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

Для аутентификации по знанию («что-то знать») могут использоваться, например, такие факторы, как пароль, PIN-код, девичья фамилия матери или комбинации этих факторов. Такой способ аутентификации обычно является самым простым для внедрения. Однако у него есть недостаток – другой человек может получить это «знание» и воспользоваться им для несанкционированного доступа к системе.

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

Аутентификация по характеристикам («кем-то быть»), т.е. проверка чего-то, специфичного для человека, более интересна. Этот метод основан на проверке физических атрибутов, например, биометрии (более подробно об этом рассказано далее в разделе «Биометрия»).

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

Требования к идентификации. При выпуске идентификаторов для пользователей, следует учитывать следующее:

• Каждый идентификатор должен быть уникален для обеспечения подотчетности;
• Должна использоваться стандартная схема имен;
• Идентификатор не должен указывать на должность или задачи пользователя;
• Идентификатор не должен совместно использоваться несколькими пользователями.

Обзор управления доступом. Основные концепции управления доступом:

• Идентификация
• Субъекты предоставляют идентификационную информацию
• Имя пользователя, идентификатор пользователя, номер счета
• Аутентификация
• Проверка идентификационной информации
• Парольная фраза, PIN-код, биометрия, одноразовый пароль, обычный пароль
• Авторизация
• Использование критериев, определяющих операции, которые субъект может выполнять над объектом
• «Я знаю, кто вы, что теперь мне разрешить вам делать?»
• Подотчетность
• Ведение и мониторинг журналов регистрации событий для отслеживания действий субъектов над объектами

Идентификация – достаточно сложная концепция, которая имеет множество нюансов (например, один и тот же человек может иметь множество различных логинов в различных системах, что может вызвать значительные сложности при попытке централизации управления доступом). Определение идентификации в сфере безопасности имеет три ключевых аспекта: уникальность (uniqueness), неявность (nondescriptive) и публикация (issuance). Уникальность подразумевает, что каждый пользователь должен иметь уникальный идентификатор (для обеспечения подотчетности). Неявность означает, что никакая из частей учетных данных не должна указывать на цель учетной записи (например, не следует использовать логины типа «administrator», «CEO», «backup_operator» и т.п.). Публикация подразумевает возможность выпуска средств идентификации другим уполномоченным органом (например, идентификационные карты).

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

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

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

Рынок продуктов управления идентификацией сегодня процветает, так как эти продукты позволяют снизить административные расходы, повысить безопасность, обеспечить соответствие требованиям и повысить уровень сервиса в масштабах всей компании. Продолжающееся повышение сложности и разнообразия сетевых сред только повышает потребности в управлении тем, кто может получить доступ, к чему и когда. Компании используют различные типы приложений, сетевых операционных систем, баз данных, ERP-систем, CRM-систем – все они используются для выполнения различных задач бизнеса. У компаний есть партнеры, консультанты, подрядчики, постоянные и временные сотрудники. Каждый из пользователей использует несколько различных видов систем для выполнения своих ежедневных задач, что делает систему управления доступом и обеспечение необходимого уровня безопасности различных типов данных весьма трудной задачей. Часто это приводит к неожиданным и невыявленным «дырам» в защите активов, дублированию и противоречию средств управления, несоответствию действующим требованиям. Целью технологий IdM является упрощение задач администрирования и наведение порядка в этом хаосе.

Ниже представлены наиболее частые вопросы, возникающие сегодня в компаниях, при управлении доступом к активам:

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

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

• Каталоги
• Управление веб-доступом
• Управление паролями
• Функциональность единого входа (SSO - Single Sign-On)
• Управление учетными записями
• Обновление профилей

Каталоги

Большинство компаний имеют тот или иной каталог (directory), который содержит информацию о компании, ее сетевых ресурсах и пользователях. Большинство каталогов имеют формат иерархической базы данных, основаны на стандарте X.500 и имеют протокол доступа (например, LDAP - Lightweight Directory Access Protocol), позволяющий приложениям и субъектам взаимодействовать с ним. Приложения могут запросить информацию о конкретном пользователе, сделав LDAP-запрос в каталог, а пользователь аналогичным образом может запросить информацию о конкретных ресурсах.

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

В среде Windows, когда вы входите в систему, вы регистрируетесь на контроллере домена (DC - Domain Controller), который хранит в своей базе данных иерархический каталог. Эта база данных используется службой каталога (AD - Active Directory), которая организует сетевые ресурсы и выполняет функции управления доступом пользователей. Как только пользователь успешно аутентифицируется на контроллере домена, ему станут доступны определенные сетевые ресурсы (сервер печати, файловый сервер, почтовый сервер и т.д.) в соответствии с настройками AD.

Как же службе каталогов удается содержать в порядке все эти элементы? Она использует для этого пространства имен (namespace). Каждая служба каталога имеет способ идентификации и именования объектов, которыми она управляет. В базе данных, основанной на стандарте X.500 и доступной посредством LDAP, служба каталогов присваивает каждому объекту различимое имя (DN - Distinguished Name). Каждое DN представляет собой набор атрибутов, относящихся к соответствующему объекту, который хранится в каталоге как элемент. В следующем примере DN состоит из общего имени (cn - common name) и компонента домена (dc - domain component).

dn: cn=Ivan Ivanov,dc=Acme,dc=ru
cn: Ivan Ivanov

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

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

Организация всего этого хлама. В базе данных каталога, основанной на стандарте X.500, используются следующие правила организации объектов:

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

Схема описывает структуру каталога, используемые в нем имена и другие вещи (схема и компоненты базы данных более глубоко описаны в Домене 09).

OU (organizational unit ) – это организационные единицы. Они используются в качестве контейнеров для других OU, пользователей и ресурсов. Они обеспечивают организационную структуру «родительский-дочерний» (иногда ее называют «дерево-лист»).

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

Роль каталогов в Управлении идентификацией

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

Много информации, хранящейся в каталоге IdM, разбросано по всей компании. Информация об атрибутах пользователей (статус сотрудника, должностная инструкция, подразделение и т.д.) обычно хранится в базе данных HR (отдела кадров), аутентификационная информация может быть на сервере Kerberos, информация о ролях и группах хранится в базе данных SQL, а информация о доступе к ресурсам размещена в AD на контроллере домена. Продукты управления идентификацией поступают очень хитро, создавая мета-каталоги или виртуальные каталоги, которые собирают необходимую информацию из множества различных источников и хранят ее в одном центральном каталоге. Это обеспечивает унифицированное представление всей цифровой идентификационной информации пользователей в рамках всей компании. Мета-каталог периодически синхронизируется со всеми хранилищами идентификационной информации, чтобы обеспечить актуальной информацией все приложения и компоненты IdM компании.

Разница между виртуальным каталогом и мета-каталогом состоит только в том, что мета-каталог физически хранит идентификационные данные в своем каталоге, а виртуальный каталог только ссылается на реальные места хранения идентификационных данных.

Рисунок 2-3 иллюстрирует центральный LDAP каталог, который используется службами IdM: управление доступом, инициализация, управление идентификацией. Когда одна из этих служб принимает запрос от пользователя или приложения, она извлекает необходимые данные из каталога, чтобы выполнить запрос. Если эти данные хранятся в различных местах, каталог метаданных, в свою очередь, извлекает данные из их источников и обновляет LDAP каталог.

Рисунок 2-3.Мета-каталог извлекает данные из других источников для внесения их в IdM каталог 

Управление веб-доступом

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

Рисунок 2-4 показывает основные компоненты и действия в процессе управления веб-доступом.

Рисунок 2-4.Простой пример управления веб-доступом

1. Пользователь отправляет учетные данные на веб-сервер.
2. Веб-сервер проверяет учетные данные пользователя.
3. Пользователь запрашивает доступ к ресурсу (объекту).
4. Веб-сервер на основе политики безопасности проверяет может ли пользователь выполнять эту операцию.
5. Веб-сервер разрешает доступ к запрошенному ресурсу.

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

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

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

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

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

Веб-сервер постоянно просит браузер Кэти доказать, что она была аутентифицирована. Браузер делает это, предоставляя информацию куки-файла (информация куки-файла может содержать пароль пользователя, номер учетной записи, уровень безопасности, информацию о браузере и/или информацию персонализации). Все время, пока Кэти аутентифицирована, программное обеспечение веб-сервера отслеживает каждый ее запрос, журналирует ее действия, делает изменения в ее контексте безопасности в соответствии с ее запросами. Контекст безопасности (security context) – это уровень авторизации, основанный на разрешениях, полномочиях и правах доступа.

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

ПРИМЕЧАНИЕ. Куки-файл в формате текстового файла может быть сохранен на жестком диске пользователя (постоянно) или может храниться только в памяти (в течении сессии). Если в куки-файле содержится какая-либо критичная информация, его следует хранить только в памяти и стирать по окончании сессии.

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

ПРИМЕЧАНИЕ. Технологии SSO будут рассмотрены далее в этом домене.

Итак, продукты WAM позволяют администратору настроить и управлять доступом к внутренним ресурсам. Этот тип управления доступом обычно используется для управления внешними сущностями (пользователями), запрашивающими доступ. Продукт WAM может работать как на единственном веб-сервере, так и на ферме серверов.

Управление паролями

Мы рассмотрим требования к паролям, вопросы безопасности и лучшие практики далее в этом домене. Сейчас нам нужно понять, как работает управление паролями в среде IdM.

Сотрудники службы технической поддержки и администраторы знают сколько времени теряется на сброс паролей, когда пользователи забывают их. Основной проблемой чаще всего является количество различных паролей для доступа в различные системы, которые пользователи должны помнить. Для изменения пароля администратор должен напрямую подключиться к управляющему программному обеспечению соответствующей системы и изменить значение пароля. Казалось бы, это не так трудно, однако представьте, что в компании работают 4000 пользователей, используются 7 различных систем, 35 различных приложений, а ряд подразделений работает круглосуточно...

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

• Синхронизация паролей (password synchronization). Уменьшает количество различных паролей от различных систем, которые нужно помнить пользователям.
• Система самообслуживания для сброса паролей (self-service password reset). Уменьшает количество звонков в службу технической поддержки, позволяя пользователям самим сбрасывать свои пароли.
• Сброс паролей с дополнительной помощью (assisted password reset). Упрощает процесс сброса паролей службой технической поддержки. Могут использоваться различные механизмы аутентификации (биометрия, токены).

Синхронизация паролей

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

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

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

Система самообслуживания для сброса паролей

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

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

ПРЕДУПРЕЖДЕНИЕ. Вопросы не должны быть такими, ответы на которые может легко узнать любой, либо информация по которым находится в публичном доступе, так как кто угодно может найти эту информацию и попытаться идентифицироваться в системе под чужим именем.

Сброс паролей с дополнительной помощью

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

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

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

Функциональность единого входа

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

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

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

Большинство сред не являются гомогенными с точки зрения устройств и приложений, что еще больше усложняет надлежащее внедрение корпоративного решения SSO. Унаследованные системы часто требуют другого типа процесса аутентификации, отличающегося от того, который предоставляет система SSO. В настоящее время около 80% приложений и устройств потенциально способны работать с программным обеспечением SSO, а оставшиеся 20% требуют, чтобы пользователи аутентифицировались в них напрямую. В таких ситуациях ИТ-департамент может самостоятельно разработать решение для унаследованных систем на базе командных скриптов.

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

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

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

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

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

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

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

ПРИМЕЧАНИЕ. Эти типы продуктов управления учетными записями обычно используются для сопровождения внутренних учетных записей. Управление веб-доступом используется в основном для внешних пользователей.

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

Инициализация

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

Большинство решений IdM извлекают информацию о пользователях из кадровой базы данных (называемой авторитетным источником (authoritative source)), потому что в ней эта информация уже собрана, хранится в одном месте и постоянно обновляется по мере изменения состояния работников и подрядчиков.

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

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

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

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

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

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

Рисунок 2-5.Компоненты управления идентификацией

Обновление профиля

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

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

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

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

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

Каталог (или мета-каталог) системы IdM централизовано хранит всю идентификационную информацию, поэтому он очень важен.

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

Интеграция

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

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

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

ПРИМЕЧАНИЕ. Федеративный идентификатор, как и все технологии IdM, обсуждаемые далее, обычно более сложны, чем представляется в этом тексте. Это всего лишь обзор «на один дюйм в глубину», позволяющий сдать экзамен CISSP. Для получения более глубоких сведений о технологиях IdM посетите веб-сайт автора www.logicalsecurity.com/IdentityManagement.

Кому нужно управление идентификацией? Следующий список является хорошим показателем для оценки потребности вашей компании в решениях по управлению идентификацией:

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

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

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

HTML (HyperText Markup Language – гипертекстовый язык разметки) появился в начале 1990-х годов. Предшественниками HTML были SGML (стандартный обобщенный язык разметки) и GML (обобщенный язык разметки). В настоящее время HTML по-прежнему широко используется.

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

Более мощный язык разметки – XML (Extensible Markup Language – расширяемый язык разметки) – был разработан в качестве спецификации для создания различных языков разметки. Исходя из этой спецификации XML были разработаны более специфические стандарты, предоставляющие для отдельных отраслей необходимые им функции. Отдельные отрасли имеют различные потребности в использовании языков разметки, что может вызвать проблемы совместимости для компаний, которым требуется взаимодействовать друг с другом. Например, автомобильной компании нужно работать с данными о ценах, цветах, запасных частях, моделях и т.п. А компания, производящая автомобильные шины, работает с другими данными – этапах производства, спецификациях, типах синтетической резины, способах доставки для автомобильных компаний и т.п. Эти компании должны иметь возможность взаимодействия на уровне своих компьютеров и приложений. К примеру, автомобильная компания использует тег языка разметки <модель>, который определяет модель автомобиля, и шинная компания также использует тег <модель>, однако он определяет модель шин. Это приводит к возникновению проблемы совместимости. Чтобы иметь возможность взаимодействия, эти компании должны говорить на одном языке. Таким языком является XML, который должны использовать и понимать обе взаимодействующие компании. Поскольку компании используют различные типы данных, необходимые им для работы, каждая компания (либо отрасль) использует свой производный от XML стандарт, который лучше всего подходит ее потребностям.

ПРИМЕЧАНИЕ. XML используется для множества различных целей, а не только для построения веб-страниц и веб-сайтов.

Но какое все это имеет отношение к управлению доступом? Существует язык разметки, построенный на базе XML, предназначенный для обмена информацией о доступе пользователей к различным ресурсам и сервисам. Скажем, шинная компания предоставляет менеджерам автомобильной компании возможность для заказа шин. Менеджер автомобильной компании Боб регистрируется в программном обеспечении автомобильной компании и делает заказ на 40 комплектов шин. Но каким образом шинная компания узнает, что этот заказ действительно исходит от автомобильной компании и от уполномоченного на это менеджера? Программное обеспечение автомобильной компании может передавать программному обеспечению шинной компании идентификационную информацию о пользователе и группе. На основе этой информации программное обеспечение шинной компании может провести авторизацию данного запроса и реально позволит Бобу заказать 40 комплектов шин.

Языком разметки, который может обеспечить такую функциональность, является SPML (Service Provisioning Markup Language – обеспечивающий сервис язык разметки). Этот язык позволяет одной компании передавать запросы на обслуживание, а другой компании принимать их и обеспечивать (разрешать) доступ к своим сервисам. Так как и отправляющая, и принимающая компании следуют одному и тому же стандарту (XML), они могут взаимодействовать.

Если автомобильная и шинная компании имеют реализованную модель доверия и общие методы идентификации, авторизации и аутентификации, Боб может быть аутентифицирован и авторизован программным обеспечением автомобильной компании, которое передаст соответствующую информацию программному обеспечению шинной компании, и Бобу не нужно будет дважды проходить аутентификацию. Таким образом, когда Боб регистрируется в программном обеспечении автомобильной компании, он сразу же получает возможность заказа шин в шинной компании. Это означает, что автомобильная и шинная компании имеют домены безопасности, которые доверяют друг другу (это доверие может быть либо взаимным, либо односторонним). Компания, которая отправляет авторизационные данные, называется поставщиком подтверждений (producer of assertion), а получающая их компания – потребителем подтверждений (consumer of assertion).

Компании не должны принимать решения об авторизации волей-неволей. Например, разработчик XML для шинной компания должен не просто принимать решение о том, что менеджеры могут выполнять одни функции, бухгалтеры – другие функциональности, а Сью может делать все, что захочет. Компания должна иметь политики безопасности для конкретных приложений, в которых указано, какие роли и отдельные пользователи могут выполнять конкретные функции. Эти решения должны приниматься не на уровне разработчика приложений. Автомобильная и шинная компании должны следовать одинаковым политикам безопасности, чтобы когда менеджер регистрируется в приложении автомобильной компании, обе компании одинаково понимают, что может делать эта роль. Это является целью XACML (eXtensible Access Control Markup Language – расширяемого языка разметки управления доступом). Политики безопасности приложений могут совместно использоваться различными приложениями, чтобы гарантировать, что все приложения следуют одним и тем же правилам безопасности.

ПРИМЕЧАНИЕ. Кто разрабатывает и отслеживает все эти стандартизованные языки? Это делает Организация по развитию структурированных информационных стандартов (OASIS – Organization for the Advancement of Structured Information Standards). Эта организация разрабатывает и поддерживает стандарты по различным аспектам взаимодействия через веб.

Итак, подытожим эти сведения. Компаниям нужен способ управления информацией внутри их приложений. XML является стандартом, обеспечивающим структуры метаданных, которые позволяют описывать данные. Компаниям необходимо иметь возможность передавать свою информацию, для чего им целесообразно использовать XML, являющийся международным стандартом и позволяющий избежать проблем совместимости. Пользователям на стороне отправителя нужно иметь доступ к сервисам на стороне получателя, что обеспечивается с помощью SPML. Принимающая сторона должна убедиться, что пользователь, который делает запрос, надлежащим образом аутентифицирован отправляющей стороной, прежде чем она разрешит доступ к запрошенному сервису, что обеспечивается посредством SAML. Чтобы обеспечить, что отправляющая и принимающая компания следуют одним и тем же правилам безопасности, они должны следовать одинаковым политикам безопасности, что является функциональностью, обеспечиваемой XACML.

ПРИМЕЧАНИЕ. XML рассматривается в Домене 09.

Для получения дополнительной информации об этих языках разметки и их функциях, посетите следующие сайты:

• www.oasis-open.org/home/index.php
• www.w3.org/XML
• http://saml.xml.org/
• http://identitymngr.sourceforge.net/

Ссылки по теме:

• Identity Management
• Identity Management

<<< Предыдущий раздел • Содержание • Следующий раздел >>>