Dele acceso a los usuarios de VPN a un servicio, no a la subred

Un contratista necesita una aplicación web interna y nada más, y la respuesta fácil es darle un túnel hacia la subred del servidor. Eso funciona hasta el día en que la escanea. El diseño más estrecho exige más reflexión, porque la accesibilidad, el enrutamiento y el permiso de la aplicación son tres controles separados que deben coincidir.

Escriba el requisito como un servicio, no como una subred

Empiece por el host de destino, el protocolo y el puerto, y luego añada el grupo de usuarios o de dispositivos que debe llegar a él. Incluya la zona DNS privada solo si la aplicación resuelve un nombre, e incluya un proveedor de identidad solo si el flujo de inicio de sesión lo necesita. Todo lo demás es una dependencia que aún no ha justificado.

Una subred es un detalle de implementación del equipo de red, mientras que un servicio es lo que pidió el negocio y la unidad que se puede revisar y retirar.

Si la lista de dependencias supera los tres elementos, probablemente la aplicación necesita su propia conversación de diseño.

Enrute de forma estrecha, pero aplique en otro lugar

Una ruta o un selector estrecho le dice al túnel qué paquetes debe transportar; no es una política de autorización. El filtro de la puerta de enlace, el cortafuegos del host de destino y el modelo de permisos de la propia aplicación son donde se decide el acceso. Una ruta que cubre una sola dirección es un buen comienzo, y no es el control que detiene a un usuario decidido. Esa separación es lo que le permite cambiar el filtro sin rediseñar el túnel.

A la inversa, una ruta amplia con un filtro estricto puede ser legítima, pero solo si todos los implicados saben cuál de las dos hace la aplicación de la norma.

Documente explícitamente el punto de aplicación, o el siguiente cambio lo moverá por accidente.

Compruebe el origen que el servicio ve realmente

El destino ve la dirección del grupo del cliente o la dirección de la puerta de enlace, según si traduce. Las reglas del cortafuegos del host y los registros deben coincidir con el origen real. Si varios usuarios comparten un origen traducido, ninguna regla por usuario en ese host puede distinguirlos, y eso es una restricción de diseño, no un error.

Elija la traducción deliberadamente: simplifica el enrutamiento y destruye la identidad del origen, lo que importa para la auditoría y para las reglas por usuario.

Anote cuál de las dos eligió, junto a la regla que depende de ella.

La autorización de la aplicación no es opcional

Llegar a un puerto no otorga un rol. La aplicación sigue necesitando su propio inicio de sesión y sus propios permisos, porque la capa de red no puede expresar qué registros puede editar un usuario. Un servicio que confía en cualquier petición de la subred interna convierte un túnel estrecho en acceso completo para una credencial comprometida. El túnel decide quién puede abrir el socket, y la aplicación decide qué puede hacer con él.

Aquí es donde el diseño estrecho compensa dos veces, porque menos hosts accesibles significa menos lugares donde se puede explotar un error a nivel de aplicación.

Mantenga la regla de red y el rol de la aplicación en sistemas separados, y retire ambos por separado.

Demuestre tanto la ruta permitida como la denegada

Conéctese como el usuario autorizado y realice una operación representativa inofensiva, y luego pruebe un destino que debería ser inalcanzable. Un diseño que solo prueba la primera mitad no está probado, y la prueba denegada es la que demuestra el diseño. Pruebe una sesión nueva después de cada cambio de regla, y mire la ruta de retorno si llegan peticiones pero no respuestas.

No desactive los filtros de reenvío para que pase la prueba de aceptación, porque eso cambia la cosa que se está probando.

Cuando el usuario ya no necesite el servicio, retire la identidad remota y el rol de la aplicación en sus sistemas respectivos, y registre ambos. La guía de reenvío de strongSwan cubre el lado de la puerta de enlace de la ruta.