Supabase für Berufsgeheimnisträger

Supabase soll für eine Kanzlei, Praxis oder andere Organisation mit Berufsgeheimnissen betrieben oder migriert werden? Supabase-Betrieb für Berufsgeheimnisträger einordnen.

Supabase ist für KI-generierte Anwendungen, Portale und interne Fachsoftware attraktiv, weil PostgreSQL, Authentifizierung, Storage, Realtime, APIs und Functions in einer Plattform zusammenkommen. Genau diese Breite macht die Prüfung für Berufsgeheimnisträger jedoch anspruchsvoller: Ein Datenbankstandort allein beschreibt nicht, wo Identitäten, Dateien, Protokolle und serverseitige Funktionen verarbeitet werden.

Eine sinnvolle Einordnung beginnt deshalb bei der Anwendung und betrachtet Supabase als vollständige Plattform.

Welche Supabase-Komponenten betroffen sein können

Eine Anwendung kann beispielsweise in PostgreSQL nur Fallnummern speichern, während vollständige Dokumente im Storage liegen. Umgekehrt können Datenbank-Functions sensible Inhalte verarbeiten, obwohl das Frontend sie nur verkürzt anzeigt.

Supabase Cloud oder Self-Hosting?

Beide Modelle haben unterschiedliche Verantwortungsgrenzen.

Supabase Cloud

Der Plattformanbieter betreibt die von ihm bereitgestellte Umgebung. Edition, Region, Funktionen, Supportweg, Dienstleister und Vertragsunterlagen müssen zur konkreten Verarbeitung geprüft werden. Die Supabase-Dokumentation zur Sicherheitsgrenze weist ausdrücklich darauf hin, dass Kontrollen innerhalb des Supabase-Produkts nicht automatisch auf Umgebungen außerhalb dieser Grenze übergehen.

Self-Hosted Supabase

Der Open-Source-Stack läuft auf eigener oder verwalteter Infrastruktur. Dadurch lassen sich Betriebsort, Netzwerk und Dienstleister anders gestalten. Gleichzeitig übernimmt der Betreiber zusätzliche Verantwortung für:

• Härtung und Secrets
• Updates der einzelnen Supabase-Komponenten
• PostgreSQL- und Plattform-Upgrades
• Monitoring und Alarmierung
• Datenbank- und Storage-Backup
• Wiederherstellung und Skalierung
• SMTP, Domains und externe Dienste

Die offizielle Self-Hosting-Dokumentation macht deutlich, dass Self-Hosting nicht denselben Managed-Funktionsumfang wie Supabase Cloud bereitstellt. Fehlende Cloud-Funktionen müssen bei Bedarf im Zielbetrieb ersetzt werden.

Self-Hosting ist deshalb kein automatischer Compliance-Schalter. Es erweitert die Kontrolle und zugleich die Betriebsverantwortung.

RLS und Mandantentrennung

Browser- und Mobile-Anwendungen greifen häufig direkt über die Supabase Data API zu. Row Level Security kann Zugriffe auf Zeilenebene begrenzen. Für Mandanten- oder Patientendaten sollte die Prüfung unter anderem beantworten:

• Ist RLS auf allen exponierten Tabellen aktiviert?
• Gibt es Policies für Lesen, Schreiben, Ändern und Löschen?
• Werden anonyme und authentifizierte Rollen getrennt?
• Können Nutzer ihre Mandanten- oder Organisationszuordnung verändern?
• Sind Views, Functions und RPC-Aufrufe passend abgesichert?
• Welche Komponenten verwenden service_role oder andere privilegierte Rollen?
• Stimmen Storage-Regeln und Datenbankberechtigungen überein?

Policies sollten gegen reale Nutzerwege getestet werden. Reines Lesen des SQL-Codes übersieht leicht Kombinationen aus JWT-Claims, Views und serverseitigen Funktionen.

Authentifizierung ist mehr als die Nutzertabelle

Supabase Auth verarbeitet Identitäten, Sitzungen und Token. Zum Zielbild gehören:

• erlaubte Login-Methoden und OAuth-Provider
• MFA-Anforderungen
• Redirect-URLs und Domainwechsel
• SMTP und Inhalte von Auth-E-Mails
• Lebensdauer und Rotation von Tokens und Secrets
• Sperrung, Löschung und Export von Nutzerkonten
• administrative Nutzerverwaltung

Bei einer Migration können Passwort-Hashes, Providerverknüpfungen oder bestehende Sitzungen besondere Behandlung erfordern. Der Migrationsplan sollte festhalten, ob Nutzer unterbrechungsfrei übernommen werden können oder sich neu anmelden müssen.

Storage, Functions und externe Datenwege

Storage-Buckets und Edge Functions bilden häufig die größten blinden Flecken.

Für Storage sind zu prüfen:

• öffentliche und private Buckets
• signierte URLs und deren Gültigkeit
• Objektpfade und Mandantentrennung
• Dateitypen, Größenlimits und Malware-Prüfung
• Metadaten und tatsächliche Dateiobjekte im Backup

Für Functions sind relevant:

• verwendete Secrets und API-Schlüssel
• ausgehende Verbindungen
• Webhooks und externe Empfänger
• Protokollierung von Request und Response
• Deployment- und Versionsweg
• Fehlerverhalten und Wiederholungen

Eine Function kann die geschützte Information an einen externen Dienst weitergeben, auch wenn Datenbank und Storage vollständig in einer kontrollierten Umgebung laufen.

Backup und Wiederherstellung

Ein PostgreSQL-Dump allein stellt Supabase nicht vollständig wieder her. Ein belastbares Konzept umfasst:

1. Datenbank mit Schema, Rollen, Daten und benötigten Extensions
2. Storage-Dateien und zugehörige Metadaten
3. Functions und deren Deploymentstand
4. Konfiguration und Secrets in einem getrennten Schutzmodell
5. Auth-, SMTP-, Domain- und Providerkonfiguration
6. dokumentierten Restore in eine leere Zielumgebung

Aufbewahrung und Löschung müssen auch zusätzliche Kopien berücksichtigen. Der Artikel Supabase vollständig sichern vertieft die technischen Ebenen.

Migration in ein kontrolliertes Zielmodell

Ein vorhandenes Cloud-, Lovable- oder Firebase-Backend sollte nicht direkt im ersten Lauf umgeschaltet werden. Der sichere Pfad ist:

1. Komponenten und Abhängigkeiten inventarisieren.
2. Zielumgebung mit Netzwerk, Auth, Backup und Monitoring vorbereiten.
3. Datenbank, Storage, Functions und Konfiguration testweise übertragen.
4. RLS und fachliche Nutzerwege in der Zielumgebung prüfen.
5. Cutover, Wartungsfenster und Rückfallpunkt festlegen.
6. produktive Umschaltung durchführen und dokumentiert abnehmen.

Nach der Migration kann das Entwicklungsteam die Anwendung weiter mit den gewohnten KI- und Entwicklungswerkzeugen bearbeiten. Git-Pushes werden über die vereinbarte Build- und Deploymentstrecke mit der neuen Supabase-Umgebung verbunden. Je nach Kritikalität sind getrennte Staging- und Produktionsumgebungen, Freigaben, Datenbankmigrationsprüfungen und Rollback vorgesehen.

Für den allgemeinen Ablauf gibt es die Supabase-Migrationscheckliste. WZ-IT bietet die technische Supabase-Migration ab 3.490 Euro netto an; der konkrete Aufwand wird vorab anhand des tatsächlichen Scopes angeboten.

Passende WZ-IT-Angebote

• Die Supabase-Migration ab 3.490 Euro netto ist ein eigenständiger Einstieg für Supabase Cloud, Firebase, Lovable und weitere Ausgangssysteme. Der Ab-Preis legt keinen pauschalen Leistungsumfang fest.
• Managed Supabase deckt Installation, Managed Hosting und laufenden Betrieb der Zielplattform ab.
• Der AI Code & Production Readiness Audit prüft die mit Supabase verbundene Anwendung, insbesondere Auth, RLS, Secrets und Deployment.
• Die §203 Managed Cloud für Supabase ergänzt diese allgemein verfügbaren Leistungen für Berufsgeheimnisse um das dafür vorgesehene Betriebsmodell.

Quellen

• Supabase-Dokumentation: Architektur
• Supabase-Dokumentation: Self-Hosting
• Supabase-Dokumentation: Row Level Security
• Supabase-Dokumentation: Security and compliance boundary
• § 203 StGB - Verletzung von Privatgeheimnissen