Zero Trust, VPN e inspeção TLS fazem trabalhos diferentes

Os documentos de compras tratam zero trust, VPN e inspeção TLS como se fosse a mesma compra, e cada um responde a uma pergunta que os outros não conseguem. Um túnel constrói um caminho protegido, um gateway de inspeção lê o tráfego que consegue terminar, e uma política decide se uma identidade nomeada pode executar uma operação nomeada sobre um recurso nomeado. Só a última é uma decisão de autorização. Um produto pode fazer as duas primeiras na perfeição e ainda deixar a verdadeira pergunta em aberto.

Três mecanismos, três perguntas

O túnel responde a como o tráfego chega à rede. Um gateway de inspeção responde ao que um elemento intermédio pode ver e fazer onde está autorizado a terminar TLS. Um motor de políticas responde a quem pode fazer o quê a que recurso, e depois precisa de um ponto de aplicação capaz de aplicar essa resposta. A arquitetura zero trust do NIST coloca o recurso no centro e recusa inferir confiança de onde veio um pacote.

Esse enquadramento é mais difícil de satisfazer do que um rótulo, e muito mais difícil de falsificar numa revisão. Também desloca a pergunta de que produtos estão implementados para que decisões são aplicadas e por quem.

Onde a decisão é realmente aplicada

Considere um pedido: um engenheiro de suporte abre uma consola de serviço, e uma máquina pessoal ligada ao mesmo comutador não deve herdar essa permissão só por estar perto. Anote a operação permitida, as condições do dispositivo e o componente que as aplica. A localização decide tudo: um gateway de aplicação, um proxy de serviço, um controlo de anfitrião ou outra fronteira que a organização realmente suporte. Seja qual for esse componente, tem de estar no caminho das tentativas remotas e das locais.

O tráfego que nunca atravessa a entrada da VPN não é regido por uma verificação feita ali, por mais minuciosa que seja. É essa única lacuna que explica a maior parte da distância entre um diagrama zero trust e uma implementação que funciona. Desenhe o caminho do pedido antes de desenhar a arquitetura.

A desencriptação não é autorização

A interceção serve objetivos de inspeção estreitos e carrega o seu próprio fardo de certificados, raízes fidedignas, revisão de privacidade e aplicações que se quebram por baixo. Nada disso é o que significa zero trust, e nada disso substitui uma decisão de política. Autenticar uma pessoa e autorizar um serviço é perfeitamente possível sem desencriptar um único pacote. Um fluxo desencriptado não diz nada sobre se o utilizador tinha direito à operação que transporta.

A política precisa de um tipo de prova, e a desencriptação não é isso. A saúde do dispositivo é uma entrada entre identidade, sensibilidade do recurso e contexto, e passá-la uma vez não entrega a essa máquina o resto da rede. Misturar as duas transforma uma pergunta de autorização num projeto de certificados.

Quando o gateway não está em lado nenhum do caminho

Inventarie o que viaja sem tocar no gateway remoto: ligações entre máquinas no segmento local, chamadas de uma carga de trabalho para outra e pontos finais alcançados diretamente dentro de uma conta cloud. Para cada caminho, nomeie um método de aplicação que possa realmente ser implementado hoje. Equipamento que não consegue alojar um agente continua a precisar de outro controlo explicitamente suportado, e assumir que o agente chegará mais tarde não fecha nada agora. O acesso de serviço a serviço costuma adequar-se melhor à identidade da carga de trabalho e a uma verificação escrita contra o recurso do que a outra rede sobreposta.

Aceite o desenho pelo comportamento e não pelos diagramas: que operações são permitidas, quais são negadas e onde cada resposta é aplicada. Aprove operações específicas permitidas e negadas, e inclua uma rota local que nunca chegue ao gateway. Registe quem é dono da política, como muda e como funciona a revogação.

Um túnel renomeado continua a ser um túnel. Uma política decide, e algo tem de a aplicar.