Transzparens adattitkosítás (TDE) védő eltávolítása a PowerShell használatával

A következőre vonatkozik: Azure SQL DatabaseAzure SQL Managed InstanceAzure Synapse Analytics (csak dedikált SQL-készletek)

Ez a cikk azt ismerteti, hogyan reagálhat az Azure SQL Database vagy az Azure Synapse Analytics potenciálisan sérült TDE-védelmére, amely a TDE-t ügyfél által felügyelt kulcsokkal használja az Azure Key Vaultban – Saját kulcs használata (BYOK) támogatással. A TDE BYOK-támogatásával kapcsolatos további információkért tekintse meg az áttekintési oldalt.

Figyelem

A cikkben ismertetett eljárásokat csak szélsőséges esetekben vagy tesztkörnyezetekben szabad elvégezni. Gondosan tekintse át a lépéseket, mivel az aktívan használt TDE-védők törlése az Azure Key Vaultból az adatbázis elérhetetlenné válását eredményezi.

Ha egy kulcs feltörésének gyanúja merül fel, például hogy egy szolgáltatás vagy felhasználó jogosulatlanul fért hozzá a kulcshoz, a legjobb, ha törli a kulcsot.

Ne feledje, hogy miután a TDE-védőt törölték a Key Vaultban, legfeljebb 10 perc múlva az összes titkosított adatbázis elkezdi megtagadni a megfelelő hibaüzenettel rendelkező összes kapcsolatot, és az állapotát elérhetetlenre módosítja.

Ez az útmutató végigvezeti az adatbázisok elérhetetlenné válásának megközelítését egy sérült incidensre adott válasz után.

Feljegyzés

Ez a cikk az Azure SQL Database-re, a felügyelt Azure SQL-példányra és az Azure Synapse Analyticsre (dedikált SQL-készletekre (korábban SQL DW)) vonatkozik. A Synapse-munkaterületeken belüli dedikált SQL-készletek transzparens adattitkosítás dokumentációját az Azure Synapse Analytics titkosításában találja.

Előfeltételek

  • Azure-előfizetéssel kell rendelkeznie, és rendszergazdai jogosultságokkal kell rendelkeznie az adott előfizetésben.
  • Telepítenie és futtatnia kell az Azure PowerShellt.
  • Ez az útmutató feltételezi, hogy már használ egy Azure Key Vault-kulcsot egy Azure SQL Database vagy Azure Synapse TDE-védelmezőjeként. További információért tekintse meg transzparens adattitkosítás BYOK-támogatással.

Az Az modul telepítési útmutatását az Azure PowerShell telepítését ismertető cikkben találja. Adott parancsmagokért lásd: AzureRM.Sql. Használja az új Azure PowerShell Az modult.

A TDE Protector ujjlenyomatainak ellenőrzése

Az alábbi lépések azt ismertetik, hogyan ellenőrizheti egy adott adatbázis virtuális naplófájljai (VLF) által még használatban lévő TDE Protector ujjlenyomatait. Az adatbázis aktuális TDE-védőjének ujjlenyomata és az adatbázis-azonosító a következő futtatásával található:

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

Az alábbi lekérdezés a használatban lévő VLF-eket és A TDE Protector ujjlenyomatait adja vissza. Minden egyes ujjlenyomat az Azure Key Vault (AKV) különböző kulcsára utal:

SELECT * FROM sys.dm_db_log_info (database_id)

Másik lehetőségként használhatja a PowerShellt vagy az Azure CLI-t:

A PowerShell-parancs Get-AzureRmSqlServerKeyVaultKey a lekérdezésben használt TDE-védő ujjlenyomatát tartalmazza, így láthatja, hogy mely kulcsokat és mely kulcsokat kell törölni az AKV-ban. Csak az adatbázis által már nem használt kulcsok törölhetők biztonságosan az Azure Key Vaultból.

Titkosított erőforrások akadálymentesítése

  1. Hozzon létre egy új kulcsot a Key Vaultban. Győződjön meg arról, hogy az új kulcs a potenciálisan sérült TDE-védőtől eltérő kulcstartóban jön létre, mivel a hozzáférés-vezérlés tárolószinten van kiépítve.

  2. Adja hozzá az új kulcsot a kiszolgálóhoz az Add-AzSqlServerKeyVaultKey és a Set-AzSqlServerTransparentDataEncryptionProtector parancsmagokkal, és frissítse azt a kiszolgáló új TDE-védelmezőjeként.

    # add the key from 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. A Get-AzSqlServerTransparentDataEncryptionProtector parancsmaggal győződjön meg arról, hogy a kiszolgáló és a replikák frissültek az új TDE-védőre.

    Feljegyzés

    Eltarthat néhány percig, amíg az új TDE-védő propagálja a kiszolgáló alatti összes adatbázist és másodlagos adatbázist.

    Get-AzSqlServerTransparentDataEncryptionProtector -ServerName <LogicalServerName> -ResourceGroupName <SQLDatabaseResourceGroupName>
    
  4. Készítsen biztonsági másolatot az új kulcsról a Key Vaultban.

    # -OutputFile parameter is optional; if removed, a file name is automatically generated.
    Backup-AzKeyVaultKey -VaultName <KeyVaultName> -Name <KeyVaultKeyName> -OutputFile <DesiredBackupFilePath>
    
  5. Törölje a feltört kulcsot a Key Vaultból a Remove-AzKeyVaultKey parancsmaggal.

    Remove-AzKeyVaultKey -VaultName <KeyVaultName> -Name <KeyVaultKeyName>
    
  6. Kulcs visszaállítása a Key Vaultba a Jövőben a Restore-AzKeyVaultKey parancsmaggal.

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

Titkosított erőforrások elérhetetlenné tétele

  1. A potenciálisan feltört kulcs által titkosított adatbázisok elvetése.

    A rendszer automatikusan biztonsági másolatot készít az adatbázisról és a naplófájlról, így az adatbázis időponthoz kötött visszaállítása bármikor elvégezhető (feltéve, hogy megadja a kulcsot). Az adatbázisokat az aktív TDE-védő törlése előtt el kell dobni, hogy a legutóbbi tranzakcióktól akár 10 percnyi adatvesztés is elkerülhető legyen.

  2. Biztonsági másolatot készít a TDE-védő kulcsanyagáról a Key Vaultban.

  3. Távolítsa el a potenciálisan feltört kulcsot a Key Vaultból.

Feljegyzés

A kulcstartó engedélymódosításainak érvénybe lépése körülbelül 10 percet vehet igénybe. Ez magában foglalja a TDE-védő hozzáférési engedélyeinek visszavonását az AKV-ban, és az ezen időkereten belüli felhasználók továbbra is rendelkezhetnek hozzáférési engedélyekkel.