This entry is parte 2 de 2 in the series Zero Trust

Zero Trust

Índice

Zero Trust é frequentemente apresentado como um conjunto de tecnologias ou práticas de segurança, mas essa leitura é incompleta.

Na prática, isso leva a uma compreensão superficial do modelo, onde a adoção de determinadas ferramentas ou mecanismos é confundida com a implementação de segurança efetiva.

Zero Trust não é uma ferramenta, nem uma arquitetura específica. É um modelo de decisão baseado em evidência (NIST SP 800-207).

Isso significa que a confiança não é estabelecida por configuração ou posição na rede, mas construída a partir de sinais observáveis a cada interação.

Nesse modelo, nenhuma requisição é considerada legítima por padrão. Cada ação precisa ser avaliada com base no contexto em que ocorre, e não apenas na identidade associada.

Essa mudança desloca o foco da segurança:

  • de mecanismos isolados para decisões contextualizadas
  • de confiança implícita para verificação contínua
  • de identidade como garantia para identidade como um dos elementos de avaliação

Mais do que adicionar camadas de proteção, Zero Trust redefine o próprio critério pelo qual uma requisição é considerada aceitável.

2.1. O princípio

O conceito central é simples:

never trust, always verify

No entanto, essa frase é frequentemente interpretada de forma superficial, como se significasse apenas “validar mais” ou adicionar novas camadas de autenticação.

Na prática, ela implica uma mudança mais profunda na forma como sistemas tratam confiança.

Confiança deixa de ser um estado persistente e passa a ser uma decisão contextual.

Isso significa que ela não é estabelecida em um único ponto do fluxo, como no momento do login, nem é mantida automaticamente ao longo do tempo.

Cada interação precisa ser avaliada com base nas evidências disponíveis naquele instante.

Essa decisão não é estática, nem acumulativa. Ela pode variar ao longo do tempo, conforme o contexto muda.

O mesmo usuário, com a mesma identidade, pode ser considerado confiável em um momento e não em outro, dependendo das condições em que a requisição é realizada.

Esse princípio rompe com a ideia tradicional de “sessão confiável” e substitui esse modelo por um processo contínuo de verificação.

2.2. Identidade não é confiança

Modelos tradicionais associam confiança diretamente à identidade.

Uma vez autenticado, o usuário passa a operar dentro de um contexto implicitamente considerado seguro, e suas ações subsequentes são tratadas como legítimas por padrão.

Esse modelo simplifica a tomada de decisão, mas introduz uma dependência crítica: a confiança passa a ser derivada de um único evento, a autenticação.

Zero Trust rompe com essa associação.

A identidade continua sendo um elemento relevante, mas deixa de ser suficiente para sustentar decisões de segurança. Ela passa a ser apenas um dos sinais considerados na avaliação de uma requisição.

Nesse modelo, autenticar não equivale a confiar. A identidade responde quem está interagindo com o sistema, mas não fornece garantias sobre o contexto em que essa interação ocorre.

Confiança, portanto, não é herdada do login nem propagada automaticamente ao longo da sessão.

Ela é construída a partir de evidências observáveis, que precisam ser avaliadas continuamente.

Isso inclui não apenas quem realiza a ação, mas também onde, como e em que condições essa ação é executada.

Essa distinção é central para compreender a mudança proposta pelo Zero Trust.

2.3. Tudo se torna sinal

Se confiança é uma decisão, ela precisa ser baseada em dados observáveis.

Isso implica tratar cada requisição não apenas como uma ação isolada, mas como um conjunto de evidências que descrevem o contexto em que ela ocorre.

Nesse modelo, tudo o que envolve a interação pode ser interpretado como sinal:

  • características do dispositivo que originou a chamada
  • estado da aplicação no momento da execução
  • condições do ambiente, como integridade, emulação ou debug
  • características de contexto, como localização geográfica e rede de origem
  • comportamento associado à interação, como padrão de uso e sequência de ações

Esses sinais não são, individualmente, garantias de segurança.

Nenhum deles, por si só, é suficiente para determinar se uma requisição é legítima ou não. Eles podem ser manipulados, simulados ou apresentar ambiguidade quando analisados isoladamente. O valor está na combinação.

Ao correlacionar múltiplos sinais, o sistema passa a construir uma representação mais fiel do contexto da requisição, reduzindo a dependência de suposições e aumentando a capacidade de detectar inconsistências.

Essa abordagem transforma o problema de segurança de uma validação pontual para uma análise contextual baseada em evidências.

2.4. Confiança como processo dinâmico

No modelo tradicional, a confiança é estática: começa no login e se mantém ao longo da sessão.

Uma vez estabelecida, essa confiança é reutilizada de forma implícita em todas as interações subsequentes, independentemente de mudanças no contexto.

No modelo Zero Trust, essa premissa é abandonada. A confiança passa a ser tratada como um processo dinâmico, construído e reavaliado continuamente.

Cada requisição deixa de depender exclusivamente de uma decisão passada e passa a ser analisada no momento em que ocorre.

Isso permite que o sistema:

  • reaja a mudanças no ambiente de execução, como transições para debug, emulação ou comprometimento do dispositivo
  • identifique desvios de comportamento em relação ao padrão esperado
  • ajuste decisões de segurança ao longo da sessão, de acordo com o nível de risco observado
  • reduza a janela de exposição, limitando o impacto de sessões comprometidas

Como consequência, a segurança deixa de ser um ponto isolado no tempo e passa a operar como um processo contínuo.

Cada interação deixa de ser apenas uma continuidade da sessão e passa a representar uma nova decisão de confiança.

2.5. O papel do cliente em aplicações mobile

Em aplicações mobile, o cliente passa a ter um papel ativo nesse modelo.

Ele deixa de ser apenas um executor de requisições e passa a atuar como fonte de sinais sobre o contexto em que cada interação ocorre.

Essa mudança é especialmente relevante porque, em um ambiente mobile, grande parte das evidências necessárias para qualificar uma requisição nasce no próprio dispositivo. É no cliente que estão disponíveis informações sobre o estado da aplicação, as condições do ambiente de execução e aspectos comportamentais associados ao uso.

Esses sinais podem estar relacionados a diferentes dimensões:

  • dispositivo, como identidade, integridade e características do ambiente
  • aplicação, como versão, estado de execução e condições de instrumentação
  • sessão, como continuidade, consistência e alterações ao longo do tempo
  • comportamento, como padrão de uso, sequência de ações e desvios em relação ao esperado

Isso não transforma o cliente em autoridade de segurança. O papel do cliente não é decidir, validar ou estabelecer confiança por conta própria. Sua função é observar, coletar e transmitir evidências relevantes.

A decisão continua dependendo da correlação desses sinais com outros elementos do sistema e da forma como eles são interpretados dentro do modelo de segurança adotado.

Esse ponto é importante porque evita um erro comum: confundir coleta de sinais com delegação de confiança.

No contexto de Zero Trust, o cliente participa da construção do contexto, mas não da definição final de legitimidade.

Sua responsabilidade é fornecer dados que permitam ao sistema avaliar, com maior precisão, as condições em que cada requisição está sendo realizada.

2.6. A mudança de perspectiva

Zero Trust não adiciona apenas novas verificações. Ele muda a forma como o sistema interpreta uma requisição.

Zero Trust transforma contexto em dado verificável.

Essa é a diferença central.

No modelo tradicional, grande parte das decisões de segurança depende de premissas implícitas sobre o ambiente, o comportamento e a integridade do cliente.

Essas premissas não são observadas diretamente. Elas apenas sustentam o funcionamento do sistema.

No modelo Zero Trust, essas suposições deixam de existir como base de decisão.

O que antes era implícito passa a ser observado. O que antes era assumido passa a ser avaliado.

Isso implica transformar aspectos do contexto, que antes eram ignorados ou tratados como garantidos, em dados coletáveis, mensuráveis e analisáveis.

A requisição deixa de ser interpretada apenas como uma chamada válida dentro de um fluxo esperado e passa a ser tratada como um evento que precisa ser justificado por evidências.

Essa mudança desloca o sistema de um modelo baseado em confiança herdada para um modelo baseado em verificação contínua.

2.7. O próximo passo

Se confiança passa a ser construída a partir de sinais, surge uma questão prática inevitável:

como coletar essas evidências em um ambiente que, por definição, não é confiável?

Essa não é apenas uma questão de instrumentação, mas de arquitetura.

No contexto mobile, o cliente é simultaneamente a principal fonte de sinais e o ponto menos confiável do sistema. Essa dualidade impõe um desafio central: extrair informações úteis sem assumir a integridade do próprio ambiente que as produz.

Isso exige mecanismos capazes de:

  • coletar sinais relevantes sem depender de premissas frágeis
  • validar, correlacionar e atribuir peso a esses sinais
  • lidar com manipulação, simulação e ausência de garantias no cliente

O problema deixa de ser apenas “o que coletar” e passa a ser “como confiar, ainda que parcialmente, no que foi coletado”.

É a partir dessa tensão que se constrói a próxima etapa.

Como transformar o cliente mobile em uma fonte consistente de sinais, mesmo operando em um ambiente potencialmente adversarial.