De overgrote meerderheid van het internetverkeer is versleuteld, voornamelijk met TLS om de vertrouwelijkheid, integriteit en authenticiteit van gegevens te waarborgen. Transport Layer Security (TLS) is een netwerkprotocol dat andere protocollen in een laag van versleuteling wikkelt, en is het verschil tussen HTTP en HTTPS voor webverkeer. Versleuteling beschermt tegen afluisteren, maar garandeert niet dat het versleutelde verkeer veilig is.<\/p>\n\n\n\n
Hoewel TLS het beste bekend staat om zijn gegevensversleuteling, biedt het ook bescherming voor gegevensintegriteit en authenticiteit. Standaard authenticates HTTPS de identiteit van de server met behulp van een digitaal certificaat, en wederzijdse TLS (mTLS) doet hetzelfde voor de client.<\/p>\n\n\n\n
Versleuteld verkeer verwijst naar de versleuteling van gegevens tijdens de overdracht, vaak met TLS (een vervanging voor onveilige SSL). Gegevens kunnen ook in rust worden versleuteld met behulp van AES en soortgelijke algoritmen. Gegevensversleuteling tijdens de overdracht converteert netwerkverkeer in onleesbare ciphertext voordat de afzender het over het netwerk verzendt. De ontvanger heeft de decryptiesleutel en kan deze gebruiken om de oorspronkelijke gegevens te herstellen.<\/p>\n\n\n\n
Het meeste internetverkeer is nu versleuteld, aangezien versleuteling helpt om de authenticiteit en integriteit van de verzonden gegevens te waarborgen, evenals het beschermen tegen afluisteren. Bijvoorbeeld, het merendeel van het moderne webverkeer – inclusief webbrowserverkeer, SaaS-toepassingsverkeer, API-aanroepen en mobiel app-verkeer – maakt gebruik van het versleutelde HTTPS-protocol, dat HTTP in TLS verpakt.<\/p>\n\n\n\n
Andere netwerkprotocollen zijn ook versleuteld, hetzij opzettelijk of door het gebruik van TLS. Voorbeelden zijn:<\/p>\n\n\n\n
De meeste netwerkprotocollen die het moderne internet vormen (HTTP, DNS, enz.) zijn niet standaard veilig, omdat ze geen gegevensversleuteling, authenticatie en integriteitsbescherming bieden. Tegenwoordig is het gebruik van versleutelde protocollen de standaard geworden om verschillende redenen, waaronder:<\/p>\n\n\n\n
Verkeersversleuteling met TLS heeft verschillende voordelen, waaronder de bescherming van gegevensvertrouwelijkheid, integriteit en authenticiteit. Dit is belangrijk omdat, zonder het, netwerkverkeer kwetsbaar kan zijn voor afluisteren en wijziging onderweg naar de bestemming. Tegelijkertijd cre\u00ebert verkeersversleuteling ook beveiligingsuitdagingen, aangezien, net als aanvallers, beveiligingstools de inhoud van versleuteld verkeer standaard niet kunnen lezen. Dit is problematisch omdat malware, PII en kwetsbaarheidsuitbuitingen verborgen kunnen zijn binnen versleuteld verkeer.<\/p>\n\n\n\n
Het ontsleutelen van netwerkverkeer vereist ofwel toegang tot eindpunten of het verbreken van de TLS-verbinding en het uitvoeren van computationeel dure TLS-ontsleuteling binnen netwerkbeveiligingstools. Als gevolg hiervan gebruiken beveiligingstools vaak metadata, prestatie-indicatoren en eindpunttelemetrie om potenti\u00eble bedreigingen te identificeren.<\/p>\n\n\n\n
Hoewel TLS de inhoud van een netwerkpakket versleutelt, moet sommige informatie ontsleuteld blijven om het pakket zijn bestemming te laten bereiken. Enkele van de metadata die beveiligingsteams nog kunnen zien in versleuteld verkeer zijn:<\/p>\n\n\n\n
Echter, de bruikbaarheid van deze informatie hangt ook af van hoe het verkeer is versleuteld. Als een IPsec VPN<\/a> in plaats van TLS voor versleuteling wordt gebruikt, zullen IP-adressen en poorten naar de VPN-eindpunten wijzen, niet naar de uiteindelijke bestemmingen van het netwerkverkeer.<\/p>\n\n\n\n Organisaties kunnen twee verschillende benaderingen hanteren om de beveiligingsrisico’s van versleuteld verkeer te beheren:<\/p>\n\n\n\n Vaak gebruiken organisaties een combinatie van de twee technieken. Bijvoorbeeld, ze kunnen standaard metadata onderzoeken en alleen ontsleuteling uitvoeren voor verkeer dat als potentieel risicovol wordt ge\u00efdentificeerd.<\/p>\n\n\n\n De eerste mogelijke benadering is om versleuteld verkeer te inspecteren, ook wel bekend als TLS- of SSL-inspectie. Onder dit model ontsleutelt een beveiligingsapparaat het verkeer op een inspectiepunt, evalueert het en versleutelt het vervolgens opnieuw voor levering. Dit stelt de organisatie in staat om beleid af te dwingen, bedreigingen te detecteren, te scannen op malware en inhoudscontroles uit te voeren die zicht op de payload vereisen.<\/p>\n\n\n\n Echter, deze aanpak introduceert ook risico’s, aangezien het vereist dat de versleutelde TLS-verbinding wordt verbroken, vaak door twee aparte versleutelde verbindingen te cre\u00ebren, \u00e9\u00e9n van de client naar het beveiligingsapparaat en de andere van het apparaat naar de server. Decryptie introduceert privacyrisico’s, kan de prestaties schaden en voegt complexiteit toe die applicaties kan verstoren.<\/p>\n\n\n\n Inspectie op basis van decryptie werkt door de versleutelde TLS-sessie in twee aparte sessies te splitsen met een decryptiepunt in het midden. Dit omvat de volgende stappen:<\/p>\n\n\n\n Voor het inspectiepunt om een sessie met de client te cre\u00ebren, moet de client accepteren dat zijn digitale certificaat een geldig certificaat is voor de doelsite. Dit wordt vaak ge\u00efmplementeerd als een wildcard digitaal certificaat dat van toepassing is op elke site die de client mogelijk bezoekt.<\/p>\n\n\n\n Nadat verkeer is gedecrypt bij het inspectiepunt, heeft het beveiligingsapparaat volledige toegang tot de payload van het pakket. Dit stelt het in staat om verschillende beveiligingsfuncties te implementeren, zoals:<\/p>\n\n\n\n Decryptie is niet altijd een optie (of de beste optie). Een alternatief is dat beveiligingstools het risico dat aan een verbinding is verbonden, afleiden met behulp van metadata, flowgedrag, endpointtelemetrie en andere signalen zonder de payloadinhoud te decrypten. Signaleringen die voor deze analyse worden gebruikt, zijn onder andere:<\/p>\n\n\n\n Deze aanpak heeft enkele voordelen, aangezien het de overhead en privacyrisico’s die gepaard gaan met verkeersdecryptie, elimineert. Echter, ze kunnen bedreigingen missen die alleen zichtbaar zijn binnen de payload van het netwerkverkeer. Organisaties kunnen ook AI-gebaseerde analyse van versleuteld verkeer<\/a> gebruiken om de effectiviteit van deze techniek te verbeteren.<\/p>\n\n\n\n Het decrypten van versleuteld verkeer voor analyse kan potenti\u00eble problemen voor het bedrijf introduceren. Om app-breuken te voorkomen, moeten organisaties bepaalde beleidsmaatregelen en technische controles implementeren.<\/p>\n\n\n\n Decryptie van ondernemingsverkeer vereist doorgaans het vervangen van het digitale certificaat van de server door een inspectiecertificaat van de onderneming. Dit kan problematisch zijn als een applicatie certificaat pinning of strikte certificaatvalidatie implementeert, waarbij alleen een bepaald digitaal certificaat voor een doelwebsite wordt geaccepteerd.<\/p>\n\n\n\n Als dit het geval is, kunnen applicaties falen, ondervinden ze authenticatielussen of kunnen ze niet worden bijgewerkt. Mogelijke oplossingen zijn het omzeilen van inspectie voor deze apps, het gebruik van endpointbeveiligingscontroles om verkeer voor\/na encryptie te inspecteren, of het bekijken van de richtlijnen van de leverancier voor oplossingen.<\/p>\n\n\n\n Mutual TLS (mTLS) authenticates zowel de client als de server met behulp van digitale certificaten. Dit kan ervoor zorgen dat onderschepping faalt als het inspectiepunt de clientcertificaatauthenticatie niet correct kan doorgeven, valideren of opnieuw origineren.\u00a0<\/p>\n\n\n\n Mogelijke resultaten zijn API-fouten, herhaalde authenticatieprompten en plotselinge “niet-geautoriseerde” fouten na het inschakelen van inspectie. Om dit te mitigeren, kunnen organisaties inspectie omzeilen voor specifieke mTLS-bestemmingen, endpoint-bewuste controles gebruiken, of expliciete ondersteuning voor clientcertificaat-passthrough configureren, waar beschikbaar.<\/p>\n\n\n\n Inspectietools ondersteunen mogelijk niet elk protocol of onderhandelingspatroon dat door een applicatie en\/of server wordt gebruikt. Als dit het geval is, kan het inspectiepunt falen in het onderhandelen van een of beide versleutelde verbindingen die het onderhoudt met de client en server.<\/p>\n\n\n\n Symptomen van dit probleem zijn verbindingsfouten, intermitterende time-outs en gedeeltelijke paginaladingen. Potenti\u00eble mitigaties omvatten het bijwerken van het inspectiepunt om ontbrekende protocollen op te nemen of inspectiebeleid opnieuw te defini\u00ebren om die applicatie uit te sluiten.<\/p>\n\n\n\n Moderne protocollen, zoals HTTP\/3, QUIC en ECH, veranderen hoe onderschepping werkt of de niet-versleutelde metadata die wordt gebruikt om versleuteld verkeer te analyseren. Bijvoorbeeld, Encrypted Client Hello (ECH) versleutelt meer van de TLS-handshake, waardoor de beschikbare niet-versleutelde gegevens verminderen.<\/p>\n\n\n\n Als gevolg hiervan heeft de organisatie mogelijk bijgewerkte tools of andere benaderingen nodig voor netwerkstromen die deze protocollen gebruiken. Sommige organisaties blokkeren tijdelijk of verlagen QUIC\/HTTP\/3 (dwingen HTTP\/2 over TLS) om inspectie en consistente beleidsafstemming te behouden, en schakelen deze vervolgens weer in naarmate tools en beleid zich ontwikkelen.<\/p>\n\n\n\n In sommige gevallen mag er geen inspectie plaatsvinden, zelfs als dit technisch mogelijk is. Veel organisaties zullen bijvoorbeeld vermijden om verkeer naar gezondheidsportalen, banken, persoonlijke e-mail en systemen voor zelfbediening van werknemers te ontsleutelen om te voldoen aan de privacywetten. Om toegang tot gevoelige persoonlijke gegevens te vermijden, moeten programma’s voor verkeerontsleuteling onder strikte governance staan, controleerbaar zijn en zo min mogelijk gevoelige en priv\u00e9gegevens ontsleutelen.<\/p>\n\n\n\n Ontsleuteling is computationeel kostbaar en kan latentie in netwerkverbindingen introduceren. Als meerdere beveiligingsapparaten of proxies onafhankelijk de gegevens ontsleutelen en opnieuw versleutelen, kan dit de netwerklatentie en potenti\u00eble storingen verhogen, wat leidt tot trage laadtijden van pagina’s, time-outs en inconsistente prestaties.<\/p>\n\n\n\n Single-pass of single-scan inspectie voert een enkele ronde van verkeerontsleuteling\/nieuwversleuteling uit voor beveiligingsinspectie. Meerdere beveiligingsfuncties kunnen toegang krijgen tot de ontsleutelde gegevens, waarbij hetzelfde niveau van beveiliging wordt geboden terwijl het aantal redundante cryptografische stappen en de bijbehorende netwerklatentie wordt verminderd.<\/p>\n\n\n\n Inspectie van versleuteld verkeer kan noodzakelijk zijn voor beveiliging, maar kan ook schade toebrengen aan het bedrijf als het verkeerd wordt ge\u00efmplementeerd. Enkele best practices zijn:<\/p>\n\n\n\n Verkeersontsleuteling is niet altijd noodzakelijk, en organisaties moeten beslissen of verkeer ontsleuteling vereist. Enkele factoren om te overwegen zijn:<\/p>\n\n\n\n Versleuteld verkeer maakt gebruik van cryptografie om netwerkverkeer te beschermen tegen afluisteren en kwaadaardige wijziging. TLS is het meest voorkomende protocol voor verkeersversleuteling en is het verschil tussen HTTP- en HTTPS-webverkeer. Hoewel versleuteling de integriteit, vertrouwelijkheid en authenticiteit van gegevens beschermt, garandeert het niet dat de versleutelde gegevens onschadelijk zijn.<\/p>\n\n\n\n HTTPS is een veelvoorkomende vorm van versleuteld verkeer, waarbij TLS wordt gebruikt om HTTP-verkeer te beschermen. Er zijn echter ook andere vormen van versleuteld verkeer, waaronder VPN’s en andere netwerkprotocollen die door TLS worden beschermd.<\/p>\n\n\n\n TLS is de opvolger van SSL, dat onveilig is. Mensen kunnen nog steeds SSL of SSL\/TLS zeggen terwijl ze naar TLS verwijzen uit gewoonte of erkenning van deze erfenis.<\/p>\n\n\n\n Versleuteling kan beveiligingsblinde vlekken cre\u00ebren, aangezien beveiligingstools versleutelde gegevens niet kunnen lezen om naar malware, phishinginhoud, datalekken en andere bedreigingen te zoeken. Als gevolg hiervan moeten organisaties mogelijk vertrouwen op niet-versleutelde metadata en gedragsignalen om verdachte verbindingen te identificeren of netwerkverkeer te ontsleutelen.<\/p>\n\n\n\n Het analyseren van versleuteld netwerkverkeer zonder het te ontsleutelen omvat het gebruik van metadata, flowgedrag, endpointtelemetrie en dreigingsinformatie om risico’s af te leiden zonder inhoud te lezen. Bijvoorbeeld, een organisatie kan afleiden dat verkeer naar een bekend kwaadwillig IP-adres kwaadaardig is zonder de inhoud te lezen. Echter, sommige controles vereisen zichtbaarheid van de payload, zodat niet-ontsleutelingsmethoden geen volledige vervanging zijn.<\/p>\n\n\n\n Inspectie op basis van ontsleuteling kan gepast zijn voor risicovolle categorie\u00ebn zoals onbekend webverkeer, bestandsdownloads of toegang tot gevoelige systemen, wanneer beleid en governance aanwezig zijn. Echter, ontsleuteling introduceert risico’s, zoals privacy- en nalevingszorgen, verminderde prestaties en applicatieproblemen als certificaatpinnen of vergelijkbare oplossingen aanwezig zijn. Organisaties moeten selectief zijn over het verkeer dat ze ontsleutelen, testen op kritieke apps en een duidelijk omleidings- en uitzonderingsproces handhaven.<\/p>\n\n\n\n De Cato SASE<\/a> Cloud omvat een wereldwijd netwerk van SASE PoPs, gebouwd rond Cato’s Single Pass Cloud Engine (SPACE). Cato verenigt de beveiligingsfuncties van Security Service Edge (SSE)<\/a> \u2014 inclusief FWaaS<\/a>, CASB<\/a>, SWG<\/a> en DLP<\/a> \u2014 in \u00e9\u00e9n enkele oplossing, en SPACE stelt deze beveiligingsfuncties in staat om toegang te krijgen tot ontsleutelde gegevens binnen \u00e9\u00e9n ronde van verkeer ontsleuteling en herversleuteling. Wanneer verkeer ontsleuteling nodig is, minimaliseert dit de potenti\u00eble impact op prestaties en latentie.<\/p>\n\n\n\nHoe organisaties versleuteld verkeer beheren in bedrijfsomgevingen<\/h2>\n\n\n\n
\n
Benadering 1: Inspectie op basis van ontsleuteling<\/h3>\n\n\n\n
Hoe Werkt Inspectie op Basis van Decryptie?<\/h4>\n\n\n\n
\n
Welke Rol Spelen Certificaten en Vertrouwensopslag?<\/h4>\n\n\n\n
Deze aanpak vereist aanzienlijke vertrouwen in de onderneming en haar beveiliging, aangezien de client het echte digitale certificaat dat door de doelsite wordt verstrekt niet langer kan valideren. Als gevolg hiervan is dit digitale certificaat een veelvoorkomende bron van misconfiguraties, beveiligingsrisico’s en uitval.<\/p>\n\n\n\nWat Wordt Ge\u00efnspecteerd Na Decryptie?<\/h4>\n\n\n\n
\n
Approach 2: Niet-decryptie zichtbaarheid<\/h2>\n\n\n\n
\n
Wat gaat er mis in de echte wereld bij het beheren van versleuteld verkeer?<\/h2>\n\n\n\n
Certificaat Pinning en Strikte Certificaatvalidatie<\/h3>\n\n\n\n
Mutual TLS (mTLS) en Client Certificaat Authenticatie<\/h3>\n\n\n\n
Niet-ondersteunde Protocollen, Ciphers en Randgevallen<\/h3>\n\n\n\n
HTTP\/3, QUIC, TLS 1.3 Gedragingen en ECH<\/h3>\n\n\n\n
Privacygrenzen en gereguleerde categorie\u00ebn<\/h3>\n\n\n\n
Hoe kan de prestaties verslechteren met meerdere inspectie-hops?<\/h2>\n\n\n\n
Wat betekent “single-pass” of “single-scan” inspectie?<\/h3>\n\n\n\n
Best practices voor het omgaan met versleuteld verkeer zonder de bedrijfsvoering te verstoren<\/h2>\n\n\n\n
\n
Hoe moeten teams beslissen wat te ontsleutelen en wat te omzeilen?<\/h3>\n\n\n\n
\n
FAQ over versleuteld verkeer<\/h2>\n\n\n\n
Wat is versleuteld verkeer in eenvoudige termen?<\/h3>\n\n\n\n
Is versleuteld verkeer hetzelfde als HTTPS?<\/h3>\n\n\n\n
Wat is TLS, en waarom zeggen mensen nog steeds SSL?<\/h3>\n\n\n\n
Waarom kan versleuteling beveiligingsblinde vlekken cre\u00ebren?<\/h3>\n\n\n\n
Kunnen teams versleuteld verkeer analyseren zonder het te ontsleutelen?<\/h3>\n\n\n\n
Wanneer is inspectie op basis van ontsleuteling gepast, en wat zijn de grootste risico’s?<\/h3>\n\n\n\n
Inspectie van versleuteld verkeer met Cato<\/h2>\n\n\n\n