Zarządzanie tożsamością

1) Cele i obowiązki IGA

IGA - zarządza, kto ma jaki dostęp, dlaczego, ile i jak to udowodnić.
Cele: minimalne prawa (najmniejszy przywilej), brak dostępu „osieroconych”, kontrola SoD, weryfikacja regulacyjna (RODO/ISO/AML/PCI, jeżeli ma zastosowanie), szybkie przyznawanie/cofanie praw.

• Personel: personel, wykonawcy, tymczasowo.
• B2B/vendors/affiliates: użytkownicy zewnętrzni/integracje.
• Konta serwisowe/bot: API/integracja, maszyny.
• Wysokie ryzyko: administratorzy, płatności, AML/KYC, DPO, DevOps/SRE.
• (Op.) CIAM: gracze - w oddzielnym systemie; role i granice integracji są ustalane w IGA.

2) Architektura i źródła prawdy

Źródło autorytatywne: system HRIS/HR (dla personelu) + rejestr sprzedawcy (dla zewnętrznego).

IdP/SSO: OIDC/SAML, grupy

Rdzeń IGA: katalog uprawnień, zasady SoD, żądania przepływu pracy, kampanie ponownej certyfikacji, raporty.
Zasilanie: złącza do systemów docelowych (panele administracyjne, DWH/BI, KYC/AML, PSP, Git/CI, Jira/Confluence, chmura, K8).
Magazyn tożsamości/metadane: agregacja atrybutów (dział, rola, region, poziom zaufania, typ pracownika).
PAM/JIT: Na uprzywilejowane sesje i krótkoterminowe podwyżki.

3) JML - cykl życia tożsamości

Stolarka (na pokładzie)

Tworzenie konta z HRIS → przypisywanie ról rodowitych (SSO, mail, podstawowe narzędzia).
Role domeny według pozycji/polecenia/lokalizacji/najemcy; Podstawowa kontrola SoD.
MSZ/WebAuthn, menedżer haseł, szkolenia.

Mover

Automatyczna zmiana praw przy zmianie pozycji/projektu/lokalizacji; usunięcie starych ról (brak akumulacji).
Aktualizacja wyceny SoD, aktualizacja atrybutów ABAC (region/najemca), szablony JIT.

Dźwignia (offboarding)

Blokowanie SSO ≤ 15 minut, odwoływanie żetonów/kluczy API, zamykanie sesji, odwoływanie dostępu do DWH/administratorów, przenoszenie własności artefaktów, usuwanie/archiwizowanie według zasad.

4) Katalog praw i model roli

Katalog uprawnień: prawa normalizowane (CRUD/operations/exports/admin), właściciel, poziom ryzyka, system, konflikty SoD, domyślne maskowanie PII.

• Rdzeń: 'employee _ basic', 'viewer _ internal'.
• Моменна: 'payments _ ops',' aml _ officer ',' kyc _ operator ',' fraud _ analyst ',' vip _ manager ',' bi _ analyst '.
• System: 'devops _ admin', 'dba _ admin', 'read _ only _ prod'.
• Uprzywilejowany (JIT/PAM): 'prod _ db _ jit _ editor', 'break _ glass _ admin'.
• Role jako kod: YAML/JSON w repozytorium + walidatory CI + changelog CAB.

yaml role: payments_ops@EEA description: "EEA payment transactions"
entitlements:
- FIN:APPROVE_WITHDRAWAL
- FIN:VIEW_TX_MASKED constraints:
region: EEA data_class: <= Confidential sod_conflicts:
- FRAUD:RULE_ADMIN masking: default owner: head_of_payments

5) Wnioski o dostęp i zatwierdzenie (przepływ pracy)

Portal IDM/ITSM: wymaganie z „przeznaczeniem”, określenie (TTL), systemy/role.

• Niskie ryzyko: auto-zatwierdzenie przez właściciela domeny.
• Wysokie ryzyko/PII/pieniądze: właściciel + Bezpieczeństwo/Zgodność (+ DPO w PII demask).
• JIT na wysokość (15-120 min), automatyczne wycofanie, pełne nagrywanie sesji (PAM).
• SoD sprawdza synchronicznie, blokuje sprzeczne kombinacje.

6) SoD i ABAC w IGA

Zasady SoD: niekompatybilne role/prawe pary (np. „pavements _ ops',” „fraud _ rule _ admin”).
Atrybuty ABAC: środowisko (prod/stage), region/najemca, urządzenie (MDM), czas/zmiana, ryzyko urządzenia, poziom KYC, „cel”.
Policy unmask: 'pii _ unmask' JIT tylko + potwierdzenie + pola audytu.

7) Ponowna certyfikacja i kampanie

Opinie kwartalne: Właściciele potwierdzają dostęp pracownika/sprzedawcy.
Kampanie eventowe: w przypadku reorganizacji, zmiany właściciela systemu, wycofania produktu.
Automatyczne odzyskiwanie „wiszących” praw (niewykorzystane> 30/60 dni).

8) Sprzedawcy i tożsamości zewnętrzne (B2B)

Oddzielny najemca B2B, nazwane konta, minimalne zakresy API, lista IP, okna czasowe.
DPA/SLA: role, czasopisma, retencja, geografia, incydenty, sub-procesory.
Offboarding: odzyskanie klucza, potwierdzenie usunięcia, akt zamknięcia.

9) Konta serwisowe/bot i tajemnice

Rejestracja IGA u właściciela/cel/termin, brak logowania; uwierzytelnianie za pomocą mTLS/OIDC client-creds/signed webhooks.
Klucze w tajnym menedżerze; rotacja według harmonogramu/zdarzenia; dziennik połączeń.

10) Dzienniki, audyt i sprawozdawczość

Овебателкна собтий: „ACCOUNT _ PROVISION/DEPROVISION”, „ROLE _ ASSIGN/REVOKE/UPDATE”, „ACCESS _ REQUEST/APPROVE/DENY”, „JIT _ GRANT”, „BREAK _ SZKŁO”, „SOD _ BLOCK”, „RECERT _ START/END”, „EXPORT _ DATA”, „PII _ UNMASK”.

Kopia WORM, łańcuchy hash, podpis pakietu, 'ts _ utc'/' trace _ id'/' actor _ id'/' purpose'.
Raporty: ponowna certyfikacja, naruszenia SoD, osierocony dostęp, SLA JML, statystyki JIT.

11) Wskaźniki (KPI/KRI)

Czas do dostarczenia (łącznik): mediana ≤ 2 godziny (systemy kluczowe).
Czas do deprowizji (dźwignia): ≤ 15 min (SSO/krytyczny), ≤ 4 h (wtórny).
Naruszenia SoD: = 0 (próby - auto-blok).
Zakończenie ponownej certyfikacji: 100% na czas.
Konta osierocone: = 0; Uśpione oczyszczanie dostępu ≥ 98 %/24 ° C.
Wskaźnik JIT: ≥ 80% podwyższeń - JIT.
Maskowany stosunek odczytu: ≥ 95% połączeń do PII jest zamaskowanych.

12) SOP (procedury)

12. 1 Tworzenie/modyfikowanie katalogu praw

1. Zapytanie właściciela domeny → formalizacja zadań → mapowanie na uprawnieniach → SoD-check → pilot → CAB → wydanie (YAML) → ogłoszenie.

12. 2 Wniosek o dostęp

1. Zapytanie z 'purpose '/TTL → SoD/ABAC check → route of approvals → issue (often masked-read) → logging → revision date.

12. 3 Wsiadanie poza pokład

1. Wydarzenie z HRIS/Portal → SSO Block/Sesje → Grupa/Rola/Key Recall → Transfer własności → Raport.

12. 4 Ponowna certyfikacja

1. Start → kampania dunning → escalate overdue → auto-recall niepotwierdzone prawa → raport.

13) Przykłady polityki (snippets)

13. 1 Birthright - SoD

yaml birthright:
roles:
- employee_basic
- viewer_internal sod:
conflicts:
- [payments_ops, fraud_rule_admin]
- [kyc_operator, support_agent]

13. 2 Zasady JIT

yaml jit:
roles:
- prod_db_jit_editor
- pii_unmasker ttl_minutes: 30 approvals:
- owner
- security session_recording: required

13. 3 Kampania ponownej certyfikacji

yaml recertification:
frequency: quarterly scope: [payments_ops, aml_officer, devops_admin]
auto_revoke_unused_days: 60

14) Bezpieczeństwo i zgodność

RODO/Prywatność: Need-to-Know, maskowanie, kompatybilność DSAR, audyt PII.
AML/KYC: role tylko dla przeszkolonych; dziennik decyzji, retension kłód.
ISO/ISMS: obowiązkowa polityka IGA; roczne audyty, ćwiczenia testowe.
PWZ (w stosownych przypadkach): segregacja strefy płatności; oddzielne klucze i hosting.

15) incydenty IGA (szybkie odtwarzanie)

Dostęp wykryty bez „celu ”/naruszenia SOD → blokowanie roli/konta, otwarcie incydentu, retro audyt działań, DPO/zgłoszenie zgodności, CAPA (rola/polityka/edycje szkoleń).
Kompromitacja konta → odwoływanie sesji/żetonów, zmiana tajemnic, analiza dzienników, powiadamianie w razie potrzeby.

16) Listy kontrolne

Przed udzieleniem dostępu

• Określone 'purpose' i TTL
• Sprawdzono SoD/jurysdykcje/klasę danych
• Włączone maskowanie/ABAC
• Otrzymane zatwierdzenia (właściciel/bezpieczeństwo)
• Rejestry i data rewizji

Kwartalny

• 100% ponownej certyfikacji roli
• Automatyczne cofnięcie niewykorzystanych praw
• Weryfikacja rachunków B2B/vendor
• Rotacja klucza konta usługi

17) Plan działania w zakresie wdrażania

Tygodnie 1-2: inwentaryzacja systemów, połączenie HRIS/IdP, podstawowe role urodzinowe, katalog praw, matryca SoD.
Tygodnie 3-4: rezerwa SCIM, portal aplikacji, JIT/PAM, repozytorium roli YAML, pierwsze kampanie ponownej certyfikacji.
Miesiąc 2: rozszerzenie złącza (KYC/AML/PSP/DWH), atrybuty ABAC (region/MDM/czas), raportowanie i KRI.
Miesiąc 3 +: automatyzacja analiz SoD, rola górnictwo/zalecenia, sygnały UEBA, regularne ćwiczenia i audyty sprzedawcy.

TL; DR

Skuteczna IGA = HRIS → IdP → IGA - yadro → provizhening, role/prawa jako kod, JML z szybkim offboarding, SoD + ABAC, JIT/PAM dla przywilejów, ponownej certyfikacji i rygorystycznego audytu. Rezultatem jest mniejsze ryzyko i koszty, szybszy dostęp, większa zgodność i przejrzystość.