КАК CОЗДАТЬ ЕДИНЫЙ КАТАЛОГ

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

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

Пока ясно одно: на любом предприятии будет существовать несколько каталогов. Такие компании, как International Data Corporation (IDC) и Gartner Group, пришли к выводу, что в большинстве крупных организаций свыше 100 хранилищ данных будут использоваться как каталоги для аутентификации пользователей и предоставления прав доступа к определенным ресурсам. За счет уменьшения числа хранимых элементов данных затраты можно существенно сократить, именно поэтому концепция метакаталогов становится как никогда актуальной.

Ключевое слово в этом утверждении - концепция. Метакаталог - это не продукт. Это идея или подход к объединению несвязанных хранилищ данных и представлению их в виде единого источника данных, на основе которого можно было бы пользоваться и управлять ресурсами сети, учитывая индивидуальные особенности пользователя. Данный термин, впервые введенный специалистами компании Burton Group, стал находкой для специалистов по маркетингу. Теперь в рекламе о каждой службе каталогов говорится, что она не просто является одним из метакаталогов, а единственным заслуживающим этого названия - Метакаталогом с большой буквы.

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

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

КАТАЛОГИ, КОТОРЫЕ МЫ ЗНАЕМ И ЛЮБИМ

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

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

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

Административный каталог сетевой операционной системы (NOS) выполняет аутентификацию и определение прав пользователей при доступе к ресурсам локальной сети, как правило, к дисководам, принтерам и специфическим для производителя приложениям для конкретной сетевой ОС. Хотя эти каталоги предлагаются как корпоративные каталоги общего назначения, каждый производитель имеет продукт, относящейся к категории метакаталогов (у Microsoft это Microsoft Metadirectory Services (MMS), а у Novell - Dirxml), в целях обеспечения отсутствующей у основных продуктов совместимости.

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

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

ВЕШАЛКИ ДЛЯ РАЗНЫХ ШЛЯП

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

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

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

СПИСОК ВОПРОСОВ О КАТАЛОГАХ

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

Доступ. Каким образом приложения, пользователи, сетевые устройства и службы будут обращаться к каталогу с запросами на сохранение и получение информации? Если процедуры доступа к каталогу плохо продуманы, то служба каталогов будет ненадежной и бесполезной, вне зависимости от того, насколько элегантной окажется ее техническая структура. Процедуры доступа также связаны с вопросами выбора протоколов для передачи запросов к каталогу. Команды LDAP через HTTP занимают одно из первых мест в списке стандартных методов организации доступа. Кроме того, некоторые компании используют собственные API, такие, как Active Directory Service Interface (ADSI) вместе с Active Directory или другие специализированные API при проектировании пользовательских приложений, ориентированных на работу с каталогами. Протоколы доступа необходимо методично оценить с учетом эталонной архитектуры.

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

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

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

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

RadiantOne компании Radiant Logic может служить примером виртуального каталога, использующего LDAP, Extensible Markup Language (XML) и SQL для объединения разрозненных хранилищ данных и обеспечения доступа к ним через Information Resource Locator (IRL). Особенность данного решения в том, что в каталоге размещается только IRL, поэтому нет необходимости решать вопросы синхронизации. Такой подход позволяет администраторам создавать несколько разных представлений одновременно, не меняя базовую физическую структуру. Структура пространства имен каталогов - это минное поле, где следует двигаться с осторожностью.

Физическая структура. Где разместить машины с хранилищами данных каталога? Как осуществлять тиражирование и синхронизацию информации между хранилищами данных? Что произойдет, если в канале глобальной сети или на сервере возникнет сбой? При проектировании каталогов часто забывают о необходимости тщательной оценки возможностей существующей физической сети. Нужно оценить, как повлияют различные модели тиражирования на уже имеющуюся и планируемую инфраструктуру. Такие вопросы, как готовность и тиражирование, непосредственно связаны с эффективностью сети; крайне важное значение имеет тщательный анализ различных архитектур и структуры трафика. Производители служб каталогов, как правило, не обладают достаточной для проведения такого анализа квалификацией и обычно предполагают, что сеть имеет 100-процентную готовность и неограниченную пропускную способность. Самое лучшее при оценке производительности приложения - определить, каким образом различные структуры каталогов и, как следствие, виды трафика повлияют на вашу сеть.

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

Интеграция. Каким образом можно объединить несколько каталогов в единое целое? Там, где это возможно, следует согласовать архитектурные компоненты со стандартами. Одна из основных причин растущей популярности служб каталогов - появление более зрелых стандартов, связанных с этими службами. Самыми важными являются стандарты X.500, LDAP, Common Information Model (CIM), XML и ODBC.

X.500 И LDAP

LDAP - это движущая сила большинства современных проектов интеграции каталогов. LDAP - производная от Directory Access Protocol (DAP), протокола клиентского доступа, описанного в стандарте на каталоги X.500. Упрощенная версия была разработана из-за слишком больших накладных расходов, связанных с DAP; она позволила предоставить доступ к каталогам в стандарте X.500 большему диапазону клиентов. Сейчас IETF и Desktop Management Task Force (DMTF) совместно работают над воспроизведением в стандартах LDAP функциональности, описанной в X.500, с меньшими затратами и большей гибкостью.

Например, X.500 описывает тиражирование между хранилищами данных по протоколу Directory System Protocol (DSP). В мире LDAP пока не существует сравнимого с DSP стандарта. Это серьезный изъян, который сейчас производители компенсируют с помощью собственных нестандартных средств в своих продуктах или тех или иных расширений LDAP. Сейчас ведется работа по добавлению функций тиражирования к LDAP. Суть состоит в том, чтобы, следуя продуманной методологии, разработать пилотную программу, которая гарантировала бы, что все механизмы тиражирования, связанные с конкретной средой, функционировали должным образом, объединяя набор инструментальных средств для поддержки и управления процессом. Ведущие производители служб каталогов поддерживают LDAP и как протокол доступа, и как интеграционный протокол, при этом для передачи между ними информации один каталог рассматривается в качестве "клиента" другого.

CIM, DEN И WBEM

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

Одной из реализаций стандарта CIM является спецификация Directory Enabled Network (DEN). Эта спецификация определяет строительные блоки для реализации интеллектуального управления физической сетью путем указания соответствия пользователей и сетевых служб, а также соответствия бизнес-критериев предоставляемым сетевым службам. Это позволяет приложениям и службам от имени пользователя прозрачно использовать ресурсы сетевой инфраструктуры на базе правил; предоставлять услуги из конца в конец; поддерживать распределенное создание, предоставление и управление сетевыми службами.

Спецификация DEN создается на основе спецификации DMTF CIM. К моменту публикации данной статьи должна быть выпущена предварительная общедоступная версия CIM 2.5. Эта версия определяет стандартную схему DEN, охватывающую следующие восемь разделов: Core, Physical, Network, System, Device, Core Policy, QoS Policy и IPSec.

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

Еще одна реализация CIM - это стандарт Web-Based Enterprise Management (WBEM) - набор стандартов на базе Internet, который унифицирует управление разнородными приложениями, в том числе службами каталогов. DEN также обеспечивает определенный уровень совместимости с решениями WBEM. Взаимодействие DEN и WBEM возможно, поскольку данные стандарты созданы на единой основе масштабируемых и расширяемых спецификаций CIM.

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

НЕ ЗАБУДЬТЕ XML, DSML И UDDI

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

Однако при использовании XML возникает одна серьезная проблема, связанная с его гибкостью: типы и структуры данных часто настолько специализированы, что общая интеграция просто невозможна. Это подтверждает наличие более 160 стандартных определений XML, созданных в разных отраслях и предметных областях и ориентированных на их специфические нужды. Что касается каталогов, то такого рода задачи в данной области решаются в рамках проекта по созданию языка разметки для служб каталогов (Directory Services Markup Language, DSML). Инициатора этого проекта компанию Bowstreet поддерживают большинство ведущих разработчиков служб каталогов. Bowstreet предлагает программное обеспечение автоматизации Web, где XML рассматривается как основное решение для интеграции узлов электронной коммерции. На первом этапе предполагалось, что XML послужит основой для работы с DSML.

DSML предусматривает стандартизацию общих объектов каталогов таким образом, чтобы продукты различных производителей представляли информацию в одинаковом формате. Дополняющий его "рекомендованный стандарт" Standard Object Access Protocol (SOAP), впервые предложенный IBM и Microsoft, создает оболочку, которая в случае необходимости может быть зашифрована, для передачи текстов XML по каналам связи. (В действительности SOAP является некоторым наброском, с которого только начинается процесс создания рекомендуемого стандарта.)

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

Arriba, Microsoft и IBM - основные сторонники другого стандарта - спецификации универсального описания, обнаружения и интеграции (Universal Description, Discovery and Integration, UDDI). Она создает независящую от платформы среду, используя которую, предприятия могут оповещать о своих услугах и находить друг друга. Эта среда создается на основе XML, HTTP и SOAP. UDDI будет опираться на регистр уникальных идентификаторов, хранящихся в каталоге, используемом для создания "Белых страниц" предприятий, "Желтых страниц" категорий предприятий и "Зеленых страниц", которые охватывают технические аспекты служб, предлагаемых отдельными бизнес-системами. Эта новая инициатива вызвала интерес у ряда ведущих компаний, работающих на рынке служб каталогов и электронной коммерции.

Может показаться, что ODBC никак не связано со службой каталогов, но многие хранилища данных представляют собой РСУБД, и это необходимо учитывать при определении стратегии создания служб каталогов. Большинство современных хранилищ данных РСУБД не поддерживают LDAP и пока не готовы к использованию XML. Однако к ним можно получать доступ через ODBC, и соответствующая информация, например подтверждение прав доступа, может быть передана в имеющийся в компании каталог общего назначения.

ИСКУССТВО ВИДЕТЬ ПЕРСПЕКТИВУ

Предложения по стандартам появляются постоянно. Novell предложила новый глобальный домен верхнего уровня - .dir, который указывал бы на то, что узел с таким адресом - это общедоступный каталог компании. Не отстают от Novell и другие организации, в том числе Oasis, The Open Group и RosettaNet, которые работают над созданием общей модели для обеспечения взаимодействия информационных систем. Положительным моментом является факт сотрудничества между этими разработчиками ПО в попытках дальнейшего развития технологии службы каталогов, причем на взаимоприемлемых принципах. Это может служить хорошим предзнаменованием для тех, кто в качестве основы для своей экономической стратегии выбирает электронную коммерцию.

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

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

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

Ресурсы Internet

Oasis - некоммерческий международный консорциум, работающий над созданием спецификаций, обеспечивающих совместимость на основе открытых стандартов. Узел Web консорциума расположен по адресу: www.oasis-open.org.

The Open Group проверяет соответствия стандартам, публикуя результаты тестирования и сертификации, касающиеся совместимости продуктов различных производителей. Эти данные можно найти по адресу: www.opengroup.org/directory/.

RosettaNet (http://www.rosettanet.org) - это некоммерческий консорциум компаний, работающих над созданием единого языка электронного бизнеса.

Цель рабочей группы DSML состоит в том, чтобы утвердить DSML как открытый стандарт, тогда разработчики и производители смогут со временем использовать его в своих системах. Более подробную информацию можно найти по адресу: www.dsml.org.

The Desktop Management Task Force (http://www.dmtf.org) - отраслевая организация, которая разрабатывает, адаптирует и объединяет стандарты и инициативы, связанные с управлением настольными и корпоративными системами и средами Internet.