Alltid på VPN: att skilja på väg, behörighet och session
En alltid på-tunnel kan vara rätt för en filial och fel för en bortglömd bärbar dator. Gå igenom de tre tillstånd den håller vid liv, och vad borttagning faktiskt avslutar.
Att hålla en tunnel uppe dygnet runt är ett designval med en försvarlig och en oaktsam variant. En filial som behöver en central applikation hela dagen, plus ett nattligt säkerhetskopieringsjobb, har ett skäl. En bärbar dator som lämnas ansluten på ett hotellrum i tre dagar är en olycka.
Båda visar samma gröna ikon, och båda svarar likadant om du frågar hur länge tunneln har varit uppe. Den siffran är inte den intressanta. Det som spelar roll är vad anslutningen håller tillgängligt, för vem, och vad som faktiskt avslutar den.
Tre klockor som går var för sig
Det första tillståndet är vägen. En tunnel och dess policyer gör en uppsättning tjänster nåbara, och en länk utan trafik kan stå redo för nästa begäran. Hur länge den står redo är ett implementeringsbeslut, inte en universell timer.
Det andra tillståndet är behörighet. En accepterad identitet eller enhet kan vara auktoriserad att använda den vägen. Den auktoriseringen bör ändras när en roll ändras, en enhet försvinner eller kompromettering misstänks, och den är oberoende av om paket flödar.
Det tredje tillståndet är applikationens egen session. En databasklient, ett fjärrskrivbord eller en webbapplikation autentiserar separat och håller sitt eget tillstånd. Att stänga tunneln avslutar inte nödvändigtvis något av detta.
En genomgång som behandlar detta som en enda fråga slutar med att bråka om inaktiva timers. Alla tre kan vara friska eller trasiga var för sig, och ett fynd i en säger lite om de andra. En checklista med tre rader slår en debatt om ett enda timeout-värde. Skriv svaret för varje tillstånd separat.
Tunneln är en väg, inte ett märke
En etablerad tunnel är bevis på att en skyddad väg finns mellan två ändpunkter. Det är inte bevis på att varje process bakom någon ändpunkt bör nå varje tjänst på andra sidan.
NIST:s zero trust-vägledning säger samma sak från andra hållet: nätverksposition bör inte behandlas som implicit tillit. En platslänk är ett transportfaktum, och behörighet för en värd att använda en applikation är ett separat beslut med egen ägare.
En komprometterad peer kan fortfarande försöka skadliga handlingar genom tjänster den har tillåtelse att nå. Filtrering och övervakning minskar specifika risker utan att sudda ut konsekvenserna av kompromettering på ändpunkten. Designa för vägen och auktorisera för tjänsten.
Att motivera en permanent platslänk
Den försvarliga varianten av alltid på namnger sitt syfte exakt. Vilka källor, vilka mål, vilken riktning och vem som äger varje post. En filialbrandvägg som tillåter varje filialvärd mot varje centralt subnät har inte hållit en länk för ett namngivet syfte; den har hållit den för vad som helst någon kommer på senare.
Där en peer inte kan uppfylla den nödvändiga tillitsnivån, snäva in gränsen eller ändra arrangemanget. Att förlita sig på sporadisk manuell frånkoppling är en processkontroll, och processkontroller är minst tillförlitliga just när en incident gör dem obekväma.
Håll motiveringen tillsammans med konfigurationen. Ett permanent undantag med skrivet syfte kan granskas och avvecklas. Ett utan syfte blir permanent som standard.
Nyckelbyte är inte återkallelse
Att ersätta nycklar enligt ett schema upprätthåller skyddets livscykel. Det förnyar material och bevarar konfidentialitet. Det tar inte bort en ändpunkts rättighet.
Om ändpunkten fortfarande har giltiga uppgifter och en åtkomstpolicy som accepterar den, återställer nästa förhandling samma tillåtna väg. Därför är påståendet att nycklar roterar varje timme inte ett svar på en förlorad enhet: den förlorade enheten roterar också, så länge dess identitet är betrodd. Kontrollera rättigheten innan du kontrollerar schemat. Rotation är hygien, och återkallelse är ett åtkomstbeslut.
Återkallelse är en annan mekanism med egen latens: ett återkallat certifikat, ett inaktiverat konto, en ändrad grupp, en borttagen nätverksregel. Var och en träder i kraft vid en annan punkt, och var och en beter sig olika för sessioner som redan är etablerade.
Att avsluta det som redan körs
Fråga vad implementeringen gör med etablerade sessioner när åtkomst tas bort. Den kan avsluta dem, vänta på utgång eller tillämpa ett dokumenterat beteende däremellan. Anta inte att morgondagens antagningsändring stänger dagens applikationsanslutning.
För interaktiv åtkomst, lägg sessionsgränser och inaktivitetsregler hos identitets- och VPN-ägarna i stället för enbart nätverksteamet. För en platstjänst, fastställ proceduren som underhåll, avbrott eller en säkerhetsincident använder för att stänga av åtkomst.
Testa sedan tre utfall: tillåtet arbete fungerar fortfarande, en orelaterad tjänst nekas, och borttagningsproceduren ger det dokumenterade resultatet. En alltid på-design är acceptabel när syfte, auktorisering och avstängningsförmåga alla är nedskrivna och övade. Annars är det en bekvämlighet som överlevde sitt skäl.