Dados reais em ambiente de teste: a cópia sem dono
Dado real de cliente só deveria entrar em teste como exceção autorizada, com dono e prazo. Cada cópia da produção é um segundo sistema com os mesmos dados e menos controles. O NIST pede limitar dado pessoal em teste e, sempre que possível, usar dado fictício; a LGPD pede o mínimo necessário.
Por que a cópia de produção vira um segundo sistema?
Porque ela nasce para destravar uma entrega e ninguém a desenha como sistema. Alguém precisa reproduzir um erro, pede um dump do banco e sobe tudo num ambiente de teste. O dado é o mesmo da produção. A proteção costuma ser menor.
Isto é observação de arquitetura, não resultado de estudo. A produção tem alguém que responde por ela, controle de acesso definido e uma rotina de cópia de segurança. A cópia de teste pode ter senha simples, acesso aberto a quem trabalha no projeto, inclusive terceiros, e nenhuma data para acabar. Quem criou a cópia sabe que ela existe. Em muitas empresas, ninguém tem a lista completa.
O risco, então, não é o teste. É o dado real morando num lugar que ninguém inventariou. Não há ferramenta que resolva isso sozinha: é uma decisão de arquitetura sobre onde o dado pode existir e quem responde por ele.
O que o NIST e a LGPD dizem sobre dado pessoal em teste?
O NIST pede limitar o dado pessoal usado em teste e preferir dado fictício. A LGPD não trata de ambiente de teste pelo nome, mas os princípios dela se aplicam a qualquer tratamento, inclusive esse.
O catálogo de controles NIST SP 800-53, revisão 5, traz o controle PM-25, sobre minimizar o dado pessoal usado em teste, treinamento e pesquisa. Ele pede que a organização tenha política e procedimentos para esse uso, limite a quantidade de dado pessoal, autorize o uso quando for necessário e revise a política. No texto de apoio, o NIST diz que usar dado pessoal em teste aumenta o risco de exposição ou mau uso e que, sempre que possível, as organizações devem usar dados fictícios. O SP 800-53 é referência técnica americana. Para uma empresa privada brasileira, é parâmetro e não obrigação.
Na LGPD, três trechos pesam aqui. O art. 6º traz a finalidade, que exige propósitos legítimos, específicos, explícitos e informados ao titular, e a necessidade, que limita o tratamento ao mínimo necessário. O art. 46 exige medidas de segurança aptas a proteger o dado de acessos não autorizados, e o § 2º diz que elas valem desde a concepção do produto ou serviço até a execução. O art. 48 obriga o controlador a comunicar a ANPD e o titular em caso de incidente com risco ou dano relevante.
Se o cliente deu o dado para ser atendido, usá-lo para testar o seu sistema é a mesma finalidade? Essa pergunta é jurídica, e a resposta para o seu caso é do seu jurídico ou do seu encarregado. O que a arquitetura pode fazer é tornar a pergunta desnecessária. Cada cópia a mais também entra no raio de qualquer incidente que o art. 48 mande comunicar.
O que aconteceu quando um snapshot de teste foi acessado?
A Imperva, empresa de segurança, contou o caso no próprio blog, em 2019. Na migração do banco de usuários do Cloud WAF para o AWS RDS, em 2017, foi criado um snapshot para testes. Uma instância interna, acessível pela internet, guardava uma chave de API da AWS. Um atacante comprometeu a instância, roubou a chave e a usou para acessar o snapshot.
Segundo a reconstrução publicada pelo Help Net Security, a Imperva recebeu o conjunto de dados em 20 de agosto de 2019, de um terceiro que pedia recompensa por falha (bug bounty). Os registros da empresa indicaram que a retirada dos dados aconteceu em outubro de 2018, cerca de dez meses antes (conta nossa). O SecurityWeek lista o que saiu: e-mails, senhas com hash e sal, chaves de API e chaves TLS de clientes do Cloud WAF com conta até 15 de setembro de 2017. A empresa disse que a retirada não resultou de vulnerabilidade do Cloud WAF e que bancos e snapshots de outros produtos não foram retirados.
O snapshot não vazou sozinho. Foi preciso uma instância exposta e uma chave dentro dela. Mas a cadeia só rendeu algo porque havia, fora da produção, uma cópia completa de dados de clientes esperando por quem tivesse a chave. Uma empresa de segurança chegou a esse ponto. É a razão para tratar a cópia como sistema, e não como arquivo.
Como isso aparece numa operação de PME?
Como uma exceção que ninguém registra. O exemplo a seguir é uma hipótese, não uma medição.
Imagine uma rede de clínicas com milhares de cadastros de pacientes e um parceiro externo que mantém o sistema de agendamento. Um erro de horário aparece só para alguns pacientes. Para reproduzi-lo, o desenvolvedor pede uma cópia do banco. A cópia vai para um servidor de homologação, outra para o notebook dele e uma terceira para uma pasta na nuvem, onde o colega que ajuda a investigar consegue abrir.
O erro é corrigido em duas semanas. As cópias ficam. Se isso se repetir três vezes por ano e cada cópia durar o ano inteiro, ao fim de dois anos haverá até seis cópias vivas do cadastro, em lugares com regras de acesso diferentes e nenhuma na lista da empresa. A conta é nossa e ilustrativa, mas o mecanismo é o do caso anterior: o dado não precisa ser roubado de onde está bem protegido, basta estar onde a proteção é menor.
No case Colo Saúde, a Yowpi começou por uma auditoria de segurança numa plataforma herdada que guardava dados de pacientes. Em plataforma herdada com dado de saúde, mapear onde estão as cópias faz parte desse tipo de trabalho.
O que fazer no lugar da cópia da produção?
Esta parte é leitura nossa, não conclusão das fontes. Cinco decisões, nesta ordem.
Primeiro, dado fictício por padrão. O banco de teste nasce de um script que gera dados com a mesma forma da produção (formatos, tamanhos, relações entre tabelas), e não de um dump. O ambiente de teste pode ser recriado a qualquer hora, e isso já elimina o problema do prazo.
Segundo, mascaramento quando a forma real importa. Se o erro só aparece com o dado como ele é, a transformação (trocar nome, documento e contato, preservando as relações) acontece antes de o dado sair da produção. Mascarar é decisão de projeto e precisa ser testada: se a máscara mantiver o suficiente para reidentificar a pessoa, ela não protege.
Terceiro, exceção com nome. Quando o dado real for indispensável, o pedido registra quem pediu, qual dado, até quando, onde fica e quem confirma a destruição. Sem prazo, a exceção vira regra.
Quarto, o mesmo controle de acesso da produção para o que contiver dado real. Se o ambiente tem dado real, ele tem as regras de acesso da produção, como as de controle de acessos: quem vê o quê. Chaves e senhas do ambiente de teste não ficam em instância que a internet alcança.
Quinto, um inventário. Uma lista de ambientes e de cópias, com dono e data de revisão. Para terceiros, o contrato deve dizer o que podem receber e o que fazem com o dado ao final, o ponto que tratamos em incidente no fornecedor: os três dias úteis são seus.
Perguntas frequentes
Dado fictício não reproduz os erros reais da minha operação. Como testo?
Em geral o erro depende da forma do dado, e não de quem é a pessoa: um campo vazio, um nome com acento, uma data no limite do mês. Descreva o caso sem o dado, gere registros sintéticos que o reproduzam e acrescente os casos extremos que a produção já mostrou. Quando só o dado como ele é reproduz o erro, use a exceção mascarada, com prazo.
Não tenho equipe qualificada para montar isso. Por onde começo?
Sem código: faça a lista de onde existem cópias do seu banco e quem as acessa, e crie uma regra simples, a de que nenhuma cópia sai da produção sem pedido registrado. O gerador de dados fictícios é um projeto pequeno, que um parceiro externo faz uma vez para o seu sistema e que a equipe passa a usar sempre.
Vale o esforço numa empresa do meu tamanho?
O tamanho da empresa não elimina a obrigação de proteger o dado nem a de comunicar um incidente (art. 46 e art. 48 da LGPD). O custo de limitar a cópia é uma regra e um script. O custo de não limitar é descobrir, no meio de um incidente, quantas cópias existiam e onde estavam. Este texto não traz estimativa de custo de incidente: as fontes que encontramos não separam empresas desse porte.
O próximo passo
Se você não sabe quantas cópias dos seus dados existem fora da produção, essa é uma das perguntas que o Diagnóstico de Arquitetura Operacional, uma conversa de 30 minutos, ajuda a responder. Se fizer sentido, fale com a Yowpi.
Cases relacionados
Reconheceu a sua operação neste artigo?
Agende o Diagnóstico de Arquitetura Operacional: 30 minutos para mapear onde está o gargalo da sua operação. Sem proposta na primeira conversa.
Agendar diagnóstico