Scrivere policy di accesso

Le policy di accesso decidono quali soggetti possono leggere quali oggetti, con row filters e projection di colonne opzionali — applicate server-side nella cella, fail-closed.

In stesura

Una guida completa alla stesura di policy è in arrivo. Questa pagina delinea il modello; vedi Governance e la cella per i concetti e Autenticazione per i ruoli su cui le policy fanno match.

Il modello in un paragrafo

OSL emette fatti di policy per ogni oggetto governato. Il punto di decisione delle policy fa il match della (data, action, actor, context) di una richiesta contro quei fatti e le policy che scrivi, restituendo allow/deny più le obbligazioni (row filters, projection, oscuramento). Il punto di applicazione delle policy applica la decisione prima che qualsiasi dato esca dalla cella.

Snapshot di policy effettiva

Per vedere le decisioni che attualmente si applicano a un tenant:

GET /v1/tenants/{t}/policies/effective

Principi che non cambieranno

• Fail-closed. Senza snapshot → deny (E2001, 503). Deny-by-default sui facet con ACL.
• La PII si dichiara nel connettore, mai si inferisce nella UI, e si oscura server-side.
• Negazioni non rivelatrici. Una richiesta negata non rivela mai quale policy ha negato.
• Tutto viene tracciato in audit — allow o deny — su un’unica traccia concatenata tramite hash.