Durante muito tempo, a segurança foi tratada como a capacidade de impedir invasões. A lógica era clara: proteger o perímetro, corrigir vulnerabilidades, bloquear acessos indevidos.
Esse modelo ainda existe, mas ele já não explica o que está acontecendo nos ambientes corporativos hoje.
O problema não é mais, necessariamente, alguém tentando entrar. O problema é alguém que já entrou, e não parece um invasor.
A forma como os ataques evoluíram nos últimos anos deslocou o centro da segurança. Em vez de explorar falhas evidentes, muitos deles passaram a operar dentro das regras do próprio ambiente. Usam acessos legítimos, sessões já autenticadas, tokens válidos, integrações autorizadas. Não há quebra de porta. Há uso da chave.
Isso muda completamente a natureza do risco.
Em muitos casos, o que sustenta esse tipo de acesso não é uma credencial roubada no sentido clássico, mas algo muito mais difícil de perceber: um token que nunca expirou, uma sessão que continua válida, uma integração que ninguém mais revisou, uma automação criada há meses que ainda tem privilégio elevado.
São elementos que não aparecem em auditorias superficiais porque continuam funcionando. E é justamente esse o problema.
A identidade, nesse contexto, deixou de ser apenas um mecanismo de autenticação. Ela passou a ser a forma como sistemas, aplicações e serviços se relacionam entre si. Cada integração depende de uma identidade. Cada automação opera com uma identidade. Cada fluxo entre sistemas carrega permissões que, na prática, determinam o que pode ou não acontecer dentro do ambiente.
Quando isso não é governado, o ambiente continua operando, mas fora de controle.
Esse tipo de desorganização não surge de uma decisão isolada. Ele se acumula. Um acesso concedido para resolver um problema urgente. Um token criado para integrar duas plataformas. Um script que precisa rodar com mais privilégio para evitar falhas. Uma conta técnica que nunca foi revisada.
Nada disso parece crítico no momento em que é criado, mas, ao longo do tempo, forma uma camada invisível de acesso que ninguém domina completamente.
É nesse ponto que a identidade se torna um problema estrutural.
Grande parte dessas identidades sequer está associada a pessoas. São contas de serviço, aplicações, integrações, pipelines, ferramentas de monitoramento, rotinas automatizadas. Elas não passam por processos formais de revisão, não têm ciclo de vida claro e, muitas vezes, operam com privilégios superiores aos necessários.
E, diferentemente de um usuário humano, elas não geram comportamento suspeito evidente. Elas fazem exatamente o que foram configuradas para fazer, mesmo que isso represente um risco.
Isso cria uma situação delicada. A empresa pode ter controles bem implementados para acesso de usuários, pode exigir autenticação forte, pode monitorar login e comportamento. Ainda assim, pode estar exposta por acessos que não passam por nenhuma dessas camadas.
Porque não são vistos como acesso. São vistos como funcionamento normal.
A discussão sobre identidade, portanto, deixou de ser um tema restrito à segurança. Ela passou a impactar diretamente a operação.
Quando uma integração depende de uma credencial específica, quando uma automação concentra permissões críticas, quando uma sessão pode ser reutilizada sem controle, o que está em jogo não é apenas proteção. É continuidade, confiabilidade e previsibilidade do ambiente.
É por isso que tratar a IAM como um domínio isolado já não é suficiente.
A identidade hoje define como os sistemas se conectam, como os dados circulam, como as decisões automatizadas acontecem e como as dependências se formam. Quando essa camada não é bem gerida, o ambiente pode até continuar funcionando, mas passa a operar em um nível de risco que não é evidente até que algo dê errado.
E quando dá errado, o ponto de origem raramente é óbvio.
Não é um firewall que falhou. Não é uma vulnerabilidade explorada de forma direta. É um acesso que existia, mas não deveria. Uma permissão que foi mantida além do necessário. Uma integração que se tornou um caminho não previsto.
O mais desafiador é que esse tipo de problema não aparece de forma abrupta. Ele se constrói ao longo do tempo, em pequenas decisões que nunca foram revisitadas. E, justamente por isso, tende a ser subestimado.
A sensação de controle permanece, até o momento em que ela deixa de existir.
Rever identidade, nesse cenário, não é apenas revisar quem pode acessar o quê. É entender quais acessos existem, por que existem, por quanto tempo deveriam existir e o que acontece se forem utilizados fora do contexto esperado.
É sair da lógica de cadastro e entrar na lógica de operação.
Porque, hoje, o acesso mais perigoso não é o que tenta entrar à força. É o que já está dentro e ninguém mais questiona.
Fontes
Microsoft Security Blog — OAuth redirection abuse enables phishing and malware delivery.
Google Cloud / Mandiant — M-Trends 2026.
CISA / NIST — Protecting Tokens and Assertions from Forgery, Theft, and Misuse.
NIST SP 800-63-4 — Digital Identity Guidelines / Session Management.
Microsoft Learn — Workload identities overview / Conditional Access for workload identities / Managed identities.
OWASP — Non-Human Identities Top 10 2025.
GitHub Docs — Personal access tokens and API credential security.
