Boa sorte em sua jornada de Governança Contínua de Dados. Em um mundo onde dados naufragam mais do que o desejado, o mascaramento ainda pode servir como o "colete salva-vidas da privacidade". Considere usar essas recomendações para que seus dados tornem-se tão disfarçados que nem eles mesmos se reconheçam. Em caso de dúvida, necessidade com o assunto, com modelos de governança, ferramentas, integrações ou indicadores, contacte a OmniSec.

Mascaramento de dados nacional e sua importância

Independentemente do setor de atuação da sua empresa ou mesmo do regramento escolhido para governar e proteger dados e informações, existe preocupações e riscos de mercado que, em teoria, deveria estar no mapa de risco (ou pelo menos na lista de preocupações) das empresas, dos DPOs ou pelo menos de todas as lideranças responsáveis pela sustentação deste tema tão relevante e, por vezes, negligenciado até o momento em que um vazamento, exposição, compartilhamento errôneo ou mesmo um incidente materializado, torna público o quão inseguro, ingerenciável e desprotegido estes dados estavam.

Alguns frameworks listam explicitamente a necessidade de mascaramento, mas é fato que, nem todos os manipuladores e usuários acabam tendo acesso a esse tipo de informação. Em alguns casos, nem mesmo a área de Compliance, de Dados ou mesmo Segurança promove a visibilidade e conscientização proporcional a importância do tema. A única certeza universal é: quanto maior a quantidade, fonte e variedade dos dados, normalmente menor a aderência, o etiquetamento, a rotulagem ou a catalogação promovida pela instituição.

Mas, precisamos mesmo? Sim, preferencialmente um modelo nacional (ainda inexistente) que padronize as regras entre instituições diversas - independente de setor, porte e nicho. Observe o que dizem alguns regramentos/leis e, avalie se há divergências encontradas e propagadas por instituições que deveriam ser referência no Brasil.

• ISO-27001/27002 - 8.11 Mascaramento de Dados

  Convém que o mascaramento de dados seja usado de acordo com a política específica, aos requisitos relacionados e requisitos de negócios, levando em consideração a legislação aplicável.

• PCI-DSS 4 - Requisito 3: Proteja os Dados da Conta Armazenados

  Métodos de proteção como criptografia, truncamento, mascaramento e hashing são componentes essenciais da proteção de dados da conta. A abordagem de mascaramento deve sempre exibir apenas o número de dígitos necessários para executar uma função de negócios específica do ecossistema de cartões.

• PPSI - Privacidade em banco de dados e aplicações

  "A proteção de microdados por meio de mascaramento de dados e síntese de dados", aparece na seção de Banco de Dados e "Introduzir o mascaramento do campo de entrada para entradas que contêm dados sensíveis em aplicações" na seção de Aplicações. Nenhum outro contexto foi encontrado até a data da publicação - caso o leitor tenha identificado outras abordagens, informe-nos para atualizarmos esta redação.

• NIST- NIST Special Publication 800-188 - De-Identifying Government Datasets

  "Ferramentas de mascaramento de dados são programas que podem remover ou substituir campos designados em um conjunto de dados enquanto mantêm suas relações, podendo ser usadas para remover identificadores diretos, porém, não conseguem identificar ou modificar quase-identificadores de maneira consistente a partir de uma política de privacidade ou análise de risco."
  Deve-se considerar a consulta adicional a NIST SP 800-122 - Guide to Protecting the Confidentiality of Personally Identifiable Information, NIST SP 800-53 - Security and Privacy Controls for Information Systems and Organizations e NIST SP 800-38G - Recommendation for Block Cipher Modes of Operation: Methods for Format-Preserving Encryption que tratam em profundidade diversas táticas, abordagens e contextos específicos ao tema.

• CIS - Controle 3: Proteção de Dados

  Proteção de Dados é um Controle CIS que pode ajudar a proteger uma infinidade de tipos de informações em uma rede corporativa, incluindo PII e outros dados pessoais. Sem essas medidas de segurança, grande parte das informações pessoais e de clientes que as empresas mantêm estariam em risco de exposição não autorizada.

• LGPD - Lei Geral de Proteção de Dados Pessoais

  Art.2, IV - a inviolabilidade da intimidade, da honra e da imagem.

  Art.5, XVII - relatório de impacto à proteção de dados pessoais: documentação do controlador que contém a descrição dos processos de tratamento de dados pessoais que podem gerar riscos às liberdades civis e aos direitos fundamentais, bem como medidas, salvaguardas e mecanismos de mitigação de risco.

  Art.6, X - responsabilização e prestação de contas: demonstração, pelo agente, da adoção de medidas eficazes e capazes de comprovar a observância e o cumprimento das normas de proteção de dados pessoais e, inclusive, da eficácia dessas medidas.

  Art.10, § 3º A autoridade nacional poderá dispor sobre padrões e técnicas utilizados em processos de anonimização e realizar verificações acerca de sua segurança, ouvido o Conselho Nacional de Proteção de Dados Pessoais.

  Art.10, § 3º A autoridade nacional poderá solicitar ao controlador relatório de impacto à proteção de dados pessoais, quando o tratamento tiver como fundamento seu interesse legítimo, observados os segredos comercial e industrial.

  Art.12, § 3º A autoridade nacional poderá dispor sobre padrões e técnicas utilizados em processos de anonimização e realizar verificações acerca de sua segurança, ouvido o Conselho Nacional de Proteção de Dados Pessoais.

  Art.25 - Os dados deverão ser mantidos em formato interoperável e estruturado para o uso compartilhado, com vistas à execução de políticas públicas, à prestação de serviços públicos, à descentralização da atividade pública e à disseminação e ao acesso das informações pelo público em geral.

  Art.32 - A autoridade nacional poderá solicitar a agentes do Poder Público a publicação de relatórios de impacto à proteção de dados pessoais e sugerir a adoção de padrões e de boas práticas para os tratamentos de dados pessoais pelo Poder Público.

  Art.42 - O controlador ou o operador que, em razão do exercício de atividade de tratamento de dados pessoais, causar a outrem dano patrimonial, moral, individual ou coletivo, em violação à legislação de proteção de dados pessoais, é obrigado a repará-lo.

  Art.50, § 2º, I, a) demonstre o comprometimento do controlador em adotar processos e políticas internas que assegurem o cumprimento, de forma abrangente, de normas e boas práticas relativas à proteção de dados pessoais.

• LCP 105 - Lei do Sigilo Bancário e Fiscal

  Art. 2o O dever de sigilo é extensivo ao Banco Central do Brasil, em relação às operações que realizar e às informações que obtiver no exercício de suas atribuições.

  § 5o O dever de sigilo de que trata esta Lei Complementar estende-se aos órgãos fiscalizadores mencionados no § 4o e a seus agentes

  Art. 10. A quebra de sigilo, fora das hipóteses autorizadas nesta Lei Complementar, constitui crime e sujeita os responsáveis à pena de reclusão, de um a quatro anos e multa, aplicando-se, no que couber, o Código Penal, sem prejuízo de outras sanções cabíveis.

  Art. 11. O servidor público que utilizar ou viabilizar a utilização de qualquer informação obtida em decorrência da quebra de sigilo de que trata esta Lei Complementar responde pessoal e diretamente pelos danos decorrentes, sem prejuízo da responsabilidade objetiva da entidade pública, quando comprovado que o servidor agiu de acordo com orientação oficial.
  

Observe que existem diversas redações que tipificam direta e indiretamente o tema, de forma que anormalidades, incidentes (naturais ou indesejados) e outros eventos não previstos podem, adicionalmente aos problemas diretamente ocorridos, incorrer em riscos e efeitos colaterais de maiores proporções ou impacto.

Existem diferentes abordagens de mascaramento de dados, cada qual com suas vantagens, desvantagens, aplicabilidade e estes são essenciais para garantir que os dados mascarados sejam realistas, ora irreversíveis e flexíveis o suficiente para lidar com diversas fontes de dados integradas aos fluxos de trabalhos existentes, sejam para atividades cotidianas do usuário, SDLC/SecDevOps ou mesmo para amparar algum modelo específico de Proteção, Governança de Dados e Privacidade. Infelizmente, como poderemos avaliar, esses padrões ainda são bem rudimentares em solo brasileiro, seja em instituições maiores, associações de classe (que deveriam se engajar com o tema) ou mesmo em entidades governamentais que poderiam (deveriam?) prover recomendações nacionais setorizadas conforme a eCiber preconiza em "é a orientação manifesta do Governo federal à sociedade brasileira sobre as principais ações por ele pretendidas, em termos nacionais e internacionais, na área de segurança cibernética") via LGPD, ou melhor ainda, através de algum regramento que não possuísse orientação siliar e fosse independente de nicho (sem preferência aos chamados IFCs - setores de Infraestruturas Críticas que, mais segregam as demandas de Segurança do que criam sinergia).

Métodos de mascaramento mais comuns

Importante mencionar que, ao contrário da criptografia (assunto para outro post), boa parte das técnicas de mascaramento podem implicar num processo irreversível de proteção de dados que garante a conformidade com regulamentos de proteção de dados, mantendo ainda as características originais do conjunto de dados não mascarado. Veja alguns métodos, requisitos e técnicas sobre.

Informações extras

• Os contextos marcados com * na tabela anterior, mesmo fazendo parte de grupo classificatório diferente de DP (Dados Pessoais), dependendo do tipo de arranjo e informações complementares, podem se tornar Dados Pessoais (DP). Avalie seu preset de forma completa.

• Importante considerar todas essas recomendações para DaR (Data at Rest(, DiT (Data in Transit) e DiU (Data in Use).

• A anonimização altera irreversivelmente o DP de tal forma que o titular de DP não pode mais ser identificado direta ou indiretamente. A pseudonimização substitui as informações de identificação por um pseudônimo. O conhecimento do algoritmo usado para realizar a pseudonimização permite pelo menos alguma forma de identificação do titular de DP. Convém, portanto, que essas “informações adicionais” sejam mantidas separadas e protegidas.

• Embora a pseudonimização seja, portanto, mais fraca que a anonimização, os conjuntos de dados pseudononimizados podem ser mais úteis em pesquisas estatísticas. Controles adicionais sobre a proteção de DP em nuvens públicas são fornecidos na ABNT NBR ISO/IEC 27018 com informações adicionais sobre técnicas de desidentificação disponíveis na ISO/IEC 20889.

• Funções hash podem ser usadas para anonimizar porém, para evitar ataques de enumeração, convém que sejam sempre combinados com uma função de salto (salt).

• Sempre que possível, procure adicionar algum "identificador único" com dados compartilhados com seus clientes, fornecedores e parceiros. O recurso pode ser útil futuramente para ajudar na identificação de vazamentos ou incidentes envolvendo massas de dados.

Requisitos de mascaramento a serem atendidos

Os requisitos são essenciais para termos certeza que o objetivo do mascaramento será completamente atendido, sem abrir mão da preservação das características originais, integridade, completude, possibilidades de reprodução e/ou simulação esperadas.

Técnicas de mascaramento disponíveis

A implementação eficaz das técnicas, permite equilibrar segurança, desempenho e usabilidade dos sistemas. Ajudam a proteger informações previamente classificadas, substituindo, ocultando ou transformando dados reais em valores fictícios ou ofuscados, permitindo sua utilização em ambientes de testes, simulados, em banco de dados não verdadeiros, provas de conceito sem deixar de atender o nível de segurança e privacidade previsto em diversas regulamentações, minimizando inclusive o impacto e o risco em caso de vazamento e/ou acessos indevidos.

Exemplos de mascaramento de dados no Brasil

A amplitude dos casos de uso do mascaramento de dados deve ser considerada antes do compartilhamento de dados de terceiros e com parceiros, em bancos de dados compartilhados com desenvolvimento, controle de qualidade, antes de adicionar um conjunto de dados a um "data lake”, a um ambiente de bigdata ou mesmo antes de iniciar operações de extração, transformação e apresentação (ETL) de dados.

Para ajudar manipuladores de dados e informações (desenvolvedores, operadores, processadores, data stewards, data owners, classificadores, auditorias, agentes de privacidade…), a OmniSec recomenda que seja considerado e adotado (onde a tecnologia, processos e componentes auxiliares permitirem) as seguintes sugestões de mascaramento. São exemplos não exaustivos e, conforme informado, infelizmente ainda sem uma padronização nacional comum e conhecida (ver próxima seção). As recomendações foram construídas considerando os casos mais utilizados e praticados em solo nacional em projetos reais de Governança de Dados.

Discrepâncias em nível nacional

A ausência de um padrão "de-facto" nacional, torna mais complexo a condução do assunto, não fornece um "norte brasileiro" para atributos e conteúdos de interesse de segurança nacional como colabora com "criminosos e vazadores de dados" uma vez que, a partir de mais 1+ vazamento, esses "colecionadores de dados" conseguem realizar agrupamentos que enriquecem ainda mais suas bases ou pior, tornam completos dados que antes eram parciais. Como assim?

Considere que a Instituição-A utiliza para mascaramento a recomendação deste artigo para CPF: xxx.456.789-xx.
Outra Instituição-B utiliza modelo diferente, como 123.xxx.xxx-30.

Caso ocorra vazamento em ambas as instituições (ou outros atores menores de mercado que utilizam regras diferentes), é esperado que o "colecionador de dados" entre em ação. O mesmo déficit existe para todos os demais atributos da tabela anterior o que torna, cada vez mais complicado o processo de validação da criação de novas contas, cadastros e onboardings digitais (um dos maiores problemas atuais e destaque em fraudes de diversos tipos).

As amostras reais abaixo foram desfiguradas, apenas com o intuito de apresentar, a partir de alguns players relevantes de mercado que, o assunto ainda precisa de atenção e a orquestração central por alguma agência/instituição/associação é, além de tardia, fortemente desejada.