Silnik ról

1) Modele autoryzacji

RBAC (Role-Based Access Control): obiekt otrzymuje role, role są związane z uprawnieniami. Wystarczy zarządzać, dobre dla typowych obowiązków.
ABAC (Atrybut-based Access Control) - rozwiązanie zależy od atrybutów przedmiotu, zasobów, działania i środowiska (czas, IP, region, ryzyko). Elastyczne i skalowalne do złożonych zasad.
Hybryda RBAC + ABAC: role dają „podstawową” zdolność, atrybuty ją zawężają (warunki).
(nieobowiązkowo) ReBAC/Zależność: wykres relacji (właściciel, członek zespołu, delegat), przydatny w dokumentach i orgach.

2) Architektura: PDP/PEP i przepływy

PEP (Policy Enforcement Point): gdzie zastosowane jest rozwiązanie (brama API, metoda backend, warstwa SQL, interfejs użytkownika).
PDP (Policy Decision Point): usługa/biblioteka, która oblicza 'PERMIT/DENY' według zasad i atrybutów.
PIP (Policy Information Point): źródła atrybutów (IdP/profil, metadane zasobów, wskaźnik ryzyka, geo).
PAP (Policy Administration Point) - interfejs administracyjny/repozytorium polityki (wersje, projekty, publikacja).

Przepływ: PEP → żądanie tworzy kontekst → PDP wyciąga brakujące atrybuty (przez PIP) → oblicza decyzję → PEP ma zastosowanie (włącz/wyłączyć/odciąć pola) → audyt.

3) Model danych

• „subject” (użytkownik/serwis) α атриктава: 'tenant _ id',' roles ',' departamenty ',' risk _ level ',' mfa _ verified ',' scopes ',' claims '.
• „resource” z rodzaju i atrybutów: „type”, „owner _ id”, „tenant _ id',” classification „(public/confidential),” region „,” tags'.
• „działanie”: „odczytać”, „zapisać”, „usunąć”, „eksportować”, „zatwierdzić”, „impersonować”, „zdjąć”. п.
• "wironment": "czas", "ip", "urządzenie", "geo", "auth _ strength", "business _ context" (okанаα, тари, ").

• „roles (id, tenant_id, name, inherits [])” - wsparcie hierarchii i wzorców.
• „permissions (id, resource_type, action, constraint?)”.
• „role _ permissions (role_id, permission_id)”.
• „zadania (subject_id, role_id, zakres)” - zakres: globalny/w podziale na projekty/obiekty.

• „policy (id, effect = allow 'deny, target: {subject, resource, action}, condition: expr, priority, version, status)”.

4) Zasady podejmowania decyzji

Odmowa-nadrzędności: Wyraźne zakazy ustalają priorytety uprawnień.
Najmniejszy przywilej (PoLP): Wydaj minimalny wymagany dostęp, rozwiń poprzez warunki.
Rozdzielenie obowiązków (SoD): zakaz kombinacji ról/działań (na przykład „utworzona płatność” i „aresztowana”).
Świadomość kontekstu: Wzmocnienie wymogów o wyższym ryzyku (brak pomocy makrofinansowej, podejrzane IP).
Determinizm: ten sam kontekst → ta sama odpowiedź; Zaloguj wersję zasad.

5) Schematy wdrażania

5. 1 Hybrydowy RBAC → ABAC (kondycjonowanie)

yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5. 2 wiersze/bezpieczeństwo na poziomie pola

Na poziomie bazy danych: zasady RLS (przez 'lokator _ id',' owner _ id').
Na poziomie API: kolekcje filtrów i pola maski, jeśli nie ma 'allow: read_sensitive_fields'.

5. 3 Rozwiązania stopniowe

allow if action == "export" and subject. mfa_verified == true else deny

5. 4 Tolerancje tymczasowe

Dotacje z TTL: "przydział. expires_at', dostęp do „okien” (w godzinach pracy regionu zasobów).

6) Wydajność i buforowanie

Pamięć podręczna decyzji według klucza „(subject_hash, resource_key, działanie, policy_version)” z krótkim TTL.
Pamięć podręczna krawędzi atrybutów przedmiotu (oświadczenia w tokenie) + leniwe atrybuty zasobów fetch.
Unieważnienie przyrostowe: niepełnosprawność według zdarzeń (zmiana roli, zmiana polityki, transfer zasobów do „poufnego”).
Sprawdzanie partii: dla list - ocenić za pomocą „filtra” (policy-predict pushdown), aby nie ciągnąć linii PDP po linii.

7) Multi-najemca

W każdej tabeli - 'lokator _ id'; domyślne zasady ograniczają dostęp w ramach leasingu.
Administratorzy dzierżawy zarządzają tylko rolami/prawami ich dzierżawy.
Dostęp do leasingu krzyżowego - wyłącznie poprzez wyraźne zaproszenia/udostępnianie z wyraźnym zakwestionowaniem.

8) Zarządzanie polityką i cykl życia

Wersioning: "polityka. wersja "w odpowiedzi PDP, przechowywać w audycie.
Środowiska: projekt → kanaryjski (części ruchu/trybu cienia) → prod.
Matryca testowa: tabele prawdy według ról/atrybutów kluczowych (testy kontraktowe).
Zarządzanie zmianami: Łączenie wniosków dotyczących polityk z przeglądami bezpieczeństwa/zgodności.

9) Audyt i obserwowalność

Мурнач ребений: "decision _ id'," subject "," action "," resource _ ref "," result "," matched _ policies "," policy _ version "," atrybuty _ digest ".
Wskaźniki: PDP QPS, opóźnienie p95, pamięć podręczna, odmowa udziału, szybkość przyspieszenia, incydenty SoD.
Ślady: rozpiętość na połączenie PDP; korelacja z żądaniem API.
Powtórka: możliwość „powtórzenia” historycznych decyzji dotyczących nowej wersji polityki (kontrola bezpieczeństwa).

10) Integracja z uwierzytelnianiem i żetonami

Tożsamość - od IdP (OIDC/SAML). Żetony posiadają co najmniej atrybuty: 'sub', 'lokator', 'role', 'auth _ time', 'amr', 'scopes'.
Dla ABAC, wyciągnąć „ciężkie” znaki od strony serwera (PIP), aby nie nadmuchiwać token.
Podpisane żetony zasobów (funkcje/zaproszenia) - dla ściśle ograniczonych delegacji.

11) pseudo kod PDP (uproszczony)

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12) Anty-wzory

„Rola = strona” (setki małych ról bez modelu domeny).
Zasady przechowywania tylko w kodzie bez wersji/audytów.
Brak odmowy-override i SoD → zwiększone ryzyko oszustw.
Listy twarde 'user _ id' in reguły (zamiast atrybutów/relacji).
Brak filtrowania warstwy danych (RLS) tylko z filtrem interfejsu użytkownika.
Synchronizacja ról poprzez ręczne skrypty bez zdarzeń i niepełnosprawności pamięci podręcznej.

13) Przypadki i przepisy

13. 1 Maskowanie na poziomie pola:

allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13. 2 Dane dotyczące wywozu z MSZ wyłącznie:

allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13. 3 SoD:

deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13. 4 Delegacja (token ograniczony):

Token funkcji zawiera' resource _ id',' actions = [” read”] ',' expires _ at ',' aud'. PEP weryfikuje podpis i termin.

14) Badanie

Testy jednostkowe zasad: tabele prawdy według głównych kombinacji.
Właściwości oparte: generowanie losowych atrybutów, aby znaleźć „dziury”.
Złote testy: mocowanie zestawu rozwiązań dla krytycznych punktów końcowych.
Canary/Shadow: równoległa ocena starych i nowych wersji polityk z rejestrowaniem rozbieżności.

15) Powiązane możliwości sekcji „Architektura i protokoły”

Uwierzytelnianie i autoryzacja (OIDC/OAuth2)

Zarządzanie zgodą

Tokenizacja i zarządzanie kluczami

Obserwowalność: kłody, mierniki, ślady

Trasa geograficzna i lokalizacja

Szyfrowanie odpoczynku/tranzytu

16) Lista kontrolna architekta

1. Czy role tematyczne i ich hierarchie są określone?
2. Czy istnieje model hybrydowy: role + warunki dotyczące atrybutów?
3. Wdrożona PDP z zakazem, SoD i krokiem?
4. Gdzie jest PEP? (brama, backend, baza danych, interfejs użytkownika) - czy wszędzie jest jednolity?
5. Czy pamięć podręczna rozwiązania i niepełnosprawność zdarzeń są skonfigurowane?
6. Czy polityka jest weryfikowana, testowana, realizowana w drodze procesu?
7. Czy decyzje audytu, metryki i ślady są włączone?
8. Obsługiwane multi-leasing i RLS/field-masking?
9. Masz książkę wypadków i regresji polityki?

Wniosek

RBAC zapewnia sterowność, ABAC zapewnia kontekst i dokładność. Łącząc role z warunkami atrybutów, udostępniając PDP/PEP, wdrażając buforowanie, audyt i testowanie polityki, budujesz autoryzację jako możliwość platformy: przewidywalną, weryfikowalną i skalowalną dla wymagań produktowych i regulacyjnych.