Governance & Identität
Governance ist in lavalake keine Schicht über der Plattform, sondern der Weg, auf dem jede Abfrage läuft. Es gibt keinen Pfad daran vorbei – auch nicht für die Suche, das Dashboard, den BI-Feed oder den KI-Assistenten.
Auf dieser Seite
Delegierte Identität statt Dienstkonto
Ein Backend, das Daten mit eigenen, weitreichenden Rechten liest und danach selbst entscheidet, was es dem Nutzer zeigt, ist der Normalfall – und der Punkt, an dem Rechtemodelle zerfallen. lavalake macht es andersherum: Der Agent tauscht das Token des angemeldeten Nutzers über den Standard-Token-Exchange von Keycloak (RFC 8693) gegen ein Token für Trino und stellt die Abfrage damit.
Was Sie in lavalake sehen, ist genau das, was Trino Ihrer Kennung zeigt. Ein Fehler in der Oberfläche kann Ihnen keine Zeile aufdecken, die Sie nicht sehen dürfen.
Zeilen- und Spaltenrichtlinien
Unter Verwaltung → Richtlinien legt die Plattform-Administration fest, welche Zeilen eine Rolle sieht und welche Spalten maskiert werden. Die Konsole speichert diese Regeln nicht nur – sie übersetzt sie in Trinos dateibasierte Zugriffskontrolle. Trino liest die erzeugte Regeldatei über ein gemeinsames Volume ein und wendet sie auf jede Abfrage an, gleich woher sie kommt.
- Zeilenzugriff: eine Bedingung, die Trino jeder Abfrage auf die Tabelle anhängt.
- Spaltenmaskierung: ein Ausdruck, der den Wert ersetzt, statt die Spalte zu verbergen.
- Wirksam für alle Wege – Arbeitsblatt, Suche, Dashboard, BI-Feed, Assistent.
Richtlinien wirken in Trino
Dafür schreibt der Agent die Regeldatei auf ein Volume, das Trino mitliest – eingestellt über TRINO_ACCESS_RULES_FILE. Fehlt der Pfad, werden Richtlinien gespeichert, aber nicht durchgesetzt.
Das Audit-Protokoll
Jeder Zugriff wird protokolliert, und die Einträge bilden eine Hash-Kette: jeder Eintrag trägt die Prüfsumme seines Vorgängers. Ein nachträglich geänderter oder entfernter Eintrag bricht die Kette an einer nachweisbaren Stelle. Archiviert wird nach MinIO unter Object Lock – also in einen Speicher, der Überschreiben verweigert.
Protokolliert wird der Zugriff, nicht der Inhalt
Die Kette hält fest, wer wann was abgefragt hat – nicht die Werte. Sonst entstünde neben den Daten eine zweite, ungeschützte Kopie.
Herkunft und Zugriffshistorie
Aus derselben Kette leitet die Seite Herkunft zwei Fragen ab, die sonst niemand beantworten kann: Woher stammen die Daten dieser Tabelle – aus welchem Import, welcher Quelle, welchem Dokument? Und wer hat sie seither gelesen oder verändert? Beides ist abgeleitet, nicht getrennt gepflegt, und kann deshalb nicht mit der Wirklichkeit auseinanderlaufen.
Was sonst noch schützt
| Maßnahme | Wirkung |
|---|---|
| Nur über den Reverse-Proxy erreichbar | Backend, Datenbank, Objektspeicher und der Keycloak-Backchannel liegen im internen Netz. |
| Verschlüsselte Geheimnisse | Quell-Passwörter, LLM- und Einbettungsschlüssel sowie OAuth-Material liegen AES-256-GCM-verschlüsselt und werden nie zurückgegeben, protokolliert oder auditiert. |
| TLS zu Quelldatenbanken | Voreinstellung verify – TLS mit Zertifikatsprüfung, je Quelle umstellbar. |
| Egress-Schutz | Admin-ausgelöste Verbindungstests und Einbettungsaufrufe erreichen keine Link-Local- oder Cloud-Metadaten-Adressen. Eine Allowlist kann weiter einschränken. |
| Isoliertes Dokumenten-Parsing | PDF- und Word-Extraktion läuft in einem begrenzten Worker mit hartem Zeitlimit. Ein bösartiges Dokument kann nur seinen eigenen Worker beenden. |
Stand: Diese Seite beschreibt lavalake 0.16.0. Produkt und Dokumentation liegen in getrennten Repositories – im Zweifel gilt, was die Konsole zeigt.
Etwas fehlt?
Wenn diese Seiten Ihre Frage nicht beantworten, zeigen wir die Plattform in einer halben Stunde an Ihrem Fall.
Demo vereinbaren