Controllo di accesso e RBAC in API

1) Perché controllare l'accesso all'API

L'autorizzazione è la risposta alla domanda "Questo attore può eseguire questa azione su questa risorsa ora? ». Gli errori causano fughe di BOLA/IDOR, un'escalation dei diritti e violazioni dei regolatori. L'obiettivo è quello di costruire un modello su più livelli, un perimetro, un servizio-mash e regole aziendali, con regole e controlli espliciti a livello di oggetto.

2) Modelli di autorizzazione: quando scegliere cosa

RBAC (Rolle-Based Access Control) - ruoli di risoluzione →. Semplice, stabile, ma incline a far esplodere i ruoli.
ABAC - Soluzione per attributi oggetto/oggetto/contesto (paese, livello KYC, proprietario della risorsa, rischio).
ReBAC (Relationship-Based) è un conte di relazioni (proprietario, membro del team, project manager) risolve gerarchie complesse.
Scopes (OAuth) - Contratto tra un client e una risorsa server per un'area di accesso "(ad esempio," payments: write ").
Pratica: RBAC per la matrice di base, ABAC per il contesto e i vincoli per le gerarchie complesse (cartelle, organizzazioni, limiti e podcount).

3) Tassonomia di risorse e azioni

Gerarchie: "org → project" wallet "→ →. Eredita i diritti dall'alto verso il basso con i possibili «vincoli».
Azioni: CRUD + domain-specifici («approve», «refund», «settle»).
Proprietà risorse: proprietario, regione, stato, rischio-tag (AML/KYC), limiti.
Multiutility: tutte le soluzioni contengono «tenant _ id»; impedisce le query di default (deny-by-default).

4) Architettura: dove viene presa la decisione

PEP (Policy Enforcement Point) - gateway/API-gatway, sidecar mash, servizio stesso.
PDP (Policy Decection Point) - Motore criteri centralizzato (OPA, Cedar Motion) o Library incorporato.
PIP (Policy Information Point) - Origini di attributi: catalogo utente/ruolo, profilo tenante, COUS/rischio, mappa di proprietà risorse.
Gip (Policy Administration Point) - Gestione delle versioni dei criteri, pubblicazione, revisione.

Raccomandazione PDP centralizzato + cache locale delle soluzioni PEP Controlli su oggetti complessi nel servizio in presenza di invarianti di dominio.

5) Token, marchi e identità

OIDC/OAuth2: «sub», «aud», «scope »/« roles», «tenant», «kyc _ level», «risk _ tier».
JWT: firma RS/ES, breve «exp», reimpostazione per rifresh. Non mettere PII; Usa «jti» per richiamare/track check.
mTLS/HMAC: servizio-a-servizio e partner; le etichette vengono trascinate dalla directory dì client _ id '.
Device/Text: IP/ASN, geo, ore del giorno - Accesso alla soluzione ABAC (ad esempio, divieto write al di fuori delle ore di lavoro).

6) Autorizzazioni oggetto-livello (PALLA-first)

Ogni operazione deve rispondere a «il soggetto possiede/ha diritto a questo» resource _ id «?».

Verifica di proprietà: 'resource. owner_id == subject. id o appartenenza à org "con un ruolo.
Filtrazione campionamenti: sovrascrivi sempre «WHERE resource». tenant_id =:tenant AND...` (row-level security).
Per le operazioni di riferimento (ID nel percorso/corpo) - Normalizzare e convalidare fino alla logica aziendale.

7) Progettazione RBAC: ruoli, autorizzazioni, set

Permessi - Diritti atomici: 'wallet. read`, `wallet. write`, `payment. refund`.
Ruoli - Set di autorizzazioni denominati "ammin", "support. read`, `cashier`, `fraud. analyst`.
Scopes è un contratto esterno per i clienti.

• ruoli di base + «plug-in»,
• restrizioni ABAC (paese/regione/tenante),
• «aumenti temporanei» (data di scadenza).

8) ABAS/vincoli contestuali

Geo/giurisdizione: divieto write da paesi proibiti (sanzioni/regolamentazione).
Tempo/rischio: 'risk _ score <threshold'per operazioni di grandi dimensioni.
KUS/limiti: 'kyc _ level> = 2' per le conclusioni> X; Controllo del raffreddamento tra le transazioni.
«Dispositivi di fiducia», richiedere un mTLS per i partner su rotte pericolose.

9) ReBAC e conte ha ragione

Utile per strutture aziendali complesse (gruppi, team, marchi, filiali).

Relazioni: «member», «ammin», «owner», «viewer».
Diritti derivati: «viewer» della risorsa viene ereditato da «member» del progetto «org».
Archivio grafico: database con matrice di relazioni, servizio specializzato (nello spirito di approccio Zanzibar). Memorizzare nella cache le risposte «check (subject, relation, object)».

10) Cache di soluzioni e prestazioni

La cache PDP a livello PEP (ad esempio, nel gateway) con la chiave «sub» tenant «resource» action «policy _ vision».
TTL breve (secondi-minuti) + disabilità per eventi - Modifica di ruoli/relazioni/tenente.
Controllo batch (bulk authz) per gli elenchi: riduce i charjee PDP.
Misurare le soluzioni latency; in caso di degrado - graceful-degradation solo per read (mai per write/denaro).

11) Esempi di regole

11. 1 marchio JWT → 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 Vincolo di giurisdizione (criterio deny-list)

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

11. 4 Politica ReBAC (pseudo)

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

12) Gestione di regole e versioni

Versioning di regole ('policy _ version') e canarino per modifiche pericolose.
Dry-run/shadow decisions - Logifiche'allow/deny'senza effetto.
Catalogo di regole e migrazioni: chi, quando e perché ha cambiato; il confronto con gli incidenti.
I test per gli scenari negativi (valigette proibite) sono obbligatori in CI.

13) Osservazione e verifica

I fogli di soluzione sono: «trace _ id», «subject», «tenant», «action», «resource _ id», «result», «policy _ variante», causa di guasto.
Metriche: 'authz _ decision _ latency', 'authz _ denied _ total {action}', quota di tentativi PALLA, cache-hit-rate.
I Dashboard sono i top-back per azioni/tenanti, le tendenze dopo le release delle regole.

14) Sicurezza e sostenibilità

Deny-by-default: nessuna autorizzazione esplicita = proibizione.
Fail-closed - Se PDP non è disponibile, i write critici non sono consentiti (o la degradazione a «minimi» ruoli rigorosamente testati).
Controlli guard locali all'interno dei servizi per gli invarianti critici (ad esempio, tenant/owner).
Ridurre al minimo i marchi in JWT; attributi sensibili da adattare tramite PIP su un canale protetto.

15) Specificità iGaming/finanza

Ruoli: 'cashier', 'kyc'. agent`, `aml. officer`, `fraud. analyst`, `vip. manager`, `risk. admin`.
Restrizioni: le transazioni di pagamento dipendono da «kyc _ level», limiti di pagamento responsabile, stato AML/sanzioni.
I registri di blocco sono i filtri ABAC su write.
Registri di controllo invariati per le azioni KYC/AML/conclusioni; Conservazione in base ai tempi regolatori.
API partner: mTLS + «scopes» contrattuali su rotte, filtri geo/ASN sul perimetro.

16) Test e verifica

Matrice negativa: elenca le valigette «proibitive» esplicite e fissa i test.
Fuzz autorizzazioni: sostituzione di «tenant _ id», «owner _ id», aggiramento dei filtri di paginazione/ordinamento.
Test di load PDP: controlla la latenza e il comportamento della cache a p95/p99.
Rilascio delle regole: dry-run + canary + autolesionismo con i deny/allow attesi.
Incidenti, repliche di richieste sullo stand con una versione precisa delle regole.

17) Antipattern

Affidarsi solo à scope "senza controllo oggetto (PALLA).
Miscelare logica aziendale e controllo dei diritti in ogni handler senza un modello centralizzato.
Hardcoder i ruoli dell'UI e fidarsi delle soluzioni dei clienti.
Nessun filtro «tenant »/« owner» nelle richieste di database (leaky reads).
Nessuna disabilità nella cache quando si cambiano ruoli/relazioni.
JWT a lunga vita senza ritiro/rotazione.

18) Assegno-foglio prod-pronto

• Definite le risorse/azioni, le gerarchie e la multiutilità.
• Matrice RBAC di base + limitatori ABAC, dove si desidera.
• PDP/PEP progettati la cache locale delle soluzioni e la sua invalidità.
• I criteri sono versionati, test di script negativi in CI.
• Controlli BOLA in ogni write/read per «resource _ id» specifico.
• JWT con marchi minimi, brevi 'exp'; controllo/revoca su «jti».
• Metriche/fogli di soluzioni, dashboard, alert per deny/latency.
• Fail-closed per write critici; la modalità fallback è documentata.
• Documentazione client: «scopes», codici di errore (401/403/404/409), esempi.

19) TL; DR

Costruisci l'autorizzazione di BOLA-first: PDP centrale + cache delle soluzioni, RBAC come base, ABAC per il contesto, ReBAC per le relazioni. Tutte le richieste sono nel contesto «tenant» e nello specifico «resource _ id»; deny-by-default, JWT brevi, filtri di oggetti nel database. Versionare e testare le regole, misurare latency/deny, gli incidenti riprodurre la replica. Per i iGaming, ruoli separati (KYC/AML/cassa), vincoli ABAC rigidi e controllo invariato.