Traitement du contexte de la demande Évaluation des politiques dans un compte unique Identification d'une demande autorisée ou refusée dans un compte Exemple d'évaluation de politique basée sur l'identité et sur les ressources Différence entre les refus explicites et implicites

Logique d'évaluation de politiques

Lorsqu'un principal essaie d'utiliser AWS Management Console, l'API AWS ou l'AWS CLI, il envoie une demande à AWS. Lorsqu'un service AWS reçoit la demande, AWS exécute plusieurs étapes pour déterminer s'il autorise ou refuse la demande.

Authentication (Authentification) : AWS authentifie d'abord le principal à l'origine de la demande, si nécessaire. Cette étape n'est pas nécessaire pour quelques services, tels qu'Amazon S3, qui autorisent certaines demandes provenant d'utilisateurs anonymes.
Traitement du contexte de la demande : AWS traite les informations recueillies dans la demande pour déterminer les politiques qui s'y appliquent.
Évaluation des politiques dans un compte unique :AWS évalue tous les types de politique qui affectent l'ordre dans lequel les politiques sont évaluées.
Identification d'une demande autorisée ou refusée dans un compte : AWS traite ensuite les politiques par rapport au contexte de la demande pour déterminer si la demande est autorisée ou refusée.

Traitement du contexte de la demande

AWS traite la demande pour recueillir les informations suivantes dans un contexte de la demande :

Actions (or operations) (Actions [ou opérations]) : les actions ou opérations que le principal souhaite exécuter.
Ressources : l'objet de ressource AWS sur lequel les actions ou opérations sont exécutées.
Principal : l'utilisateur, le rôle, l'utilisateur fédéré ou l'application à l'origine de la demande. Les informations sur le principal incluent les politiques associées à ce dernier.
Données d'environnement : informations sur l'adresse IP, l'agent utilisateur, le statut SSL ou le moment de la journée.
Données de ressources : données liées à la ressource qui est demandée. Par exemple, ces informations peuvent inclure le nom d'une table DynamoDB ou une balise sur une instance Amazon EC2.

AWS utilise ensuite ces informations pour identifier les politiques qui s'appliquent au contexte de la demande.

Évaluation des politiques dans un compte unique

La façon dont AWS évalue les politiques dépend des types de politiques qui s'appliquent au contexte de la demande. Les types de politique suivants sont répertoriés par ordre de fréquence et utilisables dans un seul Compte AWS. Pour plus d'informations sur ces types de politique, consultez Politiques et autorisations dans IAM. Pour savoir comment AWS évalue les stratégies d'accès entre comptes, veuillez consulter Logique d'évaluation des politiques entre comptes.

Politiques basées sur l'identité : les politiques basées sur l'identité sont attachées à une identité IAM (utilisateur, groupe d'utilisateurs ou rôle) et octroient des autorisations aux entités IAM (utilisateurs et rôles). Si seules les politiques basées sur une identité s'appliquent à une demande, AWS vérifie toutes ces politiques pour au moins une Allow.
Politiques basées sur les ressources – Les politiques basées sur les ressources accordent des autorisations au principal (compte, utilisateur, rôle et principaux de session tels que les sessions de rôle et les utilisateurs fédérés IAM) spécifié comme principal. Les autorisations définissent ce que le principal peut faire avec la ressource à laquelle la politique est attachée. Si les politiques basées sur les ressources et l'identité s'appliquent à une demande, AWS vérifie toutes les politiques pour au moins une Allow. Lorsque les politiques basées sur les ressources sont évaluées, l'ARN principal qui est spécifié dans la politique détermine si les rejets implicites dans d'autres types de politiques sont applicables à la décision finale.
IAM permissions boundaries (Limites d'autorisations) : les limites d'autorisations sont une fonctionnalité avancée qui définit les autorisations maximales qu'une politique basée sur les identités peut accorder à une entité IAM (utilisateur ou rôle). Lorsque vous définissez une limite d'autorisations pour une entité, l'entité peut effectuer uniquement les actions autorisées par ses deux ses stratégies basées sur l'identité et ses limites d'autorisations. Dans certains cas, un refus implicite dans une limite d'autorisations peut limiter les autorisations accordées par une politique basée sur les ressources. Pour en savoir plus, veuillez consulter Identification d'une demande autorisée ou refusée dans un compte plus loin dans cette rubrique.
AWS Organizations service control policies (SCPs) (Politiques de contrôle de service [SCP]) : les politiques de contrôle de service Organizations spécifient les autorisations maximales pour une organisation ou une unité d'organisation. La stratégie de contrôle de service maximale s'applique aux mandataires dans les comptes membres, y compris dans chaque Utilisateur racine d'un compte AWS. Si une stratégie de contrôle de service est présente, les politiques basées sur l'identité et sur les ressources accordent des autorisations aux principaux dans les comptes membres uniquement si ces politiques et la stratégie de contrôle de service autorise l'action. Si une limite d'autorisations et une politique de contrôle de service sont présentes, la limite, la politique de contrôle de service et la politique basée sur l'identité doivent toutes autoriser l'action.
Session policies (Politiques de session) : les politiques de session sont des politiques avancées que vous transmettez en tant que paramètres lorsque vous créez par programmation une session temporaire pour un rôle ou un utilisateur fédéré. Pour créer une session de rôle par programmation, utilisez l'une des opérations d'API AssumeRole*. Lorsque vous procédez ainsi et transmettez de politiques de session, les autorisations de session obtenues sont une combinaison de la politique basée sur l'identité de l'entité IAM et des politiques de session. Pour créer une session d'utilisateur fédéré, vous utilisez des clés d'accès d'utilisateur IAM pour appeler par programmation l'opération d'API GetFederationToken. Une politique basée sur les ressources a un autre effet sur l'évaluation des autorisations de la politique de session. La différence dépend de si l'utilisateur ou l'ARN du rôle ou de la session de l'ARN est répertorié en tant que principal dans la politique basée sur les ressources. Pour plus d’informations, veuillez consulter Politiques de session.

Pour rappel, un refus explicite dans l'une de ces politiques remplace l'autorisation.

Évaluation des politiques basées sur l'identité avec des politiques basées sur des ressources

Les politiques basées sur l'identité et sur les ressources accordent des autorisations aux identités ou ressources auxquelles elles sont associées. Lorsqu'une entité IAM (utilisateur ou rôle) demande l'accès à une ressource dans le même compte, AWS évalue toutes les autorisations accordées par les politiques basées sur l'identité et les politiques basées sur les ressources. Les autorisations obtenues constituent le total des autorisations des deux types. Si une action est autorisée par une politique basée sur une identité, une politique basée sur les ressources, ou les deux, AWS autorise l'action. Un refus explicite dans l'une ou l'autre de ces stratégies remplace l'autorisation.

Évaluation des politiques basées sur l'identité et des politiques basées sur des ressources

Évaluation des politiques basées sur l'identité avec des limites d'autorisations

Lorsqu'AWS évalue les politiques basées sur l'identité et les limites d'autorisations pour un utilisateur, les autorisations obtenues constituent l'intersection des deux catégories. En d'autres termes, lorsque vous ajoutez une limite d'autorisations à un utilisateur avec les politiques basées sur l'identité existantes, vous pouvez réduire les actions exécutées par l'utilisateur. Sinon, lorsque vous supprimez une limite d'autorisations à partir d'un utilisateur, vous pouvez augmenter les actions qu'il peut exécuter. Un refus explicite dans l'une ou l'autre de ces stratégies remplace l'autorisation. Pour afficher des informations sur la façon dont les autres types de politique sont évalués avec des limites d'autorisations, consultez Évaluation des autorisations effectives avec limites.

Évaluation des stratégies basées sur l'identité et des limites d'autorisations

Évaluation des politiques basées sur l'identité avec des SCP Organizations

Lorsqu'un utilisateur appartient à un compte qui est membre d'une organisation, les autorisations obtenues sont une combinaison des politiques de l'utilisateur et de la SCP. Cela signifie qu'une action doit être autorisée par la politique basée sur l'identité et la SCP. Un refus explicite dans l'une ou l'autre de ces stratégies remplace l'autorisation.

Évaluation des politiques basées sur l'identité et des SCP

Vous pouvez savoir si votre compte est membre d'une organisation dans AWS Organizations. Les membres de l'organisation pourraient être affectés par une SCP. Pour afficher ces données à l'aide de la commande d'AWS CLI ou l'opération d'API AWS, vous devez avoir les autorisations permettant d'effectuer l'action organizations:DescribeOrganization pour votre entité Organizations. Vous devez disposer des autorisations supplémentaires pour effectuer l'opération dans la console Organizations. Pour savoir si une stratégie de contrôle de service refuse l'accès à une demande spécifique ou pour modifier vos autorisations effectives, contactez votre administrateur AWS Organizations.

Identification d'une demande autorisée ou refusée dans un compte

Supposons qu'un principal envoie une demande à AWS d'accéder à une ressource dans le même compte que l'entité du principal. Le code d'application AWS décide si la demande doit être autorisée ou refusée. L’interface AWS évalue toutes les politiques qui s'appliquent au contexte de la demande. Vous trouverez ci-dessous un résumé de la logique d'évaluation AWS des politiques au sein d'un même compte.

Par défaut, toutes les demandes sont implicitement rejetées à l'exception de l'Utilisateur racine d'un compte AWS, qui dispose d'un accès complet.
Une autorisation explicite dans une politique basée sur l'identité ou les ressources remplace cette valeur par défaut.
Si une limite d'autorisations, SCP Organizations ou politique de session est présente, elle peut remplacer l'autorisation avec un refus implicite.
Un refus explicite dans n'importe quelle politique remplace toutes les autorisations.

Le diagramme suivant décrit comment la décision est prise. Cet organigramme ne couvre pas l'impact des politiques basées sur les ressources et des rejets implicites dans d'autres types de politiques.

Deny evaluation (Refuser l'évaluation) : par défaut, toutes les demandes sont refusées. Il s'agit d'un refus implicite. Le code d'application AWS évalue toutes les politiques du compte qui s'appliquent à la demande. Ces types incluent les SCP AWS Organizations, les politiques basées sur les ressources, les politiques basées sur l'identité, les limites d'autorisations IAM, et les politiques de session de rôle. Dans toutes ces politiques, le code d'application recherche une instruction Deny (Refuser) qui s'applique à la demande. Ceci est appelé un refus explicite. Si le code trouve un refus explicite qui s'applique, il retourne la décision finale Deny (Refuser). S'il n'y a pas de refus explicite, l'évaluation du code d'application se poursuit.
Organizations SCPs (Politiques de contrôle de service des organisations) : le code d'application évalue ensuite les politiques de contrôle de service (SCP) AWS Organizations qui s'appliquent à la demande. Les stratégies de contrôle de service s'appliquent aux principaux du compte auquel elles sont rattachées. Si le code d'application ne trouve aucune instruction Allow applicable dans les SPC, la demande est explicitement refusée, même si le refus est implicite. Le code d'application retourne la décision finale Deny (Refuser). S'il n'y a pas de SCP, ou si la SCP autorise l'action demandée, l'évaluation du code d'exécution se poursuit.

Politiques basées sur les ressources – Au sein d'un même compte, les politiques basées sur les ressources influencent l'évaluation des politiques différemment selon le type de principal accédant à la ressource et le principal autorisé dans la politique basée sur les ressources. Selon le type de principal, un Allow dans une politique basée sur les ressources peut aboutir à une décision finale de Allow, même si un rejet implicite dans une politique basée sur une identité, une limite d'autorisations ou une politique de séance est présente.

Pour la plupart des ressources, vous n'avez besoin d'une autorisation explicite pour le principal que dans une politique basée sur l'identité ou dans une politique basée sur les ressources pour accorder l'accès. Les politiques de confiance des rôles IAM et politiques de clé KMS sont des exceptions à cette logique, car ils doivent explicitement autoriser l'accès pour les principaux.

La logique des politiques basées sur les ressources diffère des autres types de politiques si le principal spécifié est un utilisateur IAM, un rôle IAM ou un principal de séance. Les principaux de séance incluent les séances de rôle IAM ou une séance d'utilisateur fédérée IAM. Si une politique basée sur les ressources accorde des autorisations directement à l'utilisateur IAM ou au principal de séance qui fait la demande, un rejet implicite dans une politique basée sur l'identité, une limite d'autorisations ou une politique de séance n'a pas d'incidence sur la décision finale.

Le tableau suivant vous aide à comprendre l'impact des politiques basées sur les ressources pour différents types de principal lorsque des rejets implicites sont présents dans les politiques basées sur une l'identité, les limites d'autorisations et les politiques de séance.

Politiques basées sur les ressources et rejets implicites dans d'autres types de politique (même compte)
Principal faisant la demande	Politique basée sur une ressource	Politique basée sur l'identité	Limite d'autorisations	Politique de séance	Résultat	Raison
Rôle IAM	Ne s'applique pas	Ne s'applique pas	Ne s'applique pas	Ne s'applique pas	Ne s'applique pas	Un rôle lui-même ne peut pas faire de demande. Les demandes sont faites avec la séance de rôle une fois qu'un rôle est endossé.
Séance de rôle IAM	Autorise l'ARN du rôle	Refus implicite	Refus implicite	Refus implicite	REJETER	La limite des autorisations et la politique de séance sont évaluées dans le cadre de la décision finale. Un rejet implicite dans l'une ou l'autre des politiques entraîne une décision de REJET.
Séance de rôle IAM	Autorise l'ARN de séance de rôle	Refus implicite	Refus implicite	Refus implicite	AUTORISER	Les autorisations sont accordées directement à la séance. Les autres types de politiques n'affectent pas la décision.
Utilisateur IAM	Autorise l'ARN de l'utilisateur IAM	Refus implicite	Refus implicite	Ne s'applique pas	AUTORISER	Les autorisations sont accordées directement à l'utilisateur. Les autres types de politiques n'affectent pas la décision.
Utilisateur fédéré IAM (`GetFederationToken`)	Autorise l'ARN de l'utilisateur IAM	Refus implicite	Refus implicite	Refus implicite	REJETER	Un rejet implicite dans la limite des autorisations ou dans la politique de séance entraîne un REJET.
Utilisateur fédéré IAM (`GetFederationToken`)	Autorise l'ARN de séance d'utilisateur fédérée IAM	Refus implicite	Refus implicite	Refus implicite	AUTORISER	Les autorisations sont accordées directement à la séance. Les autres types de politiques n'affectent pas la décision.
utilisateur root	Autorise l'ARN de l'utilisateur racine	Ne s'applique pas	Ne s'applique pas	Ne s'applique pas	AUTORISER	L'utilisateur root a un accès complet et illimité à toutes les ressources de votre Compte AWS. Pour connaître la procédure à suivre pour contrôler l'accès aux utilisateurs root pour les comptes dans AWS Organizations, veuillez consulter la rubrique Politiques de contrôle de service (SCP) dans le Guide de l'utilisateur des organisations.
Principal de service AWS	Autorise un principal de service AWS	Ne s'applique pas	Ne s'applique pas	Ne s'applique pas	AUTORISER	Lorsqu'une politique basée sur les ressources accorde directement des autorisations à un principal de service AWS, les autres types de politiques n'affectent pas la décision.

Rôle IAM – Les politiques basées sur les ressources qui accordent des autorisations à un ARN de rôle IAM sont limitées par un rejet implicite dans une limite d'autorisations ou une politique de séance.

Exemple d'ARN de rôle
```
arn:aws:iam::111122223333:role/examplerole
```
Rôle IAM – Au sein du même compte, les politiques basées sur les ressources qui accordent des autorisations à un ARN de séance de rôle IAM accordent des autorisations directement à la séance de rôle supposée. Les autorisations accordées directement à une séance ne sont pas limitées par un rejet implicite dans une politique basée sur l'identité, une limite d'autorisations ou une politique de séance. Lorsque vous endossez un rôle et que vous faites une demande, le principal qui fait la demande est l'ARN de séance de rôle IAM et non l'ARN du rôle lui-même.

Exemple d'ARN de séance de rôle
```
arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname
```
Utilisateur IAM – Au sein du même compte, les politiques basées sur les ressources qui accordent des autorisations à un ARN d'utilisateur IAM (qui n'est pas une séance d'utilisateur fédérée) ne sont pas limitées par un rejet implicite d'une politique basée sur l'identité ou d'une limite d'autorisations.

Exemple d'ARN d'utilisateur IAM
```
arn:aws:iam::111122223333:user/exampleuser
```
Séances d'utilisateur fédérées IAM – Une séance d'utilisateur fédérée IAM est une séance créée en appelant GetFederationToken. Lorsqu'un utilisateur fédéré fait une demande, le principal qui effectue la demande est l'ARN d'utilisateur fédéré et non l'ARN de l'utilisateur IAM qui a fédéré. Dans le même compte, les politiques basées sur les ressources accordant des autorisations à un ARN d'utilisateur fédéré accordent des autorisations directement à la séance. Les autorisations accordées directement à une séance ne sont pas limitées par un rejet implicite dans une politique basée sur l'identité, une limite d'autorisations ou une politique de séance.

Toutefois, si une politique basée sur les ressources accorde une autorisation à l'ARN de l'utilisateur IAM qui s'est fédéré, les demandes effectuées par l'utilisateur fédéré pendant la séance sont limitées par un rejet implicite dans une limite d'autorisation ou une politique de séance.

Exemple d'ARN de séance d'utilisateur fédérée IAM
```
arn:aws:sts::111122223333:federated-user/exampleuser
```

Identity-based policies (Politiques basées sur l'identité) : le code vérifie ensuite les politiques basées sur l'identité pour le principal. Pour un utilisateur IAM, cela comprend notamment les politiques d'utilisateur et les politiques de groupes auxquels l'utilisateur appartient. Si aucune politique basée sur l'identité ou aucune instruction dans les politiques basées sur l'identité n'autorise l'action demandée, alors la demande est implicitement refusée et le code renvoie une décision finale de refus. Si une instruction dans n'importe quelle politique basée sur l'identité applicable autorise l'action demandée, le code continue.
IAM permissions boundaries (limites d'autorisations IAM) – le code vérifie ensuite si l'entité IAM utilisée par le principal possède une limite d'autorisations. Si la politique qui est utilisée pour définir la limite d'autorisations n'autorise pas l'action demandée, la demande est implicitement refusée. Le code retourne la décision finale Deny (Refuser). S'il n'y a pas de limite d'autorisations, ou si la limite d'autorisations autorise l'action demandée, le code continue.
Politiques de séance : Le code vérifie ensuite si le principal est un principal de séance. Les principaux de séance incluent une séance de rôle IAM ou une séance d'utilisateur fédérée IAM. Si le principal n'est pas un principal de séance, le code d'application renvoie une décision finale d'autorisation.

Pour les principaux de séance, le code vérifie si une politique de séance a été transmise dans la demande. Vous pouvez transmettre une politique de session tout en utilisant l'API AWS CLI ou l’interface AWS pour obtenir des informations d'identification temporaires pour un rôle ou un utilisateur fédéré IAM.
- Si une politique de session est présente et n'autorise pas l'action demandée, la demande est implicitement refusée. Le code retourne la décision finale Deny (Refuser).
- S'il n'y a pas de politique de séance, le code vérifie si le principal est une séance de rôle. Si le principal est une séance de rôle, la demande est autorisée. Sinon, la demande est implicitement rejetée et le code renvoie une décision finale de rejet.
- Si une politique de séance est présente et autorise l'action demandée, le code d'exécution renvoie une décision finale d'autorisation.
Errors (Erreurs) : si le code d'application AWS rencontre une erreur à n'importe quel stade de l'évaluation, il génère une exception et se ferme.

Exemple d'évaluation de politique basée sur l'identité et sur les ressources

Les types de politiques les plus courants sont celles basées sur l'identité et les ressources. Lorsque l'accès à une ressource est demandé, AWS évalue toutes les autorisations accordées par les politiques pour au moins une autorisation au sein du même compte. Un rejet explicite dans l'une de ces politiques remplace l'autorisation.

Important

Si la politique basée sur les identités ou celle basée sur les ressources dans le même compte autorise la demande et que l'autre ne l'autorise pas, la demande reste autorisée.

Supposons que le nom d'utilisateur de Carlos soit carlossalazar et que ce dernier essaie d'enregistrer un fichier dans le compartiment Amazon S3 carlossalazar-logs.

Supposons également que la politique suivante soit attachée à l'utilisateur IAM carlossalazar.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ListRead",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowS3Self",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::carlossalazar/*",
                "arn:aws:s3:::carlossalazar"
            ]
        },
        {
            "Sid": "DenyS3Logs",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::*log*"
        }
    ]
}

L'instruction AllowS3ListRead de cette politique autorise Carlos à afficher une liste de tous les compartiments du compte. L'instruction AllowS3Self accorde à Carlos un accès total au compartiment du même nom que son nom d'utilisateur. L'instruction DenyS3Logs refuse à Carlos l'accès à n'importe quel compartiment S3 comprenant log dans son nom.

De plus, la politique basée sur les ressources suivante (appelée politique de compartiment) est attachée au compartiment carlossalazar.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/carlossalazar"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::carlossalazar/*",
                "arn:aws:s3:::carlossalazar"
            ]
        }
    ]
}

Cette politique spécifie que seul l'utilisateur carlossalazar peut accéder au compartiment carlossalazar.

Lorsque Carlos effectue une demande d'enregistrement d'un fichier dans le compartiment carlossalazar-logs, AWS détermine les stratégies qui s'appliquent à la demande. Dans ce cas, seule les politiques basées sur l'identité et les ressources s'appliquent. Il s'agit de deux politiques d'autorisations. La logique d'évaluation est réduite à la logique suivante, car aucune limite d'autorisations ne s'applique.

AWS recherche d'abord une instruction Deny qui s'applique au contexte de la demande. Il en trouve une, car la politique basée sur l'identité refuse explicitement à Carlos l'accès à n'importe quel compartiment S3 utilisé pour la journalisation. Carlos se voit refuser l'accès.

Supposons qu'il réalise ensuite son erreur et essaie d'enregistrer le fichier dans le compartiment carlossalazar. AWS recherche une instruction Deny et n'en trouve pas. Ensuite, il vérifie les politiques d'autorisations. La politique basée sur l'identité et celle basée sur les ressources autorisent la demande. Par conséquent, AWS autorise la demande. Si l'un d'entre eux refuse explicitement l'instruction, alors la demande est refusée. Si l'un des types de politique autorise la demande et que l'autre ne l'autorise pas, la demande reste autorisée.

Différence entre les refus explicites et implicites

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": "*"
        }
    ]
}

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Types de données pris en charge

Logique d'évaluation des politiques entre comptes