¿Sigue haciendo falta una VPN de sitio si la aplicación usa mTLS y SSO?
Recorra los canales que el inicio de sesión de su aplicación nunca cubre y decida después si el acceso a la red privada es redundante o sigue siendo la única vía hasta el host.
Inicia sesión mediante mTLS, el panel se carga y la afirmación de que la VPN de sitio ya es redundante suena razonable más o menos el tiempo que tarda en hacerle falta restaurar una base de datos a las dos de la madrugada. La frontera TLS de la aplicación describe un solo canal. El host, la base de datos, el destino de las copias de seguridad y la cuenta de nube llevan cada uno su propia ruta de entrada, su propia identidad y su propio aprobador, y ninguno de ellos se ejercita con un inicio de sesión correcto.
Camine hacia fuera desde la pantalla de inicio de sesión
Inicie sesión como lo haría un usuario corriente y anote cada salto que toca la petición: navegador, borde, escucha de la aplicación, almacén de sesiones, API de backend. Cada salto tiene un propietario y una decisión de autenticación. Ahora repita el recorrido para la persona que aplica parches al host y para el trabajo que escribe la copia de seguridad nocturna. Esos recorridos suelen divergir ya en el primer salto.
Esa divergencia es la pregunta que merece respuesta. Una VPN de sitio solo es redundante cuando cada canal de ese segundo recorrido tiene una política de entrada y autorización que se sostiene por sí sola.
Cinco canales que el inicio de sesión de la aplicación nunca cubre
La tabla siguiente es una plantilla de inventario, no una lista de comprobación de despliegue. Rellene la segunda columna con lo que su propio entorno aplica realmente hoy.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
Compartir un proveedor de identidad no fusiona estas autorizaciones. Un usuario que puede enviar una petición de API no queda por ello autorizado a sustituir un disco de máquina virtual ni a restaurar una base de datos con las credenciales de la aplicación. El resumen de arquitectura de confianza cero de NIST mantiene la autenticación y la autorización de recursos separadas de la ubicación de red exactamente por este motivo.
Un ingeniero de soporte que puede leer un tique no queda por ello autorizado a abrir una consola en el host que hay detrás.
Una ruta solo es real si la alternativa permanece cerrada
Restringir la accesibilidad a escuchas administrativas privadas es una sustitución legítima de una VPN de sitio, siempre que la restricción se aplique y no solo se dibuje. El fallo habitual es una escucha alternativa que nadie recordaba: un servicio aún ligado a todas las interfaces, una regla de grupo de seguridad abierta para un contratista, un puerto de administración accesible desde internet.
Compruebe escuchas, no diagramas. En el host, enumere lo que está realmente ligado con ss -ltnp y confirme que los puertos administrativos están en una dirección privada. En la consola de la nube, lea las reglas de entrada de la subred de carga de trabajo y busque 0.0.0.0/0 en cualquier cosa administrativa. Después pruebe la conexión desde fuera de la ruta privada, porque esa prueba es la que responde a la pregunta.
Una sola regla abierta al mundo en SSH deshace todos los argumentos que hizo el diseño del túnel.
Escriba el mapa antes de comparar diseños
Para cada fila del inventario, anote quién aprueba las identidades, quién actualiza las reglas de acceso, quién retira las credenciales cuando alguien se marcha y quién se ocupa de la recuperación cuando la propia ruta se rompe. Cuatro nombres por fila bastan para dejar al descubierto las filas donde la respuesta es una cuenta compartida y una página de wiki de hace tres años.
Después valide un permiso y una denegación por canal. Un permiso demuestra que la identidad prevista puede llegar al recurso por la ruta prevista. Una denegación demuestra que una identidad similar no puede, y es la prueba que la gente se salta, y por eso las escuchas alternativas sobreviven a las auditorías. Compare el diseño propuesto con estos resultados, no con la configuración TLS de la aplicación, que nunca ejercitó ninguno de ellos.
Donde una VPN de sitio todavía se gana su lugar
Un túnel o una puerta estrecha es la respuesta correcta cuando un recurso no tiene autenticación propia por petición: puertos de mantenimiento de bases de datos, destinos de copias de seguridad, consolas de hipervisor, gestión fuera de banda. Esas escuchas confían en la red, así que la red tiene que ser lo que autentica al llamante.
No es la única respuesta. Una puerta que termina la autorización por recurso puede ser más estrecha que un túnel de toda la subred y deja un rastro de auditoría mejor que un host de salto compartido.
Orden de trabajo: complete el inventario, cierre las alternativas, valide una denegación por fila y solo entonces retire el túnel. Si una fila no puede producir una denegación, mantenga la ruta privada hasta que pueda.