À l’instar d’une attribution de rôle, une affectation de refus associe un ensemble d’actions de refus à un utilisateur, un groupe ou un principal de service, sur une étendue spécifique, afin de refuser l’accès. Les affectations de refus empêchent les utilisateurs d'effectuer des actions particulières sur les ressources Azure, même si une attribution de rôle leur confère un accès.
Cet article explique comment répertorier les affectations de refus.
Important
Vous ne pouvez pas directement créer vos propres affectations de refus. Les affectations de refus sont créées et gérées par Azure.
Création des affectations de refus
Les affectations de refus sont créées et gérées par Azure pour protéger les ressources. Vous ne pouvez pas directement créer vos propres affectations de refus. Toutefois, vous pouvez spécifier des paramètres de refus lors de la création d’une pile de déploiement, ce qui crée une attribution de refus appartenant aux ressources de la pile de déploiement. Les piles de déploiement sont actuellement en préversion. Pour plus d’informations, consultez Protéger les ressources managées contre la suppression.
Comparer les attributions de rôles et les affectations de refus
Les affectations de refus suivent un modèle similaire à celui des affectations de rôles, mais présentent également certaines différences.
Une attribution de refus possède les propriétés suivantes :
Propriété
Obligatoire
Type
Description
DenyAssignmentName
Oui
Chaîne
Nom d'affichage de l’attribution de refus. Les noms doivent être uniques pour une étendue donnée.
Description
Non
Chaîne
Description de l’attribution de refus.
Permissions.Actions
Au moins un élément Actions ou DataActions
String[]
Tableau de chaînes qui spécifient les actions du plan de contrôle auxquelles l’attribution de refus bloque l’accès.
Permissions.NotActions
Non
String[]
Tableau de chaînes qui spécifient les actions du plan de contrôle à exclure de l’attribution de refus.
Permissions.DataActions
Au moins un élément Actions ou DataActions
String[]
Tableau de chaînes qui spécifient les actions du plan de contrôle auxquelles l’attribution de refus bloque l’accès.
Permissions.NotDataActions
Non
String[]
Tableau de chaînes qui spécifient les actions du plan de contrôle à exclure de l’attribution de refus.
Scope
Non
Chaîne
Chaîne qui spécifie l’étendue à laquelle l’attribution de refus s’applique.
DoNotApplyToChildScopes
Non
Boolean
Spécifie si l’attribution de refus s’applique aux étendues enfants. La valeur par défaut est False.
Principals[i].Id
Oui
String[]
Tableau d’ID d’objet principal Microsoft Entra (utilisateur, groupe, principal de service ou identité managée) auquel l’attribution de refus s’applique. Définie sur un GUID vide 00000000-0000-0000-0000-000000000000 pour représenter tous les principaux.
Principals[i].Type
Non
String[]
Tableau de types d’objet représentés par Principals[i].Id. Définie sur SystemDefined pour représenter tous les principaux.
ExcludePrincipals[i].Id
Non
String[]
Tableau d’ID d’objet principal Microsoft Entra (utilisateur, groupe, principal de service ou identité managée) auquel l’attribution de refus ne s’applique pas.
ExcludePrincipals[i].Type
Non
String[]
Tableau de types d’objet représentés par ExcludePrincipals[i].Id.
IsSystemProtected
Non
Boolean
Spécifie si cette attribution de refus a été créée par Azure et ne peut pas être modifiée ou supprimée. Actuellement, toutes les attributions de refus sont protégées par le système.
Le principal Tous les principaux
Un principal défini par le système nommé Tous les principaux a été introduit pour prendre en charge les affectations de refus. Ce principal représente tous les utilisateurs, groupes, principaux de service et identités managées dans un annuaire Microsoft Entra. Si l’ID du principal est un GUID nul 00000000-0000-0000-0000-000000000000, et le type de principal SystemDefined, le principal représente tous les principaux. Dans la sortie d’Azure PowerShell, Tous les principaux se présente comme suit :
Tous les principaux peut être combiné avec ExcludePrincipals pour refuser tous les principaux, à l’exception de certains utilisateurs. Tous les principaux présente les contraintes suivantes :
Il peut être utilisé uniquement dans Principals et ne peut pas être utilisé dans ExcludePrincipals.
Principals[i].Type doit être défini sur SystemDefined.
Répertorier les affectations de refus
Suivez ces étapes pour répertorier les affectations de refus.
Important
Vous ne pouvez pas directement créer vos propres affectations de refus. Les affectations de refus sont créées et gérées par Azure. Pour plus d’informations, consultez Protéger les ressources managées contre la suppression.
Pour obtenir des informations sur une affectation de refus, vous devez disposer de :
l’autorisation Microsoft.Authorization/denyAssignments/read, qui est incluse dans la plupart des rôles intégrés Azure.
Répertorier les affectations de refus dans le portail Azure
Effectuez ces étapes pour répertorier les affectations de refus au niveau de l’abonnement ou de l’étendue du groupe d’administration.
Dans le portail Azure, ouvrez l’étendue sélectionnée, telle que le groupe de ressources ou l’abonnement.
Sélectionnez Contrôle d’accès (IAM) .
Sélectionnez l’onglet Refuser les affectations (ou sélectionnez le bouton Afficher sur la vignette Afficher les affectations de refus).
S’il existe des affectations de refus à cette étendue ou héritées à cette étendue, elles sont répertoriées.
Pour afficher des colonnes supplémentaires, sélectionnez Modifier les colonnes.
Colonne
Description
Nom
Nom de l’affectation de refus.
Type de principal
Utilisateur, groupe, groupe défini par le système ou principal du service.
Refusé
Nom du principal de sécurité qui est inclus dans l’affectation de refus.
Id
Identificateur unique pour l’affectation de refus.
Principaux exclus
Indique s’il existe des principaux de sécurité qui sont exclus de l’affectation de refus.
Ne s’applique pas aux enfants
Indique si l’affectation de refus est transmise à des étendues secondaires.
Système protégé
Indique si l’affectation de refus est managée par Azure. Actuellement, toujours Oui.
Portée
Groupe d’administration, abonnement, groupe de ressources ou ressource.
Ajoutez une coche à l’un des éléments activés, puis sélectionnez OK pour afficher les colonnes sélectionnées.
Répertorier les détails d’une affectation de refus
Suivez ces étapes pour répertorier des détails supplémentaires sur une affectation de refus.
Ouvrez le volet Affectations de refus, comme décrit à la section précédente.
Sélectionnez le nom de l’affectation de refus pour ouvrir la page Utilisateurs.
La page Utilisateurs comprend les deux sections suivantes.
Paramètre de refus
Description
L’affectation de refus s’applique à
Principaux de sécurité auxquels l’affectation de refus s’applique.
L’affectation de refus exclut
Principaux de sécurité qui sont exclus de l’affectation de refus.
Le principal défini par le système représente tous les utilisateurs, groupes, principaux de service et identités managées figurant dans un annuaire Azure AD.
Pour afficher la liste des autorisations refusées, sélectionnez Autorisations refusées.
Type d’action
Description
Actions
Actions refusées du plan de contrôle.
NotActions
Actions du plan de contrôle exclues des actions refusées du plan de contrôle.
DataActions
Actions refusées du plan de données.
NotDataActions
Actions du plan de données exclues des actions refusées du plan de données.
Pour l’exemple illustré dans la capture d’écran précédente, les éléments suivants sont les autorisations effectives :
Toutes les actions de stockage sur le plan de données sont refusées à l’exception des actions de calcul.
Pour afficher les propriétés d’une affectation de refus, sélectionnez Propriétés.
Dans la page Propriétés , vous pouvez voir le nom d’affectation de refus, l’ID, la description et l’étendue. Le commutateur Ne s’applique pas aux enfants indique si l’affectation de refus est transmise à des étendues secondaires. Le commutateur Système protégé indique si cette affectation de refus est managée par Azure. Actuellement, c’est Oui dans tous les cas.
Prérequis
Pour obtenir des informations sur une affectation de refus, vous devez disposer de :
l’autorisation Microsoft.Authorization/denyAssignments/read, qui est incluse dans la plupart des rôles intégrés Azure
Répertorier les affectations de refus dans l’étendue d’un abonnement
Pour répertorier toutes les affectations de refus dans l’étendue d’un abonnement, utilisez Get-AzDenyAssignment. Pour obtenir l’ID d’abonnement, vous pouvez le trouver dans la page Abonnements dans le portail Azure ou utiliser Get-AzSubscription.
Remplacez {filter} par la condition que vous voulez appliquer pour filtrer la liste des affectations de refus.
Filter
Description
(aucun filtre)
Répertorie toutes les affectations de refus dans l’étendue spécifiée, mais aussi dans les étendues au-dessus et en dessous.
$filter=atScope()
Répertorie les affectations de refus uniquement dans la portée spécifiée et dans les étendues au-dessus. N’inclut pas les affectations de refus dans les étendues en dessous.
$filter=assignedTo('{objectId}')
Répertorie les affectations de refus pour l’utilisateur ou le principal de service spécifié. Si l’utilisateur est membre d’un groupe auquel un rôle a été attribué, cette affectation de refus est également répertoriée. Ce filtre est transitif pour les groupes, ce qui signifie que si l’utilisateur est membre d’un groupe et que ce groupe est membre d’un autre groupe auquel un refus a été affecté, cette affectation de refus est également répertoriée. Ce filtre accepte uniquement un ID d’objet pour un utilisateur ou principal de service. Vous ne pouvez pas transmettre un ID d’objet pour un groupe.
$filter=atScope()+and+assignedTo('{objectId}')
Répertorie les affectations de refus pour l’utilisateur ou le principal de service spécifié, et au niveau de l’étendue spécifiée.
Découvrez comment utiliser des rôles Azure intégrés, des identités managées et une stratégie RBAC pour contrôler l’accès aux ressources Azure. L’identité est la clé pour sécuriser les solutions.
Expliquez les fonctionnalités de Microsoft Entra ID pour moderniser des solutions d’identité, implémenter des solutions hybrides et une gouvernance des identités.