Kontrola dostępu i RBAC w API

1) Dlaczego kontrola dostępu API

Autoryzacja jest odpowiedzią na pytanie "czy ten aktor może wykonać tę akcję na tym zasobie teraz? ». Błędy prowadzą do wycieków BOLA/IDOR, eskalacji praw i naruszenia wymogów regulacyjnych. Celem jest zbudowanie modelu wielopoziomowego: obwód → serwis mash → zasady biznesowe, z wyraźnymi zasadami i kontrolami na poziomie obiektu.

2) Modele autoryzacji: kiedy wybrać co

RBAC (Role-Based Access Control) - role → permissions. Prosty, stabilny, ale podatny na „eksplozję roli”.
ABAC (Atrybut-Based) - decyzja w sprawie atrybutów przedmiotu/obiektu/kontekstu (kraj, poziom KYC, właściciel zasobów, ryzyko).
ReBAC (Relationship-Based) - wykres relacji (właściciel, członek zespołu, „project manager”); rozwiązuje złożone hierarchie.
Scopes (OAuth) - umowa między klientem a serwerem zasobów o „obszarze dostępu” (na przykład, 'płatności: write').
Praktyka: RBAC dla macierzy podstawowej, ABAC dla kontekstu i ograniczeń, ReBAC dla hierarchii złożonych (foldery, organizacje, limity i podakonty).

3) Taksonomia zasobów i działań

Hierarchie: 'org → projekt → portfel → transakcja'. Dziedziczenie praw od góry do dołu z możliwymi „ograniczeniami”.
Działania: CRUD + specyficzne dla domeny („zatwierdzać”, „refundować”, „rozliczać”).
Właściwości zasobów: właściciel, region, status, znaczniki ryzyka (AML/KYC), limity.
Wielopoziomowość: wszystkie rozwiązania zawierają "najemca _ id'; odmówić domyślnie.

4) Architektura: w przypadku podjęcia decyzji

PEP (Policy Enforcement Point) - strona weryfikacyjna: gateway/API-gateway, side decar mash, service itself.
PDP (Policy Decision Point) - silnik polityczny: scentralizowany (OPA-service, Cedar-engine) lub wbudowana biblioteka.
PIP (Policy Information Point) - źródła atrybutów: użytkownik/katalog ról, profil najemcy, CCP/risk, mapa własności zasobów.
PAP (Policy Administration Point) - weryfikacja polityki, wydawnictwo, audyt.

Zalecenie: scentralizowany PDP + lokalny pamięć podręczna rozwiązania w PEP; złożone kontrole obiektów w usłudze w obecności niezmienników domeny.

5) Żetony, znaczki i tożsamość

OIDC/OAuth2: "sub" (identyfikator przedmiotu), "aud' (usługa docelowa)," zakres "/" role "," lokator "," kyc _ level "," risk _ tier ".
JWT: podpis RS/ES, krótki 'exp', ponowne zwolnienie przez odświeżenie. Nie umieszczaj PII; używać „jti” do odwołania/audytu ścieżki.
mTLS/HMAC: usługi i partnerzy; znaczki są pobierane z katalogu przez 'client _ id'.
Urządzenie/Kontekst: IP/ASN, geo, pora dnia - zaloguj się do rozwiązania ABAC (na przykład zabraniaj pisania poza godzinami pracy).

6) Autoryzacja poziomu obiektu (BOLA-first)

Każda operacja musi odpowiedzieć na pytanie „czy właściciel/ma prawo do tego 'resource _ id'?”.

Kontrola własności: 'resource. owner_id = = przedmiot. id' lub członkostwo w „org” z rolą.
Próbki filtrowania: zawsze nakładaj zasób 'WHERE'. tenant_id =: najemca AND... '(zabezpieczenie na poziomie wiersza).
Dla operacji referencyjnych (ID w ścieżce/korpusie) - normalizacja i walidacja logiki biznesowej.

7) RBAC Design: Role, uprawnienia, zestawy

Uprawnienia - prawa atomowe: "portfel. czytać „,” portfel. napisz ',' płatność. zwrot ".
Role - nazywane zestawy uprawnień: 'admin', 'support. czytać „,” kasjer „,” oszustwo. analityk '.

Zakresy - umowa zewnętrzna dla klientów (zakres → mapowanie uprawnień)

• role bazowe + pakiety zezwoleń,
• ograniczenia ABAC (kraj/region/najemca),
• „Dostęp w czasie”.

8) ABAC/ograniczenia kontekstowe

Geo/jurysdykcja: zakaz pisania z krajów objętych zakazem (sankcje/przepisy).
Czas/ryzyko: "risk _ score <threshold' dla dużych operacji.
ACC/wartości graniczne: 'kyc _ level> = 2' dla szpilek> X; kontrola „chłodzenia” między transakcjami.
„Zaufane urządzenia”: wymagają mTLS dla partnerów na niebezpiecznych trasach.

9) ReBAC i wykres praw

Przydatne dla złożonych struktur biznesowych (grupy, zespoły, marki, oddziały).

Relacje: 'członek', 'administrator', 'właściciel', 'widza'.
Prawa pochodne: „widza” zasobu odziedziczonego po „członku” projektu należącego do „org”.
Przechowywanie wykresu: baza danych z matrycą relacji, usługą specjalistyczną (w duchu podejścia Zanzibar). Odpowiedzi Cache 'check (temat, relacja, obiekt)'.

10) Pamięć podręczna rozwiązania i wydajność

Pamięć podręczna PDP na poziomie PEP (na przykład w bramce) z kluczem: „sub” najemca „zasobów” action „policy _ version”.
TTL krótki (sekundy-minuty) + niepełnosprawność według zdarzeń: rola/relacja/zmiana lokatora.
Kontrole partii (luzem autz) dla list: zmniejszyć opłaty PDP.
Pomiar rozwiązań dotyczących opóźnień; podczas degradacji - wdzięku-degradacji tylko do odczytu (nigdy do pisania/pieniężnego).

11) Przykłady polityk

11. 1 znaczki JWT → szorstki PEP (pseudo-brama)

yaml
- match: { prefix: "/api/v1/wallets" }
authz:
require:
- claim: "aud"
equals: "wallet-service"
- claim: "scope"
includes_any: ["wallet. read", "wallet. write"]
context:
tenant_from: "claim:tenant"

11. 2 OPA/Rego (ABAC + BOLA)

rego package authz

default allow = false

allow {
input. action == "wallet. read"
input. subject. tenant == input. resource. tenant some role role:= input. subject. roles[_]
role == "support. read"
}

allow {
input. action == "payment. refund"
input. subject. tenant == input. resource. tenant input. subject. kyc_level >= 2 input. subject. risk_tier <= 2 input. subject. id == input. resource. owner_id # BOLA
}

11. 3 Ograniczenie jurysdykcji (polityka odmowy listy)

rego deny[msg] {
input. action == "withdraw. create"
input. context. country in {"IR","KP","SY"}
msg:= "Jurisdiction not allowed"
}

11. 4 Polityka ReBAC (pseudo)

allow(subject, "wallet. write", wallet) --
related(subject, "member", wallet. project) ∧ related(subject, "admin", wallet. org)   ∧ wallet. tenant == subject. tenant.

12) Zarządzanie polityką i wersją

Weryfikacja polityki („policy _ version”) i kanaryjska dla niebezpiecznych zmian.
„Suchy bieg” (decyzje dotyczące suchego biegu/cienia) - dziennik „zezwalać/zaprzeczać” bez wpływu.
Katalog zasad i migracji: Kto zmienił kiedy i dlaczego; mapowanie zdarzeń.
Testy na negatywne scenariusze (przypadki zabronione) - wymagane w CI.

13) Obserwowalność i audyt

Dzienniki decyzji: 'trace _ id',' subject ',' lokator ',' action ',' resource _ id', 'result', 'policy _ version', powód niepowodzenia.
Metryki: 'authz _ decision _ latency', 'authz _ denied _ total {action}', udział prób BOLA, cache hit-rate.
Deski rozdzielcze: najlepsze awarie przez akcje/najemców, trendy po zwolnieniach polityki.

14) Bezpieczeństwo i zrównoważony rozwój

Odmowa domyślna: brak wyraźnego uprawnienia = odmowa.
Fail-closed: gdy plik PDP jest niedostępny, krytyczny zapis → zabroniony (lub zdegradowany do „minimalnego zestawu” ściśle zweryfikowanych ról).
Lokalne „kontrole strażnicze” w ramach usług dla stałych krytyków (na przykład „najemca ”/„ właściciel”).
Minimalizacja znaków charakterystycznych w JWT; ładowanie wrażliwych atrybutów za pośrednictwem PIP przez bezpieczny kanał.

15) Szczegóły dotyczące iGaming/Finance

Role: "kasjer", "kyc. agent ',' aml. oficer „,” oszustwo. analityk ',' vip. kierownik „,” ryzyko. admin '.
Ograniczenia: transakcje płatnicze zależą od „kyc _ level”, limitów odpowiedzialnych płatności, statusu AML/sankcji.
Rejestry blokad: 'org/brand/device/payment _ instrument' - filtry ABAC na zapisie.
dzienniki audytu niezmienione dla działań KYC/AML/pin; przechowywanie zgodnie z terminami regulacyjnymi.
Partnerskie interfejsy API: mTLS + kontrakt „zakresy” na trasach, filtry geo/ASN na obwodzie.

16) Badanie i weryfikacja

Matryca negatywna: wyświetl wyraźne „zakazane” przypadki i naprawić za pomocą testów.
Autoryzacja Fuzz: zastąpienie 'lokator _ id',' owner _ id', omijanie filtrów podczas paginowania/sortowania.
Test obciążenia PDP: Sprawdź opóźnienie i zachowanie pamięci podręcznej w p95/p99.
Wydanie polityki: dry-run + canary + auto-test z oczekiwaną odmową/zezwoleniem.
Incydenty: powtórzyć żądania na stoisku z dokładną wersją zasad.

17) Antypattery

Polegać tylko na „zakresie” bez kontroli przedmiotów (BOLA).
Łączenie logiki biznesowej i kontroli praw w każdym obsługującym bez scentralizowanego modelu.
Role hardcode w UI i zaufanie rozwiązań klienta.
Brak filtrów 'najemcy '/' właściciela' w żądaniach do bazy danych (wyciek odczytuje).
Nie ma rozwiązania pamięci podręcznej niepełnosprawność podczas zmiany ról/relacji.
Długotrwałe JWT bez pamięci/rotacji.

18) Lista kontrolna gotowości Prod

• Zdefiniowano zasoby/działania, hierarchie i wielopoziomowość.
• Podstawowa matryca RBAC + ograniczniki ABAC, w razie potrzeby - ReBAC.
• PDP/PEP zostały zaprojektowane; istnieje lokalny pamięć podręczna rozwiązania i jego niepełnosprawność.
• Polityki są wersjonowane, negatywne testy scenariusza w CI.
• Kontrole BOLA w każdym zapisie/odczytaniu do określonego "resource _ id'.
• JWT z minimalnymi znaczkami, krótkie „exp”; audyt/przypomnienie o „jti”.
• Mierniki/dzienniki decyzji, deski rozdzielcze, wpisy w drodze odmowy/opóźnienia.
• Nieudane dla pisma krytycznego; tryb awaryjny jest udokumentowany.
• Dokumentacja klienta: „zakresy”, kody błędów (401/403/404/409), przykłady.

19) TL; DR

Budowa autoryzacji BOLA-first: centralna pamięć podręczna PDP +, RBAC jako podstawa, ABAC dla kontekstu, ReBAC dla relacji. Wszystkie wnioski są w kontekście "najemcy" i konkretnego "resource _ id'; odmowa domyślnie, krótki JWT, filtry obiektów w bazie danych. Zasady wersji i testów, pomiar opóźnienia/zaprzeczenia, powtórki incydentów. iGaming - indywidualne role (KYC/AML/kasa), twarde ograniczenia ABAC i niezmienny audyt.