Eine Datenbank pro Organisation
Jede Organisation erhält eine eigene Postgres-Datenbank, statt Kundendatensätze in einer gemeinsamen Anwendungstabelle zu teilen.
Mandantenisolation
Operative Daten jeder Organisation bleiben hinter einer eigenen Datenbankgrenze.
Relpin stellt jeder Organisation eine eigene Postgres-Datenbank bereit. Ein vertrauenswürdiger Runtime-Kontext bestimmt Organisation und Umgebung, bevor schemaqualifizierte serverseitige Abfragen ausgeführt werden.
assignments · dev 12 columns · 5 rows
| Employee | Project | Status | Alloc |
|---|---|---|---|
| Mina Alvarez | Northwind Rollout | ACTIVE | 40% |
| Jonah Kim | Atlas Migration | ACTIVE | 75% |
| Priya Nwosu | Northwind Rollout | PLANNED | 30% |
| Lena Richter | Mercury Support | BLOCKED | 55% |
server-side SQL · statement + lock timeouts on every transaction
Das Isolationsproblem
Eine Mandanten-ID in einer Browseranfrage ist keine Datengrenze.
Authentifizierung stellt die Identität fest. Autorisierung begrenzt erlaubte Aktionen. Mandantenisolation stellt zusätzlich sicher, dass Runtime-Arbeit nur die Organisation und Umgebung erreicht, die durch vertrauenswürdigen serverseitigen Kontext festgelegt wurden.
Isolationsebenen
Organisationsdaten werden getrennt, bevor Anwendungscode sie erreicht.
Relpin verbindet eine dedizierte Organisationsdatenbank mit explizitem Umgebungsbezug und kontrolliertem serverseitigem Zugriff.
Umgebungsbezogene Schemas
DEV, TEST und PROD verwenden standardmäßig explizite Schemas innerhalb der Organisationsdatenbank. Jede Abfrage ist für die gewählte Umgebung qualifiziert.
Vertrauenswürdiger Mandantenkontext
Die Runtime bestimmt Organisations- und Umgebungsbezug auf dem Server, statt diese Werte aus nicht vertrauenswürdigen Browser-Headern zu übernehmen.
Runtime-Pfad
Kontext bestimmen, Zugriff qualifizieren, dann ausführen.
Der Isolationspfad bleibt vom authentifizierten Organisationskontext bis zur finalen Datenbankanweisung explizit.
- 01
Organisation bestimmen
Relpin prüft Sitzung und Organisationsmitgliedschaft an der vertrauenswürdigen Dispatch-Grenze, bevor Runtime-Code Kontext erhält.
- 02
Umgebung auswählen
Die Runtime bindet die Anfrage an DEV, TEST oder PROD und wendet das zugehörige Schema sowie operative Limits an.
- 03
Serverseitig ausführen
Abfragen verwenden schemaqualifizierte Bezeichner und parametrisierte Werte gegen die bestimmte Organisationsdatenbank.
Isolationsnachweise
Dediziertes Postgres pro Organisation
Expliziter DEV/TEST/PROD-Bezug
Schemaqualifiziertes serverseitiges SQL
Vertrauenswürdiger Runtime-Identitätskontext
Fragen zur Isolation
Wie Relpin Mandantendaten und Umgebungsbezug trennt.
Ist Authentifizierung dasselbe wie Mandantenisolation?
Nein. Authentifizierung bestätigt die Identität, Autorisierung prüft Berechtigungen. Mandantenisolation begrenzt zusätzlich, welche Organisationsdatenbank und welches Umgebungsschema die Runtime erreichen kann.
Erhält jede Umgebung eine eigene Datenbank?
Nicht standardmäßig. Jede Organisation erhält eine dedizierte Datenbank; DEV, TEST und PROD werden durch explizite Schemas getrennt. Eine Datenbank pro Umgebung ist eine Enterprise-Isolationsoption und keine Standardzusage.
Kann Anwendungscode über einen geänderten Header eine andere Organisation auswählen?
Nein. Die vertrauenswürdige Dispatch-Grenze entfernt nicht vertrauenswürdige Relpin-Kontext-Header und stellt der Runtime verifizierten Organisations-, Benutzer- und Umgebungskontext bereit.
Isolation vor Anwendungslogik
Interne Tools auf einer organisationsspezifischen Datengrenze bauen.
Mandantenrouting, Umgebungsbezug und Datenbankzugriff bleiben auf einem kontrollierten serverseitigen Pfad.
Open Beta · Kein SLA