Saindo do “por quê”—os princípios orientadores¹—da abordagem Zero Trust, a próxima preocupação é “como”— as técnicas e tecnologias usadas para implementar esses princípios.

De uma perspectiva mais ampla, os princípios da abordagem Zero Trust podem ser aplicados a todo o ciclo de vida de desenvolvimento da aplicação, incluindo o design do sistema, as plataformas de hardware usadas e os procedimentos de aquisição.² No entanto, esse artigo discute os aspectos operacionais da implementação da abordagem Zero Trust para defender aplicações e dados no 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 que para 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 motivadas diretamente pelos princípios de “verificação explícita” e “menor privilégio”, pois elas estão no núcleo da aplicação de “Quem pode fazer O que”. Implementações de autenticação mais sofisticadas observam o comportamento contínuo de um agente, capturando a mentalidade de “avaliar continuamente”.

As tecnologias de autenticação têm tudo a ver com construir a confiança em uma identidade atestada: Quem está atuando em uma transação. O processo de autenticação possui 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 a declaração ser correta — o agente ser quem ele afirma ser. O gráfico a seguir demonstra os diferentes aspectos da autenticação, os modelos de maturidade para cada um deles e é seguido por uma discussão mais profunda de cada aspecto.

A forma mais básica de declaração, geralmente, é mencionada como um “usuário” — um humano, ou agente que atua em nome de um humano, que deseja realizar uma transação. No entanto, no caso da abordagem Zero Trust usada dentro de uma aplicação, um agente pode ser uma carga de trabalho (como um processo, serviço ou contêiner), portanto, o conceito generalizado de identidade deve incluir esses agentes. Em outros casos, a noção de Quem não inclui apenas o humano ou a carga de trabalho, mas considerações ou dimensões adicionais da identidade. Dessa perspectiva, dimensões adicionais da identidade podem incluir o ecossistema de dispositivos que está sendo usado para a interação ou o local do agente. Por exemplo, um usuário “Alice” pode estar em um PC marcado como “ABC- 0001” usando uma instância de navegador identificada específica, com origem no endereço IPv4 10.11.12.13.

Alguns sistemas permitem que usuários não autenticados, às vezes, mencionados como usuários “convidados” ou “anônimos”, realizem um conjunto limitado de transações. Para esses sistemas, as etapas adicionais para fornecer a identidade e para o sistema renderizar um veredito não são relevantes. No entanto, para qualquer identidade atestada específica, os seguintes métodos são normalmente usados para suportar essa declaraçã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.

Geralmente, se for necessário um alto nível de confiança, diversos métodos são usados. Isso fica claro no modelo Google BeyondCorp³, que exige a autenticação multifatorial (MFA) antes de permitir transações com valores mais elevados. As soluções de autenticação mais sofisticadas associam uma “confiança” a cada identidade e especificam um nível de confiança mínimo 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 únicas, mas podem e devem ser contínuas conforme o princípio da avaliação “contínua”. Nesses casos, a pontuação da confiança atribuída à declaração de identidade pode aumentar ou diminuir ao longo do tempo. Por exemplo, a identificação do navegador ou o endereço IP podem mudar em 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 agente em uma sessão, a pontuação de confiança pode aumentar ou diminuir dependendo de como o comportamento atual se compara com observações anteriores.

A autenticação dinâmica pode trabalhar em conjunto com o controle de acesso em sistemas mais avançados. Como o 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, como mencionado anteriormente. O próximo nível da interação permite que o subsistema de controle de acesso forneça o feedback para o subsistema de autenticação, normalmente pedindo que a autenticação adicional aumente a pontuação de confiança para o limite mínimo.

Após usar técnicas de autenticação para confirmar Quem está atuando em uma transação, as próximas perguntas são: O que esse agente está permitido a fazer? E Para quem? Essa é a competência das tecnologias de controle de acesso.

Para realizar uma analogia de segurança física, imagine que você deseja visitar uma base militar. Após os guardas determinarem com confiança se você é um civil, um político ou um soldado, eles usam essa determinação para decidir em quais edifícios você pode entrar e se você pode levar uma câmera para cada edifício que permitiram que você entrasse. A política que governa essas escolhas pode ser muito simples 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 podem entrar apenas nos edifícios e , mas podem levar câmeras apenas para o edifício ”).

Ao serem aplicadas no contexto de cibersegurança, as técnicas de controle de acesso devem incorporar o princípio Zero Trust de “menor privilégio”. Em outras palavras, a política de controle de acesso ideal deve apenas permitir exatamente os privilégios de que o agente precisa e proibir todos os outros privilégios. Além disso, uma política robusta ideal seria condicional em um nível mínimo específico de confiança sobre a autenticidade da identidade do agente, 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 julgado pelo quanto ela está alinhada a esses ideais. Uma solução de segurança de Zero Trust deve incluir especificamente o controle de acesso e deve avaliar a tecnologia de controle de acesso junto com as dimensões demonstradas abaixo e descritas em seguida.

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

1. Qual é a granularidade da ação — o O que na transação? Ela é:

1. Binária: permite “todas” as transações ou “nenhuma”. Na analogia da base militar, isso corresponderia a “todos os soldados podem entrar em qualquer edifício e podem fazer tudo que quiserem” e “civis não podem entrar em nenhum edifício.”
2. Simples: granular para o ponto de extremidade da API ou “tipo” de transação (como E/S de arquivos, comunicação de rede e controles de processos). Em nosso exemplo, permitiria um nível de nuance sobre a ação permitida, como “políticos podem entrar nos edifícios, mas não podem tirar fotografias”.
3. Fina: no nível sub-API (ou seja, que depende dos parâmetros ou da versão da API) ou “subtipo” de transação (como somente leitura de E/S de arquivos ou somente recebimento de TCP). Usando mais uma vez nossa analogia, permitiria controles mais refinados, como “civis podem entrar em edifícios somente se acompanhados por um soldado”.

2. Há uma granularidade de acordo com o destino da ação — o Para quem na transação? Ou seja:

1. Não granular em relação ao destino: a política de controle de acesso não considera o destino da ação. Em nosso exemplo, essa abordagem mapearia para a granularidade de permitir a entrada em alguns edifícios, mas não em outros — com edifícios sendo o destino da ação “entrar”.
2. Granular em relação ao destino, nível da infraestrutura: a política de controle de acesso pode incluir o destino da ação, mas usa algumas marcas/rótulos específicos da infraestrutura, como o endereço IP, o nome DNS, ou o nome do contêiner Kubernetes (K8S) para o destino. Isso permite que a política seja granular em relação ao edifício, mas cada base militar deve ter uma convenção de nomes diferente para os edifícios.
3. Granular em relação ao destino, com reconhecimento de identidade: a política de controle de acesso pode incluir o destino da ação, identificando o destino usando o mesmo namespace de identidade (por exemplo, SPIFFE) usado para o agente (o Quem). O benefício em relação à abordagem anterior é que todas as bases militares usariam um esquema consistente para como os edifícios são identificados, 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. Sem reconhecimento de riscos: a solução de controle de acesso trata todos os privilégios de controle de acesso de maneira idêntica, em termos de decidir se permite ou não a ação.
2. Gerenciamento de riscos por MFA: a solução de controle de acesso gerencia o risco ao permitir que a política especifique que algumas transações permitidas ainda exijam o uso da Autenticação multifatorial, com base no agente (Quem), na ação (O que), ou no destino (Para quem) envolvidos na transação.
3. Gerenciamento de riscos por confiança: a solução de controle de acesso gerencia o risco ao permitir que a política especifique se qualquer transação ainda pode exigir um nível de confiança mínimo na autenticidade do agente, com base na ação (O que) e no destino (Para quem) na transação. A MFA pode aumentar a confiança, embora outros meios possam ser utilizados; em outros casos, a transação pode não ser permitida em nenhuma hipótese se a transação tiver um alto valor e se a autenticidade do agente for suficientemente incerta.

De acordo com o princípio de “avaliar (e reavaliar) continuamente”, toda crença na autenticidade do agente deve ser ajustada ao longo do tempo. Em uma solução simples, isso pode ser apenas um tempo limite; em sistemas mais sofisticados, a confiança pode variar com base nas observações do comportamento do agente 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 da análise — um sistema não pode mitigar o que ele não pode ver. Assim, a eficácia da solução de segurança Zero Trust será diretamente proporcional à profundidade e expansão da telemetria que pode ser coletada das operações do sistema e de fora do contexto. No entanto, uma infraestrutura de visibilidade moderna será capaz de fornecer dados, metadados e contexto possivelmente muito mais úteis do que qualquer humano razoavelmente desamparado poderá gerenciar de maneira oportuna. Como resultado do desejo por mais dados e da capacidade de condensar esses dados em percepções mais rapidamente, um requisito essencial é o auxílio de máquinas para os operadores humanos.

Essa assistência normalmente é implementada usando algoritmos automatizados que englobam o espectro de análises baseadas em regras a métodos estatísticos e algoritmos avançados de aprendizado de máquina. Esses algoritmos são responsáveis por traduzir o grande fluxo de dados brutos em uma consciência situacional consumível e operacionalizada que pode ser usada por operadores humanos para avaliação e, se necessário, remediação. Por esse motivo, análises auxiliadas por ML andam de mãos dadas com a visibilidade.

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

A visibilidade é a implementação — o “como” — do princípio da abordagem Zero Trust de “avaliar continuamente”. Ela inclui manter um inventário de entrada (Catálogo) de dados disponíveis e telemetria em tempo real, além da retenção (coleta) de dados de histórico.

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

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

A latência fornece um vínculo inferior de o quão rapidamente uma possível ameaça pode ser respondida. A latência de uma solução de Zero Trust deve ser medida em segundos ou menos; caso contrário, ela será como qualquer análise — independentemente da precisão — e será muito tarde para evitar o impacto da exploração, como a criptografia/exfiltração de dados ou a indisponibilidade devido à exaustão dos 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 total visibilidade e análise sejam concluídas. Como a mitigação síncrona provavelmente adiciona latência à transação, esse modo de operação seria reservado particularmente para transações anômalas ou arriscadas, permitindo que todas as outras transações enviem telemetria e sejam analisadas de maneira assíncrona.

2. Consumabilidade: com que prontidão os dados podem ser consumidos?
   

Essa preocupação é relevante se os dados vierem de diversas origens ou tipos de sensores de dados, que é um cenário comum. Esse fator normalmente é dividido em duas sub-preocupações.

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

• No nível semântico, diferentes fontes podem não só variar em sua sintaxe e transporte, mas também na semântica. Usando o exemplo da reputação do 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 bucket 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. Integridade: 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 uma possível violação. Para fazer isso de maneira eficiente, a solução deve receber a telemetria em todas as “camadas” relevantes da entrega de aplicações: a aplicação em si, obviamente, mas também a infraestrutura das aplicações, a infraestrutura de rede e até mesmo os eventos no dispositivo cliente. Por exemplo, identificar um usuário vindo de um novo dispositivo, nunca visto antes, pode ser levemente suspeito por si só; mas, quando combinado com informações de rede (como mapeamento de GeoIP de um país estrangeiro), o nível de suspeita fica muito elevado. Esse nível de suspeita é manifestado como uma menor pontuação de confiança na identidade do usuário. No contexto de uma política de segurança de abordagem Zero Trust, quando esse agente tenta realizar uma transação de alto valor (como transferência de fundos para uma conta estrangeira), a solução de controle de acesso pode decidir 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: o quão bem os dados de estatuto e baseados em licença usam os requisitos suportados?

Por fim, toda coleta de dados deve estar em conformidade com os requisitos de estatutos e licenças reativos à segurança, à retenção e ao uso de dados. Portanto, uma solução de visibilidade robusta deve atender a cada uma dessas necessidades. A compreensão das restrições sobre o uso de dados implicadas pela governança deve ser fatorada em uma solução de visibilidade de abordagem Zero Trust. Por exemplo, se um IP for considerado como Informações de identificação pessoal (PII), então o uso e a retenção em 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 nos algoritmos de análise podem ser limitadas a um único fluxo de dados de uma única fonte, ou podem buscar em diversos fluxos, incluindo de várias fontes de dados e todas as camadas da infraestrutura e da 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 entre diversos usuários. Essa análise pode resultar em algumas percepções mais básicas, como “esse usuário nunca fez login durante esse horário do dia” ou “parece que esse usuário sempre faz login imediatamente após outro usuário ”. Aquela pode reduzir a confiança na identidade, enquanto esta pode ser um indicativo de algum padrão de nível mais elevado, talvez mal intencionado.
• Uma contextualização mais avançada considera o escopo baseado em tempo e de diversas instâncias não só para um único “tipo” de dados, mas também realiza uma correlação de tempo entre diferentes “tipos” ou “fluxos” de dados. Um exemplo seria a correlação dos dados de login do usuário com ações específicas na camada de aplicações (como transferência de dinheiro ou atualizações de contato de email) ou na camada da rede (como uma pesquisa de localização geográfica baseada em IP).

Um segundo aspecto particularmente relevante da análise na estrutura Zero Trust é lidar com o volume e a taxa de dados ingeridos, que excederá a capacidade de ingestão de qualquer humano. Portanto, algum tipo de assistência de máquina para formar percepções que possam ser ingeridas por humanos é necessário. Novamente, a sofisticação da assistência pode ser descrita como uma progressão.

• Apenas visualização: a primeira etapa é a pura apresentação 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 cruzada longitudinal entre usuários/transações em uma janela de tempo fixa). Painéis mais avançados oferecem a capacidade de classificar e agrupar os dados, bem como fazer drill-down por meio da filtragem. Nesse modelo, o humano realiza toda a exploração de dados, priorização de eventos, análise e remediação, com a automação ajudando principalmente na exploração de dados.
• Visualização, além de regras estáticas configuráveis: a próxima extensão da visualização mais comum é a capacidade de permitir que os humanos definam regras especificadas estaticamente, seja para alertas ou remediação. Exemplos dessas regras seriam “notificar o humano <John> se <a carga da CPU excede 80% por um período de 5 minutos>” ou “exigir <MFA por e-mail> se <a API [Y] for invocada e se o país não for [Estados Unidos]>”. Essas regras podem ser limitadas para regras predefinidas especificadas pelo provedor da solução, ou subsistemas baseados em regras mais avançadas também podem permitir regras personalizadas criadas por um engenheiro de SecOps. Em qualquer caso, todas as regras aplicadas são controladas (e definidas, se necessário) normalmente por meio da configuração.
• Visualização, além de assistência de ML: o próximo nível usa técnicas mais avançadas que descobrem anomalias comportamentais e/ou transações que correspondem a padrões de transações mal intencionadas identificadas anteriormente. Embora haja muitas técnicas utilizadas (e uma profunda discussão das compensações técnicas e comerciais está fora do escopo desse artigo), há alguns pontos principais 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 algum corpus de dados de tamanho razoável deve ser pré-categorizado usando um “classificador” confiável. Geralmente, para se ter uma categorização confiável, o “classificador” acaba sendo um humano ou um grupo de humanos. Nesses casos, o esforço humano necessário deve ser levado em conta. Outras técnicas (também conhecidas como aprendizado não supervisionado) detectam anomalias e/ou reconhecem padrões por si só, sem o esforço humano.
• Explicabilidade: a saída gerada do sistema de aprendizado de máquina resulta da avaliação dos dados de entrada em relação a um modelo. Esse modelo pode ser baseado em uma série de perguntas de resposta simples como, “Esse usuário foi visto nesse dispositivo no último mês?” ele também pode ser baseado em uma similaridade facilmente explicada, como “esse usuário segue o padrão geral que vejo em usuário 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 com vetores nos dados de entrada, sem uma lógica de alto nível facilmente discernível. Esse último caso, claramente, é mais difícil de explicar — mais como uma “caixa preta”— do que os dois exemplos anteriores. Em alguns casos, a explicabilidade é um fator importante para a compreensão humana ou a capacidade de auditoria. Para esses casos, um modelo explicável terá uma preferência muito maior em relação a um inescrutável.
• Disponibilidade da pontuação de confiança: como mencionado anteriormente, uma métrica que indique o quão confiante o modelo está para uma decisão — em outras palavras, uma ideia da probabilidade relativa de um falso positivo ou falso negativo — geralmente é muito útil. Em alguns algoritmos, a saída da métrica de confiança é gerada naturalmente; em outros, como os baseados em regras, um nível de confiança precisa ser especificado explicitamente como uma das saídas. Em qualquer um dos casos, algoritmos que fornecem uma pontuação de confiança são mais robustos do que os que não o fazem.

Assim como com a abordagem baseada em regras, a assistência de ML pode ser para a detecção apenas ou pode estar vinculada à remediação automática. Além disso, a assistência de ML pode ser usada em conjunto com um sistema baseado em regras, em que o “veredito” (ou opinião ou confiança) da ML pode ser usado como uma entrada em uma regra, como “realizar a ação se ”.

O princípio final da mentalidade Zero Trust é “presumir a violação”. Para esclarecimento e fornecer uma perspectiva, métodos implementados de autenticação e controle de acesso são eficientes na prevenção da esmagadora maioria de transações mal intencionadas. No entanto, por uma grande paranoia, alguém pode presumir que os mecanismos de aplicação da autenticação e do controle de acesso serão derrotados por algum adversário sortudo ou suficientemente motivado. A detecção de violações, necessária para responder a essas escapadas de maneira oportuna, requer a visibilidade e análises auxiliadas por máquina. Portanto, é pelo fato de que outros mecanismos de aplicação serão derrotados ocasionalmente que as tecnologias de visibilidade que alimentam as análises contextuais auxiliadas por ML são uma necessidade essencial para suportar a solução de remediação baseada em riscos da segurança Zero Trust.

Para os casos de “falsos negativos”, em que uma transação mal intencionada real derrotou a autenticação e o controle de acesso, o mecanismo de remediação automatizada baseada em riscos deve ser usado como uma barreira. Mas, como essa tecnologia é aplicada como uma barreira contra transações que passaram pelas verificações de aplicação anteriores, há uma preocupação maior em relação à marcação incorreta do que era, na verdade, um “negativo verdadeiro” (uma transação válida desejável) em “falso positivo” (marcado incorretamente como transação mal intencionada). Para mitigar essa preocupação, todas as ações de remediação acionadas por uma crença em uma possível má intenção, que, por algum motivo, não foi pega pela autenticação ou pelo 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 de visualização de 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 um bilhete é provavelmente uma transação de recompensa comercial maior em relação a uma transação que liste os voos atualmente atrasados. O valor comercial é o benefício da possível recompensa comercial ponderada em relação ao perfil de risco da transação. É mais aceitável tolerar qualquer efeito de “falso positivo” da remediação especulativa a transações de baixa recompensa/alto risco, em comparação com transações de alta recompensa/baixo risco que tenham um alto valor comercial.
• Confiança na crença de “má intenção”: obviamente, nem todas as sugestões para remediação especulativa são iguais. Especificamente, além do risco-recompensa mencionado acima, o outro fator principal é a confiança nas crenças em relação a essa transação, como a confiança na identidade declarado do agente. De modo geral, a probabilidade de “falso negativo” — ou seja, a probabilidade de os mecanismos de aplicação não terem sido acionados, mas que deveriam — é inversamente proporcional à confiança no agente. E, como a redução de “falsos negativos” é o objetivo da remediação baseada em riscos, quanto menor a confiança, mais enviesado 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 riscos é possível, variando de algumas visíveis ao usuário (por exemplo, ao pedir credenciais adicionais/MFA, fornecer um desafio como captcha), a outras que são, em sua maioria, invisíveis ao usuário (realização de uma inspeção de tráfego mais profunda como DLP, ou a realização de uma análise de alta computação/mais avançada). Portanto, o impacto da realização dessas formas adicionais de redução de riscos — conforme medido pelo atrito experimentado pelo usuário e pelos custos operacionais para a aplicação (como para DLP ou análises de alta computação) — é o terceiro fator a ser considerado. Remediações transparentes para o usuário de baixo impacto têm preferência em relação a desafios visíveis para o cliente de maior impacto e, francamente, bloquear a transação é a opção menos atrativa. No entanto, o bloqueio pode ser adequado quando a confiança for alta, ou para transações arriscadas que não podem aumentar de maneira suficiente a confiança por meio dos outros mecanismos de redução de riscos.

A segurança Zero Trust é uma abordagem mais moderna em relação a abordagens anteriores à segurança como a defesa em profundidade, estendendo o método anterior ao assumir uma visão centrada na transação sobre a segurança — Quem está tentando fazer O que Para quem. Essa abordagem permite a proteção não só do acesso externo a uma aplicação, mas também a proteção de elementos internos da aplicação.⁵ Por essa visualização transacional fundamental, a segurança Zero Trust está enraizada em um conjunto de princípios fundamentais que são usados para defender aplicações no ambiente mais complexo e desafiador de hoje, com os princípios sendo mapeados para um conjunto de soluções de nível do sub-sistema, ou métodos, que englobam esses princípios. Os princípios fundamentais e a maneira como eles são mapeados para os métodos da solução estão descritos a seguir.

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