Considerações de técnicas e tecnologias para a adoção de abordagem Zero Trust

Expandindo a partir do “porquê” — os princípios orientadores¹ —de confiança zero, a próxima preocupação é “como” — as técnicas e tecnologias usadas para implementar esses princípios.

Da perspectiva mais ampla, os princípios de confiança zero podem ser aplicados a todo o ciclo de vida de desenvolvimento de aplicativos, incluindo o design do sistema, as plataformas de hardware utilizadas e os procedimentos de aquisição.² Entretanto, este artigo discute os aspectos operacionais da implementação de confiança zero para defender aplicativos e dados em tempo de execução. 

Em termos gerais, a segurança Zero Trust usa tecnologias para atingir uma das três metas distintas:

1. Aplicar restrições transacionais: Quem pode fazer o quê a quem .
2. Fornecer consciência situacional para o operador de sistema humano.
3. Realizar uma redução/remediação de riscos avançada, com base nos indicadores de suspeita auxiliados por ML (Aprendizado de máquina) e no perfil de risco/recompensa das transações em questão.

O gráfico a seguir demonstra esse modelo transacional de segurança Zero Trust geral, com as seções seguintes se aprofundando em cada classe de tecnologias.

As duas primeiras tecnologias — autenticação e controle de acesso — estão intimamente relacionadas e são diretamente motivadas pelos princípios de “verificação explícita” e “privilégio mínimo”, uma vez que essas tecnologias estão no cerne da aplicação de “ Quem pode fazer o quê ”. Implementações mais sofisticadas de autenticação observam o comportamento contínuo de um ator, capturando a mentalidade de “avaliar continuamente”. 

As tecnologias de autenticação visam criar confiança em uma identidade atestada: Quem está atuando em uma transação. O processo de autenticação tem três componentes: 

1. Há uma declaração, ou reivindicação, feita pelo agente, declarando a identidade do agente.
2. Há alguns dados, normalmente fornecidos pelo agente, que oferecem uma prova da veracidade da declaração.
3. O sistema produz um veredito ou decisão sobre a probabilidade de que a atestação esteja correta — o ator é quem ele afirma ser. O gráfico abaixo descreve os diferentes aspectos da autenticação, os modelos de maturidade para cada um e é seguido por uma discussão mais aprofundada de cada aspecto. 

A forma mais básica de atestado é frequentemente chamada de “usuário” — um ser humano, ou agente agindo em nome de um ser humano, que deseja realizar uma transação. Entretanto, no caso de confiança zero usada em um aplicativo, um ator pode ser uma carga de trabalho (como um processo, serviço ou contêiner), então o conceito generalizado de identidade deve incluir tais atores. Em outros casos, a noção de Quem inclui não apenas o humano ou a carga de trabalho, mas considerações ou dimensões adicionais de identidade. Dessa perspectiva, dimensões adicionais de identidade podem incluir o dispositivo ou plataforma do usuário/carga de trabalho, ou o ecossistema usado para a interação ou a localização do agente. Por exemplo, um usuário “Alice” pode estar em um PC marcado como “ABC- 0001” usando uma instância específica de navegador com impressão digital, originada do endereço IPv4 10.11.12.13. 

Alguns sistemas permitem que usuários não autenticados, às vezes chamados de “convidados” ou usuários “anônimos”, realizem um conjunto limitado de transações. Para tais sistemas, as etapas adicionais de comprovação de identidade e o sistema que emite um veredito não são relevantes. Entretanto, para qualquer identidade atestada específica, os seguintes métodos são comumente usados para dar suporte a essa atestação:

• Conhecimento de um segredo compartilhado, como uma senha.
• Algum tipo de credencial de um terceiro de confiança, como um certificado assinado.
• Interrogação — automatizada (como dispositivo de digital) ou ativa (como um recurso de captcha) — do usuário, da carga de trabalho ou da plataforma.
• Metadados relacionados ao agente, como localização geográfica, reputação de IP ou tempo de acesso.
• Análise comportamental, como análise biométrica passiva ou padrões de fluxo de trabalho da interação da aplicação.

Muitas vezes, quando é necessário um alto grau de confiança, vários métodos são usados. Isso é evidenciado no modelo do Google BeyondCorp,³ que exige autenticação multifator (MFA) antes de permitir transações de maior valor. As soluções de autenticação mais sofisticadas associam uma “confiança” a cada identidade e especificam um nível mínimo de confiança para cada tipo de transação, com base no valor e no risco da transação.

Por fim, observe que alguns desses métodos não são ações estáticas e pontuais, mas podem e devem ser contínuos, de acordo com o princípio de “avaliação contínua”. Nesses casos, a pontuação de confiança atribuída à comprovação de identidade pode aumentar ou diminuir ao longo do tempo. Por exemplo, a impressão digital do navegador ou o endereço IP podem mudar dentro de uma única sessão do usuário, o que pode ser visto como suspeito, reduzindo a confiança; ou, à medida que mais dados são coletados sobre o comportamento do ator em uma sessão, a pontuação de confiança pode aumentar ou diminuir dependendo de como o comportamento atual se compara a observações anteriores.

A autenticação dinâmica pode funcionar em conjunto com o controle de acesso em sistemas mais avançados. Como primeiro nível dessa interação, a política de controle de acesso pode especificar uma pontuação de confiança mínima para diferentes classes de transações, conforme mencionado anteriormente. O próximo nível de interação permite que o subsistema de controle de acesso forneça feedback ao subsistema de autenticação, normalmente solicitando autenticação adicional para aumentar a pontuação de confiança para o limite mínimo.

Após utilizar técnicas de autenticação para verificar quem está atuando em uma transação, as próximas perguntas são: O que esse ator tem permissão para fazer? E para quem ? Este é o escopo das tecnologias de controle de acesso.

Para fazer uma analogia de segurança física, imagine que você queira visitar uma base militar. Depois que os guardas determinam com segurança se você é um civil, político ou soldado, eles usam essa determinação para decidir em quais prédios você pode entrar e se você pode levar uma câmera para cada prédio em que tiver permissão para entrar. A política que rege essas escolhas pode ser muito grosseira e se aplicar a todos os edifícios (por exemplo, “políticos podem entrar em qualquer edifício”) ou pode ser mais refinada (como “políticos só podem entrar nos edifícios <A> e <B>, mas só podem levar câmeras para <A>”).

Aplicadas ao contexto da segurança cibernética, as técnicas de controle de acesso devem incorporar o princípio de confiança zero de “privilégio mínimo”. Em outras palavras, a política de controle de acesso ideal permitiria apenas aqueles privilégios que o ator requer e não permitiria todos os outros privilégios. Além disso, uma política robusta ideal seria condicional a um nível mínimo específico de confiança na autenticidade da identidade do ator, com o limite de confiança especificado na granularidade de cada privilégio permitido.

Portanto, o valor de uma solução de controle de acesso pode ser avaliado pelo quão próximo ela está desses ideais. Especificamente, uma solução de segurança de confiança zero deve incluir controle de acesso e deve avaliar a tecnologia de controle de acesso ao longo das dimensões descritas abaixo e posteriormente. 

1. Quão refinados são os privilégios de controle de acesso?

1. Qual é a granularidade da ação — o quê na transação? É isso:

1. Binário : Permitir “todas” as transações ou “nenhuma”. Na analogia da base militar, isso corresponderia a “todos os soldados podem entrar em qualquer edifício e fazer o que quiserem” e “os civis não podem entrar em nenhum edifício”.
2. Grosso : Granular para o ponto de extremidade da API ou “tipo” de transação (como E/S de arquivo, comunicação de rede e controles de processo). Em nosso exemplo, isso permitiria um nível de nuance em torno da ação permitida, como “políticos podem entrar em prédios, mas não tirar fotos”. 
3. Multar: Na sub-API (ou seja, dependente dos parâmetros ou da versão da API) ou “subtipo” de transação (como E/S de arquivo somente leitura ou TCP somente recebimento). Usando nossa analogia mais uma vez, isso permitiria controles mais precisos, como “civis podem entrar em edifícios somente se acompanhados por um soldado”. 

2. Existe granularidade quanto ao alvo da ação — o Quem na transação? É isso:

1. Não granular ao alvo: A política de controle de acesso não considera o alvo da ação. Em nosso exemplo, essa abordagem seria mapeada para a granularidade de permitir a entrada em alguns edifícios, mas não em outros — os edifícios sendo o alvo da ação “entrar”.
2. Nível de infraestrutura granular de destino: A política de controle de acesso pode incluir o alvo da ação, mas usa alguma tag/rótulo específico da infraestrutura, como o endereço IP, o nome DNS ou o nome do contêiner do Kubernetes (K8S) para o alvo. Isso permitiria que a política fosse mais granular para cada edifício, mas cada base militar poderia ter uma convenção de nomenclatura diferente para edifícios.
3. Alvo granular, com reconhecimento de identidade: A política de controle de acesso pode incluir o alvo da ação, identificando o alvo usando o mesmo espaço de nome de identidade (por exemplo, SPIFFE) usado para o ator (o Quem). O benefício em relação à abordagem anterior é que todas as bases militares usariam um esquema consistente de identificação de edifícios, tornando a política mais portátil.

2. Como a solução de controle de acesso lida com o conceito de ações menos ou mais arriscadas?

1. Não consciente dos riscos: A solução de controle de acesso trata todos os privilégios de controle de acesso de forma idêntica, em termos da decisão de permitir ou não a ação.
2. Gestão de riscos via MFA: A solução de controle de acesso gerencia o risco permitindo que a política especifique que algumas transações permitidas ainda precisam usar a autenticação multifator, com base no ator ( Quem ), ação ( O quê ) ou alvo ( Quem ) envolvido na transação.
3. Gestão de risco via confiança: A solução de controle de acesso gerencia o risco permitindo que a política especifique que qualquer transação ainda pode exigir um nível mínimo de confiança na autenticidade do ator, com base na ação ( o quê ) e no alvo ( quem ) na transação. A MFA pode aumentar a confiança, embora outros meios possam ser usados; em outros casos, a transação pode não ser permitida se for de alto valor e a autenticidade do ator for suficientemente incerta.

Observando o princípio de “avaliar (e reavaliar) continuamente”, qualquer crença na autenticidade do ator deve se ajustar ao longo do tempo. Em uma solução simples, pode ser apenas um tempo limite; em sistemas mais sofisticados, a confiança pode variar com base nas observações do comportamento do ator ao longo do tempo.

Se a autenticação e o controle de acesso forem implementações de mentalidade “sempre verificar” e “menor privilégio”, então, a visibilidade e a análise contextual são fundamentais para os princípios de “avaliar continuamente” e “presumir uma violação”.

A visibilidade é o precursor necessário para a análise: um sistema não pode mitigar o que não pode ver. Portanto, a eficácia da solução de segurança de confiança zero será diretamente proporcional à profundidade e amplitude da telemetria que pode ser coletada das operações do sistema e do contexto externo. No entanto, uma infraestrutura de visibilidade moderna será capaz de fornecer muito mais dados, metadados e contexto potencialmente úteis do que qualquer ser humano razoável e sem assistência seria capaz de lidar em tempo hábil. Como resultado do desejo por mais dados e da capacidade de destilar esses dados em insights mais rapidamente, um requisito fundamental é a assistência de máquinas para os operadores humanos.

Essa assistência normalmente é implementada usando algoritmos automatizados que abrangem desde análises baseadas em regras até métodos estatísticos e algoritmos avançados de aprendizado de máquina. Esses algoritmos são responsáveis por traduzir a mangueira de dados brutos em consciência situacional consumível e operacionalizada que pode ser usada por operadores humanos para avaliar e, se necessário, remediar. Por esse motivo, a análise assistida por ML anda de mãos dadas com a visibilidade.

O pipeline generalizado de dados brutos (visibilidade) até a ação (remediação) é exibido a seguir:

Visibilidade é a implementação — o “como” — do princípio de “avaliação contínua” de confiança zero. Inclui manter um inventário de entradas de dados disponíveis (Catálogo) e telemetria em tempo real, além de retenção de dados históricos (Coletar).

A maturidade da visibilidade de uma abordagem Zero Trust deve considerar quatro fatores:

1. Latência : Quão próximos do tempo real estão os dados?

A latência fornece um limite inferior para a rapidez com que uma ameaça potencial pode ser respondida. A latência de uma solução de confiança zero deve ser medida em segundos ou menos; caso contrário, é bem provável que qualquer análise — não importa quão precisa seja — seja tarde demais para evitar o impacto da exploração, como exfiltração/criptografia de dados ou indisponibilidade devido ao esgotamento de recursos. Sistemas mais sofisticados podem permitir mitigações síncronas e assíncronas. A mitigação síncrona inibiria a conclusão da transação até que a visibilidade e a análise completas fossem concluídas. Como a mitigação síncrona provavelmente adicionará latência à transação, esse modo de operação seria reservado para transações particularmente anômalas ou arriscadas, permitindo que todas as outras transações enviem telemetria e sejam analisadas de forma assíncrona.

2. Consumibilidade : Quão facilmente os dados podem ser consumidos?
   

Essa preocupação é relevante se os dados chegam de várias fontes ou tipos de sensores de dados, o que é um cenário comum. Este fator normalmente se divide em duas subpreocupações. 

• No nível sintático, como os dados podem ser extraídos e representados. Por exemplo, se uma reputação de IP de origem chega como um campo de texto (como “malicioso”, “suspeito”, “desconhecido” etc.) em uma mensagem syslog de uma origem e como um campo numérico codificado em binário em um arquivo de dados de outra, então uma representação canônica deve ser identificada. A serialização de dados será necessária para extrair e transformar os dados recebidos nessa representação. 

• No nível semântico, diferentes fontes podem variar não apenas em sua sintaxe e transporte, mas também na semântica. Usando o exemplo de reputação de IP novamente, um provedor pode fornecer uma pontuação de ameaça como um número, enquanto outro provedor pode classificar o IP em um intervalo como “nó TOR”, “Controle DNS” ou “Phishing”. A solução de visibilidade também deve fornecer um mecanismo para normalizar os dados recebidos em uma sintaxe consistente. 

3. Completude: Qual é a amplitude e a profundidade dos dados disponíveis?

Um valor essencial derivado de uma solução de visibilidade de alta qualidade é a capacidade de descobrir atividades suspeitas como um indicador de possível violação. Para fazer isso de forma eficaz, a solução deve receber telemetria em todas as “camadas” relevantes de entrega do aplicativo: o aplicativo em si, é claro, mas também a infraestrutura do aplicativo, a infraestrutura de rede, quaisquer serviços aplicados ou usados pelo aplicativo e até mesmo os eventos no dispositivo cliente. Por exemplo, identificar um usuário acessando um dispositivo novo, nunca visto antes, pode ser um pouco suspeito por si só; mas quando combinado com informações de rede (como mapeamento GeoIP de um país estrangeiro), o nível de suspeita aumenta ainda mais. Esse nível de suspeita se manifesta como uma pontuação de confiança mais baixa na identidade do usuário. No contexto de uma política de segurança de confiança zero, quando esse ator tenta uma transação de alto valor (como transferência de fundos para uma conta estrangeira), a solução de controle de acesso pode optar por bloquear a transação, com base na baixa confiança.

Em relação à mentalidade Zero Trust, quanto mais profunda e completa for a solução de visibilidade, mais eficiente o sistema pode ser na limitação apropriada de transações e na detecção de violações

4. Governança: Quão bem os requisitos de uso de dados estatutários e baseados em licenças são atendidos?

Por fim, qualquer coleta de dados deve estar em conformidade com os requisitos legais e de licenciamento relacionados à segurança, retenção e uso de dados. Portanto, uma solução de visibilidade robusta deve atender a cada uma dessas necessidades. Entender as restrições no uso de dados implícitas na governança deve ser considerado em uma solução de visibilidade de confiança zero. Por exemplo, se um IP for considerado Informação Pessoalmente Identificável (PII), então o uso e a retenção de longo prazo de endereços IP para análise devem atender ao uso permitido dos endereços IP. 

Além da visibilidade, o outro maquinário necessário para implementar a “avaliação contínua” são as ferramentas analíticas necessárias para realizar uma avaliação significativa; ou seja, ter uma avaliação que possa ser operacionalizada por uma solução de Zero Trust.

Uma consideração para análise é o escopo e a amplitude dos dados de entrada. As entradas para os algoritmos de análise podem ser limitadas a um único fluxo de dados de uma única fonte ou podem olhar através de múltiplos fluxos, incluindo de várias fontes de dados e todas as camadas da infraestrutura e aplicação. 

• A contextualização mais básica está dentro do escopo de um único “tipo” ou “fluxo” de dados (como um fluxo de eventos de “informações de login do usuário com hora e endereço IP de origem”), normalmente com contexto histórico e/ou dados de vários usuários. Essa análise pode resultar em alguns insights básicos, como “este usuário <X> nunca fez login durante esse horário do dia” ou “este usuário <X> parece sempre fazer login imediatamente após outro usuário <Y>”. O primeiro pode reduzir a confiança na identidade; o último pode ser indicativo de algum padrão de nível superior, talvez malicioso.
• Uma contextualização mais avançada considera o escopo baseado em tempo e multi-instância não apenas para um único “tipo” de dados, mas também realiza correlação de tempo entre diferentes “tipos” ou “fluxos” de dados. Um exemplo seria correlacionar os dados de login do usuário com ações específicas na camada de aplicação (como transferência de dinheiro ou atualizações de contato por e-mail) ou na camada de rede (como uma pesquisa de geolocalização baseada em IP). 

Um segundo aspecto particularmente relevante da análise na estrutura de confiança zero é lidar com o volume e a taxa de dados ingeridos, que excederão a capacidade de qualquer ser humano de digerir. Portanto, é necessário algum tipo de assistência mecânica para formar insights digeríveis por humanos. Mais uma vez, a sofisticação da assistência pode ser descrita como uma progressão.

• Somente visualização: O primeiro passo é a apresentação simples de estatísticas e eventos, normalmente por meio de painéis disponíveis em um portal de gerenciamento. Os dados apresentados são baseados em fluxos de dados coletados (geralmente uma série temporal ou uma seção transversal longitudinal entre usuários/transações dentro de uma janela de tempo fixa). Painéis mais avançados oferecem a capacidade de classificar e agrupar dados, bem como detalhamentos por meio de filtragem. Neste modelo, o ser humano faz toda a exploração de dados, priorização de eventos, análise e correção, com a automação ajudando principalmente na exploração de dados.
• Visualização mais regras estáticas configuráveis: A próxima extensão mais comum da visualização é a capacidade de permitir que o ser humano defina regras estaticamente especificadas, seja para alerta ou correção. Exemplos de tais regras seriam “notificar o humano < John > se < a carga da CPU exceder 80% por um período de 5 minutos >” ou “exigir < MFA por e-mail > se < API [Y] for invocada e o país não for [Estados Unidos] >”. Essas regras podem ser limitadas a regras predefinidas especificadas pelo provedor da solução, ou subsistemas baseados em regras mais avançados também podem permitir regras personalizadas escritas por um engenheiro de SecOps. Em ambos os casos, quaisquer regras aplicadas são normalmente controladas (e definidas, se necessário) por meio de configuração. 
• Visualização mais assistência de ML: O próximo nível usa técnicas mais avançadas que encontram anomalias comportamentais e/ou transações que correspondem aos padrões de transações maliciosas identificadas anteriormente. Embora existam muitas técnicas utilizadas (e uma discussão profunda sobre as compensações técnicas e comerciais está fora do escopo deste artigo), há alguns pontos-chave a serem considerados: 

• Esforço humano necessário: Algumas técnicas de ML exigem “treinamento” (também conhecido como aprendizado supervisionado), o que significa que um corpus de dados de tamanho razoável deve ser pré-categorizado usando um “classificador” confiável. Muitas vezes, para ter uma categorização confiável, o “classificador” acaba sendo um humano ou um conjunto de humanos. Nesses casos, o esforço humano necessário deve ser levado em consideração. Outras técnicas (também conhecidas como aprendizagem não supervisionada) detectam anomalias e/ou reconhecem padrões por conta própria, sem esforço humano. 
• Explicabilidade: A(s) saída(s) de um sistema de aprendizado de máquina resultam da avaliação dos dados de entrada em relação a um modelo. Este modelo pode ser baseado em uma série de perguntas simples e fáceis de responder, como: “Este usuário foi visto neste dispositivo no mês passado?” Também poderia ser baseado em uma similaridade facilmente explicada, como “este usuário se enquadra no padrão geral que vi de usuários que nunca fazem login durante o horário de trabalho”. Em outros casos, o modelo pode ser baseado na aplicação de um conjunto complexo de operações de álgebra vetorial nos dados de entrada, sem lógica de alto nível facilmente discernível. Este último caso é claramente menos explicável — mais como uma “caixa preta” — do que os dois exemplos anteriores. Em alguns casos, a explicabilidade é um fator importante para a compreensão ou auditabilidade humana. Para esses casos, um modelo explicável será fortemente preferido em vez de um inescrutável. 
• Disponibilidade da pontuação de confiança: Como mencionado anteriormente, uma métrica que indica o quão confiante o modelo é para uma decisão — em outras palavras, uma noção da probabilidade relativa de um falso positivo ou falso negativo — geralmente é muito útil. Alguns algoritmos são tais que uma saída de métrica de confiança surge naturalmente; para outros, como os baseados em regras, um nível de confiança precisaria ser explicitamente especificado como uma das saídas. Em ambos os casos, os algoritmos que podem fornecer uma pontuação de confiança são mais robustos do que aqueles que não podem. 

Assim como na abordagem baseada em regras, a assistência de ML pode ser apenas para detecção ou pode ser vinculada à correção automática. Além disso, a assistência de ML pode ser usada em conjunto com um sistema baseado em regras, onde o “veredito” de ML (ou opinião ou confiança) pode ser usado como uma entrada em uma regra, como “executar ação <X> se <avaliador de ML [bot_detector_A] relatar bot com confiança maior que 90%>.” 

O princípio final da mentalidade de ferrugem zero é “assumir a violação”. Para ser claro e fornecer perspectiva, métodos de autenticação e controle de acesso implementados corretamente são eficazes na prevenção da grande maioria das transações maliciosas. No entanto, deve-se, por excesso de paranoia, supor que os mecanismos de execução de autenticação e controle de acesso serão derrotados por algum adversário suficientemente motivado ou sortudo. A detecção de violações, necessária para responder a essas fugas em tempo hábil, requer visibilidade e análise assistida por máquina. Portanto, é porque os outros mecanismos de execução serão derrotados ocasionalmente que as tecnologias de visibilidade que alimentam a análise contextual assistida por ML são uma necessidade crítica para alimentar a solução de segurança de confiança zero de remediação baseada em risco. 

Para os casos de “falso negativo” em que uma transação maliciosa real derrotou a autenticação e o controle de acesso, o mecanismo de correção automatizada baseada em risco deve ser usado como um recurso. Mas como essa tecnologia é aplicada como um obstáculo contra transações que passaram nas verificações de execução anteriores, há uma preocupação maior em sinalizar incorretamente o que era, na verdade, um “verdadeiro negativo” (uma transação válida e desejável) como um “falso positivo” (sinalizado incorretamente como uma transação maliciosa). Para atenuar essa preocupação, quaisquer ações de correção desencadeadas pela crença em possível malícia, que de alguma forma não foi detectada pela autenticação ou controle de acesso, devem ser baseadas nos três fatores a seguir:⁴

• Valor comercial da transação: Diferentes transações terão diferentes níveis de risco e recompensa. Por exemplo, uma transação que visualiza uma conta bancária é menos arriscada do que uma transação que transfere dinheiro para uma conta estrangeira. Da mesma forma, para uma companhia aérea, comprar uma passagem provavelmente será uma transação com maior recompensa comercial, em comparação a uma transação que lista atrasos de voos atuais. O valor comercial é o benefício da potencial recompensa comercial ponderada em relação ao perfil de risco da transação. É mais aceitável tolerar quaisquer efeitos de “falso positivo” de remediação especulativa para transações de baixa recompensa/alto risco, em comparação com transações de alta recompensa/baixo risco que têm alto valor comercial. 
• Confiança na crença de “malícia”: É claro que nem todas as sugestões para remediação especulativa são iguais. Especificamente, além do risco-recompensa mencionado acima, o outro fator-chave é a confiança nas crenças em torno dessa transação, como a confiança na identidade atestada do ator. Em termos gerais, a probabilidade de “falso negativo” — ou seja, a probabilidade de que os mecanismos de execução não tenham sido acionados, mas deveriam ter sido — é inversamente proporcional à confiança no ator. E como a redução de “falsos negativos” é o objetivo da remediação baseada em risco, quanto menor a confiança, mais tendencioso o sistema deve ser em relação à aplicação da remediação.
• Impacto da remediação: Por fim, nem todas as remediações são decisões binárias: permitir ou bloquear. Na verdade, uma variedade de técnicas de redução de risco são possíveis, desde algumas que são visíveis ao usuário (por exemplo, solicitar credenciais/MFA adicionais, fornecer um desafio como um captcha) até outras que são quase invisíveis ao usuário (realizar uma inspeção de tráfego mais profunda, como DLP, ou fazer uma análise mais avançada/computacionalmente intensiva). Portanto, o impacto da execução dessas formas adicionais de redução de risco — medido pelo atrito experimentado pelo usuário e pelos custos operacionais do aplicativo (como para DLP ou análise de computação pesada) — é o terceiro fator a ser considerado. Soluções de baixo impacto e transparentes para o cliente são preferíveis a desafios de maior impacto visíveis para o cliente, e o bloqueio total da transação é a opção menos atraente. No entanto, o bloqueio pode ser apropriado quando a confiança é alta ou para transações arriscadas que não podem aumentar suficientemente a confiança por meio de outros mecanismos de redução de risco. 

A segurança de confiança zero é uma abordagem mais moderna de abordagens anteriores de segurança, como defesa em profundidade, estendendo a técnica anterior ao adotar uma visão centrada em transações sobre segurança: quem está tentando fazer o quê a quem . Essa abordagem permite proteger não apenas o acesso externo a um aplicativo, mas também é aplicável à proteção dos componentes internos do aplicativo.⁵ Dada essa visão transacional fundamental, a segurança de confiança zero está enraizada em um conjunto de princípios fundamentais que são usados para defender aplicativos no ambiente mais complexo e desafiador de hoje, com os princípios então mapeados para um conjunto de soluções de nível de subsistema, ou métodos, que incorporam esses princípios. Os princípios básicos e como eles se relacionam com métodos de solução estão resumidos abaixo. 

Estas ferramentas — os métodos de autenticação, o controle de acesso, a visibilidade, a análise contextual e a remediação de consciência de riscos — são necessárias e suficientes para evitar uma grande variedade de tipos de ataque.

Baixe o relatório