Capítulo 14 — Fundamentos de privacidade | Graduação Segurança de infraestrutura crítica e setores

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 14 publicada. Mapa, exemplo, EX027.

flowchart TD
  N0["14.1 Segurança não é privacidade"]
  N1["14.2 Princípios"]
  N2["14.3 Dados pessoais em lugares inesperados"]
  N3["14.4 Privacidade nas operações de segurança"]
  N4["14.6 Atividade prática"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX027"]

Desenho lógico

flowchart LR
  N0["14.1 Segurança não é privacidade"]
  N1["14.2 Princípios"]
  N2["14.3 Dados pessoais em lugares inesperados"]
  N3["14.4 Privacidade nas operações de segurança"]
  N4["14.6 Atividade prática"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX027"]

[14.1 Segurança não é privacidade]
    |
    v
[14.2 Princípios]
    |
    v
[14.3 Dados pessoais em lugares inesperados]
    |
    v
[14.4 Privacidade nas operações de segurança]
    |
    v
[14.6 Atividade prática]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX027]

Objetivos de aprendizagem e conexão

Depois deste capítulo, você consegue (1) explicar a diferença entre segurança e privacidade; (2) aplicar princípios de proteção de dados como licitude, limitação da finalidade, minimização e limitação da conservação; (3) identificar dados pessoais nos sistemas dos serviços críticos, inclusive dados que se tornam pessoais quando combinados; e (4) recomendar projetos que protegem a privacidade para o monitoramento e os dados de incidentes. O capítulo se apoia no Capítulo 9 (dados) e no Capítulo 10 (ética) e prepara o Capítulo 29 (operações) e os requisitos éticos do trabalho de conclusão.

14.1 Segurança não é privacidade

A segurança protege os sistemas e as informações contra acesso, alteração e perda não autorizados. A privacidade trata de saber se o tratamento de informações sobre pessoas — mesmo um tratamento autorizado — é apropriado, proporcional e justo. Um banco de dados hospitalar perfeitamente seguro ainda pode violar a privacidade se for usado para uma finalidade sobre a qual os pacientes nunca foram informados. O NIST Privacy Framework trata o risco de privacidade como algo que surge do próprio tratamento de dados, sobreposto ao risco de cibersegurança, mas distinto dele.

A detecção de clonagem da CT é o exemplo: guardar com segurança dois anos de validações ainda seria um problema de privacidade.

14.2 Princípios

O Regulamento Geral sobre a Proteção de Dados da UE estabelece princípios amplamente espelhados em outros lugares: licitude, lealdade e transparência; limitação da finalidade; minimização dos dados; exatidão; limitação da conservação; integridade e confidencialidade; e responsabilidade (Regulation (EU) 2016/679, Article 5). Os dados de saúde são uma categoria especial, que exige condições adicionais. Você não precisa se tornar advogado, mas precisa reconhecer quando uma questão de projeto também é uma questão de proteção de dados e envolver o encarregado de proteção de dados da organização — e nunca deve apresentar o resumo deste livro como aconselhamento jurídico para um caso específico.

14.3 Dados pessoais em lugares inesperados

Os serviços críticos guardam dados pessoais óbvios (prontuários, contas bancárias, chamadas de emergência) e dados menos óbvios. As leituras de medidores inteligentes em intervalos curtos podem revelar quando uma família está em casa. Os dados de bilhetagem de um cartão de transporte traçam os deslocamentos de uma pessoa. Os logs de segurança registram quem fez login, de onde e quando — dados pessoais sobre a equipe. A combinação importa: nem um código postal nem uma data de nascimento sozinhos costumam identificar alguém, mas juntos e com o sexo muitas vezes identificam. A pseudonimização (substituir nomes por códigos) reduz o risco, mas não é anonimização se a chave existir ou se a reidentificação for possível.

14.4 Privacidade nas operações de segurança

O monitoramento de segurança coleta dados sobre pessoas por concepção. Uma prática que protege a privacidade: coletar o que a finalidade de detecção exige, e não tudo o que está disponível; restringir o acesso aos logs brutos; definir prazos de retenção; pseudonimizar onde a análise não precisa de nomes; documentar a finalidade e a base legal; e, num incidente, compartilhar indicadores (endereços, hashes de arquivos) em vez de dados pessoais sempre que possível. Durante uma violação que envolva dados pessoais, podem se aplicar deveres de notificação em prazos curtos, então os planos de incidente incluem o encarregado de proteção de dados desde o início.

O projeto revisado da CT aplica quatro dessas práticas: 30 dias de detalhe, pseudônimos com chave, dois analistas nomeados e uma finalidade declarada.

14.5 Exemplo resolvido: análise de bilhetagem da CT (sintético)

Este caso é sintético. A equipe de segurança da Calder Transit quer detectar cartões de transporte clonados procurando o mesmo cartão usado em duas estações distantes demais num intervalo curto demais. O projeto proposto copia toda validação de cartão (ID do cartão, estação, hora) por dois anos para a plataforma de análise de segurança. Uma revisão de privacidade pergunta: dois anos são necessários? (A detecção de clonagem precisa de minutos a dias; reter o detalhe completo por 30 dias e depois agregar.) O ID do cartão é necessário em claro? (Um pseudônimo com chave basta para o casamento; só os casos confirmados são reidentificados, pela equipe de fraude.) Quem pode consultá-lo? (Dois analistas nomeados, com registro.) O histórico de viagens dos passageiros está sendo criado como efeito colateral? (Sim — e é por isso que o projeto limita a retenção e o acesso.) O projeto revisado atende à finalidade de detecção com uma fração do risco de privacidade.

14.6 Atividade prática

Escolha um serviço que você usa (um cartão de transporte, um medidor inteligente, um aplicativo de hospital). A partir do aviso de privacidade público, liste os dados pessoais coletados, as finalidades declaradas e a retenção. Identifique um item de dado cuja finalidade não esteja clara e redija uma pergunta que você poderia enviar ao fornecedor do serviço.

Observe se o aviso declara a retenção em dias ou anos, ou apenas "pelo tempo necessário"; esta última vale uma pergunta. Observe se o monitoramento de segurança aparece sequer como finalidade. Redija a sua pergunta de forma educada e específica, por exemplo perguntando por quanto tempo os dados por viagem são mantidos antes da agregação e quem pode acessá-los.

14.7 Erros comuns e limites

"Somos seguros, portanto estamos em conformidade."
Coletar tudo "caso seja útil".
Chamar dados pseudonimizados de anônimos.
Esquecer os dados da equipe nos logs.
Dar conclusões jurídicas sem os assessores jurídicos e de proteção de dados da organização.

Cada um aparece nos exemplos deste capítulo. A cópia original das validações por dois anos da CT era segura e mesmo assim desproporcional. "Caso seja útil" é como o ID completo do cartão foi parar na plataforma de análise. Os pseudônimos com chave são reversíveis pela equipe de fraude, então não são anônimos. A proposta de monitoramento de acessos do CVH no EX027 registra os nomes da equipe, que são dados pessoais da equipe. E nenhum desses projetos deveria ser chamado de lícito sem o encarregado de proteção de dados.

Exercícios — capítulo 14

EX027 — Minimize um log. Objetivo: aplicar a minimização ao monitoramento de segurança. Entradas: uma proposta do CVH de registrar todo acesso da equipe a prontuários com o nome completo do paciente, o diagnóstico, o nome do profissional, a estação de trabalho e a hora, retidos indefinidamente, para detectar acessos inadequados. Etapas: proponha um projeto minimizado que atenda à mesma finalidade. Evidência esperada: lista de campos, retenção, acesso e uma frase sobre a finalidade. Rubrica: 3 = identificador do registro no lugar do diagnóstico, retenção definida, acesso restrito, finalidade declarada, equipe informada; 2 = parcial; 1 = "registrar menos" sem projeto; 0 = nada.

EX028 — Risco de combinação. Objetivo: reconhecer a reidentificação. Entradas: a CW publica o consumo horário "anonimizado" por medidor, com código postal e tipo de imóvel. Etapas: explique dois riscos de reidentificação e duas mitigações. Evidência esperada: explicação. Rubrica: 3 = códigos postais pequenos com tipos de imóvel únicos identificam domicílios, a ocupação é inferível pelos padrões horários; mitigações: limiares de agregação, tempo ou localização mais grosseiros, acordos de acesso; 2 = um de cada; 1 = vago; 0 = nada.

Síntese do capítulo

A privacidade pergunta se o tratamento de dados sobre pessoas é apropriado, e não só se ele é seguro. Aplique a limitação da finalidade, a minimização e a limitação da conservação — especialmente ao próprio monitoramento de segurança —, reconheça que as combinações reidentificam e envolva especialistas em proteção de dados, em vez de oferecer conclusões jurídicas.