Always-on VPN: rute, løyve og økt kvar for seg
Ein konstant open tunnel kan vere rett for ein filial og gal for ein gløymd berbar PC. Gå gjennom dei tre tilstandane han held i live, og kva ei fjerning faktisk avsluttar.
Å halde ein tunnel open heile døgnet er eit designval med ein forsvarleg og ein slurvete versjon. Ein filial som treng ein sentral applikasjon heile dagen, i tillegg til ein nattleg tryggleikskopijobb, har ei grunn. Ein berbar PC som blir liggjande tilkopla tre dagar på eit hotellrom, er ei ulukke.
Begge viser same grøne ikonet, og begge svarar likt om ein spør kor lenge tunnelen har vore oppe. Det talet er ikkje det interessante. Det som tel, er kva sambandet held tilgjengeleg, for kven, og kva som faktisk avsluttar det.
Tre klokker som går kvar for seg
Den første tilstanden er ruta. Ein tunnel og retningslinjene hans gjer eit sett tenester tilgjengelege, og ei lenke utan trafikk kan stå klar for neste førespurnad. Kor lenge ho står klar, er eit implementeringsval, ikkje ein universell timer.
Den andre tilstanden er løyvet. Ein godteken identitet eller eining kan vere autorisert til å bruke den ruta. Det løyvet bør endre seg når ei rolle endrar seg, ei eining forsvinn eller kompromittering blir mistenkt, og det er uavhengig av om pakkar flyt.
Den tredje tilstanden er den eigne økta til applikasjonen. Ein databaseklient, eit fjernskrivebord eller ein webapplikasjon autentiserer seg separat og held sin eigen tilstand. Å lukke tunnelen avsluttar ikkje nødvendigvis nokon av dei.
Ei vurdering som behandlar desse tre som eitt spørsmål, endar i diskusjon om inaktivitetstimar. Kvar av dei tre kan vere sunn eller øydelagd for seg, og eit funn i éin seier lite om dei andre. Ei sjekkliste med tre linjer er betre enn ein debatt om éin tidsavbrotsverdi. Skriv svaret for kvar tilstand separat.
Tunnelen er ei rute, ikkje eit merke
Ein etablert tunnel er prov på at det finst ei verna rute mellom to endepunkt. Det er ikkje prov på at kvar prosess bak eit endepunkt må nå kvar teneste på den andre sida.
Nulltillitsrettleiinga frå NIST seier det same frå den andre retninga: nettverksplassering bør ikkje behandlast som implisitt tillit. Ei lokasjonslenke er eit transportfaktum, og løyvet for éin vert til å bruke éin applikasjon er eit separat val med sin eigen eigar.
Ein kompromittert partnar kan framleis prøve skadelege handlingar gjennom tenester han har lov til å nå. Filtrering og overvaking reduserer særskilde risikoar utan å slette følgjene av kompromittering av endepunktet. Design for ruta, og autoriser for tenesta.
Grunngi ei permanent lokasjonslenke
Den forsvarlege versjonen av alltid-på namngjev føremålet presist. Kva kjelder, kva mål, kva retning, og kven som eig kvar oppføring. Ein filialbrannmur som lèt kvar filialvert nå kvart sentralt subnett, har ikkje halde ei lenke for eit namngjeve føremål; han har halde henne for alt nokon finn på seinare.
Der ein partnar ikkje kan nå det kravde tillitsnivået, gjer grensa snevrare eller endre ordninga. Å stole på sporadisk manuell fråkopling er ein prosesskontroll, og prosesskontrollar er minst pålitelege nettopp når ei hending gjer dei ubekveme.
Oppbevar grunngjevinga saman med konfigurasjonen. Eit permanent unntak med skrive føremål kan gjennomgåast og trekkjast tilbake. Eit utan føremål blir permanent som standard.
Nøkkelbyte er ikkje tilbakekalling
Å byte nøklar etter ein plan held livssyklusen til vernet oppe. Det fornyar materiale og bevarer konfidensialitet. Det tek ikkje bort retten til eit endepunkt.
Viss endepunktet framleis har gyldige påloggingsdata og ein tilgangspolicy som godtek det, gjenopprettar neste forhandling den same tillatne ruta. Difor er nøkkelrotasjon kvar time ikkje eit svar på ei mist eining: den miste eininga roterer òg, så lenge identiteten hennar framleis er betrudd. Kontroller retten før planen. Rotasjon er hygiene, og tilbakekalling er eit tilgangsval.
Tilbakekalling er ein annan mekanisme med si eiga forseinking: eit tilbakekalla sertifikat, ein deaktivert konto, ei endra gruppe, ei fjerna nettverksregel. Kvar verkar på eit ulikt tidspunkt og oppfører seg ulikt for økter som alt er etablerte.
Avslutte det som alt går
Spør kva implementeringa gjer med etablerte økter når tilgangen blir fjerna. Ho kan avslutte dei, vente på utløp eller bruke ein dokumentert åtferd imellom. Ikkje gå ut frå at morgondagens opptaksendring lukkar dagens applikasjonssamband.
For interaktiv tilgang bør øktgrenser og inaktivitetsreglar liggje hos eigarane av identitet og VPN, ikkje berre hos nettverksteamet. For ei lokasjonsteneste, fastset prosedyren som vedlikehald, driftsstans eller ei tryggleikshending brukar for å slå av tilgangen.
Test så tre utfall: tillate arbeid verkar framleis, ei urelatert teneste blir avvist, og fjerningsprosedyren gir det dokumenterte resultatet. Eit alltid-på-design er akseptabelt når føremålet, autorisasjonen og evna til å slå av alle er skrivne ned og øvde. Elles er det ei bekvemmelegheit som har overlevd grunnen sin.