Budujemy model ról zarządzania dostępem. Część pierwsza, przygotowawcza

Obecnie pracuję w firmie dostarczającej oprogramowanie, a dokładniej w zakresie rozwiązań do zarządzania dostępem. Moje doświadczenie z "przeszłego życia" wiąże się natomiast z rolą klienta – dużą instytucją finansową. Wówczas nasza grupa zajmująca się kontrolą dostępu w dziale zabezpieczeń informacji nie mogła pochwalić się dużymi kompetencjami w dziedzinie IdM. Uczyliśmy się wiele w trakcie, musieliśmy popełnić wiele błędów, aby zbudować w firmie działający mechanizm zarządzania uprawnieniami użytkowników w systemach informacyjnych.

Łączenie mojego doświadczenia zdobytego po stronie klienta z wiedzą i kompetencjami dostawcy, chcę podzielić się z wami swoistą instrukcją krok po kroku: jak w dużej firmie stworzyć model ról zarządzania dostępem i jakie to przyniesie korzyści. Moja instrukcja składa się z dwóch części: pierwsza – przygotowania do stworzenia modelu, druga – samo budowanie. Oto część pierwsza, przygotowawcza.

N.B. Budowanie modelu ról to, niestety, nie rezultat, a proces. A dokładniej, jest to część procesu tworzenia w firmie ekosystemu zarządzania dostępem. Dlatego nastaw się na długotrwałą grę.

Na początku zdefiniujmy – czym właściwie jest zarządzanie dostępem oparte na rolach? Załóżmy, że masz dużą bank z dziesiątkami, a nawet setkami tysięcy pracowników (podmiotów), z których każdy ma dziesiątki uprawnień do setek wewnętrznych systemów informacyjnych (obiektów). A teraz pomnóż liczbę obiektów przez liczbę podmiotów – dokładnie tyle relacji minimum musisz najpierw zbudować, a potem kontrolować. Czy da się to zrobić ręcznie? Oczywiście, że nie – w tym celu powstały role.

Rola to zestaw uprawnień, które są potrzebne użytkownikowi lub grupie użytkowników do wykonywania określonych zadań zawodowych. Każdy pracownik może posiadać jedną lub więcej ról, a każda rola może zawierać od jednego do wielu uprawnień, które są dozwolone użytkownikowi w ramach tej roli. Role mogą być przypisane do określonych stanowisk, działów lub funkcjonalnych zadań pracowników.

Role są zazwyczaj tworzone na podstawie indywidualnych uprawnień pracownika w każdym systemie informacyjnym. Następnie z ról każdego systemu formułowane są globalne role biznesowe. Na przykład rola biznesowa „menedżer kredytowy” obejmie kilka indywidualnych ról w systemach informacyjnych wykorzystywanych w biurze klienta banku. Powiedzmy, w takich jak główny zautomatyzowany system bankowy, moduł kasowy, system elektronicznego obiegu dokumentów, menedżer usług oraz inne. Role biznesowe zazwyczaj są powiązane z organizacyjną strukturą firmy – krótko mówiąc, z zestawem jednostek organizacyjnych firmy oraz stanowiskami w nich. W ten sposób formułowana jest globalna macierz ról (przykład podaję w tabeli poniżej).

Warto zauważyć, że zbudowanie modelu ról w 100%, zapewniając wszystkie niezbędne prawa pracownikom na każdym stanowisku w strukturze komercyjnej, jest po prostu niemożliwe. Nie ma też takiej potrzeby. Gdyż model ról nie może być statyczny, ponieważ zależy od ciągle zmieniającego się otoczenia. I od zmiany działalności biznesowej firmy, co odpowiednio ma wpływ na zmianę struktury organizacyjnej i funkcji. I od braku pełnego zabezpieczenia zasobami, i od nieprzestrzegania przepisów służbowych, i od dążenia do zysku kosztem bezpieczeństwa, i od wielu innych czynników. Dlatego należy budować model ról, który będzie w stanie zaspokoić do 80% potrzeb użytkowników w zakresie niezbędnych podstawowych praw przy przyjmowaniu na stanowisko. A pozostałe 20% będą mogli, jeśli zajdzie taka potrzeba, zgłaszać później w osobnych wnioskach.

Oczywiście możesz zapytać: „Czy w ogóle istnieją 100% modele ról?” Cóż, zdarzają się takie sytuacje, na przykład w strukturach non-profit, które nie podlegają częstym zmianom – w jakimś instytucie badawczym. Lub w organizacjach sektora obronnego o wysokim poziomie zabezpieczeń, gdzie bezpieczeństwo jest priorytetem. Zdarza się też w strukturach komercyjnych, ale w ramach pojedynczej jednostki, której działalność jest na tyle statyczna i przewidywalna.

Główną zaletą zarządzania rolami jest uproszczenie przyznawania uprawnień, ponieważ liczba ról jest znacznie mniejsza niż liczba użytkowników systemu informacyjnego. A to odnosi się do każdej branży.

We take a retail company: it employs thousands of sellers, but they all have the same rights in system N, and only one role will be created for them. When a new seller joins the company, they are automatically assigned the appropriate role in the system, which already has all the necessary permissions. Similarly, with one click, rights can be changed for thousands of sellers at once, for example, adding a new option for generating reports. There is no need to perform a thousand operations, linking the new right to each account – it’s enough to include this option in the role, and it will appear for all sellers simultaneously.

Another advantage of role management is the exclusion of incompatible permissions. That is, an employee with a specific role in the system cannot simultaneously have another role whose permissions should not coincide with those in the first. A clear example is the prohibition of combining functions of entering and controlling a financial operation.

Everyone interested in how role-based access management came into being can
dive into a history overview
If we look back at history, it was in the 1970s that the IT community first began to think about methods of access management. Although applications were quite simple at that time, just like now, everyone wanted to manage access to them conveniently. Granting, changing, and controlling user rights – simply to better understand what access each of them has. However, at that time, there were no common standards; the first access management systems were being developed, and each company based its systems on its own ideas and rules.

Now, many different access management models are known, but they did not emerge all at once. Let’s focus on those that made a significant contribution to the development of this field.

The first and probably the simplest model is Discretionary (selective) access control (DAC – Kontrola dostępu w oparciu o uprawnienia). Model ten zakłada wspólne korzystanie z uprawnień przez wszystkich uczestników procesu dostępu. Każdy użytkownik otrzymuje dostęp do konkretnych obiektów lub operacji. W istocie, liczba podmiotów uprawnień odpowiada liczbie obiektów. Model ten został uznany za zbyt elastyczny i zbyt skomplikowany do utrzymania: listy dostępu z czasem stają się ogromne i trudne do kontrolowania.

Drugim modelem jest Zarządzanie dostępem oparte na zezwoleniach (MAC — Mandatory access control). W tym modelu każdy użytkownik uzyskuje dostęp do obiektu zgodnie z określonym zezwoleniem na dany poziom poufności danych. Odpowiednio, obiekty muszą być klasyfikowane według poziomu poufności. W przeciwieństwie do pierwszego elastycznego modelu, ten okazał się zbyt rygorystyczny i ograniczający. Jego zastosowanie nie jest uzasadnione, gdy w firmie jest wiele różnorodnych zasobów informacyjnych: aby rozdzielić dostęp do różnych zasobów, będzie trzeba wprowadzić wiele kategorii, które nie będą się krzyżować.

W związku z oczywistymi niedoskonałościami tych dwóch metod, środowisko IT kontynuowało opracowywanie modeli, które byłyby bardziej elastyczne i mniej więcej uniwersalne do wsparcia różnych typów organizacyjnych polityk kontroli dostępu. I w ten sposób pojawił się trzeci model zarządzania dostępem oparty na rolach! Podejście to okazało się najbardziej obiecujące, ponieważ wymaga nie tylko autoryzacji tożsamości użytkownika, ale i jego funkcji w systemach.

Pierwszą jasno opisaną strukturę modelu ról zaproponowali amerykańscy naukowcy David Ferraiolo i Richard Kuhn z Narodowego Instytutu Standardów i Technologii USA w 1992 roku. Wtedy po raz pierwszy pojawił się termin RBAC (Kontrola dostępu oparta na rolach). Badania te oraz opisy podstawowych komponentów, jak również ich wzajemnych powiązań, stanowiły podstawę obowiązującego do dziś standardu INCITS 359-2012, zatwierdzonego przez Międzynarodowy Komitet ds. Standardów Technologii Informacyjnych (INCITS).

Standard określa rolę jako „funkcję służbową w kontekście organizacji, z pewną związaną semantyką w odniesieniu do pełnomocnictw i odpowiedzialności, nałożonych na użytkownika, któremu przydzielono rolę”. Dokument ustala podstawowe elementy RBAC – użytkowników, sesje, role, uprawnienia, operacje i obiekty, a także relacje i powiązania między nimi.

W standardzie przedstawiono minimalnie konieczną strukturę do budowy modelu ról – łączenie praw w rolach, a następnie przydzielanie dostępu użytkownikom za pośrednictwem tych ról. Określono mechanizmy składania ról z obiektów i operacji, opisano hierarchię ról i dziedziczenie pełnomocnictw. W każdej firmie występują role, które łączą podstawowe uprawnienia, które są niezbędne dla wszystkich pracowników firmy. Może to obejmować dostęp do poczty elektronicznej, systemu zarządzania treścią, portalu korporacyjnego itp. Te uprawnienia można połączyć w jedną wspólną rolę o nazwie „pracownik”, co eliminuje konieczność wymieniania wszystkich podstawowych praw w każdej z ról wyższego poziomu. Wystarczy wskazać atrybut dziedziczenia roli „pracownik”.

Później standard został uzupełniony o nowe atrybuty dostępu, związane z dynamicznie zmieniającym się środowiskiem. Dodano możliwość wprowadzenia ograniczeń statycznych i dynamicznych. Statyczne wiążą się z niemożliwością łączenia ról (to właśnie ten wprowadzenie i kontrola operacji, o którym wspomniano wcześniej). Ograniczenia dynamiczne mogą być określane przez zmieniające się parametry, na przykład czas (godziny robocze/nierobocze), lokalizację (biuro/dom) itp.

Osobno warto wspomnieć o zarządzaniu dostępem opartym na atrybutach (ABAC — kontrola dostępu oparta na atrybutach). Podejście to polega na udzielaniu dostępu za pomocą reguł współdzielenia atrybutów. Model ten może być używany samodzielnie, ale dość często aktywnie uzupełnia klasyczny model ról: do danej roli można dodawać atrybuty użytkowników, zasobów i urządzeń, a także czasu lub lokalizacji. Pozwala to na stosowanie mniejszej liczby ról, wprowadzenie dodatkowych ograniczeń i zapewnienie minimalnego, wystarczającego dostępu, a tym samym zwiększenie bezpieczeństwa.

Na przykład księgowy może mieć dostęp do kont, jeśli pracuje w określonym regionie. Wtedy lokalizacja specjalisty będzie porównywana z określoną wartością referencyjną. Można też przyznać dostęp do kont tylko wtedy, gdy użytkownik loguje się z urządzenia, które znajduje się na liście dozwolonych. To dobre uzupełnienie modelu ról, ale rzadko stosowane samodzielnie z powodu potrzeby tworzenia wielu zasad i tabel uprawnień lub ograniczeń.

Podam przykład zastosowania ABAC z mojej 'poprzedniej pracy'. W naszym banku było kilka oddziałów. Pracownicy biur obsługi klienta w tych oddziałach wykonywali absolutnie takie same operacje, ale musieli pracować w głównym systemie tylko z kontami swojego regionu. Na początku zaczęliśmy tworzyć osobne role dla każdego regionu – takich ról z powtarzającą się funkcjonalnością, ale z dostępem do różnych kont było bardzo dużo! Wtedy, wykorzystując atrybut lokalizacji użytkownika i łącząc go z konkretnym zakresem kont do weryfikacji, znacznie zmniejszyliśmy liczbę ról w systemie. W rezultacie pozostały role tylko dla jednego oddziału, które były powielone na odpowiednie stanowiska we wszystkich pozostałych terytorialnych jednostkach banku.

A teraz porozmawiajmy o niezbędnych krokach przygotowawczych, bez których nie można zbudować działającego modelu ról.

Krok 1. Tworzymy model funkcjonalny

Warto zacząć od stworzenia modelu funkcjonalnego - dokumentu na wysokim poziomie, w którym szczegółowo opisano funkcjonalność każdego działu i każdej pozycji. Zazwyczaj informacje do niego trafiają z różnych dokumentów: instrukcji stanowiskowych oraz regulaminów dotyczących poszczególnych działów - wydziałów, zarządów, departamentów. Model funkcjonalny powinien być uzgodniony ze wszystkimi zainteresowanymi działami (biznes, kontrola wewnętrzna, bezpieczeństwo) i zatwierdzony przez kierownictwo firmy. Do czego potrzebny jest ten dokument? Aby model ról mógł się do niego odwoływać. Na przykład, zamierzacie zbudować model ról na podstawie już istniejących uprawnień pracowników - wyeksportowanych z systemu i „ujednoliconych”. Wówczas przy uzgadnianiu otrzymanych ról z właścicielem biznesowym systemu można powołać się na konkretny punkt modelu funkcjonalnego, na podstawie którego do roli włączane jest dane prawo.

Krok 2. Audytujemy systemy IT i opracowujemy plan priorytetyzacji

Na drugim etapie należy przeprowadzić audyt systemów IT, aby zrozumieć, jak zorganizowany jest w nich dostęp. Na przykład, w mojej firmie finansowej eksploatowano kilka setek systemów informacyjnych. We wszystkich systemach były pewne zalążki zarządzania rolami, w większości - jakieś role, ale głównie na papierze lub w katalogu systemu - były one dawno przestarzałe, a dostęp do nich przyznawano na podstawie faktycznych wniosków użytkowników. Naturalnie, zbudowanie modelu ról od razu w kilku setkach systemów jest po prostu niemożliwe, trzeba od czegoś zacząć. Przeprowadziliśmy szczegółową analizę procesu zarządzania dostępem, aby określić poziom jego dojrzałości. W trakcie analizy opracowaliśmy kryteria priorytetyzacji systemów informacyjnych - krytyczność, gotowość, plany wycofania z eksploatacji itp. Z ich pomocą ustaliliśmy kolejność opracowywania/aktualizacji modeli ról dla tych systemów. A następnie włączyliśmy modele ról do planu integracji z rozwiązaniem zarządzania tożsamością, aby zautomatyzować zarządzanie dostępem.

Jak więc określić krytyczność systemu? Odpowiedz sobie na następujące pytania:

• Czy system jest związany z procesami operacyjnymi, od których zależy podstawowa działalność firmy?
• Czy awaria systemu wpłynie na integralność aktywów firmy?
• Jak długo system może być offline, zanim niemożliwe staje się przywrócenie działalności po przerwaniu?
• Czy naruszenie integralności informacji w systemie może prowadzić do nieodwracalnych konsekwencji, zarówno finansowych, jak i reputacyjnych?
• Krytyczność w zakresie oszustw. Obecność funkcji, przy niewystarczającej kontroli, która może umożliwić dokonanie oszustw wewnętrznych/zewnętrznych;
• Jakie są wymagania prawne oraz wewnętrzne zasady i procedury dotyczące tych systemów? Czy będą nałożone kary ze strony regulatorów za niewłaściwe przestrzeganie?

W naszej firmie finansowej przeprowadziliśmy audyt w ten sposób. Kierownictwo opracowało procedurę audytu Przeglądu Uprawnień Dostępu, aby wyjaśnić istniejących użytkowników i uprawnienia najpierw w tych systemach informacyjnych, które znalazły się na liście najważniejszych. Właścicielem tego procesu zostało wyznaczone dział bezpieczeństwa. Jednak aby uzyskać pełny obraz uprawnień dostępu w firmie, konieczne było zaangażowanie w proces działów IT i biznesu. I tu zaczęły się spory, nieporozumienia, a czasami nawet sabotaż: nikt nie chce rezygnować ze swoich obecnych obowiązków i angażować się w jakieś, na pierwszy rzut oka, niejasne działania.

N.B. Duże firmy z rozwiniętymi procesami IT na pewno znają procedurę audytu IT – IT general controls (ITGC), która pozwala zidentyfikować niedociągnięcia w procesach IT i wprowadzić kontrolę, aby poprawić procesy zgodnie z najlepszymi praktykami (ITIL, COBIT, IT Governance itp.) Taki audyt pozwala IT i biznesowi lepiej się zrozumieć i wypracować wspólną strategię rozwoju, przeanalizować ryzyko, zoptymalizować koszty i wypracować bardziej efektywne podejścia w pracy.



Jednym z kierunków audytu jest określenie parametrów dostępu logicznego i fizycznego do systemów informacyjnych. Zebrane dane przyjęliśmy jako podstawę do dalszego wykorzystania przy budowie modelu ról. W wyniku takiego audytu powstał rejestr systemów IT, w którym określono ich parametry techniczne i sporządzono opisy. Ponadto dla każdego systemu wyznaczono właściciela z działu biznesowego, w interesie którego był on eksploatowany: to on odpowiadał za procesy biznesowe, które ten system wspierał. Wyznaczony został również menedżer działu IT, odpowiedzialny za techniczną realizację potrzeb biznesu w konkretnym IS. Zarejestrowano najważniejsze systemy dla firmy oraz ich parametry techniczne, terminy wprowadzania i wycofywania z eksploatacji itd. Parametry te bardzo pomogły w procesie przygotowania do budowy modelu ról.

Krok 3 Tworzymy metodologię

Kluczem do sukcesu każdego przedsięwzięcia jest odpowiednio dobrana metoda. Dlatego również przy budowie modelu ról oraz przeprowadzaniu audytu musimy stworzyć metodologię, w której opiszemy interakcje między działami, przypiszemy odpowiedzialności w regulaminach firmy itd.
Na początku należy zbadać wszystkie dokumenty, które określają zasady przyznawania dostępu i praw. Zasadniczo procesy powinny być udokumentowane na kilku poziomach:

• ogólne wymagania korporacyjne;
• wymagania dotyczące obszarów bezpieczeństwa informacji (zależą od kierunków działalności organizacji);
• wymagania dotyczące procesów technologicznych (instrukcje, matryce dostępu, wskazówki metodologiczne, wymagania dotyczące konfiguracji).

W naszej firmie finansowej odkryliśmy wiele przestarzałych dokumentów – musieliśmy je dostosować do wprowadzanych nowych procesów.

Na polecenie kierownictwa powołano grupę roboczą, w skład której weszli przedstawiciele działów bezpieczeństwa, IT, biznesu i kontroli wewnętrznej. W poleceniu określono cele utworzenia grupy, kierunek działalności, czas trwania oraz odpowiedzialnych z każdej strony. Ponadto opracowaliśmy metodologię przeprowadzania audytu oraz zasady budowy modelu ról: zostały one uzgodnione przez wszystkich odpowiedzialnych przedstawicieli działów i zatwierdzone przez kierownictwo firmy.

Dokumenty opisujące procedurę wykonywania prac, terminy, odpowiedzialność itp. to gwarancja, że na drodze do upragnionego celu, który na początku nie jest oczywisty dla wszystkich, nikt nie będzie miał pytania "po co to robimy, dlaczego jest nam to potrzebne itp." i nie będzie możliwości "wyjąć się" lub spowolnić proces.

Krok 4. Zapisujemy parametry istniejącego modelu zarządzania dostępem

Opracowujemy tzw. "paszport systemu" w zakresie zarządzania dostępem. W zasadzie jest to kwestionariusz dotyczący konkretnego systemu informacyjnego, w którym zostały zapisane wszystkie algorytmy zarządzania dostępem do niego. Firmy, które już wdrożyły rozwiązania klasy IdM, z pewnością znają podobny kwestionariusz, ponieważ od niego zaczyna się badanie systemów.

Część informacji o systemie i właścicielach została przeniesiona do kwestionariusza z rejestru IT (patrz krok 2, audyt), ale dodano także nowe:

• w jaki sposób zarządzane są konta użytkowników (bezpośrednio w bazie danych lub za pośrednictwem interfejsów programistycznych);
• w jaki sposób użytkownicy logują się do systemu (za pomocą osobnego konta lub korzystając z konta AD, LDAP itp.);
• jakie poziomy dostępu do systemu są używane (poziom aplikacji, poziom systemowy, użycie systemu zasobów plików sieciowych);
• opis i parametry serwerów, na których działa system;
• jakie operacje zarządzania kontami użytkowników są wspierane (blokada, zmiana nazwy itp.);
• według jakich algorytmów lub zasad formowany jest identyfikator użytkownika systemu;
• na podstawie jakiego atrybutu można ustanowić powiązanie z zapisem pracownika w systemie kadrowym (imię i nazwisko, numer identyfikacyjny itp.);
• wszystkie możliwe atrybuty konta użytkownika oraz zasady ich wypełniania;
• jakie prawa dostępu istnieją w systemie (role, grupy, prawa atomowe itp., czy istnieją prawa zagnieżdżone lub hierarchiczne);
• mechanizmy podziału praw dostępu (według stanowisk, działów, funkcji itp.);
• czy w systemie istnieją zasady podziału obowiązków (SOD – Segregacja Obowiązków) i jak one działają;
• jak w systemie przetwarzane są wydarzenia nieobecności, przeniesienia, zwolnienia, aktualizacji danych o pracownikach itp.

Można kontynuować tę listę z dokładnym opisem różnych parametrów i innych obiektów zaangażowanych w proces zarządzania dostępem.

Krok 5. Tworzymy opis uprawnień zorientowany na biznes

Innym dokumentem, który będzie potrzebny przy budowie modelu ról, jest słownik wszystkich możliwych uprawnień (praw), które można przyznać użytkownikom w systemie informacyjnym z szczegółowym opisem funkcji biznesowej, która za tym stoi. Często uprawnienia w systemie są zaszyfrowane w postaci określonych nazw składających się z liter i cyfr, a pracownicy biznesu nie mogą zrozumieć, co się za tym kryje. Wtedy zwracają się do działu IT, a tam… również nie mogą uzyskać odpowiedzi na przykład w sprawie rzadko używanych praw. Wtedy konieczne staje się przeprowadzenie dodatkowych testów.

Dobrze, jeśli opis biznesowy już istnieje lub nawet występuje połączenie tych praw w grupy i role. Dla niektórych aplikacji najlepszą praktyką jest stworzenie takiego słownika już na etapie ich rozwoju. Jednak to zdarza się rzadko, dlatego znowu idziemy do działu IT, aby zebrać informacje o wszystkich możliwych prawach i je opisać. Nasz słownik w końcu będzie zawierał następujące elementy:

• nazwa uprawnienia, w tym obiekt, do którego stosuje się prawo dostępu;
• czynność, którą można wykonać z obiektem (przeglądanie, modyfikacja itp., możliwość ograniczenia, na przykład według kryteriów terytorialnych lub grup klientów);
• kod uprawnienia (kod i nazwa funkcji/zapytania systemu, które można wykonać z wykorzystaniem uprawnienia);
• opis uprawnienia (szczegółowy opis działań w IS przy stosowaniu uprawnienia i ich skutków dla procesu;
• status uprawnienia: «Aktywne» (jeśli uprawnienie jest przyznane przynajmniej jednemu użytkownikowi) lub «Nieaktywne» (jeśli uprawnienie nie jest używane).

Krok 6 Wyeksportuj z systemów dane o użytkownikach i uprawnieniach oraz porównaj je ze źródłem kadrowym

Na ostatnim etapie przygotowań należy wyeksportować dane z systemów informacyjnych dotyczące wszystkich użytkowników oraz posiadanych przez nich uprawnień na chwilę obecną. Możliwe są dwa scenariusze. Pierwszy: jednostka ds. bezpieczeństwa ma bezpośredni dostęp do systemu i dysponuje odpowiednimi środkami do wyeksportowania raportów, co zdarza się rzadko, ale jest bardzo wygodne. Drugi: wysyłamy zapytanie do IT o uzyskanie raportów w wymaganym formacie. Praktyka pokazuje, że zgoda z IT i uzyskanie potrzebnych danych za pierwszym razem nie jest łatwe. Należy podjąć kilka prób, zanim informacja zostanie uzyskana w odpowiedniej formie i formacie.

Jakie dane należy wyeksportować:

• Nazwa konta
• Imię i nazwisko pracownika, do którego jest przypisane
• Status (aktywny lub zablokowany)
• Data utworzenia konta
• Data ostatniego użycia
• Lista dostępnych uprawnień/grup/rol

Zatem otrzymaliśmy eksport z systemu ze wszystkimi użytkownikami i wszystkimi przyznanymi im uprawnieniami. Od razu odłożyliśmy na bok wszystkie zablokowane konta, ponieważ prace nad budową modelu ról będą prowadzone tylko dla aktywnych użytkowników.

Następnie, jeśli w Twojej firmie nie ma zautomatyzowanych środków do zamykania dostępu byłym pracownikom (co jest dość powszechne) lub istnieje patchworkowa automatyzacja, która nie zawsze działa poprawnie, należy zidentyfikować wszystkie 'martwe dusze'. Mowa tu o kontach byłych pracowników, których uprawnienia z jakiegoś powodu nie zostały zablokowane – należy je zablokować. W tym celu porównujemy wyeksportowane dane z danymi kadrowymi. Eksport danych kadrowych również należy wcześniej uzyskać od jednostki prowadzącej bazę kadrową.

Należy osobno odłożyć konta, których właściciele nie zostali odnalezieni w bazie kadrowej, nienałożone na nikogo, czyli bezpańskie. Do tej listy potrzebna będzie data ostatniego użycia: jeśli jest dość świeża, to i tak trzeba będzie poszukać właścicieli. Mogą to być konta zewnętrznych wykonawców lub służbowe konta, nienałożone na nikogo, ale związane z jakimiś procesami. Aby ustalić przynależność kont, można rozesłać do wszystkich działów wiadomości z prośbą o odpowiedź. Gdy właściciele zostaną odnalezieni, wprowadzamy ich dane do systemu: w ten sposób wszystkie aktywne konta są zidentyfikowane, a pozostałe blokujemy.

Gdy nasze wywody są oczyszczone z niepotrzebnych wpisów i pozostały tylko aktywne konta, można przystąpić do budowy modelu ról dla konkretnego systemu informatycznego. O tym opowiem już w następnym artykule.

Autor: Ludmiła Sewastjanowa, menedżer ds. promocji Solar inRights

Źródło: habr.com