O que significa “proteção de dados e criptografia” na prática
Proteger dados não é apenas “colocar senha” ou “ativar criptografia”. Na prática, é garantir que a informação permaneça confidencial, íntegra e disponível ao longo do seu ciclo de vida (criação, uso, compartilhamento, armazenamento, arquivamento e descarte), com controles proporcionais ao impacto de um vazamento, alteração indevida ou indisponibilidade. A criptografia é uma das ferramentas mais fortes para isso, mas ela só funciona bem quando vem acompanhada de regras de uso, gestão de chaves e exceções controladas.
Um erro comum é tratar criptografia como um item de checklist (“criptografar tudo”) ou como um obstáculo (“cripto atrapalha performance”). Em governança prática, o objetivo é: (1) definir onde criptografia é obrigatória, (2) padronizar como ela será aplicada, (3) garantir que as chaves sejam protegidas e recuperáveis, (4) permitir exceções apenas quando houver justificativa técnica/negócio e compensações, e (5) evidenciar que isso está funcionando no dia a dia.
Onde a criptografia entra: dados em trânsito, em repouso e em uso
Dados em trânsito
São dados trafegando entre sistemas, usuários, APIs, integrações, dispositivos e redes. O controle típico é criptografia de transporte (ex.: TLS). Aqui, as regras precisam evitar “meia criptografia”, como aceitar protocolos antigos, certificados inválidos ou ignorar validação de hostname.
- Exemplo prático: um portal interno que usa HTTPS, mas permite TLS 1.0 para “compatibilidade”. Isso cria risco desnecessário. A regra deve definir versões mínimas e suites de cifra aprovadas.
- Exemplo prático: integrações entre microserviços dentro da mesma rede. Mesmo “interno”, o tráfego pode ser interceptado. Regra: TLS/mTLS para chamadas sensíveis, com rotação de certificados.
Dados em repouso
São dados armazenados em discos, bancos, backups, objetos em nuvem, arquivos em endpoints e mídias removíveis. A criptografia aqui reduz impacto de perda/roubo de mídia, acesso indevido a storage e exposição acidental de backups.
- Exemplo prático: notebook corporativo com criptografia de disco (FDE). Se for perdido, o risco de vazamento diminui drasticamente.
- Exemplo prático: banco de dados com criptografia transparente (TDE) e/ou criptografia em nível de coluna para campos altamente sensíveis (ex.: documentos, chaves, segredos).
Dados em uso
São dados sendo processados na memória, exibidos em tela, manipulados por aplicações e usuários. Criptografia “pura” nem sempre resolve aqui; entram mascaramento, tokenização, segregação de ambientes, controles de sessão e redução de exposição (ex.: não logar dados sensíveis).
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
- Exemplo prático: central de atendimento que precisa ver apenas os 4 últimos dígitos de um identificador, não o valor completo. A regra é “minimização”: mostrar o mínimo necessário.
- Exemplo prático: logs de aplicação que registram payloads completos de requisições e acabam armazenando dados pessoais. A regra deve proibir e orientar sanitização.
Regras de uso: o que deve estar definido (sem burocracia)
“Regras de uso” são decisões claras e aplicáveis, que orientam times técnicos e áreas de negócio sobre quando e como criptografar, e o que é proibido. Para funcionar, precisam ser objetivas, testáveis e conectadas a padrões técnicos.
1) Escopo: quais dados entram nas regras
Defina categorias de dados que exigem proteção reforçada. Evite listas enormes; foque em classes que mudam decisões técnicas.
- Dados pessoais e sensíveis: identificadores, dados financeiros, saúde, biometria, credenciais.
- Segredos: senhas, tokens, chaves de API, chaves privadas, certificados.
- Dados estratégicos: propriedade intelectual, preços, contratos, roadmap.
2) Onde criptografia é obrigatória
Transforme em regras do tipo “SE/ENTÃO” para reduzir interpretação.
- Em trânsito: se o dado sair do processo local (rede, API, fila, integração), então usar TLS com versões mínimas aprovadas; para integrações sensíveis, usar mTLS.
- Em repouso: se o dado estiver em dispositivo móvel/endpoint, então criptografia de disco obrigatória; se estiver em storage compartilhado, então criptografia do volume/objeto; se for backup, então criptografia obrigatória antes de sair do ambiente de produção.
- Em bancos: se a tabela contém dados pessoais/sensíveis, então TDE e/ou criptografia de coluna conforme criticidade; se for segredo, então nunca armazenar em texto puro (usar cofre de segredos).
3) O que é proibido
Regras negativas evitam “atalhos” perigosos.
- Proibido armazenar senhas em texto puro ou com hash fraco; usar algoritmos de hash adequados para senha (com salt e custo).
- Proibido enviar dados sensíveis por e-mail sem proteção; quando inevitável, usar canal seguro e criptografia ponta a ponta aprovada.
- Proibido desativar validação de certificado em clientes (ex.: “ignore SSL errors”).
- Proibido colocar segredos em repositórios de código, imagens de container, planilhas compartilhadas ou tickets.
4) Padrões mínimos de criptografia (o “como”)
Sem entrar em “receita de bolo” excessiva, defina mínimos que possam ser auditados por configuração.
- Transporte: TLS com versões modernas e configurações seguras; certificados válidos e gerenciados; rotação e revogação.
- Armazenamento: criptografia forte em volumes/objetos; chaves gerenciadas com controle de acesso; rotação periódica quando aplicável.
- Aplicação: bibliotecas criptográficas aprovadas; proibição de algoritmos obsoletos; uso de geradores de números aleatórios criptograficamente seguros.
5) Gestão de chaves: o coração do controle
Criptografia sem gestão de chaves é “cadeado com a chave pendurada”. As regras devem cobrir:
- Propriedade e custódia: quem administra chaves (time de plataforma/segurança) e quem pode solicitar uso.
- Armazenamento: chaves privadas e segredos em módulos/serviços apropriados (HSM/KMS/cofre), não em arquivos ou variáveis expostas.
- Rotação: periodicidade e gatilhos (ex.: suspeita de comprometimento, troca de fornecedor, desligamento de colaborador com acesso privilegiado).
- Backup e recuperação: como recuperar chaves sem criar um “super usuário” sem controle; uso de split knowledge e dual control quando necessário.
- Segregação: chaves diferentes por ambiente (dev/homolog/prod) e por domínio de dados; evitar reutilização.
Exceções controladas: por que existem e como evitar que virem regra
Exceções existem porque a realidade tem legado, limitações técnicas, requisitos de performance, integrações com terceiros e prazos. O problema não é ter exceção; é ter exceção sem controle, sem prazo e sem compensação. Exceção controlada é uma autorização temporária, rastreável e revisada, com medidas alternativas que reduzem o risco.
Quando uma exceção pode ser aceitável
- Compatibilidade com legado: um equipamento industrial ou sistema antigo que não suporta TLS moderno.
- Limitação técnica temporária: migração em andamento para um serviço de chaves gerenciadas.
- Requisito de negócio com alternativa: parceiro que só aceita um formato específico, mas permite canal dedicado e controles adicionais.
Quando uma exceção não deve ser aceita
- “Porque é mais rápido desenvolver sem criptografia”.
- “Porque sempre foi assim” sem plano de correção.
- “Porque ninguém vai ver” (segurança por obscuridade).
O que toda exceção precisa ter
Para ser prática, a exceção deve caber em uma página (ou um ticket bem estruturado) e conter campos objetivos:
- Regra/padrão violado: qual requisito de criptografia não será atendido.
- Escopo: sistemas, dados, ambientes, usuários afetados.
- Justificativa: motivo técnico/negócio, com evidência (ex.: documentação do fornecedor).
- Avaliação de impacto: o que pode acontecer se houver vazamento/interceptação.
- Controles compensatórios: o que será feito para reduzir risco (ex.: segmentação de rede, allowlist de IP, túnel VPN, monitoramento reforçado, limitação de dados).
- Prazo de validade: data de expiração curta e realista.
- Plano de remediação: ações e marcos para voltar ao padrão.
- Aprovação: dono do sistema + segurança (e, quando aplicável, jurídico/privacidade), com registro.
Passo a passo prático: implementando regras de criptografia e exceções controladas
Passo 1: mapear “pontos de exposição” de dados
Liste onde dados sensíveis entram, saem e são armazenados. Não precisa ser perfeito; comece pelos fluxos mais críticos.
- APIs públicas e integrações com parceiros
- Bancos de dados principais e réplicas
- Backups e exportações (CSV, relatórios)
- Endpoints (notebooks, celulares, VDI)
- Filas, streams, data lake/warehouse
- Logs, APM, observabilidade
Resultado esperado: uma visão de “onde criptografia importa” para priorizar.
Passo 2: definir um conjunto curto de regras “SE/ENTÃO”
Crie regras que possam ser verificadas por configuração e que orientem decisões. Exemplo de conjunto inicial:
- Todo tráfego HTTP deve ser HTTPS com TLS moderno; exceções exigem túnel seguro e prazo.
- Todo backup que contenha dados pessoais deve ser criptografado antes de ser armazenado fora do ambiente de produção.
- Segredos devem estar em cofre de segredos; é proibido armazenar em código ou arquivos de configuração.
- Dispositivos corporativos devem ter criptografia de disco habilitada e verificada.
- Logs não devem conter dados sensíveis; quando necessário para diagnóstico, usar mascaramento.
Passo 3: traduzir regras em padrões técnicos reutilizáveis
Para reduzir atrito, forneça “blocos prontos”:
- Templates de configuração para TLS em servidores e proxies
- Bibliotecas internas para criptografia de campo e mascaramento
- Blueprints de armazenamento criptografado (volumes, objetos, bancos)
- Pipeline que bloqueia segredos em commits e imagens
Exemplo prático: um template de API gateway que já vem com HTTPS obrigatório, redirecionamento de HTTP para HTTPS desabilitado (para evitar downgrade), cabeçalhos de segurança e logs sanitizados.
Passo 4: implementar gestão de chaves com separação e rastreabilidade
Escolha um mecanismo padrão para chaves e segredos (KMS/HSM/cofre). O importante é padronizar e registrar uso.
- Crie chaves por domínio (ex.: “dados_clientes_prod”, “backups_prod”).
- Defina políticas de acesso por serviço/identidade, não por usuário humano.
- Habilite auditoria de uso de chaves (quem/qual serviço/quando).
- Defina rotação e procedimento de emergência (comprometimento).
Exemplo prático: um serviço de processamento usa uma identidade de workload para solicitar descriptografia apenas em tempo de execução; desenvolvedores não têm acesso direto à chave de produção.
Passo 5: cobrir os “vazamentos silenciosos”: logs, exports e ambientes não produtivos
Muitos incidentes acontecem fora do banco principal.
- Logs: implemente filtros para remover/mascarar campos sensíveis; proíba log de payload completo em produção.
- Exports: relatórios e CSVs devem ser gerados com expiração, acesso restrito e, quando necessário, criptografia.
- Não produção: use dados mascarados/tokenizados; se precisar de dados reais por exceção, trate como exceção formal com prazo.
Passo 6: criar o fluxo de exceção controlada (simples e rápido)
Um fluxo lento incentiva “jeitinho”. Faça um processo leve, com SLA e critérios claros.
- Entrada: formulário/ticket com campos obrigatórios (regra violada, escopo, prazo, compensações).
- Triagem: segurança valida se é exceção legítima ou se há alternativa padrão.
- Aprovação: dono do sistema + segurança; para dados pessoais, incluir privacidade quando aplicável.
- Registro: exceção recebe ID, data de expiração e responsáveis.
- Revisão: revisão periódica (ex.: quinzenal/mensal) das exceções ativas.
Exemplo prático: exceção para um fornecedor que só suporta SFTP com algoritmos limitados. Compensações: IP fixo allowlist, túnel VPN site-to-site, monitoramento de transferência, retenção mínima e plano de troca do fornecedor em 90 dias.
Passo 7: evidenciar conformidade com checagens automatizadas
Sem depender de auditoria manual, use verificações técnicas:
- Scanner de configuração TLS em endpoints e APIs
- Políticas de storage que exigem criptografia habilitada
- Detecção de segredos em repositórios e pipelines
- Verificação de criptografia de disco em endpoints gerenciados
- Alertas de uso anômalo de chaves (picos, serviços inesperados)
Resultado esperado: você sabe onde está fora do padrão e consegue agir antes de virar incidente.
Controles compensatórios comuns (catálogo rápido)
Quando a criptografia padrão não é possível, escolha compensações que reduzam probabilidade e impacto. Evite compensações “cosméticas”.
- Segmentação e isolamento: rede dedicada, microsegmentação, bloqueio de tráfego lateral.
- Allowlist: restrição por IP, por identidade de serviço, por origem.
- Túnel seguro: VPN ou túnel criptografado para proteger tráfego de um protocolo legado.
- Minimização: enviar menos dados (ex.: apenas identificador, não o conjunto completo).
- Tokenização: substituir valores sensíveis por tokens, mantendo o dado real em cofre.
- Monitoramento reforçado: alertas específicos, retenção de logs, correlação de eventos.
- Tempo de vida curto: arquivos temporários com expiração automática e acesso restrito.
Exemplos práticos de regras e exceções (cenários reais)
Cenário 1: compartilhamento de arquivo com dados pessoais
Regra: arquivos com dados pessoais não podem ser compartilhados por link público; devem ter acesso autenticado, expiração e, quando enviados fora da organização, criptografia aprovada.
Exceção controlada: parceiro sem acesso ao portal autenticado. Compensações: arquivo criptografado com senha entregue por canal separado, expiração de 48 horas, registro de destinatários, remoção após confirmação de recebimento.
Cenário 2: aplicação legada sem suporte a TLS moderno
Regra: tráfego deve usar TLS moderno.
Exceção controlada: manter protocolo legado por 60 dias. Compensações: colocar a aplicação atrás de um proxy que termina TLS moderno externamente e comunica internamente em rede isolada; bloquear acesso direto; monitorar conexões; plano de atualização com data.
Cenário 3: dados em ambiente de testes
Regra: ambientes não produtivos usam dados mascarados; é proibido copiar base de produção integral.
Exceção controlada: necessidade de reproduzir bug crítico com subconjunto de dados reais. Compensações: extrair apenas registros necessários, mascarar campos não essenciais, armazenar por tempo limitado, acesso restrito, auditoria de acesso e destruição ao final.
Checklist operacional (para usar no dia a dia)
Checklist de implementação
- Tráfego externo e interno sensível protegido com TLS/mTLS conforme padrão
- Storage e backups criptografados com chaves gerenciadas
- Segredos centralizados em cofre e fora do código
- Logs sanitizados e sem dados sensíveis
- Chaves separadas por ambiente e domínio, com auditoria e rotação
Checklist de exceções
- Exceção tem ID, regra violada e escopo claro
- Tem prazo de expiração e plano de remediação
- Tem controles compensatórios verificáveis
- Tem aprovadores definidos e registro
- É revisada periodicamente e encerrada quando possível
Modelo simples de registro de exceção (campos mínimos)
- Sistema/Serviço:
- Regra/padrão não atendido:
- Dados afetados:
- Ambiente (prod/homolog/dev):
- Justificativa:
- Risco/impacto:
- Controles compensatórios:
- Data de expiração:
- Plano de remediação (marcos):
- Aprovadores:
- Evidências (links/configs):
