Рост популярности серверов виртуальных каталогов

Большинство систем управления удостоверениями и доступом (IAM) состоит из множества частей, в число которых обычно входит Active Directory (AD).

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

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

Все это хорошо работало для приложений внутри леса AD, в котором находятся все нужные данные пользователей, или леса с установленными отношениями доверия, открывающими этим приложениям доступ к данным пользователей из другого леса. А что если приложение находится в лесу, для которого невозможно установление отношений доверия с корпоративным лесом, хотя бы из-за его расположения (например, в демилитаризованной зоне или вообще за пределами корпоративного сетевого экрана)? А если это даже не приложение Windows? Компании вынуждены искать решение, позволяющее объединить данные удостоверений из разных источников и сделать их доступными для всех приложений, которые в этих данных нуждаются.

Сервер метакаталогов

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

В частности, распространенный вариант использования службы метакаталогов — поместить в лес AD в демилитаризованную зону (с поддержкой приложения с выходом в Интернет) уникальные идентификаторы (ID) всех пользователей данного подразделения в корпоративном лесу. Согласно требованиям безопасности, между корпоративным лесом AD и лесом в демилитаризованной зоне с выходом в Интернет не может быть отношений доверия. Как обеспечить сотрудникам компании, администрирующим или использующим лес в демилитаризованной зоне, возможность задействовать те же учетные данные, что и во внутреннем корпоративном лесу (то есть реализовать однократную регистрацию — SSO)? Эту задачу решает сервер метакаталогов, который выносит соответствующие объекты и атрибуты из метавселенной в лес в демилитаризованной зоне, обеспечивая синхронизацию учетных данных между корпоративным лесом и лесом в демилитаризованной зоне, как показано на рисунке 1.

Рисунок 1. Вариант применения сервера метакаталогов

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

Наконец, может возникнуть вопрос масштабируемости; сервер метакаталогов перемещает множество данных удостоверений между конечными точками, даже если в этом нет насущной необходимости. Возьмем, к примеру, приложение, имеющее сотни тысяч авторизованных пользователей в своем локальном хранилище удостоверений, заполняемом сервером метакаталогов. Предположим, что приложение запрашивает регулярно обновляемый атрибут lastLogon у корпоративной AD. Даже если в это приложение входят лишь пять пользователей в день, приложению передаются все данные удостоверений всех его пользователей. А поскольку атрибут lastLogon регулярно обновляется, его значение для многих пользователей также должно передаваться приложению в ходе каждого цикла синхронизации. Это означает множество циклов обработки, выполняемых впустую.

Виртуальный сервер каталогов

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

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

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

Рисунок 2. Распространенный сценарий применения виртуального сервера каталогов

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

Новый перспективный сценарий, использующий сильные стороны концепции виртуального сервера каталогов, реализуется с участием «облачных» вычислений. Для безопасного доступа к «облачной» службе (например, Salesforce.com) между поставщиком удостоверений (то есть вашей организацией) и поставщиком службы (Salesforce.com) должно быть установлено федеративное отношение доверия. Это осуществляется путем развертывания локального сервера федерации (например, службы федерации Active Directory (AD FS) или PingFederate), который генерирует LDAP-запросы к вашей среде удостоверений и строит маркеры безопасности, предоставляемые Salesforce.com. Федерацию также можно организовать с участием поставщика интернет-удостоверений Identity as a Service (IDaaS), например Symplified или Okta.

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

Рисунок 3. Упрощение архитектуры федерации удостоверений

Шон Дьюби (sdeuby@windowsitpro.com) — старший аналитик в компании Platform Vision с 25-летним стажем работы в области корпоративных информационных систем. Внештатный редактор Windows IT Pro, имеет звание MVP