To jest specyfikacja docelowa (SPEC) cyklicznego przeglądu dostępów dla ipIII: kto ma jaką rolę, dlaczego, od kiedy i czy nadal powinien. Obejmuje break-glass (dostęp awaryjny), deprovisioning (odbieranie uprawnień) i eksport logu dostępu. Egzekwowanie (enforce) nie jest wdrożone na prod — dziś działa RBAC lokalny i audit log zapisu zdarzeń; cały mechanizm cyklicznego przeglądu i automatycznego odbierania dostępu poniżej jest oznaczony jako ROADMAP, zgodnie z doktryną claim ≤ proof.
Access review odpowiada na cztery pytania, które bank SIFI, regulator lub audytor zada jako pierwsze: kto ma dostęp i dlaczego (przegląd), co się dzieje w sytuacji awaryjnej (break-glass), jak szybko cofamy uprawnienia po odejściu/zmianie roli (deprovisioning) i czy da się to udowodnić (eksport logu). Dziś mamy surowe dane w audit logu — mechanizm przeglądu, alertowania i wymuszania jest zaprojektowany, ale niewdrożony.
Kolumna Status = priorytet domknięcia: P0 blokuje wdrożenie enterprise · P1 wymagane dla banku/partnera, nie blokuje pilota. Data weryfikacji: 2026-07-05.
| Element | Opis | Zależność | Status dziś | Priorytet |
|---|---|---|---|---|
| Cykliczny przegląd dostępów | Okresowy (np. kwartalny) przegląd: kto ma jaką rolę, czy uprawnienie jest nadal zasadne, kto potwierdza (właściciel zasobu / manager). | Wymaga listy ról z OIDC/IdP (mapowanie claims → role) jako źródła prawdy. | ROADMAP — brak harmonogramu, brak UI przeglądu, brak workflow potwierdzeń. | P0 |
| Break-glass (dostęp awaryjny) | Procedura tymczasowego podniesienia uprawnień w sytuacji incydentu, z obowiązkowym uzasadnieniem i automatycznym wygaśnięciem po czasie. | Wymaga audit logu zdarzenia użycia (dziś LIVE na poziomie zapisu) + mechanizmu wygasania tokenu (dziś brak TTL na podniesione uprawnienia). | ROADMAP — brak dedykowanej ścieżki break-glass; dziś podniesienie uprawnień to zwykła zmiana roli w RBAC, bez znacznika „awaryjne". | P0 |
| Deprovisioning | Automatyczne odebranie dostępu po odejściu z organizacji, zmianie roli lub upływie terminu współpracy (np. konsultant zewnętrzny). | Wymaga centralnego provisioningu z IdP (OIDC, faza F1, staging) — bez zewnętrznego źródła prawdy o statusie konta deprovisioning jest ręczny. | ROADMAP — dziś odebranie dostępu to ręczna zmiana rekordu użytkownika przez admina, bez automatycznego triggera ani SLA. | P1 |
| Eksport logu dostępu | Możliwość wyeksportowania pełnej historii zdarzeń dostępowych (logowania, zmiany ról, użycia break-glass) dla audytora lub regulatora. | Zależy od kompletności audit logu (dziś LIVE — zapis zdarzeń w PostgreSQL) + formatu eksportu. | ROADMAP — surowe dane są w bazie, ale nie ma dziś endpointu/eksportu w formacie gotowym dla audytora (CSV/JSON z podpisem integralności). | P1 |
LIVE Audit log — zapis zdarzeń (logowanie, zmiana ról, żądania API) w PostgreSQL.
LIVE RBAC lokalny — role i uprawnienia sprawdzane przy każdym żądaniu.
LIVE JWT wystawiany lokalnie (bez zewnętrznego IdP) — patrz znane ograniczenia.
ROADMAP OIDC / JWKS z zewnętrznym IdP (Keycloak) — faza F1, wyłącznie na staging, nie na prod.
ROADMAP Mapowanie ról z claims tokenu OIDC.
Szczegóły specyfikacji: /auth-enterprise.
ROADMAP Cykliczny przegląd, break-glass, deprovisioning, eksport logu — zero z tego nie jest wdrożone na prod ani staging. To jest wyłącznie specyfikacja (SPEC).
Powiązane: specyfikacja tożsamości enterprise (OIDC/mTLS) → /auth-enterprise · pełny rejestr znanych ograniczeń → /known-limitations · macierz statusów wszystkich elementów → /status-matrix.