W tradycyjnie działającej firmie proces przyznawania uprawnień zakłada wnioskowanie przez działy biznesowe o przyznanie uprawnień dla danego użytkownika. Ich poziom jest zależny od jego funkcji w organizacji. Taki wniosek trafia do działu IT, który wdraża założenia w życie. Proces można podzielić na następujące etapy:

- określenie ról przez biznes

- zatwierdzenie zmian w rolach pracownika

- dostarczenie informacji do działu IT

- przełożenie informacji o rolach na elementarne uprawnienia w poszczególnych systemach

- przygotowanie uprawnień i zastosowanie ich w systemach oraz aplikacjach

- sporządzenie zapisów w dokumentacji

- przeprowadzenie kontroli poprawności nadanych uprawnień.

Procedura jest realizowana za każdym razem przy przyjmowaniu nowego pracownika, przy jego zwalnianiu lub zmianie stanowiska, skutkującej zmianą uprawnień do firmowych aplikacji i danych. Procedura jest kłopotliwa i przy każdym audycie przeglądane są zapisy w dotyczącej jej dokumentacji. Zatem każdy błąd przekłada się na potencjalne problemy, mogące w konsekwencji doprowadzić do utraty certyfikatów. Z takim problemem boryka się prawie każda firma świadcząca usługi IT, w której pracownicy mają uprawnienia systemowe do zarządzania rozwiązaniami klientów.

Zarządzanie tożsamością to automatyzacja

Przekazanie zarządzania wszystkimi kontami do specjalizowanego oprogramowania na pierwszy rzut oka wydaje się komplikować działanie IT w firmie, ale praktyka pokazuje, że efekty są korzystne. Po wdrożeniu systemu zarządzania tożsamością proces nadawania i odwoływania uprawnień wygląda następująco:

- pracownik biznesowy, na przykład właściciel procesu, określa role pracownika;

- role zostają zatwierdzone;

- oprogramowanie tłumaczy role biznesowe na elementarne uprawnienia;

- wprowadzenie uprawnień odbywa się automatycznie;

- oprogramowanie raportuje wykonanie zadania, wprowadzając odpowiednie zapisy do logu.

Podstawowa różnica miedzy metodą tradycyjną a programową polega na tym, że przełożenie uprawnień z ról biznesowych (pojęcia zrozumiałego dla właścicieli procesów lub menedżerów) na elementarne uprawnienia (zrozumiałe dla deweloperów i administratorów aplikacji) odbywa się automatycznie. Razem z rolami (w zarządzanych systemach, w organizacji), można zarządzać także dostępem do zasobów zarządzanych przez Active Directory. Pracownik otrzymuje dostęp do systemu service desk, folderów sieciowych z dokumentami, poczty elektronicznej oraz dodatkowe dostępy w miarę potrzeb. Ponieważ połączenie między rolami a uprawnieniami cząstkowymi jest utrzymywane przez system, odpowiedzialność za prawidłowe przydzielenie uprawnień spada głównie na biznes, a uprawnienia użytkownika odzwierciedlają wymagania biznesowe. Jest to szczególnie ważne w przypadku zarządzania systemami klienta w firmie usługowej. Pracownik będący administratorem lub deweloperem systemów klienta może mieć kilkanaście kont, ale bez wspomnianego systemu musiałby pamiętać nawet 100 różnych haseł.

Zwolnienie pracownika

W chwili rozwiązania umowy o pracę wszystkie konta, do których pracownik miał dostęp, powinny zostać zablokowane. W tradycyjnym modelu nie jest to proste, wymaga sporo pracy, a musi być wykonane niezawodnie, w krótkim czasie i z zachowaniem odpowiednich procedur. Przy centralnym zarządzaniu tożsamością wystarczy jej zawieszenie lub zablokowanie, co skutkuje natychmiastowym przerwaniem dostępu do zarządzanych systemów. Czas reakcji jest przy tym liczony w minutach.

Niektóre działania, na przykład zlecenie zawieszenia dostępu ze względu na prawdopodobną kradzież hasła, mogą być wykonane także przez innych pracowników, co umożliwia minimalizację ryzyka kradzieży informacji. Decyzję o docelowym zablokowaniu dostępu podejmuje właściciel procesu, czyli człowiek związany z biznesem, na przykład odpowiedni dyrektor.

Kto ma uprawnienia

Podstawowe pytanie, często zadawane przez specjalistów z działu bezpieczeństwa, a także przez biznes, dotyczy uprawnień poszczególnych użytkowników. W firmach o skomplikowanej strukturze gąszcz uprawnień jest na tyle trudny do zrozumienia, że nie można obyć się bez specjalizowanych narzędzi lub procedur realizowanych z żelazną konsekwencją. Część uprawnień może być przypisana do grup w systemie operacyjnym, inne przywileje deklarowane są na poziomie aplikacji, jeszcze inne obowiązują w bazach danych - ten łańcuch musi być połączony spójnym zestawem wzorców i ról biznesowych dla poszczególnych pracowników. Narzędzia zarządzania tożsamością mogą od razu udzielić odpowiedzi na pytania związane z uprawnieniami, przy czym w wielu rozwiązaniach możliwy jest także przegląd uprawnień wstecz. Jest to istotne przy audycie takim jak SAS 70, który sprawdza ostatni rok. Przy kontroli jakakolwiek niezgodność powoduje problemy z otrzymaniem pozytywnego wyniku.

Szybki audyt

Oprócz bieżącego utrzymania przywilejów niezbędne są audyty zarówno stanu uprawnień, jak i aktywności kont. Jeśli organizacja musi wykazać się zgodnością z SOX, bardzo dokładne audyty przeprowadzane są co miesiąc, a to wymaga dużej pracy przy ręcznej analizie zmian. Gdy organizacja dysponuje centralnym zarządzaniem tożsamością, audyt SOX jest mocno wspomagany przez dostarczone raporty. Narzędzia ułatwiają także analizę incydentów, gdyż każde wykorzystanie przywilejów jest rejestrowane. Przy odtwarzaniu informacji o zdarzeniu można pozyskać informację, kto i kiedy logował się do zarządzanych systemów, jakich przywilejów użył.

Konta utworzone poza centralnym zarządzaniem (popularnie zwane duchami) są automatycznie wykrywane przez system. Tego typu konta powstają, gdy aplikacja podczas instalacji tworzy sobie konto automatycznie. Administratorzy przejmują takie konto, przypisując je do specjalnych tożsamości technicznych, związanych właśnie z kontami wymaganymi przez aplikacje. Przejęcie konta podlega odnotowaniu i opisaniu jako działanie techniczne.

Polityka haseł

W firmie usługowej szczególnie ważna jest polityka haseł, gdy administratorzy muszą mieć uprawnienia systemowe do zarządzanych przez nich rozwiązań. Ponieważ każda firma może mieć inne założenia odnośnie do utrzymywania haseł, system zarządzający tożsamością potrafi ustanowić jedną spójną politykę, spełniającą wszystkie założenia (zostanie wybrane najostrzejsze kryterium). Dzięki temu administratorzy nie muszą pilnować zmian haseł w każdym z systemów, logując się w każdym z nich za pomocą swojego aktualnego, mocnego i dobrze strzeżonego hasła.