Comment la logique du code d’application AWS évalue les demandes d’autorisation ou de refus d’accès

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.

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 et RCP 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 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.

RCP des organisations : le code d’application évalue les politiques de contrôle des ressources (RCP) AWS Organizations 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.

SCP des organisations : le code d’application évalue ensuite les politiques de contrôle des services (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 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.

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

Politiques basées sur l’identité : le code d’application vérifie 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 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 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 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'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 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.