Share via

Door de klant beheerde sleutels voor meerdere tenants configureren voor uw Azure Cosmos DB-account met Azure Key Vault

  • Artikel

VAN TOEPASSING OP: Nosql MongoDB Cassandra Gremlin Tabel

Gegevens die zijn opgeslagen in uw Azure Cosmos DB-account, worden automatisch en naadloos versleuteld met door de service beheerde sleutels die worden beheerd door Microsoft. U kunt er echter voor kiezen om een tweede versleutelingslaag toe te voegen met sleutels die u beheert. Deze sleutels worden door de klant beheerde sleutels (of CMK) genoemd. Door de klant beheerde sleutels worden opgeslagen in een Azure Key Vault-exemplaar.

In dit artikel wordt uitgelegd hoe u versleuteling configureert met door de klant beheerde sleutels op het moment dat u een Azure Cosmos DB-account maakt. In dit voorbeeld scenario voor meerdere tenants bevindt het Azure Cosmos DB-account zich in een tenant die wordt beheerd door een onafhankelijke softwareleverancier (ISV) die de serviceprovider wordt genoemd. De sleutel die wordt gebruikt voor versleuteling van het Azure Cosmos DB-account, bevindt zich in een sleutelkluis in een andere tenant die wordt beheerd door de klant.

Over door de klant beheerde sleutels voor meerdere tenants

Veel serviceproviders die SaaS-aanbiedingen (Software as a Service) bouwen in Azure willen hun klanten de mogelijkheid bieden om hun eigen versleutelingssleutels te beheren. Met door de klant beheerde sleutels kan een serviceprovider de gegevens van de klant versleutelen met behulp van een versleutelingssleutel die wordt beheerd door de klant van de serviceprovider en die niet toegankelijk is voor de serviceprovider. In Azure kan de klant van de serviceprovider Azure Key Vault gebruiken om hun versleutelingssleutels te beheren in hun eigen Microsoft Entra-tenant en -abonnement.

Azure-platformservices en -resources die eigendom zijn van de serviceprovider en die zich in de tenant van de serviceprovider bevinden, vereisen toegang tot de sleutel van de tenant van de klant om de versleutelings-/ontsleutelingsbewerkingen uit te voeren.

In de onderstaande afbeelding ziet u een data-at-rest-versleuteling met federatieve identiteit in een CMK-werkstroom voor meerdere tenants voor een serviceprovider en de klant.

Screenshot showing a cross-tenant CMK with a federated identity.

In het bovenstaande voorbeeld zijn er twee Microsoft Entra-tenants: de tenant van een onafhankelijke serviceprovider (tenant 1) en de tenant van een klant (tenant 2). Tenant 1 fungeert als host voor Azure-platformservices en Tenant 2 als host voor de sleutelkluis van de klant.

Er wordt een registratie van meerdere tenants gemaakt door de serviceprovider in Tenant 1. Er wordt een federatieve identiteitsreferentie voor deze toepassing gemaakt met behulp van een door de gebruiker toegewezen beheerde identiteit. Vervolgens wordt de naam en toepassings-id van de app gedeeld met de klant.

Een gebruiker met de juiste machtigingen installeert de toepassing van de serviceprovider in de tenant van de klant, Tenant 2. Een gebruiker verleent vervolgens de service-principal die is gekoppeld aan de geïnstalleerde toepassing toegang tot de sleutelkluis van de klant. De klant slaat ook de versleutelingssleutel of door de klant beheerde sleutel op in de sleutelkluis. De klant deelt de sleutellocatie (de URL van de sleutel) met de serviceprovider.

De serviceprovider heeft nu:

  • Een toepassings-id voor een toepassing met meerdere tenants die is geïnstalleerd in de tenant van de klant, die toegang heeft gekregen tot de door de klant beheerde sleutel.
  • Een beheerde identiteit die is geconfigureerd als de referentie in de multitenant-toepassing.
  • De locatie van de sleutel in de sleutelkluis van de klant.

Met deze drie parameters richt de serviceprovider Azure-resources in tenant 1 in die kunnen worden versleuteld met de door de klant beheerde sleutel in Tenant 2.

Laten we de bovenstaande end-to-end-oplossing in drie fasen verdelen:

  1. De serviceprovider configureert identiteiten.
  2. De klant verleent de multitenant-app van de serviceprovider toegang tot een versleutelingssleutel in Azure Key Vault.
  3. De serviceprovider versleutelt gegevens in een Azure-resource met behulp van de CMK.

Bewerkingen in fase 1 zijn een eenmalige installatie voor de meeste serviceprovidertoepassingen. Bewerkingen in fase 2 en 3 worden voor elke klant herhaald.

Fase 1: de serviceprovider configureert een Microsoft Entra-toepassing

Stap Beschrijving Minimale rol in Azure RBAC Minimale rol in Microsoft Entra RBAC
1. Maak een nieuwe multitenant Microsoft Entra-toepassingsregistratie of begin met een bestaande toepassingsregistratie. Noteer de toepassings-id (client-id) van de toepassingsregistratie met behulp van Azure Portal, Microsoft Graph API, Azure PowerShell of Azure CLI Geen Toepassingsontwikkelaar
2. Maak een door de gebruiker toegewezen beheerde identiteit (te gebruiken als federatieve identiteitsreferentie).
Azure Portal / Azure CLI / Azure PowerShell/ Azure Resource Manager-sjablonen		 Inzender voor beheerde identiteit Geen
3. Configureer door de gebruiker toegewezen beheerde identiteit als federatieve identiteitsreferentie voor de toepassing, zodat deze de identiteit van de toepassing kan imiteren.
Graph API-verwijzing naar Azure Portal/ Azure CLI/ Azure PowerShell/ 		Geen Eigenaar van de toepassing
4. Deel de naam en toepassings-id van de toepassing met de klant, zodat ze de toepassing kunnen installeren en autoriseren. Geen Geen

Overwegingen voor serviceproviders

  • Arm-sjablonen (Azure Resource Manager) worden niet aanbevolen voor het maken van Microsoft Entra-toepassingen.
  • Dezelfde multitenant-toepassing kan worden gebruikt voor toegang tot sleutels in een willekeurig aantal tenants, zoals Tenant 2, Tenant 3, Tenant 4, enzovoort. In elke tenant wordt een onafhankelijk exemplaar van de toepassing gemaakt met dezelfde toepassings-id, maar een andere object-id. Elk exemplaar van deze toepassing wordt dus onafhankelijk geautoriseerd. Overweeg hoe het toepassingsobject dat voor deze functie wordt gebruikt om uw toepassing te partitioneren voor alle klanten.
    • De toepassing kan maximaal 20 federatieve identiteitsreferenties hebben. Hiervoor moet een serviceprovider federatieve identiteiten delen tussen de klanten. Zie Een app configureren om een externe id-provider te vertrouwen voor meer informatie over ontwerpoverwegingen en -beperkingen voor federatieve identiteiten
  • In zeldzame scenario's kan een serviceprovider één toepassingsobject per klant gebruiken, maar waarvoor aanzienlijke onderhoudskosten nodig zijn om toepassingen op schaal te beheren voor alle klanten.
  • In de tenant van de serviceprovider is het niet mogelijk om de verificatie van de uitgever te automatiseren.

Fase 2: de klant autoriseert toegang tot de sleutelkluis

Stap Beschrijving Minst bevoegde Azure RBAC-rollen Microsoft Entra-rollen met minimale bevoegdheden
1.
  • Aanbevolen: de gebruiker verzenden om u aan te melden bij uw app. Als de gebruiker zich kan aanmelden, bestaat er een service-principal voor uw app in de tenant.
  • Gebruik Microsoft Graph, Microsoft Graph PowerShell, Azure PowerShell of Azure CLI om de service-principal te maken.
  • Maak een URL voor beheerderstoestemming en ververleent tenantbrede toestemming om de service-principal te maken met behulp van de toepassings-id.
    		•  Geen Gebruikers met machtigingen voor het installeren van toepassingen
    2. Maak een Azure Key Vault en een sleutel die wordt gebruikt als de door de klant beheerde sleutel. Aan een gebruiker moet de rol Key Vault-inzender zijn toegewezen om de sleutelkluis te maken

    Aan een gebruiker moet de rol Key Vault Crypto Officer worden toegewezen om een sleutel toe te voegen aan de sleutelkluis    		 Geen
    3. Versleutelingsgebruiker van Key Vault cryptoserviceversleutelingsgebruiker toewijzen aan de toepassings-id met toestemming voor de Azure-sleutelkluis Als u de key vault cryptoserviceversleutelingsgebruikersrol wilt toewijzen aan de toepassing, moet u de rol Gebruikerstoegang Beheer istrator hebben toegewezen. Geen
    4. Kopieer de URL en sleutelnaam van de sleutelkluis naar de configuratie van door de klant beheerde sleutels van de SaaS-aanbieding. Geen Geen

    Notitie

    Als u toegang tot de beheerde HSM wilt autoriseren voor versleuteling met behulp van CMK, raadpleegt u hier het voorbeeld voor het opslagaccount. Zie Een beheerde HSM beheren met de Azure CLI voor meer informatie over het beheren van sleutels met beheerde HSM

    Overwegingen voor klanten van serviceproviders

    • In de tenant van de klant, Tenant 2, kan een beheerder beleidsregels instellen om te voorkomen dat niet-beheerders toepassingen installeren. Deze beleidsregels kunnen voorkomen dat niet-beheerders service-principals maken. Als een dergelijk beleid is geconfigureerd, moeten gebruikers met machtigingen voor het maken van service-principals betrokken zijn.
    • Toegang tot Azure Key Vault kan worden geautoriseerd met behulp van Azure RBAC of toegangsbeleid. Wanneer u toegang verleent tot een sleutelkluis, moet u het actieve mechanisme voor uw sleutelkluis gebruiken.
    • Een Registratie van een Microsoft Entra-toepassing heeft een toepassings-id (client-id). Wanneer de toepassing in uw tenant is geïnstalleerd, wordt er een service-principal gemaakt. De service-principal deelt dezelfde toepassings-id als de app-registratie, maar genereert een eigen object-id. Wanneer u de toepassing machtigt om toegang te hebben tot resources, moet u mogelijk de service-principal Name of ObjectID eigenschap gebruiken.

    Fase 3: de serviceprovider versleutelt gegevens in een Azure-resource met behulp van de door de klant beheerde sleutel

    Nadat fase 1 en 2 zijn voltooid, kan de serviceprovider versleuteling voor de Azure-resource configureren met de sleutel en sleutelkluis in de tenant van de klant en de Azure-resource in de tenant van de ISV. De serviceprovider kan door de klant beheerde sleutels voor meerdere tenants configureren met de clienthulpprogramma's die door die Azure-resource worden ondersteund, met een ARM-sjabloon of met de REST API.

    Door de klant beheerde sleutels voor meerdere tenants configureren

    In deze sectie wordt beschreven hoe u een door de klant beheerde sleutel (CMK) voor meerdere tenants configureert en klantgegevens versleutelt. U leert hoe u klantgegevens in een resource in Tenant1 versleutelt met behulp van een CMK die is opgeslagen in een sleutelkluis in Tenant2. U kunt Azure Portal, Azure PowerShell of Azure CLI gebruiken.

    Meld u aan bij Azure Portal en volg deze stappen.

    De serviceprovider configureert identiteiten

    De volgende stappen worden uitgevoerd door de serviceprovider in de tenant tenant1 van de serviceprovider.

    De serviceprovider maakt een nieuwe app-registratie voor meerdere tenants

    U kunt een nieuwe Microsoft Entra-toepassingsregistratie voor meerdere tenants maken of beginnen met een bestaande toepassingsregistratie met meerdere tenants. Als u begint met een bestaande toepassingsregistratie, noteert u de toepassings-id (client-id) van de toepassing.

    Ga als volgt te werk om een nieuwe registratie te maken:

    1. Zoek in het zoekvak naar Microsoft Entra-id. Zoek en selecteer de Extensie Microsoft Entra-id .

    2. Selecteer App-registraties beheren > in het linkerdeelvenster.

    3. Selecteer + Nieuwe registratie.

    4. Geef de naam op voor de registratie van de toepassing en selecteer Account in een organisatiemap (Elke Microsoft Entra-directory – Multitenant).a0>

    5. Selecteer Registreren.

    6. Noteer de ApplicationId/ClientId van de toepassing.

      Screen shot showing how to create a new multi-tenant application registration.

    De serviceprovider maakt een door de gebruiker toegewezen beheerde identiteit

    Maak een door de gebruiker toegewezen beheerde identiteit die moet worden gebruikt als federatieve identiteitsreferentie.

    1. Zoek in het zoekvak naar beheerde identiteiten . Zoek en selecteer de extensie Beheerde identiteiten .

    2. Selecteer + Maken.

    3. Geef de resourcegroep, regio en naam op voor de beheerde identiteit.

    4. Selecteer Controleren + maken.

    5. Let bij een geslaagde implementatie op de Azure ResourceId van de door de gebruiker toegewezen beheerde identiteit, die beschikbaar is onder Eigenschappen. Voorbeeld:

      /subscriptions/tttttttt-0000-tttt-0000-tttt0000tttt/resourcegroups/XTCMKDemo/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ConsotoCMKDemoUA

      Screen shot showing how to create a resource group and a user-assigned managed identity.

    De serviceprovider configureert de door de gebruiker toegewezen beheerde identiteit als federatieve referentie voor de toepassing

    Configureer een door de gebruiker toegewezen beheerde identiteit als federatieve identiteitsreferentie voor de toepassing, zodat deze de identiteit van de toepassing kan imiteren.

    1. Navigeer naar Microsoft Entra ID > App-registraties > uw toepassing.

    2. Selecteer Certificaten en geheimen.

    3. Selecteer Federatieve referenties.

      Screen shot showing how to navigate to Certificate and secrets.

    4. Selecteer + Referentie toevoegen.

    5. Selecteer onder Scenario met federatieve referenties de optie Door klant beheerde sleutels.

    6. Klik op Een beheerde identiteit selecteren. Selecteer het abonnement in het deelvenster. Selecteer onder Beheerde identiteit de door de gebruiker toegewezen beheerde identiteit. Zoek in het vak Selecteren naar de beheerde identiteit die u eerder hebt gemaakt en klik vervolgens onderaan het deelvenster op Selecteren .

      Screen shot showing how to select a managed identity.

    7. Geef onder Referentiegegevens een naam en een optionele beschrijving op voor de referentie en selecteer Toevoegen.

      Screen shot showing how to add a credential.

    De serviceprovider deelt de toepassings-id met de klant

    Zoek de toepassings-id (client-id) van de toepassing met meerdere tenants en deel deze met de klant.

    De klant verleent de app van de serviceprovider toegang tot de sleutel in de sleutelkluis

    De volgende stappen worden uitgevoerd door de klant in de tenant tenant2 van de klant. De klant kan Azure Portal, Azure PowerShell of Azure CLI gebruiken.

    De gebruiker die de stappen uitvoert, moet een beheerder zijn met een bevoorrechte rol, zoals Application Beheer istrator, Cloud Application Beheer istrator of Global Beheer istrator.

    Meld u aan bij Azure Portal en volg deze stappen.

    De klant installeert de toepassing van de serviceprovider in de tenant van de klant

    Als u de geregistreerde toepassing van de serviceprovider in de tenant van de klant wilt installeren, maakt u een service-principal met de toepassings-id van de geregistreerde app. U kunt de service-principal op een van de volgende manieren maken:

    De klant maakt een sleutelkluis

    Als u de sleutelkluis wilt maken, moet het account van de gebruiker de rol Key Vault-inzender of een andere rol hebben waarmee een sleutelkluis kan worden gemaakt.

    1. Selecteer + Een resource maken in het menu van Azure Portal of op de startpagina. Voer sleutelkluizen in het zoekvak in. Selecteer sleutelkluizen in de lijst met resultaten. Selecteer Maken op de pagina Sleutelkluizen.

    2. Kies een abonnement op het tabblad Basisbeginselen . Selecteer onder Resourcegroep Nieuwe maken en voer de naam van een resourcegroep in.

    3. Voer een unieke naam in voor de sleutelkluis.

    4. Selecteer een regio en prijscategorie.

    5. Schakel beveiliging tegen opschonen in voor de nieuwe sleutelkluis.

    6. Selecteer op het tabblad Toegangsbeleid het op rollen gebaseerde toegangsbeheer van Azure voor het machtigingsmodel.

    7. Selecteer Controleren en maken en vervolgens Maken.

      Screen shot showing how to create a key vault.

    Noteer de naam van de sleutelkluis en de URI-toepassingen die toegang hebben tot uw sleutelkluis, moeten deze URI gebruiken.

    Zie Quickstart: Een Azure Key Vault maken met Azure Portal voor meer informatie.

    De klant wijst de rol Crypto Officer van Key Vault toe aan een gebruikersaccount

    Deze stap zorgt ervoor dat u versleutelingssleutels kunt maken.

    1. Navigeer naar uw sleutelkluis en selecteer Toegangsbeheer (IAM) in het linkerdeelvenster.
    2. Onder Toegang verlenen tot deze bron, selecteert u Roltoewijzing toevoegen.
    3. Zoek en selecteer Key Vault Crypto Officer.
    4. Selecteer onder Leden de optie Gebruiker, groep of service-principal.
    5. Selecteer Leden en zoek uw gebruikersaccount.
    6. Selecteer Controleren + Toewijzen.

    De klant maakt een versleutelingssleutel

    Als u de versleutelingssleutel wilt maken, moet aan het account van de gebruiker de rol Crypto Officer van key vault of een andere rol worden toegewezen waarmee een sleutel kan worden gemaakt.

    1. Selecteer Sleutels op de eigenschappenpagina van Key Vault.
    2. Selecteer Genereren/Importeren.
    3. Geef in het scherm Een sleutel maken een naam op voor de sleutel. Houd voor de overige waarden de standaardwaarden aan.
    4. Selecteer Maken.
    5. Kopieer de sleutel-URI.

    De klant verleent de toepassing van de serviceprovider toegang tot de sleutelkluis

    Wijs de Azure RBAC-rol Key Vault Crypto Service Encryption-gebruiker toe aan de geregistreerde toepassing van de serviceprovider, zodat deze toegang heeft tot de sleutelkluis.

    1. Navigeer naar uw sleutelkluis en selecteer Toegangsbeheer (IAM) in het linkerdeelvenster.
    2. Onder Toegang verlenen tot deze bron, selecteert u Roltoewijzing toevoegen.
    3. Zoek en selecteer Key Vault Crypto Service Encryption User.
    4. Selecteer onder Leden de optie Gebruiker, groep of service-principal.
    5. Selecteer Leden en zoek de toepassingsnaam van de toepassing die u hebt geïnstalleerd bij de serviceprovider.
    6. Selecteer Controleren + Toewijzen.

    U kunt nu door de klant beheerde sleutels configureren met de sleutelkluis-URI en sleutel.

    Een nieuw Azure Cosmos DB-account maken dat is versleuteld met een sleutel van een andere tenant

    Tot nu toe hebt u de toepassing met meerdere tenants geconfigureerd op de tenant van de serviceprovider. U hebt de toepassing ook geïnstalleerd op de tenant van de klant en de sleutelkluis en sleutel op de tenant van de klant geconfigureerd. Vervolgens kunt u een Azure Cosmos DB-account maken op de tenant van de serviceprovider en door de klant beheerde sleutels configureren met de sleutel van de tenant van de klant.

    Wanneer u een Azure Cosmos DB-account maakt met door de klant beheerde sleutels, moeten we ervoor zorgen dat het toegang heeft tot de sleutels die de klant heeft gebruikt. In scenario's met één tenant geeft u directe sleutelkluistoegang tot de Azure Cosmos DB-principal of gebruikt u een specifieke beheerde identiteit. In een scenario voor meerdere tenants kunnen we niet langer afhankelijk zijn van directe toegang tot de sleutelkluis, omdat deze zich in een andere tenant bevindt die wordt beheerd door de klant. Deze beperking is de reden in de vorige secties dat we een toepassing voor meerdere tenants hebben gemaakt en een beheerde identiteit in de toepassing hebben geregistreerd om deze toegang te geven tot de sleutelkluis van de klant. Deze beheerde identiteit, gekoppeld aan de toepassings-id voor meerdere tenants, is wat we gaan gebruiken bij het maken van het CMK-account voor meerdere tenants in Azure Cosmos DB. Zie fase 3 voor meer informatie: de serviceprovider versleutelt gegevens in een Azure-resource met behulp van de door de klant beheerde sleutelsectie van dit artikel.

    Wanneer een nieuwe versie van de sleutel beschikbaar is in de sleutelkluis, wordt deze automatisch bijgewerkt in het Azure Cosmos DB-account.

    JSON-sjablonen van Azure Resource Manager gebruiken

    Implementeer een ARM-sjabloon met de volgende specifieke parameters:

    Notitie

    Als u dit voorbeeld opnieuw maakt in een van uw Azure Resource Manager-sjablonen, gebruikt u een apiVersion van 2022-05-15.

    Parameter Description Voorbeeldwaarde
    keyVaultKeyUri Id van de door de klant beheerde sleutel die zich in de sleutelkluis van de serviceprovider bevinden. https://my-vault.vault.azure.com/keys/my-key
    identity Object dat aangeeft dat de beheerde identiteit moet worden toegewezen aan het Azure Cosmos DB-account. "identity":{"type":"UserAssigned","userAssignedIdentities":{"/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity":{}}}
    defaultIdentity Combinatie van de resource-id van de beheerde identiteit en de toepassings-id van de Microsoft Entra-toepassing met meerdere tenants. UserAssignedIdentity=/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity&FederatedClientId=11111111-1111-1111-1111-111111111111

    Hier volgt een voorbeeld van een sjabloonsegment met de drie geconfigureerde parameters:

    {
  "kind": "GlobalDocumentDB",
  "location": "East US 2",
  "identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
      "/subscriptions/00000000-0000-0000-0000-000000000000/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/00000000-0000-0000-0000-000000000000/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity&FederatedClientId=11111111-1111-1111-1111-111111111111"
  }
}

    Belangrijk

    Deze functie wordt nog niet ondersteund in Azure PowerShell, Azure CLI of Azure Portal.

    U kunt door de klant beheerde sleutels niet configureren met een specifieke versie van de sleutelversie wanneer u een nieuw Azure Cosmos DB-account maakt. De sleutel zelf moet worden doorgegeven zonder versies en geen afsluitende backslashes.

    Als u door de klant beheerde sleutels wilt intrekken of uitschakelen, raadpleegt u door de klant beheerde sleutels configureren voor uw Azure Cosmos DB-account met Azure Key Vault

    Zie ook