Traitement du contexte de la demande - AWS Identity and Access Management
Comprendre le modèle PARCImportance du contexte de la demandeComment AWS utilise le contexte de la demandeExemple d’évaluation des politiques à l’aide du modèle PARC

Traitement du contexte de la demande

Lorsqu’AWS évalue et autorise une demande, il rassemble les informations relatives à cette demande dans un contexte de demande. Le contexte de la demande contient toutes les informations pouvant être utilisées dans l’évaluation de la politique.

  • Principal : l’utilisateur, le rôle ou le principal utilisateur fédéré à l’origine de la demande. Les informations sur le principal incluent les politiques associées à ce dernier.

  • Actions : une ou plusieurs actions que le principal souhaite exécuter.

  • Ressources : un ou plusieurs objets de ressource AWS sur lequel les actions ou opérations sont exécutées.

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

  • Données d'environnement : informations sur l'adresse IP, l'agent utilisateur, le statut SSL ou le moment de la journée.

Ces informations sont comparées aux politiques applicables afin de déterminer s’il convient d’accepter ou de refuser la demande. Vous pouvez organiser ces informations de propriété à l’aide du modèle PARC (Principal, Action, Ressource, et Condition) afin de mieux comprendre comment les politiques AWS sont évaluées.

Comprendre le modèle PARC

Le modèle PARC représente le contexte de la demande sur la base des quatre éléments JSON du langage de politique :

  • Principal : l’entité à l’origine de la demande. Un principal représente un utilisateur humain ou une charge de travail programmatique qui peut être authentifié et autorisé à effectuer des actions dans Comptes AWS.

  • Action : l’opération en cours d’exécution. Souvent, l’action sera mappée à une action API.

  • Resource ; la ressource AWS sur laquelle l’action est effectuée.

  • Condition : contraintes supplémentaires qui doivent être respectées pour que la demande soit acceptée.

Voici un exemple illustrant comment le modèle PARC pourrait représenter un contexte de demande :

Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:
- aws:UserId=AIDA123456789EXAMPLE:BobsSession
- aws:PrincipalAccount=123456789012
- aws:PrincipalOrgId=o-example
- aws:PrincipalARN=arn:aws:iam::AIDA123456789EXAMPLE:role/HR
- aws:MultiFactorAuthPresent=true
- aws:CurrentTime=...
- aws:EpochTime=...
- aws:SourceIp=...
- aws:PrincipalTag/dept=123
- aws:PrincipalTag/project=blue
- aws:RequestTag/dept=123

Importance du contexte de la demande

Il est essentiel de comprendre le contexte de la demande et son interaction avec l’évaluation des politiques pour :

  • Résoudre les problèmes d’accès

  • Concevoir des politiques efficaces et sécurisées

  • Comprendre l’étendue complète des autorisations accordées par une politique

  • Prédire le résultat des évaluations des politiques dans différents scénarios

En visualisant le contexte de la demande à l’aide du modèle PARC, vous pouvez plus facilement comprendre comment AWS prend ses décisions d’autorisation et concevoir vos politiques plus efficacement.

Comment AWS utilise le contexte de la demande

Lors de l’évaluation des politiques, AWS compare les informations contenues dans le contexte de la demande avec les informations spécifiées dans toutes les politiques applicables. Cela inclut les politiques basées sur l’identité, les politiques basées sur les ressources, les limites des autorisations IAM, les SCP des organisations, les RCP des organisations et les politiques de session.

Pour chaque type de politique, AWS utilise le contexte de la demande pour vérifier :

  • Si la politique s’applique à la demande en fonction du principal.

  • Si l’action demandée est autorisée sur la ressource spécifiée.

  • Si les conditions spécifiées dans la politique sont remplies par le contexte de la demande.

La façon dont AWS évalue les politiques dépend des types de politiques qui s'appliquent au contexte de la demande. Ces types de politique sont utilisables dans un seul Compte AWS. Pour plus d'informations sur ces types de politique, consultez Politiques et autorisations dans AWS Identity and Access Management. Pour savoir comment AWS évalue les stratégies d'accès entre comptes, veuillez consulter Logique d'évaluation des politiques entre comptes.

  • Politique de contrôle des ressources (RCP) AWS Organizations : les RCP AWS Organizations spécifient les autorisations maximales pour une les ressources au sein des comptes d’une organisation ou d’une unité organisationnelle (UO). Les RCP s’appliquent aux ressources des comptes de membres et ont un impact sur les autorisations effectives des principaux, y compris le Utilisateur racine d'un compte AWS, que les principaux appartiennent ou non à votre organisation. Les RCP ne s’appliquent pas aux ressources du compte de gestion de l’organisation ni aux appels effectués par des rôles liés à des services. Si une RCP est présente, les autorisations accordées par les politiques basées sur les identités et les ressources aux ressources de vos comptes membres ne sont effectives que si la RCP autorise l’action.

  • Politique de contrôle des services (SCP) AWS Organizations : les SCP AWS Organizations spécifient les autorisations maximales pour les principaux au sein des comptes d’une organisation ou d’une unité organisationnelle (UO). La SCP s’applique aux principaux dans les comptes membres, y compris dans chaque Utilisateur racine d'un compte AWS. Si une SCP est présente, les autorisations accordées par les politiques basées sur les identités et les ressources aux principaux de vos comptes membres ne sont effectives que si la SCP autorise l’action. Les seules exceptions sont les principaux du compte de gestion de l’organisation et les rôles liés à un service.

  • Politiques basées sur les ressources : les politiques basées sur les ressources accordent des autorisations aux principaux spécifiés dans la politique. Les autorisations définissent ce que le principal peut faire avec la ressource à laquelle la politique est attachée.

  • Limites des autorisations : les limites d’autorisations sont une fonctionnalité 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 politiques 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 de plus amples informations, consultez Comment la logique du code d’application AWS évalue les demandes d’autorisation ou de refus d’accès.

  • 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 de session : les politiques de session sont des politiques que vous transmettez en tant que paramètres lorsque vous créez par programmation une session temporaire pour un rôle ou une session d’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. Pour de plus amples informations, consultez Politiques de session.

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

Note

Les politiques déclaratives AWS Organizations vous permettent de déclarer et d’appliquer de manière centralisée la configuration souhaitée pour un Service AWS donné à l’échelle de l’organisation. Étant donné que les politiques déclaratives sont appliquées directement au niveau du service, elles n’ont pas d’impact direct sur les demandes d’évaluation des politiques et ne sont pas incluses dans le contexte de la demande. Pour plus d’informations, consultez Politiques déclaratives dans le Guide de l’utilisateur AWS Organizations.

Exemple d’évaluation des politiques à l’aide du modèle PARC

Pour illustrer comment le contexte de la demande interagit avec l’évaluation de la politique, prenons un exemple de politique :

JSON
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:CreateBucket",
      "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/dept": "123"
        }
      }
    }
  ]
}

Dans cet exemple, la politique n’autoriserait l’action CreateBucket que si le contexte de la demande inclut une valeur aws:PrincipalTag/dept de « 123 » et si la ressource correspond au nom du compartiment amzn-s3-demo-bucket1. Le tableau suivant montre comment AWS utilise le contexte de la demande pour évaluer cette politique et prendre des décisions d’autorisation.

Politique Contexte de la requête Résultat de l’évaluation 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=123

Correspondance

 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
 
Principal: AIDA123456789EXAMPLE
Action: s3:DeleteBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=123

Aucune correspondance

 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:  
    - aws:PrincipalTag/dept=321

Aucune correspondance

 
"StringEquals": {
    "aws:PrincipalTag/dept": "123"
}
 
Principal: AIDA123456789EXAMPLE
Action: s3:CreateBucket
Resource: arn:aws:s3:::amzn-s3-demo-bucket1
Context:

Aucun aws:PrincipalTag dans la demande.

Aucune correspondance