Sdílet prostřednictvím

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 ochránce transparentního šifrování dat (TDE), asymetrický klíč spravovaný zákazníkem používaný k zabezpečení šifrovacího klíče databáze (DEK), uložen buď ve službě Azure Key Vault nebo ve spravovaném HSM služby Azure Key Vault. Jedná se o zabezpečené cloudové služby pro správu klíčů navržené pro zajištění vysoké dostupnosti a škálovatelnosti. Azure Key Vault podporuje klíče RSA a je možné ho zálohovat ověřenými moduly HSM úrovně 140-2 FIPS 2. Pro zákazníky, kteří vyžadují vyšší úroveň zabezpečení, nabízí Azure Key Vault spravovaný HSM ověřený hardware FIPS 140-2 úroveň 3. Klíč se dá vygenerovat ve službě, importovat nebo bezpečně přenést z místních hsM. Přímý přístup ke klíčům je omezený – autorizované služby provádějí kryptografické operace bez zveřejnění 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 používat TDE ochránce uložený ve službě Azure Key Vault k šifrování DEK, musí správce služby Key Vault udělit serveru přístupová práva pomocí 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í.

Požadavky na konfiguraci prostředku ochrany TDE

  • Ochranným prostředkem TDE může být jen asymetrický klíč, klíč šifrování RSA nebo klíč HSM RSA. Podporované délky klíčů jsou 2 048 bitů a 3 072 bitů.

  • Jako datum aktivace klíče (pokud ho nastavíte) je potřeba nastavit minulé datum a čas. Datum vypršení platnosti (pokud je nastavené) musí být budoucí datum a čas.

  • Klíč musí být ve stavu Povoleno .

  • Pokud importujete existující klíč do trezoru klíčů, ujistěte se, že je zadaný v jednom z podporovaných formátů souborů: .pfx, .byoknebo .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 tady. 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í při konfiguraci šifrování dat spravovaného zákazníkem pomocí Transparentního Šifrování Dat (TDE)

  • Pokud chcete zajistit optimální výkon a spolehlivost, důrazně doporučujeme použít vyhrazenou službu Azure Key Vault pro Azure SQL. Tento trezor klíčů by se neměl sdílet s jinými službami. Pokud je trezor klíčů zatížený velkým zatížením kvůli sdílenému využití nebo nadměrným operacím klíčů, může negativně ovlivnit výkon databáze, zejména při přístupu k šifrovacímu klíči. 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 je zásadní při převzetí služeb při selhání serveru, což aktivuje klíčové operace 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řidružujte více než 500 stránkových serverů k jediné službě Azure Key Vault. 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ánkových serverů překročí 500, použijte pro každou databázi Hyperscale, která není sdílená s jinými prostředky Azure SQL, vyhrazenou službu Azure Key Vault.

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

  • 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í při 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 obměně klíčů ponechte předchozí verze klíče v trezoru klíčů nebo spravovaném HSM, aby bylo možné obnovit starší zálohy databáze. Při změně ochrany transparentním šifrováním dat pro databázi se staré zálohy databáze neaktualizují , aby používaly nejnovější ochranu transparentním šifrováním dat. Při obnovení každá záloha vyžaduje TDE ochranu, kterou byla zašifrována při vytvoření. Obměny klíčů je možné provádět podle pokynů v článku Rotace transparentního ochranného prvku šifrování dat (TDE).

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

Otočení TDE ochránce

Obměna chrániče TDE pro server znamená přepnutí na nový asymetrický klíč, který chrání databáze na serveru. 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.

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.

  • Podporují se scénáře geografické replikace využívající uživatelsky spravované klíče (CMK) pro TDE (transparentní šifrování dat). 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.

Geo-DR a šifrování dat řízené zákazníkem (TDE)

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í servery propojit se službou Azure Key Vault nebo spravovaným HSM Azure umístěným v libovolné oblasti. Server a trezor klíčů nebo spravovaný HSM nemusí být umisťovány ve stejné oblasti. Kvůli jednoduchosti je možné primární a sekundární servery připojit ke stejnému trezoru klíčů nebo spravovanému HSM (v libovolné oblasti). To pomáhá vyhnout se scénářům, kdy by mohlo dojít k výpadku klíčového materiálu, pokud jsou pro oba servery používány samostatné trezory klíčů nebo spravované moduly HSM.

Azure Key Vault a Azure Managed HSM mají několik vrstev redundance, aby se zajistilo, že klíče a trezory klíčů zůstanou dostupné v případě selhání služby nebo oblasti. Redundance je podporována nepairovanými a spárovanými oblastmi. Další informace najdete v tématu Dostupnost a redundance služby Azure Key Vault.

V závislosti na požadavcích zákazníků existuje několik možností pro uložení klíče pro ochranu transparentním šifrováním dat:

  • Použijte Azure Key Vault s nativní odolností párované oblasti nebo s odolností nespárované oblasti.

  • Používejte zákaznický HSM a načítejte klíče v Azure Key Vault v samostatných Azure Key Vaultech napříč více regiony.

  • Použijte Azure Managed HSM a možnost replikace mezi oblastmi.

    • Tato možnost umožňuje zákazníkovi vybrat požadovanou oblast, ve které se klíče replikují.

Následující diagram představuje konfiguraci spárované oblasti (primární a sekundární) pro křížové převzetí služeb při selhání ve službě Azure Key Vault s nastavením Azure SQL pro geografickou replikaci pomocí skupiny převzetí služeb při selhání:

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

Poznámky ke službě Azure Key Vault pro Geo-DR

  • Primární i sekundární servery v Azure SQL mají přístup ke službě Azure Key Vault v primární oblasti.

  • Převzetí služeb při selhání služby Azure Key Vault iniciuje služba Azure Key Vault, nikoli zákazník.

  • Pokud Azure Key Vault přejde do sekundární oblasti, bude mít server v Azure SQL stále přístup k Azure Key Vault. I když je připojení služby Azure Key Vault interně přesměrováno do služby Azure Key Vault v sekundární oblasti.

  • Vytváření nových klíčů, importy a obměny klíčů jsou možné jenom v případě, že je k dispozici Azure Key Vault v primární oblasti.

  • Jakmile dojde k převzetí při selhání, nebude rotace klíčů povolena, dokud nebude služba Azure Key Vault v primární oblasti spárovaného regionu znovu přístupná.

  • Zákazník se nemůže ručně připojit k sekundární oblasti.

  • Služba Azure Key Vault je ve stavu jen pro čtení, zatímco Služba Azure Key Vault v primární oblasti není k dispozici.

  • Zákazník nemůže zvolit nebo zkontrolovat, v jaké oblasti se služba Azure Key Vault právě nachází.

  • V případě nespárované oblasti mají oba servery Azure SQL přístup ke službě Azure Key Vault v první oblasti (jak je uvedeno v grafu) a Azure Key Vault používá zónově redundantní úložiště k replikaci dat v rámci oblasti mezi nezávislými zónami dostupnosti v téže oblasti.

Další informace najdete v tématu dostupnosti a redundance služby Azure Key Vault, párů oblastí Azure a neprůzných oblastía smluv o úrovni služeb pro službu Azure Key Vault.

Poznámky k Azure SQL pro Geo-DR

  • Pokud chcete zvýšit odolnost, použijte zónově redundantní možnost služby Azure SQL Managed Instance a Azure SQL Database. Další informace najdete v tématu Co jsou zóny dostupnosti Azure?.

  • Použijte skupiny pro převzetí služeb při selhání pro Azure SQL Managed Instance a Azure SQL Database k zotavení po havárii do sekundární oblasti. Další informace najdete v přehledu skupin převzetí služeb při selhání a osvědčených postupech &.

  • Pokud je databáze součástí aktivní geografické replikace nebo skupin převzetí služeb při selhání a stane se nepřístupnou, řídicí rovina SQL přeruší propojení a převede databázi na samostatnou databázi. Po opravě oprávnění ke klíči je obvykle možné primární databázi přenést zpět do režimu online. Sekundární databázi nejde přenést do režimu online, protože Azure SQL záměrně neprovádí úplné zálohy sekundárních databází. Doporučuje se vypustit sekundární databáze a znovu vytvořit propojení.

  • Konfigurace může vyžadovat složitější zónu DNS, pokud se v Azure SQL používají privátní koncové body (například nemůže vytvořit dva privátní koncové body do stejného prostředku ve stejné zóně DNS).

  • Ujistěte se, že aplikace používají logiku opakování.

Existuje několik scénářů, kdy zákazníci můžou chtít zvolit řešení Azure Managed HSM přes Azure Key Vault:

  • Potřeba ručního připojení k sekundárnímu trezoru.

  • Požadavek na přístup pro čtení k trezoru i v případě selhání.

  • Flexibilita při výběru oblasti, do které se jejich klíčový materiál replikuje

    • Vyžaduje povolení replikace mezi oblastmi, což vede k vytvoření druhého fondu spravovaného HSM Azure ve druhé oblasti.

  • Použití spravovaného HSM Azure umožňuje zákazníkům vytvořit přesnou repliku pro HSM, pokud dojde ke ztrátě nebo nedostupnosti původního modulu.

  • Použití spravovaného HSM Azure pro požadavky na zabezpečení nebo zákonné požadavky.

  • Možnost zálohovat celý trezor oproti zálohování jednotlivých klíčů.

Pro více informací viz Povolení replikace ve více regionech na službě Azure Managed HSM a Zotavení po havárii spravovaného HSM.

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