Was ist SSL-/TLS-Inspection?
SSL-/TLS-Inspection ist ein Verfahren, bei dem TLS-verschlüsselter Datenverkehr an einer vertrauenswürdigen Zwischenstelle entschlüsselt, auf Bedrohungen und Datenabfluss geprüft und anschließend neu verschlüsselt weitergeleitet wird. Da heute der weitaus größte Teil des Web-Verkehrs verschlüsselt ist, blieben Malware, Phishing und Datenabfluss ohne diese Prüfung weitgehend unsichtbar. In Zscaler Internet Access (ZIA) findet die Inspektion inline in der Zero Trust Exchange statt: entschlüsseln, prüfen, neu verschlüsseln. Damit Browser und Anwendungen der Zwischenstelle vertrauen, wird ein entsprechendes Stammzertifikat auf den Endgeräten verteilt. Welche Ziele geprüft und welche ausgenommen werden, steuern Richtlinien, etwa für Banking- oder Gesundheitsdienste.
SSL-/TLS-Inspection im Detail
Technisch arbeitet die Inspektion als kontrollierte Zwischenstelle: Der Client baut die TLS-Verbindung zur Prüfinstanz auf, diese wiederum zur Zielseite. Dem Client stellt die Prüfinstanz dabei ein Zertifikat aus, das von einem im Unternehmen verteilten Stammzertifikat signiert ist, entweder dem Zscaler-Stammzertifikat oder einer eigenen Unternehmens-CA. Fehlt dieses Stammzertifikat im Zertifikatsspeicher eines Geräts oder einer Anwendung, erscheinen Zertifikatswarnungen.
Nicht jeder Verkehr lässt sich sinnvoll prüfen. Anwendungen mit Certificate Pinning akzeptieren nur ihr erwartetes Zertifikat und brechen unter Inspektion; sie brauchen gezielte Ausnahmen. Daneben gibt es bewusste Ausnahmen aus Datenschutz-Gründen, typischerweise für Kategorien wie Banken oder Gesundheit. Jede Ausnahme ist zugleich ein blinder Fleck: Was nicht entschlüsselt wird, kann nicht auf Schadcode oder Datenabfluss geprüft werden. Die Kunst liegt in einem dokumentierten, möglichst kleinen Ausnahmenkatalog.
Warum ist SSL-/TLS-Inspection im Zscaler-Betrieb wichtig?
Für den Support ist SSL-/TLS-Inspection eine der häufigsten verdeckten Ursachen: Zertifikatswarnungen im Browser, Anwendungen, die nur im Firmennetz oder nur mit aktivem Client scheitern, Uploads, die eine Richtlinie stoppt. Ohne Blick auf Inspektions- und Richtlinienstatus wirken solche Fälle wie Anwendungsfehler. Die Schlüsselfragen lauten: Wird die Verbindung inspiziert, greift eine Ausnahme, und vertraut das Gerät dem Stammzertifikat?
Auf Steuerungsebene ist die Inspektionsabdeckung ein Sicherheitsindikator: Zu viele oder überbreite Ausnahmen höhlen Sandbox, Virenschutz und DLP aus. Zugleich verlangen Datenschutz und Mitbestimmung nachvollziehbare Regeln, welche Kategorien warum ausgenommen sind. Für Nachweise, etwa im Rahmen von NIS2, gehört dokumentiert, wie die Inspektionsrichtlinie aussieht, wer sie geändert hat und wann.
Typische Fehlerquellen
- Stammzertifikat unvollständig verteilt: Einzelne Geräte oder Werkzeuge mit eigenem Zertifikatsspeicher (Browser, Entwicklungsumgebungen) vertrauen der Inspektion nicht und werfen Zertifikatsfehler.
- Certificate Pinning übersehen: Gepinnte Apps scheitern unter Inspektion; ohne gepflegte Ausnahmeliste entstehen wiederkehrende, schwer zuzuordnende Störungen.
- Überbreite Ausnahmen: Ganze Domains oder Kategorien dauerhaft von der Prüfung auszunehmen schafft blinde Flecken für Malware und Datenabfluss.
- Datenschutz-Kategorien ungeregelt: Fehlende oder undokumentierte Ausnahmen für Banking- und Gesundheitsdienste werden zum Compliance-Risiko.
SSL-/TLS-Inspection in der Praxis: so hilft CentaurNexus
CentaurNexus hilft an beiden Enden. Im Einzelfall zieht Connectivity Triage Map die ZDX-Kette und den Policy-Status zusammen und nennt die Ursache im Klartext, etwa ob eine Blockade oder ein Zertifikatsproblem hinter der Störung steckt. Auf Konfigurationsebene bewertet Policy Health Saga die Konfigurations-Gesundheit als Score mit priorisiertem Maßnahmenplan und PDF-Report für NIS2- und DORA-Nachweise; so fallen überbreite Ausnahmen und Lücken der Inspektionsrichtlinie systematisch auf, als read-only Analyse ohne automatische Regel-Eingriffe. Der Helpdesk braucht dafür keine Zscaler-Admin-Rechte. Wie Nutzer eine Blockade oder Zertifikatswarnung selbst einordnen, zeigt der Beitrag Zscaler-Self-Service direkt im Browser.
Verwandte Begriffe
Häufige Fragen zur SSL-/TLS-Inspection
Der größte Teil des Web-Verkehrs ist heute TLS-verschlüsselt, auch Malware-Downloads, Phishing-Seiten und Datenabfluss. Ohne Entschlüsselung sehen Virenschutz, Sandbox und DLP nur Metadaten und können Inhalte nicht bewerten. Die Inspektion macht verschlüsselten Verkehr prüfbar und ist damit Voraussetzung dafür, dass die übrigen Schutzfunktionen wirken.
Zscaler Internet Access sitzt inline im Datenstrom: Die Verbindung wird an der Zero Trust Exchange entschlüsselt, geprüft und zur Zielseite neu verschlüsselt. Dem Endgerät präsentiert Zscaler ein Zertifikat, das von einem im Unternehmen verteilten Stammzertifikat signiert ist. Richtlinien steuern, welche Ziele geprüft und welche ausgenommen werden.
Üblich sind Ausnahmen für Anwendungen mit Certificate Pinning, die unter Inspektion brechen, sowie für datenschutzsensible Kategorien wie Banken oder Gesundheitsdienste. Wichtig ist, Ausnahmen klein, begründet und dokumentiert zu halten, denn jede ausgenommene Verbindung ist ein blinder Fleck für Bedrohungs- und Datenschutzprüfungen.
Sie ist gestaltbar: mit dokumentierten Ausnahmen für sensible Kategorien, transparenter Information der Beschäftigten und klaren Regeln, wer Prüfdaten einsehen darf. In Deutschland gehört die Mitbestimmung dazu. Die konkrete Ausgestaltung sollte mit Datenschutzbeauftragten und gegebenenfalls Betriebsrat abgestimmt werden; dieser Artikel ersetzt keine Rechtsberatung.
Typische Signale: Zertifikatswarnungen, die nur mit aktivem Client oder im Firmennetz auftreten, Anwendungen, die exakt beim Verbindungsaufbau scheitern, oder Fehler, die nach einer gezielten Ausnahme verschwinden. Hilfreich ist zu prüfen, ob die Verbindung inspiziert wird, welche Richtlinie greift und ob das Gerät dem Stammzertifikat vertraut.
- Zscaler Help Portal: ZIA-Dokumentation, help.zscaler.com/zia
- Zscaler Help Portal: About SSL Inspection - help.zscaler.com/zia/about-ssl-inspection
- BSI: Technische Richtlinie TR-02102-2 „Verwendung von Transport Layer Security (TLS)“ - bsi.bund.de/.../BSI-TR-02102-2
Hinweis: CentaurNexus ist ein unabhängiges Produkt der SourcingBlox GmbH und kein Angebot von Zscaler, Inc. Produkt- und Markennamen gehören ihren jeweiligen Inhabern.