Conceito e mecanismo
Zero trust reduz confiança implícita baseada em localização ou propriedade. Uma VPN ou estação gerida pode contribuir para a avaliação, mas não autoriza todas as ações. Distingue identidade, postura, recurso, ação e contexto. Uma sessão autenticada por mTLS pode continuar sem permissão para o tenant pedido. O desenho precisa de pontos que apliquem decisões nos percursos reais, com registos suficientes para compreender concessões e recusas. Também precisa de comportamento de falha: indisponibilidade do decisor não deve resultar numa permissão global indefinida nem numa política improvisada durante o incidente. Define validade de decisões em cache, restrições por recurso e recuperação testada.
Aplicação guiada
Num serviço fictício em EC2, a equipa continua responsável pelo sistema operativo convidado, mesmo usando hardware gerido pela AWS. Regista quem executa patches e quem verifica resultados. Para uma intervenção curta, associa elevação de privilégio ao pedido, limita tempo e âmbito e conserva rastreabilidade. Na integração FinOps, um fornecedor que atende vários clientes pode tornar-se um confused deputy se aceitar referências a roles sem distinguir o cliente. O ExternalId deve ser único entre os seus clientes e controlado pelo fornecedor, aplicado na trust policy e no pedido correspondente. Não é uma password nem substitui permissões mínimas. O teste de aceitação deve mostrar que o cliente correto consegue aceder ao necessário e que outro contexto não consegue usar a mesma delegação.
Identidade confirmada + tenant errado = autorização ainda por satisfazer.
Armadilhas comuns
VPN como autorização geral; mTLS como acesso a tudo; ExternalId partilhado; responsabilidade cloud indiferenciada.
Tópicos relacionados: Governance, risco e exceções · Fornecedores, dados e ameaças · Resiliência e dependências de recuperação
Documenta quem decide, quem aplica e como se comporta em falha.
Referência: Zero trust architecture · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17