Privacidade de dados para análises de escala de nuvem no Azure
A análise em escala de nuvem ajuda a determinar os padrões ideais de acesso a dados que atendem aos seus requisitos, protegendo dados pessoais em vários níveis. Os dados pessoais incluem qualquer informação que possa identificar exclusivamente indivíduos, por exemplo, números de carteira de motorista, números de previdência social, detalhes da conta bancária, números de passaporte e endereços de email. Existem muitos regulamentos para proteger a privacidade do usuário.
Para proteger a privacidade de dados em um ambiente de nuvem, como o Azure, você pode criar um esquema de confidencialidade de dados que especifica políticas de acesso a dados. Essas políticas podem definir a arquitetura subjacente na qual o aplicativo de dados reside, definir como autorizar o acesso a dados e especificar quais linhas ou colunas os usuários podem acessar.
Criar um esquema de classificação de confidencialidade de dados
| Classificação | Descrição |
|---|---|
| Pública | 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, você deve categorizar os dados como confidenciais ou abaixo ou dados pessoais confidenciais:
- Classifique os dados em confidencial ou abaixo se você não precisar restringir quais colunas e linhas os usuários podem exibir.
- Classifique dados em dados pessoais confidenciais se precisar restringir quais colunas e linhas os usuários podem exibir.
Importante
Um conjunto de dados pode mudar de dados confidenciais ou inferiores para dados pessoais confidenciais quando você combina dados com outros produtos de dados que anteriormente tinham uma classificação mais baixa. Se você precisar de dados persistentes, mova-os para uma pasta designada que se alinhe ao nível de confidencialidade e ao processo de integração.
Criar um conjunto de políticas do Azure
Depois de classificar seus dados, você deve alinhar a classificação aos requisitos de política do setor e às políticas internas da empresa. Você deseja criar um conjunto de políticas do Azure que rege qual infraestrutura pode ser implantada, o local onde ela pode ser implantada e os padrões de rede e criptografia.
Para setores regulamentados, você pode usar as iniciativas de política de conformidade regulatória da Microsoft como linha de base para estruturas de conformidade.
A classificação de dados segue as mesmas regras de criptografia, SKUs de infraestrutura permitidas e iniciativas de política. Portanto, você pode armazenar todos os dados na mesma zona de destino.
Para dados restritos, você deve hospedar dados em uma zona de destino de dados dedicada em um grupo de gerenciamento em que você pode definir um conjunto mais alto de requisitos para infraestrutura. Por exemplo, você pode definir chaves gerenciadas pelo cliente para criptografia ou restrições de entrada ou de saída para a zona de destino.
Observação
Você pode colocar dados pessoais sensíveis e dados confidenciais ou de nível inferior na mesma zona de aterrissagem de dados, mas em contas de armazenamento diferentes. Mas essa prática pode complicar a solução na camada de rede, por exemplo, com grupos de segurança de rede.
Uma solução de governança de dados implantada deve limitar quem pode pesquisar dados restritos no catálogo. Considere implementar o acesso condicional da ID do Microsoft Entra para todos os ativos e serviços de dados. Para aprimorar a segurança, aplique o acesso just-in-time a dados restritos.
Considere os requisitos de criptografia
Além de definir políticas para locais e serviços permitidos do Azure, considere os requisitos de criptografia para cada classificação de dados. Considere os requisitos para as seguintes áreas:
- Gerenciamento de chaves
- Armazenamento de chaves
- Criptografia de dados em repouso
- Criptografia de dados em trânsito
- Criptografia de dados em uso
Para o gerenciamento de chaves, você pode usar chaves de criptografia gerenciadas pela plataforma ou gerenciadas pelo cliente. Para obter mais informações, consulte Visão geral do gerenciamento de chaves no Azure e Como escolher a solução de gerenciamento de chaves correta.
Para obter mais informações sobre opções de criptografia, consulte Criptografia de Dados do Azure em Repouso e Modelos de Criptografia de Dados .
Você pode usar o protocolo TLS (
Se o cenário exigir que os dados permaneçam criptografados durante o uso, o modelo de ameaça de Computação Confidencial do Azure ajudará a minimizar a confiança. Ele minimiza a possibilidade de que operadores de provedor de nuvem ou outros atores no domínio do locatário possam acessar código e dados durante a implementação.
Para obter mais informações, consulte produtos de computação confidencial do Azure.
Implementar a governança de dados
Depois de definir as políticas para a implantação de serviços permitidos do Azure, determine como conceder acesso ao produto de dados.
Se você tiver uma solução de governança de dados, como Microsoft Purview ou Azure Databricks Unity Catalog, poderá criar produtos ou ativos de dados para camadas de data lake enriquecidas e curadas. Certifique-se de definir as permissões dentro do catálogo de dados para ajudar a proteger esses objetos de dados.
Use o Microsoft Purview para gerenciar, proteger e controlar centralmente as seguintes áreas:
- Acesso a dados
- O ciclo de vida dos dados
- Políticas e regulamentos internos e externos
- Políticas de compartilhamento de dados
- Identificando dados confidenciais
- Insights sobre proteção e conformidade
- Políticas para a geração de relatórios de proteção de dados
Para obter mais informações sobre como usar o Microsoft Purview para gerenciar o acesso de leitura ou modificação, confira Conceitos para políticas de proprietário de dados do Microsoft Purview.
Se você decidir implementar o Microsoft Purview ou outra solução de governança de dados, use grupos de ID do Microsoft Entra para aplicar políticas a produtos de dados.
Use a API REST da solução de governança de dados para integrar um novo conjunto de dados. Suas equipes de aplicativos de dados criam produtos de dados e os registram na solução de governança de dados para ajudar a identificar dados confidenciais. A solução de governança de dados importa a definição e nega todo o acesso aos dados até que suas equipes configurem suas políticas de acesso.
Usar padrões de proteção de dados
Para proteger dados confidenciais, escolha um padrão de proteção de dados com base nos dados, serviços e políticas que você implementa.
Várias cópias
O pipeline para cada produto de dados que tem uma classificação de dados pessoais confidenciais cria duas cópias. O pipeline classifica a primeiro como confidencial ou inferior. Essa cópia não inclui as colunas de dados pessoais confidenciais. Ela é criado na pasta confidencial ou abaixo para o produto de dados. A outra cópia é criada na pasta de dados pessoais confidenciais. Essa cópia inclui os dados confidenciais. Cada pasta recebe um leitor do Microsoft Entra ID e um grupo de segurança do gravador de Microsoft Entra ID.
Se você usar o Microsoft Purview, poderá registrar ambas as versões do produto de dados e usar políticas para ajudar a proteger os dados.
O padrão de várias cópias separa dados pessoais sensíveis e dados classificados como confidenciais ou de nível inferior. Mas se você conceder a um usuário acesso a dados pessoais confidenciais, ele poderá consultar todas as linhas. Talvez sua organização precise considerar outras soluções que forneçam segurança em nível de linha para filtrar linhas.
Segurança em nível de linha e em nível de coluna
Se você precisar filtrar linhas que os usuários podem exibir, você poderá mover seus dados para uma solução de computação que usa segurança em nível de linha.
Para impedir a nova engenharia, selecione o serviço do Azure apropriado ou a solução do Microsoft Fabric para seu caso de uso específico. Diferentes tipos de bancos de dados são projetados para diferentes finalidades. Por exemplo, você não deve usar um banco de dados OLTP (processamento de transações online) para análise abrangente. E se você usar um aplicativo de comércio eletrônico, não deverá usar uma solução personalizada para análise de Big Data, pois ela não pode alcançar os tempos de resposta de milissegundos necessários.
Se você implementar soluções que dão suporte à segurança em nível de linha, suas equipes de aplicativos de dados deverão criar diferentes grupos de ID do Microsoft Entra e atribuir permissões com base na confidencialidade dos dados.
Além da segurança em nível de linha, você pode restringir o acesso a determinadas colunas. A tabela a seguir mostra um exemplo de quatro grupos de ID do Microsoft Entra que têm 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 dá suporte ao mascaramento dinâmico de dados, que oculta dados confidenciais de usuários que não têm privilégios. Você pode usar uma API REST para integrar essa abordagem à integração de um conjunto de dados.
O segundo nível de restrições adiciona segurança em nível de coluna para impedir que gerentes que não são de RH visualizem salários. Ele também adiciona segurança em nível de linha para restringir quais linhas os membros da equipe europeus e norte-americanos podem ver.
Criptografia de coluna
O mascaramento dinâmico de dados mascara os dados no ponto de apresentação, mas alguns casos de uso exigem que a solução nunca tenha acesso aos dados de texto sem formatação.
O recurso do SQL Always Encrypted aprimora a segurança de dados confidenciais em bancos de dados do SQL Server. O SQL Always Encrypted ajuda a garantir que os dados confidenciais nos bancos de dados do SQL Server permaneçam seguros e protegidos contra acesso não autorizado. Esse recurso criptografa os dados em repouso e em trânsito, o que ajuda a manter a confidencialidade máxima dos dados e a conformidade regulatória. O SQL Always Encrypted executa operações de criptografia e descriptografia no lado do cliente. Integre esse recurso para ajudar a proteger seus ativos de dados mais valiosos.