Sdílet prostřednictvím

Šifrování s klíči spravovanými zákazníkem v Microsoft Cloud for Sovereignty

  • Článek

Zákazníci, kteří plánují implementaci Microsoft Cloud for Sovereignty, mohou vyžadovat použití funkcí šifrování dat, aby splnili požadavky na suverenitu dat. Zákazníci s přísnými požadavky na datovou suverenitu by měli vyvinout plány implementace správy klíčů v cloudu. Tento článek vede cloudové architekty, vlastníky kryptografických systémů a další osoby s rozhodovací pravomocí k vytvoření plánu implementace šifrování na úrovni platformy v Azure. Plánování šifrování na úrovni platformy obvykle zahrnuje identifikaci požadavků na správu klíčů, výběr technologií a výběr návrhů a možností konfigurace pro služby Azure, které se mají používat. Tento proces zahrnuje přijímání technických rozhodnutí ve třech oblastech:

  • Definice požadavky na správu klíčů: Co musí vaše organizace udělat, aby ochránila citlivá data zákazníků a citlivý kryptografický materiál?
  • Vyberte funkce šifrování dat k ochraně zákaznických dat: Jak, kde a kdy byste měli šifrovat zákaznická data v Azure?
  • Vyberte řešení správy klíčů k ochraně zákaznických klíčů: Jaké úložiště klíčů byste měli použít k ochraně klíčů pro šifrování dat, které se používají k šifrování zákaznických dat v Azure?

Definování požadavků správy klíčů

Požadavky na správu klíčů mohou zahrnovat technické požadavky na používané kryptografické služby a provozní požadavky související s výkonem, bezpečností a suverenitou. Doporučeným výchozím bodem pro rozhodování o tom, kdy a jak šifrovat data v úlohách Azure, je systém klasifikace dat organizace. Díky sladění požadavků na šifrování s klasifikacemi dat namísto specifických systémů nebo řešením mají organizace větší flexibilitu při výběru optimální úrovně šifrování během plánování migrace úloh.

Založení požadavků na šifrování na klasifikaci dat také umožňuje stupňovitý přístup, kdy úlohy s nižší kritičností mohou využívat výhod jednodušších řešení a zároveň si nejsložitější konfigurace vyhradit pro úlohy s vyšší úrovní přirozeného rizika. Příkladem tohoto přístupu by bylo umožnit použití klíčů spravovaných společností Microsoft k šifrování účtů úložiště pro vývojová prostředí a zároveň vyžadovat, aby účty produkčního úložiště používaly šifrovací klíče spravované zákazníkem.

Poté, co organizace jasně pochopí, jak její požadavky na šifrování souvisí s jejich klasifikací dat, může zahájit proces výběru funkcí pro služby Azure, které plánují využívat. Některé z těchto funkcí mohou fungovat jinak než podobné místní systémy, takže organizacím doporučujeme, aby se seznámily s tím, jak funguje šifrování v Azure, a prostudovaly si doporučení a osvědčené postupy pro navrhování řešení šifrování. Následující články poskytují další pohledy na některá technická rozhodnutí, která musí zákazníci učinit, a mohou být užitečným výchozím bodem pro zahájení konverzace o cílech správy klíčů v cloudu v organizaci.

Výběr funkcí šifrování dat

Mnoho služeb Azure umožňuje šifrování pomocí klíčů, které jsou generovány, ukládány a spravovány výhradně Azure, bez jakékoli interakce se zákazníkem. Tyto klíče spravované platformou mohou organizacím pomoci implementovat šifrování s minimální provozní režií. Zákazníci s přísnými požadavky na suverenitu dat však možná budou muset vybrat konkrétní funkce šifrování platformy, aby ochránili citlivá data, když jsou v klidu v dané službě Azure.

U vysoce citlivých dat mnoho běžně používaných služeb Azure umožňuje zákazníkům implementovat dvojité šifrování pomocí klíčů spravovaných zákazníkem (CMK). Implementace klíčů spravovaných zákazníkem ve službách Azure může zákazníkům pomoci chránit data uložená v těchto službách před neoprávněným přístupem.

Implementace klíčů spravovaných zákazníkem v Azure může zvýšit náklady a složitost úlohy, takže organizacím doporučujeme, aby vyhodnotily potřebu této funkce pro každou úroveň úloh a klasifikace dat. Implementace klíčů spravovaných zákazníkem pouze pro úlohy a datové typy, které to potřebují, může pomoci snížit provozní režii u úloh, které nezpracovávají citlivá data.

Pokud jsou vyžadovány klíče spravované zákazníkem, je třeba je nakonfigurovat pro každou příslušnou službu Azure. Organizace mohou pomoci zefektivnit plánování nasazení nebo migrace zavedením celopodnikových standardů a opakovatelných návrhových vzorů pro implementaci těchto funkcí. Následující články poskytují další informace o tom, jak se v Azure konfiguruje šifrování dat v klidu:

Přečtěte si, jak nakonfigurovat běžně používané služby Azure pro šifrování dat v klidu pomocí klíčů spravovaných zákazníkem:

Výběr řešení správy klíčů

Zatímco funkce, jako je dvojité šifrování pomocí klíčů spravovaných zákazníkem, mohou pomoci chránit zákaznická data, která jsou spravována ve službách Azure, cloudová řešení správy klíčů pomáhají chránit šifrovací klíče a další kryptografické materiály, které se používají k šifrování citlivých dat. Zákazníci s přísnými požadavky na suverenitu dat by si měli vybrat vhodné řešení správy klíčů na základě svých potřeb ujištění a rizikového profilu svých úloh.

Úlohy, které zpracovávají citlivá data, mohou těžit z přidané jistoty, kterou poskytují řešení, jako je Spravovaný HSM Azure, včetně modulů hardwarového zabezpečení ověřených FIPS-140-2 na úrovni 3, které obsahují další ovládací prvky zabezpečení pro ochranu uloženého kryptografického materiálu.

Následující články poskytují pokyny, které mohou zákazníci použít k výběru vhodného úložiště klíčů pro jejich identifikované scénáře. Poskytuje také informace o tom, jak společnost Microsoft spravuje kryptografické služby, které používají zákazníci jako součást jejich řešení šifrování.

Operační modely pro správu klíčů

Azure Key Vault implementuje řízení přístupu na základě rolí různými způsoby v závislosti na tom, zda používáte úroveň Standard/Premium Azure Key Vault, nebo Spravovaný HSM Azure Key Vault. Tyto rozdíly v řízení přístupu mohou ovlivnit způsob, jakým organizace tyto funkce používá. Tato část popisuje tyto rozdíly a jak mohou ovlivnit způsob, jakým se organizace rozhodne navrhnout své provozní procesy pro cloudovou správu klíčů.

Omezení shody pro FIPS-140 ověření úrovně 3

Ověření FIPS-140 úrovně 3 vyžaduje identifikaci operátora na základě identity. Tato zabezpečení se nasazují a ověřují v základním hardwaru HSM, který podporuje služby Key Vault v Azure. V důsledku toho jsou funkce RBAC v Azure Key Vault závislé na možnostech RBAC základního hardwaru.

Spravovaný HSM Azure Key Vault využívá místní přiřazení RBAC, která jsou implementována na úrovni hardwaru a umožňují přiřazení rolí v rozsahu domény zabezpečení (například v rámci HSM) nebo na základě jednotlivých klíčů. To znamená, že vytvoření klíče vyžaduje oprávnění správce v celé doméně zabezpečení, protože oprávnění nelze přiřadit ke klíči, který ještě neexistuje. Dopad tohoto návrhu je, že kdokoli, kdo potřebuje uložit klíč v instanci mHSM, musí mít buď úplná oprávnění pro všechny klíče uložené v této doméně zabezpečení, nebo si klíče vyžádat od centralizovaného týmu, který má požadovaná oprávnění v bezpečnostní doméně. To představuje posun od zásad pro Azure Key Vault, které doporučují vytvořit samostatné trezory klíčů pro každou aplikaci.

Operace správy klíčů ve Spravovaném HSM Azure Key Vault

Aby bylo možné vyvinout provozní procesy pro správu klíčů, měli by se zákazníci zjistit, zda vyžadují Spravovaný HSM Azure Key Vault jako součást své architektury řešení. Organizace, které plánují používat spravovaný HSM, by se měly nejprve seznámit s modely řízení přístupu používanými pro správu i kryptografické operace a porozumět tomu, jak je přidělováno řízení přístupu založené na rolích.

Další informace o řízení přístupu ve spravovaném HSM:

Organizace, které plánují používat Azure Key Vault HSM, by si měly prohlédnout seznam vestavěných rolí RBAC a povolených operací pro spravovaný HSM a konkrétně naplánovat řešení následujících provozních scénářů:

  • Vytvoření nového klíče ve spravovaném HSM
  • Operace správy existujícího klíče pomocí řídicí roviny, jako jsou aktualizace klíčů nebo rotace klíčů
  • Využití existujícího klíče v rovině dat aplikací nebo službou

V současné době je jediným způsobem, jak přidělit oprávnění k vytvoření nového klíče, přiřazení role, jako např. Crypto User, která také zahrnuje další oprávnění, jako je střídání a mazání klíčů. V důsledku toho může udělení potřebných oprávnění k vytvoření vlastních klíčů ve spravovaném HSM členovi aplikačního týmu pravděpodobně porušit principy nejmenších oprávnění, protože tento uživatel by měl také oprávnění správce pro všechny klíče v HSM. Tento problém lze vyřešit zavedením centralizovaného týmu se zvýšenými oprávněními, který může usnadnit požadavky na vytváření klíčů, nebo zavedením automatizace, která může usnadnit požadavky na vytváření nových klíčů prostřednictvím procesů správy služeb IT, které využívají rozhraní REST API spravovaného HSM.

Související obsah