Grundläggande begrepp i Azure Key Vault

  • Artikel

Azure Key Vault är en molntjänst för säker lagring och åtkomst till hemligheter. En hemlighet är allt som du vill kontrollera åtkomsten till, till exempel API-nycklar, lösenord, certifikat eller kryptografiska nycklar. Key Vault-tjänsten stöder två typer av containrar: valv och HSM-pooler (Managed Hardware Security Module). Valv stöder lagring av programvara och HSM-säkerhetskopierade nycklar, hemligheter och certifikat. Hanterade HSM-pooler stöder endast HSM-säkerhetskopierade nycklar. Mer information finns i Översikt över REST API för Azure Key Vault.

Här är andra viktiga termer:

  • Klientorganisation: en klientorganisation är den organisation som äger och hanterar en specifik instans av Microsoft-molntjänster. Den används oftast för att referera till uppsättningen azure- och Microsoft 365-tjänster för en organisation.

  • Valvägare: valvägaren kan skapa ett nyckelvalv och få fullständig åtkomst till och kontroll över det. Valvägaren kan även konfigurera granskning för att logga vem som använder hemligheter och nycklar. Administratörer kan styra nyckelns livscykel. De kan distribuera en ny version av nyckeln, säkerhetskopiera den och utföra andra relaterade uppgifter.

  • Valvkonsument: valvkonsumenten kan utföra åtgärder på tillgångarna i nyckelvalvet när valvägaren ger konsumenten åtkomst. Vilka åtgärder som är tillgängliga beror på vilka behörigheter som beviljats.

  • Hanterade HSM-administratörer: Användare som har tilldelats rollen Administratör har fullständig kontroll över en hanterad HSM-pool. De kan skapa fler rolltilldelningar för att delegera kontrollerad åtkomst till andra användare.

  • Hanterad HSM Crypto Officer/Användare: Inbyggda roller som vanligtvis tilldelas till användare eller tjänstens huvudnamn som utför kryptografiska åtgärder med hjälp av nycklar i Managed HSM. Kryptoanvändare kan skapa nya nycklar, men kan inte ta bort nycklar.

  • Hanterad HSM Kryptotjänstkrypteringsanvändare: Inbyggd roll som vanligtvis tilldelas till en tjänstkontohanterad tjänstidentitet (till exempel lagringskonto) för kryptering av vilande data med kundhanterad nyckel.

  • Resurs: en resurs är ett hanterbart objekt som är tillgängligt via Azure. Vanliga exempel är virtuell dator, lagringskonto, webbapp, databas och virtuellt nätverk. Det finns många fler.

  • Resursgrupp: resursgruppen är en container som innehåller relaterade resurser för en Azure-lösning. Resursgruppen kan innehålla alla resurser för lösningen, eller endast de resurser som du vill hantera som en grupp. Du bestämmer hur du vill allokera resurser till resursgrupper baserat på vad som passar din organisation bäst.

  • Säkerhetsobjekt: Ett Azure-säkerhetsobjekt är en säkerhetsidentitet som användarskapade appar, tjänster och automatiseringsverktyg använder för att få åtkomst till specifika Azure-resurser. Se det som en "användaridentitet" (användarnamn och lösenord eller certifikat) med en specifik roll och strikt kontrollerade behörigheter. Ett säkerhetsobjekt bör bara behöva göra specifika saker, till skillnad från en allmän användaridentitet. Det förbättrar säkerheten om du endast beviljar den lägsta behörighetsnivå som den behöver för att utföra sina hanteringsuppgifter. Ett säkerhetsobjekt som används med ett program eller en tjänst kallas för tjänstens huvudnamn.

  • Microsoft Entra-ID: Microsoft Entra ID är Active Directory-tjänsten för en klientorganisation. Varje katalog har en eller flera domäner. En katalog kan ha många prenumerationer som är associerade med den, men endast en klientorganisation.

  • Azure-klient-ID: Ett klient-ID är ett unikt sätt att identifiera en Microsoft Entra-instans i en Azure-prenumeration.

  • Hanterade identiteter: Azure Key Vault är ett sätt att lagra autentiseringsuppgifter och andra nycklar och hemligheter på ett säkert sätt, men koden måste autentiseras till Key Vault för att hämta dem. Genom att använda en hanterad identitet blir det enklare att lösa problemet genom att ge Azure-tjänster en automatiskt hanterad identitet i Microsoft Entra-ID. Du kan använda den här identiteten för att autentisera till Key Vault eller någon tjänst som stöder Microsoft Entra-autentisering, utan att ha några autentiseringsuppgifter i koden. Mer information finns i följande bild och översikten över hanterade identiteter för Azure-resurser.

Autentisering

Om du vill utföra åtgärder med Key Vault måste du först autentisera till det. Det finns tre sätt att autentisera till Key Vault:

  • Hanterade identiteter för Azure-resurser: När du distribuerar en app på en virtuell dator i Azure kan du tilldela en identitet till den virtuella datorn som har åtkomst till Key Vault. Du kan också tilldela identiteter till andra Azure-resurser. Fördelen med den här metoden är att appen eller tjänsten inte hanterar rotationen av den första hemligheten. Azure roterar automatiskt identiteten. Vi rekommenderar den här metoden som bästa praxis.
  • Tjänstens huvudnamn och certifikat: Du kan använda tjänstens huvudnamn och ett associerat certifikat som har åtkomst till Key Vault. Vi rekommenderar inte den här metoden eftersom programägaren eller utvecklaren måste rotera certifikatet.
  • Tjänstens huvudnamn och hemlighet: Även om du kan använda tjänstens huvudnamn och en hemlighet för att autentisera till Key Vault rekommenderar vi det inte. Det är svårt att automatiskt rotera bootstrap-hemligheten som används för att autentisera till Key Vault.

Kryptering av data internt

Azure Key Vault tillämpar TLS-protokollet (Transport Layer Security) för att skydda data när de färdas mellan Azure Key Vault och klienter. Klienter förhandlar om en TLS-anslutning med Azure Key Vault. TLS ger stark autentisering, meddelandesekretess och integritet (möjliggör identifiering av manipulering, avlyssning och förfalskning), samverkan, algoritmflexibilitet och enkel distribution och användning.

Perfect Forward Secrecy (PFS) skyddar anslutningar mellan kundernas klientsystem och Microsofts molntjänster med unika nycklar. Anslutningar använder också RSA-baserade 2 048-bitars krypteringsnyckellängder. Den här kombinationen gör det svårt för någon att fånga upp och komma åt data som är under överföring.

Nyckelvalvroller

Använd följande tabell för att bättre förstå hur Key Vault kan hjälpa utvecklare och säkerhetsadministratörer.

Roll Problembeskrivning Åtgärdas av Azure Key Vault
Azure-programutvecklare "Jag vill skriva ett program för Azure som använder nycklar för signering och kryptering. Men jag vill att dessa nycklar ska vara externa från mitt program så att lösningen är lämplig för ett program som är geografiskt distribuerat.

Jag vill att de här nycklarna och hemligheterna ska skyddas utan att behöva skriva koden själv. Jag vill också att dessa nycklar och hemligheter ska vara enkla för mig att använda från mina program, med optimal prestanda."		 √ Nycklar lagras i ett valv och anropas av en URI vid behov.

√ Nycklar skyddas av Azure med branschstandardalgoritmer, nyckellängder och maskinvarusäkerhetsmoduler.

√ Nycklar bearbetas i HSM-modulerna som finns i samma Azure-datacenter som programmen. Denna metod ger bättre tillförlitlighet och kortare svarstider än om nycklarna finns på en annan plats, till exempel lokalt.
Utvecklare av programvara som en tjänst (SaaS) " Jag vill inte ha ansvar eller potentiellt ansvar för mina kunders klientnycklar och hemligheter.

Jag vill att kunderna ska äga och hantera sina nycklar så att jag kan koncentrera mig på att göra det jag gör bäst, vilket är att tillhandahålla de viktigaste programvarufunktionerna."		 √ Kunder kan importera sina egna nycklar till Azure och hantera dem. När ett SaaS-program behöver utföra kryptografiska åtgärder med hjälp av kundernas nycklar utför Key Vault dessa åtgärder för programmets räkning. Programmet ser inte kundernas nycklar.
Säkerhetschef "Jag vill veta att våra program följer FIPS 140 HSM på nivå 3 för säker nyckelhantering.

Jag vill vara säker på att min organisation har kontrollen över nycklarnas livscykel och kan övervaka nyckelanvändningen.

Och även om vi använder flera Azure-tjänster och resurser vill jag hantera nycklarna från en enda plats i Azure."		 √ Välj valv eller hanterade HSM:er för FIPS 140-verifierade HSM:er.
√ Välj hanterade HSM-pooler för FIPS 140-2 Nivå 3-verifierade HSM:er.

√ Key Vault är utformat så att Microsoft inte kan se eller extrahera dina nycklar.
√ Nyckelanvändningen loggas i nära realtid.

√ Valvet tillhandahåller ett enda gränssnitt, oavsett hur många valv du har i Azure, vilka regioner de stöder och vilka program använder dem.

Vem som helst med en Azure-prenumeration kan skapa och använda nyckelvalv. Även om Key Vault gynnar utvecklare och säkerhetsadministratörer kan det implementeras och hanteras av en organisations administratör som hanterar andra Azure-tjänster. Den här administratören kan till exempel logga in med en Azure-prenumeration, skapa ett valv för organisationen där nycklar ska lagras och sedan ansvara för driftuppgifter som dessa:

  • Skapa eller importera en nyckel eller hemlighet.
  • Återkalla eller ta bort en nyckel eller hemlighet.
  • Ge användare eller program åtkomst till nyckelvalvet, så att de kan hantera eller använda sina nycklar och hemligheter.
  • Konfigurera nyckelanvändningen (till exempel signera eller kryptera).
  • Övervaka nyckelanvändningen.

Den här administratören ger sedan utvecklar-URI:er att anropa från sina program. Den här administratören ger även information om nyckelanvändningsloggning till säkerhetsadministratören.

Översikt över hur Azure Key Vault fungerar

Utvecklare kan också hantera nycklar direkt, med hjälp av API:er. Mer information finns i guiden för Key Vault-utvecklare.

Nästa steg

Azure Key Vault är tillgängligt i de flesta regioner. Mer information finns på sidan med Key Vault-priser.