Paweł Goleń, blog

Po co wdrażać

O tym, po co wdrażać System Zarządzania Tożsamością napisano już wiele, więc może nie będę powtarzał utartych frazesów. Według mnie jednym z istotniejszych celów wdrożenia systemu, który często lepiej jest przemilczeć, jest uporządkowanie sytuacji odnośnie kont i uprawnień użytkowników w poszczególnych systemach informatycznych organizacji. Rozwój instytucji jest dynamiczny, IT (i nie tylko IT, czasem nawet sam biznes nie nadąża za sobą) nie zawsze za tym rozwojem nadąża. Często brak jest wizji odnośnie zintegrowanego, centralnego uwierzytelniania i przyznawania uprawnień w poszczególnych systemach, zamiast wizji jest zapatrzenie w kolejnych dostawców, którzy tworzą kolejne bazy użytkowników z kolejnymi hasłami. W efekcie okazuje się, że przeciętny pracownik posiada od kilku do kilkunastu kont w różnych systemach, o różnych nazwach, różnych hasłach... Z tymi różnymi hasłami to oczywiście kwestia umowna, w pewnej chwili taki użytkownik wszędzie ustawi hasło ala123, tak na wszelki wypadek, by nie zapomnieć. A i jego zmiany unikać będzie jak ognia. Przy pewnej skali organizacji zapanowanie nad tym wszystkim jest w praktyce nie możliwe. Jeśli do tego dodamy istniejącą w niektórych przypadkach konieczność dokumentowania ścieżki nadawania uprawnień, wkrótce utonąć można w olbrzymiej ilości „papieru” i wniosków czekających na akceptację lub realizację. Kompletną mrzonką w tej sytuacji staje się zasada minimalnych uprawnień, szczególnie w przypadku długoletnich pracowników „akumulujących” uprawnienia ze wszystkich swoich uprzednich stanowisk... Choć w teorii zmiana stanowiska powinna generować zmianę uprawnień, w praktyce tak nie jest. O odebranie uprawnień raczej nikt się nie upomina, a o przyznanie wręcz przeciwnie. Po prostu totalny chaos z tendencją do zwiększania poziomu nieuporządkowania w dodatku połączony z niewydolnością w działaniu. W pewnej chwili absolutnie niemożliwe staje się utrzymanie spójności opisów poszczególnych kont użytkownika (imię się nie zmienia, ale nazwisko już tak, zwłaszcza u kobiet, stanowiska się zmieniają, lub te same stanowiska i jednostki organizacyjne nazywane są w nowy, lepszy sposób, itp.). Nie ma nawet co myśleć o tak podstawowych „dobrych praktykach” jak blokowanie kont na okres urlopu czy natychmiastowe blokowanie ich w przypadku odejścia pracownika. To zadanie jest często niewykonalne choćby dlatego, że może okazać się, iż nawet sam użytkownik nie jest w stanie wymienić wszystkich swoich kont(!). Dopiero gdy w jakiś sposób uda się uzyskać połączenie między konkretnym człowiekiem pracującym w/dla danej instytucji a poszczególnymi kontami w różnych systemach, można myśleć o poprawie efektywności zarządzania. Ale sam system Zarządzania Tożsamością to nie wszystko. Trzeba wypracować i trzymać się pewnej wizji, w której jasno zostanie określone, że istnieje centralna baza użytkowników, z której wszystkie aplikacje powinny korzystać. Baza ta powinna zawierać nie tylko informacje o użytkowniku, ale również o jego uprawnieniach. Owszem, w poszczególnych aplikacjach może zaistnieć potrzeba dołączenia jakichś dodatkowych danych specyficznych, w sytuacji gdy jedna informacja może być wykorzystywana przez więcej aplikacji, należy pomyśleć o wyniesieniu jej „wyżej”. W rezultacie takiego podejścia uzyskuje się sytuację, w której liczba kont użytkownika jest zmniejszona z kilkunastu do kilku (w praktyce idea jednego konta jest ciężka do szybkiego osiągnięcia, zwłaszcza w przypadku instytucji z dłuższą historią), w której wszystkie „współdzielone” informacje są przechowywane centralnie (istotne zmniejszenie nadmiarowości danych). I co ważniejsze trzymając się tej koncepcji, mamy duże szanse, że mozolnie tworzony system będzie w stanie obsługiwać bez większych zmian nowe aplikacje, które nawet nie były mglistą wizją na etapie jego implementacji. Uporządkowanie... Pod tym hasłem można umieścić następujące zagadnienia:

• Opracowanie metody mapowania osoby na konta w systemach,
• Opracowanie i wdrożenie wizji centralnego uwierzytelnienia i autoryzacji użytkownika,
• Wyeliminowanie nadmiarowości danych,
• Implementacja synchronizacji danych (początkowo nawet prostej),
• Wdrożenie „cyklu życia” konta w oparciu o „cykl życia” pracownika,

Pod pojęciem „cyklu życia” na razie nie chciałbym ujmować zarządzania uprawnieniami danej osoby w poszczególnych systemach, lecz skupił się na kwestii bardziej trywialnej, obsłudze zdarzenia zatrudnienia, nieobecności oraz odejścia osoby z instytucji. W idealnym świecie pracownik przychodzący do firmy ma wszystko czego potrzebuje do pełnienia swoich nowych obowiązków. To „wszystko” to zarówno biurko, telefon, komputer, jak i potrzebne uprawnienia w systemach informatycznych. W praktyce często na wszystko powyższe trzeba czekać. Założenie konta (i przyznanie uprawnień) jest istotne dla biznesu, bo bez tego nowy pracownik nie może wykonywać swojej pracy, zamiast wypracowywać zysk, przynosi straty (nie pracuje, a pensja już się liczy). Tak więc tutaj największym motorem działania powinien być biznes właśnie. Inaczej w przypadku blokowania konta pracownika w trakcie jego nieobecności. Tutaj dla biznesu jest to mało istotne, a nawet jak się dziś dowiedziałem „nieżyciowe” (no chyba, że w jakiś sposób analiza ryzyka wykaże, że oczekiwane straty wynikające z nadużyć z użyciem nieblokowanego konta pracownika są niepomijalne dla biznesu), ale działka zajmująca się bezpieczeństwem na ten temat ma już inne zdanie. Jest to coś więcej niż tylko dobra praktyka. A i różnego rodzaju audyty lubują się w porównywaniu list aktywnych kont z listą aktywnych (czyli aktualnie pracujących, nie przebywających na urlopach, zwolnieniach lub zawieszeniach pracowników). Doszły mnie również słuchy, że Państwowa Inspekcja Pracy również zaczyna porównywać listy urlopowe z logami systemów informatycznych, co może się w niektórych przypadkach skończyć karą. Być może po kolejnej rekomendacji audytu lub jakiejś głośnej wizycie PIP w tym temacie zostaną podjęte działania. Rozwiązanie białkowe działa mniej więcej tak:

• Dział HR musi przekazać informację o nieobecności pracownika,
• Administratorzy systemów powinni zablokować konta (jeśli w jakiś magiczny sposób potrafią je powiązać ze wskazaną osobą),
• W dzień powrotu osoby, konta powinny zostać odblokowane,

Taki sposób rozwiązania problemu generuje dodatkowe obciążenie dla wszystkich jego uczestników, a dodatkowo najprawdopodobniej pracownik po powrocie z urlopu będzie miał wszystkie konta zablokowane i będzie musiał przejść żmudną procedurę informowania osób odpowiednich, że oto już wrócił z wypoczynku i bardzo chciałby na nowo zabrać się do pracy... Tutaj doskonale sprawdza się System Zarządzania Tożsamością, zwłaszcza jeśli jego źródłem danych jest system kadrowy. Sam to mogę obserwować w postaci telefonów i mailów nieco zirytowanych kierowników, którzy mają za złe fakt, iż wreszcie obowiązujące regulacje wdrożone są w życie. Po prostu wcześniej konta nie były blokowane i „osoba zastępująca” pracowała sobie wprost na koncie osoby zastępowanej. Miodzio... Aby jednak system mógł się w tym zakresie sprawdzić, musi wiedzieć jakie konta „należą” do Jana Kowalskiego, czyli znowu wracamy do etapu pierwszego – uporządkowanie. Gdy będzie uporządkowanie, pojawi się zysk w postaci wspierania przez taki system podstawowych procesów związanych z zarządzaniem użytkownikami i nadawaniem uprawnień w systemach IT.

Innym ciekawym argumentem powoływanym w celu uzasadnienia wdrożenia systemu jest fakt, że dzięki niemu administratorzy będą mogli zająć się administracją. To fakt, „klepanie wniosków” o nadanie dostępu jest zadaniem zajmującym, monotonnym i odmóżdżającym. Jeśli przejmie to, choć w jakiejś części, system, wówczas administratorzy rzeczywiście będą mogli zająć się poważniejszymi sprawami. Może się nawet okazać, że w miejsce kilku obecnych będzie można zatrudnić mniejszą ilość lepiej wykwalifikowanych osób, które nigdy by się nie zgodziły wcześniej na pracę, bo wspomniane klepanie wniosków po prostu ich nie interesuje. Ta interpretacja może jednak nie jest najszczęśliwsza, bo wówczas zamiast mieć wsparcie z IT, będzie się miało w tym dziale wroga.

W bankach na prezentacjach systemów realizujących funkcje Zarządzania Tożsamością przywoływany jest budzący zgrozę BASEL2. Jest to argument mocno naciągany, ponieważ sam BASEL2 w żaden sposób nie wymaga wdrożenia systemu Zarządzania Tożsamością. Z drugiej jednak strony system taki może się przyczynić do znaczącej redukcji ryzyka operacyjnego, a co za tym idzie do redukcji odkładanych rezerw, co z kolei jest już czystym zyskiem dla banku. Jest to oczywiście uproszczenie, ale warto o tym mechanizmie pamiętać.

Dla kogo?

Dużym błędem jest postrzeganie systemu Zarządzania Tożsamością jako narzędzia stworzonego dla IT lub działki bezpieczeństwa IT. Należy pamiętać, że rolą firmy (bo instytucja to również choćby instytucja rządowa, a tam to już nie zawsze) jest przede wszystkim zarabianie pieniędzy. Rolą banku jest również to samo – zarabianie pieniędzy, a nie, na przykład, posiadanie najbezpieczniejszego ze wszystkich systemu bankowości elektronicznej. Oczywiście bezpieczeństwo jest ważne, ale stosowane podejście opiera się raczej na analizie ryzyka i podejmowaniu uzasadnionych ekonomicznie decyzji o akceptacji ryzyka, jego redukcji lub przeniesieniu na ubezpieczyciela. Jeśli popatrzeć na funkcjonowanie takiego tworu w sposób procesowy (niestety, jestem nieco skażony „kulturą korporacyjną”), wówczas wyraźnie widzi się, iż zarówno rolą IT, jak i działki związanej z bezpieczeństwem (choć tutaj akurat może mniej, ale z drugiej strony teraz bezpieczeństwo zwykle przesuwa się w stronę analizy ryzyka) jest świadczenie usług. Usługą taką jest założenie konta, jego zablokowanie w przypadku, gdy taka konieczność zachodzi, konfiguracja uprawnień, utrzymywanie spójności i aktualności danych. To wszystko są usługi. Te usługi nie są na nic potrzebne IT, ich konsumentem jest biznes. Wdrażany system wspiera (a przynajmniej powinien) wspierać te procesy, tak więc ostatecznym beneficjentem jest biznes właśnie, bo to on będzie otrzymywał usługi szybciej, sprawniej, a, nieuniknione, wykorzystanie systemów IT w działalności firmy będzie generowało mniejsze ryzyko operacyjne. Czy biznes powinien być informowany od początku o implementacji takiego systemu? Szczerze powiem – nie wiem. Wydaje mi się, że wdrożenie systemu można podzielić na dwie fazy, fazę wdrożenia technicznego oraz fazę, nazwijmy to, implementacji biznesowej. W fazie wdrożenie technicznego udział biznesu nie jest kluczowy, aczkolwiek powinno w niej brać co najmniej IT, bezpieczeństwo oraz HR. Być może w organizacji udało by się wytypować kilka bardziej „światłych” osób i zaprosić ich do prac nad projektem systemu, ich punkt patrzenia może być istotny dla całości projektu. Wyjście na tym etapie z pytaniem „co byście chcieli” spowoduje według mnie stworzenie projektu trudnego do zaimplementowania potworka, niewątpliwe bogatego w interesujące funkcje, ale przy tym tak złożonego i bogatego w logikę rozmytą (tak, w prawdziwą logikę rozmytą), że cały projekt może zakończyć się klęską. Nie oznacza to, że projekt nie może się zakończyć wdrożeniem systemu, lecz po wyższych kosztach, w większym niż zakładano czasie i prawdopodobnie w niepełnym zakresie. Jeśli za zakończony sukcesem projekt uznamy ten zakończony w terminie i pełnym zakresie projekt, który zmieścił się w zakładanym budżecie, to mamy klęskę na całej linii...

Określenie zakresu

Określenie zakresu projektu jest bardzo istotnym elementem. Tym bardziej, że system Zarządzania Tożsamością może naprawdę bardzo dużo. Poza opisanymi przeze mnie zadaniami wspomagającymi, może na przykład konfigurować kontrolę dostępu (fizycznego do budynku), generować nowe numery telefonów i składać zapotrzebowania na sprzęt. W zależności od stanowiska system może zamówić telefon stacjonarny, komórkowy, komputer biurkowy, laptopa, samochód służbowy, wczasy na Hawajach... Prezentacje produktów podsycają ten optymizm, później przychodzi mniej optymistyczny etap, czyli przedstawienie ceny... Moim zdaniem system taki należy implementować małymi kroczkami. Kroki należy dobrać tak, by stanowiły one funkcjonalną całość, która w kolejnym kroku może być rozszerzona. Tutaj nie należy dać się oszukać doświadczeniu firmy wybranej do wdrożenia/implementacji systemu. Prawda jest taka, że jest to firma, która przychodzi wdrażać znany sobie system w nieznanym środowisku. Z kolei zamawiający, który swoje środowisko zna, najczęściej nie ma większego pojęcia o zamawianym systemie. Informacje z prezentacji marketingowych (nawet jeśli nazywają się one techniczne) najlepiej od razu zapomnieć. Jeśli system jest wdrażany małymi krokami, wówczas obie strony mają szanse „nauczyć się siebie”. Jeśli tej wzajemnej znajomości nie będzie, otwiera się prosta droga do przedłużenia projektu, rozczarowania efektem, a może i kar umownych, bądź też zerwania umowy... A jaki powinien być zakres na początku? Myślę, że na początek integracja kilku podstawowych systemów, synchronizacja danych opisowych, być może obsługa zdarzeń zatrudnienia, zwolnienia i nieobecności pracowników. Prawie cały system? Prawie... ale prawie naprawdę robi różnicę.

Jaki system wybrać

Na dobrą sprawę można wyróżnić co najmniej dwa typy rozwiązań. Wielkie kombajny, które mają wszystko, oraz rozwiązania, które mają podstawowe funkcje i funkcje specyficzne dla danego wdrożenia należy dopiero zaimplementować. Uważam, że lepszym rozwiązaniem może okazać się wybór systemu mniej „totalnego”. Dlaczego? Ponieważ wielkie kombajny mają to do siebie, że są one implementacją wizji ich producenta. Wizji, która wcale nie musi być zgodna z wizją istniejącą w miejscu, gdzie system jest implementowany. Owszem, umożliwiają one w pewnym zakresie dostosowanie się do wymagań (szczególnie pięknie wygląda to na prezentacjach przed podpisaniem umowy), jednak w trakcie wdrożenia okazuje się, że to tak nie do końca jest z tą elastycznością systemu i pojawiają się skojarzenia z „any color that you like, as long as it is black”. Drugą grupą, którą wyodrębniłem na swoje własne potrzeby, są te systemy, które tak właściwie są silnikiem synchronizacji danych. Cała reszta musi zostać dopiero dobudowana. Według mnie mogą one lepiej wpasować się w charakter organizacji. Poważnym problemem może być jednak przekonanie sponsora projektu, że ten system będzie lepszy. Systemem typu „kombajn” łatwiej jest zrobić proof-of-concept, w takim przypadku zwykle nie uwzględnia się wszystkich zawiłości implementowanych procesów. Wszelkie problemy pojawiają sie dopiero w trakcie projektu, wówczas pojawia się dylemat, czy lepiej jest zmienić organizację, gdzie system jest wdrażany, czy zmodyfikować system. To ostatnie może okazać się niemożliwe, bo potrzeby marnej, 15 000 firmy są mało istotne w porównaniu z ilością firm, które „wzięły system taki, jaki jest”.