Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Platí pro: Vyhrazené SQL fondy služby Azure Synapse Analytics (dříve SQL DW)
Tip
Microsoft Fabric Data Warehouse je relační sklad v podnikovém měřítku na základu datového jezera s architekturou připravenou pro budoucnost, integrovanou AI a novými funkcemi. Pokud s datovými sklady začínáte, doporučujeme vám začít s „Fabric Data Warehouse“. Stávající úlohy dedikovaného SQL fondu mohou upgradovat na Fabric a získat tak přístup k novým funkcím napříč datovou vědou, analytikou v reálném čase a reportingem.
Transparentní šifrování dat (TDE) pomocí klíče spravovaného zákazníkem (CMK) umožňuje scénář Bring Your Own Key (BYOK) pro ochranu dat v klidu a umožňuje organizacím zavést oddělení rolí při správě klíčů a dat. Používáním TDE spravovaného zákazníkem přebíráte odpovědnost a plnou kontrolu nad řízením životního cyklu klíčů (vytváření, nahrávání, rotace, mazání klíčů), oprávněními k používání klíčů a auditem operací na klíčích.
V tomto scénáři je ochranný nástroj transparentní šifrování dat (TDE) zákazníkem spravovaný klíč, který chrání klíč Database Encryption Key (DEK). TDE ochránce ukládáte buď do Azure Key Vault, nebo Azure Key Vault Managed HSM, což jsou bezpečné cloudové služby správy klíčů navržené pro vysokou dostupnost a škálovatelnost. Obě služby podporují kryptografické klíče chráněné hardwarem ověřeným FIPS 140-2: Azure Key Vault podporuje FIPS 140-2 úroveň 2 a Azure Key Vault Managed HSM podporuje FIPS 140-2 úroveň 3. Obě služby také podporují asymetrické a symetrické typy klíčů a podporované algoritmy a využití závisí na modelu nasazení TDE. Klíč můžete generovat ve službě, importovat jej nebo bezpečně přenést z místních HSM. Přímý přístup ke klíčům je omezen, takže autorizované služby provádějí kryptografické operace bez vystavení materiálu klíče.
Note
Tento článek se zabývá samostatnými dedikovanými SQL pooly (dříve SQL DW).
- Pro dedikované SQL pooly v Azure Synapse Analytics (dříve SQL DW) nastavte TDE protector na úrovni serveru. Všechny šifrované databáze spojené s tímto serverem dědí TDE ochranu.
- Šifrujte data v dedikovaných SQL poolech a serverless SQL poolech v pracovním prostoru Synapse pomocí klíče spravovaného zákazníkem nakonfigurovaného na úrovni pracovního prostoru. Další informace o transparentním šifrování dat pro vyhrazené fondy SQL v pracovních prostorech Synapse najdete v tématu Šifrování služby Azure Synapse Analytics.
Klíč spravovaný zákazníkem (CMK) a přineste si vlastní klíč (BYOK)
V tomto článku se termíny Klíč spravovaný zákazníkem (CMK) a ByOK (Bring Your Own Key) používají zaměnitelně, ale představují určité rozdíly.
Customer Managed Key (CMK) – Řídíte životní cyklus klíče, včetně vytváření, rotace a mazání klíče. Uložte klíč do Azure Key Vault nebo Azure Managed HSM a použijte jej k šifrování klíče šifrování databáze (DEK).
Bring Your Own Key (BYOK) – Bezpečně přinesete nebo importujete svůj vlastní klíč z místního hardwarového bezpečnostního modulu (HSM) do Azure Key Vault. Tyto importované klíče se můžou používat jako jakýkoli jiný klíč ve službě Azure Key Vault, včetně klíče spravovaného zákazníkem pro šifrování klíče DEK. Další informace najdete v tématu Import klíčů chráněných HSM do spravovaného HSM (BYOK).
Výhody TDE spravovaného zákazníkem
TDE spravované zákazníkem přináší následující výhody:
Úplná a podrobná kontrola nad používáním a správou ochrany TDE.
Přehlednost použití ochrany TDE.
Schopnost implementovat oddělení povinností při správě klíčů a dat v organizaci.
Správce služby Azure Key Vault může odvolat přístupová oprávnění ke klíčům, aby byla zašifrovaná databáze nepřístupná.
Centrální správa klíčů ve službě Azure Key Vault
Větší důvěryhodnost od koncových zákazníků, protože Služba Azure Key Vault je navržená tak, aby Microsoft neviděl ani extrahovala šifrovací klíče.
Important
Pro ty, kteří používají TDE spravované službou a chtějí začít používat TDE spravované zákazníky, zůstávají data během přechodu šifrovaná a nedochází k výpadkům ani přešifrování databázových souborů. Při přechodu od klíče spravovaného službou ke klíči spravovanému zákazníkem je potřeba jenom znovu zašifrovat DEK, což je rychlá online operace.
Oprávnění ke konfiguraci TDE spravovaného zákazníkem ve službě Azure Key Vault
Vyberte typ služby Azure Key Vault, který chcete použít.
Aby mohl logický server SQL v Azure používat ochranu TDE uloženou ve službě Azure Key Vault k šifrování klíče DEK, musí Key Vault Administrator udělit serveru přístupová oprávnění pomocí jeho jedinečné identity Microsoft Entra. Identita serveru může být spravovaná identita přiřazená systémem nebo spravovaná identita přiřazená uživatelem přiřazená k serveru. Existují dva přístupové modely pro udělení přístupu k trezoru klíčů serveru:
Řízení přístupu na základě role v Azure (RBAC) – Pomocí Azure RBAC udělte uživateli, skupině nebo aplikaci přístup k trezoru klíčů. Tato metoda se doporučuje pro její flexibilitu a členitost. Identita serveru potřebuje uživatelskou roli Key Vault Crypto Service Encryption User, aby mohla klíč používat pro šifrování a dešifrovací operace.
Zásady přístupu trezoru – Pomocí zásad přístupu trezoru klíčů udělte serveru přístup k trezoru klíčů. Tato metoda je jednodušší a přímější, ale méně flexibilní. Identita serveru vyžaduje následující oprávnění na klíčovém trezoru:
- get – pro načtení veřejné části a vlastností klíče ve službě Azure Key Vault
- wrapKey – schopnost chránit (šifrovat) DEK
- unwrapKey – aby bylo možné odemknout (dešifrovat) DEK
V nabídce Konfigurace přístupu v Azure portálu pro trezor klíčů máte možnost vybrat řízení přístupu na základě role Azure nebo zásadu přístupu ke klíčovému trezoru. Podrobné pokyny krok za krokem k nastavení přístupové konfigurace Azure Key Vault pro TDE najdete v článku Nastavení SQL Server TDE Extensible Key Management pomocí Azure Key Vault. Další informace o přístupových modelech najdete v tématu Zabezpečení služby Azure Key Vault.
Správce služby Key Vault může také povolit protokolování událostí auditu trezoru klíčů, aby je bylo možné auditovat později.
Když server nakonfigurujete tak, aby používal ochranu TDE ze služby Azure Key Vault, odešle server klíč DEK každé databáze s povoleným TDE do služby Azure Key Vault k zašifrování. Klíčový trezor vrací zašifrovaný DEK, který server ukládá do uživatelské databáze.
V případě potřeby server odešle chráněný DEK do trezoru klíčů k dešifrování DEK.
Auditoři mohou pomocí Azure Monitoru zkontrolovat protokoly AuditEvent v trezoru klíčů, pokud je protokolování povoleno.
Note
Může trvat asi 10 minut, než se jakákoli změna oprávnění pro klíčový trezor uplatní. Tento interval zahrnuje odebrání přístupových oprávnění k chrániči TDE v AKV a uživatelé mohou mít stále přístupová oprávnění.
Požadavky na konfiguraci TDE spravovaného zákazníkem v Azure Key Vault
Povolte funkce ochrany proti soft-delete a před vyprázdněním v Azure Key Vault. Tato konfigurace pomáhá předcházet nechtěnému nebo škodlivému odstranění trezoru klíčů nebo klíče, které by mohlo vést k přechodu databáze do stavu nepřístupnosti. Když nastavíte ochranu TDE na existujícím serveru nebo během vytváření serveru, Azure SQL ověřuje, že klíčový trezor, který používáte, má zapnuté obnovitelné odstranění i ochranu proti vyprázdnění. Pokud v trezoru klíčů není povolený soft-delete a ochrana proti vymazání, nastavení ochrany TDE selže s chybou. V tomto případě povolte soft-delete a purge protection na klíčovém trezoru a poté proveďte nastavení ochránce TDE.
Pokud používáte bránu firewall se službou Azure Key Vault, musíte povolit možnost Povolit důvěryhodným službám Microsoftu obejít bránu firewall, pokud nepoužíváte privátní koncové body pro Azure Key Vault. Další informace najdete v tématu Konfigurace a nastavení bran firewall služby Azure Key Vault a virtuálních sítí.
Klíčové požadavky pro konfiguraci protektoru TDE
transparentní šifrování dat s klíči spravovanými zákazníkem používá externí klíč, nazývaný TDE protector, uložený v Azure Key Vault k ochraně šifrovacího klíče databáze (DEK).
Platí následující požadavky.
Podporované typy a velikosti klíčů
TDE ochránce může být chráněn asymetrickými klíči uloženými v Azure Key Vault. Podporované velikosti klíčů jsou 2 048 bitů a 3 072 bitů.
Požadavky na stav klíče a platnost
- Pokud určíte datum aktivace klíče, nastavte ho na datum a čas v minulosti.
- Pokud určíte datum vypršení platnosti klíče, nastavte ho na datum a čas v budoucnu.
- Klíč musí být ve stavu Povoleno .
Požadavky na import klíčů
Pokud importujete existující klíč do Azure Key Vault, zadejte klíč v jednom z následujících podporovaných formátů:
.pfx.byok.backup
Doporučení pro konfiguraci TDE spravovaného zákazníkem v Azure Key Vault
Pokud chcete zachovat vysokou dostupnost a vyhnout se problémům s omezováním, postupujte podle těchto pokynů pro každé předplatné:
Pro zajištění optimálního výkonu a spolehlivosti použijte dedikovaný Azure Key Vault pro Azure SQL. Nesdílejte tento trezor klíčů s jinými službami. Pokud je trezor klíčů pod velkým zatížením kvůli sdílenému využití nebo nadměrným operacím s klíči, může to negativně ovlivnit výkon databáze, zejména při přístupu ke šifrovacím klíčům. Azure Key Vault vynucuje limity omezování. Při překročení těchto limitů mohou být operace zpožděné nebo neúspěšné. Toto riziko je nejvyšší při failoverech serveru, které spustí operace s klíčem pro každou databázi na serveru.
Další informace o chování omezování požadavků najdete v pokynech k omezování požadavků ve službě Azure Key Vault.
Počet databází Hyperscale, které můžete přiřadit k jednomu Azure Key Vault, závisí na počtu page serverů. Každý stránkový server je propojený s logickým datovým souborem. Pro zjištění počtu serverů stránek spusťte následující dotaz.
-- # of page servers (primary copies) for this database SELECT COUNT(*) AS page_server_count FROM sys.database_files WHERE type_desc = 'ROWS';Nepřiřazujte ke službě Azure Key Vault více než 500 stránkových serverů. S růstem databáze se počet stránkových serverů zvyšuje automaticky, takže je důležité pravidelně monitorovat velikost databáze. Pokud počet stránkovacích serverů přesáhne 500, používejte pro každou databázi Hyperscale vyhrazený Azure Key Vault a nesdílejte tento klíčový trezor s jinými Azure SQL zdroji.
Monitorování a konfigurace upozornění služby Azure Key Vault Pro více informací o monitorování a upozorněních viz Monitorování Azure Key Vault a Konfigurace výstrah Azure Key Vault.
Nastavte zámek prostředku v trezoru klíčů, abyste mohli řídit, kdo může tento kritický prostředek odstranit, a zabránili náhodnému nebo neoprávněnému odstranění. Chcete-li se dozvědět více o zámcích prostředků.
Povolte protokolování a zprávy u všech šifrovacích klíčů: Azure Key Vault poskytuje protokoly, které lze snadno integrovat do jiných nástrojů pro správu informací o zabezpečení a událostí. Operations Management Suite Log Analytics je jedním z příkladů služby, která je již integrovaná.
Použijte klíčový trezor z oblasti Azure, který může replikovat svůj obsah do spárované oblasti pro zajištění maximální dostupnosti. Další informace najdete v tématu osvědčené postupy pro používání služby Azure Key Vault a dostupnosti a redundance služby Azure Key Vault.
Doporučení pro konfiguraci ochrany TDE
Uchovejte kopii TDE protectoru na bezpečném místě nebo ji uložte u escrow služby.
Pokud vygenerujete klíč v Key Vaultu, vytvořte zálohu klíče před prvním použitím klíče v Azure Key Vault. Zálohu můžete obnovit pouze do Azure Key Vault. Pro více informací viz příkaz Backup-AzKeyVaultKey . Azure Managed HSM podporuje vytvoření úplné zálohy celého obsahu HSM, včetně všech klíčů, verzí, atributů, tagů a přiřazení rolí. Další informace naleznete v tématu Úplné zálohování a obnovení a selektivní obnovení klíče.
Vytvořte novou zálohu pokaždé, když provedete jakékoli změny klíče (například atributy klíčů, tagy, ACL).
Při rotaci klíčů si ponechte předchozí verze klíče v trezoru klíčů nebo v Managed HSM, abyste mohli obnovit starší databázové zálohy. Když se změní TDE ochrana v databázi, staré zálohy databáze nejsou aktualizovány pro nejnovější TDE ochranu. Při obnovení každá záloha vyžaduje TDE ochranu, kterou byla zašifrována při vytvoření. Pro otáčení klíčů postupujte podle pokynů v článku Rotate the Transparent Data encryption (TDE) protector.
Všechny dříve použité klíče si ponechte v Azure Key Vault i po přechodu na klíče spravované službou. Zajišťuje, že zálohy databáze lze obnovit pomocí ochranných prvků TDE uložených v Azure Key Vault. Chránič TDE vytvořený pomocí Azure Key Vault musí být udržován, dokud nebudou všechny zbývající uložené zálohy vytvořeny s klíči spravovanými službou. Vytvořte obnovitelné zálohy těchto klíčů pomocí Backup-AzKeyVaultKey.
Pokud chcete odebrat potenciálně ohrožený klíč během incidentu zabezpečení bez rizika ztráty dat, postupujte podle kroků v článku Odebrání ochrany transparentního šifrování dat (TDE) pomocí PowerShellu. Vždy aktualizujte na novou ochranu TDE a ověřte, že všechny databáze používají nový klíč, před tím, než odstraníte nebo zakážete ohrožený klíč. Smazání nebo deaktivace klíče bez předchozího otočení způsobí, že všechny šifrované databáze se stanou nepřístupnými a nezneplatní žádné kopie klíčů, které byly dříve zálohovány a obnoveny do jiného trezoru.
Otočení TDE ochránce
Když rotujete protektor TDE, nahradíte klíč, který chrání šifrovací klíč databáze (DEK). Rotace klíčů je online operace a trvá jen několik sekund. Tato operace dešifruje a znovu šifruje pouze šifrovací klíč databáze, nikoli celou databázi.
Ochranu TDE můžete obměnit přepnutím konfigurace na použití nového klíče uloženého v Azure Key Vault. V závislosti na nabídce a podporované konfiguraci může tento klíč mít následující hodnoty:
- Přechod na novou verzi téhož klíče
- Přepnutí na jiný klíč
Otáčení ochranného prvku TDE lze provádět ručně nebo pomocí automatizované rotační funkce.
Automatickou rotaci chrániče TDE můžete povolit, když konfigurujete chránič TDE pro server. Automatizovaná rotace je ve výchozím nastavení zakázaná. Je-li tato funkce povolena, server průběžně kontroluje Key Vault, zda neobsahuje nové verze klíče, který se používá jako ochrana TDE. Pokud server detekuje novou verzi klíče, automaticky do 24 hodin obmění ochranu TDE na serveru nebo databázi na nejnovější verzi klíče.
Note
Když nastavujete TDE pomocí CMK pomocí ruční nebo automatizované rotace klíčů, vždy používáte nejnovější verzi klíče, kterou systém podporuje. Nastavení nepovoluje použití předchozí nebo nižší verze klíčů. Použití vždy nejnovější verze klíče odpovídá zásadám zabezpečení Azure SQL, které nepovolují předchozí verze klíčů, jež by mohly představovat ohrožení.
Nepřístupný TDE ochránce
Když nastavíte TDE tak, aby používalo klíč spravovaný zákazníkem, databáze potřebuje nepřetržitý přístup k ochránci TDE, aby zůstala online. Pokud server ztratí přístup k zákaznicky spravovanému TDE protectoru v Azure Key Vault, databáze začne do 10 minut odmítat všechna připojení, zobrazí chybovou hlášku a změní stav na Nedostupné. Jediná akce povolená pro databázi v nepřístupném stavu je její odstranění.
Nepřístupný stav
Pokud je databáze nepřístupná kvůli přerušovanému výpadku sítě (například kvůli chybě 5XX), nevyžaduje se žádná akce, protože databáze se automaticky vrátí do online režimu. Aby se snížil vliv síťových chyb nebo výpadků při přístupu k TDE ochránci v Azure Key Vault, služba zavádí 24hodinový buffer před pokusem přesunout databázi do nepřístupného stavu. Pokud dojde k přepnutí při selhání před dosažením stavu nepřístupnosti, databáze se stane nedostupnou kvůli ztrátě mezipaměti šifrování.
Pokud server ztratí přístup k zákaznicky spravovanému TDE protectoru v Azure Key Vault kvůli jakékoli chybě Azure Key Vault (například chybě 4XX), databáze se po 30 minutách přesune do nepřístupného stavu.
Obnovení přístupu k databázi po chybě Azure Key Vault
Po obnovení přístupu ke klíči vyžaduje návrat databáze do režimu online další čas a kroky, které se můžou lišit v závislosti na době nedostupnosti klíče a velikosti dat v databázi.
Pokud se přístup ke klíči obnoví během 30 minut, databáze se během následující hodiny automaticky opraví. Pokud se ale přístup ke klíči obnoví po více než 30 minutách, automatické opravy databáze není možné. V takových případech zahrnuje obnovení databáze další postupy prostřednictvím webu Azure Portal a v závislosti na velikosti databáze může být časově náročné.
Jakmile je databáze opět online, předchozí nastavení na úrovni serveru, včetně konfigurací skupin pro převzetí služeb při selhání, značek a nastavení na úrovni databáze, jako jsou konfigurace elastického fondu, škálování pro čtení, automatické pozastavení činnosti, historie obnovy k určitému bodu v čase, zásady dlouhodobého uchovávání dat a další, se ztratí. Proto doporučujeme, aby zákazníci implementovali systém oznámení, aby během 30 minut detekovali ztrátu přístupu k šifrovacímu klíči. Po uplynutí 30minutového intervalu doporučujeme ověřovat všechna nastavení na úrovni serveru a databáze v obnovené databázi.
Následuje přehled dodatečných kroků potřebných k tomu, aby se databáze vrátila do online režimu, která je na portálu nedostupná.
Náhodné odvolání přístupu k šifrovacímu mechanizmu TDE
Může se stát, že někdo s dostatečnými přístupovými právy k trezoru klíčů nebo spravovanému HSM zařízení omylem zakáže přístup serveru k tomuto klíči tak, že:
Odebrání oprávnění "get", "wrapKey", "unwrapKey" z klíčového trezoru nebo spravovaného HSM ze serveru
odstranění klíče
odstranění trezoru klíčů nebo spravovaného HSM
změna pravidel brány firewall pro trezor klíčů nebo pro spravovanou HSM
odstranění spravované identity serveru v Microsoft Entra ID
Přečtěte si další informace o běžných příčinách nedostupné databáze.
Blokovaná konektivita mezi SQL Managed Instance a Azure Key Vault
K bloku síťového připojení mezi službou SQL Managed Instance a trezorem klíčů nebo spravovaným HSM dochází většinou v případě, že existuje trezor klíčů nebo spravovaný prostředek HSM, ale jeho koncový bod se nedá získat ze spravované instance. Všechny scénáře, kdy je možné dosáhnout trezoru klíčů nebo spravovaného koncového bodu HSM, ale připojení se odepře, chybějící oprávnění atd., způsobí, že databáze změní stav na Nepřístupný.
Nejčastější příčiny nedostatku síťové konektivity k Azure Key Vault jsou:
Azure Key Vault je vystaven přes soukromý koncový bod a soukromá IP adresa služby Azure Key Vault není povolena v odchozích pravidlech skupiny zabezpečení sítě (NSG) přidružené k podsíti spravované instance.
Chybné rozlišení DNS, jako když plně kvalifikovaný název domény trezoru klíčů nebo spravovaného HSM není vyřešen nebo je vyřešen na neplatnou IP adresu.
Otestujte konektivitu ze služby SQL Managed Instance do Azure Key Vaultu, který obsahuje ochranu TDE.
- Koncový bod je FQDN trezoru, například <vault_name.vault.azure.net> (bez https://).
- Port, který byste měli otestovat, je 443.
- Výsledek pro RemoteAddress by měl existovat a mělo by se jednat o správnou IP adresu.
- Výsledkem testu TCP by mělo být TcpTestSucceeded: True.
V případě, že test vrátí hodnotu TcpTestSucceeded: False, zkontrolujte konfiguraci sítě:
Zkontrolujte přeloženou IP adresu a ověřte, že je platná. Chybějící hodnota znamená problém s překladem DNS.
Ověřte, že skupina zabezpečení sítě ve spravované instanci obsahuje odchozí pravidlo, které pokrývá přeloženou IP adresu na portu 443, zejména pokud přeložená adresa patří do privátního koncového bodu trezoru klíčů nebo spravovaného koncového bodu HSM.
Zkontrolujte další síťové konfigurace, jako je směrovací tabulka, existence virtuálního zařízení a jeho konfigurace atd.
Monitorovat TDE spravované zákazníkem
Pokud chcete monitorovat stav databáze a povolit upozorňování na ztrátu přístupu pro ochranu transparentním šifrováním dat, nakonfigurujte následující funkce Azure:
Azure Resource Health. Nepřístupná databáze, která ztratila přístup k chrániči TDE, se poté, co je při prvním pokusu o připojení k databázi přístup odepřen, zobrazí jako "Nedostupná".
Protokol aktivit při selhání přístupu k chráněné TDE (Transparent Data Encryption) v trezoru klíčů spravovaném zákazníkem jsou položky přidány do protokolu aktivit. Vytvořením upozornění na tyto události můžete přístup co nejdříve obnovit.
Akční skupiny lze definovat tak, aby vám posílaly oznámení a upozornění podle vašich preferencí, například e-mail, SMS, Push, Voice, Logic App, Webhook, ITSM nebo Automation Runbook.
Zálohování a obnova databáze s TDE spravovaným zákazníkem
Jakmile je databáze zašifrována pomocí TDE s použitím klíče z Azure Key Vault, jsou všechny nově vytvářené zálohy také zašifrovány stejným ochranným prvkem TDE. 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.
Chcete-li obnovit zálohu zašifrovanou chráničem TDE z Azure Key Vault, ujistěte se, že je klíčový materiál k dispozici na cílovém serveru. Proto uchovejte všechny staré verze TDE protectoru v key vaultu nebo spravovaném HSM, aby bylo možné obnovit zálohy databáze.
Important
Pro server nelze mít více než jeden TDE ochranný prvek současně. Klíč označený jako nastavit klíč jako výchozí ochranu TDE v podokně Azure portálu je ochranou TDE. Několik klíčů ale můžete propojit se serverem, aniž byste je označili jako ochranu transparentním šifrováním dat. Tyto klíče se nepoužívají k ochraně DEK, ale lze je použít při obnově ze zálohy, pokud je záložní soubor zašifrován klíčem s odpovídajícím otiskem klíče.
Pokud klíč potřebný k obnovení zálohy už není pro cílový server dostupný, vrátí se následující chybová zpráva při pokusu o obnovení: Cílový server <Servername> nemá přístup ke všem identifikátorům URI AKV vytvořeným mezi <časovým razítkem č. 1> a <časovým razítkem č. 2>. Po obnovení všech identifikátorů URI AKV zkuste operaci zopakovat."
Pokud ho chcete zmírnit, spusťte rutinu Get-AzSqlServerKeyVaultKey pro cílový server nebo Get-AzSqlInstanceKeyVaultKey pro cílovou spravovanou instanci, abyste vrátili seznam dostupných klíčů a identifikovali chybějící klíče. Pokud chcete zajistit, aby všechny zálohy mohly být obnoveny, ujistěte se, že cílový server pro obnovení má přístup ke všem potřebným klíčům. Tyto klíče není nutné označovat za ochránce TDE.
Další informace o obnovení zálohování pro vyhrazené fondy SQL ve službě Azure Synapse Analytics najdete v tématu Obnovení vyhrazeného fondu SQL.
Další aspekty souborů protokolu: Zálohované soubory protokolu zůstanou zašifrované pomocí původní ochrany TDE, i když byla změněna a databáze teď používá novou ochranu TDE. V době obnovení jsou k obnovení databáze potřeba oba klíče. Pokud logovací soubor používá ochranu TDE uloženou v Azure Key Vault, je tento klíč potřeba v době obnovení, i když byla mezitím databáze změněna na servisně spravované TDE.
Vysoká dostupnost s využitím transparentního šifrování dat spravovaného zákazníkem
Díky využití více vrstev redundance služby Azure Key Vault mohou řešení TDE využívající klíč spravovaný zákazníkem těžit z dostupnosti a odolnosti služby Azure Key Vault. Mohou se plně spolehnout na řešení redundance Azure Key Vault.
Více redundančních vrstev Azure Key Vault zajišťuje přístup ke klíčům i v případě, že selžou jednotlivé komponenty služby nebo pokud jsou Azure regiony či dostupné zóny mimo provoz. Další informace najdete v Azure Key Vault - dostupnost a redundance.
Azure Key Vault nabízí následující komponenty dostupnosti a odolnosti automaticky bez zásahu uživatele: