Datenisolation zwischen Umgebungen

Jede KeenAuth-Umgebung (development, staging, production in jedem Ihrer Projekte) ist ein eigener Mandant. Benutzer, Organisationen, Anwendungen, Sitzungen, Schlüssel, Protokolle und Ereignisse einer Umgebung sind für keine andere Umgebung sichtbar, auch nicht für eine andere Umgebung Ihres eigenen Kontos. Diese Seite erklärt, wie diese Grenze durchgesetzt wird.

Zwei unabhängige Verteidigungslinien

Umgebungen teilen sich ein Datenbankschema, und jede Zeile, die zu einer Umgebung gehört, trägt die Kennung dieser Umgebung. Die Isolation wird zweimal erzwungen. Damit Daten die Grenze überschreiten können, müssen beide Prüfungen gleichzeitig fehlschlagen:

  1. Typisierter Umgebungsbezug in der Anwendung. Jede Anfrage wird vor dem Lesen von Daten anhand ihres Hostnamens oder ihrer Zugangsdaten genau einer Umgebung zugeordnet. Code, der Umgebungsdaten liest oder schreibt, kann ohne diesen Bezug keine Datenbanktransaktion öffnen. Ein Aufruf ohne ihn wird abgelehnt, bevor die Abfrage ausgeführt wird.
  2. Zeilenbasierte Sicherheit in PostgreSQL (Row-Level Security). Jede Tabelle mit Umgebungsdaten hat Row-Level Security aktiviert und erzwungen, sodass die Richtlinie auch für den Tabellenbesitzer gilt. Jede Transaktion setzt die aktuelle Umgebung, und eine Zeile ist nur sichtbar, wenn ihre Umgebung übereinstimmt. Eine Transaktion, die keine Umgebung gesetzt hat, sieht keine Zeilen. Keine Anwendungs- oder Wartungsrolle darf Row-Level Security umgehen.

Jede Tabelle mit Umgebungsbezug beginnt ihren Primärschlüssel und ihre Indizes mit der Umgebungskennung, sodass die Isolationsbedingung keine zusätzliche Suche in Abfragen erzeugt.

Suchen über Token oder Schlüssel

Manche Anfragen enthalten nur einen geheimen Wert, zum Beispiel einen Autorisierungscode, ein Refresh-Token oder einen API-Schlüssel. KeenAuth findet einen solchen Wert über eine reine Digest-Suche und vergleicht danach die Umgebung des gespeicherten Datensatzes mit der Umgebung der Anfrage. Weichen beide ab, wird der Wert als ungültig behandelt.

Was Sie sehen, wenn Sie die Grenze überschreiten

Versuch Antwort
Eine Ressource lesen, die zu einer anderen Umgebung gehört 404 Not Found; die Antwort verrät nicht, dass die Ressource existiert
Ein Zugriffstoken verwenden, das von einer anderen Umgebung ausgestellt wurde 401 Unauthorized; jede Umgebung hat einen eigenen Aussteller und eigene Signaturschlüssel (JWKS)
Sich mit einem Client authentifizieren, der in einer anderen Umgebung registriert ist invalid_client

Jenseits der Datenbank

Dieselbe Grenze gilt für alle anderen Orte, an denen Umgebungsdaten liegen:

Das Übertragen von Konfiguration von einer Umgebung in eine andere (Konfigurationsübernahme) kopiert nur Einstellungen. Geheimnisse sowie Daten von Endbenutzern oder Organisationen sind nie Teil eines Übernahmepakets.

So wird die Isolation getestet

Eine Testsuite zur Mandantenisolation läuft in der Continuous Integration von KeenAuth und blockiert eine Änderung, wenn sie fehlschlägt. Sie prüft:

Eine Schemaprüfung lehnt zudem jede neue Datentabelle für Umgebungen ohne die Spalte mit der Umgebungskennung ab.

Verwandte Themen