O "Novo trabalho de proteção de várias tabelas ..." assistente no IRI Workbench descrito neste artigo é uma das maneiras pelas quais os usuários do produto IRI FieldShield (ou plataforma IRI Voracity) podem mascarar automaticamente informações de identificação pessoal (PII) em colunas de banco de dados que fazem parte de um relacionamento de chave estrangeira e, assim, preservar a integridade referencial entre as mesas. Isso garante que os registros permaneçam vinculados mesmo depois de serem desidentificados.

Observe que, desde 2018, um método mais novo e robusto para alcançar esse mesmo resultado foi publicado em nosso artigo sobre classificação, descoberta e mascaramento de várias tabelas de banco de dados aqui e é demonstrado nos vídeos do Youtube 1, 2, 3, 5 e 7 aqui.

Mas neste assistente original e ainda popular, os usuários preservam a integridade referencial definindo regras de mascaramento em nível de campo que são automaticamente e consistentemente aplicadas a colunas com nomes semelhantes. Qualquer uma das 14 categorias de funções de mascaramento de dados  disponíveis para usuários do FieldShield, incluindo criptografia, pseudonimização e redação, pode ser aplicada com base nessas regras.

Este assistente é mais apropriado para usuários que mascaram e mapeiam várias tabelas em um esquema que nem todas contêm PII. Por exemplo, a IRI recomendaria este assistente se você tiver 50 tabelas e precisar mover todas elas para um ambiente inferior, mas tiver apenas 20 das tabelas contendo PII para mascarar consistentemente (as outras 30 não têm PII).

Este exemplo usa apenas três tabelas Oracle — Departments, Employees e Job_History — para mostrar como esse assistente funciona. Quando as tabelas foram originalmente projetadas, o Número de Previdência Social do Funcionário foi usado para sua identificação. Isso cria um risco de segurança ao executar qualquer relatório que exiba o campo ID.





O diagrama E-R acima para essas tabelas e a consulta SQL e seus resultados abaixo são mostrados em várias visualizações da GUI do IRI Workbench para FieldShield. Veja este artigo sobre:​​Criação de ERD no IRI Workbench. A consulta juntou informações sobre funcionários, gerentes e departamentos, mas expõe valores de número de seguro social (SSN) nas colunas SID do funcionário e SID do gerente. Consulte este artigo sobre como codificar e executar tarefas SQL no IRI Workbench.





Usando o Trabalho de proteção de várias tabelas do FieldShield assistente, esses campos podem ser criptografados (ou de outra forma desidentificados) para que os SSNs reais sejam mascarados nas tabelas e consultas subsequentes. A integridade referencial é mantida porque a mesma criptografia é aplicada a todas as tabelas usando uma regra.

Na página de configuração do assistente, ODBC é selecionado como carregador. As três tabelas acima mencionadas são selecionadas na página Extração de dados. A próxima página é a página Regras de modificação de campo. Nesta página, podem ser desenhadas as regras a serem aplicadas a todas as tabelas extraídas selecionadas.

Clicando em Criar  abrirá a página do Field Rule Matcher. É aqui que os detalhes do matcher são inseridos. Comece inserindo um nome de correspondência.

Depois de clicar em Criar  ao lado de Nome da regra , a página Seleção do Assistente de Nova Regra do Campo de Proteção é exibida. Selecione Funções de criptografia ou descriptografia . Essa seleção garante que o mesmo algoritmo de proteção se aplique a todos os dados, garantindo a integridade referencial.



A próxima página é onde o tipo de criptografia é selecionado. Nesse caso, enc_fp_aes256_ascii é usado. Esse algoritmo de criptografia com preservação de formato usa o conjunto de caracteres ASCII para substituir os dados reais. Ele é usado nesta demonstração para que a criptografia seja perceptível na saída. Uma escolha mais realista normalmente seria o alphanum  versão, que também preservaria a aparência real dos SSNs (9 números neste caso).

Embora este exemplo use uma frase secreta incorporada, um arquivo de senha também pode ser usado para a chave de criptografia, assim como uma variável de ambiente.



Clicando em Concluir  irá inserir esta regra no matcher. Em seguida, o próprio matcher deve ser criado. Clique em Adicionar  nos Correspondentes seção. Isso abrirá a página Detalhes do Matcher de Regras de Campo. Aqui pode ser usado um padrão ou uma classe de dados. Consulte o artigo Aplicando regras de campo usando classificação para obter detalhes sobre a segunda opção.

Neste exemplo, Padrão  é selecionado e .*SID é inserido nos detalhes. Este regex corresponderá a todos os nomes de coluna que terminam em SID.



O matcher termina com os detalhes exibidos abaixo. O Teste  O botão pode ser usado para testar os correspondentes para garantir que eles correspondam a todas as colunas pretendidas. Vários detalhes do matcher podem ser inseridos e a lógica AND/OR pode ser utilizada para produzir matchers refinados. Por exemplo, há uma coluna adicional chamada VP_SSN . O mesmo matcher acima pode ser usado com outro matcher com um padrão de .*SSN   e o operador E  para corresponder nesta coluna adicional, mas com a mesma regra.



Clicando em OK  aqui retorna para a página Regras, onde cada correspondente de regra é exibido. Diferentes correspondentes podem ser usados ​​para campos diferentes, de modo que apenas uma passagem de transformação seja necessária, mesmo que as regras mascarassem colunas diferentes de maneiras diferentes.



Clicando em Avançar  exibirá a página Estágio de Carregamento de Dados. Aqui é onde a tabela de saída e as opções são selecionadas. Neste exemplo, as mesmas tabelas que as tabelas de entrada são selecionadas. Além disso, o modo de saída foi alterado para Criar  para truncar as tabelas antes de carregar para que as chaves exclusivas não sejam violadas.



Depois de clicar em Concluir , uma pasta é criada com vários scripts que serão executados com o arquivo de lote incluído.



Para ver como a regra transformará o campo e nos dará a chance de modificar as coisas manualmente, SCOTT_EMPLOYEES.fcl o script pode ser revisado no editor do Workbench. Na saída, tanto o EMPLOYEE_SID  e o MANAGER_SID mostrar o algoritmo de criptografia aplicado.



Depois de executar o arquivo em lote, a mesma consulta SQL mostra os mesmos resultados combinados, mas com o Employee_SID  e Manager_SID  agora criptografado. Além disso, a integridade referencial é preservada. As relações funcionário-gerente originais são mantidas e os IDs do gerente na linha 2 e do funcionário na linha 26 são os mesmos.



Este exemplo demonstra como uma regra de criptografia pode ser usada em várias colunas em várias tabelas, mantendo a integridade referencial. Quaisquer regras criadas durante os assistentes de trabalho são salvas em uma biblioteca de regras. Isso permite que eles sejam reutilizados e até compartilhados com colegas para que os mesmos resultados sejam garantidos nos mesmos dados.

Se você tiver alguma dúvida sobre as regras de mascaramento de dados do FieldShield ou precisar de ajuda para usar qualquer um de seus assistentes de descoberta de dados ou mascaramento, entre em contato com seu representante IRI.