Privacidade de dados para análises de escala de nuvem no Azure

A análise em escala de nuvem libera as organizações para determinar os melhores padrões a fim de atender às necessidades e proteger os dados pessoais em vários níveis. Dados pessoais são todos os dados que podem ser usados para identificar pessoas, como números de: carteira de motorista, seguro social, conta bancária, passaporte, além de endereços de email etc. Atualmente, existem muitas regulamentações para proteger a privacidade do usuário.

Esquema de classificação de confidencialidade de dados

classificação	Descrição
Setor Público	Qualquer pessoa pode acessar os dados, e eles podem ser enviados a qualquer um. Por exemplo, abertura de dados governamentais.
Somente para uso interno	Somente os funcionários podem acessar os dados, e eles não podem ser enviados para fora da empresa.
Confidencial	Os dados só poderão ser compartilhados se forem necessários para uma tarefa específica. Os dados não podem ser enviados para fora da empresa sem um contrato de não divulgação.
Confidenciais (dados pessoais)	Os dados contêm informações particulares, que precisam ser mascaradas e compartilhados apenas com aqueles diretamente interessados e por um período limitado. Os dados não podem ser enviados a pessoas não autorizadas ou fora da empresa.
Restritos	Os dados só podem ser compartilhados com pessoas nomeados que são responsáveis pela proteção deles. Por exemplo, documentos legais ou segredos comerciais.

Antes de ingerir dados, categorize-os como confidencial ou inferior ou confidencial (dados pessoais):

• Os dados podem ser classificados em confidencial ou inferior se o usuário receber acesso ao ativo de dados em enriquecido ou coletado. Os usuários podem exibir todas as colunas e linhas.

• Os dados podem ser classificados em confidencial (dados pessoais) quando as colunas e linhas visíveis têm restrições de acordo com o usuário.

Importante

Um conjunto de dados pode mudar de confidencial ou inferior para confidencial (dados pessoais) quando os dados são combinados. Quando os dados precisam ser mantidos de forma permanente, é necessário copiá-los em uma pasta separada de acordo com a classificação de confidencialidade de dados e ao processo de integração.

Confidencial ou inferior

Para cada produto de dados integrado, criamos duas pastas de data lake nas camadas enriquecidas e selecionadas, confidenciais ou abaixo e confidenciais (dados pessoais), e usamos listas de controle de acesso para habilitar a Autenticação de Passagem do diretório do Microsoft Azure (Microsoft Entra ID).

Se uma equipe de aplicativo de dados integrar um ativo de dados confidencial ou inferior, os nomes principais de usuário e os objetos de entidade de serviço poderão ser adicionados a dois grupos do Microsoft Entra (um para acesso de leitura/gravação e outro para acesso somente leitura). Esses dois grupos do Microsoft Entra devem ser criados durante o processo de integração e classificados na pasta de produto de dados apropriada com contêineres confidenciais ou abaixo para dados brutos e enriquecidos.

Esse padrão permite que qualquer produto de computação que ofereça suporte à autenticação de passagem do Microsoft Entra se conecte ao data lake e autentique usuários conectados. Se um usuário fizer parte do grupo Microsoft Entra do ativo de dados, ele poderá acessar os dados por meio da autenticação de passagem do Microsoft Entra. Ele permite que os usuários do grupo leiam todo o ativo de dados sem filtros de política. O acesso pode ser auditado em detalhes com os logs apropriados e o Microsoft Graph.

Para obter recomendações sobre o layout do data lake, veja Provisionar três contas do Azure Data Lake Storage Gen2 para cada zona de destino de dados.

Observação

Exemplos de produtos de computação são Azure Databricks, Azure Synapse Analytics, Apache Spark e pools sob demanda do Azure Synapse SQL habilitados com autenticação de passagem do Microsoft Entra.

Dados confidenciais (dados pessoais)

Para confidencial (dados pessoais), a empresa precisa restringir o que os usuários podem ver usando políticas, cópias de dados ou computação. Nesse caso, a organização precisa considerar mover ou injetar o controle de acesso na camada de computação. Há quatro opções de abordagem de proteção de dados na análise em escala de nuvem.

Cenário de exemplo

O exemplo a seguir descreve opções para garantir a confidencialidade (dados pessoais):

Um aplicativo de dados ingere um produto de dados da equipe de RH (recursos humanos) para a América do Norte e a Europa. O caso de uso exige que usuários europeus vejam apenas registros da equipe europeia e que usuários norte-americanos vejam apenas registros da equipe norte-americana. Ele também exige que somente os gerentes de RH vejam colunas que contêm dados de salário.

Opção 1: mecanismo de política (recomendado)

As duas primeiras opções oferecem uma forma de lidar com a confidencialidade (dados pessoais)e também concedem controle às equipes de produto de dados e operações de integração para identificar e restringir o acesso. Isso pode ser suficiente para uma plataforma de análise de pequena escala, mas é preciso aplicar um mecanismo de política na zona de destino de gerenciamento de dados de grandes empresas que abrigam centenas de produtos de dados. Os mecanismos de política dão suporte a uma forma centralizada de gerenciar, proteger e controlar:

• Acesso a dados
• Gerenciamento do ciclo de vida dos dados
• Políticas e regulamentos internos e externos
• Políticas de compartilhamento de dados
• Identificação da confidencialidade (dados pessoais)
• Insights sobre proteção e conformidade
• Políticas para a geração de relatórios de proteção de dados

Normalmente, um mecanismo de política seria integrado a um catálogo de dados como o Azure Purview. O Azure Marketplace apresenta soluções de fornecedores de terceiros, e alguns fornecedores trabalham com Azure Synapse e o Azure Databricks para criptografar e descriptografar informações, fornecendo também segurança no nível da linha e da coluna. Em janeiro de 2022, o Azure Purview lançou uma versão prévia pública de políticas de acesso para controlar o acesso aos dados armazenados no Blob e no ADLS (Azure Data Lake Storage) Gen2. Confira Provisionamento de conjunto de dados pelo proprietário de dados para o Armazenamento do Microsoft Azure (versão prévia).

O mecanismo de política deve usar grupos do Microsoft Entra para aplicar políticas a produtos de dados. A expectativa de qualquer solução de política que forneça privacidade de dados é tokenizar confidencialidade (dados pessoais) e sempre verificar o controle de acesso de atributo para que o usuário destokenize as colunas que precisam acessar.

Conforme mencionado, para que um mecanismo de política seja bem sucedido, é importante que ele se integre ao catálogo de dados e que DevOps usem uma API REST para integrar um novo conjunto de dados. Quando as equipes de aplicativos de dados criam fontes de dados de leitura, elas são registradas no catálogo de dados e ajudam a identificar dados do tipo confidencial (dados pessoais). O mecanismo de política deve importar a definição e negar todo o acesso aos dados até que as equipes configurem as políticas de acesso. Tudo isso deve ser feito por meio de um fluxo de trabalho da API REST na solução gerenciamento de serviços de TI.

Opção 2: versões de “confidencial ou menos” e “confidencial (dados pessoais)”

Para cada produto de dados classificado como confidencial (dados pessoais), são criadas duas cópias pelo pipeline. Uma classificada como confidencial ou menos, com todas as colunas confidencial (dados pessoais) removidas, que é criada na pasta confidencial ou menos do produto de dados. Outra criada na pasta confidencial (dados pessoais) do produto de dados, com todos os dados confidenciais incluídos. Cada pasta receberia um grupo de segurança do leitor do Microsoft Entra e um grupo de segurança do gravador do Microsoft Entra. Com o gerenciamento de acesso a dados, um usuário pode solicitar acesso ao produto de dados.

Embora isso atenda à separação de confidencial (dados pessoais) e confidencial ou menos, um usuário com acesso concedido por meio da autenticação de passagem do Active Directory para confidencial (dados pessoais) poderá consultar todas as linhas. Se você precisar de segurança em nível de linha, use a Opção 1: mecanismo de políticas (recomendado) ou a Opção 3: pools do Banco de Dados SQL do Azure, da Instância Gerenciada de SQL ou do SQL do Azure Synapse Analytics.

Opção 3: pools do Banco de Dados SQL do Azure, da Instância Gerenciada de SQL ou do SQL do Azure Synapse Analytics

Um aplicativo de dados usa os pools do Banco de Dados SQL, da Instância Gerenciada de SQL ou do Azure Synapse Analytics para carregar os produtos de dados em um banco de dados que dá suporte à segurança em nível de linha, à segurança em nível de coluna e ao mascaramento dinâmico de dados. As equipes de aplicativos de dados criam diferentes grupos do Microsoft Entra e atribuem permissões que oferecem suporte à sensibilidade dos dados.

Para o caso de uso desse cenário, as equipes de aplicativos de dados precisariam criar os quatro grupos do Microsoft Entra a seguir com acesso somente leitura:

Grupo	Permissão
DA-AMERICA-HRMANAGER-R	Exibir ativos de dados da equipe de RH da América do Norte com informações de salário.
DA-AMERICA-HRGENERAL-R	Exibir ativos de dados da equipe de RH da América do Norte sem informações de salário.
DA-EUROPE-HRMANAGER-R	Exibir ativos de dados da equipe de RH da Europa com informações de salário.
DA-EUROPE-HRGENERAL-R	Exibir ativos de dados da equipe de RH da Europa sem informações de salário.

O primeiro nível de restrições seria compatível com o mascaramento de dados dinâmico, que oculta dados confidenciais de usuários sem privilégios. Uma vantagem dessa abordagem é que ela pode ser integrada à integração de um conjunto de dados com uma API REST.

O segundo nível consiste em adicionar segurança em nível de coluna para impedir que quem não é gerente de RH veja os salários, além da segurança em nível de linha para restringir as linhas que os membros das equipes europeia e norte-americana podem ver.

Além da criptografia de dados transparente, a camada de segurança seria para criptografar a coluna de dados e descriptografar após a leitura.

As tabelas podem ser disponibilizadas para o Azure Databricks com o conector de Apache Spark: SQL Server e Banco de Dados SQL do Azure.

Opção 4: Azure Databricks

A opção quatro é usar o Azure Databricks para explorar confidencial (dados pessoais). Usar uma combinação de bibliotecas de criptografia Fernet, UDFs (funções definidas pelo usuário), segredos do Databricks, controle de acesso à tabela e funções de exibição dinâmica ajuda a criptografar e descriptografar colunas.

Como a postagem de blog Enforcing Column-level Encryption and Avoiding Data Duplication descreve:

"A primeira etapa desse processo é proteger os dados criptografando-os durante a ingestão, e uma solução possível é a biblioteca Python Fernet. A Fernet usa criptografia simétrica, que é criada com vários primitivos criptográficos padrão. Essa biblioteca é usada em uma UDF de criptografia que nos permite criptografar qualquer coluna em um quadro de dados. Para armazenar a chave de criptografia, usamos segredos do Databricks com controles de acesso em vigor para permitir que apenas nosso processo de ingestão de dados a acesse. Depois que os dados são gravados em nossas tabelas do Delta Lake, colunas de dados pessoais que mantém valores como número do seguro social, número de telefone, número de cartão de crédito e outros identificadores não podem ser lidas por um usuário não autorizado.

Quando os dados confidenciais estão gravados e protegidos, os usuários privilegiados precisam ler os dados confidenciais. Primeiro, é necessário criar um UDF permanente a ser adicionado à instância do Hive em execução no Databricks. Para que o UDF seja permanente, ele deve ser escrito em Scala. Felizmente, a Fernet também tem uma implementação Sala que você pode usar nas leituras descriptografadas. Esse UDF também acessa o mesmo segredo usado na gravação criptografada para fazer a descriptografia e, nesse caso, é adicionado à configuração do Spark do cluster. Isso nos exige adicionar controles de acesso de cluster para que usuários privilegiados e não privilegiados controlarem o acesso à chave. Depois que o UDF é criado, podemos usá-lo em nossas definições de exibição para que os usuários com privilégios vejam os dados descriptografados.

Com as funções de exibição dinâmica, você pode criar apenas uma exibição e retornar os valores criptografados ou descriptografados com base no grupo do Databricks ao qual eles pertencem.

No exemplo anterior, você criaria duas funções de exibição dinâmicas, uma para a América do Norte e outra para a Europa e implementaria as técnicas de criptografia neste notebook.

Exibição da América do Norte:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_us AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-AMERICA-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='US'

Exibição da Europa:

-- Alias the field 'email' to itself (as 'email') to prevent the
-- permission logic from showing up directly in the column name results.
CREATE VIEW vhr_eu AS
SELECT
  emp_id,
  CASE WHEN
    is_member('DA-EUROPE-HRMANAGER-R') THEN udfPIIDecrypt(salary, "${spark.fernet}")
    ELSE 0
  END AS salary,
FROM hr_enriched
where region='EU'

Para que funcione, você precisaria habilitar o controle de acesso à tabela do Azure Databricks no espaço de trabalho e aplicar as seguintes permissões:

• Conceda DA-AMERICA-HRMANAGER-R e DA-AMERICA-HRGENERAL-R grupos do Microsoft Entra acesso à vhr_us exibição.
• Conceda DA-EUROPE-HRMANAGER-R e DA-EUROPE-HRGENERAL-R grupos do Microsoft Entra acesso à vhr_eu exibição.

Como as colunas são criptografadas e não podem ser descriptografadas no espaço de trabalho confidencial ou abaixo, os espaços de trabalho confidenciais ou abaixo ainda podem usar a autenticação de passagem do Microsoft Entra e permitir que os usuários explorem o lago, com base em suas permissões.

Quando o acesso à tabela é usado, as equipes que exigem acesso são adicionadas ao workspace do Azure Databricks. O Azure Databricks usaria as entidades de serviço para mapear para Azure Data Lake Storage, mas os dados seriam protegidos com o controle de acesso à tabela do Azure Databricks.

À medida que novos produtos de dados são implantados, parte do processo de DevOps precisaria executar scripts para configurar as permissões de tabela no espaço de trabalho do Azure Databricks e adicionar os grupos corretos do Microsoft Entra a essas permissões.

Observação

O controle de acesso à tabela do Azure Databricks não pode ser combinado com a autenticação de passagem do Microsoft Entra. Portanto, você pode usar apenas um workspace do Azure Databricks e o controle de acesso à tabela.

Dados restritos

Além das opções de implementação de dados confidenciais ou restritos, também é recomendado hospedar dados altamente confidenciais em uma zona de destino de gerenciamento de dados e em uma zona de destino de dados dedicada.

Isso permite requisitos específicos, como o acesso just-in-time, chaves gerenciadas pelo cliente para criptografia e restrições de entrada ou saída aplicadas à zona de destino. As diretrizes avaliaram a inserção de dados desse tipo na mesma zona de destino de dados, mas em contas de armazenamento diferentes. Mas isso pode tornar a solução complicada na camada de rede, por exemplo, com grupos de segurança de rede.

A zona de destino de gerenciamento de dados “restritos” dedicada deve se conectar para catalogar os dados na zona de destino de dados “restritos”. Isso deve restringir quem pode pesquisar esses dados no catálogo.

Próximas etapas

• Gerenciamento de acesso a dados