O DSPM existe porque os dados sensíveis não ficam mais parados.
Além do banco de dados, dados sensíveis estão em logs, filas, ferramentas SaaS, sistemas de suporte, pipelines de análise, data warehouses, backups e, agora, em prompts de IA e stores de vetores. Eles se movem porque a aplicação os move. Um endereço de e-mail de cliente pode começar em um formulário de inscrição, passar por uma API, ser gravado no Postgres, aparecer em um log de aplicação, ser copiado para o Snowflake, fluir para uma ferramenta de suporte, ser enviado para o Stripe e, então, talvez ser puxado para um fluxo de trabalho de IA mais tarde. E isso é considerado um fluxo de trabalho bastante normal.
Então, quando as pessoas falam sobre DSPM, ou Data Security Posture Management, a ideia básica é bastante direta. Ajudar as equipes a entender onde os dados sensíveis estão, que tipo de dados são, quem ou o que pode acessá-los, como são protegidos e onde podem estar expostos.
A maioria das empresas não possui um mapa perfeito de onde os dados sensíveis residem. Elas sabem que têm dados de clientes, detalhes de pagamento, tokens, dados de funcionários e, agora, todos os tipos de contexto de IA. O que nem sempre sabem é onde todos esses dados foram parar, quem pode acessá-los ou se estão sendo tratados de uma forma que corresponda às suas expectativas de segurança e conformidade.
A visibilidade é o problema que o DSPM tradicional está tentando resolver.
O DSPM tradicional começa onde os dados foram armazenados
O DSPM tradicional geralmente começa com o patrimônio de dados. Isso geralmente significa escanear sistemas de armazenamento e plataformas conectadas. Buckets S3, bancos de dados, data warehouses, aplicativos SaaS e backups.
A ferramenta busca dados sensíveis, os classifica, verifica permissões e exposição, e ajuda a equipe de segurança a priorizar o que é importante. Pode informar que um bucket S3 contém PII. Ou que uma tabela de data warehouse possui dados relacionados a pagamentos. Ou que um compartilhamento de arquivos é muito amplamente acessível. Ou que um backup possui registros de clientes de produção em um local que ninguém verificou em um ano.
Isso é obviamente útil. Há muitos dados sensíveis circulando em ambientes modernos, e grande parte deles é copiada, replicada, exportada, registrada, sincronizada, arquivada e esquecida. O DSPM tradicional ajuda as equipes a encontrar isso. Ele oferece à equipe de segurança uma visão melhor do patrimônio de dados real, além dos recursos da Cloud ao seu redor.
Mas para desenvolvedores e equipes de AppSec, essa é frequentemente a segunda parte da história.
A primeira parte é como os dados chegaram lá.
A pergunta que falta é o caminho do código.
Uma ferramenta DSPM tradicional pode dizer: “PII foi encontrado neste armazenamento de logs.”
Mas o desenvolvedor ainda precisa descobrir por que o PII está lá, qual parte da aplicação o escreveu, se foi intencional e qual mudança realmente o corrigiria. E para isso, é preciso analisar o código.
A aplicação coletou os dados, processou-os e decidiu quais campos retornar de uma API. Em seguida, registrou o corpo da requisição, passou um token para um worker, enviou metadados do cliente para um fornecedor e construiu o prompt que incluía contexto sensível.
Assim, a pergunta mais nativa para o desenvolvedor deve ir além de “Onde os dados sensíveis estão armazenados?” e ser mais como “Qual caminho do código criou a exposição?” Essa é a versão shift-left do DSPM.
O DSPM baseado em código começa com a aplicação em vez da camada de armazenamento. Ele analisa APIs, modelos ORM, chamadas de logging, consumidores de fila, fluxos de trabalho de CI/CD, integrações de IA e muito mais. O objetivo é entender como os dados sensíveis entram no sistema, como se movem, onde são armazenados, onde saem e onde podem ser mal utilizados.
DSPM baseado em código e Auditorias de Exposição de Dados
Na Aikido, acredito que a maneira mais clara de descrever nosso DSPM baseado em código é encará-lo como uma Auditoria de Exposição de Dados, que utiliza IA para encontrar fluxos de dados sensíveis e riscos de segurança no código.
Uma Auditoria de Exposição de Dados abrange PII, PHI, PCI, Secrets, tokens, conteúdo do cliente e tratamento de dados relacionados à IA. Cada resultado vem com evidências e uma remediação no código, sem a necessidade de conectar-se diretamente aos datastores.
A leitura do código também pode encontrar proteção de dados fraca. Pode sinalizar um campo sensível armazenado sem criptografia, uma chave hardcoded no código-fonte, MD5 ou SHA1 ou base64 usados como se fossem criptografia, um Secrets commitado no repositório e dados sensíveis enviados por um canal inseguro.
Há outra forma de abordar isso. O DSPM tradicional precisa de acesso aos seus dados reais, conectando-se a buckets S3, bancos de dados e data warehouses para escanear o que está dentro deles. O DSPM baseado em código, em vez disso, lê o código que cria e move esses dados, de modo que nunca solicita acesso ou baixa nada. A leitura a partir do código reduz a barreira para ativá-lo, já que não há novo acesso de produção a ser concedido.
Isso também o torna mais rápido, já que não há nada para rastrear. É mais preciso também, pois lê como um campo é usado em vez de assumir que qualquer número de nove dígitos é um número de Seguro Social. O resultado é um mapa de onde os dados sensíveis residem em sua arquitetura e como são protegidos, construído inteiramente a partir do código.
Na Aikido, isso é executado como parte da análise de código com IA, então a Auditoria de Exposição de Dados fica ao lado do restante da revisão de código, em vez de ser uma integração de acesso a dados separada.
Como a qualidade dos achados difere
Tomemos o logging como um exemplo simples.
Um produto DSPM tradicional pode eventualmente informar que PII existe em logs de aplicação. Novamente, útil. Mas agora alguém precisa ir caçar a origem.
Uma Auditoria de Exposição de Dados baseada em código pode contar uma história mais completa, conectando os dados, o caminho do código, o destino, o risco de exposição e a correção. Isso a torna mais útil para os desenvolvedores.
Por exemplo, o controlador de checkout registra o objeto billingDetails completo quando a autorização de pagamento falha. Esse objeto inclui e-mail, número de telefone, endereço de cobrança e os últimos quatro dígitos do cartão. Os logs são enviados para o Datadog. A correção é redigir esses campos antes do logging e manter apenas o ID do cliente, o ID da intenção de pagamento e o código de erro.
Essa é uma informação muito diferente da que você obtém de um DSPM tradicional.
O mesmo se aplica a Secrets e tokens. Considere um token SCM usado para ler código do GitHub, GitLab ou Bitbucket. Uma visão orientada ao armazenamento pode perguntar se o token está criptografado no banco de dados. No entanto, essa não é a história completa.
Onde o token entra na plataforma? É um token OAuth, um token de GitHub App ou um PAT enviado pelo usuário? Quais escopos ele possui? Como é validado? Onde é criptografado? Onde é armazenado? Quando é descriptografado? É armazenado em cache? Está incorporado em uma URL de clone? É passado para um worker? Poderia vazar através de logs, traces, erros, argumentos de processo ou telemetria? É um problema de segurança de dados, mas o código nos diz o que precisamos saber sobre seu movimento.
Do dashboard à correção
É aqui que eu acho que o DSPM baseado em código se torna interessante.
A melhor versão disso não é outro dashboard que diz: “Você tem dados sensíveis.” Todo mundo sabe disso. A melhor experiência diz: aqui está o inventário de dados sensíveis, aqui está o fluxo, aqui está o risco de exposição, aqui estão os controles relevantes e aqui está a mudança no código que reduz o risco.
Se o código criou a exposição, a correção provavelmente pertence ao código.
O fluxo de trabalho típico do desenvolvedor deve, portanto, ser:
- Redigir campos sensíveis antes do log.
- Retornar um objeto de resposta de API menor.
- Adicionar uma verificação de propriedade do tenant.
- Parar de passar tokens em URLs.
- Mascarar dados de produção antes de restaurá-los para o ambiente de staging.
- Adicionar criptografia antes do armazenamento.
- Remover dados do cliente de um prompt de LLM.
- Corrigir a lógica de exclusão para que os registros downstream sejam realmente removidos.
O engenheiro quer saber qual caminho de código específico cria um risco específico de exposição de dados e como corrigi-lo.
Isso também torna a conexão com frameworks de segurança e conformidade muito mais concreta. Se um token for mal gerenciado, isso pode ser relevante para o gerenciamento de autenticadores, proteção de transmissão, privilégio mínimo e proteção de logs de auditoria. Se PII for registrado sem redação, isso pode ser relevante para privacidade, retenção, minimização de dados e controles de monitoramento. Se os dados do cliente forem copiados para o staging sem mascaramento, isso pode afetar o controle de acesso, a separação de ambientes e as obrigações de conformidade. Se os registros sobreviverem a uma solicitação de exclusão, ou se os dados permanecerem além de sua janela de retenção, isso se liga diretamente às obrigações do GDPR e CCPA, e precisa ser corrigido na própria lógica de exclusão e retenção.
A descoberta que apenas diz “Padrão de log inseguro” é bastante limitada em sua utilidade. Mas algo como “PII do cliente flui para os logs através deste caminho de código, criando um risco de exposição de dados, afetando estes controles, e pode ser corrigido redigindo estes campos antes do log”, é acionável.
Essa é uma maneira muito melhor de trazer engenharia, AppSec e conformidade para a mesma conversa.
A versão simples
O DSPM tradicional ainda é importante. Ele ajuda as equipes a entender onde os dados sensíveis residem no ambiente real. Ele pode encontrar buckets esquecidos, bancos de dados expostos, shadow data e armazenamentos com permissões excessivas.
Mas o DSPM baseado em código adiciona a camada de aplicação que faltava. Ele ajuda a explicar como os dados sensíveis chegam lá, como eles se movem, onde o mecanismo de exposição reside e o que os desenvolvedores podem fazer a respeito.
Então, a versão simples se parece com:
O DSPM tradicional encontra dados sensíveis onde eles residem.
O DSPM baseado em código encontra como os dados sensíveis são expostos.
Uma Auditoria de Exposição de Dados conecta esse fluxo de volta ao código, à lacuna de controle e à correção.
Essa é a versão shift-left do DSPM. E para desenvolvedores e equipes de AppSec, é provavelmente a versão que mais ajuda as equipes.
Aikido oferece o primeiro de seu tipo em DSPM baseado em código. Proteja e rastreie seus dados, sem sequer conectar seus bancos de dados.
