Configurar o Gerenciamento Extensível de Chave de TDE do SQL Server usando o Azure Key Vault

Aplica-se a: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 anteriormente 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:

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.

  1. Entre no portal do Azure e siga uma destas etapas:

    • Selecione o botão Microsoft Entra ID.

      Captura de tela do painel serviços do Azure.

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

  2. 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.

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

      Captura de tela da página Visão geral do Microsoft Entra ID no portal do Azure.

    2. Na página Registros de aplicativo, selecione Novo registro.

      Captura de tela do painel Registros de aplicativo no portal do Azure.

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

      Captura de tela do painel Registrar um aplicativo.

    4. No painel esquerdo, selecione Certificados e segredos > Segredos do cliente > Novo segredo do cliente.

      Captura de tela do painel Certificados e segredos para o aplicativo no portal do Azure.

    5. 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.

      Captura de tela de uma seçao Adicionar um segredo do cliente para o aplicativo no portal do Azure.

    6. 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.

      Captura de tela do valor do segredo no portal do Azure.

    7. 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.

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

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.

  1. 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.

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

  2. 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 e insira os valores apropriados para a guia. Também recomendamos ativar a proteção contra limpeza.

    Captura de tela do painel Criar cofre de chaves no portal do Azure.

  3. 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.

    Captura de tela do painel Criar cofre de chaves e da guia Configuração de acesso no portal do Azure.

  4. 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.

  1. Vá para o recurso do cofre de chaves que você criou e selecione a configuração Controle de acesso (IAM).

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

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

  3. 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.

    Captura de tela da 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 que você criou na Etapa 1. Selecione o aplicativo e clique no botão Selecionar.

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

  5. Clique em Revisar + atribuir duas vezes para concluir a atribuição de função.

  6. 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.

  7. 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.

  1. 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.

  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 Desencapsular chave e Encapsular chave nas opções de Operações criptográficas. Selecione Avançar

    Captura de tela do link Adicionar Política de Acesso no painel Políticas de acesso.

  3. Na guia Principal, selecione o aplicativo que foi criado na Etapa 1.

    Captura de tela da caixa de pesquisa do aplicativo no painel Entidade de segurança.

  4. Selecione Avançar e, em seguida, 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 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.

  2. Use o tipo de chave RSA e o tamanho da chave RSA2048. 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.

    Captura de tela do painel Criar Chave.

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.

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ê pode 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.

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

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:

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.

  1. Certifique-se de que o SQL Server esteja instalado e em execução.

  2. Execute regedit para abrir o Editor do Registro.

  3. Criar uma chave do Registro 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 mouse na chave SQL Server Cryptographic Provider do Registro e selecione Permissões.

  5. 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.

    Captura de tela da chave do Registro EKM no Editor do Registro.

  6. Selecione Aplicar e, em seguida, OK.

  7. 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

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

  2. 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;
    
  3. 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.

  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 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 inclua https:// no URI do cofre de chaves.
    • 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 argumento SECRET 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
                 --<----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 (Transact-SQL).

  5. 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. 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.

  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 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;
    
  8. 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

  1. 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;
    
  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 registro

  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 instrução retorna:

    name            algorithm_desc    thumbprint
    EKMSampleASYKey RSA_2048          <key thumbprint>
    
  2. 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

  1. 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.

  2. 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 chave SQL Server Cryptographic Provider do Registro em HKEY_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.

  1. Atualize o segredo originalmente criado 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 seguinte código. 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), 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.

  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 à entidade de segurança:

    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 em nosso exemplo) ou uma chave versionada (ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379, 1a4d3b9b393c4678831ccc60def75379onde é 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 logon da nova chave assimétrica:

    CREATE LOGIN <new_login_name>
    FROM ASYMMETRIC KEY <new_ekm_key_name>;
    
  5. Descarte a credencial da entidade de segurança:

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

    ALTER LOGIN <new_login_name>;
    ADD CREDENTIAL <new_credential_name>;
    
  7. 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>;
    
  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');
    

    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.