Zarządzanie tożsamością to nie tylko technologia, ale także sztuka organizacji i planowania.

Rosnące firmy z reguły mocno rozbudowują również infrastrukturę teleinformatyczną. Wiąże się z tym wzrost liczby punktów, w których odbywa się uwierzytelnianie, a w efekcie zapotrzebowanie na systemy do zarządzania tożsamością, które umożliwiają kontrolę i zabezpieczanie dostępu do zasobów IT. Ale wbrew pozorom, nie zawsze wdrożenie zarządzania tożsamością powoduje automatyczne poprawienie bezpieczeństwa w firmie.

Od haseł do centralnego uwierzytelniania

Małe firmy mają dość proste potrzeby w dziedzinie zarządzania tożsamością. Najczęściej wystarcza im podstawowy system wykorzystujący nazwę użytkownika i hasło. Jeśli jednak liczba aplikacji, systemów i zasobów wymagających uwierzytelnienia rośnie, to wzrasta również liczba haseł. W praktyce, gdy liczba haseł przekroczy cztery, a jednocześnie administrator zadba, aby były to hasła względnie bezpieczne, a więc odpowiednio długie i złożone, to niemal każdy użytkownik zapisze je na kartce, w notesie lub pliku. Oprócz tego - jeśli możliwości techniczne na to pozwalają - to większość ludzi prawdopodobnie ustawi takie samo hasło do wszystkich zasobów, aby ułatwić sobie życie. Choć trudno się temu dziwić, to oczywiście bezpieczeństwo systemu jako całości bardzo na tym cierpi.

Zastosowanie centralnego uwierzytelnienia teoretycznie załatwia problem, gdyż użytkownik stosuje te same zasady do wszystkich zasobów, do których ma mieć dostęp. W praktyce bywa jednak różnie, bo scentralizowane systemy wymagają bardzo ostrożnego wdrażania i szczególnie dobrego zaplanowania. Wiadomo bowiem, że nie wszystkie zasoby są równorzędne pod względem ważności i wymaganego poziomu zabezpieczeń.

Gdy procesy teleinformatyczne są obsługiwane przez wiele systemów o różnej konstrukcji, powstaje gmatwanina mechanizmów uwierzytelnienia. Może tak być, że w jednym systemie logowanie odbywa się na podstawie stałego hasła, zaś login nie jest w ogóle wymagany, drugi pobiera uprawnienia ze stacji roboczej, trzeci wymaga okresowo zmienianego hasła i innego loginu, zaś czwarty jest uwierzytelniany tokenem. Naturalną odpowiedzią na taki problem jest oferta producentów proponujących systemy jednokrotnego logowania (single sign-on). Na pozór wszystko jest w porządku - uwierzytelnianie jest zarządzane centralnie i można użyć silnej dwustopniowej autoryzacji, wykorzystującej np. token. Choć ułatwia to życie użytkownikom, w miarę wzrostu liczby systemów podłączonych do centralnego serwera uwierzytelniającego zarządzanie staje się coraz trudniejsze.

Należy bowiem pamiętać, że zarządzanie tożsamością to pojęcie znacznie szersze niż tylko sprawdzenie poprawności hasła. Wymaga ono także właściwych procedur użytkowania systemu, określania dostępu do obiektów, możliwości nadawania i odwoływania uprawnień lokalnych i globalnych, a oprócz tego, co jest szczególnie ważne, sprawnego audytu.

Błędy, których należy unikać

Zastosowanie centralnego zarządzania tożsamością może wywołać poważne zmniejszenie poziomu bezpieczeństwa w przedsiębiorstwie, jeśli zostaną popełnione kardynalne, a wcale nierzadkie, błędy w projekcie i wdrożeniu. Przykładem jest logowanie do wszystkich zasobów przy użyciu tej samej prostej technologii (np. tej samej pary login-hasło), gdy jedna z tych usług wysyła dane przez sieć bez szyfrowania. Odczytanie hasła przesyłanego czystym tekstem jest bardzo proste. W takim przypadku, spotykanym od czasu do czasu w polskich firmach, zdobycie przez osobę nieuprawnioną hasła, np. do firmowego intranetu, daje automatycznie dostęp do wszystkich zasobów, do których użytkownik ma uprawnienia, czasem nawet z możliwością zdalnego dostępu włącznie. To samo dotyczy ustalonych zależności między autentykacją, takich jak automatyczne logowanie do innych zasobów po udanym zalogowaniu do jednego z nich. Dlatego też należy przygotować spójny schemat autentykacji do wszystkich modułów systemu.

Aby dobrze wdrożyć system zarządzania tożsamością, wszystkie systemy teleinformatyczne obecne w przedsiębiorstwie muszą być gotowe do tego zadania. To jest warunek konieczny, choć nie wystarczający. Klucz do sukcesu w takim zaprojektowaniu składników systemu to, by były one zgodne ze wspólnym, wybranym standardem. Celowo pomijam tu opisy i przykłady technologii, bo liczy się tylko pełna zgodność mechanizmów autentykacji we wszystkich modułach infrastruktury. Systemy, które mają konstrukcję zintegrowaną, z zasady lepiej nadają się do efektywnego wdrożenia zarządzania tożsamością niż zlepek różnych technologii.

Kupowanie oprogramowania i sprzętu przeznaczonego do autentykacji bez uprzedniego odpowiedniego przygotowania infrastruktury to często wyrzucone pieniądze, gdyż koszty późniejszego dostosowywania istniejących rozwiązań do nowej technologii mogą się okazać wyższe niż cena wdrożenia systemu zintegrowanego. Typowym przykładem są częste problemy z agentami uwierzytelniania dla tej czy innej platformy.

Są też sytuacje, gdy opłaca się pozostawienie najmniej znaczących elementów sieci poza systemem centralnego zarządzania tożsamością użytkowników. Szczególnie dotyczy to składników pełniących rolę informacyjną, których ważność jest niska, zaś wymagania wobec bezpieczeństwa jeszcze niższe. Jest to wyłom w zasadach, jednak należy świadomie oceniać nie tylko zyski, ale także ryzyko. Niedopracowany system (np. z nieszyfrowanym połączeniem) może być poważniejszym zagrożeniem przy podłączeniu go do systemu zarządzania tożsamością niż pozostawiony tak jak jest - z osobnym hasłem.

Gdy wszystkie systemy spełniają pewien wspólny standard, można opracować procedury związane z uprawnieniami. To bardzo ważny krok, bowiem pominięcie go i wdrożenie na zasadzie "jakoś to będzie" wywołuje potem konflikt interesów. Przykładowo zwalanie na barki działu informatyki zarządzania poziomami dostępu dla poszczególnych użytkowników programu handlowego jest bez sensu. Według mnie uprawnienia decyzyjne dotyczące detali dostępu pracowników w obrębie aplikacji powinny być delegowane poza dział informatyki - do osoby odpowiedzialnej za pracę programu w dziale firmy.

Dobrze zaprojektowany system zarządzania tożsamością powinien dawać możliwość nadawania i odwoływania uprawnień pracowników nie tylko przez administratora, ale również innych kierowników, którzy nie posiadają uprawnień do zarządzania systemem IT. Dzięki temu dział IT nie będzie musiał wykonywać czynności związanych ze szczegółowym ustawianiem poziomów dostępu, a lepiej niż pracownicy IT zrobi to np. ktoś wyszkolony w zakresie zapobiegania atakom socjotechnicznym.

Nie ma bezpieczeństwa bez audytu

Bardzo ważnym, a najczęściej niedocenianym, składnikiem systemu zarządzania tożsamością jest audyt. Typowe pytania, na które musi odpowiedzieć osoba analizująca zapisy audytu, to:

• kto się logował,
• skąd (stacja robocza, adres IP, lokalizacja),
• do których zasobów,
• jak długo działał,
• co tam robił,
• jakie dane mogły być wykorzystane,
• jakie zostały zmienione,
• które przywileje zostały użyte, które nie,
• co jeszcze mógł wykonać w tych warunkach.

Bez odpowiednich narzędzi centralizujących zarówno autentykację, jak i audyt, trudno dać odpowiedź na powyższe pytania. Odsetek krajowych przedsiębiorstw posiadających dobrze zaprojektowany mechanizm audytu jest żałośnie niski. To jeden z bardzo poważnych błędów w założeniach systemów bezpieczeństwa w polskich firmach. Nawet jeśli używa się usług katalogowych, takich jak Active Directory lub eDirectory i wbudowanych w nie narzędzi, mało kto poprawnie konfiguruje funkcje audytu.

Często np. dane z logów są zapisywane, ale nie ma wdrożonych narzędzi do ich zaawansowanej analizy. Lwia część istniejących systemów nie potrafi wykorzystać danych z różnych modułów do analizy zależności między nimi. Przykładem może być analiza wpisów z zapory sieciowej skorelowana z danymi z serwera tokenów. Jeśli ktoś najpierw zalogował się do stacji roboczej i użył do tego celu tokena, a potem zapora zarejestrowała ruch wychodzący do Internetu, oznacza to, że użytkownik po zalogowaniu uruchomił przeglądarkę internetową. Ale gdy najpierw zarejestrowano ruch wychodzący ze stacji roboczej użytkownika, a potem odbyła się autentykacja - jest to zachowanie nietypowe i powinno generować alarm. Centralne zarządzanie tożsamością daje takie możliwości i należy z nich korzystać. Bez nich najważniejsze informacje o poczynaniach użytkownika często są nieuchwytne.

Jeśli mechanizmy audytu zostaną wdrożone i ktoś systematycznie przegląda logi, należy pamiętać, że osoba ta musi się znajdować "poza wszelkimi podejrzeniami", bo ma możliwości modyfikacji zapisów logu oraz ingerencji w system. Jej kontrola jest szczególnie trudna do realizacji w większości dzisiejszych systemów, bowiem z reguły administratorzy "mogą wszystko". Modelowym rozwiązaniem jest to, które wybrał Novell w systemie Netware (od wersji 4.x), gdzie możliwy jest audyt działań wszystkich użytkowników systemu, włącznie z administratorem, przez osobę pozbawioną uprawnień do administracji, czyli audytora. Systemy typu Unix (także Linux) dają możliwość odkładania logów na drugą maszynę, warto o tym pamiętać.

W Polsce nie obowiązują takie regulacje prawne jak Sarbanes-Oxley Act w USA, który nakłada na firmy m.in. obowiązek audytu poczynań użytkowników. Być może jest to przyczyną bardzo rzadkich wdrożeń systemów zarządzania tożsamością w naszym kraju i stosunkowo niewielkich doświadczeń w tej dziedzinie.

Tożsamość kulą u nogi

Są przypadki, gdy centralizowany system zarządzania tożsamością zaczyna być przeszkodą w normalnej eksploatacji infrastruktury teleinformatycznej. Jednym z nich jest wdrożenie takiego systemu w firmie wielooddziałowej połączonej z centralą za pomocą zawodnych łączy. W polskich warunkach o to nietrudno. Jeśli łącze między oddziałem firmy i centralą zawodzi, zaczynają się problemy z autoryzacją użytkowników. Przy restrykcyjnych ustawieniach (a tylko takie znacząco podwyższają bezpieczeństwo), nawet cała zdalna lokalizacja może zostać sparaliżowana w przypadku awarii łącza.

Niektóre systemy pozwalają na zastosowanie wówczas autoryzacji offline, która jest lekarstwem na takie wypadki, ale warto pamiętać, że może to doprowadzić do poważnego naruszenia bezpieczeństwa systemu. Autoryzacja offline umożliwia atak przy użyciu kradzionego tokena - wystarczy rozłączyć sieć, uruchomić komputer i zalogować się. W trybie offline system nie może sprawdzić faktu zablokowania tokena, bo nie może uzyskać żadnych informacji na ten temat od serwera uwierzytelniającego.

Wyjściem jest zastosowanie zarządzania tożsamością tylko w centrali firmy, gdzie jest niezawodne połączenie sieciowe do serwera uwierzytelnienia. Ponadto w lokalizacji tej następuje kumulacja wszelkich danych i dlatego centralizacja przynosi najwięcej korzyści.

System zabezpieczeń powinien być dobrze wyważonym kompromisem między maksymalnie najwyższym bezpieczeństwem a wygodą użytkowników. Z tego powodu warto poświęcić czas na staranną analizę i zaplanowanie wdrożenia.