Audyt tożsamości
1) Cel i wynik
Cel: zapewnienie udowodnionej zgodności z zasadami Zero Trust i najmniej przywilejów poprzez regularną weryfikację, kto ma jaki dostęp gdzie i dlaczego.
Wynik: kompletny i aktualny rejestr tożsamości i praw z potwierdzonymi właścicielami, wyeliminowany „zamrożony” dostęp, sformalizowana baza dowodowa dla kontroli wewnętrznej i organów regulacyjnych.
2) Zakres stosowania
Użytkownicy wewnętrzni: pracownicy, stażyści, organy nadzoru, role tymczasowe.
Wykonawcy/partnerzy: studia gier, dostawcy PSP/KYC/AML, podmioty powiązane.
Identyfikacje serwisowe: boty, CI/CD, integracje, klucze i tokeny API.
Role uprzywilejowane: administratorzy infrastruktury/bazy danych, płatności, ryzyko, handel.
Odtwarzacze (w kontekście KYC): poprawność pakietu kont, a nie zawartość dokumentów.
3) Warunki i zasady
Tożsamość: unikalny podmiot (osoba/usługa) z atrybutami.
Uprawnienie: szczególne prawo/rola dla danego zasobu.
JML: Joiner → Mover → Dźwignia - cykl życia tożsamości.
SoD: rozdzielenie obowiązków związanych z operacjami wysokiego ryzyka.
Minimum Privilege & Just-in-Time (JIT): minimalny zestaw praw przyznanych na czas określony.
Odpowiedzialność: każda tożsamość ma właściciela, każde prawo ma sprawę biznesową i termin.
4) Źródła prawdy i model danych
System HRIS/HR: podstawowe źródło statusu pracownika (wynajem/przeniesienie/wyjście).
IdP/SSO: pojedynczy punkt uwierzytelniania (MFA/FIDO2), federacja.
IAM/IGA: Katalog ról, polityk i procesów recertyfikacji.
Katalog CMDB/usługi: własność systemów i pętli dostępu.
Platformy dostawców: PSP/KYC/CDN/WAF/dostawcy gier - zewnętrzne portale dostępu.
Модела: Tożsamość → (należy do) → Org Unit/Team → (has) → Roles → (expand via ABAC) → Entitlements → (apply) → Resources.
5) Kontrolowane kontrole
1. SSO i MFA wszędzie (bez kont lokalnych i wspólnych).
2. RBAC/ABAC/PBAC: prawa opisane przez politykę (policy-as-code), role - typowe i spójne.
3. SoD: niekompatybilne role i wyjątki są formalizowane.
4. JIT/PAM: tymczasowe promocje z biletem, nagrywanie sesji i auto-recall.
5. Sekrety/klucze: Przechowywane w Menedżerze Tajemnic, z rotacją i okresami życia.
6. Kłody i provability: manipulator-dowód, spójne śledzenie kto/co/gdzie/kiedy/dlaczego.
7. Dostęp do danych: maskowanie PII, eksport - tylko poprzez przepływ pracy z szyfrowaniem i TTL.
6) Proces audytu (od końca do końca)
1. Przygotowanie: zamrożenie migawki praw (uprawnień migających) według systemu; Pobierz z IdP/IAM/dostawców
2. Normalizacja: mapowanie ról do katalogu, deduplikacja, grupowanie przez właścicieli zasobów.
3. Kategoryzacja ryzyka: P1/P2 (uprzywilejowane i wrażliwe) → weryfikacja priorytetowa.
4. Ponowna certyfikacja praw: właściciele systemu potwierdzają/odrzucają prawa (kampanie przeglądu dostępu).
5. Sprawdzanie SoD pod kątem niezgodności i tymczasowych wyjątków (z datą wygaśnięcia).
6. Pojednanie JML: mapowanie wynajmu/przeniesienia/wyjścia na rzeczywiste prawa (w tym portale zewnętrzne).
7. Konta serwisowe: dostępność właściciela, krótkotrwałe żetony, brak „boskiego zakresu”.
8. Podstawa dowodowa: tworzenie pakietu artefaktów (raporty, przesyłki, akty).
9. Plan rekultywacji: bilety na wycofanie/korektę, terminy i osoby odpowiedzialne.
10. Raport końcowy: Status ryzyka, KPI cyklu, wyciągnięte wnioski i ulepszenia polityki.
7) Kontury JML (które sprawdzamy głębiej)
Stolarka: automatyczne przypisywanie ról podstawowych, zakaz ręcznych „dodatków” poza katalogiem.
Mover: zmiana polecenia/lokalizacji → automatyczna wymiana ról, cofnięcie starych uprawnień.
Dźwignia: cofnięcie wszystkich praw w ciągu X minut/godziny, zamknięcie poczty/VPN/portali dostawców, wyłączanie kluczy i żetonów.
8) Zewnętrzne zależności i portale
Dostawcy PSP/KYC/AML/CDN/WAF/gier: każde konto ma właściciela, cel, termin, MFA, zakaz wspólnych kont.
Kontraktowy SoD/SLA: dostępność podwójnej kontroli dla operacji P1 (zmiana trasy płatności, limity bonusowe itp.).
Regularne uzgadnianie: rejestr portali zewnętrznychspisu aktualnych użytkowników
9) Cechy domeny iGaming
Płatności i ryzyko: wybierz gałęzie SoD; aktualizacje dotyczące zmian limitów/tras; audyt korekt ręcznych.
Handel/czynniki: piaskownice do modelowania, indywidualne role wydawnicze, szybki zwrot; zmień dziennik.
Responsible Gaming/KYC/PII: ścisła kontrola eksportu, maskowanie w BI, przetwarzanie SLA żądań regulatora.
Partnerzy i streamerzy: ograniczone portale z możliwościami raportowania bez dostępu do PII.
10) Polityka jako kodeks (PaC)
Zasady w repozytorium (Rego/YAML), przegląd PR, testy.
Kontekst dynamiczny w rozwiązaniach pozwalających/zaprzeczających: środowisko (prod), czas, lokalizacja, krytyczność operacji, sygnały KRI (na przykład przepięcie wrażliwych działań).
Obowiązkowe powiązanie z biletem i celem promocji JIT.
11) Czasopisma i sprawdzalność
Łańcuch zdarzeń: admin console/IdP → API → bazy danych → dostawcy zewnętrzni.
Oczywiste manipulowanie: WORM/immutable-storages, podpis zapisów, ścisły TTL.
Wyszukiwanie i reagowanie: SLA odpowiedzi na wnioski wewnętrzne/zewnętrzne (audyt, organ regulacyjny, bank/partner).
12) Mierniki i KPI/KRI
KPI:- Udział potwierdzonych praw na czas (ponowna certyfikacja),% zaległych kampanii.
- Czas od zwolnienia do całkowitego cofnięcia praw (MTTR-dźwignia).
- Udział przyrostów JIT w uporczywych przywilejach.
- Liczba rozwiązywanych konfliktów SoD na cykl.
- Kompletność systemów krytych i zewnętrznych portali.
- Wrażliwe przyczepności działania (eksport PII, zmiany PSP).
- Niewykorzystane prawa> dni N.
- Złamane szkło bez kontroli.
- Konta bez właściciela/celu/terminu.
13) Plan realizacji (8-12 tygodni)
Ned. 1-2: wykaz tożsamości i systemów (w tym zewnętrznych portali), katalog ról i matryca SoD.
Ned. 3-4: Połączenie SSO/MFA wszędzie, pojedynczy zbiór uprawnień, pierwsze raporty migawkowe.
Ned. 5-6: uruchomienie kampanii rekertyfikacyjnych IGA (P1/P2 priorytet), automatyczne wycofanie Leaver.
Ned. 7-8: JIT/PAM dla obwodów produkcyjnych, sesje nagraniowe, zakaz wspólnych kont dostawców.
Ned. 9-10: PaC: formalizacja kluczowych polityk (eksport PII, routing PSP, wydania), testy jednostkowe polityk.
Ned. 11-12: Deski rozdzielcze KPI/KRI, regulacje kwartalnego cyklu, sprawozdawczość w odniesieniu do zgodności/regulatorów.
14) Wzory artefaktów
Katalog ról: rola, opis, minimalne uprawnienia, właściciel, aplikacja (lokator/region/środowisko).
SoD Matrix - niekompatybilne role/operacje, wyjątki, termin wyjątkowy i właściciel wyjątku.
Pakiet przeglądowy dostępu: arkusz potwierdzenia praw, komentarze, wynik (zatwierdzić/cofnąć/złagodzić).
Rejestr konta serwisowego: cel, właściciel, czas życia, zakresy, miejsce przechowywania tajemnic, harmonogram rotacji.
Zewnętrzne portale Inventory: system, kontakty, lista użytkowników, MFA, ostatnia data recertyfikacji.
Lista kontrolna dowodów: co przesyła/logi i w jakim formacie przechowywać do audytu.
15) Antypattery
Rachunki ogólne i „administrator na zawsze”.
Ręczna kwestia praw omijających IdP/IGA.
Brak tolerancji SoD lub „tymczasowych wyjątków” bez daty ważności.
Żetony serwisowe bez rotacji/właściciela.
Eksport PII „listownie” bez przepływu pracy i szyfrowania.
Brak audytu zewnętrznych portali (PSP/KYC/dostawcy gier).
16) Częste badania i szybka korekta
Zamrożony dostęp od zwolnionych/wykonawców: włącz automatyczne sprzężenie zwrotne na temat zdarzeń HR (Leaver).
Nadmiarowe role: rozkładają się do mniejszych ról i wiążą atrybuty ABAC.
Wspólne rachunki z dostawcami: migracja do osobistych + MSZ, wydawanie tymczasowych ról w rzadkich zadaniach.
Długotrwałe sekrety: przejście na krótkotrwałe tokeny/certyfikaty i planowana rotacja.
17) Zespół zarządzania incydentami
Każdy incydent z elementem dostępu → obowiązkowa aktualizacja rejestru zagrożeń i polityk, punkt ponownej certyfikacji poszkodowanych ról, pośmiertnie z pozycjami działań (i terminami).
Razem
Audyt tożsamości to cykl powtarzalny, zautomatyzowany: kompletny rejestr tożsamości i praw → rekertyfikacja zorientowana na ryzyko → twarde JML i JIT/PAM → polityki jako kod i udowodniony audyt → poprawa wyników cyklu. Ta pętla zmniejsza prawdopodobieństwo nadużyć i błędów, przyspiesza dochodzenia, wzmacnia zgodność i chroni kluczowe operacje biznesowe platform iGaming.