Identidade ganha papel central na prevenção e resposta a incidentes de exposição de dados, aponta especialista da SEK
Incidentes de exposição de dados estão cada vez mais ligados ao uso indevido de identidades, credenciais legítimas e falhas de autorização em aplicações e APIs, exigindo das empresas uma abordagem que vá além da proteção do perímetro.
Em entrevista ao Crypto ID, Fábio Portes, Diretor de Serviços e Porta-voz da SEK, explica que a investigação precisa partir dos registros de aplicação e de API, combinando contexto de identidade, telemetria de autenticação, logs de acesso a dados e histórico de alterações em código e pipelines de CI/CD.
Para o especialista, a capacidade de reconstruir a sequência dos eventos, identificar comportamentos anômalos e preservar evidências é determinante para conter o incidente, dimensionar a exposição e evitar que uma credencial válida se transforme em porta de entrada para novos acessos indevidos.
Quem é Fábio Portes, Diretor de Serviços da SEK?
Fábio Portes é Diretor de Serviços da SEK Security Ecosystem Knowledge e especialista em cibersegurança, com trajetória construída em áreas técnicas de segurança da informação, pesquisa e desenvolvimento. Sua experiência inclui firewalls, testes de intrusão (penetration testing), avaliação de vulnerabilidades e aplicação de boas práticas para proteção de ambientes e infraestruturas digitais.
Ao longo da carreira, desenvolveu uma atuação voltada à identificação de riscos, análise da postura de segurança das organizações e adoção de estratégias capazes de antecipar e responder a ameaças cibernéticas. Seu perfil profissional também registra experiência relacionada aos segmentos militar e de serviços de proteção, além de formação pela Universidade Gama Filho.
Na SEK, Portes participa de discussões sobre a evolução das estratégias de defesa cibernética diante de ataques cada vez mais sofisticados. Entre os temas abordados publicamente pelo executivo estão o uso de inteligência artificial na segurança, a análise de padrões de comportamento de atacantes, o enriquecimento de Indicadores de Ataque (Indicators of Attack, IOAs) e a integração de conhecimentos de diferentes áreas para aprimorar a postura de segurança das organizações.
Leia a entrevista completa!
Crypto ID: Em um incidente de exposição de dados como este, quais evidências técnicas são mais importantes para identificar o vetor inicial do ataque?
Fábio Portes: Em incidentes desse perfil, em que ocorre acesso não autorizado pela camada de aplicação, sem comprometimento da infraestrutura, a primeira decisão do time de DFIR é onde procurar. E a resposta é: no log de aplicação, não no perímetro.
Firewall e EDR vão mostrar tráfego legítimo, porque tecnicamente ele é legítimo. O atacante está usando a aplicação exatamente como ela foi construída para funcionar. O problema é que ela foi construída para permitir mais do que deveria.
As evidências mais valiosas, na ordem em que costumamos priorizá-las, são:
Logs de aplicação e de API com contexto de identidade. É o ativo mais crítico e, na prática, o mais negligenciado. Não basta registrar “requisição recebida“. É preciso ter, por evento, o identificador da sessão, o usuário autenticado, o recurso consultado e o resultado.
Sem isso, é impossível responder à pergunta que a empresa mais precisa responder: quais titulares foram efetivamente acessados? Foi exatamente esse trabalho que consumiu as semanas de análise técnica no caso público.
Logs de gateway, WAF e CDN. Eles trazem IP de origem, user-agent, cadência e volumetria. É onde o padrão de abuso aparece: uma sessão legítima que faz milhares de consultas sequenciais em minutos, com incremento previsível de identificadores. Isso não é uso, é enumeração.
Telemetria de autenticação e do provedor de identidade. Autenticações bem-sucedidas de geolocalizações incoerentes, reuso de credencial, sessões de longa duração e tokens que não expiram. Em muitos casos, o acesso indevido não quebra a autenticação: ele se apoia em uma sessão válida e explora a falha de autorização depois dela.
Logs de banco de dados e de acesso a dados. Consultas com volume anômalo de retorno, chamadas fora do padrão de horário ou de perfil de serviço também são evidências relevantes.
Histórico do repositório e do pipeline de CI/CD. Esse é um ponto que costuma ser ignorado. Quando a correção passa pelo código-fonte, a linha do tempo precisa incluir quando aquele comportamento foi introduzido, em qual commit, aprovado por quem e por qual esteira.
Isso responde à pergunta mais desconfortável do pós-incidente: há quanto tempo a exposição existia antes de alguém encontrá-la?
Sobre movimentação lateral e exfiltração, vale uma distinção técnica importante para o leitor: nem todo vazamento envolve lateralidade. Quando a falha é de autorização em um endpoint exposto, não há necessidade de se mover pela rede. O dado sai pela porta da frente, em respostas HTTP legítimas, sem tocar em nenhum controle de detecção tradicional.
A exfiltração aparece como agregação: muitas requisições pequenas, individualmente irrelevantes, que somadas reconstroem a base.
Por isso, o fator determinante para a qualidade da investigação é decidido antes do incidente: a política de retenção. Se o log de aplicação guarda sete ou quinze dias, e a exposição durou meses, a investigação não é difícil. Ela é impossível.
Recomendamos retenção mínima de 90 dias em quente e um ano em frio para trilhas de acesso a dados pessoais, com integridade preservada. Esse é o insumo que separa uma notificação precisa de uma notificação genérica ao regulador e ao titular.
Crypto ID: Como o comprometimento de identidades e credenciais pode ser identificado antes que resulte em acesso indevido a sistemas ou dados?
Fábio Portes: A pergunta inverte uma lógica que ainda domina o mercado: a maioria das empresas descobre o comprometimento de identidade pelo efeito, quando o dado já saiu.
Detectar antes exige aceitar uma premissa incômoda: credencial válida não é sinônimo de acesso legítimo. Do ponto de vista do sistema, o atacante com credencial correta é um usuário exemplar. Ele autentica na primeira tentativa, não gera erro e não dispara alerta.
O que permite antecipar são três camadas trabalhando juntas.
Sinais antecedentes, fora do ambiente. Boa parte do comprometimento é detectável antes do primeiro login. Credenciais corporativas circulando em vazamentos de terceiros, logs de infostealer com cookies de sessão da empresa, domínios recém-registrados imitando a marca e painéis de phishing em preparação são alguns exemplos.
Threat Intelligence aplicada à superfície de identidade, com monitoramento contínuo e correlação ao diretório da própria organização, dá uma janela de horas ou dias para forçar reset e invalidar a sessão antes do uso.
Autenticação resistente a phishing. MFA já não é resposta suficiente. A discussão hoje é sobre qual MFA. SMS e OTP digitáveis são interceptáveis por proxy reverso e engenharia social, exatamente o cenário que dados vazados de fidelidade viabilizam.
O padrão que efetivamente quebra o ataque é FIDO2/WebAuthn com chave vinculada ao domínio, complementado por binding de sessão e reavaliação contínua de risco, não apenas no momento do login.
Também é necessário tratar token e cookie de sessão como credenciais de fato: expiração curta, revogação centralizada e detecção de reuso.
Privilégio mínimo com validade. O que amplifica o dano é o acúmulo silencioso de permissão: conta de serviço com escopo amplo demais, acesso concedido para um projeto e nunca revogado ou chave de API sem rotação.
Os controles que mais reduzem exposição são acesso just-in-time com elevação temporária e aprovação, revisão periódica de direitos e governança de identidades não humanas.
Em ambientes modernos, identidades de máquina superam as humanas em ordem de grandeza e quase nunca têm MFA, dono definido ou ciclo de vida. É onde o risco cresce mais rápido e a visibilidade é menor.
Monitoramento comportamental é o que amarra tudo. A pergunta operacional do SOC deixa de ser “essa credencial é válida?” e passa a ser “esse comportamento é compatível com esse usuário?“.
É preciso estabelecer um baseline por identidade e por conta de serviço: volume típico de consulta, horário, geografia, recursos acessados e cadência.
O que dispara investigação são desvios: a conta que sempre leu dez registros por dia e passou a ler dez mil; o serviço que nunca consultou determinada tabela e começou a consultar; ou a sessão que muda de ASN no meio do uso.
Nesse modelo, a enumeração massiva de um endpoint aparece como anomalia de comportamento mesmo quando cada requisição, isoladamente, é autorizada.
O ponto estratégico para o leitor é que identidade virou o perímetro, mas continua sendo tratada como tema de TI operacional, dividida entre times que não conversam: IAM, aplicação e SOC.
Enquanto a correlação entre esses três domínios não existir, a organização vai continuar descobrindo comprometimento pelo impacto, e não pelo sinal.
Crypto ID: Em ambientes com aplicações, APIs e integrações com terceiros, quais são hoje os pontos de maior exposição a ataques?
Fábio Portes: Os pontos de maior exposição hoje quase nunca são os que aparecem no scanner. São os que dependem de lógica de negócio, e lógica de negócio não tem CVE.
Na prática, o que mais vemos em investigação:
Falha de autorização em objeto e em função. O endpoint autentica corretamente e depois entrega o recurso sem verificar se aquele usuário pode vê-lo. É a categoria que lidera o Top 10 de API da OWASP há anos e a que mais produz exposição em massa, porque permite iterar identificadores e reconstruir a base inteira sem quebrar nada.
Ausência de limite de consumo. Endpoint sem rate limit, sem quota por identidade e sem teto de volumetria por sessão transforma uma falha pontual em vazamento de escala.
Superfície não inventariada. APIs sombra, versões antigas que ninguém desligou, endpoints de homologação expostos e documentação viva apontando rotas descontinuadas.
Não se protege o que não se sabe que existe. E o inventário de API é, na maioria das empresas, mais desatualizado que o de servidores.
Cadeia de terceiros e integrações. Tokens de parceiro com escopo excessivo e sem rotação, webhooks sem validação de assinatura, SDKs e bibliotecas de terceiros carregados no front-end.
O risco aqui é assimétrico: a empresa herda a postura de segurança de quem integrou, mas responde sozinha perante o titular e o regulador.
Segredo em código e em pipeline. Chave commitada, variável de ambiente em log e credencial em artefato de build são exemplos de situações em que a fronteira entre desenvolvimento e produção se dissolve.
Sobre a distinção diagnóstica, essa é exatamente a decisão que define o rumo da resposta a incidente. Ela se faz por padrão de evidência, não por intuição.
Falha de configuração tem assinatura de acesso amplo e indiscriminado. O recurso responde a quem quer que pergunte, frequentemente sem autenticação. Costuma haver múltiplas origens não relacionadas acessando o mesmo recurso, incluindo crawlers e varredores automatizados.
Também há um marco temporal claro: o comportamento nasce em uma mudança, como um deploy, alteração de política ou migração. A trilha está no histórico de configuração e no pipeline.
Abuso de credencial legítima tem assinatura de autenticação impecável com comportamento incoerente. Zero erro de login, nenhuma tentativa malsucedida e sessão válida, mas o volume, horário, geografia ou recursos acessados não correspondem ao histórico daquela identidade.
É o caso mais difícil, porque nenhum controle preventivo é violado. Só o baseline denuncia.
Exploração de vulnerabilidade tem assinatura de tentativa e erro antes do sucesso. Existe uma fase de reconhecimento, com payloads malformados, respostas de erro, códigos 4xx e 5xx em sequência, manipulação de parâmetros e, só então, a requisição que funciona.
Há também sinal no código: o comportamento é reproduzível em ambiente controlado e desaparece quando o trecho é corrigido. É a única das três que se resolve com patch.
O que amarra o diagnóstico é a correlação de três fontes: log de aplicação com contexto de identidade, histórico de mudança de configuração e código, e baseline comportamental.
Faltando qualquer uma delas, a investigação vira hipótese.
E há uma consequência estratégica pouco discutida: o enquadramento correto define a remediação. Tratar abuso de credencial como se fosse bug leva a corrigir código que não estava errado. Tratar falha de autorização como se fosse credencial comprometida leva a resetar senha de usuário enquanto a porta continua aberta.
Errar o diagnóstico não é só perder tempo. É reabrir o incidente semanas depois.
Crypto ID: Quais controles devem proteger contas privilegiadas, repositórios de código, pipelines de CI/CD, segredos, tokens, chaves de API e identidades de máquina? E em quais situações uma falha nesses ambientes pode abrir caminho para acesso a dados ou sistemas de produção?
Fábio Portes: Existe um desequilíbrio estrutural nesse tema: a maior parte do investimento em segurança protege a produção, enquanto o caminho mais curto até a produção passa pelo ambiente de desenvolvimento.
O pipeline é, hoje, uma identidade privilegiada com acesso legítimo ao ambiente crítico e raramente é tratado como tal.
Contas privilegiadas. O modelo que funciona é o acesso sem privilégio permanente: elevação just-in-time, com aprovação, escopo definido e expiração automática.
É necessário somar autenticação resistente a phishing para qualquer elevação, sessão registrada e revisão periódica de direitos.
Conta administrativa nominal, nunca compartilhada. Se não há a quem atribuir a ação, não há investigação possível depois.
Repositórios de código. Autenticação forte obrigatória para todo colaborador, proteção de branch principal, revisão por pares como requisito de merge, assinatura de commit e bloqueio de push direto.
Também é necessária a varredura de segredos no pré-commit e no histórico, e não apenas no código novo.
É fundamental revisar quem tem acesso, incluindo contas de integração, aplicativos de terceiros instalados na organização e ex-colaboradores com fork pessoal.
Pipelines de CI/CD. Runners isolados por ambiente, sem credencial de produção em esteira de desenvolvimento, aprovação humana para deploy em produção e integridade de artefato, com assinatura e verificação de proveniência.
Dependências devem ser fixadas por versão e por hash, com validação de origem.
Também deve existir segregação clara: quem escreve o pipeline não deveria ser quem aprova a execução em produção.
Segredos, tokens e chaves. Cofre centralizado, credencial de curta duração e, sempre que possível, autenticação federada por identidade de carga de trabalho em vez de segredo estático.
Rotação automática, escopo mínimo por token e, principalmente, revogação testada.
Muita organização sabe emitir credencial e não sabe cancelá-la rapidamente sob pressão.
Identidades de máquina. Aqui está o ponto cego mais grave. Toda conta de serviço, token de integração e chave de API precisa de dono nomeado, propósito documentado, escopo mínimo, data de expiração e monitoramento de comportamento.
Sem dono, a credencial nunca é revogada. Sem expiração, ela sobrevive ao projeto que a criou. Sem baseline, seu abuso é indistinguível do uso normal.
Os caminhos que mais reconstruímos em investigação são credencial de produção armazenada em variável de pipeline acessível a qualquer branch; token de longa duração commitado e exposto em repositório público ou amplamente acessível internamente; dependência ou action de terceiro comprometida executando dentro da esteira com acesso ao cofre; ambiente de homologação apontando para a base de produção; conta de serviço criada para uma integração pontual, com permissão ampla, esquecida e depois reutilizada.
Também existe o vetor humano: engenharia social sobre desenvolvedor com acesso ao repositório, que hoje é alvo prioritário justamente porque concentra privilégio.
A conexão com o caso público é direta. Quando a resposta a um incidente envolve corrigir código-fonte e aplicar travas adicionais, isso indica que o controle que faltou estava no ciclo de desenvolvimento, e não no perímetro.
Por isso, defendemos deslocar parte do investimento para revisão de autorização em código, teste de lógica de negócio e governança de acesso ao repositório e ao pipeline.
É consideravelmente mais barato barrar um endpoint mal autorizado no code review do que descobri-lo meses depois, através de uma análise forense de três semanas para determinar quais titulares foram acessados.
Crypto ID: Depois da confirmação de um acesso não autorizado, qual deve ser a sequência técnica de investigação e contenção para interromper o ataque sem comprometer as evidências forenses?
Fábio Portes: A primeira regra é contraintuitiva: a pressa é inimiga da resposta.
O reflexo natural, desligar o servidor, resetar tudo e apagar o acesso, destrói exatamente a evidência que responderá às perguntas do regulador e do titular.
Contenção e preservação não são etapas sequenciais, são simultâneas, e a ordem correta é sempre: preservar, entender o suficiente, conter, erradicar.
Preservação primeiro, e em minutos. Antes de qualquer ação de contenção, congela-se o que é volátil e o que expira: memória de sistemas envolvidos, imagem de disco quando aplicável e, no caso de exposição por aplicação, os logs de aplicação, gateway, WAF e autenticação.
Esses dados devem ser copiados para repositório com integridade preservada e cadeia de custódia formal.
O motivo é prático: log de nuvem rotaciona, sessão expira e provedor de terceiros descarta dados em janela curta. O que não for coletado nas primeiras horas frequentemente não existirá mais na semana seguinte.
Escopo mínimo viável, em paralelo. Não se contém o que não se compreendeu minimamente. Precisamos saber, ainda que preliminarmente: qual identidade, qual caminho e qual janela temporal.
Uma contenção prematura e parcial avisa o adversário e o faz migrar para um acesso alternativo que ainda não mapeamos. Trocamos um incidente conhecido por um desconhecido.
Contenção. A decisão é orientada pelo vetor. Em exposição por aplicação, a contenção eficaz é bloqueio de origem, imposição de limite de consumo, desativação do endpoint vulnerável ou correção emergencial, e não isolamento de servidor, que interrompe o negócio sem fechar a porta.
Isolamento de ativo se aplica quando há indício de comprometimento de host, execução de código ou lateralidade.
Em ambos os casos, a contenção deve ser acompanhada de monitoramento reforçado para observar se o adversário reage.
Revogação de sessão e rotação de credencial entram depois do escopo definido e precisam ser feitas de forma coordenada, em um único movimento.
Revogação fatiada é o erro clássico: rotaciona-se a credencial A hoje, descobre-se a credencial B amanhã e o acesso nunca é efetivamente cortado.
É necessário invalidar tokens e cookies ativos, rotacionar segredos e chaves de API do escopo afetado e revisar dispositivos confiáveis e métodos de MFA registrados, porque o método de MFA adicionado pelo atacante é uma das formas de persistência mais silenciosas em um ambiente de identidade.
Análise de persistência é obrigatória mesmo quando o incidente parece simples. Procuramos contas de serviço criadas na janela, tokens emitidos, regras de encaminhamento de e-mail, aplicativos OAuth consentidos, chaves adicionadas, tarefas agendadas, alterações em pipeline e código.
Um incidente que aparenta ser “só uma consulta indevida” pode ter deixado uma credencial de longa duração para retorno futuro.
Threat hunting ocorre em dois momentos: durante o incidente, para validar se o vetor identificado é o único e se o mesmo padrão aparece em outros sistemas; e depois, de forma continuada por semanas, porque o retorno do adversário costuma vir após o encerramento formal do caso, quando a atenção diminui.
A linha que separa uma resposta madura de uma improvisada é o que foi feito antes: playbook definido, retenção de log adequada, autoridade decisória clara para desligar um serviço e integração com jurídico e comunicação desde a primeira hora.
É isso que determina se a notificação ao regulador e ao titular sairá precisa em poucos dias ou genérica, semanas depois, dizendo apenas que “uma parcela limitada” foi afetada porque a evidência não permitiu concluir mais do que isso
Crypto ID: Como a SEK pode ajudar uma organização a prevenir, detectar e responder a um incidente com essas características?
Fábio Portes: A SEK trabalha esse tipo de cenário com identidade no centro da arquitetura, que é exatamente onde incidentes como esse se decidem.
Não é acaso: somos parceiro de entrega Admiral da SailPoint há cinco anos, o único da América Latina, e o primeiro parceiro de entrega IAM da Ping Identity na região, com prática consolidada em IGA, CIAM, PAM e identidade de máquina.
Quando o vetor é autorização quebrada e consulta massiva com credencial válida, o problema não se resolve no perímetro. Resolve-se governando quem pode acessar o quê, com qual escopo e por quanto tempo.
Na prevenção, atuamos em três frentes que conversam entre si: governança de identidade, incluindo o inventário e o ciclo de vida das identidades não humanas, que é o ponto cego mais comum; gestão de acesso privilegiado, com elevação temporária em vez de privilégio permanente, inclusive sobre repositório e pipeline; e consultoria de segurança que traz a revisão de autorização para dentro do ciclo de desenvolvimento, junto com gestão de risco de terceiros.
Isso é organizado pelo método RAP, Resilience Acceleration Program, que estrutura cada engajamento em entender o risco, implantar as defesas e sustentar a resiliência no dia a dia, com quantificação baseada em FAIR.
O ponto relevante para o CISO é que se trata de um método publicado e verificável: dá para ler o playbook, acompanhar cada etapa e conferir como cada número foi calculado.
Na detecção, o que importa nesse tipo de incidente é telemetria comportamental correlacionada com o contexto de identidade.
Operamos MDR, threat hunting e SOC 24/7 orquestrados pela plataforma Nautilus, que reúne tecnologia, inteligência e serviços em uma única camada e integra as ferramentas que o cliente já utiliza, em vez de exigir substituição.
Isso permite enxergar a anomalia que discutimos nas respostas anteriores: a credencial legítima cujo volume de consulta rompeu o baseline.
Somamos a isso monitoramento de superfície externa e brand protection, que é o que antecipa credencial vazada, log de infostealer e infraestrutura de phishing sendo preparada contra a marca, o sinal que chega antes do primeiro acesso indevido.
Na resposta, temos prática dedicada de IR/DFIR e exercícios de tabletop.
Vale sublinhar o tabletop: a diferença entre encerrar um incidente em dias ou em semanas raramente está na ferramenta. Está em ter ensaiado quem decide desligar um serviço, quem fala com o regulador e quem autoriza a rotação coordenada de credenciais.
Sobre medir se o controle realmente reduziu o risco, essa é a parte que separa segurança de teatro de segurança.
Os indicadores que defendemos incluem:
Indicadores de tempo: MTTD e MTTC, mas medidos por cenário, e não em média agregada; tempo entre detecção e determinação do escopo de titulares afetados, número que define a qualidade da notificação ao regulador; e tempo de revogação efetiva de credencial sob pressão, testado, e não estimado.
Indicadores de identidade: percentual de identidades com privilégio permanente versus just-in-time; cobertura de MFA resistente a phishing; número de identidades de máquina sem dono, sem expiração ou sem rotação; idade média de segredo em produção; e percentual de acesso concedido e não revisado no ciclo.
Indicadores de aplicação e pipeline: cobertura de teste de autorização por perfil; percentual de endpoints inventariados e com limite de consumo; densidade de segredos detectados no repositório; e tempo de correção de vulnerabilidade de lógica de negócio.
Indicadores de detecção: cobertura de casos de uso mapeados contra ATT&CK, taxa de detecção validada por emulação de adversário e cobertura de retenção de log, porque, como falamos, retenção insuficiente inviabiliza a investigação antes que ela comece.
O RAP fecha esse ciclo transformando risco em número e número em prioridade, provando o resultado e ordenando o que fazer primeiro.
Na prática, é o que permite ao conselho responder à pergunta que sempre vem depois de um incidente de mercado: estamos expostos ao mesmo risco?
Reflexão final
Os incidentes de exposição de dados mostram que a segurança corporativa precisa acompanhar um ambiente cada vez mais conectado, no qual identidades, APIs, aplicações, pipelines e credenciais de máquina ampliam a superfície de risco. Para Fábio Portes, da SEK, a resposta depende da capacidade de correlacionar evidências, monitorar comportamentos e preservar registros para reconstruir os eventos.
Nesse cenário, segurança vai além do perímetro e exige governança contínua, controle de privilégios e visibilidade sobre credenciais e acessos. O desafio das empresas é não apenas evitar ataques, mas estar preparadas para identificar, explicar e responder rapidamente quando eles ocorrerem.
Agradecimento
O Crypto ID agradece a Fábio Portes e à SEK pela contribuição para esta entrevista e pela oportunidade de aprofundar um tema essencial para o cenário atual de cibersegurança: a proteção de identidades, credenciais e dados diante de uma superfície de ataque cada vez mais complexa.
Agradecemos pela disponibilidade e pelos insights técnicos que contribuem para ampliar o debate sobre segurança, governança e resposta a incidentes no ambiente digital.
ID Talk | Royal FIC transforma sua operação com SAP S/4HANA e prepara caminho para automação e IA
ID Talk | Antônio Carlos, da GlobalSign, detalha o papel do Code Signing na segurança do software
ID Talk com Elias Rogério da Silva: infraestrutura, IA e resiliência no Febraban Tech 2026
ID Talk | Fabio Plein, da Coinbase, debate regulação, stablecoins e risco onchain
ID Talk são entrevistas que geram insights poderosos e soluções práticas para você tomar decisões estratégicas e liderar o futuro. Assistindo ou lendo você descobre o que há de mais inovador em tecnologia. Você vai gostar muito!
