Referenzarchitektur für die Sicherheit in der Hybrid-Cloud

Eine Referenzarchitektur für die Hybrid-Cloud-Sicherheit ist ein herstellerunabhängiger Leitfaden, der veranschaulicht, wie Sicherheitsmaßnahmen über die lokale Infrastruktur, die Private Cloud, SaaS und die Public Cloud hinweg miteinander verknüpft sind. Sie dient dazu, Bereitstellungen zu planen, Anbieter zu vergleichen, das Sicherheitskonzept gegenüber Prüfern zu erläutern und die Fortschritte auf dem Weg zum Zero-Trust-Ansatz zu messen.

Dieser Artikel bietet ein umfassendes Referenzmodell: die zugrunde liegenden Entwurfsprinzipien, Logik- und Bereitstellungsdiagramme, eine Komponentenübersicht, sechs Datenverkehrsströme, Kontrollgrenzen, Entwurfsüberlegungen zu Identität, Protokollierung, Kapazität und Ausfallsicherheit, eine Zuordnung zu den CISA- und NIST-Kontrollmaßnahmen, fünf Bereitstellungsbeispiele sowie einen Reifegradpfad mit Validierungstests.

Dieser Artikel ist Teil des Leitfadens zur Hybrid-Cloud-Sicherheit. Einen allgemeinen Überblick über die Infrastruktur von Hybridumgebungen finden Sie unter „Hybrid-Cloud-Architektur: Komponenten und Bereitstellungsmodelle“.

Gestaltungsprinzipien des Referenzmodells

Das Referenzmodell basiert auf vier Grundsätzen, die aus den Zero-Trust-Leitlinien des NIST und der CISA abgeleitet wurden.

1. Trennen Sie Entscheidungen von der Durchsetzung. NIST SP 800-207 unterscheidet zwischen dem Policy Decision Point (PDP), an dem entschieden wird, ob der Zugriff gewährt wird, und dem Policy Enforcement Point (PEP), der die Verbindung herstellt, überwacht oder beendet. Ein PDP, viele PEPs.
2. Gewähren Sie kein Vertrauen allein aufgrund des Standorts im Netzwerk. Die Zugehörigkeit zum Unternehmens-LAN ist kein Grund, auf eine Authentifizierung oder Überprüfung zu verzichten. NIST SP 800-215 beschreibt den Verlust einer sinnvollen Perimetergrenze als ein charakteristisches Merkmal heutiger Unternehmensnetzwerke.
3. Schützen Sie Daten anhand ihrer Klassifizierung, nicht anhand ihres Speicherorts. Die Kontrollmaßnahmen folgen der Datenklasse, wohin auch immer diese sich bewegt.
4. Gehen Sie davon aus, dass jede einzelne Abhängigkeit ausfallen kann. Identitätsanbieter, Cloud-Dienste und WAN-Verbindungen fallen alle aus. Die Architektur legt fest, was in diesem Fall geschieht.

Der im Juni 2025 gemeinsam mit 24 Anbietern veröffentlichte Praxisleitfaden SP 1800-35 des NIST mit dem Titel „Implementierung einer Zero-Trust-Architektur“ veranschaulicht 19 Beispielimplementierungen dieser Prinzipien in lokalen und Cloud-Umgebungen und stellt eine nützliche Ergänzung zu diesem Modell dar.

Architekturdiagramme

Die Referenzarchitektur wird anhand von zwei Sichten beschrieben: einer logischen Sicht auf ihre Ebenen und einer Bereitstellungssicht, die zeigt, wo die Komponenten ausgeführt werden.

Logische Architektur

Die logische Architektur umfasst drei Ebenen: eine zentralisierte Steuerungsebene, eine verteilte Durchsetzungsebene und eine gemeinsame Transparenzsebene.

Die Steuerungsebene definiert die Richtlinien einmalig. Die Durchsetzungsebene wendet diese überall dort an, wo Datenverkehr fließt. Die Transparenz-Ebene sammelt Telemetriedaten von jedem Durchsetzungspunkt und leitet Risikosignale zurück an die Richtlinienebene.

Bereitstellungstopologie

Die Bereitstellungsansicht zeigt, an welchen Standorten die einzelnen Durchsetzungspunkte physisch betrieben werden – in der Zentrale, in den Niederlassungen, in Cloud-Regionen und bei Remote-Benutzern.

Komponentenübersicht

Jede Komponente hat eine festgelegte Funktion, einen festgelegten Einbauort und eine Reihe von hybridspezifischen Anforderungen.

Verkehrsströme

Sechs Verkehrsströme decken die meisten Hybrid-Netzwerke ab, und jeder sollte über einen dokumentierten Durchsetzungspunkt und einen Entschlüsselungspunkt verfügen.

Ablauf 1: Zugriff eines Büronutzers auf das Internet oder auf SaaS-Dienste

Der Benutzer authentifiziert sich über den Identitätsanbieter. Der Datenverkehr wird an das lokale Gateway weitergeleitet, das die Daten entschlüsselt, auf Bedrohungen überprüft und Web- sowie Zugriffsrichtlinien anwendet; anschließend leitet es datenschutzrelevante Sitzungen zur Überprüfung gemäß denselben Richtlinien an die Cloud des Anbieters weiter. Dokumentieren Sie die TLS-Beendigung und -Neuverschlüsselung entlang dieses Pfades und vermeiden Sie redundante Überprüfungen, im Einklang mit den Leitlinien der NSA zum Umgang mit Risiken bei der TLS-Überprüfung.

Ablauf 2: Remote-Benutzer zu SaaS

Der Endpunkt-Agent oder die Browser-Steuerung leitet den Datenverkehr an den nächstgelegenen zugelassenen Cloud-Standort weiter. Es gilt derselbe Richtliniensatz wie in Ablauf 1. CASB fügt SaaS-spezifische Kontrollen hinzu, wie beispielsweise Mandantenbeschränkungen und DLP auf Aktivitätsebene.

Ablauf 3: Vom Benutzer zur privaten Anwendung

Der Zugriff erfolgt über ZTNA und nicht über ein VPN auf Netzwerkebene. Der Zugriffsdienst überprüft die Identität, den Gerätestatus und die Richtlinien und verbindet den Benutzer anschließend ausschließlich mit einer autorisierten Anwendung. Bei einer Bereitstellung kann ein Cloud-Broker für Remote-Benutzer und ein lokales Gateway für unterstützte Sitzungen vor Ort zum Einsatz kommen. Überprüfen Sie die Platzierung des Brokers, die Anwendungsprotokolle, die Sichtbarkeit der Sitzungen und den tatsächlichen Datenpfad. Siehe „On-Premises-ZTNA für private Anwendungen“.

Ablauf 4: Von Arbeitslast zu Arbeitslast

Der Datenverkehr zwischen Diensten im Rechenzentrum und IaaS-Workloads basiert auf der Workload-Identität, gegenseitigem TLS und Segmentierungsregeln. In derselben Richtlinienquelle wird festgelegt, welche Dienste miteinander kommunizieren dürfen.

Ablauf 5: In Cloud-Diensten gespeicherte Daten

Die CASB-API-Integration und der DSPM-Scan überprüfen genehmigte Cloud-Speicher und SaaS-Dienste auf sensible Daten, risikobehaftete Freigaben und übermäßige Berechtigungen und beheben diese anschließend unter Verwendung derselben Klassifizierung, die inline angewendet wird. Erfahren Sie, wie DSPM und SSE zusammenwirken.

Ablauf 6: KI-Agenten und Dienstkonten

KI-Agenten und Automatisierungssysteme verfügen häufig über Zugriffsrechte auf Benutzerebene und rufen interne APIs über langlebige Verbindungen – darunter auch WebSockets – auf, die innerhalb des Netzwerks entstehen. Weisen Sie jedem Agenten eine eigene Identität und anwendungsspezifische Berechtigungen zu, leiten Sie dessen Datenverkehr über einen lokalen Kontrollpunkt und wenden Sie DLP auf die Daten an, die er an externe KI-Dienste sendet.

Kontrollgrenzen

Kontrollgrenzen sollten um das herum gezogen werden, was geschützt werden muss, und nicht um den Standort der Anlagen.

Die Zuständigkeitsgrenze wird häufig übersehen. Wenn entschlüsselter Datenverkehr, Überwachungsprotokolle oder Kopien von DLP-Vorfällen eine Zuständigkeit verlassen, kann die Architektur gegen Aufbewahrungsverpflichtungen verstoßen, selbst wenn die gespeicherten Daten niemals übertragen werden. Siehe „Datensouveränität in der Hybrid-Cloud-Sicherheit“.

Netzwerksicherheit für Hybrid-Clouds

Die Netzwerksicherheit in einer hybriden Umgebung verlagert sich vom Schutz der Netzwerkgrenzen hin zum Schutz einzelner Verbindungen.

• Ersetzen Sie flache Site-to-Site-Vertrauensbeziehungen durch Segmentierung und anwendungsspezifischen Zugriff.
• Behalten Sie verschlüsselte Tunnel (IPsec, GRE oder private Verbindungen) zwischen Standorten und Cloud-Regionen bei, betrachten Sie die Zugehörigkeit zu einem Tunnel jedoch nicht als Autorisierung.
• Leiten Sie den Datenverkehr gezielt: explizite Proxy- oder PAC-Dateien für verwaltete Büronetzwerke, Agenten oder Browsersteuerungen für Benutzer im Roaming, Tunnel für Zweigstellen.
• Legen Sie fest, welche Komponente den jeweiligen Datenfluss entschlüsselt, damit kein Datenfluss zweimal entschlüsselt wird.
• An jedem Kontrollpunkt protokollieren und zentral abgleichen.

In NIST SP 800-215 werden diese Optionen behandelt, darunter ZTNA, Mikrosegmentierung, softwaredefinierte Perimeter sowie Secure Access Service Edge (SASE)-Modelle, die Netzwerk- und Sicherheitsdienste kombinieren.

Konstruktionsaspekte

Vier Entwurfsbereiche entscheiden darüber, ob die Architektur in der Praxis funktioniert: Identität, Protokollierung, Kapazität und Ausfallverhalten.

Identitätsarchitektur

Die Identität ist die erste Grundlage für jede Zugriffsentscheidung; daher behandelt die Referenzarchitektur vier Arten von Identitäten als vorrangige Aspekte.

• Benutzer im Unternehmen. Ein einziger, maßgeblicher Identitätsanbieter, der mit jedem Cloud-Anbieter und jeder SaaS-Anwendung vernetzt ist und über phishing-sichere MFA sowie bedingten Zugriff verfügt. Gruppen- und Rollendaten sollten aus einer einzigen Quelle stammen, damit die Zugriffsrechte zwischen den Umgebungen nicht voneinander abweichen.
• Geräte. Die Geräteidentität und der Gerätestatus (Verwaltungsstatus, Patch-Stand, Festplattenverschlüsselung, Endgeräteschutz) sollten sowohl für Benutzer vor Ort als auch für Remote-Benutzer bewertet werden.
• Workloads und Dienste. Anwendungen und Dienste authentifizieren sich gegenseitig anhand von Workload-Identitäten und gegenseitigem TLS anstelle von gemeinsamen Geheimnissen oder dem Netzwerkstandort.
• KI-Agenten und Automatisierung. Jeder Agent erhält eine eigene Identität, begrenzte Zugriffsrechte und einen verantwortlichen menschlichen Betreuer, sodass seine Handlungen unabhängig autorisiert, protokolliert und widerrufen werden können.

Zwei Designaspekte werden leicht übersehen. Erstens sollten Sitzungen bei einer Änderung des Kontexts – beispielsweise wenn ein Gerät die Konformitätsanforderungen nicht mehr erfüllt – neu bewertet werden, anstatt bis zum Ablauf ihrer Gültigkeit als vertrauenswürdig anzusehen. Zweitens sollten Sie für Administratoren einen Notfallzugriff definieren, der auch dann funktioniert, wenn der Identitätsanbieter nicht verfügbar ist, und der mit strengen Kontrollmechanismen sowie Warnmeldungen bei seiner Nutzung ausgestattet ist.

Protokollierung und Telemetrie

Die Protokollierung in einer Hybridarchitektur muss der Erkennung, Untersuchung und Einhaltung von Vorschriften dienen und dabei berücksichtigen, wohin Daten weitergeleitet werden dürfen.

• Was erfasst werden soll: Jeder Durchsetzungspunkt sollte den Benutzer, das Gerät, die Anwendung oder das Ziel, die Richtlinienentscheidung, die angewendete Regel sowie die betreffende Datenklassifizierung protokollieren. Verwenden Sie gemeinsame Korrelationsschlüssel (Benutzer-ID, Geräte-ID, Sitzungs-ID), damit Ereignisse aus der lokalen und der Cloud-basierten Durchsetzung miteinander verknüpft werden können.
• Wo werden die Daten erfasst? Lokale Erfassungsstellen an jedem größeren Standort speichern die Ereignisse zunächst und leiten sie anschließend an das zentrale SIEM weiter. Dadurch bleiben die Protokolle auch bei Ausfällen des WAN erhalten, und eine selektive Weiterleitung ist möglich.
• Was ist weiterzuleiten? Leiten Sie die für die Erkennung erforderlichen Metadaten weiter. Bewahren Sie die vollständigen DLP-Beweismittel und Inhaltsauszüge in dem Rechtsgebiet auf, in dem sie erfasst wurden, wobei der Zugriff auf autorisierte Ermittler beschränkt ist.
• Aufbewahrungsfristen. Passen Sie die Aufbewahrungsfristen an die gesetzlichen Anforderungen je nach Datenkategorie und Rechtsraum an und dokumentieren Sie dies.
• Integrität. Schützen Sie Protokolle vor Manipulationen und warnen Sie bei Lücken, die sowohl auf Ausfälle als auch auf Angriffe hindeuten können.

Kapazität und Dimensionierung

Lokale Durchsetzungsstellen müssen für den entschlüsselten Datenverkehr zu Spitzenzeiten ausgelegt sein, da dies die häufigste Ursache für Leistungsprobleme in Hybrid-Bereitstellungen ist.

• Ermitteln Sie den Spitzen-Durchsatz und die Verbindungsraten pro Standort sowie den Anteil des Datenverkehrs, der entschlüsselt wird. Die TLS-Entschlüsselung ist rechenintensiv.
• Dimensionieren Sie die Cluster so, dass ausreichend Spielraum für ein Failover vorhanden ist, damit der Ausfall eines Knotens die übrigen Knoten nicht überlastet.
• Berücksichtigen Sie den Anstieg des verschlüsselten Datenverkehrs, größere Dateiübertragungen sowie lang andauernde KI- und Kollaborationssitzungen.
• Planen Sie, wie Kapazitäten erweitert werden sollen. Virtuelle und containerisierte Appliances lassen sich schneller skalieren als dedizierte Hardware.
• Erkundigen Sie sich bei Cloud-Präsenzstandorten beim Anbieter nach der regionalen Kapazität und den Failover-Optionen, insbesondere wenn aufgrund von Standortbeschränkungen nur bestimmte Regionen genutzt werden dürfen.

Resilienz und Ausfallverhalten

Eine Referenzarchitektur ist erst dann vollständig, wenn sie festlegt, was geschieht, wenn eine der Abhängigkeiten ausfällt.

• Anbieter-Cloud nicht verfügbar: Die lokale Durchsetzung der Richtlinien für Web- und private Anwendungen wird anhand der zwischengespeicherten Richtlinien fortgesetzt, während aus der Cloud bereitgestellte Dienste – darunter Datenschutz, remote browser isolation, KI-Sicherheitskontrollen, CASB und das Management des Datensicherheitsstatus – erst wieder angewendet werden, sobald die Verbindung wiederhergestellt ist; Remote-Benutzer werden auf andere Präsenzpunkte umgeleitet.
• Identitätsanbieter nicht verfügbar: Legen Sie fest, ob bestehende Sitzungen fortgesetzt werden sollen und ob ein lokaler Fallback vorhanden ist.
• Ausfall der WAN- oder Internetverbindung am Standort: Dank der lokalen ZTNA bleibt der Zugriff auf lokale Anwendungen vor Ort weiterhin gewährleistet.
• Ausfall eines lokalen Gateways: Ein Cluster-Peer oder ein Cloud-Präsenzpunkt übernimmt unter Beibehaltung derselben Richtlinie.
• Fail-Open oder Fail-Closed: Legen Sie dies für jede Verkehrsklasse fest und machen Sie den Status für den Betrieb sichtbar.

Einen Testplan finden Sie unter „Hybrid SSE Resilience: Failover und Wiederherstellung “.

Zuordnung der Kontrollmaßnahmen zu CISA und NIST

Durch die Zuordnung jeder Komponente zu anerkannten Rahmenwerken wird die Referenzarchitektur zu einem Nachweis für Auditoren und zu einer Checkliste für die Verantwortlichen bei der Umsetzung.

Die Tabelle ordnet die Komponenten den Säulen des „Zero Trust Maturity Model“ der CISA sowie repräsentativen Kontrollfamilien in NIST SP 800-53 Rev. 5 zu.

Diese Zuordnung dient als Ausgangspunkt. Jede Organisation sollte die Anwendbarkeit der Kontrollmaßnahmen anhand ihrer eigenen Ausgangsbasis und ihres regulatorischen Geltungsbereichs überprüfen.

Anwendungsbeispiele

Dasselbe Referenzmodell lässt sich an verschiedene Branchen anpassen, indem die Kontrollpunkte verschoben werden, nicht jedoch durch eine Neugestaltung der Richtlinien.

Beispiel 1: Regionalbank

In der Zentrale und in den Rechenzentren werden lokale SWG- und ZTNA-Gateways betrieben, sodass Kundendaten ausschließlich auf der von der Bank kontrollierten Infrastruktur entschlüsselt und überprüft werden. Der Datenverkehr der Filialen erfolgt über lokale Geräte oder Tunnel zum nächstgelegenen Rechenzentrum. Mitarbeiter an entfernten Standorten nutzen Cloud-Präsenzpunkte, die auf Standorte innerhalb der jeweiligen Region beschränkt sind. Die Überprüfungsprotokolle verbleiben im jeweiligen Land. Dieses Modell erfüllt die DORA-ICT-Risikoanforderungen sowie die Anforderungen an Drittanbieter für EU-Institutionen und ermöglicht gleichzeitig den Einsatz von Cloud-CASB für SaaS.

Beispiel 2: Hersteller mit OT-Netzwerken

Eine Segmentierungs-Firewall trennt die OT-Netzwerke der Anlage von der Unternehmens-IT. OT-Systeme können über eine lokale SWG ausschließlich auf genehmigte Update- und Telemetrie-Ziele zugreifen. Ingenieure greifen über lokales ZTNA mit Gerätezustandsprüfungen auf die Anlagensysteme zu. Sollte das WAN oder ein Cloud-Dienst ausfallen, werden der Zugriff auf die Anlage und die Überwachung lokal fortgesetzt.

Beispiel 3: Behörde des öffentlichen Sektors

Für klassifizierte oder isolierte Netzwerke sind Komponenten erforderlich, die ausdrücklich für den Betrieb ohne externe Dienste unterstützt werden. In nicht klassifizierten Netzwerken dürfen für Remote-Mitarbeiter entsprechend autorisierte Cloud-Dienste genutzt werden. Dokumentieren Sie die Abhängigkeiten hinsichtlich Richtlinienabgleich, Identitäten, Aktualisierungen und Lizenzen und unterziehen Sie umgebungsspezifische Ausnahmen einer Änderungskontrolle.

Beispiel 4: Regionales Gesundheitssystem

Die elektronischen Patientenakten und Bildgebungssysteme werden in den Rechenzentren des Gesundheitssystems betrieben. Klinische Arbeitsplätze in Krankenhäusern nutzen lokale Gateways, sodass Patientendaten im Web- und SaaS-Datenverkehr vor Ort überprüft werden. Medizinische Geräte befinden sich in segmentierten Zonen mit streng eingeschränkten ausgehenden Zugängen. Klinisches Personal, das remote arbeitet, greift über den Cloud-ZTNA-Broker auf die elektronische Gesundheitsakte zu, wobei Anforderungen an verwaltete Geräte gelten; DLP-Regeln für geschützte Gesundheitsdaten finden in beiden Zugriffspfaden gleichermaßen Anwendung und unterstützen damit die Sicherheitsvorkehrungen der HIPAA-Sicherheitsvorschrift.

Beispiel 5: Weltweit tätiger Einzelhändler

Filialen nutzen kleine Filial-Gateways oder Tunnel zu regionalen Hubs, wobei die Kassensysteme in einer segmentierten Umgebung für Karteninhaberdaten betrieben werden, auf die ausschließlich Zahlungsabwickler Zugriff haben. Das Surfen von Mitarbeitern der Unternehmenszentrale und der Filialen wird an regionalen Hubs oder Cloud-Präsenzpunkten überwacht, wobei der europäische Datenverkehr auf EU-Regionen beschränkt und die Protokolle regional gespeichert werden. Die Filialsysteme bleiben auch bei Ausfällen des Weitverkehrsnetzwerks (WAN) in Betrieb, da die lokale Segmentierung und die Zugriffsregeln nicht von der Cloud abhängig sind. Dies unterstützt die Segmentierungs- und Protokollierungsanforderungen des PCI DSS.

Reifegradverlauf und Validierung

Nutzen Sie die Reifegrade der CISA, um die Einführung schrittweise durchzuführen, und führen Sie wiederholbare Tests durch, um nachzuweisen, dass jede Phase funktioniert.

Fälligkeitsverlauf

Unternehmen setzen die Referenzarchitektur selten auf einmal vollständig um; das Modell der CISA beschreibt vier Phasen („Traditionell“, „Anfänglich“, „Fortgeschritten“ und „Optimal“), die einen nützlichen Fahrplan darstellen.

Nutzen Sie die Lücke zwischen der aktuellen Phase und der nächsten als Grundlage für einen stufenweisen Plan.

Validierung der Architektur

Eine Architektur ist nur so gut wie ihr getestetes Verhalten; überprüfen Sie daher jeden Ablauf und jede Grenze mit wiederholbaren Tests.

• Leiten Sie eine bekanntermaßen schädliche URL, eine Test-Malware-Datei und ein DLP-Testdokument durch jeden Kontrollpunkt und überprüfen Sie, ob die Ergebnisse mit dem verfügbaren Cloud-Pfad übereinstimmen. Erfassen Sie das erwartete Verhalten der in der Cloud angewendeten Kontrollen, wenn dieser Pfad unterbrochen wird.
• Stellen Sie sicher, dass jeder Datenstrom genau einmal entschlüsselt wird.
• Versuchen Sie, von einem lokalen, einem Remote- und einem nicht verwalteten Gerät aus auf eine private Anwendung zuzugreifen, und überprüfen Sie die erwarteten Ergebnisse.
• Sperren Sie den Zugriff von einem Standort aus auf die Cloud des Anbieters und stellen Sie sicher, dass die lokalen Richtlinien weiterhin eingehalten werden.
• Stellen Sie sicher, dass die Protokolle aller Kontrollpunkte das SIEM erreichen und dass die Aufbewahrungsvorschriften eingehalten werden.

Wie sich Skyhigh in die Referenzarchitektur einordnet

Skyhigh Hybrid SSE Mesh deckt die Steuerungsebene (eine Konsole und eine Policy-Engine, bei der Richtlinien als Code bereitgestellt werden), die lokale Durchsetzung (lokale SWG-Appliances mit lokaler TLS-Prüfung und lokalem ZTNA), die Durchsetzung in der Cloud (Cloud-SWG, CASB, ZTNA und RBI), Kontrollen auf Browserebene sowie DSPM ab (Skyhigh Security).

Für den Schutz von Inspektionsschlüsseln und die Sandbox-Umgebung vor Ort klären Sie bitte die unterstützten Integrationen, Produktversionen und Bereitstellungsanforderungen mit Skyhigh ab. Gehen Sie nicht davon aus, dass das ausgewählte Gateway oder der ausgewählte Dienst HSM unterstützt.

Quellen

1. NIST. SP 800-207: Zero-Trust-Architektur (August 2020). https://csrc.nist.gov/pubs/sp/800/207/final
2. NIST. SP 800-215: Leitfaden für eine sichere Unternehmensnetzwerkinfrastruktur (November 2022). https://csrc.nist.gov/pubs/sp/800/215/final
3. NIST NCCoE. SP 1800-35: Implementierung einer Zero-Trust-Architektur (Juni 2025). https://csrc.nist.gov/pubs/sp/1800/35/final
4. NIST. SP 800-53 Rev. 5: Sicherheits- und Datenschutzmaßnahmen für Informationssysteme und Organisationen. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
5. CISA. Zero-Trust-Reifegradmodell, Version 2.0. https://www.cisa.gov/zero-trust-maturity-model
6. NSA. Umgang mit Risiken durch die Überprüfung der Transportschicht-Sicherheit (November 2019). https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
7. Europäische Union. Verordnung (EU) 2022/2554 (Gesetz über digitale Betriebsresilienz). https://eur-lex.europa.eu/eli/reg/2022/2554/oj
8. US-Gesundheitsministerium (HHS). HIPAA-Sicherheitsvorschrift. https://www.hhs.gov/hipaa/for-professionals/security/index.html
9. PCI Security Standards Council. PCI DSS v4.0.1 (Dokumentenbibliothek). https://www.pcisecuritystandards.org/document_library/
10. Skyhigh Security. „Modernisierung Ihrer Symantec Edge- Secure Web Gateway s mit Skyhigh Hybrid SSE Mesh“ (15. Juli 2026). https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
11. Skyhigh Security. „Die Einführung von Hybrid-Lösungen ist mit der Skyhigh SSE-Plattform jetzt noch einfacher“ (3. Oktober 2024). https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html