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

  • Článek

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

Transparentní šifrování dat (TDE) Azure SQL s klíčem spravovaným 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 klíčem používaným k šifrování šifrovacího klíče databáze (DEK) označovaného jako ochrana transparentním šifrováním dat asymetrický klíč spravovaný zákazníkem uložený ve službě Azure Key Vault (AKV) vlastněný zákazníkem a spravovaný zákazníkem, cloudový externí systém pro správu klíčů. Key Vault je vysoce dostupné a škálovatelné zabezpečené úložiště pro kryptografické klíče RSA, volitelně zálohované moduly hardwarového zabezpečení (HSM) standardem FIPS 140-2 Level 2. Nepovoluje přímý přístup k uloženému klíči, ale poskytuje služby šifrování a dešifrování pomocí klíče autorizovaným entitě. Klíč může generovat trezor klíčů, importovaný nebo přenesený do trezoru klíčů z místního zařízení HSM.

Pro Azure SQL Database a Azure Synapse Analytics je ochrana transparentním šifrováním dat nastavená na úrovni serveru a dědí se všemi šifrovanými databázemi přidruženými k danému serveru. Pro spravovanou instanci Azure SQL je ochrana transparentním šifrováním dat nastavená na úrovni instance a dědí se všemi šifrovanými databázemi v této instanci. Termínový server odkazuje na server ve službě SQL Database i Azure Synapse a na spravovanou instanci ve službě SQL Managed Instance v celém tomto dokumentu, pokud není uvedeno jinak.

Správa ochrany transparentním šifrováním dat 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)). Dokumentaci k transparentnímu šifrování dat pro vyhrazené fondy SQL v pracovních prostorech Synapse najdete v tématu Šifrování Služby Synapse Analytics.
  • Aby zákazníci Azure SQL poskytli dvě vrstvy šifrování neaktivních uložených dat, zavádí se šifrování infrastruktury (pomocí šifrovacího algoritmu AES-256) s klíči spravovanými platformou. To poskytuje další vrstvu šifrování neaktivních uložených dat spolu s transparentním šifrováním dat s klíči spravovanými zákazníkem, které jsou již k dispozici. Pro Azure SQL Database a Azure SQL Managed Instance se při zapnutí šifrování infrastruktury zašifrují všechny databáze, včetně master databáze a dalších systémových databází. V tuto chvíli musí zákazníci požádat o přístup k této funkci. Pokud vás tato funkce zajímá, obraťte AzureSQLDoubleEncryptionAtRest@service.microsoft.comse na .

Poznámka:

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

Výhody transparentního šifrování dat spravovaného zákazníkem

Transparentní šifrování dat 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 transparentním šifrováním dat;

  • Transparentnost použití ochrany transparentním šifrováním dat;

  • Schopnost implementovat oddělení povinností při správě klíčů a dat v rámci organizace;

  • Správce služby Key Vault může odvolat přístupová oprávnění ke klíči, aby byla zašifrovaná databáze nepřístupná;

  • Centrální správa klíčů v AKV;

  • Větší důvěryhodnost od koncových zákazníků, protože služba AKV je navržená tak, aby Společnost Microsoft neviděla ani extrahovala šifrovací klíče;

Důležité

V případě zákazníků, kteří používají transparentní šifrování dat spravované službou a chtějí začít používat transparentní šifrování dat spravované zákazníkem, zůstanou data při přechodu zašifrovaná a nedojde k výpadku ani opětovnému šifrování souborů databáze. 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.

Jak funguje transparentní šifrování dat spravované zákazníkem

Nastavení a fungování transparentního šifrování dat spravovaného zákazníkem

Aby logický server v Azure mohl používat ochranu transparentním šifrováním dat uložený v AKV k šifrování DEK, musí správce trezoru klíčů poskytnout serveru následující přístupová práva pomocí jedinečné identity Microsoft Entra:

  • get – pro načtení veřejné části a vlastností klíče ve službě Key Vault

  • wrapKey – schopnost chránit (šifrovaný) klíč DEK

  • unwrapKey – aby bylo možné odemknout (dešifrovat) DEK

Správce trezoru klíčů 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 z AKV, odešle server DEK každé databáze s povoleným transparentním šifrováním dat do trezoru klíčů za účelem š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:

Může trvat přibližně 10 minut, než se změny oprávnění pro trezor klíčů projeví. 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

Požadavky na konfiguraci AKV

  • Funkce obnovitelného odstranění a ochrany před vymazáním musí být v trezoru klíčů povoleny, aby se chránily před ztrátou dat kvůli náhodnému odstranění klíče (nebo trezoru klíčů).

  • Udělte serveru nebo spravované instanci přístup k trezoru klíčů (get, wrapKey, unwrapKey) pomocí své 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. Při použití webu Azure Portal se identita Microsoft Entra vytvoří automaticky při vytvoření serveru. Při použití PowerShellu nebo Azure CLI se musí identita Microsoft Entra vytvořit explicitně a musí se ověřit. Podrobné pokyny k použití PowerShellu najdete v tématu Konfigurace transparentního šifrování dat pomocí funkce BYOKpro spravovanou instanci SQL.

    • Přístup k trezoru klíčů můžete udělit buď tak, že vytvoříte zásadu přístupu k trezoru klíčů, nebo tak, že vytvoříte novou roli Azure RBAC, kterou přiřadíte roli Uživatel šifrování kryptografické služby Key Vault, ale záleží na modelu oprávnění používaném v trezoru klíčů (zásady přístupu nebo Azure RBAC).

  • Při použití brány firewall s AKV musíte povolit možnost Povolit důvěryhodné služby Microsoft obejít bránu firewall. Další informace najdete v tématu Konfigurace bran firewall služby Azure Key Vault a virtuálních sítí.

Povolení obnovitelného odstranění a ochrany před vymazáním pro AKV

Důležité

Při konfiguraci transparentního šifrování dat spravovaného zákazníkem na novém nebo existujícím serveru nebo spravované instanci musí být v trezoru klíčů povolené obnovitelné odstranění i ochrana před vymazáním.

Obnovitelné odstranění a ochrana před vymazáním jsou důležité funkce služby Azure Key Vault, které umožňují obnovení odstraněných trezorů a odstraněných objektů trezoru klíčů, což snižuje riziko náhodného nebo škodlivého odstranění klíče nebo trezoru klíčů.

  • Obnovitelné odstraněné prostředky se uchovávají po dobu 90 dnů, pokud ho zákazník neobnoví nebo nevyprázdní. Akce obnovení a vymazání mají svá vlastní oprávnění přidružená k zásadám přístupu trezoru klíčů. Funkce obnovitelného odstranění je ve výchozím nastavení zapnutá pro nové trezory klíčů a je také možné ji povolit pomocí webu Azure Portal, PowerShellu nebo Azure CLI.

  • Ochranu mazání je možné zapnout pomocí Azure CLI nebo PowerShellu. Pokud je povolená ochrana před vymazáním, není možné trezor ani objekt v odstraněném stavu vymazat, dokud neuplyne doba uchovávání. Výchozí doba uchovávání je 90 dnů, ale dá se nakonfigurovat od 7 do 90 dnů prostřednictvím webu Azure Portal.

  • Azure SQL vyžaduje povolení obnovitelného odstranění a ochrany před vymazáním v trezoru klíčů obsahujícího šifrovací klíč, který se používá jako ochrana transparentním šifrováním dat pro server nebo spravovanou instanci. To pomáhá zabránit scénáři náhodného nebo škodlivého trezoru klíčů nebo odstranění klíče, které můžou vést k tomu, že databáze přejde do nepřístupného stavu.

  • Při konfiguraci ochrany transparentním šifrováním dat na existujícím serveru nebo při vytváření serveru Azure SQL ověří, že použitý trezor klíčů má zapnutou ochranu obnovitelného odstranění a vymazání. Pokud v trezoru klíčů není povolená ochrana obnovitelného odstranění a vymazání, nastavení ochrany transparentním šifrováním dat selže s chybou. V takovém případě musí být v trezoru klíčů povolená ochrana obnovitelného odstranění a vymazání a pak by se mělo provést nastavení ochrany transparentním šifrováním dat.

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 2048 bitů a 3072 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íčů, nezapomeňte ho zadat v podporovaných formátech souborů (.pfxnebo .byok.backup).

Poznámka:

Azure SQL teď podporuje použití klíče RSA uloženého ve spravovaném HSM jako ochrany transparentním šifrováním dat. Spravovaný HSM služby Azure Key Vault je plně spravovaná, vysoce dostupná cloudová služba kompatibilní s jedním tenantem, která umožňuje chránit kryptografické klíče pro cloudové aplikace pomocí ověřených HSM úrovně 140–2 FIPS 3. Přečtěte si další informace o spravovaných HSM.

Poznámka:

Problém s verzemi Thales CipherTrust Manageru před verzí 2.8.0 brání nově importovaným klíčům do služby Azure Key Vault ve scénářích transparentního šifrování dat ve službě Azure SQL Database nebo Azure SQL Managed Instance. Další podrobnosti o tomto problému najdete tady. V takových případech počkejte 24 hodin po importu klíče do trezoru klíčů 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ý ve Správci cipherTrust Manageru thales v2.8.0.

Doporučení ke konfiguraci transparentního šifrování dat spravovaného zákazníkem

Doporučení při konfiguraci AKV

  • Přidružte celkem maximálně 500 databází pro obecné účely nebo 200 Pro důležité obchodní informace k trezoru klíčů v jednom předplatném, abyste zajistili vysokou dostupnost, když server přistupuje k ochraně transparentním šifrováním dat v trezoru klíčů. Tyto údaje jsou založeny na zkušenostech a zdokumentovaných v limitech služby Key Vault. Záměrem je zabránit problémům po převzetí služeb při selhání serveru, protože aktivuje tolik operací s klíči vůči trezoru, jako jsou databáze na tomto serveru.

  • 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 zámcích prostředků.

  • Povolte auditování a vytváření sestav u všech šifrovacích klíčů: Key Vault poskytuje protokoly, které se dají snadno vkládat 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á.

  • Propojte každý server se dvěma trezory klíčů, které se nacházejí v různých oblastech, a zajistěte vysokou dostupnost šifrovaných databází. Označte klíč z jednoho z trezorů klíčů jako ochranu transparentním šifrováním dat. Systém automaticky přepne do trezoru klíčů ve druhé oblasti se stejným materiálem klíčů, pokud dojde k výpadku trezoru klíčů v první oblasti.

Poznámka:

Kvůli větší flexibilitě při konfiguraci transparentního šifrování dat spravovaného zákazníkem je teď možné propojit službu Azure SQL Database a Azure SQL Managed Instance v jedné oblasti s trezorem klíčů v jakékoli jiné oblasti. Server a trezor klíčů se nemusí nacházet ve stejné oblasti.

Doporučení při konfiguraci ochrany transparentním šifrováním dat

  • 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íče před prvním použitím klíče v AKV. 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 .

  • 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íčů, 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 ochranu transparentním šifrováním dat, pomocí které se zašifrovala při vytvoření. Obměny klíčů je možné provést podle pokynů v tématu Otočení transparentní ochrany šifrování dat pomocí PowerShellu.

  • Uchovávejte v AKV všechny dříve používané klíče i po přechodu na klíče spravované službou. Tím se zajistí možnost obnovení databází ze záloh s ochranou transparentním šifrováním dat uloženou v AKV. Ochrana transparentním šifrováním dat vytvořená pomocí služby Azure Key Vault se musí udržovat, dokud se nevytvořily všechny zbývající uložené zálohy 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 části Odebrání potenciálně ohroženého klíče.

Otočení ochrany transparentním šifrováním dat

Obměně ochrany transparentním šifrováním dat pro server znamená přepnutí na nový asymetrický klíč, který chrání databáze na serveru. Obměně klíčů je online operace a dokončení by mělo trvat jenom několik sekund. Operace pouze dešifruje a znovu zašifruje šifrovací klíč databáze, nikoli celou databázi.

Otočení ochrany transparentním šifrováním dat je možné provést buď ručně, nebo pomocí funkce automatizovaného otáčení.

Automatická obměně ochrany transparentním šifrováním dat je možné povolit při konfiguraci ochrany transparentním šifrováním dat pro server. Automatizovaná rotace je ve výchozím nastavení zakázaná. Pokud je tato možnost povolená, server bude nepřetržitě kontrolovat trezor klíčů pro všechny nové verze klíče, které se používají jako ochrana transparentním šifrováním dat. 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 automatizovaným obměnám klíčů ve službě Azure Key Vault tato funkce umožňuje komplexní rotaci bez dotykového ovládání pro ochranu transparentním šifrováním dat ve službě Azure SQL Database a azure SQL Managed Instance.

Poznámka:

Nastavení transparentního šifrování dat pomocí cmk pomocí ručního nebo automatizovaného obměně klíčů bude vždy používat nejnovější podporovanou verzi klíče. Instalační program 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é mohou 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 v případě dlouhodobého uchovávání záloh, kde se starší verze klíčů musí zachovat. 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é obměny ochrany transparentním šifrováním dat

Abyste se vyhnuli problémům při vytváření geografické replikace nebo při geografické replikaci, je důležité při konfiguraci geografické replikace dodržovat tato pravidla při automatické obměně ochrany transparentním šifrováním dat na primárním nebo sekundárním serveru:

  • 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 k klíči ve stejném trezoru klíčů, který se používá s primárním serverem (a ne k jinému klíči se stejným materiálem klíče). Případně před zahájením geografické replikace zajistěte, aby spravovaná identita sekundárního serveru (přiřazená uživatelem nebo systémem) měla požadovaná oprávnění k trezoru klíčů primárního serveru 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, na sekundární server. Sekundární server vyžaduje přístup k klíči ve stejném trezoru klíčů, který se používá s primárním serverem (a ne k jinému klíči se stejným materiálem klíče). Případně před povolením automatizovaného klíče zajistěte, aby 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í přidat klíč na sekundární server.

  • Podporují se scénáře geografické replikace využívající klíče spravované zákazníkem (CMK) pro 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í transparentního šifrování dat najdete v tématu Automatická obměně klíčů pro konfigurace geografické replikace.

Nepřístupná ochrana transparentním šifrováním dat

Pokud je pro transparentní šifrování dat nakonfigurované používání klíče spravovaného zákazníkem, databáze potřebuje nepřetržitý přístup k ochraně transparentním šifrováním dat, aby mohla zůstat online. Pokud server ztratí přístup k ochraně transparentním šifrováním dat spravovaným zákazníkem ve službě AKV, za 10 minut začne databáze zamítat všechna připojení s odpovídající chybovou zprávou a změnit její stav na Nepřístupný. Jediná akce povolená pro databázi v nepřístupném stavu ji odstraní.

Poznámka:

Pokud je databáze nepřístupná kvůli přerušovanému výpadku sítě, nevyžaduje se žádná akce a databáze se automaticky vrátí do online režimu.

Po obnovení přístupu ke klíči vyžaduje vrácení databáze do režimu online další čas a kroky, které se můžou lišit v závislosti na čase, který uplynul bez přístupu ke klíči a velikosti dat v databázi:

Poznámka:

  • Pokud se přístup ke klíči obnoví do 30 minut, databáze se do příští hodiny automaticky zočká.
  • Pokud se přístup ke klíči obnoví po více než 30 minutách, automatické závorky databáze není možné. Přenesení databáze vyžaduje další kroky na webu Azure Portal a může trvat značné množství času v závislosti na velikosti databáze.
  • Jakmile je databáze opět online, dříve nakonfigurovaná nastavení na úrovni serveru, která můžou zahrnovat konfiguraci skupiny převzetí služeb při selhání, značky a nastavení na úrovni databáze, jako je konfigurace elastických fondů, škálování čtení, automatické pozastavení, historie obnovení k určitému bodu v čase, dlouhodobé zásady uchovávání informací a další, budou ztraceny. Proto se doporučuje, aby zákazníci implementovali systém oznámení, který do 30 minut identifikuje ztrátu přístupu k šifrovacímu klíči. Po uplynutí 30 minut doporučujeme ověřovat všechna nastavení na úrovni serveru a databáze v obnovené databázi.

Níže najdete přehled dodatečných kroků potřebných k tomu, aby se databáze vrátila do online režimu.

Nepřístupná databáze TDE BYOK

Náhodné odvolání přístupu k ochraně transparentním šifrováním dat

Může se stát, že někdo s dostatečnými přístupovými právy k trezoru klíčů omylem zakáže přístup k tomuto klíči:

  • odvolání oprávnění get, wrapKey, unwrapKey ze serveru

  • odstranění klíče

  • odstranění trezoru klíčů

  • změna pravidel brány firewall trezoru klíčů

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

Blokování připojení mezi spravovanou instancí SQL a službou Key Vault

Ve službě SQL Managed Instance můžou chyby sítě při pokusu o přístup k ochraně transparentním šifrováním dat ve službě Azure Key Vault způsobit, že databáze změní svůj stav na nepřístupný , ale potom instanci nevykreslí. K tomu dochází většinou v případě, že prostředek trezoru klíčů existuje, ale jeho koncový bod není dostupný ze spravované instance. Všechny scénáře, kdy je možné dosáhnout koncového bodu trezoru klíčů, ale připojení je odepřeno, chybějící oprávnění atd., způsobí, že databáze změní svůj stav na Nepřístupný.

Mezi nejběžnější příčiny chybějícího síťového připojení ke službě Key Vault patří:

  • Služba Key Vault je přístupná prostřednictvím privátního koncového bodu a privátní IP adresa služby AKV není povolená v odchozích pravidlech skupiny zabezpečení sítě (NSG) přidružené k podsíti spravované instance.
  • Chybné překlady DNS, například když se plně kvalifikovaný název domény trezoru klíčů nepřeloží nebo přeloží na neplatnou IP adresu.

Otestujte připojení ze služby SQL Managed Instance ke službě Key Vault hostující ochranu transparentním šifrováním dat.

  • Koncový bod je plně kvalifikovaný název domény 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 má 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íčů.
    • Zkontrolujte další síťové konfigurace, jako je směrovací tabulka, existence virtuálního zařízení a jeho konfigurace atd.

Monitorování transparentního šifrování dat spravovaného 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 ochraně transparentním šifrováním dat v trezoru klíčů spravovaných zákazníkem se položky přidají 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/nabízení/hlas, Aplikace logiky, Webhook, ITSM nebo runbook Automation.

Zálohování a obnovení databáze s transparentním š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 Key Vault, všechny nově generované zálohy se také šifrují pomocí stejné ochrany transparentním šifrováním dat. Při změně ochrany transparentním šifrováním dat se staré zálohy databáze neaktualizují , aby používaly nejnovější ochranu transparentním šifrováním dat.

Pokud chcete obnovit zálohu zašifrovanou pomocí ochrany transparentním šifrováním dat ze služby Key Vault, ujistěte se, že je pro cílový server k dispozici materiál klíče. Proto doporučujeme v trezoru klíčů uchovávat všechny starší verze ochrany transparentním šifrováním dat, aby bylo možné obnovit zálohy databáze.

Důležité

V každém okamžiku nemůže existovat více než jedna sada ochrany transparentním šifrováním dat pro server. Je to klíč označený jako "Nastavit klíč jako výchozí ochranu transparentním šifrováním dat" v podokně webu Azure Portal. Několik dalších 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 je možné je použít při obnovení ze zálohy, pokud je záložní soubor šifrovaný pomocí klíče s odpovídajícím kryptografickým otiskem.

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čené jako ochrana transparentním šifrováním dat.

Další informace o obnovení zálohování pro službu SQL Database najdete v tématu Obnovení databáze ve službě 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 SQL Managed Instance.

Další aspekty souborů protokolu: Zálohované soubory protokolu zůstanou zašifrované pomocí původní ochrany transparentním šifrováním dat, i když byla obměna a databáze teď používá novou ochranu transparentním šifrováním dat. V době obnovení budou k obnovení databáze potřeba oba klíče. Pokud soubor protokolu používá ochranu transparentním šifrováním dat uložený ve službě Azure Key Vault, bude 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

I v případech, kdy pro server není nakonfigurovaná geografická redundance, důrazně doporučujeme nakonfigurovat server tak, aby používal dva různé trezory klíčů ve dvou různých oblastech se stejným materiálem klíčů. Klíč v sekundárním trezoru klíčů v jiné oblasti by neměl být označený jako ochrana transparentním šifrováním dat a ani není povolený. Pokud dojde k výpadku primárního trezoru klíčů a teprve potom systém automaticky přepne na druhý propojený klíč se stejným kryptografickým otiskem v sekundárním trezoru klíčů, pokud existuje. Mějte na paměti, že k přepnutí nedojde, pokud je ochrana transparentním šifrováním dat nepřístupná kvůli odvolaným přístupovým právům nebo kvůli odstranění klíče nebo trezoru klíčů, protože to může znamenat, že zákazník záměrně chtěl omezit přístup k tomuto klíči serveru. Poskytnutí stejného materiálu ke dvěma trezorům klíčů v různých oblastech je možné provést vytvořením klíče mimo trezor klíčů a jejich importem do obou trezorů klíčů.

Můžete ho také provést vygenerováním klíče pomocí trezoru primárních klíčů v jedné oblasti a klonováním klíče do trezoru klíčů v jiné oblasti Azure. Pomocí rutiny Backup-AzKeyVaultKey načtěte klíč v šifrované podobě z primárního trezoru klíčů a pak použijte rutinu Restore-AzKeyVaultKey a zadejte trezor klíčů ve druhé oblasti pro klonování klíče. Případně můžete klíč zálohovat a obnovit pomocí webu Azure Portal. Operace zálohování a obnovení klíčů je povolená pouze mezi trezory klíčů ve stejném předplatném Azure a geografickou oblastí Azure.

Vysoká dostupnost jednoúčelového serveru

Geo-DR a transparentní šifrování dat spravované zákazníkem

Ve scénářích aktivní geografické replikace i skupin převzetí služeb při selhání je možné primární a sekundární servery propojit buď se stejným trezorem klíčů (v libovolné oblasti), nebo oddělit trezory klíčů. Pokud jsou samostatné trezory klíčů propojené s primárním a sekundárním serverem, zodpovídá zákazník za zachování konzistentního klíče mezi trezory klíčů, aby se geograficky sekundární server synchronizoval a mohl převzít používání stejného klíče z jeho propojeného trezoru klíčů, pokud se primární server stane nedostupným kvůli výpadku v oblasti a aktivuje se převzetí služeb při selhání. Je možné nakonfigurovat až čtyři sekundy a řetězení (secondaries of secondaries) se nepodporuje.

Abyste se vyhnuli problémům při vytváření geografické replikace nebo během geografické replikace kvůli neúplnému klíčovému materiálu, je důležité při konfiguraci transparentního šifrování dat spravovaného zákazníkem dodržovat tato pravidla (pokud se pro primární a sekundární servery používají samostatné trezory klíčů):

  • Všechny zahrnuté trezory klíčů musí mít stejné vlastnosti a stejná přístupová práva pro příslušné servery.

  • Všechny zahrnuté trezory klíčů musí obsahovat identický materiál klíče. Vztahuje se nejen na aktuální ochranu transparentním šifrováním dat, ale na všechny předchozí ochrany transparentním šifrováním dat, které lze použít v záložních souborech.

  • Počáteční nastavení i obměně ochrany transparentním šifrováním dat musí být provedeny na sekundárním zařízení a poté na primárním serveru.

Skupiny převzetí služeb při selhání a geografické zotavení po havárii

Pokud chcete otestovat převzetí služeb při selhání, postupujte podle kroků v přehledu aktivní geografické replikace. Testování převzetí služeb při selhání by se mělo provádět pravidelně, aby se ověřilo, že služba SQL Database udržuje přístupová oprávnění k oběma trezorům klíčů.

Server služby Azure SQL Database a sql Managed Instance v jedné oblasti je teď možné propojit s trezorem klíčů v jakékoli jiné oblasti. Server a trezor klíčů nemusí být umístěné ve stejné oblasti. Díky tomu je pro zjednodušení možné propojit primární a sekundární server ke stejnému trezoru klíčů (v jakékoli oblasti). To pomáhá vyhnout se scénářům, kdy může být materiál klíčů mimo synchronizaci, pokud se pro oba servery používají samostatné trezory klíčů. Azure Key Vault zajišťuje několik úrovní redundance, aby se zajistila dostupnost klíčů a trezorů klíčů v případě selhání služeb nebo oblastí. Dostupnost a redundance služby Azure Key Vault

Azure Policy pro transparentní šifrování dat spravované zákazníkem

Azure Policy se dá použít k vynucení transparentního šifrování dat spravovaného zákazníkem během vytváření nebo aktualizace serveru Azure SQL Database nebo spravované instance Azure SQL. Když použijete tuto zásadu, 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 se podporují následující dvě předdefinované 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 transparentního šifrování dat spravované zákazníkem je možné spravovat na webu Azure Portal a vyhledejte službu Policy. V části Definice vyhledejte klíč spravovaný zákazníkem.

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

  • Audit – Výchozí nastavení a zachytí sestavu auditu jenom 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 v vytváření nebo aktualizaci logického serveru nebo spravované instance bez povoleného transparentního šifrování dat spravovaného zákazníkem.

Pokud je transparentní šifrování dat spravované zákazníkem nastavené na Odepřít, logický server Azure SQL nebo vytvoření spravované instance selže. Podrobnosti o tomto selhání se zaznamenávají v protokolu aktivit skupiny prostředků.

Důležité

Starší verze předdefinovaných zásad transparentního šifrování dat spravovaného zákazníkem, které tento AuditIfNotExist účinek obsahují, jsou zastaralé. Stávající přiřazení zásad používající zastaralé zásady nejsou ovlivněná a budou fungovat stejně jako předtím.

Další kroky

Můžete také zkontrolovat následující ukázkové skripty PowerShellu pro běžné operace s transparentním šifrováním dat spravovaným zákazníkem:

Kromě toho povolte Programu Microsoft Defender pro SQL zabezpečení databází a jejich dat funkce pro zjišťování a zmírnění potenciálních ohrožení zabezpečení databáze a detekci neobvyklých aktivit, které by mohly znamenat hrozbu pro vaše databáze.