Privacidade desde a concepção e políticas de retenção de dados

Privacy by Design (PbD) é uma estrutura desenvolvida por Ann Cavoukian na década de 1990 que trata a privacidade como um Requirement arquitetural fundamental, e não como algo pensado posteriormente. Em vez de adicionar controls de privacidade depois que um sistema é construído, a PbD os integra desde a primeira decisão de design. O Artigo 25 da GDPR codificou formalmente a PbD como um Requirement Legal para sistemas voltados à EU, exigindo proteção de Data desde a concepção e por padrão — o que significa que as configurações padrão devem ser sempre a opção mais protetiva à privacidade disponível.

Os sete princípios de Cavoukian são: Proativa, não reativa — antecipar e prevenir eventos de privacidade antes que ocorram. Privacidade como padrão — nenhuma ação do User é necessária para proteger a privacidade. Privacidade incorporada ao design — não adicionada como uma camada. Funcionalidade completa — a privacidade não exige abrir mão da Security nem da funcionalidade. Security de ponta a ponta — proteção durante todo o ciclo de vida, da coleta ao descarte. Visibilidade e transparência — operações abertas à verificação independente. Respeito à privacidade do User — controls centrados no User e padrões fortes.

Privacidade por padrão significa que as configurações que mais protegem a privacidade vêm ativas de fábrica — os User não devem precisar recusar a coleta de Data nem Restrict o compartilhamento; em vez disso, o compartilhamento deve exigir uma aceitação ativa. Exemplos práticos: o perfil em uma rede social deve ser privado por padrão, não público; uma ferramenta de análise deve coletar o mínimo de Data por padrão; um aplicativo não deve solicitar permissão de localização por padrão. Os princípios da PbD exigem que os engenheiros tornem automáticas as escolhas que protegem a privacidade, em vez de depender da conscientização do User.

Minimização de Data é um princípio da PbD e um Requirement Legal da GDPR: coletar somente os Data pessoais estritamente necessários para a finalidade especificada. Antes de desenvolver um recurso, os engenheiros devem perguntar: “Nós realmente precisamos deste campo?” Técnicas comuns de minimização incluem: coletar valores derivados em vez de Data brutos (faixa etária em vez da data de nascimento), usar Pseudonymization (substituir identificadores diretos por tokens) e implementar anonimização quando não for necessária uma análise em nível individual. Data que nunca são coletados não podem sofrer violações.

Pseudonymization substitui Data diretamente identificadores por um identificador artificial (token), mantendo a tabela de Mapping para que a reidentificação seja possível com a chave. A GDPR reconhece a Pseudonymization como uma técnica de redução de Risk, mas a GDPR NÃO isenta Data pseudonimizados da GDPR — eles continuam sendo Data pessoais. A anonimização remove de forma irreversível a possibilidade de identificar indivíduos. Data genuinamente anônimos estão fora do escopo da GDPR, mas a anonimização verdadeira é tecnicamente difícil — muitos conjuntos de Data considerados anônimos podem ser reidentificados usando Data auxiliares ou ataques por inferência.

Uma Avaliação de Impacto sobre a Privacidade (PIA), chamada de Avaliação de Impacto sobre a Proteção de Data (DPIA) pela GDPR, avalia os Risks de privacidade antes do lançamento de um novo sistema ou processo. A GDPR exige DPIAs quando o processamento provavelmente resultará em alto Risk — por exemplo, processamento em larga escala de Data sensíveis, criação sistemática de perfis ou uso de novas tecnologias. Uma DPIA documenta: a finalidade do processamento, a avaliação de necessidade, a identificação de Risk e as medidas de mitigação de Risk. Concluir uma DPIA antecipadamente evita um redesenho caro depois que os sistemas são construídos.

Uma política de retenção de Data especifica por quanto tempo cada categoria de Data é mantida antes de ser descartada com Security. As decisões de retenção equilibram duas pressões opostas: manter Data por tempo suficiente para cumprir Requirements legais, operacionais e de auditoria, sem mantê-los por tanto tempo a ponto de se tornarem um Risk desnecessário. O princípio de limitação de armazenamento da GDPR exige a exclusão dos Data quando eles não forem mais necessários para a finalidade original. Os cronogramas de retenção devem ser documentados e aplicados tecnicamente por meio de tarefas automatizadas de exclusão e configurações de expiração de arquivos de arquivo.

Os cronogramas de retenção devem ter um mecanismo de exceção para retenções Legal. Quando um litígio é previsto ou iniciado, as organizações têm o dever de preservar todos os Data potencialmente relevantes, independentemente dos cronogramas normais de retenção. Destruir Data sob uma retenção Legal pode constituir destruição de evidências e resultar em decisões judiciais desfavoráveis ou sanções. O software de retenção Legal coloca uma sinalização técnica de preservação nos Data afetados, impedindo a exclusão automatizada até que a retenção seja liberada pela equipe jurídica. As retenções Legal devem ser acompanhadas e documentadas durante toda a sua duração.

Quando os Data chegam ao fim do período de retenção, devem ser destruídos de uma forma que impossibilite a recuperação. Para Data digitais: apagamento criptográfico (destruir as chaves de Encrypt torna o texto cifrado inútil), desmagnetização (para mídias magnéticas), sobrescrita segura (NIST SP 800-88 Clear ou Purge) ou destruição Physical (fragmentação, incineração). As organizações devem emitir certificados de destruição — especialmente para a destruição de mídias por terceiros — como evidência em auditorias de conformidade. Para armazenamento em nuvem, o apagamento criptográfico normalmente é o único método viável.

As organizações que dependem do consentimento como base legal devem manter registros de consentimento que comprovem: quem consentiu, quando, com relação a qual tratamento específico e por qual mecanismo. Esses registros devem ser mantidos enquanto o tratamento continuar e por um período razoável depois disso, para a resolução de disputas. Plataformas de gestão de consentimento (CMPs) automatizam o consentimento para cookies, o registro de preferências e a retirada do consentimento. Uma trilha de auditoria das alterações de consentimento é essencial — se um usuário retirar o consentimento, mas seus dados continuarem sendo tratados, a organização ficará sujeita a uma responsabilidade significativa perante o GDPR.

Na prática, a privacidade desde a concepção significa que os arquitetos fazem perguntas sobre privacidade durante a etapa de design. Prefira a renderização no servidor aos sinalizadores de análise no cliente. Use tokenização em vez de armazenar números de cartão brutos. Aplique criptografia em nível de coluna nos bancos de dados para campos confidenciais. Projete camadas de acesso a dados que imponham a quantidade mínima de dados necessária para cada consulta. Armazene PII em um esquema de banco de dados separado e com mais restrições. Aplique privacidade diferencial às saídas de análise. Essas escolhas se acumulam e resultam em um sistema realmente difícil de explorar, até mesmo por pessoas de dentro da organização.

Teste sua compreensão dos conceitos do CompTIA Security+ (SY0-701) apresentados nesta lição.

Nesta lição, você aprendeu que a Privacidade desde a concepção incorpora a privacidade aos sistemas desde o início, com sete princípios fundamentais, incluindo a privacidade como configuração padrão; que a minimização de dados e a pseudonimização reduzem o valor dos dados para os invasores sem impedir a análise; e que as políticas de retenção de dados equilibram as obrigações legais e o risco do armazenamento desnecessário de dados, com destruição segura ao fim da vida útil. A seguir, exploraremos a segurança de dispositivos: antivírus e plataformas EDR e XDR.