Configurer des clés gérées par le client multilocataire pour votre compte Azure Cosmos DB avec Azure Key Vault
S’APPLIQUE À : NoSQL MongoDB Cassandra Gremlin Table
Les données stockées dans votre compte Azure Cosmos DB sont chiffrées automatiquement et de façon fluide avec des clés gérées par le service managées par Microsoft. Toutefois, vous pouvez choisir d’ajouter une deuxième couche de chiffrement avec des clés gérées par vos soins. Ces clés sont appelées clés gérées par le client (ou CMK). Les clés gérées par le client doivent être stockées dans une instance Azure Key Vault.
Cet article aborde comment configurer le chiffrement avec des clés gérées par le client au moment où vous créez un compte Azure Cosmos DB. Dans cet exemple de scénario interlocataire, le compte Azure Cosmos DB réside dans un locataire géré par un éditeur de logiciels indépendants (ISV) appelé fournisseur de services. La clé utilisée pour le chiffrement du compte Azure Cosmos DB réside dans un coffre de clés dans un autre locataire géré par le client.
À propos des clés gérées par le client multilocataires
De nombreux fournisseurs de services qui créent des offres SaaS (Software as a Service) sur Azure entendent offrir à leurs clients la possibilité de gérer leurs propres clés de chiffrement. Les clés gérées par le client permettent à un fournisseur de services de chiffrer les données du client à l’aide d'une clé de chiffrement gérée par le client du fournisseur de services et à laquelle le fournisseur de services n’a pas accès. Dans Azure, le client du fournisseur de services peut utiliser Azure Key Vault pour gérer ses clés de chiffrement dans son propre locataire et abonnement Microsoft Entra.
Les services et ressources de la plateforme Azure appartenant au fournisseur de services et résidant dans le locataire du fournisseur de services doivent avoir accès à la clé du locataire du client pour effectuer les opérations de chiffrement/déchiffrement.
L’image ci-dessous montre un chiffrement de données au repos avec une identité fédérée dans un flux de travail de CMK inter-client couvrant un fournisseur de services et son client.
Dans l’exemple ci-dessus, il existe deux locataires Microsoft Entra : le locataire d’un fournisseur de services indépendant (Locataire 1) et le locataire d’un client (Locataire 2). Le locataire 1 héberge les services de la plateforme Azure et le locataire 2 héberge le coffre de clés du client.
Une inscription d’application multilocataire est créée par le fournisseur de services dans Locataire 1. Des informations d’identification d’identité fédérée sont créées sur cette application à l’aide d’une identité managée affectée par l’utilisateur. Ensuite, le nom et l’ID de l’application sont partagés avec le client.
Un utilisateur disposant des autorisations appropriées installe l'application du fournisseur de services dans le locataire client, locataire 2. Un utilisateur accorde ensuite au principal de service associé à l’application installée l’accès au coffre de clés du client. Le client stocke également la clé de chiffrement ou la clé gérée par le client dans le coffre de clés. Le client partage l’emplacement de la clé (URL de la clé) avec le fournisseur de services.
Le fournisseur de services dispose désormais des informations suivantes :
- L’ID d’une application multilocataire installée dans le locataire du client, qui a reçu l’accès à la clé gérée par le client.
- Une identité managée configurée en tant qu’informations d’identification sur l’application multilocataire.
- Emplacement de la clé dans le coffre de clés du client.
Avec ces trois paramètres, le fournisseur de services fournit des ressources Azure dans le locataire 1 qui peuvent être chiffrées avec la clé gérée par le client dans le locataire 2.
Nous allons diviser la solution de bout en bout ci-dessus en trois phases :
- Le fournisseur de services configure les identités.
- Le client accorde à l’application multilocataire du fournisseur de services l’accès à une clé de chiffrement dans Azure Key Vault.
- Le fournisseur de services chiffre les données dans une ressource Azure à l’aide de la clé gérée par le client.
Les opérations de la phase 1 correspondent à une configuration unique pour la plupart des applications de fournisseur de services. Les opérations des phases 2 et 3 se répètent pour chaque client.
Phase 1 : le fournisseur de services configure une application Microsoft Entra
Étape | Description | Rôle minimal dans Azure RBAC | Rôle minimal dans le RBAC Microsoft Entra |
---|---|---|---|
1. | Créez une inscription d’application Microsoft Entra multilocataire ou commencez par une inscription d’application existante. Notez l’ID d’application (ID client) de l’inscription d’application à l’aide du Portail Azure, de l’API Microsoft Graph, d’Azure PowerShell ou d’Azure CLI | Aucun | Développeur d’applications |
2. | Créez une identité managée affectée par l’utilisateur (à utiliser en tant qu’informations d’identification d’identité fédérée). Portail Azure / Azure CLI / Azure PowerShell/ Modèles Azure Resource Manager |
Contributeur d’identité managée | Aucun(e) |
3. | Configurez l’identité managée affectée par l’utilisateur en tant qu’informations d’identification d’identité fédérée sur l’application pour lui permettre d’emprunter l’identité de l’application. Référence de l’API Graph/ Portail Azure/ Azure CLI/ Azure PowerShell |
Aucun | Propriétaire de l’application |
4. | Partagez le nom et l’ID de l’application avec le client pour lui permettre d’installer et d’autoriser l’application. | None | None |
Considérations relatives aux fournisseurs de services
- Les modèles Azure Resource Manager (ARM) ne sont pas recommandés pour la création d’applications Microsoft Entra.
- La même application multilocataire peut être utilisée pour accéder aux clés de n’importe quel nombre de locataires, comme Locataire 2, Locataire 3, Locataire 4, etc. Dans chaque locataire, une instance indépendante de l’application est créée et porte le même ID d’application mais un ID d’objet différent. Dès lors, chaque instance de cette application est autorisée indépendamment. Réfléchissez à la manière dont l’objet d’application utilisé pour cette fonctionnalité est utilisé pour partitionner votre application sur tous les clients.
- L’application peut avoir au maximum 20 informations d’identification d’identité fédérée, ce qui oblige un fournisseur de services à partager les identités fédérées entre ses clients. Pour plus d’informations sur les considérations et restrictions de la conception d’identités fédérées, consultez Configurer une application pour approuver un fournisseur d’identité externe
- Dans de rares scénarios, un fournisseur de services peut utiliser un seul objet Application par client, mais cela entraîne des coûts de maintenance importants pour gérer les applications à grande échelle dans l’ensemble des clients.
- Dans le locataire du fournisseur de services, il n’est pas possible d’automatiser la vérification de l’éditeur.
Phase 2 : le client autorise l’accès au coffre de clés
Étape | Description | Rôles RBAC Azure avec privilèges minimum | Rôles Microsoft Entra les moins privilégiés |
---|---|---|---|
1. | Aucun | Utilisateurs disposant des autorisations nécessaires pour installer des applications | |
2. | Créez un coffre de clés Azure Key Vault et une clé utilisée en tant que clé gérée par le client. | Un utilisateur doit disposer du rôle Contributeur Key Vault pour créer le coffre de clés Un utilisateur doit avoir le rôle Agent de chiffrement Key Vault pour ajouter une clé au coffre de clés |
Aucun |
3. | Accordez à l’identité d’application autorisée l’accès au coffre de clés Azure en attribuant le rôle Utilisateur du service de chiffrement Key Vault. | Pour attribuer le rôle Utilisateur du service de chiffrement Key Vault à l’application, le rôle Administrateur de l’accès utilisateur doit vous avoir été attribué. | Aucun |
4. | Copiez l’URL et le nom du coffre de clés dans la configuration des clés gérées par le client de l’offre SaaS. | None | None |
Notes
Pour autoriser l'accès au HSM géré pour le chiffrement à l'aide de CMK, consultez l'exemple de compte de stockage ici. Pour plus d'informations sur la gestion des clés avec le HSM géré, consultez Gérer un HSM géré à l'aide d'Azure CLI
Considérations relatives aux clients des fournisseurs de services
- Dans le locataire client, locataire 2, un administrateur peut définir des stratégies pour empêcher les utilisateurs non administrateurs d'installer des applications. Ces stratégies peuvent empêcher les utilisateurs non administrateurs de créer des principaux de service. Si une telle stratégie est configurée, les utilisateurs disposant des autorisations nécessaires pour créer des principaux de service doivent être impliqués.
- L’accès à Azure Key Vault peut être autorisé à l’aide d’Azure RBAC ou de stratégies d’accès. Lorsque vous accordez l’accès à un coffre de clés, veillez à utiliser le mécanisme actif pour votre coffre de clés.
- Une inscription d’application Microsoft Entra a un ID d’application (ID client). Lorsque l’application est installée dans votre locataire, un principal de service est créé. Le principal de service partage le même ID d’application que l’inscription d’application, mais génère son propre ID d’objet. Si vous autorisez l’application à accéder aux ressources, vous devrez peut-être utiliser la propriété
Name
ouObjectID
du principal de service.
Phase 3 : le fournisseur de services chiffre les données dans une ressource Azure à l’aide de la clé gérée par le client
Une fois les phases 1 et 2 terminées, le fournisseur de services peut configurer le chiffrement sur la ressource Azure avec la clé et le coffre de clés dans le locataire du client et la ressource Azure dans le locataire de l’éditeur de logiciels indépendants. Le fournisseur de services peut configurer des clés gérées par le client multilocataires à l’aide des outils clients pris en charge par cette ressource Azure, avec un modèle ARM ou l’API REST.
Configurer des clés gérées par le client multilocataires
Cette section explique comment configurer une clé gérée par le client (CMK) multilocataire et chiffrer les données client. Découvrez comment chiffrer les données client dans une ressource dans Tenant1 à l’aide d’une clé gérée par le client stockée dans un coffre de clés dans Tenant2. Vous pouvez utiliser le portail Azure, Azure PowerShell ou Azure CLI.
Connectez-vous au portail Azure et suivez les étapes ci-dessous.
Le fournisseur de services configure les identités
Les étapes suivantes sont effectuées par le fournisseur de services dans le locataire du fournisseur de services Tenant1.
Le fournisseur de services crée une inscription d’application multilocataire
Vous pouvez créer une inscription d’application Microsoft Entra multilocataire ou commencer avec une inscription d’application multilocataire existante. Si vous commencez par une inscription d’application existante, notez l’ID d’application (ID client) de l’application.
Pour créer une inscription
Recherchez Microsoft Entra ID dans la zone de recherche. Recherchez et sélectionnez l’extension Microsoft Entra ID.
Sélectionnez Gérer > Inscriptions d’applications dans le volet gauche.
Sélectionnez + Nouvelle inscription.
Indiquez le nom de l’inscription d’application et sélectionnez Compte dans n’importe quel annuaire organisationnel (n’importe quel annuaire Microsoft Entra – multilocataire).
Sélectionnez Inscrire.
Notez les valeurs ApplicationId/ClientId de l’application.
Le fournisseur de services crée une identité managée affectée par l’utilisateur
Créez une identité managée affectée par l’utilisateur à utiliser en tant qu’informations d’identification d’identité fédérée.
Recherchez Identités managées dans la zone de recherche. Recherchez et sélectionnez l’extension Identités managées.
Sélectionnez + Créer.
Indiquez le groupe de ressources, la région et le nom de l’identité managée.
Sélectionnez Revoir + créer.
Au terme du déploiement, notez l’ID de ressource Azure de l’identité managée affectée par l’utilisateur disponible sous Propriétés. Par exemple :
/subscriptions/tttttttt-0000-tttt-0000-tttt0000tttt/resourcegroups/XTCMKDemo/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ConsotoCMKDemoUA
Le fournisseur de services configure l’identité managée affectée par l’utilisateur en tant qu’informations d’identification fédérées sur l’application
Configurez une identité managée affectée par l’utilisateur en tant qu’informations d’identification d’identité fédérée sur l’application pour lui permettre d’emprunter l’identité de l’application.
Accédez à Microsoft Entra ID > Inscriptions d’application > votre application.
Cliquez sur Certificats et secrets.
Sélectionnez Informations d’identification fédérées.
Sélectionnez + Ajouter des informations d’identification.
Sous Scénario d’informations d’identification fédérées, sélectionnez Clés gérées par le client.
Cliquez sur Sélectionner une identité managée. Dans le volet, sélectionnez l’abonnement. Sous Identité managée, sélectionnez Identité managée affectée par l’utilisateur. Dans la zone Sélectionner, recherchez l’identité managée que vous avez créée précédemment, puis cliquez sur Sélectionner en bas du volet.
Sous Détails des informations d’identification, fournissez un nom et une description facultative pour les informations d’identification, puis sélectionnez Ajouter.
Le fournisseur de services partage l’ID d’application avec le client
Recherchez l’ID d’application (ID client) de l’application multilocataire et partagez-le avec le client.
Le client accorde à l’application du fournisseur de services l’accès à la clé dans le coffre de clés
Les étapes suivantes sont effectuées par le client dans le locataire du client Tenant2. Le client peut utiliser le portail Azure, Azure PowerShell ou Azure CLI.
L’utilisateur qui exécute les étapes doit être un administrateur disposant d’un rôle privilégié tel que Administrateur d’application, Administrateur d’application cloud ou Administrateur général.
Connectez-vous au portail Azure et suivez les étapes ci-dessous.
Le client installe l’application du fournisseur de services dans le locataire du client
Pour installer l’application inscrite du fournisseur de services dans le locataire du client, vous créez un principal de service avec l’ID de l’application inscrite. Vous pouvez créer le principal de service de l’une des manières suivantes :
- Utilisez Microsoft Graph, Microsoft Graph PowerShell, Azure PowerShell ou Azure CLI pour créer manuellement le principal de service.
- Créez une URL de consentement administrateur et accordez le consentement à l’échelle du locataire pour créer le principal de service. Vous devez les fournir avec votre AppId.
Le client crée un coffre de clés
Pour créer le coffre de clés, le compte de l’utilisateur doit se voir attribuer le rôle Contributeur Key Vault ou un autre rôle qui autorise la création d’un coffre de clés.
Dans le menu du portail Azure ou dans la page Accueil, sélectionnez + Créer une ressource. Dans la zone de recherche, entrez Coffres de clés. Dans la liste des résultats, sélectionnez Coffres de clés. Dans la page Coffres de clés, sélectionnez Créer.
Sous l’onglet Informations de base, choisissez un abonnement. Sous Groupe de ressources, sélectionnez Créer nouveau, puis entrez un nom de groupe de ressources.
Entrez un nom unique pour le coffre de clés.
Sélectionnez une région et un niveau tarifaire.
Activez la protection contre le vidage pour le nouveau coffre de clés.
Sous l’onglet Stratégie d’accès, sélectionnez Contrôle d’accès en fonction du rôle Azure pour Modèle d’autorisation.
Sélectionnez Vérifier + créer, puis Créer.
Notez le nom du coffre de clés et les applications URI qui accèdent à votre coffre de clés doivent utiliser cet URI.
Pour plus d’informations, consultez Démarrage rapide - Créer un coffre de clés Azure Key Vault avec le portail Azure.
Le client attribue le rôle Agent de chiffrement Key Vault à un compte d’utilisateur
Cette étape garantit la possibilité de créer des clés de chiffrement.
- Accédez à votre coffre de clés et sélectionnez Access Control (IAM) dans le volet gauche.
- Sous Accorder l’accès à cette ressource, sélectionnez Ajouter une attribution de rôle.
- Recherchez et sélectionnez Agent de chiffrement Key Vault.
- Sous l’onglet Membres, sélectionnez Utilisateur, groupe ou principal du service.
- Sélectionnez Membres et recherchez votre compte d’utilisateur.
- Sélectionnez Vérifier + attribuer.
Le client crée une clé de chiffrement
Pour créer la clé de chiffrement, le compte de l’utilisateur doit se voir attribuer le rôle Agent de chiffrement Key Vault ou un autre rôle qui autorise la création d’une clé.
- Dans la page des propriétés Key Vault, sélectionnez Secrets.
- Sélectionnez Générer/Importer.
- Dans l’écran Créer une clé, spécifiez un nom pour la clé. Conservez les valeurs par défaut des autres options.
- Sélectionnez Create (Créer).
- Copiez l’URI de la clé.
Le client accorde à l’application du fournisseur de services l’accès au coffre de clés
Attribuez le rôle RBAC Azure Utilisateur du service de chiffrement Key Vault à l’application inscrite du fournisseur de services pour lui permettre d’accéder au coffre de clés.
- Accédez à votre coffre de clés et sélectionnez Access Control (IAM) dans le volet gauche.
- Sous Accorder l’accès à cette ressource, sélectionnez Ajouter une attribution de rôle.
- Rechercher et sélectionnez le rôle Utilisateur du service de chiffrement Key Vault.
- Sous l’onglet Membres, sélectionnez Utilisateur, groupe ou principal du service.
- Sélectionnez Membres et recherchez le nom de l’application que vous avez installée à partir du fournisseur de services.
- Sélectionnez Vérifier + attribuer.
Vous pouvez maintenant configurer des clés gérées par le client avec l’URI et la clé du coffre de clés.
Créer un compte chiffré Azure Cosmos DB avec une clé d’un autre locataire
Jusqu’à présent, vous avez configuré l’application multilocataire sur le locataire du fournisseur de services. Vous avez également installé l’application sur le locataire du client et avez configuré le coffre de clés et la clé sur le locataire du client. Ensuite, vous pouvez créer un compte Azure Cosmos DB sur le locataire du fournisseur de services et configurer des clés gérées par le client avec la clé à partir du locataire du client.
Lors de la création d’un compte Azure Cosmos DB avec des clés gérées par le client, nous devons nous assurer qu’il a accès aux clés utilisées par le client. Dans les scénarios monolocataires, donnez directement accès au coffre de clés au principal Azure Cosmos DB ou utilisez une identité managée spécifique. Dans un scénario interlocataire, nous ne pouvons plus dépendre d’un accès direct au coffre de clés, car il se trouve dans un autre locataire géré par le client. Cette contrainte est la raison pour laquelle nous avons créé une application interlocataire et inscrit une identité managée à l’intérieur de l’application pour lui donner accès au coffre de clés du client. Cette identité managée, associée à l’ID d’application interlocataire, est ce que nous allons utiliser lors de la création du compte CMK Azure Cosmos DB entre locataires. Pour plus d’informations, consultez la Phase 3 : le fournisseur de services chiffre les données dans une ressource Azure à l’aide de la section clé gérée par le client de cet article.
Chaque fois qu’une nouvelle version de la clé est disponible dans le coffre de clés, elle est automatiquement mise à jour sur le compte Azure Cosmos DB.
Utilisation de modèles JSON Azure Resource Manager
Déployez un modèle ARM avec les paramètres spécifiques suivants :
Notes
Si vous recréez cet exemple dans l’un de vos modèles Azure Resource Manager, utilisez un apiVersion
de 2022-05-15
.
Paramètre | Description | Valeur d'exemple |
---|---|---|
keyVaultKeyUri |
Identificateur de la clé gérée par le client résidant dans le coffre de clés du fournisseur de services. | https://my-vault.vault.azure.com/keys/my-key |
identity |
Objet spécifiant que l’identité managée doit être affectée au compte Azure Cosmos DB. | "identity":{"type":"UserAssigned","userAssignedIdentities":{"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity":{}}} |
defaultIdentity |
Combinaison de l’ID de ressource de l’identité managée et de l’ID d’application de l’application Microsoft Entra mutualisée. | UserAssignedIdentity=/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity&FederatedClientId=aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e |
Voici un exemple de segment de modèle avec les trois paramètres configurés :
{
"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"
}
}
Important
Cette fonctionnalité n’est pas encore prise en charge dans Azure PowerShell, Azure CLI ou le Portail Azure.
Vous ne pouvez pas configurer de clés gérées par le client avec une version spécifique de la version de clé lorsque vous créez un compte Azure Cosmos DB. La clé elle-même doit être passée sans versions et sans barre oblique inverse.
Pour révoquer ou désactiver les clés gérées par le client, consultez configurer les clés gérées par le client pour votre compte Azure Cosmos DB avec Azure Key Vault