Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Azure Database for PostgreSQL – flexibilní server vždy šifruje všechna data v klidovém stavu. Tato data zahrnují všechny systémové a uživatelské databáze, protokoly serveru, segmenty protokolů pro zápis a zálohy. Základní úložiště zpracovává šifrování prostřednictvím šifrování Azure Disk Storage na straně serveru.
Šifrování neaktivních uložených dat pomocí klíčů spravovaných službou (SMK) nebo klíčů spravovaných zákazníkem (CMK)
Azure Database for PostgreSQL podporuje dva režimy šifrování neaktivních uložených dat: klíče spravované službou (SMK) a klíče spravované zákazníkem (CMK). Šifrování dat pomocí klíčů spravovaných službou je výchozím režimem flexibilního serveru Azure Database for PostgreSQL. V tomto režimu služba automaticky spravuje šifrovací klíče používané k šifrování dat. K povolení ani správě šifrování v tomto režimu nemusíte provádět žádnou akci.
V režimu klíčů spravovaných zákazníkem můžete k šifrování dat použít vlastní šifrovací klíč. Tento režim poskytuje větší kontrolu nad procesem šifrování, ale také vyžaduje, abyste šifrovací klíče spravovat sami. Musíte nasadit vlastní službu Azure Key Vault nebo modul hardwarového zabezpečení (HSM) služby Azure Key Vault a nakonfigurovat ho tak, aby ukládal šifrovací klíče používané flexibilním serverem Azure Database for PostgreSQL.
Režim můžete vybrat pouze při vytváření serveru. Režim z jednoho na druhý nemůžete změnit po celou dobu životnosti serveru.
K zajištění šifrování dat Azure Database for PostgreSQL používá šifrování neaktivních uložených dat Azure Storage. Při používání CMK zodpovídáte za poskytování klíčů pro šifrování a dešifrování dat ve službách Blob Storage a Azure Files. Tyto klíče musíte uložit v Azure Key Vault nebo ve službě Azure Key Vault Managed Hardware Security Module (HSM). Další informace najdete v tématu Klíče spravované zákazníkem pro šifrování služby Azure Storage.
Výhody poskytované jednotlivými režimy (SMK nebo CMK)
Šifrování dat pomocí klíčů spravovaných službou pro Azure Database for PostgreSQL poskytuje následující výhody:
- Služba automaticky a plně řídí přístup k datům.
- Služba automaticky a plně řídí životní cyklus klíče, včetně obměně klíče.
- Nemusíte se starat o správu šifrovacích klíčů dat.
- Šifrování dat na základě klíčů spravovaných službou nemá negativní vliv na výkon vašich úloh.
- Zjednodušuje správu šifrovacích klíčů (včetně jejich pravidelné obměně) a správu identit používaných pro přístup k těmto klíčům.
Šifrování dat pomocí klíčů spravovaných zákazníkem pro Azure Database for PostgreSQL poskytuje následující výhody:
- Plně řídíte přístup k datům. Pokud chcete znepřístupnit databázi, můžete klíč odebrat.
- Životní cyklus klíče, včetně obměně klíče, plně řídíte tak, aby odpovídal firemním zásadám.
- Všechny šifrovací klíče můžete centrálně spravovat a organizovat ve vlastních instancích služby Azure Key Vault.
- Šifrování dat založené na klíčích spravovaných zákazníkem nemá negativní vliv na výkon vašich úloh.
- Můžete implementovat oddělení povinností mezi bezpečnostními důstojníky, správci databází a správci systému.
Požadavky CMK
Při použití šifrovacího klíče spravovaného zákazníkem převezmete odpovědnost. Musíte nasadit vlastní Azure Key Vault nebo Azure Key Vault HSM. Musíte vygenerovat nebo importovat vlastní klíč. Ve službě Key Vault musíte udělit požadovaná oprávnění, aby flexibilní server Azure Database for PostgreSQL mohl s klíčem provádět nezbytné akce. Musíte nakonfigurovat všechny aspekty sítě Azure Key Vault, ve kterých se klíč uchovává, aby k klíči měl přístup váš Azure Database for PostgreSQL flexibilní server. Auditování přístupu ke klíči je také vaší zodpovědností. Nakonec zodpovídáte za obměna klíče a v případě potřeby aktualizujete konfiguraci flexibilního serveru Azure Database for PostgreSQL tak, aby odkazoval na obměněnou verzi klíče.
Když pro účet úložiště nakonfigurujete klíče spravované zákazníkem, Azure Storage zašifruje kořenový klíč šifrování dat (DEK) daného účtu pomocí klíče spravovaného zákazníkem v přidruženém trezoru klíčů nebo ve spravovaném HSM. Ochrana kořenového šifrovacího klíče se změní, ale data ve vašem účtu Azure Storage zůstanou zašifrovaná vždy. Na vaší straně není potřeba žádná další akce, která zajistí, že vaše data zůstanou zašifrovaná. Ochrana pomocí klíčů spravovaných zákazníkem se projeví okamžitě.
Azure Key Vault je cloudový externí systém pro správu klíčů. Je vysoce dostupné a poskytuje škálovatelné a zabezpečené úložiště pro kryptografické klíče RSA, volitelně podporované moduly hardwarového zabezpečení (HSM) ověřenými podle standardu FIPS 140. Nepovoluje přímý přístup k uloženému klíči, ale poskytuje služby šifrování a dešifrování autorizovaným entitům. Key Vault může klíč vygenerovat, importovat ho nebo ho přijímat z místního zařízení HSM.
Následující seznam popisuje požadavky na konfiguraci šifrování dat pro Azure Database for PostgreSQL:
- V případě konfigurací CMK s jedním tenantem musí Key Vault a flexibilní server Azure Database for PostgreSQL patřit do stejného tenanta Microsoft Entra. Scénáře napříč tenanty najdete v tématu Klíče spravované zákazníkem napříč tenanty. Přesunutí prostředku Key Vault poté vyžaduje překonfigurování šifrování dat.
- Nastavte pro službu Key Vault konfiguraci Počet dnů uchovávání odstraněných trezorů na 90 dnů. Pokud jste nakonfigurovali existující Key Vault instanci s nižším číslem, zůstane platná. Pokud ale chcete toto nastavení upravit a zvýšit hodnotu, musíte vytvořit novou instanci Key Vault. Po vytvoření instance nemůžete toto nastavení změnit.
- Povolte funkci obnovitelného odstranění v Key Vault, která pomáhá chránit před ztrátou dat, pokud dojde k náhodnému odstranění klíče nebo instance Key Vault. Služba Key Vault uchovává prostředky po přechodném odstranění po dobu 90 dnů, pokud je uživatel mezitím neobnoví nebo trvale neodstraní. Akce obnovení a vymazání mají svá vlastní oprávnění přidružená k roli RBAC služby Key Vault nebo k oprávnění zásad přístupu. Funkce dočasného odstranění je ve výchozím nastavení zapnutá. Pokud máte nějaký trezor klíčů Key Vault, který byl nasazen před dlouhou dobou, může mít stále zakázané měkké odstranění. V takovém případě ho můžete zapnout pomocí Azure CLI.
- Povolením ochrany před vymazáním vynuťte povinnou dobu uchovávání pro odstraněné trezory a objekty trezorů.
- Udělte spravované identitě přiřazené uživatelem flexibilního serveru Azure Database for PostgreSQL přístup ke klíči následujícím způsobem:
- Upřednostňovaný postup: Nakonfigurujte Azure Key Vault pomocí modelu oprávnění RBAC a přiřaďte spravovanou identitu roli uživatele šifrování šifrovací služby Key Vault.
- Starší verze: Pokud je služba Azure Key Vault nakonfigurovaná s modelem oprávnění zásad přístupu, udělte spravované identitě následující oprávnění:
- get: Načíst vlastnosti a veřejnou část klíče z Key Vault.
- list: Seznam a iterace prostřednictvím klíčů uložených ve službě Key Vault.
- wrapKey: Šifrování šifrovacího klíče dat.
- unwrapKey: Dešifrování šifrovacího klíče dat.
- Klíč použitý k šifrování šifrovacího klíče dat může být pouze asymetrický, RSA nebo RSA-HSM. Podporují se velikosti klíčů 2 048, 3 072 a 4 096. K lepšímu zabezpečení použijte 4 096bitový klíč.
- Datum a čas aktivace klíče (pokud je nastavená) musí být v minulosti. Datum a čas vypršení platnosti (pokud je nastaveno) musí být v budoucnu.
- Klíč musí být ve stavu Povoleno .
- Pokud importujete existující klíč do služby Key Vault, zadejte ho v podporovaných formátech souborů (
.pfx.byoknebo.backup).
Aktualizace verze klíče CMK
CmK můžete nakonfigurovat pro ruční obměnu klíčů a aktualizace nebo automatické aktualizace verzí klíčů po ruční nebo automatické obměně klíčů v Key Vault.
Další informace najdete v tématu Konfigurace šifrování dat pomocí klíče spravovaného zákazníkem během zřizování serveru.
Důležité
Když klíč otočíte na novou verzi, ponechte starý klíč dostupný pro úspěšné opětovné šifrování. Zatímco většina přešifrování probíhá během 30 minut, počkejte aspoň 2 hodiny, než zakážete přístup ke staré verzi klíče.
Ruční rotace klíčů a aktualizace
Při konfiguraci CMK s ručními aktualizacemi klíčů je nutné ručně aktualizovat verzi klíče v Azure Database for PostgreSQL flexibilním serveru po ruční nebo automatické obměně klíčů v Key Vault. Server bude nadále používat starou verzi klíče, dokud ji neaktualizujete. Tento režim nastavíte zadáním identifikátoru URI klíče, který v URI obsahuje verzi GUID. Například: https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Donedávna byla tato možnost jedinou dostupnou možností.
Pokaždé, když klíč ručně otočíte nebo když AKV klíč automaticky obmění na základě zásad jeho obměny, bylo nutné aktualizovat vlastnost CMK na vašem serveru PostgreSQL. Tento přístup se ukázal být pro operátory náchylný k chybám nebo vyžadoval vlastní skript k zajištění rotace, zejména při použití funkce automatické rotace služby Key Vault.
Automatické aktualizace verze klíče
Pokud chcete povolit automatické aktualizace verzí klíče, použijte identifikátor URI klíče bez verzí. Tento přístup eliminuje potřebu aktualizovat vlastnost verze CMK na serveru PostgreSQL po obměně klíčů. PostgreSQL automaticky převezme novou verzi klíče a znovu zašifruje šifrovací klíč dat. Tento přístup výrazně zjednodušuje správu životního cyklu klíčů, zejména v kombinaci s Key Vault autorotací.
Pokud chcete tento přístup implementovat pomocí Azure Resource Manager, Bicep, Terraformu, Azure PowerShell nebo Azure CLI, vynecháte verzi GUID z identifikátoru URI klíče.
V portálu zaškrtněte políčko, aby uživatelské rozhraní při interaktivním výběru a při ověřování identifikátoru URI potlačilo identifikátory GUID verzí.
Recommendations
Pokud pro šifrování dat používáte klíč spravovaný zákazníkem, nakonfigurujte Key Vault podle těchto doporučení:
- Nastavte zámek prostředku na Key Vault, aby se zabránilo náhodnému nebo neoprávněnému odstranění tohoto kritického prostředku.
- Povolte audit a reportování pro všechny šifrovací klíče. Key Vault poskytuje protokoly, které se dají snadno vložit do jiných nástrojů pro správu událostí a informací o zabezpečení (SIEM). Protokoly služby Azure Monitor jsou jedním z příkladů služby, která je už integrovaná.
- Uzamkněte službu Key Vault výběrem možnosti Zakázat veřejný přístup a Povolit důvěryhodným službám Microsoftu obejít tuto bránu firewall.
- Povolte automatické aktualizace verze klíče.
Poznámka:
Když vyberete Možnost Zakázat veřejný přístup a Povolit důvěryhodným službám Microsoftu obejít tuto bránu firewall, může se při pokusu o správu služby Key Vault přes portál zobrazit chyba podobná následující: "Povolili jste řízení přístupu k síti. K tomuto trezoru klíčů mají přístup pouze povolené sítě." Tato chyba nebrání možnosti poskytovat klíče během instalace klíče spravovaného zákazníkem nebo načítání klíčů ze služby Key Vault během operací serveru.
- Uchovávejte kopii klíče spravovaného zákazníkem na bezpečném místě nebo ji uložte do služby escrow.
- Pokud Key Vault tento klíč vygeneruje, vytvořte zálohu klíče před prvním použitím klíče. Zálohu můžete obnovit jenom do služby Key Vault.
Zvláštní aspekty
Náhodné odvolání přístupu ke klíči ze služby Azure Key Vault
Někdo s dostatečnými přístupovými právy k Key Vault může omylem zakázat přístup k serveru ke klíči:
- Zrušení přiřazení role RBAC šifrovací služby Key Vault - Uživatel šifrování nebo odvolání oprávnění z identity, která se používá k načtení klíče v Key Vault.
- Odstranění klíče
- Odstranění instance služby Key Vault
- Změna pravidel brány firewall služby Key Vault
- Odstranění spravované identity serveru v Microsoft Entra ID
Monitorování klíčů uložených v Azure Key Vault
Pokud chcete monitorovat stav databáze a zapnout výstrahy pro ztrátu přístupu k ochraně šifrování dat, nakonfigurujte následující funkce Azure:
- Stav prostředku: Databáze, která ztratila přístup ke klíči CMK, se po zamítnutí prvního připojení k databázi zobrazí jako Nepřístupná.
- Protokol aktivit: Pokud přístup k klíči CMK v instanci služby Key Vault spravované zákazníkem selže, položky se přidají do protokolu aktivit. Pokud vytvoříte upozornění na tyto události co nejdříve, můžete přístup obnovit.
- Skupiny akcí: Definujte tyto skupiny pro příjem oznámení a upozornění na základě vašich preferencí.
Obnovení záloh serveru nakonfigurovaného pomocí klíče spravovaného zákazníkem
Po zašifrování flexibilního serveru Azure Database for PostgreSQL klíčem spravovaným zákazníkem uloženým v Key Vault se zašifruje také všechna nově vytvořená kopie serveru. Tuto novou kopii můžete vytvořit prostřednictvím operace obnovení k určitému bodu v čase (PITR) nebo replik pro čtení.
Když nastavujete šifrování dat pomocí klíče spravovaného zákazníkem, během operace, jako je obnovení zálohy nebo vytvoření repliky pro čtení, můžete se vyhnout problémům pomocí těchto kroků na primárních a obnovených serverech nebo serverech replik:
- Zahajte proces obnovení nebo proces vytvoření repliky pro čtení z primárního Azure Database for PostgreSQL flexibilního serveru.
- Na obnoveném serveru nebo replice serveru můžete změnit zákazníkem spravovaný klíč a uživatelem přiřazenou spravovanou identitu, která se používá pro přístup ke službě Key Vault. Ujistěte se, že identita přiřazená na nově vytvořeném serveru má požadovaná oprávnění ke službě Key Vault.
- Po obnovení neodvolejte původní klíč. V tuto chvíli není odvolání klíče podporováno po obnovení serveru s klíčem spravovaným zákazníkem na jiný server.
Spravované hsmy
Moduly hardwarového zabezpečení (HSM) jsou hardwarová zařízení odolná proti manipulaci, která pomáhají zabezpečit kryptografické procesy generováním, ochranou a správou klíčů používaných k šifrování dat, dešifrování dat, vytváření digitálních podpisů a vytváření digitálních certifikátů. Moduly HSM se testují, ověřují a certifikují podle nejvyšších standardů zabezpečení, včetně standardu FIPS 140 a společných kritérií.
Azure Key Vault Managed HSM je plně spravovaná, vysoce dostupná cloudová služba pro jednoho tenanta v souladu se standardy. Můžete ho použít k ochraně kryptografických klíčů pro cloudové aplikace prostřednictvím ověření HSM FIPS 140-3.
Při vytváření nového Azure Database for PostgreSQL flexibilního serveru na portálu Azure pomocí klíče spravovaného zákazníkem můžete jako úložiště klíčů zvolit Azure Key Vault Managed HSM jako alternativu k Azure Key Vault. Požadavky, pokud jde o uživatelsky definovanou identitu a oprávnění, jsou stejné jako u služby Azure Key Vault (jak je uvedeno výše v tomto článku). Další informace o tom, jak vytvořit spravovanou instanci HSM, její výhody a rozdíly od sdíleného úložiště certifikátů založeného na službě Key Vault a jak importovat klíče do spravovaného HSM, najdete v tématu Co je spravovaný HSM služby Azure Key Vault?.
Nepřístupná podmínka klíče spravovaného zákazníkem
Když nakonfigurujete šifrování dat pomocí klíče spravovaného zákazníkem uloženým v Key Vault, server vyžaduje nepřetržitý přístup k tomuto klíči, aby zůstal online. Pokud server ztratí přístup, změní jeho stav na Nepřístupný a začne odepřít všechna připojení.
Mezi možné důvody nedostupného stavu serveru patří:
| Příčina | Řešení |
|---|---|
| Kterýkoli ze šifrovacích klíčů, na které server odkazuje, má nastavené datum a čas vypršení platnosti a toto datum a čas nastanou. | Rozšiřte datum vypršení platnosti klíče. Pak počkejte, až služba znovu aktualizuje klíč a automaticky přepojí stav serveru na Připraveno. Teprve když je server zpět ve stavu Ready, můžete klíč obměnit na novější verzi nebo vytvořit nový klíč a aktualizovat server tak, aby odkazoval na tuto novou verzi téhož klíče nebo na nový klíč. |
| Otočíte klíčem a zapomenete aktualizovat instanci Azure Database for PostgreSQL – flexibilní server tak, aby odkazovala na novou verzi klíče. Starý klíč, na který server odkazuje, vyprší a změní stav serveru na Nepřístupný. | Abyste se této situaci vyhnuli, nezapomeňte při každé obměně klíče aktualizovat instanci serveru tak, aby odkazovat na novou verzi. Uděláte to tak, že použijete az postgres flexible-server updatenásledující příklad, který popisuje "Změnit klíč nebo identitu pro šifrování dat. Šifrování dat nejde povolit po vytvoření serveru, tím se aktualizuje jenom klíč nebo identita.". Pokud jej raději chcete aktualizovat pomocí rozhraní API, můžete volat koncový bod služby Servers - Update. |
| Odstraníte instanci Key Vault, flexibilní server Azure Database for PostgreSQL nemůže získat přístup ke klíči a přesune se do nepřístupného stavu. | Obnovte instanci služby Key Vault a počkejte, až služba spustí pravidelnou revalidaci klíče, a automaticky převést stav serveru na připraveno. |
| Odstraníte spravovanou identitu z Microsoft Entra ID, která se používá k načtení libovolného šifrovacího klíče uloženého ve službě Key Vault. | Obnovte identitu a počkejte, až služba spustí pravidelnou revalidaci klíče, a automaticky převést stav serveru na Připraveno. |
| Model oprávnění služby Key Vault je nakonfigurovaný tak, aby používal řízení přístupu na základě role. Odeberete přiřazení role RBAC uživatele šifrovací služby Key Vault ze spravovaných identit, které jsou nakonfigurované pro načítání libovolného klíče. | Znovu přiřaďte roli RBAC spravované identitě a počkejte, až služba provede pravidelnou opětovnou kontrolu klíče a automaticky přepne stav serveru na Ready. Alternativní přístup spočívá v udělení role ve službě Key Vault jiné spravované identitě a aktualizaci serveru tak, aby pro přístup k klíči používal tuto jinou spravovanou identitu . |
| Váš model oprávnění služby Key Vault je nakonfigurovaný tak, aby používal zásady přístupu. Odvoláváte zásady přístupu list, get, wrapKey nebo unwrapKey od spravovaných identit, které jsou nakonfigurovány k načítání kteréhokoli z klíčů. | Znovu přiřaďte roli RBAC spravované identitě a počkejte, až služba provede pravidelné opětovné ověření klíče a automaticky přepne stav serveru na Připraveno. Alternativním přístupem je udělení požadovaných zásad přístupu ve službě Key Vault jiné spravované identitě a aktualizace serveru tak, aby používala tuto druhou spravovanou identitu pro přístup ke klíči. |
| Nastavili jste příliš omezující pravidla brány firewall služby Key Vault, aby flexibilní server Azure Database for PostgreSQL nemohl komunikovat se službou Key Vault za účelem načtení vašich klíčů. | Při konfiguraci brány firewall služby Key Vault nezapomeňte vybrat možnost povolit důvěryhodné služby Microsoftu , aby flexibilní server Azure Database for PostgreSQL mohl bránu firewall obejít. |
Poznámka:
Pokud je klíč zakázaný, odstraněný, prošlý nebo nedostupný, stane se server, který má data zašifrovaná tímto klíčem, nedostupný, jak je uvedeno dříve. Stav serveru se znovu nezmění na Připraveno , dokud nebude moct znovu obnovit šifrovací klíče.
Obecně platí, že se server stane nedostupným do 60 minut poté, co je klíč zakázán, odstraněn, vyprší jeho platnost nebo není dostupný. Jakmile bude klíč k dispozici, může trvat až 60 minut, než server znovu přejde do stavu Připraveno.
Obnovení po odstranění spravované identity
Pokud odstraníte spravovanou identitu přiřazenou uživatelem, která přistupuje k šifrovacímu klíči uloženému v Key Vault v Microsoft Entra ID, obnovte ho následujícím postupem:
- Obnovte identitu nebo vytvořte novou spravovanou identitu Entra ID.
- Pokud jste vytvořili novou identitu, i když má úplně stejný název jako odstraněná identita, aktualizujte Azure Database pro vlastnosti flexibilního serveru, aby věděla, že tato nová identita musí použít pro přístup k šifrovacímu klíči.
- Ujistěte se, že tato identita má správná oprávnění pro operace s klíčem ve službě Azure Key Vault (AKV).
- Počkejte přibližně hodinu, než server znovu ověří klíč.
Důležité
Jednoduché vytvoření nové identity Entra ID se stejným názvem jako odstraněná identita neobnoví spravovanou identitu po jejím odstranění.
Používejte šifrování dat s klíči spravovanými zákazníkem a geograficky redundantní funkce pro zajištění kontinuity provozu
Azure Database for PostgreSQL podporuje pokročilé funkce obnovení dat , jako jsou repliky a geograficky redundantní zálohování. Následující požadavky platí pro nastavení šifrování dat pomocí sad CMK a těchto funkcí kromě základních požadavků na šifrování dat pomocí sad CMK:
- V instanci Key Vault, která musí existovat v oblasti, ve které je uložená geograficky redundantní záloha, musíte vytvořit geograficky redundantní šifrovací klíč.
- Verze rozhraní REST API Azure Resource Manageru pro podporu geograficky redundantních serverů CMK s podporou geograficky redundantního zálohování je 2022-11-01-preview. Pokud chcete použít šablony Azure Resource Manageru k automatizaci vytváření serverů, které používají šifrování pomocí sad CMK i geograficky redundantních funkcí zálohování, použijte tuto verzi rozhraní API.
- Stejnou identitu spravovanou uživatelem nemůžete použít k ověření pro instanci služby Key Vault primární databáze a instanci služby Key Vault, která obsahuje šifrovací klíč pro geograficky redundantní zálohování. Pokud chcete zachovat regionální odolnost, vytvořte identitu spravovanou uživatelem ve stejné oblasti jako geograficky redundantní zálohy.
- Pokud při vytváření nastavíte repliku databáze pro čtení tak, aby byla šifrovaná pomocí klíčů CMK, musí být její šifrovací klíč v instanci služby Key Vault v oblasti, kde se replika databáze pro čtení nachází. Musíte vytvořit uživatelem přiřazenou identitu k ověřování vůči této instanci služby Key Vault ve stejné oblasti.
Klíče spravované zákazníkem napříč tenanty (CMK) (Preview)
Klíče spravované zákazníkem mezi tenanty umožňují používat šifrovací klíče uložené v trezoru klíčů Key Vault nebo v instanci Managed HSM, které patří k jinému Microsoft Entra ID než váš flexibilní server Azure Database for PostgreSQL. Nastavení CMK mezi klienty vyžaduje dodatečnou konfiguraci a koordinaci mezi klienty. Ve scénáři mezi tenanty se prostředek Azure Database for PostgreSQL nachází v tenantovi spravovaném nezávislým dodavatelem softwaru (ISV) označovaným jako poskytovatel služeb. Klíč použitý k šifrování prostředku Azure Database for PostgreSQL se nachází v trezoru klíčů v jiném tenantovi, který spravuje zákazník.
Přehled nastavení
V tenantovi ISV
Vytvoření víceklientských aplikací
V klientském tenantu
Vytvořte nebo použijte existující trezor klíčů nebo spravované HSM a udělte oprávnění ke klíčům víceklientské aplikaci
Vytvoření nového nebo použití existujícího klíče
Načtení klíče ze služby Azure Key Vault nebo spravovaného HSM Azure a zaznamenání identifikátoru klíče
V tenantovi ISV
Až do tohoto bodu jste nakonfigurovali multitenantní aplikaci na tenantovi poskytovatele služby. Také jste nainstalovali aplikaci na zákaznickém tenantu a nakonfigurovali trezor klíčů a klíč na zákaznickém tenantu. Dále můžete vytvořit Azure Database for PostgreSQL server v tenantovi poskytovatele služeb a nakonfigurovat klíče spravované zákazníkem pomocí klíče z tenanta zákazníka.
Když vytvoříte Azure Database for PostgreSQL server s klíči spravovanými zákazníkem, musíte zajistit, aby měl přístup ke klíčům, které zákazník použil. Ve scénářích s jedním tenantem udělíte přímý přístup k trezoru klíčů uživatelem spravované identitě serveru Azure Database for PostgreSQL. Ve scénáři mezi tenanty už nemůžete záviset na přímém přístupu k trezoru klíčů, protože je v jiném tenantovi spravovaném zákazníkem. Toto omezení je důvod, proč jste vytvořili aplikaci mezi tenanty a zaregistrovali spravovanou identitu uvnitř aplikace, abyste jí poskytli přístup k trezoru klíčů zákazníka v předchozích částech. Tato spravovaná identita ve spojení s ID aplikace mezi tenanty je to, co používáte při vytváření klíče CMK mezi tenanty pro Azure Database for PostgreSQL server.
Kdykoli je v trezoru klíčů dostupná nová verze klíče, server Azure Database for PostgreSQL automaticky převezme novou verzi.
Použití portálu Azure
Pokud chcete nakonfigurovat klíče spravované zákazníkem napříč tenanty pro nový server Azure Database for PostgreSQL na portálu Azure, postupujte takto:
Při vytváření prostředku Azure Database for PostgreSQL na Azure Portal vyberte kartu Zabezpečení a potom vyberte možnost Klíč spravovaný zákazníkem.
Přiřaďte spravovanou identitu přiřazenou uživatelem vytvořenou jako spravovanou identitu přiřazenou uživatelem.
Aplikaci pro více klientů přiřaďte pomocí názvu aplikace.
Do metody výběru klíče zadejte identifikátor klíče pomocí identifikátoru klíče zákazníka získaného z klientského tenanta.
Použití Azure Resource Manager šablon JSON a rozhraní REST API
Nasadit šablonu ARM s následujícími konkrétními parametry:
Poznámka:
Pokud tuto ukázku znovu vytváříte v některé z vašich šablon Azure Resource Manager, použijte verzi apiVersion2025-03-15-privatepreview nebo novější.
| Parameter | Description | Ukázková hodnota |
|---|---|---|
primaryKeyUri |
Identifikátor klíče spravovaného zákazníkem, který se nachází v úložišti klíčů poskytovatele služeb. | https://my-vault.vault.azure.com/keys/my-key |
primaryUserAssignedIdentity |
Objekt určující, že spravovaná identita by měla být přiřazena Azure Database for PostgreSQL flexibilnímu serveru. | "identity":{"type":"UserAssigned","userAssignedIdentities":{"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity":{}}} |
primaryFederatedIdentityClientId |
ID klienta víceklientských Microsoft Entra aplikací | application-client-id |
Tady je příklad rozhraní REST API s nakonfigurovanými třemi parametry:
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview
Příklad textu požadavku:
{
"location": "eastus2",
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>": {}
}
},
"sku": {
"name": "Standard_D2s_v3",
"tier": "GeneralPurpose"
},
"properties": {
"createMode": "Create",
"version": "16",
"minorVersion": "5",
"storage": {
"storageSizeGB": 32
},
"network": {
"publicNetworkAccess": "Enabled"
},
"backup": {
"backupRetentionDays": 7,
"geoRedundantBackup": "Disabled"
},
"dataEncryption": {
"type": "AzureKeyVault",
"primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
"primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<key-version>",
"primaryFederatedIdentityClientId": "<application-client-id>"
}
}
}
Tady je příklad rozhraní REST API pro obměnu klíčů. Příklad PATCH aktualizuje pouze identifikátor URI klíče CMK, aby se šifrovací klíč otočil bez opětovného vytvoření serveru.
PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview
Tělo požadavku (příklad pro rotaci klíče):
{
"properties": {
"dataEncryption": {
"type": "AzureKeyVault",
"primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
"primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<new-key-version>",
"primaryFederatedIdentityClientId": "<application-client-id>"
}
}
}
Důležité
I když aktualizujete pouze primaryKeyUri, musíte v textu požadavku zadat všechny vlastnosti šifrování dat. Pokud v těle požadavku nezadáte primaryFederatedIdentityClientId, je požadavek považován za nemezitenantní konfiguraci CMK.
Omezení verze Preview pro klíče spravované zákazníkem (CMK) napříč tenanty
- Azure PowerShell a Azure CLI tuto funkci zatím nepodporují.
- Vytvoření serveru s geograficky redundantními zálohami a povolením operací dlouhodobého uchovávání záloh se v současné době nepodporuje.
- Verze Preview je aktuálně podporovaná jenom v těchto oblastech:
- USA – východ 2
- USA – západ 2
- USA – střed
- Austrálie – jihovýchod
- Austrálie – východ
- Severní Evropa
Omezení klíčů spravovaných zákazníkem (CMK)
Toto jsou aktuální omezení konfigurace klíče spravovaného zákazníkem na flexibilním serveru Azure Database for PostgreSQL:
- Šifrování klíče spravovaného zákazníkem můžete nakonfigurovat pouze při vytváření nového serveru, ne jako aktualizace existujícího Azure Database for PostgreSQL flexibilního serveru. Místo toho můžete obnovit zálohu pitR na nový server s šifrováním CMK.
- Jakmile nakonfigurujete šifrování klíčů spravovaných zákazníkem, nemůžete se vrátit zpět k systémovému spravovanému klíči. Pokud se chcete vrátit zpět, musíte server obnovit na nový s šifrováním dat nakonfigurovaným pomocí systémového spravovaného klíče.
- Instance Azure Key Vault Managed HSM nebo instance Azure Key Vault, na které chcete šifrovací klíč uložit, musí existovat ve stejné oblasti, ve které vytváříte Azure Database pro flexibilní server.