Zarządzanie tożsamością i dostępem

Krótkie podsumowanie

IAM to zbiór procesów, polityk i narzędzi, które zapewniają dostęp do tego, co, w jakich warunkach i w jaki sposób jest kontrolowane. Cele: zminimalizowanie zbędnych praw, zmniejszenie powierzchni ataku, przyspieszenie wejścia na pokład i audytu, zgodność (PCI DSS, RODO itp.) oraz wymierna niezawodność dostępu.

Podstawowe koncepcje

Tożsamość: osoba (pracownik, wykonawca), usługa/aplikacja, urządzenie.
Uwierzytelnianie (AuthN): kto sprawdza (hasło → MFA → schematy FIDO2/passkeys bez hasła).
Autoryzacja (AuthZ): decyzja „co jest dozwolone” (RBAC/ABAC/ReBAC, polityki).
Poświadczenia: hasła, klucze, tokeny, certyfikaty (mTLS).
Tajne zarządzanie: KMS/HSM/Skarbiec, obroty, krótki TTL, tajemnice dynamiczne.
Cykl życia: Joiner-Mover-Leaver (JML) - tworzenie, zmiana ról, przypomnienie.

Docelowa architektura IAM

Samoloty i role:

IdP (dostawca tożsamości): SSO, MFA, katalog, federacja (OIDC/SAML), polityka ryzyka.
PDP/PEP: decyzja/egzekwowanie - silnik polityczny (OPA/Cedar) + punkty aplikacji (bramki API, serwery proxy, siatka serwisowa).
Katalogi/HR System: Źródło prawdy przez pracownika i rola
Rezerwacja: SCIM/Automatyzacja do tworzenia/modyfikowania/cofania dostępu.
Audyt: scentralizowane dzienniki, UEBA, raporty dotyczące roli i dostępu.

Przepływ dostępu (użytkownik → aplikacja):

SSO (+ MFA) → token issue (OIDC/JWT/SAML) → PEP sprawdza token/kontekst → PDP decyduje o polityce (rola/atrybuty/ryzyko) → kwestie aplikacji/odmawia dostępu.

Uwierzytelnianie: od haseł do paszportów

Hasła: tylko z menedżerami haseł, co najmniej 12-14 znaków, bez rotacji „zgodnie z kalendarzem”, ale z obowiązkowym w przypadku incydentu.
Domyślne MSZ: TOTP/WebAuthn/Push; unikać SMS jako głównego czynnika.
Logowanie bez hasła: FIDO2/passkeys dla domen krytycznych.
Adaptive AuthN: Rozważyć sygnał ryzyka (geo, ASN, urządzenie, anomalie) → wymagają dodatkowego czynnika/bloku.

Autoryzacja: RBAC, ABAC, ReBAC

RBAC: role odpowiadające funkcjom (wsparcie, finanse, DevOp). Proste i zrozumiałe, ale „rosnące”.
ABAC: zasady dotyczące atrybutów (dział, poziom ryzyka, czas, strefa, etykiety zasobów). Skalowalne.
ReBAC: „kto należy do czego” relacje (właściciele projektów, członkowie zespołu). Wygodne dla scenariuszy dla wielu najemców.

Najlepsze praktyki:

Połączyć RBAC (siatkę bazową) + ABAC/ReBAC (kontekst/granice).
JIT (Just-In-Time): wydanie tymczasowych przywilejów poprzez żądanie/aplikację, automatyczne odwołanie.
JEA (Just-Enough Access): Minimalne wystarczające prawa do operacji.
PAM: odizolowane „silne” akcesoria (administratorzy DB/chmury) z brokerem sesyjnym, nagrywaniem ekranu/polecenia i wydawaniem krótkotrwałych kredytów.

Federacja i SSO

Protokoły: OIDC (żetony JWT), SAML 2. 0 (twierdzenia XML) - dla zewnętrznych dostawców/partnerów.
SSO: pojedynczy punkt wejścia z MFA, redukcja phishing, scentralizowane wycofanie.
B2B/B2C: federacja z partnerami, ograniczenie domeny, zasady oparte na domenie.
mTLS/m2m: w przypadku usług należy stosować krótkotrwałe x.509 (SPIFFE/SVID) lub OAuth2 poświadczenia klienta.

Cykl życia (JML) i zaopatrzenie

Joiner: automatyczne udostępnianie rachunków SCIM i podstawowych ról z HR/directory.
Mover: role zmieniają się automatycznie przez atrybuty (dział, projekt, lokalizacja).
Dźwignia: natychmiastowe wycofanie SSO, klawiszy, żetonów, repozytorium/chmura/CI/CD.
Procesy: żądania dostępu (ITSM), matryca SoD (podział obowiązków), okresowy przegląd dostępu.

Sekrety, klucze i obroty

KMS/HSM: Przechowywanie kluczy głównych/krytycznych, włączanie audytu operacji.
Menedżerowie skarbca/tajemnicy: kredyty dynamiczne (DB, chmury), auto-revok na zakończenie TTL.
Obroty: żetony OAuth, klucze do podpisywania JWT, hasła serwisowe - w harmonogramie i w przypadku incydentów.
mTLS: certyfikaty krótkotrwałe (godziny/dni), automatyczne ponowne uruchomienie.

Polityka i silnik rozwiązania

Deklaracja: Polityka sklepu w Git; sprawdź w CI (testy polityki).
Kontekst: czas/lokalizacja/ASN/poziom ryzyka/stan urządzenia (MDM/EDR).

Przykład (Rego, uproszczony):

rego package authz. payments default allow = false

allow {
input. user. role == "finance"
input. device. compliant == true input. action == "read"
input. resource. type == "report"
time. now_hh >= 8 time. now_hh <= 20
}

Monitorowanie, SLO i audyt

Metryka:

Sukces AuthN/AuthZ (%), czas logowania/podejmowania decyzji p95, udział wejść bez hasła/MFA.
Liczba eskalacji JIT/PAM, średni czas trwania przywileju.
Pokrycie urządzeń zgodnych, udział tajemnic krótkotrwałych.

SLO (przykłady):

Dostępność SSO/IdP ≥ 99. 95% miesięcznie.
p95 Decyzja w sprawie AuthZ ≤ 50 Д.
100% zamknięcia konta ≤ 15 minut po odłączeniu.
Audyt i UEBA: scentralizowane dzienniki niezmienne (dostęp, zmiany ról, nieudane wejścia, rozwiązania PDP), analityka behawioralna i alarmy anomalii.

Odpowiedź na incydent w IAM

Kompromis żetonów/kluczy: natychmiastowe odwołanie, wymuszone wylogowanie, rotacja kluczy podpisu, ponowne wydanie krótkotrwałych tajemnic.
Nadużycie praw: zawiesić konto, zablokować JIT/JEA, przeprowadzić przegląd dostępu sąsiadujących podmiotów.
IdP nie jest dostępny: tryby offline (tymczasowa walidacja pamięci podręcznej żetonów z krótkim TTL), procedury odzyskiwania priorytetów.
Phishing: obowiązkowe MFA, kontrole ryzyka sesji, powiadomienia użytkowników, szkolenia.

Chmury i kubernety (wzory)

Public Cloud IAM: używać rodzimych ról z najmniejszym przywilejem; zamiast „wiecznych” klawiszy - obciążenia pracą z federacją OIDC do chmury (IRSA/Workload Identity).
Kubernetes: RBAC według neimspaces/role, limit 'cluster-admin'; tajemnice - za pośrednictwem menedżerów zewnętrznych; siatka usługowa + OPA dla polityk L7; Kontrolery wstępu (podpisane obrazy, zakaz „: najnowsze”).
Bramki API: sprawdzanie JWT/mTLS, limitów stawek, podpisów żądania (HMAC) dla wrażliwych punktów końcowych.

Praktyka iGaming/fintech

Domeny dostępu: płatności, przeciwdziałanie oszustwom, PII, dostawcy treści - odizolować się od ról i segmentów sieci.
SoD: Nie łączyć sprzecznych ról (np. create promo + approve payments).
PAM i JIT: dostęp do PSP/banków i prod-DB - tylko za pośrednictwem brokera sesyjnego, z nagrywaniem i automatycznym odzyskiwaniem.
Zgodność: PCI DSS - MFA, minimalne uprawnienia, segmentacja strefy CHD; RODO - zasada minimalizacji danych i logów punktowych dostępu do PII.
Partnerzy i dostawcy treści: polityka federacyjna i polityka jednego najemcy; krótkotrwałe żetony i lista zezwoleń IP/ASN.

Częste błędy

„Wieczne” klucze i żetony: nie ma obrotów i TTL → wysokie ryzyko wycieków.
Ręczne offboarding: opóźnienia w cofnięciu praw → dostęp „duchowy”.
Role monolityczne: jedna „super rola” zamiast kompozycji i atrybutów.
MSZ tylko w panelu administracyjnym: MSZ powinny być dla wszystkich wejść i operacji krytycznych.
Dzienniki „do niczego”: nie ma centralizacji i UEBA → późniejsze wykrywanie incydentów.

Mapa drogowa wdrażania IAM

1. Spis użytkowników/usług/zasobów; mapa danych i wrażliwości.
2. SSO + MFA dla wszystkich, obejmują czynniki odporne na phishingi.
3. Model roli: podstawowe atrybuty RBAC + (ABAC) dla kontekstu; Matryca SoD.
4. Rezerwa SCIM: automatyczne tworzenie/zmiana/cofnięcie praw z HR/katalogu; aplikacje i aktualizacje w ITSM.
5. PAM i JIT/JEA: dla uprzywilejowanych dostępu; sesje nagraniowe, krótkie TTL.
6. Tajne zarządzanie: odrzucenie kluczy statycznych; sekrety dynamiczne, obroty, mTLS z krótkimi certyfikatami.
7. Zasady w Git + CI: testy reguł, kontrola zmian, wdrażanie zasad kanaryjskich.
8. Obserwowalność i SLO: deski rozdzielcze AuthN/AuthZ, wpisy, regularny przegląd dostępu.

Przykłady artefaktów

Polityka AWS IAM (minimum do czytania raportów S3)

json
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "ReadOnlyReports",
"Effect": "Allow",
"Action": ["s3:GetObject","s3:ListBucket"],
"Resource": [
"arn:aws:s3:::reports-bucket",
"arn:aws:s3:::reports-bucket/"
],
"Condition": {
"IpAddress": { "aws:SourceIp": "203. 0. 113. 0/24" }
}
}]
}

Kubernetes RBAC (twórca powierzchni nazw)

yaml apiVersion: rbac. authorization. k8s. io/v1 kind: Role metadata:
name: dev-read-write namespace: app-prod rules:
- apiGroups: ["","apps"]
resources: ["pods","deployments","services","configmaps"]
verbs: ["get","list","watch","create","update","patch","delete"]
apiVersion: rbac. authorization. k8s. io/v1 kind: RoleBinding metadata:
name: dev-bind namespace: app-prod subjects:
- kind: User name: alice@example. com roleRef:
kind: Role name: dev-read-write apiGroup: rbac. authorization. k8s. io

OIDC: zatwierdzenia ABAC (przykład)

json
{
"sub": "d81f0b5c-...",
"email": "bob@example. com",
"dept": "finance",
"role": "analyst",
"device_compliant": true,
"tenant": "casino-eu"
}

Polityka może wymagać dopasowania 'device _ compliant = true' i 'lokator' do zasobu.

Lista kontrolna

SSO jest włączony dla wszystkich aplikacji; MSZ domyślnie, passkeys w priorytecie.
Definicja RBAC; ABAC/ReBAC dodaje kontekst; wdrożony przez JIT/JEA.
PAM chroni dostęp uprzywilejowany; sesje są rejestrowane.
Rezerwa SCIM z HR; offboarding jest w pełni zautomatyzowany.
Sekrety są dynamiczne, z krótkim TTL; obroty są zautomatyzowane.
Polityka została zmieniona w Git, przetestowana w CI; są obliczenia kanaryjskie.
Deski rozdzielcze i SLO zgodnie z AuthN/AuthZ; scentralizowane dzienniki i UEBA.
Okresowy przegląd dostępu i kontrole SOD; sprawozdania dotyczące zgodności.

NAJCZĘŚCIEJ ZADAWANE PYTANIA

Czy ReBAC potrzebuje wszystkich?
Nie, nie jest. RBAC + ABAC jest wystarczający dla prostych środowisk. ReBAC jest przydatny w złożonej hierarchii własności zasobów i wielopoziomowości.

Mogę opuścić lokalne konta?
Tylko dla scenariuszy break-glass i offline, z surowymi ograniczeniami i okresową weryfikacją.

Jak zmniejszyć „eksplozję ról”?
Zwiększ ziarnistość zasobów, użyj ABAC/szablonów, zautomatyzuj opinie i odrzucaj niewykorzystane role.

Razem

Dojrzała architektura IAM to SSO + MFA, minimalne niezbędne prawa, zautomatyzowany JML, scentralizowana polityka i obserwowalność. Łącząc RBAC z atrybutami i modelami relacyjnymi, stosując JIT/JEA i PAM oraz automatyzując rezerwację i tajne obroty, uzyskujesz zarządzany, audytowalny i skalowalny dostęp, który spełnia wymagania bezpieczeństwa i biznesu.