Partage via

Contrôle d’accès pour le HSM managé

  • Article

Le HSM managé Azure Key Vault est un service cloud qui protège les clés de chiffrement. Ces données étant sensibles et critiques pour votre entreprise, vous devez sécuriser vos modules de sécurité matériels (HSM) gérés en ne permettant qu'aux applications et utilisateurs autorisés d'accéder aux données.

Cet article fournit une vue d’ensemble du modèle de contrôle d’accès HSM managé. Il décrit l’authentification et l’autorisation, puis explique comment sécuriser l’accès à vos HSM managés.

Notes

Le fournisseur de ressources Azure Key Vault prend en charge deux types de ressources : les coffres et les HSM managés. Le contrôle d’accès décrit dans cet article s’applique uniquement aux HSM managés. Pour plus d’informations sur le contrôle d’accès pour HSM managé, consultez Donner accès aux clés, certificats et secrets du coffre de clés avec contrôle d’accès en fonction du rôle Azure.

Modèle de contrôle d'accès

L’accès à un HSM managé est contrôlé par le biais de deux interfaces :

  • Plan de gestion
  • Plan de données

Le plan de gestion vous permet de gérer le HSM. Les opérations de ce plan incluent la création et la suppression de HSM managés, ainsi que la récupération des propriétés des HSM managés.

Sur le plan de données, vous utilisez les données stockées dans un HSM managé. Autrement dit, vous utilisez les clés de chiffrement HSM. Vous pouvez ajouter, supprimer, modifier et utiliser des clés pour effectuer des opérations de chiffrement, gérer les attributions de rôles pour contrôler l’accès aux clés, créer une sauvegarde HSM complète, restaurer une sauvegarde complète et gérer le domaine de sécurité à partir de l’interface du plan de données.

Pour accéder à un HSM managé dans l’un ou l’autre de ces plans, tout appelant doit être authentifié et autorisé. L’authentification établit l’identité de l’appelant. L’autorisation détermine les opérations que l’appelant peut exécuter. Un appelant peut être un des principaux de sécurité définis dans Microsoft Entra ID : utilisateur, groupe, principal de service ou identité managée.

Les deux plans utilisent Microsoft Entra ID pour l’authentification. Pour l’autorisation, ils utilisent différents systèmes :

  • Le plan de gestion utilise le contrôle d’accès en fonction du rôle Azure (Azure RBAC), un système d’autorisation basé sur Azure Resource Manager.
  • Le plan de données utilise le contrôle d’accès en fonction du rôle au niveau du HSM managé, un système d’autorisation implémenté et appliqué au niveau du HSM managé.

Lorsqu’un HSM managé est créé, le demandeur fournit une liste d’administrateurs de plan de données (tous les principaux de sécurité sont pris en charge). Seuls ces administrateurs peuvent accéder au plan de données du HSM managé pour effectuer des opérations sur les clés et gérer les attributions de rôles de plan de données (RBAC local du HSM managé).

Les modèles d’autorisation des deux plans utilisent la même syntaxe, mais il est appliqué à des niveaux différents, et les attributions de rôles utilisent des étendues différentes. L’Azure RBAC du plan de gestion est appliqué par Azure Resource Manager et le RBAC local du HSM managé est appliqué par le HSM managé lui-même.

Important

L’octroi d’un accès au plan de gestion à un principal de sécurité n’accorde pas l’accès au plan de données du principal de sécurité. Par exemple, un principal de sécurité avec accès au plan de gestion n’a pas automatiquement accès aux clés ou aux attributions de rôle de plan de données. Cet isolement vise à prévenir une expansion intempestive des privilèges qui affecte l’accès aux clés qui sont stockées dans le HSM managé.

Mais il existe une exception : les membres du rôle Administrateur général Microsoft Entra peuvent toujours ajouter des utilisateurs au rôle Administrateur du HSM managé à des fins de récupération, par exemple lorsqu’il n’y a plus de comptes Administrateur du HSM managés valides. Pour plus d’informations, consultez meilleures pratiques Microsoft Entra ID pour sécuriser le rôle d’administrateur général.

Par exemple, un administrateur d’abonnement (parce qu’il dispose des autorisations contributeurs pour toutes les ressources de l’abonnement) peut supprimer un HSM managé dans son abonnement. Toutefois, s’ils n’ont pas d’accès au plan de données spécifiquement accordé via le RBAC local HSM managé, ils ne peuvent pas accéder aux clés ou gérer les attributions de rôles dans le HSM managé pour s’accorder eux-mêmes ou d’autres utilisateurs l’accès au plan de données.

Authentification Microsoft Entra

Lorsqu’un HSM managé est créé dans un abonnement Azure, le HSM managé est automatiquement associé au client Microsoft Entra de cet abonnement. Tous les appelants dans les deux plans doivent être inscrits auprès de ce locataire et s’authentifier pour accéder au HSM managé.

L’application s’authentifie auprès de Microsoft Entra ID avant d’appeler un plan. L’application peut utiliser une méthode d’authentification prise en charge selon le type d’application. L’application acquiert un jeton pour une ressource du plan afin d’y accéder. La ressource est un point de terminaison dans le plan de gestion ou de données, en fonction de l’environnement Azure. L’application utilise le jeton et envoie une demande d’API REST au point de terminaison du HSM managé. Pour en savoir plus, passez en revue le flux d’authentification intégral.

L’utilisation d’un même mécanisme d’authentification pour les deux plans présente plusieurs avantages :

  • Les organisations peuvent contrôler de manière centralisée l’accès à tous leurs HSM managés.
  • Si un utilisateur quitte une organisation, il perd instantanément l’accès à tous les HSM managés de l’organisation.
  • Les organisations peuvent personnaliser l’authentification à l’aide des options de Microsoft Entra ID (par exemple, pour activer l’authentification multifacteur afin de renforcer la sécurité).

Points de terminaison de ressource

Les principaux de sécurité accèdent aux plans par le biais de points de terminaison. Les contrôles d’accès pour les deux plans fonctionnent indépendamment. Pour permettre à une application d’utiliser des clés dans un HSM managé, vous accordez l’accès au plan de données à l’aide d’un RBAC local de HSM managé. Pour permettre à un utilisateur d’accéder à la ressource HSM managé pour créer, lire, supprimer, déplacer les HSM managés et modifier d’autres propriétés et balises, vous utilisez Azure RBAC.

Le tableau suivant présente les points de terminaison pour le plan de gestion et de données.

Plan d’accès Points de terminaison d’accès Opérations Mécanisme de contrôle d’accès
Plan de gestion Mondial :
management.azure.com:443
 Créer, lire, mettre à jour, supprimer et déplacer des HSM managés

Définir des balises de HSM managé		 Azure RBAC
Plan de données Mondial :
<hsm-name>.managedhsm.azure.net:443
 Clés : decrypt, encrypt,
désenvelopper, envelopper, vérifier, signer, get, lister, mettre à jour, créer, importer, supprimer, sauvegarder, restaurer, purger

Gestion du rôle du plan de données (Managed HSM local RBAC)* : définitions des rôles de listes, affectation des rôles, supprimer les affectations des rôles, définir les rôles personnalisés

Sauvegarde et restauration : sauvegarder, restaurer, vérifier l’état des opérations de sauvegarde et de restauration

Domaine de sécurité : télécharger et charger le domaine de sécurité		 RBAC local HSM managé

Plan de gestion et Azure RBAC

Dans le plan de gestion, vous utilisez Azure RBAC pour autoriser les opérations qu’un appelant peut exécuter. Dans le modèle Azure RBAC, chaque abonnement Azure a une instance de Microsoft Entra ID. Vous accordez l’accès aux utilisateurs, groupes et applications de ce répertoire. L'accès est accordé pour gérer les ressources d'abonnement qui utilisent le modèle de déploiement Azure Resource Manager. Pour accorder l’accès, utilisez le portail Azure, l’interface Azure CLI, Azure PowerShell ou les API REST Azure Resource Manager.

Vous créez un coffre de clés dans un groupe de ressources et vous gérez l’accès à l’aide de Microsoft Entra ID. Vous autorisez des utilisateurs ou des groupes à gérer les coffres de clés dans un groupe de ressources. Vous accordez l’accès à un niveau d’étendue spécifique en attribuant les rôles Azure appropriés. Pour permettre à un utilisateur de gérer des coffres de clés, vous attribuez un rôle key vault Contributor prédéfini à l’utilisateur dans une étendue spécifique. Le niveau d’étendue suivant peut être attribués à un rôle Azure :

  • Groupe d’administration : un rôle Azure attribué au niveau d’un abonnement s’applique à tous les abonnements au sein de ce groupe d’administration.
  • Abonnement: Un rôle Azure attribué au niveau d’un abonnement s’applique à tous les groupes de ressources et à toutes les ressources au sein de cet abonnement.
  • Groupe de ressources : Un rôle Azure attribué au niveau d’un groupe de ressources s’applique à toutes les ressources de ce groupe de ressources.
  • Ressource spécifique : Un rôle Azure attribué pour une ressource spécifique s’applique à cette ressource. Dans ce cas, la ressource est un coffre de clés spécifique.

Plusieurs rôles sont prédéfinis. Si un rôle prédéfini ne répond pas à vos besoins, vous pouvez définir votre propre rôle. Pour plus d’informations, consultez Azure RBAC : pour les ressources Azure.

Plan de données et RBAC local HSM managé

Vous octroyez à un principal de sécurité l’accès pour exécuter des opérations de clé spécifiques en attribuant un rôle. Pour chaque attribution de rôle, vous devez spécifier un rôle et une étendue auxquels s’applique cette attribution. Pour le RBAC local HSM managé, deux étendues sont disponibles :

  • / or /keys : Étendue de niveau HSM. Les principaux de sécurité auxquels un rôle a été attribué à cette étendue peuvent effectuer les opérations définies dans le rôle pour tous les objets (clés) au sein du HSM managé.
  • /keys/<key-name> : Étendue de niveau clé. Les principaux de sécurité auxquels un rôle a été attribué à cette étendue peuvent effectuer les opérations définies dans ce rôle pour toutes les versions de la clé spécifiée uniquement.

Étapes suivantes