Mover una aplicación web de empresa detrás de la VPN: guía del corte

Imagine el cambio desde el lado del usuario. Alguien hace clic en un marcador, espera la página de inicio de sesión de siempre y, en cambio, recibe un error de conexión porque el nombre de host ahora solo responde dentro del túnel. Ese único momento contiene todo lo que el plan de migración debe acertar: el nombre, la ruta, el certificado, la cuenta y la operación que hay detrás. Recorra los pasos siguientes en ese orden y el corte deja de ser un salto.

Paso 1: anote lo que los usuarios hacen hoy

Empiece por el nombre de host en la barra de direcciones, el puerto, las operaciones que realiza la gente y las cuentas que utiliza. Si no puede nombrar las tres operaciones principales, no está listo para cerrar la entrada pública, porque no reconocerá una rota durante la aceptación.

Después decida quién es el público privado. Los empleados en la VPN corporativa son un comienzo, no una respuesta. Los contratistas, el personal de soporte y el equipo financiero pueden necesitar todos la aplicación y puede que no todos estén detrás de la misma puerta de enlace.

Paso 2: separe el túnel del inicio de sesión

Cuando el usuario llega a la aplicación a través de la VPN, el navegador sigue abriendo una conexión TLS al punto final propio de la aplicación. El certificado debe coincidir con ese nombre, y la aplicación sigue autenticando la cuenta. Nada del túnel sustituye a ninguno de los dos.

Aquí es donde las migraciones fallan en silencio. Alguien decide que la dirección privada ya no necesita un certificado válido, los usuarios aprenden a hacer clic a través de una advertencia, y la organización ha cambiado una exposición pública por un programa de formación en ignorar avisos de seguridad. Si la aplicación necesita de verdad un certificado interno, emita uno de la autoridad interna y distribuya la confianza correctamente. Eso es un cambio controlado; una página de advertencia no lo es.

Mantenga la autorización donde ya vive. El resumen de la arquitectura de confianza cero de NIST lo dice directamente: la ubicación en la red no es motivo para conceder una operación sensible. Estar dentro del túnel no debería convertir una cuenta de solo lectura en administrador.

Paso 3: encuentre a los llamadores que no son empleados

Abra la configuración de la aplicación y enumere todo lo que habla con ella: la URL de retorno del proveedor de identidad, el webhook de un proveedor de pagos, una importación programada, una sonda de monitorización, el cliente API de un socio. Cada uno es una dependencia con un propietario, y cada uno fallará en un momento distinto.

Decida una ruta soportada para cada uno que deba permanecer. Un proveedor de webhook no puede unirse a su VPN de empleados, así que o expone un punto final de integración de alcance estrecho con su propia autenticación, o cambia el modelo de integración. Dejar toda la aplicación pública porque existe una devolución de llamada es una elección, y normalmente la incorrecta.

Anote cada excepción con destino, operación permitida, autenticación y propietario. Una cuenta VPN genérica entregada a una integración es como una excepción se vuelve permanente. Revise la lista en la siguiente revisión de accesos, porque las integraciones sobreviven a los proyectos que las añadieron. Una excepción sin fecha de caducidad es una decisión de diseño permanente que nadie tomó.

Paso 4: retire la ruta pública, no solo el registro DNS

Recorra la cadena de publicación: DNS, receptores del balanceador de carga, reglas del proxy inverso, cortafuegos del host y cualquier nombre alternativo que todavía apunte a la dirección antigua. Compruebe ambas familias de direcciones. Cambiar el registro A principal no demuestra casi nada si un CNAME más antiguo o un receptor IPv6 sigue sirviendo la aplicación.

En paralelo, confirme que el nombre privado se resuelve dentro del túnel y que el certificado cubre el nombre que los usuarios escribirán. Un usuario que tiene que pegar una dirección numérica ha encontrado un síntoma, no una solución.

Limite el público de la VPN a la ruta de la aplicación. El acceso amplio a la red de oficina cambia una decisión de exposición por otra mayor, y las interfaces administrativas necesitan sus propias fuentes permitidas en lugar de heredar la regla de usuario.

Paso 5: recorra la aceptación usted mismo

Conéctese como usuario aprobado, abra el marcador, compruebe el certificado, inicie sesión y realice una operación real. Luego pruebe una cuenta que no debería tener esa operación y confirme que se le deniega. Después pruebe desde un dispositivo fuera de la VPN y confirme que la aplicación es inalcanzable.

Repita para cada integración retenida, y lea el registro de entrega del proveedor en lugar de suponer que un 200 de su propia herramienta de pruebas es lo mismo. Un inicio de sesión VPN correcto no es evidencia de ninguno de estos resultados.

Paso 6: ensaye el mal día

Decida qué ocurre durante una caída del túnel: el trabajo se detiene o toma el relevo otro método de acceso aprobado. Elija lo que elija, anótelo y pruébelo una vez, porque la reapertura pública de emergencia como mecanismo de recuperación no documentado acabará ejecutándola alguien bajo presión.

Mantenga el acceso de recuperación para los administradores que mantienen la puerta de enlace y la aplicación, con un propietario y una fecha de retirada. Registre el cambio y sus condiciones de reversión en el mismo lugar, para que una migración fallida no deje fuera a las personas que la repararían.

Después del corte, el parcheo, el ciclo de vida de las cuentas, la autorización de la aplicación y la auditoría siguen siendo suyos. El túnel estrechó la entrada; no asumió ninguna de esas tareas.