Podstawową rolą systemów Identity Management jest udzielenie odpowiedzi na wiele pytań związanych z tożsamością. Kto ma dostęp, do jakich zasobów i dlaczego? Jakie są polityki dostępowe? Kiedy po raz ostatni X miał dostęp do określonego zasobu? Co działo się po uzyskaniu dostępu? Kto zezwolił na dostęp? System zarządzania tożsamością działa więc jako pośrednik pomiędzy użytkownikiem, administratorem a aplikacją czy usługą.

Nasza firma rośnie, zatrudnia nowych pracowników. Jednym słowem, wielka radość! Ale czy dla wszystkich? Biedny administrator na wieść o przyjęciu nowych pracowników dostaje wysypki. Ma pod sobą kilkadziesiąt różnych systemów, a do co najmniej kilkunastu "nowi" będą musieli mieć dostęp. Również i pracownicy dostaną białej gorączki, kiedy pozmieniają sobie hasła w kilku systemach, a przy tym każde z nich będzie inne. Frustracje nie opuszczają też CSO - ludzie przychodzą i odchodzą, ale czy można być w 100% pewnym, że oprócz drzwi wyjściowych za odchodzącym pracownikiem zamknie się dostęp do wszystkich systemów? Na te i kilka innych rozterek odpowiadają rozwiązania zarządzania tożsamością - Identity Management.

IdM/IAM/IMS?

Mówiąc o Identity Management (IdM), musimy zrozumieć, co kryje się za tym terminem. Według firmy Burton Group, jest to zespół procesów biznesowych wraz z wspierającą je infrastrukturą służący do tworzenia, utrzymywania oraz użytkowania elektronicznych tożsamości. Rozwiązania, których przeznaczeniem jest zarządzanie tożsamością, określa się mianem IMS (Identity Management Systems). Istnieje także rozróżnienie na IdM (tylko tożsamość) oraz IAM (Identity and Access Management). Te drugie, oprócz zarządzania tożsamością elektroniczną, łączą funkcje kontroli dostępu do zasobów dla takich tożsamości. Obecnie jednak - patrząc na funkcjonalność oferowanych na rynku rozwiązań - zarówno systemy IdM, jak i IAM nie odbiegają od siebie znacząco i trudno znaleźć producenta, który oferowałby tylko mechanizmy zarządzania tożsamością, bez przynajmniej elementów kontroli dostępu.

Ciężki kawałek chleba

IdM jest specyficznym obszarem związanym tylko częściowo z bezpieczeństwem, i błędem jest traktowanie tylko w takim kontekście. Jest to przy tym niezwykle roz-legły obszar i zazębia się z innymi zagadnieniami. Dlatego też sku-pimy się na sprawach podstawowych.

IdM od momentu zauważenia potrzeby centralizacji zarządzania tożsamością przeszedł prawdziwą ewolucję. Początkowo rozwiązania były typowo punktowe - tj. koncentrowały się na poszczególnych systemach. Dominowały wówczas mainframe'y. Była to więc niezwykle monolityczna i zdecentralizowana struktura. Potem nastąpił okres rozkwitu internetu i portali webowych, co spowodowało przeobrażenie rozwiązań w produkty specjalizowane i dążące do centralizacji zarządzania uprawnieniami. Pojawiły się mechanizmy SSO (Single Sign-On), które zaczęły być integrowane czy też konsolidowane z systemami WAM (Web Access Management). W słowniku IT zaistniał także niezwykle modny obecnie termin - provisioning.

IdM jest to zatem swoista hybryda, łącząca nie tylko mechanizmy kontroli, audytu czy raportowania, ale także - a może przede wszystkim - automatyzująca procesy biznesowe i usprawniająca obieg informacji związanych z szeroko rozumianą tożsamością. Jej zadaniem jest również uniknięcie chaosu i powiązanie rozproszonych danych (atrybutów) z osobami. Dlatego też projekty IdM angażują całą organizację i nie odnoszą się tylko i wyłącznie do IT. Strona technologiczna całego przedsięwzięcia jest ważna, ale nie wiodąca. Stąd też wdrażanie systemów tego rodzaju jest zadaniem trudnym i wielowarstwowym (o tym szerzej pod koniec artykułu), a problemów do rozwiązania wiele. Przede wszystkim konieczność ogarnięcia i być może przeprojektowania procesów. Do tego dochodzi wielość źródeł informacji o tożsamości, np. systemy mainframe, RDBMS (Relational Database Management Systems), usługi katalogowe, systemy ERP, książki adresowe itp.

Oprócz tego borykamy się z wielością użytkowników i przypisanych im ról. Musimy uwzględnić pracowników (z podziałem na pełnione przez nich funkcje), gości, kontraktorów, partnerów biznesowych itp. Wreszcie trzeba połączyć to wszystko w spójnym systemie zarządzania oraz zmusić do współpracy aplikacje czy usługi, które zostaną tym procesem "dotknięte" (logistyka, aplikacje finansowe, CRM, HR, systemy operacyjne itp.). A to jeszcze nie koniec. Należy zadbać o to, żeby łatwo dało się wyciągnąć przejrzyste informacje, które

dostarczą odpowiedzi na pytania, o których już wspominaliśmy - chociażby po to, żeby spełnić wymagania mnożących się regulacji i zasad polityki oraz "zadowolić" audytorów. Uff!

Puzzle do poskładania

System IdM musi zatem umożliwiać jednoznaczną identyfikację osób oraz "wiązać" je z rolami oraz usługami za pomocą określonych procesów. A jeżeli mowa o identyfikacji, to także o uwierzytelnianiu - ale to jest sprawą w miarę prostą. Tutaj możemy stosować różnorodne mechanizmy - karty PKI, tokeny OTP, standardowe hasła, biometrykę itp. Gorzej jest z autoryzacją. Ta ma udzielić odpowiedzi na pytanie, czy użytkownik ma prawo otrzymać dostęp do określonego zasobu. W grę wchodzą także dodatkowe elementy, takie jak: rola, którą użytkownik pełni (tzw. role-based access control), posiadane przez niego określone atrybuty, przynależność do grupy, pora dnia itp. Z kolei administrowanie użytkownikami budowane jest na podstawie zarządzania kontami, hasłami do nich, przypisywania do grup i ról, provisioningu - to wszystko skupione w centralnym repozytorium, do którego mogą odwoływać się różne usługi. Ostatnia wersja ITIL (Information Technology Infrastructure Library) - v3 uwzględnia IAM jako kluczowy element pozwalający poprawić "sprawność" biznesową firmy.

Ogólnie rzecz biorąc, możemy wszystkie elementy IdM zgrupować wokół kilku grup funkcjonalnych: zarządzania tożsamością, infrastruktury tożsamości, zarządzania dostępem oraz raportowania i audytu.

Zarządzanie tożsamością

Pod parasolem zarządzania tożsamością możemy umieścić takie komponenty, jak: provisioning użytkowników, zarządzanie rolami, zarządzanie kontami uprzywilejowanymi. Provisioning to mechanizmy, które pomagają w sposób zautomatyzowany, na podstawie informacji uzyskanych z centralnego repozytorium/katalogu, utworzyć, zmodyfikować lub usunąć konta powiązane z określoną tożsamością. "Akcja" musi zostać przeprowadzona globalnie tak, aby zmiany były skuteczne wobec wszystkich objętych nią aplikacji/usług/systemów.

Większość systemów provisioningu skupiała się w przeszłości na tym, żeby szybko odciąć użytkownika od danych, w momencie kiedy opuszczał firmę. Dzisiaj provisioning to znacznie więcej. Musi umożliwiać taki sprzęg z usługami, że możliwe będzie wydobycie z nich informacji o tym, kto ma dostęp do każdej z nich oraz działać na rozbudowanym katalogu atrybutów, przypisując je aplikacjom. Moduł provisioningu musi dawać także możliwość budowania agentów dla różnych systemów czy aplikacji - nie może być komponentem zamkniętym. Z tego powodu jednym z najczęściej wykorzystywanych protokołów w modułach provisioningu jest SPML (Services Provisioning Markup Language), bazujący na XML (co zapewnia odpowiednią elastyczność).

Provisioning wiąże się ściśle z tzw. workflow, czyli określoną z góry ścieżką akceptacyjną, która musi być przebyta, żeby możliwe było stworzenie, zmodyfikowanie lub usunięcie tożsamości oraz przydzielenie jej dostępu do zasobu. Workflow określa, w jakim przypadku, kto, komu i do czego może przypisać uprawnienia. Zbudowanie czytelnej, a jednocześnie pełnej ścieżki akceptacyjnej jest jednym z najtrudniejszych zadań (podobnie jak prawidłowe zdefiniowanie ról). Wymaga określenia m.in. właścicieli danych, opiekunów danych (np. administratorów) i nadzorców (np. przełożonych, menedżerów).

Wyzwaniem jest następnie spełnienie wymogu rozdziału obowiązków (Separation of Duties - SoD) tak, aby wnioskujący nie mógł jednocześnie sam zaakceptować swojej prośby. Dochodzi też zdefiniowanie zasad powiadamiania w ramach workflow i to niekoniecznie osób bezpośrednio zaangażowanych w proces decyzyjny. Workflow opisywany jest najczęściej również przy wykorzystaniu języków z serii XML (np. Sun używa języka Express), co daje bardzo duże możliwości modyfikacji.

Obecnie sporo uwagi poświęca się zarządzaniu uprawnieniami wg ról oraz tzw. User Access Recertification, czyli wymuszaniu na użytkownikach poświadczenia (aktualizacji) swoich uprawnień np. za pomocą intuicyjnego interfejsu webowego.