Microsoft Azure-tjänster – Azure Key Vault

Azure Key Vault är Microsofts molntjänst för att lagra och kontrollera åtkomst till kryptografiska nycklar, hemligheter och certifikat. Det är viktigt eftersom varje autentiseringsuppgift som ett program behöver (krypteringsnycklar, anslutningssträngar, TLS-certifikat) blir en enda komprometteringspunkt om den lämnas kvar i kod eller konfigurationsfiler istället för ett hanterat valv. Rekommenderad åtgärd: använd Key Vault med Azure RBAC och hanterade identiteter som standard och reservera hanterad HSM för arbetsbelastningar med ett dokumenterat krav på dedikerad hårdvara.

Publicerad: februari 2021. Uppdaterad: augusti 2026. Granskad av Encryption Consultings Cloud Key Management Team.

För information om hur Azure Key Vault passar in i ett bredare efterlevnadsprogram, se Hur du kan göra organisationer mer nöjda med Microsoft Azure?. För information om hur Key Vault står sig i jämförelse med AWS och GCP:s nyckelhanteringstjänster, se AWS KMS vs. Azure Key Vault vs. GCP KMS . För moln-HSM-alternativ i allmänhet, se Jämförelse mellan molnbaserad HSM kontra lokal HSM , och för certifikatbaserad identitet över moln, se Vad är molnbaserad PKI-arkitektur ?.

Vad är Azure Key Vault?

Azure Key Vault är en molntjänst som fungerar som en central, åtkomstkontrollerad lagring för en organisations känsliga material, organiserad i tre resurstyper: hemligheter (anslutningssträngar, lösenord, API-nycklar, upp till 10 KB vardera), nycklar (kryptografiska nycklar som används för kryptering, signering och nyckelomslag, som aldrig lämnar valvets säkra gräns i användbar form) och certifikat (SSL/TLS X.509-certifikat som Key Vault kan etablera, förnya och distribuera till integrerade Azure-tjänster). Avsiktligt kan inte ens Microsoft extrahera eller visa kundnyckelmaterial; varje åtgärd sker inuti valvet eller HSM-gränsen och loggas för granskning.

Hur fungerar nativ kontra extern nyckelkontroll i Azure Key Vault?

Azure Key Vault och dess relaterade tjänster erbjuder flera nivåer av nyckelförvaring, avvägning av kostnader, isolering och vem som slutligen kontrollerar nyckelmaterialet:

Nyckelkontrollnivå	Skyddsnivå	Bästa passform
Standardnivå (inbyggd, programvara)	FIPS 140-2 Nivå 1, kryptografisk modul för programvara.	Standard för de flesta hemligheter, nycklar och certifikat.
Premiumnivå (inbyggd, HSM-baserad)	FIPS 140-3 Nivå 3 på aktuell HSM Platform 2-hårdvara, delad pool med flera hyresgäster.	Arbetsbelastningar som behöver hårdvarubaserade nycklar utan dedikerad HSM-kostnad.
Hanterad HSM (inbyggd, dedikerad)	FIPS 140-3 Nivå 3, dedikerad HSM-pool för en enda klient; varje nyckel är HSM-skyddad, inget programvarunyckelalternativ.	Reglerade arbetsbelastningar som kräver fullständig administrativ kontroll över en dedikerad HSM.
Azure Dedikerad HSM (kundstyrd)	Kundadministrerad fysisk HSM-apparat; Microsoft driver den inte.	Ett efterlevnadskrav om att molnleverantören aldrig själv administrerar HSM.
BYOK (importerat nyckelmaterial)	Nyckelmaterial som genereras utanför Azure, ofta i en lokal HSM, importeras till Key Vault eller Managed HSM.	Organisationer som behöver bevisa nyckelns ursprung eller som redan genererar nycklar lokalt.

Standardinställningen är Standard eller Premium, såvida inte ett namngivet krav kräver Managed HSM:s dedikerade pool eller Dedicated HSM:s kundadministrerade hårdvara; båda kostar betydligt mer och är endast värda det när ett specifikt mandat kräver den isoleringsnivån.

Vilka är de viktigaste Azure Key Vault-koncepten du behöver känna till?

• Hemlighet: en liten data-blob (upp till 10 KB) såsom en autentiseringsnyckel, lösenord, token eller .pfx-fil, hämtad av en auktoriserad anropare snarare än inbäddad i programkoden.
• Nyckel: en kryptografisk nyckel som används för kryptering/dekryptering, omslag/packning eller signering/verifiering; till skillnad från hemligheter lämnar nyckelmaterial aldrig valvets säkra gräns.
• Ägare av Key Vault: administratören som skapar valvet och auktoriserar användare och program för specifika åtgärder.
• Tjänstens huvudman: den identitet som ett program använder för att autentisera mot Azure Active Directory (Microsoft Entra ID) och i sin tur mot Key Vault.
• Åtkomstpolicy kontra rolltilldelning: Den äldre, valvbaserade behörighetsmodellen kontra Azure RBAC:s rollbaserade behörighetsmodell, som beskrivs nedan.

Hur bör IAM struktureras för Azure Key Vault?

Azure RBAC är Microsofts rekommenderade behörighetsmodell för Key Vault, som ersätter det äldre åtkomstpolicysystemet på valvnivå med samma detaljerade, granskningsbara rolltilldelningar som används i resten av Azure.

1. Migrera valv som fortfarande använder den äldre åtkomstpolicymodellen till Azure RBAC, eftersom RBAC integreras med villkorlig åtkomst och skapar en konsekvent granskningslogg över alla tjänster.
2. Separera Kryptoansvarig för nyckelvalv roll (nyckellivscykel: skapa, rotera, ta bort) från Key Vault Crypto-användare (endast kryptera/dekryptera/signera), vilket ger var och en till olika identiteter.
3. Bevilja åtkomst till hemligheter och certifikat via motsvarande Användare av Key Vault Secrets och Certifikatsansvarig för nyckelvalv roller snarare än ett enda brett Key Vault-administratörstillstånd.
4. Omfånga rolltilldelningar på valvnivå, eller på individuell nyckel-/hemlighets-/certifikatnivå för finare kontroll, snarare än på prenumerationsnivå.
5. Granska rolltilldelningar i samma takt som andra granskningar av produktionsåtkomst, eftersom en inaktuell kryptoanvändarbeviljandegrad motsvarar permanent dekrypteringsåtkomst.

Hur autentiserar du ett program till Azure Key Vault?

Microsofts nuvarande rekommendation är att autentisera program med en hanterad identitet snarare än en klienthemlighet för tjänstens huvudperson, eftersom en hanterad identitet tar bort behovet av att lagra några autentiseringsuppgifter alls:

1. Aktivera en systemtilldelad eller användartilldelad hanterad identitet på programmets Azure-resurs (App Service, VM, Function eller liknande).
2. Ge den hanterade identiteten lämplig RBAC-roll (kryptoanvändare, hemlighetsanvändare eller certifikatansvarig) på målvalvet.
3. Programmet begär en token från Azure Active Directory med sin hanterade identitet, utan någon klienthemlighet inblandad.
4. Programmet presenterar den token för Key Vault, som validerar den och returnerar den begärda hemligheten, nyckelåtgärdsresultatet eller certifikatet.
5. För program som inte kan använda en hanterad identitet (anropare i flera moln eller lokala anropare), använd ett tjänstens huvudnamn med en certifikatautentiseringsuppgift snarare än en klienthemlighet och rotera den autentiseringsuppgiften enligt ett definierat schema.

Hur ska du hantera nyckelrotation i Azure Key Vault?

Key Vault stöder inbyggda automatiska rotationspolicyer, vilket låter en organisation definiera en rotationsperiod och ett valfritt aviseringsfönster före utgångsdatum. Precis som med alla större molntjänster för nyckelhantering skapar rotationen bara en ny nyckelversion för framtida operationer; den krypterar inte om data som redan skyddats av en tidigare version och tar inte bort den tidigare versionen automatiskt. En komplett rotationsplan behöver ett separat omkrypteringssteg och ett uttryckligt schema för att pensionera gamla nyckelversioner när ingenting är beroende av dem. Certifikat följer sitt eget förnyelseschema, separat från nyckelrotation, och Key Vault kan automatiskt begära förnyelse från en integrerad certifikatutfärdare före utgångsdatum.

Vad bör du logga för Azure Key Vault?

• Diagnostiska loggar för Key Vault, skickas till Azure Monitor eller Log Analytics, som täcker varje hemlighets-, nyckel- och certifikatåtgärd, anropar-ID och den specifika objektversion som används.
• Ändringar i rolltilldelning på valvet, eftersom ett nytt RBAC-beviljande i sig är en säkerhetsrelevant händelse.
• Händelser för förnyelse och utgång av certifikat, så en misslyckad automatisk förnyelse upptäcks innan certifikatet faktiskt löper ut.
• Ändringar av brandvägg och nätverksregler på valvet, eftersom Key Vault också stöder begränsning av åtkomst till specifika virtuella nätverk eller privata slutpunkter.

Vad kostar Azure Key Vault?

Standardnivån faktureras per åtgärd för hemligheter, nycklar och certifikat till en låg avgift per 10 000 operationer. Premiumnivån lägger till en avgift per HSM-skyddad nyckelåtgärd utöver samma basavgift för att täcka den delade HSM-poolen. Managed HSM fakturerar en fast timavgift per HSM-pool plus avgifter per nyckelversion och per åtgärd, väsentligt högre än Standard eller Premium, för att täcka dedikerad hårdvara för en enda klient. Azure Dedicated HSM fakturerar per timme per fysisk enhet oavsett användning. Kontrollera aktuella priser per enhet mot Microsofts egna prissidor innan du budgeterar en hanterad HSM- eller dedikerad HSM-migrering, eftersom kostnadsgapet mellan nivåerna är betydande.

Hur ser nyckelhantering i flera moln ut i Azure, AWS och GCP?

Varje större moln implementerar samma konceptuella nivåer, en billig programvaruskyddad standardnivå, en delad HSM-baserad nivå och ett dedikerat HSM-alternativ för en enda hyresgäst, under olika namn och med olika FIPS-valideringshistoriker. En konsekvent arkitektur för flera moln standardiserar åtkomstkontroll och rotationspolicy över varje molns inbyggda nyckelvalv snarare än att försöka köra en nyckelhanteringstjänst över alla tre, eftersom ingen av de tre nativt hanterar en annans nycklar.

Se vår jämförelse av AWS KMS, Azure Key Vault och GCP KMS för en fullständig översikt över hur dessa tre skiljer sig åt vad gäller rotation, IAM och specifikt kostnad.

Vilka är begränsningarna med Azure Key Vault?

• Standardnivåns programvaruskyddade nycklar har endast FIPS 140-2 nivå 1-validering, vilket inte uppfyller ett krav på hårdvarubaserad nyckelförvaring.
• Att migrera valv från den äldre åtkomstpolicymodellen till RBAC kräver noggrann planering, eftersom de två modellerna inte mappas en-till-en och en förhastad migrering kan antingen överbevilja eller spärra legitim åtkomst.
• Både Managed HSM och Dedicated HSM har betydligt högre kostnader än Standard eller Premium, vilket måste motiveras mot ett faktiskt efterlevnadskrav.
• Rotation omkrypterar inte befintlig data automatiskt; omkryptering och rensning av gamla versioner är kundens ansvar.

Checklista för beslut: Att välja rätt Azure Key Vault-nivå

1. Standardnivån används för hemligheter och programvaruskyddade nycklar; byt endast till Premium när en arbetsbelastning behöver HSM-baserade nycklar.
2. Reservera hanterad HSM eller dedikerad HSM för ett namngivet krav på dedikerad hårdvara för en enda klient.
3. Migrera alla valv som fortfarande använder den äldre åtkomstpolicymodellen till Azure RBAC, och separera nyckeladministration från nyckelanvändning.
4. Autentisera applikationer med hanterade identiteter och använd endast certifikatbaserade tjänsteprinciper när det är nödvändigt.
5. Aktivera automatisk rotation och dokumentera den separata omkrypteringsprocessen för befintliga data.

Vad skulle krypteringskonsulter rekommendera?

De flesta Azure-miljöer som vi utvärderar har fortfarande applikationer som autentiserar med en långlivad tjänstprinciphemlighet istället för en hanterad identitet, och valv som fortfarande kör den äldre åtkomstpolicymodellen år efter att RBAC blev den rekommenderade metoden. Encryption Consultings Cloud Key Management-tjänster utformar RBAC-rollstrukturen och migreringen av hanterade identiteter för din Key Vault-egendom, vårt HSM-as-a-Service -erbjudande ger dig hårdvarubaserad nyckelförvaring utan att behöva använda HSM:er direkt, och vår PKI-as-a-Service utökar detta till fullständig certifikatlivscykelhantering.

Vanliga frågor om partihandel med mat och dryck

Vad är skillnaden mellan Azure Key Vault Standard och Premium?

Standardnivån skyddar nycklar i programvara, FIPS 140-2 nivå 1 validerad; Premiumnivån skyddar nycklar i en delad pool av hårdvarusäkerhetsmoduler, nu FIPS 140-3 nivå 3 validerad på Microsofts nuvarande HSM-plattform.

Är hanterad HSM samma sak som Key Vault Premium?

Nej. Premium är en delad HSM-pool med flera innehavare i ett standardnyckelvalv. Managed HSM är en dedikerad HSM-pool med en enda innehavare med sin egen administrativa modell, och varje nyckel i den är HSM-skyddad utan programvarunyckelalternativ.

Bör jag fortfarande använda valvåtkomstprinciper istället för Azure RBAC?

Nej. Azure RBAC är Microsofts nuvarande rekommenderade behörighetsmodell för Key Vault; åtkomstprinciper är den äldre metoden och befintliga valv bör migreras.

Kan Azure Key Vault fungera med en extern nyckelhanterare som Thales?

Key Vault stöder import av externt genererat nyckelmaterial via BYOK. För ett scenario där molnleverantören aldrig ska ha användbart nyckelmaterial alls är Azure Dedicated HSM, som administreras direkt av kunden, det närmaste alternativet till en HYOK-modell.

Krypterar nyckelrotation i Key Vault befintliga data igen?

Nej. Rotation skapar bara en ny aktiv nyckelversion för framtida operationer; data som redan är krypterade under den tidigare versionen förblir beroende av den tills en explicit omkrypteringsprocess körs.

Behöver du hjälp med att strukturera Azure Key Vault RBAC-roller och migrera bort äldre åtkomstpolicyer? Prata med Encryption Consultings Cloud Key Management-team.

Referensprojekt

Översikt över Azure Key Vault – learn.microsoft.com

Om nycklar i Azure Key Vault (FIPS-valideringsnivåer) – learn.microsoft.com

Om nycklar i Managed HSM – learn.microsoft.com