Aínda necesita unha VPN se usa un Identity-Aware Proxy?

A suposición é esta: en canto un proxy que coñece a identidade se sitúa diante das aplicacións internas, a VPN é decoración e o cliente pode marchar. Iso vale para un caso estreito, unha aplicación HTTPS interactiva que unha persoa usa no navegador, e falla en silencio en todo o demais. Un proxy autoriza unha solicitude contra un recurso; unha VPN admite un cliente nun ámbito de rede, e eses dous límites raramente coinciden. Antes de retirar un túnel, compare as operacións que a súa xente realiza de verdade, non as etiquetas de produto do diagrama.

As dúas portas autorizan cousas distintas

Unha porta de aplicación decide se esta solicitude, desta identidade, pode alcanzar este recurso protexido. A visión xeral de Identity-Aware Proxy de Google describe exactamente esa forma: unha capa central de autorización diante de aplicacións HTTPS, gobernada por un rol de IAM. O límite é o recurso, e a unidade de acceso é a solicitude. Unha VPN encamiñada fai algo máis groso e amplo: admite un cliente nun ámbito de rede definido, tras o cal a aplicación segue decidindo que pode facer ese cliente.

Ningún dos dous modelos implica o outro. Pasar a porta non di nada sobre ler un rexistro concreto, e estar na rede non di nada sobre ter permiso para actuar.

O que o proxy non cobre e a VPN si

As sesións SSH, os clientes de bases de datos, os intermediarios de mensaxes e os nomes de host internos que ningún navegador abre non se volven accesibles porque exista un proxy web. Cada un fala o seu propio protocolo, e cada un necesita ou a súa propia ruta autenticada ou unha rede que o transporte. Esa é a fenda que a xente descobre o primeiro día dunha migración, normalmente dun enxeñeiro de garda cun portátil que xa non pode resolver un nome de host.

A fenda inversa é igual de real. Unha VPN que admite un cliente nunha subrede non autentica a persoa dentro dela, e un dispositivo comprometido nesa subrede herda o que a rede permita. Se o requisito é autorización por solicitude cunha identidade auditable, o encamiñamento só non pode producila. A maioría das organizacións acaba executando ambas, e a pregunta interesante é a que recursos se permite que cada unha se poña diante.

O fluxo do cliente decide máis que o diagrama de arquitectura

Un inicio de sesión no navegador cunha redirección e un desafío MFA ocasional é unha boa experiencia para quen fai clic nun marcador. Unha tarefa cron, unha CLI ou un axente de compilación non ten navegador e non pode responder a un aviso interactivo, así que necesita unha ruta non interactiva documentada ou o túnel. O descubrimento dese requisito adoita ocorrer despois de aprobar o deseño.

Conte os clientes antes de contar as aplicacións. Un panel pode servir a cen persoas; un porto de base de datos pode bloquear todo un equipo.

A postura do dispositivo non é propiedade de ningunha das dúas portas

Instalar un cliente VPN non é unha comprobación de cumprimento, e un deseño baseado no navegador non é automaticamente incapaz de respectar a política de dispositivos xestionados. Ambos poden integrarse con sinais de postura, e ambos poden despregarse sen eles. Pregunte que aplicación existe, quen posúe a política e que ocorre cun dispositivo que a incumpre, en lugar de inferilo da forma do produto.

A mesma precaución se aplica á retirada do acceso. Eliminar unha pertenza a un grupo no proxy e revogar un certificado para o túnel son operacións distintas con atrasos distintos, e unha delas adoita esquecerse durante a baixa.

Atope as rutas alternativas antes de retirar nada

Unha orixe sen protexer detrás do proxy, un segundo nome de host que o evita ou unha ruta privada ampla herdada dun deseño anterior decidirán que porta está realmente en vigor. Probe unha operación permitida e unha denegada a través do cliente real, non da consola, e probeas desde un dispositivo que nunca se rexistrase. O caso denegado é o que lle di se a porta fai algo.

Despois escriba o traspaso: rexistro, actualizacións, retirada do acceso e a ruta de recuperación para alguén bloqueado ás 2 da madrugada. Quitar un aviso ou unha aplicación cliente traslada a responsabilidade entre equipos; non elimina a responsabilidade.

Se decide esta semana, comece por unha lista de operacións en lugar dunha lista de produtos, marque cales pode realizar un navegador e deixe que o resto xustifique o acceso de rede que sobreviva.