Каталоги LDAP и метакаталоги

Каталоги на основе протокола LDAP стали за последние два-три года «горячей» темой для ИТ-специалистов. Microsoft пропагандирует свой каталог Active Directory как ключ к снижению общей стоимости эксплуатации корпоративных компьютерных сетей, Novell, соглашаясь с идеей, агитирует за использование своего каталога eDirectory, а Sun Microsystems рекламирует iPlanet Directory Server как ядро своего набора решений для электронного бизнеса. При этом у многих еще не появилось полной ясности по поводу того, что представляют собой каталоги LDAP, для чего их надо и не надо использовать, и какие смежные технологии наподобие метакаталогов использовать с тем, чтобы извлечь из каталогов максимальную пользу. Цель статьи — навести некоторую ясность в этой области.

Начнем с вопроса: где и как хранить данные о сотрудниках, клиентах и партнерах с тем, чтобы они были легко доступны тем пользователям и приложениям, которым они нужны? Небольшие организации решают эту задачу многими нехитрыми способами, например, записывая их в текстовый файл или в файл Excel или Access. Однако с некоторого объема данных такое решение становится неприемлемым. Постоянное внесение изменений означает, что новые версии файла должны создаваться и рассылаться (и, соответственно, сохраняться или даже распечатываться) очень часто. Вдобавок, административные разделения делают необходимой работу по консолидации данных из разных источников. Другая крайность — ведение полноценной реляционной базы данных; это решение может быть технически совершенно, но его цена и сложность часто неоправданно высоки.

Каталоги LDAP призваны решить и эту задачу: хранение данных о реальных объектах в относительно простой, надежной и распределенной системе.

Истоки I: технология X.500

Идея создать общий стандарт для систем каталогов впервые возникла у инженеров Международного союза электросвязи (ITU — International Telecommunications Union) в середине 80-х. Для формирования этих стандартов была создана рабочая группа ITU X.500; первая версия стандарта X.500 вышла в 1988 году. Конечная цель проекта X.500 была весьма амбициозна: создать распределенную международную систему каталогов, содержащую в себе все данные о всех телефонных абонентах по всему миру. Предполагалось, что эта система каталогов будет располагаться на компьютерах, принадлежащих крупным телекоммуникационным компаниям (которые собственно и формировали МСЭ). Стандарт содержал в себе ключевые элементы, перечисленные ниже.

• Порядок именования данных. Согласно этому порядку, объекты в каталоге упорядочиваются в логическое "дерево": корень дерева не имеет имени, а остальные вершины характеризуются парами "атрибут-значение". Полное наименование вершины получается путем составления таких пар на пути от корня дерева к самой вершине. К примеру, человек может иметь следующий уникальный идентификатор: cn=Александр Привалов, ou=Вычислительный Центр, o=НИИЧаВо, l=Соловцы, с=ru. Здесь cn, o, ou, l, o и c - раз и навсегда зафиксированные названия атрибутов: c (country) - название страны, o (organization) - название организации, и т.д.
• Порядок представления данных. Каждая вершина дерева, помимо уникального названия, содержит информацию о соответствующем реальном объекте, представленную в виде набора пар в том же формате "атрибут-значение". Так, с указанной выше вершиной могут быть связаны пары "mail: privalov@mail.ru", "phone: +7-123-45678", и т.д.
• Клиентский протокол DAP (Directory Access Protocol), описывающий порядок посылки запросов от клиентской программы к каталогу и формат ответа.
• Протокол для создания "теневой" копии DISP (Directory Information Shadowing Protocol). Для повышения эффективности каталогов иногда имеет смысл создать резервную копию, доступную только для чтения (т.е. "теневую"), поблизости от потребителей информации. При помощи DISP один каталог может передать данные другому каталогу для использования в качестве теневой копии.
• Протокол для передачи запросов DSP (Directory System Protocol). При помощи протокола DSP один каталог может запросить у другого информацию, которая отсутствует у него самого. Таким образом, клиент, связываясь всегда с одним и тем же каталогом, сможет получать данные из всей системы каталогов.

Стандарт X.500, равно как и другие инициативы МСЭ, никак не планировал использование структуры и стандартов Internet. Так, в качестве стека сетевых протоколов, предполагалось использовать не TCP/IP, а стек OSI, требующий намного больших ресурсов.

Рис. 1. Представление данных в стандарте X.500

Истоки II: от X.500 к LDAP

После опубликования стандартов X.500 стало ясно, что задача построения глобального каталога при их помощи практически неподъемна: технология оказалась слишком сложна, а конкретные ее реализации слишком ненадежны и мало совместимы между собой. Тем не менее выяснилось, что существует заметный спрос на каталоги масштаба организации: например, многие хотели перейти от дорогостоящего и медленного процесса печатания адресных книг на бумаге к электронному хранению тех же данных. Но даже внедрение каталога X.500 в масштабе одного предприятия или университетского кампуса оказалось крайне нетривиальной задачей. Помимо проблем с самими программными продуктами встал еще и вопрос ресурсов: разработчики стандарта просто не предполагали, что возникнет надобность запускать клиент DAP на персональных компьютерах и небольших рабочих станциях под Unix.

Решение этих проблем было предложено группой из Мичиганского Университета под руководством Тима Хауса. В 1993 году Хаус с коллегами опубликовали текст RFC 1487 с описанием LDAP (Lightweight Directory Access Protocol) — протокола, работающего непосредственно с TCP/IP и достаточно «легковесного», чтобы хорошо работать на обыкновенных персональных компьютерах. Вначале предполагалось, что LDAP будет использоваться именно как дополнение к существующим продуктам X.500 для относительно маломощных компьютеров; в такой схеме клиент DAP является одновременно сервером LDAP. Производители каталогов X.500 поддержали этот подход и включили LDAP в свои продукты, что привело к резкому росту популярности каталогов масштаба организации. Тем не менее сами серверы X.500 оставались крайне сложными и ресурсоемкими. Для преодоления этой проблемы группа Хауса создала простой сервер slapd, который хранил данные непосредственно на локальном жестком диске. Таким образом каталоги LDAP, сохраняя логические стандарты X.500 (организация объектов в логическое дерево, хранение данных в виде «атрибут-значение», и т.д.), стали независимы от X.500 на уровне протоколов, полностью перейдя на стандарты эпохи Internet. В начале 1996 года группа Хауса целиком перешла в компанию Netscape, и вскоре после этого появилась первая версия Netscape Directory Server, основанная на slapd.

Использование каталогов LDAP

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

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

• Хранение данных о ресурсах (пользователях, группах, компьютерах) компьютерной сети. У каталогов Microsoft Active Directory и Novell NDS/eDirectory это предназначение является главным. Технология Active Directory, например, заменила использовавшуюся в Windows NT базу данных пользователей, компьютеров и групп, хранящуюся на контроллере домена. Подобным образом можно использовать любой каталог LDAP под Unix/Linux, совмещая его со стандартной технологией NIS. Такие каталоги часто называют NOS-каталогами (Network Operating System).
• Хранение контактных данных сотрудников организации (внутренняя адресная книга).
• Хранение контактных данных клиентов или партнеров организации (внешняя адресная книга).
• Хранение пользовательских профилей для многопользовательских программ. К примеру, сервер электронной почты Exchange 2000 поставляется вообще без своего хранилища профилей; предполагается, что профили будут размещены в Active Directory. Аналогично, такие продукты iPlanet, как сервер электронной почты или календарный сервер, поставляются вместе с iPlanet Directory Server.
• Хранение профилей пользователей сайтов Internet/extranet/intranet. При помощи таких профилей можно контролировать степень доступа пользователя и персонализировать содержание самих страниц.
• Хранение сертификатов в криптографических системах с открытым ключом (Public Key Infrastructure - PKI). Доступность любого сертификата для быстрого считывания является важным условием для качественной работы систем PKI, и каталоги LDAP представляются естественным решением. Интересно, что такое предназначение каталогов предусматривалось c самого начала: самым широко используемым сегодня стандартом PKI является X.509, разрабатывавшийся параллельно с X.500.

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

Рынок каталогов LDAP

На сегодняшний день рынок каталогов LDAP не выявил одного-двух лидеров, позиции игроков довольно стабильны. Это можно связать с тем, что весьма значительные изначальные усилия по созданию приличного сервера каталогов оказались по силам только крупным компаниям, которые не исчезают из-за колебаний рынка. Вдобавок внедрение корпоративной системы каталогов остается проектом, требующим активного вовлечения специалистов (обычно консультантов, приглашенных извне); для компаний-производителей серверов LDAP консалтинг становится немаловажной статьей дохода. Это объясняет еще и относительную географическую разделенность рынка: например, европейские компании (немецкая Siemens и ирландская Critical Path) намного сильнее в Европе, а американская iPlanet (бывшая Netscape, ныне поглощенная Sun Microsystems) — на своем домашнем рынке.

Имеющиеся серверы каталогов можно классифицировать по ряду параметров.

• Связанные или не связанные с сетевой операционной системой. В некоторых случаях NOS-каталоги вообще не подходят (так, Internet-провайдеру нет смысла заводить учетную запись Windows 2000 для каждого абонента). В других случаях использование NOS-каталога возможно, но не всегда разумно. Например, иногда профили пользователей Internet складываются отдельно от имеющегося NOS-каталога из соображений распределения риска.
• Сохраняющие или не сохраняющие совместимость с X.500.
• Поддерживающие или не поддерживающие создание теневых копий только для чтения (каталоги X.500 автоматически поддерживают создание теневых копий по протоколу DISP).
• Предлагающие или не предлагающие мультимастерную репликацию. Мультимастерная репликация означает существование нескольких синхронизированных каталогов, одновременно доступных для записи. Надо заметить, что мультимастерная репликация потенциально опасна: в каталоги LDAP не встроена система контроля транзакций, так что данные об объекте могут изменяться одновременно возможно противоречивыми способами (например, в одном каталоге под данной вершиной дерева создается еще одна вершина, а в другом первая вершина удаляется). Тем не менее мультимастерная репликация бывает полезна, если требуется по-настоящему распределенное администрирование данных каталога.

Среди имеющихся на рынке серверов каталогов стоит отметить Oracle Internet Directory и IBM SecureWay. Оба этих продукта являются по существу надстройками над существующими реляционными СУБД двух компаний; это делает их более громоздкими и менее эффективными, но упрощает работу тем организациям, у которых уже установлены соответствующие базы данных.

На практике каталоги Siemens, IBM и Oracle чаще всего внедряются в рамках более крупных проектов с участием консультантов соответствующих фирм или их партнеров. Реально только Critical Path предлагает свой продукт вне какого-либо интегрированного набора решений. Свободно распространяемый сервер OpenLDAP основан на slapd Тима Хауса и идеален для обучения технике LDAP; к сожалению, при работе с большими объемах данных OpenLDAP часто бывает нестабилен. В совокупности с общим недоверием ИТ-менеджеров к продуктам категории open source это объясняет относительно малое проникновение OpenLDAP в коммерческие организации (в университетах он довольно распространен).

Проблема переизбытка каталогов

В 1996 году компания Forrester Research опубликовала результаты интересного исследования. Опираясь на расширенное понятие «каталога» как любого компьютерного источника данных о реальных людях (сотрудниках, партнерах или клиентах организации), исследователи решили подсчитать каталоги, используемые крупными международными компаниями. Оказалось, что корпорации из списка Fortune 500 имеют в среднем по 191 (!) активно используемому каталогу. Даже со скидкой на крайнюю тщательность исследования (обновляемый файл со списком сотрудников, играющих по воскресеньям в футбол, тоже может считаться каталогом) эта цифра впечатляет. Допустим, что только 20 из этих каталогов существенны для нормального функционирования организации; это означает, что при изменении данных 20 сотрудников нужно предпринять 400 отдельных действий.

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

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

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

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

Метакаталоги

Метакаталогами (meta-directory) называются механизмы, позволяющие синхронизировать данные между различными каталогами. Сам термин «метакаталог« был введен в обиход в 1997 году аналитиками из Burton Group; в том же году появился первый коммерческий продукт, ZoomIt MetaDirectory (компания ZoomIt была вскоре после этого поглощена Microsoft).

Рис. 2. Метакаталоги с метапредставлением

Синхронизация данных включает в себя две основные составляющие: автоматическое создание и удаление учетных записей из соответствующих каталогов, и синхронизацию значений атрибутов, характеризующих эти учетные записи. В типичной конфигурации метакаталога только один из подсоединенных каталогов («собственник») имеет право создавать и удалять учетные записи (чаще всего собственником является система отдела кадров). Соответственно, при создании учетной записи в каталоге-собственнике метакаталог создаст записи и во всех подключенных системах. Для каждого атрибута имеется «авторитетный» источник, причем такие источники могут быть разными для разных атрибутов. Например, для атрибута «должность» авторитетным источником может быть тот же отдел кадров, для атрибута «e-mail» — почтовый сервер, а для атрибута «рабочий телефон» — офисная мини-АТС. Метакаталог берет данные из авторитетного источника и копирует их во все остальные подключенные системы.

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

• Имеется ли отдельное метапредставление (MetaView)? Метапредставлением называют выделенный каталог, в котором собираются данные из всех подсоединяемых (вторичных) каталогов. У метакаталогов, использующих метапредставление, синхронизация может происходить только между вторичными каталогами и метапредставлением. Напротив, метакаталоги, не использующие метапредставления, обычно позволяют копировать данные откуда угодно и куда угодно (например, из каталога в каталог, из каталога во временный файл, или из временного файла в каталог.) Метапредставление часто используется как основной каталог организации.
• Если метапредставление используется, то какие каталоги для этого подходят? Например, для метакаталога Critical Path годится любой сервер LDAP, а метакаталог Microsoft использует базу данных специального формата.
• Используются ли специальные возможности подключенных каталогов по контролю изменений? Многие каталоги (например, каталоги LDAP) содержат записи changelog, описывающие все изменения, произошедшие за последнее время. Некоторые метакаталоги в состоянии использовать эти записи во избежание ненужной работы; вместо того, чтобы считывать все данные из подключенного каталога, метакаталог, по сути, спрашивает: "А что у вас изменилось с момента нашей прежней связи?". В некоторых ситуациях эта функциональность совершенно незаменима (например, при работе с каталогами, содержащими данные о клиентах крупных телекоммуникационных компаний, где число записей зачастую исчисляется десятками миллионов). Некоторые метакаталоги, такие как Critical Path и iPlanet, содержат также средства, позволяющие создать аналог записей changelog для реляционных баз данных.

Метакаталоги также различаются количеством разных каталогов, с которыми они в состоянии взаимодействовать; соответствующие модули называют коннекторами. Если специальные коннекторы отсутствуют, обычно предусматривается доступ через отдельно написанные программы (обычно на Perl, JavaScript или VBScript); таким образом, любые данные, доступные соответствующей программе, становятся доступны метакаталогу.

Рис. 3. Метакаталоги без метапредставления

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

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

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

Смежные продукты

Список продуктов, тем или иным образом связанных с каталогами LDAP, весьма широк; многие производители многопользовательского программного обеспечения прислушиваются к желаниям потребителей, и встраивают в свои продукты возможность хранить пользовательские профили в общем каталоге LDAP, а популярность этих каталогов привела к широкому распространению простых клиентов LDAP (такой клиент, например, встроен в Microsoft Outlook и Outlook Express). Тем не менее можно выделить ряд продуктов, имеющих более непосредственное отношение к внедрению и администрированию каталогов.

• Виртуальные каталоги и прокси-серверы LDAP, такие как iPlanet Directory Access Router (iDAR) и MaXware Virtual Directory (MVD). Из этих продуктов более мощным набором функций обладает MVD: он принимает запрос клиента по LDAP (на чтение или на запись данных) и переводит его либо в другой запрос LDAP к собственно серверу, либо в запрос к реляционной базе данных, либо в запрос информации, реализованный в виде отдельной программы. Таким образом, MVD позволяет добиться функциональности каталога LDAP без установки сервера LDAP: данные могут храниться в реляционной базе данных, либо вообще в файле. MVD может также связываться с несколькими источниками данных с серверной стороны, позволяя распределять данные по нескольким каталогам, либо балансируя запросы клиентов при высокой загрузке, перенаправляя их к нескольким разным копиям данных. iDAR специализируется исключительно на балансировке запросов LDAP между несколькими копиями.
• Продукты для доступа к каталогам LDAP и администрирования данных, такие, как Calendra Directory Manager и Oblix Publisher. Большинство серверов LDAP поставляются вместе с доступным через браузер интерфейсом для конечного пользователя, но их функциональность часто весьма ограничена, равно как ограничены и возможности подстройки под ситуацию конкретной организации. Указанные продукты заполняют эту нишу, предоставляя мощные и гибкие средства для создания пользовательского интерфейса. Они имеют также встроенный контроль доступа для того, чтобы пользователи сами могли редактировать данные в каталоге (скажем, о себе или своих подчиненных).
• Продукты категории e-provisioning, такие, как Access360 enRole и Business Layers eProvision Day One. (e-provisioning - автоматизация обеспечения сотрудников, партнеров и клиентов необходимыми ресурсами, в первую очередь электронными). Названные продукты позволяют, например, создать для вновь пришедшего сотрудника учетные записи во всех требуемых многопользовательских программах, а также, например, послать электронную почту офис-менеджеру с тем, чтобы тот подготовил место работы нового сотрудника.

Рост спроса на такие продукты может служить признаком того, что рынок каталогов в целом развивается. Технология LDAP установилась в качестве стандарта для систем каталогов; в перспективе ее, возможно, может заменить DSML (Directory Services Markup Language) — вариант XML, разработанный специально для работы с каталогами.

Использование DSML будет естественным образом стимулироваться развитием Web-служб; на сегодняшний день данные технологии находятся в стадии становления, и большинство соответствующих приложений напрямую пользуются протоколом LDAP.