Partilhar via


Configurar o Gerenciamento Extensível de Chaves TDE do SQL Server usando o Cofre de Chaves do Azure

Aplica-se a:SQL Server

Neste artigo, você instala e configura o SQL Server Connector para o Azure Key Vault.

Observação

Microsoft Entra ID era anteriormente conhecido como Azure Ative 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, começando com a Atualização Cumulativa 12 do SQL Server 2022 (16.x). 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ê atendeu aos seguintes pré-requisitos:

Observação

No SQL Server 2022 (16.x) 14 e versões posteriores, o SQL Server no Linux dá suporte ao Gerenciamento Extensível de Chaves TDE com o Azure Key Vault. As etapas 3 e 4 deste guia não são necessárias para o SQL Server no Linux.

Etapa 1: Configurar um principal de serviço do Microsoft Entra

Para conceder permissões de acesso à instância do SQL Server ao cofre de chaves do Azure, precisa-se de uma conta principal de serviço no Microsoft Entra ID.

  1. Entre no portal do Azuree execute uma das seguintes ações:

    • Selecione o botão Microsoft Entra ID.

      Captura de ecrã do painel de serviços do Azure.

    • Selecione Mais serviços e, em seguida, no painel Todos os serviços, digite Microsoft Entra ID.

  2. Registre um aplicativo com o Microsoft Entra ID fazendo o seguinte. Para obter instruções detalhadas passo a passo, consulte a seção Obter uma identidade para o aplicativo da postagem do blog Azure Key Vault, Azure Key Vault – Step by Step.

    1. Na seção Gerenciar do recurso ID do Microsoft Entra, selecione Registros de aplicativo.

      Captura de ecrã da página Descrição Geral do Microsoft Entra ID no portal do Azure.

    2. Na página Registos na aplicação, selecione Novo registo.

      Captura de ecrã do painel Registos de aplicações no portal do Azure.

    3. No painel Registrar um aplicativo, insira o nome voltado para o usuário do aplicativo e selecione Registrar.

      Captura de tela do painel Registrar um aplicativo.

    4. No painel esquerdo, selecione Certificados & segredos de cliente > Segredos de cliente > Novo segredo de cliente.

      Captura de ecrã do painel Certificados & segredos da Aplicação no portal do Azure.

    5. Em Adicionar um segredo do cliente, insira uma descrição e uma expiração apropriada e selecione Adicionar. Não pode escolher um período de validade superior a 24 meses. Para obter mais informações, consulte Adicionar um segredo do cliente.

      Captura de tela da seção Adicionar um segredo do cliente para o Aplicativo no portal do Azure.

    6. No painel Certificados & segredos, em Valor, selecione o botão Copiar ao lado do valor do segredo da aplicação a ser usado para criar uma chave assimétrica no SQL Server.

      Captura de ecrã do valor secreto no portal do Azure.

    7. No painel esquerdo, selecione Visão geral e, em seguida, na caixa ID do aplicativo (cliente), copie o valor a ser usado para criar uma chave assimétrica no SQL Server.

      Captura de tela do valor ID do aplicativo (cliente) no painel Visão geral.

Etapa 2: Criar um cofre de chaves

Selecione o método que deseja usar para criar um cofre de chaves.

Observação

Apenas o Azure Key Vault e o Azure Key Vault Managed HSM são suportados. O Azure Cloud HSM não é suportado.

Criar um cofre de chaves usando o portal do Azure

Você pode usar o portal do Azure para criar o cofre de chaves e, em seguida, adicionar um principal do Microsoft Entra a ele.

  1. Crie um grupo de recursos.

    Todos os recursos do Azure que você cria por meio do portal do Azure devem estar contidos em um grupo de recursos, que você cria para abrigar seu cofre de chaves. O nome do recurso neste exemplo é DocsSampleRG. Escolha o seu próprio grupo de recursos e o nome do cofre de chaves, porque todos os nomes de cofres de chaves devem ser globalmente exclusivos.

    No painel Criar um grupo de recursos, em Detalhes do projeto, insira os valores e selecione Revisar + criar.

    Captura de ecrã do painel Criar um grupo de recursos no portal do Azure.

  2. No portal do Azure, procure 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 Noções básicas . Insira os valores apropriados para a guia. Nós também recomendamos ativar a proteção contra purga.

    Captura de ecrã do painel Criar cofre de chaves no portal do Azure.

  3. Na guia de configuração do Access , tem a opção de selecionar controlos de acesso baseados em função do Azure ou uma política de acesso do Cofre . Analisamos ambas as opções, mas a opção de controle de acesso baseado em função do Azure é recomendada. Para mais informações, consulte Visão geral do modelo de acesso.

    Captura de ecrã do painel Criar cofre de chaves e do separador Configuração de Acesso no portal do Azure.

  4. Você pode deixar a guia Rede no padrão ou pode configurar as configurações de rede para o cofre de chaves. Se você estiver usando um firewall com o cofre de chaves, a opção Permitir que serviços confiáveis da Microsoft ignorem o firewall deverá ser habilitada, a menos que você esteja usando conexões de ponto de extremidade privadas . Para obter mais informações, consulte Configurar firewalls e redes virtuais do Azure Key Vault.

  5. Selecione Revisão + criar e crie o cofre de chaves.

Controle de acesso baseado em funções no Azure

O método recomendado é usar RBAC (controle de acesso baseado em função) do Azure para atribuir permissões ao cofre de chaves. Esse método permite que você atribua 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 só conseguir utilizar a política de acesso, pode ignorar esta secção e ir para a secção política de acesso ao Vault. Para obter mais informações sobre as permissões RBAC do Cofre de Chaves do Azure, consulte funções internas incorporadas do Azure para operações do plano de dados do Cofre de Chaves.

  1. Vá ao recurso do cofre de chaves que criaste e seleciona a definição Controle de acesso (IAM).

  2. Selecione Adicionar>Adicionar atribuição de função.

    Captura de ecrã do botão Adicionar atribuição de função no painel Controlo de acesso (IAM) no portal do Azure.

  3. O aplicativo EKM precisa da função Key Vault Crypto Service Encryption User para executar operações de encapsulamento e desempacotamento. Pesquise por Key Vault Crypto Service Encryption User e selecione a função. Selecione Avançar.

    Captura de ecrã a mostrar a seleção de uma atribuição de função no portal do Azure.

  4. Na guia Membros, selecione a opção Selecionar membros e procure o aplicativo Microsoft Entra criado na Etapa 1. Selecione o aplicativo e, em seguida, o botão Selecionar.

    Captura de ecrã do painel Selecionar membros para adicionar uma atribuição de função no portal do Azure.

  5. Selecione Revisar e atribuir duas vezes para concluir a atribuição de função.

  6. O utilizador que cria a chave precisa da função Administrador do Cofre de Chaves. Procure Administrador do Cofre de Chaves e selecione o papel. Selecione Avançar.

  7. Assim como as etapas anteriores, adicione o membro que está criando a chave e atribua a função.

Política de acesso ao Vault

Observação

Se estiver a utilizar a opção de controlo de acesso baseado na função do Azure , pode ignorar esta secção. Se estiver a alterar o modelo de permissão, pode fazê-lo acedendo ao menu de configuração do Access do cofre de chaves. Verifique se você tem as permissões corretas para gerenciar o cofre de chaves. Para obter mais informações, consulte Habilitar permissões do Azure RBAC no Key Vault.

  1. No separador de configuração do Access, selecione a política de acesso ao Vault. Se estiver a utilizar um Cofre de chaves existente, pode selecionar o menu Políticas de acesso no recurso Cofre de chaves e selecionar Criar.

  2. 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 Desempacotar Chave e Encapsular Chave das opções de Operações Criptográficas. Selecione Próximo

    Captura de ecrã da ligação Adicionar Política de Acesso no painel Políticas de acesso.

  3. Na aba Principal, selecione a aplicação que foi criada na Etapa 1.

    Captura de ecrã da caixa de pesquisa da aplicação no painel Principal.

  4. Selecione Seguinte e depois Criar.

Criar uma chave

  1. 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 de cofre de chaves. Selecione a opção Gerar e insira um nome para a chave. O SQL Server Connector requer que o nome da chave use apenas os caracteres "a-z", "A-Z", "0-9" e "-", com um limite de 26 caracteres.

  2. Use o tipo de chave RSA e o tamanho de chave RSA como 2048 . Atualmente, o EKM suporta apenas uma chave RSA. Defina as datas de ativação e expiração conforme apropriado e defina Ativado como Sim.

    Captura de ecrã do painel Criar chave.

Melhores práticas

Para garantir a recuperação rápida de chaves e poder acessar seus dados fora do Azure, recomendamos as seguintes práticas recomendadas:

  • Crie sua chave de criptografia localmente em um dispositivo HSM (módulo de segurança de hardware) local. Certifique-se de usar uma chave RSA 2048 ou 3072 assimétrica para que ela seja suportada pelo SQL Server.

  • Importe a chave de criptografia para seu cofre de chaves do Azure. Esse processo é descrito nas próximas seções.

  • Antes de usar a chave em seu cofre de chaves do Azure pela primeira vez, faça um backup de chave do cofre de chaves do Azure usando o cmdlet Backup-AzureKeyVaultKey PowerShell.

  • Sempre que você fizer alterações na chave (por exemplo, adicionando ACLs, tags ou atributos de chave), certifique-se de fazer outro backup de chave do cofre de chaves do Azure.

    Observação

    O backup de uma chave é uma operação de chave do Cofre de Chaves do Azure que retorna um arquivo que pode ser salvo em qualquer lugar.

    Usar o SQL Server Connector para Azure Key Vault atrás de um firewall ou servidor proxy pode afetar o desempenho se o tráfego estiver atrasado ou bloqueado. Familiarize-se com Acesso ao Key Vault do Azure por trás de um firewall para garantir que as regras corretas estejam em vigor.

Opcional - Configurar um HSM gerenciado do Azure Key Vault (Módulo de Segurança de Hardware)

Azure Key Vault Managed HSM (Hardware Security Module) é suportado por SQL Server e SQL Server em Máquinas Virtuais (VMs) do Azure ao usar a versão mais recente do SQL Server Connector, assim como o Azure SQL. O Managed HSM é um serviço HSM de locatário único, altamente disponível e totalmente gerido. O HSM gerenciado fornece uma base segura para operações criptográficas e armazenamento de chaves. O HSM gerenciado foi projetado para atender aos mais rigorosos requisitos de segurança e conformidade.

Na etapa 2, aprendemos como criar um cofre de chaves e definir 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 SQL Server Connector. Aqui estão os passos:

  1. Crie 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 oda CLI do Azure, PowerShellou um modelo ARM .

  2. 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 gerido no portal do Azure, onde pode selecionar Download Security Domain no menu Visão Geral do recurso. Em seguida, siga um dos guias de início rápido para ativar o seu HSM gerenciado.

  3. Conceda permissões para que o principal de serviço Microsoft Entra aceda ao HSM Gerido. A função Managed HSM Administrator não concede permissões para criar uma chave. Semelhante ao da etapa 2,o aplicativo EKM precisa da função Managed HSM Crypto User ou Managed HSM Crypto Service Encryption User para executar operações de encapsulamento e desempacotamento. Escolha o tipo de aplicação empresarial ao adicionar o principal para a atribuição de função. Para obter mais informações, consulte funções internas locais do RBAC para HSM gerenciado.

  4. 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 aceder ao HSM gerido, a identidade é <name of Managed HSM>.managedhsm.azure.net, que pode ser encontrada no Visão Geral do HSM gerido no Azure Key Vault, como o URI do HSM no portal do Azure.

    Há suporte para RSA-HSM_2048 e RSA-HSM_3072 de algoritmos a partir da Atualização Cumulativa 13 do SQL Server 2022 (16.x).

    A rotação automática de chaves é suportada no Azure Key Vault Managed HSM. Para obter mais informações, consulte Configurar a rotação automática das chaves no Azure Managed HSM.

    SQL Server Connector versão 15.0.2000.440 ou posterior é necessária para dar suporte ao Azure Key Vault Managed HSM.

    O HSM gerenciado oferece suporte a conexões de ponto de extremidade privadas. Para obter mais informações, consulte Integrar HSM gerido com Azure Private Link. Nessa configuração, a opção de desvio de serviço confiável da Microsoft deve ser habilitada para a configuração de Rede do Azure Key Vault Managed HSM.

Etapa 3: Instalar o SQL Server Connector

Transfira o SQL Server Connector a partir do Centro de Transferências da Microsoft. O download deve ser feito pelo administrador do computador SQL Server.

Observação

  • As versões 1.0.0.440 e anteriores do SQL Server Connector foram substituídas e não têm mais suporte em ambientes de produção, sendo necessário seguir as instruções na página SQL Server Connector Maintenance & Troubleshooting sob Atualização do SQL Server Connector.
  • A partir da versão 1.0.3.0, o SQL Server Connector relata mensagens de erro relevantes para os logs de eventos do Windows para solução de problemas.
  • A partir da versão 1.0.4.0, há suporte para nuvens privadas do Azure, incluindo o Azure operado pela 21Vianet, Azure Alemanha e Azure Government.
  • Há uma mudança radical na versão 1.0.5.0 em termos do algoritmo de impressão digital. Você pode enfrentar falhas de restauração do banco de dados após a atualização para 1.0.5.0. Para obter mais informações, consulte Erro 33111 ao restaurar backups de versões mais antigas do SQL Server Connector para Microsoft Azure Key Vault.
  • A partir da versão 1.0.5.0 (TimeStamp: setembro de 2020), o SQL Server Connector oferece suporte à filtragem de mensagens e à lógica de repetição de solicitações de rede.
  • A partir da versão atualizada 1.0.5.0 (TimeStamp: novembro de 2020), o SQL Server Connector oferece suporte às chaves RSA 2048, RSA 3072, RSA-HSM 2048 e RSA-HSM 3072.
  • A partir da versão atualizada 1.0.5.0 (Carimbo de data/hora: novembro de 2020), você pode consultar uma versão de chave específica no Cofre de Chaves do Azure.

Captura de tela do assistente de instalação do SQL Server Connector.

Por padrão, o conector é instalado em C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault. Esta localização pode ser alterada durante a configuração. Se alterares, ajusta os scripts na próxima secção.

Não há interface para o conector, mas se ele for instalado com êxito, o Microsoft.AzureKeyVaultService.EKM.dll será instalado na máquina. Este assembly é a DLL do provedor de EKM criptográfico que precisa ser registrada no SQL Server usando a declaração CREATE CRYPTOGRAPHIC PROVIDER.

A instalação do SQL Server Connector também permite que, opcionalmente, você baixe scripts de exemplo para criptografia do SQL Server.

Para exibir explicações de código de erro, definições de configuração ou tarefas de manutenção para o SQL Server Connector, consulte:

Etapa 4: Adicionar chave do Registro para dar suporte ao provedor EKM

Advertência

A modificação do registro deve ser realizada por usuários que sabem exatamente o que estão fazendo. Poderão ocorrer problemas graves se modificar o registo incorretamente. Para maior proteção, faça backup do registro antes de modificá-lo. Você pode restaurar o registro se ocorrer um problema.

A modificação do registro deve ser feita pelo administrador do computador SQL Server.

  1. Verifique se o SQL Server está instalado e em execução.

  2. Execute regedit para abrir o Editor do Registro.

  3. Crie uma chave de registo SQL Server Cryptographic Provider no HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft. O caminho completo é HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider.

  4. Clique com o botão direito do rato na chave de registo SQL Server Cryptographic Provider e, em seguida, selecione Permissões.

  5. Conceda permissões de Controle Total na chave do Registro SQL Server Cryptographic Provider à conta de usuário que executa o serviço do SQL Server.

    Captura de ecrã da chave de registo EKM no Editor de registo.

  6. Selecione Aplicar e, em seguida, OK.

  7. Feche o Editor do Registro e reinicie o serviço SQL Server.

    Observação

    Se utilizar TDE com EKM ou Azure Key Vault numa instância de cluster de failover, deverá realizar uma etapa adicional para adicionar HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider à rotina do ponto de verificação do registo do cluster, para que o registo possa sincronizar 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 do Ponto de Verificação do Registro do 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

Para obter uma observação sobre os níveis mínimos de permissão necessários para cada ação nesta seção, consulte B. Perguntas freqüentes.

Configurar o banco de dados master

  1. Execute sqlcmd ou abra o SQL Server Management Studio.

  2. Configure o SQL Server para usar o EKM executando o seguinte script 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;
    
  3. Registre o SQL Server Connector como um provedor EKM com o SQL Server.

    Crie um provedor criptográfico usando o SQL Server Connector, que é um provedor EKM para o Cofre de Chaves do Azure. 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 comprimento do caminho do arquivo não pode exceder 256 caracteres.

  4. 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 login que executará a criptografia usando uma chave do cofre de chaves. Isso pode incluir:

    • Um logon de administrador do SQL Server que usa o cofre de chaves para configurar 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 um-para-um entre credenciais e logins. Ou seja, cada login deve ter uma credencial exclusiva.

    Modifique esse script Transact-SQL das seguintes maneiras:

    • Edite o argumento IDENTITY (DocsSampleEKMKeyVault) para apontar para o seu Azure Key Vault.

    • Substitua a primeira parte do argumento SECRET pela ID do Cliente Microsoft Entra da da Etapa 1: Configurar uma entidade de serviço do Microsoft Entra. Neste exemplo, o ID do Cliente é d956f6b9xxxxxxx.

      Importante

      Certifique-se de remover os hífenes do ID da Aplicação (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 cadeia de caracteres final para o argumento SECRET será uma longa sequência de letras e números, sem hífenes (exceto para a seção Segredo do Cliente, caso o Segredo do Cliente contenha algum hífenes).

      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 de como usar variáveis para o argumento CREATE CREDENTIAL e remover programaticamente o hífenes da ID do cliente, consulte CREATE CREDENTIAL.

  5. Abra a chave do Cofre da Chave do Azure na instância do SQL Server.

    Quer tenha criado uma nova chave ou importado uma chave assimétrica, conforme descrito em Passo 2: Criar um cofre de chaves, tem de abrir a chave. Abra-o fornecendo o nome da chave no seguinte script Transact-SQL.

    Importante

    Certifique-se de primeiro preencher os pré-requisitos do Registro para esta etapa.

    • Substitua EKMSampleASYKey pelo nome que você deseja que a chave tenha no SQL Server.
    • Substitua ContosoRSAKey0 pelo nome da sua chave no Cofre da Chave do Azure 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;
    

    A partir da versão atualizada 1.0.5.0 do conector do SQL Server, você pode consultar uma versão de chave específica no Cofre da Chave do Azure:

    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 será usada. Se você usar esse script, não importa se você atualizar a chave com uma nova versão. A versão de chave (por exemplo) 1a4d3b9b393c4678831ccc60def75379 sempre será usada para operações de banco de dados.

  6. 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;
    
  7. Crie um novo logon a partir da chave assimétrica no SQL Server. Remova o mapeamento de credenciais de Etapa 5: Configurar o SQL Server para que as credenciais possam ser mapeadas para o novo login.

    --Now drop the credential mapping from the original association
    ALTER LOGIN [<domain>\<login>]
        DROP CREDENTIAL sysadmin_ekm_cred;
    
  8. Altere o novo login e mapeie as credenciais do EKM para o novo login.

    --Now add the credential mapping to the new Login
    ALTER LOGIN TDE_Login
        ADD CREDENTIAL sysadmin_ekm_cred;
    

Configurar o banco de dados de usuários para ser criptografado

  1. Crie um banco de dados de teste que será criptografado com a chave do Cofre da Chave do Azure.

    --Create a test database that will be encrypted with the Azure Key Vault key
    CREATE DATABASE TestTDE;
    
  2. 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;
    
  3. 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 registo

  1. 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 declaração retorna:

    name            algorithm_desc    thumbprint
    EKMSampleASYKey RSA_2048          <key thumbprint>
    
  2. No banco de dados do 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 declaração retorna:

    encryptor_type encryption_state_desc encryptor_thumbprint
    ASYMMETRIC KEY ENCRYPTED             <key thumbprint>
    

Limpeza

  1. Limpe os objetos de teste. Exclua todos os objetos que foram 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 obter scripts de exemplo, consulte o blog em SQL Server Transparent Data Encryption and Extensible Key Management with Azure Key Vault.

  2. A chave de registo SQL Server Cryptographic Provider não é removida automaticamente após a eliminação de uma chave ou de todas as chaves EKM. Deve ser limpo manualmente. A limpeza da chave de registo deve ser feita com extrema cautela, uma vez que a limpeza prematura do registo pode quebrar a funcionalidade EKM. Para limpar a chave do Registro, exclua a chave do Registro SQL Server Cryptographic Provider no HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.

Troubleshoot

Se a chave do Registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider 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 à credencial.

  1. Atualize a chave secreta originalmente criada na Etapa 1: Configurar uma entidade de serviço do Microsoft Entra.

  2. Altere a credencial usando a mesma identidade e o novo segredo usando o código a seguir. Substitua <New Secret> pelo seu novo segredo:

    ALTER CREDENTIAL sysadmin_ekm_cred
    WITH IDENTITY = 'DocsSampleEKMKeyVault',
        SECRET = '<New Secret>';
    
  3. Reinicie o serviço SQL Server.

Observação

Se você estiver usando o EKM em um grupo de disponibilidade (AG), precisará alterar a credencial e reiniciar o serviço do SQL Server em todos os nós do AG.

Rodar a chave assimétrica com uma nova chave AKV ou uma nova versão da chave AKV

Observação

  • Ao girar manualmente uma chave AKV, o SQL Server suporta uma chave AKV sem versão ou uma chave versionada e não há necessidade de usar uma chave AKV diferente.
  • A chave AKV original pode ser girada criando 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 referindo-se à chave sem versão ou à chave versionada que foi rotacionada no Azure Key Vault (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, você deve 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 do 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 de chaves 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 girar uma chave assimétrica manualmente são as seguintes.

  1. 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;
    
  2. Adicione a credencial ao principal:

    ALTER LOGIN [domain\userName];
    ADD CREDENTIAL <new_credential_name>;
    
  3. 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 no nosso exemplo) ou uma chave versionada (ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379 em que 1a4d3b9b393c4678831ccc60def75379 é 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;
    
  4. Crie um novo login a partir da nova chave assimétrica:

    CREATE LOGIN <new_login_name>
    FROM ASYMMETRIC KEY <new_ekm_key_name>;
    
  5. Remova a credencial do principal:

    ALTER LOGIN [domain\username]
    DROP CREDENTIAL <new_credential_name>;
    
  6. Mapeie a credencial AKV para o novo login:

    ALTER LOGIN <new_login_name>;
    ADD CREDENTIAL <new_credential_name>;
    
  7. Altere a chave de criptografia do 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>;
    
  8. 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');
    

    Esta impressão digital deve corresponder à chave de registo sob o caminho HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider\Azure Key Vault\<key_vault_url>\<thumbprint> e dar-lhe o KeyUri para a sua chave girada.

Importante

Girar o protetor TDE lógico para um servidor significa alternar para uma nova chave assimétrica ou certificado que proteja a chave de criptografia do banco de dados (DEK). A rotação de chaves é uma operação online e deve levar apenas alguns segundos para ser concluída, porque isso apenas descriptografa e criptografa novamente o DEK e não todo o banco de dados.

Não exclua versões anteriores da chave após a rotação. Quando as chaves são giradas, alguns dados ainda são criptografados com as chaves anteriores, como backups de banco de dados mais antigos, arquivos de log de backup, arquivos de log virtuais (VLF) e arquivos de log de transações. As chaves anteriores também podem ser necessárias para uma recuperação de banco de dados ou uma restauração de banco de dados.