Ainda precisa de uma VPN se usar um Identity-Aware Proxy?

A premissa é esta: assim que um proxy que conhece a identidade se coloca à frente das aplicações internas, a VPN é decoração e o cliente pode ir-se embora. Isso vale para um caso estreito, uma aplicação HTTPS interativa utilizada por uma pessoa num navegador, e falha silenciosamente em todo o resto. Um proxy autoriza um pedido contra um recurso; uma VPN admite um cliente num âmbito de rede, e essas duas fronteiras raramente coincidem. Antes de retirar um túnel, compare as operações que as suas pessoas realmente executam, não as etiquetas de produto no diagrama.

Os dois portões autorizam coisas diferentes

Um portão de aplicação decide se este pedido, desta identidade, pode alcançar este recurso protegido. A visão geral do Identity-Aware Proxy da Google descreve exatamente essa forma: uma camada central de autorização à frente de aplicações HTTPS, guiada por um papel de IAM. A fronteira é o recurso, e a unidade de acesso é o pedido. Uma VPN encaminhada faz algo mais grosseiro e amplo: admite um cliente num âmbito de rede definido, após o que a aplicação continua a decidir o que esse cliente pode fazer.

Nenhum dos modelos implica o outro. Passar o portão não diz nada sobre ler um registo específico, e estar na rede não diz nada sobre ter permissão para agir.

O que o proxy não cobre, e a VPN cobre

As sessões SSH, os clientes de bases de dados, os intermediários de mensagens e os nomes de anfitrião internos que nenhum navegador abre nunca não se tornam acessíveis só porque existe um proxy web. Cada um fala o seu próprio protocolo, e cada um precisa ou do seu próprio caminho autenticado ou de uma rede que o transporte. É a lacuna que as pessoas descobrem no primeiro dia de uma migração, normalmente através de um engenheiro de prevenção com um portátil que já não resolve um nome de anfitrião.

A lacuna inversa é igualmente real. Uma VPN que admite um cliente numa sub-rede não autentica a pessoa lá dentro, e um dispositivo comprometido nessa sub-rede herda o que a rede permitir. Se o requisito for autorização por pedido com uma identidade auditável, o encaminhamento sozinho não a consegue produzir. A maioria das organizações acaba por executar ambos, e a pergunta interessante é quais recursos cada um pode cobrir.

O fluxo do cliente decide mais do que o diagrama de arquitetura

Um início de sessão no navegador com redirecionamento e um desafio MFA ocasional é uma boa experiência para quem clica num marcador. Uma tarefa cron, uma CLI ou um agente de compilação não tem navegador e não pode responder a um pedido interativo, por isso precisa de um caminho não interativo documentado ou do túnel. A descoberta desse requisito acontece normalmente depois de o desenho ser aprovado.

Conte os clientes antes de contar as aplicações. Um painel pode servir cem pessoas; uma porta de base de dados pode bloquear uma equipa inteira.

A postura do dispositivo não é propriedade de nenhum dos portões

Instalar um cliente VPN não é uma verificação de conformidade, e um desenho baseado no navegador não é automaticamente incapaz de respeitar a política de dispositivos geridos. Ambos podem integrar-se com sinais de postura, e ambos podem ser implementados sem eles. Pergunte que aplicação existe, a quem pertence a política e o que acontece a um dispositivo que falha, em vez de inferir isso da forma do produto.

A mesma cautela aplica-se à remoção do acesso. Eliminar uma pertença a um grupo no proxy e revogar um certificado para o túnel são operações diferentes com atrasos diferentes, e uma delas costuma ser esquecida durante a saída.

Encontre os caminhos alternativos antes de retirar seja o que for

Uma origem desprotegida atrás do proxy, um segundo nome de anfitrião que o contorna, ou uma rota privada ampla que sobrou de um desenho anterior vão decidir qual portão está efetivamente em vigor. Teste uma operação permitida e uma negada através do cliente real, não da consola, e teste-as a partir de um dispositivo que nunca foi inscrito. O caso negado é o que lhe diz se o portão está a fazer alguma coisa.

Depois escreva a passagem: inscrição, atualizações, remoção de acesso e o caminho de recuperação para alguém trancado fora às 2 da manhã. Remover um pedido ou uma aplicação cliente transfere responsabilidade entre equipas; não elimina a responsabilidade.

Se está a decidir esta semana, comece por uma lista de operações em vez de uma lista de produtos, marque quais um navegador pode executar, e deixe o resto justificar o acesso de rede que sobreviver.