Autentisering i Azure Key Vault

Autentisering med Key Vault fungerar tillsammans med Microsoft Entra ID, som ansvarar för att autentisera en säkerhetsprincips identitet.

Ett säkerhetsobjekt är ett objekt som representerar en användare, grupp, tjänst eller ett program som begär åtkomst till Azure resurser. Azure tilldelar varje säkerhetsobjekt ett unikt object-ID.

• Säkerhetsobjektet user identifierar en person som har en profil i Microsoft Entra ID.

• Ett group säkerhetsobjekt identifierar en uppsättning användare som skapats i Microsoft Entra ID. Alla roller eller behörigheter som tilldelats gruppen beviljas till alla användare i gruppen.

• Ett huvudnamn för tjänsten är en typ av säkerhetsobjekt som identifierar ett program eller en tjänst, det vill säga en kod i stället för en användare eller grupp. Ett objekt-ID för tjänstens huvudnamn fungerar som dess användarnamn. tjänstens huvudnamns klienthemlighet fungerar som dess lösenord.

För applikationer finns det två sätt att hämta ett tjänstehuvudnamn:

• Rekommenderas: aktivera en systemtilldelad hanterad identitet för programmet.

  Med hanterad identitet hanterar Azure internt programmets tjänsthuvudnamn och autentiserar programmet automatiskt med andra Azure tjänster. Hanterad identitet är tillgänglig för program som distribueras till en mängd olika tjänster.

  Mer information finns i översikten över hanterad identitet. Se även Azure tjänster som stöder hanterad identitet, som länkar till artiklar som beskriver hur du aktiverar hanterad identitet för specifika tjänster (till exempel App Service, Azure Functions, Virtual Machines osv.).

• Om du inte kan använda hanterad identitet registrerar du programmet med din Microsoft Entra klientorganisation, som beskrivs i Quickstart: Registrera ett program med Azure identitetsplattform. Registreringen skapar också ett andra programobjekt som identifierar appen för alla klienter.

Key Vault autentiseringsscenarier

När du skapar ett nyckelvalv i en Azure-prenumeration associeras det automatiskt med prenumerationens Microsoft Entra klientorganisation. Alla uppringare i båda noden måste registrera sig hos denna klient och autentisera sig för att få tillgång till nyckelvalvet. Program kan komma åt Key Vault på tre sätt:

• Endast applikation: Applikationen representerar tjänstens huvudansvarig eller hanterade identitet. Den här identiteten är det vanligaste scenariot för program som regelbundet behöver komma åt certifikat, nycklar eller hemligheter från nyckelvalvet. För att detta scenario ska fungera när du använder åtkomstprinciper (äldre) måste objectId i applikationen specificeras i åtkomstprincipen, och applicationId får inte specificeras eller måste vara null. När du använder Azure RBAC, tilldela lämpliga roller till tillämpningens hanterade identitet eller tjänstens huvudprincip.

• Endast användare: Användaren kommer åt nyckelvalvet från alla program som är registrerade i klientorganisationen. Exempel på den här typen av åtkomst är Azure PowerShell och Azure portalen. För att det här scenariot ska fungera när du använder åtkomstprinciper (äldre), måste användarens objectId anges i åtkomstprincipen applicationId och den får inte anges eller måste vara null. När du använder Azure RBAC tilldelar du lämpliga roller till användaren.

• Program-plus-användare (kallas ibland sammansatt identitet): Användaren måste komma åt nyckelvalvet från ett visst program och programmet måste använda OBO-flödet (on-behalf-of authentication) för att personifiera användaren. För att det här scenariot ska fungera med åtkomstprinciper (äldre) måste båda applicationId och objectId anges i åtkomstprincipen. Identifierar applicationId det program som krävs och objectId identifierar användaren. För närvarande är det här alternativet inte tillgängligt för dataplanet Azure RBAC.

I alla typer av åtkomst autentiseras programmet med Microsoft Entra ID. Programmet använder alla autentiseringsmetoder som stöds baserat på programtypen. Programmet hämtar en token för en resurs i planet för att bevilja åtkomst. Resursen är en slutpunkt i hanterings- eller dataplanet baserat på Azure-miljön. Programmet använder token och skickar en REST API-begäran till Key Vault. Mer information finns i hela autentiseringsflödet.

Modellen för en enda mekanism för autentisering till båda planen har flera fördelar:

• Organisationer kan styra åtkomsten centralt till alla nyckelvalv i organisationen.
• Om en användare lämnar företaget förlorar de omedelbart åtkomsten till alla nyckelvalv i organisationen.
• Organisationer kan anpassa autentiseringen med hjälp av alternativen i Microsoft Entra ID, till exempel för att aktivera multifaktorautentisering för ökad säkerhet.

Konfigurera Key Vault-brandväggen

Som standard tillåter Key Vault åtkomst till resurser via offentliga IP-adresser. För större säkerhet kan du också begränsa åtkomsten till specifika IP-intervall, tjänstslutpunkter, virtuella nätverk eller privata slutpunkter.

Mer information finns i Access Azure Key Vault bakom en brandvägg.

Förfrågningsflödet för Key Vault med autentisering

Key Vault autentisering sker som en del av varje begärandeåtgärd på Key Vault. När ett token har hämtats kan det återanvändas vid efterföljande anrop. Exempel på autentiseringsflöde:

1. En token begär att autentiseras med Microsoft Entra ID, till exempel:

   • En Azure resurs som en virtuell dator eller App Service-program med en hanterad identitet kontaktar REST-slutpunkten för att hämta en åtkomsttoken.
   • En användare loggar in på Azure-portalen med ett användarnamn och lösenord.

2. Om autentisering med Microsoft Entra ID lyckas beviljas säkerhetsobjektet en OAuth-token.

3. Ett anrop till Key Vault REST API via Key Vault slutpunkt (URI).

4. Brandväggen i Key Vault kontrollerar följande kriterier. Om något kriterium uppfylls tillåts anropet. Annars blockeras anropet och ett förbjudet svar returneras.

   • Brandväggen är inaktiverad och den offentliga slutpunkten för Key Vault kan nås från det offentliga Internet.
   • Anroparen är en Key Vault Trusted Service, vilket gör att den kan kringgå brandväggen.
   • Anroparen visas i brandväggen efter IP-adress, virtuellt nätverk eller tjänstslutpunkt.
   • Anroparen kan nå Key Vault via en konfigurerad privat länkanslutning.

5. Om brandväggen tillåter anropet anropar Key Vault Microsoft Entra ID för att verifiera säkerhetsobjektets åtkomsttoken.

6. Key Vault kontrollerar om säkerhetsprincipalen har nödvändig behörighet för den begärda åtgärden. Annars returnerar Key Vault ett förbjudet svar.

7. Key Vault utför den begärda åtgärden och returnerar resultatet.

Följande diagram illustrerar processen för ett program som anropar ett Key Vault "Hämta hemlighet"-API:

Autentisering mot Key Vault i programkod

Key Vault SDK använder Azure Identity-klientbiblioteket, vilket möjliggör sömlös autentisering till Key Vault över olika miljöer med samma kod.

Azure Identity-klientbibliotek

Mer information om bästa praxis och utvecklarexempel finns i Autentisera till Key Vault i kod

Nästa steg

• Key Vault utvecklarguide

• Tilldela en Key Vault åtkomstpolicy

• Tilldela Azure RBAC-roll till Key Vault

• Felsökning av Key Vault-åtkomstpolicy

• Key Vault REST API-felkoder

• Vad är Azure rollbaserad åtkomstkontroll (Azure RBAC)?