Sdílet prostřednictvím

Transparentní šifrování dat (TDE) s klíči spravovanými zákazníkem na úrovni databáze

  • Článek

Platí pro: Azure SQL Database

Tento článek popisuje transparentní šifrování dat (TDE) s klíči spravovanými zákazníkem na úrovni databáze pro Azure SQL Database.

Poznámka:

CmK na úrovni databáze je k dispozici pro Azure SQL Database (všechny edice SQL Database). Není k dispozici pro azure SQL Managed Instance, místní SQL Server, virtuální počítače Azure a Azure Synapse Analytics (vyhrazené fondy SQL (dříve SQL DW)).

Poznámka:

ID Microsoft Entra se dříve označovalo jako Azure Active Directory (Azure AD).

Přehled

Azure SQL nabízí zákazníkům možnost šifrování neaktivních uložených dat prostřednictvím transparentního šifrování dat (TDE). Rozšíření transparentního šifrování dat pomocí klíče spravovaného zákazníkem (CMK) umožňuje ochranu neaktivních uložených dat, kde je ochrana transparentním šifrováním dat (šifrovací klíč) uložená ve službě Azure Key Vault, která šifruje šifrovací klíče databáze. V současné době je transparentní šifrování dat s CMK nastaveno na úrovni serveru a dědí se všemi šifrovanými databázemi přidruženými k danému serveru. Tato nová funkce umožňuje nastavit ochranu transparentním šifrováním dat jako klíč spravovaný zákazníkem jednotlivě pro každou databázi na serveru. Jakýkoli Microsoft.Sql/servers/databases prostředek s platnou neprázdnou encryptionProtector vlastností je nakonfigurovaný s klíči spravovanými zákazníkem na úrovni databáze.

V tomto scénáři je možné asymetrický klíč uložený ve vlastnictví zákazníka a spravovaném zákazníkem azure Key Vault (AKV) použít jednotlivě pro každou databázi v rámci serveru k šifrování šifrovacího klíče databáze (DEK) označovaného jako ochrana transparentním šifrováním dat. K dispozici je možnost přidat klíče, odebrat klíče a změnit spravovanou identitu přiřazenou uživatelem pro každou databázi. Další informace o identitách najdete v tématu Typy spravovaných identit v Azure.

K dispozici jsou následující funkce:

  • Spravovaná identita přiřazená uživatelem: K databázi můžete přiřadit jednu spravovanou identitu přiřazenou uživatelem. Tuto identitu můžete použít pro přístup ke službě Azure Key Vault a ke správě šifrovacích klíčů.
  • Správa šifrovacích klíčů: Můžete povolit přidání jednoho nebo více šifrovacích klíčů na úrovni databáze a nastavit jeden z přidaných klíčů jako ochranu transparentním šifrováním dat. Přidané šifrovací klíče používají spravovanou identitu přiřazenou uživatelem, která je už přiřazená k databázi pro přístup ke službě Azure Key Vault.
  • Identita federovaného klienta: Můžete také povolit klíč spravovaný zákazníkem (CMK) ze služby Azure Key Vault v jiném tenantovi Microsoft Entra tak, aby se na úrovni databáze nastavil jako ochrana transparentním šifrováním dat pomocí identity federovaného klienta nastaveného ve službě Azure SQL Database. To umožňuje spravovat transparentní šifrování dat pomocí klíčů uložených ve službě Azure Key Vault jiného tenanta.

Poznámka:

Spravovaná identita přiřazená systémem není podporována na úrovni databáze.

Výhody transparentního šifrování dat spravovaného zákazníkem na úrovni databáze

Jako další poskytovatelé služeb, označovaní také jako nezávislí dodavatelé softwaru (ISV), používají Azure SQL Database k vytváření svých služeb, mnoho z nich se mění na elastické fondy jako způsob efektivní distribuce výpočetních prostředků napříč několika databázemi. Díky tomu, že mají všichni zákazníci databáze ve sdíleném elastickém fondu, můžou nezávislí výrobci softwaru využít možnost fondu optimalizovat využití prostředků a zároveň zajistit, aby každá databáze měla odpovídající prostředky.

Existuje však jedno významné omezení tohoto přístupu. Pokud je na stejném logickém serveru Azure SQL hostováno více databází, sdílejí ochranu transparentním šifrováním dat na úrovni serveru. Nezávislí výrobci softwaru nemůžou svým zákazníkům nabízet skutečné klíče spravované zákazníkem (CMK). Bez schopnosti spravovat vlastní šifrovací klíče mohou zákazníci váhat svěřovat citlivá data službě nezávislých výrobců softwaru, zejména pokud předpisy dodržování předpisů vyžadují, aby si zachovali úplnou kontrolu nad svými šifrovacími klíči.

Díky cmK na úrovni databáze můžou nezávislí výrobci softwaru nabídnout svým zákazníkům funkce CMK a dosáhnout izolace zabezpečení, protože ochranu transparentního šifrování dat jednotlivých databází může potenciálně vlastnit příslušný zákazník ISV v trezoru klíčů, který vlastní. Izolace zabezpečení dosažená pro zákazníky nezávislých výrobců softwaru se týká klíče i identity používané pro přístup k klíči.

Následující diagram shrnuje nové funkce uvedené výše. Představuje dva samostatné tenanty Microsoft Entra. TenantBest Services, který obsahuje logický server Azure SQL se dvěma databázemi, DB 2DB 1 a s Azure Key Vault 1 Key 1 přístupem k databázi DB 1 pomocí UMI 1. Nastavení UMI 1 na úrovni serveru a Key 1 reprezentace. Ve výchozím nastavení zdědí všechny databáze vytvořené na tomto serveru toto nastavení pro transparentní šifrování dat pomocí cmk. Tenant Contoso představuje klienta, který obsahuje Azure Key Vault 2 s posouzením Key 2 databáze DB 2 napříč tenanty jako součást podpory CMK na úrovni databáze pomocí Key 2 a UMI 2 nastavení pro tuto databázi.

Nastavení a fungování transparentního šifrování dat spravovaného zákazníkem na úrovni databáze

Další informace o konfiguraci identity mezi tenanty najdete v dokumentu na úrovni serveru, který spravuje klíče spravované zákazníkem napříč tenanty s transparentním šifrováním dat.

Podporované scénáře správy klíčů

V následující části předpokládejme, že existuje server, který se skládá ze tří databází (například Database1, Database2a Database3).

Existující scénář

Key1 je nakonfigurovaný jako klíč spravovaný zákazníkem na úrovni logického serveru. Všechny databáze na tomto serveru dědí stejný klíč.

  • Server – Key1 nastavený jako CMK
  • Database1 – Key1 používá se jako CMK
  • Database2 – Key1 používá se jako CMK
  • Database3 – Key1 používá se jako CMK

Nový podporovaný scénář: Logický server nakonfigurovaný s klíčem spravovaným zákazníkem

Key1 je nakonfigurovaný jako klíč spravovaný zákazníkem na úrovni logického serveru. Na úrovni databáze je možné nakonfigurovat jiný klíčKey2 spravovaný zákazníkem ().

  • Server – Key1 nastavený jako CMK
  • Database1 – Key2 používá se jako CMK
  • Database2 – Key1 používá se jako CMK
  • Database3 – Key1 používá se jako CMK

Poznámka:

Pokud je logický server nakonfigurovaný s klíči spravovanými zákazníkem pro transparentní šifrování dat, individuální databáze na tomto logickém serveru se nedá vyjádřit k použití klíče spravovaného službou pro transparentní šifrování dat.

Nový podporovaný scénář: Logický server nakonfigurovaný s klíčem spravovaným službou

Logický server je nakonfigurovaný s využitím spravovaného klíče (SMK) pro transparentní šifrování dat. Na úrovni databáze je možné nakonfigurovat jiný klíčKey2 spravovaný zákazníkem ().

  • Server – Klíč spravovaný službou nastavený jako ochrana transparentním šifrováním dat
  • Database1 – Key2 nastavit jako CMK
  • Database2 – Sada klíčů spravovaných službou jako ochrana transparentním šifrováním dat
  • Database3 – Sada klíčů spravovaných službou jako ochrana transparentním šifrováním dat

Vrácení šifrování na úrovni serveru

Database1 je nakonfigurovaný s klíčem spravovaným zákazníkem na úrovni databáze pro transparentní šifrování dat, zatímco logický server je nakonfigurovaný s klíčem spravovaným službou. Database1 můžete vrátit zpět, aby se použil klíč spravovaný službou na úrovni logického serveru.

Poznámka:

Pokud je logický server nakonfigurovaný s klíčem CMK pro transparentní šifrování dat, databáze nakonfigurovaná pomocí cmk na úrovni databáze se nedá vrátit zpět na šifrování na úrovni serveru.

Operace vrácení se sice podporuje jenom v případě, že je logický server nakonfigurovaný s klíčem spravovaným službou při použití transparentního šifrování dat, databázi nakonfigurovanou pomocí klíče CMK na úrovni databáze je možné obnovit na server nakonfigurovaný pomocí cmK za předpokladu, že má server přístup ke všem klíčům používaným zdrojovou databází s platnou identitou.

Požadavky na službu Key Vault a spravovaná identita

Stejné požadavky na konfiguraci klíčů služby Azure Key Vault (AKV) a spravovaných identit, včetně nastavení klíčů a oprávnění udělených identitám, které platí pro funkci klíče spravovaného zákazníkem (CMK) na úrovni serveru, platí také pro klíč na úrovni databáze. Další informace najdete v tématu transparentní šifrování dat (TDE) s CMK a spravovanými identitami pomocí CMK.

Správa klíčů

Otočení ochrany transparentním šifrováním dat pro databázi znamená přepnutí na nový asymetrický klíč, který chrání databázi. Obměně klíčů je online operace a dokončení by mělo trvat jenom několik sekund. Operace pouze dešifruje a znovu zašifruje šifrovací klíč databáze, nikoli celou databázi. Jakmile je k databázi přiřazená platná spravovaná identita přiřazená uživatelem, obměna klíče na úrovni databáze je operace CRUD databáze, která zahrnuje aktualizaci vlastnosti ochrany šifrování databáze. Set-AzSqlDatabase a vlastnost -EncryptionProtector lze použít k obměně klíčů. Chcete-li vytvořit novou databázi nakonfigurovanou s CMK na úrovni databáze, můžete použít New-AzSqlDatabase s parametrem -EncryptionProtector, -AssignIdentitya -UserAssignedIdentityId parametry.

Nové klíče je možné přidat a stávající klíče je možné z databáze odebrat pomocí podobných požadavků a upravit vlastnost klíčů pro prostředek databáze. Set-AzSqlDatabase s parametrem -KeyList a -KeysToRemove dá se použít pro tyto operace. K načtení nastavení ochrany šifrování, identity a klíčů je možné použít Get-AzSqlDatabase . Prostředek Azure Resource Manageru Microsoft.Sql/servers/databases ve výchozím nastavení zobrazuje pouze ochranu transparentního šifrování dat a spravovanou identitu nakonfigurovanou v databázi. Pokud chcete rozšířit úplný seznam klíčů, jsou potřeba další parametry -ExpandKeyList . Kromě toho -KeysFilter "current" a hodnotu k určitému bodu v čase (například 2023-01-01) lze použít k načtení aktuálních klíčů použitých a klíčů použitých v minulosti v určitém bodu v čase.

Automatická obměně klíčů

Automatická obměny klíčů je dostupná na úrovni databáze a dá se použít s klíči služby Azure Key Vault. Rotace se aktivuje, když se zjistí nová verze klíče a automaticky se otočí do 24 hodin. Informace o tom, jak nakonfigurovat automatickou obměnu klíčů pomocí webu Azure Portal, PowerShellu nebo Azure CLI, najdete v tématu Automatické obměně klíčů na úrovni databáze.

Oprávnění ke správě klíčů

V závislosti na modelu oprávnění trezoru klíčů (zásady přístupu nebo Azure RBAC) může být přístup k trezoru klíčů udělen buď vytvořením zásady přístupu v trezoru klíčů, nebo vytvořením nového přiřazení role Azure RBAC.

Model oprávnění zásad přístupu

Aby mohla databáze používat ochranu transparentním šifrováním dat uloženým v AKV k šifrování DEK, musí správce trezoru klíčů udělit následující přístupová práva spravované identitě přiřazené uživatelem databáze pomocí jedinečné identity Microsoft Entra:

  • get – pro načtení veřejné části a vlastností klíče ve službě Azure Key Vault.
  • wrapKey – aby bylo možné chránit klíč DEK (encrypt).
  • unwrapKey – aby bylo možné odemknout (dešifrovat) DEK.

Model oprávnění Azure RBAC

Aby databáze používala ochranu transparentním šifrováním dat uloženou v AKV pro šifrování DEK, musí být pro spravovanou identitu přiřazenou uživatelem databáze přidána nová přiřazení role Azure RBAC s rolí Uživatelem přiřazená šifrovací službou Key Vault pomocí jedinečné identity Microsoft Entra.

Klíče spravované zákazníkem napříč tenanty

Klíče spravované zákazníkem napříč tenanty s transparentním šifrováním dat popisují, jak nastavit ID federovaného klienta pro cmK na úrovni serveru. Podobné nastavení je potřeba provést pro CMK na úrovni databáze a federované ID klienta musí být přidáno jako součást požadavků rozhraní API Set-AzSqlDatabase nebo New-AzSqlDatabase .

Poznámka:

Pokud se aplikace s více tenanty nepřidá do zásad přístupu trezoru klíčů s požadovanými oprávněními (Get, Wrap Key, Unwrap Key), při použití aplikace pro federaci identit na webu Azure Portal se zobrazí chyba. Před konfigurací federované identity klienta se ujistěte, že jsou oprávnění správně nakonfigurovaná.

Pokud je logický server nakonfigurovaný pomocí klíče spravovaného službou pomocí Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevert, může se vrátit k šifrování na úrovni serveru.

V případě nepřístupné ochrany transparentním šifrováním dat, jak je popsáno v transparentním šifrování dat (TDE) s CMK, je možné po opravě přístupu ke klíči použít Invoke-AzSqlDatabaseTransparentDataEncryptionProtectorRevalidation , aby byla databáze přístupná.

Poznámka:

Správa identit a klíčů pro transparentní šifrování dat pomocí klíčů spravovaných zákazníkem na úrovni databáze podrobně popisuje operace správy identit a klíčů pro CMK na úrovni databáze spolu s powershellem, Azure CLI a příklady rozhraní REST API.

Další důležité informace

  • Pokud je transparentní šifrování dat s CMK již povoleno na úrovni serveru, nastavení CMK pro konkrétní databázi přepíše nastavení CMK na úrovni serveru (DEK databáze se znovu zašifruje pomocí ochrany transparentním šifrováním dat na úrovni databáze).
  • Změny nebo obměna klíče na úrovni logického serveru nemají vliv na nastavení cmk na úrovni databáze a databáze nadále používá vlastní nastavení CMK.
  • CMK na úrovni databáze se nepodporuje prostřednictvím jazyka Transact-SQL (T-SQL).
  • Spravovanou identitu přiřazenou uživatelem (UMI) logického serveru je možné použít na úrovni databáze. Doporučuje se ale použít určený UMI pro cmk na úrovni databáze.
  • Nastavení cmk na úrovni serveru napříč tenanty nemá vliv na jednotlivé databáze nakonfigurované pomocí cmk na úrovni databáze a nadále používají vlastního jednoho tenanta nebo konfiguraci mezi tenanty.
  • Na úrovni databáze je možné nastavit pouze jednu spravovanou identitu přiřazenou uživatelem.

Poznámka:

Spravované identity v databázi musí být při přejmenování databáze znovu přiřazeny.

Migrace existujících databází na cmk na úrovni databáze

Nové databáze je možné nakonfigurovat pomocí klíče CMK na úrovni databáze během vytváření a stávajících databází na serverech nakonfigurovaných pomocí klíčů spravovaných službou lze migrovat na cmK na úrovni databáze pomocí operací popsaných v tématu Identita a správa klíčů pro transparentní šifrování dat s klíči na úrovni zákazníka. Pokud chcete migrovat databáze nakonfigurované pomocí cmk na úrovni serveru nebo geografické replikace, je potřeba provést další kroky popsané v následujících částech.

Databáze nakonfigurovaná pomocí cmk na úrovni serveru bez geografické replikace

  1. Použijte sys.dm_db_log_info (Transact-SQL) – SQL Server pro vaši databázi a vyhledejte soubory virtuálních protokolů (VLF), které jsou aktivní.
  2. U všech aktivních souborů VLF zaznamenejte vlf_encryptor_thumbprint výsledek sys.dm_db_log_info .
  3. Ke kontrole encryptor_thumbprintpoužijte sys.dm_database_encryption_keys (Transact-SQL) – zobrazení SQL Serveru pro vaši databázi. Zaznamenejte záznam .encryptor_thumbprint
  4. Pomocí rutiny Get-AzSqlServerKeyVaultKey získejte všechny klíče na úrovni serveru nakonfigurované na logickém serveru. Ve výsledcích vyberte ty, které mají stejný kryptografický otisk, který odpovídá vašemu seznamu z výše uvedeného výsledku.
  5. Proveďte volání rozhraní API pro aktualizaci databáze, kterou chcete migrovat, spolu s ochranou identity a šifrování. Výše uvedené klíče předejte jako klíče na úrovni databáze pomocí parametrů Set-AzSqlDatabase pomocí -UserAssignedIdentityIdparametrů , -AssignIdentity, -KeyList-EncryptionProtector (a v případě potřeby). -FederatedClientId

Důležité

Identita použitá v žádosti o aktualizaci databáze musí mít přístup ke všem klíčům předávaným jako vstup.

Databáze nakonfigurovaná pomocí cmk na úrovni serveru s geografickou replikací

  1. Pokud chcete načíst seznam klíčů potřebných k migraci, postupujte podle kroků (1) až (4) uvedených v předchozí části.
  2. Proveďte volání rozhraní API pro aktualizaci databáze do primární a sekundární databáze, kterou chcete migrovat, spolu s identitou a výše uvedenými klíči jako klíči na úrovni databáze pomocí Set-AzSqlDatabase a parametru -KeyList . Ještě nenastavujte ochranu šifrování.
  3. Klíč na úrovni databáze, který chcete použít jako primární ochranu databází, musí být nejprve přidán do sekundární databáze. Pomocí set-AzSqlDatabase -KeyList přidejte tento klíč do sekundární databáze.
  4. Jakmile se šifrovací klíč ochrany přidá do sekundární databáze, pomocí Set-AzSqlDatabase ji nastavte jako ochranu šifrování v primární databázi pomocí parametru -EncryptionProtector .
  5. Pro dokončení migrace nastavte klíč jako ochranu šifrování v sekundární databázi, jak je popsáno v části (4).

Důležité

Pokud chcete migrovat databáze, které jsou nakonfigurované s klíčem spravovaným službou na úrovni serveru a geografickou replikací, postupujte podle kroků (3), (4) a (5) z této části.

Geografická replikace a vysoká dostupnost

Ve scénářích aktivní geografické replikace i skupin převzetí služeb při selhání je možné primární i sekundární databáze propojit buď se stejným trezorem klíčů (v libovolné oblasti), nebo oddělit trezory klíčů. Pokud jsou k primárnímu a sekundárnímu serveru připojeny samostatné trezory klíčů, je zákazník odpovědný za udržování konzistence informací o klíčích v trezorech klíčů, aby byl geosekundární server synchronizován a mohl k převzetí použít stejný klíč z připojeného trezoru klíčů, pokud se primární server stane nedostupným z důvodu výpadku v oblasti a dojde k převzetí funkce při selhání. Je možné nakonfigurovat až čtyři sekundy a řetězení (secondaries of secondaries) se nepodporuje.

Chcete-li vytvořit aktivní geografickou replikaci pro databázi nakonfigurovanou pomocí klíče CMK na úrovni databáze, musí být sekundární replika vytvořena s platnou spravovanou identitou přiřazenou uživatelem a seznamem aktuálních klíčů používaných primární databází. Seznam aktuálních klíčů je možné načíst z primární databáze pomocí nezbytných filtrů a parametrů dotazu nebo pomocí PowerShellu a Azure CLI. Kroky potřebné k nastavení geografické repliky takové databáze:

  1. Předem naplní seznam klíčů používaných primární databází pomocí příkazu Get-AzSqlDatabase a -ExpandKeyList parametrů a -KeysFilter "current" parametrů. Vylučte -KeysFilter , pokud chcete načíst všechny klíče.
  2. Vyberte spravovanou identitu přiřazenou uživatelem (a ID federovaného klienta, pokud konfigurujete přístup mezi tenanty).
  3. Vytvořte novou databázi jako sekundární pomocí rutiny New-AzSqlDatabaseSecondary a zadejte předem vyplněný seznam klíčů získaných ze zdrojové databáze a výše uvedené identity (a federovaného klienta DI, pokud konfigurujete přístup mezi tenanty) ve volání rozhraní API pomocí -KeyListparametrů , -AssignIdentity, , -EncryptionProtector -UserAssignedIdentityId(a v případě potřeby). -FederatedClientId
  4. Pomocí new-AzSqlDatabaseCopy vytvořte kopii databáze se stejnými parametry v předchozím kroku.

Důležité

Databáze nakonfigurovaná pomocí cmk na úrovni databáze musí mít nakonfigurovanou repliku (nebo kopii) s cmK na úrovni databáze. Replika nemůže použít nastavení šifrování na úrovni serveru.

Pokud chcete použít databázi nakonfigurovanou s cmK na úrovni databáze ve skupině převzetí služeb při selhání, výše uvedené kroky k vytvoření sekundární repliky se stejným názvem jako primární replika musí být použity na sekundárním serveru. Po nakonfigurování této sekundární repliky je možné databáze přidat do skupiny převzetí služeb při selhání.

Databáze nakonfigurované pomocí cmk na úrovni databáze nepodporují automatizované sekundární vytváření při přidání do skupiny převzetí služeb při selhání.

Další informace najdete v tématu Konfigurace geografické replikace a obnovení zálohy pro transparentní šifrování dat pomocí klíčů spravovaných zákazníkem na úrovni zákazníka. Popisuje, jak nastavit geografickou replikaci a skupiny převzetí služeb při selhání pomocí rozhraní REST API, PowerShellu a Azure CLI.

Poznámka:

Všechny osvědčené postupy týkající se geografické replikace a vysoké dostupnosti zvýrazněné v transparentním šifrování dat (TDE) s CMK pro cmk na úrovni serveru platí pro CMK na úrovni databáze CMK.

Zálohování a obnovení databází s využitím transparentního šifrování dat s klíčem spravovaným zákazníkem na úrovni databáze

Jakmile je databáze šifrovaná pomocí transparentního šifrování dat pomocí klíče ze služby Azure Key Vault, všechny nově generované zálohy se také šifrují pomocí stejné ochrany transparentním šifrováním dat. Při změně ochrany transparentním šifrováním dat se staré zálohy databáze neaktualizují , aby používaly nejnovější ochranu transparentním šifrováním dat. Pokud chcete obnovit zálohu zašifrovanou pomocí ochrany transparentním šifrováním dat ze služby Azure Key Vault nakonfigurovanou na úrovni databáze, ujistěte se, že se cílovým databázím poskytuje materiál klíče. Doporučujeme zachovat všechny staré verze ochrany transparentním šifrováním dat v trezoru klíčů, aby bylo možné obnovit zálohy databáze.

Důležité

Pro databázi je možné nastavit pouze jednu ochranu transparentním šifrováním dat. Během obnovení však může být do databáze předáno více dalších klíčů, aniž byste je označili jako ochranu transparentním šifrováním dat. Tyto klíče se nepoužívají k ochraně DEK, ale je možné je použít při obnovení ze zálohy, pokud je záložní soubor šifrovaný pomocí klíče s odpovídajícím kryptografickým otiskem.

Obnovení k určitému bodu v čase

Pro obnovení databáze nakonfigurované pomocí klíčů spravovaných zákazníkem na úrovni databáze jsou potřeba následující kroky:

  1. Předem naplní seznam klíčů používaných primární databází pomocí příkazu Get-AzSqlDatabase a -ExpandKeyList parametrů a -KeysFilter "2023-01-01" parametrů. 2023-01-01 je příkladem bodu v čase, do kterého chcete databázi obnovit. Vylučte -KeysFilter , pokud chcete načíst všechny klíče.
  2. Vyberte spravovanou identitu přiřazenou uživatelem (a ID federovaného klienta, pokud konfigurujete přístup mezi tenanty).
  3. Použijte Restore-AzSqlDatabase s parametrem -FromPointInTimeBackup a zadejte předem vyplněný seznam klíčů získaných z výše uvedených kroků a výše uvedenou identitu (a ID federovaného klienta při konfiguraci přístupu mezi tenanty) ve volání rozhraní API pomocí -KeyListparametrů , -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (a v případě potřeby) -FederatedClientId.

Poznámka:

Obnovení databáze bez -EncryptionProtector vlastnosti se všemi platnými klíči ji resetuje tak, aby používala šifrování na úrovni serveru. To může být užitečné při vrácení konfigurace klíče spravovaného zákazníkem na úrovni databáze na konfiguraci klíče spravovaného zákazníkem na úrovni serveru.

Vyřazené obnovení databáze

Pro vyřazené obnovení databáze nakonfigurované pomocí klíčů spravovaných zákazníkem na úrovni databáze jsou potřeba následující kroky:

  1. Předem naplní seznam klíčů používaných primární databází pomocí rutiny Get-AzSqlDeletedDatabaseBackup a parametru -ExpandKeyList . Doporučuje se předat všechny klíče, které zdrojová databáze používala, ale případně se o obnovení může také pokusit s klíči poskytnutými časem odstranění jako .-KeysFilter
  2. Vyberte spravovanou identitu přiřazenou uživatelem (a ID federovaného klienta, pokud konfigurujete přístup mezi tenanty).
  3. Použijte Restore-AzSqlDatabase s parametrem -FromDeletedDatabaseBackup a zadejte předem vyplněný seznam klíčů získaných z výše uvedených kroků a výše uvedenou identitu (a ID federovaného klienta, pokud konfigurujete přístup mezi tenanty) ve volání rozhraní API pomocí -KeyListparametrů , -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (a v případě potřeby, -FederatedClientId) .

Geografické obnovení

Pro geografické obnovení databáze nakonfigurované pomocí klíčů spravovaných zákazníkem na úrovni databáze jsou potřeba následující kroky:

  • Vytvořte předem seznam klíčů používaných primární databází pomocí rutiny Get-AzSqlDatabaseGeoBackup a -ExpandKeyList načtení všech klíčů.
  • Vyberte spravovanou identitu přiřazenou uživatelem (a ID federovaného klienta, pokud konfigurujete přístup mezi tenanty).
  • Použijte Restore-AzSqlDatabase s parametrem -FromGeoBackup a zadejte předem vyplněný seznam klíčů získaných z výše uvedených kroků a výše uvedenou identitu (a ID federovaného klienta, pokud konfigurujete přístup mezi tenanty) ve volání rozhraní API pomocí -KeyListparametrů , -AssignIdentity, -UserAssignedIdentityId, -EncryptionProtector (a v případě potřeby, -FederatedClientId) .

Důležité

Doporučuje se, aby se při obnově databáze zachovaly všechny klíče používané databází. Doporučujeme také předat všechny tyto klíče do cíle obnovení.

Poznámka:

Dlouhodobé zálohy uchovávání záloh (LTR) neposkytují seznam klíčů používaných zálohováním. Pokud chcete obnovit zálohu LTR, musí být všechny klíče používané zdrojovou databází předány cíli obnovení LTR.

Další informace o obnovení zálohování pro SLUŽBU SQL Database s využitím cmK na úrovni databáze s příklady pomocí PowerShellu, Azure CLI a rozhraní REST API najdete v tématu Konfigurace geografické replikace a obnovení zálohy pro transparentní šifrování dat s využitím klíčů spravovaných zákazníkem na úrovni databáze.

Omezení

Funkce klíčů spravovaných zákazníkem na úrovni databáze nepodporuje obměny klíčů, pokud jsou soubory virtuálních protokolů databáze šifrované pomocí starého klíče, který se liší od aktuální primární ochrany databáze. Chyba vyvolaná v tomto případě:

PerDatabaseCMKKeyRotationAttemptedWhileOldThumbprintInUse: Obměna klíčů pro ochranu transparentním šifrováním dat na úrovni databáze je blokována, když aktivní transakce uchovávají protokol šifrovaný starými klíči.

Abychom tomuto scénáři lépe porozuměli, podívejme se na následující časovou osu:

Příklad časové osy obměny klíčů v databázi nakonfigurované pomocí klíčů spravovaných zákazníkem na úrovni databáze.

  • Čas t0 = Vytvoří se databáze bez šifrování.
  • Time t1 = Tato databáze je chráněna pomocí klíče spravovaného zákazníkem Thumbprint Ana úrovni databáze.
  • Čas t2 = Ochrana databáze se otočí na nový klíč spravovaný zákazníkem na úrovni databáze. Thumbprint B
  • Čas t3 = Vyžaduje se Thumbprint C změna ochrany.
  • Pokud aktivní funkce VLF používají Thumbprint A, není rotace povolená.
  • Pokud aktivní funkce VLF nepoužívají Thumbprint A, je rotace povolená.

Můžete použít zobrazení sys.dm_db_log_info (Transact-SQL) – SQL Server pro vaši databázi a vyhledat aktivní soubory virtuálních protokolů. Měl by se zobrazit aktivní kód VLF zašifrovaný prvním klíčem (například Thumbprint A). Po vygenerování dostatek protokolů vložením dat se tento starý VLF vyprázdní a měli byste být schopni provést další otočení klíče.

Pokud se domníváte, že se protokol drží déle, než se čekalo, projděte si následující dokumentaci, kde najdete další řešení potíží:

Další kroky

Projděte si následující dokumentaci k různým operacím CMK na úrovni databáze: