Kryptering med kundhanterade nycklar i Microsoft Cloud for Sovereignty

  • Artikel

Kunder som planerar att implementera Microsoft Cloud for Sovereignty kan behöva använda datakrypteringsfunktionerna för att uppfylla de krav som ställs på datasuveränitet. Kunder med strikta krav på datasuveränitet bör utveckla planer för att implementera nyckelhantering i molnet. Den här artikeln vägleder molnarkitekter, kryptografiska systemägare och andra tekniska beslutsfattare att utveckla en plan för implementering av kryptering på plattformsnivå i Azure. Planering för kryptering på plattformsnivå innebär vanligtvis att identifiera viktiga hanteringskrav, fatta tekniska beslut och välja designer och konfigurationsval för de Azure-tjänster som ska användas. Denna process involverar att fatta tekniska beslut inom tre domäner:

  • Definiera nyckelhanteringskrav: Vad behöver din organisation göra för att skydda känsliga kunddata och känsligt kryptografiskt material?
  • Välj datakrypteringsfunktioner för att skydda kunddata: Hur, var och när ska du kryptera kunddata i Azure?
  • Välj nyckelhanteringslösningar för att skydda kundnycklar: Vilket nyckellager ska du använda för att skydda datakrypteringsnycklar som används för att kryptera kunddata i Azure?

Definiera krav för nyckelhantering

Krav på nyckelhantering kan innefatta tekniska krav på de kryptografiska tjänster som används och operativa krav relaterade till prestanda, säkerhet och suveränitet. Den rekommenderade utgångspunkten för att fatta beslut om när och hur data ska krypteras i Azure-arbetsbelastningar är en organisations dataklassificeringssystem. Genom att anpassa krypteringskraven till dataklassificeringar snarare än till specifika system eller lösningar har organisationer större flexibilitet att välja den optimala krypteringsnivån under planering av arbetsbelastningsmigrering.

Att basera krypteringskraven på dataklassificering möjliggör också ett stegvis tillvägagångssätt, där arbetsbelastningar med lägre kritikalitet kan dra fördel av enklare lösningar samtidigt som de mest komplexa konfigurationerna reserveras för arbetsbelastningar med en högre nivå av inneboende risk. Ett exempel på detta tillvägagångssätt skulle vara att tillåta användning av Microsoft-hanterade nycklar för att kryptera lagringskonton för utvecklingsmiljöer, samtidigt som det krävs att produktionslagringskonton använder kundhanterade krypteringsnycklar.

Efter att en organisation tydligt förstår hur deras krypteringskrav relaterar till deras dataklassificeringar kan de påbörja processen med funktionsval för de Azure-tjänster som de planerar att använda. Vissa av dessa funktioner kan fungera annorlunda än liknande lokala system, varför organisationer uppmuntras att bekanta sig med hur kryptering fungerar i Azure och granska rekommendationer och bästa praxis för att utforma krypteringslösningar. Följande artiklar ger ytterligare perspektiv på några av de tekniska val som kunderna behöver göra, och kan vara en användbar utgångspunkt för att inleda en konversation om en organisations mål för hantering av molnnycklar.

Välj datakrypteringsfunktioner

Många Azure-tjänster möjliggör kryptering med hjälp av nycklar som genereras, lagras och hanteras helt av Azure, utan någon kundinteraktion. Dessa plattformshanterade nycklar kan hjälpa organisationer att implementera kryptering med låga driftskostnader. Kunder med strikta datasuveränitetskrav kan emellertid behöva välja specifika plattformskrypteringsfunktioner för att skydda känsliga data medan dessa är i vila i en given Azure-tjänst.

För ytterst känsliga data tillåter många vanliga Azure-tjänster kunder att implementera dubbel kryptering med hjälp av hundhanterade nycklar (CMK). Implementering av kundhanterade nycklar i Azure-tjänster kan hjälpa kunder att skydda data som lagras i dessa tjänster från obehörig åtkomst.

Implementering av kundhanterade nycklar i Azure kan öka kostnaden och komplexiteten för en arbetsbelastning, varför organisationer uppmuntras att utvärdera behovet av den här funktionen för varje enskild arbetsbelastning och dataklassificeringsnivå. Genom att bland annat implementera kundhanterade nycklar för endast de arbetsbelastningar och datatyper som behöver det kan den operativa omkostnaden sänkas för de arbetsbelastningar som inte hanterar känsliga data.

Om kundhanterade nycklar krävs måste de konfigureras för varje respektive Azure-tjänst. Organisationer kan hjälpa till att effektivisera implementeringen eller migreringsplaneringen genom att etablera organisationsomfattande standarder och repeterbara designmönster för implementering av dessa funktioner. Följande artiklar ger mer information om hur data-at-rest-kryptering konfigureras i Azure:

Lär dig hur du konfigurerar vanliga Azure-tjänster för att kryptera data-at-rest med hjälp av kundhanterade nycklar:

Välj nyckelhanteringslösningar

Medan funktioner såsom dubbelkryptering med kundhanterade nycklar kan hjälpa till att skydda kunddata som underhålls i Azure-tjänster, hjälper molnbaserade nyckelhanteringslösningar till att skydda krypteringsnycklarna och annat kryptografiskt material som används för att kryptera känsliga data. Kunder med strikta krav på datasuveränitet bör välja en lämplig nyckelhanteringslösning baserat på deras säkerhetsbehov och riskprofilen för deras arbetsbelastningar.

Arbetsbelastningar som hanterar känsliga data kan ha nytta av den extra säkerhet som erbjuds av lösningar som Azure Managed HSM ger, inklusive FIPS-140-2 Level-3-validerade maskinvarusäkerhetsmoduler med extra säkerhetskontroller som skyddar lagrat kryptografiskt material.

Följande artiklar ger vägledning som kunder kan använda för att välja en lämplig nyckelbutik för sina identifierade scenarier. De ger också information om hur Microsoft hanterar kryptografiska tjänster som används av kunder som en del av deras krypteringslösning.

Verksamhetsmodeller för nyckelhantering

Azure Key Vault implementerar rollbaserad åtkomstkontroll på olika sätt, beroende på om du använder Standard/Premium-nivån i Azure Key Vault eller Azure Key Vault Managed HSM. Skillnader i åtkomstkontroll kan påverka hur en organisation använder dessa funktioner. I det här avsnittet beskrivs skillnaderna och hur de kan påverka hur en organisation väljer att utforma sina verksamhetsprocesser för molnnyckelhantering.

Överensstämmelsebegränsningar för FIPS-140 nivå 3-validering

FIPS-140 nivå 3-validering kräver identitetsbaserad operatörsidentifiering. Dessa säkerhetsfunktioner distribueras och verifieras i den underliggande HSM-maskinvaran som stöder Key Vault-tjänsterna i Azure. RBAC-funktionerna i Azure Key Vault är därför beroende av RBAC-funktionerna i den underliggande maskinvaran.

Azure Key Vault Managed HSM utnyttjar de lokala RBAC-tilldelningarna som implementeras på maskinvarunivå och tillåter rolltilldelningar i omfattningen av säkerhetsdomänen (till exempel HSM-omfattande) eller per nyckel. Det innebär att det krävs administrativa behörigheter för att skapa nycklar över hela säkerhetsdomänen eftersom det inte går att tilldela behörigheter för en nyckel som ännu inte finns. Påverkan av denna design är att alla som behöver lagra en nyckel i en mHSM-instans antingen måste ha fullständig behörighet för alla nycklar som lagras i säkerhetsdomänen eller begära nycklar från ett centraliserat team som har de behörigheter som krävs över säkerhetsdomänen. Detta är ett skifte från vägledningen för Azure Key Vault som rekommenderar att du skapar separata nyckelvalv för varje program.

Nyckelhanteringsåtgärder i Azure Key Vault Managed HSM

För att kunna utveckla verksamhetsprocesser för nyckelhantering måste kunderna avgöra om de behöver Azure Key Vault Managed HSM som en del av lösningsarkitekturen. Organisationer som planerar att använda hanterad HSM bör först bekanta sig med de åtkomstkontrollmodeller som används för både administration och kryptografiska åtgärder, och förstå hur rollbaserad åtkomstkontroll tilldelas.

Läs mer om åtkomstkontroll i hanterad HSM:

Organisationer som planerar att använda Azure Key Vault HSM bör granska listan med inbyggda RBAC-roller och tillåtna åtgärder för hanterad HSM, och specifikt planera för att hantera följande verksamhetsscenarier:

  • Skapa en ny nyckel i hanterad HSM
  • Hantering av en befintlig nyckel med hjälp av kontrollplanet, t.ex. nyckeluppdateringar eller nyckelrotation
  • Dataplananvändning av en befintlig nyckel av ett program eller en tjänst

För tillfället kan du bara tilldela behörigheter för att skapa en ny nyckel genom att tilldela en roll som exempelvis Crypto User som också innehåller andra behörigheter, till exempel nyckelrotation och nyckelborttagning. Om en programteammedlem får de behörigheter som krävs för att skapa egna nycklar i hanterade HSM kan det därför troligen innebära brott mot principer om lägsta privilegium, eftersom användaren även har administratörsbehörighet för alla nycklarna i HSM. Det här problemet kan lösas genom att introducera ett centraliserat team med utökade behörigheter som kan underlätta förfrågningar om att skapa nycklar, eller genom att införa automatisering som underlättar nya förfrågningar om att skapa nya nycklar med hjälp av IT-servicehanteringsprocesser med hanterade HSM-REST API.

Relaterat innehåll