O que engenheiros de software deveriam saber sobre GDPR?

Vai criar novas soluções de software em 2018? Se sim, é uma boa ideia ler isso. O Regulamento Geral de Proteção de Dados da União Europeia (GDPR) está saindo do período de transição para se tornar obrigatório neste ano. A violação de seus termos pode levá-lo a enfrentar multas de até 20 milhões de euros - ainda mais para grandes organizações. Além das sanções listadas no regulamento, até mesmo a prisão é possível para pessoas responsáveis por grandes negligências ou violações de dados.

Obviamente, isso soa severo. Vi duas abordagens extremas para o GDPR: uma delas é fingir que não se aplica a você e tentar ignorá-lo; outra é declarar o fim dos tempos e que nenhum desenvolvimento pode se concentrar mais nos dados pessoais. Ambas as abordagens são erradas, mal informadas e podem levar a enormes prejuízos. O GDPR não cria um cenário de fim a todos os dados pessoais; em vez disso, estabelece regras para o gerenciamento transparente e seguro de dados pessoais e ameaça aqueles que ignoram isso com sanções muito interessantes.

O GDPR enfatiza fortemente o pensamento baseado em risco; você toma todas as medidas para mitigar os riscos de privacidade até que os riscos se tornem algo tolerável. Aprecio este regulamento - há software suficiente por aí que não tem absolutamente nenhuma segurança ou privacidade construída no projeto. Esse tipo de software e suas brechas levam os usuários a desconfiar de como seus dados pessoais estão sendo usados. É hora de mudar isso.

Pontos-chave para o entendimento

Este tópico é enorme, então estou me concentrando exclusivamente no processo de criação de novas soluções de software. Há muito a dizer sobre suporte organizacional e sistemas legados, mas eles são altamente dependentes do ponto de partida. O GDPR não permite muitas exceções à regra, então tanto grandes e pequenas empresas, organizações sem fins lucrativos e organizações governamentais precisam conhecer os principais pontos.

Um ponto-chave do novo regulamento é a transparência à qual os dados estão sujeitos. Quando você possui um registro - por exemplo, um banco de dados - que contém dados de identificação pessoal, o GDPR afirma que seu uso deve ser transparente para os assuntos de dados. Isso significa que as pessoas cujos dados está coletando devem ser capazes de descobrir o que está sendo coletado, seu propósito, quem tem acesso aos dados e quanto tempo os dados vivem dentro dos sistemas. Para lidar com este requisito, você naturalmente deve conhecer todas essas coisas e documentá-las. Além da transparência, é preciso fornecer um acesso melhor aos referidos dados. As pessoas em questão devem ser capazes de verificar, corrigir, exportar, mover e apagar seus dados com a mesma facilidade que deram a você.

Outro tópico importante é a privacidade por projeto/padrão. Isso deve ser integrado em cada bit da arquitetura a partir de agora. Isso deveria ter sido um elemento padrão de projeto antes deste regulamento, mas as pessoas geralmente não querem pagar por segurança ou privacidade até que algo aconteça. O GDPR dá um poderoso incentivo para cuidar disso agora - um incentivo no valor de até 20 milhões de euros. A privacidade por padrão significa muitas coisas, mas essencialmente visa proteger os dados pessoais identificáveis e sua privacidade, com controles adequados. Isso geralmente requer, por exemplo, trilhas claras de auditoria sobre a forma como quem fez o quê, incluindo especialmente o acesso de leitura de informações pessoais identificáveis. Além disso, preste atenção aos dados ao armazená-los e em trânsito entre camadas diferentes, e aplique uma criptografia adequada para evitar vazamentos de dados de seus sistemas.

Tenha também uma base válida para o processamento de dados pessoais, o que significa especificamente o direito de coletar e processar a informação. A base, por exemplo, pode ser uma lei que exige que informações sobre pessoas sejam coletadas e armazenadas por um período de tempo. A base para o processamento de dados pessoais pode ser um contrato, acordo ou transação.

O consentimento pode ser solicitado para coletar e processar dados pessoais, mas o GDPR não permite que seja algo fácil. Não é aceitável que um checkbox já tenha sido marcado com uma declaração como "Aceito que minhas informações possam ser usadas para fins de marketing". O consentimento deve ser claro, preciso e compreensível - e não pode ser pré-definido. Deve ser tão fácil cancelar o consentimento quanto consentir em primeiro lugar. Os arquitetos de software não podem decidir nada disso por conta própria, precisam discutir isso com quem possui o software.

Aqui é um outro ponto interessante. Se os membros da equipe que compõem o software tiverem acesso a dados pessoais reais ao construí-lo, eles se tornam processadores de dados e passíveis das mesmas sanções e responsabilidades. O mesmo vale para o time de operações. Se eles têm acesso a bancos de dados e dados, também são legalmente responsáveis. Talvez queira pensar muito sobre isso. É possível construir e operar a maioria dos sistemas sem acessar os dados reais do cliente, afinal.

Reconhecendo informações de identificação pessoal (PII)

O GDPR só está interessado em informações de identificação pessoal (PII). O GDPR não se aplica a dados que não estão vinculados a uma pessoa, como informações de produtos ou contabilísticas. Assim, mesmo se classificar essas informações como sensíveis e queira protegê-las, o GDPR considerará como dados não-PII, ignorando essas situações.

O GDPR identifica duas classes de dados PII. Há dados que podem ser usados para identificar de forma exclusiva uma pessoa como: número de segurança social, endereço de e-mail ou qualquer coisa diretamente conectada a esses identificadores, como o histórico de compras. Em seguida, há dados extra-sensíveis, como informações médicas/saúde, religião, orientação sexual ou qualquer informação coletada de um menor.

Observe que de acordo com o GDPR, as combinações de informações que podem não ser exclusivas isoladamente podem potencialmente identificar um indivíduo. Portanto, a PII também inclui identidades que podem ser deduzidas de valores como código postal, viagens ou vários locais de compra. Conjuntos de dados minúsculos e combinações raras de valores facilitam a identificação pessoal.

Uma vez que qualquer informação anexada ou coletada de uma pessoa está protegida por regras de privacidade, a maioria dos bancos de dados irá conter PII, com algumas exceções. Estimaria que 70% a 80% dos dados típicos dos sistemas sejam PII. Ou seja, não são apenas números de segurança social e números de cartão de crédito que deveriam estar protegidos.

Houve muita discussão sobre logs de acesso, logs de auditoria, etc. que contêm endereços IP ou chaves de substituição. São dados pessoais? São registros? Todos os direitos pessoais se estendem a eles? Quão fortemente eles devem ser protegidos? Os especialistas parecem não concordar com as respostas. Temos que esperar e ver como isso evolui. Recomendaria, no entanto, evitar a histeria e usar o senso comum em áreas cinzentas. Esse tipo de informação poderia e deveria ser protegido até certo ponto, dependendo de quanto dano causaria uma infração de dados. Mas simplesmente não vejo que todos os servidores web do mundo se tornem um registro PII no sentido mais exigente da definição.

Projetando para a privacidade

A maneira mais barata de construir o seu software para cumprir o GDPR é criar os requisitos de maneira correta. Quão abrangente ser depende do nível de risco do sistema específico em questão:

• O seu sistema contém informações extra-sensíveis?
• O seu sistema contém algo que, embora não seja sensível para fins do GDPR, seria embaraçoso/perigoso publicar?
• Se alguém publicou seu conteúdo de banco de dados, qual seria o maior risco para sua empresa?
• Quão grande é o seu banco de dados de usuários?

Se tem poucos usuários e as informações que coleta não são sensíveis e nem prejudiciais, pode considerar seu sistema como um ambiente de baixo risco e usar controles mais econômicos para protegê-lo. Por outro lado, se o seu sistema contiver dados confidenciais para muitos usuários, deveria ser aplicada uma proteção mais forte.

Uma boa trilha de auditoria é um requisito mínimo. Uma trilha de auditoria não só mostra que controles foram aplicados, mas também ajuda a limitar os danos em caso de violação de dados. Após qualquer violação de dados, seja por uma parte interna ou externa, a primeira coisa que precisa ser feita é investigar evidências que possam mostrar quais usuários são afetados e quais dados foram acessados. Esta é a informação que precisa ser reportada às autoridades de proteção de dados. Além disso, estes são os usuários que precisam ser informados sobre a violação de dados. Se não há como investigar evidências, deve-se assumir que uma violação pode ter afetado todos os usuários e todos os registros.

Uma boa trilha de auditoria também apresenta não-repúdio - em outras palavras, não pode ser alterada/danificada, mesmo pelos administradores do sistema. Por exemplo, trilhas de auditoria podem ser usadas para ver quais dados um administrador de sistema estava violando. Isso aconteceu antes e acontecerá novamente. As trilhas de auditoria também são classificadas como PII: elas possuem uma identidade e dados únicos diretamente conectados a isso.

Após as trilhas de auditoria, a próxima tarefa é limitar a exposição dos dados. A melhor maneira de fazer isso é limitar quais dados são coletados e por quanto tempo ele será armazenado. Ao introduzir alguns tipos de mecanismos de arquivamento/apagamento no seu software desde o início, isso poderá ser documentado para seus usuários. Se ocorrer uma violação de dados, ela só pode afetar os dados que estavam realmente no sistema direcionado nesse ponto. Muitos sistemas continuam a coletar todos os dados, mas nunca o limpam, mesmo quando os dados se tornam obsoletos. O GDPR encoraja a definir claramente os ciclos de vida dos dados e a documentá-los. O acesso aos dados também deve ser restringido apenas ao que é realmente necessário. Isto é especialmente verdadeiro para dados confidenciais.

Já mencionei que é desejável ter mecanismos de proteção suficientes para dados que estão descansando em um banco de dados ou sistema de arquivos e que estão sendo transferido através de uma rede, especialmente para outras partes. A criptografia é eficiente, mas tem seus pontos fracos. A tecnologia de criptografia mais poderosa criptografa antes, protege suas chaves e desencripta depois. Infelizmente, esta é uma solução complexa e custosa para implementar. Os serviços em nuvem, no outro extremo do espectro, muitas vezes permitem codificar e simplesmente criptografar um banco de dados completo com um checkbox ou se oferece para gerenciar chaves e criptografia para você. Embora sejam fáceis, esses mecanismos têm pontos fracos. Só é preciso encontrar o que funciona para você, com base nos riscos e na sensibilidade dos dados.

Vale ressaltar que os mecanismos de anonimização e pseudonização podem ajudá-lo com coisas como dados de teste ou dados de análise. A anonimização basicamente remove todas as informações identificáveis excluindo ou mascarando campos. A pseudonização substitui informações identificáveis com pseudônimos, que tipicamente mantêm as identidades separadas nos dados. Ambas as práticas, no entanto, são difíceis de fazer corretamente e podem não oferecer meios perfeitos para ajudar sua compatibilidade GDPR. Ainda assim, são ferramentas valiosas no seu kit de ferramentas.

Talvez seja desejável revisitar seus padrões e diretrizes de log. É mais fácil se puder garantir que seus logs não contenham PII - caso contrário, eles se tornam registros PII também com todas as implicações. Alguns logs são anexados a indivíduos: logs de acesso e logs de auditoria, por exemplo. Mas não polua logs de depuração operacionais, escrevendo IDs de usuários, nomes ou valores similares neles. É bom separar claramente os logs que podem ser vinculados a indivíduos de logs que não podem ser tão vinculados, mas que contêm informações gerais do sistema.

Documente os seus sistemas

O GDPR adora documentação. Um ponto importante do regulamento é poder demonstrar conformidade. Isso pode ser feito mostrando certificados, que, por sua vez, se beneficiam da documentação de seus sistemas. Pode-se criar, se necessário, o nível de documentação que costuma fornecer, o que pode variar de acordo com muitos fatores. Mas há alguma documentação adicional que será útil de agora em diante. Aqui está uma breve lista para verificação:

• Documentar os dados pessoais em seu sistema.
• Documentar ciclos de vida de dados coletados.
• Documentar todas as partes que processam os dados.
• Documente sua base para coletar os dados.
• Informar os usuários de dados sobre seus direitos e explique como eles podem exercê-los.

Deve-se documentar quais dados são coletados, seu propósito, por quanto tempo são armazenados e sua base para o processamento desses dados. Isso pode ser feito melhor com uma combinação de tipos de documento. Pode-se (e deve-se) já ter um documento de política geral que explica as regras, mas vi muitos designers de software começarem a criar uma grade de colunas de dados nas quais eles podem indicar a classificação GDPR. Basicamente, qualquer documentação já usada por ser seu modelo de domínio, mas depois expanda com informações de privacidade. Esses documentos servirão então de base para o documento de política de proteção de dados que seria oferecido aos seus usuários. O primeiro passo para garantir os direitos dos usuários é entender quais das informações seu sistema coleta.

Outro lado interessante é a forma como os dados se movem sobre as redes e quais partes podem acessá-lo/processá-lo. Para isso, você pode criar um diagrama de fluxo de dados que documenta partes, camadas e até protocolos. Em caso de violação de dados, isso também pode ser usado para entender e limitar a exposição rapidamente.

Além disso, se desejar, pode-se querer documentar quais controles são usados para proteger os dados, alcançando um nível de privacidade suficiente.

Dar respaldo à expansão dos direitos do usuário

A maioria dos direitos dos usuários/assuntos de dados já existe na Diretiva de Proteção de Dados estabelecida pela UE. Aqui está uma lista simples de como eles aparecem sob o GDPR:

• Direito de acesso,
• Direito de retificação,
• Direito a apagamento,
• Direito de restringir / objeto ao processamento,
• Direito de portabilidade de dados,
• Direito de ser notificado de violações de dados.

Antes de começar a projetar todos os tipos loucos de API e sistemas para suportar isso, vale a pena notar que o GDPR não exige que estejam automatizadas, operações em tempo real. Na verdade, só é preciso responder a um pedido dentro de 30 dias. Responder que não há base para apagar ou exportar os dados (devido a leis, contratos em andamento, etc.) pode ser uma resposta legítima - e quando uma pessoa faz um pedido, é muito importante que os identifique adequadamente para que não crie uma nova violação de dados manipulando ou exportando dados de outras pessoas. A janela de resposta de 30 dias permite que os dados sejam misturados ou apagados de várias maneiras, mesmo manipulando em sistemas que simplesmente não são possíveis de integrar.

Dito isto, se a sua organização já tiver um conceito de identidade digital para clientes/usuários/assuntos de dados e você fornecer algum autoatendimento, é uma boa ideia anexar esses direitos de identidade à interface de usuário do autoatendimento. Quanto mais documentação for coberta com processos automatizados, mais barato se torna. Além disso, os usuários ficam mais satisfeitos com o acesso em tempo real, em vez de fazer um pedido que leva 30 dias para processar.

Pode ser sábio se preparar para o apagamento de dados e exportar funções ao projetar qualquer novo pedaço de software. Pode-se conseguir o apagamento, excluindo informações, mas é mais fácil substituir parcialmente, efetivamente anonimizando-o. O formato para a exportação de dados não parece importar agora, mas pode ser uma boa ideia planejar, mesmo que seu domínio não contenha interfaces de usuário GDPR.

A coisa mais importante para obter direito é o lugar comum onde as pessoas em questão podem exercer seus direitos, levando a um processo que identifica e valida a solicitação e depois aos mecanismos que apagam ou exportam esses dados.

Processador de dados ou não?

Quando está trabalhando em um projeto de software sob responsabilidades GDPR, é preciso responder a uma pergunta importante: pretende-se ser um processador de dados ou não? Por padrão, deseja-se não ser um processador de dados, uma vez que ser um faz com que se responsabilize por quaisquer sanções. Para evitar a responsabilidade do GDPR, simplesmente certifique-se de que não poderá acessar e não irá acessar dados pessoais em qualquer circunstância. Também é preciso ter certeza de que isso está claramente indicado em qualquer contrato. Pode ser difícil evitar o processamento de PII, uma vez que os dados pessoais podem ocultar em arquivos de log incorretamente escritos, ambientes de teste e quaisquer patches de emergência para o seu ambiente de produção. Mas se deseja evitar a responsabilidade, é preciso resolver tudo isso. Proteja-se dos dados e proteja os dados de você.

Outro caminho a seguir é abraçar esse status de processador de dados. Isso permite que se tenha acesso gratuito a dados pessoais, desde que a atividade seja documentada, há bases válidas para o processamento e o acesso acontece dentro de limites definidos. Isso o torna legalmente responsável claramente, então esteja atento a quaisquer sanções. Mas este é o caminho a seguir se é preciso o acesso às bases de dados PII.

A maioria dos projetos de software não requerem exposição aos dados reais de PII, e este é definitivamente o caminho recomendado a seguir - mas pode exigir novas habilidades e ferramentas.

Quebrando mitos do GDPR

Não, um tópico de dados não pode apagar dívidas ou antecedentes criminais exercendo direitos de usuário.

Não, um tópico de dados não deve ter tudo conectado à sua identidade quando solicitar uma exportação de seus dados. Apenas informações coletadas diretamente devem ser incluídas. O espírito do regulamento é a transparência e a opção de mudar os prestadores de serviços.

Os direitos de usuário não são exercidos automaticamente. É importante primeiro verificar a identidade do usuário e a validade de uma solicitação antes de manipular dados. Isso pode ser difícil se um banco de dados não possuir identificadores únicos e seguros. Pode haver muitos motivos válidos para recusar um pedido.

Não, o GDPR não exige que tudo seja criptografado com chaves de 2048 bits em repouso e em trânsito. Os controles para proteger esses dados são usados apenas para mitigar os riscos até que eles se tornem acessíveis, e os riscos são diferentes para cada sistema e situação.

Não, o GDPR não o impede de coletar e processar dados do usuário. Cuide da transparência, segurança de dados e base legal, e não colete mais dados do que é preciso e tudo está bem.

Não, ter uma violação de dados não o sujeita automaticamente a 20 milhões de euros em multas. Poderia - mas se leu este artigo e seguiu o conselho, já deveria estar bem no seu caminho para reduzir potenciais penalidades. Reparar o que pode ser feito agora, desde o início, e ter um plano para o resto, vai um longo caminho. O GDPR lista algumasdúzias de perguntas que serão usadas para decidir a escala das penalidades se esse tempo chegar.

Não, as sanções não são o principal motivo para começar a fazer algo sobre a privacidade dos dados. Este regulamento está em vigor porque mais e mais dados são coletados todos os dias, e cada vez mais violações de dados estão acontecendo. Ter uma violação de dados no seu sistema pode custar-lhe muito mais do que taxas e sanções, pode custar-lhe a confiança dos seus clientes. Mas as sanções são uma boa maneira de motivar as empresas a gastar dinheiro com segurança e privacidade ao construir e comprar software e sistemas de informação.

Não, os serviços em nuvem não são um grande não-não com o GDPR. Na verdade, eles podem realmente estar mais em sincronia com os requisitos de privacidade por padrão do que muitos data centers tradicionais. Claro, transferir dados confidenciais para terceiros torna as coisas ligeiramente mais complicadas quando se trata de contratos e documentação.

Não, o GDPR não exige que tudo seja auditado e registrado e que tenha ferramentas para detecção de intrusão e gerenciamento de dados de teste. Essas ferramentas podem tornar a vida mais fácil quando utilizadas com sucesso, mas o núcleo da sua abordagem deve ser uma avaliação baseada em risco e controles adequados.

Conclusão

Não há muito tempo antes que o GDPR se torne exigível. Para já, qualquer novo sistema deve ser construído compatível com o GDPR. Esta não é uma definição precisa, especialmente porque as interpretações continuam a evoluir e muitas delas só serão esclarecidas à medida que as violações de dados, auditorias e sanções ocorrerem no futuro. Minha esperança é que este artigo possa ajudá-lo a evitar estar entre os primeiros a pagar o preço.

Imagino que os regulamentos de proteção de dados que estão por vir são fortemente positivos e surpreendentemente ambiciosos. Finalmente, há motivos para colocar mais ênfase na segurança e na privacidade. A medida que a transparência e a privacidade são melhoradas e se proporciona mais controle, os usuários de seus sistemas confiarão mais em você mais e muitos deles provavelmente permitirão que suas informações sejam usadas para novos tipos de análise e marketing que ninguém está ciente agora mesmo. Provavelmente haverá alguma turbulência no meio de 2018, uma vez que algumas das regras serão esclarecidas, mas acredito que o GDPR levará a mais segurança e transparência a longo prazo e aposto tudo nisso.

Quando se encontrar nas áreas cinzentas dos regulamentos, sem saber o que fazer, o senso comum percorre um longo caminho. A fonte de confusão é algo que pode ser documentado e explicado honestamente aos usuários/tópicos de dados da sua solução de software sem constrangimento ou vergonha? Se assim for, provavelmente tudo vai ficar bem. Pense nos cenários do pior caso, como violações de dados. Se o seu banco de dados, a cópia instantânea ou a exportação do Excel devem cair em mãos erradas que o publiquem em algum lugar, como poderia se descobrir exatamente o que foi vazado, por quem e quais dos seus usuários precisam ser notificados? Poderia explicar como os dados foram protegidos? Caso contrário, provavelmente foi feito o que era humanamente possível, o que provavelmente ajudará a mitigar as sanções, se houver. Faça o seu melhor, coloque o resto em um roteiro. Construa para um mundo mais seguro com mais transparência. No final, todos estarão mais felizes.

Sobre o autor

Arto Santala é um arquiteto de software da Solita Oy. Tem mais de 20 anos de experiência na elaboração de soluções de software para permitir já o futuro do mundo. Suas maiores paixões incluem automatizar praticamente tudo e usar metodologias ágeis para fazer as coisas certas da maneira certa.