| Обединение на идентичността чрез Oracle Virtual Directory |
| Четвъртък, 07 Февруари 2008 00:00 |
|
Информацията за самоличността на потребителите на информационни системи в големите организации винаги се намира в различни хранилища. Няма голяма организация, която да няма повече от една директорийна услуга. Всъщност в преобладаващите случаи организацията смесва директорийни услуги, които работят върху платформи на различни доставчици. Обичайна гледка е например използването на Microsoft Active Directory за целите на Microsoft Exchange и същевременно ползване на IBM Directory Server за целите на автентикацията в IBM AIX. Нещо повече – една компания рядко се ограничава единствено до директорийни услуги, когато съхранява информация за различните потребители на информационните й системи. В много случаи потребителските акаунти се съхраняват в таблици в база данни. Проблемите, които се пораждат от липсата на централизирано хранилище на информацията за потребителите, са в няколко аспекта. Първо, от гледна точка на регулаторната съвместимост с редица стандарти и директиви е задължително да можем да определим с точност потребителите в организацията и съответните им права. При наличие на множество хранилища с информация за тях това е труден процес. Второ, в много от случаите един и същи потребител присъства в различни директории или бази данни, но тази негова идентичност не е синхронизирана. Ако един потребител има профил в Microsoft Active Directory и Sun Java System Directory Server, но в двата профила адресът му е различен, на коя от двете системи да вярваме? Трето, ако организацията въвежда в експлоатация нова система, до която трябва да даде достъп на потребители, „разхвърляни“ в две различни директории, как може да подходи тя? В този случай трябва или двете директории да се слеят в една (на практика тежък и неприложим във всички случаи процес), или да се въведе нова директория, в която да се копират данните на потребителите, които ще използват новата система. Последният подход всъщност още повече задълбочава проблемите, тъй като въвежда допълнително хранилище на потребителска информация и увеличава дублираните данни. Един не лош вариант за решаване на проблема с многото директории и хранилища на информация за потребителите е използването на централна директорийна услуга (или метадиректория), която да синхронизира останалите. Oracle предоставя такова решение, което се състои от два основни компонента – Oracle Internet Directory и Oracle Directory Integration Platform.  Oracle Internet Directory е пълноправна директорийна услуга, която може да съдържа информация и атрибути на потребителите. Различните приложения могат да се свързват към нея посредством протокола LDAP. От друга страна Oracle Directory Integration Platform може да бъде свързана както с Internet Directory, така и с директорийните услуги на други доставчици (Microsoft, IBM, Sun, Novell и други). Тази система може двупосочно да синхронизира данните между Internet Directory и другите хранилища на потребителски данни. По този начин тя централизира информацията за потребителите в единна директория, към която могат да се насочат различните приложения, или от която могат да се изваждат отчети за потребителите и атрибутите от техните профили. Разглеждайки такъв тип архитектура, трябва внимателно да помислим за две особености. Първо, централизацията чрез синхронизация не отразява пълната картина наистина в реално време, тъй като обикновено самата синхронизация се извършва веднъж на определен период от време. Второ, има дублиране на цялата информация от останалите директории, което не винаги е изгодно от гледна точка на нужния ресурс за поддръжка. Въпреки споменатите недостатъци използването на метадиректория е един сравнително приемлив компромис, който помага за централизацията на потребителските идентичности и отчетността към тях. Именно за премахване на споменатите ограничения около архитектурите с метадиректория наскоро Oracle представи едно ново решение в областта, което се нарича Oracle Virtual Directory (OVD). Предназначението на продукта отново е централизация на потребителските идентичности, но при него има една основна разлика, а именно – тук няма процес на преместване на данни от другите директории. Всичко се случва в реално време. За да разберем как работи Oracle Virtual Directory нека кажем няколко думи за нейната архитектурата. Условно можем да я разделим на пет логически слоя. Най-ниско стоят адаптерите. Чрез тях Virtual Directory се свързва с хранилищата на информация за потребителите. Чрез LDAP адаптер може да се осъществи връзка с популярните директорийни услуги (Active Directory, eDirectory, Directory Server и други). Тъй като в някои случаи потребителски профили стоят и в таблици, разположени в бази данни (най-често при собствените приложения на организацията), Virtual Directory включва и адаптер за бази данни, който може да извлича потребителите от популярните системи за управление на бази данни. Съществува, разбира се, и набор от библиотеки за разработването на собствени адаптери.  На следващото ниво в архитектурата стоят филтрите, чрез които можем динамично да ограничаваме данните, достъпни през адаптерите. Чрез този механизъм можем да вземем само част от дървото на директорийната услуга, която достъпваме през адаптера. На следващото ниво – plugins, можем да извършваме трансформация на данните в реално време. Например, ако една от директориите, които достъпваме през адаптер, е Microsoft Active Directory и тя съдържа два атрибута – givenName за име и SN за фамилия, чрез трансформация можем да направим нов виртуален атрибут employeeName, който да съдържа в себе си името и фамилията, разделени с интервал. Разбира се, възможни са много по-сложни трансформации, включващи логически избор според стойностите на атрибутите. На ниво „Сигурност“ работят различни защитни механизми, най-важният от които е механизмът, поддържащ списъците за контрол на достъпа (ACL). Чрез него можем да зададем политики на достъп, указващи кои потребители имат достъп до данните. Можем да зададем права за четене, търсене, промяна и други. Ако потребителите имат право да променят атрибутите във виртуалната директория, то тя прозрачно ще направи нужните промени чрез адаптерите си в съответните директорийни услуги. Последното ниво в архитектурата са услугите, през които може да се достъпва Virtual Directory от клиенти – потребители или приложения. Използвайки LDAP Listener, виртуалната директория може да се маскира като обикновена LDAP v3 директорийна услуга. Тя може да предостави достъп до данните в себе си и през уеб услуги, използвайки HTTP Listener. В допълнение, Virtual Directory поддържа и стандарта Directory Service Markup Language чрез специалния DSML Listener.  Virtual Directory има много приложения. Тя може да се използва за обединяване на всички източници на потребителски идентичности и да предостави стандартизиран достъп към тази информация. Това изключително улеснява внедряването на нови приложения, както и създаването на отчети в съответствие с различни регулаторни изисквания. Virtual Directory може да служи и за преводач, в случаите когато организацията има една директорийна услуга, но различни приложения очакват такава от друг производител. Тогава виртуалната директория може да играе ролята на преводач и динамично да преобразува атрибутите от съществуващата директория в такива, които приложенията очакват. В допълнение, Oracle Virtual Directory е продукт, който е изключително лесен за внедряване и определено заслужава да му обърнем внимание. (C) 2007 Николай Манчев сп. "Information Security Bulgaria" брой 5, декември 2007 |
Коментари