Configurar o Gerenciamento Extensível de Chave de TDE do SQL Server usando o Azure Key Vault
Aplica-se: SQL Server
Neste artigo, você instala e configura o Conector do SQL Server para o Azure Key Vault.
Observação
O Microsoft Entra ID era conhecido como Azure Active Directory (Azure AD).
O Gerenciamento Extensível de Chaves usando o Azure Key Vault (AKV) está disponível para o SQL Server em ambientes Linux, a partir do SQL Server 2022 (16.x) Atualização Cumulativa 12. Siga as mesmas instruções, mas ignore as etapas 3 e 4.
Pré-requisitos
Antes de começar a usar o Azure Key Vault com sua instância do SQL Server, verifique se você atende aos seguintes pré-requisitos:
Você precisa ter uma assinatura do Azure.
Instale o Azure PowerShell, versão 5.2.0 ou posterior.
Criar um locatário do Microsoft Entra.
Familiarize-se com os princípios de armazenamento do EKM (Gerenciamento Extensível de Chave) com o Azure Key Vault examinando Gerenciamento Extensível de Chave usando o Azure Key Vault (SQL Server).
Ser capaz de modificar o registro no computador SQL Server.
Instale a versão do Pacote Redistribuível do C++ para Visual Studio baseada na versão do SQL Server que está sendo executada:
Versão do SQL Server Versão do Pacote Redistribuível do Visual Studio C++ 2008, 2008 R2, 2012, 2014 Pacotes Redistribuíveis do Visual C++ para o Visual Studio 2013 2016, 2017, 2019, 2022 Pacotes Redistribuíveis do Visual C++ para Visual Studio 2015 Familiarize-se com o Acesso Azure Key Vault atrás de um firewall se você planeja usar o Conector do SQL Server para o Azure Key Vault atrás de um firewall ou com um servidor proxy.
Observação
No SQL Server 2022 (16.x) CU 14 e versões posteriores, o SQL Server em Linux oferece suporte ao Gerenciamento Extensível de Chaves TDE com o Azure Key Vault. Não é necessário seguir as etapas 3 e 4 deste guia para o SQL Server em Linux.
Etapa 1: configurar uma entidade de serviço do Microsoft Entra
Para conceder à sua instância do SQL Server permissões de acesso ao Azure Key Vault, você precisará de uma conta de entidade de serviço no Microsoft Entra ID.
Entre no portal do Azure e siga uma destas etapas:
Selecione o botão Microsoft Entra ID.
Selecione Mais serviços e, no painel Todos os serviços, digite Microsoft Entra ID.
Registre um aplicativo no Microsoft Entra ID fazendo o que se segue. Para obter instruções passo a passo detalhadas, consulte a seção Obter uma identidade para o aplicativo da postagem no blog do Azure Key Vault, Azure Key Vault – Passo a passo.
Na seção Gerenciar do recurso Microsoft Entra ID, selecione Registros de aplicativo.
Na página Registros de aplicativo, selecione Novo registro.
No painel Registrar um aplicativo, insira o nome do aplicativo voltado para o usuário e selecione Registrar.
No painel esquerdo, selecione Certificados e segredos > Segredos do cliente > Novo segredo do cliente.
Em Adicionar um segredo do cliente, insira uma descrição e uma validade apropriada e selecione Adicionar. Não é possível escolher um período de expiração superior a 24 meses. Para saber mais, confira Adicionar um segredo do cliente.
No painel Certificados e segredos, em Valor, selecione o botão Copiar ao lado do valor do segredo do cliente a ser usado para criar uma chave assimétrica no SQL Server.
No painel esquerdo, selecione Visão geral e, na caixa ID do aplicativo (cliente), copie o valor a ser usado para criar uma chave assimétrica no SQL Server.
Etapa 2: Crie um Key Vault
Selecione o método que deseja usar para criar um cofre de chaves.
Criar um cofre de chaves usando o portal do Azure
Você pode usar o portal do Azure para criar o cofre de chaves e, então, adicionar uma entidade de segurança do Microsoft Entra a ele.
Crie um grupos de recursos.
Todos os recursos do Azure criados usando o portal do Azure devem estar contidos em um grupo de recursos, que você cria para alojar seu cofre de chaves. O nome do recurso neste exemplo é DocsSampleRG. Escolha seu grupo de recursos e o nome do cofre de chaves, pois todos os nomes de cofre de chaves devem ser globalmente exclusivos.
No painel Criar um grupo de recursos, em Detalhes do projeto, insira os valores e selecione Examinar + criar.
No portal do Azure, pesquise ou selecione os serviços de Cofres de chaves para criar um cofre de chaves. Selecione Criar.
No painel Criar um cofre de chaves, selecione a guia Básico. Insira os valores apropriados para a guia. Também recomendamos ativar a proteção contra limpeza.
Na guia Configuração de acesso, você tem a opção de selecionar o Controle de acesso baseado em função do Azure ou a Política de acesso ao cofre. Abordamos ambas as opções, mas a opção de Controle de acesso baseado em função do Azure é a recomendada. Para obter mais informações, consulte Visão geral do modelo de acesso.
A guia Redes pode ser deixada como padrão, ou você pode configurar os ajustes de rede para o cofre de chaves. Se você usar um firewall com o cofre de chaves, precisa habilitar a opção Permitir que os serviços confiáveis da Microsoft ignorem o firewall, a menos que esteja usando conexões de pontos de extremidade privados. Para obter mais informações, consulte Configurar redes virtuais e firewalls do Azure Key Vault.
Selecione o botão Revisar + criar e crie o cofre de chaves.
Controle de acesso baseado em função do Azure
O método recomendado é usar o Controle de acesso baseado em função (RBAC) do Azure para atribuir permissões ao cofre de chaves. Esse método permite atribuir permissões a usuários, grupos e aplicativos em um nível mais granular. Você pode atribuir permissões ao cofre de chaves no plano de gerenciamento (atribuições de função do Azure) e no plano de dados (políticas de acesso ao cofre de chaves). Se você só puder usar a política de acesso, poderá ignorar esta seção e ir para a seção Política de acesso do cofre. Para obter mais informações sobre permissões de RBAC do Azure Key Vault, consulte Funções internas do Azure para operações de plano de dados do cofre de chaves.
Vá para o recurso do cofre de chaves que você criou e selecione a configuração Controle de acesso (IAM).
Selecione Adicionar>Adicionar atribuição de função.
O aplicativo EKM precisa da função Usuário de Criptografia do Serviço de Criptografia do Cofre da Chaves para executar operações de encapsulamento e desencapsulamento. Procure Usuário de Criptografia do Serviço de Criptografia do Key Vault e selecione a função. Selecione Avançar.
Na guia Membros, selecione a opção Selecionar membros e procure o aplicativo Microsoft Entra que você criou na Etapa 1. Selecione o aplicativo e clique no botão Selecionar.
Clique em Revisar + atribuir duas vezes para concluir a atribuição de função.
O usuário que cria a chave precisa da função Administrador do Cofre de Chaves. Pesquise por Administrador do Cofre de Chaves e selecione a função. Selecione Avançar.
Assim como nas etapas anteriores, adicione o membro criando a chave e atribua a função.
Política de acesso ao cofre
Observação
Se você estiver usando a opção de Controle de acesso baseado em função do Azure, poderá ignorar esta seção. Se você estiver alterando o modelo de permissão, poderá fazê-lo acessando o menu de Configuração de acesso do cofre de chaves. Verifique se você tem as permissões corretas para gerenciar o cofre de chaves. Para mais informações, acesse Habilitar permissões do RBAC do Azure no Key Vault.
Na guia Configuração de acesso, selecione Política de acesso ao cofre. Se você estiver usando um cofre de chaves existente, poderá selecionar o menu Políticas de acesso no recurso Cofre de chaves e selecionar Criar.
No painel Criar uma política de acesso, selecione as permissões Obter e Listar nas opções de Operações de Gerenciamento de Chaves. Selecione as permissões Desencapsular chave e Encapsular chave nas opções de Operações criptográficas. Selecione Avançar
Na guia Principal, selecione o aplicativo que foi criado na Etapa 1.
Selecione Avançar e, em seguida, Criar.
Criar uma chave
No painel Cofre de Chaves, selecione Chaves e, em seguida, selecione a opção Gerar/Importar. Isso abre o painel Criar uma chave. Insira um nome para o cofre de chaves. Selecione a opção Gerar e insira um nome exclusivo para a chave. O Conector do SQL Server exige que o nome da chave use somente os caracteres "a-z", "A-Z", "0-9" e "-", com um limite de 26 caracteres.
Use o tipo de chave RSA e o tamanho da chave RSA 2048. No momento, o EKM oferece suporte apenas a uma chave RSA. Defina as datas de ativação e término conforme apropriado e defina Habilitado como Sim.
Práticas recomendadas
Para garantir a recuperação rápida da chave e poder acessar seus dados fora do Azure, recomendamos as seguintes melhores práticas:
Crie a chave de criptografia localmente, em um dispositivo HSM (módulo de segurança de hardware) local. Certifique-se de usar uma chave RSA assimétrica 2048 ou 3072 para que ela tenha suporte do SQL Server.
Importe a chave de criptografia para o Azure Key Vault. Esse processo é descrito nas seções a seguir.
Antes de usar a chave em seu Azure Key Vault pela primeira vez, faça um backup da chave do Azure Key Vault usando o
Backup-AzureKeyVaultKey
PowerShell cmdlet.Sempre que fizer qualquer alteração na chave (por exemplo, adicionar ACLs, marcas ou atributos de chave), faça outro backup da chave do Azure Key Vault.
Observação
Fazer backup de uma chave é uma operação de chave do Azure Key Vault que retorna um arquivo que pode ser salvo em qualquer lugar.
Usar o Conector do SQL Server para Azure Key Vault atrás de um firewall ou servidor proxy pode afetar o desempenho se o tráfego for atrasado ou bloqueado. Familiarize-se com Acesso do Azure Key Vault atrás de um firewall para garantir que as regras corretas estejam em vigor.
Opcional - Configure um HSM (Módulo de Segurança de Hardware) gerenciado do Azure Key Vault
O HSM (Módulo de Segurança de Hardware) Gerenciado do Azure Key Vault tem suporte para SQL Server e SQL Server em VMs (Máquinas Virtuais) do Azure ao usar a versão mais recente do SQL Server Connector, assim como o SQL do Azure. O HSM gerenciado é um serviço de HSM totalmente gerenciado, altamente disponível e de locatário único. O HSM gerenciado fornece uma base segura para operações criptográficas e armazenamento de chaves. O HSM gerenciado é projetado para atender aos mais rigorosos requisitos de segurança e conformidade.
Na etapa 2, aprendemos a criar um cofre de chaves e uma chave no Azure Key Vault. Opcionalmente, você pode usar um HSM Gerenciado do Azure Key Vault para armazenar ou criar uma chave a ser usada com o Conector do SQL Server. Estas são as etapas:
Criar um HSM gerenciado do Azure Key Vault. Isso pode ser feito usando o portal do Azure pesquisando o serviço HSM Gerenciado do Azure Key Vault e criando o novo recurso ou usando a CLI do Azure, o PowerShell ou um modelo do ARM.
Ative o HSM Gerenciado. Somente os administradores designados que foram atribuídos durante a criação do HSM gerenciado podem ativar o HSM. Isso pode ser feito selecionando o recurso HSM Gerenciado no portal do Azure, selecionando Baixar Domínio de Segurança no menu Visão Geral do recurso. Em seguida, siga um dos guias de início rápido para ativar o HSM Gerenciado.
Conceda permissões para a entidade de serviço do Microsoft Entra para acessar o HSM gerenciado. A Administrador do HSM Gerenciado não concede permissões para criar uma chave. Semelhante à etapa 2, o aplicativo EKM precisa da função Usuário de Criptografia do HSM Gerenciado ou Usuário de Criptografia do Serviço de Criptografia do HSM Gerenciado para executar operações de encapsulamento e desencapsulamento. Escolha o tipo Aplicativo empresarial ao adicionar a entidade de segurança para a atribuição de função. Para obter mais informações, consulte Funções internas do RBAC local para HSM gerenciado.
No menu do serviço HSM Gerenciado do Azure Key Vault, em Configuração, selecione Chaves. Na janela Chaves, selecione Gerar/Importar/Restaurar Backup para criar uma chave ou importar uma chave existente.
Observação
Ao criar uma credencial para acessar o HSM Gerenciado, a identidade é
<name of Managed HSM>.managedhsm.azure.net
, que pode ser encontrado na Visão geral do HSM Gerenciado do Azure Key Vault como o URI do HDM no portal do Azure.A troca automática de chave é suportada no HSM gerenciado do Azure Key Vault. Para saber mais, confira Configurar rotação automática de chave no HSM gerenciado do Azure.
O SQL Server Connector versão 15.0.2000.440 ou posterior é necessário para dar suporte ao HSM Gerenciado do Azure Key Vault.
O HSM gerenciado permite conexões de pontos de extremidade privados. Para obter mais informações, consulte Integrar o HSM gerenciado com o Link Privado do Azure. Nessa configuração, a opção de bypass de serviço confiável da Microsoft deve ser habilitada para a configuração de Redes de HSM gerenciado do Azure Key Vault.
Etapa 3: Instalação do Conector do SQL Server
Baixe o Conector do SQL Server no Centro de Download da Microsoft. O download deve ser feito pelo administrador do computador SQL Server.
Observação
- O Conector do SQL Server versões 1.0.0.440 e anteriores foram substituído e não têm mais suporte em ambientes de produção e usando as instruções na página Manutenção e Solução de Problemas do Conector do SQL Server em Atualização do Conector do SQL Server.
- Da versão 1.0.3.0 em diante, o Conector do SQL Server relata mensagens de erro relevantes para os logs de eventos do Windows para solução de problemas.
- Da versão 1.0.4.0 e m diante, há suporte para nuvens privadas do Azure, incluindo o Azure operado pela 21Vianet, o Azure Alemanha e a Governança do Azure.
- Há uma alteração da falha na versão 1.0.5.0, em termos do algoritmo de impressão digital. Você poderia enfrentar falhas de restauração do banco de dados após atualizar para a 1.0.5.0. Para saber mais, confira o artigo da base de dados de conhecimento 447099.
- A partir da versão 1.0.5.0 (carimbo de data/hora: setembro de 2020), o Conector do SQL Server dá suporte à filtragem de mensagens e lógica de repetição de solicitação de rede.
- A partir da versão 1.0.5.0 atualizada (carimbo de data/hora: novembro de 2020), o Conector do SQL Server é compatível com as chaves RSA 2048, RSA 3072, RSA-HSM 2048 e RSA-HSM 3072.
- A partir da versão 1.0.5.0 atualizada (carimbo de data/hora: novembro de 2020), você pode fazer referência a uma versão de chave específica no Azure Key Vault.
Por padrão, o conector é instalado em C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault
. Esse local pode ser alterado durante a instalação. Se alterá-lo, ajuste os scripts na próxima seção.
Não há interface para o Conector, mas se ele for instalado com êxito, o Microsoft.AzureKeyVaultService.EKM.dll
será instalado no computador. Esse assembly é o DLL do provedor EKM criptográfico que precisa ser registrado com o SQL Server usando a instrução CREATE CRYPTOGRAPHIC PROVIDER
.
A instalação do Conector do SQL Server também permite que você baixe opcionalmente os scripts de exemplo para criptografia do SQL Server.
Para ver explicações de códigos de erro, definições de configuração ou tarefas de manutenção do SQL Server Connector, confira:
- R. Instruções de manutenção do Conector do SQL Server
- C. Explicações de código de erro do Conector do SQL Server
Etapa 4: adicionar chave do registro para oferecer suporte ao provedor EKM
Aviso
A modificação do registro deve ser realizada por usuários que saibam exatamente o que estão fazendo. Problemas sérios podem ocorrer se você modificar o Registro incorretamente. Para proteção acrescida, faça backup do Registro antes de modificá-lo. Em caso de problema, é possível restaurar o registro.
Certifique-se de que o SQL Server esteja instalado e em execução.
Execute regedit para abrir o Editor do Registro.
Criar uma chave do Registro
SQL Server Cryptographic Provider
noHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
. O caminho completo éHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider
.Clique com o botão direito do mouse na chave
SQL Server Cryptographic Provider
do Registro e selecione Permissões.Conceda permissões de Controle total na chave
SQL Server Cryptographic Provider
do registro para a conta de usuário que executa o serviço SQL Server.Selecione Aplicar e, em seguida, OK.
Feche o Editor do Registro e reinicie o serviço SQL Server.
Observação
Se você usar TDE com EKM ou Azure Key Vault em uma instância de cluster de failover, deverá concluir uma etapa adicional para adicionar
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider
à rotina de ponto de verificação do registro de cluster, para que o registro possa ser sincronizado entre os nós. A sincronização facilita a recuperação do banco de dados após o failover e a rotação de chaves.Para adicionar a chave do registro à rotina de ponto de verificação do registro de cluster, no PowerShell, execute o seguinte comando:
Add-ClusterCheckpoint -RegistryCheckpoint "SOFTWARE\Microsoft\SQL Server Cryptographic Provider" -Resourcename "SQL Server"
Etapa 5: configurar o SQL Server
Confira B. Perguntas frequentes para ver uma observação sobre os níveis de permissão mínimos necessários para cada ação nesta seção.
Configurar o banco de dados master
Execute sqlcmd ou abra o SQL Server Management Studio.
Configure o SQL Server para usar o EKM executando o seguinte script do Transact-SQL:
-- Enable advanced options. USE master; GO EXEC sp_configure 'show advanced options', 1; GO RECONFIGURE; GO -- Enable EKM provider EXEC sp_configure 'EKM provider enabled', 1; GO RECONFIGURE;
Registre o Conector do SQL Server como um provedor EKM com o SQL Server.
Crie um provedor criptográfico usando o Conector do SQL Server, que é um provedor EKM do Azure Key Vault. Neste exemplo, o nome do provedor é
AzureKeyVault_EKM
.CREATE CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM FROM FILE = 'C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault\Microsoft.AzureKeyVaultService.EKM.dll'; GO
Observação
O tamanho do caminho do arquivo não pode ultrapassar 256 caracteres.
Configure uma credencial do SQL Server para um logon do SQL Server para usar o cofre de chaves.
Uma credencial deve ser adicionada a cada logon que executará a criptografia usando uma chave do cofre de chaves. Isso pode incluir:
Um logon do administrador SQL Server que usa o cofre de chaves para instalar e gerenciar cenários de criptografia do SQL Server.
Outros logons do SQL Server que podem habilitar o TDE ou outros recursos de criptografia do SQL Server.
Há um mapeamento individualizado entre as credenciais e logons. Ou seja, cada logon deve ter uma credencial exclusiva.
Modifique o script Transact-SQL abaixo das seguintes maneiras:
Edite o argumento
IDENTITY
(DocsSampleEKMKeyVault
) para apontar para o Cofre de Chaves do Azure.- Se estiver usando o Azure global, substitua o argumento
IDENTITY
pelo nome do seu Azure Key Vault da Etapa 2: Criar um cofre de chaves. - Se estiver usando uma nuvem do Azure privada, (por exemplo, a Governança do Azure, o Microsoft Azure operado pela 21Vianet ou o Azure Alemanha), substitua o argumento
IDENTITY
pelo URI do Cofre que é retornado na etapa 3 da seção Criar um cofre de chaves e uma chave usando o PowerShell. Não incluahttps://
no URI do cofre de chaves.
- Se estiver usando o Azure global, substitua o argumento
Substitua a primeira parte do argumento
SECRET
pela ID do Cliente do Microsoft Entra da Etapa 1: configurar uma entidade de serviço do Microsoft Entra. Nesse exemplo, a ID do Cliente éd956f6b9xxxxxxx
.Importante
Remova os hifens da ID do Aplicativo (Cliente).
Conclua a segunda parte do argumento
SECRET
com o Segredo do Cliente da Etapa 1: configurar uma entidade de serviço do Microsoft Entra. Neste exemplo, o Segredo do Cliente éyrA8X~PldtMCvUZPxxxxxxxx
. A sequência final para o argumentoSECRET
será uma sequência longa de letras e números, sem hifens (exceto para a seção Segredo do cliente, caso o Segredo do cliente contenha hifens).USE master; CREATE CREDENTIAL sysadmin_ekm_cred WITH IDENTITY = 'DocsSampleEKMKeyVault', -- for public Azure -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.usgovcloudapi.net', -- for Azure Government -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.azure.cn', -- for Microsoft Azure operated by 21Vianet -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.microsoftazure.de', -- for Azure Germany -- WITH IDENTITY = '<name of Managed HSM>.managedhsm.azure.net', -- for Managed HSM (HSM URI in the Azure portal resource) --<----Application (Client) ID ---><--Microsoft Entra app (Client) ID secret--> SECRET = 'd956f6b9xxxxxxxyrA8X~PldtMCvUZPxxxxxxxx' FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM; -- Add the credential to the SQL Server administrator's domain login ALTER LOGIN [<domain>\<login>] ADD CREDENTIAL sysadmin_ekm_cred;
Para obter um exemplo do uso de variáveis para o argumento
CREATE CREDENTIAL
e remover programaticamente os hifens da ID do Cliente, confira CREATE CREDENTIAL.Abra sua chave do Azure Key Vault em sua instância do SQL Server.
Se você criou uma nova chave ou importou uma chave assimétrica conforme descrito na Etapa 2: Criar um cofre de chaves, precisará abrir a chave. Abra a chave fornecendo o nome dela no script Transact-SQL a seguir.
Importante
Certifique-se de primeiro concluir os pré-requisitos do Registro para esta etapa.
- Substitua
EKMSampleASYKey
com o nome que deseja que a chave tenha no SQL Server. - Substitua
ContosoRSAKey0
pelo nome da chave no Azure Key Vault ou no HSM gerenciado. Abaixo está um exemplo de uma chave sem versão.
CREATE ASYMMETRIC KEY EKMSampleASYKey FROM PROVIDER [AzureKeyVault_EKM] WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0', CREATION_DISPOSITION = OPEN_EXISTING;
Começando na versão atualizada 1.0.5.0 do Conector do SQL Server, você pode se referir a uma versão de chave específica no Azure Key Vault:
CREATE ASYMMETRIC KEY EKMSampleASYKey FROM PROVIDER [AzureKeyVault_EKM] WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379', CREATION_DISPOSITION = OPEN_EXISTING;
No script de exemplo anterior,
1a4d3b9b393c4678831ccc60def75379
representa a versão específica da chave que vai ser usada. Se você usar esse script, não importa se você atualizar a chave para uma nova versão. A versão da chave (por exemplo)1a4d3b9b393c4678831ccc60def75379
sempre vai ser usada para as operações de banco de dados.- Substitua
Crie um novo logon usando a chave assimétrica no SQL Server que você criou na etapa anterior.
--Create a Login that will associate the asymmetric key to this login CREATE LOGIN TDE_Login FROM ASYMMETRIC KEY EKMSampleASYKey;
Crie um logon da chave assimétrica no SQL Server. Libere o mapeamento de credencial da Etapa 5: configurar o SQL Server para que as credenciais possam ser mapeadas para o novo logon.
--Now drop the credential mapping from the original association ALTER LOGIN [<domain>\<login>] DROP CREDENTIAL sysadmin_ekm_cred;
Altere o novo logon e mapeie as credenciais do EKM para o novo logon.
--Now add the credential mapping to the new Login ALTER LOGIN TDE_Login ADD CREDENTIAL sysadmin_ekm_cred;
Configure o banco de dados de usuário para ser criptografado
Crie um banco de dados de teste que será criptografado com a chave do Azure Key Vault.
--Create a test database that will be encrypted with the Azure Key Vault key CREATE DATABASE TestTDE;
Crie uma chave de criptografia de banco de dados usando o
ASYMMETRIC KEY
(EKMSampleASYKey
).USE <DB Name>; --Create an ENCRYPTION KEY using the ASYMMETRIC KEY (EKMSampleASYKey) CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER ASYMMETRIC KEY EKMSampleASYKey;
Criptografe o banco de dados de teste. Habilite o TDE definindo
ENCRYPTION ON
.--Enable TDE by setting ENCRYPTION ON ALTER DATABASE TestTDE SET ENCRYPTION ON;
Detalhes do registro
Execute a seguinte consulta Transact-SQL no banco de dados
master
para mostrar a chave assimétrica usada.SELECT name, algorithm_desc, thumbprint FROM sys.asymmetric_keys;
A instrução retorna:
name algorithm_desc thumbprint EKMSampleASYKey RSA_2048 <key thumbprint>
No banco de dados de usuário (
TestTDE
), execute a seguinte consulta Transact-SQL para mostrar a chave de criptografia usada.SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint FROM sys.dm_database_encryption_keys WHERE database_id = DB_ID('TestTDE');
A instrução retorna:
encryptor_type encryption_state_desc encryptor_thumbprint ASYMMETRIC KEY ENCRYPTED <key thumbprint>
Limpar
Limpe os objetos de teste. Exclua todos os objetos criados neste script de teste.
-- CLEAN UP USE master; GO ALTER DATABASE [TestTDE] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DROP DATABASE [TestTDE]; GO ALTER LOGIN [TDE_Login] DROP CREDENTIAL [sysadmin_ekm_cred]; DROP LOGIN [TDE_Login]; GO DROP CREDENTIAL [sysadmin_ekm_cred]; GO USE master; GO DROP ASYMMETRIC KEY [EKMSampleASYKey]; DROP CRYPTOGRAPHIC PROVIDER [AzureKeyVault_EKM]; GO
Para ver scripts de exemplo, confira o blog em Transparent Data Encryption e Gerenciamento Extensível de Chaves do SQL Server com o Azure Key Vault.
A chave do Registro
SQL Server Cryptographic Provider
não é limpa automaticamente depois que uma chave ou todas as chaves EKM são excluídas. É necessário limpá-la manualmente. A limpeza da chave do Registro deve ser feita com extremo cuidado, uma vez que a limpeza prematura do registro pode quebrar a funcionalidade do EKM. Para limpar a chave do Registro, exclua a chaveSQL Server Cryptographic Provider
do Registro emHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
.
Solução de problemas
Se a chave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider
do Registro não for criada ou as permissões necessárias não forem concedidas, a seguinte instrução DDL falhará:
CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0',
CREATION_DISPOSITION = OPEN_EXISTING;
Msg 33049, Level 16, State 2, Line 65
Key with name 'ContosoRSAKey0' does not exist in the provider or access is denied. Provider error code: 2058. (Provider Error - No explanation is available, consult EKM Provider for details)
Segredos do cliente que estão prestes a expirar
Se a credencial tiver um segredo de cliente prestes a expirar, um novo segredo poderá ser atribuído ao valor expirado.
Atualize o segredo originalmente criado na Etapa 1: configurar uma entidade de serviço do Microsoft Entra.
Altere a credencial usando a mesma identidade e o novo segredo usando o seguinte código. Substitua
<New Secret>
pelo seu novo segredo:ALTER CREDENTIAL sysadmin_ekm_cred WITH IDENTITY = 'DocsSampleEKMKeyVault', SECRET = '<New Secret>';
Reinicie o serviço SQL Server.
Observação
Se você estiver usando o EKM em um grupo de disponibilidade (AG), será necessário alterar a credencial e reiniciar o serviço do SQL Server em todos os nós do AG.
Substitua a chave assimétrica por uma nova chave AKV ou uma nova versão da chave AKV
Observação
- Ao girar manualmente uma chave AKV, o SQL Server oferece suporte a uma chave AKV sem versão ou a chave versionada e não há necessidade de usar uma chave AKV diferente.
- A chave AKV original pode ser girada por meio da criação de uma nova versão que pode substituir a chave anterior criada no SQL Server.
- Para rotação manual de chaves, uma nova chave assimétrica do SQL Server deve ser criada referente à chave sem versão ou à chave versionada que foi girada no AKV. Para a nova chave assimétrica do SQL Server, a chave AKV sem versão será escolhida automaticamente usando a versão de chave mais alta no AKV. Para a chave versionada, é necessário indicar a versão mais alta no AKV usando a sintaxe
WITH PROVIDER_KEY_NAME = <key_name>/<version>
. Você pode alterar a chave de criptografia de banco de dados para criptografar novamente com a nova chave assimétrica. O mesmo nome de chave (versionado ou sem versão) pode ser usado com a política de rotação do AKV. Para a chave versionada, a versão atual deve ser adicionada. Para chave sem versão, use o mesmo nome de chave.
O SQL Server não tem um mecanismo para girar automaticamente a chave assimétrica usada para TDE. As etapas para substituir uma chave assimétrica manualmente são as seguintes.
A credencial usada em nossa configuração inicial (
sysadmin_ekm_cred
) também pode ser reutilizada para a rotação de chaves. Opcionalmente, crie uma nova credencial para a nova chave assimétrica.CREATE CREDENTIAL <new_credential_name> WITH IDENTITY = <key vault>, SECRET = 'existing/new secret' FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM;
Adicione a credencial à entidade de segurança:
ALTER LOGIN [domain\userName]; ADD CREDENTIAL <new_credential_name>;
Crie a nova chave assimétrica com base na nova chave (depois de girar a chave). A nova chave pode ser uma chave sem versão (
ContosoRSAKey0
em nosso exemplo) ou uma chave versionada (ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379
,1a4d3b9b393c4678831ccc60def75379
onde é a versão da chave atualizada no AKV):CREATE ASYMMETRIC KEY <new_ekm_key_name> FROM PROVIDER [AzureKeyVault_EKM] WITH PROVIDER_KEY_NAME = <new_key_from_key_vault>, CREATION_DISPOSITION = OPEN_EXISTING;
Crie um novo logon da nova chave assimétrica:
CREATE LOGIN <new_login_name> FROM ASYMMETRIC KEY <new_ekm_key_name>;
Descarte a credencial da entidade de segurança:
ALTER LOGIN [domain\username] DROP CREDENTIAL <new_credential_name>;
Mapeie a credencial AKV para o novo logon:
ALTER LOGIN <new_login_name>; ADD CREDENTIAL <new_credential_name>;
Altere a chave de criptografia de banco de dados (DEK) para criptografar novamente com a nova chave assimétrica:
USE [databaseName]; GO ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY <new_ekm_key_name>;
Você pode verificar a nova chave assimétrica e a chave de criptografia usada no banco de dados:
SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint FROM sys.dm_database_encryption_keys WHERE database_id = DB_ID('databaseName');
Essa impressão digital deve corresponder à chave do Registro sob o caminho
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider\Azure Key Vault\<key_vault_url>\<thumbprint>
e fornecer a vocêKeyUri
para sua chave girada.
Importante
A rotação do protetor de TDE lógico para um servidor significa alternar para uma nova chave assimétrica que protege a chave de criptografia do bancos de dados (DEK). A rotação de chaves é uma operação online e deve demorar apenas alguns segundos para ser concluída, porque isso somente descriptografa e criptografa novamente o DEK, não o banco de dados inteiro.
Não exclua as versões anteriores da chave após uma substituição. Quando as chaves são substituídas, alguns dados ainda são criptografados com as chaves anteriores, como backups de banco de dados mais antigos, arquivos de log virtual (VLF) e arquivos de log de transações. As chaves anteriores também podem ser necessárias para uma recuperação ou restauração de banco de dados.