Segurança Focada em Identidade: Por Que o Perímetro Morreu Definitivamente e o Que o Substitui

Os atacantes há muito tempo pararam de tentar quebrar muros; eles entram pela porta com credenciais legítimas. Analisamos por que o modelo de perímetro: "firewall + VPN + círculo de confiança" é estruturalmente insustentável, como o identificador se torna o novo plano de controle de segurança e o que muda com o surgimento de agentes de IA como uma classe independente de sujeitos.

O Cenário Que Inicia um Hack Típico em 2026

Um funcionário de uma empresa abre um e-mail de phishing, clica em um link e seu laptop é infectado com um infostealer. Em poucos minutos, o malware extrai o que está no navegador: senhas salvas, arquivos cookie, sessões SSO ativas do Entra ID e serviços em nuvem. Em 24 horas, o log é enviado para um marketplace sombrio, onde é vendido por dezenas de dólares. Poucos dias depois, o atacante abre o navegador, insere a sessão roubada e faz login no SaaS corporativo. O MFA não é acionado: o token já está autenticado. O firewall não vê nada: é apenas HTTPS com um User-Agent legítimo.

De acordo com o relatório Verizon DBIR 2025 (uma fonte respeitada em segurança da informação), o abuso de credenciais é o vetor de acesso inicial dominante pelo segundo ano consecutivo: 22% de todas as violações confirmadas começam com credenciais roubadas, e em aplicações web esse número chega a 88%. 54% das vítimas de ransomware tiveram comprometimento prévio em logs de infostealers antes do ataque. No ano passado, infostealers roubaram 1,8 bilhão de credenciais e foram responsáveis por 86% das violações.

A um atacante, muitas vezes, não é necessário um exploit. Não é necessário um 0-day. Não é necessário contornar um NGFW. Basta que exista um usuário, que o usuário tenha credenciais e que as credenciais tenham uma sessão ativa.

Esta é uma crise estrutural do modelo de perímetro. E resolvê-la com um "firewall mais espesso" e um "churrasco" escalonado de sistemas de segurança é inútil.

Por Que "O Perímetro Morreu" Não é uma Metáfora, Mas um Fato de Infraestrutura

A segurança tradicional se baseava em uma premissa simples: dentro da rede corporativa – confiável, fora – hostil. Entre eles – firewall, VPN, proxy. Essa premissa se desfez em três frentes simultaneamente.

• Trabalho Híbrido e BYOD: Em 2025, 46% dos dispositivos com credenciais corporativas em logs de infostealers eram não gerenciados – laptops pessoais, computadores domésticos, dispositivos de contratados. Essas máquinas não estão "dentro do perímetro" por definição, mas têm acesso a recursos corporativos via SSO e VPN.
• SaaS e Multicloud: Dados corporativos não residem mais em um único data center. Eles estão distribuídos por dezenas de serviços externos – Bitrix24, amoCRM, GitHub, Atlassian, Yandex 360, VK WorkSpace, MoiOffice. Nenhum desses serviços está fisicamente fora do seu perímetro, e o acesso a eles é impossível de controlar através de um firewall clássico.
• Identidades de Máquina (NHI): Esta é a mudança mais subestimada. De acordo com a CyberArk, em grandes organizações, as identidades de máquina superam as humanas na proporção de 45:1 (Reddit/CyberArk); Veza, no State of Identity 2026, dá uma estimativa mais conservadora – 17:1 em média de mercado (Veza). Cada chave de API, token OAuth, conta de serviço, runner de CI/CD – é uma identidade separada, sem rosto, sem dispositivo corporativo, sem ciclo de vida claro. Embora o cenário de TI doméstico ainda esteja atrasado em relação ao global, levará meses, não anos, para que a situação em nossas empresas seja exatamente a mesma.

O perímetro não está "morrendo" – ele já está morto. A questão é o que o substitui.

O Identificador Como o Novo Plano de Controle

Se a fronteira "dentro / fora" não funciona mais, onde a decisão de acesso é tomada? A resposta está se consolidando gradualmente na indústria: no identificador. Cada solicitação a um recurso começa com um evento de identificação – autenticação ou autorização, e este é o único ponto estável através do qual todos os outros caminhos passam.

Gartner formula isso explicitamente: as organizações devem adotar a segurança focada em identidade (identity-first security), onde os controles no nível de identidade se tornam o alicerce da arquitetura, e não apenas uma de suas camadas.

Na prática, isso significa três coisas:

1. O identificador deixa de ser um sistema IAM separado e se torna um plano de controle para toda a arquitetura de segurança: NGFW, EDR, SWG, SIEM começam a tomar decisões com base no contexto de identidade.
2. Cada solicitação de acesso é avaliada em tempo real com base na composição "quem (identificador) + de onde (estado do dispositivo) + em que contexto (geolocalização, comportamento, avaliação de risco)".
3. A autenticação deixa de ser um evento único. A confiança é reavaliada continuamente, a cada solicitação.

Uma arquitetura madura se baseia em cinco componentes:

ZTNA vs. VPN: A Transição Se Tornou Obrigatória

Historicamente, a VPN resolvia uma tarefa: "estender o perímetro" para o usuário remoto. Do ponto de vista da segurança focada em identidade, este é um modelo estruturalmente falho: o usuário obtém acesso à rede a um grande segmento, a seguir operam ACLs de rede, o movimento lateral é possível por padrão, o contexto da sessão não é reavaliado após o estabelecimento do túnel.

ZTNA muda o nível de controle. O acesso é concedido não à rede, mas a uma aplicação específica. A decisão é tomada no momento da solicitação, levando em conta o identificador, o estado do dispositivo e o contexto. Não há túnel "para algum lugar dentro" – há um proxy no nível da aplicação com autorização contínua.

Comparação em uma tabela:

Gartner prevê que até 2027, 80% das empresas desenvolverão uma estratégia unificada de acesso a aplicações web, em nuvem e internas via ZTNA.

Nós, na Ideco, integramos a funcionalidade ZTNA diretamente ao nosso NGFW, sem um gateway separado ou um broker em nuvem – escrevemos detalhadamente sobre a arquitetura dessa abordagem e os cenários de migração de VPN anteriormente.

Roadmap Prático de Migração de VPN para ZTNA:

1. Auditoria das políticas VPN existentes e da área de acesso real.
2. Inventário de aplicações e serviços críticos, priorização.
3. Implantação paralela de ZTNA ao lado da infraestrutura VPN ativa.
4. Migração de usuários remotos e acesso de contratados em primeiro lugar.
5. Aplicação forçada de políticas de privilégios mínimos necessários às aplicações.
6. Desativação de concentradores VPN com amplo acesso no nível de rede.
7. Integração de telemetria ZTNA em SecOps/SIEM como um sinal de identidade.

O erro crucial é tentar "modernizar a VPN". São modelos de confiança diferentes. Um concentrador VPN pode permanecer como transporte, mas o plano de identidade deve gerenciar o acesso.

Casos Reais de 2025: Como a Identidade Se Tornou o Principal Caminho Para Dentro

Os incidentes, e não os relatórios, explicam melhor a necessidade de segurança focada em identidade. 2025 proporcionou à indústria uma coleção tão densa de confirmações que argumentar contra a tese "o identificador é o perímetro" tornou-se praticamente impossível. Vamos analisar cinco incidentes do ano passado – dois russos e três globais, cada um ilustrando sua classe de vulnerabilidades no plano de identidade.

• Aeroflot / Silent Crow + "Ciberpartisans" (Julho de 2025): O ataque cibernético aberto mais destrutivo a uma empresa russa até hoje. Os atacantes primeiro invadiram a rede da "Bakka Soft" – um contratado que desenvolvia aplicações móveis e web para a Aeroflot. A primeira invasão foi detectada em janeiro de 2025 e expulsa, mas em maio os atacantes retornaram. Através da "Bakka Soft", eles obtiveram acesso administrativo remoto à infraestrutura da Aeroflot. Em 28 de julho, lançaram um wipe em cerca de 10 mil estações de trabalho, "mataram e apagaram" o domínio AD – sem comunicação com o controlador de domínio, os balcões de check-in nos aeroportos pararam de funcionar. Resultado: cancelamento e atraso de centenas de voos, colapso de transporte em Sheremetyevo, publicação de mais de 20 TB de dados internos (incluindo a estratégia de segurança e prontuários médicos de pilotos), perdas diretas da Aeroflot – pelo menos 260 milhões de rublos apenas de voos cancelados, dano total – dezenas de milhões de dólares. O próprio hack, de acordo com a análise do The Bell, "foi banal" – usou ferramentas padrão. Conclusão chave de identidade: o atacante nunca "quebrou" a Aeroflot por fora. Ele veio com credenciais administrativas válidas de um contratado que tinha acesso direto à produção sem segmentação e sem o princípio de privilégios mínimos (Meduza/The Bell).

• Salesloft Drift / UNC6395 (Agosto de 2025): Um caso exemplar de ataque à cadeia de suprimentos OAuth. De março a junho, os atacantes se estabeleceram no ambiente GitHub da Salesloft, em agosto invadiram o contorno AWS de sua subsidiária Drift e extraíram tokens de atualização OAuth emitidos para mais de 700 organizações para integrar o Drift com Salesforce, Google Workspace, Slack e plataformas em nuvem. De 8 a 18 de agosto, o ator acessou o Salesforce dos clientes através de tokens legítimos, extraindo chaves AWS, senhas e outros segredos dos campos CRM, e apagando os logs de solicitação. Na lista de vítimas confirmadas estão Cloudflare, Zscaler, Proofpoint, Tenable, Cisco, Palo Alto Networks, Qualys (CSA, BlackFog). Característica distintiva: as vítimas foram comprometidas não por suas falhas, mas pelos direitos excessivos concedidos a uma aplicação OAuth de terceiros e tokens de atualização perpétuos que ninguém rotacionava.

• Salesforce / ShinyHunters (Google, Workday e outros, Verão de 2025): Um episódio paralelo, mas com física diferente. O grupo ShinyHunters (UNC6040, parcialmente associado ao Scattered Spider) usou phishing por voz (vishing) e engenharia social para convencer funcionários a aprovar uma aplicação OAuth maliciosa no Salesforce ou fornecer um código MFA. Resultado no verão de 2025: vazamento do Google (cerca de 2,5 milhões de registros de CRM de clientes para PMEs), da Workday – dados de até 11 mil clientes corporativos e 70 milhões de registros de usuários, incidentes confirmados em Cisco, Adidas, Allianz Life. As próprias plataformas Salesforce não tinham vulnerabilidades – todo o ataque foi construído em torno do fluxo de consentimento do usuário OAuth e do contorno de MFA através de um operador humano (BlackFog, The Hacker News).

• Bybit / Lazarus – Safe Wallet (Fevereiro de 2025, US$ 1,4 bilhão): O maior hack de criptomoedas da história – e um caso quase exemplar de comprometimento de identidade de máquina na cadeia de suprimentos. A norte-coreana Lazarus comprometeu a máquina de trabalho de um desenvolvedor da Safe Wallet – uma plataforma de carteiras multi-assinatura usada pela Bybit. Um JavaScript foi implantado no computador do desenvolvedor, que foi implantado na interface web de produção da Safe e substituiu seletivamente dados em transações enviadas para as carteiras de hardware da Bybit. Três signatários no esquema 3 de 6 confirmaram o DelegateCall para um contrato malicioso, vendo uma transferência inofensiva na tela. Resultado: 400.000 ETH no valor de cerca de US$ 1,1 bilhão e mais tokens no valor de cerca de US$ 300 milhões (Cyfrin, Curvegrid). Nenhum exploit na Bybit, nenhum comprometimento de conta de usuário. A identidade que Lazarus usou para a invasão pertencia a um engenheiro contratado.

• RosElTorg / Yellow Drift (2025): Ataque à maior plataforma russa de comércio eletrônico federal para compras estatais e corporativas. Os atacantes apagaram cerca de 550 TB de dados, incluindo e-mails internos e backups, afetando agências governamentais e fornecedores que realizavam compras. Aqui, duas características das grandes infraestruturas russas são particularmente evidentes – a abundância de contas de serviço privilegiadas e o controle fraco de seu ciclo de vida.

O denominador comum de todos os cinco casos: nenhum deles envolveu um hack clássico de perímetro. Nem um exploit em um serviço público, nem arrombamento de firewall – em todos os casos, o atacante veio com uma identidade ativa: credenciais de administrador de contratado, token OAuth de integração, token de atualização sem rotação, sessão privilegiada de desenvolvedor. E em todos os casos, o mesmo defeito estrutural é visível – identidade com privilégios excessivos, sem proprietário, sem rotação e sem reavaliação de risco após a emissão.

Agentes de IA: A Próxima Camada de Identidades e uma Nova Classe de Ameaças

Se NHI já é complexo, os agentes de IA complicam a imagem em uma ordem de magnitude. São entidades autônomas que obtêm acesso a sistemas corporativos via MCP, OAuth, tokens de API e frequentemente herdam os direitos do usuário em nome do qual agem. Eles tomam decisões por si mesmos (e de forma não determinística). Chamam ferramentas por si mesmos. E escalam em velocidade de máquina, não dando às redes neurais "biológicas" tempo para reagir.

Especificidade estrutural da ameaça para o modelo de identidade:

• Agente de IA comprometido – rota direta para sistemas internos com os direitos do agente, não do atacante.
• Movimentação pela infraestrutura, exfiltração e escalonamento de privilégios ocorrem em velocidade de máquina: o analista de SOC não tem tempo de reagir no ritmo humano.
• Um token OAuth padrão emitido para um humano é muito amplo para um agente. Ele carrega consigo o papel, o departamento, o conjunto de aplicações – tudo o que o usuário "já tem". Para um agente, isso é muito contexto e muitos direitos.
• MCP como nova superfície de ataque.

Model Context Protocol sobre JSON-RPC 2.0 tornou-se o padrão de fato para conectar agentes a ferramentas, e aqui podemos tropeçar nas mesmas pedras. A especificação oficial do MCP reconhece: o protocolo "não pode fornecer princípios de segurança no nível do protocolo". OWASP MCP Top 10 (2025) registra os principais riscos: injeções de prompt, abuso de confiança (confused deputy) através de erros de configuração OAuth, cadeia de suprimentos através de pacotes MCP substituídos. CVE-2025-49596 (CVSS 9.4) permitia a execução de comandos arbitrários através de instâncias não autorizadas do MCP Inspector. O primeiro pacote MCP malicioso em registros públicos foi detectado em setembro de 2025.

O que deve estar entre o agente de IA e os sistemas corporativos:

• Identificadores efêmeros e criptograficamente vinculados: O token é emitido sob demanda para uma ação específica, vinculado à chave do agente, não pode ser reutilizado.
• OAuth On-Behalf-Of (OBO) + DPoP: OBO vincula a ação do agente a um delegado – a pessoa em nome de quem ele age; DPoP vincula criptograficamente o token à chave do agente e impede a reprodução (Strata.io).
• Gateway/proxy MCP: Cada chamada de ferramenta passa por um ponto único onde OAuth 2.1 + PKCE, restrições de escopo, lista branca para cada ferramenta e fixação de versão são aplicadas.
• Humano na cadeia de decisão para ações críticas: Pagamentos, alterações em produção, envio de comunicações – confirmação obrigatória que o agente não pode contornar por manipulação consigo mesmo.
• CAEP (Continuous Access Evaluation Protocol): Permite revogar o acesso do agente em tempo real quando a avaliação de risco muda.

A principal conclusão: um agente de IA não pode ser protegido "como um usuário" nem "como uma conta de serviço". É uma nova classe de sujeito de acesso, e o plano de identidade deve aprender a distingui-lo como uma entidade separada com seu próprio ciclo de vida, escopo e trilha de auditoria.

Identity Fabric: Um Modelo Operacional para CISO

Identity-first na prática não é a compra de um novo IAM, mas uma nova visão da arquitetura de segurança. A configuração alvo é chamada de Identity Security Fabric (ISF): um plano de controle unificado que combina IGA, PAM, ITDR, gerenciamento de acesso e visibilidade para identidades de máquina e IA através de protocolos padrão – SAML, OAuth, OIDC, SCIM, LDAP (Okta).

Gartner destaca três características de um programa IAM maduro:

1. Integração com a estratégia geral de cibersegurança e gerenciamento de risco corporativo.
2. Medição por resultado: tempo de revogação de acesso, cobertura de MFA, volume de transações privilegiadas, participação de acesso sob demanda.
3. Implementação de ITDR: monitoramento contínuo e resposta rápida a ataques à identidade.

Ao mesmo tempo, o inventário é a fase mais subestimada. Sem ele, todos os outros passos de implementação são inúteis: é impossível proteger o que não foi contabilizado. E é aqui que geralmente se revela o principal: a proporção de identidades de máquina para humanas se aproxima de 30:1, mesmo onde o departamento de TI confiantemente citava o número 5:1, ou onde se pensava que agentes de IA não eram usados.

Especificidade Russa: Identity-First em Infraestrutura Híbrida

Em grandes empresas russas, o identity-first tem seu próprio contexto. Infraestrutura híbrida com AD local de longa duração, acesso limitado a IdPs ocidentais (Okta, Ping, Azure AD como serviços completos), requisitos de substituição de importações para entidades de infraestrutura crítica de TI (КИИ) e crescimento ativo do mercado interno de soluções.

A base regulatória já existe. As ordens do FSTEC nº 17 (para sistemas de informação estatais) e nº 239 (para objetos significativos de КИИ) contêm subseções completas de IAF (identificação e autenticação) e UDA (gerenciamento de acesso): IAF.1–6 cobrem a autenticação de funcionários e usuários externos, UDA.1–10 – gerenciamento de contas, separação de funções, privilégios mínimos necessários, limitação de sessões paralelas, bloqueio de inativos. A arquitetura identity-first não entra em conflito com esses requisitos – ela os cumpre de forma mais rigorosa e observável.

Conclusões Práticas para Equipes de Segurança da Informação Russas:

• NGFW e SWG se tornam pontos de aplicação de políticas de identidade: Integração com AD/LDAP, controle de identidade do usuário em cada sessão de tráfego, aplicação de políticas com base no contexto de identidade. No Ideco NGFW, isso é implementado através da vinculação ponta a ponta da sessão de rede com a identidade do usuário no nível das regras de tráfego, sem a necessidade de um proxy separado.
• Concentrador VPN como plataforma de migração: Não "descartar e instalar ZTNA", mas migrar a lógica de acesso camada por camada para cima – da rede para a aplicação. A infraestrutura VPN existente permanece como transporte, e as decisões de acesso são tomadas pelo plano de identidade. Ou, ao usar o Ideco NGFW, é conveniente (inclusive para operação) combinar NGFW+VPN+ZTNA em uma única solução.
• ITDR através da integração de telemetria NGFW com SIEM: Anomalias comportamentais no contexto de cada identidade no tráfego são um sinal poderoso que a maioria das empresas ainda não utiliza. A combinação "logs de autenticação + contexto de rede do usuário + acesso a aplicações" cobre uma parte significativa da cadeia de ataque à identidade.
• Contabilidade separada de NHI e agentes de IA: Contas de serviço, chaves de API, tokens de integração devem ser um inventário separado com seu próprio ciclo de vida e proprietário – não "residir no AD ao lado de usuários comuns".

Importante: identity-first não exige "desmontar tudo e substituir". Exige remontar a arquitetura em torno da identidade como o principal plano de controle – e tornar NGFW, EDR, SWG, SIEM participantes dessa decisão, e não seus concorrentes.

Para Onde a Identificação Está Indo: Horizonte 2026-2030

Várias tendências não são mais "possíveis", mas estatisticamente muito prováveis.

• MFA resistente a phishing se torna o padrão: É por isso que no Ideco NGFW Novum 22 adicionamos a capacidade de usar um certificado de máquina como um dos fatores de autenticação. Senha e login serão roubados, o usuário dirá o token OTP ou SMS aos golpistas, mas entregar um laptop corporativo, por exemplo, é muito mais difícil.
• Identificação pós-quântica: O NIST fixou 2030 como prazo para a remoção de RSA/ECC de sistemas críticos e 2035 como prazo absoluto. A infraestrutura de identidade – PKI, tokens, chaves de sessão, assinaturas – é a primeira a ser atingida: certificados de longa duração e assinaturas de arquivo são valiosos para ataques do tipo "colete agora – descriptografe depois".
• Identificação descentralizada (DID, credenciais verificáveis): Mudança de bancos de dados IdP centralizados para identificadores que o próprio usuário possui, e para credenciais criptograficamente verificáveis. Isso reduz o raio de impacto de vazamentos: simplesmente não há um banco de dados centralizado de senhas e atributos.
• Identificação para agentes de IA como disciplina separada: O OAuth 2.0/2.1 atual cobre apenas parcialmente as necessidades básicas de agentes de IA. Em 2026, um conjunto de extensões está se cristalizando, sem as quais não é possível trabalhar seriamente com agentes: OBO para delegação, troca de tokens para comunicação entre nuvens, DPoP para proteção contra reprodução de tokens, PKCE para autorização segura, CAEP para revogação de acesso em tempo real, autorização baseada em atributos (ABAC) para controle fino. Paralelamente, estão os padrões de identidade criptográfica no estilo SPIFFE para agentes e experimentos com protocolos como AAuth. Em 2-3 anos, a vaga "engenheiro de identidade de agentes de IA" será tão padrão quanto "arquiteto de segurança em nuvem" hoje.
• CARTA se torna o padrão: Continuous Adaptive Risk and Trust Assessment (Avaliação Contínua Adaptativa de Risco e Confiança) deixa de ser um conceito do Gartner e se torna um padrão arquitetônico: cada decisão de acesso é tomada com base na avaliação de risco atual, que é recalculada continuamente. O "login estático a cada oito horas" está desaparecendo; vem o "confiança que está sempre em movimento". O Ideco Client, por exemplo, verifica constantemente a conformidade do ambiente de informação onde opera e fornece instantaneamente informações sobre a mudança do perfil HIP para o NGFW para reavaliar as decisões de acesso.

Em Vez de Conclusão: Não Fortalecer o Muro, Mas Reconstruir a Confiança

Identity-first não é um produto. Não é um projeto. Não é "Next Generation IAM". É uma filosofia operacional na qual a confiança não pode ser atribuída por padrão a nenhuma entidade – nem a uma pessoa, nem a um serviço, nem a um agente de IA. Cada solicitação é verificada. Cada confiança é temporária. Cada identificador tem um proprietário, um escopo, um ciclo de vida e uma trilha de auditoria.

Um CISO que continua a pensar em termos de um perímetro interno seguro em 2026 faz uma escolha não conservadora, mas perigosa. Ele constrói uma falsa sensação de segurança que os atacantes monetizam ativamente – através de cookies roubados, através de aplicações OAuth abandonadas, através de contas de serviço sem proprietário, através de agentes de IA com direitos de desenvolvedor.

O identificador é o próprio perímetro. E é aqui que cada decisão de acesso é tomada. Uma arquitetura de segurança que não leva em conta esse fato será hackeada. Uma arquitetura que coloca o identificador no centro tem a chance não de alcançar as ameaças, mas de superá-las.