Lokale TLS-Prüfung vs. TLS-Prüfung in der Cloud: Abwägungen bei der Bereitstellung
- Bei der TLS-Prüfung wird der Datenverkehr entschlüsselt, geprüft und erneut verschlüsselt, sodass der Klartext – wo auch immer dies geschieht – kurzzeitig vorliegt.
- Durch eine lokale Überprüfung erhalten Sie die Kontrolle über lokale Klartextdaten und Schlüssel; bewerten Sie cloudbasierte Dienste und deren Verarbeitung separat.
- Die NSA-Leitlinien empfehlen, jede Sitzung einmal innerhalb des Unternehmensnetzwerks und ohne verkettete Proxys zu überprüfen.
- Führen Sie eine geprüfte Ausnahmeliste für angeheftete Apps, datenschutzrelevante Kategorien und Datenverkehr, der bei der Überprüfung fehlschlägt,.
- Das als RFC 9849 veröffentlichte „Encrypted Client Hello“ schränkt die passive Sichtbarkeit ein und erfordert eine bewusste Handhabung.
Die TLS-Überprüfung (oft noch als SSL-Überprüfung bezeichnet) ist der Vorgang, bei dem eine TLS-Sitzung abgefangen, mit einem vom Unternehmen vertrauenswürdigen Zertifikat entschlüsselt, der Inhalt überprüft und die Sitzung vor der Weiterleitung an den Empfänger erneut verschlüsselt wird. Ohne diese Funktion sehen sichere Web-Gateways, DLP-Engines und Sandboxes lediglich die Metadaten des Ziels. Mit dieser Funktion können sie Malware erkennen, Datenexfiltration verhindern und Richtlinien zur zulässigen Nutzung innerhalb verschlüsselter Sitzungen durchsetzen.
Die Entscheidung lautet nicht, ob eine Überprüfung stattfinden soll, sondern wo. In diesem Leitfaden werden die lokale und die Cloud-basierte TLS-Überprüfung hinsichtlich Entschlüsselungspfaden, Zuständigkeiten für Zertifikate, Ausnahmen, Protokollierung und Betrieb verglichen.
Dieser Artikel ist Teil des Leitfadens zur Hybrid-Cloud-Sicherheit.
So funktioniert die TLS-Prüfung
Bei der TLS-Überprüfung beendet ein vertrauenswürdiger Proxy die verschlüsselte Sitzung des Clients, überprüft den Inhalt und eröffnet eine neue verschlüsselte Sitzung zum Ziel.
Der Proxy fungiert gegenüber dem Client als Server und gegenüber dem Ziel als Client:
- Der Client initiiert eine TLS-Sitzung mit einer Website oder einer Anwendung.
- Der Proxy fängt die Verbindung ab und legt ein Zertifikat für das Ziel vor, das von einer Zertifizierungsstelle (CA) für die Unternehmensüberprüfung signiert wurde, der die Client-Geräte vertrauen.
- Der Proxy eröffnet eine eigene TLS-Sitzung mit dem eigentlichen Ziel und überprüft das Zertifikat dieses Servers.
- Der Datenverkehr wird zwischen den beiden Sitzungen entschlüsselt, überprüft und erneut verschlüsselt.
Dies bedeutet, dass der Proxy über einen sehr leistungsstarken Schlüssel verfügt und bei jeder überprüften Sitzung Klartext verarbeitet. Die NSA-Empfehlung „Managing Risk from Transport Layer Security Inspection“ rät dazu, solche Fälle auf ein Minimum zu beschränken: Führen Sie die Überprüfung nur einmal innerhalb des Unternehmensnetzwerks durch und vermeiden Sie redundante Überprüfungen durch mehrere Forward-Proxys. In einer früheren Warnung der CISA zum Thema HTTPS-Abfang wurde darauf hingewiesen, dass schlecht implementierte Überprüfungsprodukte die TLS-Sicherheit schwächen können, beispielsweise durch eine unzureichende Validierung von vorgelagerten Zertifikaten.
TLS-Prüfung vor Ort vs. in der Cloud – auf einen Blick
Bei der lokalen Überprüfung verbleiben Klartext und Schlüssel in Ihrer Infrastruktur, während sie bei der Cloud-Überprüfung an die Präsenzpunkte des Anbieters übertragen werden.
| Faktor | Lokale (vor Ort durchgeführte) TLS-Überprüfung | TLS-Prüfung in der Cloud |
|---|---|---|
| Wo Klartext vorliegt | Ihre Geräte im Rechenzentrum oder in den Niederlassungen | Präsenzstandorte der Anbieter |
| Wer verwahrt den privaten Schlüssel der Zertifizierungsstelle für die Überprüfung? | Sie, optional in Ihrem eigenen HSM | Anbieter oder Sie über vom Anbieter unterstützte Schlüsseloptionen |
| Am besten geeignet für | Regulierte Daten, interner Datenverkehr, Nutzer vor Ort, OT | Remote-Benutzer, Datenverkehr direkt zu SaaS-Diensten |
| Latenz für Nutzer vor Ort | Hängt von der lokalen Kapazität und der Verkehrsführung ab | Hängt von der Entfernung zum Präsenzpunkt und vom Routing ab |
| Kapazitätsplanung | Mit freundlichen Grüßen; die Entschlüsselung ist rechenintensiv | Anbieter |
| Abhängigkeit von externen Verbindungen | Keine für die Durchsetzung lokaler Webrichtlinien; erforderlich für Cloud-basierte Dienste wie beispielsweise den Datenschutz | Erforderlich |
| Speicherort von Protokollen und Beweismitteln | Lokale Protokolle sind konfigurierbar; die Aufzeichnungen von Cloud-Diensten richten sich nach den Speicherrichtlinien des jeweiligen Dienstes | Anbieterregionen, je nach Konfiguration |
| Operativer Aufwand | Hardware-Dimensionierung, Patching, Lebenszyklus von Zertifikaten | Zertifikatsverteilung, Ausnahmen, Anbieter-Konfiguration |
Die meisten hybriden Organisationen nutzen beides: lokale Überprüfung für ausgewählten Datenverkehr vor Ort und regulierten Datenverkehr sowie Cloud-Überprüfung für Remote-Benutzer. Ordnen Sie die TLS-Terminierung jedem Pfad zu und vermeiden Sie redundante Entschlüsselung, auch wenn ein lokales Gateway Datenverkehr für in der Cloud bereitgestellte Dienste weiterleitet.
Entschlüsselungspfade
Jedes Hybridkonzept sollte jeden TLS-Terminierungs- und Neuverschlüsselungspunkt abbilden und redundante Überprüfungen vermeiden.
Zu den gängigen Pfaden gehören:
- Zugang vom Bürobenutzer zum Internet: über ein lokales Gateway oder über einen Tunnel zu einem Cloud-Standort
- Remote-Benutzer zum Internet: Cloud-Präsenzpunkt oder über ein Backhaul-Verbindung zu einem lokalen Gateway
- Benutzer zur privaten App: Stellen Sie fest, ob und wo der ausgewählte ZTNA-Pfad die TLS-Prüfung unterstützt
- Browsersitzung: Steuerelemente auf Browserebene, die Inhalte ohne Netzwerkentschlüsselung anzeigen
- Endpunkt: agentenbasierte Überprüfung auf dem Gerät
Ein Risiko in hybriden Umgebungen ist die ungeplante doppelte Entschlüsselung. Eine Niederlassung könnte Datenverkehr zunächst über einen lokalen Proxy und anschließend über einen Cloud-Dienst leiten, der die TLS-Verbindung erneut beendet. Dokumentieren Sie jede erforderliche Prüfstufe, sichern Sie jede Klartextgrenze ab und entfernen Sie redundante Stufen, die das Sicherheitsrisiko erhöhen oder die Fehlerbehebung erschweren.
Verantwortlichkeiten im Zusammenhang mit Zertifikaten
Die TLS-Prüfung ist nur so vertrauenswürdig wie die ihr zugrunde liegenden Zertifikate; legen Sie daher für jeden Abschnitt des Zertifikatslebenszyklus klare Zuständigkeiten fest:
- Erstellung und Schutz von CA-Zertifikaten. Dokumentieren Sie, wo sich der private Schlüssel befindet, wer darauf zugreifen darf und ob ein HSM erforderlich ist. Vergewissern Sie sich, welche HSM-Integrationen für jedes lokale Gateway bzw. jeden Cloud-Dienst und die jeweilige Produktversion unterstützt werden; gehen Sie nicht einfach davon aus, dass eine Unterstützung gegeben ist.
- Verteilung. Wie die Zertifizierungsstelle (CA) in den Vertrauensspeichern des Betriebssystems und des Browsers auf verwalteten Geräten installiert wird und was auf nicht verwalteten Geräten geschieht.
- Rotation. Der Zeitplan und der Ablauf für den Austausch der Prüf-CA ohne Betriebsunterbrechung.
- Validierung auf der Eingangsseite. Stellen Sie sicher, dass der Proxy ungültige, abgelaufene oder widerrufene Zielzertifikate zurückweist, anstatt sie vor den Benutzern zu verbergen.
- Protokollunterstützung. TLS 1.3 (RFC 8446) sollte nativ verarbeitet und nicht auf eine niedrigere Version herabgestuft werden.
Verkehrsausnahmen
Keine Organisation sollte alles entschlüsseln; führen Sie daher eine dokumentierte und regelmäßig überprüfte Ausnahmeliste:
| Ausnahmetyp | Grund | Typische Handhabung |
|---|---|---|
| Anwendungen mit festgelegten Zertifikaten | Die Überprüfung unterbricht die Verbindung | Umgehung nach Zielort; Anwendung von Reputations- und Kategorieprüfungen |
| Kategorien: Gesundheit, Finanzen und Persönliches | Datenschutz der Mitarbeiter, gesetzliche Vorschriften und betriebsratsrechtliche Anforderungen | Entschlüsselung umgehen; Kategorie-Richtlinie weiterhin durchsetzen |
| Gegenseitige TLS- und Client-Zertifikat-Authentifizierung | Der Proxy kann das Client-Zertifikat nicht vorlegen | Umgehen Sie dies oder nutzen Sie eine unterstützte Pass-Through-Funktion |
| Aktualisierungsdienste und einige OT-Protokolle | Stabilität und Herstellerunterstützung | Umleitung nach Zielort bei eingeschränkter Zufahrt |
| QUIC und HTTP/3 (RFC 9000) | Viele Proxys können QUIC nicht überprüfen | Blockieren Sie QUIC, damit Browser auf TLS über TCP zurückgreifen, oder bestätigen Sie die native Unterstützung |
Überprüfen Sie die Ausnahmen vierteljährlich. Veraltete Umgehungen stellen häufig einen blinden Fleck dar.
Verschlüsseltes „Client Hello“ und welche Auswirkungen dies hat
Durch „Client Hello“ verschlüsselt wird der Zielhostname vor passiven Beobachtern verborgen, sodass die auf SNI basierende Erkennbarkeit und einige Entscheidungen bezüglich der Umgehung neu überdacht werden müssen.
„Encrypted Client Hello“ wurde im Jahr 2026 als RFC 9849 veröffentlicht. ECH verschlüsselt den Teil des TLS-Handshakes, der zuvor den Hostnamen des Zielservers (die „Server Name Indication“, SNI) sowie weitere Felder offenlegte. Passive Tools, die den Datenverkehr anhand der SNI klassifizieren, verlieren bei ECH-fähigen Websites diese Einblicke.
Explizite Proxys, die TLS beenden, befinden sich in einer anderen Situation, da sie eigene Sitzungen zu den Zielsystemen aufbauen. Dennoch hat ECH betriebliche Auswirkungen:
- Browser senden unter Umständen ECH-ähnliche Erweiterungen, auch wenn ECH nicht verwendet wird; daher müssen Überwachungsprogramme diese korrekt verarbeiten.
- In dem RFC wird darauf hingewiesen, dass in verwalteten Unternehmensumgebungen ein Ansatz darin besteht, ECH über Gruppenrichtlinien zu deaktivieren und darauf zu vertrauen, dass die Clients diese Einstellung einhalten.
- Für Entscheidungen hinsichtlich Kategorie und Reputation, die bei umgeleitetem Datenverkehr auf der SNI basierten, ist eine Alternative erforderlich, beispielsweise Kontrollen auf DNS-Ebene oder eine explizite Proxy-Konfiguration.
Überprüfen Sie die ECH-Roadmap Ihres Inspektionsanbieters und dessen Testverhalten mit aktuellen Browserversionen.
Protokollierung
Da Überwachungsprotokolle URLs, Identitäten und DLP-Nachweise enthalten können, erfordern deren Inhalt, Speicherort und Zugriff ausdrückliche Entscheidungen:
- Welche Felder werden für entschlüsselten bzw. umgeleiteten Datenverkehr protokolliert?
- Wo werden die Holzstämme gelagert, und dürfen sie das Zuständigkeitsgebiet verlassen?
- Aufbewahrungsfristen und die Frage, wer Zugriff auf den vollständigen Beweisstoff hat
- Welche Ereignisse werden an das SIEM weitergeleitet?
Durch eine lokale Überprüfung lassen sich Protokolle und Nachweise leichter im Inland aufbewahren. Bei einer Überprüfung in der Cloud müssen die Speicherorte der Protokolle sowie die Zugriffskontrollen des Anbieters überprüft werden. Siehe „Datenhoheit in der Hybrid-Cloud-Sicherheit“.
Operative Kompromisse
Bei der lokalen Inspektion wird der operative Aufwand gegen die Kontrolle eingetauscht, bei der Cloud-Inspektion die Kontrolle gegen Einfachheit, und bei der hybriden Inspektion ist eine einzige Richtlinien-Engine erforderlich, damit das System funktioniert.
Die lokale Überprüfung erfordert die Dimensionierung der Geräte für die Entschlüsselung bei Spitzenauslastung, die regelmäßige Aktualisierung der Überprüfungs-Engines sowie die Planung des Ausbaus der Hardware- oder virtuellen Kapazitäten. Im Gegenzug bietet sie vollständige Kontrolle über Klartext, Schlüssel und Protokolle des lokal überprüften Datenverkehrs, und die lokale Durchsetzung von Richtlinien für Web- und private Anwendungen wird auch während einer Unterbrechung des WAN- oder Cloud-Zugangs fortgesetzt, während die in der Anbieter-Cloud bereitgestellten Dienste so lange pausieren, bis die Verbindung wiederhergestellt ist.
Durch die Cloud-Prüfung werden die Kapazitätsplanung und die Aktualisierung der Engine auf den Anbieter verlagert. Die Verteilung von Zertifikaten, das Ausnahmemanagement und die Anpassung der Richtlinien sind weiterhin erforderlich, und es entsteht eine Abhängigkeit von der Verfügbarkeit und Konnektivität des Anbieters.
Die Hybridprüfung kombiniert beides, funktioniert jedoch nur dann einwandfrei, wenn eine einzige Policy-Engine zum Einsatz kommt. Verfügen lokale und Cloud-Gateways über separate Ausnahmelisten und DLP-Regeln, werden die Benutzer je nach Standort unterschiedlich behandelt.
Wie Skyhigh die Inspektion vor Ort und in der Cloud angeht
Skyhigh überprüft TLS lokal, sofern dies aufgrund der Compliance-Anforderungen erforderlich ist, sowie in der Cloud für Remote-Benutzer – und zwar im Rahmen einer einheitlichen Richtlinie.
Skyhigh Hybrid SSE Mesh führt die SSL/TLS-Entschlüsselung und -Prüfung lokal auf den unternehmenseigenen Geräten durch, sofern dies aus Compliance-Gründen erforderlich ist, sowie in den Skyhigh-Cloud-Präsenzpunkten für Remote-Benutzer, wobei für beide Bereiche eine einheitliche Richtlinien-Engine zum Einsatz kommt. „ Secure Web Gateway “ und „Zero Trust Access“ werden nativ am Gateway durchgesetzt, während die Datenschutzrichtlinie in der Skyhigh-Cloud auf den vom Gateway weitergeleiteten Datenverkehr angewendet wird. Der am lokalen Gateway entschlüsselte Webdatenverkehr wird dort überprüft und zur Durchsetzung lokaler Webrichtlinien erneut verschlüsselt. Wenn eine Richtlinie einen in der Cloud bereitgestellten Dienst wie den Datenschutz nutzt, leitet das Gateway den entsprechenden Datenverkehr an die Skyhigh-Cloud weiter, wo dieselbe Richtlinie angewendet wird. Agentless Secure Browser Controls ergänzen dies um eine WebSocket-fähige Überprüfung von KI- und Messaging-Datenverkehr innerhalb der Browsersitzung.
Quellen
- 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
- CISA. „HTTPS-Abfang schwächt die TLS-Sicherheit“ (Warnmeldung TA17-075A, März 2017). https://www.cisa.gov/news-events/alerts/2017/03/16/https-interception-weakens-tls-security
- IETF. RFC 8446: Das Transport Layer Security (TLS)-Protokoll, Version 1.3. https://www.rfc-editor.org/rfc/rfc8446.html
- IETF. RFC 9849: TLS-verschlüsseltes „Client Hello“. https://www.rfc-editor.org/rfc/rfc9849.html
- IETF. RFC 9000: QUIC: Ein UDP-basierter, multiplexierter und sicherer Transport. https://www.rfc-editor.org/rfc/rfc9000.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
- 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