Zero Trust, VPN och TLS-inspektion gör olika saker

Upphandlingsdokument behandlar zero trust, VPN och TLS-inspektion som om det vore samma inköp, och var och en av dem svarar på en fråga som de andra inte kan. En tunnel bygger en skyddad väg, en inspektionsgateway läser trafik som den kan avsluta, och en policy avgör om en namngiven identitet får utföra en namngiven operation på en namngiven resurs. Bara den sista är ett auktorisationsbeslut. En produkt kan göra de två första perfekt och ändå lämna den egentliga frågan öppen.

Tre mekanismer, tre frågor

Tunneln svarar på hur trafik når nätverket. En inspektionsgateway svarar på vad en mellanliggande box kan se och göra där den är auktoriserad att avsluta TLS. En policymotor svarar på vem som får göra vad mot vilken resurs, och behöver sedan en upprätthållandepunkt som kan tillämpa svaret. NIST:s zero trust-arkitektur sätter resursen i centrum och vägrar att härleda förtroende från varifrån ett paket kom.

Den ramen är svårare att uppfylla än en etikett, och mycket svårare att förfalska i en granskning. Den flyttar också frågan från vilka produkter som är utplacerade till vilka beslut som upprätthålls och av vad.

Var beslutet faktiskt tillämpas

Ta en förfrågan: en supporttekniker öppnar en tjänstekonsol, och en personlig maskin kopplad till samma switch får inte ärva den behörigheten bara för att den är i närheten. Skriv ned den tillåtna operationen, enhetsvillkoren och komponenten som upprätthåller dem. Placeringen avgör allt: en applikationsgateway, en tjänsteproxy, en värdkontroll eller en annan gräns som organisationen faktiskt stöder. Vad den komponenten än visar sig vara måste den ligga i vägen för både fjärr- och lokala försök.

Trafik som aldrig passerar VPN-ingången styrs inte av en kontroll som utförs där, hur grundlig den kontrollen än är. Just den enda luckan förklarar det mesta av avståndet mellan ett zero trust-diagram och en fungerande utrullning. Rita förfrågningsvägen innan du ritar arkitekturen.

Dekryptering är inte auktorisation

Avlyssning tjänar snäva inspektionsmål och bär sin egen börda av certifikat, betrodda rötter, integritetsgranskning och applikationer som går sönder under den. Inget av detta är vad zero trust betyder, och inget av det ersätter ett policybeslut. Att autentisera en person och auktorisera en tjänst är fullt möjligt utan att dekryptera ett enda paket. Ett dekrypterat flöde säger ingenting om huruvida användaren hade rätt till operationen som bärs inuti det.

Policyn behöver en sorts bevis, och dekryptering är det inte. Enhetens hälsa är en indata bland identitet, resurskänslighet och kontext, och att klara den en gång ger inte den maskinen resten av nätverket. Att blanda de två gör en auktorisationsfråga till ett certifikatprojekt.

När gatewayen inte finns någonstans i vägen

Inventera vad som färdas utan att röra fjärrgatewayen: länkar mellan maskiner på det lokala segmentet, anrop från en arbetsbelastning till en annan och slutpunkter som nås direkt inne i ett molnkonto. Namnge för varje väg en upprätthållandemetod som faktiskt kan rullas ut i dag. Utrustning som inte kan vara värd för en agent behöver fortfarande en annan uttryckligen stödd kontroll, och antagandet att agenten kommer senare stänger ingenting nu. Tjänst-till-tjänst-åtkomst passar vanligtvis bättre för arbetsbelastningsidentitet och en kontroll skriven mot resursen än ännu ett överlagringsnät.

Acceptera designen på beteende och inte på diagram: vilka operationer som tillåts, vilka som nekas och var varje svar upprätthålls. Godkänn konkreta tillåtna och nekade operationer, och ta med en lokal rutt som aldrig når gatewayen. Registrera vem som äger policyn, hur den ändras och hur återkallelse fungerar.

En omdöpt tunnel är fortfarande en tunnel. En policy avgör, och något måste upprätthålla den.