Zugriffs-Policies schreiben

Zugriffs-Policies entscheiden, welche Subjekte welche Objekte lesen dürfen, mit optionalen Zeilenfiltern und Spalten-Projektion — serverseitig in der Zelle durchgesetzt, fail-closed.

In Arbeit

Eine vollständige Anleitung zum Verfassen von Policies folgt. Diese Seite skizziert das Modell; siehe Governance & die Zelle für die Konzepte und Authentifizierung für die Rollen, auf die Policies matchen.

Das Modell in einem Absatz

OSL emittiert Policy-Fakten für jedes gesteuerte Objekt. Der Policy Decision Point matcht das (data, action, actor, context) einer Anfrage gegen diese Fakten und die Policies, die du verfasst, und gibt allow/deny plus Obligationen (Zeilenfilter, Projektion, Redaktion) zurück. Der Policy Enforcement Point wendet die Entscheidung an, bevor irgendwelche Daten die Zelle verlassen.

Snapshot der effektiven Policy

Um die Entscheidungen zu sehen, die aktuell für einen Tenant gelten:

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

Prinzipien, die sich nicht ändern werden

• Fail-closed. Kein Snapshot → deny (E2001, 503). Deny-by-default auf Facetten mit ACL.
• PII wird am Connector deklariert, niemals in der UI inferiert, und serverseitig redigiert.
• Nicht-enthüllende Ablehnungen. Eine abgelehnte Anfrage gibt niemals preis, welche Policy abgelehnt hat.
• Alles wird auditiert — allow oder deny — auf einer hash-verketteten Spur.