Isolation der Tenanten und Grenzen

Die Isolierung von Tenanten und Grenzen ist das Fundament einer multi-tenanten Architektur. Das Ziel: dass die Handlungen eines Mieters niemals die Daten, die Sicherheit und das SLO eines anderen beeinflussen und die Ressourcen fair und vorhersehbar verteilt werden. Nachfolgend finden Sie eine praktische Lösungskarte von der Datenebene über die Berechnungsplanung bis zum Incident Management.

1) Bedrohungsmodell und Ziele

Drohungen

Datenleck zwischen Mietern (logisch/per Cache/über Protokolle).
„Noisy neighbor“: Leistungsminderung durch Spitzen bei einem Kunden.
Berechtigungseskalation (Fehler in der Zugriffsrichtlinie).
Abrechnungsdrift (Nichtübereinstimmung von Nutzung und Gebühren).
Kaskadierende fehlertolerante Szenarien (ein Vorfall führt zu einem Downtime von vielen).

Ziele

Strikte Isolierung von Daten und Geheimnissen.
Per-tenante Grenzen/Quoten und faire Planung.
Transparente Auditierung, Beobachtbarkeit und Abrechnung.
Lokalisierung von Vorfällen und schnelle Wiederherstellung per tenant.

2) Isolationsstufen (Durchlaufmodell)

1. Daten

'tenant _ id' in Schlüsseln und Indizes, Row-Level Security (RLS).
Verschlüsselung: KMS-Hierarchie → Mieterschlüssel (KEK) → Datenschlüssel (DEK).
Getrennte Schaltungen/OBD bei hohen Anforderungen (Silo), Gesamtcluster c RLS für Effizienz (Pool).
Politiker sind retenschna und „Recht auf Vergessen“ per tenant, crypto-shredding Schlüssel.

2. Berechnungen

CPU/RAM/IO-Quoten, Worker-Pools pro Tenant, „gewichtete“ Warteschlangen.
GC/Heap Isolation (JVM/Laufzeitcontainer/Einstellungen), Grenzen für Parallelismus.
Per-tenant autoscaling + backpressure.

3. Netz

Segmentierung: private Endpunkte/VPC, ACL durch 'tenant _ id'.
Rate Begrenzung und per-tenant Verbindung caps an der Grenze.
Schutz vor DDoS/Bots unter Berücksichtigung des Plans/der Priorität.

4. Aktivitäten und Prozesse

Paarmigrationen, Backups, DRs, Feature-Flags.
Vorfälle - „Mikro-Blast-Radius“: Fusionieren nach 'tenant _ id'.

3) Zugangskontrolle und Mieterkontext

AuthN: OIDC/SAML; Token tragen 'tenant _ id', 'org _ id', 'plan', 'scopes'.
AuthZ: RBAC/ABAC (Rollen + Attribute Projekt, Abteilung, Region).
Kontext an der Grenze: Das API-Gateway extrahiert und validiert den Kontext des Tenants, ergänzt mit Limits/Quoten, schreibt in Traces.
Prinzip „Doppelsperre“: Überprüfung im Service + RLS/OBD-Richtlinie.

4) Daten: Schemata, Cache, Protokolle

• Shared-Schema (Row-Level): Maximale Effizienz, striktes RLS ist Pflicht.
• Per-Schema: Der Kompromiss Isolation/Operationalität.
• Per-DB/Cluster (Silo): für VIP/einstellbar.

Cache: Schlüsselpräfixe' tenant: {id}:...', TTL nach Plänen, Schutz gegen cache-stampede (lock/early refresh).

Logs/Metadaten: vollständige Pseudonymisierung der PII, Filter nach 'tenant _ id', Verbot des „Klebens“ von Logs verschiedener Mieter.

5) Begrenzung von Verkehr und Betrieb

Grundmechanik

Token Bucket: geglättete Bursts, Parametrisierung 'rate '/' burst'.
Leaky Bucket: Stabilisierung des Durchbruchs.
Fixed Window/Sliding Window: einfache/genaue Kontingente nach Zeitfenster.
Concurrency limits: Caps für gleichzeitige Anfragen/Jobs.

Wo anwenden

An der Grenze (L7/API-Gateway) - Grundschutz und „Quick Failure“.
Im Kern (in Diensten/Warteschlangen) - für den zweiten Kreislauf und „Fair Share“.

Richtlinien

Nach Tenant/Plan/Endpoint/Operationstyp (öffentliche APIs, schwere Exporte, Admin-Aktionen).
Priority-aware: VIP erhält ein größeres' Burst 'und Gewicht bei der Schlichtung.
Idempotency-keys für sichere Retrays.

Beispielprofile (Konzepte)

Starter: 50 req/s, burst 100, 2 parallele Exporte.
Geschäft: 200 req/s, burst 400, 5 Exporte.
Enterprise/VIP: 1000 req/s, burst 2000, engagierte Worker.

6) Quoten und faire Planung (Fairness)

Ressourcenkontingente: Speicher, Objekte, Meldungen/min, Aufträge/Stunde, Größe der Warteschlangen.
Weighted Fair Queuing/Deficit Round Robin: „gewichteter“ Zugang zu gemeinsamen Workern.
Per-tenant Arbeiterpools: harte Isolierung für laute/kritische Kunden.
Admissionskontrolle: Ausfall/Degradation vor der Ausführung, wenn die Kontingente ausgeschöpft sind.
Backoff + Jitter: exponentielle Verzögerungen, um Spitzen nicht zu synchronisieren.

7) Beobachtbarkeit und Abrechnung per tenant

Erforderliche Tags: 'tenant _ id', 'plan', 'region', 'endpoint', 'status'.
SLI/SLO per tenant: p95/p99 latency, error rate, availability, utilization, saturation.
Usage-Metriken: Zähler für CPU-Operationen/Bytes/Sekunden → Aggregator → Rechnungen.
Idempotenz der Abrechnung: Schnappschüsse an der Grenze, Schutz vor doppelten Abschreibungen/Ereignisverlust.
Dashboards in Segmenten: VIP/regulierte/neue Mieter.

8) Vorfälle, Degradierung und DR „nach Mietern“

Fusionieren durch 'tenant _ id': Notabschaltung/Drosselung eines bestimmten Mieters ohne Einfluss auf den Rest.
Graceful Degradation: Read-only-Modus, Warteschlangen in der „Sandbox“, verzögerte Aufgaben.
RTO/RPO per tenant: Wiederherstellungs- und Verlustziele für jeden Plan.
Übung: regelmäßige „Spieltage“ mit Ausfall des lärmenden Mieters und DR-Check.

9) Compliance (Wohnsitz, Privatsphäre)

Pinning Tenant zur Region; klare Regeln für regionalübergreifende Ströme.
Schlüssel-/Datenzugriffsprüfung, Protokollierung von Admin-Operationen.
Retention und Datenexport per tenant verwalten.

10) Mini-Referenz: wie man zusammenbringt

Anforderungsablauf

1. Edge (API-Gateway): TLS → 'tenant _ id' extrahieren → Token validieren → rate/quotas anwenden → Traces platzieren.
2. Polysi-Engine: Kontext 'tenant _ id/plan/features' → Entscheidung über Route und Limits.
3. Service: Rechteüberprüfung + Labels' tenant _ id '→ Arbeit mit DB unter RLS → Cache mit Präfix.
4. Verwendung-Sammlung: Betriebs-/Bytezähler → Aggregator → Abrechnung.

Daten

Schema/DB nach Strategie (row-level/per-schema/per-DB).
KMS: Schlüssel zum Mieter, Rotation, Crypto-Shredding beim Löschen.

Berechnungen

Warteschlangen mit Gewichten, Worker-Pools per Tenant, Caps per Concurrency.
Autoscaling durch per-tenante Metriken.

11) Pseudo-Politik (zur Orientierung)

yaml limits:
starter:
req_per_sec: 50 burst: 100 concurrency: 20 exports_parallel: 2 business:
req_per_sec: 200 burst: 400 concurrency: 100 exports_parallel: 5 enterprise:
req_per_sec: 1000 burst: 2000 concurrency: 500 exports_parallel: 20

quotas:
objects_max: { starter: 1_000_000, business: 20_000_000, enterprise: 100_000_000 }
storage_gb: { starter: 100,   business: 1000,    enterprise: 10000 }

12) Checkliste vor dem Verkauf

• Eine einzige Quelle der Wahrheit „tenant _ id“; Überall wird gepinkelt und protokolliert.
• RLS/ACL auf OBD-Ebene aktiviert + Service Check (Doppelverriegelung).
• Verschlüsselungsschlüssel per tenant, Rotation/Löschung dokumentiert (crypto-shredding).
• Grenzen/Quoten an der Grenze und innerhalb; Bursts und „Burst“ getestet.
• Fair-queuing und/oder dedizierte Worker für VIPs; caps на concurrency.
• Per-tenante SLOs und Alerts; Dashboards nach Segmenten.
• Die Nutzungsgebühr ist idempotent; Abrechnung mit Abrechnung geprüft.
• DR/Incidents werden vor dem Mieter lokalisiert; Fusionieren durch 'tenant _ id' funktioniert.
• Der Cache/die Protokolle sind nach Mietern aufgeteilt; PII ist maskiert.
• Verfahren für Migrationen/Backups/Exporte - Nachmietverfahren.

13) Typische Fehler

RLS vom „Service“ -Benutzer deaktiviert/umgangen - Leckagerisiko.
Eine einzige globale Grenze → „noisy neighbor“ und SLO-Verletzung.
Gemeinsame Caches/Warteschlangen ohne Präfixe → Datenüberschneidung.
Die Abrechnung zählt nach den Protokollen, die bei Spitzen verloren gehen.
Das Fehlen von Pairing Fusioning - kaskadierende Stürze.
Migrationen „auf einen Schlag“ ohne die Möglichkeit, das Problem zu stoppen 'tenant _ id'.

14) Schnelle Strategieauswahl

Reguliert/VIP: Silo-Daten (per-DB), engagierte Worker, strenge Quoten und Residency.
Massive SaaS: Shared-Schema + RLS, starke Grenzen an der Grenze, Fair-Queuing im Inneren.
Last „laut/pulsierend“: große' burst'+ harte concurrency-caps, backpressure und Prioritäten für die Pläne.

Schlussfolgerung

Bei der Isolation von Tenanten und Grenzen geht es um Grenzen und Gerechtigkeit. Ein klares' tenant _ id 'durch Stack, RLS und Verschlüsselung auf Daten, Limits und Quoten an der Grenze und im Kern, ein fairer Planer, Beobachtbarkeit und Lokalisierung von Vorfällen - all das zusammen gibt Sicherheit, vorhersehbare Qualität und transparente Abrechnung für jeden Mieter, auch bei aggressivem Plattformwachstum.