Always-on VPN: rute, tillatelse og økt hver for seg

Å holde en tunnel åpen hele døgnet er et designvalg med en forsvarlig og en slurvete versjon. En filial som trenger en sentral applikasjon hele dagen, i tillegg til en nattlig sikkerhetskopijobb, har en grunn. En bærbar PC som blir liggende tilkoblet tre dager på et hotellrom, er en ulykke.

Begge viser samme grønne ikon, og begge svarer likt hvis man spør hvor lenge tunnelen har vært oppe. Det tallet er ikke det interessante. Det som betyr noe, er hva forbindelsen holder tilgjengelig, for hvem, og hva som faktisk avslutter den.

Tre klokker som går hver for seg

Den første tilstanden er ruten. En tunnel og dens policyer gjør et sett tjenester tilgjengelige, og en lenke uten trafikk kan stå klar for neste forespørsel. Hvor lenge den står klar, er en implementeringsbeslutning, ikke en universell timer.

Den andre tilstanden er tillatelsen. En akseptert identitet eller enhet kan være autorisert til å bruke den ruten. Den autorisasjonen bør endres når en rolle endres, en enhet forsvinner eller kompromittering mistenkes, og den er uavhengig av om pakker flyter.

Den tredje tilstanden er applikasjonens egen økt. En databaseklient, et fjernskrivebord eller en webapplikasjon autentiserer seg separat og holder sin egen tilstand. Å lukke tunnelen avslutter ikke nødvendigvis noen av dem.

En gjennomgang som behandler disse tre som ett spørsmål, ender i diskusjon om inaktivitetstimere. Hver av de tre kan være sunn eller ødelagt for seg, og et funn i én sier lite om de andre. En sjekkliste med tre linjer er bedre enn en debatt om én tidsavbruddsverdi. Skriv svaret for hver tilstand separat.

Tunnelen er en rute, ikke et merke

En etablert tunnel er bevis for at det finnes en beskyttet rute mellom to endepunkter. Det er ikke bevis for at hver prosess bak et endepunkt må nå hver tjeneste på den andre siden.

NISTs nulltillitsveiledning sier det samme fra den andre retningen: nettverksplassering bør ikke behandles som implisitt tillit. En lokasjonslenke er et transportfaktum, og tillatelsen for én vert til å bruke én applikasjon er en separat beslutning med sin egen eier.

En kompromittert partner kan fortsatt forsøke skadelige handlinger gjennom tjenester den har lov til å nå. Filtrering og overvåking reduserer bestemte risikoer uten å slette følgene av kompromittering av endepunktet. Design for ruten, og autoriser for tjenesten.

Begrunne en permanent lokasjonslenke

Den forsvarlige versjonen av alltid-på navngir formålet presist. Hvilke kilder, hvilke mål, hvilken retning, og hvem som eier hver oppføring. En filialbrannmur som tillater hver filialvert å nå hvert sentralt subnett, har ikke holdt en lenke for et navngitt formål; den har holdt den for alt noen finner på senere.

Der en partner ikke kan nå det krevede tillitsnivået, gjør grensen snevrere eller endre ordningen. Å stole på sporadisk manuell frakobling er en prosesskontroll, og prosesskontroller er minst pålitelige nettopp når en hendelse gjør dem ubekvemme.

Oppbevar begrunnelsen sammen med konfigurasjonen. Et permanent unntak med skrevet formål kan gjennomgås og trekkes tilbake. Et uten formål blir permanent som standard.

Nøkkelutskifting er ikke tilbakekalling

Å bytte nøkler etter en plan opprettholder beskyttelsens livssyklus. Det fornyer materiale og bevarer konfidensialitet. Det fjerner ikke et endepunkts rettighet.

Hvis endepunktet fortsatt har gyldige påloggingsdata og en tilgangspolicy som godtar det, gjenoppretter neste forhandling den samme tillatte ruten. Derfor er timelig nøkkelrotasjon ikke et svar på en mistet enhet: den mistede enheten roterer også, så lenge identiteten dens fortsatt er betrodd. Kontroller rettigheten før planen. Rotasjon er hygiene, og tilbakekalling er en tilgangsbeslutning.

Tilbakekalling er en annen mekanisme med sin egen forsinkelse: et tilbakekalt sertifikat, en deaktivert konto, en endret gruppe, en fjernet nettverksregel. Hver virker på et forskjellig tidspunkt og oppfører seg forskjellig for økter som allerede er etablert.

Avslutte det som allerede kjører

Spør hva implementeringen gjør med etablerte økter når tilgangen fjernes. Den kan avslutte dem, vente på utløp eller anvende en dokumentert atferd imellom. Ikke anta at morgendagens opptaksendring lukker dagens applikasjonsforbindelse.

For interaktiv tilgang bør øktgrenser og inaktivitetsregler ligge hos eierne av identitet og VPN, ikke bare hos nettverksteamet. For en lokasjonstjeneste, fastsett prosedyren som vedlikehold, driftsstans eller en sikkerhetshendelse bruker for å slå av tilgangen.

Test deretter tre utfall: tillatt arbeid virker fortsatt, en urelatert tjeneste avvises, og fjerningsprosedyren gir det dokumenterte resultatet. Et alltid-på-design er akseptabelt når formålet, autorisasjonen og evnen til å slå av alle er skrevet ned og øvd. Ellers er det en bekvemmelighet som har overlevd grunnen sin.