Entenda a LGPD e como ela impacta a segurança dos seus dados

LGPD

Em 2018, o Brasil adotou a LGPD (Lei Geral de Proteção de dados Pessoais – LGPD/LGPDP), assim como diversos outros países (os EUA, a CCPA e a União Europeia, a GRPR). A partir de então,  empresas de todo o mundo têm encarado com maior seriedade a privacidade dos usuários finais e a proteção de seus dados pessoais. Como reflexo, temos visto,  políticas de privacidade atualizadas em aplicativos de celular, redes sociais, e-commerces e outros serviços web.

Internamente, essas empresas também precisaram passar por diversas reestruturações, não só tecnológicas, mas também processuais e metodológicas. Isso porque, leis como a LGPD estipulam novos critérios vitais que devem ser aplicados a todo o ciclo de vida do dado armazenado, especialmente dados pessoais dos usuários finais.

Na prática, significa que as empresas obrigatoriamente precisa realizar  um levantamento detalhado do conjunto mínimo de dados pessoais que podem pedir ao usuário,  apresentando justificativa para cada campo e o período de retenção máxima dele.

Por exemplo, se a empresa não precisa do endereço do usuário, a LGPD diz que ela não deveria pedir esse dado. Por outro lado, ; se precisa dele, então deve deixar claro ao usuário a razão de obtê-lo. Além disso, ; ao solicitar  a informação dado, fica instituído que a empresa deve obter também o consentimento do usuário, que deve ser mantido junto ao dado. Assim,no momento que não precisar mais , deve apagá-lo juntamente come todas as suas cópias.

Esse processo de governança dos dados pessoais é uma das contribuições mais centrais da LGPD. Claramente, também adiciona tarefas e até desafios em todas as ações da empresa, desde as mais fundamentais e internas até as de maior valor agregado e visibilidade externa.

Na prática, então, a contratação de um novo colaborador deve obter o mínimo de documentos, deixando o propósito de cada um bem claro. Da mesma forma, a empresa , deve impedir o vazamento de dados pessoais mesmo internamente, realizando o apagamento algum tempo após o desligamento (esse tempo depende da legislação trabalhista e órgãos reguladores que podem exigir relatórios da empresa alguns anos além dos períodos trabalhados).

Outro exemplo em que se aplica a LGPD é no trato de informações pessoais em redes sociais, que devem ser apagadas no momento da remoção da conta ou sempre que o usuário pedir. Como vemos, essas preocupações adicionam tarefas aos ciclos de desenvolvimento e de manutenção das nossas soluções e infraestruturas.

No entanto, é importante ressaltar que a governança dos dados pessoais não traz apenas custos, desvantagens e possíveis multas por não-conformidade. Na verdade, ela também traz diversas vantagens que, quando bem exploradas, se tornam pontos estratégicos para a empresa.

A primeira é a própria diminuição do risco de vazamento de dados pessoais; uma vez que com nome, CPF  e data de nascimento de alguém, um terceiro consegue acessar diversos serviços governamentais se passando pela pessoa. Por isso, é importante que as empresas não deixem essas informações vazarem internamente (nem mesmo anunciando aniversariantes do mês sem o consentimento explicito de cada colaborador).

Outra é a responsabilização no caso de vazamento de dados pessoais, importante quando o dado era compartilhado entre empresas e vazava, deixando o indivíduo e o meio jurídico sem uma empresa específica para responsabilizar. Consequentemente, isso também diminui os prejuízos ao indivíduo.

Além de tudo isso, uma boa aplicação de governança de dados pessoais aumenta a confiabilidade da empresa e da marca frente ao mercado, já que isso está sendo cada vez mais valorizado pelo usuário final – podendo, e, portanto, ser usado como ponto de persuasão pela equipe de vendas da empresa.

Por fim, a LGPD também permite a regulamentação da troca e venda de dados pessoais entre as empresas, que é ponto importante de dor ao indivíduo que encontra seu nome em bancos de dados de empresas com as quais nunca teve contato prévio.

PostgreSQL e LGPD

O desejo de encriptar dados no banco de dados existe há décadas. Cada vez mais, após 2018, empresas e indivíduos buscam a 4Linux para atender esse pedido específico na esperança de que  resolva o “problema de conformidade com a LGPD” que atualmente enfrentam.

No entanto, como vimos antes, a conformidade com a LGPD e a governança dos dados pessoais são muito mais complexas que apenas a encriptação direta dos dados, já que envolvem todo o ciclo de vida dos dados desde antes de entrarem no banco de dados até muito além de saírem dele (nisso incluo tanto interfaces de aplicações quanto backups e dumps).

A seguir, vamos ver alguns pontos técnicos que podem apoiar partes específicas desse ciclo de vida, mas reconhecendo que, assim como uma cadeira não é feita apenas de quatro pernas (precisa de assento, encosto etc), também a conformidade de um banco de dados na LGPD não é feita de apenas a encriptação dos dados (precisa de políticas de retenção, consentimento do indivíduo etc).

Dependendo das demandas de negócio, alguns requisitos técnicos funcionais e não-funcionais precisam ser levantados e tratados adequadamente. Por outro lado, outros requisitos podem ser ignorados caso não sejam relevantes ao negócio ou aos dados tratados, por exemplo dados não-pessoais podem receber um tratamento bem menos estrito. A seguir, elencamos alguns requisitos e seus casos de uso, mas a escolha de quais são relevantes para seu negócio é uma decisão que depende completamente do domínio da aplicação e do desenvolvimento do seu software.

Data at rest encryption

Discos físicos em data centers são onde os dados são armazenados em grande parte da sua vida útil (também em fitas e outras mídias, dependendo do caso de uso). Quando esses discos são perdidos, roubados ou aposentados, é necessário que eles continuem seguros, ou seja, que não possam ser lidos por terceiros.

Para isso, grandes provedores de serviços de nuvem executam processos complexos de sobrescrita e destruição desses discos sempre que possível. Adicionalmente, os dados dos clientes desses serviços de nuvem nunca são armazenados diretamente nos discos, mas sim encriptados. Esse conjunto de preocupações e ações adicionais (sobrescrita, encriptação, destruição etc.) são exigidos pela LGPD, GDPR, HIPAA e todas as normas de gestão de dados pessoais atuais, assim como normas de dados corporativos como ISO 27000 e PCI-DSS.

No caso de discos de notebooks de colaboradores, esse risco é muito maior, já que esses computadores podem ser facilmente roubados ou perdidos e, então, explorados por terceiros. Portanto, é vital que os discos de computadores corporativos tenham seus discos permanentemente encriptados para evitar essas perdas de dados. Além disso, quando usamos data centers e infraestrutura próprios, também precisamos ao menos fazer essa encriptação nos discos dos servidores.

No Linux, a solução padrão e presente na maioria das distribuições é o LUKS, que faz a encriptação e desencriptação de forma transparente. No boot, o sistema operacional consulta o usuário pela senha que é usada como chave desse processo. Essa chave é mantida em memória RAM enquanto o sistema está ligado, assim o sistema operacional consegue encriptar e desencriptar o que lê e escreve no disco.

Adicionalmente, é vital que outras medidas sejam usadas em conjunto com essa encriptação transparente, como o bloqueio de tela. Caso contrário um computador corporativo poderia ser roubado enquanto ligado e logado um usuário válido.

Em servidores, o PostgreSQL (e todo outro software que trabalha com dados armazenados) não precisa conhecer essa camada de encriptação de dados. No entanto,  é importante que a chave de encriptação de disco não esteja armazenada no mesmo disco (por exemplo em outra partição) dos dados encriptados, já que uma perda do disco significaria que os dados poderiam ser desencriptados pelos terceiros com facilidade.

A chave deve estar em algum lugar externo e pode ser informada também manualmente no boot pelo administrador do sistema ou obtida por um serviço remoto, como o Hashcorp Vault. Nesse caso, a preocupação é movida para a autenticação da máquina de banco de dados com o Vault (usuário/senha ou certificado de serviço), que também não deveria estar armazenada na máquina de banco de dados.

Isso porque, um terceiro que consiga roubar um disco do seu data center muito provavelmente também tem acesso suficiente à rede para conseguir fazer a requisição da chave ao serviço usando as mesmas credenciais usadas pelo serviço genuíno.

Obs.: Uma funcionalidade futura para o PostgreSQL é Transparent Data Encryption (TDE), que permitirá esse tipo de benefício apenas para dados do PostgreSQL, mas não estará disponível antes do PostgreSQL 15.

Anonimização

Dados são anonimizados para que eles não contenham mais nenhuma informação pessoalmente identificável e, então, possam ser compartilhados com parceiros corporativos, público geral ou entidades governamentais. Por exemplo, os dados de censo do IBGE são obtidos do público, mas passam por etapas de anonimização rígida antes de serem publicadas de volta à população para consumo geral. O video “Protecting privacy with MATH” do canal minutephysics é uma das melhores descrições sobre a matemática por trás desse processo: https://www.youtube.com/watch?v=pT19VwBAqKA.

Como é uma atividade intensamente matemática, ela deve ser feita por uma equipe de estatísticos com bom conhecimento e domínio da aplicação e de cada campo da massa de dados, então não existe solução pronta no PostgreSQL que resolva isso instantaneamente. Contudo, muitos desses profissionais usam ferramentas do PostgreSQL para apoiar seus trabalhos, como a linguagem PL/R.

Essa atividade é exigida pela LGPD para dados pessoalmente identificáveis que precisam ser compartilhados sem violar a privacidade. Isso ocorre em resposta direta a alguns casos famosos (no Brasil, Europa e EUA) de abusos de compartilhamento de dados pessoais.

No Brasil, por exemplo, redes de farmácia oferecem ao consumidor incluir o CPF no cadastro de clientes, com a promessa de um desconto na compra; posteriormente, compartilham os dados de CPF e medicações compradas com empresas de planos de saúde, que usam essas informações para aumentar o custo de planos de saúde do indivíduo e sua família, em adição às informações de sinistralidade que já têm. O compartilhamento desse histórico de compras individuais e o uso dele são proibidos pela LGPD exceto se forem perfeitamente anonimizados, o que garantiria que indivíduos não poderiam ser identificados.

Pseudoanonimização

Uma pseudoanonimização é quando os dados pessoais são simplificados o suficiente para que a pessoa não possa ser vitimada caso eles sejam vazados, mas não tanto a ponto de que essa identificação deixe de ser útil. O exemplo mais simples é motoristas/entregadores de aplicativos, que são identificados aos passageiros/usuários apenas pelo primeiro nome e vice-versa, assim as pessoas dos dois lados têm informação suficiente para interagir com o outro, mas não tanta informação a ponto de poder usá-la contra ele.

Um exemplo um pouco mais complexo é o mascaramento de campos mais sensíveis como número de cartão de crédito, CPF ou telefone, assim o usuário pode inspecionar visualmente se reconhece os seus próprios dados e de terceiros mesmo sem que eles estejam completamente disponíveis.

Então essa é uma atividade muito importante em softwares de backoffice de serviços para garantir que dados pessoais dos clientes não sejam vistos livremente por todos da empresa. Sendo assim, o atendente veria apenas partes do nome, como “Arthur N.” em vez do nome completo, assim como os últimos quatro dígitos “(11) xxxxx-1234” do telefone da pessoa com quem está falando, o que é suficiente para garantir que estão conversando com a pessoa certa, mas não é tanto dado pessoal que os expor traria problemas para esse usuário.

Essa é outra atividade exigida em resposta a casos reais famosos no mundo. Por exemplo, em call centers responsáveis por entrar em contato com pessoas com dívidas, alguns operadores de call center roubam informações de contato desses devedores, como nome completo, endereço, telefone e filiação.

Eles então as usam para extorsão e até para golpes telefônicos, como o famoso golpe de sequestro de presídios, causando prejuízos e humilhação. Em alguns casos até os dados de cartão de crédito armazenados no sistema seriam visíveis aos operadores, que venderiam essas informações ou as usariam diretamente para fazer compras em nome dessas vítimas.

O ponto mais importante dentro da pseudoanonimização é identificar quais dados são pessoais e quais são importantes de serem expostos em cada etapa da comunicação. Aqueles que não precisam ser apresentados devem ser escondidos; e os que precisam ser apresentados, podem ser sumarizados ou mascarados. Essa conscientização é o mais importante e não há software que faça isso sozinho. A implementação na aplicação pode ser feita com filtros na camada de visão (MVC) ou até como visões no banco de dados. Existe uma ferramenta de PostgreSQL que apoia esse mascaramento dos dados de forma declarativa: PostgreSQL Anonymizer. Com esse tipo de ferramenta, alguns usuários teriam acesso apenas às visões pseudoanonimizadas, enquanto outros usuários teriam acesso às tabelas originais (por exemplo, o usuário usado pelo software de VoIP que faz a ligação precisa ler o telefone completo).

Proteção de campos avulsos

Também acontece de pensarmos em encriptar campos específicos das tabelas para evitar que alguém com permissão de leitura na tabela possa acessá-los, mas isso traz uma infinidade de outros problemas. Felizmente existem várias alternativas que alcançam esse objetivo, então podemos deixar a encriptação do campo como última opção.

A primeira opção dentro de um banco de dados como o PostgreSQL é usar o próprio sistema de permissões. Com ele podemos permitir e proibir operações específicas (SELECR, INSERT, UPDATE, DELETE) em cada coluna de cada tabela.

Assim, o campo sensível, por exemplo, do número de cartão de crédito, só seria legível para o usuário do microsserviço da aplicação responsável por fazer as cobranças, mas não para outros usuários de aplicação – nem desenvolvedores,  equipe de backoffice e  o usuário final (que não deveria receber na sua interface nada mais que um mascaramento de um ou outro campo).

Outra opção é separar os dados em silos diferentes em função da visibilidade deles. Em um e-commerce, por exemplo, o catálogo de produtos, histórico de vendas e diversos outros dados não são pessoalmente identificáveis e podem ser armazenados em um banco de dados com controle mais relaxado.

No entanto, os campos de identificação do usuário, endereços de entregas e cartões de crédito são todos sensíveis e devem ser isolados em um banco de dados muito mais estrito, submetido a regras como as do PCI-DSS e benchmarks de segurança regulares como os do OpenSCAP. Essas regras são extremamente onerosas em bancos grandes, como seria do catálogo e histórico de vendas, mas são perfeitamente aplicáveis em dados reduzidos e sensíveis, como cadastro de usuários. E esse silo de dados sensível pode receber apenas a encriptação de disco, que é mais eficiente.

Por fim, também é possível encriptar cada campo com o OpenPGP (RFC 4880) disponível na extensão pgcrypto. Contudo, essa encriptação e desencriptação online é muito mais custosa do que aquela em nível de bloco de disco. Ela também abre a dúvida sobre onde armazenar as senhas, chaves ou certificados que são usados nesse processo.

Se essa senha for armazenada em outro campo da própria tabela de usuário ou mesmo em qualquer outro lugar do mesmo banco de dados, um acesso indevido ao banco de dados tem acesso tanto ao dado encriptado quanto ao segredo para desencriptá-lo. Se esse segredo for armazenado em outro local, mais seguro, então é indício de que deveríamos ter colocado os dados sensíveis nesse outro lugar, em vez do segredo para decodificá-lo, ou seja, separado os dados em silos.

E ainda mais, esses campos encriptados não podem ser consultados porque não é possível criar um índice nos valores (mesmo encriptação homomórfica só é válida para grandes volumes, não campos individuais). E se for possível criar um índice funcional sobre esses campos, então o acesso indevido consegue também extrair os dados do índice quase com a mesma facilidade que consegue ler a tabela. Em resumo, a estratégia de encriptar campos avulsos quase nunca faz sentido.

Autenticação e autorização

A LGPD frisa a importância de políticas bem definidas de autenticação e autorização, que nunca deveriam ter sido deixadas de lado. A maior parte dos problemas de segurança são provenientes de esforços insuficientes ou incorretos nessa direção.

Afinal de contas, se um usuário tem acesso indevido a uma tabela isso é um problema de autenticação e autorização que encriptação não tem como resolver sozinha, já que esse mesmo usuário pode ter outros acessos indevidos, como a arquivos de segredos.

No PostgreSQL, os mecanismos de autenticação (pg_hba.conf) e autorização (GRANT, REVOKE, ALTER DEFAULT PRIVILEGES) são suficientes para todas as exigências regulatórias, contanto que sejam usados corretamente, com a identificação dos perfis de acesso diferentes e a atribuição das permissões mínimas para cada um deles.

Auditoria e gestão proativa de logs

A LGPD também destaca a importância de logs de acessos, de operações e de eventos. Esses logs devem ser mantidos em lugares que não podem ser perdidos ou violados, caso contrário um invasor pode também apagar seus traços. E eles devem ser continuamente observados para identificar eventos importantes, como usuários consultando dados.

Dentro do PostgreSQL existem várias opções de logs adicionais, cada uma com seus casos de uso. Mas elas não reportam operações com tanto detalhe quanto pode ser necessário para alguns alvos de conformidade. Para isso existe também o PostgreSQL Audit Extension: https://github.com/pgaudit/pgaudit.

Algumas ferramentas que conseguem automatizar essa gestão proativa de logs e gerar notificações rápidas e dashboards úteis são o Graylog e o Logstash.

Conclusão

A LGPD é uma nova faceta de atenção que devemos ter ao longo de todo o desenvolvimento das nossas soluções. Mas ela não afeta apenas os nossos softwares e infraestruturas, principalmente porque ela também cobre dados em registros físicos, incluindo formulários e contratos em papel. Ou seja, todo e qualquer que seja o meio de armazenamento ou comunicação que contenha dados pessoais dos colaboradores, parceiros ou usuários finais deve estar em conformidade.

É possível atender todos os possíveis requisitos funcionais e não-funcionais com o PostgreSQL (usando funcionalidades próprias dele ou funcionalidades de módulos adicionais, sendo que apenas algumas foram cobertas neste post). No entanto, é apenas quando se alinha essas funcionalidades com a governança de dados pessoais exigida pela LGPD para a sua empresa inteira é que podemos alcançar a conformidade.

Líder em Treinamento e serviços de Consultoria, Suporte e Implantação para o mundo open source. Conheça nossas soluções:

CURSOSCONSULTORIA