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 bewerkingen zonder opmaak en voert de versleuteling en ontsleuteling intern uit. De resourceprovider kan versleutelingssleutels gebruiken die worden beheerd door Microsoft of door de klant, afhankelijk van de opgegeven configuratie.
Elk van de at-rest-versleutelingsmodellen aan de serverzijde impliceert onderscheidende kenmerken van sleutelbeheer. Dit omvat waar en hoe versleutelingssleutels worden gemaakt en opgeslagen, evenals de toegangsmodellen en de procedures voor sleutelrotatie.
Houd rekening met het volgende voor versleuteling aan de clientzijde:
- 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. Met versleuteling aan de serverzijde met behulp van door de service beheerde sleutels kunnen klanten de specifieke resource (opslagaccount, SQL DB, enzovoort) markeren voor versleuteling en alle aspecten van sleutelbeheer, zoals sleuteluitgifte, rotatie en back-up naar Microsoft laten. 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. Dit betekent dat de service volledige toegang heeft tot de sleutels en dat de service volledige controle heeft 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-serverversleuteling met door de service beheerde sleutels is 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 basisresourceproviders van Azure 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 beveiligd 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
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.
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. Versleutelings-at-restsleutels 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.
Ondersteunende services
De Azure-services die elk versleutelingsmodel ondersteunen:
Product, functie of service | Serverzijde met door service beheerde sleutel | Serverzijde met door de klant beheerde sleutel | Clientzijde met door client beheerde sleutel |
---|---|---|---|
AI en Machine Learning | |||
Azure AI Search | Ja | Ja | - |
Azure AI-services | Ja | Ja, inclusief beheerde HSM | - |
Azure Machine Learning | Ja | Ja | - |
Content Moderator | Ja | Ja, inclusief beheerde HSM | - |
Face | Ja | Ja, inclusief beheerde HSM | - |
Taalbegrip | Ja | Ja, inclusief beheerde HSM | - |
Azure OpenAI | Ja | Ja, inclusief beheerde HSM | - |
Personalizer | Ja | Ja, inclusief beheerde HSM | - |
QnA Maker | Ja | Ja, inclusief beheerde HSM | - |
Spraakservices | Ja | Ja, inclusief beheerde HSM | - |
Translator Text | Ja | Ja, inclusief beheerde HSM | - |
Power Platform | Ja | Ja, inclusief beheerde HSM | - |
Dataverse | Ja | Ja, inclusief beheerde HSM | - |
Dynamics 365 | Ja | Ja, inclusief beheerde HSM | - |
Analyse | |||
Azure Stream Analytics | Ja | Ja**, inclusief beheerde HSM | - |
Event Hubs | Ja | Ja | - |
Functies | Ja | Ja | - |
Azure Analysis Services | Ja | - | - |
Azure Data Catalog | Ja | - | - |
Azure HDInsight | Ja | Ja | - |
Azure Monitor Application Insights | Ja | Ja | - |
Azure Monitor-logboekanalyse | Ja | Ja, inclusief beheerde HSM | - |
Azure Data Explorer | Ja | Ja | - |
Azure Data Factory | Ja | Ja, inclusief beheerde HSM | - |
Azure Data Lake Store | Ja | Ja, RSA 2048-bits | - |
Containers | |||
Azure Kubernetes Service | Ja | Ja, inclusief beheerde HSM | - |
Container Instances | Ja | Ja | - |
Container Registry | Ja | Ja | - |
Compute | |||
Virtual Machines | Ja | Ja, inclusief beheerde HSM | - |
Schaalset voor virtuele machines | Ja | Ja, inclusief beheerde HSM | - |
SAP HANA | Ja | Ja | - |
App Service | Ja | Ja**, inclusief beheerde HSM | - |
Automation | Ja | Ja | - |
Azure Functions | Ja | Ja**, inclusief beheerde HSM | - |
Azure Portal | Ja | Ja**, inclusief beheerde HSM | - |
Azure VMware Solution | Ja | Ja, inclusief beheerde HSM | - |
Logic Apps | Ja | Ja | - |
Door Azure beheerde toepassingen | Ja | Ja**, inclusief beheerde HSM | - |
Service Bus | Ja | Ja | - |
Siteherstel | Ja | Ja | - |
Databases | |||
SQL Server on Virtual Machines | Ja | Ja | Ja |
Azure SQL-database | Ja | Ja, RSA 3072-bits, inclusief beheerde HSM | Ja |
Azure SQL Managed Instance | Ja | Ja, RSA 3072-bits, inclusief beheerde HSM | Ja |
Azure SQL Database for MariaDB | Ja | - | - |
Azure SQL Database for MySQL | Ja | Ja, inclusief beheerde HSM | - |
Azure SQL Database for PostgreSQL | Ja | Ja, inclusief beheerde HSM | - |
Azure Synapse Analytics (alleen toegewezen SQL-pool (voorheen SQL DW) | Ja | Ja, RSA 3072-bits, inclusief beheerde HSM | - |
SQL Server Stretch Database | Ja | Ja, RSA 3072-bits | Ja |
Table Storage | Ja | Ja | Ja |
Azure Cosmos DB | Ja (meer informatie) | Ja, inclusief beheerde HSM (meer informatie en meer informatie) | - |
Azure Databricks | Ja | Ja, inclusief beheerde HSM | - |
Azure Database Migration-service | Ja | N.v.t.* | - |
Identiteit | |||
Microsoft Entra ID | Ja | - | - |
Microsoft Entra Domain Services. | Ja | Ja | - |
Integratie | |||
Service Bus | Ja | Ja | - |
Event Grid | Ja | - | - |
API Management | Ja | - | - |
IoT-services | |||
IoT Hub | Ja | Ja | Ja |
IoT Hub Device Provisioning | Ja | Ja | - |
Beheer en governance | |||
Azure Managed Grafana | Ja | - | N.v.t. |
Azure Site Recovery | Ja | - | - |
Azure Migrate | Ja | Ja | - |
Media | |||
Media Services | Ja | Ja | Ja |
Beveiliging | |||
Microsoft Defender for IoT | Ja | Ja | - |
Microsoft Sentinel | Ja | Ja, inclusief beheerde HSM | - |
Storage | |||
Blob Storage | Ja | Ja, inclusief beheerde HSM | Ja |
Premium Blob Storage | Ja | Ja, inclusief beheerde HSM | Ja |
Disk Storage | Ja | Ja, inclusief beheerde HSM | - |
Ultra Disk Storage | Ja | Ja, inclusief beheerde HSM | - |
Beheerde schijfopslag | Ja | Ja, inclusief beheerde HSM | - |
File Storage | Ja | Ja, inclusief beheerde HSM | - |
File Premium Storage | Ja | Ja, inclusief beheerde HSM | - |
File Sync | Ja | Ja, inclusief beheerde HSM | - |
Queue Storage | Ja | Ja, inclusief beheerde HSM | Ja |
Data Lake Storage Gen2 | Ja | Ja, inclusief beheerde HSM | Ja |
Avere vFXT | Ja | - | - |
Azure Cache voor Redis | Ja | Ja**, inclusief beheerde HSM | - |
Azure NetApp Files | Ja | Ja, inclusief beheerde HSM | Ja |
Archive Storage | Ja | Ja | - |
StorSimple | Ja | Ja | Ja |
Azure Backup | Ja | Ja, inclusief beheerde HSM | Ja |
Data Box | Ja | - | Ja |
Azure Stack Edge | Ja | Ja | - |
Overig | |||
Azure Data Manager for Energy | Ja | Ja | Ja |
* Deze service bewaart geen gegevens. Tijdelijke caches, indien aanwezig, worden versleuteld met een Microsoft-sleutel.
** Deze service ondersteunt het opslaan van gegevens in uw eigen Key Vault, opslagaccount of andere gegevens die al ondersteuning bieden voor versleuteling aan de serverzijde met door de klant beheerde sleutel.
Tijdelijke gegevens die tijdelijk zijn opgeslagen op schijf, zoals paginabestanden of wisselbestanden, worden versleuteld met een Microsoft-sleutel (alle lagen) of een door de klant beheerde sleutel (met behulp van de Enterprise- en Enterprise Flash-lagen). Zie Schijfversleuteling configureren in Azure Cache voor Redis voor meer informatie.