Bereitstellung einer privaten SSE: Architektur und Cloud-Abhängigkeiten
- Bei „Private SSE“ werden das Web-Gateway und die Durchsetzung privater Anwendungen auf einer vom Kunden kontrollierten Infrastruktur betrieben, während Datendienste wie beispielsweise der Datenschutz weiterhin von der Cloud des Anbieters bereitgestellt werden können. Ordnen Sie die einzelnen Elemente ein.
- Bewerten Sie die Datenebene, die Steuerungsebene und die unterstützenden Dienste getrennt voneinander, da jede dieser Komponenten privat oder in der Cloud betrieben werden kann.
- Die meisten selbst gehosteten SSE-Lösungen sind in irgendeiner Hinsicht nach wie vor von der Cloud des Anbieters abhängig; erfassen Sie daher alle ausgehenden Abhängigkeiten.
- Telemetrie besteht aus Daten; entscheiden Sie, welche Protokolle, Stichproben und Metadaten Ihre Umgebung verlassen und wohin sie übertragen werden.
- Private und Cloud-basierte SSE können parallel betrieben werden, wobei die private Durchsetzung den Standorten vorbehalten ist, die diese benötigen.
„Private SSE“ ist ein Bereitstellungsmodell, bei dem Funktionen von „ Security Service Edge “, wie beispielsweise „ secure web gateway “ (SWG), „ zero trust network access “ (ZTNA) und „ data loss prevention “ (DLP), auf einer vom Kunden gehosteten Infrastruktur ausgeführt werden. Es wird von Unternehmen genutzt, die die Überprüfung des Datenverkehrs, Schlüssel oder Protokolle innerhalb ihrer eigenen Einrichtungen oder Gerichtsbarkeiten aufbewahren müssen oder die darauf angewiesen sind, dass ihre Sicherheitsmaßnahmen unabhängig von einer externen Cloud weiterhin funktionieren.
Gartner definiert SSE als eine Lösung, die in erster Linie über die Cloud bereitgestellt wird, weist jedoch darauf hin, dass sie auch lokale oder agentenbasierte Komponenten umfassen kann. Bei einer privaten SSE-Lösung stehen diese Komponenten im Mittelpunkt.
Dieser Artikel ist Teil des Leitfadens zur Hybrid-Cloud-Sicherheit.
Die drei Ebenen einer SSE-Architektur
Jede SSE-Bereitstellung – sei es in der Cloud oder in einer privaten Umgebung – besteht aus drei logischen Schichten.
Das Zero-Trust-Modell des NIST in SP 800-207 unterscheidet ebenfalls zwischen Richtlinienentscheidungen und der Durchsetzung von Richtlinien.
Datenebene. Die Komponenten, die sich im Datenfluss befinden und Verbindungen überprüfen oder vermitteln: Web-Proxys, ZTNA-Gateways, TLS-Überprüfung, DLP-Scans und Malware-Analyse. Hier liegen die Daten im Klartext vor.
Steuerungsebene. Hier definieren Administratoren Richtlinien, verwalten Identitäten und Gruppen und übertragen Konfigurationen an Durchsetzungspunkte. Dabei kann es sich um eine Konsole vor Ort, in der Cloud des Anbieters oder um beides handeln.
Unterstützende Dienste. Die Elemente, auf die sich Durchsetzungsstellen bei ihren Entscheidungen stützen: URL-Kategorisierung, Bedrohungsinformationen, Dateireputation, Sandboxing, Software- und Signatur-Updates, Lizenzierung sowie Analysen.
Ein Einsatz ist nur so vertraulich wie seine am wenigsten vertrauliche Ebene.
Modelle für den privaten Einsatz von SSE
Private SSE reicht von einer privaten Datenebene mit Cloud-Verwaltung bis hin zu vollständig privaten Bereitstellungen ohne externe Abhängigkeiten. Hierbei handelt es sich um Testmodelle; die Verfügbarkeit und die Betriebsgrenzen hängen vom ausgewählten Produkt ab.
| Modell | Datenebene | Steuerungsebene | Begleitende Dienstleistungen | Typische Passform |
|---|---|---|---|---|
| Cloud-SSE | Anbieter-Cloud | Anbieter-Cloud | Anbieter-Cloud | Unternehmen, bei denen die Arbeit im Homeoffice im Vordergrund steht |
| Hybrid-SSE | Kunden- und Lieferanten-Cloud | Anbieter-Cloud oder einheitliche Konsole | Anbieter-Cloud mit lokalen Caches | Regulierte Unternehmen mit Mitarbeitern im Homeoffice |
| Private Datenebene | Kundeninfrastruktur | Anbieter-Cloud | Anbieter-Cloud | Vor-Ort-Prüfung erforderlich, Cloud-Management zulässig |
| Völlig privat | Kundeninfrastruktur | Kundeninfrastruktur | Vom Kunden gehostete oder Offline-Updates | Air-Gapped-, geheimhaltungsrelevante oder hoheitliche Umgebungen |
Das Modell mit privater Datenebene ist am weitesten verbreitet. Dabei erfolgen Entschlüsselung und Überprüfung lokal, während für Richtlinien und Analysen eine Cloud-Konsole genutzt wird. Vollständig private Bereitstellungen sind seltener und stellen höhere Anforderungen an das Betriebsteam des Kunden.
Vom Kunden gehostete Komponenten
Bei einer privaten oder hybriden SSE-Bereitstellung hostet und betreibt der Kunde die Durchsetzungs- und Schlüsselkomponenten, zu denen in der Regel Folgendes gehört:
- Web-Gateway-Geräte – physisch, virtuell oder in Containern – für die lokale TLS-Prüfung und die Durchsetzung von Web-Richtlinien
- ZTNA-Gateways oder -Konnektoren, die den Zugriff auf private Anwendungen vermitteln
- DLP-Scanning, sofern ein Anbieter dies vor Ort anbietet; Skyhigh wendet über seine Cloud Datenschutzmaßnahmen auf den Datenverkehr an, den das Gateway weiterleitet
- Sandboxing vor Ort für sensible Dateien
- Prüfungder Zertifizierungsstelle (CA) und der Schlüsselaufbewahrung, wobei eine hardwaregestützte Verwahrung nur dort erfolgt, wo dies unterstützt und verifiziert wurde
- Protokollsammler, die Ereignisse lokal speichern und ausgewählte Daten weiterleiten
Der Kunde ist für die Kapazität, die Verfügbarkeit, die Installation von Patches sowie die physische Sicherheit dieser Komponenten verantwortlich.
Zuzuordnende Cloud-Abhängigkeiten
Die meisten privaten SSE-Implementierungen sind nach wie vor in irgendeiner Weise von der Anbieter-Cloud abhängig; listen Sie daher jede Abhängigkeit und das entsprechende Ausfallverhalten auf.
Bevor Sie eine private SSE-Architektur bewerten, bitten Sie den Anbieter, alle ausgehenden Verbindungen von beim Kunden gehosteten Komponenten aufzulisten und anzugeben, was geschieht, wenn die jeweilige Verbindung nicht verfügbar ist:
| Abhängigkeit | Frage, die Sie stellen sollten | Worauf Sie achten sollten |
|---|---|---|
| Richtlinien und Konfiguration | Wird die Durchsetzung mit der zuletzt bekannten Richtlinie fortgesetzt, wenn die Konsole nicht erreichbar ist? | Zwischengespeicherte Richtlinie mit definiertem Verhalten |
| URL-Kategorisierung und Reputation | Erfolgen die Abfragen lokal, in der Cloud oder in einer Hybridumgebung? | Lokale Datenbank mit Aktualisierung über die Cloud |
| Bedrohungsinformationen und Signaturen | Wie werden Updates bereitgestellt, und können sie schrittweise oder offline bereitgestellt werden? | Stufenweise Aktualisierungen; Offline-Option für Standorte ohne Internetverbindung |
| Sandboxing | Werden Dateien an eine Cloud-Sandbox gesendet? | Option für eine lokale Sandbox |
| Authentifizierung | Hängt der Zugriff von einem Cloud-Identitätsdienst ab? | Ausweichlösung für lokale Identitäten oder zwischengespeicherte Token |
| Lizenzierung | Wird die Durchsetzung eingestellt, wenn die Führerscheinkontrollen fehlschlagen? | Nachfrist |
| Protokollierung und Analyse | Was wird übermittelt, wo wird es gespeichert und lässt sich diese Funktion deaktivieren? | Konfigurierbare Felder und Bereiche |
| Zugang zum Support | Können Mitarbeiter des Anbieters auf vom Kunden gehostete Komponenten zugreifen? | Vom Kunden gesteuerter, geprüfter Zugriff |
Entscheiden Sie für jede Abhängigkeit, ob das Standardverhalten akzeptabel ist oder ob eine lokale Alternative erforderlich ist.
Telemetrie-Datenströme
Telemetriedaten von privaten Kontrollstellen stellen eigenständige Daten dar und können Folgendes umfassen:
- Zugriffsprotokolle: Benutzer, Gerät, URL, Kategorie, Aktion
- Vorfälle im Zusammenhang mit dem Schutz vertraulicher Informationen (DLP), teilweise mit Auszügen aus den Inhalten oder vollständigen Kopien
- Datei-Hashes oder Proben zur Bedrohungsanalyse
- Leistungs- und Gesundheitskennzahlen
- Nutzungsdaten für die Lizenzierung
Ein Teil davon ist harmlos. Ein anderer Teil besteht aus regulierten Daten. Erstellen Sie eine Telemetriekarte, die jeden Datenstrom, dessen Inhalt, dessen Ziel sowie dessen Aufbewahrungsdauer erfasst. Dies ist oft der entscheidende Unterschied zwischen einer erfolgreich abgeschlossenen und einer ins Stocken geratenen Souveränitätsprüfung. Siehe „Datensouveränität in der Hybrid-Cloud-Sicherheit“.
Ein sinnvolles Verfahren besteht darin, sensible Daten innerhalb der Kundenumgebung zu „fingerprinten“ und lediglich Hash-Werte an den Dienst zu übermitteln, sodass die geschützten Inhalte selbst niemals das System verlassen. Erkundigen Sie sich bei jedem Anbieter, wo Fingerabdrücke für den exakten Datenabgleich und den Dokumentenabgleich generiert werden und welche Daten übertragen werden. Skyhigh generiert und wendet den Datenschutzabgleich in seiner Cloud an.
Wann eine private SSE sinnvoll ist
Eine private SSE ist dann sinnvoll, wenn Regulierung, Anbindung, Betriebstechnik, Verkehrsaufkommen oder die Erneuerung veralteter Anlagen eine lokale Umsetzung erfordern.
- Vorschriften oder Verträge schreiben vor, dass entschlüsselter Datenverkehr, Schlüssel oder Protokolle im Inland oder vor Ort verbleiben müssen
- Die Netzwerke sind luftisoliert, als vertraulich eingestuft oder nur zeitweise miteinander verbunden
- Betriebstechnische Systeme oder kritische Infrastrukturen müssen bei externen Ausfällen weiterhin funktionieren
- Das interne Datenverkehrsvolumen führt dazu, dass die Überprüfung in der Cloud kostspielig oder langsam ist
- Das Unternehmen ersetzt einen lokal installierten Proxy und möchte eine Modernisierung vornehmen, ohne dabei zwangsläufig auf die Cloud umsteigen zu müssen.
Wenn keiner dieser Punkte zutrifft, ist der Betriebsaufwand bei Cloud-SSE in der Regel geringer.
Betriebliche Kompromisse
Bei der privaten SSE liegt die Verantwortung wieder beim Kunden: Dimensionierung, Redundanz, Patching, Vorbereitung von Updates und Fehlerbehebung.
Zu den Vorteilen zählen die Kontrolle über Klartext, Schlüssel und Protokolle sowie die Kontinuität, wenn die Cloud des Anbieters nicht erreichbar ist. Hybride Konzepte ermöglichen es Unternehmen, die interne Durchsetzung auf die Standorte und den Datenverkehr zu beschränken, bei denen dies erforderlich ist.
Wie Skyhigh private und hybride SSE unterstützt
Skyhigh unterstützt private und hybride SSE-Lösungen mit einer lokal betriebenen Datenebene, die über dieselbe Konsole verwaltet wird wie die Cloud-Dienste des Unternehmens.
Skyhigh Hybrid SSE Mesh setzt die Richtlinien für „ secure web gateway “ und „Zero Trust Access“ auf dem kundeneigenen lokalen Gateway durch – mit lokaler TLS-Prüfung und einer im März 2026 eingeführten containerisierten Appliance-Architektur – und wendet Datenschutz, CASB sowie die weiteren Datendienste in der Skyhigh-Cloud auf den vom Gateway weitergeleiteten Datenverkehr an, und zwar alles im Rahmen einer einzigen Richtlinie, die über eine einzige Konsole erstellt wird. Die Steuerungsebene wird über die Cloud bereitgestellt, sodass die Erstellung von Richtlinien, die Berichterstellung und die Protokollübermittlung von der Erreichbarkeit der Cloud abhängen, während die lokale Durchsetzung der Richtlinien für Web- und private Anwendungen vor Ort fortgesetzt wird, falls diese Verbindung unterbrochen wird. Skyhigh verfügt über eine FedRAMP-High-Zulassung.
Quellen
- Gartner. „Security Service Edge “ (SSE), Glossar der Informationstechnologie. https://www.gartner.com/en/information-technology/glossary/security-service-edge-sse
- NIST. SP 800-207: Zero-Trust-Architektur (August 2020). https://csrc.nist.gov/pubs/sp/800/207/final
- Skyhigh Security. „Skyhigh Security kündigt neue Lösungen zur Stärkung seiner bahnbrechenden universellen SSE-Plattform an“ (24. März 2026). https://www.skyhighsecurity.com/about/newsroom/newswire/skyhigh-security-announces-new-solutions-to-strengthen-disruptive-universal-sse-platform.html
- 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
- 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