Protegendo dados em repouso e em movimento

Os aplicativos de banco de dados que atualizam e consultam tabelas podem precisar proteger os dados que entram ou são recuperados dessas tabelas. Os dados confidenciais devem ser protegidos no caminho para a tabela, uma vez na tabela ou na saída. Em todos os casos, o objetivo é impedir que pessoas não autorizadas acessem determinados valores de linhas ou colunas considerados confidenciais.

Para dados de formato normal (estruturados) em bancos de dados relacionais, o utilitário de mascaramento de dados autônomo do IRI FieldShield ou sua biblioteca compatível de funções de mascaramento que podem ser chamadas pode acomodar os cenários acima, fornecendo muitas opções para estática (persistente, em repouso) e dinâmica (em -transit) opções de mascaramento de dados. Se você também tiver valores PII/PHI flutuando aleatoriamente em colunas RDB semi e não estruturadas (como texto, C/BLOB, XML/JSON), consulte este artigo sobre a abordagem IRI DarkShield.

Este artigo falará sobre as opções do FieldShield, no entanto, já que a maioria dos usuários do RDB está preocupada em encontrar e mascarar os valores das colunas fixas. Os usuários do FieldShield podem classificar, localizar e mascarar dados em tabelas de banco de dados e, para usuários de aplicativos, executar por meio de:

• um mascaramento de dados estáticos em tabelas de produção e desmascaramento dinâmico por usuários de aplicativos autorizados
• funções de mascaramento incorporadas em tarefas de transformação, limpeza ou relatórios compatíveis com metadados
• um sistema de redação de dados dinâmicos baseado em proxy
• por meio de uma API SDK, ou sistema, chamada de um programa
• in-situ, por meio de procedimentos SQL usando uma biblioteca personalizada

Se seus dados estiverem em bancos de dados NoSQL como MongoDB, Cassandra, Elasticsearch ou MarkLogic, o FieldShield lidará com coleções estruturadas, enquanto o DarkShield lidará com coleções estruturadas e não estruturadas.

Por padrão — e a maneira como a GUI do IRI Workbench apresenta o FieldShield para usuários finais e DBAs — uma ou mais tabelas completas são normalmente protegidas com funções de mascaramento de dados estáticos (como criptografia, redação, pseudonimização) de acordo com as regras de negócios. A escolha de cada "escudo de campo (coluna)" deve ser baseada em segurança, realismo, reversibilidade e talvez considerações de CPU ou armazenamento.

A abordagem estática funciona bem quando os dados estão em repouso. A tabela de origem pode ser protegida ou uma nova tabela ou arquivo de destino com proteções aplicadas pode ser criado. Os aplicativos que buscam os dados protegidos não precisam se preocupar com a segurança porque suas fontes de dados foram pré-protegidas. Os programas FieldShield projetados para proteger dados em repouso também podem ser agendados ou chamados em trabalhos em lote para atualizações regulares.

No entanto, em um ambiente em tempo real onde as linhas atualizadas precisam de proteção dinâmica, as funções do FieldShield devem ser integradas ao fluxo de dados do aplicativo. Existem várias abordagens a considerar:

1) Seu programa chama FieldShield
Banco de dados e outros programas que buscam ou enviam dados novos ou alterados para tabelas podem passá-los para uma função de API de criptografia, hash, codificação ou redação do FieldShield em C, Java ou .NET. Você também pode passar os dados em movimento para um programa FieldShield autônomo por meio de um pipe ou procedimento de entrada. Qualquer um desses métodos pode preencher destinos com funções de proteção (ou revelação) no nível da coluna aplicadas.

2) O FieldShield protege apenas as atualizações
Os programas FieldShield também podem ser personalizados através das funções /QUERY e /UPDATE, ou para filtrar condicionalmente apenas novos registros, onde as linhas a serem protegidas atendem a critérios específicos, como novidade. As chamadas de API permitiriam uma lógica de negócios ainda mais granular e facilitariam mais condições de "velocidade" (ou latência) de dados — por exemplo, mais mascaramento de dados em tempo real — porque essas necessidades podem ser expressas por meio do aplicativo e definidas por sua lógica. Veja este exemplo de PL/SQL de mascaramento em tempo real com base em um gatilho.

3) Capture e proteja Deltas no CoSort (FieldShield Pai)
As tarefas de captura de dados de alteração (CDC) também podem ser programadas na linguagem de controle de classificação do CoSort (SortCL), em que apenas inserções, atualizações, exclusões ou linhas inalteradas selecionadas podem ser passadas para tabelas ou arquivos com proteções de coluna aplicadas à medida que isso acontece. Os usuários do CoSort têm todas as funções de proteção do FieldShield à sua disposição, portanto, é possível mascarar apenas os dados alterados neste paradigma de relatórios em massa.

4) Interceptações de consulta baseadas em proxy
A IRI agora fornece um driver especial “JDBC SQL Trail” para uso de aplicativos que filtra consultas de banco de dados para usuários autorizados e tabelas e colunas específicas. Aqueles que não estão isentos da definição de política do DDM verão apenas valores total ou parcialmente editados em andamento para esse aplicativo especialmente conectado do banco de dados, que permanece desmascarado em repouso.

5) Integrações personalizadas
IRI pode trabalhar com seu DBA ou programador de aplicativos para projetar uma solução sob medida que envolva elementos do acima, ou para fornecer bibliotecas FieldShield que seus procedimentos SQL podem invocar in-situ como estes para proteger ou revelar (criptografar ou descriptografar) consultas resultados, tabelas de consulta, visualizações materializadas e assim por diante.

Entre em contato para obter ajuda na integração de uma função de mascaramento de dados dinâmico, como redação ou criptografia de preservação de formato em seu aplicativo.