Gegevensversleutelingmodellen
Een goed begrip van de verschillende versleutelingsmodellen en hun voor- en nadelen is essentieel om te begrijpen hoe de verschillende resourceproviders in Azure versleuteling at rest implementeren. Deze definities worden gedeeld door alle resourceproviders in Azure om een gemeenschappelijke taal en taxonomie te garanderen.
Er zijn drie scenario's voor versleuteling aan de serverzijde:
Versleuteling aan de serverzijde met door de service beheerde sleutels
- Azure Resource Providers voeren de versleutelings- en ontsleutelingsbewerkingen uit
- Microsoft beheert de sleutels
- Volledige cloudfunctionaliteit
Versleuteling aan de serverzijde met door de klant beheerde sleutels in Azure Key Vault
- Azure Resource Providers voeren de versleutelings- en ontsleutelingsbewerkingen uit
- Sleutels van klanten beheren via Azure Key Vault
- Volledige cloudfunctionaliteit
Versleuteling aan de serverzijde met door de klant beheerde sleutels op door de klant beheerde hardware
- Azure Resource Providers voeren de versleutelings- en ontsleutelingsbewerkingen uit
- Klant beheert sleutels op door de klant beheerde hardware
- Volledige cloudfunctionaliteit
Versleutelingsmodellen aan de serverzijde verwijzen naar versleuteling die wordt uitgevoerd door de Azure-service. In dat model voert de resourceprovider de versleutelings- en ontsleutelingsbewerkingen uit. Azure Storage kan bijvoorbeeld gegevens ontvangen in tekst zonder opmaak en de versleuteling en ontsleuteling intern uitvoeren. De resourceprovider kan versleutelingssleutels gebruiken die worden beheerd door Microsoft of door de klant, afhankelijk van de opgegeven configuratie.
Elk van de versleuteling-at-rest-modellen aan de serverzijde impliceert onderscheidende kenmerken van sleutelbeheer, waaronder waar en hoe versleutelingssleutels worden gemaakt en opgeslagen, evenals de toegangsmodellen en de procedures voor sleutelrotatie.
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). Sleutels zijn niet beschikbaar voor Azure-services
- Verminderde cloudfunctionaliteit
De ondersteunde versleutelingsmodellen in Azure zijn gesplitst in twee hoofdgroepen: 'Clientversleuteling' en 'Versleuteling aan serverzijde', zoals eerder vermeld. Onafhankelijk van het gebruikte versleutelings-at-rest-model, raden Azure-services altijd het gebruik van een beveiligd transport aan, zoals TLS of HTTPS. Versleuteling in transport moet daarom worden aangepakt door het transportprotocol en mag geen belangrijke factor zijn bij het bepalen van welk versleuteling-at-rest-model moet worden gebruikt.
Clientversleutelingsmodel
Het clientversleutelingsmodel verwijst naar versleuteling die buiten de resourceprovider of Azure wordt uitgevoerd door de service of aanroepende toepassing. De versleuteling kan worden uitgevoerd door de servicetoepassing in Azure of door een toepassing die wordt uitgevoerd in het datacenter van de klant. In beide gevallen ontvangt de Azure-resourceprovider bij het gebruik van dit versleutelingsmodel een versleutelde blob met gegevens zonder de mogelijkheid om de gegevens op welke manier dan ook te ontsleutelen of toegang te hebben tot de versleutelingssleutels. In dit model wordt het sleutelbeheer uitgevoerd door de aanroepende service/toepassing en is ondoorzichtig voor de Azure-service.
Versleuteling aan de serverzijde met door de service beheerde sleutels
Voor veel 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 de service beheerde sleutels maakt dit model mogelijk doordat klanten de specifieke resource (opslagaccount, SQL DB, enzovoort) kunnen markeren voor versleuteling en alle aspecten van sleutelbeheer, zoals sleuteluitgifte, rotatie en back-ups naar Microsoft kunnen maken. De meeste Azure-services die ondersteuning bieden voor versleuteling in rust ondersteunen doorgaans dit model voor het offloaden van het beheer van de versleutelingssleutels naar Azure. 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 de service heeft volledige controle over het levenscyclusbeheer van referenties.
Versleuteling aan de serverzijde met behulp van door de service beheerde sleutels biedt daarom snel een oplossing voor de noodzaak van versleuteling in rust met een lage overhead voor de klant. Wanneer een klant beschikbaar is, wordt de Azure-portal doorgaans geopend voor het doelabonnement en de resourceprovider en wordt een selectievakje ingeschakeld dat aangeeft dat de gegevens moeten worden versleuteld. In sommige Resource Managers is versleuteling aan de serverzijde met door de service beheerde sleutels standaard ingeschakeld.
Versleuteling aan de serverzijde met door Microsoft 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, moeten de kosten en het risico dat is gekoppeld aan een aangepaste sleutelopslagoplossing worden overwogen 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 versleuteling-at-restsleutels. 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 versleuteling aan de serverzijde met door de service beheerde sleutels wordt gebruikt, worden de toegang tot sleutels, opslag en service allemaal beheerd door de service. Normaal gesproken slaan de fundamentele Azure-resourceproviders de gegevensversleutelingssleutels op in een archief dat zich dicht bij de gegevens bevindt en snel beschikbaar en toegankelijk is terwijl de sleutelversleutelingssleutels worden opgeslagen in een veilig intern archief.
Voordelen
- Eenvoudige instellingen
- Microsoft beheert sleutelrotatie, back-up en redundantie
- De klant heeft niet de kosten die zijn gekoppeld aan de implementatie of het risico van een aangepast sleutelbeheerschema.
Nadelen
- Geen klantcontrole over de versleutelingssleutels (sleutelspecificatie, levenscyclus, intrekking, enzovoort)
- Geen mogelijkheid om sleutelbeheer te scheiden van het algemene beheermodel voor de service
Versleuteling aan de serverzijde met door de klant beheerde sleutels in Azure Key Vault en Azure Managed HSM
Voor scenario's waarbij de vereiste is om de data-at-rest te versleutelen en de versleutelingssleutels te beheren, kunnen klanten versleuteling aan de serverzijde gebruiken met behulp van door de klant beheerde sleutels in Key Vault. 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 dat 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 gebruikt als de hoofdsleutel voor alle versleutelingsbewerkingen.
Verlies van sleutelversleutelingssleutels betekent verlies van gegevens. Daarom mogen sleutels niet worden verwijderd. Er moet een back-up van sleutels worden gemaakt wanneer deze worden gemaakt of gedraaid. Beveiliging tegen voorlopig verwijderen en opschonen moet zijn ingeschakeld voor elke kluis die sleutelversleutelingssleutels opslaat om te beschermen tegen onbedoelde of schadelijke cryptografische verwijdering. In plaats van een sleutel te verwijderen, is het raadzaam om ingeschakeld in te stellen op onwaar op de sleutelversleutelingssleutel. Gebruik toegangsbeheer om de toegang tot afzonderlijke gebruikers of services in te trekken in Azure Key Vault of beheerde HSM.
Notitie
Zie Services die CMK's ondersteunen in Azure Key Vault en Azure Managed HSM voor een lijst met services die door de klant beheerde sleutels ondersteunen in Azure Key Vault en Azure Managed 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. Versleuteling-at-rest-sleutels worden toegankelijk gemaakt voor een service via een toegangsbeheerbeleid. Dit beleid verleent de service-id toegang om de sleutel te ontvangen. Een Azure-service die wordt uitgevoerd namens een gekoppeld abonnement, kan worden geconfigureerd 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. Dit token kan vervolgens aan Key Vault worden gepresenteerd om een sleutel te verkrijgen waartoe het toegang heeft gekregen.
Voor bewerkingen met behulp van versleutelingssleutels kan een service-id toegang krijgen tot een van de volgende bewerkingen: ontsleutelen, versleutelen, uitpakken, wrapKey, verifiëren, ondertekenen, ophalen, weergeven, bijwerken, maken, importeren, verwijderen, back-up en herstel.
Als u een sleutel wilt verkrijgen voor gebruik bij het versleutelen of ontsleutelen van gegevens in rust, moet de service-id die door het Resource Manager-service-exemplaar wordt uitgevoerd, beschikken over UnwrapKey (om de sleutel voor ontsleuteling op te halen) en WrapKey (om een sleutel in te voegen in de sleutelkluis bij het maken van een nieuwe sleutel).
Notitie
Zie de pagina voor uw sleutelkluis beveiligen in de documentatie van Azure Key Vault voor meer informatie over Key Vault-autorisatie.
Voordelen
- Volledige controle over de gebruikte sleutels: versleutelingssleutels worden beheerd in de Key Vault van de klant onder het beheer van de klant.
- 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
- Klant heeft volledige verantwoordelijkheid voor sleuteltoegangsbeheer
- Klant heeft volledige verantwoordelijkheid voor sleutellevenscyclusbeheer
- Extra overhead voor setup en configuratie
Versleuteling aan de serverzijde met door de klant beheerde sleutels in door de klant beheerde hardware
Sommige Azure-services maken het HYOK-sleutelbeheermodel (Host Your Own Key) mogelijk. Deze beheermodus is handig in scenario's waarin de data-at-rest moeten worden versleuteld en de sleutels moeten worden beheerd in een eigen opslagplaats buiten het beheer van Microsoft. 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 complexer. Omdat de service tijdens de versleutelings- en ontsleutelingsbewerkingen wel toegang heeft tot de DEK, zijn de algemene beveiligingsgaranties van dit model vergelijkbaar met wanneer de sleutels door de klant worden beheerd in Azure Key Vault. Als gevolg hiervan is dit model niet geschikt voor de meeste organisaties, tenzij ze specifieke vereisten voor sleutelbeheer hebben. 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 versleuteling aan de serverzijde wordt gebruikt met door de klant beheerde sleutels in door de klant beheerde hardware, worden de sleutelversleutelingssleutels onderhouden op een systeem dat door de klant is geconfigureerd. Azure-services die ondersteuning bieden voor dit model, bieden een manier om een beveiligde verbinding tot stand te brengen met een door de klant geleverde sleutelarchief.
Voordelen
- Volledige controle over de gebruikte hoofdsleutel: versleutelingssleutels worden beheerd door een door de klant geleverde winkel
- 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
- Volledige verantwoordelijkheid voor sleutelopslag, beveiliging, prestaties en beschikbaarheid
- Volledige verantwoordelijkheid voor sleuteltoegangsbeheer
- Volledige verantwoordelijkheid voor sleutellevenscyclusbeheer
- Aanzienlijke installatie-, configuratie- en doorlopende onderhoudskosten
- Verhoogde afhankelijkheid van netwerkbeschikbaarheid tussen het datacenter van de klant en Azure-datacenters.