A defesa resiliente da Okta: uma análise aprofundada da ITDR com IA

Enquanto você lia esta frase, milhares de tentativas de login mal-intencionadas estavam sendo feitas ao redor do mundo. A escala e a complexidade dos ataques baseados em identidade são surpreendentes, com as ameaças evoluindo a cada dia. Em 2025, somente a Okta bloqueou mais de 15 bilhões de logins mal-intencionados em mais de 10 mil organizações. Como é que uma organização conseguiria acompanhar esse ritmo? A resposta não está em construir uma única parede forte, mas em desenvolver a arquitetura de uma defesa mais inteligente e responsiva. Esse é o princípio fundamental por trás da detecção e resposta a ameaças de identidade (ITDR) impulsionadas por IA. Nesta análise aprofundada, desvendaremos a arquitetura da plataforma de segurança da Okta, apresentando um plano de como a prevenção inline e a análise offline colaboram para criar uma defesa verdadeiramente resiliente.

Em um artigo anterior, apresentamos o conceito de defesas em camadas. Neste artigo, vamos explorar a arquitetura completa. Abordaremos estes três tópicos:

1. A arquitetura das nossas defesas inline. As defesas inline são como os guardas no portão, protegendo os usuários em tempo real enquanto interagem diretamente com a Okta.
2. A arquitetura das nossas defesas offline. As defesas offline são como os sistemas de vigilância que protegem as identidades de forma contínua, analisando os sinais de segurança da Okta e de terceiros.
3. Recomendações essenciais para proteger os locatários da Okta.

Por que precisamos de defesas inline e offline?

Detectamos e corrigimos ataques tanto inline, no caminho das solicitações da web para a Okta (por exemplo, tentativas de login, inscrições de usuários), quanto offline, como uma reação a eventos de segurança (por exemplo, um fornecedor de segurança detecta malware no dispositivo de um usuário).

Uma combinação de defesas inline e offline é necessária pelos motivos a seguir.

1. Depois que o usuário utiliza a Okta para realizar o login único em um aplicativo de terceiros, ele interage com esse aplicativo até que o token permaneça válido. A Okta não está no caminho dessas requisições da web e depende de sinais offline do dispositivo, do aplicativo de terceiros e de parceiros (por exemplo, ZTNA, SASE, fornecedores de EDR) para detectar ataques.
2. As detecções inline devem ser executadas muito rapidamente (em poucos milissegundos), para não prejudicar a experiência de usuários legítimos. Alguns ataques sofisticados não podem ser identificados com alta precisão, pelas detecções inline.

O diagrama abaixo captura a visão geral de alto nível das defesas inline e offline. Como mostra o diagrama, os eventos assíncronos gerados pelas defesas inline, juntamente com os sinais de terceiros, se tornam uma entrada para as defesas offline. Os tipos de ações que podemos realizar inline (por exemplo, bloqueio ou MFA) são diferentes e complementares às ações que podemos realizar offline (como o Universal Logout ou executar fluxos de trabalho).

Defesas inline

A Okta processa mais de 100 milhões de logins e 100 mil novas inscrições de usuários todos os dias. As defesas multicamadas descritas abaixo são executadas para atender a essas solicitações. Nos últimos 18 meses, introduzimos as camadas a seguir (negrito e itálico nas caixas azuis), além das camadas existentes descritas no artigo anterior.

Agora, gostaríamos de analisar as inovações recentes nas defesas inline.

Zonas dinâmicas aprimoradas

Os invasores costumam usar proxies de anonimato, proxies residenciais e certos tipos de VPNs para ocultar a própria localização e iniciar ataques como preenchimento de credenciais e sequestro de sessão. Para detectar esses ataques, introduzimos o suporte para zonas dinâmicas aprimoradas. Agora, os clientes podem criar zonas de rede com base em uma combinação de categorias de serviço de IP (tipos específicos de proxies de anonimato, proxies residenciais e VPNs), localizações geográficas e ASNs (números de sistemas autônomos). Essas zonas podem ser usadas como listas de bloqueio ou configuradas como condições nas políticas de autenticação, MFA e outras. 

Você pode usar as zonas para dar suporte a vários casos de uso. Por exemplo:

1. Bloqueie todas as solicitações ao locatário provenientes de qualquer proxy de anonimato, exceto os permitidos pelas suas políticas de segurança.
2. Solicite o uso de MFA para logins provenientes de tipos específicos de VPNs, permitindo todo o restante do tráfego.
3. Negue a inscrição de MFA a partir de uma combinação de ASNs, países e tipos de proxy.

Depois desse recurso, passamos a avaliar os metadados de IP para cada solicitação que chega à Okta, um avanço importante. Em 2025, mais de mil clientes da Okta utilizaram esse recurso para bloquear mais de um bilhão de solicitações mal-intencionadas.

O diagrama abaixo apresenta a arquitetura de alto nível para a ingestão de feeds de metadados de IP de terceiros e a disponibilização desses para consultas extremamente rápidas. Esses feeds fornecem geolocalização e outros metadados de IP, como categorias de serviços de IP.

Essa arquitetura alcança dois objetivos principais:

1. Qualidade aprimorada: para reduzir o risco de falsos positivos e falsos negativos, criamos um pipeline offline que atualiza os metadados de IP assim que os fornecedores terceirizados disponibilizarem os dados.
2. Latência reduzida: para reduzir os tempos de resposta das solicitações, projetamos a camada de aplicação para consultar metadados de IP de vários fornecedores em milissegundos de um único dígito.

Proteção de BOT

Bots mal-intencionados estão envolvidos em muitos ataques de alto volume baseados em credenciais, como criação fraudulenta de contas e ataques de pulverização de senhas. Para combater essas ameaças, anunciamos recentemente a versão beta do Bot Protection, que complementa o ThreatInsight para bloquear ataques baseados em credenciais pelas maneiras a seguir.

1. Detecção: o ThreatInsight foi desenvolvido para detectar IPs envolvidos em ataques de login. O Bot Protection detecta bots com base em sinais além do IP envolvido, não apenas no login, mas também em ataques de cadastro e recuperação. 
2. Remediação: o ThreatInsight permite bloquear ou registrar como opções de remediação. O bloqueio é uma ação sólida de remediação. Com um bloqueio, o custo dos falsos positivos é alto. O Bot Protection permite que os clientes configurem um desafio de prova de trabalho mais leve como ação de remediação. Isso introduz obstáculos para os bots e garante o mínimo de atrito para usuários legítimos.
3. Configuração: o Bot Protection permite que os clientes configurem a remediação com base em sua tolerância ao risco. Dessa forma, é possível ajustar o recurso para otimizar entre falsos positivos e falsos negativos, mantendo a precisão necessária.

Utilizamos o imenso volume de dados de ataques que a Okta coletou ao longo dos anos com o objetivo de criar heurísticas e modelos de aprendizado de máquina para identificar bots.

Identity Threat Protection: avaliação do contexto da sessão

Após a autenticação de um usuário, o risco não desaparece. O Identity Threat Protection agora inclui a avaliação inline das mudanças no contexto da sessão para detectar ameaças pós-autenticação. Esse recurso avalia continuamente as sessões para detectar qualquer indicação de uma sessão sequestrada. Sempre que o IP ou o contexto do dispositivo muda, avaliamos o risco da sessão executando um modelo de aprendizado de máquina para determinar o nível de risco. O modelo identifica o grau de anomalia da solicitação em comparação com a linha de base do usuário em questão. 

Caso a sessão seja considerada arriscada, os clientes poderão configurar políticas para reavaliar todas as políticas globais e de acesso a aplicativos. As mesmas políticas são avaliadas antes que uma sessão seja concedida. A avaliação de políticas não apenas no contexto de um login, mas também de modo contínuo em reação a qualquer alteração no contexto da sessão, permite que a Okta ofereça uma autenticação contínua verdadeira. 

Recomendamos a leitura deste artigo para compreender os detalhes da autenticação contínua.

Defesas offline

Nossas defesas offline orientadas por eventos analisam sinais de segurança obtidos em uma ampla variedade de fontes continuamente, para identificar ameaças e responder a elas de forma proativa.

Identity Threat Protection: avaliação contínua de risco do usuário

O Identity Threat Protection vai além da análise inline. Ingerimos e analisamos continuamente uma ampla gama de eventos de segurança provenientes de fontes próprias e de terceiros. Utilizamos uma combinação de modelos de heurística e aprendizado de máquina offline para estimar o nível de risco de um usuário de modo contínuo. O cliente poderá configurar políticas para realizar ações automatizadas quando um usuário for sinalizado como de alto risco, como iniciar um Universal Logout para desconectar o usuário da Okta e de todos os aplicativos em que ele estiver conectado. Em 2025, o Identity Threat Protection sinalizou mais de 70 mil usuários de alto risco. Leia este artigo para ter uma visão mais detalhada do impacto real do Identity Threat Protection.

O diagrama abaixo descreve a arquitetura de alto nível para ingerir sinais de várias fontes e processar essas informações de forma assíncrona, a fim de atualizar e remediar o risco do usuário.

Ingestão de sinais de terceiros

A maioria dos clientes usa a Okta em conjunto com outros produtos de segurança de terceiros. Muitos produtos de segurança funcionam isoladamente, e é extremamente desafiador para os clientes integrarem os sinais de vários produtos ao planejarem detectar e bloquear ataques baseados na identidade. Nossa inovação com o padrão OpenID Shared Signals Framework aborda esse desafio. O Identity Threat Protection permite que os clientes configurem a Okta para trocar sinais de segurança com seus produtos de segurança existentes (ZTNA, WAF, SASE, EDR etc.). Uma troca de sinais baseada em padrões possibilita uma integração contínua e segura, beneficiando tanto os fornecedores de segurança quanto os clientes.

Sinais próprios da Okta

O Identity Threat Protection ingere sinais de várias fontes nativas da Okta. Por exemplo:

1. Ingerimos feeds de ameaças produzidos pela equipe Okta Threat Intelligence. Esses feeds incluem indicadores de comprometimento associados à infraestrutura mal-intencionada de phishing como serviço. Isso permite que os clientes realizem ações automatizadas de remediação, como o Universal Logout, com base nos insights acionáveis gerados por nossa equipe de pesquisa de ameaças. 
2. Nós ingerimos sinais do dispositivo (por exemplo, status de gerenciamento do dispositivo, se o dispositivo foi desbloqueado por jailbreak, sinais do software EDR instalado no dispositivo) do Okta Verify de forma contínua para construir um contexto detalhado do dispositivo. Esse contexto do dispositivo é usado para avaliar continuamente o risco associado ao usuário e à sessão.
3. Ingerimos eventos de log do sistema Okta continuamente em um data lake para executar modelos de heurística e aprendizado de máquina offline para sinalizar usuários de risco e IPs mal-intencionados.

Breached Credential Protection

De acordo com algumas estimativas, existem mais de 50 bilhões de credenciais violadas na dark web. Os invasores utilizam esses dados para realizar grandes ataques baseados em credenciais. O Breached Credential Protection (agora disponível para o público geral) integra-se a provedores terceirizados para verificar continuamente se as credenciais dos usuários apareceram em violações de dados conhecidas. Caso uma correspondência seja encontrada, podemos expirar automaticamente a senha comprometida e encerrar todas as sessões ativas, impedindo que um invasor use as credenciais roubadas. 

Construímos uma arquitetura altamente escalável que é capaz de baixar grandes bancos de dados, processá-los e disponibilizá-los para consultas de latência muito baixa, após uma autenticação bem-sucedida baseada em senha.

O diagrama abaixo captura a arquitetura de alto nível para ingerir bilhões de dados de credenciais violadas de vários fornecedores e como esses dados são usados para detectar e corrigir violações.

Após entrar em disponibilidade geral, o Breached Credential Protection sinalizou, em três meses, 1,7 milhão de credenciais comprometidas e redefiniu 770 mil credenciais.

A inteligência unificadora: como a IA liga os pontos

Nem a camada inline nem a offline operam isoladamente. O verdadeiro poder dessa arquitetura está no nosso mecanismo de detecção baseado em IA, que unifica os dados de ambas. No centro desse mecanismo de detecção estão os dados de uso verdadeiramente únicos (por exemplo, IPs, uso de aplicativos, validações de credenciais, uso de dispositivos etc.) que a Okta coleta no pipeline de identidade em torno de bilhões de logins todos os meses. Tais dados de uso abrangentes, em conjunto com os dados rotulados de ataques conhecidos, são usados para treinar modelos de aprendizado de máquina offline e inline para bloquear ataques sofisticados com base em identidade. Por exemplo:

1. Utilizamos um modelo de aprendizado de máquina offline para identificar IPs mal-intencionados envolvidos em grandes ataques baseados em credenciais. Procuramos padrões relacionados a ataques de pulverização de senhas, taxas de login, taxas de falha, tipos de falhas etc. a fim de identificar esses IPs. A pulverização de senhas é um ataque interessante baseado em credenciais. Nesse tipo de ataque, os invasores automatizam a verificação de uma senha em várias contas de usuário. A Okta rastreia o uso dessas senhas entre usuários e organizações para identificá-las e bloquear as tentativas.
2. Utilizamos um modelo de aprendizado de máquina offline para identificar IPs envolvidos em ataques de phishing, com base em sinais provenientes de tentativas bloqueadas pelo FastPass.
3. Utilizamos um modelo de aprendizado de máquina inline para identificar ataques de roubo de conta e sequestro de sessão. O modelo de aprendizado de máquina determina se a solicitação se desvia da linha de base (endereços IP confiáveis, dispositivos confiáveis, locais confiáveis etc.) que estabelecemos para os usuários de acordo com os logins bem-sucedidos.
4. Utilizamos um modelo de aprendizado de máquina inline para identificar solicitações suspeitas com base em vários atributos no nível da solicitação. Assim, podemos aplicar um limite de taxa a essas solicitações separadamente das solicitações legítimas feitas à organização.

Principais recomendações 

1. Ative o ThreatInsight, o Enhanced Dynamic Zones e o Bot Protection para bloquear ataques automatizados em grande escala na entrada, de forma proativa.
2. Ative o Breached Credential Detection para neutralizar instantaneamente as ameaças provenientes de credenciais comprometidas em violações de terceiros.
3. Ative o Identity Threat Protection para ter autenticação contínua verdadeira e responder a ameaças pós-autenticação em tempo real.

Conclusão

Recomendamos que você utilize esta análise aprofundada como uma ferramenta para examinar seu próprio nível de segurança. Suas defesas estão funcionando em conjunto? Você está utilizando a IA para detectar o indetectável? Buscar outras ferramentas além das tradicionais e isoladas e adotar uma estrutura de ITDR integrada e com tecnologia de IA é o próximo passo definitivo para proteger as identidades e os ativos contra o cenário de ameaça moderno.