Dokumentation

Architektur

Multi-Tenant-Modell mit einer Datenbank, Postgres Row-Level Security über account_id und Modul-Schalter je Arbeitsbereich.

Architektur

DARION-AI läuft als Multi-Tenant-SaaS auf einer gemeinsamen Datenbank. Alle Mandanten teilen sich eine Postgres-Instanz. Die Trennung passiert über Row-Level Security in der Datenbank. Jede Tabelle mit Mandantenbezug führt eine Spalte account_id, und jede Zeile gehört genau einem Arbeitsbereich.

Eine Datenbank für alle Mandanten

  • Eine Postgres-Instanz mit drei Knoten hält alle Mandanten.
  • Ein gemeinsames Schema für alle Module, getrennt durch account_id je Tabelle.
  • Geringe Betriebskosten, weil kein Schema je Mandant nötig ist.
  • Migrationen laufen einmal und gelten für alle Mandanten.

Postgres Row-Level Security

Tabellen mit Mandantenbezug tragen eine RLS-Policy. Diese Policy prüft über die Funktion has_role_on_account(account_id), ob der angemeldete Nutzer Mitglied des Arbeitsbereichs ist. Die Prüfung läuft in der Datenbank, nicht in der Anwendung. Ein Zugriff ohne Mitgliedschaft liefert kein Ergebnis.

Die Identität kommt aus dem Supabase-Token. Postgres liest sie über auth.uid() direkt aus der Sitzung. Es gibt keine Zwischenschicht, die eine Mandanten-Kennung selbst setzen müsste.

Weg einer Anfrage

Browser → Cloudflare → Traefik im K3s-Cluster
                              │
                              ▼
                    Next.js (Server Components)
                              │ Supabase-Client mit Nutzer-Token
                              ▼
                    PgBouncer → Postgres mit RLS

Modul-Schalter je Arbeitsbereich

Welche Module es überhaupt gibt, steht in der Datei modules.config.ts im Code. Der Katalog umfasst 24 Module. Davon sind 21 nutzbar, 3 sind noch nicht verfügbar.

Der Haupt-Inhaber eines Arbeitsbereichs kann einzelne Module ein- und ausblenden. Öffne dazu Einstellungen im Arbeitsbereich. Der Schalter steuert die Sichtbarkeit in der Navigation. Er löscht keine Daten und sperrt keine Tabelle.

Ein Administrator sieht dieses Feld nicht. Nur der Haupt-Inhaber darf Module schalten.

Berechtigungen auf Anwendungsebene

Innerhalb eines Arbeitsbereichs gilt zusätzlich das Rollensystem mit Inhaber, Administrator und Mitglied. Die Rolle gilt für den ganzen Arbeitsbereich, nicht je Modul. Mitglieder dürfen nur lesen. Mehr dazu in Berechtigungen.

Replikation und Sicherung

  • CloudNativePG betreibt drei Postgres-Knoten mit einem Primary und zwei Replicas.
  • barman-cloud schreibt Sicherungen und WAL-Dateien auf Synology C2 Object Storage.
  • Verschlüsselung mit AES256 und gzip-Komprimierung für Daten und WAL.
  • Aufbewahrung 30 Tage in der Sicherungsablage.

Sicherheits-Schichten

  • Cilium-Netzwerkregeln zwischen den Diensten im K3s-Cluster.
  • Supabase Auth für Anmeldung und Sitzungen. Zwei-Faktor ist für den Betreiberbereich Pflicht.
  • External Secrets Operator holt Zugangsdaten aus 1Password. Im Code steht kein Geheimnis.
  • Strikte Content-Security-Policy in der Produktivumgebung.

Was es noch nicht gibt

  • Keine getrennte Datenbank je Mandant.
  • Keinen Schreib-Schutzmodus, der die Daten eines abgeschalteten Moduls einfriert.
  • Keine unveränderliche Ablage (WORM) für Sicherungen.

Verwandt