Criptografia no armazenamento de dados – Parte 3: gestão de chaves, LGPD/GDPR e plano de ação

Parte 3 de 3 – Governação e implementação

Nas partes anteriores desta série, vimos os fundamentos da criptografia e como usar criptografia simétrica e assimétrica no armazenamento de dados. Agora, vamos tratar do que realmente sustenta tudo isto: gestão de chaves, ligação à LGPD/GDPR, erros comuns e um plano prático de ação.

1. Gestão de chaves: o coração da criptografia

Criptografia sem boa gestão de chaves é, na prática, uma falsa sensação de segurança. Se a chave é exposta, todo o esforço de cifrar dados perde valor.

Alguns princípios essenciais de Key Management:

1.1 Nunca guardar a chave junto dos dados

Um erro comum é armazenar a chave de criptografia no mesmo servidor (ou até na mesma pasta) em que os dados cifrados estão. Por exemplo:

• chaves em ficheiros de configuração sem proteção;
• segredos hardcoded no código-fonte;
• variáveis de ambiente expostas a qualquer processo no servidor.

Se o atacante comprometer o servidor, terá acesso tanto aos dados cifrados como às chaves, anulando a proteção. Em vez disso, utilize:

• cofres de segredos (Secrets Manager, Parameter Store, Vault, etc.);
• serviços de KMS (Key Management Service) com controlo de acesso e registos;
• HSMs (Hardware Security Modules) quando o nível de criticidade o exigir.

1.2 Rotação periódica de chaves

Rotacionar chaves reduz o impacto de um vazamento. Boas práticas incluem:

• definir uma política clara de periodicidade (por exemplo, a cada 6 ou 12 meses);
• automatizar ao máximo a rotação para evitar erros humanos;
• ter um plano para recriptografar dados antigos quando necessário.

1.3 Segregação de funções

Nem toda a pessoa que administra a base de dados precisa de ter acesso às chaves. E nem todo programador deve conseguir desencriptar dados de produção.

Uma boa estratégia é separar papéis como:

• Infraestrutura (quem cuida de servidores e redes);
• segurança e gestão de chaves;
• desenvolvimento e suporte.

Esta segregação reduz o risco de abuso interno e apoia práticas de governação mais maduras.

1.4 Monitorização e auditoria

Registo e análise de logs são fundamentais. Alguns pontos para monitorizar:

• quem solicitou o uso de determinada chave;
• quando e de que sistema/IP partiu o pedido;
• em que contexto (produção, homologação, testes).

Numa investigação de incidente, estes registos ajudam a reconstruir o cenário com precisão e a tomar decisões rápidas.

2. Criptografia alinhada à LGPD, GDPR e normas de mercado

Praticamente todas as organizações lidam com dados pessoais em algum nível. Leis como a LGPD no Brasil e o GDPR na União Europeia exigem que empresas adotem medidas técnicas e administrativas para proteger essas informações.

A criptografia aparece nessas regulamentações como uma das principais medidas recomendadas. Alguns benefícios concretos:

• Redução do risco regulatório: dados pessoais fortemente criptografados, com chaves bem protegidas, tendem a reduzir o impacto de incidentes do ponto de vista legal;
• Melhor postura em auditorias: apresentar políticas de criptografia, gestão de chaves e monitorização ajuda a demonstrar diligência;
• Alinhamento com normas como ISO 27001, PCI-DSS e outras, que frequentemente exigem ou recomendam criptografia em repouso.

Importante: criptografia por si só não garante conformidade, mas é uma peça essencial de um programa estruturado de privacidade e segurança.

3. Erros comuns ao implementar criptografia em armazenamento

Algumas armadilhas repetem-se em muitos projetos. Entre as mais comuns:

1. Usar algoritmos obsoletos ou inseguros
   Algoritmos antigos, como DES ou 3DES, ou chaves com tamanho insuficiente, podem não oferecer proteção adequada hoje. Prefira padrões atuais, revistos pela comunidade e autoridades de segurança.
2. “Inventar” algoritmos ou protocolos próprios
   Criptografia caseira é fonte frequente de vulnerabilidades. Utilize bibliotecas consolidadas, bem testadas e ativamente mantidas.
3. Esquecer de criptografar backups e logs
   Muitas organizações protegem apenas o ambiente de produção principal, mas deixam dumps de base, backups antigos e logs sensíveis em texto claro.
4. Armazenar chaves em texto claro no código ou repositórios
   Commits com chaves, palavras-passe e tokens expostos são uma das causas mais comuns de incidentes. Use cofres de segredos e boas práticas de gestão de credenciais.
5. Ignorar o impacto na performance
   A criptografia tem custo de processamento. É preciso escolher com cuidado o que será cifrado em nível de disco, base, aplicação ou objeto, e testar o impacto.
6. Não testar cenários de recuperação
   Não adianta criptografar se, num incidente, não sabe restaurar acessos nem recuperar dados. Teste regularmente cenários de desastre e recuperação de chaves.

4. Checklist prático: por onde começar (ou evoluir) a sua estratégia

Para transformar conceitos em ação, use este checklist como guia:

1. Mapear dados sensíveis
   • Que tipos de dados pessoais, financeiros ou estratégicos armazena?
   • Onde eles estão (bases, ficheiros, backups, cloud, postos de trabalho)?
2. Classificar ativos
   • Separar dados por nível de criticidade (alto, médio, baixo);
   • identificar o que precisa ser protegido com mais urgência.
3. Ativar criptografia de disco/volume quando disponível
   • ativar criptografia nativa em volumes de cloud;
   • usar LUKS, BitLocker ou alternativas equivalentes em servidores e estações.
4. Avaliar TDE nas bases de dados
   • verificar se o SGBD oferece criptografia transparente;
   • entender impacto em performance, backup e restore.
5. Definir campos sensíveis para criptografia em nível de aplicação
   • documentos pessoais, credenciais, segredos de negócio;
   • desenhar como cifrar/decifrar e como tratar pesquisas e relatórios.
6. Implementar um serviço de gestão de chaves
   • escolher um KMS ou cofre de segredos fiável;
   • definir quem pode aceder a cada chave e em que ambientes.
7. Combinar criptografia simétrica e assimétrica
   • usar algoritmos simétricos para cifrar os dados;
   • usar infraestrutura assimétrica para proteger as data keys (envelope encryption).
8. Documentar políticas e procedimentos
   • como as chaves são criadas, rotacionadas e revogadas;
   • quem é responsável por cada etapa do processo.
9. Monitorizar e auditar
   • registar o uso de chaves e acessos a dados cifrados;
   • rever periodicamente eventos suspeitos.
10. Formar as equipas
    • programadores, DBAs e equipas de infraestrutura devem entender o básico de criptografia;
    • reforçar boas práticas para evitar erros clássicos (como chaves hardcoded).

5. Conclusão: criptografia como estratégia de negócio

A criptografia em dados em repouso deixou de ser um detalhe técnico para se tornar parte da estratégia de negócio. Organizações que levam este tema a sério:

• reduzem a probabilidade e o impacto de vazamentos;
• protegem a sua reputação e a confiança de clientes e parceiros;
• estão mais preparadas para cumprir LGPD, GDPR e normas de mercado;
• respondem a incidentes com mais clareza, rapidez e transparência.

Ao combinar criptografia simétrica para grandes volumes de dados com criptografia assimétrica e uma boa gestão de chaves, constrói uma camada robusta de defesa, alinhada com as melhores práticas do mercado.

Se a sua organização ainda não tem uma estratégia clara de criptografia em repouso, o melhor momento para começar é agora. Dê os primeiros passos com o checklist acima, evolua a arquitetura e integre a criptografia aos processos de governação de dados e privacidade.

Dica extra: se pretende ir além e estruturar a governação de dados pessoais com transparência para titulares e conformidade com LGPD/GDPR, explore soluções como a Unova para centralizar consentimentos, registos e provas de conformidade.