Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Différence entre les refus explicites et implicites

Mode de mise au point
Différence entre les refus explicites et implicites - AWS Identity and Access Management

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Une demande se traduit par un refus explicite si une politique applicable inclut une instruction Deny (Refuser). Si les politiques qui s'appliquent à une demande incluent une instruction Allow (Autoriser) et une instruction Deny (Refuser), alors l'instruction Deny a priorité sur l'instruction Allow (Autoriser). La demande est refusée explicitement.

Un refus implicite se produit en cas d'absence d'instructions Deny (Refuser) et Allow (Autoriser) applicables. Étant donné qu'un principal IAM se voit refuser l'accès par défaut, il doit être explicitement autorisé à effectuer une action. Sinon, il se voit refuser l'accès implicitement.

Lorsque vous concevez votre stratégie d'autorisations, vous devez créer des politiques avec des instructions Allow (Autoriser) pour permettre à vos principaux d'effectuer des demandes avec succès. Toutefois, vous pouvez choisir n'importe quelle combinaison de refus explicites et implicites.

Par exemple, vous pouvez créer la politique suivante qui inclut des actions autorisées, des actions implicitement rejetées et des actions explicitement rejetées. L'instruction AllowGetList permet un accès en lecture seule aux actions IAM qui commencent par les préfixes Get et List. Toutes les autres actions dans IAM, comme iam:CreatePolicy, sont implicitement rejetées. L'instruction DenyReports rejette explicitement l'accès aux rapports IAM en rejetant l'accès aux actions qui incluent le suffixe Report, comme iam:GetOrganizationsAccessReport. Si quelqu'un ajoute une autre politique à ce principal pour lui donner accès aux rapports IAM, comme iam:GenerateCredentialReport, les demandes liées aux rapports sont toujours rejetées en raison de ce rejet explicite.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowGetList", "Effect": "Allow", "Action": [ "iam:Get*", "iam:List*" ], "Resource": "*" }, { "Sid": "DenyReports", "Effect": "Deny", "Action": "iam:*Report", "Resource": "*" } ] }
ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.