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. Server-sideversleuteling omvat drie scenario's:

• Server-side encryptie door gebruik te maken van door het platform beheerde sleutels (standaard).

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

• Server-side encryptie door gebruik te maken van door klanten beheerde sleutels in Azure Key Vault (optioneel).

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

• Server-side encryptie door gebruik te maken van door de klant beheerde sleutels op door de klant gecontroleerde 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 encryptiesleutels gebruiken die Microsoft of de klant beheert, afhankelijk van je 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 encryptiemodellen in Azure zijn opgesplitst in twee hoofdgroepen: clientversleuteling en server-side encryptie. Ongeacht het versleutelings-at-rest-model dat u gebruikt, raden Azure-services altijd het gebruik van een beveiligd transport aan, zoals TLS of HTTPS. Daarom wordt adresversleuteling tijdens transport via het transportprotocol gebruikt. Het zou geen grote factor moeten zijn bij het bepalen welk encryptiemodel in rust wordt gebruikt.

Clientversleutelingsmodel

Het clientencryptiemodel verwijst naar de versleuteling die de service of aanroepende applicatie buiten de resource provider of Azure uitvoert. 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 resource provider bij gebruik van dit encryptiemodel een versleutelde datablob zonder de mogelijkheid om de data op enigerlei wijze te ontsleutelen of toegang te krijgen tot de encryptiesleutels. In dit model verwerkt de aanroepende service of toepassing sleutelbeheer en blijft deze ondoorzichtig voor de Azure-service.

Server-side encryptie door platformbeheerde sleutels te gebruiken (standaard)

Voor de meeste organisaties is de essentiële vereiste dat data versleuteld wordt wanneer deze in rust is. Server-side encryptie door gebruik te maken van platformbeheerde sleutels (voorheen service-managed keys genoemd) voldoet aan deze eis door standaard automatische encryptie te bieden. Deze aanpak maakt encryptie in rust mogelijk zonder dat je encryptiesleutels hoeft te configureren of beheren. Microsoft verzorgt sleutelbeheertaken zoals sleuteluitgifte, rotatie en back-up.

De meeste Azure-diensten implementeren dit model als standaardgedrag, waarbij data in rust automatisch wordt versleuteld door platformbeheerde sleutels te gebruiken zonder dat er klantactie nodig is. De Azure-resourceprovider maakt de sleutels, plaatst deze in beveiligde opslag en haalt deze op wanneer dat nodig is. De dienst heeft volledige toegang tot de sleutels en behoudt volledige controle over het beheer van de levenscyclus van de inloggegevens. Deze controle biedt sterke encryptiebescherming zonder beheersbelasting.

Serverversleuteling met behulp van door het platform beheerde sleutels voorziet in de behoefte aan versleuteling van gegevens in rust, zonder extra overhead. Azure maakt deze encryptie standaard mogelijk in alle Azure-diensten, waardoor automatische gegevensbescherming wordt geboden zonder enige configuratie of beheer. Je profiteert direct van sterke encryptiebescherming zodra je data opslaat in Azure-diensten, zonder extra stappen, kosten of doorlopend beheer.

Server-side encryptie door gebruik te maken van platformbeheerde sleutels betekent dat de dienst volledige toegang heeft om de sleutels op te slaan en te beheren. Hoewel sommige organisaties de sleutels willen beheren omdat ze meer veiligheid verwachten, moet men bij het evalueren van dit model rekening houden met de kosten en risico's van een op maat gemaakte sleutelopslagoplossing. 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 eisen hebben om de creatie of levenscyclus van de encryptiesleutels te beheren of om ander personeel te laten beheren dan degenen die de dienst beheren (afscheiding van sleutelbeheer van het algemene beheermodel voor de dienst).

Sleuteltoegang

Wanneer je server-side encryptie gebruikt met platformbeheerde sleutels, verzorgt de service het aanmaken van sleutels, opslag en service-toegang. Doorgaans slaan de fundamentele Azure-resourceproviders data-encryptiesleutels op in een opslag die dicht bij de data ligt en snel toegankelijk is, terwijl sleutelencryptiesleutels zich in een beveiligde interne opslag bevinden.

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 controle over de encryptiesleutels (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.

Server-side encryptie door gebruik te maken van klantbeheerde sleutels in Azure Key Vault en Azure Key Vault Managed HSM (optioneel)

Voor scenario's waarin organisaties specifieke eisen hebben om hun encryptiesleutels te beheren buiten de standaard platformbeheerde encryptie, kun je optioneel server-side encryptie kiezen door klantbeheerde sleutels te gebruiken in Key Vault of Azure Key Vault Managed HSM. Deze aanpak bouwt voort op de standaardencryptie in rust, waardoor je je eigen sleutels kunt gebruiken terwijl Azure de encryptie- en ontsleutelingsoperaties blijft uitvoeren.

Sommige diensten slaan alleen de root key encryptiesleutel (KEK) op in Azure Key Vault en slaan de versleutelde data-encryptiesleutel (DEK) op op een interne locatie dichter bij de data. In dit scenario kun je het bring your own key (BYOK)-model gebruiken om sleutels te importeren in Key Vault of nieuwe sleutels te genereren in Key Vault, en deze vervolgens gebruiken om de gewenste bronnen te versleutelen. Terwijl de resource provider de encryptie- en ontsleutelingsoperaties uitvoert, gebruikt hij je geconfigureerde KEK als rootkey voor alle encryptiebewerkingen.

Verlies van sleutelversleutelingssleutels betekent verlies van gegevens. Verwijder daarom geen sleutels. Maak altijd een back-up van sleutels wanneer u ze maakt of roteert. Wanneer een KEK wordt geroteerd, omhult de service de gegevensversleutelingssleutels met de nieuwe sleutelversie - de onderliggende gegevens worden niet opnieuw versleuteld. Zowel oude als nieuwe sleutelversies moeten ingeschakeld blijven totdat alle data-encryptiesleutels zijn verpakt met de nieuwe sleutelversie. Ter bescherming tegen onbedoeld of kwaadwillig cryptografisch wissen moeten Soft-delete en opschoonbeveiliging zijn ingeschakeld voor elke kluis waarin sleutelversleutelingssleutels worden opgeslagen. 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.

Warning

Als je vermoedt dat een sleutel is gecompromitteerd, schakel deze dan niet direct uit of verwijder hem. Het uitschakelen of verwijderen van een sleutel haalt alle afhankelijke diensten offline, maar het maakt geen kopieën van de sleutel ongeldig die zijn geback-upt en hersteld naar een andere kluis. Deze kopieën blijven volledig functioneel. Schakel in plaats daarvan over naar een nieuwe sleutel en migreer alle afhankelijke services voordat u de gecompromitteerde sleutel uitschakelt. Zie De beveiligingsoverwegingen voor back-ups en het reageren op belangrijke inbreuk voor de volledige procedure voor incidenten.

Voor klantbeheerde sleutelscenario's gebruik Azure Key Vault Premium tier (HSM-ondersteund) als minimum voor compliance-eisen die HSM-beschermde sleutels verplicht stellen. Gebruik Azure Key Vault Managed HSM voor workloads die soevereiniteit van sleutels of toegewezen HSM-capaciteit vereisen. Voor organisaties die wettelijke of contractuele vereisten hebben die vereisen dat sleutelmateriaal fysiek buiten de Microsoft-infrastructuur moet worden geplaatst, ondersteunt Azure Key Vault Managed HSM ook extern sleutelbeheer (preview), waardoor de KEK volledig buiten Azure wordt beheerd in een door klanten beheerde HSM.

Notitie

Voor een lijst van diensten die klantbeheerde sleutels ondersteunen in Azure Key Vault en Azure Key Vault Managed HSM, zie Services die CMK's ondersteunen in Azure Key Vault en Azure Key Vault Managed HSM.

Sleuteltoegang

In het server-side encryptiemodel dat klantbeheerde sleutels gebruikt in Azure Key Vault, benadert de dienst de sleutels om te versleutelen en te ontsleutelen indien nodig. 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 dienst presenteert vervolgens het token aan Key Vault om een sleutel te verkrijgen die hij kan benaderen.

Voor bewerkingen die encryptiesleutels gebruiken, kun je een service-identiteit toegang geven tot een van de volgende bewerkingen: decrypt, encrypt, unwrapKey, wrapKey, verify, signgetlistupdatecreateimportdeletebackupen .restore

Om een sleutel te verkrijgen voor gebruik bij het versleutelen of ontsleutelen van in rusttoestand opgeslagen gegevens, moet de service-identiteit waaronder de Resource Manager-service-instantie wordt uitgevoerd, beschikken over de machtigingen UnwrapKey (om de sleutel voor ontsleuteling te verkrijgen) en WrapKey (om een sleutel in Key Vault op te slaan bij het aanmaken van een nieuwe sleutel).

Notitie

Voor meer informatie over autorisatie van Key Vault, zie Secure your key vault.

Voordelen

• Volledige controle over de gebruikte toetsen. Encryptiesleutels worden beheerd in je Key Vault onder jouw controle.
• Je kunt meerdere diensten versleutelen met één root-sleutel.
• Je kunt sleutelbeheer scheiden van het algemene beheermodel van de dienst.
• Je kunt de dienst en de locatie van de sleutel in verschillende regio's definiëren.

Nadelen

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

Server-side encryptie door gebruik te maken van door klanten beheerde sleutels in door de klant gecontroleerde hardware (gespecialiseerde optie)

Sommige Azure-services maken het HYOK-sleutelbeheermodel (Host Your Own Key) mogelijk voor organisaties met gespecialiseerde beveiligingsvereisten. Deze beheermodus is nuttig in sterk gereguleerde situaties die versleuteling van rustende gegevens en sleutelbeheer in een eigen repository volledig buiten de controle van Microsoft vereisen. Het gaat verder dan de standaard platformbeheerde encryptie en optionele, door klanten beheerde sleutels in Azure Key Vault.

In dit model moet de dienst de sleutel van een externe site gebruiken om de DEK te ontsleutelen. Prestatie- en beschikbaarheidsgaranties worden beïnvloed en configuratie is aanzienlijk complexer. Bovendien, omdat de dienst geen toegang heeft tot de DEK tijdens de encryptie- en ontsleutelingsoperaties, zijn de algehele 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 ondersteunen de meeste Azure-diensten geen server-side encryptie door klantbeheerde sleutels te gebruiken in door klanten gecontroleerde hardware. Een van de twee sleutels in Double Key Encryption volgt dit model.

Sleuteltoegang

Wanneer je server-side encryptie gebruikt met door klanten beheerde sleutels in door klanten gecontroleerde hardware, houd je de sleutelsleutels op een systeem dat je zelf 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

• Je hebt volledige controle over de root key omdat een door klanten geleverde winkel de encryptiesleutels beheert.
• Je kunt meerdere diensten versleutelen met één root-sleutel.
• Je kunt sleutelbeheer scheiden van het algemene beheermodel van de dienst.
• Je kunt de dienst en de locatie van de sleutel in verschillende regio's definiëren.

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.
• Het model vergroot de afhankelijkheid van netwerkbeschikbaarheid tussen het klantdatacenter en Azure-datacenters.

Gerelateerde inhoud

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