Zscaler- & Zero Trust-lexicon voor de praktijk · Toegang & verkeer

Wat is een SSL-inspectie-bypass?

Definitie

Een SSL Inspection Bypass is een gerichte uitzondering waarmee bepaalde applicaties of domeinen van de SSL/TLS-inspectie worden uitgesloten. De meest voorkomende reden is Certificate Pinning: applicaties die het servercertificaat vast in de code hebben opgeslagen, accepteren het dynamisch uitgegeven inspectiecertificaat niet en breken de verbinding af. De uitzondering laat deze verbindingen onversleuteld door, terwijl het overige verkeer gecontroleerd blijft. Goed toegepast is een bypass een precisie-instrument: zo strak mogelijk afgebakend, met een gedocumenteerde reden en een regelmatige controle of het nog nodig is.

SSL-inspectie-bypass in detail

Bij actieve SSL-inspectie geeft Zscaler de client voor elke gecontroleerde verbinding een certificaat uit dat door de Intermediate CA van de tenant is ondertekend. Browsers vertrouwen dat zodra het certificaat in de trust store is verspreid. Applicaties met Certificate Pinning vergelijken daarentegen met het vast opgeslagen origineel en beëindigen de verbinding na de TLS-handshake, vaak met een certificaatfout of gewoon zonder melding. Zscaler houdt een officiële lijst bij van getroffen applicaties, van Adobe-diensten tot mobiele apps.

Voor de uitzondering noemt de Zscaler-documentatie twee wegen: de cloudapplicatie als geheel van de inspectie uitsluiten, of afzonderlijke domeinen via een eigen URL-categorie. Belangrijk is de afbakening ten opzichte van de volledige Zscaler-bypass via PAC-bestand of app-profiel: de inspectie-uitzondering blijft in het Zscaler-datapad en behoudt URL-filtering en overige controles, de volledige bypass verlaat dat pad helemaal.

Waarom tellen SSL-inspectie-bypasses in de Zscaler-praktijk?

Bypasses bepalen twee dingen tegelijk: beschikbaarheid en zichtbaarheid. Ontbreekt een noodzakelijke uitzondering, dan staat een vakapplicatie stil en zoekt de helpdesk de oorzaak vaak bij wifi, VPN of serverstatus, terwijl de onderbreking in werkelijkheid aan pinning ligt. Zijn er omgekeerd te veel uitzonderingen, dan ontstaat een groeiende blinde vlek: verkeer dat niemand meer controleert op schadelijke code of gegevensverlies.

In de praktijk stapelen bypasses zich sluipend op: een uitzondering voor een project, een voor een test, een op verzoek. Na twee jaar weet niemand meer welke daarvan nog nodig zijn. Daarom hoort bij elke bypass een vermelding met reden, datum en verantwoordelijke, plus een vaste reviewcyclus. Zo blijft de inspectiedekking een bewuste status en geen toevalsproduct van de tickethistorie.

Veelvoorkomende foutbronnen

SSL-inspectie-bypass in de praktijk: wat CentaurNexus bijdraagt

Of een bepaalde URL werkelijk langs Zscaler loopt of alleen van de ontsleuteling is uitgesloten, beantwoordt CentaurNexus zonder giswerk. PAC-Lens leest het daadwerkelijk actieve PAC-bestand uit de tenant en toont via een test-URL welke regel van toepassing is en of het verkeer rechtstreeks of via Zscaler loopt. Hoe u een los adres via een test-URL live kunt controleren, laat onze video van ongeveer tweeënhalve minuut over de PAC-tester zien. Connectivity Triage Map duidt vervolgens of een gemeld probleem aan het apparaat, het netwerk of een beleidsregel ligt. Zo wordt van de vraag „Waarom werkt deze app niet?" een onderbouwde bevinding in plaats van een vermoeden. Hoe gebruikers verbindingsgevallen vooraf zelf kunnen controleren, laat dit artikel zien Zscaler self-service rechtstreeks in de browser.

Bekijk in de live demo hoe PAC-Lens via een test-URL toont welke regel echt van toepassing is.Live demo bekijken

Verwante begrippen

Veelgestelde vragen over de SSL-inspectie-bypass

Waarom werken apps met Certificate Pinning niet onder SSL-inspectie?

Zulke apps controleren of het servercertificaat exact overeenkomt met een vast opgeslagen certificaat. Bij actieve SSL-inspectie levert Zscaler de app echter een dynamisch uitgegeven certificaat van de Intermediate CA. Dat komt niet overeen met het opgeslagen origineel, en de app breekt de verbinding af. Zscaler documenteert getroffen applicaties in een officiële lijst.

Hoe richt u een SSL-inspectie-uitzondering in Zscaler in?

Volgens de Zscaler-documentatie zijn er twee wegen: de betreffende cloudapplicatie van de SSL/TLS-inspectie uitsluiten, of de afzonderlijke domeinen via een eigen URL-categorie uitsluiten. Beproefd is de meest precieze weg: alleen de daadwerkelijk noodzakelijke domeinen, met gedocumenteerde reden en datum, zodat de uitzondering later controleerbaar blijft.

Wat is het verschil tussen een SSL-inspectie-uitzondering en een PAC-bypass?

Een SSL-inspectie-uitzondering laat het verkeer gewoon via Zscaler lopen, alleen dan onversleuteld; URL-filtering en overige controles blijven van toepassing. Een bypass in het PAC-bestand of in het app-profiel stuurt het verkeer daarentegen volledig langs Zscaler. Dat is een aanzienlijk grotere ingreep en hoort de zeldzame, goed onderbouwde uitzondering te blijven.

Zijn SSL-inspectie-bypasses een veiligheidsrisico?

Elke uitzondering is een blinde vlek: inhoud in uitgesloten verbindingen wordt niet gecontroleerd op schadelijke code of gegevensverlies. Op zichzelf en onderbouwd is dat te verdedigen; gevaarlijk wordt de sluipende opeenstapeling over de jaren. Daarom horen bypasses geïnventariseerd te worden, met reden gedocumenteerd en regelmatig gecontroleerd of ze nog nodig zijn.

Waaraan herkent u dat Certificate Pinning de oorzaak van een probleem is?

Typisch patroon: de website werkt in de browser, maar de bijbehorende desktop- of mobiele app maakt geen verbinding of meldt een certificaat- of verbindingsfout. De onderbreking gebeurt direct na de TLS-handshake. Een vergelijking met de officiële Zscaler-lijst van gepinde applicaties en een blik in de client-logs bevestigen het vermoeden.

Informatiebronnen & verder lezen:

Let op: CentaurNexus is een onafhankelijk product van SourcingBlox GmbH en geen aanbod van Zscaler, Inc. Product- en merknamen behoren toe aan hun respectieve eigenaren.