O que é Zero Trust?

O modelo Zero Trust substitui a confiança baseada na localização pela verificação contínua. Enquanto o modelo de perímetro considerava, por padrão, tudo o que estivesse dentro da rede como confiável, o modelo Zero Trust avalia cada solicitação como se ela tivesse se originado de um local não confiável, independentemente de onde ela realmente tenha vindo ou do que tenha sido concedido ao mesmo usuário uma hora antes.

Três conceitos definem o modelo na prática:

• Sem confiança implícita. A posição na rede, por si só, não garante nada, e o fato de uma solicitação estar dentro do firewall não é prova de que ela seja legítima.
• Verificação contínua. A confiança é avaliada a cada solicitação, em vez de ser estabelecida uma única vez no momento do login e mantida durante toda a sessão.
• Privilégio mínimo. O acesso é limitado ao que uma solicitação específica exige e não vai além disso.

O Zero Trust não é um produto que as organizações possam adquirir. Trata-se de uma estratégia que abrange identidade, dispositivos, redes, aplicativos e dados, e não de uma tecnologia restrita a qualquer uma dessas camadas. Os fornecedores que a apresentam como um produto geralmente estão se referindo a um único componente da arquitetura.

O próprio termo remonta a 1994, quando Stephen Paul Marsh o utilizou em uma tese de doutorado sobre confiança computacional na Universidade de Stirling. Ele ganhou destaque no cenário de segurança em 2010, quando o analista da Forrester, John Kindervag, publicou “No More Chewy Centers: Introducing the Zero Trust Model of Information Security” e defendeu que a confiança em si era uma vulnerabilidade. O projeto BeyondCorp do Google, iniciado em 2009, foi uma das primeiras implementações em grande escala.

A norma NIST SP 800-207 define sete princípios que qualquer arquitetura de confiança zero deve cumprir.

1. Todas as fontes de dados e serviços de computação são recursos. Bancos de dados, aplicativos, serviços SaaS, dispositivos de IoT e estações de trabalho dos usuários — todos exigem proteção, sem que sejam concedidas isenções com base na localização ou na importância percebida.
2. Todas as comunicações são protegidas, independentemente da localização da rede. O tráfego que atravessa a rede interna é autenticado e criptografado de acordo com o mesmo padrão utilizado para o tráfego proveniente da internet pública.
3. O acesso é concedido por sessão. A confiança é avaliada para a sessão em questão e não se estende a outras sessões; portanto, o acesso a um recurso não implica, de forma alguma, o acesso a outro.
4. O acesso é determinado por uma política dinâmica. As decisões levam em conta a identidade do cliente, o estado da aplicação, a postura dos ativos e os atributos comportamentais e ambientais, em vez de se basearem em um conjunto estático de regras.
5. A empresa monitora a situação de segurança de todos os ativos. Nenhum ativo é considerado confiável por padrão, e a integridade do dispositivo é avaliada continuamente para que esse fator possa ser levado em conta nas decisões de acesso.
6. A autenticação e a autorização são dinâmicas e rigorosamente aplicadas antes do acesso. A verificação funciona como um ciclo contínuo de concessão, análise, adaptação e reavaliação, e não como uma única etapa no início de uma sessão.
7. A empresa coleta o máximo de informações possível e as utiliza para melhorar sua postura. Os dados de telemetria coletados dos ativos, da infraestrutura e dos canais de comunicação são utilizados para ajustar as políticas que regem o acesso.

Também circula amplamente uma estrutura mais concisa, dividida em três partes: verificar explicitamente, presumir violação, aplicar o princípio do privilégio mínimo. Essa formulação tem origem no Microsoft e funciona razoavelmente bem como resumo, mas não é o que a norma SP 800-207 realmente especifica; portanto, as organizações que estão se alinhando às diretrizes do NIST devem seguir os sete princípios acima.

Cada solicitação de acesso é interceptada e avaliada em tempo real, seguindo uma sequência que permanece consistente, independentemente de quem tenha desenvolvido a pilha de tecnologia subjacente:

1. Um interessado solicita acesso a um recurso, sendo que esse sujeito pode ser uma pessoa, uma conta de serviço, uma carga de trabalho ou um agente de IA.
2. Os sinais são coletados, incluindo identidade, estado do dispositivo, localização, hora, comportamento anterior e informações sobre ameaças.
3. Um mecanismo de políticas avalia a solicitação em desacordo com a política da organização e com uma pontuação de risco calculada.
4. Uma decisão é proferida e executada, concedendo acesso, negando-o ou reforçando-o com um fator de autenticação adicional.
5. A sessão está sendo monitorada, de modo que mudanças no risco desencadeiem uma reavaliação e o acesso possa ser revogado enquanto a sessão ainda estiver aberta.

Essa etapa final é o que distingue o Zero Trust dos modelos que o precederam, já que a segurança de perímetro toma uma decisão na fronteira e depois arca com as consequências, enquanto o Zero Trust continua avaliando enquanto a sessão durar.

A maneira mais clara de entender a diferença é que uma VPN amplia o perímetro, enquanto o modelo Zero Trust elimina completamente o perímetro.

Quando um usuário se conecta por meio de uma VPN tradicional, ele é colocado na rede corporativa e passa a ter amplo acesso em nível de rede com base em uma única verificação realizada no momento da conexão. Tudo o que for acessível a partir dessa posição na rede fica ao alcance desse usuário e de qualquer pessoa que consiga roubar suas credenciais.

O modelo Zero Trust concede acesso a recursos específicos, e não a redes; portanto, a autorização para acessar um aplicativo não se estende a outros recursos. Cada solicitação é reavaliada com base nas condições de risco atuais.

A Publicação Especial 800-207 do NIST, publicada em agosto de 2020, é a arquitetura de referência na qual a maioria das organizações se baseia. Ela estabelece uma distinção clara entre os componentes que tomam e aplicam decisões de acesso e as fontes de dados que servem de base para essas decisões.

Três componentes lógicos principais

Mecanismo de Políticas (PE). Toma a decisão de acesso avaliando a política da empresa em relação aos dados descritos abaixo, aplicando um algoritmo de confiança e, em seguida, concedendo, negando ou revogando o acesso.

Administrador de Apólices (PA). Executa essa decisão abrindo ou fechando o caminho de comunicação e emitindo a credencial ou o token que o sujeito utiliza para acessar o recurso. Juntos, o PE e o PA formam o que o NIST denomina de ponto de decisão de política.

Ponto de Aplicação de Políticas (PEP). Ativa, monitora e encerra a conexão entre o sujeito e o recurso, inserindo-se no caminho da solicitação e aplicando o que for determinado pelo ponto de decisão da política.

Fontes de dados que alimentam o mecanismo de políticas

Os itens a seguir fornecem os sinais que o mecanismo de políticas avalia, sem tomar decisões por conta própria:

• Sistema de gerenciamento de identidades. Contas, registros de identidade, funções, atributos e direitos.
• Políticas de acesso aos dados. As regras que definem quem pode acessar quais recursos e em que condições.
• Diagnóstico contínuo e medidas de mitigação. Inventário de ativos e estado dos dispositivos.
• Informações sobre ameaças. Indicadores internos e externos de ataques e vulnerabilidades recém-descobertos.
• Registros de atividades e SIEM. Telemetria agregada utilizada para aprimorar a política ao longo do tempo.
• Sistemas de conformidade do setor. Requisitos regulatórios que a empresa é obrigada a cumprir.
• PKI. Emissão e validação de certificados para entidades e recursos.

As equipes frequentemente confundem essa distinção durante a implementação, tratando um sistema de identidade ou um feed de ameaças como se ele estivesse tomando decisões de acesso, quando, no modelo do NIST, esses sistemas apenas fornecem informações ao mecanismo de políticas que, na verdade, toma as decisões. Essa distinção é fundamental ao avaliar quais partes da arquitetura um fornecedor realmente abrange.

Como conceito, o Zero Trust é bastante simples: não confie em ninguém nem aprove nenhuma ação até que você tenha validado a pessoa e autorizado a solicitação. É na implementação que a maioria das organizações fica paralisada, pois o Zero Trust abrange identidade, rede, terminais, aplicativos e dados simultaneamente, e poucas equipes de segurança têm orçamento ou capital político para lidar com todos os cinco aspectos de uma só vez. Isso levanta a questão prática de por onde começar, e a resposta é quase sempre a identidade.

Toda decisão no modelo Zero Trust se resume a uma única questão: se esse usuário é quem afirma ser e se ele deve ter esse acesso neste momento. A segmentação e a criptografia não conseguem responder a essa pergunta, e a postura do dispositivo restringe a questão sem resolvê-la, o que deixa a identidade como o único controle capaz de resolvê-la. Quando a identidade é fraca, todos os controles posteriores estão aplicando fielmente uma decisão baseada em uma premissa não verificada.

A identidade assume o peso em três aspectos:

• Autenticação. Verificando o assunto por meio de métodos resistentes ao phishing em vez de segredos compartilhados que podem ser roubados, reproduzidos ou alvo de engenharia social.
• Autorização. Determinar a que um sujeito verificado tem direito, com base em funções regulamentadas em vez do acesso que se acumulou ao longo de anos de mudanças de função.
• Avaliação contínua. Reavaliar ambos à medida que os sinais de risco mudam e revogar o acesso quando os sinais assim o justificarem.

Há uma consequência incômoda por trás disso, que é a seguinte: não é possível aplicar um padrão de privilégio mínimo que nunca foi definido, e não é possível definir um padrão de privilégio mínimo sem saber quem tem acesso a quê atualmente. A maioria das organizações não consegue responder a essa pergunta com segurança, e é por isso que governança de identidade deve ser implementado no início de um programa de Zero Trust, e não em uma fase posterior.

Gerenciamento de identidade e acesso fornece os componentes dos quais uma arquitetura Zero Trust depende.

Há dois requisitos que tendem a ser subestimados mais do que qualquer outro.

A autenticação deve ser resistente a tentativas de phishing. MFA baseada em códigos de acesso únicos O envio por SMS ou e-mail eleva o nível de segurança, mas não elimina a vulnerabilidade, já que ataques do tipo “adversário no meio” e campanhas de “fadiga da autenticação multifatorial” conseguem contornar os métodos de notificação push e OTP com certa frequência. FIDO2 e senhas de acesso vinculadas ao dispositivo vincular a credencial tanto ao dispositivo quanto à origem, o que constitui o mecanismo que realmente impede o ataque, em vez de apenas retardá-lo. A RSA vem defendendo esse argumento desde muito antes de ele se tornar a posição consensual, na qualidade de membro do conselho da Aliança FIDO e copresidente do grupo de trabalho Enterprise.

O Access precisa continuar funcionando mesmo quando a nuvem não estiver disponível. Uma arquitetura que encaminha todas as decisões de acesso por meio de um mecanismo de políticas na nuvem introduz, por definição, um único ponto de falha; e, quando esse serviço fica inacessível, ninguém consegue trabalhar. Para organizações que operam em ambientes locais, híbridos, isolados fisicamente ou de disponibilidade constante — onde uma interrupção acarreta consequências operacionais, e não apenas transtornos —, essa é uma troca desvantajosa. O modelo Zero Trust deve reduzir o número de fatores capazes de deixar uma organização fora do ar, em vez de concentrá-los; é por isso que os caminhos de aplicação fora de linha e no local são o que tornam o modelo viável nesses ambientes.

Quando uma organização adota a estratégia de Zero Trust, o trabalho de verdade começa. Trata-se de um programa que se estende por vários anos, e as organizações que obtêm resultados com ele tendem a organizar o trabalho em etapas, em vez de tentar fazer tudo ao mesmo tempo.

1. Identidades de inventário, recursos e acesso atual. O princípio do privilégio mínimo não pode ser aplicado com base em uma linha de base desconhecida; portanto, comece definindo quem e o que tem acesso a quais recursos atualmente, incluindo contas de serviço, prestadores de serviços e identidades de máquinas.

2. Reforce a autenticação em primeiro lugar. A implantação de autenticação multifatorial (MFA) resistente a phishing nas rotas de acesso de maior valor proporciona a maior redução de risco por unidade de esforço e é um pré-requisito para a maior parte do que se segue.

3. Definir e aplicar políticas de acesso. Transforme funções e necessidades de negócios em políticas explícitas; em seguida, remova o acesso amplo permanente e substitua-o por permissões com escopo definido e passíveis de revisão.

4. Incluir contexto nas decisões de acesso. A adoção da autenticação baseada em risco permite que solicitações de baixo risco sejam aprovadas sem problemas, enquanto as anômalas são submetidas a verificações adicionais ou bloqueadas; essa é também a maneira de impedir que os usuários encontrem formas de contornar o programa.

5. Recursos do segmento. Limitar o alcance de uma sessão comprometida restringe o alcance dos danos no momento em que — e não “se”, mas “quando” — um mecanismo de controle falhar.

6. Monitorar, revisar e revogar. As revisões de direitos devem ser realizadas de acordo com um cronograma, pois o acesso que se acumula sem revisão acaba se transformando na proliferação de privilégios que o programa tinha como objetivo evitar.

Nesse caso, a sequência é mais importante do que o ritmo, já que a segmentação aplicada sem uma identidade controlada por trás dela produz redes bem particionadas que ainda protegem contas com privilégios excessivos.

As organizações nunca alcançam ou atingem o modelo Zero Trust. Elas devem avaliar continuamente sua postura de segurança e revisar todas as decisões de acesso.

Dificuldades do usuário. Uma verificação excessivamente rigorosa leva ao uso de soluções alternativas, à TI paralela e ao aumento do volume de solicitações ao suporte técnico, embora a acessibilidade e a segurança não precisem, na verdade, ser colocadas em contraposição uma à outra. A autenticação baseada em risco adapta o nível de exigência ao risco que cada solicitação individual representa, em vez de aplicar um nível uniforme de restrição a todos.

Sistemas legados. Aplicativos anteriores aos padrões modernos de autenticação muitas vezes não podem ser integrados sem um gateway, um proxy ou uma substituição completa, o que faz com que esse seja o maior obstáculo na maioria dos programas e o aspecto mais frequentemente subestimado na fase de planejamento.

Dependência de disponibilidade. Concentrar as decisões de acesso em um único serviço em nuvem cria uma nova dependência crítica; se o mecanismo de políticas ficar inacessível, todos ficarão sem acesso a nada. Vale a pena perguntar diretamente a qualquer fornecedor o que acontece com a autenticação quando o serviço deles fica fora do ar.

Âmbito organizacional. Como o Zero Trust abrange equipes de identidade, rede, terminais, aplicativos e dados, os programas executados inteiramente por uma única função tendem a ficar estagnados nos limites dessa função.

Confundição de fornecedores. Não existe um único produto que ofereça o modelo Zero Trust; portanto, os fornecedores devem ser avaliados com base nos componentes arquitetônicos que realmente oferecem, e a “plataforma Zero Trust” deve ser vista mais como uma alegação a ser verificada do que como uma categoria de produto a ser adquirida.

Expansão descontrolada dos dados de identidade. A identidade é um problema de dados em constante evolução, e não algo estático, e as autorizações se acumulam mais rapidamente do que a maioria das equipes consegue analisá-las manualmente; é nesse ponto que a automação e a análise de dados deixam de ser opcionais.

A abordagem Zero Trust deixou de ser apenas uma prática recomendada para se tornar um requisito em diversos ambientes regulamentados.

• Ordem Executiva 14028 orienta Órgãos civis federais dos EUA em direção à arquitetura Zero Trust.
• Modelo de Maturidade Zero Trust da CISA fornece a estrutura na qual as agências federais avaliam seu nível de maturidade, organizada em torno de cinco pilares: identidade, dispositivos, redes, aplicativos e cargas de trabalho, e dados.
• Estratégia de Confiança Zero do Departamento de Defesa (DoD) define as atividades do modelo Zero Trust para os componentes de defesa.
• CMMC 2.0 impõe requisitos de controle de acesso e autenticação multifatorial (MFA) em toda a base industrial de defesa.
• DORA e NIS2 impor requisitos de controle de acesso, resiliência e continuidade operacional a Serviços financeiros da UE e infraestruturas críticas que se enquadram nos princípios do Zero Trust, independentemente de o termo aparecer ou não no texto.

A identidade surge como um pilar ou uma família de controles em cada um desses casos, e é também nesse ponto que os auditores costumam solicitar evidências em primeiro lugar e onde as organizações raramente estão preparadas para apresentá-las.

Os requisitos de resiliência e as arquiteturas exclusivamente na nuvem também entram em conflito de maneiras que vale a pena analisar desde o início. As expectativas de continuidade operacional previstas na DORA, juntamente com as exigências de disponibilidade constante nos setores de defesa e infraestrutura crítica, são difíceis de atender utilizando um modelo de acesso que deixa de funcionar sempre que o serviço de um fornecedor fica inacessível.