RBAC mit 3 Ebenen und Funktionstrennung
Wer die Daten betreibt, ist nicht derjenige, der sie steuert. By Design.
Rahmen / Norm: ISO/IEC 38505-1 (Autorität) · SoD (SOX/DORA) · ISO/IEC TR 38505-2 §6
Der DBA, der eine Tabelle betreibt, sollte nicht den Geschäftsbegriff genehmigen können, der sie beschreibt. Linedat trennt, wer betreibt, von wem, der steuert, mit einem dreistufigen Autorisierungsmodell und einer einzigen Quelle der Wahrheit für Berechtigungen.
Drei Ebenen, ein Enum
Die Autorisierung kombiniert die Organisationsrolle, die Domänenrolle und die Ressourceneigentümerschaft — alles durch ein einziges Berechtigungs-Enum. Keine verteilten Rollenprüfungen in den Komponenten, keine kopierten Bedingungen: Jede Autorisierungsentscheidung läuft durch dieselbe Stelle.
Technischer Verwalter ohne Governance-Autorität
Die Verwalterrolle (technischer Betrieb) liegt bewusst unterhalb des Stewards und erbt keine Governance-Aktionen (Begriffe genehmigen, Eigentümer zuweisen). Es ist echte Funktionstrennung, ausgerichtet auf die von SOX und DORA geforderte.
Die Grenzen (was wir nicht behaupten)
Die Berechtigung auf Organisationsebene ist das tragende Gate; Domänengruppen schränken innerhalb dieser Berechtigung ein, gewähren aber nicht darüber hinaus. Eine Rollenänderung braucht bis zur Cache-Lebensdauer der Auth (~30 s), um sich zwischen Prozessen zu propagieren, wenn sie nicht explizit invalidiert wird.
Wie Linedat hilft
Linedat gibt Ihnen ein granulares Enterprise-RBAC ohne Komplexität, mit echter Funktionstrennung — wer die Daten betreibt, ist nicht derjenige, der sie steuert.
Verwandte Funktionen
Zugang mit typifiziertem Zweck und Ablaufdatum. Nicht „einfach so".
Einvernehmliche und zeitlich begrenzte AutoritätsdelegationAutorität wird nicht aufgezwungen: Sie wird delegiert, der Delegierte akzeptiert sie, und sie läuft von selbst ab.
Der Katalog in Ihrer IDE: nativer MCP-ServerIhre IDE fragt den Katalog ab, ohne den Editor zu verlassen — und ohne eine einzige Berechtigung zu umgehen.