Zero Trust, VPN en TLS-inspectie doen verschillende taken

Inkoopdocumenten behandelen zero trust, VPN en TLS-inspectie alsof het dezelfde aankoop is, en elk ervan beantwoordt een vraag die de andere niet kunnen. Een tunnel bouwt een beschermd pad, een inspectiegateway leest verkeer dat hij kan beëindigen, en een beleid bepaalt of een genoemde identiteit een genoemde bewerking op een genoemde resource mag uitvoeren. Alleen het laatste is een autorisatiebeslissing. Een product kan de eerste twee perfect doen en de echte vraag toch openlaten.

Drie mechanismen, drie vragen

De tunnel beantwoordt hoe verkeer het netwerk bereikt. Een inspectiegateway beantwoordt wat een tussenliggend apparaat kan zien en doen waar het bevoegd is TLS te beëindigen. Een beleidsengine beantwoordt wie wat met welke resource mag doen, en heeft daarna een handhavingspunt nodig dat dat antwoord kan toepassen. De zero trust-architectuur van NIST zet de resource in het midden en weigert vertrouwen af te leiden uit waar een pakket vandaan kwam.

Dat kader is lastiger te vervullen dan een etiket, en veel lastiger te vervalsen in een beoordeling. Het verschuift de vraag ook van welke producten zijn ingezet naar welke beslissingen worden gehandhaafd en waardoor.

Waar de beslissing werkelijk wordt toegepast

Neem één verzoek: een supportengineer opent een serviceconsole, en een persoonlijke machine aan dezelfde switch mag die toestemming niet erven alleen omdat zij in de buurt is. Schrijf de toegestane bewerking, de apparaatvoorwaarden en het onderdeel dat ze handhaaft op. Plaatsing beslist alles: een applicatiegateway, een serviceproxy, een hostcontrole of een andere grens die de organisatie werkelijk ondersteunt. Wat dat onderdeel ook blijkt te zijn, het moet in het pad liggen van zowel externe als lokale pogingen.

Verkeer dat nooit de VPN-ingang kruist, wordt niet beheerst door een controle die daar wordt uitgevoerd, hoe grondig die controle ook is. Juist dat ene gat verklaart het grootste deel van de afstand tussen een zero trust-diagram en een werkende inzet. Teken het verzoekpad voordat je de architectuur tekent.

Ontsleuteling is geen autorisatie

Afluisteren dient smalle inspectiedoeleinden en draagt zijn eigen last van certificaten, vertrouwde wortels, privacytoetsing en applicaties die eronder stukgaan. Niets daarvan is wat zero trust betekent, en niets daarvan vervangt een beleidsbeslissing. Een persoon authenticeren en een dienst autoriseren is heel goed mogelijk zonder één pakket te ontsleutelen. Een ontsleutelde stroom zegt niets over of de gebruiker recht had op de bewerking die erin wordt vervoerd.

Het beleid heeft één soort bewijs nodig, en ontsleuteling is dat niet. Apparaatgezondheid is één invoer naast identiteit, gevoeligheid van de resource en context, en er één keer doorheen komen geeft die machine niet de rest van het netwerk. De twee mengen maakt van een autorisatievraag een certificaatproject.

Wanneer de gateway nergens in het pad zit

Inventariseer wat reist zonder de externe gateway aan te raken: verbindingen tussen machines op het lokale segment, aanroepen van de ene workload naar de andere en eindpunten die rechtstreeks binnen een cloudaccount worden bereikt. Benoem voor elk pad een handhavingsmethode die vandaag echt kan worden ingezet. Apparatuur die geen agent kan hosten heeft nog steeds een andere expliciet ondersteunde controle nodig, en de aanname dat de agent later komt sluit nu niets. Dienst-tot-diensttoegang past meestal beter bij workloadidentiteit en een controle geschreven tegen de resource dan bij nog een overlaynetwerk.

Accepteer het ontwerp op gedrag en niet op diagrammen: welke bewerkingen zijn toegestaan, welke geweigerd, en waar elk antwoord wordt gehandhaafd. Keur concrete toegestane en geweigerde bewerkingen goed, en neem één lokale route op die de gateway nooit bereikt. Leg vast wie het beleid bezit, hoe het verandert en hoe intrekking werkt.

Een omgedoopte tunnel blijft een tunnel. Een beleid beslist, en iets moet het handhaven.