Microsoft Azure Services - Azure Key Vault

Azure Key Vault is de cloudservice van Microsoft voor het opslaan en beheren van de toegang tot cryptografische sleutels, geheimen en certificaten. Dit is belangrijk omdat elke referentie die een applicatie nodig heeft (versleutelingssleutels, verbindingsreeksen, TLS-certificaten) een potentieel kwetsbaar punt wordt als deze in code of configuratiebestanden wordt bewaard in plaats van in een beheerde kluis. Aanbevolen actie: gebruik Key Vault standaard met Azure RBAC en beheerde identiteiten, en reserveer Managed HSM voor workloads met een gedocumenteerde vereiste voor specifieke hardware.

Key Takeaways

Azure Key Vault beheert drie verschillende resourcetypen (geheimen, sleutels en certificaten) onder één toegangsbeheerde service, elk met zijn eigen bewerkingen en auditlogboek.
De sleutels van de standaardlaag zijn FIPS 140-2 niveau 1 gevalideerd (softwarematig beveiligd); de sleutels van de premiumlaag draaien nu op HSM Platform 2 en zijn FIPS 140-3 niveau 3 gevalideerd; Managed HSM is een dedicated pool voor één tenant en is eveneens FIPS 140-3 niveau 3 gevalideerd.
Azure RBAC heeft het oude toegangsbeleidsmodel voor de kluis vervangen als het door Microsoft aanbevolen machtigingssysteem, en beheerde identiteiten zijn de aanbevolen manier voor applicaties om zich te authenticeren, ter vervanging van service-principal secrets.
BYOK stelt een organisatie in staat om extern gegenereerd sleutelmateriaal te importeren in Key Vault of Managed HSM; Azure Dedicated HSM is de meest vergelijkbare optie met HYOK, omdat de klant die hardware rechtstreeks beheert in plaats van Microsoft.
Sleutelrotatie, diagnostische logboekregistratie en kosten variëren aanzienlijk per abonnementsniveau, en geen van deze drie wordt automatisch geconfigureerd wanneer een kluis voor het eerst wordt aangemaakt.

Gepubliceerd: februari 2021. Bijgewerkt: augustus 2026. Beoordeeld door het Cloud Key Management Team van Encryption Consulting.

Voor meer informatie over hoe Azure Key Vault past in een breder complianceprogramma, zie Hoe u organisaties beter kunt laten voldoen aan de Microsoft Azure- richtlijnen . Voor een vergelijking tussen Key Vault en de sleutelbeheerservices van AWS en GCP, zie AWS KMS versus Azure Key Vault versus GCP KMS . Voor algemene informatie over cloud-HSM-opties, zie Vergelijking tussen cloud-gebaseerde HSM en on-premises HSM , en voor certificaatgebaseerde identiteit in verschillende clouds, zie Wat is een cloud-gebaseerde PKI-architectuur ?.

Wat is Azure Key Vault?

Azure Key Vault is een cloudservice die fungeert als een centrale, met toegangscontrole beveiligde opslagplaats voor gevoelige gegevens van een organisatie. Deze gegevens zijn onderverdeeld in drie typen: geheimen (verbindingsreeksen, wachtwoorden, API-sleutels, tot 10 KB per stuk), sleutels (cryptografische sleutels die worden gebruikt voor versleuteling, ondertekening en sleutelversleuteling, en die de beveiligde omgeving van de kluis nooit in bruikbare vorm verlaten) en certificaten (SSL/TLS X.509-certificaten die Key Vault kan aanmaken, vernieuwen en implementeren in geïntegreerde Azure-services). Zelfs Microsoft kan de sleutelgegevens van klanten niet extraheren of inzien; elke bewerking vindt plaats binnen de kluis of HSM en wordt vastgelegd voor auditdoeleinden.

Hoe werkt native versus extern sleutelbeheer in Azure Key Vault?

Azure Key Vault en de bijbehorende services bieden verschillende niveaus van sleutelbeheer, waarbij kosten, isolatie en wie uiteindelijk de controle over het sleutelmateriaal heeft, tegen elkaar worden afgewogen:

Sleutelbeheerlaag	Beschermingsniveau	Beste pasvorm
Standaardlaag (native, software)	FIPS 140-2 Niveau 1, softwarematige cryptografische module.	Standaard voor de meeste geheimen, sleutels en certificaten.
Premium-niveau (native, HSM-ondersteund)	FIPS 140-3 Niveau 3 op de huidige HSM Platform 2-hardware, gedeelde multi-tenant pool.	Werkbelastingen die hardwarematig ondersteunde sleutels vereisen zonder de kosten van een aparte HSM.
Beheerde HSM (native, dedicated)	FIPS 140-3 Niveau 3, speciale HSM-pool voor één gebruiker; elke sleutel is HSM-beveiligd, geen optie voor softwarematige sleutels.	Gereguleerde werkzaamheden die volledige administratieve controle over een speciaal daarvoor bestemd HSM vereisen.
Azure Dedicated HSM (door de klant beheerd)	Het fysieke HSM-apparaat wordt door de klant beheerd; Microsoft beheert het niet.	Een nalevingsvereiste dat de cloudprovider de HSM nooit zelf mag beheren.
BYOK (geïmporteerd sleutelmateriaal)	Sleutelmateriaal dat buiten Azure is gegenereerd, vaak in een on-premises HSM, wordt geïmporteerd in Key Vault of Managed HSM.	Organisaties die de herkomst van sleutels moeten bewijzen of die al zelf sleutels genereren.

Kies standaard voor Standard of Premium, tenzij een specifieke vereiste de dedicated pool van Managed HSM of de door de klant beheerde hardware van Dedicated HSM vereist; beide opties zijn aanzienlijk duurder en alleen de moeite waard als een specifieke opdracht dat niveau van isolatie vereist.

Wat zijn de belangrijkste concepten van Azure Key Vault die u moet kennen?

Geheim: Een klein gegevensblok (tot 10 KB), zoals een authenticatiesleutel, wachtwoord, token of .pfx-bestand, dat wordt opgevraagd door een geautoriseerde beller in plaats van ingebed te zijn in de applicatiecode.
Sleutel: Een cryptografische sleutel wordt gebruikt voor versleutelings-/ontsleutelings-, versleutelings-/ontsleutelings- of ondertekenings-/verificatiebewerkingen; in tegenstelling tot geheimen verlaat het sleutelmateriaal nooit de beveiligde grens van de kluis.
Eigenaar van de sleutelkluis: De beheerder die de kluis aanmaakt en gebruikers en applicaties autoriseert voor specifieke bewerkingen.
Hoofddienst: De identiteit die een applicatie gebruikt om zich te authenticeren bij Azure Active Directory (Microsoft Entra ID) en vervolgens bij Key Vault.
Toegangsbeleid versus roltoewijzing: Het traditionele, op de kluis gebaseerde machtigingsmodel versus het op rollen gebaseerde machtigingsmodel van Azure RBAC, zoals hieronder beschreven.

Hoe moet IAM worden gestructureerd voor Azure Key Vault?

Azure RBAC is het door Microsoft aanbevolen machtigingsmodel voor Key Vault. Het vervangt het oudere systeem met toegangsbeleid op kluisniveau door dezelfde gedetailleerde, controleerbare roltoewijzingen die in de rest van Azure worden gebruikt.

Migreer kluizen die nog steeds gebruikmaken van het oude toegangsbeleidsmodel naar Azure RBAC, aangezien RBAC integreert met Conditional Access en een consistent auditspoor genereert voor alle services.
Scheid de Key Vault Crypto Officer rol (sleutellevenscyclus: aanmaken, roteren, verwijderen) van Key Vault Crypto-gebruiker (alleen versleutelen/ontsleutelen/ondertekenen), waarbij elk aan een andere identiteit wordt toegekend.
Verleen toegang tot geheimen en certificaten via het equivalent daarvan. Key Vault Secrets Gebruiker en Sleutelkluis Certificatenbeheerder rollen in plaats van één algemene Key Vault Administrator-machtiging.
Definieer roltoewijzingen op kluisniveau of op het niveau van individuele sleutels/geheimen/certificaten voor nauwkeurigere controle, in plaats van op abonnementsniveau.
Beoordeel de roltoewijzingen met dezelfde frequentie als andere beoordelingen van productietoegang, aangezien een verlopen Crypto User-toekenning gelijk staat aan permanente decryptietoegang.

Hoe verifieer je een applicatie bij Azure Key Vault?

Microsoft adviseert momenteel om applicaties te authenticeren met een beheerde identiteit in plaats van een service-principal client secret, omdat een beheerde identiteit het opslaan van inloggegevens overbodig maakt.

Schakel een door het systeem of de gebruiker toegewezen beheerde identiteit in voor de Azure-resource van de toepassing (App Service, VM, Function of vergelijkbaar).
Wijs de betreffende beheerde identiteit de juiste RBAC-rol (Crypto User, Secrets User of Certificates Officer) toe op de doelkluis.
De applicatie vraagt een token aan bij Azure Active Directory met behulp van de beheerde identiteit, zonder dat er een clientgeheim aan te pas komt.
De applicatie presenteert dat token aan Key Vault, die het valideert en het gevraagde geheim, het resultaat van de sleutelbewerking of het certificaat retourneert.
Voor applicaties die geen beheerde identiteit kunnen gebruiken (multi-cloud of on-premises aanroepen), moet worden teruggevallen op een service-principal met een certificaatreferentie in plaats van een clientgeheim, en moet die referentie volgens een vast schema worden vernieuwd.

Hoe moet u sleutelrotatie in Azure Key Vault aanpakken?

Key Vault ondersteunt ingebouwde automatische rotatiebeleidsregels, waarmee een organisatie een rotatieperiode en een optioneel meldingvenster vóór de vervaldatum kan definiëren. Net als bij alle belangrijke cloudservices voor sleutelbeheer, creëert rotatie alleen een nieuwe sleutelversie voor toekomstige bewerkingen; het versleutelt geen gegevens die al door een eerdere versie zijn beveiligd en verwijdert die eerdere versie ook niet automatisch. Een volledig rotatieplan vereist een aparte herversleutelingsstap en een expliciet schema voor het buiten gebruik stellen van oude sleutelversies zodra deze niet meer nodig zijn. Certificaten volgen hun eigen vernieuwingsschema, los van sleutelrotatie, en Key Vault kan automatisch een verlenging aanvragen bij een geïntegreerde certificeringsinstantie vóór de vervaldatum.

Wat moet u loggen voor Azure Key Vault?

Diagnostische logboeken van Key Vault, Deze gegevens worden naar Azure Monitor of Log Analytics verzonden en omvatten elke bewerking met betrekking tot geheimen, sleutels en certificaten, de identiteit van de beller en de specifieke objectversie die is gebruikt.
Wijzigingen in roltoewijzing op de kluis, aangezien een nieuwe RBAC-toekenning op zich een beveiligingsrelevante gebeurtenis is.
Evenementen rondom het verlengen en verlopen van certificaten, Een mislukte automatische verlenging wordt dus opgemerkt voordat het certificaat daadwerkelijk verloopt.
Wijzigingen in firewall- en netwerkregels op de kluis, aangezien Key Vault ook ondersteuning biedt voor het beperken van de toegang tot specifieke virtuele netwerken of privé-eindpunten.

Wat kost Azure Key Vault?

De standaardlaag wordt gefactureerd per bewerking op geheimen, sleutels en certificaten tegen een laag tarief per 10,000 bewerkingen. De premiumlaag voegt een toeslag per HSM-beveiligde sleutelbewerking toe aan hetzelfde basistarief, ter dekking van de gedeelde HSM-pool. Managed HSM factureert een vast uurtarief per HSM-pool plus kosten per sleutelversie en per bewerking, aanzienlijk hoger dan de standaard- of premiumlaag, ter dekking van de dedicated hardware voor één tenant. Azure Dedicated HSM factureert per uur per fysiek apparaat, ongeacht het gebruik. Controleer de actuele tarieven per eenheid op de prijspagina's van Microsoft zelf voordat u een budget opstelt voor een migratie naar Managed HSM of Dedicated HSM, aangezien het kostenverschil tussen de lagen aanzienlijk is.

Hoe ziet sleutelbeheer in meerdere clouds eruit binnen Azure, AWS en GCP?

Elke grote cloud implementeert dezelfde conceptuele lagen: een goedkope, softwarematig beveiligde standaardlaag, een gedeelde laag met HSM-ondersteuning en een dedicated HSM-optie voor één tenant, onder verschillende namen en met verschillende FIPS-validatiegeschiedenissen. Een consistente multi-cloudarchitectuur standaardiseert het toegangscontrole- en rotatiebeleid voor de eigen sleutelkluis van elke cloud, in plaats van te proberen één sleutelbeheerservice voor alle drie te gebruiken, aangezien geen van de drie de sleutels van een andere cloud van nature beheert.

Bekijk onze vergelijking van AWS KMS, Azure Key Vault en GCP KMS voor een volledig overzicht van de verschillen tussen deze drie, met name op het gebied van rotatie, IAM en kosten.

Wat zijn de beperkingen van Azure Key Vault?

De softwarebeveiligde sleutels van de standaardlaag voldoen slechts aan de FIPS 140-2 Level 1-validatie, wat niet voldoet aan de eis van hardwarematige sleutelbewaring.
Het migreren van kluizen van het oude toegangsbeleidsmodel naar RBAC vereist zorgvuldige planning, aangezien de twee modellen niet één-op-één overeenkomen en een overhaaste migratie kan leiden tot overmatige toegang of juist tot het blokkeren van legitieme toegang.
Zowel Managed HSM als Dedicated HSM brengen aanzienlijk hogere kosten met zich mee dan Standard of Premium, en deze kosten moeten worden gerechtvaardigd aan de hand van een daadwerkelijke compliance-vereiste.
Rotatie versleutelt bestaande gegevens niet automatisch opnieuw; herversleuteling en het verwijderen van oude versies zijn de verantwoordelijkheid van de klant.

Beslissingschecklist: De juiste Azure Key Vault-laag kiezen

Gebruik standaard het Standard-niveau voor geheimen en softwarematig beveiligde sleutels; ga alleen over naar Premium wanneer een workload HSM-beveiligde sleutels vereist.
Reserveer een Managed HSM of Dedicated HSM voor een specifieke behoefte aan dedicated hardware voor één enkele gebruiker.
Migreer alle kluizen die nog steeds gebruikmaken van het oude toegangsbeleidsmodel naar Azure RBAC, waarbij sleutelbeheer en sleutelgebruik van elkaar worden gescheiden.
Authenticeer applicaties met beheerde identiteiten en val alleen terug op certificaatgebaseerde serviceprincipals wanneer dat nodig is.
Schakel automatische rotatie in en documenteer het afzonderlijke herversleutelingsproces voor bestaande gegevens.

Wat zou Encryption Consulting aanbevelen?

De meeste Azure-omgevingen die we beoordelen, gebruiken nog steeds applicaties die authenticeren met een lang geldig service-principal-geheim in plaats van een beheerde identiteit, en kluizen draaien nog steeds op het verouderde toegangsbeleidsmodel, jaren nadat RBAC de aanbevolen aanpak is geworden. De Cloud Key Management-services van Encryption Consulting ontwerpen de RBAC-rolstructuur en de migratie naar beheerde identiteiten voor uw Key Vault-omgeving. Ons HSM-as-a-Service -aanbod biedt u hardwarematig ondersteunde sleutelbewaring zonder dat u zelf HSM's hoeft te beheren, en onze PKI-as-a-Service breidt dit uit naar volledig certificaatlevenscyclusbeheer.

Veelgestelde Vragen / FAQ

Wat is het verschil tussen Azure Key Vault Standard en Premium?

De standaardlaag beschermt sleutels in software en is gevalideerd volgens FIPS 140-2 niveau 1; de premiumlaag beschermt sleutels binnen een gedeelde pool van hardwarebeveiligingsmodules en is nu gevalideerd volgens FIPS 140-3 niveau 3 op het huidige HSM-platform van Microsoft.

Is Managed HSM hetzelfde als Key Vault Premium?

Nee. Premium is een gedeelde HSM-pool voor meerdere gebruikers binnen een standaard Key Vault; Managed HSM is een dedicated HSM-pool voor één gebruiker met een eigen beheermodel, en elke sleutel daarin is HSM-beveiligd zonder de mogelijkheid tot softwarematige sleutels.

Moet ik nog steeds toegangsbeleid voor de kluis gebruiken in plaats van Azure RBAC?

Nee. Azure RBAC is het huidige door Microsoft aanbevolen machtigingsmodel voor Key Vault; toegangsbeleid is de verouderde aanpak en bestaande kluizen moeten worden gemigreerd.

Kan Azure Key Vault samenwerken met een externe sleutelbeheerder zoals Thales?

Key Vault ondersteunt het importeren van extern gegenereerd sleutelmateriaal via BYOK. Voor een scenario waarin de cloudprovider nooit bruikbaar sleutelmateriaal hoeft te bewaren, is Azure Dedicated HSM, dat direct door de klant wordt beheerd, de beste optie in vergelijking met een HYOK-model.

Worden bestaande gegevens opnieuw versleuteld bij sleutelrotatie in Key Vault?

Nee. Rotatie creëert alleen een nieuwe actieve sleutelversie voor toekomstige bewerkingen; gegevens die al met de vorige versie zijn versleuteld, blijven daarvan afhankelijk totdat een expliciet herversleutelingsproces wordt uitgevoerd.

Heeft u hulp nodig bij het structureren van RBAC-rollen in Azure Key Vault en het migreren van verouderde toegangsbeleidsregels? Neem dan contact op met het Cloud Key Management-team van Encryption Consulting.