Mettre à l’échelle la gestion des attributions de rôles Azure à l’aide des conditions et des attributs de sécurité personnalisés
Le contrôle d’accès en fonction du rôle Azure (RBAC Azure) a une limite d’attributions de rôles par abonnement. Si vous avez besoin de créer des centaines, voire des milliers d’attributions de rôles Azure, vous pourriez rencontrer cette limite. La gestion de centaines ou de milliers d’attributions de rôles peut être difficile. Selon votre scénario, vous pouvez être en mesure de réduire le nombre d’attributions de rôles et de faciliter la gestion de l’accès.
Cet article décrit une solution pour mettre à l’échelle la gestion des attributions de rôles à l’aide des conditions de contrôle d’accès en fonction des attributs Azure (Azure ABAC) et des attributs de sécurité personnalisés Microsoft Entra pour les principaux.
Exemple de scénario
Imaginez une société nommée Contoso qui compte des milliers de clients et qui veut mettre en place la configuration suivante :
- Distribuer des données client sur 128 comptes de stockage pour des raisons de sécurité et de performances.
- Ajouter 2 000 conteneurs à chaque compte de stockage, avec un conteneur pour chaque client.
- Représentez chaque client par un principal de service Microsoft Entra unique.
- Autoriser chaque client à accéder aux objets de son conteneur, mais pas à ceux des autres conteneurs.
Cette configuration pourrait nécessiter 256 000 attributions de rôle de propriétaire de données Blob de stockage Microsoft Azure dans un abonnement, ce qui dépasse largement la limite d’attributions de rôles. Toutes ces attributions de rôle seraient difficiles, voire impossibles, à maintenir.
Exemple de solution
Pour gérer ce scénario efficacement, vous pouvez utiliser des conditions d’attribution de rôle. Le diagramme suivant illustre une solution permettant de réduire les 256 000 attributions de rôle à une seule attribution de rôle à l’aide d’une condition. L’attribution de rôle se trouve dans une étendue de groupe de ressources supérieure et une condition permet de contrôler l’accès aux conteneurs. La condition vérifie si le nom du conteneur correspond à l’attribut de sécurité personnalisé sur le principal de service pour le client.
Voici l’expression dans la condition qui fait fonctionner cette solution :
@Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name]
StringEquals
@Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]
La condition complète serait similaire à ce qui suit. La liste d’actions pourrait être ajustée aux seules actions nécessaires.
(
(
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete'})
AND
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})
AND
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write'})
AND
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action'})
AND
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action'})
AND
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action'})
AND
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action'})
AND
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action'})
AND
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/permanentDelete/action'})
AND
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action'})
AND
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read'})
AND
!(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write'})
)
OR
(
@Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name] StringEquals @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]
)
)
Pourquoi utiliser cette solution ?
Il existe plusieurs mécanismes de contrôle d’accès que vous pouvez utiliser pour fournir un accès aux ressources du plan de données.
Les clés d’accès sont une méthode courante pour fournir un accès aux ressources du plan de données. Les clés d’accès fournissent des autorisations de lecture, d’écriture et de suppression à quiconque possède la clé d’accès. Cela signifie que les attaquants peuvent accéder à vos données sensibles s’ils peuvent accéder à vos clés d’accès. Les clés d’accès n’ont pas de liaison d’identité, n’ont pas d’expiration et constituent un risque de sécurité pour le stockage.
Comme les clés d’accès, les jetons de signature d’accès partagé (SAS) ne sont pas liés à une identité, mais expirent régulièrement. L’absence de liaison d’identité représente les mêmes risques de sécurité que les clés d’accès. Vous devez gérer l’expiration pour vous assurer que les clients n’obtiennent pas d’erreurs. Les jetons SAS requièrent du code supplémentaire pour gérer et fonctionner tous les jours et peuvent constituer une surcharge importante pour une équipe DevOps.
Azure RBAC fournit un contrôle d’accès centralisé et affiné. Azure RBAC dispose d’une liaison d’identité qui réduit le risque de sécurité. À l’aide de conditions, vous pouvez potentiellement mettre à l’échelle la gestion des attributions de rôles et rendre le contrôle d’accès plus facile à gérer car l’accès est basé sur des attributs flexibles et dynamiques.
Voici quelques-uns des avantages de cette solution :
- Contrôle d’accès centralisé
- Plus facile à gérer
- Ne dépend pas des clés d’accès ou des jetons SAS
- Ne vous oblige pas à gérer l’accès à chaque objet
- Peut potentiellement améliorer votre posture de sécurité
Pouvez-vous utiliser cette solution ?
Si vous avez un scénario similaire, suivez ces étapes pour voir si vous pouvez utiliser cette solution.
Étape 1 : Déterminer si vous remplissez les conditions préalables
Pour utiliser cette solution, vous devez disposer :
Plusieurs attributions de rôles intégrés ou personnalisés qui ont des actions de données de stockage d’objets blob. Sont inclus les rôles intégrés suivants :
Étape 2 : Identifier les attributs que vous pouvez utiliser dans votre condition
Il existe plusieurs attributs que vous pouvez utiliser dans votre condition, tels que :
- Nom du conteneur
- Chemin d’accès d’objet blob
- Balises d’index d’objet blob [Clés]
- Balises d’index de blob [Valeurs dans la clé]
Vous pouvez également définir vos propres attributs de sécurité personnalisés pour les utilisateurs, les applications d’entreprise et les identités gérées.
Pour plus d’informations, consultez le format et la syntaxe des conditions d’attribution de rôle Azure et quelles sont les attributs de sécurité personnalisés dans l’ID Microsoft Entra ?.
Étape 3 : Créer une condition d’une portée supérieure
Créez une ou plusieurs attributions de rôle qui utilisent une condition dans une étendue plus élevée pour gérer l’accès. Pour plus d’informations, consultez Ajouter ou modifier des conditions d’attribution de rôle Azure à l’aide du portail Azure.