GDPR para a operação

O que é o GDPR e por que devo me importar?

O GDPR (Regulamento Geral de Proteção de Dados) destina-se a ajudar os cidadãos da União Europeia (UE) a ter maior controle sobre seus dados pessoais. Aplica-se a qualquer organização (dentro ou fora da UE) que detenha dados sobre cidadãos da UE, de forma que o âmbito é bastante amplo, o que causou um certo pânico em algumas organizações.

Parte da razão para isto é que o regulamento introduz sanções de até 20 milhões de euros ou 4% do volume de negócios mundial anual. Esta é uma penalidade financeira mais significativa do que a que pode ser imposta pela Diretiva de Proteção de Dados (substituída pelo GDPR) e, portanto, forçou uma conversa mais séria sobre conformidade e responsabilidade na sala de reuniões.

Como sempre, o trabalho duro real de implementar o GDPR continua em um lugar qualquer em uma organização. Como praticantes de administração de sistemas, operações, DevOps ou SRE, com o que precisamos nos preocupar?

Costumo recomendar que, se irá se comprometer com alguma forma de regulação, provavelmente levará algum tempo para ler o texto em questão para ter uma ideia da linguagem que está sendo usada, para que esteja melhor posicionado para discutir detalhes com auditores ou conselheiros. No entanto, não espere encontrar nenhuma resposta técnica útil nos regulamentos do GDPR. Este é um instrumento legislativo, projetado para advogados, não um guia de segurança para engenheiros. Os leitores que trabalharam com as listas de verificação de padrões muito prescritivos do PCI-DSS podem ficar desapontados ao descobrir que não há equivalente no GDPR.

Há boas e más notícias aqui. A boa notícia é que muitas das disposições do GDPR não são diferentes das disposições da Diretiva de Proteção de Dados à qual substitui. A má notícia é que muitas organizações não estão realmente fazendo um bom trabalho no suporte à essas disposições.

Fundamentalmente, a maioria dos regimes de conformidade é sobre segurança de dados, e seu conteúdo pode basicamente ser reduzido às duas principais preocupações de "não deixar os dados vazarem" e "não deixar os caras maus entrarem". O GDPR expande essas noções básicas, exigindo que os indivíduos tenham o direito de saber mais sobre como seus dados estão sendo usados, solicitar cópias de dados sobre eles, e ainda para solicitar que seus dados sejam excluídos. Estes regimes têm implicações óbvias do ponto de vista da tecnologia.

Em particular, o artigo 25.º refere-se à "proteção de dados por design e por padrão". Quais considerações de design deveríamos estar incorporando em nossos sistemas?

Identidade e controle de acesso

Do ponto de vista do sistema, uma boa postura de segurança requer um gerenciamento forte da identidade. Cada indivíduo que interage com um sistema deve ter sua própria identidade exclusiva, gerenciada centralmente em algum tipo de solução de diretório. Este pode ser um serviço executado como o Active Directory ou LDAP, ou pode ser uma solução SaaS fornecida por uma empresa como a Okta. Esse serviço de identidade gerenciará credenciais, como senhas e tokens de segurança, usados para fatores adicionais de autenticação. Ao fornecer um SAML ou OAuth2 IdP (provedor de identidade) com suporte deste serviço, é possível federar essa identidade em qualquer sistema separado, permitindo que os usuários efetuem login com um único conjunto de credenciais.

Embora esse tipo de federação de usuários seja mais comumente usado com serviços SaaS externos, também pode ser usado com sistemas da Web internos. Usando o Traefik ou software similar (como o IAP do Google) é possível colocar um proxy com reconhecimento de identidade na frente de aplicativos Web existentes, para que os usuários façam login no proxy com suas credenciais de logon único para acessar o aplicativo em si.

Na Amazon Web Services, tanto o IAM (seu serviço de gerenciamento de acesso e identidade) quanto o Cognito podem fazer uso de fontes federadas de identidade, permitindo que os usuários façam logon nesses serviços com suas credenciais de logon único.

Isso também não ocorre somente com interfaces Web: o Hashicorp Vault fornece um serviço de API de segurança que pode usar um IdP externo como fonte de identidade para os usuários. Uma vez identificados, os usuários podem solicitar ao Vault a venda de certificados SSH assinados, que permitirão o acesso de shell a sistemas remotos; ou fornecer credenciais de acesso temporário a bancos de dados e outros serviços.

Com uma boa história de identidade, a próxima coisa a considerar é o RBAC (Role Based Access Control). O gerenciamento de permissões por usuário é tedioso, é muito difícil de escalar e é difícil raciocinar do ponto de vista da auditoria. Em um modelo RBAC, criamos funções e atribuímos permissões a essas funções. Uma função pode ser "administrador de banco de dados" ou "agente de atendimento ao cliente", por exemplo. Cada uma dessas funções terá permissões muito diferentes, o administrador de banco de dados pode ter acesso shell a clusters de banco de dados, mas nenhum acesso ao front-end da web de serviço ao cliente. Atribuindo funções aos usuários, podemos ver facilmente quem tem quais grupos de permissões.

A identidade não é apenas sobre pessoas, servidores físicos, máquinas virtuais, containers e aplicativos também podem ter identidades. Fornecedores de nuvem, como a AWS, e plataformas de orquestração, como o Kubernetes, têm fortes conceitos de identidade para seus componentes. Na AWS, as instâncias do EC2 podem obter acesso ao "documento de identidade da instância", bem como a um conjunto de assinaturas que podem ser usadas para verificar a autenticidade desses dados. O documento de identidade pode ser usado para provar a identidade da instância para o Hashicorp Vault, que pode, então, fornecer segredos com segurança a essa instância com base na função atribuída. Um workflow semelhante está disponível para estabelecer a identidade de um container agendado pelo Kubernetes. Com princípios de identidade fortes como esses, nunca deve ser necessário colocar segredos, como credenciais de banco de dados ou chaves de API, diretamente na configuração do aplicativo, isso pode ser gerenciado centralmente.

Agora podemos atribuir funções, tanto a pessoas quanto a partes do nosso sistema. Cada uma dessas funções deve receber o menor conjunto absoluto de permissões necessárias para realizar seu trabalho. Esse princípio de privilégio mínimo facilita a demonstração a um auditor de conformidade sobre quais pessoas ou sistemas podem acessar quais objetos de dados.

Logging e auditoria

Depois de estabelecer quais pessoas ou sistemas podem acessar quais itens de dados, é preciso registrar esse acesso para mostrar a um auditor que os controles de acesso estão funcionando corretamente. Também é preciso ser capaz de demonstrar que os logs não podem ser adulterados depois de terem sido gravados.

Na AWS, é possível ativar o registro em log do CloudTrail, que registrará todas as chamadas da API AWS feitas nos recursos. Esses registros devem ser gravados e criptografados no armazenamento S3 de propriedade de uma conta de registro seguro dedicada. O acesso a essa conta de registro deve ser estritamente controlado, as políticas neste intervalo devem garantir que não seja possível, uma vez gravados, modificar ou excluir logs.

Outros registros do sistema e do aplicativo devem ser agregados de maneira semelhante, enviados diretamente dos servidores host para um armazenamento seguro e à prova de falsificação. O expedidor de log utilizado usa aqui deve ser configurado para copiar os dados do log, literalmente, para demonstrar a um auditor que os logs armazenados não foram modificados a partir de seu formato original.

Se também estiver usando ferramentas como a stack ELK do Elastic para visualizar e pesquisar dados de log, há várias razões pelas quais pode-se querer modificar dados de log à medida que os envia. Nesse caso, use uma segunda configuração de remetente de log para essa cópia menos segura dos logs.

É possível que os registros contenham dados pessoais conforme definido pelos termos do GDPR e, como tal, devem ser expirados e excluídos em uma linha do tempo apropriada. A aparência dessa linha do tempo dependerá da sua carga de trabalho específica e de quaisquer outras obrigações de conformidade que você tenha. O Artigo 17 do GDPR abrange o "direito de apagar", em que um titular de dados pode solicitar que exclua quaisquer dados pessoais que detenha sobre ele. Isso será mais fácil quanto menos dados tiver por padrão.

O Artigo 15 abrange o "direito de acesso pelo titular dos dados", em que alguém pode pedir que se forneça todos os dados possuídos sobre eles. A organização provavelmente tem uma boa ideia de quais dados pessoais existem em seus armazenamentos de dados principais e de como esses dados estão vinculados às relações, mas pode ser menos óbvio quais desses itens de dados podem acabar em seus registros. Isso provavelmente significa que é preciso procurar por entradas de registro de um usuário específico sob um direito de solicitação de acesso. Nesse caso, é provável que os dados de log estruturados (em vez de texto livre) sejam úteis, e ferramentas de pesquisa, como a AWS Athena, podem facilitar esse trabalho.

Para tornar a conformidade mais fácil, convém insistir que os desenvolvedores de software tomem medidas com suas estruturas de log para remover dados pessoais de eventos de log, se não forem necessários. Lembre-se que, de acordo com as regras GDPR, identificadores de dispositivo, endereços IP, códigos postais e outros podem ser considerados dados pessoais, já que podem ser usados para identificar um indivíduo, portanto, considere isso também.

Backups

É muito provável que tenhamos dados pessoais em nossos backups. O GDPR pode, portanto, afetar nossas políticas de retenção. Sob o direito de ser esquecido, um titular de dados pode pedir que os dados sobre ele sejam removidos. Se excluirmos apenas os dados desse titular dos sistemas de produção, ainda teremos cópias em nossos backups.

Talvez queira perguntar a um advogado amigável sobre isso, mas a partir da minha própria pesquisa sobre o assunto, parece que deve ser razoável remover dados de bancos de dados de produção e informar o indivíduo que, embora seus dados ainda existam em backups, que estes serão expirados em 30 dias, ou o que for, de acordo com sua política de retenção.

No caso de precisar fazer uma restauração a partir dos backups, será preciso apagar os dados desse indivíduo novamente e, assim, os dados dos indivíduos apagados precisarão de rastreamento, pelo menos durante o período de sua política de retenção.

Criar uma função de "administrador de backup", impedindo o acesso a backups por qualquer outra pessoa e limitar o número de pessoas que têm essa função ajudará a reduzir o número de indivíduos com acesso a dados apagados durante o período de retenção de backup, o que parece uma medida razoável a se tomar.

Conjuntos de dados de teste e desenvolvimento

Algumas empresas estão acostumadas a restaurar cópias de dados de produção em sistemas de preparação ou desenvolvimento, a fim de facilitar o teste. Pode haver um argumento para permitir isso em ambientes de armazenamento temporário, supondo que o acesso àqueles seja limitado da mesma forma que o acesso de produção. No entanto, permitir que todos os desenvolvedores acessem o conjunto de dados completo é definitivamente um "não-não" para o GDPR.

Existem soluções comerciais (como o Data Masker da RedGate Software) para obter um conjunto de dados e mascarar dados confidenciais como parte de uma operação ETL em outro banco de dados. Também vi a tentativa de organizações em construí-las.

Pode ser suficiente gerar conjuntos de dados fictícios para uso em ambientes de desenvolvimento, e existem ferramentas que facilitam essa geração. Será preciso garantir que os dados gerados sejam de tamanho e cardinalidade realísticos, caso contrário, os sistemas de desenvolvimento funcionarão de maneira muito diferente.

Qual dessas abordagens é a mais adequada será muito dependente da carga de trabalho. A estreita colaboração com as equipes de desenvolvimento será muito importante aqui.

Monitoramento e alerta

Os artigos 33 e 34 exigem que, em caso de violação de dados, seja notificado os titulares de dados afetados juntamente com a autoridade supervisora, haverá um desses para cada membro de estado da UE.

Obviamente, isso só é possível quando se souber que foi violado e, portanto, o monitoramento, a verificação de segurança e os alertas desempenharão seu papel aqui. Geralmente prefiro soluções de código aberto, mas no caso do monitoramento de segurança, recorrer a fornecedores é a opção inteligente, pois eles têm equipes inteiras trabalhando para manter as soluções atualizadas com detalhes das ameaças mais recentes.

Os firewalls de aplicações web (WAF) podem ajudar a reduzir os modos comuns de ataque a aplicativos Web e APIs, observando solicitações de impressões digitais desses tipos de ataques e bloqueando-os na origem. Por exemplo, um WAF pode verificar o conteúdo de cada solicitação HTTP, aplicando uma lista de expressões regulares que correspondem a ataques SQL injections conhecidos. No caso de um padrão corresponder, a solicitação será bloqueada em vez de ser encaminhada ao cluster de aplicativos por trás dela.

A varredura do tráfego de rede de saída pode ajudar a identificar violações de dados, ferramentas modernas inteligentes como Darktrace usam o aprendizado de máquina para criar um modelo de aparência normal, a fim de procurar anomalias, bem como correspondência de padrões em dados "pessoais", como cartões de crédito, códigos postais e endereços de e-mail. Ver muitos desses dados deixando a rede pode levantar uma bandeira vermelha para uma investigação mais aprofundada.

Dentro da rede, as ferramentas de detecção de intrusões podem ajudar a identificar quando os sistemas foram acessados por agentes mal-intencionados, verificando o tráfego da rede ou observando dados do registro. A AlertLogic e o ThreatStack têm ofertas neste espaço, e o AWS GuardDuty também oferece alguns desses recursos.

Outra boa higiene

Há algumas outras práticas de segurança que devem ser empregadas.

Tudo em trânsito e em repouso deveria ser encriptado. Não há realmente nenhuma razão para não fazer isso nos dias de hoje, e os fornecedores de nuvem também fornecem um pontapé para tornar isso mais fácil. É mais simples projetá-lo em uma infraestrutura desde o início do que atualizá-lo mais tarde, portanto, certifique-se de que seja uma consideração inicial do projeto.

O design da rede ainda é importante. Proteja o perímetro e use firewalls de host e grupos de segurança dentro da rede para limitar o acesso aos sistemas. Separe ferramentas de gerenciamento de outros sistemas e mantenha cada ambiente distinto entre si para evitar o vazamento de dados entre eles. Em alguns casos, pode ser apropriado separar diferentes classes de dados em bancos de dados distintos para limitar ainda mais seu acesso pela rede.

Não é preciso dizer, mas é necessário garantir que tenha um regime regular de correção de software, e não apenas para seus componentes de infraestrutura. Mantenha-se atualizado sobre as novas versões de suas dependências de aplicativos e empregue ferramentas como o Snyk em seu pipeline para obter alertas sobre vulnerabilidades de dependência antes que o código entre em produção. Incidentes de alto perfil, como a violação de dados da Experian, são muitas vezes o resultado de bibliotecas inseguras ainda em uso.

A segurança é tanto uma preocupação de desenvolvimento quanto operacional. Ferramentas como o OWASP Zap e o Gauntlt podem ajudar a procurar problemas de segurança no código do aplicativo antes de serem ativados e causarem problemas.

Considere quais serviços externos são utilizados e quais dados são passados para eles. Se estiver usando provedores de registro SaaS, por exemplo, esteja ciente de que pode-se estar transmitindo dados pessoais para fora de sua rede e que eles também tenham obrigações com seus titulares de dados.

Conclusão

O GDPR é um fato inevitável para quem trabalha com dados sobre cidadãos da UE. Cuidar desses dados pessoais é uma responsabilidade de toda a organização, mas na parte de operações da empresa, podemos fornecer muitas ferramentas de suporte para ajudar a lidar com as múltiplas facetas desse problema.

O GDPR não amplia substancialmente as disposições da Diretiva de Proteção de Dados, e muito do que descrevi aqui são boas práticas que já deveria estar seguindo. As penalidades por não cumprir com o GDPR são muito mais altas. É hora de parar de olhar para a segurança como uma obrigação e começar a transformar a privacidade de dados do cliente em realidade.

Sobre o autor

Jon Topper é CTO da The Scale Factory, uma empresa britânica de DevOps e consultoria de infraestrutura em nuvem. Trabalhou com a infraestrutura de hospedagem na web do Linux desde 1999, originalmente para os Servidores do ISP Designer e, em seguida, para a startup de tecnologia móvel Trutap. Desde 2009, Jon e a The Scale Factory trabalham para projetar, construir, dimensionar e operar a infraestrutura para uma variedade de tipos de carga de trabalho. Tem um interesse particular na arquitetura de sistemas e na criação de equipes de alto desempenho. É palestrante regular sobre DevOps e tópicos sobre infraestrutura em nuvem, tanto no Reino Unido quanto internacionalmente.