Gegevensversleutelingmodellen

Als u wilt weten hoe Azure-resourceproviders versleuteling in rust implementeren, moet u de verschillende versleutelingsmodellen en hun voor- en nadelen begrijpen. Om een gemeenschappelijke taal en taxonomie te garanderen, delen Azure-resourceproviders deze definities.

Azure versleutelt gegevens in rust standaard automatisch met behulp van door het platform beheerde sleutels. U kunt desgewenst andere methoden voor sleutelbeheer kiezen op basis van uw beveiligings- en nalevingsvereisten. Er bestaan drie scenario's voor versleuteling aan de serverzijde:

• Versleuteling aan de serverzijde met behulp van door platform beheerde sleutels (standaard)

  • Azure-resourceproviders voeren de versleutelings- en ontsleutelingsbewerkingen uit.
  • Microsoft beheert de sleutels automatisch.
  • Standaard ingeschakeld zonder configuratie vereist.
  • Volledige cloudfunctionaliteit.

• Versleuteling aan de serverzijde met door de klant beheerde sleutels in Azure Key Vault (optioneel)

  • Azure-resourceproviders voeren de versleutelings- en ontsleutelingsbewerkingen uit.
  • U kunt sleutels beheren via Azure Key Vault.
  • Vereist klantconfiguratie en -beheer.
  • Volledige cloudfunctionaliteit.

• Versleuteling aan de serverzijde met door de klant beheerde sleutels op door de klant beheerde hardware (geavanceerde optie)

  • Azure-resourceproviders voeren de versleutelings- en ontsleutelingsbewerkingen uit.
  • U beheert versleutelingssleutels op door de klant beheerde hardware.
  • Complexe configuratie en beperkte ondersteuning voor Azure-services.
  • Volledige cloudfunctionaliteit.

Versleutelingsmodellen aan de serverzijde verwijzen naar versleuteling die door de Azure-service wordt uitgevoerd. In dat model voert de resourceprovider de bewerkingen voor versleutelen en ontsleutelen uit. Azure Storage kan bijvoorbeeld gegevens ontvangen in tekst zonder opmaak en de versleuteling en ontsleuteling intern uitvoeren. De resourceprovider kan versleutelingssleutels gebruiken die Door Microsoft of de klant worden beheerd, afhankelijk van de opgegeven configuratie.

Elk server-side model voor versleuteling in rust heeft onderscheidende kenmerken van sleutelbeheer. Deze kenmerken omvatten waar en hoe u versleutelingssleutels maakt en opslaat, evenals de toegangsmodellen en de sleutelrotatieprocedures.

Voor versleuteling aan de clientzijde kunt u het volgende overwegen:

• Azure-services kunnen ontsleutelde gegevens niet zien.
• Klanten beheren en bewaren sleutels on-premises (of in andere beveiligde winkels). Azure-services hebben geen toegang tot sleutels.
• Verminderde cloudfunctionaliteit.

De ondersteunde versleutelingsmodellen in Azure zijn onderverdeeld in twee hoofdgroepen: Clientversleuteling en Versleuteling aan de serverzijde. Ongeacht het versleutelings-at-rest-model dat u gebruikt, raden Azure-services altijd het gebruik van een beveiligd transport aan, zoals TLS of HTTPS. Versleuteling tijdens transport moet daarom door het transportprotocol worden afgehandeld en mag geen belangrijke factor zijn bij het bepalen welk versleutelingsmodel voor opgeslagen gegevens moet worden gebruikt.

Clientversleutelingsmodel

Het clientversleutelingsmodel verwijst naar versleuteling die door de service of aanroepende toepassing buiten de resourceprovider of Azure wordt uitgevoerd. De servicetoepassing in Azure of een toepassing die wordt uitgevoerd in het datacenter van de klant, kan de versleuteling uitvoeren. In beide gevallen ontvangt de Azure-resourceprovider, wanneer u dit versleutelingsmodel gebruikt, een versleutelde blob met gegevens zonder de mogelijkheid om de gegevens op welke manier dan ook te ontsleutelen of toegang te krijgen tot de versleutelingssleutels. In dit model verwerkt de aanroepende service of toepassing sleutelbeheer en blijft deze ondoorzichtig voor de Azure-service.

Versleuteling aan de serverzijde met behulp van door platform beheerde sleutels (standaard)

Voor de meeste klanten is het essentieel om ervoor te zorgen dat de gegevens worden versleuteld wanneer ze in rust zijn. Versleuteling aan de serverzijde met behulp van door platform beheerde sleutels (voorheen door de service beheerde sleutels genoemd) voldoet aan deze vereiste door standaard automatische versleuteling te bieden. Deze benadering maakt versleuteling in rust mogelijk zonder dat klanten versleutelingssleutels hoeven te configureren of beheren, waardoor alle aspecten van sleutelbeheer, zoals sleuteluitgifte, rotatie en back-up naar Microsoft, worden overgelaten.

De meeste Azure-services implementeren dit model als het standaardgedrag, waarbij gegevens-at-rest automatisch worden versleuteld met behulp van door het platform beheerde sleutels, zonder dat hiervoor actie van de klant is vereist. De Azure-resourceprovider maakt de sleutels, plaatst deze in beveiligde opslag en haalt deze op wanneer dat nodig is. De service heeft volledige toegang tot de sleutels en houdt volledige controle over het levenscyclusbeheer van referenties en biedt robuuste versleutelingsbeveiliging met geen beheeroverhead voor klanten.

Versleuteling aan de serverzijde met behulp van door platform beheerde sleutels heeft betrekking op de noodzaak van versleuteling in rust met nul overhead voor de klant. Deze versleuteling is standaard ingeschakeld in Azure-services, waardoor automatische gegevensbeveiliging wordt geboden zonder dat er klantconfiguratie of -beheer nodig is. Klanten profiteren direct van robuuste versleutelingsbeveiliging bij het opslaan van gegevens in Azure-services, zonder extra stappen, kosten of doorlopend beheer.

Versleuteling aan de serverzijde met door platform beheerde sleutels impliceert dat de service volledige toegang heeft tot het opslaan en beheren van de sleutels. Hoewel sommige klanten de sleutels mogelijk willen beheren omdat ze meer beveiliging krijgen, moet u rekening houden met de kosten en het risico dat is gekoppeld aan een aangepaste sleutelopslagoplossing bij het evalueren van dit model. In veel gevallen kan een organisatie bepalen dat resourcebeperkingen of risico's van een on-premises oplossing groter zijn dan het risico van cloudbeheer van de encryptiesleutels voor gegevens in rust. Dit model is echter mogelijk niet voldoende voor organisaties die vereisten hebben om het maken of de levenscyclus van de versleutelingssleutels te beheren of om verschillende medewerkers de versleutelingssleutels van een service te laten beheren dan die die de service beheren (dat wil gezegd, scheiding van sleutelbeheer van het algemene beheermodel voor de service).

Sleuteltoegang

Wanneer u versleuteling aan de serverzijde gebruikt met door het platform beheerde sleutels, beheert de service het maken van sleutels, opslag en servicetoegang. Normaal gesproken slaan de fundamentele Azure-resourceproviders de gegevensversleutelingssleutels op in een archief dat zich dicht bij de gegevens bevindt en snel toegankelijk is, terwijl de sleutelversleutelingssleutels worden opgeslagen in een beveiligd intern archief.

Voordelen

• Eenvoudige installatie.
• Microsoft beheert sleutelrotatie, back-up en redundantie.
• U maakt geen kosten of risico's met betrekking tot het implementeren van een aangepast sleutelbeheerschema.

Overwegingen

• Geen klantcontrole over de versleutelingssleutels (sleutelspecificatie, levenscyclus, intrekking, enzovoort). Deze optie is geschikt voor de meeste gebruiksvoorbeelden, maar voldoet mogelijk niet aan gespecialiseerde nalevingsvereisten.
• Geen mogelijkheid om sleutelbeheer te scheiden van het algehele beheermodel voor de service. Organisaties die scheiding van taken vereisen, hebben mogelijk door de klant beheerde sleutels nodig.

Versleuteling aan de serverzijde met door de klant beheerde sleutels in Azure Key Vault en Azure Managed HSM (optioneel)

Voor scenario's waarin organisaties specifieke vereisten hebben om hun versleutelingssleutels te beheren buiten de standaard door het platform beheerde versleuteling, kunnen klanten optioneel versleuteling aan de serverzijde kiezen met behulp van door de klant beheerde sleutels in Key Vault of Azure Managed HSM. Deze benadering bouwt voort op de standaardversleuteling-at-rest, zodat klanten hun eigen sleutels kunnen gebruiken terwijl Azure de versleutelings- en ontsleutelingsbewerkingen blijft verwerken.

Sommige services slaan mogelijk alleen de hoofdsleutelversleutelingssleutel op in Azure Key Vault en slaan de versleutelde gegevensversleutelingssleutel op een interne locatie dichter bij de gegevens op. In dit scenario kunnen klanten hun eigen sleutels meenemen naar Key Vault (BYOK – Bring Your Own Key) of nieuwe sleutels genereren en deze gebruiken om de gewenste resources te versleutelen. Hoewel de resourceprovider de versleutelings- en ontsleutelingsbewerkingen uitvoert, wordt de geconfigureerde sleutelversleutelingssleutel van de klant gebruikt als de hoofdsleutel voor alle versleutelingsbewerkingen.

Verlies van sleutelversleutelingssleutels betekent verlies van gegevens. Verwijder daarom geen sleutels. Maak altijd een back-up van sleutels wanneer u ze maakt of roteert. Ter bescherming tegen onbedoelde of kwaadwillende cryptografische verwijdering moet Soft-Delete- en opschoningsbeveiliging zijn ingeschakeld voor elke kluis die sleutelversleutelingssleutels opslaat. In plaats van een sleutel te verwijderen, stel ingeschakeld in op onwaar voor de sleutel voor versleuteling. Gebruik toegangsbeheer om de toegang tot afzonderlijke gebruikers of services in te trekken in Azure Key Vault of beheerde HSM.

Sleuteltoegang

Het versleutelingsmodel aan de serverzijde met door de klant beheerde sleutels in Azure Key Vault omvat de service die toegang heeft tot de sleutels om naar behoefte te versleutelen en ontsleutelen. U maakt versleutelde rustsleutels toegankelijk voor een service via een toegangscontrolebeleid. Dit beleid verleent de service-id toegang om de sleutel te ontvangen. U kunt een Azure-service configureren die wordt uitgevoerd namens een gekoppeld abonnement met een identiteit in dat abonnement. De service kan Microsoft Entra-verificatie uitvoeren en een verificatietoken ontvangen dat zichzelf identificeert als die service die namens het abonnement handelt. De service presenteert vervolgens het token aan Key Vault om een sleutel te verkrijgen waartoe het toegang heeft gekregen.

Voor bewerkingen met behulp van versleutelingssleutels kunt u een service-identiteit toegang verlenen tot een van de volgende bewerkingen: ontsleutelen, versleutelen, sleutelontpakken, sleutelverpakken, verifiëren, ondertekenen, ophalen, weergeven, bijwerken, maken, importeren, verwijderen, backuppen en herstellen.

Als u een sleutel wilt verkrijgen voor gebruik bij het versleutelen of ontsleutelen van data-at-rest, moet de service-identiteit die door de Resource Manager-service-instantie wordt gebruikt beschikken over UnwrapKey (om de sleutel voor ontsleuteling op te halen) en WrapKey (om een sleutel toe te voegen aan de sleutelkluis bij het maken van een nieuwe sleutel).

Voordelen

• Volledige controle over de gebruikte sleutels: versleutelingssleutels worden beheerd in uw Key Vault onder uw beheer.
• Mogelijkheid om meerdere services te versleutelen naar één master.
• Kan sleutelbeheer scheiden van het algemene beheermodel voor de service.
• Kan service- en sleutellocatie definiëren tussen regio's.

Nadelen

• U hebt volledige verantwoordelijkheid voor sleuteltoegangsbeheer.
• U hebt volledige verantwoordelijkheid voor sleutellevenscyclusbeheer.
• Extra installatie- en configuratie-overhead.

Versleuteling aan de serverzijde met door de klant beheerde sleutels in door de klant beheerde hardware (gespecialiseerde optie)

Sommige Azure-services maken het HYOK-sleutelbeheermodel (Host Your Own Key) mogelijk voor organisaties met gespecialiseerde beveiligingsvereisten. Deze beheermodus is handig in sterk gereglementeerde scenario's waarbij er een vereiste is om de data-at-rest te versleutelen en de sleutels in een eigen opslagplaats volledig buiten de controle van Microsoft te beheren, naast de standaard door het platform beheerde versleuteling en optionele door de klant beheerde sleutels in Azure Key Vault.

In dit model moet de service de sleutel van een externe site gebruiken om de DATA Encryption Key (DEK) te ontsleutelen. Prestatie- en beschikbaarheidsgaranties worden beïnvloed en configuratie is aanzienlijk complexer. Omdat de service geen toegang heeft tot de DEK tijdens de versleutelings- en ontsleutelingsbewerkingen, zijn de algemene beveiligingsgaranties van dit model vergelijkbaar met wanneer de sleutels door de klant worden beheerd in Azure Key Vault. Dit model is daarom niet geschikt voor de meeste organisaties, tenzij ze zeer specifieke wettelijke of beveiligingsvereisten hebben die niet kunnen worden voldaan aan door het platform beheerde sleutels of door de klant beheerde sleutels in Azure Key Vault. Vanwege deze beperkingen bieden de meeste Azure-services geen ondersteuning voor versleuteling aan de serverzijde met behulp van door de klant beheerde sleutels in door de klant beheerde hardware. Een van de twee sleutels in Dubbele sleutelversleuteling volgt dit model.

Sleuteltoegang

Wanneer u versleuteling aan de serverzijde gebruikt met door de klant beheerde sleutels in door de klant beheerde hardware, onderhoudt u de sleutelversleutelingssleutels op een systeem dat u configureert. Azure-services die dit model ondersteunen, bieden een manier om een beveiligde verbinding tot stand te brengen met een door de klant geleverde sleutelarchief.

Voordelen

• U hebt volledige controle over de rootsleutel die wordt gebruikt, omdat de versleutelingssleutels worden beheerd door een klantbeheerde opslag.
• Mogelijkheid om meerdere services te versleutelen naar één master.
• Kan sleutelbeheer scheiden van het algemene beheermodel voor de service.
• Kan service- en sleutellocatie definiëren tussen regio's.

Nadelen

• U hebt volledige verantwoordelijkheid voor sleutelopslag, beveiliging, prestaties en beschikbaarheid.
• U hebt volledige verantwoordelijkheid voor sleuteltoegangsbeheer.
• U hebt volledige verantwoordelijkheid voor sleutellevenscyclusbeheer.
• Er worden aanzienlijke installatie-, configuratie- en doorlopende onderhoudskosten in rekening gebracht.
• Er is meer afhankelijkheid van netwerkbeschikbaarheid tussen het datacenter van de klant en Azure-datacenters.

Gerelateerde inhoud

• Services die CMK's ondersteunen in Azure Key Vault en Azure Managed HSM
• Hoe versleuteling wordt gebruikt in Azure
• Dubbele versleuteling