VPN sempre activa: camiño, permiso e sesión por separado

Manter un túnel aberto as vinte e catro horas é unha decisión de deseño cunha versión razoable e unha versión descoidada. Unha sucursal que necesita unha aplicación central todo o día, máis unha tarefa de copia nocturna, ten un motivo. Un portátil que queda conectado tres días nunha habitación de hotel é un accidente.

Ambos mostran a mesma icona verde e ambos responden igual se se pregunta canto tempo leva aberto o túnel. Ese número non é o interesante. O que importa é que mantén dispoñible a conexión, para quen e que a termina realmente.

Tres reloxos que van por separado

O primeiro estado é o camiño. Un túnel e as súas políticas fan accesible un conxunto de servizos, e unha ligazón sen tráfico pode seguir lista para a seguinte petición. Canto tempo segue lista é unha decisión de implementación, non un temporizador universal.

O segundo estado é o permiso. Unha identidade ou un dispositivo aceptado pode estar autorizado a usar ese camiño. Esa autorización debería cambiar cando cambia un rol, desaparece un dispositivo ou se sospeita un compromiso, e é independente de se flúen paquetes.

O terceiro estado é a sesión propia da aplicación. Un cliente de base de datos, un escritorio remoto ou unha aplicación web autentícanse por separado e manteñen o seu propio estado. Pechar o túnel non remata necesariamente con ningún deles.

Unha revisión que trata estes tres como unha soa pregunta acaba discutindo sobre temporizadores de inactividade. Cada un pode estar san ou roto pola súa conta, e un achado nun di pouco sobre os demais. Unha lista de tres liñas é mellor que un debate sobre un só valor de espera. Escriba a resposta para cada estado por separado.

O túnel é un camiño, non unha insignia

Un túnel establecido é proba de que existe un camiño protexido entre dous extremos. Non é proba de que cada proceso detrás de calquera extremo deba acadar cada servizo do outro lado.

As guías de confianza cero do NIST din o mesmo desde a outra dirección: a localización na rede non debe tratarse como confianza implícita. A ligazón dunha sede é un feito de transporte, e o permiso dun host para usar unha aplicación é unha decisión separada co seu propio propietario.

Un par comprometido aínda pode tentar accións daniñas a través de servizos aos que ten permiso de chegar. O filtrado e a monitorización reducen riscos concretos sen borrar as consecuencias do compromiso dun extremo. Deseñe para o camiño e autorice para o servizo.

Xustificar unha ligazón de sede permanente

A versión defendible do sempre activo nomea o seu propósito con precisión. Que fontes, que destinos, que dirección e quen posúe cada entrada. Un cortalumes de sucursal que permite a cada host da sucursal cada subrede central non mantivo unha ligazón para un propósito nomeado; mantívoa para calquera cousa que a alguén se lle ocorra despois.

Onde un par non pode acadar o nivel de confianza esixido, estreite a fronteira ou cambie a disposición. Confiar nunha desconexión manual ocasional é un control de proceso, e os controis de proceso son menos fiables xusto cando un incidente os fai incómodos.

Garde a xustificación coa configuración. Unha excepción permanente cun propósito escrito pódese revisar e retirar. Unha sen propósito vólvese permanente por defecto.

Rotar claves non é revogar

Substituír as claves segundo un calendario mantén o ciclo de vida da protección. Renova o material e preserva a confidencialidade. Non retira o dereito dun extremo.

Se o extremo aínda ten credenciais válidas e unha política de acceso que o acepta, a seguinte negociación restaura o mesmo camiño permitido. Por iso rotar claves cada hora non é unha resposta a un dispositivo perdido: o dispositivo perdido tamén rota mentres a súa identidade siga sendo confiable. Comprobe o dereito antes do calendario. A rotación é hixiene e a revogación é unha decisión de acceso.

A revogación é outro mecanismo coa súa propia latencia: un certificado revogado, unha conta desactivada, un grupo cambiado, unha regra de rede eliminada. Cada un surte efecto nun punto distinto e compórtase de forma diferente coas sesións xa establecidas.

Rematar o que xa está en marcha

Pregunte que fai a implementación coas sesións establecidas cando se retira o acceso. Pode terminalas, agardar a caducidade ou aplicar algún comportamento documentado entre medias. Non supoña que o cambio de admisión de mañá pecha a conexión de aplicación de hoxe.

Para o acceso interactivo, poña os límites de sesión e as regras de inactividade en mans dos propietarios de identidade e de VPN, non só do equipo de rede. Para un servizo de sede, fixe o procedemento que mantemento, unha caída ou un incidente de seguridade usa para desactivar o acceso.

Despois probe tres resultados: o traballo permitido segue funcionando, un servizo non relacionado denégase e o procedemento de retirada produce o resultado documentado. Un deseño sempre activo é aceptable cando o seu propósito, a súa autorización e a súa capacidade de apagado están escritos e exercitados. Se non, é unha comodidade que sobreviviu ao seu motivo.