Przegląd uprawnień poza SAP: case study 8 systemów

Gdy audytor finansowy sygnalizuje „opinię z zastrzeżeniem", ponieważ osiem krytycznych dla biznesu systemów nie ma procesu przeglądu uprawnień, organizacja nie ma problemu zgodności. Ma problem w rachunku wyników.

To historia tego, jak duża polska grupa telco-media rozszerzyła smartReview poza SAP, aby objąć osiem systemów spoza SAP przechowujących pozostałą część danych księgowych i klientów. Sześć miesięcy projektowania i integracji, cztery odrzucone architektury alternatywne, jeden neutralny platformowo wzorzec adaptera GRC i obrona przed audytem, która wreszcie przestała kosztować dziesiątki osobodni rocznie.

Powód był konkretny. Audytor zewnętrzny grupy przez dwa kolejne audyty rocznego sprawozdania finansowego podnosił tę samą kwestię: SAP był objęty okresowym przeglądem uprawnień (przy użyciu smartGRC od kilku lat), ale osiem innych krytycznych dla biznesu systemów przechowujących istotne dane księgowe, billingowe i klientów - nie. Podczas audytu za rok 2019 sprawa niemal przekroczyła granicę opinii z zastrzeżeniem do sprawozdania finansowego. Zespoły wewnętrzne spędziły dziesiątki osobodni nad dowodami kompensującymi - wyciąganiem raportów, obroną doboru próby, mapowaniem uprawnień na księgowania w księdze głównej - dla ustaleń, których realny przegląd uprawnień w ogóle by nie dopuścił.

Decyzja, przed którą grupa stanęła w połowie 2020 roku, nie brzmiała „czy uruchomić przeglądy uprawnień w systemach spoza SAP". Brzmiała jak, biorąc pod uwagę presję czasową przed kolejnym cyklem audytowym, złożoność organizacyjną oraz równoległy projekt wyboru IDM, który już zdecydował, że funkcji GRC nie obejmuje swoim zakresem.

To opis tego, jak ta decyzja przebiegła, co analizowano, co odrzucono, co zbudowano i czego projekt nauczył nas o ograniczeniach każdej innej architektury w tej kategorii. Nazwy, dokładne liczby i identyfikujące nazwy systemów zostały zanonimizowane; wzorce strukturalne i rzędy wielkości pozostają niezmienione. Pięciu klientów korporacyjnych, w tym jedna grupa giełdowa, eksploatuje smartReview poza SAP w środowisku produkcyjnym do dziś.

Tablica wyników na start

Systemów spoza SAP

~13 tys.

Unikatowych kont użytkowników

Wzorców powiązania tożsamości

Archetypów modelu uprawnień

12 tyg.

Od projektu do pierwszego przeglądu

Platforma GRC (smartGRC)

Złożoności dwóch systemów

Lata presji audytowej

Dlaczego przegląd uprawnień poza SAP nigdy się nie wykonuje

Pytanie nie brzmi, dlaczego złożona organizacja chce przeglądów uprawnień. Pytanie brzmi, dlaczego w praktyce dotyczą one SAP i niemal nigdy reszty portfela aplikacji. Odpowiedzią jest czterostronna luka własnościowa i odpowiadająca jej luka narzędziowa.

Audyt wewnętrzny nadzoruje framework kontrolny, ale go nie operuje. IT rozumie role i grants na poziomie bazy, ale rzadko rozumie konsekwencję biznesową konkretnej autoryzacji w konkretnej aplikacji. Administratorzy aplikacji biznesowych często znają detal techniczny, ale to oni są populacją, którą przegląd ma badać, więc nie mogą być weryfikatorami. Właściciel biznesowy aplikacji zawierającej kartoteki klientów, hurtowni danych czy platformy billingowej zwykle nie ma ani słownictwa technicznego, by czytać definicje ról, ani mandatu organizacyjnego, by działać na podstawie tego, co by zobaczył. Stanowisko, które powinno prowadzić okresowe przeglądy w systemie spoza SAP, często w ogóle nie istnieje w strukturze organizacyjnej.

Luka narzędziowa odzwierciedla lukę własnościową. Platformy GRC wyrosły historycznie z praktyki audytu SAP - mówią językiem SAP, dostarczają biblioteki SoD skalibrowane pod transakcje SAP, ich konektory celują przede wszystkim w SAP ERP. Platformy IDM operują na zupełnie innej warstwie: zarządzają cyklem życia konta w języku technicznym („rola AA_KSIEGOWANIE_130"), który nie jest językiem, w którym weryfikator biznesowy może podjąć decyzję. W efekcie ponad siedemdziesiąt procent ryzyka dostępowego w organizacji - żyjącego poza SAP, na platformach billingowych, w hurtowniach danych, w CRM, w księgach pomocniczych, w aplikacjach własnych - wpada w pas niczyj, w którym ani narzędzie GRC, ani narzędzie IDM nie jest oczywistą odpowiedzią.

To właśnie tę lukę projekt postawił sobie za cel zamknąć.

Cztery warianty, które analizowaliśmy, w rosnącej kolejności poważności

Każda istotna zmiana w środowisku regulowanym zaczyna się od dyscypliny wymienienia alternatyw. Grupa przeanalizowała cztery opcje, zanim wybrała tę, która zadziałała.

Wariant 0

Nic nie robić - dalej ponosić koszt obrony przed audytem

Koszt ukryty: dziesiątki osobodni na cykl audytowy poświęcone obronie braku okresowego przeglądu dowodami kompensującymi. Wyciąganie raportów, mapowanie próbek, tłumaczenie, dlaczego konkretny użytkownik miał konkretne uprawnienie. Koszt nie wynosił zero - był rozłożony pomiędzy IT, Finanse i Audyt, dlatego właściciele budżetów nigdy nie widzieli go jako jednej pozycji.

Dlaczego odrzucono: relacja z audytorem była już napięta. Trzeci cykl audytowy z tym samym ustaleniem z wysokim prawdopodobieństwem przesunąłby treść z „kwestii podkreślanej" na formalne zastrzeżenie. Umowa z audytorem miała trzy lata do końca; bardziej pobłażliwego kontrahenta na horyzoncie nie było.

Wariant 1

„Excel + e-mail" - manualny przegląd okresowy bez narzędzi

Jak to wygląda w praktyce: koordynator wyciąga raporty użytkownik-po-systemie, decyduje, kto weryfikuje którą część, pakuje dane do arkuszy, wysyła je mailem, ściga weryfikatorów, zbiera odpowiedzi, odczytuje odpowiedzi i śledzi remediację w kolejnym arkuszu. Każdy cykl pochłania osobotygodnie, zanim którykolwiek weryfikator kliknie „zatwierdzam" przy choćby jednym wierszu.

Dlaczego odrzucono: trzy powody. Nie było właściciela organizacyjnego, który mógłby wiarygodnie absorbować ten wolumen pracy. Odpowiedzi weryfikatorów - nawet gdyby zostały zebrane - nie miałyby formy, na której IT mogłoby czysto działać. A cykl byłby tak kosztowny, że wykonywałby się nigdy - co właśnie było status quo.

Wariant 2

Przeglądy prowadzone przez istniejącą platformę IDM (Oracle)

Co oferowała: platforma IDM mogła w zasadzie generować techniczne raporty dostępu per użytkownik per system, co jest surowcem każdego przeglądu uprawnień. IDM był już wdrożony i mógł, przy pewnej konfiguracji, prowadzić cykl recertyfikacji dla systemów spoza SAP.

Dlaczego odrzucono: język IDM jest techniczny. Weryfikator biznesowy zapytany „czy ten użytkownik powinien móc księgować uzgodnienia bankowe" jest w stanie zdecydować. Weryfikator biznesowy zapytany „czy ten użytkownik nadal potrzebuje roli AA_KSIEGOWANIE_130" - nie jest. IDM nie miał też technicznej ścieżki, by analizować autoryzacje SAP w wystarczającej szczegółowości. Kierowanie przeglądów spoza SAP przez IDM, a przeglądów SAP przez smartGRC zostawiłoby weryfikatorów pracujących w dwóch różnych narzędziach z dwoma różnymi modelami mentalnymi - wzorzec operacyjny, który z doświadczenia rozpada się w ciągu dwóch cykli.

Wariant 3

Nowy zintegrowany pakiet IDM-plus-GRC od dużego dostawcy

Co obiecywał: platforma jednego dostawcy obejmująca tożsamość, recertyfikację i analitykę SoD zarówno dla SAP, jak i poza SAP. Czysta narracja dla komitetu audytu. Prosta pozycja w cenniku licencji.

Dlaczego odrzucono: żaden z kandydujących dostawców nie wycenił modułu analizy SAP. Jeden zadeklarował dostępność funkcji, ale nie zobowiązał się do dostawy. Krajobraz SAP grupy miał własne kontrole - włącznie z blokadami zapisu na poziomie transakcji dla wybranych kodów FI i HR - których standardowy analizator SAP nie zrozumiałby bez prac integracyjnych. Koszt i ryzyko były wyższe niż obawa audytora, którą miały adresować. A praca konfiguracyjna już zainwestowana w smartGRC po stronie SAP musiałaby zostać powtórzona od zera - wysiłek liczony w osobomiesiącach.

Wariant 4

Rozszerzyć moduł smartReview platformy smartGRC na systemy spoza SAP

Dlaczego to była właściwa odpowiedź: smartReview był już zaakceptowany przez audytora finansowego dla SAP. Zespół audytu wewnętrznego był już przeszkolony w konfigurowaniu ryzyk i przeglądów. Dostawca był wystarczająco responsywny, by zakontraktować custom development przy znanym koszcie i znanym harmonogramie. Dodanie systemów spoza SAP było kwestią zbudowania uniwersalnego wzorca pobierania danych, a nie wymiany platformy, która już działała dla największego pojedynczego systemu w zakresie.

Decyzja oparła się na dwóch faktach. Po pierwsze, neutralny platformowo prymityw, na którym operuje smartReview - użytkownik, atrybut uprawnienia, ryzyko w języku biznesowym, rola weryfikatora, werdykt, ścieżka dowodowa - jest ten sam, niezależnie od tego, czy system źródłowy to SAP, czy platforma billingowa. Po drugie, format, który platforma potrzebowała konsumować, to standardowy XML opisany XSD, który dowolny system w portfelu można było zmusić do produkowania.

Decyzja zapadła w połowie czerwca 2020. Dostawca zobowiązał się do gotowości na koniec października. Pierwszy cykl przeglądu spoza SAP ruszył jeszcze w tym samym roku.

Osiem systemów, które podłączyliśmy

Osiem systemów wystarczy, by ujawnić wszystkie ciekawe wzorce integracyjne istniejące w typowym portfelu aplikacji korporacyjnych. Poniższa macierz opisuje je anonimowo, w przybliżonej kolejności trudności integracji:

Typ systemu	Liczba użytkowników	Złożoność techniczna	Złożoność biznesowa
Platforma billingowa telco (backend Sybase/VMS/S2K)	~2 600	Wysoka	Średnia
UI obsługi klienta billingu (natywne AD)	~2 000	Niska	Niska
Korporacyjna hurtownia danych (Teradata)	~1 200	Bardzo wysoka	Bardzo wysoka
Backend transmisji danych billingowych (MS SQL)	~30	Wysoka	Średnia
CRM telemarketingowy (wieloaplikacyjny)	~8 000	Średnia	Wysoka
Księga pomocnicza (aplikacja webowa)	~30	Średnia	Niska
Skonsolidowana nakładka księgowa kartoteki klientów	<20	Niska	Niska
Aplikacja uzgodnień billingowych DTH	~1 000	Średnia	Niska

W tych ośmiu systemach napotkaliśmy każdy wzorzec powiązania tożsamości z kontem, który rozpozna każdy zespół integracyjny w organizacji:

Bezpośrednie powiązanie z Active Directory - przypadek łatwy. Aplikacja uwierzytelnia się względem AD, login AD jest tożsamością, tablica mapująca jest niejawna.
AD plus tablica mapująca dla administratorów - większość użytkowników jest natywna AD, administratorzy mają dedykowane konta techniczne, które wymagają osobnego mapowania z tablicy pomocniczej.
Uwierzytelnianie NTLM międzydomenowe - login walidowany względem domeny macierzystej użytkownika, ale aplikacja siedzi w innej; atrybut EmployeeNumber łączy obie domeny.
Most EmployeeNumber pomiędzy dwiema domenami - aplikacja powstała przed federacją AD; tożsamość trzeba rekonstruować, łącząc atrybuty z systemu HR z dwoma drzewami AD.
Mapowanie zewnętrzne dla kont technicznych - system ma kategorie kont user_##, exp_*, load_*, apl_*, tylko część z nich mapuje się na tożsamości ludzkie; reszta to konta serwisowe wymagające osobnego traktowania.

Jeśli portfel organizacji wygląda choć trochę jak portfel, który rósł przez piętnaście lat akwizycji i replatformingów, ma wszystkie pięć.

Cztery archetypy modelu uprawnień

Modele uprawnień to obszar, w którym systemy różnią się najmocniej, i obszar, w którym abstrakcje w platformie GRC muszą zrobić najwięcej, by ukryć tę różnicę przed weryfikatorem biznesowym.

Profilowy z doradczym IDM - aplikacja ma konta użytkowników i granularne uprawnienia na poziomie bazy danych; warstwa IDM definiuje „profile" jako pakiety tych granularnych uprawnień; ale profil w IDM jest doradczy, nie wiążący. Administrator systemu źródłowego może odbiegać od profilu do woli, a odchylenie nie jest widoczne w widoku IDM. Przegląd IDM mówi, jak powinno być. Przegląd systemu źródłowego mówi, jak jest. Tylko ten drugi ma wartość dla audytu.

Tylko grupy AD - aplikacja autoryzuje na podstawie członkostwa w niewielkiej liczbie grup AD. Przegląd jest czysty: wymienić użytkowników, wymienić ich członkostwa, zdecydować, czy każda para użytkownik-grupa pozostaje zasadna.

Rola bazodanowa z dziedziczeniem - aplikacja jest cienkim klientem nad bazą, a baza ma role, plus jawne grants per tabela lub per widok ponad rolami, plus hierarchie dziedziczenia ról. Uprawnienia są wyliczane dynamicznie w momencie zapytania. Liczba odrębnych „efektywnych uprawnień", które użytkownik może posiadać, jest kombinatoryczna, a większość z nich nigdy nie zostaje wykonana. Naiwny raport wymienia tysiące wierszy uprawnień na użytkownika; raport użyteczny audytowo wymienia kilkanaście uprawnień, które mają znaczenie, i pokazuje, czy użytkownik ma którekolwiek z nich.

Uprawnienia atomowe plus kontekst lokalizacji - najtrudniejsze. Uprawnienia to granularne operacje („utwórz zamówienie", „podnieś umowę", „sprzedaj"), ale operacja ma sens tylko w kontekście lokalizacji organizacyjnej („utwórz zamówienie dla sklepu #4781 dla kategorii klienta X"). Pytanie przeglądu brzmi nie „czy ten użytkownik może utworzyć zamówienie", lecz „czy ten użytkownik może utworzyć zamówienie w tej lokalizacji dla tej kategorii klienta". Model danych musi obsłużyć ten poziom warunkowania, a interfejs weryfikatora musi go wystawić w języku biznesowym. Bez tego przegląd produkuje wolumen bez sygnału.

Wzorzec uniwersalny: adapter XML opisany XSD

Decyzja architektoniczna, która sprawiła, że projekt można było dostarczyć w czasie i w budżecie, była taka: nie budować N konektorów per system. Zbudować jedną dobrze zdefiniowaną schemę pobierania danych i wymagać, by każdy system ją produkował.

Schema opisywała, dla dowolnego systemu źródłowego: populację użytkowników (z metadanymi powiązania tożsamości), katalog uprawnień (atomowych i złożonych), przypisania użytkownik-uprawnienie, znaczniki czasu i statusy przypisań, opcjonalne tagi klasy ryzyka. XSD czynił schemę walidowalną i samodokumentującą. Dowolny system źródłowy, który można było skłonić do zapisania pliku XML w tej schemie, dawał się pobierać.

Miało to trzy praktyczne konsekwencje. Po pierwsze, prace inżynierskie dla każdego nowego systemu były zakresowo zamknięte: wyprodukuj plik XML w schemie, zwaliduj go względem XSD, przekaż dalej. Brak własnej logiki konektora po stronie GRC, brak negocjacji protokołu, brak czekania na uzgodnienia kalendarzy IT. Po drugie, ta sama schema miała później być wypełniana przez nową platformę IDM po jej wdrożeniu; manualny upload był Fazą 1, automatyczny feed z IDM Fazą 2, a logika pobierania danych po stronie GRC nie musiała być przepisywana między fazami. Po trzecie, schema dała każdemu właścicielowi biznesowemu precyzyjną specyfikację tego, co jego system wnosi do procesu przeglądu - co okazało się najszybszym sposobem ujawnienia odkryć typu „ten atrybut jest u nas faktycznie pusty".

Neutralny platformowo prymityw, na którym operuje system GRC, jest ten sam w każdej aplikacji: użytkownik, uprawnienie, ryzyko biznesowe, weryfikator, werdykt, ścieżka dowodowa. Cała reszta to klej integracyjny.

Co musiał dodać smartReview

Rozszerzenie istniejącego narzędzia zawsze wymaga zestawu funkcji, których narzędzie jeszcze nie ma. Dla smartReview były to:

Wiele równoległych cykli przeglądu. Przegląd SAP biegł raz w roku. Osiem systemów spoza SAP oznaczało cykle rozłożone w kalendarzu, czasem nakładające się, czasem wyzwalane ad-hoc (wejścia, ruchy, zmiany regulacyjne). Model danych i kolejka weryfikatora musiały obsługiwać wiele aktywnych cykli adresujących różne populacje systemowe w tym samym czasie, bez przenikania pomiędzy nimi.

Definicje ryzyk spoza SAP w języku biznesowym. Biblioteki SoD SAP opisują ryzyka w kodach transakcji. Katalog ryzyk spoza SAP opisuje ryzyka w działaniach („zaksięguj uzgodnienie bankowe", „zatwierdź korektę kredytową powyżej X EUR", „zmień adres rozliczeniowy klienta"). Definicje ryzyka trzeba było autorsko stworzyć per system, a następnie wyrazić w interfejsie weryfikatora językiem, którego oczekiwała rola weryfikatora.

Ścieżka dowodowa przyjazna audytowi. Każda decyzja weryfikatora musiała zostawić czysty zapis: kto weryfikował, kiedy, co mu pokazano, co zdecydował, jakie dowody dołączył. Audytor finansowy badał ścieżkę dowodową podczas kolejnego audytu; jeśli ścieżka nie wytrzymałaby presji, sam proces przeglądu również by nie wytrzymał. Tu inwestowaliśmy z nawiązką celowo.

Czego się nauczyliśmy

Trzy lekcje powędrowały z nami do każdego kolejnego projektu Beyond SAP.

Sześćdziesięciominutowa klasyfikacja systemu przed jakimkolwiek skopowaniem. Macierz złożoności powyżej to nie artefakt opisu; to realny krok klasyfikacyjny wykonywany na początku każdej nowej integracji systemu. Dwie osie - złożoność techniczna eksportu, złożoność biznesowa mapowania eksportu na język ryzyka - pozwalają zespołowi zobowiązać się do kalendarza z przekonaniem. Pominąć klasyfikację - a projekt deklaruje 6 tygodni i dostarcza w 5 miesięcy.

Właściciel systemu jest w sali, albo system nie zostaje zintegrowany. Trzy z ośmiu systemów w tym projekcie niemal się posypały, bo pierwotny właściciel odszedł, nowy nie został formalnie wyznaczony, a zespół techniczny nie miał uprawnienia, by zobowiązać się do formatu eksportu danych. Nauczyliśmy się odmawiać startu prac, dopóki przy kick-offie nie był obecny imiennie wskazany, aktualny właściciel systemu.

Niektóre systemy należy odroczyć, a nie forsować. Dwa systemy z pierwotnej dziesięcioelementowej listy nie weszły do pierwszego cyklu przeglądu. Jeden miał powiązanie tożsamości na tyle zepsute, że jego rozwiązanie było projektem samym w sobie; jeden był zaplanowany do dekomisji w ciągu dwunastu miesięcy i dałby jeden cykl przeglądu wartości przy koszcie pełnej integracji. „Później" lub „w ogóle nie" to uprawniony wynik kroku klasyfikacyjnego.

Szersza perspektywa

Standardowa narracja o platformach GRC mówi, że istnieją po to, by monitorować SAP. Ta narracja ma piętnaście lat. Dane księgowo-audytowo istotne we współczesnej organizacji wymigrowały na platformy billingowe, do hurtowni danych, do kartotek klientów, do CRM, do nakładek księgowych i aplikacji własnych, które nigdy nie były w SAP i nigdy nie będą. SAP w wielu grupach to znacznie mniej niż połowa powierzchni ryzyka dostępowego.

Platforma GRC, która zatrzymuje się na SAP, rozwiązuje ułamek problemu, do którego zaświadczenia komitet audytu jest proszony. Wybór, który podjęła grupa - dalej eksploatować przegląd SAP w smartReview, rozszerzyć ten sam smartReview na osiem systemów spoza SAP, zbudować neutralny platformowo adapter XML, który przyszły IDM będzie mógł później zasilać automatycznie - nie był sprytnym obejściem. Była to architektura, którą ta kategoria powinna była mieć dziesięć lat temu. Każdy kolejny klient, który eksploatuje smartReview poza SAP, potwierdza to samo: inżynieria nie jest trudna, trudne są własność i język ryzyka. Gdy platforma staje się neutralna, rozmowa przesuwa się tam, gdzie jest wartość.

Audytor finansowy przestał podnosić temat przeglądu uprawnień już w następnym roku. Zespół audytu wewnętrznego przestał spędzać dziesiątki osobodni na dowodach kompensujących. Zespoły IT obsługujące osiem systemów po raz pierwszy zyskały jasną roczną kadencję pracy recertyfikacyjnej, dotąd wykonywanej ad-hoc i częściowo. Komitet audytu zyskał obronną odpowiedź na pytanie, na które przez dekadę odpowiadał błędnie.

Pięciu klientów, w tym jedna giełdowa grupa europejska, eksploatuje smartReview poza SAP w środowisku produkcyjnym do dziś. Wzorzec się przenosi. Jeśli wasz komitet audytu zadaje to samo pytanie, a wasza platforma GRC zatrzymuje się na SAP, architektura powyżej to jest właśnie ta odpowiedź.

O projekcie. Wzorzec opisany w tym artykule został wypracowany przez smartGRC LAB w GRC Advisory podczas projektu w 2020 roku w dużej polskiej grupie telco-media, zanonimizowanego tutaj zgodnie z obowiązkami poufności. Konkretne liczby użytkowników, nazwy systemów, szczegóły powiązania tożsamości i katalogi ryzyk zostały dostosowane, by usunąć szczegóły identyfikujące; wzorce strukturalne i rzędy wielkości pozostają niezmienione. Jeśli operujecie wielosystemową organizacją, w której większość ryzyka dostępowego żyje poza SAP, i chcecie omówić przeprowadzenie podobnego projektu na własnym portfelu, dane kontaktowe i podgląd UX na żywo znajdują się na smartgrc.eu.

Przegląd uprawnień poza SAP: 8 systemów, jedna platforma