Data classification: identificando e protegendo dados sensíveis

1. Fundamentos da Classificação de Dados

1.1 O que é classificação de dados e por que importa para devs

Classificação de dados é o processo de categorizar informações com base no seu nível de sensibilidade, valor crítico e requisitos regulatórios. Para desenvolvedores, isso não é apenas um exercício de compliance — é uma decisão arquitetural que impacta diretamente como armazenamos, transmitimos e processamos dados. Quando você sabe que um campo é "confidencial", pode aplicar criptografia automática, restringir acesso em logs e definir políticas de retenção específicas. Sem classificação, cada dado é tratado como igual, o que leva a dois extremos: proteger demais (onerando performance e usabilidade) ou proteger de menos (criando riscos de vazamento).

A LGPD (Brasil) e o GDPR (Europa) exigem que organizações demonstrem controle sobre dados pessoais. A classificação é a base para atender a requisitos como minimização de dados, consentimento e direito à exclusão.

1.2 Níveis comuns de classificação

Nível Exemplo Acesso típico
Público Nome de produto, descrição pública Qualquer pessoa
Interno Relatórios financeiros internos, manuais Funcionários
Confidencial CPF, e-mail, dados de cartão Equipes autorizadas
Restrito Dados biométricos, segredos de negócio Indivíduos específicos

Cada nível define controles diferentes. Dados restritos exigem criptografia em repouso e em trânsito, logging de acesso e revisão periódica de permissões.

1.3 Consequências da má classificação

Em 2023, um hospital nos EUA classificou dados de pacientes como "internos" em vez de "confidenciais". Um script de backup expôs milhões de registros médicos em um bucket S3 público. Resultado: multa de US$ 1,5 milhão e danos irreparáveis à reputação. Quando a classificação falha, as proteções adequadas não são aplicadas.

2. Identificando Dados Sensíveis no Ecossistema

2.1 Mapeamento de fluxos de dados

Antes de classificar, você precisa saber onde os dados estão. Crie diagramas de fluxo de dados (DFD) que rastreiem:

  • Entrada: formulários web, APIs, uploads de arquivos
  • Trânsito: chamadas entre microsserviços, mensageria (Kafka, RabbitMQ)
  • Armazenamento: bancos relacionais, NoSQL, buckets object storage
  • Saída: relatórios, exports, logs, respostas de API

Ferramentas como draw.io ou Lucidchart ajudam a documentar visualmente. Para cada fluxo, pergunte: "que tipo de dado trafega aqui?"

2.2 Categorias de dados sensíveis

  • PII (Personally Identifiable Information): nome, CPF, RG, endereço, e-mail, telefone
  • Dados financeiros: número de cartão, conta bancária, histórico de transações
  • Dados biométricos: impressão digital, reconhecimento facial, íris
  • Dados de saúde: prontuários, exames, diagnósticos
  • Dados de crianças: qualquer PII de menores de idade (LGPD Art. 14)

2.3 Ferramentas automatizadas de descoberta

Scanners como Amazon Macie, Google DLP ou Apache Atlas podem varrer bancos e repositórios em busca de padrões. Exemplo de regex para CPF:

Pattern: [0-9]{3}\.[0-9]{3}\.[0-9]{3}-[0-9]{2}
Classification: "confidential"
Action: encrypt column

Para schemas de banco, você pode adicionar metadados:

CREATE TABLE usuarios (
    id INT PRIMARY KEY,
    nome VARCHAR(100) CLASSIFICATION 'internal',
    cpf VARCHAR(11) CLASSIFICATION 'confidential',
    email VARCHAR(100) CLASSIFICATION 'confidential'
);

3. Estratégias de Proteção Baseadas na Classificação

3.1 Controles de acesso granular

Use RBAC (Role-Based Access Control) ou ABAC (Attribute-Based Access Control) para restringir acesso com base na classificação. Exemplo de policy em Open Policy Agent (OPA):

package data_classification

default allow = false

allow {
    input.user.role == "admin"
    input.data.classification == "confidential"
}

allow {
    input.user.role == "developer"
    input.data.classification == "internal"
}

3.2 Criptografia em repouso e em trânsito

  • Em trânsito: TLS 1.3 obrigatório para todos os dados classificados como "confidencial" ou superior
  • Em repouso: AES-256 para dados confidenciais; AES-128 para internos; sem criptografia para públicos (mas com hash de integridade)
  • Gerenciamento de chaves: use AWS KMS, Azure Key Vault ou HashiCorp Vault; nunca hardcode chaves

3.3 Mascaramento e anonimização

Em logs e ambientes de staging, nunca exponha dados reais. Exemplo de mascaramento:

CPF original: 123.456.789-00
CPF mascarado: ***.456.***-00
E-mail original: joao.silva@exemplo.com
E-mail mascarado: j***@exemplo.com

Pseudonimização substitui identificadores por tokens reversíveis (útil para testes). Anonimização remove qualquer possibilidade de reidentificação (irreversível).

4. Implementando Classificação no Código

4.1 Anotações e metadados de dados

Adicione campos de classificação diretamente nos schemas:

{
    "userId": "12345",
    "name": "João Silva",
    "classification": "internal",
    "email": "joao@exemplo.com",
    "email_classification": "confidential",
    "cpf": "12345678900",
    "cpf_classification": "restricted"
}

Em Protobuf, use opções customizadas:

message User {
    string user_id = 1 [(classification) = "internal"];
    string email = 2 [(classification) = "confidential"];
    string cpf = 3 [(classification) = "restricted"];
}

4.2 Validação em pipelines CI/CD

Crie gatilhos que bloqueiem deploys se dados sensíveis não forem classificados:

# .github/workflows/classification-check.yml
name: Classification Check
on: [pull_request]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Scan for unclassified sensitive data
        run: |
          python scripts/scan_classification.py
          if [ $? -ne 0 ]; then
            echo "ERROR: Dados sensíveis sem classificação encontrados"
            exit 1
          fi

4.3 Exemplo prático: função de classificação

def classify_data(value: str, context: dict) -> str:
    """
    Classifica um dado com base em padrões e contexto.
    Retorna: 'public', 'internal', 'confidential', 'restricted'
    """
    # Padrões de dados sensíveis
    patterns = {
        'cpf': r'^\d{3}\.\d{3}\.\d{3}-\d{2}$',
        'email': r'^[\w\.-]+@[\w\.-]+\.\w+$',
        'credit_card': r'^\d{4}-\d{4}-\d{4}-\d{4}$'
    }

    for tipo, padrao in patterns.items():
        if re.match(padrao, value):
            if tipo == 'credit_card':
                return 'restricted'
            return 'confidential'

    # Se tem contexto de produção, assume interno
    if context.get('environment') == 'production':
        return 'internal'

    return 'public'

5. Monitoramento e Auditoria Contínua

5.1 Logs de acesso por classificação

Registre quem acessou o quê, mas nunca o conteúdo sensível:

{
    "timestamp": "2025-03-15T10:30:00Z",
    "user": "dev-joao",
    "action": "read",
    "resource": "usuarios.cpf",
    "classification": "confidential",
    "access_granted": true,
    "reason": "debugging_production_issue"
}

5.2 Alertas automáticos para anomalias

Configure regras como: "se um desenvolvedor acessar dados restritos em produção sem ticket de incidente, dispare alerta no Slack e bloqueie a sessão".

5.3 Revisão periódica de classificação

Dados mudam de sensibilidade. Um e-mail corporativo pode ser "interno" hoje, mas se contiver senhas, vira "confidencial". Crie um processo trimestral de revisão com stakeholders de compliance e segurança.

6. Integração com Temas Vizinhos da Série

6.1 Relação com Privacy by Design

Classificação é o primeiro passo para minimização de dados. Se você sabe que um campo é "confidencial", pode questionar: "precisamos mesmo armazenar isso?" — reduzindo superfície de ataque.

6.2 Conexão com Right to be Forgotten

Para excluir dados de um usuário sob LGPD/GDPR, você precisa localizá-los. Classificação permite encontrar rapidamente onde cada dado sensível reside, em vez de varrer todo o sistema.

6.3 Alinhamento com Audit Trails Imutáveis

Logs de classificação e acesso devem ser imutáveis (append-only). Use blockchain ou bancos imutáveis como Amazon QLDB para garantir que registros de auditoria não sejam adulterados.

7. Checklist para Devs e Próximos Passos

7.1 Checklist de implementação

  • [ ] Mapear todos os fluxos de dados (entrada, trânsito, armazenamento, saída)
  • [ ] Definir níveis de classificação (público, interno, confidencial, restrito)
  • [ ] Adicionar tags de classificação em schemas de banco e APIs
  • [ ] Configurar criptografia AES-256 para dados confidenciais
  • [ ] Implementar mascaramento em logs e ambientes não produtivos
  • [ ] Criar políticas RBAC/ABAC baseadas em classificação
  • [ ] Adicionar validação de classificação no CI/CD
  • [ ] Configurar alertas para acesso anômalo a dados restritos

7.2 Erros comuns e como evitá-los

  • Superclassificação: classificar tudo como "restrito" torna o sistema caro e lento. Seja específico.
  • Subclassificação: ignorar dados sensíveis em backups, caches ou arquivos de configuração. Varra tudo.
  • Ignorar dados em cache: Redis, Memcached e CDNs também precisam de classificação e proteção.

7.3 Recursos e ferramentas recomendadas

  • Apache Atlas: governança de dados open-source com classificação automática
  • Open Policy Agent (OPA): engine de políticas para controle de acesso
  • Amazon Macie: descoberta automatizada de dados sensíveis em S3
  • Google Cloud DLP: API de classificação e mascaramento
  • Vault (HashiCorp): gerenciamento de segredos e chaves de criptografia

Referências