RBAC: zarządzanie rolami i uprawnieniami

1) Cele i zasady RBAC

Cel: Zapewnienie możliwości zarządzania dostępem, jego zweryfikowalności i minimalnej objętości w celu ochrony pieniędzy/PII i zgodności (RODO/AML/PCI/ISO).
Zasady: najmniejszy przywilej· Need-to-Know· Separation of Duties (SoD)· Zero Trust· Cofalność (quick recall)· Auditability (provability).

2) Taksonomia praw i ról

• Dane: 'READ', 'WRITE', 'EXPORT', 'DELETE', 'MASKED_READ' (domyślnie dla PII).
• Operacje: „APPROVE_WITHDRAWAL”, „CHANGE_FRM_RULE”, „KYC_DECISION”, „SANCTIONS_OVERRIDE”.
• Admin: „ROLE_UPDATE”, „USER_PROVISION”, „SECRET_ROTATE”, „BREAK_GLASS”.
• Integracje: 'API_CALL:', 'WEBHOOK_SIGN', 'SERVICE_CONFIG_UPDATE'.

• Rdzeń (przekrojowe): „employee_basic”, „viewer_internal”, „auditor_privacy”.
• Domenowe: 'support_agent', 'vip_manager', 'payments_ops', 'aml_officer', 'kyc_operator', 'fraud_analyst', 'rg_specialist', 'bi_analyst'.
• System/te: 'devops_admin', 'dba_admin', 'service_account _', 'read_only_prod'.
• Uprzywilejowany (poprzez PAM/JIT): 'break_glass_admin', 'prod_db_jit_editor'.

3) Inżynieria roli

1. Wykaz zasobów: systemy/tabele/punkty końcowe, klasy danych (publiczne/wewnętrzne/poufne/ograniczone/ściśle ograniczone).
2. Historie użytkowników według funkcji: kto robi co i dlaczego (cel).
3. Mapowanie zadań → uprawnienia - minimalny zestaw na funkcję.
4. Grupowanie w roli: jedna rola = jedna dziedzina odpowiedzialności; unikać „super ról”.
5. Badanie SoD: sprawdzenie niezgodności (np. „pavements_ops',” „fraud_rule_admin”).
6. Pilot i pomiar: wydajemy tymczasowo ograniczoną grupę, zbieramy ścieżkę audytu.
7. Wersioning: Każda zmiana roli odbywa się za pośrednictwem CAB z changelogiem.

4) Interakcja RBAC i ABAC

RBAC odpowiada „kto w zasadzie może”, ABAC - „w jakich warunkach” (środowisko, geo, urządzenie/MDM, czas, poziom KYC, 'cel').
SoD zakazuje niebezpiecznych kombinacji ról i wymaga 4-oczu dla działań krytycznych.
Praktyka: domyślnie role dają MASKED_READ PII; niezaspokojony dostęp wymaga „celu” + atrybutu JIT i pozytywnej decyzji ABAC polityki.

5) Wielozadaniowość i kontekst geograficzny

Zakres działalności najemcy: Role związane są z dzierżawą/marką/jurysdykcją („rola: payments_ops @ EEA”).
Klucze geograficzne: poszczególne klucze szyfrujące i segmenty dostępu dla każdego regionu (EC/UK/...).
Granularność: filtrowanie według kolumny „region_code” (RLS) i według jurysdykcji gracza.

6) Bezpieczeństwo na poziomie wiersza/kolumny i maskowanie

• RLS (stringi): Dostęp tylko do rekordów kraju/marki/zespołu.
• CLS (kolumny): pola wrażliwe są dostępne maskowane; zdemaskowany - tylko z przywilejem 'pii_unmask' + 'purpose'.

sql
CREATE POLICY rls_tx
ON dwh. transactions
USING (region_code = current_setting('app. region'));

SELECT
CASE WHEN has_priv('pii_unmask') THEN email ELSE mask_email(email) END AS email_view
FROM dwh. users;

7) JIT, łamanie szkła - PAM - RBAC

JIT: tymczasowa uprzywilejowana rola (15-120 min) w ramach biletu; automatyczne sprzężenie zwrotne; pełny audyt.
Break-glass: dostęp awaryjny z MFA + drugie potwierdzenie i nagrywanie sesji; po przeglądzie z programem Security + DPO.
PAM: secret store, session proxy, password/key rotation.

8) Cykl życia ról (SOP)

SOP-1: Tworzenie/modyfikowanie roli

1. Zapytanie właściciela domeny → lista zadań → mapowanie uprawnień → SoD-check → pilot → CAB → wydanie + dokumentacja.

SOP-2: Żądanie i dostęp do dotacji

1. Wniosek (IDM/ITSM) z „celem” i terminem → SoD/jurysdykcja auto-weryfikacja → zatwierdzenie właściciela danych + Bezpieczeństwo (dla Restricted +) → wydanie (często JIT) → wpis w rejestrze.

SOP-3: Informacje zwrotne/Offboarding

Wyzwalacze: Zakończenie, zmiana roli, bezczynność> 30/60 dni, JIT wygasła.
Automatyczne wycofywanie i rejestrowanie.

SOP-4: Ponowna certyfikacja

Co kwartał właściciele potwierdzają, że role użytkowników są nadal potrzebne; system usuwa prawa „wiszące”.

9) Przykład matrycy ról (fragment)

10) Narzędzia i wdrażanie (wzory)

Katalog ról jako kod: YAML/JSON w repozytorium + walidatory CI, changelog.
Centralny IdP/SSO: rezerwa SCIM, mapy grupowe 'grupa → rola'.
Punkt decyzji politycznej: silnik polityki (ABAC) z atrybutami kontekstowymi.
Sekrety/KMS: izolacja kluczy od środowiska/regionu/najemcy.
Brama danych: pojedyncza warstwa maskowania/audytu dla DWH/BI/eksportu.
SIEM/SOAR: korelacja 'ROLE_UPDATE'/'READ_PII'/'EXPORT_DATA', auto-bilety.

11) Audyt i pozyskiwanie drewna

Obowiązkowe zdarzeń: "ROLE_ASSIGN'," ROLE_REVOKE "," ROLE_UPDATE "," BREAK_GLASS "," JIT_GRANT "," READ_PII "," EXPORT_DATA "," PAYMENT_ZATWIERDZAĆ "," KYC_DECISION ".
Wymagania: kopia WORM, łańcuchy hash, podpis pakietu, 'cel'/'ticket_id' w każdym zdarzeniu, synchronizacja czasu.

12) Mierniki i KPI/KRI

Zasięg:% systemów w RBAC ≥ 95%.
Naruszenie SoD: = 0; próby przypisania niekompatybilnych ról - auto-blok.
Wskaźnik JIT: ≥ 80% podwyżek to JIT.
Offboarding TTR: cofnięcie praw ≤ 15 min.
Maskowany stosunek odczytu: ≥ 95% wywołań do PII jest zamaskowanych.
Recertyfikacja: 100% role potwierdzone kwartalnie.
Eksport podpisany: 100% eksportu z podpisem/dziennikiem.

13) RACI (rozszerzony)

14) Listy kontrolne

Przed utworzeniem roli

• Opisane historie użytkowników i „cel”
• Wykaz zasobów i klas danych
• Minimalne mapowanie uprawnień
• Kontrola SoD/konflikty
• Polityka maskowania i RLS/CLS
• Plan ponownej certyfikacji i właściciele

Przed udzieleniem dostępu

• Stałe „przeznaczenie” i data
• SoD/jurysdykcje/MDM/MSZ zakończone
• Domyślne maskowanie, JIT na promocji
• Dziennik i data zmiany zawarte

15) Częste błędy i anty-wzory

„Super role” z szerokimi prawami zamiast małych domen.
Bezpośredni dostęp do PII bez maskowania i „celu”.
Brak SoD/czwarte oczy dla „PAYMENT_APPROVE ”/„ KYC_APPROVE”.
Przedłużenie czasowych praw „na zawsze”.
Kopiuj dane prod do dev/stage.
Nieprzezroczysty eksport bez podpisu i dziennika.

16) Plan działania w zakresie wdrażania

Tygodnie 1-2: inwentaryzacja aktywów/klasyfikacja danych; projekt macierzy ról; Stół SoD.
Tygodnie 3-4: RBAC jako kod (repozytorium), grupy IdP/SCIM, silnik ABAC (podstawowe cechy: środowisko/geo/MDM/czas), JIT/PAM, warstwa maskująca dla DWH/BI.
Miesiąc 2: ponowna certyfikacja, automatyka offboardowa, wpisy SOAR dla naruszeń RBAC/SoD/ABAC, dzienniki eksportowe/WORM.
Miesiąc 3 +: rozszerzenie atrybutu (ryzyko urządzenia, poziom KYC), audyty uprzedzeń dostępu, optymalizacja kosztów i regularne ćwiczenia tablopowe.

TL; DR

Strong RBAC = małe role domeny + warunki atrybutów (ABAC) + SoD i maskowanie JIT/PAM + oraz RLS/CLS + audyt twardy i ponowna certyfikacja. Zmniejsza to ryzyko wycieków/nadużyć, przyspiesza audyt i utrzymuje platformę w granicach wymogów dotyczących prywatności i zgodności.