Obecnie pracuję dla dostawcy oprogramowania, szczególnie rozwiązań kontroli dostępu. A moje doświadczenie „z poprzedniego życia” wiąże się ze stroną klienta - dużą organizacją finansową. W tamtym czasie nasza grupa kontroli dostępu w dziale bezpieczeństwa informacji nie mogła pochwalić się dużymi kompetencjami w zakresie IdM. Wiele się przy tym nauczyliśmy, musieliśmy pokonać wiele wybojów, aby zbudować działający mechanizm zarządzania uprawnieniami użytkowników w systemach informatycznych w firmie.
Łącząc moje ciężko wypracowane doświadczenie klienta z wiedzą i kompetencjami dostawców, chcę podzielić się z Tobą w zasadzie instrukcją krok po kroku: jak stworzyć model kontroli dostępu oparty na rolach w dużej firmie i co to da w rezultacie . Moja instrukcja składa się z dwóch części: pierwsza to przygotowanie do zbudowania modelu, druga to faktyczne budowanie. Oto część pierwsza, część przygotowawcza.
NB Budowanie wzorca do naśladowania to niestety nie wynik, ale proces. A raczej nawet część procesu tworzenia ekosystemu kontroli dostępu w firmie. Przygotuj się więc na grę przez długi czas.
Najpierw zdefiniujmy to - czym jest kontrola dostępu oparta na rolach? Załóżmy, że masz duży bank zatrudniający dziesiątki, a nawet setki tysięcy pracowników (podmiotów), z których każdy ma dziesiątki praw dostępu do setek wewnętrznych systemów informacyjnych banku (obiektów). Teraz pomnóż liczbę obiektów przez liczbę podmiotów - jest to minimalna liczba połączeń, które musisz najpierw zbudować, a następnie kontrolować. Czy naprawdę można to zrobić ręcznie? Oczywiście, że nie – role zostały stworzone, aby rozwiązać ten problem.
Rola to zestaw uprawnień, których użytkownik lub grupa użytkowników potrzebuje do wykonywania określonych zadań. Każdy pracownik może mieć jedną lub więcej ról, a każda rola może zawierać od jednego do wielu uprawnień przyznanych użytkownikowi w ramach tej roli. Role można powiązać z konkretnymi stanowiskami, działami czy zadaniami funkcjonalnymi pracowników.
Role tworzone są zazwyczaj z indywidualnych uprawnień pracowników w każdym systemie informatycznym. Następnie z ról każdego systemu tworzone są globalne role biznesowe. Na przykład rola biznesowa „menedżer ds. kredytów” będzie obejmować kilka oddzielnych ról w systemach informatycznych używanych w biurze obsługi klienta banku. Przykładowo w takich jak główny zautomatyzowany system bankowy, moduł kasowy, system elektronicznego zarządzania dokumentami, menadżer usług i inne. Role biznesowe z reguły są powiązane ze strukturą organizacyjną – innymi słowy ze zbiorem działów firmy i zajmowanymi w nich stanowiskami. W ten sposób powstaje globalna macierz ról (przykład podaję w poniższej tabeli).
Warto zaznaczyć, że w strukturze komercyjnej nie da się po prostu zbudować stuprocentowego wzorca do naśladowania, zapewniającego pracownikom wszystkich niezbędnych uprawnień na każdym stanowisku. Tak, nie jest to konieczne. W końcu wzór do naśladowania nie może być statyczny, ponieważ zależy od stale zmieniającego się otoczenia. Oraz od zmian w działalności biznesowej firmy, co odpowiednio wpływa na zmiany w strukturze organizacyjnej i funkcjonalności. Oraz z braku pełnego zapewnienia zasobów, z nieprzestrzegania opisów stanowisk, z chęci zysku kosztem bezpieczeństwa i z wielu innych czynników. Dlatego konieczne jest zbudowanie wzorca do naśladowania, który będzie w stanie pokryć aż do 100% potrzeb użytkowników w zakresie niezbędnych podstawowych uprawnień w przypadku przypisania ich do stanowiska. I w razie potrzeby mogą zażądać pozostałych 80% później w odrębnych wnioskach.
Oczywiście możesz zapytać: „Czy nie ma stuprocentowych wzorców do naśladowania?” Cóż, dlaczego tak się dzieje na przykład w strukturach non-profit, które nie podlegają częstym zmianom - w jakimś instytucie badawczym. Lub w organizacjach o kompleksie wojskowo-przemysłowym o wysokim poziomie bezpieczeństwa, gdzie bezpieczeństwo jest na pierwszym miejscu. Dzieje się to w strukturze komercyjnej, ale w ramach odrębnego działu, którego praca jest procesem dość statycznym i przewidywalnym.
Główną zaletą zarządzania opartego na rolach jest uproszczenie nadawania uprawnień, ponieważ liczba ról jest znacznie mniejsza niż liczba użytkowników systemu informatycznego. I to dotyczy każdej branży.
Weźmy firmę detaliczną: zatrudnia tysiące sprzedawców, ale mają oni ten sam zestaw uprawnień w systemie N i zostanie dla nich utworzona tylko jedna rola. Kiedy do firmy przychodzi nowy sprzedawca, automatycznie zostaje mu przypisana wymagana rola w systemie, który posiada już wszystkie niezbędne uprawnienia. Ponadto jednym kliknięciem możesz zmienić uprawnienia tysięcy sprzedawców na raz, na przykład dodać nową opcję generowania raportu. Nie ma potrzeby wykonywania tysiąca operacji, przypisywania nowego uprawnienia do każdego konta - wystarczy dodać tę opcję do roli, a pojawi się ona u wszystkich sprzedawców jednocześnie.
Kolejną zaletą zarządzania opartego na rolach jest eliminacja wydawania niezgodnych ze sobą uprawnień. Oznacza to, że pracownik pełniący w systemie określoną rolę nie może jednocześnie pełnić innej roli, której uprawnień nie należy łączyć z uprawnieniami w pierwszej. Uderzającym przykładem jest zakaz łączenia funkcji wprowadzania danych i kontroli transakcji finansowej.
Każdy, kto jest zainteresowany tym, jak powstała kontrola dostępu oparta na rolach, może to zrobić
zagłębić się w historię
Jeśli spojrzymy na historię, społeczność IT po raz pierwszy pomyślała o metodach kontroli dostępu już w latach 70. XX wieku. Choć wtedy aplikacje były dość proste, tak i teraz każdemu zależało na wygodnym zarządzaniu dostępem do nich. Nadawaj, zmieniaj i kontroluj uprawnienia użytkowników - tak aby łatwiej było zrozumieć, jakie uprawnienia ma każdy z nich. Ale w tamtym czasie nie było wspólnych standardów, powstawały pierwsze systemy kontroli dostępu, a każda firma opierała się na własnych pomysłach i zasadach.
Znanych jest obecnie wiele różnych modeli kontroli dostępu, jednak nie pojawiły się one od razu. Zastanówmy się nad tymi, którzy wnieśli znaczący wkład w rozwój tego obszaru.
Pierwszy i prawdopodobnie najprostszy model to Uznaniowa (selektywna) kontrola dostępu (DAC – uznaniowa kontrola dostępu). Model ten zakłada podział praw pomiędzy wszystkich uczestników procesu dostępu. Każdy użytkownik ma dostęp do określonych obiektów lub operacji. W istocie tutaj zbiór podmiotów praw odpowiada zbiorowi przedmiotów. Stwierdzono, że model ten jest zbyt elastyczny i zbyt trudny w utrzymaniu: listy dostępu w końcu stają się ogromne i trudne do kontrolowania.
Drugi model to Obowiązkowa kontrola dostępu (MAC - Obowiązkowa kontrola dostępu). Zgodnie z tym modelem każdy użytkownik otrzymuje dostęp do obiektu zgodnie z przyznanym mu dostępem, z zachowaniem określonego poziomu poufności danych. W związku z tym obiekty należy kategoryzować według poziomu ich poufności. W odróżnieniu od pierwszego elastycznego modelu, ten natomiast okazał się zbyt rygorystyczny i restrykcyjny. Jego stosowanie nie ma uzasadnienia, gdy firma posiada wiele różnych zasobów informacyjnych: aby zróżnicować dostęp do różnych zasobów, trzeba będzie wprowadzić wiele kategorii, które nie będą się pokrywać.
Ze względu na oczywiste niedoskonałości tych dwóch metod, społeczność IT w dalszym ciągu rozwija modele, które są bardziej elastyczne, a jednocześnie mniej lub bardziej uniwersalne, aby wspierać różne typy polityk kontroli dostępu w organizacji. I wtedy się pojawiło trzeci model kontroli dostępu oparty na rolach! Takie podejście okazało się najbardziej obiecujące, ponieważ wymaga nie tylko autoryzacji tożsamości użytkownika, ale także jego funkcji operacyjnych w systemach.
Pierwszą jasno opisaną strukturę wzorców do naśladowania zaproponowali amerykańscy naukowcy David Ferrailo i Richard Kuhn z amerykańskiego Narodowego Instytutu Standardów i Technologii w 1992 roku. Wtedy po raz pierwszy pojawiło się to określenie RBAC (kontrola dostępu oparta na rolach). Te badania i opisy głównych komponentów, a także ich powiązań, stały się podstawą obowiązującego do dziś standardu INCITS 359-2012, zatwierdzonego przez Międzynarodowy Komitet ds. Standardów Technologii Informacyjnych (INCITS).
Norma definiuje rolę jako „funkcję stanowiska w kontekście organizacji z pewną powiązaną semantyką dotyczącą uprawnień i odpowiedzialności przypisanej użytkownikowi przypisanemu do tej roli”. Dokument ustala podstawowe elementy RBAC - użytkowników, sesje, role, uprawnienia, operacje i obiekty, a także relacje i wzajemne powiązania między nimi.
Standard zapewnia minimalną niezbędną strukturę do zbudowania wzorca do naśladowania – łączenia uprawnień w role, a następnie nadawania dostępu użytkownikom poprzez te role. Zarysowano mechanizmy komponowania ról z obiektów i operacji, opisano hierarchię ról i dziedziczenie uprawnień. Przecież w każdej firmie istnieją role łączące podstawowe uprawnienia niezbędne wszystkim pracownikom firmy. Może to być dostęp do poczty elektronicznej, EDMS, portalu korporacyjnego itp. Uprawnienia te można ująć w jednej ogólnej roli zwanej „pracownikiem” i nie będzie potrzeby ciągłego wypisywania wszystkich podstawowych uprawnień w każdej z ról wyższego szczebla. Wystarczy po prostu wskazać cechę dziedziczenia roli „pracownika”.
Później standard został uzupełniony o nowe atrybuty dostępu związane ze stale zmieniającym się otoczeniem. Dodano możliwość wprowadzenia ograniczeń statycznych i dynamicznych. Statyczne implikują niemożność łączenia ról (to samo wprowadzanie i kontrola operacji, o których mowa powyżej). Ograniczenia dynamiczne można określić zmieniając parametry, na przykład czas (godziny lub dni pracy/wolne od pracy), lokalizację (biuro/dom) itp.
Osobno należy powiedzieć o kontrola dostępu oparta na atrybutach (ABAC – kontrola dostępu oparta na atrybutach). Podejście to opiera się na udzielaniu dostępu za pomocą reguł współdzielenia atrybutów. Model ten może być stosowany oddzielnie, ale często aktywnie uzupełnia klasyczny wzór do naśladowania: do określonej roli można dodać atrybuty użytkowników, zasobów i urządzeń, a także czas lub lokalizację. Dzięki temu możesz używać mniejszej liczby ról, wprowadzać dodatkowe ograniczenia i maksymalnie ograniczać dostęp, a co za tym idzie, poprawiać bezpieczeństwo.
Na przykład księgowy może uzyskać dostęp do rachunków, jeśli pracuje w określonym regionie. Następnie lokalizacja specjalisty zostanie porównana z określoną wartością referencyjną. Możesz też przyznać dostęp do kont tylko wtedy, gdy użytkownik zaloguje się z urządzenia znajdującego się na liście dozwolonych. Dobry dodatek do wzorca do naśladowania, jednak rzadko stosowany samodzielnie ze względu na konieczność tworzenia wielu reguł i tabel uprawnień lub ograniczeń.
Podam przykład użycia ABAC z mojego „poprzedniego życia”. Nasz bank miał kilka oddziałów. Pracownicy biur klientów w tych oddziałach wykonywali dokładnie te same operacje, tyle że musieli pracować w systemie głównym tylko z rachunkami w swoim regionie. Najpierw zaczęliśmy tworzyć osobne role dla każdego regionu – a było ich naprawdę wiele, z powtarzalną funkcjonalnością, ale z dostępem do różnych kont! Następnie wykorzystując dla użytkownika atrybut lokalizacji i powiązując go z konkretnym zakresem kont do przeglądu, znacząco zmniejszyliśmy liczbę ról w systemie. W rezultacie role pozostały tylko dla jednego oddziału, które zostały powielone dla odpowiednich stanowisk we wszystkich pozostałych jednostkach terytorialnych banku.
Porozmawiajmy teraz o niezbędnych krokach przygotowawczych, bez których zbudowanie działającego wzoru do naśladowania jest po prostu niemożliwe.
Krok 1. Utwórz model funkcjonalny
Należy zacząć od stworzenia modelu funkcjonalnego – dokumentu najwyższego poziomu, który szczegółowo opisuje funkcjonalność każdego działu i każdego stanowiska. Z reguły informacje trafiają do niego z różnych dokumentów: opisów stanowisk i regulaminów poszczególnych jednostek - wydziałów, wydziałów, wydziałów. Model funkcjonalny musi zostać uzgodniony ze wszystkimi zainteresowanymi działami (biznesu, kontroli wewnętrznej, bezpieczeństwa) i zatwierdzony przez kierownictwo firmy. Do czego służy ten dokument? Aby wzór do naśladowania mógł się do tego odwoływać. Na przykład zamierzasz zbudować wzór do naśladowania w oparciu o istniejące uprawnienia pracowników - wyładowane z systemu i „sprowadzone do wspólnego mianownika”. Następnie uzgadniając otrzymane role z właścicielem biznesowym systemu, możesz odwołać się do konkretnego punktu modelu funkcjonalnego, na podstawie którego to lub inne uprawnienie jest zawarte w roli.
Krok 2. Audytujemy systemy informatyczne i ustalamy plan priorytetyzacji
W drugim etapie należy przeprowadzić audyt systemów informatycznych, aby zrozumieć, jak zorganizowany jest dostęp do nich. Na przykład moja firma finansowa obsługiwała kilkaset systemów informatycznych. Wszystkie systemy miały pewne podstawy zarządzania opartego na rolach, większość miała jakieś role, ale głównie na papierze lub w katalogu systemowym - były one dawno przestarzałe, a dostęp do nich był przyznawany na podstawie rzeczywistych żądań użytkowników. Oczywiście nie da się zbudować wzorca w kilkuset systemach na raz, od czegoś trzeba zacząć. Przeprowadziliśmy dogłębną analizę procesu kontroli dostępu, aby określić jego poziom dojrzałości. W procesie analizy opracowano kryteria ustalania priorytetów systemów informatycznych – krytyczność, gotowość, plany wycofania z eksploatacji itp. Z ich pomocą zaplanowaliśmy rozwój/aktualizację wzorców do naśladowania dla tych systemów. Następnie uwzględniliśmy wzorce do naśladowania w planie integracji z rozwiązaniem Identity Management w celu automatyzacji kontroli dostępu.
Jak więc określić krytyczność systemu? Odpowiedz sobie na następujące pytania:
- Czy system jest powiązany z procesami operacyjnymi, od których zależy podstawowa działalność firmy?
- Czy zakłócenia w systemie będą miały wpływ na integralność aktywów firmy?
- Jaki jest maksymalny dopuszczalny czas przestoju systemu, po osiągnięciu którego nie ma możliwości przywrócenia działania po przerwie?
- Czy naruszenie integralności informacji w systemie może prowadzić do nieodwracalnych konsekwencji, zarówno finansowych, jak i reputacyjnych?
- Krytyka oszustwa. Obecność funkcjonalności, jeśli nie jest odpowiednio kontrolowana, może prowadzić do wewnętrznych/zewnętrznych oszukańczych działań;
- Jakie są wymagania prawne oraz wewnętrzne zasady i procedury dotyczące tych systemów? Czy organy regulacyjne będą karane za nieprzestrzeganie przepisów?
W naszej firmie finansowej przeprowadziliśmy taki audyt. Kierownictwo opracowało procedurę audytu Przeglądu Praw Dostępu, aby w pierwszej kolejności przyjrzeć się istniejącym użytkownikom i ich prawom w tych systemach informatycznych, które znajdowały się na liście najwyższych priorytetów. Właścicielem tego procesu został wyznaczony dział bezpieczeństwa. Aby jednak uzyskać pełny obraz praw dostępu w firmie, konieczne było zaangażowanie w ten proces działów IT i biznesowego. I tu zaczęły się spory, nieporozumienia, a czasem nawet sabotaż: nikt nie chce oderwać się od dotychczasowych obowiązków i wciągnąć w jakieś, na pierwszy rzut oka niezrozumiałe działania.
NB Duże firmy posiadające rozwinięte procesy IT zapewne znają procedurę audytu IT – IT general control (ITGC), która pozwala na identyfikację braków w procesach IT i ustanowienie kontroli tak, aby usprawniać procesy zgodnie z najlepszymi praktykami (ITIL, COBIT, IT Governance itp.) Taki audyt pozwala IT i biznesowi lepiej się zrozumieć i opracować wspólną strategię rozwoju, przeanalizować ryzyko, zoptymalizować koszty i wypracować bardziej efektywne podejście do pracy.
Jednym z obszarów audytu jest określenie parametrów logicznego i fizycznego dostępu do systemów informatycznych. Uzyskane dane przyjęliśmy jako podstawę do dalszego wykorzystania w budowaniu wzoru do naśladowania. W wyniku tego audytu uzyskaliśmy rejestr systemów informatycznych, w którym określono ich parametry techniczne oraz podano opisy. Dodatkowo dla każdego systemu zidentyfikowano właściciela ze względu na kierunek biznesowy, w czyim interesie był obsługiwany: to on był odpowiedzialny za procesy biznesowe, które ten system obsługiwał. Powołano także menadżera serwisu IT, odpowiedzialnego za techniczną realizację potrzeb biznesowych dla konkretnego IS. Zanotowano najważniejsze dla przedsiębiorstwa systemy i ich parametry techniczne, terminy uruchomienia i wycofania z eksploatacji, itp. Parametry te były bardzo pomocne w procesie przygotowań do stworzenia wzorca do naśladowania.
Krok 3 Stwórz metodologię
Kluczem do sukcesu każdego biznesu jest odpowiednia metoda. Dlatego zarówno chcąc zbudować wzór do naśladowania, jak i przeprowadzić audyt, musimy stworzyć metodologię, w której opiszemy interakcję pomiędzy działami, ustalimy odpowiedzialność w regulaminie firmy itp.
Najpierw musisz sprawdzić wszystkie dostępne dokumenty określające procedurę przyznawania dostępu i praw. W dobrym tego słowa znaczeniu procesy powinny być dokumentowane na kilku poziomach:
- ogólne wymagania korporacyjne;
- wymagania dotyczące obszarów bezpieczeństwa informacji (w zależności od obszarów działalności organizacji);
- wymagania dla procesów technologicznych (instrukcje, matryce dostępu, wytyczne, wymagania dotyczące konfiguracji).
W naszej firmie finansowej znaleźliśmy wiele nieaktualnych dokumentów, które musieliśmy sprowadzić zgodnie z wdrażanymi nowymi procesami.
Na zlecenie kierownictwa utworzono grupę roboczą, w skład której weszli przedstawiciele bezpieczeństwa, IT, biznesu i kontroli wewnętrznej. Rozkaz określał cele utworzenia grupy, kierunek działania, okres istnienia oraz osoby odpowiedzialne z każdej ze stron. Dodatkowo opracowaliśmy metodykę audytu oraz procedurę budowania wzorca: zostały one uzgodnione przez wszystkich odpowiedzialnych przedstawicieli obszarów i zatwierdzone przez kierownictwo firmy.
Dokumenty opisujące procedurę wykonywania pracy, terminy, obowiązki itp. - gwarancja, że w drodze do upragnionego celu, który na początku nie jest dla wszystkich oczywisty, nikt nie będzie miał pytań „po co to robimy, po co nam to itp.” i nie będzie możliwości „odskoczenia” lub spowolnienia procesu.
Krok 4. Napraw parametry istniejącego modelu kontroli dostępu
Sporządzamy tzw. „paszport systemowy” w zakresie kontroli dostępu. W istocie jest to kwestionariusz dotyczący konkretnego systemu informatycznego, w którym rejestrowane są wszystkie algorytmy kontroli dostępu do niego. Firmy, które wdrożyły już rozwiązania klasy IdM, zapewne znają taką ankietę, gdyż od niej rozpoczynają się badania nad systemami.
Niektóre parametry dotyczące systemu i właścicieli napłynęły do kwestionariusza z rejestru IT (patrz krok 2, audyt), ale dodano także nowe:
- sposób zarządzania kontami (bezpośrednio w bazie danych lub poprzez interfejsy oprogramowania);
- sposób, w jaki użytkownicy logują się do systemu (przy użyciu osobnego konta lub przy użyciu konta AD, LDAP itp.);
- jakie poziomy dostępu do systemu są stosowane (poziom aplikacji, poziom systemu, wykorzystanie przez system zasobów plików sieciowych);
- opis i parametry serwerów, na których działa system;
- jakie operacje zarządzania kontem są obsługiwane (blokowanie, zmiana nazwy itp.);
- jakie algorytmy lub reguły służą do generowania identyfikatora użytkownika systemu;
- jakim atrybutem można nawiązać połączenie z kartoteką pracownika w systemie kadrowym (imię i nazwisko, numer personalny itp.);
- wszystkie możliwe atrybuty konta i zasady ich wypełniania;
- jakie prawa dostępu istnieją w systemie (role, grupy, uprawnienia atomowe itp., czy istnieją uprawnienia zagnieżdżone lub hierarchiczne);
- mechanizmy podziału praw dostępu (według stanowiska, działu, funkcjonalności itp.);
- Czy w systemie istnieją zasady segregacji uprawnień (SOD – Segregacja Obowiązków) i jak one działają;
- w jaki sposób w systemie przetwarzane są zdarzenia nieobecności, przeniesienia, zwolnienia, aktualizacji danych pracowników itp.
Listę tę można kontynuować o szczegółowe informacje na temat różnych parametrów i innych obiektów biorących udział w procesie kontroli dostępu.
Krok 5. Stwórz biznesowy opis uprawnień
Kolejnym dokumentem, który będzie nam potrzebny przy budowaniu wzoru do naśladowania, jest księga informacyjna dotycząca wszelkich możliwych uprawnień (praw), jakie można nadać użytkownikom w systemie informatycznym wraz ze szczegółowym opisem funkcji biznesowej, która za tym stoi. Często uprawnienia w systemie są szyfrowane przy użyciu określonych nazw składających się z liter i cyfr, a pracownicy biznesowi nie są w stanie zrozumieć, co kryje się za tymi symbolami. Potem idą do serwisu IT i tam... też nie potrafią odpowiedzieć na pytanie np. o rzadko wykorzystywane uprawnienia. Następnie należy wykonać dodatkowe badania.
Dobrze jeśli jest już opis działalności lub chociaż jest połączenie tych uprawnień w grupy i role. W przypadku niektórych aplikacji najlepszą praktyką jest utworzenie takiego odniesienia na etapie programowania. Nie zdarza się to jednak często, dlatego ponownie udajemy się do działu IT, aby zebrać informacje o wszystkich możliwych uprawnieniach i je opisać. Nasz przewodnik będzie ostatecznie zawierał następujące informacje:
- nazwa organu, w tym przedmiot, którego dotyczy prawo dostępu;
- czynność, którą można wykonać na obiekcie (przeglądanie, zmienianie itp., możliwość ograniczenia np. terytorialnie lub ze względu na grupę klientów);
- kod autoryzacyjny (kod i nazwa funkcji/żądania systemu, które można wykonać przy pomocy autoryzacji);
- opis uprawnienia (szczegółowy opis działań w SI podczas stosowania uprawnienia i ich konsekwencje dla procesu;
- status uprawnień: „Aktywne” (jeśli uprawnienie jest przypisane przynajmniej jednemu użytkownikowi) lub „Nieaktywne” (jeżeli uprawnienie nie jest wykorzystywane).
Krok 6 Pobieramy z systemów dane o użytkownikach i uprawnieniach i porównujemy je ze źródłem kadrowym
Na końcowym etapie przygotowań należy pobrać z systemów informatycznych dane o wszystkich użytkownikach i przysługujących im aktualnie uprawnieniach. Możliwe są tutaj dwa scenariusze. Po pierwsze: dział bezpieczeństwa ma bezpośredni dostęp do systemu i ma możliwość pobierania odpowiednich raportów, co nie zdarza się często, ale jest bardzo wygodne. Po drugie: wysyłamy prośbę do IT o otrzymanie raportów w wymaganym formacie. Doświadczenie pokazuje, że nie da się dojść do porozumienia z IT i pozyskać niezbędnych danych za pierwszym razem. Konieczne jest wykonanie kilku podejść, aż informacja zostanie otrzymana w pożądanej formie i formacie.
Jakie dane należy pobrać:
- Nazwa konta
- Imię i nazwisko pracownika, do którego jest przypisany
- Status (aktywny lub zablokowany)
- Data utworzenia konta
- Data ostatniego użycia
- Lista dostępnych uprawnień/grup/ról
Otrzymaliśmy więc pliki do pobrania z systemu ze wszystkimi użytkownikami i wszystkimi przyznanymi im prawami. I natychmiast odkładają na bok wszystkie zablokowane konta, ponieważ prace nad zbudowaniem wzoru do naśladowania będą prowadzone tylko dla aktywnych użytkowników.
Następnie, jeśli Twoja firma nie posiada zautomatyzowanych możliwości blokowania dostępu zwalnianym pracownikom (co często się zdarza) lub ma patchworkową automatyzację, która nie zawsze działa poprawnie, musisz zidentyfikować wszystkie „martwe dusze”. Mówimy o kontach pracowników, którzy zostali już zwolnieni, których prawa z jakiegoś powodu nie są zablokowane – trzeba je zablokować. W tym celu porównujemy przesłane dane ze źródłem personelu. Rozładunek personelu należy również uzyskać wcześniej od działu prowadzącego bazę danych personelu.
Odrębnie należy wydzielić konta, których właścicieli nie odnaleziono w bazie personelu, nie są do nikogo przypisane – czyli są bez właściciela. Korzystając z tej listy, będziemy potrzebować daty ostatniego użycia: jeśli jest całkiem niedawna, nadal będziemy musieli szukać właścicieli. Mogą to być konta kontrahentów zewnętrznych lub konta usług, które nie są nikomu przypisane, ale są powiązane z jakimikolwiek procesami. Aby dowiedzieć się do kogo należą konta, możesz wysłać pisma do wszystkich działów z prośbą o odpowiedź. Po znalezieniu właścicieli wprowadzamy o nich dane do systemu: w ten sposób identyfikowane są wszystkie aktywne konta, a pozostałe są blokowane.
Gdy tylko nasze przesłane pliki zostaną oczyszczone z niepotrzebnych zapisów i pozostaną tylko aktywne konta, możemy zacząć budować wzór do naśladowania dla konkretnego systemu informacyjnego. Ale o tym opowiem w następnym artykule.
Autor: Ludmiła Sevastyanova, kierownik promocji Solar inRights
Źródło: www.habr.com