Шон Дьюби (sdeuby@windowsitpro.com)- старший аналитик в компании Platform Vision с 25-летним стажем работы в области корпоративных информационных систем. Внештатный редактор Windows IT Pro, имеет звание MVP
Одна из трудностей работы специалистов по управлению идентификацией заключается в том, что им редко приходится иметь дело лишь с одной системой идентификации, такой как Active Directory (AD). Обычно внутри компании функционирует целый набор систем – провайдеров идентификации, и все они должны быть согласованно связаны между собой для использования приложениями. И это только в случае локальных систем.
По мере распространения SaaS-решений, количество приложений, которым необходимы данные идентификации, растет гораздо быстрее, чем способность большинства ИТ-подразделений безопасно предоставлять им эти данные. . В вашей среде могут присутствовать не все упомянутые здесь компоненты, но с большинством из них вам, безусловно, приходится иметь дело, а есть и такие, которые стоит рассмотреть с точки зрения развития вашей компании.
На рисунке показаны основные компоненты и связывающие их типовые информационные потоки. Рисунок не иллюстрирует рабочую среду. Например, у службы федерации провайдеров идентификации нет точек входа от службы виртуальных каталогов (VDS) и AD, поскольку задача VDS – минимизировать подключения, требующие идентификации. Идея рисунка – дать общее представление всех узлов и их типовых входов и выходов.
.jpg) |
| Рисунок. Инфраструктура идентификации |
Active Directory
В большинстве компаний AD остается основным компонентом инфраструктуры идентификации. Во всем мире эта служба является центральной службой каталогов более чем в 75 % компаний, которые насчитывают свыше 500 клиентов. AD постепенно эволюционирует с учетом потребностей современных приложений и служб. В частности, в Windows Server 2012 AD будет безоговорочно поддерживаться виртуализация и будет введена базовая поддержка утверждений. AD – технология, с которой должно уметь работать любое приложение управления идентификацией и контроля доступа (IAM), благодаря громадным инвестициям и AD-интегрированным приложениям, не говоря уже о соответствующих аппаратных средствах, программном обеспечении и инфраструктуре рабочих процессов. Добавим к этому широко распространенное убеждение, что учетные данные должны храниться локально, и станет ясно, что современные локальные реализации AD в обозримом будущем никуда не уйдут. Обычно AD – это источник уникальных данных идентификации компании, например, групп безопасности и учетных записей компьютеров, тогда как прочие объекты (идентификаторы пользователей) и атрибуты (табельные номера сотрудников) обычно поступают из «вышестоящей» системы управления персоналом (HR).
Другие источники идентификации
Повсеместное применение AD, однако, не означает, что это единственный источник идентификации. Системы управления персоналом (HR) – наиболее широко представленные в бизнесе хранилища данных идентификации, поскольку без них нельзя вести учет сотрудников. Базы данных HR, как правило, являются вышестоящими по отношению к другим хранилищам данных идентификации и не получают от них обновлений. Другие источники, такие как базы данных физических систем защиты, содержащие уникальные идентификационные коды, либо пользовательские приложения, могут иметь собственные уникальные удостоверения с различными уровнями информационного обмена с экземплярами AD.
Службы метакаталогов
Службы метакаталогов сформировались как способ объединения объектов и атрибутов из всего многообразия источников идентификации в один всеобъемлющий метакаталог, который затем обеспечивает обновление этих источников и других приложений и пополнение необходимыми данными. Преимущество службы метакаталогов состоит в том, что она теоретически позволяет переместить любой атрибут из одного источника идентификации в другой, либо сделать его доступным для любого приложения. Однако осуществить это на практике обычно нелегко. Из-за высокой стоимости реализации и поддержки большая часть метакаталогов используется лишь на крупных предприятиях. Этот компонент занимает центральное место в локальной инфраструктуре идентификации, поскольку он связывает источники и потребителей данных идентификации.
Сервер виртуальных каталогов VDS – это один из способов обеспечить обобщенное представление объектов и атрибутов из различных источников идентификации. Вместо объединения данных из различных источников на регулярной основе в единый большой метакаталог данных идентификации с последующей выдачей данных по мере необходимости VDS обеспечивает визуальное представление этих источников данных идентификации. Это представление, воспринимаемое приложением как единый каталог, на самом деле – абстракция. Всякий раз, читая «виртуализация», следует думать о «добавлении слоя абстракции». Когда приложение обращается к этому интерфейсу, VDS посылает запросы в реальном времени к необходимым источникам данных идентификации и возвращает нужные данные приложению. Благодаря слою абстракции приложению не нужна сложная логика, чтобы определить, к какому источнику следует обратиться для получения нужных атрибутов. Популярность VDS-решений объясняется тем, что они значительно проще и дешевле, чем службы метакаталогов. В инфраструктуре идентификации этот компонент занимает место между источниками данных идентификации компании и приложениями, которым требуется использовать эти источники.
Многие компании используют системы управления веб-доступом (WAM), с которыми должны быть увязаны любые новые решения по управлению данными идентификации. WAM-решения выполняют аутентификацию и авторизацию от одного или более источников данных идентификации как для внутренних, так и для обращенных вовне веб-служб. Наиболее известный вариант применения – предоставление внешнего доступа к веб-службе под защитой корпоративного брандмауэра. Такие локальные системы тесно интегрированы с несколькими источниками данных идентификации без широкого применения более новых технологий, таких как VDS, для упрощения интеграции.
Службы синхронизации каталогов нашли широкое применение в случаях, когда существует необходимость дублировать данные идентификации, содержащиеся в корпоративном хранилище, у провайдера «облачных» служб. Как преемник обработчика синхронизации сервера метакаталогов, служба синхронизации каталогов реализует облегченный процесс и устанавливается на сервере, который отслеживает изменения данных в хранилище данных идентификации (например, AD) и тотчас же реплицирует эти изменения в «облачной» службе. Обычно это односторонняя синхронизация, при которой «облачное» хранилище идентификации воспроизводит содержимое локального хранилища, либо его подмножества (например, отдельного подразделения или группы безопасности). Синхронизация каталогов используется SaaS-решениями, такими как Microsoft Office 365 и Google Apps. Кроме того, синхронизацию каталогов применяют многие провайдеры IDaaS-решений («учетные данные как услуга») для заполнения своих хранилищ данных идентификации. Синхронизация с «облачным» хранилищем может распространяться и на пароли, что зависит от провайдера и выбранного типа конфигурации.
Федерация
Последним крупным компонентом локальной инфраструктуры идентификации в том виде, в каком она существует сегодня, является служба федерации. Этот компонент служит мостом между защищенными протоколами с разделенным секретом, такими как Kerberos (применяется в AD), и протоколами на основе утверждений, такими как язык разметки для системы безопасности Security Assertion Markup Language (SAML), который используется для приложений с поддержкой утверждений. Служба федерации преобразует маркеры (токены) между различными защищенными доменами и является важным компонентом структуры, подключающей вас к «облачным» приложениям. В инфраструктуре идентификации службы федерации подключаются к одному или более источникам данных идентификации и предоставляют маркеры (токены) локальным приложениям с поддержкой утверждений, либо провайдерам служб в «облаке».
Федерация, однако, не обязательно должна быть локальной. Функции службы федерации можно передать провайдеру IDaaS, который служит посредником, обеспечивающим аутентификацию и авторизацию разнообразным SaaS-приложениям. Большинство служб также обеспечивают процедуру единой регистрации (SSO) у провайдеров служб, не поддерживающих федерацию, с использованием собственных методов.
Отдавать предпочтение провайдерам идентификации или провайдерам служб, безусловно, решать вам. Большинство из вас, вероятно, поддерживают внутренние ИТ-системы, однако любой провайдер службы с автономным хранилищем данных идентификации (например, отдельные учетные записи, создаваемые на сайте провайдера службы) для пользователей этой службы также является провайдером идентификации. А провайдер корпоративных данных идентификации, открывающий доступ к приложению своим деловым партнерам, также является провайдером службы.
В эту комбинацию, и так достаточно сложную, включаются и другие провайдеры идентификации. Многие сайты для предоставления пользователям единой регистрации SSO используют Facebook, Google, Twitter, Yahoo! и т.д. В дальнейшем эти провайдеры будут все более широко применяться на предприятиях (например, для обеспечения SSO на порталах обслуживания клиентов).
Ориентация на будущее
Важно поддерживать существующие системы в работоспособном состоянии, но не менее важно думать и о будущем. Инфраструктуру идентификации необходимо организовать так, чтобы использовать преимущества новых технологий там, где это целесообразно с точки зрения интересов бизнеса. Анализируя экономическую модель, необходимо учитывать комбинацию факторов, таких как информационная безопасность и экономия затрат отдельных подразделений (например, за счет перехода от узковедомственного управления учетными записями у провайдеров SaaS к централизованной федеративной концепции).