Zugriffskontrolle und RBAC in der API

1) Warum API-Zugriffskontrolle

Autorisierung ist die Antwort auf die Frage "Kann dieser Akteur diese Aktion jetzt auf dieser Ressource ausführen? ». Fehler führen zu BOLA/IDOR-Lecks, eskalierenden Rechten und Verstößen gegen regulatorische Anforderungen. Ziel ist es, ein mehrstufiges Modell zu erstellen: Perimeter → Service Mash → Geschäftsregeln, mit expliziten Richtlinien und Überprüfungen auf Objektebene.

2) Autorisierungsmodelle: Wann was zu wählen ist

RBAC (Role-Based Access Control) - Rollen → Auflösungen. Einfach, stabil, aber anfällig für eine „Explosion der Rollen“.
ABAC (Attribute-Based) - Entscheidung über die Attribute des Subjekts/Objekts/Kontextes (Land, KYC-Ebene, Ressourcenbesitzer, Risiko).
ReBAC (Relationship-Based) - Beziehungsgraph (Eigentümer, Teammitglied, „Projektmanager“); Komplexe Hierarchien lösen.
Scopes (OAuth) ist ein Vertrag zwischen einem Client und einem Ressourcen-Server über einen „Zugriffsbereich“ (z. B. „Zahlungen: Schreiben“).
Praxis: RBAC für Basismatrix, ABAC für Kontext und Einschränkungen, ReBAC für komplexe Hierarchien (Ordner, Organisationen, Limits und Subaccounts).

3) Taxonomie von Ressourcen und Aktionen

„Org → Project → Wallet → Transaction“ Vererbung von Top-Down-Rechten mit möglichen „Restriktoren“.
Aktionen: CRUD + domänenspezifisch ('approve', 'refund', 'settle').
Ressourceneigenschaften: Eigentümer, Region, Status, Risiko-Tags (AML/KYC), Limits.
Multi-Leasing: Alle Lösungen enthalten 'tenant _ id'; Verhindern Sie Cross-Tenant-Standardabfragen (deny-by-default).

4) Architektur: Wo die Entscheidung fällt

PEP (Policy Enforcement Point) - Ort der Überprüfung: Gateway/API-Gateway, Sidecar-Masha, der Dienst selbst.
PDP (Policy Decision Point) - Policy Engine: zentralisiert (OPA-Service, Cedar-Engine) oder eingebettete Bibliothek.
PIP (Policy Information Point) - Attributquellen: Benutzer-/Rollenverzeichnis, Tenantprofil, KUS/Risiko, Ressourcenbesitzkarte.
PAP (Policy Administration Point) - Versionierung von Richtlinien, Veröffentlichung, Überwachung.

Empfehlung: zentrale PDP + Local Solution Cache im PEP; komplexe Objektprüfungen im Dienst bei Vorhandensein von Domäneninvarianten.

5) Token, Stempel und Identität

OIDC/OAuth2: "sub" (Entity-ID), "aud' (Zieldienst)," scope "/" roles "," tenant "," kyc _ level "," risk _ tier ".
JWT: RS/ES-Signatur, kurz' exp', Neuausgabe durch refresh. Setzen Sie nicht PII; Verwenden Sie' jti 'für Feedback/Track-Audit.
mTLS/HMAC: Service-to-Service und Partner; Die Stempel werden aus dem Verzeichnis durch 'client _ id' gezogen.
Device/Context: IP/ASN, Geo, Tageszeit - Anmeldung bei der ABAC-Lösung (z.B. Schreibverbot außerhalb der Geschäftszeiten).

6) Objektebenenberechtigung (BOLA-first)

Jeder Vorgang muss beantworten: „Ist das Subjekt Eigentümer/hat es Anspruch auf diese' resource _ id'?“.

Besitzprüfung: 'resource. owner_id == subject. id 'oder die Mitgliedschaft in' org 'mit der Rolle.
Filterung von Samples: immer überlagern 'WHERE Ressource. tenant_id =:tenant AND...` (row-level security).
Für Referenzoperationen (ID im Pfad/Körper) - Normalisieren und validieren Sie zur Geschäftslogik.

7) RBAC-Design: Rollen, Berechtigungen, Sets

Berechtigungen (permissions) - atomare Rechte: 'wallet. read`, `wallet. write`, `payment. refund`.
Rollen - Benannte Berechtigungssätze: 'admin', 'support. read`, `cashier`, `fraud. analyst`.
Scopes ist ein externer Vertrag für Kunden (scope→permissions-Mapping).

• Basisrollen + „Add-Ins“ (permission packs),
• ABAC-Beschränkungen (Land/Region/Tenant),
• „Temporäre Erhöhungen“ (Just-In-Time-Zugang, Gültigkeit).

8) AVAS/Kontextbeschränkungen

Geo/Jurisdiktion: Schreibverbot aus verbotenen Ländern (Sanktionen/Regulierung).
Zeit/Risiko: 'risk _ score <threshold' für große Operationen.
CUS/Grenzwerte: „kyc _ level> = 2“ für Anschlüsse> X; Kontrolle der „Abkühlung“ zwischen Transaktionen.
„Trusted Devices“: Fordern Sie mTLS für Partner auf gefährlichen Routen.

9) ReBAC und der Rechte-Graph

Nützlich für komplexe Geschäftsstrukturen (Gruppen, Teams, Marken, Niederlassungen).

Beziehungen: 'member', 'admin', 'owner', 'viewer'.
Abgeleitete Rechte: Der 'Viewer' einer Ressource wird von einem 'Member' eines Projekts geerbt, das zu 'org' gehört.
Graphenspeicher: DB mit Beziehungsmatrix, Fachdienst (im Sinne des Zanzibar-Ansatzes). Die Antworten 'check (subject, relation, object)' zwischenspeichern.

10) Lösungscache und Leistung

PDP-Cache auf PEP-Ebene (z.B. im Gateway) mit dem Schlüssel für: 'sub' tenant 'resource' action 'policy _ version'.
TTL kurz (Sekunden-Minuten) + Behinderung durch Ereignisse: Rollen/Beziehungen/Tenant ändern.
Batch-Checks (bulk authz) für Listen: Reduzieren Sie PDP-Charges.
Messen Sie die Latenz von Lösungen; wenn degradiert - graceful-degradation nur für read (niemals für write/money).

11) Beispiele für Richtlinien

11. 1 JWT-Stempel → grobe PEP (Pseudo-Gateway)

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 Beschränkung der Zuständigkeit (deny-list policy)

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

11. 4 ReBAC-Richtlinie (Pseudo)

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

12) Richtlinien und Versionsverwaltung

Versionierung von Richtlinien ('policy _ version') und Kanarienvogel für gefährliche Änderungen.
„Dry-run/shadow decisions“ - Loggen Sie' allow/deny 'ohne Auswirkungen.
Verzeichnis der Richtlinien und Migrationen: wer, wann und warum geändert; Vergleich mit Vorfällen.
Tests für negative Szenarien (verbotene Fälle) - obligatorisch in CI.

13) Beobachtbarkeit und Auditierung

Entscheidungsprotokolle: 'trace _ id', 'subject', 'tenant', 'action', 'resource _ id', 'result',' policy _ version', Fehlerursache.
Metriken: 'authz _ decision _ latency', 'authz _ denied _ total {action}', Anteil der BOLA-Versuche, Cache-Hit-Rate.
Dashboards: Top-Verzicht auf Aktionen/Tenanten, Trends nach Politiker-Releases.

14) Sicherheit und Nachhaltigkeit

Deny-by-default: keine explizite Auflösung = Verbot.
Fail-closed: Wenn PDPs nicht verfügbar sind, → kritisches Schreiben ein Verbot (oder eine Degradierung zu einem „Mindestsatz“ streng getesteter Rollen).
Lokale "Guard-Checks' innerhalb von Diensten für kritische Invarianten (z.B. 'tenant '/' owner').
Minimierung von Stigmen in JWT; sensible Attribute über PIP über einen sicheren Kanal hochladen.

15) Spezifität von iGaming/Finanzen

Rollen: 'cashier', 'kyc. agent`, `aml. officer`, `fraud. analyst`, `vip. manager`, `risk. admin`.
Einschränkungen: Auszahlungstransaktionen hängen von 'kyc _ level', verantwortungsvollen Zahlungslimits, AML-Status/Sanktionen ab.
Sperrregister: 'org/brand/device/payment _ instrument' - ABAC-Filter auf write.
Audit-Protokolle unveränderlich für KYC/AML/Lead-Aktionen; Lagerung gemäß den gesetzlichen Fristen.
Partner-APIs: mTLS + vertragliche „Scopes“ entlang der Routen, Geo-/ASN-Filter am Perimeter.

16) Prüfung und Verifizierung

Negative-Matrix: Listen Sie explizite „verbotene“ Fälle auf und sichern Sie sie mit Tests.
Autorisierungsfuzz: Substitution von 'tenant _ id', 'owner _ id', Umgehung der Filter beim Paginieren/Sortieren.
PDP Load Test: Überprüfen Sie die Latenz und das Verhalten der Caches bei p95/p99.
Release-Richtlinien: Dry-Run + Canary + Auto-Shift mit erwarteten Deny/Allow.
Vorfälle: Replay von Anfragen auf dem Stand mit der genauen Version der Richtlinien.

17) Antipatterns

Verlassen Sie sich nur auf 'scope' ohne Objektprüfungen (BOLA).
Mischen Sie Geschäftslogik und Rechteprüfungen in jedem Handler ohne zentralisiertes Modell.
Hardcodieren Sie Rollen in der Benutzeroberfläche und vertrauen Sie Kundenlösungen.
Keine' tenant '/' owner 'Filter in Anfragen an die DB (leaky reads).
Keine Behinderung von Cash-Entscheidungen bei Rollen-/Beziehungswechsel.
Langlebige JWTs ohne Rückruf/Rotation.

18) Checkliste Prod-Ready

• Ressourcen/Aktivitäten, Hierarchien und Multiarrangements sind definiert.
• Basis RBAC-Matrix + ABAC-Limiter, wo nötig - ReBAC.
• PDP/PEP entworfen; Es gibt einen lokalen Entscheidungscache und seine Behinderung.
• Politiker werden versioniert, negative Szenarien im CI getestet.
• BOLA-Prüfungen in jedem write/read auf eine bestimmte' resource _ id'.
• JWT mit Mindeststempeln, kurz „exp“; Audit/Widerruf von „jti“.
• Entscheidungsmetriken/Protokolle, Dashboards, Alerts von deny/latency.
• Fail-closed für kritische Texte; fallback-Modus dokumentiert.
• Kundendokumentation: 'scopes', Fehlercodes (401/403/404/409), Beispiele.

19) TL; DR

Bauen Sie die BOLA-first-Autorisierung auf: zentraler PDP + Entscheidungscache, RBAC als Basis, ABAC für Kontext, ReBAC für Beziehungen. Alle Anfragen sind im Kontext von 'tenant' und der spezifischen 'resource _ id'; deny-by-default, kurze JWTs, Objektfilter in der DB. Versionieren und testen Sie Richtlinien, messen Sie Latenz/Deny, reproduzieren Sie Vorfälle mit einem Replay. Für iGaming - separate Rollen (KYC/AML/Kasse), harte ABAC-Limiter und unveränderliches Audit.