Wie die Trennung von Netzwerken gemäß A.8.22 mandantenübergreifende Sicherheitsrisiken verhindert

Warum die Exposition gegenüber mehreren Mietern das neue Problem in flachen Netzwerken ist

Mandantenübergreifende Sicherheitslücken stellen die moderne Form eines flachen Netzwerks dar, da sie es ermöglichen, dass sich ein Sicherheitsvorfall auf Kunden und Umgebungen ausbreitet. Sind Netzwerke nicht ausreichend voneinander getrennt, kann ein Angreifer, der einen Mandanten kompromittiert, auf andere Mandanten ausweichen und einen zunächst begrenzten Vorfall zu einer Krise auf Plattformebene ausweiten. Eine strikte, risikobasierte Trennung reduziert diesen Wirkungsbereich, sodass das Problem eines Mandanten auch unter behördlicher Aufsicht und Kundendruck ein Problem des einzelnen Mandanten bleibt.

Starke Mietergrenzen sorgen dafür, dass ein Vorfall zu einem begrenzten Vorfall wird, selbst wenn die Verteidigungsmaßnahmen nicht perfekt sind.

Mandantenübergreifende Gefährdung bedeutet heutzutage häufig, dass man sich innerhalb gemeinsam genutzter Cloud- und SaaS-Infrastrukturen von einem Kunden, einer Geschäftseinheit oder einem Partner in einen anderen bewegt. Wenn Sie Anhang A.8.22 als strategische Maßnahme zur Begrenzung des Gefahrenausmaßes und nicht nur als VLAN-Verwaltungsregel betrachten, reduzieren Sie die Auswirkungen von Sicherheitsvorfällen, die Sie nicht vollständig verhindern können, erheblich und geben Auditoren einen besseren Einblick in Ihre Maßnahmen zum Schutz der einzelnen Mandanten. Die leicht verständlichen ISO-27001-Leitfäden zu A.8.22 beschreiben diese Kontrollmaßnahme genau so: Systeme und Benutzer werden risikobasiert in Zonen eingeteilt und die Datenflüsse zwischen ihnen streng kontrolliert, anstatt sich auf ein einheitliches, flaches Netzwerk zu verlassen.

Von flachen Netzwerken zu gemeinsam genutzten Infrastrukturen

Flache Netzwerke boten Angreifern einen einfachen Vorteil, da die Kompromittierung eines Hosts oft den Zugriff auf alle anderen Systeme ermöglichte. Die Segmentierung verringerte diesen Vorteil, indem das Netzwerk in separate Zonen mit kontrollierten Pfaden unterteilt wurde. Moderne Shared-Hosting-Netzwerke haben jedoch viele dieser Möglichkeiten zur lateralen Ausbreitung in komplexerer Form wieder eingeführt.

Dieses Modell haben Sie möglicherweise mit VLANs und Firewalls aufgebrochen, aber Ihre Architektur hat sich auch in Richtung gemeinsam genutzter Kubernetes-Cluster, mandantenfähiger SaaS, miteinander verbundener VPCs und verwalteter Dienste verlagert, die die alte Grenze zwischen innen und außen verwischen.

Sie müssen nun eine schwierigere Frage beantworten als „Kann ein Angreifer vom Benutzer-LAN zum Domänencontroller gelangen?“. Sie müssen aufzeigen, wie Sie verhindern, dass Angreifer über gemeinsam genutzte Infrastrukturen hinweg von den Workloads von Mandant A zu denen von Mandant B oder von Entwicklungsumgebungen in die Produktionsumgebung wechseln.

Jede Peering-Verbindung, Sicherheitsgruppe, jeder gemeinsame Protokollierungsdienst oder jedes Admin-VPN stellt einen potenziellen Sicherheitspfad dar. Betrachtet man Anhang A.8.22 unter diesem Gesichtspunkt, so wird er zur Kontrollmaßnahme, die die Gestaltung dieser Infrastrukturen so vorschreibt, dass jede „Umgebung“ sicher vom Rest abgeschirmt ist und diese Abschirmung gegenüber Prüfern und Kunden nachvollziehbar ist.

Warum dies für CISOs, Berater und Betreiber wichtig ist

Hochrangige IT-Sicherheitsverantwortliche legen Wert auf die mandantenübergreifende Gefährdung, da diese bestimmt, wie weit sich eine Kompromittierung über Mandanten und Umgebungen ausbreiten kann und wie schwerwiegend die regulatorischen, vertraglichen und reputationsbezogenen Folgen sind. Für CISOs geht es um mehr als nur einzelne Schwachstellen; es definiert, wie ein einzelner Vorfall zu einem systemischen Plattformausfall führen kann, der das gesamte Vertrauen in das System untergräbt.

Mandantenübergreifende Vorfälle sind besonders ärgerlich, weil sie Ihr zentrales Wertversprechen untergraben: Wenn das Problem eines Kunden die Daten oder die Verfügbarkeit eines anderen Kunden beeinträchtigt, bricht die Vertrauensbasis Ihrer Plattform zusammen und Benachrichtigungen über Datenschutzverletzungen können sich über mehrere Gerichtsbarkeiten erstrecken.

Nur etwa jede fünfte Organisation in der ISMS.online-Umfrage 2025 gab an, keinen Datenverlust erlitten zu haben.

Berater und interne Prüfer sehen dieselbe Lücke aus einem anderen Blickwinkel. Sie stoßen häufig auf Organisationen mit guten Richtlinien und soliden Firewalls, aber ohne schlüssiges Konzept zur durchgängigen Durchsetzung der Mandantenisolierung. Genau hier setzt A.8.22 an: Es verknüpft die übergeordnete Risikoanalyse mit einer konkreten Frage, die Prüfer Ihnen direkt stellen werden: „Wenn ein Angreifer diesen Mandanten kompromittiert, wie genau wird verhindert, dass er einen anderen Mandanten erreicht?“

Für Ihre Netzwerk- und Plattformteams bedeutet dies, dass Sie täglich Entscheidungen hinsichtlich Design und Änderungen treffen müssen: Welche Netzwerke und Cluster können die Mandanten gemeinsam nutzen, wie werden gemeinsam genutzte Dienste abgeschottet und welche Konnektivitätsanfragen müssen Sie ablehnen, weil sie die Isolation schwächen?

Von technischen Details bis hin zu Risiken auf Vorstandsebene

Die Entscheidungsträger auf Vorstandsebene möchten verstehen, wie sich das Scheitern eines Mieters auf andere auswirken könnte, denn hier liegen die systemischen Risiken, die regulatorischen Risiken und der Imageschaden. A.8.22 bietet eine einfache und konkrete Möglichkeit, zu erläutern, wie diese Risiken eingedämmt werden. Vorstandsmitglieder verstehen zunehmend, dass Plattformanbieter eine gemeinsam genutzte Infrastruktur betreiben, und erwarten klare Antworten darauf, wie die Auswirkungen begrenzt werden.

Ein einziges falsch weitergeleitetes Paket, eine zu weit gefasste Regel oder eine gemeinsam genutzte Steuerungsebene können das Problem eines einzelnen Kunden in einen regulatorischen Vorfall verwandeln, der sich über mehrere Kunden und Länder erstreckt und Folgewirkungen auf Verträge, Vertrauen und Unternehmensbewertung nach sich zieht.

Das macht die Netzwerksegmentierung zu einem relevanten Thema für den Vorstand und nicht nur zu einer technischen Angelegenheit. Wenn Sie A.8.22 so erläutern können, dass verhindert wird, dass das Problem eines Mieters zum Problem aller wird, liefern Sie den Entscheidungsträgern einen klaren Grund, die Arbeit zu unterstützen und die notwendigen Mittel für Design, Tests und die laufende Qualitätssicherung bereitzustellen, die eine ordnungsgemäße Segmentierung erfordert.

Im Bericht „State of Information Security 2025“ wird darauf hingewiesen, dass Kunden heute routinemäßig von ihren Lieferanten die Einhaltung formaler Standards wie ISO 27001, ISO 27701, DSGVO oder SOC 2 erwarten, anstatt sich auf allgemeine Zusicherungen bewährter Verfahren zu verlassen.

Kontakt

Was ISO 27001:2022 Anhang A.8.22 wirklich verlangt

Anhang A.8.22 sieht vor, dass Systeme und Benutzer risikobasiert in Netzwerkzonen unterteilt und der Datenverkehr zwischen diesen Zonen streng kontrolliert wird. In der Praxis entspricht diese ISO-27001-Kontrolle der Risikobewertung gemäß Abschnitt 6 und der Anwendbarkeitserklärung. Diese Kontrolle legt fest, welche Mandanten, Umgebungen und Dienste Netzwerke gemeinsam nutzen, welche getrennt werden müssen und wie jeder zulässige Datenverkehr zwischen ihnen begründet und überwacht wird, sodass Prüfer Entscheidungen auf dokumentierte Risiken zurückführen können. Unabhängige Leitfäden zur ISO-27001-Implementierung von A.8.22 erläutern dasselbe Prinzip: Die Zoneneinteilung erfolgt risikobasiert, und anschließend werden Kontrollen eingesetzt, um den Datenverkehr zwischen diesen Zonen einzuschränken und zu überwachen.

Formulierung und Absicht in einfacher Sprache

Im Kern besagt A.8.22, dass Systeme, Dienste und Benutzer mit unterschiedlichen Sicherheitsanforderungen nicht in einem einzigen großen, flachen Netzwerk untergebracht werden dürfen. Stattdessen unterteilen Sie Ihre Umgebung in Zonen, die auf Sensibilität und Geschäftsfunktion abgestimmt sind, und erlauben nur begründeten, dokumentierten Datenverkehr über diese Grenzen hinweg. So zeigen Sie Prüfern und Aufsichtsbehörden mit Ihrem Netzwerkdesign, dass Sie die risikobasierte Trennung gemäß Ihrer ISO 27001-Risikobewertung und der zugehörigen Anwendbarkeitserklärung umgesetzt haben.

In einfachen Worten erwartet A.8.22 von Ihnen Folgendes:

Gruppierung nach Sensitivität: – Hochvertrauliche oder kritische Systeme sollten von Systemen mit geringem Risiko ferngehalten werden.
Gruppierung nach Geschäftsbereich: – gegebenenfalls separate Funktionen wie Finanzen, Personalwesen und Technik.
Die Grenzen der Mieter respektieren: – Kunden, Partner und interne „Mieter“, die eine Trennung erwarten, isolieren.
Begründen Sie die Abläufe: – nur klar definierten, dokumentierten Verkehr zwischen den Zonen zulassen.

Dieses Modell bietet Ihnen eine einfache Checkliste, mit der Sie überprüfen können, ob Ihr Trennkonzept tatsächlich Ihr Risikobild widerspiegelt.

Aus diesem Grund greift die Behandlung von A.8.22 als bloße „Wir haben einige VLANs“ zu kurz. Bei der Segmentierung geht es nicht um willkürliche Abgrenzungen, sondern um die gezielte Gruppierung nach Sensibilität, Geschäftsfunktion und Mandant, sodass ein Ausfall in einer Gruppe nicht ohne Weiteres Auswirkungen auf andere haben kann. Diese Konzeption sollte sich direkt aus Ihrer Risikoanalyse ergeben und in Ihrer Anwendbarkeitserklärung berücksichtigt werden.

Ein einfaches Beispiel: Produktionssysteme zur Zahlungsabwicklung sollten niemals ein Netzwerksegment mit Test-Workloads geringer Qualität oder allgemeinen Büroendpunkten teilen; die Risiken und Verpflichtungen sind zu unterschiedlich.

Wie A.8.22 mit anderen Steuerelementen verbunden wird

A.8.22 steht nicht für sich allein; es interagiert mit anderen Kontrollen aus Anhang A und den Kernklauseln der ISO 27001. Das Verständnis dieser Zusammenhänge hilft Ihnen, Lücken und Doppelungen zu vermeiden und in Audits fundiertere Antworten zu geben.

A.8.20 zur Netzwerksicherheit fordert den Schutz des Datenverkehrs zwischen vernetzten Diensten, beispielsweise durch die Durchsetzung starker Verschlüsselung und Integrität für administrative Verbindungen über verschiedene Zonen hinweg. Analysen der Updates von Sicherheitsanbietern aus dem Jahr 2022 zeigen, dass es bei A.8.20 speziell um die Sicherung von Daten während der Übertragung und die Kontrolle von Netzwerkpfaden zwischen Diensten geht und nicht nur um die Einrichtung einer Firewall am Netzwerkrand.

Abschnitt A.5.23 zu Cloud-Diensten erwartet von Ihnen, dass Sie Risiken von externen Anbietern managen, einschließlich der Frage, wie Ihr Trennungsmodell auf Anbieterstrukturen wie Konten, VPCs oder Projekten basiert. Modelle der geteilten Verantwortung großer Cloud-Plattformen unterstreichen, dass Kunden für viele dieser Isolationsentscheidungen weiterhin verantwortlich sind, selbst wenn die zugrunde liegende Infrastruktur vom Anbieter betrieben wird.

Bei der Nutzung von Cloud- oder SaaS-Lösungen wird die Netzwerksegmentierung häufig teils vom Anbieter, teils von Ihrem Unternehmen implementiert. In Abschnitt A.8.22 zeigen Sie, wie diese Verantwortlichkeiten zusammenwirken: welche Isolationsfunktionen Sie von der Plattform nutzen und welche Sie selbst mit Routing, Firewalls, Sicherheitsgruppen oder Service Meshes hinzufügen.

Es überschneidet sich auch mit Zugriffskontrolle und Änderungsmanagement. Rollenbasierte Zugriffskontrolle lässt sich sicherer handhaben, wenn Benutzer in Zonen gruppiert werden, die ihren Rollen entsprechen. Änderungsmanagement ist effektiver, wenn jede neue Route, jedes VPN, jedes Peering oder jede Firewall-Regel auf ihre Auswirkungen auf die bestehende Trennung geprüft wird. Wenn Sie mit Technikern über A.8.22 sprechen, stellen Sie es als das Element dar, das sicherstellt, dass neue Verbindungen nicht unbemerkt alle anderen erfolgreichen Maßnahmen zunichtemachen.

Umfangsentscheidungen, die Ihre Verpflichtungen verändern

In modernen Umgebungen geht der Begriff „Netzwerk“ weit über klassische lokale Verbindungen hinaus. Sie müssen entscheiden, ob Ihr Geltungsbereich Cloud-VPCs, SD-WAN, Service Meshes, Management-Ebenen, standortübergreifende Verbindungen und VPNs umfasst, und Sie müssen klar definieren, wer als „Mandant“ gilt: externe Kunden, interne Geschäftsbereiche, Partnerteams und Lieferanten, die Infrastruktur gemeinsam nutzen. Diese Entscheidungen haben direkten Einfluss auf Ihre Pflichten und die Fragen, die Ihnen bei Audits gestellt werden.

Die frühzeitige Definition dieser Begriffe ist mehr als nur eine Dokumentationsübung. Die Art und Weise, wie Sie Grenzen festlegen, beeinflusst Verträge, Kundenerwartungen und den Umfang von Audits. Eine von mehreren Geschäftsbereichen gemeinsam genutzte Plattform wird im Marketing zwar nicht als „mandantenfähig“ bezeichnet, verhält sich aber aus Risikoperspektive wie eine solche. Unterliegen diese Bereiche unterschiedlichen Vorschriften oder Prüfintensitäten, muss Ihre Trennungsarchitektur dies widerspiegeln.

Zwei Drittel der Organisationen, die an der Studie „State of Information Security 2025“ teilnahmen, gaben an, dass die Geschwindigkeit und das Ausmaß der regulatorischen Änderungen die Einhaltung der Vorschriften zunehmend erschweren.

Auditoren werden Sie in der Regel bitten, darzulegen, welche Teile Ihres Geländes unter A.8.22 fallen, wie diese Zonen definiert sind und wie Sie sicherstellen, dass neue Verbindungen den Explosionsradius nicht über die beabsichtigten Grenzen hinaus erweitern. Die ISO 27001-Beratungsunterlagen zu A.8.22 und verwandten Audits betonen immer wieder die Notwendigkeit, die in den Geltungsbereich fallenden Netzwerke, Standorte und Anlagen genau zu definieren und den Prüfern die Grenzen dieser Zonen erläutern zu können.

Evidenzbasierte Gestaltung im Blick

Die Verteidigung nach A.8.22 lässt sich bei einer Prüfung deutlich erleichtern, wenn Sie Ihr Trennmodell von Anfang an unter Berücksichtigung der Nachweisbarkeit konzipieren. Das bedeutet, dass Sie bereits bei der Planung der Zonen und Warenflüsse bedenken sollten, welche Informationen Sie dem Prüfer vorlegen werden.

Auditoren achten üblicherweise auf drei Dinge: eine Richtlinie oder einen Standard, der Ihren Zonierungsansatz beschreibt, Diagramme, die die Zonen und Datenflüsse visualisieren, sowie Konfigurations- oder Testnachweise, die belegen, dass diese Datenflüsse in der Praxis tatsächlich umgesetzt werden. Große Cloud-Anbieter folgen demselben Muster in ihren ISO-27001-Zertifizierungen und veröffentlichen Richtlinien und Standards, Architekturskizzen sowie repräsentative Konfigurations- oder Testergebnisse, um zu demonstrieren, wie die Trennung implementiert und verifiziert wird.

Sie müssen nicht alle mit detaillierten Firewall-Informationen überhäufen. Konzentrieren Sie sich stattdessen auf eine klare Struktur: Risikobegründung → Zonenstandard → Übersichtsdiagramme → repräsentative Regelsätze und Tests. Ein Auditor wird oft fragen: „Zeigen Sie mir, wie die Mandanten hier getrennt sind“ und erwarten, dass Sie nahtlos von einem Diagramm zu konkreten Beispielen für durchgesetzte Regeln oder Testergebnissen übergehen, die die Wirksamkeit der Trennung belegen.

Eine Plattform wie ISMS.online kann Ihnen helfen, indem sie Ihre A.8.22-Richtlinie, Risikoeinträge, Diagramme und technischen Nachweise an einem zentralen Ort verknüpft. So müssen Sie nicht mehr jedes Mal in Wikis, Ticketsystemen und Screenshots suchen, wenn Fragen zur Mietertrennung auftauchen. Diese zentrale Datenbasis ist besonders wertvoll, wenn Aufsichtsbehörden oder Großkunden nachfragen, wie Ihre Kontrollmaßnahmen Ihre Risikobewertung und die Erfüllung Ihrer rechtlichen Verpflichtungen unterstützen.

ISMS.online verschafft Ihnen einen Vorsprung von 81 % ab dem Moment Ihrer Anmeldung

ISO 27001 leicht gemacht

Wir haben die harte Arbeit für Sie erledigt und Ihnen vom Moment Ihrer Anmeldung an einen Vorsprung von 81 % verschafft. Sie müssen nur noch die Lücken ausfüllen.

Los geht´s

Grundlagen der Mehrfamilienhausnutzung und was die mieterübergreifende Exposition bedeutet

Multi-Tenancy bedeutet, dass eine einzelne Plattform mehrere Kunden oder Gruppen bedient. Mandantenübergreifende Exposition liegt vor, wenn ein Mandant die Daten oder Dienste eines anderen Mandanten einsehen, beeinflussen oder daraus Rückschlüsse ziehen kann. Da moderne Plattformen einen Großteil der zugrundeliegenden Infrastruktur gemeinsam nutzen, kann man nicht davon ausgehen, dass Mandanten isoliert sind, nur weil die Anwendungslogik dies vorgibt. A.8.22 zwingt dazu, über die Isolation auf Anwendungsebene hinauszublicken und zu prüfen, ob die Netzwerke und die gemeinsam genutzte Infrastruktur diese Mandantengrenzen tatsächlich so gewährleisten, dass sie gegenüber Prüfern und Kunden nachvollziehbar sind.

Wie Mehrfamilienhäuser in der Praxis aussehen

In der Praxis tritt Multi-Tenancy überall dort auf, wo verschiedene Kunden, Geschäftsbereiche oder Partnerteams die zugrunde liegende Infrastruktur gemeinsam nutzen – von gemeinsam genutzten Rechenzentren über Cloud-Konten bis hin zu Kubernetes-Clustern. Um A.8.22 richtig zu bewerten, müssen Sie zunächst erkennen, wo diese gemeinsame Nutzung aktuell stattfindet.

In On-Premises-Umgebungen können mehrere Geschäftsbereiche Switches, Hypervisoren und Managementnetzwerke gemeinsam nutzen. In Cloud- und SaaS-Umgebungen laufen die Workloads verschiedener Kunden auf denselben physischen Hosts, innerhalb derselben Konten, Cluster oder virtuellen Netzwerke.

Kubernetes-Namespaces, serverlose Funktionen, gemeinsam genutzte API-Gateways und Message-Busse führen Mandantenfähigkeit auf zusätzlichen Ebenen ein. Gängige Muster, die Ihnen möglicherweise bekannt vorkommen, sind:

Mehrere interne Einheiten teilen sich ein Rechenzentrum oder eine private Cloud.
Mehrere Kunden werden in einem einzigen Cloud-Konto oder -Abonnement gehostet.
Viele Mandanten laufen als Namensräume oder Dienste in gemeinsam genutzten Clustern.

Diese einfache Liste hilft Ihnen, zu erkennen, wo Mieter bereits gemeinsam untergebracht sind, bevor Sie sich die Steuerungselemente ansehen.

Der entscheidende Punkt ist, dass jeder Mandant logische Trennung erwartet, unabhängig davon, ob Sie ihn in Ihrer Dokumentation als „Mandant“ bezeichnen. Finanz- und Personalabteilung nutzen möglicherweise eine gemeinsame Plattform, benötigen aber strikte Trennung; zwei externe Kunden, die Ihre SaaS-Lösung verwenden, dürfen unter keinen Umständen die Datensätze des jeweils anderen einsehen. Bei der Abbildung von Mandantenfähigkeit beantworten Sie im Grunde die Frage: „Wer glaubt, von wem getrennt zu sein?“ und prüfen anschließend, ob Ihre Netzwerke diese Trennung so gewährleisten, dass sie einer Prüfung oder behördlichen Untersuchung standhält.

Wie es tatsächlich zu Mieterübergriffen kommt

Mandantenübergreifende Angriffe werden selten durch eine einzelne, drastische Firewall-Regel verursacht; sie entstehen meist aus einer Reihe kleiner, einzeln betrachtet sinnvoller Entscheidungen, die zusammen einen unerwarteten Pfad schaffen. Das Verständnis dieser Muster ist unerlässlich, um tatsächliche Risiken zu minimieren und nicht nur Netzwerkdiagramme neu zu zeichnen.

Ein gemeinsam genutztes Protokollierungs- oder Überwachungssystem kann sich in einem Netzwerk befinden, das von mehreren Mandanten erreichbar ist. Eine hastig eingerichtete Peering-Verbindung kann zu sich überschneidenden Routen führen. Eine Sicherheitsgruppe kann erweitert werden, um einen Vorfall zu „beheben“, und anschließend nie wieder angepasst werden.

Schwachstellen in der Identitäts- und Steuerungsebene spielen ebenfalls eine große Rolle. Zu permissive Administratorrollen und Automatisierungskonten können Netzwerkkomponenten mandantenübergreifend neu konfigurieren. Der Missbrauch von Tags oder Labels in Richtlinienmodulen kann dazu führen, dass Regeln, die für einen Mandanten bestimmt sind, auch für einen anderen gelten. Selbst wenn der Anwendungscode die Mandanten-IDs korrekt prüft, kann die unten beschriebene Infrastruktur es einem Mandanten dennoch ermöglichen, Datenverkehr in das Netzwerksegment eines anderen Mandanten zu senden.

Ein einfaches Beispiel hierfür ist ein gemeinsam genutzter Logging-Stack in einem flachen „Monitoring“-Subnetz. Kann ein kompromittierter Host eines Mandanten mit diesem Subnetz kommunizieren und ist der Logging-Dienst nicht streng auf die Mandantenidentität eingestellt, kann ein Angreifer möglicherweise Logdaten anderer Mandanten anfordern oder daraus ableiten. Genau diese Art von unbemerktem Datenleck zwischen Mandanten soll A.8.22 verhindern, und Regulierungsbehörden sowie große Kunden hinterfragen dies zunehmend im Rahmen von Due-Diligence-Prüfungen. Europäische Leitlinien zur Cloud-Sicherheit, wie beispielsweise die von ENISA veröffentlichten Materialien, nennen die Mandantenisolation und mandantenübergreifende Pfade ausdrücklich als wichtige Bewertungskriterien bei der Beurteilung von Risiken gemeinsam genutzter Infrastrukturen.

Nur wenn man diese Szenarien in ruhigen Zeiten durchdenkt, lassen sie sich verhindern. Fragen Sie sich für jede gemeinsam genutzte Komponente oder Verbindung: „Wenn Mandant A kompromittiert wird, was hindert einen Angreifer daran, über diese Verbindung Mandant B zu erreichen?“ Lautet die ehrliche Antwort „Nichts wirklich Wirksames“, haben Sie eine Designlücke in A.8.22 aufgedeckt – und ein Risiko, das das Vertrauen Ihrer Kunden in Ihre Trennungszusage direkt untergraben könnte.

Die wichtigsten Mieter-Risikokategorien, denen Sie gegenüberstehen

Mandantenübergreifende Risiken beschränken sich nicht nur auf die Gefahr von Datenlecks; sie umfassen verschiedene Kategorien, die Vertraulichkeit, Integrität, Verfügbarkeit und die Gefährdung gemeinsam genutzter Technologien beeinträchtigen. Ein Verständnis dieser Kategorien ermöglicht die Entwicklung einer Segmentierung, die auf reale Ausfallszenarien anstatt auf allgemeine „Netzwerksicherheit“ abzielt. So können Sie Aufsichtsbehörden und Kunden nachweisen, dass Sie die Mandantenisolierung strukturiert und risikobasiert durchdacht haben.

Vier zentrale Risikokategorien

Sie können mandantenübergreifende Risiken in vier Hauptkategorien unterteilen, die Sie systematisch prüfen und entsprechend planen können. Diese Kategorien sind: Datenlecks, Missbrauch gemeinsam genutzter Dienste, Schwachstellen gemeinsam genutzter Technologien und Probleme mit dem Explosionsradius oder der Verfügbarkeit.

Datenlecks: – Ein Mieter erhält Zugriff auf die Daten eines anderen Mieters.
Missbrauch gemeinsam genutzter Dienste: – Missbrauch von gemeinsam genutzten Identitäts-, Protokollierungs- oder Verwaltungsebenen.
Schwäche bei gemeinsam genutzter Technologie: – Fehler in Hypervisoren, Containern oder Hardware.
Explosionsradius und Verfügbarkeitsrisiko: – Das Verhalten eines Mieters beeinträchtigt die anderen.

Dieses Modell bietet Ihnen eine einfache Checkliste, mit der Sie überprüfen können, ob Ihre Isolationsetage fertiggestellt ist.

Datenlecks umfassen Fälle, in denen ein Mandant durch falsch geleiteten Datenverkehr, gemeinsam genutzte Datenbanken, Caches oder Speicher direkt oder indirekt Zugriff auf die Informationen eines anderen Mandanten erlangt. Missbrauch gemeinsam genutzter Dienste liegt vor, wenn ein Mandant einen gemeinsam genutzten Identitätsanbieter, ein Protokollierungssystem oder ein API-Gateway so manipulieren kann, dass dies andere beeinträchtigt.

Das Risiko gemeinsam genutzter Technologien entsteht, wenn Schwachstellen im Hypervisor, der Container-Laufzeitumgebung oder der Hardware die Isolation aufheben, selbst wenn das Netzwerk korrekt erscheint. Dem kann teilweise durch die Wahl seriöser Anbieter und die Aktualisierung der zugrunde liegenden Plattformen begegnet werden. Das Risiko eines massiven Schadensausbreitungsradius entsteht, wenn das Verhalten eines Mandanten – ob versehentlich oder vorsätzlich – gemeinsam genutzte Komponenten überlastet und die Dienste für andere beeinträchtigt. Hierzu zählen verteilte Denial-of-Service-Angriffe, Ressourcenerschöpfung und falsch konfigurierte Steuerungsebenen.

Netzwerksegmentierung zielt primär auf die ersten beiden Kategorien ab, hat aber auch Auswirkungen auf die vierte. Sie erschwert es erheblich, dass für einen Mandanten bestimmte Daten einen anderen Mandanten erreichen, und fördert den sorgsamen Umgang mit gemeinsam genutzten Diensten. Zudem trägt sie dazu bei, die Folgen von Ausfällen gemeinsam genutzter Technologien einzudämmen, indem sie zusätzliche Hürden schafft, die ein Angreifer überwinden muss, um diese auszunutzen. Erläuterungen von Fachleuten zu ISO 27001 Control 8.22 bestätigen dies und stellen die Segmentierung als Mittel dar, um Datenpfade zwischen Mandanten zu unterbinden und gemeinsam genutzte Dienste abzusichern, mit zusätzlichen Vorteilen hinsichtlich Verfügbarkeit und Schadensbegrenzung.

Rechtliche, regulatorische und kundenbezogene Auswirkungen

Die Folgen einer gedankenübergreifenden Offenlegung sind oft gravierend, da sie viele Beteiligte gleichzeitig betreffen und die Aufmerksamkeit von Aufsichtsbehörden und Kunden auf Ihre technischen und organisatorischen Maßnahmen lenken. Diese Überprüfung umfasst häufig direkte Fragen zur Mietertrennung und Netzwerksegmentierung.

Die Studie „State of Information Security 2025“ ergab, dass die Mehrheit der Organisationen im vergangenen Jahr von mindestens einem Sicherheitsvorfall eines Drittanbieters oder Lieferanten betroffen war.

Werden Daten eines Kunden einem anderen Kunden zugänglich gemacht, können Sie gleichzeitig in mehreren Ländern Meldepflichten im Falle einer Datenschutzverletzung haben. Hinzu kommen vertragliche Strafen und eine eingehende Prüfung Ihres Konzepts zur Mandantenisolierung. Übersichten zu Cloud-Sicherheits- und Datenschutzstandards weisen darauf hin, dass Anbieter häufig mit sich überschneidenden Meldeverfahren konfrontiert sind, wenn Vorfälle Daten betreffen, die grenzüberschreitend gespeichert oder verarbeitet werden. Genau diese Situation gilt es durch eine strikte Trennung zu vermeiden.

Regulierungsbehörden erwarten zunehmend von Plattformanbietern den Nachweis einer robusten Mandantenisolierung, nicht nur allgemeiner Sicherheitsstandards. Mit einer risikobasierten Implementierung gemäß A.8.22, untermauert durch klar definierte Zonen und detailliert beschriebene Datenflüsse, liefern Sie überzeugendere Antworten auf die Frage von Regulierungsbehörden und Prüfern: „Welche technischen und organisatorischen Maßnahmen verhindern mandantenübergreifenden Zugriff?“ Leitlinien europäischer Cloud-Sicherheitsorganisationen wie ENISA heben Isolation und Risiken gemeinsam genutzter Infrastrukturen ausdrücklich als wichtige Aspekte hervor, die in Risikobewertungen von Cloud-Diensten berücksichtigt werden sollten.

Auch Kunden legen großen Wert darauf. Große Abnehmer stellen regelmäßig Fragen wie: „Wie sind unsere Umgebungen von denen anderer Kunden getrennt?“ und „Was verhindert, dass die Daten eines anderen Mandanten in unsere Systeme gelangen?“ Klare, risikobasierte Antworten, untermauert durch Diagramme und dokumentierte Kontrollmechanismen, heben Sie von Wettbewerbern ab, die lediglich sagen: „Wir verwenden VLANs und Firewalls.“ Cloud-Sicherheitsinformationen führender Anbieter beschreiben diese Fragen zur Mandantentrennung als Standardbestandteil der Due-Diligence-Prüfung von Multitenant-Plattformen – genau das, was auch Ihre Kunden wahrscheinlich fragen werden.

Zuordnung von Risiken zu Kontrollen

Es ist hilfreich, diese Risikokategorien explizit Risikominderungsmaßnahmen zuzuordnen, um zu erkennen, wo A.8.22 Anwendung findet und wo andere Kontrollen notwendig sind. Dies erleichtert auch die Strukturierung von Gesprächen mit Wirtschaftsprüfern und internen Risikoausschüssen.

Die nachstehende Tabelle ordnet jedem Risiko typische Ursachen und beispielhafte Minderungsmaßnahmen zu.

Risikokategorie	Typische Ursache	Beispielsteuerung
Datenlecks	Fehlgeleiteter Datenverkehr, gemeinsam genutzter Speicher, breit angelegte Sicherheitsgruppen	Mieterorientierte Zonen, striktes Routing, Verschlüsselung während der Übertragung
Missbrauch gemeinsam genutzter Dienste	Gemeinsame Protokollierungs-, Identitäts- und Verwaltungsebenen mit schwacher Bereichsbegrenzung	Dedizierte Servicenetzwerke, mTLS, mandantenspezifische Autorisierungsregeln
Schwäche bei gemeinsam genutzter Technologie	Hypervisor- oder Container-Schwachstellen, Hardwarefehler	Sorgfaltspflichten der Anbieter, Patching, mehrstufige Segmentierung
Explosionsradius und Verfügbarkeit	Störende Nachbarn, Überlastung der gemeinsamen Steuerungsebene	Ratenbegrenzung, Ressourcenkontingente, separate Verwaltungszonen

Die Erstellung dieser Karte zwingt dazu, klar zu formulieren: „Worauf stützen wir uns konkret, wenn Mandanten sich gegenseitig schaden können?“ Dies bietet einen klaren Ausgangspunkt für die Entwicklung von Segmentierungsmustern und die Priorisierung von Abhilfemaßnahmen und zeigt auf, wo die Netzwerksegmentierung durch Identitäts-, Plattform- und Governance-Kontrollen unterstützt werden muss. Kommentare von Sicherheitsexperten zu A.8.22 gruppieren Abhilfemaßnahmen tendenziell ähnlich und betonen, dass Segmentierung allein die Risiken gemeinsam genutzter Technologien nicht beseitigen kann, aber unerlässlich ist, um Datenpfade und den Zugriff auf gemeinsam genutzte Dienste einzuschränken.

Integrieren, erweitern und skalieren Sie Ihre Compliance, ohne dass es zu Problemen kommt. IO gibt Ihnen die Widerstandsfähigkeit und das Vertrauen, um sicher zu wachsen.

Buchen Sie Ihre Demo

Entwurf der Netzwerksegmentierung für Multi-Tenant-Umgebungen

Die Gestaltung der Datentrennung in einer Multi-Tenant-Umgebung erfordert die Festlegung einer Struktur für die Datenverteilung und deren konsistente Anwendung in Rechenzentren, Clouds und Orchestrierungsplattformen. Ein perfektes Design ist selten; stattdessen wählt man eine kleine Anzahl von Mustern, die zum Risikoprofil und den regulatorischen Rahmenbedingungen passen. Diese Muster müssen so einfach gehalten werden, dass Entwickler die Datentrennung bei Änderungen nicht versehentlich aufheben, und gleichzeitig gegenüber Auditoren verständlich erläutert werden können. Anforderung A.8.22 ist erfüllt, wenn diese Gestaltung bewusst, risikobasiert und nachweisbar ist. Der Kommentar zu ISO/IEC 27002 unterstreicht diese Aussage, indem er die Datentrennung als risikogetriebene Aktivität beschreibt, bei der die Umsetzung und Überprüfung der Zoneneinteilung in der Praxis nachvollziehbar sein muss.

Zuerst die mieterorientierten Zonen definieren

Strenge Trennungskonzepte beginnen mit Zonen und Verantwortlichkeiten, nicht mit Produkten oder Regelwerken. Zuerst identifizieren Sie die wichtigsten „Bereiche“ Ihres Geländes, legen fest, welche Bereiche sich niemals direkt berühren dürfen und welche über streng kontrollierte Wege verbunden werden können, und setzen diese Entscheidungen dann in konkrete Strukturen um. So können Sie den Prüfern leichter nachvollziehen, warum jede Verbindung besteht und wie sie im Rahmen Ihrer Risikobewertung gerechtfertigt wurde.

Man kann dies als einfache Sequenz strukturieren:

Schritt 1 – Schlüsselzonen identifizieren

Listen Sie Mandantennetzwerke, gemeinsam genutzte Dienste, Managementpfade und Umgebungsebenen wie Entwicklung, Test und Produktion auf, damit Sie sehen können, wo unterschiedliche Risikoprofile bereits zusammenliegen.

Schritt 2 – Zweck und Daten beschreiben

Für jede Zone sollten deren Rolle, Datensensibilität, typische Nutzer und regulatorische Verpflichtungen in einer kurzen, einheitlichen Beschreibung erfasst werden, die Risikoentscheidungen unterstützt.

Schritt 3 – Zulässige Beziehungen definieren

Dokumentieren Sie, welche Zonen mit welchen anderen kommunizieren dürfen und warum, einschließlich Protokollen, Anweisungen und Authentifizierungsanforderungen, damit Prüfer neue Verbindungen schnell beurteilen können.

Schritt 4 – Abbildung auf konkrete Konstrukte

Verknüpfen Sie jede Zone mit bestimmten VLANs, VRFs, virtuellen Netzwerken, Subnetzen oder Namensräumen in Ihren Plattformen, um klarzustellen, welche technischen Objekte die jeweilige Grenze implementieren.

Diese Schritte gewährleisten, dass das Design auf Risiken basiert und nicht auf der jeweils am einfachsten umzusetzenden Konfiguration. Dadurch erhalten Sie eine klare Darstellung für Wirtschaftsprüfer und interne Stakeholder.

Diese Übung mag simpel klingen, deckt aber versteckte Komplexitäten auf. Sie könnten beispielsweise feststellen, dass Ihre „Logging“-Zone ohne klare Einschränkungen von jeder anderen Zone aus aufgerufen wird oder dass sich die Verwaltungsschnittstellen mehrerer Mandanten in einem gemeinsam genutzten, schlecht kontrollierten Netzwerk befinden. Sobald die Zonen definiert sind, können Sie sie konkreten Konstrukten zuordnen – VLANs und VRFs lokal, virtuelle Netzwerke und Subnetze in der Cloud, Namespaces und Netzwerkrichtlinien in Kubernetes – und dabei dasselbe mentale Modell beibehalten.

Wählen Sie Segmentierungsmuster, die zu Ihrem Kontext passen.

Es gibt keine allgemeingültige Antwort auf die Fragen „Wie viele VPCs sollten wir haben?“ oder „Sollten wir pro Mandant eine VPC verwenden?“. Wichtig ist, dass Ihre Entscheidungen wohlüberlegt, dokumentiert und risikobasiert sind, damit Sie sie gegenüber Auditoren, Kunden und Ihren eigenen Teams nachvollziehen können.

In vielen Umgebungen hat man letztendlich die Wahl zwischen verschiedenen Mustern, wie zum Beispiel:

Netzwerk-Accounts pro Mandant: – starke Isolation, höherer Betriebsaufwand.
Gruppierung der Mieter nach Region oder Risikogruppe: – für viele Mieter effizient, erfordert jedoch eine stärkere Mikrosegmentierung.

Dieser Vergleich ermöglicht es Ihnen, über Muster zu sprechen, ohne über bestimmte Produktnamen zu streiten.

Beim Vergleich von Sicherheitsmustern sollten Sie sich Fragen stellen wie: Wie einfach können wir einem skeptischen Kunden nachweisen, dass sein Tenant isoliert ist? Was passiert, wenn ein bestimmtes Netzwerkkonto kompromittiert wird? Wie aufwendig ist es, unter jedem Muster einen neuen Tenant oder eine neue Region hinzuzufügen? Verknüpfen Sie diese Antworten explizit mit Ihren Risikokategorien. Wenn ein Muster es erschwert, Datenlecks zu verhindern oder die Auswirkungen eines Angriffs einzudämmen, hilft auch keine noch so gründliche lokale Anpassung.

Gemeinsame Dienstleistungen gestalten, ohne die Isolation zu durchbrechen

Gemeinsam genutzte Dienste wie Identitätsmanagement, Protokollierung, Überwachung und Datensicherung sind häufig die Schwachstellen vieler Trennungskonzepte. Diese Komponenten liegen oft zwischen mehreren Zonen und werden, wenn sie nicht sorgfältig konzipiert sind, zu Einfallstoren für Angreifer oder aufgrund fehlerhafter Konfigurationen zu häufigen Quellen mandantenübergreifender Sicherheitslücken.

Ziel ist es, die Zugriffspfade zu diesen Diensten so zu gestalten, dass jeder Mandant sie nutzen kann, ohne jedoch die Daten oder Steuerungsebenen anderer Mandanten einzusehen oder zu beeinträchtigen. Dies bedeutet in der Regel, gemeinsam genutzte Dienste in eigenen Zonen mit klar definierten Ein- und Ausgangsregeln zu platzieren und bei jedem Aufruf eine starke Authentifizierung und Autorisierung durchzusetzen. Beispielsweise könnten Mandanten Protokolle über verschlüsselte, gegenseitig authentifizierte Kanäle, die Mandantenkennungen enthalten, an einen zentralen Dienst senden, wobei darunter separate Speichersysteme oder robuste mandantenfähige Zugriffskontrollen implementiert sind.

Auf Netzwerkebene stellen Sie sicher, dass Mandanten nicht direkt miteinander, sondern nur mit dem gemeinsamen Dienst kommunizieren können und dass der gemeinsame Dienst keine beliebigen Verbindungen zurück in die Mandantenzonen herstellen kann. Behalten Sie bei der gesamten Planung A.8.22 stets im Blick: Es geht nicht nur darum, das Netzwerk funktionsfähig zu machen, sondern auch darum, Gruppen von Diensten und Benutzern ordnungsgemäß zu trennen und sicherzustellen, dass nur berechtigter Datenverkehr die Grenzen zwischen ihnen überschreitet.

Fehlkonfigurationen, die unbemerkt zu Fehlern führen A.8.22

Viele Organisationen verfügen zwar über ein solides übergeordnetes Design, scheitern aber dennoch in der Praxis an A.8.22, da alltägliche Änderungen die Trennung mit der Zeit untergraben. Fehlkonfigurationen und Prozesslücken führen schleichend zu einer Auflösung der Netzwerke, bis ein Penetrationstest, ein Audit oder ein realer Vorfall aufdeckt, dass die Mandantengrenzen nicht so stark sind, wie die Diagramme vermuten lassen. Das Verständnis dieser Muster ermöglicht Ihnen praktische Prüfungen, die Sie lange vor Nachfragen von Aufsichtsbehörden oder Kunden durchführen können.

Fehler bei Cloud und Virtualisierung

Cloud-Umgebungen erleichtern das Erstellen und Ändern von Sicherheitsgruppen, Netzwerk-ACLs, Routingtabellen und Peering-Verbindungen erheblich. Werden diese jedoch nicht sorgfältig geprüft, kann die Isolation unbemerkt geschwächt werden. Unter Zeitdruck erweitern Techniker möglicherweise eine Regel, um den Dienst wiederherzustellen, verbinden zwei Netzwerke per Peering, um ein Verbindungsproblem zu beheben, oder nutzen ein bestehendes Subnetz wieder, anstatt ein neues zu erstellen.

Zu den häufigsten Mustern gehören:

Zu weit gefasste Sicherheitsgruppen und ACLs: die sich über mehrere Mandanten oder Umgebungen erstrecken.
Ad-hoc-Peering oder VPNs: die zuvor getrennte Netzwerke stillschweigend miteinander verbinden.
VLAN- oder Subnetz-Wiederverwendung: die sich mit Test- und Produktionsumgebungen oder mehreren Mandanten überschneiden.

Diese Beispiele zeigen, wie kleine, lokale Korrekturen nach und nach Ihr ursprüngliches Zonenmodell außer Kraft setzen können.

Virtualisierte Rechenzentren weisen ähnliche Probleme auf. Trunk-Ports können mehr VLANs übertragen als ursprünglich vorgesehen. Ein Administrator könnte eine VLAN-ID für eine Testumgebung wiederverwenden, die sich mit einem Produktionssystem überschneidet. Private Verbindungen für einen neuen Dienst könnten innerhalb eines Management-Netzwerks anstatt in einer separaten Zone eingerichtet werden. Keine dieser Änderungen ist böswillig, doch sie alle schwächen die Trennung auf eine Weise, die anhand eines statischen Diagramms schwer zu erkennen ist.

Ein paar schnelle Überprüfungen, die Sie diese Woche durchführen können, sind: Suchen Sie nach Sicherheitsgruppen oder Firewall-Objekten, die auf „0.0.0.0/0“ verweisen und mehr als einem Mandanten oder einer Umgebung zugeordnet sind, und suchen Sie nach Peering- oder VPN-Verbindungen, bei denen die zulässigen Routen die Mandantenadressbereiche stärker überschneiden als erwartet.

Die Identifizierung dieser Probleme erfordert sowohl technische Prüfungen als auch prozessorientierte Vorgehensweisen. Netzwerkpfadanalyse-Tools, Konfigurationsvergleichsskripte und Infrastructure-as-Code-Scans können aufzeigen, wo die tatsächlichen Pfade von den geplanten abweichen. Änderungsmanagementrichtlinien, die eine Risikobewertung für neue Routen, Peering-Vereinbarungen und gemeinsam genutzte Dienste vorschreiben, tragen dazu bei, dass diese Pfade vor ihrer Implementierung berücksichtigt werden.

Prozessfehler, die gute Designs zunichtemachen

Selbst das beste technische Design kann ohne unterstützende Prozesse nicht bestehen. Konfigurationsabweichungen sind eine natürliche Folge von schnelllebigen Teams, Störungen und manuellen Änderungen. Wenn Ihre Organisation Netzwerkänderungen nicht anhand von Zonenregeln überprüft oder Ausnahmen informell genehmigt werden, wird A.8.22 untergraben, selbst wenn Sie Ihr letztes Audit bestanden haben.

Typische Prozesslücken, auf die man achten sollte, sind:

Unkontrollierte Konfigurationsdrift: aus manuellen, undokumentierten Änderungen.
Schwächere Segregation im Nichtproduktionsbereich: dadurch gelangen Muster in die Produktion.
Nicht zugeordnete Verwaltungspfade: wie beispielsweise Admin-VPNs oder Remote-Support-Tunnel.

Diese Liste bietet Ihnen eine erste Agenda für die Festigung des Veränderungsprozesses im Zusammenhang mit A.8.22.

Ein häufiges Problem ist die mangelnde Parität der Umgebungen. Entwicklungs- und Testumgebungen sind aus praktischen Gründen oft deutlich weniger segmentiert als die Produktionsumgebung. Daher testen Entwickler Muster, die in Produktivsystemen nicht zulässig wären. Mit der Zeit fließen diese Gewohnheiten in Änderungen der Produktionsumgebung ein, oft unter dem Motto: „Wir haben es im Test gemacht und es hat funktioniert.“ Die Behandlung von Segmentierungsanforderungen als nicht-funktionale Anforderungen in Testumgebungen hilft, dies zu verhindern.

Eine weitere Lücke betrifft die Behandlung von Managementpfaden. Admin-VPNs, Bastion-Hosts, Remote-Support-Tunnel und verwaiste Testschnittstellen können oft viele Mandanten oder Zonen erreichen, teilweise mit weitreichenden Berechtigungen. Werden diese Pfade nicht im Rahmen Ihrer A.8.22-Implementierung dokumentiert, werden sie nicht auf mandantenübergreifende Auswirkungen geprüft. Es ist daher unerlässlich, diese Pfade in Ihre Netzwerkdiagramme, Risikobewertungen und Änderungen einzubeziehen.

Letztendlich ist A.8.22 keine einmalige Planungsmaßnahme. Es ist eine fortlaufende Verpflichtung, Ihr reales Netzwerk an die beabsichtigte Trennung anzupassen. Interne Prüfer und externe Gutachter erkennen oft, wenn Ihre Diagramme und Dokumente ein Modell beschreiben, Ihre tatsächlichen Konfigurationen aber deutlich flacher verlaufen, insbesondere beim Vergleich von Konfigurationsbeispielen und Änderungsaufzeichnungen mit Ihren festgelegten Zonierungsstandards.

ISMS.online unterstützt über 100 Standards und Vorschriften und bietet Ihnen eine einzige Plattform für alle Ihre Compliance-Anforderungen.

Buchen Sie Ihre Demo

Kontrollmechanismen, die die seitliche Bewegung zwischen Mietern verhindern

Die Verhinderung lateraler Angriffe zwischen Mandanten ist keine Frage einer einzigen magischen Maßnahme; vielmehr geht es um die Kombination mehrerer Ebenen, sodass es Angreifern schwerfällt, die einzelnen Grenzen zu überwinden. A.8.22 bietet die Netzwerksegmentierungsebene, aber es bedarf auch Identitäts-, Endpunkt- und Governance-Maßnahmen, die diese unterstützen. Dadurch werden mandantenübergreifende Angriffe schwer erkennbar, langsamer und leichter zu erkennen und einzudämmen – genau das, was Auditoren und Großkunden von Multi-Tenant-Plattformen erwarten.

Mehrstufige technische Kontrollen

Die technische Seite lässt sich in vier Schichten unterteilen, die zusammenarbeiten, anstatt isoliert zu sein. Jede Schicht schränkt die Möglichkeiten des Angreifers ein und erhöht die Chancen, laterale Angriffe zu erkennen und zu stoppen, bevor ein weiterer Mandant betroffen ist.

Die Basis bildet die grobe Segmentierung: virtuelle Netzwerke, Subnetze, VLANs und VRFs pro Mandant oder Gruppe mit begrenzten Routen zwischen ihnen. Darüber hinaus wird die Mikrosegmentierung mithilfe von Sicherheitsgruppen, SDN-Richtlinien, Kubernetes-Netzwerkrichtlinien oder Host-Firewalls ergänzt, um die Kommunikation zwischen Workloads – selbst innerhalb eines Segments – einzuschränken.

Zero-Trust-Prinzipien verstärken die Sicherheit zusätzlich. Anstatt dem Datenverkehr aufgrund seiner Herkunft aus einem „vertrauenswürdigen“ Netzwerk zu vertrauen, sind starke Authentifizierung, Autorisierung und Verschlüsselung zwischen den Diensten erforderlich. Identitätsbewusste Proxys, Service Meshes mit gegenseitigem TLS und fein abgestufte Zugriffsrichtlinien gewährleisten, dass Angreifer selbst dann, wenn sie ein Netzwerk erreichen, in dem sich die Dienste eines anderen Mandanten befinden, kaum etwas Sinnvolles anrichten können. Endpunktkontrollen wie EDR, Host-Firewalls und strenge Konfigurationsvorgaben dienen als zusätzliche Sicherheitsmaßnahme.

Man kann sich den technischen Stack in vier Schichten vorstellen:

Grobe Segmentierung: – separate Mieter und Umgebungen in unterschiedliche Netzwerke aufteilen.
Mikrosegmentierung: – Kontrolle darüber, welche Dienste miteinander kommunizieren dürfen, sogar innerhalb eines Segments.
Zero-Trust-Dienstzugriff: – erfordern Identität und Verschlüsselung für jede Verbindung.
Endpunkthärtung: – Unerwartete Seitwärtsbewegungen erkennen und blockieren.

Zusammengenommen entsprechen diese Ebenen der Intention von A.8.22, indem sie sicherstellen, dass die Trennung an mehreren Stellen aufrechterhalten wird, sodass eine einzelne Fehlkonfiguration weniger wahrscheinlich zu einer mandantenübergreifenden Gefährdung führt.

Steuerung, Test und Überwachung

Technische Kontrollmaßnahmen funktionieren nur dann wie gewünscht, wenn sie in alltägliche Abläufe integriert und regelmäßig überprüft werden. Ihr Ziel sollte es sein, die Mieterisolierung bewusst zu planen, zu testen und zu überwachen – und nicht nur ein einmaliges Diagramm für Zertifizierungszwecke zu erstellen.

Das Änderungsmanagement für Netzwerke sollte explizit fragen: „Schafft diese Änderung einen neuen Pfad zwischen Mandanten oder Zonen?“ und bei einer positiven Antwort eine Begründung und Risikobewertung erfordern. Architekturprüfungsgremien sollten die Mandantenisolierung und die Auswirkungen auf A.8.22 standardmäßig in ihre Überlegungen einbeziehen, sobald neue Dienste, gemeinsam genutzte Komponenten oder Verbindungsmuster vorgeschlagen werden.

Tests sind ebenso wichtig. Regelmäßige Red-Team-Übungen oder gezielte Angriffssimulationen mit Fokus auf mandantenübergreifende Bewegungen können unerwartete Wege aufdecken und die Effektivität Ihrer Segmentierung bestätigen. Automatisierte Testtools können versuchen, von einem Mandanten aus auf dessen Ressourcen zuzugreifen und bei Erfolg Warnmeldungen ausgeben. Die Integration dieser Tests in die kontinuierliche Integration oder regelmäßige Betriebsprüfungen macht die Mandantenisolierung zu einer messbaren Eigenschaft und nicht zu einer Annahme.

Die Überwachung vervollständigt das Bild. Protokolle und Metriken von wichtigen Engpässen – wie Firewalls zwischen Zonen, gemeinsam genutzten Diensten und Steuerungsebenen – sollten so konfiguriert werden, dass ungewöhnliche Verbindungen zwischen Mandanten oder Zonen hervorgehoben werden. Beispielsweise sollten Zugriffsversuche von Verwaltungskonten eines Mandanten auf die Netzwerke eines anderen Mandanten oder unerwartete Protokollflüsse zwischen vermeintlich isolierten Gruppen leicht erkennbar sein.

Man kann sich den Governance-Kreislauf als drei fortlaufende Schritte vorstellen:

Schritt 1 – Änderungen zur Isolation steuern

Integrieren Sie Fragen zur Mieterisolation in Änderungs- und Architekturprüfungen, damit neue Vorgehensweisen vor der Implementierung bewertet und für Prüfungszwecke dokumentiert werden.

Schritt 2 – Isolation regelmäßig testen

Nutzen Sie Red Teaming, automatisierte Angriffspfadtests und geplante Überprüfungen, um sicherzustellen, dass die Trennung gemäß A.8.22 weiterhin gilt und die Diagramme der Realität entsprechen.

Schritt 3 – Überwachen und reagieren

Instrumentieren Sie wichtige Engpässe, um verdächtige Datenflüsse zwischen Mietern zu erkennen und bei deren Auftreten schnell zu reagieren, wobei die gewonnenen Erkenntnisse in die Gestaltung und Politik einfließen.

Für interne Teams bietet sich als praktischer Schnelltest an, einen „Vorzeige-Tenant“ auszuwählen und in einem kontrollierten Test gezielt zu versuchen, auf die Umgebung eines anderen Tenants zuzugreifen. Gelingt dies problemlos, ist dies ein starkes Indiz dafür, dass Ihre A.8.22-Implementierung verbesserungsbedürftig ist.

Schließlich muss jemand die Verantwortung dafür übernehmen. Weisen Sie innerhalb Ihres ISMS eine klare Verantwortlichkeit für den Zustand von A.8.22 zu, definieren Sie Kennzahlen (wie die Anzahl genehmigter Ausnahmen, Ergebnisse von Isolationstests und die Häufigkeit von Vorfällen im Zusammenhang mit der Datentrennung) und berichten Sie darüber zusammen mit anderen Sicherheitsindikatoren. Diese Maßnahmen erschweren und überwachen den Datenaustausch zwischen Mandanten erheblich – genau die Reduzierung des potenziellen Schadensausmaßes, die Ihre Kunden und Aufsichtsbehörden erwarten.

Buchen Sie noch heute eine Demo mit ISMS.online

A.8.22 bietet echten Mehrwert, wenn Ihre Trennungskonzepte, Risikobewertungen und technischen Nachweise ein schlüssiges Gesamtbild ergeben, dem Prüfer, Ingenieure und Kunden gleichermaßen vertrauen können. ISMS.online unterstützt Sie dabei, Ihre Entscheidungen zur Netzwerktrennung gemäß Anhang A.8.22 in klare, zusammenhängende Nachweise zu verwandeln, denen Prüfer, Ingenieure und Kunden gleichermaßen vertrauen können. Anstatt Zonierungsstandards, Diagramme, Firewall-Exporte und Risikobewertungen auf verschiedene Tools zu verteilen, können Sie diese in einer einzigen Umgebung als zusammenhängendes Gesamtbild pflegen. So bleibt die tatsächliche Arbeitsweise Ihres Unternehmens und die Entwicklung der Mieterisolation im Zeitverlauf optimal abgebildet.

Trennkonzepte in Beweise umwandeln

Ein gut durchdachtes Trennkonzept verliert an Wert, wenn die Verbindungen zu Risiken, Richtlinien und laufenden Kontrollen nicht ersichtlich sind. In ISMS.online können Sie Zonierungsstandards, Risikoeinträge, Netzpläne, Änderungsprotokolle und Testergebnisse direkt mit Anhang A.8.22 und zugehörigen Kontrollen wie A.8.20 und A.5.23 verknüpfen.

So können Sie in einer einzigen Ansicht darstellen, warum bestimmte Mandanten und Dienste getrennt sind, wie dies implementiert wurde und wie Sie die Funktionsfähigkeit sicherstellen. Da alles in einem zentralen ISMS verwaltet wird, bleibt es stets aktuell. Wenn eine neue VPC hinzugefügt, ein gemeinsam genutzter Dienst geändert oder ein Cloud-Anbieter eine neue Funktion einführt, aktualisieren Sie die zugehörigen Risiken und Kontrollen an derselben Stelle.

Mit der Zeit entsteht so eine dynamische Dokumentation der Entwicklung der Mieterisolierung – anstatt einer Sammlung von Tabellenkalkulationen, die nach jedem Audit veralten. Genau diese Dokumentation benötigen Auditoren, Kunden und interne Stakeholder, wenn sie Fragen zu A.8.22 und der Mieterübergreifenden Gefährdung stellen.

Planen Sie Ihre nächsten Schritte mit ISMS.online

Die Planung zur Verbesserung von A.8.22 im eigenen Umfeld wird einfacher, wenn man sieht, wie andere ihre Vorgehensweise von der Risikobewertung bis zur Beweissicherung strukturieren. Eine solche Übersicht hilft dabei, Prioritäten zu setzen, anstatt zu versuchen, alles gleichzeitig zu verbessern.

In der ISMS.online-Umfrage 2025 gaben fast alle Befragten an, dass das Erreichen oder Aufrechterhalten von Sicherheitszertifizierungen wie ISO 27001 oder SOC 2 für sie oberste Priorität hat.

Wenn Sie sich auf die Zertifizierung nach ISO 27001:2022 vorbereiten, einen Übergang von der Version 2013 planen oder auf den Druck von Kunden reagieren, die Mietertrennung nachzuweisen, ist das Betrachten eines funktionierenden Beispiels oft der schnellste Weg, um voranzukommen.

Eine Demo von ISMS.online zeigt Ihnen, wie andere Organisationen ihre A.8.22-Stufe strukturieren – von der ersten Risikobewertung bis hin zu Diagrammen, Kontrollen und Überwachung –, sodass Sie dieses Muster an Ihren eigenen Kontext anpassen können.

Sie können auch einen Testarbeitsbereich nutzen, um Ihre aktuelle Trennstrategie abzubilden: Definieren Sie Zonen, fügen Sie vorhandene Diagramme und Nachweise hinzu und erkennen Sie schnell, wo Verbindungen fehlen. Allein diese Übung deckt oft sowohl Lücken als auch Stärken auf, die zuvor schwer zu benennen waren. Darauf aufbauend entscheiden Sie, welche Probleme Sie zuerst angehen, welche Kontrollmechanismen Sie standardisieren und welche Beteiligten Sie einbeziehen müssen.

Damit Ihre Netzwerksegmentierungsmaßnahmen tatsächlich das Risiko zwischen Mietern reduzieren und auch Audits standhalten, ist ein ISMS hilfreich, das diese Verbindungen sichtbar macht. ISMS.online bietet Ihnen eine praktische Möglichkeit zu zeigen, dass Anhang A.8.22 mehr als nur ein Diagramm ist – es ist ein lebendiges Kontrollinstrument, das Ihre Mieter und Ihren Ruf schützt. Wenn Sie dies in der Praxis erleben möchten, können Sie einen Rundgang vereinbaren, sobald es für Ihr Team passt.

Kontakt

Häufig gestellte Fragen (FAQ)

Wie können wir diese FAQ-Sammlung so optimieren, dass sie sowohl für ISO 27001 als auch für GTM besser geeignet ist?

Jede Antwort sollte auf eine einzige klare Aufgabe fokussiert sein: Käufer beruhigen und Prüfer zufriedenstellen – und das in 300–450 Wörtern.

Wo ist dieser Luftzug bereits stark genug, um ihn aufrechtzuerhalten?

Sie müssen diese Arbeit nicht verwerfen. Sie enthält ein solides Grundgerüst, das Sie nahezu vollständig erhalten können:

Du erklärst A.8.22, genaue Mietertrennung und seitliche Bewegung.
Sie nutzen realistische Beispiele (VPCs, Sicherheitsgruppen, CI/CD, Bastions), denen ein Praktiker vertrauen wird.
Man folgt natürlich dem Risiko → Design → Betrieb → Nachweis Linienprüfer erwarten.
Sie haben bereits Platz für folgende Erwähnung geschaffen: ISMS.online als der Ort, der diese Geschichte zusammenhält.

Aus der Perspektive der ISO 27001 könnte ein Auditor dies lesen und zu dem Schluss kommen, dass Sie verstehen, was mit A.8.22 erreicht werden soll und wie dies nachgewiesen werden kann.

Wo weicht es von Ihren Vorgaben ab?

Gemessen an Ihren eigenen Vorgaben und Personas fallen drei Lücken besonders auf:

Persona-Targeting ist implizit, nicht explizit.

Die Stimme sagt zwar „guter Sicherheitsarchitekt“, aber das stimmt nicht. fühlen geschrieben an:

Kickstarter: die „Schritt für Schritt, helft uns, es beim ersten Mal zu bestehen“.
CISOs: denen Resilienz, Vertrauen im Vorstand und die Wiederverwendung von Lösungen über verschiedene Rahmenwerke hinweg am Herzen liegen.
Datenschutz/Rechtliches: die Wert auf Rechtssicherheit und regulatorisch geeignete Dokumente legen.
Praktiker: die einfach weniger Tabellenkalkulationen und weniger Prüfungsstress wollen.

Jede Antwort sollte mit einem Satz beginnen, der bei einer dieser Personen den Gedanken auslöst: „Das ist genau das Richtige für mich.“

ISMS.online ist vorhanden, wird aber nicht ausreichend genutzt.

Sie nicken dem Medium zu, aber der Text kommt nicht vollständig an. Plattformjob:

„Ein zentraler Ort“, an dem Zonenstandards, Diagramme, Regeln, Tests und Bewertungen zusammengeführt werden.
LinkedIn Insight Tag: Risiken ↔ Kontrollen ↔ Änderungen ↔ Tests ↔ AuditsA.8.22 ist also sichtbar „lebendig“, kein Dokument.

Ein einziger, sachlicher Satz in jeder Antwort würde das viel deutlicher machen, ohne in Übertreibungen abzurutschen.

Länge und Wiederholungen beeinträchtigen die Performance der Landingpage.

Mehrere Absätze greifen dieselbe Idee („A.8.22 behandelt den gesamten Prozess von der Risikobewertung über die Planung bis zum Betrieb“) aus verschiedenen Perspektiven auf. Auf einer Landingpage besteht dadurch die Gefahr, dass Besucher die Seite nur überfliegen und sofort wieder verlassen, insbesondere bei Kickstarter-Projekten, die nach „Was sage ich meinem Wirtschaftsprüfer?“ suchen, oder bei Praktikern, die wissen möchten, wie sie Mieter schnell segmentieren können.

Sie erzielen mehr Interaktion, indem Sie Wiederholungen vermeiden und den freigewordenen Platz nutzen für:

klar verankern eine Persona pro Frage; und
verschieben in neue Blickwinkel (Cloud vs. SaaS, mandantenbasiert vs. gemeinsam genutzt, Design vs. Drift).

Sie können alle sechs Fragen beibehalten, aber jeder einzelnen eine präzisere, spezifischere Aufgabe zuweisen.

1. „Wie ist ISO 27001 A.8.22 anzuwenden, wenn wir gemeinsam genutzte Cloud- und SaaS-Plattformen verwenden?“

Hauptberuf: Beruhigen Kickstarter-Projekte und CISOs dass „gemeinsame Plattform ≠ gemeinsamer Explosionsradius“ und geben Sie ihnen einen Satz, der einem Prüfer gefallen wird.

Beginnen Sie mit:

„A.8.22 verlangt von Ihnen den Nachweis, dass gemeinsam genutzte Cloud- und SaaS-Lösungen niemals zu einem gemeinsamen Gefahrenherd für Mandanten oder Teams werden.“

Dann kurz für jede Persona aufteilen:
Für Kickstarter-Projekte: „Das sagt man bei einer Prüfung in einfachen Worten.“
Für CISOs: „So erklären Sie dem Vorstand das mandantenübergreifende Risiko und die Resilienz.“
Ein hinzufügen ISMS.online-Leitung: Hier sind die Zonennormen, Diagramme und Musterregeln zu finden, damit jeder die gleiche Geschichte erzählen kann.

2. „Wie sollten wir unsere Netzwerk- und Identitätsschichten segmentieren, um A.8.22 in einer Multi-Tenant-Umgebung zu erfüllen?“

Hauptberuf: ABSICHT Praktiker Eine Zoneneinteilung, die sie kopieren können, ohne die Theorie übermäßig zu erklären.

Beginnen Sie mit einer einzeiligen Antwort:

„Verwenden Sie eine Handvoll klar definierter Zonen (Edge, Tenant, Shared Platform, Management, Corporate Users) und halten Sie die Administratoridentitäten getrennt.“

Dann:
Listen Sie die Zonen einmal auf.
Zeigen Sie, wie Sie Netzwerk- und Identitätskontrollen kombinieren, damit „ein Fehler in einer Zone nicht auf andere Zonen übergreift“.
Eins ISMS.online Satz: Zonenstandards, Diagramme und Beispielregeln als anerkannte Referenz, damit sich neue Ingenieure und Lieferanten selbst bedienen können.

3. „Welche Fehlkonfigurationen führen am häufigsten zu Problemen bei der Mietertrennung, selbst wenn die Planung auf dem Papier korrekt aussieht?“

Hauptberuf: Marke CISOs und Praktiker Nervös genug, um sich Sorgen um die Abdrift zu machen, dann zeige, wie man sie zähmt.

Öffnen Sie mit:

„Konstruktionen versagen meist still und leise durch kleine Fehlkonfigurationen, die die Trennung mit der Zeit verringern.“

Pick Nur 3–5 benannte Muster (gemeinsame Administratorkonten, kopierte Sicherheitsgruppen, Staging-Umgebung mit Produktionsdaten verknüpft, Notfall-Firewall-Änderungen nie rückgängig gemacht, falsch definierte Identitätsrollen).
Dann schnell umschalten auf Prozesskorrekturen:
verknüpfte Änderungsdatensätze,
Test der Seitwärtsbewegung
regelmäßige Überprüfungen.
Eins ISMS.online-LeitungA.8.22 als lebendiges Kontrollsystem mit verknüpften Änderungsaufzeichnungen, Tests und internen Prüfungsergebnissen.

4. „Welche unterstützenden Kontrollmechanismen fördern am besten die Umsetzung von A.8.22 in Multi-Tenant-Umgebungen?“

Hauptberuf: A.8.22 neu formulieren für CISOS als eine Strategie der Seitwärtsbewegung, die mit dem Rest von Anhang A verknüpft ist, und nicht nur als ein einzelnes Kontrollkästchen.

Beginnen wir mit der Idee:

„A.8.22 ist am stärksten, wenn es in die Bereiche Identität, Vorfallsmanagement, Kontinuitätsmanagement und Datenschutz integriert ist.“

Verwenden Sie eine kurze, beschreibende Tabelle oder Stichpunkte, die A.8.22 einigen wichtigen Gruppen zuordnen:
A.5–A.6 (Personen/Rollen),
A.8.1–A.8.5, A.8.20–A.8.22 (Technologiesegmentierung),
A.5.24–A.5.28 (Vorfall),
A.5.29–A.5.30, A.8.13–A.8.14 (Kontinuität),
A.5.31–A.5.34 (Recht/Datenschutz).
Eins ISMS.online-Leitung: Zeigen Sie A.8.22 als einen Knoten in einem Kontrollcluster mit expliziten Links zu denjenigen, die Kontrollen und Belege unterstützen.

Hauptberuf: ABSICHT Prüfer und Datenschutz/Recht Eine übersichtliche Liste von Artefakten und eine Anleitung, wie man sie „gerade ausreichend, aber immer aktuell“ hält.

Antworte zuerst:

„Man besteht nicht aufgrund von Diagrammen; man besteht, weil man einen einfachen Weg vom Risiko zur Realität beschreiten kann.“

Skizzieren Sie dann die vier Beweiseimer (Risikobeschreibung, Konstruktionsartefakte, betriebliche Kontrollen, Aufsicht).
Betonen „Zehnminütiger Rundgang, keine 40-seitige Broschüre“.
Eins ISMS.online-Leitung: A.8.22 als Kontrolldatensatz mit diesen Verknüpfungen und Anhängen, sodass Sie zum Zeitpunkt der Prüfung auswählen und nicht verschlüsseln.

6. „Wie fügt sich A.8.22 in unser gesamtes ISMS- und Annex-L-integriertes Managementsystem ein?“

Hauptberuf: Anzeigen alle Personas dass A.8.22 eine IMS-Kachel ist: Sie berührt Sicherheit, Datenschutz, Kontinuität und Qualität.

Öffnen Sie mit:

„A.8.22 ist der Punkt, an dem Mietertrennung auf Risikomanagement, Betriebsabläufe, Datenschutz und Kontinuität trifft.“

Kurzer Überblick über:
ISO 27001 Abschnitte 4–8 (Kontext, Risiko, Planung, Betrieb),
Anhang A Cluster, zu denen es gehört,
andere Annex-L-Normen, die davon beeinflusst werden (z. B. ISO 9001, 22301, 27701).
Eins ISMS.online-Leitung: A.8.22 wurde einmal registriert und anschließend mit Risiken, Audits und Maßnahmen über mehrere Standards und Abteilungen hinweg verknüpft.

Welche konkreten Änderungen erzielen die größte Wirkung bei minimalem Aufwand?

Mit ein paar gezielten Maßnahmen lässt sich dieses Set „landingpage-optimiert“ gestalten.

1. Pro Antwort nur eine Aufgabe übersichtlich gestalten.

Ziel 300–450 Wörter gemäß FAQ.
Diese Form beibehalten:
Antwort in einem Satz, maximal 20 Wörter.
2–3 kurze Absätze mit Schwerpunkt auf:
was der Leser verstehen muss,
worauf der Prüfer achten wird,
Wie Ihre Organisation und ISMS.online das erleichtern.

Alles, was diesem Zweck nicht dient, wird entfernt.

2. Schreiben Sie die Einleitungen so um, dass der Leser direkt angesprochen wird.

Ändern Sie generische Einleitungen wie „A.8.22 erwartet von Ihnen…“ in zielgruppenspezifische Formulierungen:

„Als Kickstarter-Projekt braucht man eine einfache Möglichkeit, um zu sagen…“
„Als CISO werden Sie sich weniger für die Topologie und mehr für … interessieren.“
„Wenn Sie für Verdachtsmeldungen oder behördliche Reaktionen zuständig sind, sollten Sie Folgendes prüfen…“

Diese kleine Änderung sorgt dafür, dass sich jede FAQ so anfühlt, als gehöre sie auf eine GTM-Landingpage, nicht nur in einer Bedienungsanleitung.

3. Standardisierung der ISMS.online-Brücke

Um Wiederholungen zu vermeiden, aber dennoch den Grundstückswert zu erhalten, wählen Sie ein Muster pro Frage:

„Speichern Sie die Norm, Diagramme und Beispiele gemäß A.8.22 in ISMS.online…“
„Linkänderungsanträge, Ergebnisse von Penetrationstests und Überprüfungen mit A.8.22 in ISMS.online verknüpfen…“
„Modell A.8.22 als ein Kontrollknoten, der mit Identität, Vorfall, Kontinuität und Datenschutz verknüpft ist…“
„Behandeln Sie A.8.22 als eine dynamische Kontrollgruppe in ISMS.online, damit sich die Evidenz zwischen den Audits unauffällig anhäuft…“

Sie erhalten eine konsistente Wertbotschaft, ohne dass es aufdringlich wirkt.

4. Wiederholte Erklärungen in einem einzigen Satz zusammenfassen.

Wo immer Sie derzeit die vollständige Kette „Risiko → Design → Betrieb → Nachweis“ wiederholen, fassen Sie sie in einer kurzen Formulierung zusammen, wie zum Beispiel:

„Einen einfachen Weg vom Risiko zur Realität beschreiten“
„zeigen, dass das Design auch im täglichen Betrieb noch Bestand hat“

Nutzen Sie den eingesparten Platz, um Folgendes einzuführen neue Perspektiven:

Nuancen zwischen Cloud- und On-Premise-Lösungen;
Trennung nach Mieter vs. nach Umgebung;
wie A.8.22 mit Datenschutz und Verarbeitungsaufzeichnungen interagiert.

Möchten Sie als Nächstes ein vollständig überarbeitetes Set?

Wenn Sie bestätigen, dass Sie damit einverstanden sind, dass ich nicht nur kritisieren, sondern umschreibenIch kann zurückkehren:

ein vollständiger FAQ-Fragenkatalog mit sechs Fragen, jede Frage 300–450 Wörter lang, strukturiert für Kickstarter-Initiatoren, CISOs, Datenschutz-/Rechtsexperten und Praktiker;
verstärkte, aber ruhige ISMS.online-Wertvorstellungen in jeder Antwort;
Eine prägnantere Formulierung, die alle technischen Fakten zu A.8.22 beibehält und sich gleichzeitig wie ein Text für eine Landingpage liest, nicht wie ein internes Designdokument.

Sie können es dann direkt in Ihre A.8.22 / Multi-Tenant-Landingpage einfügen und wissen, dass es gleichermaßen für Wirtschaftsprüfer und Käufer relevant ist.