Zero Trust: Por que confiar menos é uma boa ideia

Jan 7, 2026 | Categories: Arquitetura, Segurança | Tags: Zero Trust, ZTNA, Arquitetura de segurança, Identidade, Contexto, Acesso

Passei vários anos vendendo e implementando soluções de ZTNA. Muito VMware, bastante Microsoft, algo de Fortinet. Bons produtos, sólidos, bem pensados, com boa engenharia por trás. O difícil quase nunca foi a tecnologia, foi explicar o que estávamos tentando resolver.

De vez em quando eu tinha que dar alguma palestra sobre Zero Trust, ou Arquitetura Zero Trust, ou Zero Trust Network Architecture, dependendo do público e do slide deck da vez. Se desse sorte, depois aparecia algum cliente dizendo que queria “implementar Zero Trust”, e eu perguntava entre outras coisas, que problema estava tentando resolver. Às vezes a conversa ficava interessante: acesso remoto, identidades, movimento lateral, estratégia de segurança. Bem. Outras vezes a resposta era um silêncio desconfortável, ou algo como: “quero implementar Zero Trust para estar seguro” e não muito mais que isso.

Zero Trust se tornou mais uma caixinha para marcar em apresentações de compliance ou de estratégias de cibersegurança. E os vendedores —me incluo sem culpa— muitas vezes não ajudamos. Vendemos como se fosse um appliance, com um discurso de “compra isso, implanta aquilo, integra com não sei o quê, e pronto”. Já vi quem com três meses de projeto, algumas migrações dolorosas, te promete que já tem Zero Trust. Como se fosse uma certificação que chega por e-mail.

A realidade é outra. Zero Trust não é algo que você compra. Não é um produto, é uma estratégia; uma forma de pensar o acesso, a rede e a segurança de um sistema. Uma forma bastante mais desconfiada, aliás.

O curioso é que a maioria das organizações já tem boa parte do necessário para começar. Não chamam de Zero Trust, não usam de forma coerente com essa arquitetura, mas está lá: identidades, segmentação básica, logs, controles para os dispositivos, capacidade de criptografia, todos meio adormecidos.

Este artigo não é um guia canônico nem um manual de “melhores práticas”, não há receitas universais. É mais um resumo do que fui aprendendo vendo implementações que funcionaram, e outras que ficaram pela metade. Algumas com orçamentos obscenos, algumas com tecnologia bem integrada de um único fornecedor, outras feitas com esforço, paciência e um stack tecnológico diverso. E se tenho que resumir: o sucesso quase nunca esteve em “comprar a solução correta”. O que funciona é entender tanto a arquitetura quanto o problema real, aproveitar ao máximo a tecnologia que se tem, e só então —quando faz sentido— sair para comprar algo novo.

O que é Zero Trust, Sem o Marketing?

Zero Trust se resume em três ideias: nunca confie por padrão, verifique sempre, e dê o mínimo acesso necessário. Parece óbvio quando se diz assim, mas rompe com trinta anos de design de redes.

O modelo tradicional é o do castelo e do fosso. Você constrói um perímetro forte —firewall, VPN, DMZ para expor serviços— e tudo que está dentro é território confiável. Se passou a muralha, você é um dos nossos. Segmenta com VLANs, sub-redes, algumas ACLs entre zonas, mas a premissa de fundo não muda: há um “dentro” e um “fora”, e o dentro é seguro.

O castelo e o fosso

O problema com esse modelo não é que seja ruim em si mesmo. Durante anos funcionou razoavelmente bem. O problema é que assume que existe um perímetro bem definido, que é hermético, e que os de dentro são de confiança. E as três coisas deixaram de ser verdade há tempo. Os ataques modernos geralmente não forçam a porta principal; roubam credenciais, exploram uma vulnerabilidade em um endpoint remoto, ou simplesmente esperam que alguém clique no lugar errado. E uma vez dentro, com o modelo tradicional podem se mover lateralmente sem muita resistência.

Zero Trust inverte a lógica. Não há “dentro” confiável. Cada acesso é validado: quem é o usuário, de que dispositivo se conecta, que estado de segurança tem esse dispositivo, que recurso está pedindo, e se realmente precisa acessar isso. O perímetro já não é um firewall físico em um rack; é móvel, está em cada endpoint e ao redor de cada recurso.

Isso significa deixar de pensar na “rede interna segura” e começar a pensar algo como “cada fluxo de dados é suspeito até que prove o contrário”. É desconfortável, porque te obriga a desconfiar de coisas que antes dava por certas —e a ter controles para isso—. Mas é necessário, porque na época do multi-cloud e do trabalho remoto, as ameaças já não respeitam a fronteira que você desenhou no diagrama de rede.

Os 5 Pilares

Zero Trust não é uma tecnologia única, mas um conjunto de princípios de arquitetura de redes e segurança que se apoiam em cinco pilares interdependentes. Cada um protege um aspecto distinto do fluxo de acesso, mas nenhum funciona isolado. A fortaleza está em como se integram.

Vejamos um a um o que protegem, como funcionam em linhas gerais, como interagem com os demais pilares e alguns exemplos de ferramentas que fornecem funcionalidades requeridas para cada pilar.

Os 5 pilares

Device Trust (o Dispositivo como Ator Verificável)

O que protege: Previne que dispositivos comprometidos, desatualizados ou não autorizados acessem recursos corporativos. Um usuário válido em um dispositivo não confiável ainda é um risco.

Como funciona: O dispositivo deve provar sua identidade e estado de segurança antes de permitir qualquer acesso. Isso se consegue mediante:

  • Identificação única: Certificados de máquina que funcionam como “credenciais do dispositivo”. Não é suficiente saber que “alguém” se conecta; você precisa saber de qual dispositivo específico.
  • Posture checking (verificação de estado): Antes de autorizar acesso, o sistema valida que o dispositivo cumpra requisitos mínimos: antivírus ativo, firewall habilitado, SO atualizado, sem jailbreak/root, disco criptografado, etc. Se algo falha, o acesso é negado ou restrito.
  • Inventário e registro: Somente dispositivos explicitamente autorizados podem tentar se conectar. BYOD sem registro não entra.

Integração com outros pilares:

  • Se combina com User Trust para validar não só “quem você é” mas “de onde você se conecta”. Credenciais roubadas em um dispositivo não corporativo não bastam.
  • Alimenta Application Trust: o gateway pode decidir dar acesso a apps menos críticos de qualquer dispositivo corporativo ou BYOD autorizado, mas restringir apps sensíveis apenas a dispositivos corporativos com compliance perfeito.
  • Os certificados do dispositivo são usados em Transport Trust para estabelecer conexões mTLS (mutual TLS), onde ambas as extremidades validam identidade.

Que ferramentas o implementam:

  • MDM/UEM: Intune, Workspace ONE, Jamf, FortiClient EMS
  • Certificados: PKI interna (Windows CA, OpenSSL), serviços cloud (Entra ID Certificate Authority)
  • Posture checking: Agentes de endpoint que reportam estado a um servidor central (Forticlient, WorkspaceONE, etc.)

User Trust (Identidade Humana Verificável)

O que protege: Previne acesso não autorizado baseado em credenciais roubadas, compartilhadas ou comprometidas. A autenticação de um único fator já não é suficiente.

Como funciona: A identidade do usuário deve ser validada com múltiplos fatores e, dependendo do contexto, com maior ou menor fricção.

  • Multi-factor authentication (MFA): Algo que você sabe (senha) + algo que você tem (token, app no celular) + algo que você é (biometria). O segundo fator faz com que roubar credenciais não seja suficiente.
  • Autenticação baseada em certificados: O usuário tem um certificado digital pessoal. Em combinação com senha ou MFA, isso adiciona outra camada. Além disso, os certificados podem ter vigência curta e se renovar automaticamente, reduzindo janelas de exposição.
  • Passwordless (FIDO2, WebAuthn, Windows Hello): A evolução lógica de MFA é eliminar a senha completamente. Com FIDO2, o usuário autentica com biometria (impressão digital, facial) ou PIN local, e o dispositivo assina um desafio criptográfico que valida identidade sem enviar segredos pela rede. Não há senha para roubar, fazer phishing ou reutilizar. É mais seguro e mais cômodo que MFA tradicional. Windows Hello for Business, passkeys em iOS/Android, e tokens de hardware como YubiKey implementam esse padrão.
  • Autenticação contextual/adaptativa: Você nem sempre pede a mesma coisa. Se o usuário se conecta de seu dispositivo habitual, em horário comercial, do escritório, talvez baste passwordless. Se se conecta de um país novo, às 3 da manhã, de um dispositivo desconhecido, você exige passwordless + validação adicional de identidade (notificação push com confirmação explícita, pergunta de segurança).
  • Single Sign-On (SSO): Você autentica uma vez (com MFA), e esse token de identidade te dá acesso a múltiplas aplicações sem voltar a pedir credenciais. Isso reduz fricção sem sacrificar segurança, sempre que o fluxo de autenticação inicial seja robusto.

Integração com outros pilares:

  • Device Trust + User Trust = contexto completo. Você não só sabe quem é, mas de onde se conecta.
  • Application Trust: As políticas de acesso podem ser por usuário E por grupo. “A equipe de Finanças pode acessar o ERP, mas só se estiverem autenticados com MFA e de dispositivos corporativos.”
  • Transport Trust: O token de identidade (SAML assertion, JWT) é validado em cada solicitação. Se o token expira ou é invalidado (usuário desabilitado, mudança de permissões), o acesso é cortado.

Que ferramentas o implementam:

  • Diretórios: Active Directory, Entra ID, Okta, Google Workspace, WorkspaceONE
  • MFA: MFA do Entra ID, Duo, Google Authenticator, FortiToken, WorkspaceONE Verify, tokens de hardware (YubiKey)
  • SSO/Federation: SAML, OIDC, serviços como Okta, Entra ID, Workspace ONE Access

Transport/Session Trust (Comunicação Verificada Continuamente)

O que protege: Previne ataques de man-in-the-middle, sequestro de sessão, e movimento lateral depois de uma autenticação inicial bem-sucedida.

Como funciona: Não basta autenticar no início e confiar na sessão por horas. O transporte deve estar criptografado e a sessão deve ser revalidada constantemente.

  • Criptografia robusta obrigatória (TLS 1.2+): Todo o tráfego entre usuário e aplicação deve ir criptografado. Nada em texto plano, nem mesmo na rede interna. Configurar corretamente cipher suites, desabilitar versões antigas de TLS, validar certificados.
  • Mutual TLS (mTLS): Não só o servidor apresenta certificado; o cliente também. Isso assegura que ambas as extremidades da conexão são quem dizem ser. Comum em arquiteturas de microsserviços e comunicação entre sistemas.
  • Tempos de sessão curtos: Uma sessão autenticada não deve durar indefinidamente. Configurar TTL (time to live) razoável: 4-8 horas para usuários comuns, menos para acessos administrativos. Isso limita a janela de exploração se alguém rouba um token de sessão.
  • Revalidação contínua: Durante a sessão, validar periodicamente que o usuário e o dispositivo continuam cumprindo as políticas. Se o dispositivo deixa de cumprir compliance (antivírus se desliga, usuário desabilitado no AD), a sessão termina mesmo que não tenha expirado o token.
  • Micro-segmentação: Controlar o tráfego entre recursos internos (east-west traffic), não só o tráfego de entrada/saída (north-south). Cada VM, contêiner ou workload tem seu próprio perímetro de rede. As regras de firewall se aplicam por identidade (usuário, grupo AD, workload identity), não só por IP. Isso previne movimento lateral: se um atacante compromete um servidor web, não pode falar diretamente com o banco de dados a menos que exista uma regra explícita que o permita. As políticas “viajam” com a carga de trabalho se ela se move de host ou datacenter.

Integração com outros pilares:

  • Device Trust + User Trust: Os certificados de dispositivo e usuário são usados para estabelecer mTLS. Sem eles, não há conexão. Em micro-segmentação com identity-based firewalls, esses mesmos certificados ou o contexto de autenticação permitem que o firewall distribuído saiba “esse tráfego vem do usuário X no grupo Y” e aplique regras por identidade em vez de só por IP de origem/destino.
  • Application Trust: O gateway que publica a aplicação valida o token de sessão em cada request. Se o token é inválido ou expirou, rejeita a conexão.
  • Data Trust: A criptografia do transporte protege os dados enquanto viajam pela rede. Mesmo que alguém intercepte o tráfego, não pode lê-lo.

Que ferramentas o implementam:

  • Proxies reversos: nginx, HAProxy, Traefik (com configuração TLS/mTLS)
  • Gateways ZTNA: FortiGate ZTNA, Zscaler, Cloudflare Access, Palo Alto Prisma
  • Micro-segmentação: VMware NSX, Cisco ACI, Illumio, Calico (em Kubernetes)
  • Session management: Gerenciado por IdP (Entra ID, Okta) com políticas de conditional access

Application Trust (Acesso Granular e Princípio de Mínimo Privilégio)

O que protege: Previne movimento lateral. Se um atacante compromete uma conta, não deve poder acessar tudo, só o estritamente necessário para essa conta.

Como funciona: Cada aplicação ou recurso deve ter políticas de acesso explícitas. Não “se está na rede, pode acessar tudo”, mas “você tem acesso só ao que precisa para seu papel”.

  • Publicação seletiva de aplicações: Em vez de dar acesso VPN a toda a rede, você publica aplicações individualmente. O usuário se conecta a “app.empresa.com”, não a “toda a sub-rede 10.x.x.x”.
  • Políticas de acesso baseadas em identidade e contexto: Não basta com “o usuário X pode acessar”. É “o usuário X, de um dispositivo corporativo, com MFA, pode acessar o app Y entre 8h e 18h, destas localizações geográficas”.
  • Application-level gateways: Um proxy ou gateway na frente de cada aplicação valida identidade, device compliance, e permissões antes de deixar passar tráfego. Se algo falha, o tráfego não chega ao backend.

Integração com outros pilares:

  • User Trust + Device Trust: O gateway valida ambos antes de permitir acesso. Usuário válido + dispositivo não corporativo = acesso negado.
  • Transport Trust: A conexão entre usuário e gateway está criptografada, e o gateway re-valida tokens de sessão constantemente. Graças à micro-segmentação, a nível de rede o trânsito também está restrito; se um atacante evade o Gateway igualmente não pode estabelecer comunicação com um workload não autorizado.
  • Data Trust: Ao limitar que aplicações cada usuário pode usar, você limita também que dados pode tocar. Se não pode acessar o ERP, não pode ver a informação financeira que vive ali.

Que ferramentas o implementam:

  • ZTNA gateways: FortiGate ZTNA, Zscaler Private Access, Cloudflare Access
  • Proxies reversos: nginx, HAProxy com autenticação integrada
  • Identity-based firewalls: Palo Alto, FortiGate com integração AD, Azure Firewall com user identity, VMware NSX com Identity Firewall

Data Trust (Proteger a Informação, Não Só o Perímetro)

O que protege: Os dados em si, independentemente de onde estejam. Não importa se um atacante chega até o storage; se os dados estão criptografados e não tem as chaves, não lhe serve.

Como funciona: A informação deve estar protegida em repouso e em trânsito, classificada segundo criticidade, e com controles granulares sobre quem pode fazer o quê com ela.

  • Criptografia em repouso: Discos criptografados em endpoints (BitLocker, FileVault), storage criptografado em servidores, bancos de dados com TDE (Transparent Data Encryption). Se alguém rouba um disco físico ou faz snapshot de uma VM, não pode ler a informação.
  • Criptografia em trânsito: Já coberto em Transport Trust, mas vale remarcar: os dados nunca viajam em claro.
  • Classificação de informação: Nem todos os dados são iguais. Público, interno, confidencial, restrito. Cada nível tem controles diferentes. Isso implica processo (treinar usuários em como classificar) e tecnologia (metadados em arquivos, tags em objetos de storage).
  • Permissões granulares: Princípio de mínimo privilégio em file shares, bancos de dados, APIs. Não “Everyone: Full Control”. É “o grupo Finanças tem read/write nesta pasta, o resto não a vê”.
  • Data Loss Prevention (DLP): Monitorar e bloquear tentativas de exfiltração. Se alguém tenta copiar 10.000 registros de clientes para um USB ou subir para Dropbox pessoal, o sistema detecta e bloqueia.
  • Auditabilidade: Logs de quem acessou o quê, quando, de onde. Se há um incidente, poder reconstruir o que aconteceu.

Integração com outros pilares:

  • Application Trust: As políticas de acesso limitam que aplicações cada usuário pode usar, o que indiretamente limita que dados pode tocar.
  • User Trust + Device Trust: Só usuários autenticados de dispositivos verificados podem descriptografar informação. As chaves de criptografia podem estar atadas a certificados de usuário/dispositivo.
  • Transport Trust: A criptografia do transporte assegura que os dados não sejam interceptados enquanto viajam. A criptografia em repouso assegura que se alguém os rouba mesmo assim não pode lê-los.

Que ferramentas o implementam:

  • Criptografia de disco: BitLocker, FileVault, LUKS
  • Criptografia de armazenamento: AWS KMS, Azure Key Vault, soluções on-prem com encrypted volumes
  • DLP: Microsoft Purview, Symantec DLP, Forcepoint, soluções open source (MyDLP, OpenDLP)
  • Classificação: Microsoft Information Protection, Boldon James, etiquetas manuais + processo
  • Auditoria: SIEM (Splunk, QRadar, Wazuh), logs nativos de sistemas (Windows Event Log, syslog)

Como se Integram os Pilares

Em uma implementação real de Zero Trust, os pilares não “se executam” um depois do outro como uma checklist. Se sobrepõem, se alimentam e se corrigem entre si. Cada acesso é uma decisão baseada no contexto completo.

Tomemos como exemplo um caso concreto: María entra em erp.empresa.com.

Mesmo Usuário, Contexto Confiável

María está em horário comercial, de seu laptop corporativo, no escritório. O navegador já tem uma sessão ativa.

O sistema avalia identidade (User Trust) e contexto: usuário conhecido, dispositivo habitual, localização esperável. Não pede MFA adicional. Não porque “confia”, mas porque o risco é baixo e o custo de fricção não aporta segurança real.

O dispositivo apresenta seu certificado (Device Trust). É válido, emitido pela CA corporativa, o equipamento está atualizado e em compliance. Isso habilita o próximo passo.

A conexão se estabelece criptografada, com mTLS (Transport Trust). O gateway e o dispositivo se validam mutuamente. A nível de rede, a micro-segmentação permite esse fluxo específico: María → gateway ERP. Nada mais.

Com todo esse contexto, o gateway avalia políticas (Application Trust): María pertence a Finanças, está em um contexto permitido, acessa só o ERP. Não vê outras aplicações internas, mesmo que estejam “na mesma rede”.

Dentro do ERP, as permissões são as de seu papel (Data Trust). Pode consultar e carregar informação, mas não exportar massivamente dados sensíveis. Tudo fica auditado.

Acesso concedido. Sem fricção desnecessária. Segurança suficiente para o risco real.

Mesmo Usuário, Contexto Intermediário

María precisa entrar no ERP de sua casa, fora do horário, porque lhe pediram para fechar algo urgente.

A identidade é válida (User Trust), mas o contexto já não é o ideal: localização diferente, rede doméstica, horário atípico. O sistema não bloqueia, mas sobe o nível de exigência. Se pede MFA explícito, mesmo que normalmente não se pediria, e a sessão tem um TTL mais curto.

O dispositivo passa validação (Device Trust), mas com restrições. É seu laptop corporativo, está em compliance, tem certificados válidos, mas o acesso fica marcado como “risco médio”. Isso alimenta o resto das decisões.

A conexão se estabelece criptografada com mTLS (Transport Trust), mas a micro-segmentação é mais estrita: só se habilita o fluxo exato para o ERP. Nada de serviços auxiliares.

No gateway, as políticas de acesso (Application Trust) permitem o ERP, mas em modo restrito. María pode consultar informação e completar a tarefa pontual, mas certas ações ficam bloqueadas: exportações massivas, mudanças estruturais, acessos administrativos.

Os dados seguem protegidos (Data Trust): qualquer tentativa de copiar informação sensível fora dos canais permitidos se registra ou se bloqueia automaticamente. Tudo fica auditado, com mais detalhe que em um acesso normal.

O acesso existe, mas não é igual ao acesso ideal. É suficiente para resolver o problema, sem abrir mais superfície de ataque do que o necessário.

Mesmo Usuário, Contexto Pouco Confiável

Agora mudemos só o contexto: María tenta acessar erp.empresa.com num sábado de madrugada, de um país onde nunca esteve, usando um equipamento pessoal.

A identidade continua sendo válida (User Trust), mas o contexto não. O sistema exige MFA forte, e ainda assim o dispositivo não passa validação (Device Trust): não está registrado, não há certificado de máquina, não há posture conhecido.

O acesso se bloqueia antes de que a aplicação sequer entre em jogo. Não importa que a senha seja correta. Não importa que o usuário seja “de confiança”. O contexto não é.

E mesmo que alguém conseguisse passar essa etapa, a rede também não ajuda: dessa localização e segmento, o tráfego nem mesmo chega ao gateway (Transport Trust).

Resultado: acesso negado. Sem discussão.

O Importante Não é o Fluxo, é a Decisão

Zero Trust não trata de fazer mais passos, mas de tomar melhores decisões com o contexto completo:

  • O User Trust diz quem é.
  • O Device Trust diz de onde.
  • O Transport Trust assegura que a conversa é legítima e controlada.
  • O Application Trust limita ao que pode acessar.
  • O Data Trust define o que pode fazer com a informação.

Quando tudo isso se integra bem, acontecem duas coisas interessantes:

  • Em contextos saudáveis, a experiência é simples.
  • Em contextos estranhos, o sistema restringe possíveis comprometimentos.

Não é mágica, nem é automático implementá-lo, nem é grátis em complexidade. Mas quando funciona permite fluxos de trabalho com pouca fricção e uma postura de segurança elevada.

As Bases: Visibilidade e Analítica, Automação e Orquestração, Governança

Os cinco pilares são os componentes visíveis de Zero Trust, mas para que funcionem são necessárias três capacidades transversais. Não são pilares em si mesmos, mas são requisitos que permitem que todo o resto opere.

Visibilidade e analítica: Você não pode proteger o que não vê. Zero Trust requer visibilidade completa do tráfego (quem acessa o quê, de onde, quando), do estado dos dispositivos, das identidades ativas, e dos dados sensíveis. Mas visibilidade sem contexto é ruído; se necessita a capacidade de correlacionar eventos: “esse usuário se autenticou de três países diferentes em 10 minutos” não é um dado isolado, é um indicador de comprometimento. Ferramentas como SIEM (Splunk, Microsoft Sentinel, Wazuh), plataformas XDR (Microsoft Defender XDR, SentinelOne Singularity), ou soluções específicas de cada vendor (Omnissa Intelligence, FortiAnalyzer) consolidam logs e geram alertas acionáveis.

Automação e orquestração: Validar manualmente cada acesso, revisar compliance de cada dispositivo, ajustar regras de firewall quando muda um usuário de papel, não são ações escaláveis. Zero Trust necessita automação: provisioning/deprovisioning automático de acessos (identity governance), remediação automática quando um dispositivo perde compliance (forçar atualização de antivírus, revogar certificado), resposta automática a incidentes (isolar dispositivo comprometido, terminar sessões ativas do usuário afetado). SOAR (Security Orchestration, Automation and Response) como Cortex XSOAR, FortiSOAR, ou capacidades nativas de plataformas UEM/XDR tornam isso possível. Sem automação, a sobrecarga operacional impede implementar Zero Trust completo.

Governança: Alguém tem que decidir quem pode acessar o quê, sob que condições, e quem é responsável por manter essas políticas atualizadas. Governança inclui: gestão do ciclo de vida de identidades (onboarding, mudanças de papel, offboarding), revisão periódica de acessos (esse usuário ainda precisa de acesso a esse sistema?), políticas documentadas e auditáveis, e separação de funções (quem aprova acessos não é quem os configura tecnicamente). Ferramentas de Identity Governance and Administration (IGA) como Entra ID Governance ou Okta Identity Governance, ou processos bem definidos com workflows em sistemas como ServiceNow ou Jira, são parte disso. Sem governança, Zero Trust se degrada: permissões órfãs, usuários com mais acesso do que o necessário, políticas que ninguém mantém.

Conclusão: Zero Trust é Arquitetura, Não Checklist

Zero Trust não é um estado binário que você alcança e pronto. É um modelo de arquitetura que você aplica gradualmente, priorizando onde mais importa. A mudança fundamental não está em poder marcar todos os itens de uma checklist, mas em como você pensa o design de acesso: nunca confiar por padrão, verificar sempre, dar o mínimo privilégio necessário.

Os cinco pilares —Device Trust, User Trust, Transport Trust, Application Trust, Data Trust— funcionam juntos. Nenhum é suficiente em si mesmo. E sem as bases de visibilidade, automação e governança, não importa que ferramentas você tenha, não vai poder sustentá-lo no tempo.

Isso não soluciona tudo. Ainda existem aplicações legacy que não entendem autenticação moderna e para as quais devemos ser criativos e ainda assim não conseguiremos integrá-las 100%. Também ainda existem usuários que encontram formas criativas de quebrar as regras. E ainda existe o risco de que alguém roube credenciais + dispositivo + certificado, embora seja mais difícil. Zero Trust reduz a janela de oportunidade para um atacante, mas não a fecha completamente. Quem te prometer o contrário está te vendendo algo impossível.

Por último: se depois de ler isso você fica pensando “ok, entendo o conceito, mas como começo?”, na segunda parte deste artigo falo da implementação concreta: como avaliar seu stack atual, o que você pode fazer sem comprar nada, e quando sim precisa de orçamento. Porque entender a arquitetura é o primeiro passo. O seguinte é começar a aplicá-la.

Referências