Mandantentrennung in Verteidigungs-SaaS: klassifizierte Kunden in gemeinsam genutzter Infrastruktur trennen

Verteidigungs-SaaS-Plattformen stehen vor einer strukturellen Spannung, die zivile mandantenfähige Software nicht kennt. Ein kommerzieller SaaS-Anbieter sorgt sich um die logische Datentrennung zwischen Kunden, um eine versehentliche Offenlegung zu verhindern. Ein Verteidigungs-SaaS-Anbieter muss eine weitaus stärkere Garantie erreichen: dass Daten, die einem klassifizierten Mandanten gehören, für einen anderen Mandanten nachweislich unerreichbar sind, selbst wenn ein Angreifer Code der Anwendungsschicht kompromittiert oder Administrator-Anmeldedaten erlangt hat. Die regulatorische Sprache ist streng: Eine unbefugte Offenlegung von SECRET-Daten an einen nicht freigegebenen Mandanten ist kein Datenschutzvorfall, sondern ein Spillage-Ereignis mit rechtlichen und operativen Konsequenzen. Dieser Artikel untersucht, wie Mandantentrennung in Verteidigungs-SaaS-Plattformen, die Mandanten auf unterschiedlichen Geheimhaltungsstufen, mit unterschiedlichen Datenresidenz-Anforderungen und unabhängigen Akkreditierungsgrenzen bedienen, gestaltet, implementiert und nachgewiesen wird, über eine Kubernetes-basierte klassifizierte Cloud-Infrastruktur hinweg.

Warum Mandantenfähigkeit komplex ist, wenn Mandanten unterschiedliche Geheimhaltungsstufen haben

Mandantenfähige Architektur in kommerzieller Software ist in erster Linie eine wirtschaftliche Entscheidung: Das Teilen von Rechenleistung, Datenbank und Betriebsaufwand über Kunden hinweg senkt die Bereitstellungskosten pro Kunde. In Verteidigungs-SaaS ist die Wirtschaftlichkeit weiterhin relevant, aber die durch die Klassifizierung auferlegten Isolationsanforderungen führen zu Einschränkungen, die kommerzielle mandantenfähige Muster nicht sofort erfüllen können. Wenn zwei Mandanten auf unterschiedlichen Geheimhaltungsstufen arbeiten, etwa einer auf SECRET und einer auf UNCLASSIFIED, können sie keine Datenbank-Engine, keinen Container-Scheduling-Pool und keinen kryptografischen Schlüssel-Namespace teilen, denn jede dieser gemeinsam genutzten Schichten könnte zu einem Kanal für unbefugte Datenübertragung werden, sei es durch direkte Abfrage-Fehlkonfiguration, Seitenkanal-Timing-Angriffe oder kompromittierte Betreiber-Werkzeuge.

Der Unterschied in der Geheimhaltungsstufe ist nicht der einzige erschwerende Faktor. Selbst Mandanten auf derselben Geheimhaltungsstufe können inkompatible Anforderungen haben, die eine starke Isolation verlangen: unterschiedliche nationale Datenresidenz-Gesetze, unterschiedliche Regeln zur Log-Aufbewahrung und zum Audit-Zugriff, unterschiedliche autorisierte Nutzerpopulationen und unterschiedliche genehmigte Cipher-Suites. Ein Mandant des britischen Verteidigungsministeriums und ein Mandant des US-Verteidigungsministeriums arbeiten möglicherweise beide auf der Stufe RESTRICTED/SENSITIVE, dürfen aber durch bilaterale Vereinbarung daran gehindert sein, ihre Daten auf derselben physischen Hardware verarbeiten zu lassen. Das Isolationsmodell muss daher gegen eine Matrix von Mandantenattributen gestaltet werden (Geheimhaltungsstufe, nationale Jurisdiktion, Audit-Behörde und genehmigtes kryptografisches Material) und nicht gegen ein einfaches hoch/niedrig-Binärschema.

Regulatorische Rahmenwerke erhöhen die Einsätze. Unter Rahmenwerken wie dem Cloud Computing Security Requirements Guide des US-Verteidigungsministeriums und der britischen Secure-by-Design-Leitlinie muss ein System, das vorgibt, klassifizierte Mandanten zu isolieren, die Isolation durch dokumentierte Kontrollen, unabhängige Tests und kontinuierliche Überwachung nachweisen und nicht lediglich behaupten. Ein genehmigender Verantwortlicher wird nach Belegen fragen: Netzwerkverkehrs-Aufzeichnungen, die keine mandantenübergreifenden Flüsse zeigen, Protokolle des Schlüsselverwaltungsdienstes, die keine mandantenübergreifende Schlüsselnutzung zeigen, und Datenbankabfrage-Protokolle, die keine mandantenübergreifenden Ergebnismengen zeigen. Architekturentscheidungen, die diese Belege schwer erbringbar machen, sind nicht nur technisch unbequem; sie sind Akkreditierungsblocker.

Datenbank-Isolationsstrategien: Schema-pro-Mandant, Datenbank-pro-Mandant und Instanz-pro-Mandant

Die Datenbankschicht ist der Ort, an dem die meisten Fehler bei der Mandantentrennung entstehen. Es gibt drei Muster, und die richtige Wahl hängt von den Klassifizierungs- und Audit-Anforderungen der Mandantenpopulation ab. Schema-pro-Mandant platziert die Tabellen jedes Mandanten in einem separaten Schema innerhalb einer einzigen Datenbank-Engine-Instanz. Die Zugriffskontrolle wird durch Datenbankrollen durchgesetzt, die auf jedes Schema beschränkt sind, und Richtlinien zur Sicherheit auf Zeilenebene bieten eine sekundäre Durchsetzungsschicht. Dieses Muster hat den geringsten Betriebsaufwand (eine Datenbank-Engine zum Patchen, Überwachen und Sichern) und ist angemessen, wenn alle Mandanten dieselbe Geheimhaltungsstufe teilen und die Isolationsanforderung logischer und nicht physischer Natur ist. Die Schwäche besteht darin, dass eine fehlkonfigurierte Rolle, eine Schwachstelle zur Rechteausweitung in der Datenbank oder eine Abfrage, die die Sicherheitsrichtlinie auf Zeilenebene umgeht, mandantenübergreifende Daten offenlegen kann. Für klassifizierte Umgebungen, in denen ein Spillage-Ereignis schwerwiegende Konsequenzen hat, ist es eine schwer zu verteidigende Position gegenüber einem genehmigenden Verantwortlichen, sich allein auf eine logische Isolation auf Schema-Ebene zu verlassen.

Datenbank-pro-Mandant weist jedem Mandanten eine dedizierte Datenbankinstanz zu, lässt diese Instanzen aber auf gemeinsam genutzter Recheninfrastruktur laufen. Der Datenbank-Engine-Prozess ist auf Betriebssystemebene isoliert, sodass ein fehlkonfiguriertes Schema oder ein kompromittiertes Anwendungs-Anmeldedatum die Daten eines anderen Mandanten nicht ohne eine separate Rechteausweitung auf Betriebssystemebene erreichen kann. Dieses Muster reduziert die mandantenübergreifende Angriffsfläche erheblich und ist das mindestens praktikable Isolationsmodell für Verteidigungs-SaaS, das Mandanten auf unterschiedlichen Geheimhaltungsstufen bedient. Die Betriebskosten sind proportional zur Anzahl der Mandanten: Jede Datenbankinstanz benötigt ihren eigenen Sicherungsplan, ihre eigene Überwachungskonfiguration, ihren eigenen Schema-Migrations-Workflow und ihren eigenen Verbindungspool. Bei Dutzenden von Mandanten ist dies mit gut konzipierter Plattformautomatisierung handhabbar; bei Hunderten erfordert es eine Datenbank-als-Dienst-Abstraktionsschicht, um den Betriebsaufwand begrenzt zu halten.

Instanz-pro-Mandant treibt die Trennung weiter, indem nicht nur der Datenbankprozess, sondern der gesamte Rechenknoten den Workloads eines einzelnen Mandanten gewidmet wird. Dies ist erforderlich, wenn die Akkreditierungsdokumentation des Mandanten eine physische Trennung verlangt, wenn mandantenübergreifende Timing-Seitenkanäle ein glaubwürdiges Bedrohungsmodell darstellen oder wenn die Daten des Mandanten niemals eine mit anderen Mandanten gemeinsam genutzte Netzwerkstruktur durchqueren dürfen. Die Kosten sind die volle Infrastrukturrechnung pro Mandant: dedizierte Knoten, dedizierter Speicher und in einigen Konfigurationen dedizierte Netzwerkhardware. Für die Mandanten der höchsten Geheimhaltungsstufe sind diese Kosten nicht verhandelbar; die Sicherheitsanforderung treibt die Architektur, nicht die Wirtschaftlichkeit. Plattformen, die eine Mischung von Geheimhaltungsstufen bedienen, implementieren oft ein gestuftes Modell: Schema-pro-Mandant für UNCLASSIFIED, Datenbank-pro-Mandant für SECRET, Instanz-pro-Mandant für TS/SCI, mit automatisierten Bereitstellungspipelines, die aus einer Mandanten-Onboarding-Konfigurationsdatei die korrekte Stufe aufbauen.

Kubernetes-Namespace-Isolation: RBAC, Netzwerkrichtlinien und Ressourcenkontingente pro Mandant

Die Container-Orchestrierung führt eigene mandantenübergreifende Expositionsvektoren ein, die die Datenbankisolation allein nicht adressiert. In einem Kubernetes-Cluster kann ein Pod in einem Namespace standardmäßig Netzwerkverkehr an Pods in jedem anderen Namespace senden, clusterweite Ressourcen auflisten, wenn sein Dienstkonto übermäßige Berechtigungen hat, und clusterweite CPU und Speicher verbrauchen, bis er benachbarte Workloads aushungert. Für eine Verteidigungs-SaaS-Plattform ist keine dieser Standardeinstellungen akzeptabel. Die Isolationshaltung muss als verbindliche Grundlinie zum Zeitpunkt der Cluster-Bereitstellung angewendet werden, durch Admission-Controller durchgesetzt werden, die nicht konforme Workload-Definitionen ablehnen, und kontinuierlich durch eine Richtlinien-Engine validiert werden, die bei Konfigurationsabweichungen Alarm schlägt.

Die RBAC-Richtlinie für mandantenfähiges Verteidigungs-Kubernetes beginnt mit dem Grundsatz, dass die Dienstkonten jedes Mandanten standardmäßig keine namespaceübergreifende Sichtbarkeit haben. Namespacebezogene Rollen werden gegenüber Cluster-Rollen bevorzugt; cluster-admin-Bindungen sind außerhalb des dedizierten Verwaltungs-Namespace des Plattformbetreibers verboten. NetworkPolicy-Ressourcen setzen in jedem Mandanten-Namespace eine Standard-Verweigerungshaltung durch: kein Ingress und kein Egress, sofern nicht ausdrücklich durch eine Richtlinienregel erlaubt. Erlaubte Flüsse sind eng gefasst: Ein Anwendungs-Pod eines Mandanten darf mit seinem eigenen Datenbank-Pod, dem gemeinsam genutzten Ingress-Controller und dem Endpunkt des Schlüsselverwaltungsdienstes kommunizieren, und mit nichts anderem. Prinzipien der Zero-Trust-Netzwerkarchitektur bilden dieses Modell direkt ab: Jeder Datenverkehrsfluss wird verifiziert, nichts wird implizit vertraut, nur weil es innerhalb der Clustergrenze entsteht.

ResourceQuota-Objekte verhindern, dass ein einzelner Mandant durch den Verbrauch unverhältnismäßiger Cluster-Ressourcen einen Denial-of-Service-Zustand gegen andere Mandanten auslöst. Jeder Namespace erhält Kontingente für CPU-Anforderung und -Limit, Speicher-Anforderung und -Limit, Speicher für Persistent-Volume-Claims und die Anzahl laufender Pods. LimitRange-Objekte legen Standard-Ressourcenanforderungen für Pods fest, die sie nicht ausdrücklich deklarieren, und verhindern so, dass unbeschränkte Workloads das Kontingentsystem umgehen. Für klassifizierte Workloads erweitern Node-Taints und Pod-Tolerations die Isolation in die physische Scheduling-Schicht: Knoten, die einem SECRET-Mandanten gewidmet sind, tragen einen Taint, der verhindert, dass UNCLASSIFIED-Pods auf ihnen eingeplant werden, und die Pod-Spezifikationen des SECRET-Mandanten tragen die entsprechende Toleration. Die Kombination aus Namespace-RBAC, NetworkPolicy, ResourceQuota und Node-Taints ergibt ein geschichtetes Isolationsmodell, das auditierbar ist: Jede Schicht ist dokumentiert, testbar und unabhängig überprüfbar.

Verschlüsselungsschlüssel-Isolation: separate Schlüsselhierarchien für jeden klassifizierten Mandanten

Verschlüsselung ist die Kontrolle, die die Datenisolation auch dann aufrechterhält, wenn die Isolation auf Infrastrukturebene versagt. Wenn die Daten eines SECRET-Mandanten mit einem Schlüssel verschlüsselt sind, auf den nur die autorisierten Prozesse dieses Mandanten zugreifen können, dann kann eine fehlkonfigurierte Netzwerkrichtlinie oder ein entkommener Container-Prozess die Daten nicht lesen, selbst wenn er Zugriff auf die rohen Speicher-Bytes erhält. Diese Garantie erfordert, dass die Verschlüsselungsschlüssel jedes Mandanten in einem kryptografischen Namespace verwaltet werden, der für andere Mandanten unzugänglich ist, nicht nur durch eine Richtlinie auf Anwendungsebene, sondern durch die eigene Zugriffskontroll-Durchsetzung des Schlüsselverwaltungsdienstes.

Die praktische Implementierung verwendet eine hierarchische Schlüsselstruktur. An der Wurzel steht ein mandantenspezifischer Schlüsselverschlüsselungsschlüssel (KEK), gespeichert in einer HSM-Partition (hardware security module) oder einem Namespace des Schlüsselverwaltungsdienstes, der auf die Dienstkonten dieses Mandanten beschränkt ist. Der KEK umschließt eine Reihe von Datenverschlüsselungsschlüsseln (DEKs), die von der Anwendung zur Verschlüsselung bestimmter Datenkategorien verwendet werden: einen DEK für operative Datensätze, einen für Audit-Protokolle, einen für Anhänge und so weiter. Die DEKs werden verschlüsselt zusammen mit den Daten gespeichert, die sie schützen; sie können nur von einem Prozess ausgepackt werden, dem Zugriff auf den KEK des Mandanten gewährt wurde. Wenn ein Angreifer einen DEK isoliert kompromittiert, kann er diese Datenkategorie entschlüsseln. Wenn er den KEK kompromittiert, kann er möglicherweise alle Daten des Mandanten entschlüsseln, aber er kann ihn nicht nutzen, um auf die Daten eines anderen Mandanten zuzugreifen, da der KEK des anderen Mandanten in einer separaten HSM-Partition oder einem separaten Schlüsselverwaltungs-Namespace mit völlig unabhängigen Zugriffsrichtlinien liegt. Confidential-Computing-Umgebungen erweitern dieses Modell, indem sie die DEK-Auspackoperation selbst innerhalb einer hardwareverifizierten vertrauenswürdigen Ausführungsumgebung schützen.

Die Schlüsselrotationsrichtlinie ist ebenso wichtig wie die Schlüsselstruktur. Ein Mandant, dessen KEK seit zwei Jahren nicht rotiert wurde, hat einen wachsenden Wirkungsradius: Jedes Anmeldedatum, das in den vergangenen zwei Jahren irgendwann kompromittiert wurde, gewährt potenziell weiterhin Zugriff auf alle unter diesem KEK verschlüsselten Daten. Verteidigungs-SaaS-Plattformen sollten eine automatisierte KEK-Rotation nach einem von der Klassifizierungsbehörde des Mandanten festgelegten Zeitplan erzwingen, typischerweise jährlich für SECRET, häufiger für höhere Geheimhaltungsstufen, und einen Rotations-Audit-Verlauf bereitstellen, der bei Akkreditierungsprüfungen sichtbar ist. Das Rotationsereignis selbst muss im Audit-Stream des Mandanten protokolliert, mit Zeitstempel versehen und der automatisierten Rotationsrichtlinie oder dem spezifischen Betreiberkonto zugeordnet werden, das es ausgelöst hat.

Durchsetzung der Datenresidenz: Mandantendaten innerhalb autorisierter Jurisdiktionen halten

Datenresidenz-Anforderungen für Verteidigungsmandanten sind oft bindende rechtliche Verpflichtungen statt Präferenzen. Ein Mandant, der unter nationaler Sicherheitsgesetzgebung tätig ist, kann daran gehindert sein, seine Daten auf Infrastruktur außerhalb seiner nationalen Jurisdiktion verarbeiten oder speichern zu lassen, ungeachtet der vertraglichen Zusicherungen des Cloud-Anbieters. Die Durchsetzung dieser Anforderungen in einer mandantenfähigen SaaS-Plattform erfordert mehr als das Markieren von Daten mit einem Jurisdiktionsetikett; sie erfordert architektonische Kontrollen, die verhindern, dass Daten die autorisierte Region physisch verlassen, kombiniert mit Audit-Belegen, dass diese Kontrollen über den gesamten Aufbewahrungszeitraum der Daten korrekt funktioniert haben.

Die primäre Kontrolle ist die Infrastrukturtopologie: mandantenspezifische Datenbankinstanzen, Speicher-Buckets und Rechenknoten-Pools werden ausschließlich in der Cloud-Region der autorisierten Jurisdiktion bereitgestellt. Die regionsübergreifende Replikation wird auf der Speicher- und Datenbankschicht für residenzbeschränkte Mandanten deaktiviert, selbst für Zwecke der Notfallwiederherstellung; ein Replikat in einer nicht autorisierten Jurisdiktion ist ungeachtet seines Zwecks ein Residenzverstoß. Das Notfallwiederherstellungsmodell für diese Mandanten muss In-Jurisdiktions-Redundanz verwenden: Bereitstellungen über mehrere Verfügbarkeitszonen innerhalb einer einzigen nationalen Cloud-Region, mit synchroner Replikation zwischen den Zonen. Diese Einschränkung zwingt Verteidigungs-SaaS-Architekten dazu, residenzbeschränkte Mandanten als eigenständige Infrastrukturpartitionen zu behandeln, statt sie als Parameter in einem einheitlichen globalen Bereitstellungsmodell zu betrachten.

Sekundäre Kontrollen adressieren die Datenpfade, die weniger offensichtlich residenzrelevant sind: Log-Weiterleitung, Überwachungstelemetrie und Support-Werkzeuge. Eine Plattform, die die Datenspeicherung korrekt auf eine autorisierte Region beschränkt, aber Anwendungsprotokolle an ein SIEM weiterleitet, das in einem anderen Land betrieben wird, hat eine Residenzlücke. Ebenso können Remote-Administrationssitzungen, die über die Workstation eines Support-Ingenieurs in einer nicht autorisierten Jurisdiktion laufen, Datenfragmente im Sitzungszustand mit sich führen. Verteidigungs-SaaS-Plattformen müssen jeden Datenpfad nachverfolgen, nicht nur den primären Anwendungsdatenpfad, und auf alle von ihnen Residenzkontrollen anwenden. Dies erfordert typischerweise separate Überwachungsinfrastruktur pro Residenzzone und strenge Kontrollen darüber, welche Betreiberkonten administrative Sitzungen gegen welche Mandantenumgebungen einleiten können.

Verwaltung von Akkreditierungsgrenzen: wer besitzt die ATO, wenn Mandanten Infrastruktur teilen

Die Grenzen der Betriebsgenehmigung (ATO, authorization to operate) werden in einer mandantenfähigen Verteidigungs-SaaS-Plattform strukturell mehrdeutig. Der Plattformanbieter betreibt die gemeinsam genutzte Infrastruktur (die Kubernetes-Steuerungsebene, den Schlüsselverwaltungsdienst, die Netzwerkstruktur, den Identitätsanbieter) und hält eine ATO, die diese Komponenten abdeckt. Jeder Mandant betreibt Anwendungs-Workloads und Daten, die auf dieser Infrastruktur aufsetzen, und kann eine separate ATO für seine eigene Systemgrenze halten. Die Frage, wo die Plattform-ATO endet und die Mandanten-ATO beginnt, ist kein theoretisches Anliegen: Sie bestimmt, wer für jede Sicherheitskontrolle verantwortlich ist, wer der genehmigende Verantwortliche für Änderungen an dieser Kontrolle ist und wer die Haftung trägt, wenn eine Kontrolle versagt.

Das Standardmodell ist eine geschichtete Verantwortungsmatrix. Die ATO des Plattformanbieters deckt alle Kontrollen auf Infrastrukturebene ab: physische Sicherheit der Rechenzentrumseinrichtungen, Patchen von Hypervisor und Container-Laufzeit, Konfiguration der Netzwerksicherheitsgruppen, Verfügbarkeit und Zugriffsprotokollierung des Schlüsselverwaltungsdienstes und die oben dokumentierten Isolationskontrollen. Das kontinuierliche Überwachungsprogramm des Plattformanbieters muss Belege erbringen, dass diese Kontrollen für alle Mandanten gleichzeitig korrekt funktionieren, ohne die Überwachungsdaten eines Mandanten einem anderen offenzulegen. Die ATO jedes Mandanten erbt die Plattformkontrollen per Verweis (der Systemsicherheitsplan des Mandanten zitiert das ATO-Paket der Plattform als Beleg dafür, dass die Infrastrukturkontrollen erfüllt sind) und dokumentiert nur die Kontrollen, die mandantenspezifisch sind: Sicherheitskonfiguration auf Anwendungsebene, Datenklassifizierungs-Markierungen, autorisierte Nutzerpopulation und mandantenspezifische Verschlüsselungsschlüssel-Richtlinie.

Das Änderungsmanagement auf Plattformebene löst Re-Akkreditierungspflichten aus, die sich auf die Mandanten kaskadieren. Wenn der Plattformanbieter eine gemeinsam genutzte Komponente verändert (die Kubernetes-Version aktualisiert, den Durchsetzungsmechanismus der Netzwerkrichtlinie ändert, das Zugriffsrichtlinienmodell des Schlüsselverwaltungsdienstes modifiziert), muss der genehmigende Verantwortliche jedes Mandanten die Änderung überprüfen und bestätigen, dass die geerbten Kontrollen des Mandanten weiterhin gültig sind. Dies schafft einen Koordinationsaufwand, der mit der Anzahl der Mandanten wächst: Ein einziges Plattform-Upgrade kann erfordern, Dutzende unabhängiger genehmigender Verantwortlicher zu benachrichtigen und deren Bestätigung einzuholen. Verteidigungs-SaaS-Plattformen, die dies gut bewältigen, investieren in einen formellen Prozess zur Änderungskommunikation, vorab vereinbarte Benachrichtigungsfristen und Vorlagentexte, die genehmigende Verantwortliche von Mandanten verwenden können, um ihre Re-Akkreditierungsentscheidungen mit minimalem Nacharbeitsaufwand zu dokumentieren.

Audit-Protokollierung pro Mandant: getrennte Audit-Spuren für mandantenübergreifende Forensik

Die Audit-Protokollierung in einer mandantenfähigen klassifizierten Umgebung muss zwei scheinbar widersprüchliche Anforderungen erfüllen. Die Audit-Protokolle jedes Mandanten müssen isoliert sein (zugänglich für die autorisierten Prüfer dieses Mandanten und für keinen anderen Mandanten), und der Plattformbetreiber muss den Zugriff auf die Protokolle aller Mandanten für die Reaktion auf Vorfälle auf Plattformebene und forensische Untersuchungen behalten. Die Auflösung dieser Spannung erfordert ein klares Datenmodell: Mandanten-Audit-Protokolle sind mandanteneigene Daten, deren Zugriff durch den Plattformbetreiber selbst eine protokollierte, rechenschaftspflichtige Handlung ist, die denselben Audit-Anforderungen unterliegt wie jedes andere privilegierte Zugriffsereignis.

Das architektonische Muster ist eine Log-Senke pro Mandant mit Unveränderlichkeitskontrollen und Zugriffsprotokollierung auf Senken-Ebene. Die Anwendungs- und Infrastrukturereignisse jedes Mandanten werden an eine dedizierte Log-Gruppe oder Objektspeicherpartition mit einer Nur-Schreib-Richtlinie für die Anwendungsschicht und einer Nur-Lese-Richtlinie für die autorisierten Prüfer des Mandanten geleitet. Object-Lock-Richtlinien verhindern das Löschen oder Verändern von Log-Datensätzen für die Dauer des Aufbewahrungszeitraums. Der Plattformbetreiber hält eine separate administrative Rolle, die Lesezugriff auf alle Mandanten-Log-Senken gewährt, aber jede Ausübung dieser Rolle erzeugt ein Zugriffsereignis, das dem eigenen Audit-Stream des Mandanten hinzugefügt wird, sichtbar für die Prüfer des Mandanten bei ihrer nächsten Überprüfung. Dieses Design bedeutet, dass ein Mandant die Frage „Hat jemand außerhalb unserer Organisation unsere Audit-Protokolle gelesen?" jederzeit durch Prüfung seines eigenen Audit-Streams beantworten kann.

Eine mandantenübergreifende forensische Untersuchung (die Rekonstruktion eines Vorfalls, der möglicherweise mehrere Mandanten betraf) erfordert, dass der Plattformbetreiber Ereignisse über mehrere isolierte Log-Senken hinweg korreliert. Diese Korrelation muss mit Werkzeugen durchgeführt werden, die mit Plattformbetreiber-Privilegien ausgestattet sind und selbst Audit-Datensätze erzeugen, statt durch das Zusammenführen von Mandanten-Log-Streams in eine gemeinsam genutzte Speicherschicht. Eine gemeinsam genutzte Audit-Datenbank, die Ereignisse mehrerer Mandanten speichert, würde das Problem der mandantenübergreifenden Datenvermischung neu erschaffen, das die isolierte Log-Senken-Architektur verhindern sollte. Stattdessen fragen die forensischen Werkzeuge die Log-Senke jedes Mandanten unabhängig ab und stellen die mandantenübergreifende Zeitlinie im Speicher zusammen, in einer Betreiberumgebung, die von allen Mandantenumgebungen isoliert ist und selbst der Audit-Protokollierung unterliegt. Dieses Muster bewahrt die Log-Isolation der Mandanten und ermöglicht zugleich die forensische Fähigkeit auf Plattformebene, die Sicherheitsbetriebsteams benötigen.