Zeilenebenen-Sicherheit — AiHummer Dokumente

AiHummer ist mandantenfähig, und seine stärkste Isolationsgrenze liegt in der Datenbank selbst: PostgreSQL Zeilenebenen-Sicherheit (RLS). Mit aktiviertem RLS erzwingt die Datenbank — nicht nur der Anwendungscode —, dass eine Abfrage nur die Zeilen sieht, die dem aktuellen Mandanten gehören.

Warum RLS

Anwendungs-Ebene-Filterung (WHERE tenant_id = ...) ist notwendig, aber fragil: Eine einzige vergessene Klausel kann Daten zwischen Mandanten durchleiten. RLS verschiebt die Garantie in PostgreSQL, sodass selbst eine ungefilterte Abfrage nur die Zeilen des aktuellen Mandanten zurückgibt. Es ist eine Verteidigung-in-Tiefe-Schicht unterhalb des eigenen Scopings der Anwendung. Für das breitere Multitenanzmodell — und wie es mit idempotenten Nebeneffekten zusammenarbeitet — siehe Mandantenfähigkeit & Idempotenz.

Die eingeschränkte Rolle (opt-in)

RLS ist zustimmen und wird aktiviert, indem dem Gateway eine zweite Datenbankverbindung gegeben wird, die eine eingeschränkte Rolle anstelle des Eigentümers verwendet:

# /home/.aihummer/etc/gateway.env
# Owner pool — runs migrations, used for system/bypass operations
AIHUMMER_DATABASE_URL=postgres://owner:...@localhost/aihummer

# Restricted application pool — RLS policies apply (aihummer_app role)
AIHUMMER_DB_APP_URL=postgres://aihummer_app:...@localhost/aihummer

Der aihummer_app Rolle ist nicht dem Tabellenbesitzer, sodass PostgreSQL RLS-Richtlinien darauf anwendet. Anwendungsabfragen fließen durch diesen eingeschränkten Pool. Die Aktivierung von RLS ist eine Frage der Einstellung AIHUMMER_DB_APP_URL — und Lokale/Standard-(host-native)-Installationen setzen diese Variable automatisch ein., sodass RLS sofort aktiviert ist. Es ist nur insofern „optional“, als dass eine benutzerdefinierte oder manuelle Bereitstellung dies festlegen muss AIHUMMER_DB_APP_URL selbst.

[!NOTE] Ohne AIHUMMER_DB_APP_URL, das Gateway verwendet den Besitzer-Pool für alles und RLS wird effektiv nicht durchgesetzt. Legen Sie den eingeschränkten Pool fest (der standardmäßiger Installer macht für Sie), um die Isolation auf Datenbankebene einzuschalten.

[!IMPORTANT] RLS hängt nicht von der Tarifstufe ab. Es arbeitet auf jedem Tarif gleich, Community eingeschlossen. Zeigt die Lizenzseite „Zeilenebenen-Sicherheit“ als nicht verfügbar, ist das eine Ungenauigkeit dieser Anzeige und nicht der Zustand Ihrer Datenbank.

Wo RLS sofort aktiv ist und wo Sie es einschalten müssen

Wie Sie installiert haben	RLS nach der Installation
Standardinstallation, der Installer richtet PostgreSQL ein	Aktiv. Die eingeschränkte Rolle und `AIHUMMER_DB_APP_URL` werden automatisch angelegt
Eigenes oder verwaltetes PostgreSQL (Datenbankadresse vorgegeben)	Nicht aktiv. Rolle und `AIHUMMER_DB_APP_URL` legt der Betreiber an
Installation ohne Administratorrechte (rootless)	Nicht aktiv. Ebenso

[!WARNING] Zwei Fehler, nach denen RLS „an“ ist, aber nichts schützt. Erstens: AIHUMMER_DB_APP_URL zeigt auf den Tabelleneigentümer oder einen Superuser — PostgreSQL nimmt solche Rollen von den Richtlinien aus, und das Gateway meldet RLS trotzdem als aktiv. Verwenden Sie eine eigene eingeschränkte Rolle. Zweitens: auf eigenem PostgreSQL kann die eingeschränkte Rolle automatisch mit einem vorhersehbaren Passwort entstehen — vergeben Sie ein eigenes Passwort, bevor die Datenbank über das Netz erreichbar ist.

Pro-Mandanten-Abgrenzung

Innerhalb einer Anfrage legt die Anwendung den aktuellen Mandanten auf der Verbindung fest, bevor mandantenbezogene Abfragen ausgeführt werden – konzeptionell db.WithTenant. Sobald sie festgelegt sind, begrenzen RLS-Richtlinien auf der eingeschränkten Rolle jeden Lese- und Schreibzugriff auf die Zeilen dieses Mandanten. Der Umfang ist an die Arbeitseinheit gebunden, sodass er zwischen gleichzeitigen Anfragen nicht durchsickert.

request ─▶ resolve tenant ─▶ db.WithTenant(tenant) ─▶ queries see only that tenant

System-/Bypass-Modus für Arbeiter

Einige Arbeiten sind berechtigterweise mandantenübergreifend oder mandantenunabhängig – Hintergrundarbeiter, Planer, Lieferwiederherstellung und ähnliche Wartung. Für diese verwendet das Gateway eine System (Bypass)-Modus das im Besitzer-Pool läuft, außerhalb der RLS-Richtlinien pro Mieter, sodass Infrastrukturaufgaben über den gesamten Datensatz hinweg arbeiten können.

[!WARNING] Der Umgehungsmodus ist nur für vertrauenswürdige interne Mitarbeiter gedacht. Anfrageverarbeitende Codepfade die im Namen eines Benutzers handeln, müssen immer durch den eingeschränkten laufen, Mieter-spezifischer Pool — niemals der Umgehungspfad.

Migrationen laufen im Eigentümerpool

Schemaänderungen erfordern Berechtigungen, die die eingeschränkte Rolle nicht hat, also Migrationen laufen immer im Besitzer-Pool (AIHUMMER_DATABASE_URL), unter einem beratenden Sperre, beim Starten. Die eingeschränkte aihummer_app Die Rolle wird nur für gewöhnlichen Anwendungsverkehr verwendet. Dies hält die Trennung der Privilegien sauber: Schema-ändernde Operationen verwenden den Eigentümer; der Zugriff auf Mandantendaten verwendet die eingeschränkte Rolle mit angewendetem RLS.

Wohin als Nächstes

Mandantenfähigkeit & Idempotenz — das vollständige Mieter-Modell und wie Nebenwirkungen unter der Wiederherstellung sicher bleiben.
Geheimnisse Tresor — pro-Mieter DEKs verstärken dasselbe Isolation auf der Geheimnisebene.
RBAC & begrenzte API-Schlüssel — Autorisierung über die Datenebene.