Migrer d’une stratégie d’accès de coffre vers un modèle d’autorisation de type contrôle d’accès en fonction du rôle Azure
Azure Key Vault propose deux systèmes d’autorisation : le contrôle d’accès en fonction du rôle Azure (Azure RBAC) et un modèle de stratégie d’accès. Azure RBAC est le système recommandé d’autorisation et par défaut pour Azure Key Vault. Pour une comparaison des deux méthodes d’autorisation, consultez l’article Contrôle d’accès en fonction du rôle Azure (Azure RBAC) et stratégies d’accès.
Cet article fournit les informations nécessaires pour migrer une key vault d’un modèle de politique d’accès à un modèle Azure RBAC.
Mappage des stratégies d’accès aux rôles Azure
Azure RBAC a plusieurs rôles intégrés Azure que vous pouvez affecter aux utilisateurs, groupes, principaux de service et identités managées. Si les rôles intégrés ne répondent pas aux besoins spécifiques de votre organisation, vous pouvez créer vos propres rôles personnalisés Azure.
Rôles intégrés de Key Vault pour la gestion de l’accès aux clés, certificats et secrets :
- Administrateur Key Vault
- Lecteur Key Vault
- Opérateur de purge de Key Vault
- Agent des certificats Key Vault
- Utilisateur de certificat Key Vault
- Agent de chiffrement Key Vault
- Utilisateur de chiffrement Key Vault
- Utilisateur du service de chiffrement de Key Vault
- Utilisateur de libération du service de chiffrement de Key Vault
- Agent des secrets Key Vault
- Utilisateur des secrets Key Vault
Pour plus d’informations sur les rôles intégrés existants, consultez Rôles intégrés Azure
Les stratégies d’accès au coffre peuvent être attribuées avec des autorisations sélectionnées individuellement ou des modèles d’autorisation prédéfinis.
Modèles d’autorisation prédéfinis pour les stratégies d’accès :
- Gestion des clés, des secrets et des certificats
- Gestion des clés et des secrets
- Gestion des secrets et des certificats
- Gestion de clés
- Gestion des secrets
- Gestion de certificats
- connecteur SQL Server
- Azure Data Lake Storage ou Stockage Azure
- Sauvegarde Azure
- Clé client Exchange Online
- Clé client SharePoint Online
- Azure Information BYOK
Mappage des modèles de stratégie d’accès aux rôles Azure
| Modèle de stratégie d’accès | Operations | Rôle Azure |
|---|---|---|
| Gestion des clés, des secrets et des certificats | Clés : toutes les opérations Certificats : toutes les opérations Secrets : toutes les opérations |
Administrateur Key Vault |
| Gestion des clés et des secrets | Clés : toutes les opérations Secrets : toutes les opérations |
Agent de chiffrement Key Vault Agent des secrets Key Vault |
| Gestion des secrets et des certificats | Certificats : toutes les opérations Secrets : toutes les opérations |
Agent des certificats Key Vault Agent des secrets Key Vault |
| Gestion de clés | Clés : toutes les opérations | Agent de chiffrement Key Vault |
| Gestion des secrets | Secrets : toutes les opérations | Agent des secrets Key Vault |
| Gestion de certificats | Certificats : toutes les opérations | Agent des certificats Key Vault |
| connecteur SQL Server | Clés : obtenir, lister, inclure la clé, ne pas inclure la clé | Utilisateur du service de chiffrement de Key Vault |
| Azure Data Lake Storage ou Stockage Azure | Clés : obtenir, lister, désenvelopper la clé | N/A Rôle personnalisé requis |
| Sauvegarde Azure | Clés : obtenir, lister, sauvegarder Secrets : obtenir, lister, sauvegarder |
N/A Rôle personnalisé requis |
| Clé client Exchange Online | Clés : obtenir, lister, inclure la clé, ne pas inclure la clé | Utilisateur du service de chiffrement de Key Vault |
| Clé client Exchange Online | Clés : obtenir, lister, inclure la clé, ne pas inclure la clé | Utilisateur du service de chiffrement de Key Vault |
| Azure Information BYOK | Clés : obtenir, déchiffrer, signer | N/A Rôle personnalisé requis |
Notes
La configuration de certificats Azure App Service via le portail Azure ne prend pas en charge le modèle d’autorisation RBAC de coffre de clés. Vous pouvez utiliser Azure PowerShell, Azure CLI, des déploiements de modèles ARM avec une attribution de rôle Utilisateur de certificat Key Vault pour une identité globale App Service, par exemple Microsoft Azure App Service dans un cloud public.
Mappage des étendues d’affectation
Azure RBAC pour Key Vault permet l’attribution de rôles aux étendues suivantes :
- Groupe d’administration
- Abonnement
- Resource group
- Ressource Key Vault
- Clé individuelle, secret et certificat
Le modèle d’autorisation de stratégie d’accès de coffre est limité à l’attribution de stratégies uniquement au niveau de la ressource du Coffre de clés.
En général, il est recommandé de disposer d’un coffre de clés par application et de gérer l’accès au niveau du coffre de clés. Dans certains scénarios, la gestion de l’accès sur d’autres étendues peut simplifier la gestion des accès.
Infrastructure, administrateurs et opérateurs de sécurité : la gestion du groupe de coffres de clés au niveau du groupe d’administration, de l’abonnement ou du groupe de ressources avec des stratégies d’accès au coffre requiert l’entretien des stratégies pour chaque coffre de clés. Azure RBAC permet de créer une attribution de rôle au niveau d’un groupe d’administration, d’un abonnement ou d’un groupe de ressources. Cette attribution s’appliquera à tous les nouveaux coffres de clés créés dans la même étendue. Dans ce scénario, il est recommandé d’utiliser Privileged Identity Management avec un accès juste-à-temps plutôt que la fourniture d’un accès permanent.
Applications : il existe des scénarios où l’application doit partager le secret avec une autre application. Avec les stratégies d’accès au coffre, un coffre de clés distinct doit être créé pour éviter d’avoir accès à tous les secrets. Azure RBAC permet d’attribuer un rôle à la clé secrète individuelle à la place à l’aide d’un coffre de clés unique.
Étapes de migration de stratégie d’accès du coffre vers Azure RBAC
Il existe de nombreuses différences entre le modèle d’autorisation Azure RBAC et la stratégie d’accès du coffre. Pour éviter les pannes au cours de la migration, il est recommandé de suivre les étapes ci-dessous.
- Identifiez et attribuez les rôles : identifiez les rôles intégrés en fonction du tableau de mappage ci-dessus et créez des rôles personnalisés si nécessaire. Affectez des rôles aux étendues, en fonction des recommandations de mappage des étendues. Pour plus d’informations sur la façon d’attribuer des rôles à un coffre de clés, consultez Fournir l’accès à Key Vault avec un contrôle d’accès en fonction du rôle Azure
- Validez l’attribution des rôles : la propagation des attributions de rôles dans Azure RBAC peut prendre plusieurs minutes. Pour savoir comment vérifier les attributions de rôles, consultez Répertorier les affectations de rôles dans l’étendue
- Configurez la surveillance et les alertes sur le coffre de clés : il est important d’activer la journalisation et les alertes de configuration pour les exceptions de refus d’accès. Pour plus d’informations, consultez Surveillance et alertes Azure Key Vault
- Définissez le modèle d’autorisation de contrôle d’accès en fonction du rôle Azure sur Key Vault : l’activation du modèle d’autorisation Azure RBAC invalidera toutes les stratégies d’accès existantes. En cas d’erreur, le modèle d’autorisation peut être rétabli avec toutes les stratégies d’accès existantes inchangées.
Prérequis
Changer le modèle d’autorisation d’une key vault nécessite deux permissions :
- La permission « Microsoft.Authorization/roleAssignments/write », qui est incluse dans le rôle Propriétaire et le rôle Administrateur d’accès utilisateur.
- La permission « Microsoft.KeyVault/vaults/write », qui est incluse dans le rôle Contributeur Key Vault.
Les rôles Administrateur d’abonnement classiques tels que « Administrateur de service » et « Coadministrateur » ne sont pas pris en charge.
Notes
Lorsque le modèle d’autorisation RBAC Azure est activé, tous les scripts qui tentent de mettre à jour les stratégies d’accès échouent. Il est important de mettre à jour ces scripts pour utiliser Azure RBAC.
Gouvernance de la migration
Grâce au service Azure Policy, vous pouvez régir la migration du modèle d’autorisation RBAC au sein de vos coffres. Vous pouvez créer une définition de stratégie personnalisée pour auditer les coffres de clés existants et appliquer tous les nouveaux coffres clés de façon à utiliser le modèle d’autorisation Azure RBAC.
Créer et affecter une définition de stratégie pour le modèle d’autorisation Azure RBAC de coffre de clés
- Accéder à la ressource de stratégie
- Sélectionnez Affectations sous Création dans la partie gauche de la page Azure Policy.
- Sélectionnez Attribuer une stratégie en haut de la page. Ce bouton ouvre la page Affectation de stratégie.
- Entrez les informations suivantes :
- Définissez l’étendue de la stratégie en choisissant l’abonnement et le groupe de ressources sur lesquels la stratégie sera appliquée. Sélectionnez en cliquant sur le bouton à trois points dans le champ Étendue.
- Sélectionnez le nom de la définition de stratégie : « [Préversion] : Azure Key Vault doit utiliser le modèle d’autorisation RBAC »
- Accédez à l’onglet Paramètres en haut de la page et définissez l’effet souhaité de la stratégie (Audit, Refus ou Désactivé).
- Renseignez les champs supplémentaires. Naviguez dans les onglets en cliquant sur les boutons Précédent et Suivant en bas de la page.
- Sélectionner Vérifier + créer
- Sélectionnez Créer
Une fois que la stratégie intégrée a été affectée, l’analyse peut prendre jusqu’à 24 heures. Une fois l’analyse terminée, vous pouvez consulter les résultats de la conformité comme suit.
Pour plus d'informations, consultez la rubrique
Stratégie d'accès à l’outil de comparaison Azure RBAC
Important
Cet outil est généré, puis géré par les membres de la communauté Microsoft, le tout sans support client officiel des services de support. L’outil est fourni EN L’ÉTAT sans garantie d’aucune sorte.
Outil PowerShell permettant de comparer les stratégies d’accès Key Vault aux rôles RBAC attribués pour faciliter la migration de la stratégie d’accès vers modèle d’autorisation RBAC. L’objectif de l’outil est de fournir une vérification de l’intégrité lors de la migration du système Key Vault existant vers le modèle d’autorisation RBAC pour garantir que les rôles attribués avec des actions de données sous-jacentes couvrent les stratégies d’accès existantes.
Dépannage
- Il est possible que l’attribution de rôle ne fonctionne pas au bout de quelques minutes ; il existe des situations où les attributions de rôles peuvent prendre plus de temps. Il est important d’écrire une logique de nouvelle tentative dans le code pour couvrir ces cas.
- Les attributions de rôles ont disparu lorsque Key Vault a été supprimé (suppression réversible) et récupéré. Il s’agit actuellement d’une limitation de la fonctionnalité de suppression réversible pour tous les services Azure. Il est nécessaire de recréer toutes les attributions de rôles après la récupération.