Security & Trust

Sicherheit ist
Architektur, kein Siegel.

Relpin erzwingt Isolation, Identität und Least Privilege auf Plattformebene — per Default fail-closed. Wir sind in der offenen Beta und halten bislang keine Zertifizierungen. Was heute existiert, ist die Architektur unten.

Relpin Security Posture
Fail-closed
01 Tenant-Isolation

DB-per-org Postgres; per-App isolierte Workers

02 Verifizierte Identität

Spoofbare Header entfernt; Identität serverseitig injiziert

03 Least Privilege

Runtime- und DDL-Rollen getrennt; begrenzte Grants

04 Append-only Audit

Zeilengenaue Historie auf DB-Privileg-Ebene erzwungen

Offene Beta · Noch keine Zertifizierungen · Garantien auf Architekturebene
Tenant-Isolation

Jede Org läuft im
eigenen Blast Radius.

Isolation ist strukturell, kein Filter auf einer geteilten Tabelle. Jede Organisation erhält eine dedizierte Postgres-Datenbank, Schemas pro Workspace und Umgebung sowie eine eigene isolierte Runtime — auf jeder Ebene durch Least-Privilege-Rollen getrennt.

01
DB-per-org Postgres

Jede Organisation erhält eine dedizierte Postgres-Datenbank. Es gibt keine geteilte Multi-Tenant-Tabelle, über die etwas durchsickern könnte.

02
Per-App isolierte Runtime

Apps deployen als isolierte per-Tenant Cloudflare Workers auf Workers for Platforms — keine App erreicht eine andere.

03
Least-Privilege-Rollen

Runtime-Rollen und DDL-Rollen sind getrennt. Tenant-Code läuft nie mit schema-ändernden Privilegien.

Jede Org läuft auf einer dedizierten Postgres-Datenbank, nicht auf einer geteilten Tabelle
Schemas sind pro Workspace und pro Umgebung begrenzt
Apps deployen als isolierte per-Tenant Workers hinter einem fail-closed Dispatch-Router
Der Dispatch-Router entfernt vom Client gelieferte Identity-Header und injiziert verifizierte Identität
DB-per-org · Schemas pro Workspace+Umgebung · Isolierte Workers · Fail-closed Dispatch
Zwei Trust-Domains

Operatoren kommen nicht
in Ihre Apps.

Produktoberflächen und die Operator-Console laufen auf getrennten Authentifizierungs-Domains. Operator-Zugriff wird bei jedem Request neu gegen eine Allowlist berechnet, sodass ein Entzug sofort greift — und Operator-Credentials können sich nie in eine Kunden-App authentifizieren.

Product Domain

Kunden-Apps und Studio-Oberflächen. Nur verifizierte Org-Mitglieder.

Operator Domain

Operator-Console. Allowlist pro Request neu berechnet; Entzug ist sofort wirksam.

01
Getrennte Auth-Domains

Produkt und Operator-Console sind eigenständige Trust-Boundaries mit eigenständigen Credentials.

02
Allowlist pro Request

Operator-Autorisierung wird bei jedem Request neu berechnet. Ein Entzug ist sofort wirksam, nicht irgendwann.

03
Kein domainübergreifender Login

Operator-Credentials können sich nicht in Kunden-Apps authentifizieren — die beiden Domains vertrauen einander nie.

Produktoberflächen und die Operator-Console nutzen getrennte Authentifizierungs-Domains
Operator-Zugriff wird pro Request gegen eine Allowlist neu berechnet
Der Entzug von Operator-Zugriff ist sofort wirksam
Operator-Credentials können sich nie in eine Kunden-App authentifizieren
Getrennte Auth-Domains · Allowlist pro Request · Sofortiger Entzug
Secrets & Credentials

Credentials bleiben
plattformseitig.

User-Code referenziert Secrets; er erhält nie deren Werte. Datenbank-Credentials und Provider-Secrets bleiben serverseitig und erreichen nie den Browser, den User-Code oder Logs. Die Container-Preview erhält Credentials über einen isolierenden Sidecar, und jeder Zugriff wird auditiert.

01
Nur serverseitige Referenzen

Apps halten Secret-Referenzen, keine Secret-Werte. Der Klartext verlässt nie die Plattformgrenze.

02
Nie in Browser, Code oder Logs

Credentials werden nicht an den Browser ausgegeben, in User-Code injiziert oder in Logs geschrieben.

03
Sidecar-isolierte Preview

Die Container-basierte Live-Preview erhält Credentials über einen credential-isolierenden Sidecar-Proxy.

Apps referenzieren Secrets serverseitig; Werte erreichen nie den Browser oder User-Code
Credentials werden nie in Logs geschrieben
Die Live-Preview erhält Credentials über einen isolierenden Sidecar, nicht über die User-Runtime
Secret-Zugriffe werden auditiert
i Relpin speichert serverseitige Secret-Referenzen. Ein Managed Vault und Auto-Rotation sind heute nicht Teil des Produkts.
Serverseitige Referenzen · Keine Browser-Exposition · Sidecar-Isolation · Zugriff auditiert
Access Control

Jeder begrenzte Request
wird serverseitig geprüft.

Permission Keys werden auf dem Server ausgewertet, bevor eine Aktion läuft — der Browser hält die Entscheidung nie. Custom Roles nutzen Pattern Grants, per-App Runtime-Policies entscheiden, wer jede App erreicht, und Managed Accounts sind an geclaimte E-Mail-Domains gebunden.

01
Permission Keys, serverseitig

Jeder begrenzte Request löst einen Permission Key auf der Plattform auf, bevor die Aktion ausgeführt wird.

02
Custom Roles, Pattern Grants

Org-definierte Rollen gewähren Zugriff über globale, exact-key oder Prefix-Wildcard-Muster.

03
Per-App Access-Policies

Runtime-Zugriff wird auf Rolle, benannte User, Workspace oder editors-only begrenzt — erzwungen am Edge.

Permission Keys werden bei jedem begrenzten Request serverseitig geprüft
Custom Roles gewähren Zugriff über globale, exact-key und Prefix-Wildcard-Muster
Per-App Runtime-Policies begrenzen Zugriff auf Rolle, benannte User, Workspace oder editors-only
Managed Accounts werden über geclaimte E-Mail-Domains bereitgestellt
Serverseitige Keys · Pattern Grants · Per-App Policies · Geclaimte Domains
Audit & Betrieb

Append-only Historie,
durch die Datenbank erzwungen.

Jede User-Tabelle erfasst zeilengenaue Before/After-Diffs mit der handelnden Identität bei Insert, Update und Delete. Die Audit-Tabelle ist append-only — erzwungen durch DB-Privilegien, nicht durch Konvention in der App. Operative Guardrails laufen per Default fail-closed.

01
DB-erzwungenes Append-only

Tenant-Rollen erhalten nur SELECT und INSERT auf die Audit-Tabelle. Historie lässt sich nicht ändern oder löschen.

02
Zeilengenaue Field-Diffs

Trigger erfassen Before/After-Werte und den Actor bei jedem Insert, Update und Delete.

03
Fail-closed Guardrails

Statement- und Lock-Timeouts, Pagination-Caps, per-org Concurrency-Limits und fail-closed Quotas sind Defaults.

Die Audit-Tabelle ist append-only, erzwungen auf DB-Privileg-Ebene
Die zeilengenaue Historie erfasst Field-Diffs und die handelnde Identität
Jede Tenant-Transaktion trägt Statement- und Lock-Timeouts sowie Pagination-Caps
Promotion erfordert Approvals: TEST braucht 1, PROD braucht 2, mit Separation of Duties
Append-only Audit · Zeilengenaue Diffs · Fail-closed Guardrails · Promotion-Approvals
Compliance, klar gesagt

Was wir haben und
was nicht.

Ehrlichkeit gehört zur Posture. Wir behaupten keine Zertifizierungen, die wir nicht halten, und keine Controls, die wir nicht gebaut haben.

Heute verfügbar
DB-per-org Postgres-Isolation mit Least-Privilege-Rollen
Injektion verifizierter Identität und fail-closed Dispatch
Serverseitige Secret-Referenzen mit sidecar-isolierter Preview
Append-only, DB-erzwungenes Audit mit zeilengenauen Field-Diffs
Serverseitiges RBAC mit Custom Roles und per-App Policies
Gated DEV→TEST→PROD-Promotion mit Separation-of-Duties-Approvals
Geplant
+ SOC 2-, ISO 27001- und HIPAA-Zertifizierungen
+ Compliance-Reporting
+ Realtime-Audit-Streaming und SIEM-Integration
+ Managed Secrets Vault und Auto-Rotation

Relpin hält heute keine SOC 2-, ISO 27001- oder HIPAA-Zertifizierungen. Compliance-Reporting ist geplant. Was heute existiert, ist die Architektur oben.

Jetzt verfügbar · Geplant · Keine Zertifizierungen behauptet
Security & Trust

Architektur, die Sie prüfen,
bevor Sie vertrauen.

Relpin gibt Engineering- und Plattform-Teams Isolation, verifizierte Identität und Least Privilege als Plattform-Defaults — nicht als Checkliste, die später aufgesetzt wird.

Tenant-Isolation · Verifizierte Identität · Least Privilege · Append-only Audit

Produkt in offener Beta. Garantien auf Architekturebene. Keine Zertifizierungen behauptet.