VPN siempre activa: camino, permiso y sesión por separado

Mantener un túnel abierto las veinticuatro horas es una decisión de diseño con una versión razonable y una versión descuidada. Una sucursal que necesita una aplicación central todo el día, más una tarea de copia nocturna, tiene un motivo. Un portátil que queda conectado tres días en una habitación de hotel es un accidente.

Ambos muestran el mismo icono verde y ambos responden igual si se pregunta cuánto tiempo lleva abierto el túnel. Ese número no es el interesante. Lo que importa es qué mantiene disponible la conexión, para quién y qué la termina realmente.

Tres relojes que corren por separado

El primer estado es el camino. Un túnel y sus políticas hacen accesible un conjunto de servicios, y un enlace sin tráfico puede seguir listo para la siguiente petición. Cuánto tiempo sigue listo es una decisión de implementación, no un temporizador universal.

El segundo estado es el permiso. Una identidad o un dispositivo aceptado puede estar autorizado a usar ese camino. Esa autorización debería cambiar cuando cambia un rol, desaparece un dispositivo o se sospecha un compromiso, y es independiente de si fluyen paquetes.

El tercer estado es la sesión propia de la aplicación. Un cliente de base de datos, un escritorio remoto o una aplicación web se autentican por separado y mantienen su propio estado. Cerrar el túnel no termina necesariamente con ninguno de ellos.

Una revisión que trata estos tres como una sola pregunta acaba discutiendo sobre temporizadores de inactividad. Cada uno puede estar sano o roto por su cuenta, y un hallazgo en uno dice poco sobre los demás. Una lista de tres líneas es mejor que un debate sobre un solo valor de espera. Escriba la respuesta para cada estado por separado.

El túnel es un camino, no una insignia

Un túnel establecido es prueba de que existe un camino protegido entre dos extremos. No es prueba de que cada proceso detrás de cualquier extremo deba alcanzar cada servicio del otro lado.

Las guías de confianza cero del NIST dicen lo mismo desde la otra dirección: la ubicación en la red no debe tratarse como confianza implícita. El enlace de una sede es un hecho de transporte, y el permiso de un host para usar una aplicación es una decisión separada con su propio propietario.

Un par comprometido todavía puede intentar acciones dañinas a través de servicios a los que se le permite llegar. El filtrado y la monitorización reducen riesgos concretos sin borrar las consecuencias del compromiso de un extremo. Diseñe para el camino y autorice para el servicio.

Justificar un enlace de sede permanente

La versión defendible del siempre activo nombra su propósito con precisión. Qué fuentes, qué destinos, qué dirección y quién posee cada entrada. Un cortafuegos de sucursal que permite a cada host de la sucursal cada subred central no ha mantenido un enlace para un propósito nombrado; lo ha mantenido para cualquier cosa que a alguien se le ocurra después.

Donde un par no puede alcanzar el nivel de confianza exigido, estreche la frontera o cambie la disposición. Confiar en una desconexión manual ocasional es un control de proceso, y los controles de proceso son menos fiables justo cuando un incidente los vuelve incómodos.

Guarde la justificación con la configuración. Una excepción permanente con un propósito escrito se puede revisar y retirar. Una sin propósito se vuelve permanente por defecto.

Rotar claves no es revocar

Sustituir las claves según un calendario mantiene el ciclo de vida de la protección. Renueva el material y preserva la confidencialidad. No retira el derecho de un extremo.

Si el extremo aún tiene credenciales válidas y una política de acceso que lo acepta, la siguiente negociación restaura el mismo camino permitido. Por eso rotar claves cada hora no es una respuesta a un dispositivo perdido: el dispositivo perdido también rota mientras su identidad siga siendo confiable. Compruebe el derecho antes del calendario. La rotación es higiene y la revocación es una decisión de acceso.

La revocación es otro mecanismo con su propia latencia: un certificado revocado, una cuenta deshabilitada, un grupo cambiado, una regla de red eliminada. Cada uno surte efecto en un punto distinto y se comporta de forma diferente con las sesiones ya establecidas.

Terminar lo que ya está en marcha

Pregunte qué hace la implementación con las sesiones establecidas cuando se retira el acceso. Puede terminarlas, esperar su caducidad o aplicar algún comportamiento documentado entre medias. No suponga que el cambio de admisión de mañana cierra la conexión de aplicación de hoy.

Para el acceso interactivo, ponga los límites de sesión y las reglas de inactividad en manos de los propietarios de identidad y de VPN, no solo del equipo de red. Para un servicio de sede, fije el procedimiento que mantenimiento, una caída o un incidente de seguridad usa para desactivar el acceso.

Después pruebe tres resultados: el trabajo permitido sigue funcionando, un servicio no relacionado se deniega y el procedimiento de retirada produce el resultado documentado. Un diseño siempre activo es aceptable cuando su propósito, su autorización y su capacidad de apagado están escritos y ejercitados. Si no, es una comodidad que sobrevivió a su motivo.