Zero Trust, VPN og TLS-inspeksjon løyser ulike oppgåver

Anskaffingsdokument handsamar zero trust, VPN og TLS-inspeksjon som om det var same innkjøp, og kvar av dei svarar på eit spørsmål dei andre ikkje kan. Ein tunnel byggjer ein verna veg, ein inspeksjonsgateway les trafikk han kan avslutte, og ein policy avgjer om ein namngjeven identitet kan utføre ein namngjeven operasjon på ein namngjeven ressurs. Berre den siste er ei autorisasjonsavgjerd. Eit produkt kan gjere dei to første perfekt og likevel la det eigentlege spørsmålet stå ope.

Tre mekanismar, tre spørsmål

Tunnelen svarar på korleis trafikk når nettet. Ein inspeksjonsgateway svarar på kva ein mellomliggjande boks kan sjå og gjere der han er autorisert til å avslutte TLS. Ein policymotor svarar på kven som kan gjere kva mot kva ressurs, og deretter treng han eit handhevingpunkt som kan nytte svaret. NIST sin zero trust-arkitektur set ressursen i sentrum og nektar å utleia tillit frå kvar ei pakke kom frå.

Den ramma er vanskelegare å oppfylle enn ein etikett, og mykje vanskelegare å forfalske i ein gjennomgang. Ho flyttar også spørsmålet frå kva produkt som er sett ut, til kva avgjerder som blir handheva og av kva.

Kvar avgjerda faktisk blir nytta

Ta ein førespurnad: ein støtteteknikar opnar ein tenestekonsoll, og ein personleg maskin kopla til same svitsj må ikkje arve den løyvinga berre ved å vere i nærleiken. Skriv ned den tillatne operasjonen, vilkåra for eininga og komponenten som handhevar dei. Plasseringa avgjer alt: ein applikasjonsgateway, ein tenesteproxy, ein vertskontroll eller ei anna grense organisasjonen faktisk støttar. Kva den komponenten enn viser seg å vere, må han liggje i vegen for både fjern- og lokale forsøk.

Trafikk som aldri kryssar VPN-inngangen, blir ikkje styrt av ein kontroll som blir utført der, uansett kor grundig den kontrollen er. Nettopp det eine gapet forklarar det meste av avstanden mellom eit zero trust-diagram og ein fungerande utrulling. Teikn førespurnadsvegen før du teiknar arkitekturen.

Dekryptering er ikkje autorisasjon

Avlytting tenar snevre inspeksjonsmål og ber si eiga bør av sertifikat, betrudde røter, personvernvurdering og applikasjonar som brest under henne. Ingenting av dette er kva zero trust tyder, og ingenting av det erstattar ei policyavgjerd. Å autentisere ein person og autorisere ei teneste er fullt mogleg utan å dekryptere éi einaste pakke. Ein dekryptert straum seier ingenting om brukaren hadde rett til operasjonen som blir boren inni han.

Policyen treng ein slags prov, og dekryptering er det ikkje. Eininga si helse er eitt innspel blant identitet, ressurskjensle og kontekst, og å klare henne éin gong gir ikkje den maskinen resten av nettet. Å blande dei to gjer eit autorisasjonsspørsmål til eit sertifikatprosjekt.

Når gatewayen ikkje er nokon stad i vegen

Kartlegg kva som flyttar seg utan å røre den eksterne gatewayen: koplingar mellom maskinar på det lokale segmentet, kall frå éin arbeidslast til ein annan og endepunkt som blir nådde rett inni ein skykonto. For kvar veg, namngje ein handhevingsmetode som faktisk kan setjast ut i dag. Utstyr som ikkje kan huse ein agent treng framleis ein annan uttrykkeleg støtta kontroll, og å leggje til grunn at agenten kjem seinare lukkar ingenting no. Teneste-til-teneste-tilgang passar vanlegvis betre til arbeidslastidentitet og ein kontroll skriven mot ressursen enn nok eit overleggsnett.

Godta designet på åtferd og ikkje på diagram: kva operasjonar som er tillatne, kva som blir avviste, og kvar kvart svar blir handheva. Godkjenn konkrete tillatne og avviste operasjonar, og ta med éin lokal rute som aldri når gatewayen. Registrer kven som eig policyen, korleis han endrar seg og korleis tilbakekalling verkar.

Ein omdøypt tunnel er framleis ein tunnel. Ein policy avgjer, og noko må handheve han.