Zero Trust, VPN og TLS-inspeksjon løser ulike oppgaver

Anskaffelsesdokumenter behandler zero trust, VPN og TLS-inspeksjon som om det var samme innkjøp, og hver av dem svarer på et spørsmål de andre ikke kan. En tunnel bygger en beskyttet vei, en inspeksjonsgateway leser trafikk den kan avslutte, og en policy avgjør om en navngitt identitet kan utføre en navngitt operasjon på en navngitt ressurs. Bare den siste er en autorisasjonsbeslutning. Et produkt kan gjøre de to første perfekt og likevel la det egentlige spørsmålet stå åpent.

Tre mekanismer, tre spørsmål

Tunnelen svarer på hvordan trafikk når nettverket. En inspeksjonsgateway svarer på hva en mellomliggende boks kan se og gjøre der den er autorisert til å avslutte TLS. En policymotor svarer på hvem som kan gjøre hva mot hvilken ressurs, og deretter trenger den et håndhevelsespunkt som kan anvende svaret. NISTs zero trust-arkitektur setter ressursen i sentrum og nekter å utlede tillit fra hvor en pakke kom fra.

Den rammen er vanskeligere å oppfylle enn en etikett, og mye vanskeligere å forfalske i en gjennomgang. Den flytter også spørsmålet fra hvilke produkter som er utplassert, til hvilke beslutninger som håndheves og av hva.

Hvor beslutningen faktisk anvendes

Ta én forespørsel: en støttetekniker åpner en tjenestekonsoll, og en personlig maskin koblet til samme svitsj må ikke arve den tillatelsen bare ved å være i nærheten. Skriv ned den tillatte operasjonen, enhetsvilkårene og komponenten som håndhever dem. Plasseringen avgjør alt: en applikasjonsgateway, en tjenesteproxy, en vertskontroll eller en annen grense organisasjonen faktisk støtter. Hva den komponenten enn viser seg å være, må den ligge i veien for både fjern- og lokale forsøk.

Trafikk som aldri krysser VPN-inngangen, styres ikke av en kontroll som utføres der, uansett hvor grundig den kontrollen er. Nettopp det ene gapet forklarer det meste av avstanden mellom et zero trust-diagram og en fungerende utplassering. Tegn forespørselsveien før du tegner arkitekturen.

Dekryptering er ikke autorisasjon

Avlytting tjener snevre inspeksjonsmål og bærer sin egen byrde av sertifikater, betrodde røtter, personvernvurdering og applikasjoner som bryter sammen under den. Ingenting av dette er hva zero trust betyr, og ingenting av det erstatter en policybeslutning. Å autentisere en person og autorisere en tjeneste er fullt mulig uten å dekryptere én eneste pakke. En dekryptert strøm sier ingenting om hvorvidt brukeren hadde rett til operasjonen som bæres inni den.

Policyen trenger én slags bevis, og dekryptering er det ikke. Enhetshelse er ett innspill blant identitet, ressursfølsomhet og kontekst, og å bestå den én gang gir ikke den maskinen resten av nettverket. Å blande de to gjør et autorisasjonsspørsmål til et sertifikatprosjekt.

Når gatewayen ikke er noe sted i veien

Kartlegg hva som beveger seg uten å berøre den eksterne gatewayen: koblinger mellom maskiner på det lokale segmentet, kall fra én arbeidsbelastning til en annen og endepunkter som nås direkte inne i en skykonto. For hver vei, navngi en håndhevelsesmetode som faktisk kan utplasseres i dag. Utstyr som ikke kan være vert for en agent trenger fortsatt en annen uttrykkelig støttet kontroll, og å anta at agenten kommer senere lukker ingenting nå. Tjeneste-til-tjeneste-tilgang passer vanligvis bedre til arbeidsbelastningsidentitet og en kontroll skrevet mot ressursen enn nok et overleggsnettverk.

Godta designet på atferd og ikke på diagrammer: hvilke operasjoner som er tillatt, hvilke som avvises, og hvor hvert svar håndheves. Godkjenn konkrete tillatte og avviste operasjoner, og ta med én lokal rute som aldri når gatewayen. Registrer hvem som eier policyen, hvordan den endres og hvordan tilbakekalling virker.

En omdøpt tunnel er fortsatt en tunnel. En policy avgjør, og noe må håndheve den.