Konfigurera kundhanterade nycklar mellan klientorganisationer för ditt Azure Cosmos DB-konto med Azure Key Vault
GÄLLER FÖR: NoSQL MongoDB Kassandra Gremlin Bord
Data som lagras i ditt Azure Cosmos DB-konto krypteras automatiskt och sömlöst med tjänsthanterade nycklar som hanteras av Microsoft. Du kan dock välja att lägga till ett andra krypteringslager med nycklar som du hanterar. Dessa nycklar kallas kundhanterade nycklar (eller CMK). Kundhanterade nycklar lagras i en Azure Key Vault-instans.
Den här artikeln beskriver hur du konfigurerar kryptering med kundhanterade nycklar när du skapar ett Azure Cosmos DB-konto. I det här scenariot med flera klientorganisationer finns Azure Cosmos DB-kontot i en klientorganisation som hanteras av en oberoende programvaruleverantör (ISV) som kallas tjänstleverantör. Nyckeln som används för kryptering av Azure Cosmos DB-kontot finns i ett nyckelvalv i en annan klientorganisation som hanteras av kunden.
Om kundhanterade nycklar mellan klientorganisationer
Många tjänsteleverantörer som skapar SaaS-erbjudanden (Software as a Service) i Azure vill erbjuda sina kunder möjlighet att hantera sina egna krypteringsnycklar. Med kundhanterade nycklar kan en tjänstleverantör kryptera kundens data med hjälp av en krypteringsnyckel som hanteras av tjänsteleverantörens kund och som inte är tillgänglig för tjänstleverantören. I Azure kan tjänsteleverantörens kund använda Azure Key Vault för att hantera sina krypteringsnycklar i sin egen Microsoft Entra-klientorganisation och prenumeration.
Azure-plattformstjänster och resurser som ägs av tjänstleverantören och som finns i tjänstleverantörens klientorganisation kräver åtkomst till nyckeln från kundens klientorganisation för att utföra krypterings-/dekrypteringsåtgärderna.
Bilden nedan visar en vilande datakryptering med federerad identitet i ett CMK-arbetsflöde mellan klientorganisationer som sträcker sig över en tjänstleverantör och dess kund.
I exemplet ovan finns det två Microsoft Entra-klienter: en oberoende tjänstleverantörs klientorganisation (klientorganisation 1) och en kunds klientorganisation (klientorganisation 2). Klientorganisation 1 är värd för Azure-plattformstjänster och Klientorganisation 2 är värd för kundens nyckelvalv.
En programregistrering för flera klienter skapas av tjänstleverantören i klientorganisation 1. En federerad identitetsautentiseringsuppgift skapas i det här programmet med hjälp av en användartilldelad hanterad identitet. Sedan delas appens namn och program-ID med kunden.
En användare med rätt behörighet installerar tjänstleverantörens program i kundklientorganisationen, Klient 2. En användare ger sedan tjänstens huvudnamn som är associerat med det installerade programmet åtkomst till kundens nyckelvalv. Kunden lagrar även krypteringsnyckeln, eller den kundhanterade nyckeln, i nyckelvalvet. Kunden delar nyckelplatsen (nyckelns URL) med tjänstleverantören.
Tjänstleverantören har nu:
- Ett program-ID för ett program med flera klienter installerat i kundens klientorganisation, som har beviljats åtkomst till den kundhanterade nyckeln.
- En hanterad identitet som konfigurerats som autentiseringsuppgifter i programmet för flera klientorganisationer.
- Platsen för nyckeln i kundens nyckelvalv.
Med dessa tre parametrar etablerar tjänstleverantören Azure-resurser i Klientorganisation 1 som kan krypteras med den kundhanterade nyckeln i klientorganisation 2.
Nu ska vi dela upp lösningen ovan från slutpunkt till slutpunkt i tre faser:
- Tjänstleverantören konfigurerar identiteter.
- Kunden ger tjänstleverantörens app med flera klientorganisationer åtkomst till en krypteringsnyckel i Azure Key Vault.
- Tjänstleverantören krypterar data i en Azure-resurs med hjälp av CMK.
Åtgärder i fas 1 skulle vara en engångskonfiguration för de flesta tjänstleverantörsprogram. Åtgärder i fas 2 och 3 upprepas för varje kund.
Fas 1 – Tjänstleverantören konfigurerar ett Microsoft Entra-program
Steg | beskrivning | Minsta roll i Azure RBAC | Minsta roll i Microsoft Entra RBAC |
---|---|---|---|
1. | Skapa en ny microsoft entra-programregistrering för flera användare eller börja med en befintlig programregistrering. Observera program-ID (klient-ID) för programregistreringen med hjälp av Azure Portal, Microsoft Graph API, Azure PowerShell eller Azure CLI | Ingen | Programutvecklare |
2. | Skapa en användartilldelad hanterad identitet (som ska användas som en federerad identitetsautentisering). Azure Portal Azure CLI / Azure PowerShell/ Azure Resource Manager-mallar / |
Hanterad identitetsdeltagare | Ingen |
3. | Konfigurera användartilldelad hanterad identitet som en federerad identitetsautentiseringsuppgift i programmet, så att den kan personifiera programmets identitet. Graph API-referens/ Azure Portal/ Azure CLI/ Azure PowerShell |
Ingen | Programmets ägare |
4. | Dela programnamnet och program-ID:t med kunden så att de kan installera och auktorisera programmet. | Ingen | Ingen |
Överväganden för tjänsteleverantörer
- Azure Resource Manager-mallar (ARM) rekommenderas inte för att skapa Microsoft Entra-program.
- Samma program för flera klienter kan användas för att komma åt nycklar i valfritt antal klienter, till exempel klientorganisation 2, klientorganisation 3, klientorganisation 4 och så vidare. I varje klientorganisation skapas en oberoende instans av programmet som har samma program-ID men ett annat objekt-ID. Varje instans av det här programmet godkänns därför oberoende av varandra. Fundera på hur programobjektet som används för den här funktionen används för att partitionera programmet mellan alla kunder.
- Programmet kan ha högst 20 federerade identitetsuppgifter, vilket kräver att en tjänstleverantör delar federerade identiteter mellan sina kunder. Mer information om designöverväganden och begränsningar för federerade identiteter finns i Konfigurera en app för att lita på en extern identitetsprovider
- I sällsynta fall kan en tjänstleverantör använda ett enda programobjekt per kund, men det kräver betydande underhållskostnader för att hantera program i stor skala för alla kunder.
- I tjänstleverantörens klientorganisation går det inte att automatisera utgivarverifieringen.
Fas 2 – Kunden auktoriserar åtkomst till nyckelvalvet
Steg | beskrivning | Minst privilegierade Azure RBAC-roller | Minst privilegierade Microsoft Entra-roller |
---|---|---|---|
1. | Ingen | Användare med behörighet att installera program | |
2. | Skapa ett Azure Key Vault och en nyckel som används som kundhanterad nyckel. | En användare måste tilldelas rollen Key Vault-deltagare för att kunna skapa nyckelvalvet En användare måste tilldelas rollen Key Vault Crypto Officer för att lägga till en nyckel i nyckelvalvet |
Ingen |
3. | Ge den medgivande programidentiteten åtkomst till Azure-nyckelvalvet genom att tilldela rollen Key Vault Crypto Service Encryption User | Om du vill tilldela key vault-krypteringstjänstens användarroll till programmet måste du ha tilldelats rollen Administratör för användaråtkomst. | Ingen |
4. | Kopiera nyckelvalvets URL och nyckelnamn till konfigurationen av kundhanterade nycklar för SaaS-erbjudandet. | Ingen | Ingen |
Kommentar
Om du vill auktorisera åtkomst till Managed HSM för kryptering med hjälp av CMK kan du läsa exempel för Lagringskonto här. Mer information om hur du hanterar nycklar med Hanterad HSM finns i Hantera en hanterad HSM med Hjälp av Azure CLI
Överväganden för kunder hos tjänsteleverantörer
- I kundens klientorganisation, Klientorganisation 2, kan en administratör ange principer för att blockera användare som inte är administratörer från att installera program. Dessa principer kan hindra användare som inte är administratörer från att skapa tjänstens huvudnamn. Om en sådan princip har konfigurerats måste användare med behörighet att skapa tjänstens huvudnamn vara inblandade.
- Åtkomst till Azure Key Vault kan auktoriseras med hjälp av Azure RBAC eller åtkomstprinciper. När du beviljar åtkomst till ett nyckelvalv bör du använda den aktiva mekanismen för ditt nyckelvalv.
- En Microsoft Entra-programregistrering har ett program-ID (klient-ID). När programmet installeras i klientorganisationen skapas ett huvudnamn för tjänsten. Tjänstens huvudnamn delar samma program-ID som appregistreringen, men genererar ett eget objekt-ID. När du ger programmet åtkomst till resurser kan du behöva använda tjänstens huvudnamn
Name
ellerObjectID
egenskap.
Fas 3 – Tjänstleverantören krypterar data i en Azure-resurs med hjälp av den kundhanterade nyckeln
När fas 1 och 2 har slutförts kan tjänstleverantören konfigurera kryptering på Azure-resursen med nyckel- och nyckelvalvet i kundens klientorganisation och Azure-resursen i ISV:s klientorganisation. Tjänstleverantören kan konfigurera kundhanterade nycklar mellan klientorganisationer med de klientverktyg som stöds av den Azure-resursen, med en ARM-mall eller med REST-API:et.
Konfigurera kundhanterade nycklar mellan klientorganisationer
I det här avsnittet beskrivs hur du konfigurerar en kundhanterad nyckel för flera klientorganisationer (CMK) och krypterar kunddata. Du lär dig hur du krypterar kunddata i en resurs i Tenant1 med hjälp av en CMK som lagras i ett nyckelvalv i Tenant2. Du kan använda Azure Portal, Azure PowerShell eller Azure CLI.
Logga in på Azure Portal och följ dessa steg.
Tjänstleverantören konfigurerar identiteter
Följande steg utförs av tjänstleverantören i tjänstleverantörens klientorganisation 1.
Tjänstleverantören skapar en ny appregistrering för flera klientorganisationer
Du kan antingen skapa en ny Microsoft Entra-programregistrering för flera klientorganisationer eller börja med en befintlig programregistrering för flera klientorganisationer. Om du börjar med en befintlig programregistrering bör du notera programmets program-ID (klient-ID).
Så här skapar du en ny registrering:
Sök efter Microsoft Entra-ID i sökrutan. Leta upp och välj Microsoft Entra ID-tillägget .
Välj Hantera > Appregistreringar i det vänstra fönstret.
Välj + Ny registrering.
Ange namnet på programregistreringen och välj Konto i valfri organisationskatalog (Alla Microsoft Entra-kataloger – Multitenant).
Välj Registrera.
Observera ApplicationId/ClientId för programmet.
Tjänstleverantören skapar en användartilldelad hanterad identitet
Skapa en användartilldelad hanterad identitet som ska användas som en federerad identitetsautentiseringsuppgift.
Sök efter hanterade identiteter i sökrutan. Leta upp och välj tillägget Hanterade identiteter .
Välj + Skapa.
Ange resursgruppen, regionen och namnet för den hanterade identiteten.
Välj Granska + skapa.
Observera Azure ResourceId för den användartilldelade hanterade identiteten vid lyckad distribution, som är tillgängligt under Egenskaper. Till exempel:
/subscriptions/tttttttt-0000-tttt-0000-tttt0000tttt/resourcegroups/XTCMKDemo/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ConsotoCMKDemoUA
Tjänstleverantören konfigurerar den användartilldelade hanterade identiteten som en federerad autentiseringsuppgift i programmet
Konfigurera en användartilldelad hanterad identitet som en federerad identitetsautentiseringsuppgift i programmet så att den kan personifiera programmets identitet.
Gå till Microsoft Entra-ID > Appregistreringar > ditt program.
Välj Certifikat och hemligheter.
Välj Federerade autentiseringsuppgifter.
Välj + Lägg till autentiseringsuppgifter.
Under Scenario med federerade autentiseringsuppgifter väljer du Kundhanterade nycklar.
Klicka på Välj en hanterad identitet. Välj prenumerationen i fönstret. Under Hanterad identitet väljer du Användartilldelad hanterad identitet. I rutan Välj söker du efter den hanterade identitet som du skapade tidigare och klickar sedan på Välj längst ned i fönstret.
Under Information om autentiseringsuppgifter anger du ett namn och en valfri beskrivning för autentiseringsuppgifterna och väljer Lägg till.
Tjänstleverantören delar program-ID:t med kunden
Hitta program-ID :t (klient-ID) för programmet för flera klientorganisationer och dela det med kunden.
Kunden ger tjänstleverantörens app åtkomst till nyckeln i nyckelvalvet
Följande steg utförs av kunden i kundens klientorganisation 2. Kunden kan använda Azure Portal, Azure PowerShell eller Azure CLI.
Användaren som kör stegen måste vara en administratör med en privilegierad roll, till exempel programadministratör, molnprogramadministratör eller global administratör.
Logga in på Azure Portal och följ dessa steg.
Kunden installerar tjänstproviderprogrammet i kundens klientorganisation
Om du vill installera tjänstleverantörens registrerade program i kundens klientorganisation skapar du ett huvudnamn för tjänsten med program-ID:t från den registrerade appen. Du kan skapa tjänstens huvudnamn på något av följande sätt:
- Använd Microsoft Graph, Microsoft Graph PowerShell, Azure PowerShell eller Azure CLI för att skapa tjänstens huvudnamn manuellt.
- Skapa en URL för administratörsmedgivande och bevilja klientomfattande medgivande för att skapa tjänstens huvudnamn. Du måste ange app-ID:et för dem.
Kunden skapar ett nyckelvalv
Om du vill skapa nyckelvalvet måste användarens konto tilldelas rollen Key Vault-deltagare eller en annan roll som gör det möjligt att skapa ett nyckelvalv.
På menyn Azure Portal eller på startsidan väljer du + Skapa en resurs. I sökrutan anger du Nyckelvalv. I resultatlistan väljer du Nyckelvalv. På sidan Nyckelvalv väljer du Skapa.
På fliken Grundläggande väljer du en prenumeration. Under Resursgrupp väljer du Skapa ny och anger ett resursgruppsnamn.
Ange ett unikt namn för nyckelvalvet.
Välj en region och prisnivå.
Aktivera rensningsskydd för det nya nyckelvalvet.
På fliken Åtkomstprincip väljer du Rollbaserad åtkomstkontroll i Azure för Behörighetsmodell.
Välj Granska + skapa och sedan Skapa.
Anteckna namnet på nyckelvalvet och URI-program som har åtkomst till ditt nyckelvalv måste använda den här URI:n.
Mer information finns i Snabbstart – Skapa ett Azure Key Vault med Azure Portal.
Kunden tilldelar Key Vault Crypto Officer-rollen till ett användarkonto
Det här steget säkerställer att du kan skapa krypteringsnycklar.
- Gå till nyckelvalvet och välj Åtkomstkontroll (IAM) i den vänstra rutan.
- Under Bevilja åtkomst till denna resurs väljer du Lägg till rolltilldelning.
- Sök efter och välj Key Vault Crypto Officer.
- Under Medlemmar väljer du Användare, grupp eller tjänstens huvudnamn.
- Välj Medlemmar och sök efter ditt användarkonto.
- Välj Granska + tilldela.
Kunden skapar en krypteringsnyckel
För att kunna skapa krypteringsnyckeln måste användarens konto tilldelas rollen Key Vault Crypto Officer eller en annan roll som gör det möjligt att skapa en nyckel.
- På sidan Key Vault-egenskaper väljer du Nycklar.
- Välj Generera/Importera.
- På skärmen Skapa en nyckel anger du ett namn för nyckeln. Lämna standardvärdena för de andra alternativen.
- Välj Skapa.
- Kopiera nyckel-URI:n.
Kunden ger tjänstleverantörsprogrammet åtkomst till nyckelvalvet
Tilldela Azure RBAC-rollen Key Vault Crypto Service Encryption User till tjänstleverantörens registrerade program så att det kan komma åt nyckelvalvet.
- Gå till nyckelvalvet och välj Åtkomstkontroll (IAM) i den vänstra rutan.
- Under Bevilja åtkomst till denna resurs väljer du Lägg till rolltilldelning.
- Sök efter och välj Key Vault Crypto Service Encryption User( Key Vault Crypto Service Encryption User).
- Under Medlemmar väljer du Användare, grupp eller tjänstens huvudnamn.
- Välj Medlemmar och sök efter programnamnet för det program som du installerade från tjänstleverantören.
- Välj Granska + tilldela.
Nu kan du konfigurera kundhanterade nycklar med nyckelvalvets URI och nyckel.
Skapa ett nytt Azure Cosmos DB-konto krypterat med en nyckel från en annan klientorganisation
Fram tills nu har du konfigurerat programmet för flera klientorganisationer i tjänstleverantörens klientorganisation. Du har också installerat programmet på kundens klientorganisation och konfigurerat nyckelvalvet och nyckeln i kundens klientorganisation. Sedan kan du skapa ett Azure Cosmos DB-konto på tjänstleverantörens klientorganisation och konfigurera kundhanterade nycklar med nyckeln från kundens klientorganisation.
När du skapar ett Azure Cosmos DB-konto med kundhanterade nycklar måste vi se till att det har åtkomst till de nycklar som kunden använde. I scenarier med en klientorganisation ger du antingen direkt åtkomst till nyckelvalvet till Azure Cosmos DB-huvudkontot eller använder en specifik hanterad identitet. I ett scenario mellan klientorganisationer kan vi inte längre vara beroende av direkt åtkomst till nyckelvalvet som i en annan klientorganisation som hanteras av kunden. Den här begränsningen är orsaken till att vi i föregående avsnitt skapade ett program mellan klientorganisationer och registrerade en hanterad identitet i programmet för att ge den åtkomst till kundens nyckelvalv. Den här hanterade identiteten, tillsammans med program-ID:t för flera klientorganisationer, är det vi använder när vi skapar CMK:t för flera klientorganisationer i Azure Cosmos DB-kontot. Mer information finns i Avsnittet Fas 3 – Tjänstleverantören krypterar data i en Azure-resurs med hjälp av avsnittet kundhanterad nyckel i den här artikeln.
När en ny version av nyckeln är tillgänglig i nyckelvalvet uppdateras den automatiskt på Azure Cosmos DB-kontot.
Använda Azure Resource Manager JSON-mallar
Distribuera en ARM-mall med följande specifika parametrar:
Kommentar
Om du återskapar det här exemplet i en av dina Azure Resource Manager-mallar använder du en apiVersion
av 2022-05-15
.
Parameter | Description | Exempelvärde |
---|---|---|
keyVaultKeyUri |
Identifierare för den kundhanterade nyckel som finns i tjänstleverantörens nyckelvalv. | https://my-vault.vault.azure.com/keys/my-key |
identity |
Objekt som anger att den hanterade identiteten ska tilldelas till Azure Cosmos DB-kontot. | "identity":{"type":"UserAssigned","userAssignedIdentities":{"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity":{}}} |
defaultIdentity |
Kombination av resurs-ID för den hanterade identiteten och program-ID för Microsoft Entra-programmet för flera klientorganisationer. | UserAssignedIdentity=/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity&FederatedClientId=aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e |
Här är ett exempel på ett mallsegment med de tre parametrarna konfigurerade:
{
"kind": "GlobalDocumentDB",
"location": "East US 2",
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity": {}
}
},
"properties": {
"locations": [
{
"locationName": "East US 2",
"failoverPriority": 0,
"isZoneRedundant": false
}
],
"databaseAccountOfferType": "Standard",
"keyVaultKeyUri": "https://my-vault.vault.azure.com/keys/my-key",
"defaultIdentity": "UserAssignedIdentity=/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity&FederatedClientId=aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e"
}
}
Viktigt!
Den här funktionen stöds ännu inte i Azure PowerShell, Azure CLI eller i Azure Portal.
Du kan inte konfigurera kundhanterade nycklar med en specifik version av nyckelversionen när du skapar ett nytt Azure Cosmos DB-konto. Själva nyckeln måste skickas utan versioner och inga avslutande omvänt snedstreck.
Information om hur du återkallar eller inaktiverar kundhanterade nycklar finns i Konfigurera kundhanterade nycklar för ditt Azure Cosmos DB-konto med Azure Key Vault