Azure Key Vault-säkerhet

Artikel
01/30/2024

Azure Key Vault skyddar kryptografiska nycklar, certifikat (och de privata nycklar som är associerade med certifikaten) och hemligheter (till exempel anslutningssträng och lösenord) i molnet. När du lagrar känsliga och affärskritiska data måste du dock vidta åtgärder för att maximera säkerheten för dina valv och de data som lagras i dem.

Den här artikeln innehåller en översikt över säkerhetsfunktioner och metodtips för Azure Key Vault.

Kommentar

En omfattande lista över säkerhetsrekommendationer för Azure Key Vault finns i Säkerhetsbaslinje för Azure Key Vault.

Nätverkssäkerhet

Du kan minska exponeringen för dina valv genom att ange vilka IP-adresser som har åtkomst till dem. Med tjänstslutpunkterna för virtuella nätverk för Azure Key Vault kan du begränsa åtkomsten till ett angivet virtuellt nätverk. Med slutpunkterna kan du också begränsa åtkomsten till en lista över adressintervall för IPv4 (Internet Protocol version 4). Alla användare som ansluter till ditt nyckelvalv utanför dessa källor nekas åtkomst. Fullständig information finns i Tjänstslutpunkter för virtuellt nätverk för Azure Key Vault

När brandväggsregler är i kraft kan användarna bara läsa data från Key Vault när deras begäranden kommer från tillåtna virtuella nätverk eller IPv4-adressintervall. Detta gäller även för åtkomst till Key Vault från Azure-portalen. Även om användarna kan bläddra till ett nyckelvalv från Azure-portalen kanske de inte kan visa nycklar, hemligheter eller certifikat om klientdatorn inte finns med i listan över tillåtna. Implementeringssteg finns i Konfigurera Azure Key Vault-brandväggar och virtuella nätverk

Med Azure Private Link Service kan du komma åt Azure Key Vault och Azure-värdbaserade kund-/partnertjänster via en privat slutpunkt i ditt virtuella nätverk. En privat Azure-slutpunkt är ett nätverksgränssnitt som ansluter dig privat och säkert till en tjänst som drivs av Azure Private Link. Den privata slutpunkten använder en privat IP-adress från ditt virtuella nätverk som effektivt flyttar tjänsten till ditt virtuella nätverk. All trafik till tjänsten kan dirigeras via den privata slutpunkten, så inga gatewayer, NAT-enheter, ExpressRoute- eller VPN-anslutningar, eller offentliga IP-adresser behövs. Trafik mellan ditt virtuella nätverk och tjänsten passerar över Microsofts stamnätverk, vilket eliminerar exponering från det offentliga Internet. Du kan ansluta till en instans av en Azure-resurs, vilket ger dig den högsta detaljnivån i åtkomstkontrollen. Implementeringssteg finns i Integrera Key Vault med Azure Private Link

TLS och HTTPS

Key Vault-klientdelen (dataplanet) är en server med flera klientorganisationer. Det innebär att nyckelvalv från olika kunder kan dela samma offentliga IP-adress. För att uppnå isolering autentiseras och auktoriseras varje HTTP-begäran oberoende av andra begäranden.
MED HTTPS-protokollet kan klienten delta i TLS-förhandling. Klienter kan framtvinga versionen av TLS, och när en klient gör det använder hela anslutningen motsvarande nivåskydd. Key Vault stöder TLS 1.2- och 1.3-protokollversioner.

Kommentar

Du kan övervaka TLS-versionen som används av klienter genom att övervaka Key Vault-loggar med kusto-exempelfrågan här.

Alternativ för Key Vault-autentisering

När du skapar ett nyckelvalv i en Azure-prenumeration associeras det automatiskt med Prenumerationens Microsoft Entra-klientorganisation. Alla uppringare i båda planen måste registrera sig i den här klientorganisationen och autentiseras för att få åtkomst till nyckelvalvet. I båda fallen kan program komma åt Key Vault på tre sätt:

Endast program: Programmet representerar tjänstens huvudnamn 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 det här scenariot ska fungera objectId måste programmet anges i åtkomstprincipen applicationId och får inte anges eller måste vara null.
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 objectId måste användarens anges i åtkomstprincipen applicationId och får inte anges eller måste vara null.
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 måste både 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 Data Plane 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 extra säkerhet.

Mer information finns i Grunderna för Key Vault-autentisering.

Översikt över åtkomstmodell

Åtkomst till ett nyckelvalv styrs via två gränssnitt: hanteringsplanet och dataplanet. Hanteringsplanet är där du hanterar Själva Nyckelvalvet. Åtgärder i det här planet omfattar att skapa och ta bort nyckelvalv, hämta Key Vault-egenskaper och uppdatera åtkomstprinciper. Dataplanet är där du arbetar med data som lagras i ett nyckelvalv. Du kan lägga till, ta bort och ändra nycklar, hemligheter och certifikat.

Båda planen använder Microsoft Entra-ID för autentisering. För auktorisering använder hanteringsplanet rollbaserad åtkomstkontroll i Azure (Azure RBAC) och dataplanet använder en Key Vault-åtkomstprincip och Azure RBAC för key vault-dataplansåtgärder.

För att få åtkomst till ett nyckelvalv i något av plan måste alla anropare (användare eller program) ha rätt autentisering och auktorisering. Autentisering upprättar anroparens identitet. Auktorisering avgör vilka åtgärder anroparen kan köra. Autentisering med Key Vault fungerar tillsammans med Microsoft Entra-ID, som ansvarar för att autentisera identiteten för ett visst säkerhetsobjekt.

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 ett unikt objekt-ID till varje säkerhetsobjekt.

Ett huvudnamn för användarsäkerhet identifierar en person som har en profil i Microsoft Entra-ID.
Ett huvudnamn för gruppsäkerhet 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 kallas dess klient-ID och fungerar som dess användarnamn. Tjänstens huvudnamns klienthemlighet eller certifikat fungerar som dess lösenord. Många Azure-tjänster stöder tilldelning av hanterad identitet med automatiserad hantering av klient-ID och certifikat. Hanterad identitet är det säkraste och rekommenderade alternativet för autentisering i Azure.

Mer information om autentisering till Key Vault finns i Autentisera till Azure Key Vault.

Villkorlig åtkomst

Key Vault har stöd för principer för villkorsstyrd åtkomst i Microsoft Entra. Genom att använda principer för villkorsstyrd åtkomst kan du använda rätt åtkomstkontroller för Key Vault när det behövs för att skydda din organisation och hålla dig borta från användaren när det inte behövs.

Mer information finns i Översikt över villkorsstyrd åtkomst

Privilegierad åtkomst

Auktorisering avgör vilka åtgärder anroparen kan utföra. Auktorisering i Key Vault använder rollbaserad åtkomstkontroll i Azure (Azure RBAC) på hanteringsplan och åtkomstprinciper för Azure RBAC eller Azure Key Vault på dataplanet.

Åtkomsten till valv sker via två gränssnitt eller plan. De här planen är hanteringsplanet och dataplanet.

Hanteringsplanet är där du hanterar Själva Nyckelvalvet och det är gränssnittet som används för att skapa och ta bort valv. Du kan också läsa nyckelvalvets egenskaper och hantera åtkomstprinciper.
Med dataplanet kan du arbeta med data som lagras i ett nyckelvalv. Du kan lägga till, ta bort och ändra nycklar, hemligheter och certifikat.

Program får åtkomst till planen via slutpunkter. Åtkomstkontrollerna för de två planen fungerar oberoende av varandra. Om du vill ge ett program åtkomst till att använda nycklar i ett nyckelvalv ger du åtkomst till dataplanet med hjälp av Azure RBAC eller en Key Vault-åtkomstprincip. Om du vill ge en användare läsåtkomst till Key Vault-egenskaper och -taggar, men inte åtkomst till data (nycklar, hemligheter eller certifikat), ger du åtkomst till hanteringsplanet med Azure RBAC.

I följande tabell visas slutpunkterna för hanterings- och dataplan.

Åtkomstplan	Slutpunkter för åtkomst	Operations	Åtkomstkontrollmekanismer
Hanteringsplanet	Globalt: management.azure.com:443 Microsoft Azure drivs av 21Vianet: management.chinacloudapi.cn:443 Azure för amerikanska myndigheter: management.usgovcloudapi.net:443 Azure i Tyskland: management.microsoftazure.de:443	Skapa, läsa, uppdatera och ta bort nyckelvalv Ange åtkomstprinciper för Key Vault Ange Key Vault-taggar	Azure RBAC
Dataplanet	Globalt: <vault-name>.vault.azure.net:443 Microsoft Azure drivs av 21Vianet: <vault-name>.vault.azure.cn:443 Azure för amerikanska myndigheter: <vault-name>.vault.usgovcloudapi.net:443 Azure i Tyskland: <vault-name>.vault.microsoftazure.de:443	Nycklar: kryptera, dekryptera, wrapKey, unwrapKey, signera, verifiera, hämta, lista, skapa, uppdatera, importera, ta bort, återställa, säkerhetskopiera, återställa, rensa, rotera (förhandsversion), getrotationpolicy (förhandsversion), setrotationpolicy (förhandsversion), release(förhandsversion) Certifikat: managecontacts, getissuers, listissuers, setissuers, deleteissuers, manageissuers, get, list, create, import, update, delete, recover, backup, restore, purge Hemligheter: get, list, set, delete,recover, backup, restore, purge	Åtkomstprincip för Key Vault eller Azure RBAC

Hantera administrativ åtkomst till Key Vault

När du skapar ett nyckelvalv i en resursgrupp hanterar du åtkomst med hjälp av Microsoft Entra-ID. Du ger användare eller grupper möjlighet att hantera nyckelvalv i en resursgrupp. Du kan bevilja åtkomst på en specifik omfångsnivå genom att tilldela lämpliga Azure-roller. Om du vill ge åtkomst till en användare för att hantera nyckelvalv tilldelar du en fördefinierad key vault Contributor roll till användaren i ett specifikt omfång. Följande omfångsnivåer kan tilldelas till en Azure-roll:

Prenumeration: En Azure-roll som tilldelats på prenumerationsnivå gäller för alla resursgrupper och resurser i den prenumerationen.
Resursgrupp: En Azure-roll som tilldelats på resursgruppsnivå gäller för alla resurser i den resursgruppen.
Specifik resurs: En Azure-roll som tilldelats för en specifik resurs gäller för den resursen. I det här fallet är resursen ett specifikt nyckelvalv.

Det finns flera fördefinierade roller. Om en fördefinierad roll inte passar dina behov kan du definiera din egen roll. Mer information finns i Azure RBAC: Inbyggda rollermed

Viktigt!

Om en användare har Contributor, Key Vault Contributor eller någon annan roll med Microsoft.KeyVault/vaults/write behörigheter till ett nyckelvalvshanteringsplan, kan användaren ge sig själva åtkomst till dataplanet genom att ange en åtkomstprincip för Key Vault när du använder behörighetsmodellen Åtkomstprincip för åtkomst till ett nyckelvalv. Du bör noga kontrollera vem som har Contributor rollåtkomst till dina nyckelvalv med behörighetsmodellen Åtkomstprincip för att säkerställa att endast behöriga personer kan komma åt och hantera dina nyckelvalv, nycklar, hemligheter och certifikat. Vi rekommenderar att du använder den nya RBAC-behörighetsmodellen (Rollbaserad åtkomstkontroll) för att undvika det här problemet. Med RBAC som behörighetsmodell är behörighetshanteringen begränsad till rollerna Ägare och Administratör för användaråtkomst, så att du kan dela upp ansvarsområden mellan roller för säkerhetsåtgärder och allmän administration.

Styra åtkomsten till Key Vault-data

Du kan styra åtkomsten till Key Vault-nycklar, certifikat och hemligheter med hjälp av Azure RBAC- eller Key Vault-åtkomstprinciper.

Mer information finns i

Loggning och övervakning

Key Vault-loggning sparar information om de aktiviteter som utförs i valvet. Fullständig information finns i Key Vault-loggning.

Du kan integrera Key Vault med Event Grid för att meddelas när statusen för en nyckel, ett certifikat eller en hemlighet som lagras i nyckelvalvet har ändrats. Mer information finns i Övervaka Key Vault med Azure Event Grid

Det är också viktigt att övervaka hälsotillståndet för ditt nyckelvalv för att se till att tjänsten fungerar som avsett. Mer information om hur du gör det finns i Övervakning och aviseringar för Azure Key Vault.

Säkerhetskopiering och återställning

Med skydd mot mjuk borttagning och rensning i Azure Key Vault kan du återställa borttagna valv och valvobjekt. Fullständig information finns i Översikt över mjuk borttagning av Azure Key Vault.

Du bör också ta regelbundna säkerhetskopieringar av valvet vid uppdatering/borttagning/skapande av objekt i ett valv.