O DSPM existe porque os dados confidenciais já não permanecem estáticos.
Para além da base de dados, os dados sensíveis encontram-se em registos, filas, ferramentas SaaS, sistemas de apoio, pipelines de análise, armazéns de dados, cópias de segurança e, agora, em prompts de IA e armazenamentos vetoriais. Estes dados movimentam-se porque a aplicação os movimenta. O endereço de e-mail de um cliente pode começar num formulário de registo, passar por uma API, ser gravado no Postgres, aparecer num registo da aplicação, ser copiado para o Snowflake, fluir para uma ferramenta de suporte, ser enviado para o Stripe e, mais tarde, talvez ser incorporado num fluxo de trabalho de IA. E isto é considerado um fluxo de trabalho bastante normal.
Assim, quando se fala de DSPM, ou Gestão da Postura de Segurança de Dados, a ideia básica é bastante simples. Ajudar as equipas a compreender onde se encontram os dados sensíveis, de que tipo de dados se trata, quem ou o que pode aceder aos mesmos, como estão protegidos e onde podem estar expostos.
A maioria das empresas não dispõe de um mapa completo da localização dos dados sensíveis. Sabem que possuem dados de clientes, detalhes de pagamento, tokens, dados de colaboradores e, agora, todo o tipo de contexto relacionado com a IA. O que nem sempre sabem é onde é que todos esses dados acabaram por ficar, quem tem acesso aos mesmos ou se estão a ser tratados de forma a cumprir as suas expectativas em matéria de segurança e conformidade.
A visibilidade é o problema que o DSPM tradicional procura resolver.
O DSPM tradicional começa no local onde os dados chegaram
O DSPM tradicional começa, na maioria das vezes, pelo inventário de dados. Isso significa, normalmente, analisar os sistemas de armazenamento e as plataformas ligadas a eles: buckets S3, bases de dados, armazéns de dados, aplicações SaaS e cópias de segurança.
A ferramenta procura dados sensíveis, classifica-os, verifica as permissões e a exposição e ajuda a equipa de segurança a dar prioridade ao que é importante. Pode indicar-lhe que um bucket do S3 contém dados de identificação pessoal (PII). Ou que uma tabela do warehouse contém dados relacionados com pagamentos. Ou que um recurso partilhado está acessível a um público demasiado vasto. Ou que uma cópia de segurança contém registos de clientes de produção armazenados num local que ninguém consulta há um ano.
Isso é obviamente útil. Há muitos dados confidenciais a circular em ambientes modernos, e grande parte deles é copiada, replicada, exportada, registada, sincronizada, arquivada e esquecida. O DSPM tradicional ajuda as equipas a localizar esses dados. Proporciona à equipa de segurança uma visão mais abrangente do conjunto real de dados, para além dos recursos na nuvem que o rodeiam.
Mas, para os programadores e AppSec , isso é, muitas vezes, apenas a segunda parte da história.
A primeira parte explica como os dados chegaram até lá.
A questão que falta é o percurso do código
Uma ferramenta tradicional de DSPM poderia indicar: «Foram detetados dados de identificação pessoal (PII) neste repositório de registos.»
Mas o programador ainda tem de descobrir por que razão os dados pessoais estão lá, que parte da aplicação os inseriu, se foi intencional e que alteração resolveria realmente o problema. E, para isso, é necessário analisar o código.
A aplicação recolheu os dados, processou-os e decidiu quais os campos a devolver a partir de uma API. Em seguida, registou o corpo do pedido, transmitiu um token a um trabalhador, enviou metadados do cliente a um fornecedor e criou o prompt que incluía contexto sensível.
Assim, a questão mais específica para os programadores deve ir além de «Onde estão armazenados os dados sensíveis?» e ser mais do tipo «Que percurso de código criou a exposição?». Essa é a versão «shift-left» do DSPM.
O DSPM baseado em código começa pela aplicação, em vez de pela camada de armazenamento. Analisa APIs, modelos ORM, chamadas de registo, consumidores de filas, fluxos de trabalho de CI/CD, integrações de IA e muito mais. O objetivo é compreender como os dados sensíveis entram no sistema, como se deslocam, onde são armazenados, por onde saem e onde podem ser tratados de forma inadequada.
Auditorias ao DSPM baseadas em código e à exposição de dados
No Aikido, penso que a forma mais clara de descrever o nosso DSPM baseado em código é a de uma «Auditoria de Exposição de Dados», que consiste em utilizar IA para identificar fluxos de dados sensíveis e riscos de segurança no código.
Uma auditoria de exposição de dados é diferente. Analisa o código e procura compreender como os dados sensíveis circulam nesta aplicação e onde esse fluxo gera riscos. Abrange PII, PHI, PCI, secrets, tokens, conteúdos dos clientes e o tratamento de dados relacionados com a IA. Cada resultado é acompanhado de provas e de uma correção no código, sem necessidade de ligação direta às bases de dados.
A análise do código também permite detetar falhas na proteção de dados. Pode identificar um campo sensível armazenado sem encriptação, uma chave codificada diretamente no código-fonte, o uso de MD5, SHA1 ou base64 como se fossem métodos de encriptação, um segredo submetido ao repositório e dados sensíveis enviados através de um canal não seguro.
Há outra forma de encarar isto. O DSPM tradicional necessita de acesso aos seus dados reais, ligando-se a buckets do S3, bases de dados e armazéns de dados para analisar o seu conteúdo. Em contrapartida, o DSPM baseado em código lê o código que cria e transfere esses dados, pelo que nunca solicita acesso nem descarrega nada. A leitura a partir do código reduz as dificuldades para ativar o sistema, uma vez que não é necessário conceder nenhum novo acesso ao ambiente de produção.
Isso também o torna mais rápido, uma vez que não há nada para rastrear. É também mais preciso, pois analisa a forma como um campo é utilizado, em vez de partir do princípio de que qualquer número de nove dígitos é um número de Segurança Social. O resultado é um mapa que mostra onde se encontram os dados sensíveis na sua arquitetura e como estão protegidos, criado inteiramente a partir do código.
No Aikido, isto faz parte da análise de código com IA, pelo que a Auditoria de Exposição de Dados é realizada em conjunto com o resto da revisão de código, em vez de ser uma integração de acesso a dados separada
Em que medida a qualidade dos resultados difere
Tomemos a exploração florestal como um exemplo simples.
Um produto DSPM tradicional pode, eventualmente, indicar que existem dados de identificação pessoal (PII) nos registos da aplicação. Mais uma vez, é útil. Mas agora alguém tem de ir à procura da fonte.
Uma auditoria à exposição de dados baseada no código pode apresentar um panorama mais completo, ao estabelecer ligações entre os dados, o percurso do código, o destino, o risco de exposição e a correção. Isto torna-a mais útil para os programadores.
Por exemplo, o controlador de checkout regista o objeto `billingDetails` na íntegra quando a autorização de pagamento falha. Esse objeto inclui o e-mail, o número de telefone, a morada de faturação e os últimos quatro dígitos do cartão. Os registos são enviados para o Datadog. A correção consiste em ocultar esses campos antes do registo e manter apenas o ID do cliente, o ID da intenção de pagamento e o código de erro.
Essas informações são muito diferentes das que se obtêm com um DSPM tradicional.
O mesmo se aplica a secrets tokens. Tomemos como exemplo um token de SCM utilizado para ler código do GitHub, do GitLab ou do Bitbucket. Uma perspetiva orientada para o armazenamento poderia questionar se o token está encriptado na base de dados. No entanto, isto não é toda a história.
Onde é que o token entra na plataforma? Trata-se de um token OAuth, de um token de aplicação do GitHub ou de um PAT enviado pelo utilizador? Que âmbitos tem? Como é validado? Onde é encriptado? Onde é armazenado? Quando é desencriptado? É armazenado em cache? Está incorporado numa URL de clone? É transmitido a um worker? Poderá haver uma fuga de informação através de registos, rastreios, erros, argumentos de processo ou telemetria? Trata-se de um problema de segurança de dados, mas o código diz-nos o que precisamos de saber sobre o seu percurso.
Do painel de controlo à resolução
É aqui que, na minha opinião, o DSPM baseado em código se torna interessante.
A melhor abordagem não é mais um painel que diga: «Tem dados confidenciais.» Todos sabem disso. A melhor experiência consiste em apresentar o inventário dos dados confidenciais, o fluxo, o risco de exposição, os controlos relevantes e a alteração no código que reduz o risco.
Se foi o código que causou a falha, a correção provavelmente deve ser feita no próprio código.
O fluxo de trabalho típico de um programador deve, portanto, ser o seguinte:
- Ocultar os campos confidenciais antes do registo.
- Devolve um objeto de resposta da API mais pequeno.
- Adicionar uma verificação da titularidade do inquilino.
- Deixem de passar tokens nas URLs.
- Enmascarar os dados de produção antes de os restaurar no ambiente de teste.
- Aplicar encriptação antes do armazenamento.
- Remover os dados do cliente de um prompt de LLM.
- Corrigir a lógica de eliminação para que os registos a jusante sejam efetivamente removidos.
O engenheiro quer saber qual o percurso de código específico que cria um risco específico de exposição de dados e como resolver o problema.
Isto também torna a ligação às estruturas de segurança e conformidade muito mais concreta. Se um token for mal gerido, isso pode ter implicações na gestão de autenticadores, na proteção da transmissão, no princípio do privilégio mínimo e na proteção dos registos de auditoria. Se as informações de identificação pessoal (PII) forem registadas sem serem ocultadas, isso pode ter implicações em termos de privacidade, retenção, minimização de dados e controlos de monitorização. Se os dados dos clientes forem copiados para um ambiente de teste sem serem mascarados, isso pode afetar o controlo de acesso, a separação de ambientes e as obrigações de conformidade. Se os registos sobreviverem a um pedido de eliminação, ou se os dados permanecerem para além do seu período de retenção, isso está diretamente relacionado com as obrigações do RGPD e da CCPA, e isso tem de ser corrigido na própria lógica de eliminação e retenção.
A conclusão que se limita a indicar «Padrão de registo inseguro» tem uma utilidade bastante limitada. Porém, algo como «Os dados pessoais identificáveis (PII) dos clientes que entram nos registos através deste caminho de código criam um risco de exposição de dados, afetam estes controlos e podem ser corrigidos através da supressão destes campos antes do registo» é passível de ação.
Essa é uma forma muito melhor de integrar a engenharia, AppSec e a conformidade numa única discussão.
A versão simples
O DSPM tradicional continua a ser importante. Ajuda as equipas a compreender onde se encontram os dados sensíveis no ambiente real. Permite detetar buckets esquecidos, bases de dados expostas, dados ocultos e repositórios com permissões excessivas.
No entanto, o DSPM baseado em código acrescenta a camada de aplicação que faltava. Ajuda a explicar como os dados sensíveis chegam até lá, como se deslocam, onde se encontra o mecanismo de exposição e o que os programadores podem fazer a esse respeito.
Portanto, a versão simplificada fica assim:
O DSPM tradicional identifica os dados sensíveis no local onde se encontram.
O DSPM baseado em código identifica como é que os dados sensíveis ficam expostos.
Uma auditoria à exposição de dados estabelece a ligação entre esse fluxo, o código, a lacuna de controlo e a correção.
Essa é a versão «shift-left» do DSPM. E, para os programadores e AppSec , é provavelmente a versão que mais ajuda as equipas.
Aikido a primeira solução do género em DSPM baseada em código. Proteja e acompanhe os seus dados, sem sequer ter de ligar as suas bases de dados.
