Segmentacja przywilejów

1) Dlaczego segmentacja jest potrzebna

Segmentacja przywilejów jest kluczem do zmniejszenia błędów „blast promieni” i nadużyć poufnych. Pozwala dokładnie ograniczyć, kto może wykonywać działania na jakich danych i gdzie, zachowując szybkość operacji i zgodność z wymogami regulacyjnymi.

• mniejsza liczba incydentów spowodowanych „zbędnymi prawami”;
• przyspieszenie dochodzeń: dostęp jest przejrzysty i wyraźny;
• zgodność z SoD/zgodność, udowodniony audyt;
• bezpieczne eksperymenty i szybkie uwolnienia bez ryzyka dla rdzenia produkcyjnego.

2) Zasady

Zero Trust: każda akcja jest sprawdzana kontekstowo; żadnych „zaufanych stref”.
Najmniejszy przywilej: minimalne prawa wydane na minimalny okres (najlepiej JIT).
Kontekst nad rolą: prawa zależą nie tylko od roli, ale także od atrybutów (najemca, region, środowisko, ryzyko).
Segregacja obowiązków (SoD): oddzielne inicjowanie, zatwierdzanie, wykonywanie i audyt.
Policy-as-Code: zasady w kodzie z wersioning, testy i recenzje.

3) Model dojrzałości dostępu

1. RBAC (role) - start - role stałe (wsparcie, ryzyko, płatności, handel, operacje, SRE, zgodność).
2. ABAC (atrybuty): dodać atrybuty: najemca, region, jurysdykcja, produkt, kanał, środowisko (prod/stage/dev), czas, klasa ryzyka działania, sygnały KRI.
3. PBAC (oparte na zasadach): scentralizowane zasady „who/what/where/when/why” + conditions (na przykład, „in sales - only by JIT and with a ticket”).

4) Domeny segmentacji (oś według osi)

4. 1 Najemca/klient

Dostęp i operacje są ograniczone do konkretnej marki/operatora/partnera.
Zabrania się prowadzenia działalności w odniesieniu do najemców wzajemnych z wyjątkiem ściśle określonych agregacji niezwiązanych z PII.

4. 2 Region/jurysdykcja

Zasady uwzględniają lokalne zasady licencjonowania i KYC/AML.
Operacje danych gracza są ograniczone przez geografię przechowywania i przetwarzania.

4. 3 Środowisko (dev/stage/prod)

Prod jest odizolowany: pojedyncze kredyty, sieci, Bastion/PAM, „domyślnie tylko do odczytu”.
Dostęp do prod tylko JIT, z biletem i zmienić okna.

4. 4 Klasa danych

PII/finance/gaming telemetry/technologowie - różne poziomy dostępu i maskowania.
Eksport PII - tylko poprzez zatwierdzone zaszyfrowane przepływy pracy i TTL.

4. 5 Krytyczność operacji

P1/P2/P3 klasy: publikacja współczynników, ręczne offsety, wnioski, zmiana routingu PSP - wymagają podwójnej kontroli.
Działania niskiego ryzyka mogą być automatycznie zniesione przez politykę.

5) Poziomy uprzywilejowania (poziomy dokładności)

Przeglądarka: tylko do odczytu agregaty i zamaskowane dane.
Operator - Wykonaj procedury runbooka bez zmiany konfiguracji.
Contributor-Modyfikuje konfiguracje w domenach innych niż krytyczne.
Approver: zatwierdzenie zastosowań i operacji wysokiego ryzyka (niepołączonych z wykonaniem - SoD).
Admin (JIT): krótkoterminowa promocja rzadkich zadań pod podwójną kontrolą i nagrywaniem sesji.

6) SoD i niekompatybilne role

• Zainicjować konkluzje „zgodzić się na sfinalizowanie”.
• Utwórz kampanię bonusowąuaktywnij w limitach sprzedaży.
• Rozwinąć funkcję i nałożyć na prod wydruk.
• Poproś o przesłanie PII

Dla każdej pary - sformalizowana polityka zakazu i wykluczenia z datą rewizji.

7) Dostęp do JIT i PAM

Wysokość na życzenie: określić cel/bilet/termin; po wygaśnięciu - auto-recall.
Podwójna kontrola: P1/P2 działania - dwie aplikacje z różnych funkcji.
Kontrola sesji: nagrywanie sesji krytycznych, wpisy anomalii, zakaz kopiowania pasty podczas pracy z PII.
Break-glass: dostęp awaryjny z twardymi limitami i obowiązkowym po audycie.

8) Rachunki usług i zakresy API

Minimalne zakresy; Zadanie/partycja mikroservice krótkotrwałe żetony/certyfikaty.
Rotacja tajemnic, zakaz wspólnych tajemnic; zakaz „boskiego zasięgu”.
Limity stawek/kwot, klucze idempotencji, podpis haka (HMAC).

9) Segmentacja poziomu infrastruktury

Sieci: izolacja segmentu (per-domain/per-najemca), domyślny hamulec wyjścia, mTLS.
Kubernetes/Cloud: obszary nazw/projekty per-environment i domena, Gatekeeper/OPA w celu zakazania niebezpiecznych wzorów.
DB/Caches: broker dostępu (DB proxy/IAM), domyślnie tylko do odczytu, DDL zabrania sprzedaży poza oknem.
Repozytoria: różne klucze/wiadra dla poszczególnych klas danych z zasadami TTL i WORM do audytu.

10) Polityka jako kodeks (PaC)

Zasady w repozytoriach (Rego/YAML), przegląd PR, testy automatyczne (unit/e2e), audyt diff.
Kontekst dynamiczny: pora dnia, lokalizacja, poziom KRI, ocena ryzyka operacji.
Wyjaśnienie decyzji o zezwoleniu/odmowie oraz odniesienie do polityki w zakresie audytu.

11) Dzienniki i audyt

Kompletność: kto/co/gdzie/kiedy/dlaczego, wartości przed/post, identyfikator biletu.
Niezmienne: scentralizowana kolekcja, WORM/immutable, podpisywanie rekordów.
Łączność: łańcuch konsoli administratora → API → bazy danych → dostawcy zewnętrzni.
SLA audytu: stopień odpowiedzi na wnioski dotyczące kontroli/organów regulacyjnych.

12) Deski rozdzielcze i mierniki (KPI/KRI)

Dostęp KPI: udział JIT vs stałe prawa, średni czas trwania przywileju,% objęte SoD, czas przetwarzania aplikacji, pokrycie rekertyfikacji.
KRI nadużyć: wybuchy wrażliwych operacji, rozładunek masy, nietypowe lokalizacje/godziny, „zayavka → deystviye → otkat” sekwencje.
Exec-dashboard: status toru ról wysokiego ryzyka, zdarzenia ze szkła łamanego, trendy.

13) Przykłady polityk (szkice)

Prod-оверавий: „zezwolić, jeśli rola w {Operator, Admin} I = prod AND jit = true AND ticket! = null AND sod_ok AND TIME in اWindow”.
Мкскора PII: „zezwolić, jeśli I przeznaczenie w celach I ttl <= 7d ORAZ szyfrowanie = ON I zatwierdza> = 2”.
PSP-роктин, "zezwolić, jeśli akcja = Aktualizacja Routing I dual_control ORAZ risk_assessment_passed I rollback_plan_attached'.

14) Plan realizacji (8-12 tygodni)

Ned. 1-2: Działanie/Rola/Inwentaryzacja danych, Matryca SoD, Klasyfikacja danych i domeny segmentacji.
Ned. 3-4: podstawa RBAC, katalog ról, JIT dla konsoli produkcyjnych, początek PaC (OPA/Gatekeeper).
Ned. 5-6: ABAC: najemca/region/środowisko/atrybuty klasy danych; oddzielenie przestrzeni nazw/projektów.
Ned. 7-8: PAM (JIT-elevation, session recording, break-glass), DDL prohibition and database broker, polityka eksportowa PII.
Ned. 9-10: PBAC dla operacji wysokiego ryzyka (wnioski, premie, PSP), podwójna kontrola, wpisy KRI.
Ned. 11-12: Kwartalna recertyfikacja, 100% pokrycie wysokiego ryzyka operacjami PaC, sprawozdawczość i szkolenia.

15) Artefakty

Katalog ról: role, minimalne uprawnienia, właściciele.
SoD Matrix: niekompatybilne role/operacje, wyjątki, proces nadrzędny.
Pakiet zasad: zestaw zasad PaC z testami i przykładami odmawiają/zezwalają.
Formularz żądania dostępu: cel, termin, obiekt (lokator/region/środowisko), ocena ryzyka, aplikacje.
Delikatny rejestr operacyjny: lista P1/P2 działań, okna, podwójne kryteria kontroli.
Audyt Playbook: zbieranie i dostarczanie dzienników, odpowiedź SLA, role.

16) Antypattery

Stałe prawa administratora i rachunki ogólne.
Cross-najemca dostęp „dla wygody”.
Brak izolacji prod/etap/dev.
Zasady na papierze bez egzekwowania kodu/konsoli.
Eksport PII ręcznie bez szyfrowania i TTL.
Brak ponownej certyfikacji i prawa do zawieszenia.

17) Sedno sprawy

Segmentacja przywilejów to nie tylko "właściwe role. "Jest to wielowymiarowa izolacja (najemca, region, środowisko, dane, krytyka) + kontekst dynamiczny (ABAC/PBAC) + procesy (SoD, JIT, recertyfikacja) + przymus techniczny (PaC, PAM, sieci/DB). Ta pętla drastycznie zmniejsza ryzyko błędu i nadużyć, przyspiesza bezpieczne zmiany i sprawia, że platforma jest odporna na wymagania dotyczące skali i regulacji.