Transmission des balises de session dans AWS STS

Les balises de session sont des attributs de paire clé-valeur que vous transmettez lorsque vous endossez un rôle IAM ou fédérez un utilisateur dans AWS STS. Pour ce faire, effectuez une demande de AWS CLI ou d'API AWS via AWS STS ou via votre fournisseur d'identité (IdP). Lorsque vous utilisez AWS STS pour demander des informations d'identification de sécurité temporaires, vous générez une session. Les sessions expirent et disposent d'informations d'identification, telles qu'une paire de clés d'accès et un jeton de session. Lorsque vous utilisez les informations d'identification de session pour effectuer une demande ultérieure, le contexte de demande inclut la clé de contexte aws:PrincipalTag. Vous pouvez utiliser la clé aws:PrincipalTag dans l'élément Condition de vos politiques pour autoriser ou refuser l'accès en fonction de ces balises.

Lorsque vous utilisez des informations d'identification temporaires pour effectuer une demande, votre principal peut inclure un ensemble d'étiquettes. Ces balises proviennent des sources suivantes :

Opérations de balisage de session

Vous pouvez passer des balises de session à l'aide des opérations d'AWS CLI ou d'API AWS suivantes dans AWS STS. La fonctionnalité Changer de rôle AWS Management Console ne vous permet pas de transmettre des balises de session.

Vous pouvez également définir les balises de session comme transitives. Les balises transitives persistent pendant le chaînage des rôles. Pour en savoir plus, consultez Chaînage des rôles avec des balises de session.

Le tableau suivant compare les méthodes de transmission des balises de session.

Les opérations qui prennent en charge le balisage de session peuvent échouer si l'une des conditions suivantes est remplie :

Choses à savoir sur les balises de session

Avant d'utiliser des balises de session, veuillez consulter les détails suivants concernant les sessions et les balises.

Autorisations requises pour ajouter des balises de session

En plus de l'action qui correspond à l'opération d'API, vous devez disposer de l'action d'autorisation suivante dans votre politique :

sts:TagSession

Vous pouvez utiliser l'action sts:TagSession avec les clés de condition suivantes.

Par exemple, la politique d'approbation de rôle suivante permet à l'utilisateur test-session-tags d'endosser le rôle auquel la politique est attachée. Lorsque cet utilisateur endosse le rôle, il doit utiliser l'interface AWS CLI ou l'API AWS pour transmettre les trois étiquettes de session requises et l'ID externe requis. En outre, l'utilisateur peut choisir de définir les balises Department et Project comme transitives.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowIamUserAssumeRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::123456789012:user/test-session-tags"},
            "Condition": {
              "StringLike": {
                    "aws:RequestTag/Project": "*",
                    "aws:RequestTag/CostCenter": "*",
                    "aws:RequestTag/Department": "*"
                },
                "StringEquals": {"sts:ExternalId": "Example987"}
            }
        },
        {
            "Sid": "AllowPassSessionTagsAndTransitive",
            "Effect": "Allow",
            "Action": "sts:TagSession",
            "Principal": {"AWS": "arn:aws:iam::123456789012:user/test-session-tags"},
            "Condition": {
                "StringLike": {
                    "aws:RequestTag/Project": "*",
                    "aws:RequestTag/CostCenter": "*"
                },
                "StringEquals": {
                    "aws:RequestTag/Department": [
                        "Engineering",
                        "Marketing"
                    ]
                },
                "ForAllValues:StringEquals": {
                    "sts:TransitiveTagKeys": [
                        "Project",
                        "Department"
                    ]
                }
            }
        }
    ]
}

À quoi sert cette politique ?

Transmission de balises de session avec AssumeRole

L'opération AssumeRole renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux ressources AWS. Vous pouvez utiliser l'utilisateur ou les informations d'identification du rôle IAM pour appeler AssumeRole. Pour transmettre des balises de session tout en endossant un rôle, utilisez l'option AWS CLI --tags ou le paramètre d'API AWS Tags.

Pour définir les balises comme transitives, utilisez l'option AWS CLI --transitive-tag-keys ou le paramètre d'API AWS TransitiveTagKeys. Les balises transitives persistent pendant le chaînage des rôles. Pour plus d'informations, veuillez consulter Chaînage des rôles avec des balises de session.

L'exemple suivant montre un exemple de demande qui utilise AssumeRole. Dans cet exemple, lorsque vous endossez le rôle my-role-example, vous créez une session nommée my-session. Vous ajoutez les paires clé-valeur de balise de session Project = Automation, CostCenter = 12345 et Department = Engineering. Vous définissez également les balises Project et Department comme transitives en spécifiant leurs clés. Vous devez transmettre une valeur unique pour chaque balise de session. AWS STS ne prend pas en charge les balises de session à plusieurs valeurs.

aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/my-role-example \
--role-session-name my-session \
--tags Key=Project,Value=Automation Key=CostCenter,Value=12345 Key=Department,Value=Engineering \
--transitive-tag-keys Project Department \
--external-id Example987

Transmission de balises de session avec AssumeRoleWithSAML

L'opération AssumeRoleWithSAML authentifie à l'aide de la fédération basée sur SAML. Cette opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux ressources AWS. Pour de plus amples informations sur l'utilisation de la fédération basée sur SAML pour l'accès à l'AWS Management Console, veuillez consulter Activation de l'accès des utilisateurs fédérés SAML 2.0 à la AWS Management Console. Pour plus d'informations sur l'accès à l'interface AWS CLI ou à l'API AWS, veuillez consulter SAMLfédération 2.0. Pour un didacticiel sur la configuration de la fédération SAML pour vos utilisateurs Active Directory, veuillez consulter AWS Federated Authentication with Active Directory Federation Services (ADFS) dans AWS Security Blog.

En tant qu'administrateur, vous pouvez autoriser les membres de l'annuaire de votre entreprise à se fédérer dans AWS à l'aide de l'opération AWS STS AssumeRoleWithSAML. Pour ce faire, effectuez les tâches suivantes :

AWS inclut des partenaires qui possèdent une expérience de bout en bout certifiée pour les balises de session avec leurs solutions d'identité. Pour savoir comment utiliser ces fournisseurs d'identité pour configurer des balises de session, veuillez consulter Intégration de prestataires de solution SAML tiers avec AWS.

Pour transmettre les attributs SAML en tant que balises de session, incluez l'élément Attribute dont l'attribut Name est défini sur https://aws.amazon.com/SAML/Attributes/PrincipalTag:{TagKey}. Utilisez l'élément AttributeValue pour spécifier la valeur de la balise. Incluez un élément Attribute distinct pour chaque balise de session.

Par exemple, supposons que vous souhaitez transmettre les attributs d'identité suivants en tant que balises de session :

Pour transmettre ces attributs, incluez les éléments suivants dans votre assertion SAML.

<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Project">
  <AttributeValue>Automation</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter">
  <AttributeValue>12345</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department">
  <AttributeValue>Engineering</AttributeValue>
</Attribute>

Pour définir les balises précédentes ci-dessus comme transitives, incluez un autre élément Attribute dont l'attribut Name est défini sur https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys. Les balises transitives persistent pendant le chaînage des rôles. Pour plus d'informations, veuillez consulter Chaînage des rôles avec des balises de session.

Pour définir les balises Department et Project comme transitives, utilisez l'attribut à valeurs multiples suivant :

<Attribute Name="https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys">
  <AttributeValue>Project</AttributeValue>
  <AttributeValue>Department</AttributeValue>
</Attribute>

Transmission de balises de session avec AssumeRoleWithWebIdentity

Utilisez la fédération conforme à OpenID Connect (OIDC) pour authentifier l’opération AssumeRoleWithWebIdentity. Cette opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux ressources AWS. Pour de plus amples informations sur l'utilisation de la fédération d'identités Web pour l'accès à AWS Management Console, veuillez consulter Fédération OIDC.

Pour transmettre les balises de session depuis OpenID Connect (OIDC), vous devez inclure les balises de session dans le JWT (JSON Web Token) lorsque vous soumettez la requête AssumeRoleWithWebIdentity. Pour en savoir plus sur les jetons OIDC et les revendications, veuillez consulter Utilisation des jetons avec les groupes d'utilisateurs dans le Guide du développeur Amazon Cognito.

AWS prend en charge deux formats de demande pour inclure des balises de session dans le JWT :

Format de demande imbriqué

Le format de demande imbriqué utilise une structure au sein de l’espace de noms https://aws.amazon.com/tags du JWT. Dans ce format :

L’exemple suivant illustre un JWT décodé utilisant le format d’objet imbriqué :

{
    "sub": "johndoe",
    "aud": "ac_oic_client",
    "jti": "ZYUCeRMQVtqHypVPWAN3VB",
    "iss": "https://xyz.com",
    "iat": 1566583294,
    "exp": 1566583354,
    "auth_time": 1566583292,
    "https://aws.amazon.com/tags": {
        "principal_tags": {
            "Project": ["Automation"],
            "CostCenter": ["987654"],
            "Department": ["Engineering"]
        },
        "transitive_tag_keys": [
            "Project",
            "CostCenter"
        ]
    }
}

Format de demande aplati

Le format de demande aplati est compatible avec les fournisseurs d’identité qui ne prennent pas en charge les objets imbriqués dans les demandes JWT, tels que Microsoft Entra ID. Dans ce format :

Voyons maintenant comment les mêmes informations sont représentées à l’aide du format de demande aplati :

{
    "sub": "johndoe",
    "aud": "ac_oic_client",
    "jti": "ZYUCeRMQVtqHypVPWAN3VB",
    "iss": "https://xyz.com",
    "iat": 1566583294,
    "exp": 1566583354,
    "auth_time": 1566583292,
    "https://aws.amazon.com/tags/principal_tags/Project": "Automation",
    "https://aws.amazon.com/tags/principal_tags/CostCenter": "987654",
    "https://aws.amazon.com/tags/principal_tags/Department": "Engineering",
    "https://aws.amazon.com/tags/transitive_tag_keys": [
        "Project",
        "CostCenter"
    ]
}

Les deux exemples JWT décodés montrent un appel à AssumeRoleWithWebIdentity avec les balises de session Project, CostCenter, et Department. Les deux jetons définissent les balises Project et CostCenter comme transitives. Les balises transitives persistent pendant le chaînage des rôles. Pour en savoir plus, consultez Chaînage des rôles avec des balises de session.

Le format de demande aplati permet d’obtenir le même résultat que le format de demande imbriqué, mais utilise une structure aplatie pour les balises. Il vous permet d’inclure des balises de session dans des environnements où les objets JSON imbriqués ne sont pas pris en charge dans les demandes JWT. Lorsque vous utilisez l’un ou l’autre format, assurez-vous que votre fournisseur d’identité est configuré pour émettre des jetons avec les structures de demande appropriées. AWS prend en charge les deux formats de demande, de sorte que vous pouvez choisir celui qui répond le mieux aux exigences spécifiques de votre fournisseur d’identité.

Transmission de balises de session à l'aide de GetFederationToken

Le GetFederationToken vous permet de fédérer votre utilisateur. Cette opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux ressources AWS. Pour ajouter des balises à votre session utilisateur fédérée, utilisez l'option AWS CLI --tags ou le paramètre d'API AWS Tags. Vous ne pouvez pas définir les balises de session comme transitives lorsque vous utilisez le GetFederationToken, car vous ne pouvez pas utiliser les informations d'identification temporaires pour endosser un rôle. Vous ne pouvez pas utiliser le chaînage de rôles dans ce cas.

Voici un exemple de réponse à l'aide de GetFederationToken. Dans cet exemple, lorsque vous demandez le jeton, vous créez une session nommée my-fed-user. Vous ajoutez les paires clé-valeur de la balise de session Project = Automation et Department = Engineering.

aws sts get-federation-token \
--name my-fed-user \
--tags key=Project,value=Automation key=Department,value=Engineering

Lorsque vous utilisez les informations d'identification temporaires renvoyées par l'opération GetFederationToken, les balises principales de la session incluent les balises de l'utilisateur et les balises de session transmises.

Chaînage des rôles avec des balises de session

Vous pouvez endosser un rôle, puis utiliser les informations d'identification temporaires pour en endosser un autre. Vous pouvez continuer d'une session à une autre. C'est ce qu'on appelle le chaînage des rôles. Lorsque vous transmettez des balises de session en endossant un rôle, vous pouvez définir les clés comme transitives. Cela garantit que ces balises de session sont transmises aux sessions suivantes dans une chaîne de rôles. Vous ne pouvez pas définir les balises de rôle comme transitives. Pour transmettre ces balises aux sessions suivantes, indiquez-les en tant que balises de session.

L'exemple suivant montre comment AWS STS transmet les balises de session, les balises transitives et les balises de rôle aux sessions suivantes d'une chaîne de rôles.

Dans cet exemple de scénario de chaînage de rôles, vous utilisez une clé d'accès utilisateur IAM dans la AWS CLI pour endosser un rôle nommé Role1. Vous utilisez ensuite les informations d'identification de session résultantes pour endosser un second rôle nommé Role2. Vous pouvez ensuite utiliser les informations d'identification de la deuxième session pour endosser un troisième rôle nommé Role3. Ces demandes se déroulent sous la forme de trois opérations distinctes. Chaque rôle est déjà balisé dans IAM. Et lors de chaque demande, vous transmettez des balises de session supplémentaires.

Lorsque vous enchaînez des rôles, vous pouvez vous assurer que les balises d'une session antérieure persistent jusqu'aux sessions ultérieures. Pour ce faire à l'aide de la commande de la CLI assume-role, vous devez transmettre la balise en tant que balise de session et la définir comme transitive. Vous transmettez la balise Star = 1 en tant que balise de session. La commande attache également la balise Heart = 1 au rôle et s'applique en tant que balise principale lorsque vous utilisez la session. Cependant, vous voulez également que la balise Heart = 1 transmette automatiquement à la deuxième ou troisième session. Pour ce faire, vous l'incluez manuellement en tant que balise de session. Les balises de principal de session résultantes incluent ces deux balises et les définissent comme transitives.

Vous effectuez cette demande à l'aide de la commande d'AWS CLI suivante :

aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Role1 \
--role-session-name Session1 \
--tags Key=Star,Value=1 Key=Heart,Value=1 \
--transitive-tag-keys Star Heart

Vous utilisez ensuite les informations d'identification pour cette session pour endosser Role2. La commande attache la balise Sun = 2 au deuxième rôle et s'applique en tant que balise principale lorsque vous utilisez la deuxième session. Les balises Heart = Star héritent des balises de session transitive de la première session. Les balises principales résultantes de la deuxième session sont Heart = 1, Star = 1 et Sun = 2. Heart et Star continueront d'être transitives. La balise Sun attachée à Role2 n'est pas marquée comme transitive, car il ne s'agit pas d'une balise de session. Les sessions futures n'héritent pas de cette balise.

Vous effectuez cette deuxième demande à l'aide de la commande d'AWS CLI suivante :

aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Role2 \
--role-session-name Session2

Vous utilisez ensuite les informations d'identification de la deuxième session pour endosser Role3. Les balises principales de la troisième session proviennent de toutes les nouvelles balises de session, des balises de session transitive héritées et des balises de rôle. Les balises Heart = 1 et Star = 1 de la deuxième session ont été héritées de la balise de session transitive de la première session. Si vous essayez de transmettre la balise de session Sun = 2, l'opération échoue. La balise de session Star = 1 héritée remplace la balise du rôle Star = 3. Dans le chaînage des rôles, la valeur d’une balise transitive remplace le rôle correspondant à la valeur ResourceTag avant l’évaluation de la politique de confiance de rôle. Dans cet exemple, si Role3 utilise Star en tant que ResourceTag dans la politique de confiance de rôle, et définit la valeur ResourceTag à la valeur de balise transitive à partir de la session de rôle appelant. La balise du rôle Lightning s'applique également à la troisième session et n'est pas définie comme transitive.

Vous effectuez la troisième demande à l'aide de la commande d'AWS CLI suivante :

aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Role3 \
--role-session-name Session3

Utilisation des balises de session pour ABAC

Le contrôle d'accès basé sur les attributs (ABAC) utilise une stratégie d'autorisation qui définit les autorisations en fonction des attributs de balise.

Si votre entreprise utilise un fournisseur d'identité (IdP) basé sur OIDC ou SAML pour gérer les identités des utilisateurs, vous pouvez configurer votre assertion pour transmettre les balises de session à AWS. Par exemple, avec les identités d'utilisateur d'entreprise, lorsque vos employés se fédèrent en AWS, AWS applique leurs attributs à leur principal résultant. Vous pouvez ensuite utiliser l'ABAC pour autoriser ou refuser des autorisations sur la base de ces attributs. Pour plus de détails, consultez Didacticiel IAM : utilisation de balises de session SAML pour le contrôle ABAC.

Pour plus d'informations sur l'utilisation d'IAM Identity Center avec ABAC, consultez la section Attributs pour le contrôle d'accès dans le Guide de l'utilisateur de AWS IAM Identity Center.

Affichage des balises de session dans CloudTrail

Vous pouvez utiliser AWS CloudTrail pour afficher les demandes utilisées pour endosser des rôles ou fédérer des utilisateurs. Le fichier journal CloudTrail contient des informations sur les balises principales de la session utilisateur endossée ou fédérée. Pour plus d'informations, veuillez consulter Journalisation IAM et AWS STS API appels avec AWS CloudTrail.

Par exemple, supposons que vous effectuiez une demande AWS STS AssumeRoleWithSAML, que vous transmettiez des balises de session et que vous définissiez ces balises comme transitives. Vous trouverez les informations suivantes dans votre journal CloudTrail.

    "requestParameters": {
        "sAMLAssertionID": "_c0046cEXAMPLEb9d4b8eEXAMPLE2619aEXAMPLE",
        "roleSessionName": "MyRoleSessionName",
        "principalTags": {
            "CostCenter": "987654",
            "Project": "Unicorn"
        },
        "transitiveTagKeys": [
            "CostCenter",
            "Project"
        ],
        "durationSeconds": 3600,
        "roleArn": "arn:aws:iam::123456789012:role/SAMLTestRoleShibboleth",
        "principalArn": "arn:aws:iam::123456789012:saml-provider/Shibboleth"
    },

Vous pouvez afficher les exemples de journaux CloudTrail suivants pour afficher les événements qui utilisent des balises de session.