Im Rahmen der Security Masterclass-Reihe von Aikido sprach Mackenzie Jackson mit Bill Harmer (CISO, Supabase) und Etienne Stalmans (Security Engineer, Supabase), um zu erörtern, wie Supabase Sicherheit als integralen Bestandteil des Designs betrachtet und nicht als etwas, das später hinzugefügt wird.
Von Row Level Security (RLS) bis hin zu den Risiken von KI-gestützter Programmierung konzentrierte sich die Diskussion darauf, was es braucht, um schnell zu entwickeln und sicher zu bleiben.
Sicherheit beginnt mit den Daten
Die Philosophie von Supabase beginnt mit den Daten selbst.
„Wir haben Supabase aus der Sicht eines Entwickelnden aufgebaut. Alles beginnt mit den Daten. Warum sekundäre Schichten aufbauen, wenn man alles an einem Ort kontrollieren kann.“ – Bill Harmer, CISO Supabase
Anstatt die Sicherheitslogik über verschiedene Dienste zu verteilen, bringt Supabase sie näher an den Ort, wo die Daten liegen. Je näher die Kontrolle, desto geringer ist die Wahrscheinlichkeit, dass etwas schiefgeht.
Aufbauen nach ersten Prinzipien
Für Etienne ändert dieser Ansatz die Denkweise von Entwickelnden beim Erstellen von Software.
„Wenn man Sicherheit näher an die Daten bringt, beginnt man, sie von ersten Prinzipien aus zu betrachten. Sobald es Klick macht, beschleunigt man die Entwicklung und bleibt zuversichtlich, dass es sicher ist.“ – Etienne Stalmans, Security Engineer Supabase
Indem Datenhoheit und -zugriff Teil des Anwendungsdesigns werden, entfernen Teams das Rätselraten, das mit geschichteten Berechtigungssystemen einhergeht.
Anonym oder authentifiziert
Supabase hält die Zugriffskontrolle einfach. Benutzer sind entweder anonym oder authentifiziert, nichts dazwischen.
„Alle Datenaktualisierungen müssen protokolliert werden: wer, was, wann und warum. Anonyme Benutzer erhalten eingeschränkten Zugriff. Authentifizierte Benutzer erhalten genau das, was sie benötigen, und nicht mehr.“ – Bill Harmer, CISO Supabase
Etienne demonstrierte dies während der Session mithilfe einer Live-Rezept-Sharing-App.
Öffentliche Rezepte waren für jeden sichtbar. Private Rezepte waren nur für ihre Besitzer oder bestimmte freigegebene Benutzer sichtbar.
Einige wenige SQL-Zeilen, unterstützt durch Row Level Security, verwalteten das gesamte Modell.
Row Level Security ist nicht verhandelbar.
RLS definiert, wer welche Datenzeilen sehen oder ändern kann. Es ist eine der leistungsstärksten Funktionen in Postgres und eine der am einfachsten zu übersehenden.
„Es braucht nur eine fehlende Überprüfung, und alles ist offengelegt.“ – Etienne Stalmans, Security Engineer Supabase
Etienne teilte ein Beispiel, bei dem eine KI-generierte Richtlinie versehentlich jeden Datensatz in einer Tabelle zurückgab, weil sie eine Bedingung übersprang.
Die Lösung war eine einzelne Korrektur an der Abfrage, eine Zeile, die eine große Sicherheitslücke schloss.
Bill fasste es einfach zusammen:
„Wir wollen Sicherheit so nah wie möglich an den Daten. Je näher sie ist, desto weniger Raum gibt es für Fehler.“ – Bill Harmer, CISO Supabase
Testen Ihrer Richtlinien mit pgTAP
Sicherheit endet nicht, sobald die App ausgeliefert wird. Etienne zeigte, wie Supabase pgTAP verwendet, um Datenbankrichtlinien kontinuierlich zu testen.
„Man kann beweisen, dass das, was man für sicher hält, es auch tatsächlich ist. Diese Tests halten Sie ehrlich.“ – Etienne Stalmans, Security Engineer Supabase
Jeder Test prüft, was am wichtigsten ist:
- Öffentliche Benutzer sehen nur öffentliche Daten
- Authentifizierte Benutzer sehen nur das, was ihnen gehört
- Richtlinien erzwingen jedes Mal die erwarteten Grenzen
Diese kontinuierliche Absicherung stellt sicher, dass kleine Fehler nicht zu Datenlecks werden.
Skalierbare Sicherheit
Supabase betreibt RLS für Millionen von Benutzern und große Workloads ohne Probleme.
„Wir betreiben es überall, selbst in großem Maßstab. Keine Probleme, keine Ausreden.“ – Etienne Stalmans, Security Engineer Supabase
Durch die Durchsetzung von Sicherheit auf Datenbankebene hält Supabase die Logik konsistent, egal wie komplex die Anwendung wird.
„Einfach zum Laufen bringen“ – die gefährliche Anweisung
Bill beendete die Sitzung mit einer Warnung für jeden, der KI zur Codegenerierung verwendet.
„Nur weil es funktioniert, heißt das nicht, dass es produktionsreif ist.“ – Bill Harmer, CISO Supabase
„Wenn Sie einer KI sagen, sie soll etwas zum Laufen bringen, könnte sie genau die Sicherheitsüberprüfungen entfernen, die Sie schützen.“ – Bill Harmer, CISO Supabase
KI-Modelle verstehen keine Absicht. Sie werden alles tun, um das von Ihnen gesetzte Ziel zu erreichen, selbst wenn das bedeutet, RLS zu deaktivieren oder die Authentifizierungslogik zu löschen.
Die Gefahr ist nicht die Nutzung von KI, sondern die Nutzung ohne Anleitung.
„Das Modell ist nicht bösartig. Es macht seine Arbeit. Aber es kennt Ihre Absicht nicht. Das ist Ihre Aufgabe.“ – Bill Harmer, CISO Supabase
Sicher bauen per Standard
Sicherheit ist kein Hindernis. Sie ermöglicht es, schneller voranzukommen, ohne die gelieferten Ergebnisse infrage zu stellen.
Supabase beweist, dass, wenn Sicherheit auf der Datenebene angesiedelt ist, sie Teil der Entwicklung wird und nicht nur ein nachträglicher Gedanke.
