Entfernen eines Transparent Data Encryption-Schutzes in Azure Synapse Analytics

Tip

Microsoft Fabric Data Warehouse ist ein relationales Enterprise-Warehouse auf einem Data Lake-Fundament mit zukunftsfähiger Architektur, integrierter KI und neuen Features. Wenn Sie mit Data Warehouse noch nicht vertraut sind, beginnen Sie mit Fabric Data Warehouse. Vorhandene dedizierte SQL-Pool-Workloads können auf Fabric aktualisieren, um neue Funktionen in den Bereichen Data Science, Echtzeitanalyse und Berichterstellung zu nutzen.

Gilt für: Dedizierte SQL-Pools (früher SQL DW) in Azure Synapse Analytics

Verwenden Sie dieses Verfahren, wenn ein vom Kunden verwalteter TDE-Schutz kompromittiert sein könnte. Rotieren Sie zu einer neuen Schutzvorrichtung, bevor Sie den alten Schlüssel löschen oder deaktivieren, damit die dedizierten SQL-Pools zugänglich bleiben.

Caution

Das Löschen oder Deaktivieren eines aktiven TDE-Schutzes macht jeden dedizierten SQL-Pool, der darauf angewiesen ist, unzugänglich. Überprüfen Sie den Vorfall-Reaktionsplan und die Anforderungen zur Backup-Aufbewahrung, bevor Sie einen Schlüssel entfernen.

Note

Dieser Artikel behandelt eigenständige dedizierte SQL-Pools (früher SQL DW). Für dedizierte SQL-Pools in einem Synapse-Arbeitsbereich siehe Encryption for Azure Synapse Analytics workspaces.

Das Löschen eines Schlüssels macht keine Kopien dieses Schlüssels, die zuvor gesichert oder in einem anderen Schlüsseltresor wiederhergestellt wurden, unwirksam. Schützen und erfassen Sie jede Kopie als Teil der Reaktion auf den Sicherheitsvorfall.

Prerequisites

Überprüfe die Zertifikatsfingerabdrücke des TDE-Schutzes

Die folgenden Schritte zeigen, wie man die TDE-Schutz-Fingerabdrücke überprüft, welche von Virtual Log Files (VLF) einer bestimmten Datenbank weiterhin verwendet werden.

Führen Sie folgende Abfrage aus, um den Fingerabdruck des aktuellen TDE-Protektors für die Datenbank und die Datenbank-ID zu finden:

SELECT [database_id],
       [encryption_state],
       [encryptor_type], /*asymmetric key means Azure Key Vault, certificate means service-managed keys*/
       [encryptor_thumbprint]
 FROM [sys].[dm_database_encryption_keys]

Führe die folgende Abfrage aus, um die VLFs und die verwendeten TDE-Schutz-Fingerabdrücke zurückzugeben. Jeder andere Fingerabdruck bezieht sich auf einen anderen Schlüssel in Azure Key Vault:

SELECT * FROM sys.dm_db_log_info (database_id)

Alternativ können Sie PowerShell oder Azure CLI verwenden:

  • Der PowerShell-Befehl Get-AzSqlServerKeyVaultKey liefert den Fingerabdruck der TDE-Schutzvorrichtung, die in der Abfrage verwendet wird, sodass Sie sehen können, welche Schlüssel in Azure Key Vault behalten und welche gelöscht werden sollten. Nur Schlüssel, die die Datenbank nicht mehr verwendet, können sicher aus Azure Key Vault gelöscht werden.

  • Der Azure CLI-Befehl az sql server key show liefert den Fingerabdruck des TDE-Protektors, der in der Abfrage verwendet wird, sodass du sehen kannst, welche Schlüssel behalten und welche du in Azure Key Vault löschen solltest. Nur Schlüssel, die die Datenbank nicht mehr verwendet, können sicher aus Azure Key Vault gelöscht werden.

Bewahren des Zugriffs auf verschlüsselte Ressourcen

PowerShell

  1. Erstellen Sie einen neuen Schlüssel in Azure Key Vault. Stellen Sie sicher, dass Sie diesen neuen Schlüssel in einem separaten Schlüsseltresor erstellen, der sich von dem Schlüsseltresor mit dem potenziell kompromittierten TDE-Schutz unterscheidet, da die Zugangskontrolle auf Tresorebene eingerichtet ist.

  2. Fügen Sie den neuen Schlüssel dem Server hinzu, indem Sie die Cmdlets Add-AzSqlServerKeyVaultKey und Set-AzSqlServerTransparentDataEncryptionProtector verwenden und ihn als neue TDE-Schutzvorrichtung des Servers aktualisieren.

    # add the key from Azure Key Vault to the server  
    Add-AzSqlServerKeyVaultKey -ResourceGroupName <SQLDatabaseResourceGroupName> -ServerName <LogicalServerName> -KeyId <KeyVaultKeyId>
    
    # set the key as the TDE protector for all resources under the server
    Set-AzSqlServerTransparentDataEncryptionProtector -ResourceGroupName <SQLDatabaseResourceGroupName> `
        -ServerName <LogicalServerName> -Type AzureKeyVault -KeyId <KeyVaultKeyId>
    
  3. Stellen Sie sicher, dass der Server und alle vorhandenen Replikate auf den neuen TDE-Schutz aktualisiert werden, indem Sie das Cmdlet Get-AzSqlServerTransparentDataEncryptionProtector verwenden.

    Note

    Es kann einige Minuten dauern, bis sich die neue TDE-Schutzvorrichtung auf alle Datenbanken und sekundären Datenbanken auf dem Server verteilt.

    Get-AzSqlServerTransparentDataEncryptionProtector -ServerName <LogicalServerName> -ResourceGroupName <SQLDatabaseResourceGroupName>
    
  4. Erstellen Sie eine Sicherung des neuen Schlüssels in Azure Key Vault.

    # -OutputFile parameter is optional; if removed, a file name is automatically generated.
    Backup-AzKeyVaultKey -VaultName <KeyVaultName> -Name <KeyVaultKeyName> -OutputFile <DesiredBackupFilePath>
    
  5. Löschen Sie den kompromittierten Schlüssel aus Azure Key Vault mit dem cmdlet Remove-AzKeyVaultKey.

    Remove-AzKeyVaultKey -VaultName <KeyVaultName> -Name <KeyVaultKeyName>
    
  6. Verwenden Sie das Cmdlet Restore-AzKeyVaultKey , um einen Schlüssel in Azure Key Vault in Zukunft wiederherzustellen.

    Restore-AzKeyVaultKey -VaultName <KeyVaultName> -InputFile <BackupFilePath>
    

Azure CLI

Eine Befehlsreferenz finden Sie unter Azure CLI keyvault.

  1. Erstellen Sie einen neuen Schlüssel in Azure Key Vault. Stellen Sie sicher, dass Sie diesen neuen Schlüssel in einem separaten Schlüsseltresor vom potenziell kompromittierten TDE-Schutz erstellen, da die Zugangskontrolle auf Tresorebene eingerichtet ist.

  2. Fügen Sie den neuen Schlüssel zum Server hinzu, und aktualisieren Sie diesen als neue TDE-Schutzvorrichtung des Servers.

    # add the key from Azure Key Vault to the server  
    az sql server key create --kid <KeyVaultKeyId> --resource-group <SQLDatabaseResourceGroupName> --server <LogicalServerName>
    
    # set the key as the TDE protector for all resources under the server
    az sql server tde-key set --server-key-type AzureKeyVault --kid <KeyVaultKeyId> --resource-group <SQLDatabaseResourceGroupName> --server <LogicalServerName>
    
  3. Stellen Sie sicher, dass der Server und alle Repliken auf die neue TDE-Schutzvorrichtung aktualisiert werden.

    Note

    Es kann einige Minuten dauern, bis sich die neue TDE-Schutzvorrichtung auf alle Datenbanken und sekundären Datenbanken auf dem Server verteilt.

    az sql server tde-key show --resource-group <SQLDatabaseResourceGroupName> --server <LogicalServerName>
    
  4. Erstellen Sie eine Sicherung des neuen Schlüssels in Azure Key Vault.

    # --file parameter is optional; if removed, a file name is automatically generated.
    az keyvault key backup --file <DesiredBackupFilePath> --name <KeyVaultKeyName> --vault-name <KeyVaultName>
    
  5. Löschen Sie den kompromittierten Schlüssel aus Azure Key Vault.

    az keyvault key delete --name <KeyVaultKeyName> --vault-name <KeyVaultName>
    
  6. Stellen Sie einen Schlüssel später in Azure Key Vault wieder her.

    az keyvault key restore --file <BackupFilePath> --vault-name <KeyVaultName>
    

Verhindern des Zugriffs auf verschlüsselte Ressourcen

  1. Löschen Sie die Datenbanken, die den potenziell kompromittierten Schlüssel für die Verschlüsselung verwenden.

    Das System sichert automatisch die Datenbank und die Protokolldateien, sodass Sie jederzeit eine Wiederherstellung der Datenbank zu einem bestimmten Zeitpunkt durchführen können (vorausgesetzt, Sie geben den Schlüssel an). Löschen Sie die Datenbanken, bevor Sie einen aktiven TDE-Schutz löschen, um möglichen Datenverlust von bis zu 10 Minuten der letzten Transaktionen zu vermeiden.

  2. Sichern Sie das Schlüsselmaterial der TDE-Schutzvorrichtung in Azure Key Vault.

  3. Entfernen Sie den potenziell kompromittierten Schlüssel aus Azure Key Vault.

Note

Es kann etwa 10 Minuten dauern, bis Berechtigungsänderungen für den Schlüsseltresor wirksam werden. Dies umfasst diesmal den Widerruf der Zugriffsberechtigungen für den TDE-Schutz in AKV, und Benutzer könnten weiterhin Zugriffsrechte haben.