Capítulo 19 — Identidade e criptografia

Mapa da aula

Aula 19 publicada. Mapa, exemplo, EX055.

flowchart TD
  N0["19.1 Identificadores e vinculação"]
  N1["19.2 Hash com chave"]
  N2["19.3 Escolhas de criptografia"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX055"]

Desenho lógico

flowchart LR
  N0["19.1 Identificadores e vinculação"]
  N1["19.2 Hash com chave"]
  N2["19.3 Escolhas de criptografia"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX055"]

[19.1 Identificadores e vinculação]
    |
    v
[19.2 Hash com chave]
    |
    v
[19.3 Escolhas de criptografia]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX055]

Objetivos de aprendizagem

Você vai (1) escolher identificadores que limitem a vinculação; (2) aplicar corretamente a criptografia e o hash com chave; (3) entender os limites da pseudonimização.

19.1 Identificadores e vinculação

Zara percebe que a Pellmore usa o mesmo número de paciente em todos os sistemas, incluindo a área de análise e o laboratório parceiro. Um identificador único permite a qualquer pessoa com acesso a dois conjuntos de dados juntá-los. Ela propõe pseudônimos por domínio: cada destinatário externo recebe um identificador diferente, derivado do interno com uma chave separada. Vincular os conjuntos passa então a exigir as chaves, que ficam com a Pellmore. Essa abordagem reduz a vinculação entre destinatários e se ajusta ao conceito de pseudonimização do GDPR e da LGPD (art. 13, § 4º), em que a informação adicional é mantida separadamente. Cada destinatário recebe um pseudônimo diferente.

19.2 Hash com chave

Um hash simples do número do paciente não é um pseudônimo, porque qualquer pessoa pode calcular o hash de todos os números possíveis e comparar. Zara usa um hash com chave, com uma chave secreta guardada no módulo de hardware da Pellmore. Ela explica que, sem a chave, reverter o pseudônimo é inviável, mas, com ela, refazer a vinculação é trivial. Por isso a chave precisa ser protegida como os próprios dados. Ela documenta a rotação de chaves: quando uma chave muda, todos os pseudônimos daquele destinatário mudam, o que pode ser usado de propósito para romper a vinculação de longo prazo depois que um projeto termina.

19.3 Escolhas de criptografia

Zara revisa a criptografia em repouso. A cifragem do banco de dados protege contra discos roubados, mas não contra um atacante que usa a aplicação. A cifragem por campo dos campos especialmente sensíveis, como as anotações de saúde mental, acrescenta proteção, porque só os serviços que têm a chave do campo conseguem decifrá-lo. Ela pondera a complexidade adicional e decide aplicar a cifragem por campo apenas a um pequeno conjunto de campos definidos pelos médicos. A decisão ilustra a proporcionalidade do artigo 32, em que as medidas seguem o risco, em vez de serem aplicadas em toda parte. Os campos de baixo risco ficam sem cifragem para permitir buscas.

19.4 Limites da pseudonimização

Zara se lembra de que os dados pseudonimizados continuam sendo dados pessoais pelo GDPR. Um registro pseudônimo com data de nascimento e código postal pode ser reidentificado pelos atributos, como mostrou Sweeney (2002), por melhor que o identificador esteja protegido. Garfinkel (NISTIR 8053, 2015) faz a mesma observação: remover os identificadores diretos é só um primeiro passo. A pseudonimização reduz o risco e é incentivada pelo GDPR, mas não torna os dados anônimos, e os contratos da Pellmore precisam refletir isso. Quem tiver a tabela de chaves pode reverter os pseudônimos, então a tabela fica guardada longe dos dados.

Exemplo resolvido

Zara troca um número de paciente universal por pseudônimos com chave específicos de cada destinatário, protege as chaves em hardware, aplica cifragem por campo aos campos definidos pelos médicos e documenta por que os dados pseudonimizados continuam sendo dados pessoais.

Caso sintético. Os identificadores e as chaves são sintéticos; Sweeney (2002), o NISTIR 8053 e o art. 13 da LGPD são reais.

Erros e limites

A rotação de chaves rompe análises longitudinais legítimas; planeje-a com os usuários.

Exercícios

• EX055 — Fraqueza do hash simples. Por que um hash simples do número do paciente não é um pseudônimo?
  Mostrar critérios de avaliação

  Rubrica: 3 = qualquer pessoa pode calcular o hash de todos os números possíveis e comparar;; 2 = menciona reversão;; 1 = diz que é seguro;; 0 = nenhuma.
• EX056 — Pseudônimos por destinatário. O que os pseudônimos específicos por destinatário impedem?
  Mostrar critérios de avaliação

  Rubrica: 3 = juntar conjuntos de dados de destinatários diferentes sem as chaves da Pellmore;; 2 = menciona vinculação;; 1 = vago;; 0 = nenhuma.
• EX057 — Ainda pessoais. Por que os registros pseudonimizados continuam sendo dados pessoais?
  Mostrar critérios de avaliação

  Rubrica: 3 = atributos e chaves permitem a reidentificação;; 2 = menciona chaves;; 1 = diz que são anônimos;; 0 = nenhuma.

Síntese

O capítulo 19 conclui os fundamentos de segurança. O capítulo 20 define o contexto de engenharia da proteção de dados.