Transparentní šifrování dat Azure SQL s využitím klíče spravovaného zákazníkem

Platí pro:Azure SQL Database Azure SQL Managed InstanceAzure Synapse Analytics (pouze vyhrazené fondy SQL)

Transparentní šifrování dat (TDE) v Azure SQL pomocí klíče spravovaného zákazníkem (CMK) umožňuje scénář přineste si vlastní klíč (BYOK) pro ochranu neaktivních uložených dat a umožňuje organizacím implementovat oddělení povinností při správě klíčů a dat. Při transparentním šifrování dat spravovaném zákazníkem odpovídá za správu životního cyklu klíče (tzn. za vytvoření, nahrání, obměnu a odstranění klíče), za oprávnění k použití klíče a za auditování operací s klíči zákazník, který má nad nimi plnou kontrolu.

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.

Pro Azure SQL Database a Azure Synapse Analytics je chránič TDE nastaven na úrovni serveru a je zděděný všemi šifrovanými databázemi přidruženými k danému serveru. U spravované instance Azure SQL je ochrana TDE nastavena na úrovni instance a je následně používána všemi šifrovanými databázemi v této instanci. Termínový server odkazuje na server ve službě SQL Database i Azure Synapse i na spravovanou instanci ve službě SQL Managed Instance v tomto článku, pokud není uvedeno jinak.

Správa ochrany TDE na úrovni databáze ve službě Azure SQL Database je dostupná. Další informace najdete v tématu Transparentní šifrování dat (TDE) s klíči spravovanými zákazníkem na úrovni databáze.

Poznámka:

Tento článek se týká Azure SQL Database, Azure SQL Managed Instance a Azure Synapse Analytics (vyhrazené fondy SQL (dříve SQL DW)). 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.

Poznámka:

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

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.

  • klíč spravovaný zákazníkem (CMK) – zákazník spravuje životní cyklus klíče, včetně vytvoření, obměny a odstranění klíče. Klíč je uložený ve službě Azure Key Vault nebo spravovaném HSM Azure a používá se k šifrování šifrovacího klíče databáze (DEK) v Azure SQL, SQL Serveru na virtuálním počítači Azure a místním SQL Serveru.

  • Přineste si vlastní klíč (BYOK) – Zákazník bezpečně přenese nebo naimportuje vlastní klíč z místního modulu hardwarového zabezpečení (HSM) do služby Azure Key Vault nebo spravovaného HSM Azure. 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

Transparentní šifrování dat (TDE) spravované zákazníkem poskytuje zákazníkovi 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.

Důležité

Pro ty, kteří používají transparentní šifrování dat spravované službou, kteří chtějí začít používat transparentní šifrování dat spravované zákazníkem, zůstanou data během procesu přechodu zašifrovaná a nedojde k žádným výpadkům ani k opětovnému š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 transparentního šifrování dat spravovaného zákazníkem

Diagram znázorňující nastavení a fungování TDE spravovaného zákazníkem.

Vyberte typ služby Azure Key Vault, který chcete použít.

Aby logický server v Azure mohl k šifrování DEK použít ochranný klíč TDE uložený ve službě Azure Key Vault, musí správce služby Key Vault udělit serveru přístupová oprávnění prostřednictvím 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. Role uživatele pro šifrování služby Key Vault Crypto Service je vyžadována serverem, aby mohl používat klíč pro operace šifrování a dešifrování.

  • 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 musí mít v trezoru klíčů následující oprávnění:

    • 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 k nastavení konfigurace přístupu ke službě Azure Key Vault pro transparentní šifrování dat najdete v tématu Nastavení rozšiřitelné správy klíčů transparentního šifrování dat SQL Serveru pomocí služby 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.

Pokud je server nakonfigurovaný tak, aby používal ochranu transparentním šifrováním dat ze služby Azure Key Vault, server odešle klíč DEK každé databáze s povoleným transparentním šifrováním dat do trezoru klíčů k šifrování. Key Vault vrátí šifrovaný klíč DEK, který se pak uloží do uživatelské databáze.

V případě potřeby server odešle chráněný klíč DEK do trezoru klíčů k dešifrování.

Auditoři můžou pomocí služby Azure Monitor kontrolovat protokoly AuditEvent trezoru klíčů, pokud je protokolování povolené.

Poznámka:

Změny oprávnění pro trezor klíčů se mohou projevit přibližně za 10 minut. To zahrnuje odvolání přístupových oprávnění k ochraně transparentním šifrováním dat v AKV a uživatelé v tomto časovém rámci můžou mít stále přístupová oprávnění.

Požadavky na konfiguraci transparentního šifrování dat spravovaného zákazníkem

  • Funkce obnovitelného odstranění a ochrany před vymazáním musí být povolené ve službě Azure Key Vault. To pomáhá zabránit situaci náhodného nebo škodlivého smazání klíčového trezoru či klíče, což může způsobit, že databáze přejde do nepřístupného stavu. Při konfiguraci ochrany TDE na existujícím serveru nebo při vytváření nového serveru Azure SQL ověřuje, zda je trezor klíčů používán s aktivní ochranou před obnovitelným odstraněním a vymazáním. Pokud v trezoru klíčů není povolený soft-delete a ochrana proti vymazání, nastavení ochrany TDE selže s chybou. V takovém případě musí být v trezoru klíčů nejprve povolena ochrana jemného odstranění a ochrana proti vymazání, a pak by se mělo provést nastavení TDE ochrany.

  • 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 nebo Azure Managed HSM k ochraně šifrovacího klíče databáze (DEK).

Platí následující požadavky.

Podporované typy a velikosti klíčů

V závislosti na nabídce Azure SQL a konfiguraci TDE může být ochrana TDE zajištěna asymetrickými nebo symetrickými klíči uloženými v Azure Key Vault nebo Azure Key Vault Managed HSM.

  • Asymetrické klíče (RSA nebo RSA HSM)

    • Podporováno v Azure Key Vault a Azure Key Vault Managed HSM
    • Podporované velikosti klíčů: 2 048 bitů a 3 072 bitů
    • Podporováno pro Azure SQL Database, Azure SQL Managed Instance a Azure Synapse Analytics

  • Symetrické klíče (AES)

    • Podporováno v Azure Key Vault Premium (preview) a Azure Key Vault Managed HSM
    • Podporované velikosti klíčů: 128bitové, 192bitové a 256bitové
    • Podporováno pouze pro Azure SQL Database, aktuálně ve veřejné náhledové verzi

Poznámka:

transparentní šifrování dat se symetrickými klíči (AES) je momentálně ve verzi Preview. Preview funkce jsou vydávány s omezenými možnostmi, ale Microsoft je zpřístupňuje v náhledové podobě, aby zákazníci mohli získat předčasný přístup a poskytnout zpětnou vazbu. Funkce ve verzi Preview podléhají samostatným dodatečným podmínkám verze Preview a nevztahují se na smlouvy SLA. Podpora je poskytována jako nejlepší úsilí v určitých případech. Podpora Microsoftu ale chce získat zpětnou vazbu k funkcím ve verzi Preview a v některých případech může poskytovat podporu co nejlépe. Funkce ve verzi Preview můžou mít omezené nebo omezené funkce a můžou být dostupné jenom ve vybraných geografických oblastech.

Chování správy klíčů pro symetrické (AES) klíče

Jako TDE ochránce můžete použít symetrické (AES) klíče uložené v Azure Key Vault Premium (náhled) nebo Azure Key Vault Managed HSM. Chcete-li začít používat klíč z místního hardwarového bezpečnostního modulu (HSM), importujte klíč do jedné z těchto služeb. Po počátečním importu probíhají všechny probíhající operace životního cyklu klíčů v Azure Key Vault Premium (náhled) nebo Azure Key Vault Managed HSM. Obnovení k určitému bodu v čase, geografické zotavení po havárii a opakované ověření klíče – to vše závisí na tom, aby tam klíč zůstal dostupný. Udržujte lokální zálohy importovaných klíčů pro podporu scénářů obnovy a opětovné validace. Toto chování platí pouze pro symetrické (AES) klíče, nikoli pro asymetrické (RSA) klíče.

Požadavky na stav klíče a platnost

  • Pokud je zadané datum aktivace klíče, musí být nastavené na datum a čas v minulosti.
  • Pokud je zadané datum vypršení platnosti klíče, musí být nastavené 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

Pokud chcete importovat klíče chráněné HSM do spravovaného Azure HSM, viz Import klíčů chráněných HSM do spravovaného HSM (BYOK).

Poznámka:

Problém s verzemi Thales CipherTrust Manageru před verzí 2.8.0 brání tomu, aby klíče nově importované do služby Azure Key Vault byly použity ve službě Azure SQL Database nebo Azure SQL Managed Instance pro scénáře šifrování dat spravované zákazníkem pomocí TDE. Další podrobnosti o tomto problému najdete v poznámkách k verzi nástroje CipherTrust Cloud Key Manager. V takových případech počkejte 24 hodin po importu klíče do služby Azure Key Vault a začněte ho používat jako ochranu transparentním šifrováním dat pro server nebo spravovanou instanci. Tento problém je vyřešený v thales cipherTrust Manager v2.8.0.

Doporučení pro konfiguraci zákazníkem spravovaného TDE

  • 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 regulaci výkonu najdete v pokynech k omezování výkonu služby 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 prostředky Azure SQL použijte vyhrazenou službu Azure Key Vault .

    • Přidružte k jedné službě Azure Key Vault maximálně 500 databází pro obecné účely .

    • Přidružte k jedné službě Azure Key Vault maximálně 200 databází pro důležité obchodní informace .

    • Počet databází Hyperscale, které je možné přidružit k jediné službě Azure Key Vault, je určen počtem stránkových serverů. Každý stránkový server je propojený s logickým datovým souborem. Pokud chcete zjistit počet stránkových serverů, 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 Další informace o monitorování a upozorňování najdete v tématu Monitorování služby Azure Key Vault a konfigurace upozornění služby Azure Key Vault.

  • Pro sladění s dlouhodobým plánováním kryptografické odolnosti zvažte použití symetrických klíčů AES-256 jako ochrany TDE.

    Očekává se, že velkoplošné kvantové počítání prolomí kryptografické algoritmy s veřejným klíčem, jako je RSA. Symetrická kryptografie, včetně AES, je považována za kvantově odolnou při dostatečně velkých klíčích.

    Širší kvantově bezpečná strategie Microsoft klade důraz na krypto-agilitu. Přijměte silnější symetrické algoritmy tam, kde jsou podporovány, a plánujte budoucí kryptografické přechody, jak se budou vyvíjet pokyny a standardy.

    Důležité

    transparentní šifrování dat s symetrickými klíči (AES) se v současné době podporuje jenom pro Azure SQL Database a je ve verzi Public Preview.

  • 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í. Přečtěte si další informace o uzamčení 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.

Poznámka:

Pokud chcete zajistit větší flexibilitu při konfiguraci zákazníkem spravovaného transparentního šifrování dat (TDE), Azure SQL Database a Azure SQL Managed Instance v jedné oblasti je nyní možné propojit se službou Azure Key Vault v libovolné jiné oblasti. Server a trezor klíčů nemusí být umístěny ve stejné oblasti.

Doporučení pro konfiguraci ochrany TDE

  • Uchovávejte kopii ochrany transparentním šifrováním dat na zabezpečeném místě nebo ji uložte do služby escrow.

  • Pokud se klíč vygeneruje v trezoru klíčů, vytvořte zálohu klíčů před prvním použitím klíče ve službě Azure Key Vault. Zálohování je možné obnovit pouze do služby Azure Key Vault. Přečtěte si další informace o příkazu Backup-AzKeyVaultKey . Spravovaný HSM Azure podporuje vytvoření úplného zálohování celého obsahu HSM včetně všech klíčů, verzí, atributů, značek 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 při každé změně klíče (například klíčové atributy, značky, seznamy 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.

  • Uchovávejte všechny dříve použité klíče ve službě Azure Key Vault nebo Spravované HSM Azure i po přepnutí na klíče spravované službou. Zajišťuje možnost obnovení záloh databáze pomocí chráněných prvků TDE uložených ve službě Azure Key Vault nebo ve spravovaném Azure Managed HSM. Ochrany TDE vytvořené pomocí Azure Key Vault nebo Spravovaného HSM Azure musí být udržovány, dokud všechny zbývající uložené zálohy nebudou vytvořeny pomocí klíčů spravovaných službou. Vytvořte záložní kopie těchto klíčů s možností obnovení pomocí rutiny 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.

Návod

Použití verzovaných a bez-verzových klíčů služby Azure Key Vault pro Transparentní Šifrování Dat (TDE)

Při nastavování ochrany TDE můžete odkazovat na klíč Azure Key Vault pomocí konkrétní verze klíče nebo identifikátoru klíče bez verzování.

V obou případech Azure SQL Database vždy překládá a používá nejnovější povolenou verzi klíče ve službě Azure Key Vault nebo spravovaném HSM služby Azure Key Vault. V konfiguraci ochrany transparentním šifrováním dat používejte identifikátory klíčů bez verzí, abyste se vyhnuli vložení konkrétní verze klíče.

Identifikátory klíčů bez verzí se v současné době podporují jenom pro Azure SQL Database.

Příklady:

  • Identifikátor klíče, který obsahuje konkrétní verzi

    https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>

  • Identifikátor klíče bez verzí

    https://<key-vault-name>.vault.azure.net/keys/<key-name>

Otočení TDE ochránce

Obměnou protektoru TDE můžete nahradit klíč používaný k ochraně šifrovacího klíče databáze (DEK). Obměna klíčů je online operace a její dokončení by mělo trvat pouze několik sekund. Operace pouze dešifruje a znovu zašifruje šifrovací klíč databáze, nikoli celou databázi.

Klíč ochrany TDE můžete obměnit změnou konfigurace tak, aby používala nový klíč uložený ve službě Azure Key Vault nebo Azure Key Vault Managed HSM. V závislosti na nabídce Azure SQL a podporované konfiguraci to může zahrnovat:

  • Přechod na novou verzi téhož klíče
  • Přepnutí na jiný klíč
  • Přepínání mezi podporovanými typy klíčů, například asymetrickými klíči (RSA) a symetrickými klíči (AES)

Poznámka:

transparentní šifrování dat s symetrickými klíči (AES) se v současné době podporuje jenom pro Azure SQL Database a je ve verzi Public Preview.

Otočení ochrany TDE lze provést buď ručně, nebo pomocí funkce automatizovaného otáčení.

Automatická rotace ochrany TDE může být povolena při konfiguraci ochrany TDE pro server. Automatizovaná rotace je ve výchozím nastavení zakázaná. Pokud je tato možnost povolená, server nepřetržitě kontroluje trezor klíčů nebo Managed HSM pro všechny nové verze klíče, které se používají jako ochrana transparentním šifrováním dat (TDE). Pokud se zjistí nová verze klíče, ochrana transparentním šifrováním dat na serveru nebo databázi se během 24 hodin automaticky otočí na nejnovější verzi klíče.

Při použití s automatizovanou rotací klíčů ve službě Azure Key Vault nebo autorotací ve službě Azure Managed HSM tato funkce umožňuje kompletní automatickou obměnu pro TDE ochranu ve službě Azure SQL Database a Azure SQL Managed Instance.

Poznámka:

Nastavení TDE s CMK pomocí ruční nebo automatizované rotace klíčů vždy použije nejnovější verzi podporovaného klíče. Nastavení nepovoluje použití předchozí nebo nižší verze klíčů. Vždy používat nejnovější verzi klíče odpovídá zásadám zabezpečení Azure SQL, které nepovolují předchozí verze klíčů, které by mohly být ohroženy. Předchozí verze klíče můžou být potřeba pro účely zálohování nebo obnovení databáze, zejména pro dlouhodobé zálohy uchovávání, kde je potřeba zachovat starší verze klíčů. Pro nastavení geografické replikace musí být všechny klíče vyžadované zdrojovým serverem přítomné na cílovém serveru.

Aspekty geografické replikace při konfiguraci automatizované rotace protektoru pro transparentní šifrování dat

Abyste se vyhnuli problémům při vytváření nebo během geografické replikace, když je na primárním nebo sekundárním serveru povolena automatická rotace TDE ochrany, je důležité dodržovat tato pravidla při konfiguraci geografické replikace:

  • Primární i sekundární servery musí mít oprávnění Get, wrapKey a unwrapKey k trezoru klíčů primárního serveru (trezor klíčů, který obsahuje klíč ochrany transparentního šifrování dat primárního serveru).

  • Pro server s povolenou automatizovanou obměnu klíčů před zahájením geografické replikace přidejte šifrovací klíč, který se používá jako ochrana transparentním šifrováním dat na primárním serveru, do sekundárního serveru. Sekundární server vyžaduje přístup ke klíči ve stejném trezoru klíčů nebo spravovaném HSM, který se používá s primárním serverem (a ne k jinému klíči se stejným klíčovým materiálem). Případně se před zahájením geografické replikace ujistěte, že spravovaná identita sekundárního serveru (přiřazená uživatelem nebo systémem) má požadovaná oprávnění k trezoru klíčů primárního serveru nebo spravovanému HSM a systém se pokusí přidat klíč na sekundární server.

  • Pro stávající nastavení geografické replikace před povolením automatizované obměny klíčů na primárním serveru přidejte šifrovací klíč, který se používá jako ochrana transparentním šifrováním dat na primárním serveru, do sekundárního serveru. Sekundární server vyžaduje přístup ke klíči ve stejném trezoru klíčů nebo spravovaném HSM, který se používá s primárním serverem (a ne k jinému klíči se stejným klíčovým materiálem). Případně se před povolením automatizovaného klíče ujistěte, že spravovaná identita sekundárního serveru (přiřazená uživatelem nebo systémem) má požadovaná oprávnění k trezoru klíčů primárního serveru a systém se pokusí klíč přidat na sekundární server.

  • Jsou podporovány scénáře georeplikace využívající klíče spravované zákazníkem (CMK) pro TDE. Transparentní šifrování dat s automatickým obměnou klíčem musí být nakonfigurované na všech serverech, pokud konfigurujete transparentní šifrování dat na webu Azure Portal. Další informace o nastavení automatické obměny klíčů pro konfigurace geografické replikace pomocí TDE najdete v tématu Automatická obměna klíčů pro konfigurace geografické replikace.

Nepřístupný TDE ochránce

Pokud je TDE nakonfigurované pro používání klíče spravovaného zákazníkem, je pro udržení databáze online vyžadován nepřetržitý přístup k ochránci TDE. Pokud server ztratí přístup k TDE chrániči spravovanému zákazníkem ve službě Azure Key Vault nebo Azure Managed HSM, během až 10 minut začne databáze odepírat všechna připojení s odpovídající chybovou zprávou a změní svůj stav na Nepřístupný. 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 účinek chyb sítě nebo výpadků při přístupu k ochraně TDE (Transparent Data Encryption) ve službě Azure Key Vault nebo Azure Managed HSM, zavádí se 24hodinová rezerva před pokusem služby o přesunutí databáze 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 TDE ochránci spravovanému zákazníkem ve službě Azure Key Vault nebo Azure Managed HSM kvůli jakékoli chybě služby Azure Key Vault (například k chybě 4XX), databáze se po 30 minutách přesune do nepřístupného stavu.

Obnovení přístupu k databázi po chybě služby Azure Key Vault nebo spravovaného HSM Azure

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

Snímek obrazovky s nepřístupnou databází TDE BYOK

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.

Zablokované připojení mezi spravovanou instancí SQL a službou Azure Key Vault nebo spravovaným HSM Azure

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

Nejběžnější příčiny nedostatku síťového připojení ke službě Azure Key Vault nebo spravovanému HSM Azure jsou:

  • Služba Azure Key Vault nebo Azure Managed HSM je přístupná prostřednictvím privátního koncového bodu a privátní IP adresa služby Azure Key Vault nebo služby Azure Managed HSM není povolená 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 připojení ze služby SQL Managed Instance ke službě Azure Key Vault nebo ke spravovanému HSM Azure, které hostují TDE ochranu.

  • 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 ochraně transparentním šifrováním dat, se po odepření prvního připojení k databázi 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. Vytváření výstrah pro tyto události vám umožní co nejdříve obnovit přístup.

  • Skupiny akcí je možné definovat tak, aby vám na základě vašich preferencí odesílaly oznámení a upozornění, například e-mail/SMS/push oznámení/hlas, Logic App, Webhook, ITSM nebo Runbook Automation.

Databáze backup a restore s šifrováním dat spravovaným zákazníkem

Jakmile je databáze šifrovaná transparentním šifrováním dat pomocí klíče ze služby Azure Key Vault nebo spravovaného HSM Azure, 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 TDE ze služby Azure Key Vault nebo Azure Managed HSM, ujistěte se, že je klíčový materiál dostupný pro cílový server. Proto doporučujeme zachovat všechny staré verze ochrany TDE v klíčovém trezoru nebo spravovaném HSM, aby bylo možné obnovit zálohy databáze.

Důležité

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ě klíče DEK, ale je možné je použít při obnovení ze zálohy, pokud je záložní soubor zašifrovaný pomocí klíče s odpovídajícím kryptografickým otiskem.

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 nemusí být označeny jako TDE ochrana.

Další informace o obnovení zálohování pro službu SQL Database najdete v tématu Obnovení databáze ze zálohy ve službě Azure SQL Database. 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. Nativní zálohování a obnovení SQL Serveru pomocí služby SQL Managed Instance najdete v tématu Rychlý start: Obnovení databáze do služby Azure SQL Managed Instance pomocí SSMS.

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 soubor protokolu používá ochranu transparentním šifrováním dat uloženým ve službě Azure Key Vault nebo spravovaném HSM Azure, je tento klíč potřeba v době obnovení, i když se databáze mezitím změnila tak, aby používala transparentní šifrování dat spravované službou.

Vysoká dostupnost s využitím transparentního šifrování dat spravovaného zákazníkem

S využitím služby Azure Key Vault nebo spravovaného HSM Azure poskytujícího několik vrstev redundance můžou TDE využívající klíč spravovaný zákazníkem využívat výhod dostupnosti a odolnosti spravovaného HSM služby Azure Key Vault nebo Azure Managed HSM a plně využívat řešení redundance Azure Key Vault nebo Spravované HSM.

Více vrstev redundance v Azure Key Vault zajišťuje přístup ke klíčům, i v případě selhání jednotlivých komponent služeb, oblastí Azure nebo zón dostupnosti. Další informace najdete v tématu Dostupnost a redundance služby Azure Key Vault.

Azure Key Vault nabízí následující komponenty dostupnosti a odolnosti, které se poskytují automaticky bez zásahu uživatele:

Poznámka:

Pro všechny spárované oblasti se klíče služby Azure Key Vault replikují do obou oblastí a v obou oblastech existují moduly hardwarového zabezpečení (HSM), které můžou s těmito klíči pracovat. Další informace najdete v tématu Replikace dat. To platí pro úrovně služby Azure Key Vault úrovně Standard i Premium a softwarové nebo hardwarové klíče.

Replikace spravovaného HSM Azure pro více oblastí umožňuje rozšířit fond spravovaných HSM Azure z jedné oblasti Azure (označované jako primární oblast) do jiné oblasti Azure (označované jako rozšířená oblast). Po nakonfigurování jsou obě oblasti aktivní, schopné obsluhovat požadavky a s automatizovanou replikací sdílet stejný klíčový materiál, role a oprávnění. Další informace najdete v tématu Povolení replikace ve více oblastech ve službě Azure Managed HSM.

Geografické zotavení po havárii se zákazníkem spravovaným TDE

Aktivní geografická replikace a skupiny převzetí služeb při selhání podporují TDE spravované zákazníkem. Primární a sekundární servery mohou používat Azure Key Vault nebo Azure Managed HSM v jakémkoli podporovaném regionu. Servery a úložiště klíčů nemusí být ve stejné oblasti.

Pro úspěšný failover musí mít oba servery přístup ke všem Azure Key Vault nebo Azure Managed HSM, které obsahují požadovaný klíč.

Aspekty konfigurace

Při konfiguraci aktivní geo-replikace nebo failover skupiny v Azure portálu platí následující faktory:

  • Umístění TDE ochránce: Primární a sekundární servery mohou používat stejný Azure Key Vault nebo Azure Managed HSM. Používání stejného klíčového úložiště snižuje riziko, že se klíčový materiál nesynchronizuje. Pokud používáte samostatné klíčové trezory ve více regionech, musíte udržovat požadovaný klíčový materiál synchronizovaný. Informace o odolnosti úložiště klíčů najdete v článcích Dostupnost a redundance Azure Key Vault a Replikace do více oblastí v Managed HSM.

  • Zónová redundance: Kde je to možné, zónová redundance pro Azure SQL Database nebo Azure SQL Managed Instance poskytuje dodatečnou odolnost v rámci regionu. Další informace najdete v tématu Co jsou zóny dostupnosti Azure?.

  • Oprávnění klíčů: Primární i sekundární servery musí mít požadovaná oprávnění na každém Azure Key Vault nebo Azure Managed HSM, které obsahuje požadovaný TDE ochránce.

  • Dostupnost klíčů: Ujistěte se, že požadované klíče jsou dostupné jak na primárním, tak na sekundárním serveru. Servery nemusí používat identické TDE ochrany, ale každý server musí mít stejný klíčový materiál. Klíče na server můžete přidávat pomocí portálu Azure, PowerShellu, Azure CLI nebo Azure SQL REST API. Pokud požadované klíče nejsou v době failoveru dostupné, databáze se může stát nedostupnou.

  • Soukromé koncové body: Konfigurace může vyžadovat komplexnější zónu DNS, pokud používáte soukromé koncové body služby Azure SQL (například ve stejné zóně DNS nelze vytvořit dva soukromé koncové body pro stejný prostředek).

  • Konektivita aplikací: Aplikace by měly používat logiku opakovaných pokusů k řešení přechodných selhání během failoveru.

Informace o konfiguraci prostředku geoobnovy po havárii Azure SQL najdete v tématech Aktivní geo-replikace nebo Přehled skupin převzetí služeb při selhání a osvědčené postupy.

Důležité

Když vytvoříte geo-replikační spojení nebo skupinu pro failover, Azure SQL ověřuje, že oba servery mají přístup ke všem požadovaným klíčům spravovaným zákazníkem. Pokud žádný z těchto serverů nemá přístup k požadovanému klíči, operace vytvoření selže. Například pokud primární a sekundární server používají klíč A a klíč B, připočtěte oba klíče na oba servery před vytvořením georeplikačního spojení nebo skupiny pro failover.

Následující diagram znázorňuje geografickou replikaci Azure SQL se skupinou převzetí služeb při selhání a převzetí služeb při selhání mezi oblastmi ve službě Azure Key Vault v konfiguraci spárovaných oblastí:

diagram znázorňující podporu převzetí služeb při selhání pro spárovanou oblast ve službě Azure Key Vault

Azure Key Vault chování během failoveru

  • Azure Key Vault zahajuje failover, ne vy.
  • Když je trezor klíčů v primární oblasti nedostupný, trezor klíčů je jen pro čtení.
  • Klíče můžete vytvářet, importovat a otáčet pouze tehdy, když je klíčový trezor v primární oblasti dostupný. Po failoveru zůstává rotace klíče zablokovaná, dokud není primární oblast opět dosažitelná.
  • Nemůžete si vybrat ani zkontrolovat, ve kterém regionu se trezor klíčů právě nachází, a nemůžete se ručně připojit k sekundárnímu regionu.

Obnovení po nedostupném chrániči TDE

Pokud se databáze v aktivním vztahu geo-replikace nebo skupině pro failover stane nedostupnou, řídicí rovina Azure SQL přeruší spojení a převede databázi na samostatnou databázi.

Po obnovení oprávnění klíčů můžete obvykle primární databázi znovu spustit. Sekundární databázi nelze znovu spustit, protože Azure SQL neprovádí plné zálohy sekundárních databází. Odstraňte sekundární databázi a potom znovu navažte georeplikační propojení nebo skupinu převzetí služeb při selhání.

Azure Policy pro zákazníkem spravované TDE

Azure Policy lze použít k vynucení TDE spravovaného zákazníkem během vytváření nebo aktualizace serveru pro Azure SQL Database nebo spravované instance Azure SQL. Při použití této zásady všechny pokusy o vytvoření nebo aktualizaci logického serveru v Azure nebo spravované instanci selžou, pokud není nakonfigurovaný s klíčem spravovaným zákazníkem. Azure Policy se dá použít pro celé předplatné Azure nebo přímo v rámci skupiny prostředků.

Další informace o službě Azure Policy najdete v tématu Co je Azure Policy a Struktura definic Azure Policy.

Pro transparentní šifrování dat spravované zákazníkem ve službě Azure Policy jsou podporovány následující dvě vestavěné zásady:

  • Sql Servery by měly k šifrování neaktivních uložených dat používat klíče spravované zákazníkem.
  • Spravované instance by měly k šifrování neaktivních uložených dat používat klíče spravované zákazníkem.

Zásady spravované zákazníkem pro transparentní šifrování dat (TDE) lze spravovat tak, že přejdete na web Azure Portal a vyhledáte službu Policy. V části Definice vyhledejte klíč spravovaný zákazníkem.

Tyto zásady mají tři účinky:

  • Audit – Výchozí nastavení a zaznamenává pouze sestavu auditu v protokolech aktivit Azure Policy.

  • Odepřít – Zabraňuje vytvoření nebo aktualizaci logického serveru nebo spravované instance bez nakonfigurovaného klíče spravovaného zákazníkem

  • Zakázáno – Zakáže zásadu a neomezí uživatele ve vytváření nebo aktualizaci logického serveru nebo spravované instance bez zapnutého TDE spravovaného zákazníkem.

Pokud je v Azure Policy pro TDE spravované zákazníkem nastaveno Odmítnout, vytvoření logického serveru Azure SQL nebo spravované instance selže. Podrobnosti o tomto selhání se zaznamenávají v protokolu aktivit skupiny prostředků.

Důležité

Starší verze integrovaných zásad pro transparentní šifrování dat spravované zákazníkem, které obsahují účinek AuditIfNotExists, jsou zastaralé. Stávající přiřazení zásad používající vyřazené zásady nejsou ovlivněná a nadále fungují beze změny.

Související obsah

  • Last updated on