Always-on VPN: rute, tilladelse og session hver for sig

At holde en tunnel åben hele døgnet er et designvalg med en forsvarlig og en sjusket udgave. En filial, der har brug for en central applikation hele dagen, plus et natligt backupjob, har en grund. En bærbar, der bliver efterladt tilsluttet tre dage på et hotelværelse, er et uheld.

Begge viser det samme grønne ikon, og begge svarer ens, hvis man spørger, hvor længe tunnelen har været oppe. Det tal er ikke det interessante. Det afgørende er, hvad forbindelsen holder tilgængeligt, for hvem, og hvad der reelt afslutter den.

Tre ure, der går hver for sig

Den første tilstand er ruten. En tunnel og dens politikker gør et sæt tjenester tilgængelige, og et link uden trafik kan stå klar til næste anmodning. Hvor længe det står klar, er en implementeringsbeslutning, ikke en universel timer.

Den anden tilstand er tilladelsen. En accepteret identitet eller enhed kan være autoriseret til at bruge den rute. Den autorisation bør ændre sig, når en rolle ændres, en enhed forsvinder, eller kompromittering mistænkes, og den er uafhængig af, om pakker flyder.

Den tredje tilstand er applikationens egen session. En databaseklient, et fjernskrivebord eller en webapplikation godkender sig separat og holder sin egen tilstand. At lukke tunnelen afslutter ikke nødvendigvis nogen af dem.

En gennemgang, der behandler disse tre som ét spørgsmål, ender i en diskussion om inaktivitetstimere. Hver af de tre kan være sund eller i stykker for sig, og et fund i én siger lidt om de andre. En tjekliste med tre linjer er bedre end en debat om én timeoutværdi. Skriv svaret for hver tilstand separat.

Tunnelen er en rute, ikke et mærke

En etableret tunnel er bevis for, at der findes en beskyttet rute mellem to endepunkter. Det er ikke bevis for, at enhver proces bag et endepunkt skal nå enhver tjeneste på den anden side.

NISTs nul-tillid-vejledning siger det samme fra den anden side: netværksplacering bør ikke behandles som implicit tillid. Et lokalitetsslink er et transportfaktum, og tilladelsen for én vært til at bruge én applikation er en separat beslutning med sin egen ejer.

En kompromitteret peer kan stadig forsøge skadelige handlinger gennem tjenester, den må nå. Filtrering og overvågning reducerer konkrete risici uden at slette følgerne af kompromittering af endepunktet. Design til ruten, og autoriser til tjenesten.

Begrundelse af et permanent lokalitetsslink

Den forsvarlige udgave af always-on navngiver sit formål præcist. Hvilke kilder, hvilke destinationer, hvilken retning, og hvem der ejer hver post. En filial-firewall, der tillader hver filialvært at nå hvert centralt subnet, har ikke holdt et link til et navngivet formål; den har holdt det til alt, hvad nogen finder på senere.

Hvor en peer ikke kan nå det krævede tillidsniveau, indsnævr grænsen eller ændr ordningen. At stole på lejlighedsvis manuel afbrydelse er en proceskontrol, og proceskontroller er mindst pålidelige netop når en hændelse gør dem besværlige.

Opbevar begrundelsen sammen med konfigurationen. En permanent undtagelse med et skrevet formål kan gennemgås og trækkes tilbage. En uden formål bliver permanent som standard.

Nøgleudskiftning er ikke tilbagekaldelse

At udskifte nøgler efter en plan vedligeholder beskyttelsens livscyklus. Det fornyer materiale og bevarer fortrolighed. Det fjerner ikke et endepunkts berettigelse.

Hvis endepunktet stadig har gyldige legitimationsoplysninger og en adgangspolitik, der accepterer det, genskaber den næste forhandling den samme tilladte rute. Derfor er timesrotation af nøgler ikke et svar på en mistet enhed: den mistede enhed roterer også, så længe dens identitet stadig er betroet. Kontroller berettigelsen før planen. Rotation er hygiejne, og tilbagekaldelse er en adgangsbeslutning.

Tilbagekaldelse er en anden mekanisme med sin egen latenstid: et tilbagekaldt certifikat, en deaktiveret konto, en ændret gruppe, en fjernet netværksregel. Hver virker på et forskelligt tidspunkt og opfører sig forskelligt for sessioner, der allerede er etableret.

Afslutning af det, der allerede kører

Spørg, hvad implementeringen gør ved etablerede sessioner, når adgangen fjernes. Den kan afslutte dem, vente på udløb eller anvende en dokumenteret adfærd imellem. Antag ikke, at morgendagens optagelsesændring lukker dagens applikationsforbindelse.

For interaktiv adgang bør sessionsgrænser og inaktivitetsregler ligge hos identitets- og VPN-ejerne, ikke kun hos netværksteamet. For en lokalitetstjeneste fastlæg proceduren, som vedligeholdelse, nedbrud eller en sikkerhedshændelse bruger til at slå adgangen fra.

Test derefter tre udfald: tilladt arbejde virker stadig, en uafhængig tjeneste afvises, og fjernelsesproceduren giver det dokumenterede resultat. Et always-on-design er acceptabelt, når formål, autorisation og nedlukningsevne alle er skrevet ned og øvet. Ellers er det en bekvemmelighed, der har overlevet sin grund.