Você provavelmente já ouviu falar sobre o GDPR. O novo regulamento europeu de proteção de dados que se aplica praticamente a todos. Especialmente se você estiver trabalhando em uma grande empresa, é mais provável que já exista um processo para obter seus sistemas em conformidade com a regulamentação.

O regulamento é basicamente uma lei que deve ser seguida em todos os países europeus (mas também se aplica a empresas de fora da UE que possuem usuários na UE). Nesse caso específico, aplica-se a empresas que não estão registradas na Europa, mas têm clientes europeus. Então, isso é a maioria das empresas. Não vou abordar ainda mais outros “12 fatos sobre o GDPR” ou “7 mitos sobre o GDPR”, pois eles geralmente são direcionados a gerentes ou pessoas jurídicas. Em vez disso, vou me concentrar no que o GDPR significa para os desenvolvedores.

Por que estou qualificado para fazer isso? Algumas razões - fui conselheiro do vice-primeiro ministro de um país da UE e, por isso, fui exposto e escrevi alguma legislação. Eu estou familiarizado com o “legalese” e como o quadro regulatório opera em geral. Eu também sou um defensor da privacidade e escrevi sobre coisas relacionadas ao GDPR no passado, ou seja, “antes que fosse legal” ( proteger dados confidenciais , o direito de ser esquecido ). E, finalmente, estou atualmente trabalhando em um projeto que (entre outras coisas) visa ajudar a cobrir alguns aspectos do GDPR (a saber, registros seguros de auditoria).

Desta vez, tentarei ser um pouco mais abrangente e abranger o máximo de aspectos do regulamento que preocupam os desenvolvedores. E embora os desenvolvedores se preocupem principalmente com a forma como os sistemas em que estão trabalhando precisam mudar, não é improvável que um gerente menos informado atinja no final da primavera, percebendo que o GDPR entrará em vigor amanhã, perguntando “o que devemos fazer para obtenha nosso sistema / site compatível ”.

Os direitos do usuário / cliente (referidos como “titular dos dados” no regulamento) que considero relevantes para os desenvolvedores são: o direito de apagar (o direito de ser esquecido / excluído do sistema), o direito a restrições de processamento (você ainda mantém os dados, mas os marca como “restritos” e não os toca sem o consentimento do usuário), o direito à portabilidade dos dados (a capacidade de exportar os dados em um formato legível por máquina), o direito à retificação (a capacidade de consertar dados pessoais), o direito de ser informado (obtendo informações legíveis por humanos, em vez de termos e condições longos), o direito de acesso (o usuário deve poder ver todos os dados que você tem sobre eles).

Além disso, os princípios básicos relevantes são: minimização de dados (não se deve coletar mais dados do que o necessário), integridade e confidencialidade (todas as medidas de segurança para proteger os dados em que você pode pensar + medidas para garantir que os dados não foram modificados inadequadamente).

Além disso, a regulamentação exige que certos processos sejam implementados dentro de uma organização (com mais de 250 funcionários ou se uma quantidade significativa de dados for processada), e isso inclui manter um registro de todos os tipos de atividades de processamento realizadas, incluindo transferências para processadores (terceiros), que inclui provedores de serviços em nuvem. Nenhum dos outros requisitos do regulamento tem uma exceção, dependendo do tamanho da organização; portanto, “sou pequeno, o GDPR não me preocupa” é um mito.

É importante saber o que são “dados pessoais”. Basicamente, são todos os dados que podem ser usados ​​para identificar exclusivamente uma pessoa ou dados sobre uma pessoa já identificada. São dados que o usuário forneceu explicitamente, mas também dados que você coletou sobre eles de terceiros ou com base em suas atividades no site (o que eles estão vendo, o que compraram etc.)

Dito isso, vou listar vários recursos que terão que ser implementados e algumas dicas sobre como fazer isso, seguidas por algumas coisas que você deve ou não fazer. Observe que (conforme indicado em cada recurso), eles não precisam necessariamente ser automatizados - você pode simplesmente ter um processo manual em vigor. Mas para sistemas maiores, seria muito melhor automatizá-los.

  • “Esquece-me” - você deve ter um método que aceite um ID de usuário e exclua todos os dados pessoais sobre esse usuário (caso tenham sido coletados com base no consentimento ou com base nos interesses legítimos do responsável pelo tratamento (veja mais abaixo), e não devido à execução do contrato ou obrigação legal). Na verdade, é útil que os testes de integração tenham esse recurso (para limpeza após o teste), mas pode ser difícil de implementar, dependendo do modelo de dados. Em um modelo de dados regular, a exclusão de um registro pode ser fácil, mas algumas chaves estrangeiras podem ser violadas. Isso significa que você tem duas opções: certifique-se de permitir chaves estrangeiras anuláveis ​​(por exemplo, um pedido geralmente tem uma referência ao usuário que o criou, mas quando o usuário solicita que seus dados sejam excluídos, você pode definir o ID do usuário como nulo), ou certifique-se de excluir todos os dados relacionados (por exemplo, através de cascatas). Isso pode não ser desejável, por exemplo, se o pedido for usado para rastrear quantidades disponíveis ou para fins contábeis. É um pouco mais complicado para modelos de dados de fornecimento de eventos ou, em casos extremos, aqueles que incluem algum tipo de estrutura de dados blockchain / cadeia de hash / violação de violação. Com a fonte de eventos, você deve poder remover um evento passado e gerar novamente snapshots intermediários. Para estruturas do tipo blockchain - tome cuidado com o que você coloca lá e evite colocar dados pessoais dos usuários. Há uma opção para usar uma função de hash camaleão, mas isso é subótimo. No geral, você deve pensar constantemente em como pode excluir os dados pessoais. E “nosso modelo de dados não permite” não é uma desculpa. E os backups? Idealmente, você deve manter uma tabela separada de IDs de usuário esquecidos, para que cada vez que restaurar um backup, esqueça novamente os usuários esquecidos. Isso significa que a tabela deve estar em um banco de dados separado ou ter um processo de backup / restauração separado. E “nosso modelo de dados não permite” não é uma desculpa. E os backups? Idealmente, você deve manter uma tabela separada de IDs de usuário esquecidos, para que cada vez que restaurar um backup, esqueça novamente os usuários esquecidos. Isso significa que a tabela deve estar em um banco de dados separado ou ter um processo de backup / restauração separado. E “nosso modelo de dados não permite” não é uma desculpa. E os backups? Idealmente, você deve manter uma tabela separada de IDs de usuário esquecidos, para que cada vez que restaurar um backup, esqueça novamente os usuários esquecidos. Isso significa que a tabela deve estar em um banco de dados separado ou ter um processo de backup / restauração separado.

  • Notificar terceiros para apagar - excluir itens do seu sistema pode ser uma coisa, mas você também é obrigado a informar todos os terceiros para os quais enviou esses dados. Portanto, se você enviou dados pessoais para, por exemplo, Salesforce, Hubspot, twitter ou qualquer provedor de serviços em nuvem, chame uma API deles que permita a exclusão de dados pessoais. Se você é um provedor, obviamente, seu terminal “esqueça-me” deve ser exposto. Porém, chamar as APIs de terceiros para remover dados não é a história completa. Você também deve garantir que as informações não apareçam nos resultados da pesquisa. Agora, isso é complicado, pois o Google não tem uma API para remoção, apenas um processo manual. Felizmente, trata-se apenas de páginas de perfil público que podem ser rastreadas pelo Google (e outros mecanismos de pesquisa, tudo bem …), mas você ainda precisa tomar medidas. Idealmente, você deve fazer com que a página de dados pessoais retorne um status HTTP 404, para que possa ser removida.

  • Restringir processamento - no seu painel de administração, onde há uma lista de usuários, deve haver um botão “restringir processamento”. (A página de configurações do usuário também pode ter esse botão com uma lista suspensa para selecionar as opções do artigo 18 (1)). Quando clicado (depois de ler as informações apropriadas), deve marcar o perfil como restrito. Isso significa que não deve mais ser visível para a equipe do backoffice ou publicamente. Você pode implementá-lo com um simples sinalizador “restrito” na tabela de usuários e algumas clasues if aqui e ali.

  • Exportar dados - deve haver outro botão - “exportar dados”. Quando clicado, o usuário deve receber todos os dados que você possui sobre eles. O que exatamente são esses dados - depende do caso de uso específico. Geralmente, são pelo menos os dados que você exclui com a funcionalidade “esqueça-me”, mas pode incluir dados adicionais (por exemplo, os pedidos que o usuário fez podem não ser excluídos, mas devem ser incluídos no despejo). A estrutura do dump não é estritamente definida, mas minha recomendação seria reutilizar as definições do schema.org o máximo possível, para JSON ou XML. Se os dados forem bastante simples, uma exportação de CSV / XLS também seria adequada. Às vezes, a exportação de dados pode demorar muito tempo, então o botão pode acionar um processo em segundo plano, que notificaria o usuário por e-mail quando seus dados estiverem prontos (o Twitter, por exemplo, já faz isso - você pode solicitar todos os seus tweets e obter depois de um tempo). Você não precisa implementar uma exportação automatizada, embora isso seja bom. É suficiente ter um processo para permitir que os usuários solicitem seus dados, o que pode ser um processo manual de consulta ao banco de dados.

  • Permitir que os usuários editem seu perfil - isso parece uma regra óbvia, mas nem sempre é seguida. Os usuários devem poder corrigir todos os dados sobre eles, incluindo dados coletados de outras fontes (por exemplo, usando um “login com facebook”, você pode ter buscado o nome e o endereço). Regra geral - todos os campos da tabela “usuários” devem ser editáveis pela interface do usuário. Tecnicamente, a retificação pode ser feita por meio de um processo de suporte manual, mas normalmente é mais caro para uma empresa do que apenas ter o formulário para isso. Há um outro cenário, no entanto, quando você obtém os dados de outras fontes (ou seja, o usuário não forneceu os detalhes diretamente para você). Nesse caso, ainda deve haver uma página onde eles possam se identificar de alguma forma (via e-mail e / ou confirmação por sms) e obter acesso aos dados sobre eles.

  • Caixas de seleção de consentimento (ou opções sim / não) - “Aceito os termos e condições” não seria mais suficiente para reivindicar que o usuário deu seu consentimento para processar seus dados. Portanto, para cada atividade de processamento específica, deve haver uma caixa de seleção separada na tela de registro (ou perfil de usuário); ou limpe os botões sim / não. Você deve manter essas caixas de seleção / botões de consentimento em colunas separadas no banco de dados e permitir que os usuários retirem seu consentimento (desmarcando essas caixas de seleção na página de perfil - consulte o ponto anterior). Idealmente, essas caixas de seleção devem vir diretamente do registro de atividades de processamento (se você mantiver uma). Observe que as caixas de seleção não devem ser pré-selecionadas, pois isso não conta como “consentimento”. Outra coisa importante aqui é o aprendizado de máquina / IA. Se você usará os dados do usuário para treinar seus modelos de ML, você também deve obter consentimento para isso (a menos que seja para fins científicos, que tenham tratamento especial no regulamento). Observe aqui o chamado “interesse legítimo”. Cabe à equipe jurídica decidir o que é um interesse legítimo, mas o marketing direto está incluído nessa categoria, bem como qualquer processamento de bom senso relacionado à atividade comercial - por exemplo, se você coletar endereços para remessa, é obviamente um interesse legítimo. Portanto, nem todas as atividades de processamento precisam de caixas de seleção de consentimento. se você coletar endereços para envio, é obviamente um interesse legítimo. Portanto, nem todas as atividades de processamento precisam de caixas de seleção de consentimento. se você coletar endereços para envio, é obviamente um interesse legítimo. Portanto, nem todas as atividades de processamento precisam de caixas de seleção de consentimento.

  • Solicitar novamente o consentimento - se o consentimento dado pelos usuários não for claro (por exemplo, se eles simplesmente concordarem com os termos e condições), você precisará obter novamente esse consentimento. Portanto, prepare uma funcionalidade para enviar por e-mail em massa aos usuários, solicitando que eles acessem a página de perfil e marque todas as caixas de seleção das atividades de processamento de dados pessoais que você possui. Atualização: uma vez que estamos repletos de e-mails inúteis de consentimento e política de privacidade: isso só é necessário se o seu consentimento anterior não tiver sido dado claramente. Em muitos casos, tem sido, então não exagere.

  • “Ver todos os meus dados” - isso é muito semelhante ao botão “Exportar”, exceto que os dados devem ser exibidos na interface do usuário regular do aplicativo em vez de no formato XML / JSON. Eu não diria que isso é obrigatório e você pode deixá-lo como um recurso “desejável” - por exemplo, o Google Maps mostra seu histórico de localização - todos os lugares em que você esteve. É uma boa implementação do direito de acesso. (Embora o Google esteja muito longe de ser perfeito quando se trata de privacidade). Isso não é tudo sobre o direito de acesso - você deve permitir que usuários não registrados perguntem se você tem dados sobre eles, mas isso seria um processo mais manual. O mínimo ideal seria ter um recurso “verificar por email”, onde você verifica se possui dados sobre um email específico. Você também precisa informar ao usuário de que maneira você está processando os dados. Você pode simplesmente imprimir todos os registros em seu registro de processo de dados pelos quais o usuário consentiu.

  • Verificações de idade - você deve perguntar a idade do usuário e, se ele é um filho (abaixo de 16 anos), deve pedir permissão aos pais. Não há uma maneira clara de como fazer isso, mas minha sugestão é a introdução de um fluxo, onde a criança deve especificar o email de um pai, que pode confirmar. Obviamente, as crianças simplesmente trapacearão com a data de nascimento ou fornecerão um e-mail falso para os pais, mas é provável que você tenha feito seu trabalho de acordo com o regulamento (este é um dos aspectos do “pensamento positivo” do regulamento).

  • Mantendo os dados por mais tempo do que o necessário - se você coletou os dados para uma finalidade específica (por exemplo, remeter um produto), você deve excluí-los / anonimá-los assim que não precisar. Muitos sites de comércio eletrônico oferecem “compra sem registro”; nesse caso, o consentimento é válido apenas para o pedido específico. Portanto, você precisa de um job / cron agendado para passar periodicamente pelos dados e anonimá-los (excluir nomes e endereços), mas somente após uma determinada condição ser atendida - por exemplo, o produto é confirmado como entregue. Você pode ter um campo de banco de dados para armazenar o prazo após o qual os dados devem expirar e esse prazo pode ser estendido em caso de um problema de entrega.

  • Cookies - os cookies estão sujeitos a um regulamento diferente (uma diretiva que em breve se tornará um regulamento). No entanto, o GDPR ainda muda as coisas quando se trata de rastrear cookies. Descrevi minha opinião sobre o rastreamento de cookies em uma postagem separada.

Agora, alguns “cumprimentos”, que são principalmente sobre as medidas técnicas necessárias para proteger os dados pessoais (descritos no artigo 32 ). Eles podem ser mais “ops” do que “dev”, mas geralmente o aplicativo também precisa ser estendido para suportá-los. Eu listei a maior parte do que consegui pensar em um post anterior . Uma observação importante aqui é que isso não é obrigatório pelo regulamento, mas é uma boa prática e ajuda na proteção de dados pessoais.

  • Criptografar os dados em trânsito . Isso significa que a comunicação entre a camada de aplicativos e o banco de dados (ou a fila de mensagens ou qualquer componente que você tenha) deve ser feita através do TLS. Os certificados podem ser autoassinados (e possivelmente afixados) ou você pode ter uma CA interna. Bancos de dados diferentes têm configurações diferentes, apenas as conexões criptografadas do Google “X. Alguns bancos de dados precisam fofocar entre os nós - que também devem ser configurados para usar criptografia
  • Criptografar os dados em repouso - isso depende novamente do banco de dados (alguns oferecem criptografia no nível da tabela), mas também pode ser feito no nível da máquina. Por exemplo, usando LUKS. A chave privada pode ser armazenada em sua infraestrutura ou em algum serviço de nuvem como o AWS KMS.
  • Criptografe seus backups - meio óbvio
  • Implementar pseudonimização - o caso de uso mais óbvio é quando você deseja usar dados de produção para os servidores de teste / preparo. Você deve alterar os dados pessoais para algum “pseudônimo”, para que as pessoas não possam ser identificadas. Ao enviar dados para fins de aprendizado de máquina (para terceiros ou não), você também pode fazer isso. Tecnicamente, isso pode significar que o objeto Usuário pode ter um método “pseudônimo” que aplica hash + salt / bcrypt / PBKDF2 para alguns dos dados que podem ser usados para identificar uma pessoa. Os pseudônimos podem ser reversíveis ou não, dependendo do caso de uso (a definição no regulamento implica reversibilidade com base em informações secretas, mas, no caso de dados de teste / estadiamento, pode não ser). Alguns bancos de dados possuem esses recursos embutidos, por exemplo , Oracle.
  • Proteger a integridade dos dados - isso é algo muito amplo e pode significar simplesmente “ter mecanismos de autenticação para modificar dados”. Mas você pode fazer algo mais, mesmo que simples como uma soma de verificação ou uma solução mais complicada (como a que estou trabalhando). Depende das apostas, da maneira como os dados são acessados, do sistema específico etc. A soma de verificação pode estar na forma de um hash de todos os dados em um determinado registro do banco de dados, que deve ser atualizado sempre que o registro for atualizado. através da aplicação. Não é uma garantia forte, mas é pelo menos alguma coisa.
  • Tenha seu registro GDPR de atividades de processamento em algo que não seja o Excel - Artigo 30 afirma que você deve manter um registro de todos os tipos de atividades para os quais usa dados pessoais. Isso parece burocracia, mas pode ser útil - você poderá vincular certos aspectos do seu aplicativo a esse registro (por exemplo, as caixas de seleção de consentimento ou os registros da trilha de auditoria). Não demoraria muito tempo para implementar um registro simples, mas os requisitos de negócios para isso devem vir de quem é responsável pela conformidade com o GDPR. Mas você pode aconselhá-los que tê-lo no Excel não facilitará para você como desenvolvedor (imagine ter que buscar o arquivo do Excel internamente, para poder analisá-lo e implementar um recurso). Esse registro pode ser um microsserviço / aplicativo pequeno implantado separadamente em sua infraestrutura.
  • Log de acesso a dados pessoais - todas as operações de leitura em um registro de dados pessoais devem ser registradas, para que você saiba quem acessou o quê e com que finalidade. Isso não decorre diretamente das disposições do regulamento, mas está meio implícito nos princípios de responsabilidade. E os resultados (ou listas) de pesquisa que contêm dados pessoais sobre vários assuntos? Meu palpite é que simplesmente registrar o “usuário X fez uma pesquisa pelo critério Y” seria suficiente. Mas não exiba muitos dados pessoais em listas - por exemplo, veja como o Facebook faz você passar por algumas dificuldades para conseguir o aniversário de uma pessoa. Nota: alguns trataram o artigo 30 como um requisito para manter um log de auditoria. Não acho que esteja dizendo isso - em vez disso, são necessárias mais de 250 empresas (ou empresas que processam dados regularmente) para manter um registro dos tipos de atividades de processamento (ou seja, para que você usa os dados).
  • Registre todos os consumidores da API - você não deve permitir o acesso anônimo da API aos dados pessoais. Eu diria que você deve solicitar o nome da organização e a pessoa de contato para cada usuário da API no registro e adicioná-los ao registro de processamento de dados.

Finalmente, alguns “não”.

  • Não use dados para finalidades com as quais o usuário não concordou - esse deveria ser o espírito do regulamento. Se você deseja expor uma nova API a um novo tipo de clientes, ou deseja usar os dados para algum aprendizado de máquina, ou decide adicionar anúncios ao seu site com base no comportamento dos usuários ou vender seu banco de dados a terceiros - pense duas vezes. Imagino que seu registro de atividades de processamento possa ter um botão para enviar e-mails de notificação aos usuários, solicitando permissão quando uma nova atividade de processamento for adicionada (ou se você usar um registro de terceiros, provavelmente deverá fornecer uma API). Portanto, ao adicionar uma nova atividade de processamento (e adicioná-la ao seu registro), envie por e-mail em massa todos os usuários com quem você deseja consentir. Observe aqui que interesses legítimos adicionais do controlador podem ser adicionados dinamicamente.
  • Não registre dados pessoais - livrar-se dos dados pessoais dos arquivos de log (especialmente se eles forem enviados para um serviço de terceiros) pode ser entediante ou até impossível. Portanto, registre apenas identificadores, se necessário. E verifique se os arquivos antigos dos logs são limpos, apenas no caso
  • Não coloque campos no formulário de registro / perfil que você não precisa - é sempre tentador simplesmente jogar tantos campos quanto a pessoa / designer de usabilidade concordar, mas, a menos que você precise absolutamente dos dados para a entrega do seu serviço, você deve colete. Os nomes que você provavelmente sempre deve coletar, mas, a menos que você esteja entregando algo, um endereço residencial ou telefone é desnecessário.
  • Não assuma que terceiros são compatíveis - você é responsável se houver uma violação de dados em um deles (por exemplo, “processadores”) para os quais você envia dados pessoais. Portanto, antes de enviar dados por meio de uma API para outro serviço, verifique se eles têm pelo menos um nível básico de proteção de dados. Se não o fizerem, levante uma bandeira com a gerência.
  • Não pense que a ISO XXX o torna compatível - os padrões de segurança da informação e até os dados pessoais são um bom começo e provavelmente serão 70% do que a regulamentação exige, mas não são suficientes - a maioria das coisas listadas acima não são cobertas em qualquer um desses padrões

Em geral, o objetivo do regulamento é fazer com que você tome decisões conscientes ao processar dados pessoais. Impõe as melhores práticas de maneira legal. Se você seguir as orientações acima e projetar seu modelo de dados, armazenamento, fluxo de dados e chamadas de API com a proteção de dados em mente, não se preocupe com as enormes multas prescritas pelo regulamento - elas são para casos extremos, como Equifax, por exemplo . Os reguladores (autoridades de proteção de dados) provavelmente terão algumas listas de verificação nas quais você precisaria se encaixar de alguma forma, mas se você seguir as práticas recomendadas, isso não será um problema.

Eu acho que todos os recursos acima podem ser implementados em poucas semanas por uma pequena equipe. Suspeite quando um grande fornecedor oferece uma solução genérica plug-and-play de “conformidade com o GDPR”. O GDPR não se refere apenas aos aspectos técnicos listados acima - ele tem implicações organizacionais / de processo e muitas perguntas a serem respondidas . Mas também desconfie se um consultor alegar que o GDPR é complicado. Não é - depende de alguns princípios básicos que são, de fato, as melhores práticas. Só não os ignore.

Autor: Bozho - Bozhidar Bozhanov

Artigo Original