View a markdown version of this page

Comment ? AWS la logique du code d'application évalue les demandes pour autoriser ou refuser l'accès - AWS Gestion de l’identité et des accès

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.

Comment ? AWS la logique du code d'application évalue les demandes pour autoriser ou refuser l'accès

Le code AWS d'exécution décide si une demande envoyée à AWS doit être acceptée ou refusée. AWS évalue toutes les politiques applicables au contexte de la demande. Voici un résumé de la logique d'évaluation des AWS politiques.

  • 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.

  • Les demandes doivent être explicitement autorisées par une politique ou un ensemble de politiques suivant la logique d’évaluation ci-dessous pour être autorisées.

  • Un refus explicite remplace une autorisation explicite.

L’évaluation de la politique peut varier selon que la demande concerne un seul compte ou plusieurs comptes. Pour plus d’informations sur la manière dont une décision d’évaluation de politique est prise pour un rôle IAM ou un utilisateur au sein d’un seul compte, consultez Évaluation des politiques pour les demandes au sein d’un même compte. Pour plus de détails sur la manière dont une décision d’évaluation des politiques est prise pour les demandes entre comptes, consultez Cross-account logique d'évaluation des politiques.

  • Deny evaluation (Refuser l'évaluation) : par défaut, toutes les demandes sont refusées. Il s'agit d'un refus implicite. Le code AWS d'application évalue toutes les politiques du compte qui s'appliquent à la demande. Il s'agit notamment des AWS Organizations SCP et des RCP, des politiques basées sur les ressources, des politiques basées sur l'identité, des limites d'autorisations IAM 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 d’application trouve un refus explicite qui s’applique, il retourne la décision finale Refuser. S'il n'y a pas de refus explicite, l'évaluation du code d'application se poursuit.

  • AWS Organizations RCP — Le code d'application évalue les politiques de contrôle AWS Organizations des ressources (RCP) qui s'appliquent à la demande. Les RPC s’appliquent aux ressources du compte auquel elles sont rattachées. Si le code d’application ne trouve aucune instruction Allow applicable dans les RPC, le code d’application retourne la décision finale Refuser. Notez qu’une politique gérée AWS appelée RCPFullAWSAccess est automatiquement créée et attachée à chaque entité de votre organisation, y compris la racine, chaque unité d’organisation et Compte AWS lorsque les RCP sont activées. RCPFullAWSAccess ne peut pas être détachée, il y aura donc toujours une instruction Allow. S’il n’y a pas de RCP, ou si la RCP autorise l’action demandée, l’évaluation du code d’application se poursuit.

  • AWS Organizations SCP — Le code d'application évalue les politiques de contrôle des AWS Organizations services (SCP) 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 SCP, le code d’application retourne la décision finale 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.

  • Resource-based politiques — Au sein d'un même compte, les politiques basées sur les ressources ont un impact différent sur l'évaluation des politiques en fonction du type de principal accédant à la ressource et du principal autorisé dans la stratégie 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 Allow 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 les politiques clés KMS constituent des exceptions à cette logique, car elles doivent autoriser explicitement l'accès pour les principaux acteurs. Resource-based politiques relatives à des services autres que l'IAM et AWS KMS peuvent également nécessiter une Allow déclaration explicite dans le même compte pour autoriser l'accès. Pour plus d’informations, consultez la documentation service spécifique avec lequel vous travaillez.

    Pour les demandes d’évaluation de politiques à compte unique, 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 session. Les principaux de session incluent les sessions de rôle IAM ou des principaux d’utilisateur fédéréAWS STS. 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.

    • Rôle IAM  : Resource-based les politiques qui accordent des autorisations à un ARN de rôle IAM sont limitées par un refus implicite dans une limite d'autorisations ou une politique de session. Vous pouvez spécifier l’ARN du rôle dans l’élément Principal ou dans la clé de condition aws:PrincipalArn. Dans les deux cas, le principal qui fait la demande est la session de rôle IAM.

      Les limites de permissions et les politiques de session ne limitent pas les permissions accordées à l’aide de la clé de condition aws:PrincipalArn 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 de plus amples informations, veuillez consulter Principaux de rôles IAM.

      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 faites une demande, le principal qui fait la demande est l'ARN de séance du rôle IAM et non l'ARN du rôle lui-même. Pour de plus amples informations, veuillez consulter Principaux de séance de rôle.

      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

    • AWS STS Federated User Principal  : une session utilisateur fédérée est une session créée par un appel. 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.

      Cependant, 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 faites 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 session d’utilisateur fédérée

      arn:aws:sts::111122223333:federated-user/exampleuser

  • Identity-based politiques — Le code d'application vérifie les politiques basées sur l'identité pour le mandant. 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 d’application renvoie une décision finale Refuser. Si une instruction dans n’importe quelle politique basée sur l’identité applicable autorise l’action demandée, le code d’évaluation continue.

  • Limite des autorisations IAM : le code d’application vérifie 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 d'application 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 d’évaluation continue.

  • Politiques de session : le code d’application vérifie si le principal est un principal de session. Les principaux de session incluent une session de rôle IAM ou une session utilisateur AWS STS 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 d’application 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' AWS API AWS CLI or pour obtenir des informations d'identification temporaires pour un rôle ou un utilisateur principal AWS STS fédéré. Si vous n’avez pas adopté de politique de session, une politique de session par défaut est créée et le code d’application renvoie la décision finale Autoriser.

    • Si une politique de session est présente et n'autorise pas l'action demandée, la demande est implicitement refusée. Le code d'application retourne la décision finale Deny (Refuser).

    • Le code d’application vérifie si le principal est une session de rôle. Si le principal est une session de rôle, la demande est autorisée. Sinon, la demande est implicitement rejetée et le code d’application renvoie une décision finale Refuser.

    • 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.