Proteger seus dados

Concluído

Depois que o acesso à sua rede e a identidade estiver configurado e seguro, vamos examinar como proteger os seus dados, estejam eles em repouso, em movimento ou sendo exibidos por usuários e administradores.

Criptografia de dados

As conexões criptografadas são obrigatórias no Banco de Dados SQL do Azure, com a opção de especificar também a versão mínima de protocolo TLS de entrada exigida (>1.0, >1.1 ou >1.2). É recomendável forçar a criptografia no cliente para evitar a negociação do servidor e não confiar no certificado do servidor como uma melhor prática.

Transparent Data Encryption

A TDE (Transparent Data Encryption) fornece criptografia para dados inativos e é ativado por padrão para todos os novos bancos de dados no Banco de Dados SQL do Azure. Você pode configurar isso para todas as opções de implantação com uma opção no portal do Azure, conforme mostrado aqui:

Captura de tela confirmando que a TDE está no portal do Azure.

No nível do servidor ou da instância, você também pode optar por usar uma Chave gerenciada pelo serviço ou pode usar BYOK (Bring Your Own Key) usando a opção Chave gerenciada pelo cliente. O padrão é permitir que o serviço do Azure gerencie a sua chave. O Azure gera automaticamente uma chave para criptografar os seus bancos de dados e gerencia as rotações de chave. Você aprendeu como fazer isso com o portal do Azure, mas também pode usar o Azure PowerShell, a CLI do Azure, o T-SQL (Transact-SQL) ou as APIs REST.

Captura de tela do modo de exibição do servidor de opções do TDE.

Chaves gerenciadas pelo cliente com TDE

Como alternativa, você pode usar o BYOK e tirar proveito de um Azure Key Vault. As vantagens de usar chaves gerenciadas pelo cliente são:

  • Controle completo e granular sobre o uso e o gerenciamento do protetor de TDE
  • Transparência do uso do protetor de TDE
  • Capacidade de implementar a separação de tarefas no gerenciamento de chaves e dados na organização
  • O administrador do cofre de chaves pode revogar as permissões de acesso à chave para tornar o banco de dados criptografado inacessível
  • Gerenciamento central de chaves no AKV
  • Maior confiança dos clientes finais, pois o AKV foi projetado de modo que a Microsoft não possa ver nem extrair as chaves de criptografia

Você também pode aproveitar o uso de uma UMI (identidade gerenciada atribuída pelo usuário) com chaves gerenciadas pelo cliente para TDE, que:

  • Habilita a capacidade de pré-autorizar o acesso ao cofre de chaves para servidores lógicos de SQL do Azure criando uma identidade gerenciada atribuída pelo usuário e concedendo a ela acesso ao cofre de chaves, mesmo antes da criação do servidor ou do banco de dados.
  • Permite a criação de um servidor lógico do SQL do Azure com TDE e CMK habilitados.
  • Permite que a mesma identidade gerenciada atribuída pelo usuário seja atribuída a diversos servidores, eliminando a necessidade de ativar individualmente a identidade gerenciada atribuída pelo sistema para cada servidor lógico de SQL do Azure e fornecendo acesso ao cofre de chaves.
  • Fornece a capacidade de impor o CMK no momento da criação do servidor com uma política interna do Azure disponível.

A Rotação automática de chaves foi introduzida para chaves gerenciadas pelo cliente usando TDE. Quando habilitado, o servidor verifica continuamente o cofre de chaves em busca de novas versões da chave que está sendo usada como protetora de TDE. Se uma nova versão da chave for detectada, o protetor de TDE no servidor será automaticamente girado para a versão mais recente da chave dentro de 60 minutos.

Always Encrypted

Você também pode aproveitar a criptografia em nível de coluna, que tem suporte no SQL do Azure da mesma forma que no SQL Server. Esse processo envolve usar a criptografia do lado do cliente de dados confidenciais, que usa chaves que nunca foram fornecidas ao sistema de banco de dados. Além disso, o driver do cliente criptografa parâmetros de consulta de modo transparente e descriptografa os resultados criptografados. Atualmente, há suporte para dados criptografados para comparação de igualdade, incluindo os operadores JOIN, GROUP BY e DISTINCT por criptografia determinística.

O Always Encrypted com enclaves seguros expande as funcionalidades de computação confidencial do Always Encrypted habilitando a criptografia in-loco e as consultas confidenciais mais avançadas. O recurso Always Encrypted com enclaves seguros já está disponível para Banco de Dados SQL do Azure, mas ainda não há suporte para ele na Instância Gerenciada de SQL do Azure.

Máscara de Dados Dinâmicos

Às vezes, você desejará mascarar ou modificar determinados dados para que os usuários sem privilégios não possam vê-lo, mas eles ainda poderão executar consultas que incluam esses dados. Essa funcionalidade tem suporte da mesma forma que no SQL Server. No entanto, há funcionalidades e exibições adicionais no portal do Azure que permitem que você veja as recomendações dos campos a serem mascarados.

Captura de tela de recomendações de Máscara Dinâmica de Dados no portal do Azure.

Vamos dar uma olhada no exemplo no qual os dados incluem informações confidenciais, como nomes e endereços de email. Você pode aplicar uma máscara a essas colunas no portal do Azure selecionando o menu Máscara Dinâmica de Dados em Segurança no painel de configuração do Banco de Dados SQL ou usando os seguintes comandos T-SQL:

ALTER TABLE Data.Membership ALTER COLUMN FirstName
ADD MASKED WITH (FUNCTION = 'partial(1, "xxxxx", 1)')

ALTER TABLE Data.Membership ALTER COLUMN Email
ADD MASKED WITH (FUNCTION = 'email()')

ALTER TABLE Data.Membership ALTER COLUMN DiscountCode 
ADD MASKED WITH (FUNCTION = 'random(1, 100)')
 
GRANT UNMASK to DataOfficers

Nos comandos acima, você vê que há várias maneiras de aplicar uma máscara com funções.

Por exemplo, se forem atribuídos a uma função como DataOfficers (esse é apenas um exemplo e não uma função oficial), alguns usuários talvez precisem ser capazes de exibir os dados mascarados. Você pode conceder a eles os privilégios de UNMASK com o seguinte comando T-SQL:

GRANT UNMASK TO DataOfficers

Dependendo de quem está consultando, os resultados seriam mostrados da seguinte maneira:

Captura de tela de um exemplo de usuários com acesso de remoção de máscara.

Com a introdução às permissões de mascaramento de dados dinâmico regular, você pode conceder ou revogar a permissão UNMASK no nível do banco de dados, no nível do esquema, no nível da tabela ou no nível da coluna para um usuário de banco de dados, identidade do Microsoft Entra, grupo do Microsoft Entra ou função de banco de dados.

Tarefas para proteção de dados

Para instalar e configurar a proteção de dados, você deve:

  • Certifique-se de que seus aplicativos forcem a criptografia de conexão e usem a versão mais alta do TLS compatível com seu aplicativo, clientes e drivers.
  • Avaliar e habilitar a TDE. Essa é a configuração padrão para novos bancos de dados, mas, se você migrar, talvez precise habilitá-la.
  • Aproveitar a Máscara Dinâmica de Dados.
  • Para proteção avançada, você pode configurar o recurso Always Encrypted com enclaves seguros.

Verificação de conhecimento

1.

Como gerenciar quem tem acesso de exibição dos dados mascarados?

2.

Durante comparações de igualdade em dados criptografados com o Always Encrypted, quais operadores têm suporte atualmente no SQL do Azure?