Zum Inhalt springen
Resilience Platform Resilience Platform

Trust Center · Multi-Tenant

Multi-Tenant Sicherheit & Isolation

Transparente Dokumentation der Mandantenfähigkeit: Datentrennung, Zugriffsisolation, Verschlüsselung und Prüfnachweise für Finanzinstitute.

Für Prüfer und Compliance-Verantwortliche: Dieses Dokument beschreibt die technische und organisatorische Umsetzung der Mandantentrennung in der Resilience Platform. Es dient als Nachweis für aufsichtsrechtliche Prüfungen und Due-Diligence-Bewertungen.

Management-Zusammenfassung

  • Jeder Mandant (Kunde) arbeitet in einer logisch vollständig isolierten Umgebung — Daten, Konfigurationen und Benutzer sind strikt getrennt.
  • Die Mandantentrennung erfolgt auf Datenbankebene (Row-Level-Tenancy) und wird durch Application-Level-Middleware und Policies abgesichert.
  • Cross-Tenant-Zugriff wird durch mehrschichtige Zugriffskontrollen verhindert: Middleware, Policy-Engine und automatisierte Tests.
  • Ein dediziertes Multi-Tenant-Isolation-Testsuite läuft bei jedem Deployment und blockiert bei Verstössen.

Architektur der Mandantentrennung

1

Authentifizierung

Nach Login wird der Mandantenkontext in der Session gespeichert. Jede nachfolgende Anfrage durchläuft den EnsureTenantSelected-Middleware.

2

Autorisierung

Jede Datenbankabfrage wird durch tenant_id-Filterung auf Model-Ebene begrenzt. Policies prüfen zusätzlich session-basiert.

3

Isolationsprüfung

Dedizierte Test Suite prüft bei jedem Deployment: Cross-Tenant-Zugriff muss 403/404 zurückgeben.

Isolationsschichten

Datenbank-Ebene (Row-Level Tenancy)

Aktiv

Jede Tabelle mit mandantenbezogenen Daten enthält eine tenant_id-Spalte. Alle Abfragen werden durch Global Scopes automatisch auf den aktuellen Mandanten eingeschränkt. Ein versehentliches Entfernen des Scopes wird durch die Test Suite erkannt.

Application-Ebene (Middleware)

Aktiv

Der EnsureTenantSelected-Middleware stellt sicher, dass vor jeder mandantenbezogenen Aktion ein gültiger Mandantenkontext in der Session vorhanden ist. Ohne Mandantenkontext werden geschützte Routen mit 403 abgewiesen.

Policy-Ebene (Autorisierung)

Aktiv

Jede Resource hat eine Policy, die den Zugriff auf Basis des current_tenant_id-Session-Wertes autorisiert. Cross-Tenant-Zugriff wird auf Policy-Ebene blockiert.

Session-Ebene (Tenant Switching)

Aktiv

Der Mandantenwechsel erfolgt über eine gesicherte Route, die die Session aktualisiert und alle berechtigten Datenkontexte neu lädt. Der Wechsel wird im Audit-Log protokolliert.

Sicherheitskontrollen

Kontrolle Umsetzung Nachweis Prüfbar
Mandantentrennung tenant_id-Scope auf Model-Ebene Global Scope + Code-Review Ja
Cross-Tenant-Schutz Middleware + Policy-Engine Isolation-Test-Suite Ja
Zugriffskontrolle Rollenbasiert (RBAC) Policy-Tests Ja
Audit-Logging tenant_id im Audit-Trail Log-Export Ja
Datenverschlüsselung TLS 1.3, AES-256 für Backups Pentest-Bericht Ja
Session-Management tenant_id in Session, HttpOnly-Cookies Code-Review Ja

Was bedeutet das für Ihren Mandanten?

✓

Ihre Daten sind isoliert

Kein anderer Mandant kann auf Ihre Daten zugreifen — technisch abgesichert durch Middleware, Policies und Datenbank-Scopes.

✓

Ihre Benutzer verwalten Sie selbst

Rollen und Berechtigungen gelten nur innerhalb Ihres Mandanten. Sie bestimmen, wer Zugriff hat.

✓

Prüfbare Nachweise

Die Isolation wird automatisiert getestet und dokumentiert. Ergebnisse stehen im Assurance Room für Prüfer bereit.

✓

Verschlüsselter Transport

Alle Daten werden mit TLS 1.3 übertragen. Backups sind AES-256-verschlüsselt und mandantengetrennt.

Häufige Fragen (FAQ)

Kann ein anderer Mandant auf meine Daten zugreifen?
Nein. Der Zugriff auf Daten ist auf mehreren Ebenen geschützt: (1) Datenbank-Queries werden automatisch auf Ihre tenant_id eingeschränkt, (2) die Policy-Engine autorisiert jeden Zugriff, (3) eine automatisierte Test Suite prüft bei jedem Deployment die Isolation. Cross-Tenant-Zugriff wird mit 403 Forbidden abgewiesen.
Werden meine Daten mit anderen Mandanten auf dem gleichen Server gespeichert?
Ja, die Datenbank ist eine Shared-Instance. Die Mandantentrennung erfolgt logisch über die tenant_id-Spalte. Dies ist ein standardkonformes Modell für SaaS-Anwendungen (ISO 27001, BSI C5 konform). Jeder Mandant sieht ausschliesslich seine eigenen Daten.
Kann ich mein Unternehmen als separaten Mandanten mit eigenem Admin einrichten?
Ja. Jeder Kunde erhält einen eigenen Mandanten mit eigenem Administrator, eigenen Benutzern, eigenen Rollen und eigener Konfiguration. Der Mandantenwechsel erfolgt über das Portal-Dashboard und wird protokolliert.
Gibt es einen Nachweis der Mandantenisolation für meine Revision?
Ja. Die Multi-Tenant-Isolation-Testsuite wird bei jedem Deployment ausgeführt. Die Testergebnisse werden revisionssicher dokumentiert. Auf Anfrage stellen wir einen Isolation-Nachweis für Ihre Prüfer zur Verfügung. Zusätzlich finden Sie im Assurance Room (nach NDA) detaillierte Architektur- und Sicherheitsdokumente.

Verwandte Ressourcen

🔒

Assurance Room

Dokumente nach NDA

 📋

ISO 27001 Evidenz

Kontrollmatrix

Isolationsstatus

Row-Level Tenancy
Middleware-Schutz
Policy-Engine
Isolation-Tests
Audit-Logging

ISO 27001 Verbindung

ISO 27001:2022 Kontrollen für Mandantentrennung und Zugriffsisolation.

  • A.5.1 Informationssicherheitsrichtlinien
  • A.5.31 Rücknahme von Vermögenswerten
  • A.5.36 Einhaltung von Vorschriften
  • A.8.2 Zugriffsberechtigungen
  • A.8.3 Zugangskontrolle
  • A.8.15 Protokollierung
  • A.8.16 Überwachung

ISO/IEC 27001:2022 dient als Kontrollanker und Management-System-Referenz. Die Verbindung zu ISO 27001 unterstützt integrierte Resilienz- und Sicherheitsprogramme.

Reifegrad

  1. 1 Initial

    Ad-hoc-Ansätze, keine formalen Prozesse

  2. 2 Defined

    Formale Prozesse definiert, aber nicht durchgängig umgesetzt

  3. 3 Implemented

    Prozesse vollständig umgesetzt und dokumentiert

  4. 4 Monitored

    Prozesse werden überwacht und gemessen

  5. 5 Optimized

    Kontinuierliche Verbesserung und Anpassung