Este artigo demonstra o uso do IRI DarkShield para identificar e corrigir (mascarar) informações de identificação pessoal (PII) e outros dados confidenciais nos bancos de dados MongoDB, Cassandra e Elasticsearch. Embora essas etapas se concentrem principalmente em localizar e proteger dados em coleções do MongoDB, as mesmas etapas também podem ser usadas para dados em tabelas do Cassandra. Veja este artigo no Elasticsearch também.
Observe que este artigo representa o quarto método que o IRI suporta para mascarar dados no MongoDB e o segundo método para o Cassandra. Esses métodos anteriores e ainda compatíveis dependem da descoberta e desidentificação de dados estruturados por meio do IRI FieldShield, enquanto o método DarkShield oferece suporte a dados textuais em coleções estruturadas ou não estruturadas. Embora DarkShield e FieldShield sejam produtos independentes de mascaramento de dados IRI, ambos estão incluídos na plataforma de gerenciamento de dados IRI Voracity.
A abordagem mais recente usa alguns elementos de Classificação de dados , um paradigma de catalogação de dados integrado para definir os métodos de busca usados para encontrar PII independentemente da fonte dos dados. Embora este artigo forneça uma pequena introdução à Classificação de dados durante a Etapa 1, pode ser útil ler como a Classificação de dados se encaixa em nossa abordagem unificada para realizar pesquisas. Para obter mais informações sobre Classificação de dados no front-end do IRI Workbench para DarkShield e outros, leia este artigo antes de continuar.
A identificação e correção de PII usando IRI DarkShield envolve 4 etapas gerais:
Etapa (opcional) - Registre sua(s) fonte(s) de dados
Nesta etapa (opcional), as fontes de dados de um banco de dados Mongo, keyspace Cassandra ou cluster Elasticsearch são registradas. Isso permite que as fontes de dados sejam reutilizáveis. Como resultado, esta etapa é opcional se a fonte de dados desejada já existir no registro ou se você planeja defini-la no assistente.
Etapa 1 – Especificar parâmetros de pesquisa
Aqui todos os aspectos de uma pesquisa são escolhidos. Primeiro, uma coleção/tabela de origem e destino é configurada com base na conexão de dados especificada no registro ou criada no assistente. Em seguida, você pode especificar os critérios de pesquisa e correção para seus dados usando os Search Matchers, os tipos de informações a serem procurados e como essas informações devem ser corrigidas. O resultado desta etapa é uma .pesquisa Arquivo.
Etapa 2 – Faça uma pesquisa
Uma pesquisa pode ser executada a partir de um .search Arquivo. O resultado é um .darkdata arquivo anotando qualquer PII identificada.
Etapa 3 – Remediação (mascaramento)
A correção pode ser feita a partir de um .darkdata Arquivo. Qualquer PII identificada será corrigida da maneira especificada durante a criação da pesquisa.
Etapa (opcional) - Registre suas fontes de dados
Como uma etapa de pré-requisito, você precisará registrar as conexões com suas fontes de dados online (e destinos) no Registro de conexão de URL, localizado em Preferências> IRI> Registro de conexão de URL diálogo no IRI Workbench.
Todas as conexões de URL, incluindo strings de conexão de URI para MongoDB, Cassandra e Elasticsearch, podem ser salvas. Isso permite que os URLs, credenciais de autenticação e quaisquer parâmetros adicionais sejam salvos e armazenados pelo IRI Workbench para uso futuro.
Etapa 1 – Especificar parâmetros de pesquisa (criar arquivo .Search)
No IRI Workbench IDE para DarkShield, selecione New Database Discovery Job no DarkShield Menu. Selecione uma pasta de projeto e insira um nome para o trabalho:
Especificando uma origem e um destino
Quaisquer URLs Mongo, Cassandra ou Elasticsearch que foram previamente criadas e salvas no registro podem ser acessadas a partir do URI suspenso para os seletores Origem e Destino. O nome da coleção MongoDB correspondente, tabela Cassandra ou índice Elasticsearch também terá que ser inserido:
Um novo URI também pode ser criado pressionando o botão Novo botão. Isso abrirá a caixa de diálogo Detalhes da conexão de URL. Insira um nome para a conexão, selecione o esquema desejado, insira o host e insira o banco de dados. Se nenhuma porta estiver presente, a porta padrão para o esquema será assumida.
Um nome de usuário e senha também podem ser fornecidos se o banco de dados exigir autorização. Quaisquer novas conexões de URL serão salvas no Registro de Conexão de URL e podem ser reutilizadas como destino.
Depois que uma origem é especificada, você pode continuar para a próxima página para selecionar ou criar um URI de destino. O esquema do URI de destino será limitado ao URI de origem selecionado, portanto, uma origem do MongoDB só pode ser enviada para outro destino do MongoDB e, da mesma forma, para Cassandra ou Elasticsearch.
Quando um trabalho de mascaramento é executado, todas as linhas na origem serão anexadas ao destino e todas as linhas com chaves correspondentes serão substituídas. Para Cassandra, certifique-se de que o esquema da tabela de destino seja compatível com os dados da tabela de origem.
Adicionando correspondências de pesquisa
Depois que uma origem e um destino forem especificados, você poderá ir para a próxima página para adicionar correspondências de pesquisa. Selecione um local de biblioteca contendo quaisquer bibliotecas de padrões ou regras que você deseja usar e clique em Adicionar para adicionar um novo correspondente de pesquisa.
KeyNameMatcher
O primeiro Search Matcher que criaremos será usado para corresponder todo o valor correspondente a qualquer chave “name” localizada em estruturas json aninhadas arbitrariamente e aplicar um algoritmo de Criptografia de Preservação de Formato para mascará-lo. Podemos conseguir isso criando um filtro de caminho JSON “$..name”. Mais informações sobre caminhos JSON podem ser encontradas aqui.
Como as coleções do MongoDB, as tabelas do Cassandra e os índices do Elasticsearch são analisados pelo DarkShield como documentos json, o filtro pode ser aplicado a ambos para mascarar qualquer valor correspondente a qualquer chave de “nome”.
Para corresponder ao conteúdo dos dados filtrados, precisamos criar uma nova Classe de dados . Uma classe de dados representa PII e os correspondentes associados usados para identificá-lo. Esses correspondentes podem incluir qualquer combinação de:
- Padrões de Expressão Regular
- Definir pesquisas de dicionário de arquivos
- Modelos de reconhecimento de entidade nomeada
- Correspondências de caixa delimitadora (somente imagens)
- Reconhecimento Facial (somente imagens)
Você pode definir classes de dados dentro do assistente ou abrindo o Classes e grupos de dados página nas Preferências de IRI . As classes de dados definidas nas preferências podem ser usadas no FieldShield e no DarkShield para outras fontes de dados, incluindo dados estruturados e não estruturados.
Podemos criar um TUDO associado Classe de dados para este matcher que corresponderá a todo o conteúdo do valor, pois estamos razoavelmente certos de que tudo o que encontraremos nos valores são nomes. Você pode usar pesquisas de arquivo de conjunto contendo um dicionário de nomes se não tiver certeza do conteúdo de suas chaves de “nome” ou se desejar mascarar apenas um subconjunto de nomes.
Para o Nome da regra campo do KeyNameMatcher, podemos selecionar uma regra de dados existente no local da biblioteca que selecionamos ou criar uma nova regra que use a criptografia de preservação de formato (FPE), por exemplo:
Para criar uma regra do FPE, clique em Criar ao lado do Nome da regra campo, selecione Funções de criptografia ou descriptografia do Assistente de regra de dados que aparece:
Especifique uma senha apropriada para servir como sua chave de criptografia/descriptografia, que pode ser uma string explícita, uma variável de ambiente ou o nome de um arquivo seguro que contém essa string.
Correspondência de e-mails
Depois de terminar a caixa de diálogo anterior e criar nosso novo KeyNameMatcher, podemos adicionar outro Search Matcher para endereços de e-mail. Basta clicar em Adicionar para criar outro Search Matcher para adicionar à lista.
A Bancada de Trabalho IRI vem pré-carregado com um EMAIL Classe de dados que pode ser selecionada clicando em Procurar ao lado do Nome da classe de dados campo e selecionando EMAIL no menu suspenso.
Para a regra de dados, você pode selecionar a regra do FPE que criou para o correspondente de pesquisa anterior clicando em Procurar ao lado do Nome da regra campo ou crie um novo com uma das várias funções de mascaramento disponíveis. Eu criei uma função de redação de dados simples que substitui todo o e-mail por asteriscos.
Seu Search Matcher agora pode ser adicionado à lista clicando em OK.
Combinador de Nomes
Nosso último Search Matcher será usado para encontrar nomes em texto de fluxo livre. Para isso, usaremos o Reconhecimento de Entidade Nomeada (NER) para encontrar nomes usando o contexto da frase. Para começar, precisamos clicar em Adicionar para criar um novo correspondente de pesquisa e criar uma nova classe de dados chamada NAMES_NER:
Para criar um NAMES_NER Data Class, primeiro precisamos baixar o modelo Person Name Finder, en-ner-person.bin , do repositório openNLP sourceforge. Em seguida, clique em Adicionar para adicionar um novo correspondente, selecione Modelo NER da lista suspensa. Clique em Procurar e navegue até o local do modelo baixado; por exemplo:
Depois de criar a nova classe de dados, clique em OK e selecione a regra de dados do FPE que você definiu anteriormente para concluir a criação do Search Matcher:
Observe que nosso NamesMatcher e KeyNameMatcher pode ter correspondências sobrepostas. Se isso acontecer, o DarkShield seleciona a correspondência mais longa disponível e remove quaisquer outras correspondências sobrepostas. Dessa forma, você não precisa se preocupar com o DarkShield aplicando uma função de mascaramento em valores já mascarados.
Depois de adicionar todos os correspondentes desejados, clique em concluir para gerar um .search Arquivo.
O .search gerado arquivo pode ser inspecionado para mostrar os detalhes sobre uma pesquisa. Isso inclui os URIs de origem e destino e informações sobre todos os correspondentes.
Etapa 2 – Realizar uma pesquisa (criar um .Darkdata Arquivo)
Concluindo o Trabalho de descoberta de dados escuros assistente gera uma nova .pesquisa arquivo de configuração. Esse arquivo contém as opções que selecionamos, incluindo a origem e o destino de nossos dados, e os Search Matchers que serão usados para marcar PII para descoberta, entrega, exclusão e/ou desidentificação.
Para iniciar a pesquisa, clique com o botão direito do mouse em .search arquivo, selecione Executar como e escolha IRI Search Job ou Pesquisar e corrigir trabalho de IRI .
Pesquisar apenas realizará uma pesquisa, enquanto Pesquisar e corrigir também tentará mascarar (ou excluir) quaisquer dados identificados. Ambos irão gerar um .darkdata arquivo identificando quaisquer dados de interesse.
A fonte que usei foi preenchida com valores gerados aleatoriamente, então não há mal nenhum em compartilhar o .darkdata gerado arquivo aqui. No entanto, ao lidar com informações realmente confidenciais, os usuários devem garantir que o .darkdata arquivo não é exposto e é arquivado ou excluído com segurança após a conclusão da correção para evitar vazamento de PII. O IRI adicionará uma opção de quarentena para armazenar o .darkdata arquivo e artefatos de pesquisa correspondentes em um local seguro; entre em contato com [email protected] para obter detalhes sobre esse recurso planejado.
Etapa 3 – Correção (mascaramento)
Novamente, o mascaramento ou exclusão de dados pode ser realizado durante as operações de pesquisa por meio do Pesquisar e corrigir opção no assistente Dark Data Discovery. No entanto, se você deseja apenas examinar as informações identificadas e corrigi-las posteriormente, execute os trabalhos de mascaramento do .darkdata arquivo produzido na Pesquisa (Passo 2) desta forma:
Clique com o botão direito em .darkdata arquivo, passe o mouse sobre Executar como e clique em IRI Corrigir trabalho . Depois que o trabalho for executado, os dados corrigidos deverão aparecer no banco de dados de destino.
Aqui está um exemplo mostrando um antes e depois de uma pequena coleção de banco de dados MongoDB usando o prompt de comando do Workbench para acessar o servidor Mongo local:
CONCLUSÃO
Neste artigo, demonstramos o novo recurso IRI para acessar dados não estruturados em bancos de dados Mongo, keyspaces Cassandra e clusters Elasticsearch usando vários Search Matchers no IRI DarkShield. Você pode verificar o .darkdata gerado model para ver os resultados da pesquisa que foram encontrados e corrigidos e verifique seu banco de dados para ver as tabelas/coleções atualizadas.
- Se as PII estiverem incorporadas em objetos binários em suas coleções MongoDB, Cassandra, Elasticsearch, podemos ajudar a automatizar sua extração para arquivos autônomos para operações de pesquisa/máscara do DarkShield e sua reimportação.
- O IRI Workbench IDE, integrado ao Eclipse™, faz front-end de todos os FieldShield, DarkShield e mascaramento de dados relacionados, além de recursos mais amplos de manipulação de dados, na plataforma IRI Voracity.
- O Registro de Conexão de URL é usado para configurar e salvar fontes de dados baseadas em URL usadas em operações de pesquisa/máscara DarkShield e CoSort/SortCL (Voracity) ETL; por exemplo, HDFS, Kafka, buckets S3, MongoDB, S/FTP. Esse registro é semelhante, mas não idêntico, ao registro de conexão de dados no IRI Workbench para origens de bancos de dados relacionais em que os DSNs ODBC são conectados aos perfis de conexão JDBC correspondentes para o benefício dos assistentes de trabalho que aproveitam ambas as conexões.
- Um Search Matcher é uma associação entre uma Classe de dados , que é usado para definir o método de pesquisa para localizar e classificar PII e uma Regra de dados que será aplicado a qualquer instância da classe de dados encontrada na coleção ou tabela. Além disso, os Search Matchers permitem definir filtros que podem ser usados para reduzir o escopo da pesquisa. Isso é particularmente útil em coleções do Mongo, tabelas do Cassandra e índices do Elasticsearch porque o nome da chave pode ser indicativo do PII armazenado no valor correspondente.
