Delen via

Versleuteling met door de klant beheerde sleutels in Microsoft Cloud for Sovereignty

  • Artikel

Klanten die van plan zijn Microsoft Cloud for Sovereignty te implementeren, hebben mogelijk gegevensversleutelingsfuncties nodig om te voldoen aan de vereisten voor de gegevenssoevereiniteit. Klanten met strikte vereisten op het gebied van gegevenssoevereiniteit moeten plannen ontwikkelen om sleutelbeheer in de cloud te implementeren. In dit artikel worden cloudarchitecten, eigenaren van cryptografische systemen en andere technische besluitvormers begeleid bij het ontwikkelen van een plan voor het implementeren van versleuteling op platformniveau in Azure. Het plannen van versleuteling op platformniveau omvat meestal het identificeren van vereisten voor sleutelbeheer, het maken van technologische keuzes en het selecteren van ontwerpen en configuratiekeuzes die door de Azure-services moeten worden gebruikt. Dit proces omvat het nemen van technische beslissingen over drie domeinen:

  • Vereisten voor sleutelbeheer definieren: wat uw organisatie moet doen om gevoelige klantgegevens en gevoelig cryptografisch materiaal te beschermen?
  • Functies voor gegevensversleuteling selecteren om klantgegevens te beschermen: hoe, waar en wanneer moet u klantgegevens in Azure versleutelen?
  • Oplossingen voor sleutelbeheer selecteren om klantensleutels te beschermen: welk sleutelarchief moet u gebruiken om gegevensversleutelingssleutels te beschermen die worden gebruikt om klantgegevens in Azure te versleutelen?

Vereisten voor sleutelbeheer definiëren

Vereisten voor sleutelbeheer kunnen technische vereisten omvatten over de cryptografische services die worden gebruikt, en operationele vereisten met betrekking tot prestaties, beveiliging en soevereiniteit. Het aanbevolen uitgangspunt voor het nemen van beslissingen over wanneer en hoe gegevens in Azure-workloads moeten worden versleuteld, is het gegevensclassificatiesysteem van een organisatie. Door de versleutelingsvereisten af ​​te stemmen op gegevensclassificaties, in plaats van op specifieke systemen of oplossingen, hebben organisaties meer flexibiliteit om het optimale niveau van versleuteling te selecteren tijdens de planning van workloadmigratie.

Het baseren van versleutelingsvereisten op gegevensclassificatie maakt ook een gelaagde aanpak mogelijk, waarbij workloads met een lagere belang kunnen profiteren van eenvoudigere oplossingen, terwijl de meest complexe configuraties worden gereserveerd voor workloads met een hoger niveau van inherent risico. Een voorbeeld van deze aanpak is het toestaan ​​van het gebruik van door Microsoft beheerde sleutels om opslagaccounts voor ontwikkelomgevingen te versleutelen, terwijl productieopslagaccounts door de klant beheerde versleutelingssleutels moeten gebruiken.

Nadat een organisatie duidelijk begrijpt hoe hun versleutelingsvereisten betrekking hebben op hun gegevensclassificaties, kunnen ze beginnen met het proces van functieselectie voor de Azure-services die ze van plan zijn te gebruiken. Sommige van deze functies kunnen anders werken dan vergelijkbare on-premises-systemen, dus organisaties worden aangemoedigd om vertrouwd te raken met de manier waarop versleuteling in Azure werkt en om aanbevelingen en best practices voor het ontwerpen van versleutelingsoplossingen te bekijken. De volgende artikelen bieden aanvullende perspectieven op enkele van de technische keuzes die klanten moeten maken, en kunnen een nuttig startpunt zijn voor het starten van een gesprek over de doelstellingen van het cloudsleutelbeheer van een organisatie.

Functies voor gegevensversleuteling selecteren

Veel Azure-services maken versleuteling mogelijk met behulp van sleutels die volledig door Azure worden gegenereerd, opgeslagen en beheerd, zonder enige interactie met de klant. Deze door het platform beheerde sleutels kunnen organisaties helpen bij het implementeren van versleuteling met weinig operationele overhead. Klanten met strikte vereisten voor gegevenssoevereiniteit moeten echter mogelijk specifieke platformversleutelingsfuncties selecteren om gevoelige gegevens te beschermen terwijl ze in rust zijn in een bepaalde Azure-service.

Voor zeer gevoelige gegevens bieden veel veelgebruikte Azure-services klanten de mogelijkheid dubbele versleuteling te implementeren met behulp van door de klant beheerde sleutels (CMK). Door de implementatie van door de klant beheerde sleutels in Azure-services kunnen klanten de gegevens die in die services zijn opgeslagen, beschermen tegen ongeautoriseerde toegang.

De implementatie van door de klant beheerde sleutels in Azure kan de kosten en complexiteit van een workload verhogen. Organisaties worden daarom aangemoedigd om de noodzaak van deze functie voor elk workload- en gegevensclassificatieniveau te evalueren. Door de implementatie van door de klant beheerde sleutels voor alleen workloads en gegevenstypen die ze nodig hebben, kunt u de operationele overhead verminderen voor workloads die geen gevoelige gegevens verwerken.

Als door de klant beheerde sleutels vereist zijn, moeten deze voor elke respectieve Azure-service worden geconfigureerd. Organisaties kunnen de implementatie- of migratieplanning helpen stroomlijnen door organisatiebrede standaarden en herhaalbare ontwerppatronen vast te stellen voor de implementatie van deze functies. De volgende artikelen bieden meer informatie over hoe de versleuteling van gegevens in rust is geconfigureerd in Azure:

Meer informatie over hoe u veelgebruikte Azure-services configureert om gegevens in rust te versleutelen met door de klant beheerde sleutels:

Sleutelbeheeroplossingen selecteren

Hoewel functies als dubbele versleuteling met door de klant beheerde sleutels kunnen helpen bij het beschermen van klantgegevens die worden onderhouden in Azure-services, helpen cloudgebaseerde oplossingen voor sleutelbeheer de versleutelingssleutels en ander cryptografisch materiaal te beschermen dat wordt gebruikt om gevoelige gegevens te versleutelen. Klanten met strikte vereisten op het gebied van gegevenssoevereiniteit moeten een geschikte oplossing voor sleutelbeheer selecteren op basis van hun zekerheidsbehoeften en het risicoprofiel van hun workload.

Workloads waarbij gevoelige gegevens worden verwerkt, kunnen profiteren van de extra zekerheid die wordt geboden door oplossingen, zoals beheerde HSM's van Azure, waaronder gevalideerde FIPS-140-2 Level-3-gecertificeerde hardwarebeveiligingsmodules die extra beveiligingscontroles bieden om opgeslagen cryptografisch materiaal te beschermen.

De volgende artikelen bieden richtlijnen die klanten kunnen gebruiken om een ​​geschikte sleutelopslag te selecteren voor hun geïdentificeerde scenario's. De artikelen bieden ook informatie over hoe Microsoft cryptografische services beheert die door klanten worden gebruikt als onderdeel van hun versleutelingsoplossing.

Operationele modellen voor sleutelbeheer

Azure Key Vault implementeert op rollen gebaseerde toegangscontrole op verschillende manieren, afhankelijk van of u het Standard- of Premium-niveau van Azure Key Vault of een beheerde HSM van Azure Key Vault gebruikt. Deze verschillen in toegangscontrole kunnen van invloed zijn op de manier waarop een organisatie deze functies gebruikt. In deze sectie worden deze verschillen beschreven en wordt beschreven hoe deze verschillen van invloed kunnen zijn op de manier waarop een organisatie verkiest haar operationele processen voor cloudsleutelbeheer te ontwerpen.

Compliance-beperkingen voor FIPS-140 Level-3-validatie

FIPS-140 Level-3-validatie vereist op identiteit gebaseerde operatoridentificatie. Deze veiligheidsvoorzieningen worden geïmplementeerd en gevalideerd in de onderliggende HSM-hardware die de Key Vault-services in Azure ondersteunt. Als gevolg hiervan zijn de RBAC-functies in Azure Key Vault afhankelijk van de RBAC-mogelijkheden van de onderliggende hardware.

Een beheerde HSM van Azure Key Vault maakt gebruik van de lokale RBAC-toewijzingen die op hardwareniveau zijn geïmplementeerd en maakt roltoewijzingen mogelijk binnen het bereik van het beveiligingsdomein (bijvoorbeeld HSM-breed) of per sleutel. Dit betekent dat voor het maken van sleutels beheerdersrechten nodig zijn voor het gehele beveiligingsdomein, omdat er geen rechten kunnen worden toegewezen voor een sleutel die nog niet bestaat. De impact van dit ontwerp is dat iedereen die een sleutel in een mHSM-instantie moet opslaan, ofwel volledige machtigingen moet hebben voor alle sleutels die in dat beveiligingsdomein zijn opgeslagen, ofwel sleutels moet aanvragen bij een gecentraliseerd team dat over de vereiste machtigingen voor het beveiligingsdomein beschikt. Dit betekent een verschuiving ten opzichte van de leidraad voor Azure Key Vault die aanbeveelt om voor elke toepassing afzonderlijke sleutelkluizen te maken.

Sleutelbeheerbewerkingen in een beheerde HSM van Azure Key Vault

Om operationele processen voor sleutelbeheer te ontwikkelen, moeten klanten bepalen of ze een beheerde HSM van Azure Key Vault nodig hebben als onderdeel van hun oplossingsarchitectuur. Organisaties die van plan zijn beheerde HSM te gaan gebruiken, moeten zich eerst verdiepen in de toegangscontrolemodellen die worden gebruikt voor zowel beheertaken als cryptografische bewerkingen en begrijpen hoe op rollen gebaseerde toegangscontrole wordt toegewezen.

Kom meer te weten over toegangscontrole in een beheerde HSM:

Organisaties die van plan zijn Azure Key Vault HSM te gebruiken, moeten de lijst met ingebouwde RBAC-rollen en toegestane bewerkingen voor een beheerde HSM bekijken en een specifiek planning maken voor de volgende bewerkingsscenario's:

  • Het creëren van een nieuwe sleutel in een beheerde HSM
  • Beheerbewerkingen van een bestaande sleutel met behulp van het controlevlak, zoals sleutelupdates of sleutelroulatie
  • Gegevensvlakgebruik van een bestaande sleutel door een toepassing of service

Momenteel is de enige manier om machtigingen toe te wijzen voor het maken van een nieuwe sleutel het toewijzen van een rol, zoals Crypto User, die ook andere machtigingen omvat, zoals de machtiging om een sleutel te laten rouleren of te verwijderen. Als gevolg hiervan is het verlenen van de benodigde machtigingen aan een lid van het toepassingsteam voor het maken van een eigen sleutel in een beheerde HSM waarschijnlijk in strijd met het beginsel dat alleen strikt noodzakelijke rechten worden toegekend, want het lid krijgt daarmee ook beheerdersmachtigingen voor alle sleutels in de HSM. Dit probleem kan worden opgelost door een gecentraliseerd team met verhoogde machtigingen te introduceren dat verzoeken om het maken van een sleutel kan faciliteren of door automatisering te introduceren die nieuwe verzoeken om het maken van een sleutel kan faciliteren via IT-servicebeheerprocessen die gebruikmaken van de REST API voor beheerde HSM's.

Gerelateerde inhoud