Alltid på VPN: skille sti, tillatelse og sesjon

Å holde en tunnel oppe døgnet rundt er et designvalg med en forsvarlig og en uforsiktig variant. En filial som trenger en sentral applikasjon hele dagen, pluss en nattlig sikkerhetskopijobb, har en grunn. En bærbar PC som blir stående tilkoblet på et hotellrom i tre dager, er en ulykke.

Begge viser samme grønne ikon, og begge svarer likt hvis du 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 stien. 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 implementasjonsbeslutning, ikke en universell timer.

Den andre tilstanden er tillatelse. En godkjent identitet eller enhet kan være autorisert til å bruke den stien. 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 sesjon. En databaseklient, et eksternt skrivebord eller en nettapplikasjon autentiserer separat og holder sin egen tilstand. Å lukke tunnelen avslutter ikke nødvendigvis noe av dette.

En gjennomgang som behandler dette som ett spørsmål, ender med å krangle om inaktive timere. Alle tre kan være friske eller ødelagte hver for seg, og et funn i én sier lite om de andre. En sjekkliste med tre linjer slår en debatt om én tidsavbruddsverdi. Skriv svaret for hver tilstand separat.

Tunnelen er en sti, ikke et merke

En etablert tunnel er bevis på at en beskyttet sti finnes mellom to endepunkter. Det er ikke bevis for at hver prosess bak hvert endepunkt bør nå hver tjeneste på den andre siden.

NISTs zero trust-veiledning sier det samme fra motsatt side: nettverksposisjon bør ikke behandles som implisitt tillit. En stedslenke er et transportfaktum, og tillatelse for én vert til å bruke én applikasjon er en egen beslutning med egen eier.

En kompromittert peer kan fortsatt forsøke skadelige handlinger gjennom tjenester den har lov til å nå. Filtrering og overvåking reduserer bestemte risikoer uten å viske ut konsekvensene av kompromittering på endepunktet. Design for stien, og autoriser for tjenesten.

Å begrunne en permanent stedslenke

Den forsvarlige varianten 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 mot hvert sentralt subnett har ikke holdt en lenke for et navngitt formål; den har holdt den for hva som helst noen finner på senere.

Der en peer ikke kan oppfylle nødvendig tillitsnivå, må grensen innsnevres eller ordningen endres. Å stole på sporadisk manuell frakobling er en prosesskontroll, og prosesskontroller er minst pålitelige nettopp når en hendelse gjør dem upraktiske.

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

Nøkkelbytte er ikke tilbakekalling

Å erstatte 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 legitimasjoner og en tilgangspolicy som godtar det, gjenoppretter neste forhandling samme tillatte sti. Derfor er det at nøkler roteres hver time ikke et svar på en tapt enhet: den tapte enheten roterer også, så lenge identiteten er betrodd. Sjekk rettigheten før du sjekker planen. Rotasjon er hygiene, og tilbakekalling er en tilgangsbeslutning.

Tilbakekalling er en annen mekanisme med egen latens: et tilbakekalt sertifikat, en deaktivert konto, en endret gruppe, en fjernet nettverksregel. Hver trer i kraft på et ulikt punkt, og hver oppfører seg ulikt for sesjoner som allerede er etablert.

Å avslutte det som allerede kjører

Spør hva implementasjonen gjør med etablerte sesjoner når tilgang fjernes. Den kan avslutte dem, vente på utløp eller anvende en dokumentert oppførsel imellom. Ikke anta at morgendagens opptaksendring lukker dagens applikasjonsforbindelse.

For interaktiv tilgang bør sesjonsgrenser og inaktivitetsregler ligge hos identitets- og VPN-eierne, ikke bare hos nettverksteamet. For en stedstjeneste bør du fastsette prosedyren som vedlikehold, driftsstans eller en sikkerhetshendelse bruker for å stenge tilgang.

Test så 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ål, autorisasjon og nedstengningsmulighet alle er skrevet ned og øvd på. Ellers er det en bekvemmelighet som overlevde grunnen sin.