Motore di ruolo

1) Modelli di autorizzazione

RBAC (Rolle-Based Access Control) - Il soggetto riceve ruoli e ruoli associati a permessi. Basta gestire, bene per i compiti tipici.
ABAC (Attribute-Based Access Control) - La soluzione dipende dagli attributi del soggetto, della risorsa, dell'attività e dell'ambiente (tempo, IP, regione, rischio). Flessibile e scalabile su regole complesse.
Ibrido RBAC + ABAC: i ruoli offrono una capacità di base e gli attributi la restringono.
(Opzionale) Il grafico delle relazioni (proprietario, membro del team, delegato) è utile per le strutture documentali e org.

2) Architettura: PDP/PEP e flussi

PEP (Policy Enforcement Point) - Percorso di applicazione della soluzione (API gateway, backend, SQL, UI).
PDP - Servizio/libreria che calcola ALLOW/DENY per criteri e attributi.
PIP (Policy Information Point) - Origini attributi (IdP/profilo, metadati della risorsa, rischio-scansione, geo).
IP (Policy Administration Point) - Interfaccia amministrativa/repository di criteri (versioni, bozze, pubblicazione).

Flusso: la query PEP crea il contesto del PDP estende gli attributi mancanti (tramite PIP) e calcola la soluzione PEP applica (consenti/disabilita/taglia i campi) il controllo .

3) Modello di dati

• `subject` (user/service) с атрибутами: `tenant_id`, `roles`, `departments`, `risk_level`, `mfa_verified`, `scopes`, `claims`.
• «resource» con tipo e attributi: «type», «owner _ id», «tenant _ id», «classifiche» (public/confidential), «region», «tags».
• `action`: `read`, `write`, `delete`, `export`, `approve`, `impersonate` и т. п.
• `environment`: `time`, `ip`, `device`, `geo`, `auth_strength`, `business_context` (канал, тариф).

• «roles (id, tenant _ id, name, inherits [])» - Supportare gerarchie e modelli.
• `permissions(id, resource_type, action, constraint?)`.
• `role_permissions(role_id, permission_id)`.
• «assignments (subject _ id, role _ id, scope)» - scope: globale/per progetto/oggetto.

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

4) Principi decisionali

Deny-overrides - Proibizioni esplicite più priorità delle autorizzazioni.
Least Privilege (PoLP) - Concedere l'accesso minimo necessario, estenderlo attraverso le condizioni.
Separation of Duties ( ) - Impedisce le combinazioni di ruoli/azioni (ad esempio, «ha creato il pagamento».
Text-aware: aumentare i requisiti a rischio elevato (nessun MFA, IP sospetto).
Determinism: contesto identico, risposta identica; Fissare la versione dei criteri nel registro.

5) Modelli di implementazione

5. 1 Ibrido RBAC→ABAC (aria condizionata)

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 Row/Field-Level Security

A livello di database: regole RLS («tenant _ id», «owner _ id»).
Livello API - Filtra le raccolte e maschera i campi se non c'è 'allow: read _ sensitive _ fields'.

5. 3 Soluzioni step-up

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

5. 4 Tolleranze temporanee

Borse di studio con TTL: 'Assignment'. expires _ at ', «finestre» di accesso (durante l'orario di lavoro della regione della risorsa).

6) Prestazioni e cache

Cache delle soluzioni (decise cache) in chiave «(subject _ hash, resource _ key, action, policy _ variante)» con TTL breve.
Elenca la cache degli attributi dell'oggetto (clims in token) + lazy-fetch degli attributi della risorsa.
Invalidazione degli eventi (cambio dei ruoli, modifica dei criteri, traduzione della risorsa in confidential).
Controlli batch - Per gli elenchi, valutare «filtro» (policy-predicate pushdown) per evitare che il PDP venga tirato a riga.

7) Multi-tenant

In ogni tabella, «tenant _ id»; i criteri predefiniti limitano l'accesso all'interno dell'affitto.
Gli amministratori di locazione gestiscono solo ruoli/diritti di locazione.
Accesso cross-affitto - esclusivamente tramite inviti/schering espliciti deny-override.

8) Amministrazione e ciclo di vita delle regole

Versioning: 'policy. version'nella risposta PDP, memorizzare nel controllo.
Ambienti: draft → canary (parti di traffico/shadow) → prod.
Test matrix: tabelle di verità per ruoli/attributi chiave (test contrattuali).
Change management - Informazioni sui criteri con revisione della protezione/della compilazione.

9) Controllo e osservazione

Журнал решений: `decision_id`, `subject`, `action`, `resource_ref`, `result`, `matched_policies`, `policy_version`, `attributes_digest`.
Metriche: QPS PDP, latenza p95, hit-rate cache, quota deny, frequenza step-up, incidenti di SoD.
Traccia: span per la chiamata PDP; correlazione con la richiesta API.
Le repliche includono la possibilità di rielaborare le soluzioni storiche sulla nuova versione dei criteri (safety check).

10) Integrazione con l'autenticazione e i token

Identità da IdP (OIDC/SAML). I token portano un minimo di attributi: sub, tenant, roles, auth _ time, amr, scopes.
Per ABAC, trascinare i segni «pesanti» sul lato server (PIP) per non gonfiare il token.
Firmati resource tokens (capability/inviti) - per deleghe rigorosamente limitate.

11) Pseudo-codice PDP (semplificato)

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) Anti-pattern

Ruolo = pagina (centinaia di ruoli minori senza modello di oggetto).
Memorizza le regole solo in codice senza versione/controllo.
L'assenza di deny-override e l'aumento del rischio di frode.
Elenchi rigidi dì user _ id "nelle regole (al posto degli attributi/relazioni).
Nessun filtro a livello di dati (RLS) se è disponibile solo un filtro UI.
Sincronizza i ruoli con script manuali senza eventi o disabilità della cache.

13) Valigie e ricette

13. 1 Maschera a livello:

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

13. 2 Esportazione dati solo da MFA:

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 Delega (token limitato):

Capability-token contiene «resource _ id», «action = [» read «]», «expyres _ at», «aud». PEP verifica la firma e la scadenza.

14) Test

Test unit criteri: tabelle di verità per combinazione principale.
Property-based - Genera attributi casuali per cercare buchi.
Golden-test: fissa una serie di soluzioni per endpoint critici.
Canary/Shadow - Valutazione parallela delle versioni precedenti e nuove dei criteri con la logica delle soluzioni temporanee.

15) Capacità correlate della sezione Architettura e Protocolli

Autenticazione e autorizzazione (OIDC/OAuth2)

Gestione dei consensi

Tornitura e gestione delle chiavi

Osservabilità: fogli, metriche, tracciabili

Instradamento e localizzazione geo

Crittografia At Rest/In Transit

16) Assegno-foglia architetto

1. Definite i ruoli di oggetto e le relative gerarchie?
2. Esiste un modello ibrido: ruoli + condizioni sugli attributi?
3. Implementato PDP con deny-overrides, SoD e step-up?
4. Dov'è il PEP? (gateway, backand, OBD, UI) - È tutto uniforme?
5. La cache delle soluzioni e la disabilità degli eventi sono configurate?
6. I criteri vengono versionati, testati, esplorati in base al processo?
7. Controllo delle soluzioni, metriche e tracciabili attivati?
8. È supportata la multiutility e RLS/field-masking?
9. Ci sono runbook su incidenti e regressione della politica?

Conclusione

RBAC fornisce la gestione, ABAC il contesto e la precisione. Combinando i ruoli con le condizioni degli attributi, separando PDP/PEP, implementando la cache, la verifica e la verifica delle regole, si crea l'autorizzazione come TPM: prevedibile, verificabile e scalabile per i requisiti alimentari e regolatori.