6 Gemeinsam genutzter Speicher für mehrere Geschäftsbereiche oder Kunden erfordert eine starke Isolation. Mandantenfähigkeit mit strikter Speicherisolation ist kein Zusatzfeature, sondern ein Fundament. Sie entscheidet darüber, ob eine gemeinsame Infrastruktur Bedrohungen eindämmt oder sie auf alle Mandanten ausweitet. Für CISOs und Sicherheitsarchitekten, die Objektspeicher in mandantenfähigen Umgebungen bewerten, lautet die Kernfrage: Kann Ihre Speicherschicht harte Grenzen zwischen Mandanten durchsetzen? Ein kompromittierter Endpunkt, ein böswilliger Administrator oder eine Anwendungsschwachstelle bei einem Mandanten darf nicht bis zu den Daten eines anderen reichen. Scheitert die Umsetzung, drohen Bußgelder, Kundenabwanderung und Vorfälle, die bis in den Vorstand reichen. Dieser Beitrag erläutert, was Isolation bedeutet, wie starke Isolation in gemeinsam genutzter Infrastruktur funktioniert und was Ihr Sicherheitsteam bei der Bewertung von Speicherlösungen verlangen sollte. Mandantenrisiken und Schadensradius verstehen Gemeinsam genutzte Infrastruktur bietet echte betriebliche Vorteile: Kosteneffizienz, zentrale Verwaltung und einfachere Audits. Die gemeinsame Nutzung bringt jedoch ein kritisches Risiko mit sich: Eine einzige Kompromittierung betrifft alle Mandanten im gesamten Unternehmen oder Kundenstamm. Nehmen wir einen kompromittierten Anwendungsserver in einem Geschäftsbereich. Eine saubere Isolation dämmt diese Kompromittierung ein. Der Angreifer kann sich nicht auf den Speicher anderer Mandanten ausbreiten, deren Daten lesen oder auf die zugrunde liegende Infrastruktur eskalieren. Ohne Isolation wird aus der Kompromittierung eine Katastrophe – mit sofortigem Zugriff auf alle Mandantendaten, das geistige Eigentum aller Geschäftsbereiche und Kundendaten. Verhindern lässt sich das nur mit technischen Mechanismen: Richtlinien, Namespace-Grenzen, kryptografischen Kontrollen und einer Zugriffsdurchsetzung, die sowohl stark als auch überprüfbar ist. Ihre Sicherheitsarchitektur muss drei Kernfragen beantworten: Können Sie die Isolation der Namespaces garantieren? Mandanten müssen logisch und physisch so isoliert sein, dass kein Mandant den Namespace eines anderen sehen kann – selbst mit Administratorrechten. Das geht über die Benennung von Buckets hinaus: Entscheidend ist, ob das zugrunde liegende Speichersystem harte Grenzen durchsetzt. Wer Identitäts- und Zugriffsmanagement (IAM) auf der Speicherebene umsetzt, sorgt für belastbare Grenzen. Werden Zugriffskontrollen auf der Speicherebene durchgesetzt? Setzen Sie Kontrollen auf der Speicherebene selbst durch, nicht in Middleware auf Anwendungsebene. Kontrollen auf Anwendungsebene lassen sich umgehen, Kontrollen auf der Speicherebene nicht. Können Sie die Isolation unabhängig überprüfen? Audit- und Compliance-Teams müssen nachprüfen können, dass die Isolation tatsächlich besteht. Dafür braucht es Audit-Trails, kryptografische Nachweise und Belege dafür, dass ein Sicherheitsvorfall andere Mandanten nicht betroffen hat. Namespace-Isolation als erste Verteidigungslinie durchsetzen Die Isolation in mandantenfähigem Speicher beginnt mit der Trennung der Namespaces. Ein Namespace ist der logische Container – Bucket, Container oder Objekthierarchie –, der die Daten eines Mandanten enthält. Eine starke Namespace-Isolation verhindert, dass ein Mandant den Namespace eines anderen entdeckt, liest oder beschreibt, selbst mit Zugangsdaten für den zugrunde liegenden Speicher. Es handelt sich dabei nicht um eine „Zugriff verweigert“-Antwort, sondern um eine architektonische Eigenschaft: Die Anfrage wird an den Isolationsgrenzen strukturell ungültig. Viele Systeme setzen die Namespace-Isolation auf API- oder Kontoebene um – angemessen für Single-Tenant-Umgebungen oder Deployments mit geringer Isolation. Bei mandantenfähigen Enterprise-Architekturen für externe Kunden sollten Sie die Isolation auf Ebene der Speicher-Engine durchsetzen. So bleibt die Isolation auch bei kompromittierten Zugangsdaten bestehen. Gestalten Sie die Architektur so: Binden Sie jeden Namespace kryptografisch oder logisch an die Identität des Mandanten. Behandeln Sie den Namespace-Zugriff nicht als Berechtigung, die neu vergeben wird. Behandeln Sie die Namespace-Identität als untrennbar von der Mandantenidentität. Mehrstufige Zugriffskontrollen implementieren Sobald die Namespace-Isolation steht, verfeinern Sie die Zugriffskontrolle. Kontrollen auf Bucket-Ebene setzen Richtlinien durch: wer lesen, schreiben, löschen und Berechtigungen ändern darf. Viele Vorfälle entstehen nicht durch einen ersten unbefugten Zugriff, sondern durch eine übermäßige Anhäufung von Berechtigungen. Ein Entwicklerkonto erhält berechtigterweise Lese- und Schreibzugriff. Diese Berechtigungen werden nie überprüft oder entzogen. Monate später wird das Konto kompromittiert, und der Angreifer verfügt über Rechte zum Lesen, Schreiben, Löschen und Ändern von Berechtigungen. Ihre Architektur muss das Least-Privilege-Prinzip granular durchsetzen. Ein Dienstkonto, das Backup-Daten schreibt, sollte keine Löschberechtigung haben. Administratorkonten sollten keinen pauschalen Zugriff auf alle Mandanten haben. Beschränken Sie Berechtigungen auf bestimmte Buckets und Aktionen. Mit einer Zero-Trust-Architektur lassen sich die Grenzen weiter härten. Kontrollen auf Objektebene fügen eine weitere Schicht hinzu. Manche Architekturen benötigen Berechtigungen auf Objektebene, damit ein Mandant bestimmte Objekte mit einem anderen teilen kann. Falls nötig, setzen Sie dies kryptografisch durch. Mandanten dürfen keine Berechtigungen fälschen können; Berechtigungen müssen überprüfbar und widerrufbar sein. Ihre Kontrollen sind nur so stark wie Ihr Management der Zugangsdaten. Langlebige, breit verteilte oder unzureichend überwachte Zugangsdaten untergraben die Kontrollen. Behandeln Sie den Lebenszyklus von Zugangsdaten als sicherheitskritisch. Kryptografische Trennung für durchsetzbare Garantien Für manche Deployments genügt eine logische Isolation durch Namespaces und Zugriffskontrollen. Für andere – insbesondere bei regulierten Daten oder externen Kunden mit vertraglichen Isolationsgarantien – liefert die kryptografische Trennung eine zusätzliche, durchsetzbare Garantie. In kryptografisch getrennten Architekturen werden die Daten jedes Mandanten mit eigenen Schlüsseln verschlüsselt. Das Speichersystem wird gemeinsam genutzt, die Schlüssel nicht. So bleiben die Daten selbst bei physischem Zugriff oder einer Kompromittierung der Speicherschicht ohne den Schlüssel des Mandanten unlesbar. Kryptografische Trennung erfordert mehrere architektonische Elemente. Verwalten Sie Schlüssel getrennt vom Speicher – mit einem zentralen Key-Management-Service. Protokollieren und auditieren Sie Schlüsselzugriffe. Erzwingen Sie die Schlüsselrotation. Eine Kompromittierung des Key-Management-Systems wird zur Kompromittierung aller Mandanten; daher muss für das KMS dieselbe Isolation gelten wie für den Speicher. Der Vorteil: Kryptografische Trennung ist unabhängig überprüfbar. Sie können Auditoren, Compliance-Teams und Kunden nachweisen, dass ihre Daten mit Schlüsseln verschlüsselt sind, die sie selbst kontrollieren. Ohne diese Schlüssel kann das Speichersystem nichts entschlüsseln. Das schafft eine Sicherheit, die logische Isolation allein nicht bieten kann. Isolation durch Auditing kontinuierlich überwachen Die Isolation zwischen Mandanten muss kontinuierlich überprüft und auditiert werden. Audit-Logging ist nicht nur eine Compliance-Pflicht, sondern ein Sicherheitsmechanismus, der Verletzungen der Isolationsgrenzen erkennt. Erfassen Sie Zugriffe auf die gemeinsame Infrastruktur so detailliert, dass Sie nachvollziehen können, ob ein Mandant auf den Namespace eines anderen zugegriffen hat. Es geht nicht um nachträgliche Log-Auswertung, sondern um einen Echtzeit-Ereignisstrom, den Ihr Sicherheitsteam überwacht. Anomalien – Mandanten, die auf Objekte außerhalb ihres Namespace zugreifen, ungewöhnliche Nutzung von Zugangsdaten, Änderungen an Berechtigungen – sollten Alarme auslösen. Zur Compliance-Überprüfung gehören regelmäßige, unabhängige Isolationstests. Ihr Sicherheitsteam sollte regelmäßig validieren, dass kompromittierte Zugangsdaten eines Mandanten keinen Zugriff auf Daten anderer Mandanten gewähren, dass das Löschen von Objekten in einem Namespace andere nicht beeinträchtigt und dass Administratorzugänge die Isolationskontrollen nicht umgehen können. Speicherlösungen sorgfältig bewerten Testen Sie bei der Auswahl einer mandantenfähigen Speicherlösung die Isolationseigenschaften gezielt. Fordern Sie Whitepaper und Architekturdokumentation an, die die Durchsetzung der Isolation beschreiben. Fragen Sie, wie Zugangsdaten eingegrenzt werden und ob sie unabhängig voneinander widerrufen werden können. Prüfen Sie die Unterstützung kryptografischer Isolation und ob das Schlüsselmanagement vom Speicher entkoppelt ist. Testen Sie die Zugriffskontrollen direkt: Können kompromittierte Zugangsdaten auf nicht autorisierte Daten zugreifen? Lässt sich die Isolation über Audit-Logs überprüfen? Bewerten Sie vor allem die Sicherheitshistorie. Gab es Verletzungen der Isolation, sollten Sie verstehen, wie es dazu kam und ob architektonische Änderungen sie künftig verhindern. Mandantenfähige Architektur mit Zuversicht aufbauen Isolation zwischen Mandanten ist erreichbar, erfordert aber eine bewusste Architektur und kontinuierliche Überprüfung. Ihre Sicherheitslage hängt davon ab, dass Sie verstehen, wie Isolation umgesetzt, aufrechterhalten und überprüft wird. Die vertrauenswürdigste mandantenfähige Infrastruktur entsteht dort, wo CISOs und Speicherarchitekten die Isolationsanforderungen vom ersten Tag an festlegen. Sicherheitsteams halten die Disziplin, kontinuierlich zu auditieren. Das ist keine einmalige Implementierung, sondern eine dauerhafte Verpflichtung, die Grenzen in gemeinsam genutzter Infrastruktur aufrechtzuerhalten. Eine starke Datenverschlüsselung ergänzt die Isolation und sorgt für Defense in Depth. Betrachten Sie Isolation nicht als optionale Erweiterung, sondern als zentrale Sicherheitseigenschaft. Sie entscheidet, ob Ihre gemeinsame Infrastruktur Bedrohungen eindämmt oder vervielfacht. Dieser Unterschied prägt das Risikomanagement Ihres Unternehmens grundlegend. Weiterführende Artikel AES-Verschlüsselung für die Sicherheit von Unternehmensdaten Was ist SIEM? Multi-Faktor-Authentifizierung (MFA) Modell der geteilten Verantwortung Was ist das NIST Cybersecurity Framework? Best Practices für Datensouveränität DSGVO-Anforderungen an die Datenspeicherung
