Segurança de Dados

Segurança de dados (data security) é a disciplina de proteger dados contra acesso não autorizado, modificação, divulgação ou destruição ao longo de todo o seu ciclo de vida — da coleta e ingestão até o treinamento (training), a avaliação e a inferência em produção (production inference). Em sistemas de IA (AI systems), segurança de dados não é apenas uma preocupação de TI: dados de treinamento (training data) e características (features) frequentemente codificam lógica de negócio sensível, dados pessoais e sinais proprietários que podem ser exfiltrados (exfiltrated) direta ou indiretamente por meio de modelos.

Este artigo se concentra em quatro temas centrais: criptografia (encryption), retenção (retention), logs de acesso (access logs)/auditoria (auditing) e segurança de pipeline ponta a ponta (end-to-end pipeline security). Ele complementa (mas não substitui) tópicos como Privacidade, Governança de Dados e Pipelines de Dados (ETL/ELT para aprendizado de máquina (machine learning)).

Modelo de ameaças (threat model) e fundamentos

Antes de escolher controles, defina contra o que você está se defendendo.

Atores de ameaça comuns e modos de falha

  • Atacantes externos: exploram serviços expostos, credenciais roubadas, vulnerabilidades na cadeia de suprimentos.
  • Ameaças internas: acesso amplo demais, dados copiados para armazenamento pessoal, navegação “curiosa”.
  • Exposição acidental: buckets mal configurados, painéis públicos, logs de depuração contendo segredos.
  • Comprometimento do pipeline: código injetado em jobs de ETL, dependências envenenadas, artefatos adulterados.
  • Exfiltração de dados via comportamento do modelo: memorização ou vazamento (intimamente relacionado a Privacidade).

Objetivos de segurança (CIA + além)

  • Confidencialidade: apenas partes autorizadas podem ler os dados.
  • Integridade: os dados não podem ser alterados sem detecção.
  • Disponibilidade: sistemas de dados permanecem utilizáveis (incluindo backups e recuperação de desastres). Objetivos adicionais relevantes para IA:
  • Proveniência/linhagem (provenance/lineage): saber de onde os dados vieram e como foram transformados (relacionado a Versionamento de Dados).
  • Não repúdio e responsabilização: ações são atribuíveis e auditáveis via logs.

Classifique os dados desde cedo

Trate “dados” como múltiplas classes com controles diferentes:

  • Entradas brutas (podem conter PII, segredos, texto protegido por direitos autorais etc.)
  • Rótulos e metadados de anotação (frequentemente sensíveis para PI e dados de usuários)
  • Características em repositórios de características (feature stores) (podem ser altamente identificáveis mesmo se “não forem PII”)
  • Conjuntos de treinamento/validação/teste
  • Artefatos derivados (vetores de embedding (embeddings), índices (indices), snapshots de modelo (model snapshots), trilhas de avaliação)
  • Logs (frequentemente contêm identificadores e trechos de payload)

Use um esquema de classificação de Governança de Dados e aplique-o consistentemente em armazenamento, políticas de acesso, retenção e logging.

Criptografia: em repouso, em trânsito e em uso

A criptografia reduz o impacto de roubo de armazenamento, vazamento de snapshots ou interceptação de rede. Mas a criptografia só é tão forte quanto o gerenciamento de chaves (key management) e o controle de acesso (access control).

Criptografia em repouso (at rest)

A maioria das plataformas modernas de dados oferece suporte a criptografia em repouso:

  • Armazenamento de objetos (por exemplo, S3/GCS/Azure Blob)
  • Data warehouses e lakehouses
  • Bancos de dados gerenciados
  • Discos anexados ao compute (volumes de VM, volumes persistentes do Kubernetes)
  • Backups e snapshots

Criptografia de envelope (envelope encryption) (padrão recomendado)

Na criptografia de envelope:

  1. Os dados são criptografados com uma chave de dados (data key) (simétrica).
  2. A chave de dados é criptografada com uma chave de criptografia de chaves (key encryption key, KEK) armazenada em um KMS (Key Management Service)/HSM (Hardware Security Module).
  3. Rotação e políticas de acesso são aplicadas à KEK sem recriptografar todos os dados.

É assim que funcionam a maioria dos mecanismos em nuvem do tipo “SSE-KMS”.

Orientação prática

  • Prefira chaves gerenciadas por KMS para conjuntos de dados sensíveis; use chaves gerenciadas pelo provedor apenas para dados de baixo risco.
  • Exija criptografia via política (negar gravações de objetos sem criptografia).
  • Separe chaves por ambiente (dev/staging/prod) e por domínio de dados (PII vs não PII).
  • Faça rotação de chaves em um cronograma e também quando acionado por gatilhos de resposta a incidentes (incident response).

Criptografia em trânsito (in transit)

Criptografe dados em movimento entre componentes:

  • Cliente ↔ endpoint de ingestão
  • Jobs de ETL ↔ armazenamento de objetos/warehouse
  • Repositório de características ↔ jobs de treinamento
  • Treinamento ↔ rastreamento de experimentos/armazenamento de artefatos
  • Serviço de modelos (serving) ↔ repositório de características/armazenamento online

Use TLS (Transport Layer Security) em todos os lugares, inclusive no tráfego interno. “Rede interna” não é um limite de confiança em muitos ambientes de nuvem e Kubernetes.

Exemplo: exigir TLS para conexões de banco de dados Muitos drivers suportam sslmode=require (PostgreSQL) ou equivalente:

# Example environment variable for a Postgres client
export DATABASE_URL="postgresql://user:pass@host:5432/db?sslmode=require"

Considere também:

  • mTLS (mutual TLS) para autenticação serviço-a-serviço
  • Rede privada (VPC/VNet), endpoints privados e regras de firewall para reduzir exposição
  • Automação de rotação de certificados

Criptografia em uso (in use) (opcional, mas cada vez mais relevante)

Para cargas de trabalho de aprendizado de máquina de alta sensibilidade:

  • Computação confidencial (confidential computing) / enclaves seguros (secure enclaves) podem proteger dados enquanto estão sendo processados.
  • Ambientes de execução confiáveis (trusted execution environments, TEEs) ajudam a se defender contra certos tipos de ameaças no nível do host.

São recursos poderosos, mas adicionam complexidade operacional e podem restringir escolhas de hardware.

Gerenciamento de chaves e segredos

A criptografia é ineficaz se chaves e segredos forem mal gerenciados.

Práticas essenciais:

  • Armazene segredos em um gerenciador de segredos (secret manager) (não em código, notebooks ou logs de CI).
  • Aplique o princípio do menor privilégio (least privilege) às permissões de KMS (descriptografar apenas para workloads específicos).
  • Audite o uso do KMS (chamadas de descriptografia são eventos de alto sinal).
  • Evite credenciais de longa duração; prefira tokens de curta duração (OIDC (OpenID Connect), identidade de carga de trabalho (workload identity)).

Controle de acesso: menor privilégio para pessoas e serviços

O controle de acesso determina quem pode fazer o quê com os dados. Controles de criptografia geralmente são aplicados pelo mesmo sistema de identidade e acesso, então essas decisões estão fortemente acopladas.

Controle baseado em funções, baseado em atributos e acesso escopado

  • Controle de acesso baseado em funções (Role-Based Access Control, RBAC): funções como data-scientist, ml-engineer, annotator.
  • Controle de acesso baseado em atributos (Attribute-Based Access Control, ABAC): políticas baseadas em atributos (sensibilidade do conjunto de dados, ambiente, time).
  • Segurança em nível de linha/coluna (row/column-level security) em warehouses: apenas certas colunas (por exemplo, email) visíveis para certos papéis.

Exemplo: restrição em nível de coluna (conceitual) Você pode expor uma view com colunas mascaradas para acesso amplo, enquanto restringe tabelas brutas:

CREATE VIEW analytics.user_events_masked AS
SELECT
  user_id,
  event_time,
  event_type,
  sha256(email) AS email_hash
FROM raw.user_events;

GRANT SELECT ON analytics.user_events_masked TO ROLE analyst;
REVOKE SELECT ON raw.user_events FROM ROLE analyst;

Acesso humano vs acesso de workload

Separe:

  • Acesso humano interativo (notebooks, ferramentas de BI): guardrails mais fortes, MFA, timeouts de sessão.
  • Acesso de serviço/workload (jobs de ETL, execuções de treinamento): identidades com escopo restrito e permissões mínimas.

Evite “contas de serviço (service accounts) compartilhadas”. Prefira identidades por serviço e separação por ambiente.

Compartilhamento de dados e acesso temporário

Fluxos de trabalho comuns de IA exigem compartilhar recortes de dados:

  • rotulagem por fornecedor
  • conjuntos de avaliação de red team
  • depuração de regressões de modelo

Use:

  • concessões de acesso com prazo
  • URLs assinadas (signed URLs) com expiração curta
  • “exportações” de conjuntos de dados com retenção estrita e marcação d’água (watermarking)
  • dados sintéticos ou desidentificados quando possível (veja Dados Sintéticos e Privacidade)

Retenção e ciclo de vida: mantenha o que você precisa, apague o que você não precisa

Retenção é tanto um controle de segurança quanto um requisito de conformidade. O dado sensível mais seguro é o dado que você nunca armazena.

Por que retenção importa em sistemas de IA

Pipelines de IA criam muitas cópias:

  • dumps brutos → tabelas limpas → snapshots de características → shards de treinamento → batches em cache
  • trilhas de avaliação e prompts/respostas (para sistemas de LLM)
  • vetores de embedding e índices vetoriais (que podem codificar conteúdo sensível)

Sem disciplina de retenção, dados sensíveis persistem em “buckets paralelos”, pastas antigas de experimentos e backups de longa duração.

Defina políticas de retenção por classe de dados

Uma abordagem prática:

  • Dados brutos sensíveis: menor retenção viável, acesso estrito, auditoria forte.
  • Características derivadas: reter apenas enquanto forem necessárias para reprodutibilidade e monitoramento.
  • Conjuntos de dados de treinamento: manter snapshots versionados para reprodutibilidade, mas limitar quem pode acessá-los.
  • Logs: manter o suficiente para resposta a incidentes e conformidade, mas minimizar payloads.

Vincule a retenção a:

  • requisitos legais (GDPR, HIPAA, contratos)
  • necessidades do negócio (janelas de depuração, janelas de auditoria)
  • necessidades operacionais (rollbacks, investigações de Qualidade de Dados e Drift)

Exclusão: “apagar” é mais difícil do que parece

Considere todas as camadas de armazenamento:

  • armazenamento primário
  • caches
  • réplicas
  • backups e snapshots
  • dados copiados para workspaces de analistas
  • exportações para parceiros externos

Estratégias comuns:

  • Políticas de ciclo de vida (lifecycle policies) (expirar automaticamente objetos após N dias)
  • Crypto-shredding (destruir chaves de criptografia para tornar os dados ilegíveis)
  • Fluxos de trabalho de exclusão documentados e etapas de verificação

Exemplo prático: ciclo de vida em armazenamento de objetos Muitos armazenamentos de objetos suportam regras como “apagar após 30 dias” para um prefixo como tmp/training_exports/.

Garanta também que a retenção se aplique a:

  • tabelas offline do repositório de características
  • artefatos de rastreamento de experimentos
  • bancos vetoriais e caches de embeddings
  • exportações de anotação

Logs de acesso e auditoria: detectar, investigar e comprovar

Segurança não é apenas prevenção; é também detecção e resposta. Logs de acesso são a base para investigação de incidentes, auditorias de conformidade e detecção de anomalias.

O que registrar

No mínimo, registre:

  • Eventos de autenticação: logins, emissão de tokens, mudanças de MFA
  • Eventos de autorização: mudanças de permissões, edições de políticas, concessões de papéis
  • Eventos de acesso a dados:
    • leituras/gravações/exclusões de objetos
    • consultas ao banco de dados (ou metadados de consulta)
    • exportações/downloads
  • Eventos de chaves: chamadas de descriptografia/criptografia do KMS, mudanças de política de chaves
  • Execuções de pipeline: quem acionou execuções, qual versão do código, quais conjuntos de dados de entrada

Tornando logs confiáveis

Logs só são valiosos se forem:

  • centralizados (agregados em um único lugar)
  • imutáveis/evidentes contra adulteração (immutable/tamper-evident) (armazenamento WORM, sistemas append-only)
  • sincronizados no tempo (NTP, timestamps consistentes)
  • protegidos (logs podem conter identificadores sensíveis)

Um bom padrão é enviar logs para uma conta/projeto de segurança dedicado, com acesso de escrita restrito e acesso de leitura mais amplo para respondedores de segurança.

Logging vs privacidade

Logs podem virar um vazamento de dados. Evite:

  • registrar linhas brutas, prompts ou payloads completos, a menos que seja necessário
  • registrar segredos (chaves de API, cookies, headers de autorização)

Em vez disso:

  • registre metadados (ID do conjunto de dados, contagem de linhas, versão do schema)
  • faça hash ou tokenização de identificadores
  • faça redaction de campos sensíveis no logger

Exemplo: logging estruturado com redaction (pseudocódigo estilo Python)

import logging

def log_dataset_access(user, dataset_id, query, pii_fields_present):
    logging.info("dataset_access", extra={
        "user": user,
        "dataset_id": dataset_id,
        "query_fingerprint": hash(query),  # not the raw query
        "pii_fields_present": pii_fields_present,
    })

Usando logs para detecção

Depois que você tiver logs de alta qualidade, você pode detectar:

  • volume incomum de download
  • acesso a partir de novos locais
  • consultas que acessam colunas sensíveis inesperadamente
  • eventos repetidos de descriptografia no KMS por jobs atípicos
  • identidade de serviço usada fora de horários esperados

É aqui que ferramentas de SIEM (Security Information and Event Management) e detecção de anomalias se tornam práticas.

Protegendo pipelines de dados ponta a ponta (ETL → características → treinamento → serving)

Pipelines de dados de IA são sistemas multiestágio. A segurança deve ser consistente ao longo da cadeia; o elo mais fraco frequentemente vira o ponto de entrada.

Esta seção foca em proteções ponta a ponta; veja Pipelines de Dados (ETL/ELT para ML) para fundamentos de design de pipelines.

1) Segurança de ingestão

Riscos:

  • ingestão a partir de fontes não confiáveis (web, parceiros)
  • adulteração de dados em trânsito
  • ingestão acidental de segredos/PII além do escopo

Controles:

  • TLS + autenticação para endpoints de ingestão
  • validação de schema e restrições de entrada (“rejeitar campos desconhecidos”)
  • zona de aterrissagem em quarentena para drops brutos
  • varredura de malware para uploads de arquivos
  • metadados de proveniência (fonte, timestamp, checksum)

Se você fizer scraping de dados da web, alinhe-se com Dados da Web e Scraping e mantenha separação estrita entre conteúdo bruto coletado e corpora de treinamento curados.

2) Segurança de armazenamento e lake/warehouse

Riscos:

  • configuração incorreta de bucket/container público
  • permissões amplas de leitura (todo mundo consegue ler “raw/”)
  • acesso cruzado acidental entre ambientes (dev lendo prod)

Controles:

  • postura de rede “privado por padrão” (sem acesso público a menos que explicitamente necessário)
  • políticas de bucket/tabela que negam gravações sem criptografia
  • separação de ambientes no nível de conta/projeto quando possível
  • segurança em nível de linha/coluna para warehouses
  • varredura de prevenção contra perda de dados (Data Loss Prevention, DLP) para campos sensíveis quando apropriado

3) Segurança de transformação e computação de características

Riscos:

  • código de ETL exfiltra dados
  • dependências comprometidas (cadeia de suprimentos)
  • jobs de características gravam acidentalmente saídas intermediárias sensíveis em locais inseguros

Controles:

  • revisão de código + commits assinados para código de pipeline
  • fixação e varredura de dependências (SBOM (Software Bill of Materials), verificações de vulnerabilidades)
  • identidades de serviço com menor privilégio por job
  • gravar saídas apenas em prefixes/tabelas aprovados
  • segredos injetados em tempo de execução a partir do gerenciador de segredos, não em arquivos de ambiente em repositórios

Trate também a lógica de transformação como PI sensível; restrinja quem pode editar pipelines de produção.

4) Instantâneos de conjuntos de dados, versionamento e linhagem

Reprodutibilidade frequentemente exige congelar entradas de treinamento. Isso pode conflitar com minimização de retenção.

Abordagem prática:

  • versionar conjuntos de dados com snapshots imutáveis (veja Versionamento de Dados)
  • armazenar metadados de linhagem: fontes de entrada, transformações, versão do código, hash de schema (schema hash)
  • aplicar retenção a versões antigas ou a entradas brutas antigas enquanto mantém os snapshots mínimos necessários de treinamento

Documentação de conjuntos de dados (por exemplo, Documentação de Conjuntos de Dados (Fichas Técnicas (Datasheets))) ajuda a esclarecer o que está contido, quem pode acessar e por quanto tempo deve existir.

5) Segurança do ambiente de treinamento

Riscos:

  • jobs de treinamento rodam em clusters permissivos demais
  • acesso de rede de saída permite exfiltração
  • checkpoints e artefatos armazenados sem controles de acesso

Controles:

  • compute isolado (namespaces/projetos/contas separados)
  • egress restrito (allowlist de destinos necessários)
  • montar segredos apenas quando necessário; evitar embutir em imagens
  • criptografar artefatos (checkpoints, métricas, embeddings) e armazenar em repositórios com controle de acesso
  • garantir que o tráfego de treinamento distribuído seja criptografado (quando suportado)

6) Serving e acesso a características online

Sistemas de serving frequentemente se tornam alvos de alto valor porque ficam expostos à internet.

Controles:

  • autenticação/autorização estritas de API
  • limitação de taxa e detecção de abuso
  • proteger repositórios de características online (online feature stores) com isolamento de rede e identidades de serviço
  • evitar registrar conteúdo bruto do usuário; registrar metadados estruturados para depuração
  • proteger entradas/saídas do modelo em trânsito (TLS) e em repouso (logs criptografados)

Se seu sistema usa armazenamentos vetoriais (vector stores) para recuperação (retrieval), trate vetores de embedding e índices como dados derivados sensíveis; aplique os mesmos controles de acesso, criptografia e retenção.

Integridade: prevenindo e detectando adulteração

Confidencialidade não é suficiente; sistemas de IA também são vulneráveis à manipulação de dados (o que pode levar a falhas do modelo ou mudanças ocultas de comportamento).

Controles práticos de integridade

  • Somas de verificação/hashes (checksums/hashes) para arquivos e shards de conjuntos de dados na ingestão
  • Artefatos assinados (signed artifacts) para saídas de pipeline e artefatos de modelo
  • Imutabilidade (immutability) para conjuntos de dados canônicos (padrões append-only)
  • Revisão por duas pessoas (two-person review) para mudanças em conjuntos de dados sensíveis ou rótulos
  • Monitoramento de mudanças anômalas (relacionado a Qualidade de Dados e Drift)

Controles de integridade são especialmente importantes para proteger contra envenenamento de dados (data poisoning) e corrupção acidental.

Práticas operacionais e padrões

Política e processo

Tecnologia sozinha não resolve segurança de dados. Práticas operacionais importam:

  • fluxos de trabalho documentados de solicitação e aprovação de acesso
  • revisões periódicas de acesso (quem ainda precisa de acesso?)
  • runbooks de resposta a incidentes (o que fazer em caso de suspeita de vazamento)
  • treinamento de manuseio de dados para engenheiros e analistas

Padrões e conformidade (brevemente)

Dependendo do seu domínio, você pode se alinhar com:

  • ISO 27001, SOC 2, diretrizes do NIST para controles de segurança
  • GDPR/CCPA para direitos de dados pessoais
  • HIPAA para dados de saúde, PCI DSS para dados de pagamento

Trate conformidade como uma linha de base; riscos específicos de IA (proliferação de dados, artefatos derivados, vazamento por modelos) frequentemente exigem controles internos mais rigorosos do que o mínimo legal.

Checklist prático: segurança de dados ponta a ponta para aprendizado de máquina

  • Classifique dados e marque conjuntos de dados com sensibilidade e responsável.
  • Criptografe em repouso com chaves gerenciadas por KMS; imponha criptografia por política.
  • Criptografe em trânsito em todos os lugares; prefira rede privada e considere mTLS internamente.
  • Separe identidades para humanos vs workloads; aplique menor privilégio e credenciais de curta duração.
  • Fortaleça pipelines: revisão de código, fixação de dependências, gerenciamento de segredos, egress restrito.
  • Centralize logs de auditoria: acesso a dados, uso do KMS, mudanças de permissão; torne os logs evidentes contra adulteração.
  • Defina retenção por classe de dados; automatize exclusão por ciclo de vida; considere backups e caches.
  • Proteja artefatos derivados (características, vetores de embedding, checkpoints, índices vetoriais) como dados primários.
  • Verifique integridade com hashes/assinaturas e snapshots imutáveis de conjuntos de dados.
  • Monitore continuamente padrões de acesso e comportamento de pipelines; ensaie resposta a incidentes.

Segurança de dados é mais eficaz quando projetada como um sistema: criptografia, controle de acesso, logging e retenção se reforçam mutuamente. Em ambientes de IA/aprendizado de máquina — onde dados são copiados, transformados e incorporados em artefatos downstream — pensar ponta a ponta é a diferença entre “armazenamento criptografado” e pipelines verdadeiramente seguros.