Como proteger dados de clientes (PII e dados financeiros) em um SaaS ou fintech

O modelo de ameaça de um SaaS que custodia dados de terceiros

Quando um SaaS ou fintech armazena PII e dados financeiros de seus clientes, ele assume a posição de operador (controlador-operador, na linguagem da LGPD) de dados que não são seus. Isso muda o modelo de ameaça: o atacante não busca apenas a sua operação, mas o agregado de dados de todos os seus tenants concentrado em uma única plataforma. Um único comprometimento pode expor milhares de titulares de uma vez, e a superfície inclui credenciais de aplicação, chaves de API, acessos administrativos internos e o próprio plano de controle do provedor de nuvem.

O NIST SP 800-53 e o NIST Cybersecurity Framework organizam essa defesa em funções (Identificar, Proteger, Detectar, Responder, Recuperar) e o princípio que atravessa todas elas é defesa em profundidade: nenhum controle único deve ser o ponto entre o atacante e os dados em claro. O OWASP, no Top 10 de aplicações (A02:2021 Cryptographic Failures, A01:2021 Broken Access Control) e nas cheat sheets, descreve os pontos onde aplicações SaaS tipicamente falham — quase sempre na gestão de chaves, no controle de acesso e no isolamento, não na escolha do algoritmo de cifra.

Para o resto deste artigo, o foco é técnico e preventivo: as camadas concretas que reduzem o impacto de um comprometimento, na ordem em que costumam ser atacadas. Conformidade legal (LGPD) é o contexto, mas o objetivo aqui é a proteção técnica do dado, não o atendimento documental ao regulador.

Criptografia em trânsito e em repouso, e a gestão de chaves que importa

Criptografia em trânsito é o controle mais maduro e menos negociável: TLS 1.2 como mínimo, preferindo TLS 1.3, com suítes de cifra modernas, HSTS e desativação de protocolos e cifras obsoletos (SSLv3, TLS 1.0/1.1, RC4, 3DES). Isso vale para o tráfego cliente-servidor e também para o tráfego interno entre microsserviços e entre a aplicação e o banco de dados — o perímetro interno não é confiável por padrão. A OWASP Transport Layer Security Cheat Sheet e os benchmarks do CIS detalham a configuração segura.

Em repouso, AES-256 (GCM para dados de aplicação, com autenticação) é o padrão prático, e a maioria dos provedores oferece criptografia de volume e de banco transparente. O ponto crítico, porém, não é a cifra: é onde a chave vive. Chaves embutidas em código, em variáveis de ambiente em texto claro ou em arquivos de configuração anulam todo o resto. A recomendação do NIST SP 800-57 (gestão de chaves) e a prática consolidada é usar um KMS dedicado (AWS KMS, Google Cloud KMS, Azure Key Vault ou HSM) com envelope encryption: a chave de dados cifra o dado, e a chave mestra do KMS cifra a chave de dados, sem nunca sair do módulo.

Sobre o KMS devem incidir três disciplinas. Rotação automática de chaves em intervalo definido, com versionamento que permita decifrar dados antigos. Separação de funções, de modo que quem opera a aplicação não seja quem administra as chaves mestras, e que o acesso de decifração seja autorizado por política e registrado. E criptografia em nível de campo para os dados mais sensíveis (CPF, dados bancários, segredos de cliente), de modo que mesmo um dump completo do banco não revele o conteúdo sem o acesso à chave correspondente.

Vale distinguir o que cada camada protege. Criptografia de disco protege contra perda física e descarte indevido de mídia. Criptografia transparente de banco protege contra acesso direto ao arquivo. Apenas a criptografia em nível de campo, com chave fora do banco, protege o dado contra uma credencial de aplicação comprometida ou uma injeção de SQL bem-sucedida — que é o cenário mais provável em um SaaS exposto à internet.

Tokenização e mascaramento: reduzir o que existe para ser roubado

A forma mais eficaz de proteger um dado sensível é não tê-lo onde não precisa estar. Tokenização substitui o dado real (número de cartão, CPF, conta bancária) por um token sem valor matemático fora do cofre que mantém o mapeamento. A aplicação, os logs e a maior parte do banco passam a operar sobre tokens; o dado original fica concentrado em um único componente fortemente controlado. Para dados de cartão, o PCI DSS trata a tokenização como mecanismo central de redução de escopo, e o mesmo raciocínio se aplica a qualquer PII de alto valor.

Mascaramento atua na exposição: ao exibir, exportar ou usar dados em ambientes não produtivos, apresenta-se apenas o necessário (os quatro últimos dígitos, por exemplo) ou um valor substituto realista. Ambientes de desenvolvimento, homologação e analytics não devem receber PII real — a anonimização ou pseudonimização de dados antes de saírem da produção elimina uma fonte recorrente de vazamento por baixos controles em ambientes secundários.

Esses controles reforçam a minimização: cada campo coletado e retido amplia a superfície. Vale auditar o que realmente é necessário, definir período de retenção por categoria de dado e implementar expurgo automático ao fim do prazo. Dado que não existe não vaza, e dado que já foi descartado dentro de uma política clara reduz tanto o risco técnico quanto a exposição em caso de incidente.

Isolamento multi-tenant, controle de acesso e auditoria

Em um SaaS multi-tenant, o vazamento entre clientes é uma das falhas mais graves e específicas do modelo. Há três estratégias principais: banco de dados por tenant (maior isolamento, maior custo operacional), schema por tenant, e tabela compartilhada com identificador de tenant e segregação por linha. Quando se usa a abordagem compartilhada, o controle não pode depender apenas da camada de aplicação lembrar de filtrar por tenant: Row-Level Security no banco, aplicada de forma obrigatória, garante o isolamento mesmo se uma consulta esquecer a cláusula. Cada caminho de código que toca dados precisa ser validado contra o cenário de confusão de tenant.

O controle de acesso segue o princípio de menor privilégio do NIST SP 800-53 (família AC) e do CIS Controls v8: cada identidade, humana ou de serviço, recebe apenas o acesso necessário, por tempo necessário. Para dados sensíveis, acesso administrativo deve ser just-in-time e aprovado, com MFA resistente a phishing, e contas de serviço devem ter credenciais de curta duração em vez de chaves estáticas. RBAC ou ABAC bem modelados evitam que um suporte de primeiro nível ou um job de batch tenha alcance amplo demais.

Auditoria fecha o ciclo. Toda leitura e escrita de dados sensíveis, todo acesso administrativo e toda operação de decifração devem gerar registro com identidade, recurso, ação e horário, em trilha imutável e centralizada, fora do alcance de quem é auditado. Sem isso, um acesso indevido é indistinguível de uso legítimo, e a fase de Detecção do NIST CSF não tem matéria-prima. Logs de auditoria também são o insumo que permite detectar exfiltração lenta e abuso de credencial interna antes que escalem.

Prevenção e detecção de vazamento de dados

Mesmo com cifra, tokenização e acesso restrito, dados escapam por caminhos laterais: segredos commitados em repositórios, chaves de API expostas em logs ou em respostas de erro, exportações volumosas não monitoradas, e bancos ou buckets mal configurados e expostos à internet. Prevenção de perda de dados (DLP) e varredura contínua de segredos no código e na infraestrutura cobrem boa parte desses vetores, assim como revisão de configuração de armazenamento e endurecimento da postura de nuvem (CSPM).

Detecção complementa a prevenção. Monitoramento de comportamento de acesso (volumes anômalos de leitura, acesso fora de horário, padrões de exfiltração) e correlação de eventos em um SOC permitem reagir enquanto o incidente ainda é contível. E como parte dos dados vazados só aparece depois — credenciais e bases à venda em fóruns e mercados — o monitoramento de exposição em fontes externas e dark web encurta o tempo entre o vazamento e a resposta, permitindo rotacionar credenciais e notificar antes que o dado seja amplamente explorado.

É aqui que a Decripte atua como parceira técnica: monitoramento e SOC para detecção e resposta, vigilância de dark web para identificar credenciais e dados expostos da sua organização e dos seus clientes, e segurança preventiva para fechar as lacunas de configuração e acesso antes que virem incidente. Para times que estão estruturando essa camada, a Decripte oferece um plano gratuito de Gestão de Ameaças, um ponto de partida para mapear exposição sem custo inicial.

Checklist prático

1. 1

   1. Mapeie e classifique os dados sensíveis

   Inventarie onde PII e dados financeiros são coletados, trafegam e persistem (bancos, caches, filas, logs, backups, ambientes não produtivos). Classifique por sensibilidade e defina o tratamento exigido para cada categoria antes de aplicar controles.

2. 2

   2. Force criptografia em trânsito

   Exija TLS 1.2+ (preferindo 1.3) com HSTS no tráfego externo e também entre serviços internos e bancos. Desative protocolos e cifras obsoletos seguindo a OWASP TLS Cheat Sheet e os benchmarks do CIS.

3. 3

   3. Centralize as chaves em um KMS

   Migre chaves embutidas para um KMS ou HSM com envelope encryption, rotação automática, versionamento e separação de funções entre operação da aplicação e administração das chaves. Aplique criptografia em nível de campo aos dados mais sensíveis.

4. 4

   4. Tokenize e mascare

   Substitua números de cartão, CPF e dados bancários por tokens, mantendo o dado real apenas no cofre. Mascare em telas, exportações e logs, e remova ou pseudonimize PII de ambientes de desenvolvimento e analytics.

5. 5

   5. Garanta o isolamento entre tenants

   Escolha a estratégia de isolamento de forma explícita e, em modelos compartilhados, aplique Row-Level Security no banco. Inclua testes que validem que nenhum caminho de código retorna dados de outro tenant.

6. 6

   6. Aplique menor privilégio e auditoria

   Modele RBAC/ABAC com acesso just-in-time e MFA resistente a phishing para dados sensíveis. Use credenciais de curta duração para serviços e registre toda leitura, escrita e decifração em trilha de auditoria imutável e centralizada.

7. 7

   7. Monitore vazamento e exposição

   Implante DLP e varredura de segredos, revise a configuração de buckets e bancos expostos e estabeleça monitoramento contínuo de acesso anômalo e de exposição em dark web para reduzir o tempo de resposta a incidentes.

Perguntas frequentes