Privacy by Design

Privacy by Design (GDPR)

1) Sobre o que é e porquê

Privaciy by Design (PbD) é o princípio de que a privacidade é inserida no produto desde o início: exigências empresariais, arquitetura, código, processos e operação. Em termos GDPR, isso se manifesta em «privacidade by design e by default» (minimização de taxas, configurações padrão - o mais privado, transparência e responsabilização).

• Minimizar a coleta e o tratamento de dados pessoais (PDN).
• Assegurar legitimidade, transparência, correção, limitação de metas e prazos.
• Reduzir os riscos (técnicos e legais), simplificar a auditoria e provar conformidade.

2) Papéis, fundamentos legais e princípios do GDPR

2. 1 Papéis

Controlador (Controlador): identifica os alvos/ferramentas de processamento.
Processador (Processor): processa PDN em nome do controlador do contrato DPA.
O sujeito de dados (Data Subject) é o físico a que pertencem os PDN.
DPO (Oficial de Proteção de Dados): por exigência, supervisão e aconselhamento independentes.

2. 2 Fundamentos legais (escolha e documentação)

Consentimento, contrato, interesse legítimo, dever legal, interesse vital, tarefa pública. Cada um tem o objetivo, os dados, a retenção, a possibilidade de revogação (para consentimento).

2. 3 Princípios de processamento (artigo 5)

Legitimidade, justiça, transparência

Limite de destino

Minimizar dados

Precisão

Restrição de armazenamento

Integridade e privacidade

Responsabilização (accountability) - habilidade para provar conformidade.

3) Processo de PbD no SDLC (reference framework)

1. Iniciação: formulação de objetivos de processamento e base legal, atribuição de owner's dados e DPO Point.
2. Mapeamento de dados (Data Maping): as fontes → campos → o modelo de confiança → para onde flutuam → quem lê → armazena → data limite.
3. Avaliação de risco/DPIA: Modelo LINDDUN de ameaças de privacidade, avaliação de impacto, medidas de redução.
4. Soluções arquitetônicas: escolha de esquemas de minimização, pseudonimização, criptografia, separação.
5. Requisitos de OX/concordâncias/notificações: texto compreensível, grande console, configuração padrão.
6. Implementação: default privado, telemetria segura, loging sem segredos/PII.
7. Verificação: testes de privacidade, análise estática, testes privados de unit, protocolos DPIA.
8. Operação: processos DSAR, reticências e remoções, monitoramento de incidentes, ciúmes de fornecedores.
9. Revisão regular: re-DPIA para alterações de metas/tecnologia.

4) Máquinas de engenharia PbD

4. 1 Minimização e descomposição

Recolher apenas os campos necessários; aplicar progressive profiling.
Divida ID e conteúdo: mantenha a chave de comunicação separadamente (tocen/reference).

4. 2 Apelidação e anonimato

Pseudônimo: guarde a identificação real separadamente; a camada de trabalho vê o token.
Anonimato: use k-anonimato, l-diversity, t-closeness; para os analistas, privacidade diferencial.

4. 3 Controle de acesso e divisão de papéis

PoLP, ABAC/RBAC, segregação of duties, caminhos separados para almirantes e analistas.
Aqueles. medidas: mTLS, SSO/OIDC, tokens scoped, aulas temporárias para acesso a PDN.

4. 4 Criptografia e isolamento

In Transit: TLS 1. 3/mTLS; At Rest: AEAD/Envelope + KMS/HSM.
Chaves individuais por locador/dataset; «Direito ao esquecimento».

4. 5 Retenção e remoção

Políticas explícitas TTL por campo/alvo; auto-purge em pipas; remoção «em duas fases» (lógico → físico).
Para bacapes, chaves separadas e janelas curtas de armazenamento pessoal.

4. 6 Telemetria privada e logagem

Padrão: sem PII; usar tokens/hachagem com sal.
Camuflar/tornear campos sensíveis no projetor.

4. 7 X privacidade e consentimento

Grande consent por categorias (analista, marketing, personalização).
«Desfalques privados», tudo não é crítico - desligado até concordar.
A opção Revogar consentimento é clara e as notificações se forem utilizadas novamente.

5) DPIA e LINDDUN (curto)

DPIA (avaliação do impacto na proteção de dados): necessário para alto risco (monitoramento em larga escala, avaliação, nova tecnologia). Consiste na descrição de processamento, necessidade/proporcionalidade, avaliação de risco, medidas de redução.
LINDDUN угрозы: Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance. Para cada ameaça, contramedidas (minimização, pseudônimo, DP, transparência, gerenciamento de concordâncias, auditoria).

6) Transferências

Descobrir as localizações de armazenamento/acesso dos fornecedores.
Usar o SCC (cláusulas de contrato padrão) e realizar o Transfer Impacto Assessment.
Criptografia end-to-end, criptografia de clientes para dados particularmente sensíveis, restrição de acesso remoto.

7) Fornecedores e processadores (Vendor Management)

DPA/processadores aninhados, medidas técnicas e organizacionais, subprocessadores, sob controle.
Reviravoltas e auditorias regulares; o direito de inspecção; plano de saída/migração (data export).

8) Direitos das entidades de dados (DSAR)

Acesso, correção, remoção, limitação, portabilidade, objeção, não ser objeto AADM (perfilação/automação).
SLA e automação: rastreamento de solicitações, prova de identificação, registro de respostas.
Ganchos técnicos no produto: pesquisa rápida e exportação por ID; remoção em cascata por retoques.

9) Soluções automáticas e perfilação (artigo 22)

Se as decisões de «impacto significativo» forem tomadas por uma máquina - garantir o direito à intervenção humana, a explicabilidade, a transparência dos sinais.
Caminho-e-versionização de modelos; O mecanismo do recurso.

10) Segurança do processamento (artigo 32) e incidentes (artigo 33/34)

Medidas orientadas ao risco: criptografia, integridade, sustentabilidade, planos de recuperação (RTO/RPO).
Incidentes de DPN: processo de detecção → triagem → avaliação de risco → notificação do regulador ≤ 72 horas (onde necessário) e dos sujeitos (caso de alto risco).
Um playbook separado, um contato DPO/advogados, modelos de notificação.

11) Privacidade e ML/analista

Dados Governance conjuntos: data-régua, licenças/bases, consentimento.
Técnicas: privacidade diferencial, federated learning, secure aggregation, minimização de fichas.
Proteção contra ataques: membership/modelo inversion - Avaliações regulares de vazamentos, configuração, ruído/clip.
Os dados sintéticos são apenas para verificar a falta de recuperação do indivíduo.

12) Circuitos arquitetônicos (pattern)

12. 1 Arquitetura de identificadores de dois contornos

Contorno A (PDS - Personal Data Store): dados de identificação real (RED), acesso estritamente limitado, chaves/criptografia/auditoria.
Contorno B (Operational): Dados de negócios com tokens; ligações através de um corretor de tokens com limites e auditoria.

12. 2 Pneus de concordância (Consent Service)

Serviço centralizado, armazenando versões de consoantes e histórico.
SDK: 'can _ use (category, purpose)' - decide no voo; tudo é logado.

12. 3 Políticas de Reticência como código

Configuração YAML: a entidade do campo → → TTL → a ação ao término (anonimato/remoção/descarte).
O programador executa job's e os relatórios estão disponíveis no DPO.

13) Mini-receitas

def collect(field, purpose):
if not is_required(field, purpose):
return None # do not collect v = read_input (field)
return truncate(v, policy. max_length(field))

yaml dataset: users fields:
email: { ttl: P18M, on_expire: pseudonymize }
phone: { ttl: P12M, on_expire: delete }
session_logs: { ttl: P3M, on_expire: aggregate }
consent: { ttl: P7Y, on_expire: archive }

analytics:
default: deny legal_basis: consent scope: anonymous_metrics marketing:
default: deny legal_basis: consent scope: email,push

GET /privacy/export? subject_id=... -> zip:
- profile. json (metadata, legal basis)
- activity. ndjson (events, aggregates)
- consents. json (consent history)
- processors. json (list of processors and transfers)

14) Documentação e responsabilização

ROPA (Records of Processing Activities) - Registro de operações: alvo, base legal, categorias de dados/sujeitos, transferências, prazo de armazenamento, medidas.
Políticas: privacidade, cookies, notificações de informação no produto (em linguagem compreensível).
Treinamento de pessoal e ciúmes anuais.

15) Erros frequentes

Recolher «por precaução» e guardar «para sempre».
O consentimento é o único fundamento, embora seja adequado um contrato/interesse legítimo.
Bookies «vazios» sem botões reais.
Falta mapeamento de dados e falta de preparação para DSAR.
Logs com PII, bacapes desprotegidos, mistura de RID e dados operacionais.
Não há controlo de fornecedores ou transferências.

16) Folhas de cheque

• O objetivo do processamento e a base legal foram definidos; O ROPA foi atualizado.
• Mapeamento de dados e DPIA (se necessário).
• A minimização, o pseudônimo, a criptografia (no caminho/em paz) foram implementados.
• Consentimentos - granulares, com OX compreensível; Os default são privados.
• As políticas de retenção foram configuradas como código; a remoção/anonimato foi verificada.
• Logi/telemetria - sem PII; O disfarce está ativado.
• Os ganchos DSAR estão preparados e exportados.
• Treinamento do comando e aprovação do DPO.

• Revisão trimestral de retenções e fundamentos legais.
• Auditoria periódica de processadores/subprocessadores.
• Monitoramento de incidentes e prontidão para notificação ≤ 72 h.
• Revisão do DPIA em mudanças de processos/tecnologias.
• Armazenamento de artefatos de conformidade (DPIA, ROPA, relatórios de testes).

17) FAQ

Podemos «fugir» completamente das concordâncias?
Oh: Às vezes sim (contrato/obrigação legal/interesse legítimo), mas apenas se for necessário e com uma avaliação do equilíbrio de interesses. Marketing e analista não-rítico - na maioria das vezes exigem consentimento.

O pseudônimo é suficiente?
Não, ainda são dados pessoais. Para sair da esfera GDPR, você precisa de um anonimato confiável (verificável para a impossibilidade de uma nova identificação).

Em: Como estar com ML e personalização?
A: Minimize os fichos, use as abordagens DP/federated, logue as soluções, garanta o direito de interferência humana e não perfilar.

O que fazer num conflito de negócios e privacidade?
Ah: Reinventar a coleta (progressive profiling), mudar para agregados/sintéticos, reavaliar a base legal e oferecer uma opção sem tracking.

• «Gestão de segredos»
• Criptografia At Rest
• Criptografia In Transit
• «Auditar e Registos Imutáveis»
• «Assinar e verificar solicitações»
• Gerenciamento de chaves e rotação