VPN sempre activa: camí, permís i sessió per separat

Mantenir un túnel obert les vint-i-quatre hores és una decisió de disseny amb una versió raonable i una versió descuidada. Una seu que necessita una aplicació central tot el dia, més una feina de còpia nocturna, té un motiu. Un portàtil que queda connectat tres dies en una habitació d’hotel és un accident.

Tots dos mostren la mateixa icona verda i tots dos responen igual si pregunteu quant temps fa que el túnel està obert. Aquest número no és el interessant. El que importa és què manté disponible la connexió, per a qui i què l’acaba realment.

Tres rellotges que van per separat

El primer estat és el camí. Un túnel i les seves polítiques fan accessible un conjunt de serveis, i un enllaç sense trànsit pot quedar a punt per a la petició següent. Quant temps queda a punt és una decisió d’implementació, no un temporitzador universal.

El segon estat és el permís. Una identitat o un dispositiu acceptat pot estar autoritzat a utilitzar aquest camí. Aquesta autorització hauria de canviar quan canvia un rol, quan desapareix un dispositiu o quan se sospita un compromís, i és independent de si circulen paquets.

El tercer estat és la sessió pròpia de l’aplicació. Un client de base de dades, un escriptori remot o una aplicació web s’autentiquen per separat i mantenen el seu propi estat. Tancar el túnel no acaba necessàriament amb cap d’ells.

Una revisió que tracta aquests tres com una sola pregunta acaba discutint sobre temporitzadors d’inactivitat. Cadascun pot estar sa o trencat pel seu compte, i una troballa en un diu poc sobre els altres. Una llista de tres línies és millor que un debat sobre un sol valor d’espera. Escriviu la resposta per a cada estat per separat.

El túnel és un camí, no una insígnia

Un túnel establert és prova que existeix un camí protegit entre dos extrems. No és prova que cada procés darrere de qualsevol extrem hagi d’arribar a cada servei de l’altre costat.

Les guies de confiança zero del NIST diuen el mateix des de l’altra direcció: la ubicació a la xarxa no s’ha de tractar com una confiança implícita. L’enllaç d’una seu és un fet de transport, i el permís d’un amfitrió per fer servir una aplicació és una decisió separada amb el seu propi propietari.

Un parell compromès pot intentar accions perjudicials a través de serveis als quals té permís d’arribar. El filtratge i la monitorització redueixen riscos concrets sense esborrar les conseqüències del compromís d’un extrem. Dissenyeu per al camí i autoritzeu per al servei.

Justificar un enllaç de seu permanent

La versió defensable del sempre actiu anomena el seu propòsit amb precisió. Quines fonts, quines destinacions, quina direcció i qui posseeix cada entrada. Un tallafoc de seu que permet a cada amfitrió de la seu arribar a cada subxarxa central no ha mantingut un enllaç per a un propòsit nomenat; l’ha mantingut per a qualsevol cosa que algú pensi més tard.

On un parell no pot assolir el nivell de confiança exigit, estrenyeu la frontera o canvieu la disposició. Confiar en una desconnexió manual ocasional és un control de procés, i els controls de procés són menys fiables justament quan un incident els fa incòmodes.

Guardau la justificació amb la configuració. Una excepció permanent amb un propòsit escrit es pot revisar i retirar. Una sense propòsit es torna permanent per defecte.

Canviar claus no és revocar

Substituir les claus segons un calendari manté el cicle de vida de la protecció. Renova el material i preserva la confidencialitat. No treu el dret d’un extrem.

Si l’extrem encara té credencials vàlides i una política d’accés que l’accepta, la negociació següent restaura el mateix camí permès. Per això rotar claus cada hora no és una resposta a un dispositiu perdut: el dispositiu perdut també rota mentre la seva identitat sigui confiada. Comprovau el dret abans del calendari. La rotació és higiene i la revocació és una decisió d’accés.

La revocació és un mecanisme diferent amb la seva pròpia latència: un certificat revocat, un compte desactivat, un grup canviat, una regla de xarxa eliminada. Cadascun actua en un moment diferent i es comporta de manera diferent amb les sessions ja establertes.

Acabar el que ja s’està executant

Preguntau què fa la implementació amb les sessions establertes quan es retira l’accés. Pot acabar-les, esperar el venciment o aplicar un comportament documentat entremig. No suposeu que el canvi d’admissió de demà tanca la connexió d’aplicació d’avui.

Per a l’accés interactiu, posau els límits de sessió i les regles d’inactivitat en mans dels propietaris d’identitat i de VPN, no només de l’equip de xarxa. Per a un servei de seu, establiu el procediment que el manteniment, una caiguda o un incident de seguretat fa servir per desactivar l’accés.

Després provau tres resultats: la feina permesa encara funciona, un servei no relacionat es denega i el procediment de retirada produeix el resultat documentat. Un disseny sempre actiu és acceptable quan el seu propòsit, l’autorització i la capacitat d’aturada estan escrits i exercitats. Si no, és una comoditat que ha sobreviscut al seu motiu.