postgres postgresql lgpd lgpdp gdpr security
É requisito cada vez mais comum ter que atender as demandas da LGPD, a Lei Geral de Proteção de Dados Pessoais. A LGPD é uma norma muito grande e abrangente que envolve todo o ciclo de vida do dado, do software, da infraestrutura e também da empresa e da forma como ela opera.
Contudo, na direção de atender a LGPD, o primeiro pensamento de muitas pessoas tem sido em apenas encriptar os dados do banco de dados, o que os leva ao segundo problema do "como" encriptar os dados do banco, tornando isso um problema X-Y. Mas encriptação não deveria ser realmente a primeira ação para atender a LGPD e, acima de tudo, não deveria ser a única ação.
Dependendo das demandas de negócio, alguns requisitos técnicos funcionais e não-funcionais precisam ser levantados e tratados adequadamente. E 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 alguns requisitos e seus casos de uso são descritos, mas a escolha de quais são relevantes para o seu negócio é uma decisão que depende completamente do domínio da aplicação e do desenvolvimento do seu software.
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 midias dependendo do caso de uso). E quando esses discos são perdidos, roubados ou aposentados é necessário que eles 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 próprios e infraestrutura própria, 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 esta 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 bloqueio de tela, caso contrário um computador corporativo poderia ser roubado enquanto ligado e usado enquanto o login do usuário estivesse 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. Mas é 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, já que um terceiro que consiga roubar um disco do seu data center muito provavelmente também tem acesso suficiente à rede do data center 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.
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 do 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 é 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.
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 expô-los 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, causado 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 que 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).
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 nem equipe de backoffice e nem para 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 ecommerce, 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. Mas 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 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.
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.
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.