Privacidade de dados para análises de escala de nuvem no Azure
A análise em escala de nuvem permite que as organizações determinem os padrões ideais de acesso a dados para atender às suas necessidades, ao mesmo tempo em que protegem os dados pessoais em vários níveis. Dados pessoais incluem qualquer informação que possa identificar indivíduos exclusivamente, por exemplo, números de carteira de habilitação, números de previdência social, detalhes de contas bancárias, números de passaporte, endereços de email e muito mais. Atualmente, existem muitas regulamentações para proteger a privacidade do usuário.
Para proteger a privacidade dos dados com um ambiente de nuvem como o Azure, você pode começar criando um esquema de confidencialidade de dados que especifique políticas de acesso aos dados. Essas políticas podem definir a arquitetura subjacente na qual o aplicativo de dados reside, definir como o acesso aos dados é autorizado e especificar quais linhas ou colunas podem ser acessadas depois de concedidas.
Criar 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, categorize-os como confidencial ou inferior ou confidencial (dados pessoais):
- Os dados podem ser classificados em confidencial ou inferior se não houver restrições sobre quais colunas e linhas são visíveis para diferentes usuários.
- 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 com outros produtos de dados que anteriormente tinham uma classificação mais baixa. Quando os dados precisam ser persistentes, eles devem ser movidos para uma pasta designada que esteja alinhada ao seu nível de confidencialidade e ao processo de integração.
Criar um conjunto de políticas do Azure
Depois de mapear sua classificação de dados, você deve alinhar a classificação com os requisitos da política regulamentada do setor local e com as políticas internas da sua empresa. Esta etapa ajuda você a criar um conjunto de políticas do Azure que controla qual infraestrutura pode ser implantada, o local onde ela pode ser implantada e especifica os padrões de rede e criptografia.
Para setores regulamentados, a Microsoft desenvolveu muitas iniciativas de política de conformidade regulatória que atuam como linha de base para estruturas de conformidade.
Para classificação de dados, que segue as mesmas regras de criptografia e SKUs de infraestrutura permitidos, e iniciativas de políticas, os dados podem ficar dentro da mesma zona de destino.
Para dados restritos, recomendamos hospedar dados em uma zona de destino de dados dedicada em um grupo de gerenciamento em que você pode definir um conjunto superior de requisitos para infraestrutura, como chaves gerenciadas pelo cliente para criptografia e restrições de entrada ou saída aplicadas à zona de destino.
Observação
As diretrizes avaliaram a colocação de dados confidenciais (dados pessoais) e confidenciais ou inferiores 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.
Qualquer solução de governança de dados implantada deve limitar quem pode pesquisar dados restritos no catálogo.
Você também deve considerar implementar o acesso condicional do Microsoft Entra ID para todos os ativos e serviços de dados, e o acesso just-in-time para dados restritos para aumentar a segurança.
Criptografia
Além de definir políticas de localização e serviços permitidos do Azure, você deve considerar os requisitos de criptografia para cada uma das classificações de dados.
- Quais são seus requisitos para o gerenciamento de chaves?
- Quais são seus requisitos para armazenar essas chaves?
- Quais são seus requisitos, por classificação para criptografia de dados em repouso?
- Quais são seus requisitos, por classificação, para criptografia de dados em trânsito?
- Quais são seus requisitos, por classificação, para criptografia de dados em uso?
Para o gerenciamento de chaves, as chaves de criptografia podem ser gerenciadas pela plataforma ou pelo cliente. A Microsoft documentou o gerenciamento de chaves no Azure para ajudar você a escolher uma solução de gerenciamento de chaves. 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 certa.
A Microsoft publicou documentação explicando a criptografia de dados do Azure em repouso e os modelos de criptografia de dados que ajudam você a entender as opções de criptografia disponíveis.
A Microsoft dá aos clientes a capacidade de usar o protocolo TLS (Transport Layer Security) para proteger os dados quando eles estão viajando entre os serviços de nuvem e os clientes. Para obter mais informações, confira Criptografia de dados em trânsito.
Se o seu cenário exigir que os dados permaneçam criptografados durante o uso, o modelo de ameaça Computação Confidencial do Azure visa minimizar a confiança ou remover a possibilidade de um operador de provedor de nuvem ou outros participantes no domínio do locatário acessarem o código e os dados durante a execução.
Para ver as ofertas mais recentes de computação confidencial do Azure, veja Produtos de computação confidencial do Azure.
Governança de dados
Depois de definir as políticas para implantação de serviços permitidos do Azure, você deve decidir como conceder acesso ao produto de dados.
Se você tiver uma solução de governança de dados, como o Microsoft Purview ou o Catálogo do Azure Databricks Unity, poderá criar ativos/produtos de dados para camadas de data lake enriquecidas e coletadas. Certifique-se de definir as permissões no catálogo de dados para proteger esses objetos de dados.
O Microsoft Purview fornece uma maneira central de gerenciar, proteger e controlar:
- Acesso a dados
- 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
Para obter mais informações sobre como gerenciar o acesso de leitura ou modificação com o Microsoft Purview, consulte Conceitos de políticas de proprietário de dados do Microsoft Purview.
Independentemente de você decidir implementar o Microsoft Purview ou qualquer outra solução de governança de dados, é essencial usar grupos do Microsoft Entra ID para aplicar políticas a produtos de dados.
É importante usar a API REST das soluções de governança de dados para integrar um novo conjunto de dados. As 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 (pessoais). A solução de governança de dados importa a definição e nega todo o acesso aos dados até que as equipes configurem suas políticas de acesso.
Usar padrões para proteger dados confidenciais
Existem vários padrões que podem ser adotados dependendo dos dados, serviços e políticas que você precisa implementar para proteção de dados confidenciais.
Várias cópias
Para cada produto de dados classificado como confidencial (dados pessoais), duas cópias são criadas por seu pipeline. A primeira cópia é classificada como confidencial ou inferior. Essa cópia tem todas as colunas confidencial (dados pessoais) removidas e é criada na pasta confidencial ou inferior do produto de dados. A outra cópia é criada na pasta confidencial (dados pessoais) e tem todos os dados confidenciais incluídos. Cada pasta recebe um leitor do Microsoft Entra ID e um grupo de segurança do gravador de Microsoft Entra ID.
Se o Microsoft Purview estiver em uso, você poderá registrar ambas as versões do produto de dados e usar políticas para proteger os dados.
Esse processo separa dados confidenciais (dados pessoais) e confidenciais ou dados inferiores, mas um usuário que tiver acesso a dados confidenciais (dados pessoais) poderá consultar todas as linhas. Sua organização talvez precise recorrer a outras soluções que fornecem 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 vistas pelos usuários, poderá mover seus dados para uma solução de computação que use segurança em nível de linha.
Selecionar o serviço do Azure ou a solução do Microsoft Fabric apropriado para seu caso de uso específico é essencial para evitar a reengenharia. Um banco de dados OLTP não é adequado para análises extensas, assim como uma solução adaptada para análises de big data não consegue atingir tempos de resposta em milissegundos exigidos por um aplicativo de comércio eletrônico.
Para trabalhar com soluções que dão suporte à segurança em nível de linha, as equipes de aplicativos de dados criam diferentes grupos de do Microsoft Entra ID e atribuem permissões com base na confidencialidade dos dados.
Vamos elaborar o cenário especificando que, juntamente com a segurança em nível de linha, é necessário restringir o acesso a determinadas colunas. As equipes de aplicativos de dados criaram os quatro grupos do Microsoft Entra ID com acesso somente leitura, conforme mostrado na tabela a seguir:
| 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 de restrições 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.
Criptografia de coluna
Embora o mascaramento dinâmico de dados mascare os dados no ponto de apresentação, alguns casos de uso exigem que a solução nunca tenha acesso aos dados em texto simples.
O SQL Always Encrypted é um recurso avançado introduzido pela Microsoft que aprimora a segurança de dados confidenciais armazenados em bancos de dados do SQL Server. O SQL Always Encrypted garante que os dados confidenciais armazenados em bancos de dados do SQL Server permaneçam seguros e protegidos contra acesso não autorizado. Esse recurso ajuda a manter a máxima confidencialidade dos dados e a conformidade regulatória, criptografando os dados em repouso e em trânsito.
Ao executar operações de criptografia e descriptografia no cliente, o Always Encrypted garante que os dados confidenciais permaneçam protegidos contra acesso não autorizado. Sua facilidade de integração e benefícios de conformidade o tornam uma ferramenta essencial para organizações que buscam proteger seus ativos de dados mais valiosos.