Exemplo de arquitetura de uso de um proxy DLP para consultar um banco de dados que contém dados confidenciais

Last reviewed 2022-09-29 UTC

Neste documento, descrevemos o uso da Proteção de dados confidenciais para reduzir o risco de expor aos usuários os dados confidenciais armazenados nos bancos de dados do Google Cloud e ainda assim permitir que eles consultem dados significativos.

Os dados confidenciais podem existir em toda a empresa. Os dados coletados, processados e compartilhados podem conter detalhes como informações de identificação pessoal (PII, na sigla em inglês) [página em inglês], que estão sujeitas a políticas ou regulamentos externos e internos. Além dos controles de segurança adequados para restringir o acesso a dados confidenciais, também é possível usar estas técnicas para proteger os dados em uso. A desidentificação ajuda a encontrar o equilíbrio entre a utilidade e a privacidade dos dados usando técnicas, como mascaramento de dados, agrupamento por classes e tokenização.

A tokenização substitui os dados confidenciais por valores alternativos chamados de tokens, que representam o valor confidencial original (bruto) quando os dados são consultados ou visualizados. Às vezes, este processo é chamado de pseudonimização ou substituição alternativa. O conceito de tokenização é amplamente usado em setores como finanças e saúde para ajudar a diminuir o risco dos dados em uso, reduzir o escopo de conformidade e minimizar a exposição de dados confidenciais a pessoas ou sistemas que não precisam deles.

Com a proteção de dados confidenciais, é possível classificar e desidentificar dados confidenciais em lotes e em tempo real. A classificação é o processo de identificar as informações confidenciais e decidir o tipo delas. Neste documento, explicamos sobre onde é possível empregar essas técnicas de desidentificação e mostramos como usar um proxy para realizar essas tarefas.

No diagrama a seguir, ilustramos o cenário descrito neste documento.

Arquitetura de dados armazenados no Cloud Storage, ingeridos por ETL e consultados pelos usuários.

Neste cenário, os resultados retornados da consulta são dados brutos. Portanto, os dados confidenciais são exibidos e potencialmente expõem os PII ao usuário que faz a consulta. Você precisa projetar seu aplicativo para auditar e impedir consultas não autorizadas de dados confidenciais.

A arquitetura de proxy DLP

Uma maneira de proteger os dados PII é transmitir todas as consultas e os resultados por meio de um serviço que analisa, inspeciona e depois registra as descobertas ou desidentifica os resultados usando a proteção de dados confidenciais antes de retornar os dados ao usuário. Neste documento, esse serviço é chamado de proxy DLP.

O aplicativo proxy DLP aceita uma consulta SQL como entrada, executa essa consulta no banco de dados e aplica a proteção de dados confidenciais aos resultados, antes de retorná-los ao usuário que os solicita.

No diagrama a seguir, ilustramos a arquitetura do aplicativo proxy DLP.

Arquitetura do aplicativo proxy DLP com comandos de transformação de dados.

A proteção de dados confidenciais permite a configuração detalhada dos tipos de dados que serão inspecionados e como transformá-los com base nas descobertas da inspeção ou na estrutura de dados (por exemplo, nomes de campos). Para simplificar a criação e o gerenciamento da configuração, use modelos de proteção de dados confidenciais. O aplicativo proxy DLP refere-se aos modelos de inspeção e desidentificação.

É possível usar modelos para criar e manter informações de configuração com a Proteção de dados confidenciais. Os modelos são úteis para desassociar as informações de configuração da implementação de suas solicitações, por exemplo, o que você inspeciona e como faz a desidentificação disso. Para mais informações sobre modelos, consulte Modelos de proteção de dados confidenciais.

Os registros de auditoria do Cloud são um serviço integrado de geração de registros do Google Cloud usado nesta arquitetura. Primeiro, os registros de auditoria do Cloud fornecem uma trilha de auditoria de chamadas feitas à API Cloud Data Loss Prevention (parte da proteção de dados confidenciais). As entradas de registro de auditoria incluem informações sobre quem fez a chamada de API, que projeto do Cloud serviu de base para ela ser executada e detalhes sobre a solicitação, inclusive se um modelo foi usado como parte da solicitação. Segundo, se você usar o arquivo de configuração do aplicativo para ativar a auditoria, os registros de auditoria do Cloud gravarão um resumo das descobertas da inspeção.

O Cloud Key Management Service (Cloud KMS) é um serviço de gerenciamento de chaves hospedado na nuvem do Google Cloud que permite gerenciar chaves criptográficas para seus serviços de nuvem.

Os métodos de proteção de dados confidenciais para tokenização e mudança de data usam criptografia para gerar os valores de substituição. Esses métodos criptográficos usam uma chave para criptografar os valores de modo consistente a fim de manter a integridade da referência ou, para métodos que são reversíveis, a fim de destokenizar. É possível fornecer essa chave diretamente para a proteção de dados confidenciais quando a chamada é feita ou encapsulá-la usando o Cloud KMS. Encapsular a chave no Cloud KMS fornece outra camada de controle de acesso e auditoria e, portanto, é o método preferido para implantações de produção.

Em uma configuração de produção, use o princípio do menor privilégio (em inglês) para atribuir as permissões. No diagrama a seguir, ilustramos um exemplo desse princípio.

Configuração de produção com três personas e as permissões delas.

No diagrama anterior, mostramos como, em uma configuração de produção típica, há três perfis com papéis e acesso diferentes aos dados brutos:

  • Administrador de infraestrutura: instala e configura o proxy para que ele tenha acesso ao ambiente de computação em que o proxy de proteção de dados confidenciais está instalado.
  • Analista de dados: acessa o cliente que se conecta ao proxy DLP.

  • Administrador de segurança: classifica os dados, cria os modelos de proteção de dados confidenciais e configura o Cloud KMS.

Para mais informações sobre como usar o Cloud KMS para criptografar e descriptografar dados, consulte Como criptografar e descriptografar dados.

Para o proxy DLP usado neste documento, essas informações são todas configuradas em um modelo de desidentificação de proteção de dados confidenciais.

Como proteger PII com auditoria, mascaramento e tokenização

Há duas estratégias que podem ser implementadas para reduzir o risco de expor informações PII neste cenário.

Dados brutos armazenados no banco de dados

Caso seu aplicativo armazene dados brutos em um banco de dados, use o proxy DLP para processar os resultados retornados ao usuário inspecionando e gerando automaticamente uma auditoria das descobertas confidenciais. Se preferir, mascare os resultados da consulta em tempo real, conforme ilustrado no diagrama a seguir.

Arquitetura em que os resultados da consulta são mascarados em tempo real.

Esta configuração exige que você use um cliente SQL que se conecte ao proxy DLP. Se você ativar a auditoria no seu app, um registro será criado nos registros de auditoria do Cloud com um resumo das descobertas da inspeção. Esse resumo indica que tipo de informação confidencial foi retornado na consulta.

Dados armazenados de forma desidentificada

Se você não quiser armazenar os dados brutos, poderá armazenar os dados do seu aplicativo de forma desidentificada ou mascarada realizando as transformações de desidentificação durante o processo de ETL no banco de dados, conforme ilustrado no diagrama a seguir.

Arquitetura em que os resultados da consulta são mascarados durante o processo de ETL.

No diagrama anterior, ilustramos o fluxo básico, em que os dados são inspecionados e mascarados antes de serem ingeridos no banco de dados. Quando um usuário consulta os dados, mesmo se ele tiver acesso bruto ao banco de dados, só poderá ver a versão mascarada.

Se você permitir que dados não mascarados sejam vistos pelo usuário, use um cliente que possa se conectar a uma instância do proxy DLP e que tenha permissão para desmascarar os dados, conforme ilustrado no diagrama a seguir.

Arquitetura em que você usa um cliente para se conectar ao proxy DLP para visualizar dados não mascarados.

No diagrama anterior, ilustramos como é possível usar um cliente para se conectar ao proxy DLP e permitir que dados não mascarados sejam mostrados ao cliente.

A seguir