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 le AWS Management Console AWS API, le ou le AWS CLI, ce principal envoie une demande à AWS. Lorsqu'un AWS service reçoit la demande, AWS effectue plusieurs étapes pour déterminer s'il convient d'autoriser ou de refuser la demande.

Authentification : authentifie d' AWS abord le principal qui fait 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 afin de déterminer quelles politiques s'appliquent à la demande.
Évaluation des politiques dans un compte unique— AWS évalue tous les types de politiques, ce qui influe sur l'ordre dans lequel les politiques sont évaluées.
Identification d'une demande autorisée ou refusée dans un compte— traite AWS ensuite les politiques en fonction du 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 demande :

Actions (or operations) (Actions [ou opérations]) : les actions ou opérations que le principal souhaite exécuter.
Ressources : objet de AWS ressource sur lequel les actions ou opérations sont effectué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 d'SSLactivation ou l'heure de la journée.
Données de ressources : données liées à la ressource qui est demandée. Cela peut inclure des informations telles que le nom d'une table DynamoDB ou une balise sur une instance Amazon. EC2

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

Évaluation des politiques dans un compte unique

La manière dont AWS les politiques sont évaluées 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 politiques d'accès entre comptes, voir. Logique d'évaluation des politiques entre comptes

Politiques basées sur l'identité — Les politiques basées sur l'identité sont associées à une IAM identité (utilisateur, groupe d'utilisateurs ou rôle) et accordent des autorisations aux IAM entités (utilisateurs et rôles). Si seules les politiques basées sur l'identité s'appliquent à une demande, alors AWS vérifie toutes ces politiques pour au moins une d'entre elles. Allow
Politiques basées sur les ressources : les politiques basées sur les ressources accordent des autorisations au principal (compte, utilisateur, rôle et principes de session tels que les sessions de rôle et les utilisateurs IAM fédérés) 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 les politiques basées sur l'identité s'appliquent toutes deux à une demande, alors AWS vérifie toutes les politiques pour au moins une d'entre elles. Allow Lorsque les politiques basées sur les ressources sont évaluées, le principal ARN spécifié dans la politique détermine si les refus implicites dans d'autres types de politiques sont applicables à la décision finale.
IAMlimites d'autorisations : les limites d'autorisations sont une fonctionnalité avancée qui définit le maximum d'autorisations qu'une politique basée sur l'identité peut accorder à une IAM entité (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 politiques de contrôle des services (SCPs) — Les organisations SCPs spécifient les autorisations maximales pour une organisation ou une unité organisationnelle (UO). Le SCP maximum s'applique aux principaux des comptes des membres, y compris à chacun Utilisateur racine d'un compte AWS d'entre eux. SCPLe cas échéant, les politiques basées sur l'identité et les ressources accordent des autorisations aux principaux des comptes membres uniquement si ces politiques autorisent l'action. SCP Si une limite d'autorisation et une SCP sont présentes, alors la limite, la politique basée sur l'SCPidentité 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 AssumeRole* API opérations. Lorsque vous effectuez cette opération et que vous adoptez des politiques de session, les autorisations de session qui en résultent se situent à l'intersection de la politique basée sur l'identité de l'IAMentité et des politiques de session. Pour créer une session utilisateur fédérée, vous utilisez les clés IAM d'accès utilisateur pour appeler l'opération par programmation. GetFederationToken API 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 du fait que l'utilisateur, le rôle ARN ou la session ARN sont répertoriés comme principal dans la politique basée sur les ressources. Pour plus d’informations, consultez 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 IAM entité (utilisateur ou rôle) demande l'accès à une ressource au sein du même compte, AWS évalue toutes les autorisations accordées par les politiques basées sur l'identité et les ressources. Les autorisations obtenues constituent le total des autorisations des deux types. Si une action est autorisée par une stratégie basée sur l'identité, une stratégie basée sur les ressources, ou les deux, l'action est autorisée. AWS 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

Lors de l' AWS évaluation des politiques basées sur l'identité et des limites d'autorisations pour un utilisateur, les autorisations qui en résultent sont à 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 les Organizations SCPs

Lorsqu'un utilisateur appartient à un compte membre d'une organisation, les autorisations qui en résultent se situent à l'intersection des politiques de l'utilisateur et duSCP. Cela signifie qu'une action doit être autorisée à la fois par la politique basée sur l'identité et par le. SCP Un refus explicite dans l'une ou l'autre de ces stratégies remplace l'autorisation.

Évaluation des politiques fondées sur l'identité et SCPs

Vous pouvez savoir si votre compte est membre d'une organisation dans AWS Organizations. Les membres de l'organisation peuvent être concernés par unSCP. Pour afficher ces données à l'aide de la AWS CLI commande ou de AWS API l'opération, vous devez disposer des autorisations nécessaires à l'organizations:DescribeOrganizationaction pour votre entité Organizations. Vous devez disposer des autorisations supplémentaires pour effectuer l'opération dans la console Organizations. Pour savoir si un SCP refuse l'accès à une demande spécifique ou pour modifier vos autorisations effectives, contactez votre AWS Organizations administrateur.

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

Supposons qu'un principal envoie une demande AWS d'accès à une ressource dans le même compte que l'entité du principal. Le code d' AWS exécution décide si la demande doit être acceptée ou refusée. AWS évalue toutes les politiques applicables au contexte de la demande. Ce qui suit est un résumé de la logique AWS d'évaluation des politiques au sein d'un seul compte.

Par défaut, toutes les demandes sont implicitement refusées, à l'exception de 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'autorisation, une organisation SCP ou une politique de session est présente, elle peut remplacer l'autorisation par un refus implicite.
Un refus explicite dans n'importe quelle stratégie 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' AWS application évalue toutes les politiques du compte qui s'appliquent à la demande. Il s'agit notamment des politiques basées sur les ressources AWS Organizations SCPs, des politiques basées sur l'identité, des limites d'IAMautorisations et des politiques de session. 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.
Organisations SCPs — Le code d'application évalue ensuite les politiques AWS Organizations de contrôle des services (SCPs) qui s'appliquent à la demande. SCPss'appliquent au principal du compte auquel SCPs ils sont rattachés. Si le code d'exécution ne trouve aucune Allow déclaration applicable dans leSCPs, la demande est explicitement refusée, même si le refus est implicite. Le code d'application retourne la décision finale Deny (Refuser). Si ce n'est pas le casSCP, ou si l'SCPaction demandée est autorisée, l'évaluation du code d'application 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. IAMles politiques de confiance des rôles et les politiques KMS clés font exception à cette logique, car elles doivent explicitement autoriser l'accès aux principaux.

La logique de stratégie basée sur les ressources diffère des autres types de stratégie si le principal spécifié est un IAM utilisateur, un IAM rôle ou un principal de session. Les principes de session incluent des sessions de IAM rôle ou une session utilisateur IAM fédérée. Si une politique basée sur les ressources accorde l'autorisation directement à l'IAMutilisateur ou au principal de session qui fait la demande, un refus implicite dans une politique basée sur l'identité, une limite d'autorisation ou une politique de session n'a aucune 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.

Le tableau suivant présente les politiques basées sur les ressources et les refus implicites dans d'autres types de politiques pour le 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 effectuées avec la session de rôle une fois qu'un rôle est assumé.
IAMsession de rôle	Autorise le rôle ARN or Autorise une session de rôle ARN	Refus implicite	Refus implicite	Refus implicite	DENY- Rôle ARN or ALLOW- Séance de rôle ARN	Lorsque le principal élément de la stratégie basée sur les ressources est un rôle ARN, les limites d'autorisations et la politique de session sont évaluées dans le cadre de la décision finale. Un refus implicite de l'une ou l'autre politique entraîne une DENY décision. Lorsque le principal élément de la politique basée sur les ressources est une session de rôle ARN, les autorisations sont accordées directement à la session. Les autres types de politiques n'affectent pas la décision.
IAM user	Autorise IAM l'utilisateur ARN	Refus implicite	Refus implicite	Ne s’applique pas	ALLOW	Les autorisations sont accordées directement à l'utilisateur. Les autres types de politiques n'affectent pas la décision.
IAMutilisateur fédéré () `GetFederationToken`	Autorise IAM l'utilisateur ARN or Autorise une session utilisateur IAM fédérée ARN	Refus implicite	Refus implicite	Refus implicite	DENY- IAM utilisateur ARN or ALLOW- IAM session utilisateur fédérée ARN	Lorsque le principal responsable de la politique basée sur les ressources est un IAMutilisateur ARN, un refus implicite dans la limite des autorisations ou dans la politique de session entraîne un. DENY Lorsque le principal élément de la politique basée sur les ressources est une session utilisateur IAM fédérée ARN, les autorisations sont accordées directement à la session. Les autres types de politiques n'affectent pas la décision.
utilisateur root	Autorise l'utilisateur root ARN	Ne s’applique pas	Ne s’applique pas	Ne s’applique pas	ALLOW	L'utilisateur root a un accès complet et illimité à toutes les ressources de votre Compte AWS. Pour savoir comment contrôler l'accès à l'utilisateur root pour les comptes dans AWS Organizations, consultez la section Politiques de contrôle des services (SCPs) dans le Guide de l'utilisateur des Organizations.
AWS service principal	Autorise un directeur AWS de service	Ne s’applique pas	Ne s’applique pas	Ne s’applique pas	ALLOW	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.

IAMrôle — Les politiques basées sur les ressources qui accordent des autorisations à un IAM rôle ARN sont limitées par un refus implicite dans une limite d'autorisation ou une politique de session. Vous pouvez spécifier le rôle ARN dans l'élément principal ou dans la clé de aws:PrincipalArn condition. Dans les deux cas, le principal qui fait la demande est la session de IAM rôle.

Les limites d'autorisations et les politiques de session ne limitent pas les autorisations accordées à l'aide de la clé de aws:PrincipalArn condition avec un caractère générique (*) dans l'élément principal, sauf si les politiques basées sur l'identité contiennent un refus explicite. Pour plus d’informations, consultez IAMprincipes de rôle.

Exemple de rôle ARN
```
arn:aws:iam::111122223333:role/examplerole
```
IAMsession de rôle : au sein d'un même compte, les politiques basées sur les ressources qui accordent des autorisations à une session de IAM rôle ARN accordent des autorisations directement à la session de rôle assumé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 assumez un rôle et que vous faites une demande, le principal auteur de la demande est la session du IAM rôle ARN et non celle ARN du rôle lui-même. Pour plus d’informations, consultez Principaux de séance de rôle.

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

Exemple IAM d'utilisateur ARN
```
arn:aws:iam::111122223333:user/exampleuser
```
IAMsessions utilisateur fédérées : une session utilisateur IAM fédérée est une session créée par un appel. GetFederationToken Lorsqu'un utilisateur fédéré fait une demande, le principal auteur de la demande est l'utilisateur fédéré ARN et non celui qui ARN l'IAMa fédérée. Au sein d'un même compte, les politiques basées sur les ressources qui accordent des autorisations à un utilisateur fédéré ARN accordent des autorisations directement à la session. 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 l'autorisation à ARN l'IAMutilisateur qui a fédéré, les demandes faites par l'utilisateur fédéré pendant la session sont limitées par un refus implicite dans une limite d'autorisation ou une politique de session.

Exemple de session utilisateur IAM fédérée ARN
```
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 IAM utilisateur, il s'agit notamment des politiques utilisateur et des politiques des 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.
IAMlimites d'autorisations — Le code vérifie ensuite si l'IAMentité 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 principes de session incluent une session de IAM rôle ou une session utilisateur IAM fédérée. 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 adopter une politique de session lorsque vous utilisez le AWS CLI ou pour AWS API obtenir des informations d'identification temporaires pour un rôle ou un utilisateur IAM fédéré.
- 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.
Erreurs — Si le code d' AWS application rencontre une erreur à un moment quelconque au cours 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'carlossalazarIAMutilisateur.


{
    "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 demande l'enregistrement d'un fichier dans le carlossalazar-logs bucket, il AWS détermine les politiques 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 vérifie d'abord si une Deny déclaration 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 se rende compte de son erreur et essaie d'enregistrer le fichier dans le carlossalazar bucket. AWS recherche une Deny déclaration et n'en trouve aucune. 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. AWS Autorise donc 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 IAM principal 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'AllowGetListinstruction autorise l'accès en lecture seule aux IAM actions commençant par les Get préfixes et. List Toutes les autres actionsIAM, telles que, iam:CreatePolicy sont implicitement refusées. La DenyReports déclaration refuse explicitement l'accès aux IAM rapports en refusant l'accès aux actions qui incluent le Report suffixe, telles queiam:GetOrganizationsAccessReport. Si quelqu'un ajoute une autre politique à ce principe pour lui accorder l'accès aux IAM rapports, par exemple, les iam:GenerateCredentialReport demandes liées aux rapports sont toujours refusées en raison de ce refus 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