Średnie i duże firmy, które przymierzają się obecnie do wdrożenia jednolitych systemów katalogowych, stają przed problemem większym niż im się wydaje.

Gdy systemów informatycznych jest w firmie kilka, zarządzanie uprawnieniami użytkowników nie wymaga wiele wysiłku. Gdy jednak z biegiem czasu aplikacji przybywa, a każda z nich identyfikuje użytkowników na swój sposób, ustalenie rzeczywistych uprawnień osoby zaczyna sprawiać trudności. Kiedy jeszcze firma zaczyna współdzielić swoje systemy z partnerami handlowymi i/lub dostawcami, kłopoty z zarządzaniem mogą łatwo przekształcić się w zagrożenie dla bezpieczeństwa. Tęskniąc za przejrzystością, firmy decydują się zwykle na wdrożenie kompleksowego systemu zarządzania uprawnieniami, obejmującego wszystkie systemy i aplikacje. Decyzja przychodzi łatwo, jednak samo wdrożenie - już nie koniecznie.

Krew, pot i łzy

Budowa jednolitego systemu katalogowego wymaga, by wszystkie aplikacje porozumiewały się z katalogiem w sposób standardowy. Z punktu widzenia architekta rozwiązania byłoby idealnie, gdyby każda aplikacja zawierała wydzielony fragment (bibliotekę, komponent) skupiający w sobie wszystkie funkcje kontrolujące dostęp do zasobów. Można by wtedy zmodyfikować jedynie drobny fragment aplikacji, nie zmieniając reszty.

To byłoby jednak zbyt piękne. Szybko rozwijająca się firma średniej wielkości może posiadać kilkanaście, lub nawet kilkadziesiąt aplikacji, a dostawca każdej z nich może mieć własną filozofię zarządzania danymi o użytkownikach. Koncentracja funkcji uwierzytelniania w jednym miejscu dotyczyć będzie części aplikacji, ale z pewnością nie wszystkich.

W praktyce nie można liczyć także na to, że dane o użytkownikach będą składowane w domyślnym miejscu lub w standardowej formie czy dostępne za pośrednictwem standardowego wywołania. Owszem, dostawcy obsługujący dużych klientów wbudowują w swoje systemy interfejsy do popularnych systemów katalogowych zgodnych w całości ze standardem X.500 lub choćby w warstwie komunikacyjnej (LDAP). Część producentów integruje swoje produkty z systemami katalogowymi dostarczanymi wraz z systemami operacyjnymi i serwerami baz danych.

Nie jest to jednak powszechne.

Duża część dostawców oprogramowania, jak również zdecydowana większość programistów zatrudnionych wewnątrz firm starała się rozwijać aplikacje jak najmniejszym kosztem. Ścisła kontrola uprawnień długo nie była traktowana priorytetowo - ważniejsze było dostarczanie funkcjonalności biznesowej i utrzymanie zgodności z przepisami. W efekcie wiele aplikacji przechowuje dane o użytkownikach w dedykowanej tabeli bazy danych lub w plikach tekstowych w miejscach znanych głównie ich autorom.

W większości środowisk można odnaleźć wszystkie wyżej opisane pomysły. To właśnie dlatego ujednolicenie zarządzania uprawnieniami za pomocą systemu katalogowego tylko z pozoru wydaje się proste. Przedstawione na schematach dwa potencjalne podejścia do konsolidacji informacji o użytkownikach nie będą wykluczać się, lecz raczej uzupełniać w ramach jednego środowiska.

Katalog w rozkroku

Opisane wyżej kwestie, o dziwo, nie wyczerpują listy potencjalnych problemów, jakie stoją przed projektantem systemu katalogowego.

Dodatkowe trudności pojawiają się, gdy w grę wchodzi rozproszenie geograficzne aplikacji i użytkowników. W takiej sytuacji całkowicie scentralizowany system jest możliwy do realizacji, jednak pod pewnymi warunkami.

Pełna centralizacja zarządzania uprawnieniami, jakkolwiek pożądana z punktu widzenia bezpieczeństwa, grozi paraliżem firmy lub jej części w przypadku awarii sieci WAN. W rozważaniach nie można jednak abstrahować od przyjętego w firmie sposobu dostępu do aplikacji. Jeśli zdalni pracownicy korzystają wyłącznie z rozwiązań terminalowych, brak łączności z centralą uniemożliwia im pracę tak, czy owak. Decyzja dotyczy więc raczej tego, czy w razie niedostępności centralnego systemu zarządzania uprawnieniami użytkownicy w oddziałach mają prawo dostępu do lokalnych aplikacji, czy też nie.

Sposobem zachowania kontroli nad uprawnieniami - pomimo rozproszenia - może być wdrożenie mechanizmów partycjonowania katalogu i synchronizacji replik. Rozwiązania tego rodzaju sprawdziły się w Novell eDirectory. Microsoft, jak można wnioskować z zapowiedzi aktualizacji Active Directory w Windows Server 2003 R2 spodziewanej w pierwszej połowie 2005 r., idzie w tym samym kierunku (technologia ADAM).

Niebagatelnym problemem pozostaje pytanie: czy mechanizm synchronizacji powinien być częścią systemu katalogowego, czy też może być od niego niezależny? W tym pierwszym przypadku system katalogowy będzie mieć jednolitą strukturę logiczną, choć fizycznie rozproszoną w wielu lokalizacjach. Taka konstrukcja jest zazwyczaj tania oraz łatwa do wdrożenia - większość mechanizmów jest gotowa i wymaga jedynie konfiguracji. Wadą takiego podejścia jest natomiast konieczność śledzenia procesów synchronizacji i wychwytywania problemów, np. gdy występują kłopoty z dostępnością łącz.

Architektura z niezależnym od katalogu mechanizmem synchronizującym jego zawartość wymaga tak naprawdę wdrożenia wielu odrębnych systemów katalogowych - przynajmniej na poziomie oddziałów regionalnych. Takie podejście jest z gruntu kosztowniejsze niż poprzednie - nie tylko ze względu na koszt licencji systemu katalogowego, ale także z powodu konieczności wdrożenia systemu replikacyjnego, np. zgodnego z DirXML, który trzeba zakupić oddzielnie. Wiele niezależnych drzew katalogowych uniezależnia działanie systemu katalogowego od dostępności łącz WAN. Jednocześnie, w razie awarii występuje znacznie mniej problemów z ponowną synchronizacją, w której wykorzystuje się zazwyczaj prostą metodę znakowania wpisów czasem (najświeższy wpis pozostaje).

Oddzielną kwestię stanowi także wydajność łącz WAN w kontekście częstotliwości odwoływania się aplikacji oddziałowych do systemu weryfikacji uprawnień działającego w centrali. Efekty rozważań o centralizacji lub rozproszeniu będą więc zapewne inne w przypadku banku, inne zaś w przypadku sieci detalicznych.

Dane szczególnej troski

Zagadnieniem zaskakująco niedocenianym we wdrożeniach systemów katalogowych jest zabezpieczanie ich przed utratą danych. Awaria systemu katalogowego ma wpływ na dostępność dużej części infrastruktury aplikacyjnej. Czas dostępności ma tu znaczenie, ale ponieważ awarii wykluczyć nie można, w praktyce bardziej liczy się minimalizacja czasu odtwarzania. Rozsądne jest więc posłużenie się systemem backupowym z opcją disaster recovery, który oprócz danych umieści na nośniku system operacyjny wraz z parametrami środowiska, co umożliwi jego szybkie odtworzenie.

Do zabezpieczenia katalogu konieczne są dedykowane agenty backupowe, które są w stanie wykonać spójną kopię bazy wpisów. Kopie plikowe nie dają gwarancji poprawności odtworzenia wszystkich wpisów.