De acordo com Simson L. Garfinkel no Laboratório de Tecnologia da Informação da Divisão de Acesso à Informação do NIST,
A desidentificação não é uma técnica única, mas uma coleção de abordagens, algoritmos e ferramentas que podem ser aplicadas a diferentes tipos de dados com diferentes níveis de eficácia. Em geral, a proteção da privacidade melhora à medida que técnicas de desidentificação mais agressivas são empregadas, mas menos utilidade permanece no conjunto de dados resultante.
-Desidentificação de informações pessoais, NISTIR 8053
Mascaramento de dados estáticos (SDM) é o termo reconhecido no setor para esses vários meios de desidentificar elementos de dados em repouso. Os elementos são normalmente valores de campo de coluna de banco de dados ou de arquivo simples que são considerados confidenciais; no setor de saúde, eles são chamados de identificadores de chave. Especificamente em risco estão as informações de identificação pessoal (PII), informações de saúde protegidas (PHI), números de contas primárias (PAN), segredos comerciais ou outros valores confidenciais.
O produto de segurança centrado em dados de “ponto de partida” IRI FieldShield — ou o produto IRI CoSort e a plataforma IRI Voracity que incluem os mesmos recursos — fornecem várias funções de descoberta de dados e SDM para várias fontes de dados. As funções de mascaramento por campo/coluna disponíveis incluem:
- vários algoritmos de criptografia (e descriptografia) compatíveis com NSA Suite B e FIPS, incluindo preservação de formato criptografia
- Hashing SHA-1 e SHA-2
- Desidentificação ASCII (codificação de bits)
- codificação e decodificação binária
- desfocagem ou agrupamento de dados (anonimização)
- geração ou seleção aleatória
- edição (ofuscação de caracteres)
- pseudônimo reversível e não reversível
- lógica de expressão personalizada (cálculo / embaralhamento)
- filtragem ou remoção de valor condicional/parcial (omissão)
- substituição de valor personalizado
- deslocamento de bytes e funções de string
- tokenização (para PCI)
Você também pode “rolar sua própria” função de mascaramento de dados externos. Isso permite que você chame uma rotina de nível de campo escrita personalizada em tempo de execução, em vez de uma rotina integrada.
A questão permanece, qual função de mascaramento devo usar (em cada item)? Isso depende das suas necessidades e regras de negócios, bem como das leis de privacidade de dados aplicáveis. Em um nível técnico, isso geralmente significa decidir como o texto cifrado resultante (dados mascarados) precisa aparecer, se precisa ser reversível ou exclusivo, quão seguro é e, possivelmente, que tipo de recursos de computação e tempo estão disponíveis para o processo . Vejamos esses critérios comuns de decisão em detalhes:
Aparência (realismo)
Os dados recém-mascarados devem se parecer mais ou menos com os dados originais? E quanto ao seu tamanho e formato? A pseudonimização e a criptografia com preservação de formato são as duas formas mais comuns de
manter a aparência de nomes próprios e números de conta ou telefone com dígitos alfa, respectivamente. Mas o mascaramento de substring (uma redação de campo parcial, por exemplo, XXX-XX-1234) pode ser bom para coisas como SSNs. Pense na persistência e exibição dos dados para análises, etc.
Relacionado a isso, a aparência e o realismo do texto cifrado também podem determinar a usabilidade dos resultados. Os destinos de aplicativos e tabelas de banco de dados (utilitário de carregamento) podem exigir que o formato dos dados não apenas esteja em conformidade com as estruturas predefinidas, mas continue trabalhando em consultas ou outros contextos operacionais downstream.
Em outras palavras, se dados mascarados que são bonitos e/ou dados funcionais são necessários, não vá para redação completa, randomização, hash ou criptografia direta (o que amplia e ofusca os resultados). Você pode conseguir fazer ajustes menores, como envelhecimento e manipulação de sub-string, mas considere o impacto dessas escolhas em seus outros critérios de decisão…
Reversibilidade (Reidentificação)
Precisa restaurar os dados originais? A resposta para isso pode depender se você está deixando os dados de origem sozinhos, como faria no mascaramento dinâmico de dados, ou quando está gravando os dados mascarados em novos destinos. Nesses casos, a resposta é não. Se a resposta for não, você ainda pode precisar de realismo, e nesses casos a pseudonimização irreversível pode ser sua melhor aposta. Se não for e a aparência não importa, vá com a redação do personagem. E se nenhum for verdadeiro, considere a exclusão total da coluna de origem do destino.
Quando a resposta for sim, as funções de mascaramento de dados IRI como criptografia, pseudonimização reversível ou tokenização, codificação ou re-ID ASCII (embaralhamento de bits) são indicadas. Em casos de uso mais avançados, você também pode precisar de reversão diferencial; ou seja, quando diferentes destinatários do mesmo destino estão autorizados a ver coisas diferentes no mesmo conjunto de dados. Nesses casos, chaves de criptografia privadas, scripts de trabalho de revelação específicos do usuário ou até mesmo aplicativos personalizados podem ser implantados.
Singularidade (Consistência)
O mesmo valor original sempre precisa ser substituído pelo mesmo, mas diferente, valor de substituição? Os dados serão unidos ou agrupados pelos valores de substituição? Nesse caso, o algoritmo de substituição escolhido deve produzir resultados únicos e repetíveis para preservar a integridade referencial, apesar do mascaramento ocorrido.
Isso pode ser obtido por meio de criptografia quando o mesmo algoritmo e senha (chave) são usados no mesmo texto simples. Os assistentes de classificação de dados e proteção entre tabelas no IRI Workbench IDE para FieldShield, Voracity, etc. facilitam isso por meio da aplicação de tabelas cruzadas (ou mais globais) da regra de mascaramento correspondente. Dessa forma, o mesmo valor de texto simples sempre obtém o mesmo resultado de texto cifrado, independentemente de sua localização.
A pseudonimização é mais complicada aqui, no entanto, devido à falta de nomes de substituição exclusivos, nomes originais duplicados e alterações ( inserções, atualizações ou exclusões) para os valores originais em tabelas ou arquivos de origem. A IRI abordou a questão da pseudonimização consistente entre tabelas neste exemplo de fluxo de trabalho Voracity. Força (Segurança)
Uma olhada nos algoritmos dentro de cada função pode ajudá-lo a determinar sua “crackability” relativa e avaliá-la em relação a outras considerações de texto cifrado, como aparência e velocidade. Por exemplo, a função AES256 da IRI é mais forte que a opção AES128, SHA2 é mais forte que SHA1 e todas são mais fortes que as funções de codificação/decodificação base64 e de-ID/re-ID ASCII.
Por definição, funções reversíveis são tipicamente mais fracas do que aquelas que não podem ser revertidas. Por exemplo, o método de pseudonimização irreversível (conjunto de pesquisa estrangeira) do IRI é mais seguro do que seu método de pseudonimização reversível (conjunto original embaralhado). Dito isso, o algoritmo de criptografia AES-256 também pode ser muito difícil de decifrar quando a chave é perdida.
A segurança ainda mais forte é, obviamente, a omissão, seguida pela ofuscação de caracteres (edição), que são irreversíveis. Mas a desvantagem é a falta de usabilidade. No contexto de porto seguro HIPAA, a remoção de identificadores de chave está em conformidade. No entanto, se você precisar usar qualquer parte dos dados de origem para análise, pesquisa, marketing ou demonstração, precisará de uma função de mascaramento e de um especialista para determinar (e certificar) que sua(s) técnica(s) carregam um baixo índice estatístico probabilidade de reidentificação. Enquanto estamos no assunto de desidentificação HIPAA, lembre-se de que também pode haver risco associado aos chamados quase identificadores (como CEP e idade). Esses valores podem ser usados em conjunto com outros conjuntos de dados para estabelecer uma trilha de reidentificação e, portanto, também vale a pena mascarar em muitos casos; se e como estão sujeitos a essas mesmas considerações.
Computação (Desempenho)
Uma das coisas boas sobre a abordagem de mascaramento de dados - mesmo quando algoritmos de criptografia de computação intensiva estão envolvidos - é que sua sobrecarga em relação à criptografia ampla (de uma rede inteira, banco de dados, arquivo/sistema, unidade de disco) é muito menor. Somente os elementos de dados (valores de coluna) que você designar para proteção precisam ser ingeridos, processados e retornados pela função de mascaramento.
Em geral, quanto mais complexo (e mais forte) o algoritmo, mais tempo levará para ser aplicado. As velocidades de mascaramento de dados também dependerão do número de funções aplicadas, do número de colunas e linhas do banco de dados, do número de restrições de pesquisa a serem respeitadas no processo (para integridade referencial), largura de banda da rede, RAM, E/S, processos simultâneos e em breve. O gráfico não científico a seguir detalha a maioria dos atributos descritos acima para referência conveniente, para algumas (mas não todas!) categorias funcionais de mascaramento de dados IRI com suporte e apenas em termos geralmente relativos. Escusado será dizer que a IRI se isenta de qualquer garantia de adequação ou responsabilidade para este gráfico!
Funções de mascaramento de dados IRI (no FieldShield e Voracity)
Se você usa funções de mascaramento de dados IRI integradas ou funções personalizadas que você define, a ideia é aplicá-las com base em suas regras de negócios para linhas ou colunas específicas e/ou entre tabelas. E você fará isso por meio de regras de mascaramento de dados que você pode definir, armazenar e reutilizar. Também é possível (e preferível) aplicar essas funções de mascaramento de dados a dados classificados automaticamente como regras para conveniência e consistência. E você pode aproveitar vários deles em aplicativos de mascaramento de dados dinâmicos por meio de uma chamada de API.
Os usuários do FieldShield (ou Voracity) podem criar, executar e gerenciar seus trabalhos de mascaramento de dados em uma GUI gratuita de última geração, construída no Eclipse.™ Ou podem editar e executar scripts 4GL compatíveis e autodocumentados definindo seus dados de origem/destino e funções de mascaramento e execute esses scripts na linha de comando.
Para obter mais informações, consulte https://www.iri.com/solutions/data-masking ou entre em contato com seu representante IRI.
