¿Todavía necesita una VPN si usa un Identity-Aware Proxy?

La suposición es esta: en cuanto un proxy que conoce la identidad se sitúa delante de las aplicaciones internas, la VPN es decoración y el cliente puede irse. Eso vale para un caso estrecho, una aplicación HTTPS interactiva que una persona usa en el navegador, y falla en silencio en todo lo demás. Un proxy autoriza una solicitud contra un recurso; una VPN admite un cliente en un ámbito de red, y esos dos límites rara vez coinciden. Antes de jubilar un túnel, compare las operaciones que su gente realiza de verdad, no las etiquetas de producto del diagrama.

Las dos puertas autorizan cosas distintas

Una puerta de aplicación decide si esta solicitud, de esta identidad, puede alcanzar este recurso protegido. La descripción general de Identity-Aware Proxy de Google describe exactamente esa forma: una capa central de autorización delante de aplicaciones HTTPS, gobernada por un rol de IAM. El límite es el recurso, y la unidad de acceso es la solicitud. Una VPN enrutada hace algo más tosco y amplio: admite un cliente en un ámbito de red definido, tras lo cual la aplicación sigue decidiendo qué puede hacer ese cliente.

Ninguno de los dos modelos implica al otro. Pasar la puerta no dice nada sobre leer un registro concreto, y estar en la red no dice nada sobre tener permiso para actuar.

Lo que el proxy no cubre y la VPN sí

Las sesiones SSH, los clientes de bases de datos, los intermediarios de mensajes y los nombres de host internos que ningún navegador abre no se vuelven accesibles porque exista un proxy web. Cada uno habla su propio protocolo, y cada uno necesita o su propia ruta autenticada o una red que lo transporte. Esa es la brecha que la gente descubre el primer día de una migración, normalmente de un ingeniero de guardia con un portátil que ya no puede resolver un nombre de host.

La brecha inversa es igual de real. Una VPN que admite un cliente en una subred no autentica a la persona dentro de ella, y un dispositivo comprometido en esa subred hereda lo que la red permita. Si el requisito es autorización por solicitud con una identidad auditable, el enrutamiento solo no puede producirla. La mayoría de las organizaciones acaba ejecutando ambas, y la pregunta interesante es a qué recursos se permite que cada una se ponga delante.

El flujo del cliente decide más que el diagrama de arquitectura

Un inicio de sesión en el navegador con redirección y un desafío MFA ocasional es una buena experiencia para quien hace clic en un marcador. Una tarea cron, una CLI o un agente de compilación no tiene navegador y no puede responder a un aviso interactivo, así que necesita una ruta no interactiva documentada o el túnel. El descubrimiento de ese requisito suele ocurrir después de aprobar el diseño.

Cuente los clientes antes de contar las aplicaciones. Un panel puede servir a cien personas; un puerto de base de datos puede bloquear a todo un equipo.

La postura del dispositivo no es propiedad de ninguna de las dos puertas

Instalar un cliente VPN no es una comprobación de cumplimiento, y un diseño basado en navegador no es automáticamente incapaz de respetar la política de dispositivos gestionados. Ambos pueden integrarse con señales de postura, y ambos pueden desplegarse sin ellas. Pregunte qué aplicación existe, quién posee la política y qué ocurre con un dispositivo que la incumple, en lugar de inferirlo de la forma del producto.

La misma precaución se aplica a la retirada del acceso. Eliminar una pertenencia a un grupo en el proxy y revocar un certificado para el túnel son operaciones distintas con retardos distintos, y una de ellas suele olvidarse durante la baja.

Encuentre las rutas alternativas antes de jubilar nada

Un origen sin proteger detrás del proxy, un segundo nombre de host que lo elude o una ruta privada amplia heredada de un diseño anterior decidirán qué puerta está realmente en vigor. Pruebe una operación permitida y una denegada a través del cliente real, no de la consola, y pruébelas desde un dispositivo que nunca se haya inscrito. El caso denegado es el que le dice si la puerta hace algo.

Luego escriba el traspaso: inscripción, actualizaciones, retirada del acceso y la ruta de recuperación para alguien bloqueado a las 2 de la madrugada. Quitar un aviso o una aplicación cliente traslada la responsabilidad entre equipos; no elimina la responsabilidad.

Si decide esta semana, empiece por una lista de operaciones en lugar de una lista de productos, marque cuáles puede realizar un navegador y deje que el resto justifique el acceso de red que sobreviva.