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.
# Autorisations affectées aux informations d’identification de sécurité temporaires
Vous pouvez utiliser AWS Security Token Service (AWS STS) pour créer et fournir à des utilisateurs de confiance des informations d'identification de sécurité temporaires qui peuvent contrôler l'accès à vos AWS ressources. Pour plus d'informations sur AWS STS, voir[Informations d'identification de sécurité temporaires dans IAM](id_credentials_temp.md). Lorsqu' AWS STS émet des informations d'identification de sécurité temporaires, celles-ci sont valides jusqu'au délai d'expiration spécifié et elles ne peuvent pas être annulées. Toutefois, les autorisations octroyées aux informations d'identification de sécurité temporaires sont évaluées chaque fois qu'une demande est effectuée à l'aide de ces informations. Il est donc possible de révoquer les informations d'identification en modifiant leurs droits d'accès après leur émission.
Les rubriques suivantes supposent que vous avez une connaissance pratique des AWS autorisations et des politiques. Pour plus d'informations sur ces rubriques, consultez [Gestion de l'accès aux AWS ressources](access.md).
**Topics**
+ [Autorisations pour AssumeRole, AssumeRoleWith SAML et AssumeRoleWithWebIdentity](id_credentials_temp_control-access_assumerole.md)
+ [Surveiller et contrôler les actions prises avec les rôles endossés](id_credentials_temp_control-access_monitor.md)
+ [Autorisations pour GetFederationToken](id_credentials_temp_control-access_getfederationtoken.md)
+ [Autorisations pour GetSessionToken](id_credentials_temp_control-access_getsessiontoken.md)
+ [Désactivation des autorisations affectées aux informations d'identification de sécurité temporaires](id_credentials_temp_control-access_disable-perms.md)
+ [Octroi d'autorisations pour créer des informations d'identification de sécurité temporaires](id_credentials_temp_control-access_enable-create.md)
+ [Octroi d’autorisations pour l’utilisation de sessions de console à identité renforcée](id_credentials_temp_control-access_sts-setcontext.md)
# Autorisations pour AssumeRole, AssumeRoleWith SAML et AssumeRoleWithWebIdentity
La politique d'autorisations du rôle endossé actuellement déterminé les autorisations octroyées aux informations d'identification de sécurité temporaires renvoyées par `AssumeRole`, `AssumeRoleWithSAML` et `AssumeRoleWithWebIdentity`. Vous définissez ces autorisations lors de la définition ou de la mise à jour du rôle.
Le cas échéant, vous pouvez transmettre des [politiques de session](access_policies.md#policies_session) en ligne ou gérées en tant que paramètre des opérations d'API `AssumeRole`, `AssumeRoleWithSAML` ou `AssumeRoleWithWebIdentity`. Les politiques de session limitent les autorisations pour la session d'informations d'identification temporaires du rôle. Les autorisations de la session obtenues sont une combinaison des politiques basées sur l'identité du rôle et des politiques de session. Vous pouvez utiliser les informations d'identification temporaires du rôle lors des appels d' AWS API suivants pour accéder aux ressources du compte propriétaire du rôle. Vous ne pouvez pas utiliser les politiques de session pour accorder plus d'autorisations que celles autorisées par la politique basée sur l'identité du rôle endossé actuellement. Pour en savoir plus sur la façon dont AWS détermine les autorisations effectives d'un rôle, consultez [Logique d'évaluation de politiques](reference_policies_evaluation-logic.md).
![\[PermissionsWhenPassingRoles_Schéma\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/role_passed_policy_permissions.png)
Les politiques associées aux informations d'identification à l'origine de l'appel ne `AssumeRole` sont pas évaluées AWS lors de la prise de la décision d' « autoriser » ou de « refuser » l'autorisation. L'utilisateur renonce temporairement à ses autorisations d'origine en faveur de celles affectées au rôle endossé. Dans le cas des opérations `AssumeRoleWithSAML` et de l'`AssumeRoleWithWebIdentity`API, il n'y a aucune politique à évaluer car l'appelant de l'API n'est pas une AWS identité.
## Exemple : attribution d'autorisations à l'aide de AssumeRole
Vous pouvez utiliser l'opération d'API `AssumeRole` avec différents types de politiques. Voici quelques exemples.
### Politique d'autorisations de rôle
Dans cet exemple, vous appelez l'opération d'API `AssumeRole` sans spécifier la politique de session dans le paramètre `Policy` facultatif. Les autorisations affectées aux informations d'identification temporaires sont déterminées par la politique d'autorisations du rôle endossé. L'exemple de politique d'autorisations suivant accorde au rôle l'autorisation de répertorier tous les objets contenus dans un compartiment S3 nommé `productionapp`. Il permet également au rôle d'obtenir, de placer et de supprimer des objets dans ce compartiment.
**Example Exemple de politique d'autorisations de rôle**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::productionapp"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::productionapp/*"
}
]
}
```
### Politique de session transmise en tant que paramètre
Imaginons que vous souhaitiez autoriser un utilisateur à endosser le même rôle que dans l'exemple suivant. Mais, dans ce cas, vous voulez que la session de rôle ait uniquement l'autorisation d'obtenir et de placer des objets dans le compartiment `productionapp` S3. Vous ne souhaitez pas l'autoriser à supprimer des objets. Pour cela, vous pouvez créer un rôle et spécifier les autorisations souhaitées dans la politique d'autorisations du rôle. Vous pouvez également appeler l'API `AssumeRole` et inclure des politiques de session dans le paramètre `Policy` facultatif dans le cadre de l'opération d'API. Les autorisations de la session obtenues sont une combinaison des politiques basées sur l'identité du rôle et des politiques de session. Les politiques de session ne peuvent pas être utilisées pour accorder plus d'autorisations que celles autorisées par la politique basée sur l'identité du rôle endossé actuellement. Pour de plus amples informations sur les autorisations de session de rôle, veuillez consulter [Politiques de session](access_policies.md#policies_session).
Une fois que vous avez récupéré les informations d'identification temporaires de la nouvelle session, vous pouvez les transmettre à l'utilisateur auquel vous voulez donner ces autorisations.
Par exemple, imaginons que la politique suivante soit transmise en tant que paramètre de l'appel d'API. La personne qui utilise la session dispose d'autorisations pour effectuer uniquement les actions suivantes :
+ Répertorier tous les objets du compartiment `productionapp`.
+ Obtenir et placer des objets dans le compartiment `productionapp`.
Dans la session suivante, l'autorisation `s3:DeleteObject` est exclue du filtre et la session endossée n'obtient pas l'autorisation `s3:DeleteObject`. La politique définit les autorisations maximales pour la session de rôle afin qu'elle remplace les politiques d'autorisations existantes sur le rôle.
**Example Exemple de politique de session transmise avec l'appel d'API `AssumeRole`**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::productionapp"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
"Resource": "arn:aws:s3:::productionapp/*"
}
]
}
```
### Politique basée sur une ressource
Certaines AWS ressources prennent en charge les politiques basées sur les ressources, et ces politiques fournissent un autre mécanisme pour définir les autorisations qui affectent les informations d'identification de sécurité temporaires. Seules quelques ressources, comme les compartiments Amazon S3, les rubriques Amazon SNS et les files d'attente Amazon SQS, prennent en charge les politiques basées sur des ressources. L'exemple suivant développe les exemples précédents, à l'aide d'un compartiment S3 nommé `productionapp`. La politique suivante est attachée au compartiment.
Lorsque vous attachez la politique basée sur les ressources suivante au compartiment `productionapp`, *tous* les utilisateurs se voient refuser l'autorisation de supprimer des objets du compartiment. (Voir l'élément `Principal` dans la politique.) Cela inclut tous les utilisateurs du rôle endossé, même si la politique d'autorisations du rôle accorde l'autorisation `DeleteObject`. Une instruction `Deny` explicite a toujours priorité sur une instruction `Allow`.
**Example Exemple de politique de compartiment**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {"AWS": "*"},
"Effect": "Deny",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::productionapp/*"
}
}
```
Pour plus d'informations sur la façon dont plusieurs types de politiques sont combinés et évalués par AWS, voir[Logique d'évaluation de politiques](reference_policies_evaluation-logic.md).
# Surveiller et contrôler les actions prises avec les rôles endossés
Un [rôle IAM](id_roles.md) est un objet dans IAM auquel sont affectées des [autorisations](access_policies.md). Lorsque vous [assumez ce rôle](id_roles_manage-assume.md) en utilisant une identité IAM ou une identité extérieure AWS, vous recevez une session avec les autorisations attribuées au rôle.
Lorsque vous effectuez des actions dans AWS, les informations relatives à votre session peuvent être enregistrées AWS CloudTrail pour que l'administrateur de votre compte puisse les surveiller. Les administrateurs peuvent configurer les rôles de sorte à exiger des identités qu'elles transmettent une chaîne personnalisée identifiant la personne ou l'application qui effectue des actions dans AWS. Ces informations d'identité sont stockées en tant qu'*identité source* dans AWS CloudTrail. Lorsque l'administrateur examine l'activité dans CloudTrail, il peut consulter les informations d'identité de la source afin de déterminer qui ou quoi a effectué des actions dans le cadre de sessions à rôle assumé.
Une fois qu'une identité source est définie, elle est présente dans les demandes concernant toute AWS action entreprise au cours de la session de rôle. La valeur définie est conservée lorsqu'un rôle est utilisé pour assumer un autre rôle via l' AWS API AWS CLI or, ce que l'on appelle le [chaînage de rôles](id_roles.md#iam-term-role-chaining). La valeur définie ne peut pas être modifiée durant la session de rôle. Les administrateurs peuvent configurer des autorisations granulaires en fonction de la présence ou de la valeur de l'identité source afin de mieux contrôler les AWS actions entreprises avec des rôles partagés. Vous pouvez décider si l'attribut d'identité source peut être utilisé, s'il est requis ; et quelle valeur peut être utilisée.
L'utilisation de l'identité source est radicalement différente de celle du nom de session de rôle et des balises de session. La valeur d'identité source ne peut pas être modifiée une fois qu'elle est définie, et elle persiste pour toutes les actions supplémentaires qui sont prises durant la session de rôle. Voici comment utiliser les balises de session et le nom de session de rôle :
+ **Session tags** (Balises de session) : vous pouvez transmettre des balises de session lorsque vous endossez un rôle ou fédérez un utilisateur. Les balises de session sont présentes lorsqu'un rôle est endossé. Vous pouvez définir des politiques qui utilisent des clés de condition de balise pour accorder des autorisations à vos principaux en fonction de leurs balises. Vous pouvez ensuite l'utiliser CloudTrail pour afficher les demandes faites pour assumer des rôles ou fédérer des utilisateurs. Pour en savoir plus sur les balises de session, veuillez consulter [Transmettez les tags de session AWS STS](id_session-tags.md).
+ **Role session name** (Nom de la session de rôle) : vous pouvez utiliser la clé de condition `sts:RoleSessionName` dans une politique d'approbation de rôle pour exiger que vos utilisateurs fournissent un nom de session spécifique lorsqu'ils endossent un rôle. Le nom de session de rôle peut servir à différencier les sessions de rôle lorsqu'un rôle est utilisé par différents principaux. Pour en savoir plus sur le nom de session de rôle, consultez [sts : RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname).
Nous vous recommandons d'utiliser l'identité source pour contrôler l'identité qui endosse un rôle. L'identité de la source est également utile pour les CloudTrail journaux de minage afin de déterminer qui a utilisé le rôle pour effectuer des actions.
**Topics**
+ [Configuration d'utilisation de l'identité source](#id_credentials_temp_control-access_monitor-setup)
+ [Ce qu'il faut savoir sur l'identité source](#id_credentials_temp_control-access_monitor-know)
+ [Autorisations requises pour définir l'identité source](#id_credentials_temp_control-access_monitor-perms)
+ [Spécification d'une identité source lorsqu'un rôle est endossé](#id_credentials_temp_control-access_monitor-specify-sourceid)
+ [Utilisation de l'identité source avec AssumeRole](#id_credentials_temp_control-access_monitor-assume-role)
+ [Utilisation de l'identité source avec AssumeRoleWith SAML](#id_credentials_temp_control-access_monitor-assume-role-saml)
+ [Utilisation de l'identité source avec AssumeRoleWithWebIdentity](#id_credentials_temp_control-access_monitor-assume-role-web-id)
+ [Contrôle de l'accès au moyen des informations d'identité source](#id_credentials_temp_control-access_monitor-control-access)
+ [Affichage de l'identité de la source dans CloudTrail](#id_credentials_temp_control-access_monitor-ct)
## Configuration d'utilisation de l'identité source
Votre configuration d'utilisation de l'identité source dépend de la méthode employée lorsque vos rôles sont endossés. Par exemple, vos utilisateurs IAM peuvent endosser des rôles directement via l'opération `AssumeRole`. Si vous possédez des identités d'entreprise, également appelées identités du personnel, elles peuvent accéder à vos AWS ressources en utilisant`AssumeRoleWithSAML`. Si des utilisateurs finaux accèdent à vos applications mobiles ou Web, ils peuvent le faire en utilisant `AssumeRoleWithWebIdentity`. La présentation du flux de haut niveau qui suit vous aidera à comprendre comment effectuer une configuration pour utiliser les informations d'identité source dans votre environnement existant.
1. **Configurer les utilisateurs et les rôles test** : en utilisant un environnement de préproduction, configurez les utilisateurs et les rôles test, et configurez leurs politiques afin d'autoriser la définition d'une identité source.
Si vous utilisez un fournisseur d'identité (IdP) pour vos identités fédérées, configurez-le de sorte à transmettre un attribut utilisateur de votre choix pour l'identité source dans l'assertion ou le jeton.
1. **Assumer le rôle** : testez le fait d'endosser des rôles et de transmettre une identité source avec les utilisateurs et les rôles que vous configurez pour le test.
1. **Révision CloudTrail** : passez en revue les informations d'identité source de vos rôles de test dans vos CloudTrail journaux.
1. **Entraîner vos utilisateurs** : après avoir effectué des tests dans votre environnement de préproduction, vérifiez que vos utilisateurs savent parfaitement comment transmettre les informations d'identité source, si nécessaire. Définissez une date limite à laquelle vous exigerez de vos utilisateurs qu'ils fournissent une identité source dans votre environnement de production.
1. **Configurer des politiques de production** : configurez des politiques pour votre environnement de production, puis ajoutez-les à vos utilisateurs et rôles de production.
1. **Surveiller l'activité** : surveillez l'activité de votre rôle de production à l'aide de CloudTrail journaux.
## Ce qu'il faut savoir sur l'identité source
Gardez ce qui suit à l'esprit lorsque vous travaillez avec l'identité source.
+ Les politiques d'approbation pour tous les rôles connectés à un fournisseur d'identité doivent disposer de l'autorisation `sts:SetSourceIdentity`. Pour les rôles qui ne disposent pas de cette autorisation dans la politique d'approbation de rôle, l'opération `AssumeRole*` échouera. Si vous ne souhaitez pas mettre à jour la politique d'approbation de rôle pour chaque rôle, vous pouvez utiliser une instance de fournisseur d'identité distincte pour transmettre l'identité source. Ajoutez ensuite l'autorisation `sts:SetSourceIdentity` uniquement aux rôles qui sont connectés au fournisseur d'identité distinct.
+ Lorsqu'une identité définit une identité source, la clé `sts:SourceIdentity` est présente dans la demande. Pour les actions qui seront prises ultérieurement durant la session de rôle, la clé `aws:SourceIdentity` est présente dans la demande. AWS ne contrôle la valeur de l'identité source dans aucune des clés `sts:SourceIdentity` ou `aws:SourceIdentity`. Si vous choisissez d'exiger une identité source, vous devez choisir un attribut que vos utilisateurs ou votre IdP doivent fournir. Pour des raisons de sécurité, vous devez vérifier votre capacité à contrôler la façon dont ces valeurs sont fournies.
+ La valeur de l'identité source doit comporter entre 2 et 64 caractères. Elle ne peut contenir que des caractères alphanumériques, des traits de soulignement et les caractères suivants : **. , \$1 = @ -** (tiret). Vous ne pouvez pas utiliser une valeur qui commence par le texte **aws:**. Ce préfixe est réservé à un usage AWS interne.
+ Les informations d'identité source ne sont pas capturées CloudTrail lorsqu'un AWS service ou un rôle lié à un service exécute une action au nom d'une identité fédérée ou d'un personnel.
**Important**
Vous ne pouvez pas passer à un rôle dans le AWS Management Console qui nécessite la définition d'une identité source lorsque le rôle est assumé. Pour assumer un tel rôle, vous pouvez utiliser l' AWS API AWS CLI or pour appeler l'`AssumeRole`opération et spécifier le paramètre d'identité source.
## Autorisations requises pour définir l'identité source
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:SetSourceIdentity
```
+ Pour spécifier une identité source, les principaux (utilisateurs et rôles IAM) doivent disposer des autorisations nécessaires pour `sts:SetSourceIdentity`. Votre qualité d'administrateur vous permet de configurer cela dans la politique de confiance de rôle et la politique d'autorisations du principal.
+ Lorsque vous endossez un rôle avec un autre rôle ([chaînage de rôles](id_roles.md#iam-term-role-chaining)), des autorisations sont exigées pour `sts:SetSourceIdentity` tant dans la politique d'autorisations du principal qui endosse le rôle que dans la politique de confiance de rôle du rôle cible. Sinon, l'opération consistant à endosser le rôle échouera.
+ Lorsque vous utilisez l'identité source, les politiques d'approbation de rôle pour tous les rôles connectés à un fournisseur d'identité doivent disposer de l'autorisation `sts:SetSourceIdentity`. L'opération `AssumeRole*` échouera pour tout rôle connecté à un fournisseur d'identité sans cette autorisation. Si vous ne voulez pas mettre à jour la politique de confiance de rôle pour chaque rôle, vous pouvez utiliser une instance IdP distincte pour transmettre l'identité source et ajouter l'autorisation `sts:SetSourceIdentity` aux seuls rôles qui sont connectés à l'instance IdP distincte.
+ Pour définir une identité source au-delà des limites de compte, vous devez inclure l'autorisation `sts:SetSourceIdentity` à deux endroits. Elle doit être présente dans la politique d'autorisations du principal dans le compte d'origine et dans la politique de confiance de rôle du rôle dans le compte cible. Vous devrez peut-être faire cela lorsqu'un rôle est utilisé pour endosser un rôle dans un autre compte ([chaînage de rôles](id_roles.md#iam-term-role-chaining)).
Supposons, par exemple, qu'en tant qu'administrateur de compte, vous vouliez autoriser l'utilisateur IAM `DevUser` dans votre compte à endosser le `Developer_Role`dans le même compte. Mais vous voulez autoriser cette action uniquement si l'utilisateur a défini l'identité source à son nom d'utilisateur IAM. Vous pouvez attacher la politique suivante à l'utilisateur IAM.
**Example Exemple de politique basée sur l'identité attachée à DevUser**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role"
},
{
"Sid": "SetAwsUserNameAsSourceIdentity",
"Effect": "Allow",
"Action": "sts:SetSourceIdentity",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role",
"Condition": {
"StringLike": {
"sts:SourceIdentity": "${aws:username}"
}
}
}
]
}
```
Pour appliquer les valeurs d'identité source acceptables, vous pouvez configurer la politique de confiance de rôle suivante. La politique donne à l'utilisateur IAM les autorisations `DevUser` pour endosser le rôle et définir une identité source. La clé de condition `sts:SourceIdentity` définit la valeur d'identité source acceptable.
**Example Exemple de politique de confiance de rôle pour une identité source**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowDevUserAssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/DevUser"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"sts:SourceIdentity": "DevUser"
}
}
}
]
}
```
------
À l'aide des informations d'identification de l'utilisateur IAM`DevUser`, celui-ci tente de supposer qu'il `DeveloperRole` utilise la AWS CLI demande suivante.
**Example Exemple de demande AssumeRole CLI**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Developer_Role \
--role-session-name Dev-project \
--source-identity DevUser \
```
Lors de l' AWS évaluation de la demande, le contexte de la demande contient le nom `sts:SourceIdentity` de`DevUser`.
## Spécification d'une identité source lorsqu'un rôle est endossé
Vous pouvez spécifier une identité source lorsque vous utilisez l'une des opérations d' AWS STS `AssumeRole*`API pour obtenir des informations d'identification de sécurité temporaires pour un rôle. L'opération d'API que vous utilisez varie selon votre cas d'utilisation. Par exemple, si vous utilisez des rôles IAM pour donner aux utilisateurs IAM l'accès à AWS des ressources auxquelles ils n'ont normalement pas accès, vous pouvez utiliser cette opération. `AssumeRole` Si vous utilisez la fédération d'identités d'entreprise pour gérer vos utilisateurs de main-d'œuvre, vous pouvez utiliser l'opération `AssumeRoleWithSAML`. Si vous utilisez la fédération OIDC pour autoriser des utilisateurs finaux à accéder à vos applications mobiles ou Web, vous pouvez utiliser l’opération `AssumeRoleWithWebIdentity`. Les sections suivantes détaillent l'utilisation de l'identité source avec chaque opération. Pour en savoir plus sur les scénarios courants d'informations d'identification temporaires, veuillez consulter [Scénarios courants d'informations d'identification temporaires](id_credentials_temp.md#sts-introduction).
## Utilisation de l'identité source avec AssumeRole
L'`AssumeRole`opération renvoie un ensemble d'informations d'identification temporaires que vous pouvez utiliser pour accéder aux AWS ressources. Vous pouvez utiliser l'utilisateur ou les informations d'identification du rôle IAM pour appeler `AssumeRole`. Pour transmettre l'identité de la source tout en assumant un rôle, utilisez l'`-–source-identity` AWS CLI option ou le paramètre `SourceIdentity` AWS API. L'exemple suivant vous explique comment spécifier l'identité source avec la AWS CLI.
**Example Exemple de demande AssumeRole CLI**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/developer \
--role-session-name Audit \
--source-identity Admin \
```
## Utilisation de l'identité source avec AssumeRoleWith SAML
Le principal qui appelle l'opération `AssumeRoleWithSAML` est authentifié à 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 AWS ressources. Pour plus d'informations sur l'utilisation de la fédération basée sur SAML pour l' AWS Management Console accès, consultez. [Permettre aux principaux fédérés SAML 2.0 d'accéder au AWS Management Console](id_roles_providers_enable-console-saml.md) Pour plus de détails sur AWS CLI AWS l'accès à l'API, consultez[Fédération SAML 2.0](id_roles_providers_saml.md). Pour un didacticiel sur la configuration de la fédération SAML pour vos utilisateurs d'Active Directory, consultez la section [Authentification AWS fédérée avec les services de fédération Active Directory (ADFS)](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/) dans le AWS blog de sécurité.
En tant qu'administrateur, vous pouvez autoriser les membres du répertoire de votre entreprise à se fédérer pour AWS utiliser cette AWS STS `AssumeRoleWithSAML` opération. Pour ce faire, effectuez les tâches suivantes :
1. [Configurer un fournisseur SAML dans votre organisation](id_roles_providers_saml_3rd-party.md).
1. [Créer un fournisseur SAML dans IAM](id_roles_providers_create_saml.md)
1. [Configurez un rôle et ses autorisations AWS pour vos principaux fédérés SAML](id_roles_create_for-idp_saml.md).
1. [Achever la configuration de l'IdP SAML et créer des assertions pour la réponse d'authentification SAML](id_roles_providers_create_saml_assertions.md).
Pour définir un attribut SAML pour l'identité source, incluez dans l'élément `Attribute` l'attribut `Name` défini à l'adresse `https://aws.amazon.com/SAML/Attributes/SourceIdentity`. Utilisez l'élément `AttributeValue` pour spécifier la valeur de l'identité source. Par exemple, supposons que vous souhaitez transmettre l'attribut d'identité suivant en tant qu'identité source :
`SourceIdentity:DiegoRamirez`
Pour transmettre cet attribut, incluez l'élément suivant dans votre assertion SAML.
**Example Extrait d'une assertion SAML**
```
DiegoRamirez
```
## Utilisation de l'identité source avec AssumeRoleWithWebIdentity
Le principal qui appelle l’opération `AssumeRoleWithWebIdentity` est authentifié à l’aide de la fédération compatible OpenID Connect (OIDC). 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 OIDC pour l’accès à l’ AWS Management Console , consultez [Fédération OIDC](id_roles_providers_oidc.md).
Pour transmettre l'identité source depuis OpenID Connect (OIDC), vous devez inclure l'identité source dans le jeton web JSON (JWT). Incluez l'identité source dans l'espace de noms `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity` dans le jeton lorsque vous soumettez la demande `AssumeRoleWithWebIdentity`. Pour en savoir plus sur les jetons OIDC et les revendications, veuillez consulter [Utilisation des jetons avec les groupes d'utilisateurs](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html) dans le *Guide du développeur Amazon Cognito *.
Par exemple, le JWT décodé suivant est un jeton utilisé pour appeler `AssumeRoleWithWebIdentity` avec l'identité source `Admin`.
**Example Exemple de jeton web JSON décodé**
```
{
"sub": "john",
"aud": "ac_oic_client",
"jti": "ZYUCeRMQVtqHypVPWAN3VB",
"iss": "https://xyz.com",
"iat": 1566583294,
"exp": 1566583354,
"auth_time": 1566583292,
"https://aws.amazon.com/source_identity":"Admin"
}
```
## Contrôle de l'accès au moyen des informations d'identité source
Lorsqu'une identité source est initialement définie, la SourceIdentity clé [sts :](reference_policies_iam-condition-keys.md#ck_sourceidentity) est présente dans la requête. Une fois qu'une identité source est définie, la SourceIdentity clé [aws :](reference_policies_condition-keys.md#condition-keys-sourceidentity) est présente dans toutes les demandes suivantes effectuées au cours de la session de rôle. En tant qu'administrateur, vous pouvez rédiger des politiques qui accordent une autorisation conditionnelle pour effectuer des AWS actions en fonction de l'existence ou de la valeur de l'attribut d'identité source.
Imaginez que vous souhaitiez demander à vos développeurs de définir une identité source afin d'assumer un rôle essentiel et d'autoriser l'écriture sur une AWS ressource critique de production. Imaginez également que vous accordez AWS l'accès à l'identité de votre personnel en utilisant`AssumeRoleWithSAML`. Comme vous voulez que seuls les développeurs senior Saanvi et Diego aient accès au rôle, vous créez a politique de confiance suivante pour le rôle.
**Example Exemple de politique d'approbation de rôle pour une identité source (SAML)**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SAMLProviderAssumeRoleWithSAML",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:AssumeRoleWithSAML"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
},
{
"Sid": "SetSourceIdentitySrEngs",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
La politique d'approbation contient une condition pour l’interface `sts:SourceIdentity` qui exige une identité source de Saanvi ou Diego pour endosser le rôle critique.
Par ailleurs, si vous utilisez un fournisseur OIDC pour la fédération et que les utilisateurs sont authentifiés avec l’interface `AssumeRoleWithWebIdentity`, votre politique d’approbation de rôle peut se présenter comme suit.
**Example Exemple de politique d'approbation de rôle pour l'identité source (fournisseur OIDC)**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com"
},
"Action": [
"sts:AssumeRoleWithWebIdentity",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"server.example.com:aud": "oidc-audience-id"
},
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
### Chaînage de rôles et exigences entre comptes
Supposons que vous vouliez autoriser les utilisateurs ayant endossé un `CriticalRole` à endosser un `CriticalRole_2` dans un autre compte. Les informations d'identification de session de rôle qui ont été obtenues pour endosser le `CriticalRole` sont utilisées pour effectuer un [chaînage de rôles](id_roles.md#iam-term-role-chaining) à un second rôle, `CriticalRole_2`, dans un autre compte. Le rôle est endossé au-delà d'une limite de compte. Par conséquent, l'autorisation `sts:SetSourceIdentity` doit être octroyée tant dans la politique d'autorisations sur le `CriticalRole` que dans la politique de confiance de rôle sur le `CriticalRole_2`.
**Example Exemple de politique d'autorisation sur CriticalRole**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRoleAndSetSourceIdentity",
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Resource": "arn:aws:iam::222222222222:role/CriticalRole_2"
}
]
}
```
------
Afin de sécuriser la définition de l'identité source au-delà de la limite du compte, la politique de confiance de rôle suivante fait uniquement confiance au principal de rôle pour `CriticalRole` pour définir l'identité source.
**Example Exemple de politique de confiance dans les rôles sur CriticalRole \$12**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/CriticalRole"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"aws:SourceIdentity": ["Saanvi","Diego"]
}
}
}
]
}
```
------
L'utilisateur effectue l'appel suivant en utilisant les informations d'identification de session de rôle obtenues en assumant CriticalRole. L'identité de la source a été définie lors de l'hypothèse de CriticalRole, il n'est donc pas nécessaire de la redéfinir explicitement. Si l'utilisateur tente de définir une identité source différente de la valeur définie lors de la supposition de `CriticalRole`, la demande d'endosser le rôle sera refusée.
**Example Exemple de demande AssumeRole CLI**
```
aws sts assume-role \
--role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \
--role-session-name Audit \
```
Lorsque le principal appelant endosse le rôle, l'identité source dans la demande persiste à partir de la première session de rôle endossée. Par conséquent, les clés `aws:SourceIdentity` et `sts:SourceIdentity` sont toutes deux présentes dans le contexte de demande.
## Affichage de l'identité de la source dans CloudTrail
Vous pouvez l'utiliser CloudTrail pour afficher les demandes faites pour assumer des rôles ou fédérer des utilisateurs. Vous pouvez également afficher les demandes de rôle ou d'utilisateur souhaitant effectuer des actions dans AWS. Le fichier CloudTrail journal contient des informations sur l'identité source définie pour le rôle assumé ou la session utilisateur fédérée. Pour de plus amples informations, consultez [Journalisation des appels IAM et AWS STS API avec AWS CloudTrail](cloudtrail-integration.md).
Supposons, par exemple, qu'un utilisateur fasse une AWS STS `AssumeRole` demande et définisse une identité source. Vous pouvez trouver les `sourceIdentity` informations dans la `requestParameters` clé de votre CloudTrail journal.
**Example Exemple de section RequestParameters dans un journal AWS CloudTrail**
```
"eventVersion": "1.05",
"userIdentity": {
"type": "AWSAccount",
"principalId": "AIDAJ45Q7YFFAREXAMPLE",
"accountId": "111122223333"
},
"eventTime": "2020-04-02T18:20:53Z",
"eventSource": "sts.amazonaws.com",
"eventName": "AssumeRole",
"awsRegion": "us-east-1",
"sourceIPAddress": "203.0.113.64",
"userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86",
"requestParameters": {
"roleArn": "arn:aws:iam::123456789012:role/DevRole",
"roleSessionName": "Dev1",
"sourceIdentity": "source-identity-value-set"
}
```
Si l'utilisateur utilise la session de rôle assumé pour effectuer une action, les informations d'identité de la source sont présentes dans la `userIdentity` clé du CloudTrail journal.
**Example Exemple de clé UserIdentity dans un journal AWS CloudTrail**
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1",
"arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAJ45Q7YFFAREXAMPLE",
"arn": "arn:aws:iam::123456789012:role/DevRole",
"accountId": "123456789012",
"userName": "DevRole"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-02-21T23:46:28Z"
},
"sourceIdentity": "source-identity-value-present"
}
}
}
```
Pour voir des exemples AWS STS d'événements d'API dans CloudTrail les journaux, consultez[Exemple d'événements d'API IAM dans le journal CloudTrail](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api). Pour plus de détails sur les informations contenues dans les fichiers CloudTrail journaux, consultez la section [Référence des CloudTrail événements](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) dans le *guide de AWS CloudTrail l'utilisateur*.
# Autorisations pour GetFederationToken
L'opération `GetFederationToken` est appelée par un utilisateur IAM et renvoie les informations d'identification temporaires pour cet utilisateur. Cette opération *fédère* l'utilisateur. Les autorisations attribuées à une session utilisateur AWS STS fédérée sont définies à l'un des deux endroits suivants :
+ Les politiques de session transmises en tant que paramètre de l'appel d'API `GetFederationToken`. (Il s'agit du scénario le plus courant.)
+ Stratégie basée sur les ressources qui nomme explicitement la session utilisateur AWS STS fédérée dans l'`Principal`élément de la stratégie. (Ce scénario est moins courant.)
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. Lorsque vous créez une session utilisateur AWS STS fédérée et que vous adoptez des politiques de session, les autorisations de session qui en résultent sont à l'intersection de la politique basée sur l'identité de l'utilisateur et des politiques de session. Vous ne pouvez pas utiliser la politique de session pour accorder plus d'autorisations que celles autorisées par la politique basée sur l'identité de l'utilisateur fédéré.
Cela signifie que dans la plupart des cas, si vous ne transmettez pas de politique avec l'appel d'API `GetFederationToken`, les informations d'identification de sécurité temporaires générées ne disposent d'aucune autorisation. Toutefois, une politique basée sur les ressources peut fournir des autorisations supplémentaires pour la session. Vous pouvez accéder à une ressource avec une politique basée sur les ressources, qui spécifie votre session en tant que principal autorisé.
Les illustrations suivantes sont une représentation visuelle de la façon dont les politiques interagissent pour déterminer les autorisations accordées aux informations d'identification de sécurité temporaires retournées par un appel à `GetFederationToken`.
![\[Utilisateur IAM Les illustrations suivantes indiquent que les autorisations de session sont à la croisée de la politique basée sur l’identité de l’utilisateur et des politiques de session. Les autorisations de session peuvent également être à la croisée de la politique basée sur l’identité de l’utilisateur et des politiques basées sur les ressources.\]](http://docs.aws.amazon.com/fr_fr/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png)
## Exemple : attribution d'autorisations à l'aide de GetFederationToken
Vous pouvez utiliser l'action d'API `GetFederationToken` avec différents types de politiques. Voici quelques exemples.
### Politique attachée à l'utilisateur IAM
Dans cet exemple, une application cliente basée sur un navigateur s'appuie sur deux services web backend. L’un des backend est votre propre serveur d'authentification qui utilise votre système d'identité pour authentifier l'application cliente. L'autre backend est un service AWS qui fournit certaines des fonctionnalités de l'application cliente. L'application cliente est authentifiée par votre serveur, puis ce dernier créée ou récupère la politique d'autorisation appropriée. Ensuite, votre serveur appelle l'API `GetFederationToken` afin d'obtenir des informations d'identification de sécurité temporaires, puis il retourne ces informations d'identification à l'application cliente. L'application cliente peut ensuite adresser des demandes directement au AWS service avec les informations d'identification de sécurité temporaires. Cette architecture permet à l'application cliente de faire des AWS demandes sans intégrer d'informations d' AWS identification à long terme.
Votre serveur d'authentification appelle l'API `GetFederationToken` avec les informations d'identification de sécurité à long terme d'un utilisateur IAM nommé `token-app`. Cependant, les informations d'identification de l'utilisateur IAM à long terme restent sur votre serveur et ne sont jamais distribuées au client. L'exemple de politique suivant est attaché à l'utilisateur `token-app` IAM et définit l'ensemble le plus large d'autorisations dont vos utilisateurs AWS STS fédérés (clients) auront besoin. Notez que l'`sts:GetFederationToken`autorisation est requise pour que votre service d'authentification obtienne des informations d'identification de sécurité temporaires pour les utilisateurs AWS STS fédérés.
**Example Exemple de politique attachée à un `token-app` d'utilisateur IAM qui appelle `GetFederationToken`**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "dynamodb:ListTables",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sqs:ReceiveMessage",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sns:ListSubscriptions",
"Resource": "*"
}
]
}
```
La politique précédente accorde plusieurs autorisations à l'utilisateur IAM. Cependant, cette politique à elle seule n'accorde aucune autorisation à l'utilisateur AWS STS fédéré. Si cet utilisateur IAM appelle `GetFederationToken` et ne transmet pas de politique en tant que paramètre de l'appel d'API, l'utilisateur AWS STS fédéré qui en résulte ne dispose d'aucune autorisation effective.
### Politique de session transmise en tant que paramètre
La méthode la plus courante pour s'assurer que l'utilisateur AWS STS fédéré dispose des autorisations appropriées consiste à transmettre les politiques de session dans l'appel `GetFederationToken` d'API. En reprenant l'exemple précédent, imaginons que `GetFederationToken` est appelé avec les informations d'identification de l'utilisateur `token-app` IAM. Imaginons ensuite que la politique de session suivante est transmise en tant que paramètre de l'appel d'API. L’utilisateur fédéré AWS STS a obtenu l’autorisation de répertorier le contenu du compartiment Amazon S3 nommé `productionapp`. L'utilisateur ne peut pas effectuer les actions Amazon S3 `GetObject` `PutObject` et `DeleteObject` sur les éléments dans le compartiment `productionapp`.
L'utilisateur fédéré se voit attribuer ces autorisations, car elles sont une combinaison des politiques d'utilisateur IAM et les politiques de session que vous transmettez.
L'utilisateur AWS STS fédéré n'a pas pu effectuer d'actions dans Amazon SNS, Amazon SQS, Amazon DynamoDB ou dans aucun compartiment S3 à l'exception de. `productionapp` Ces actions sont refusées, même si ces autorisations sont accordées à l'utilisateur IAM associé à l'appel `GetFederationToken`.
**Example Exemple de politique transmise en tant que paramètre de l'appel d'API `GetFederationToken`**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::productionapp"]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::productionapp/*"]
}
]
}
```
### Politiques basées sur les ressources
Certaines AWS ressources prennent en charge les politiques basées sur les ressources, et ces politiques fournissent un autre mécanisme permettant d'accorder des autorisations directement à un utilisateur AWS STS fédéré. Seuls certains AWS services prennent en charge les politiques basées sur les ressources. Par exemple, Amazon S3 comprend des compartiments, Amazon SNS des rubriques, et Amazon SQS des files d'attente auxquelles vous pouvez attacher des politiques. Pour obtenir la liste de tous les services prenant en charge les politiques basées sur les ressources, consultez [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) et passez en revue la colonne « Politiques basées sur les ressources » des tableaux. Vous pouvez utiliser des politiques basées sur les ressources pour attribuer des autorisations directement à un utilisateur AWS STS fédéré. Pour ce faire, spécifiez l'Amazon Resource Name (ARN) de l'utilisateur AWS STS fédéré dans l'`Principal`élément de la politique basée sur les ressources. L'exemple suivant illustre cette méthode et développe les exemples précédents, à l'aide d'un compartiment S3 nommé `productionapp`.
La politique basée sur les ressources suivante est attachée au compartiment. Cette politique de compartiment permet à un utilisateur AWS STS fédéré nommé Carol d'accéder au compartiment. Lorsque l'exemple de politique décrit précédemment est attaché à l'utilisateur `token-app` IAM, l'utilisateur AWS STS fédéré nommé Carol est autorisé à effectuer les `s3:DeleteObject` actions `s3:GetObject``s3:PutObject`, et sur le bucket nommé. `productionapp` Cela est vrai même lorsqu'aucune politique de session n'est transmise en tant que paramètre de l'appel d'API `GetFederationToken`. En effet, dans ce cas, l'utilisateur AWS STS fédéré nommé Carol a reçu des autorisations explicites en vertu de la politique basée sur les ressources suivante.
N'oubliez pas qu'un utilisateur AWS STS fédéré ne reçoit des autorisations que lorsque ces autorisations sont explicitement accordées à la fois à l'utilisateur IAM ***et*** à l'utilisateur AWS STS fédéré. Ils peuvent également être accordés (au sein du compte) par une politique basée sur les ressources qui nomme explicitement l'utilisateur AWS STS fédéré dans l'`Principal`élément de la politique, comme dans l'exemple suivant.
**Example Exemple de politique de compartiment qui autorise l'accès à l'utilisateur fédéré**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {
"AWS": "arn:aws:sts::111122223333:federated-user/Carol"
},
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::productionapp/*"
]
}
}
```
Pour plus d'informations sur la manière dont les politiques sont évaluées, consultez la rubrique [Logique d'évaluation des politiques](reference_policies_evaluation-logic.md).
# Autorisations pour GetSessionToken
La bonne occasion pour appeler l’`GetSessionToken` opération d'API ou la `get-session-token` commande CLI est lorsqu'un utilisateur doit être authentifié avec l'authentification multi-facteur (MFA). Il est possible d'écrire une politique qui autorise certaines actions uniquement lorsque ces actions sont requises par un utilisateur authentifié à l'aide de MFA. Pour réussir à transmettre le contrôle de l'autorisation d'authentification MFA, un utilisateur doit d'abord appeler `GetSessionToken` et inclure le `SerialNumber` facultatif et `TokenCode` les paramètres. Si l'utilisateur est correctement authentifié par un dispositif MFA, les informations d'identification retournées par l'opération d'API `GetSessionToken` incluent le contexte MFA. Ce contexte indique que l'utilisateur est authentifié par l'authentification MFA et est autorisé pour les opérations d'API nécessitant une authentification MFA.
## Autorisations requises pour GetSessionToken
Aucune autorisation n'est requise pour qu'un utilisateur obtienne un jeton de session. Le but principal de l'opération `GetSessionToken` est d'authentifier l'utilisateur à l'aide de l'authentification MFA. Vous ne pouvez pas utiliser de stratégies pour contrôler les opérations d’authentification.
Pour autoriser l'exécution de la plupart AWS des opérations, vous devez ajouter l'action portant le même nom à une politique. Par exemple, pour créer un utilisateur, vous devez utiliser l'opération d'API `CreateUser`, la commande CLI `create-user` ou l' AWS Management Console. Pour effectuer ces opérations, vous devez disposer d'une politique qui vous permet d'accéder à l'action `CreateUser` .
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateUser",
"Resource": "*"
}
]
}
```
------
Vous pouvez inclure l'action `GetSessionToken` dans vos politiques, mais elle n'a aucun effet sur la possibilité de l'utilisateur d'effectuer l'opération `GetSessionToken` .
## Autorisations accordées par GetSessionToken
Si `GetSessionToken` est appelée avec les informations d'identification d'un utilisateur IAM, les informations d'identification de sécurité temporaires ont les mêmes autorisations que cet utilisateur IAM. De même, `GetSessionToken` s'ils sont appelés avec des Utilisateur racine d'un compte AWS informations d'identification, les informations d'identification de sécurité temporaires ont des autorisations d'utilisateur root.
**Note**
Il est recommandé de ne pas appeler `GetSessionToken` avec les informations d'identification d'utilisateur racine. Mettez plutôt en application nos [bonnes pratiques](best-practices-use-cases.md) pour créer des utilisateurs IAM avec les autorisations nécessaires. Utilisez ensuite ces utilisateurs IAM pour vos interactions quotidiennes avec AWS.
Les informations d'identification temporaires que vous obtenez lorsque vous appelez `GetSessionToken` présentent les fonctionnalités et limitations suivantes :
+ Vous pouvez utiliser les informations d'identification pour accéder au AWS Management Console en les transmettant au point de terminaison d'authentification unique de la fédération à l'`https://signin.aws.amazon.com/federation`adresse. Pour de plus amples informations, veuillez consulter [Permettre à un courtier d'identité personnalisé d'accéder à la AWS console](id_roles_providers_enable-console-custom-url.md).
+ Vous **ne pouvez pas** utiliser les informations d'identification pour appeler les opérations IAM ou d'API AWS STS . Vous **pouvez** les utiliser pour appeler des opérations d'API pour d'autres AWS services.
Comparez cette opération d'API et ses limitations et capacités avec les autres opérations d'API qui créent des informations d'identification de sécurité temporaires à [Comparez les AWS STS informations d'identification](id_credentials_sts-comparison.md)
Pour plus d'informations sur l'accès aux API protégé par MFA à l'aide de `GetSessionToken`, consultez [Accès sécurisé aux API avec MFA](id_credentials_mfa_configure-api-require.md).
# Désactivation des autorisations affectées aux informations d'identification de sécurité temporaires
Les informations d'identification de sécurité temporaires sont valides jusqu'à la fin de leur délai d'expiration. Ces informations d'identification sont valides pendant la durée spécifiée, de 900 secondes (15 minutes) à un maximum de 129 600 secondes (36 heures). La durée de session par défaut est de 43 200 secondes (12 heures). Vous pouvez révoquer ces informations d’identification, mais vous devez également modifier les autorisations de l’utilisateur ou du rôle IAM afin d’empêcher l’utilisation d’informations d’identification compromises pour des activités de compte malveillantes. Les autorisations attribuées aux informations d'identification de sécurité temporaires sont évaluées chaque fois qu'elles sont utilisées pour faire une AWS demande. Une fois que vous avez supprimé toutes les autorisations des informations d'identification, les AWS demandes qui les utilisent échouent.
Les mises à jour des politiques peuvent prendre quelques minutes pour être mises en vigueur. Pour les sessions de rôle IAM, vous pouvez révoquer les informations d’identification de sécurité temporaires du rôle afin d’obliger tous les utilisateurs assumant le rôle à s’authentifier à nouveau et à demander de nouvelles informations d’identification. Pour plus d’informations, consultez [Révoquer les informations d’identification temporaires du rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html).
Vous ne pouvez pas modifier les autorisations pour un Utilisateur racine d'un compte AWS. De même, vous ne pouvez pas modifier les autorisations des informations d'identification de sécurité temporaires créées en appelant `GetFederationToken` ou `GetSessionToken` lorsque vous êtes connecté comme utilisateur racine. C'est pour cette raison que nous vous recommandons de ne pas appeler `GetFederationToken` ou `GetSessionToken` en tant qu'utilisateur racine.
Pour les procédures relatives à la modification des autorisations d’un utilisateur IAM, consultez [Modification des autorisations pour un utilisateur IAM](id_users_change-permissions.md).
Pour les procédures relatives à la modification des autorisations d’un rôle IAM, consultez [Mettre à jour les autorisations pour un rôle](id_roles_update-role-permissions.md).
**Important**
Vous ne pouvez pas modifier les rôles dans IAM qui ont été créés à partir des ensembles d’autorisations d’IAM Identity Center. Vous devez révoquer la session d’ensemble d’autorisations active pour un utilisateur dans IAM Identity Center. Pour plus d’informations, consultez [Révocation des sessions de rôle IAM actives créées par des ensembles d’autorisations](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions) dans le *Guide de l’utilisateur IAM Identity Center*.
**Topics**
+ [Refus d’accès à toutes les sessions de rôle IAM associées à un rôle](#deny-access-to-all-sessions)
+ [Refus d’accès à une session de rôle IAM spécifique](#deny-access-to-specific-session)
+ [Refus d’accès aux sessions utilisant des informations d’identification de sécurité temporaires avec des clés de contexte de condition](#deny-access-to-specific-session-condition-key)
+ [Refus d’accès à un principal spécifique avec des politiques basées sur les ressources](#deny-access-with-resource-based)
## Refus d’accès à toutes les sessions de rôle IAM associées à un rôle
Cette procédure refuse les autorisations à **toutes** les sessions de rôle IAM associées à un rôle. Utilisez cette méthode lorsque vous craignez un accès suspect des :
+ Principaux d'un autre compte utilisant l'accès intercompte
+ Identités des utilisateurs externes autorisés à accéder aux AWS ressources de votre compte
+ Utilisateurs ayant été authentifiés dans une application mobile ou Web à l’aide d’un fournisseur OIDC
Pour modifier ou supprimer les autorisations affectées aux informations d’identification de sécurité temporaires obtenues en appelant `AssumeRole`, `AssumeRoleWithSAML`, `AssumeRoleWithWebIdentity`, `GetFederationToken` ou `GetSessionToken`, vous pouvez modifier ou supprimer la politique basée sur l’identité qui définit les autorisations pour le rôle.
**Important**
S'il existe une politique basée sur les ressources qui autorise l'accès au principal, vous devez également ajouter un refus explicite pour cette ressource. Consultez [Refus d’accès à un principal spécifique avec des politiques basées sur les ressources](#deny-access-with-resource-based) pour plus de détails.
**Pour refuser l’accès à **toutes** les sessions de rôle IAM associées à un rôle**
1. Connectez-vous à la console IAM AWS Management Console et ouvrez-la.
1. Dans le panneau de navigation, choisissez **Rôles**.
1. Choisissez le nom du rôle à modifier. Vous pouvez utiliser la zone de recherche pour filtrer la liste.
1. Sélectionnez l’onglet **Autorisations**.
1. Sélectionnez la politique concernée à modifier. Avant de modifier une politique gérée par le client, consultez l’onglet **Entités attachées** pour éviter de perturber l’accès à d’autres identités auxquelles la même politique est attachée.
1. Choisissez l'onglet **JSON** et mettez à jour la politique pour refuser toutes les ressources et actions.
**Note**
Ces autorisations sont les mêmes que celles de la politique AWS gérée [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html). Vous pouvez associer cette politique AWS gérée à n'importe quel utilisateur ou rôle IAM auquel vous souhaitez refuser tout accès.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAll",
"Effect": "Deny",
"Action": [
"*"
],
"Resource": "*"
}
]
}
```
------
1. Sur la page **Vérification**, vérifiez le **Récapitulatif** de la politique, puis choisissez **Enregistrer les modifications** pour enregistrer votre travail.
Lorsque vous mettez à jour la politique, les modifications affectent les autorisations de toutes les informations d'identification de sécurité temporaires associées au rôle, y compris les informations d'identification émises avant que vous apportiez des changements à la politique d'autorisations du rôle.
Après avoir mis à jour la politique, vous pouvez [révoquer les informations d'identification de sécurité temporaires du rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) pour révoquer immédiatement toutes les autorisations relatives aux informations d'identification émises pour le rôle.
## Refus d’accès à une session de rôle IAM spécifique
Lorsque vous mettez à jour les rôles IAM à l’aide d’une politique de refus ou que vous supprimez complètement le rôle, tous les utilisateurs ayant accès au rôle sont perturbés. Vous pouvez refuser l’accès sans affecter les autorisations de toutes les autres sessions associées au rôle.
Le `Principal` peut se voir refuser des autorisations à l'aide des [clés de contexte de condition](#deny-access-to-specific-session-condition-key) ou des [politiques basées sur les ressources](#deny-access-with-resource-based).
**Astuce**
Vous pouvez trouver les utilisateurs ARNs fédérés à l'aide AWS CloudTrail des journaux. Pour plus d'informations, consultez [Comment identifier facilement vos utilisateurs fédérés à l'aide AWS CloudTrail](https://aws.amazon.com/blogs/security/how-to-easily-identify-your-federated-users-by-using-aws-cloudtrail/) de.
## Refus d’accès aux sessions utilisant des informations d’identification de sécurité temporaires avec des clés de contexte de condition
Vous pouvez utiliser des clés de contexte de condition dans les politiques basées sur l’identité dans les situations où vous souhaitez refuser l’accès à des sessions d’informations d’identification de sécurité temporaires spécifiques sans affecter les autorisations de l’utilisateur ou du rôle IAM qui a créé les informations d’identification. Pour les rôles IAM, après avoir mis à jour la politique, vous pouvez également [révoquer les sessions d’informations d’identification temporaires du rôle](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) pour révoquer immédiatement toutes les informations d’identification émises.
Pour plus d'informations sur les clés de contexte de condition, veuillez consulter la rubrique [AWS clés contextuelles de condition globale](reference_policies_condition-keys.md).
### lois : PrincipalArn
Vous pouvez utiliser la clé de contexte de condition [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) dans une politique basée sur l’identité pour refuser l’accès à un principal spécifique en utilisant son Amazon Resource Name (ARN). Pour ce faire, spécifiez l'ARN de l'utilisateur, du rôle ou de la session utilisateur AWS STS fédérée IAM auxquels les informations d'identification de sécurité temporaires sont associées dans l'élément Condition d'une politique.
**Pour refuser l’accès à un principal spécifique par son ARN**
1. Dans le volet de navigation de la console IAM, choisissez **Utilisateurs** ou **Rôles**.
1. Choisissez le nom de l’utilisateur ou du rôle IAM à modifier. Vous pouvez utiliser la zone de recherche pour filtrer la liste.
1. Sélectionnez l’onglet **Autorisations**.
1. Sélectionnez la politique concernée à modifier. Avant de modifier une politique gérée par le client, consultez l’onglet **Entités attachées** pour éviter de perturber l’accès à d’autres identités auxquelles la même politique est attachée.
1. Choisissez l'onglet **JSON** et ajoutez une instruction de refus pour l'ARN principal, comme indiqué dans l'exemple suivant.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:iam::222222222222:federated-user/USERNAME"
]
}
}
}
]
}
```
------
1. Sur la page **Vérification**, vérifiez le **Récapitulatif** de la politique, puis choisissez **Enregistrer les modifications** pour enregistrer votre travail.
### lois : SourceIdentity
Vous pouvez utiliser la clé de contexte de condition [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) dans une politique basée sur l’identité pour refuser l’accès à une identité source spécifique associée à une session de rôle IAM. Cela s'applique tant que la session de rôle a été émise en définissant le paramètre de `SourceIdentity` demande lorsque le principal a assumé un rôle à l'aide de AWS STS `assume-role` commandes\$1 CLI ou d'opérations d'API AWS STS `AssumeRole` \$1. Pour cela, vous spécifiez l’identité source à laquelle les informations d’identification de sécurité temporaires sont associées dans l’élément `Condition` d’une politique.
Contrairement à la clé de contexte [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname), une fois l’identité source définie, la valeur ne peut plus être modifiée. Elle clé `aws:SourceIdentity` est présente dans le contexte de la requête pour toutes les actions entreprises par le rôle. L’identité source persiste dans les sessions de rôle suivantes lorsque vous utilisez les informations d’identification de la session pour assumer un autre rôle. Le fait d'endosser un rôle à partir d'un autre est appelé [chaînage des rôles](id_roles.md#iam-term-role-chaining).
La politique suivante montre un exemple de la manière dont vous pouvez refuser l’accès à des sessions d’informations d’identification de sécurité temporaires à l’aide d’une clé de contexte de condition `aws:SourceIdentity`. Si vous spécifiez l’identité source associée à une session de rôle, elle interdira les sessions de rôle avec l’identité source nommée sans affecter les autorisations du rôle qui a créé les informations d’identification. Dans cet exemple, l’identité source définie par le principal lors de l’émission de la session de rôle est `nikki_wolf@example.com`. Toute requête effectuée par une session de rôle avec l’identité source `nikki_wolf@example.com` sera refusée, car l’identité source est incluse dans la condition de politique et l’effet de politique est défini sur `Deny`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
]
}
```
------
### aws:userid
Vous pouvez utiliser la clé de contexte de condition [aws:userid](reference_policies_condition-keys.md#condition-keys-userid) dans une politique basée sur l’identité pour interdire l’accès à toutes les sessions d’informations d’identification de sécurité temporaires ou à des sessions spécifiques associées à l’utilisateur ou au rôle IAM. Pour ce faire, spécifiez l'identifiant unique (ID) de l'utilisateur, du rôle ou de la session utilisateur AWS STS fédérée IAM auxquels les informations d'identification de sécurité temporaires sont associées dans l'`Condition`élément d'une politique.
La politique suivante montre un exemple de la manière dont vous pouvez refuser l’accès à des sessions d’informations d’identification de sécurité temporaires à l’aide d’une clé de contexte de condition `aws:userid`.
+ `AIDAXUSER1` représente l’ID unique d’un utilisateur IAM. La spécification de l’identifiant unique d’un utilisateur IAM en tant que valeur de la clé de contexte `aws:userid` aura pour effet de refuser l’accès à l’utilisateur IAM. Cela inclut toutes les sessions d’informations d’identification de sécurité temporaires créées lors de l’appel de l’API `GetSessionToken`.
+ `AROAXROLE1:*` représente l’ID unique de toutes les sessions associées au rôle IAM. La spécification de l'ID unique d'un rôle IAM et d'un caractère générique (\$1) dans la partie caller-specified-role-session -name comme valeur de clé de contexte `aws:userid` empêchera toutes les sessions associées au rôle.
+ `AROAXROLE2:` représente l’ID unique d’une session de rôle assumé. Dans la partie caller-specified-role-session -name de l'ID unique du rôle assumé, vous pouvez spécifier un rôle, un nom de session ou un caractère générique si l' StringLike opérateur de condition est utilisé. Si vous spécifiez le nom de la session de rôle, cela refusera la session de rôle nommée sans affecter les autorisations du rôle qui a créé les informations d'identification. Si vous spécifiez un caractère générique pour le nom de session du rôle, toutes les sessions associées au rôle seront refusées.
**Note**
Le nom de session de rôle caller-specified, qui fait partie de l’identifiant unique d’une session assumed-role, peut changer pendant le chaînage des rôles. Le chaînage des rôles se produit lorsqu’un rôle assume un autre rôle. Le nom de session du rôle est défini à l'aide du paramètre de `RoleSessionName` requête lorsque le principal assume un rôle à l'aide de l'opération AWS STS `AssumeRole` API.
+ `account-id:`représente l'ID unique d'une session utilisateur AWS STS fédérée. Un utilisateur IAM crée cette session en appelant l’API `GetFederationToken`. La spécification de l’ID unique d’une session d’utilisateur fédéré AWS STS a pour effet de refuser la session fédérée nommée sans affecter les autorisations de l’utilisateur IAM qui a créé les informations d’identification.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:userId": [
"AIDAXUSER1",
"AROAXROLE1:*",
"AROAXROLE2:",
"123456789012:"
]
}
}
}
]
}
```
------
Pour des exemples spécifiques de valeurs de clé de principal, veuillez consulter la rubrique [Valeurs de la clé du principal](reference_policies_variables.md#principaltable). Pour plus d’informations sur les identifiants uniques IAM et sur la manière de les obtenir, consultez [Identifiants uniques](reference_identifiers.md#identifiers-unique-ids).
## Refus d’accès à un principal spécifique avec des politiques basées sur les ressources
Pour restreindre l’accès à un principal spécifique à l’aide d’une politique basée sur les ressources, vous pouvez utiliser des clés contextuelles de condition [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) ou [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) dans l’élément `Condition`. Une politique basée sur les ressources est une politique d’autorisation attachée à une ressource et qui contrôle qui peut accéder à la ressource et quelles actions il peut effectuer sur celle-ci.
Lorsque vous utilisez la clé de `aws:PrincipalARN` contexte, spécifiez l'ARN de l'utilisateur, du rôle ou de la session utilisateur AWS STS fédérée IAM associé aux informations d'identification de sécurité temporaires dans l'élément Condition d'une politique. L’exemple de politique suivant montre comment utiliser la clé de contexte `aws:PrincipalARN` dans une politique basée sur les ressources :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:sts::222222222222:federated-user/USERNAME"
]
}
}
}
}
```
------
Lorsque vous utilisez la clé de contexte `aws:SourceIdentity`, spécifiez la valeur d’identité source associée aux informations de sécurité temporaires du rôle dans l’élément `Condition` d’une politique. Cela s'applique tant que la session de rôle a été émise en définissant le paramètre de `SourceIdentity` demande lorsque le principal a assumé un rôle à l'aide de AWS STS `assume-role` commandes\$1 CLI ou d'opérations d'API AWS STS `AssumeRole` \$1. L’exemple suivant montre comment utiliser la clé de contexte `aws:SourceIdentity` dans une politique basée sur une ressource :
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
}
```
------
Si vous mettez uniquement à jour la politique basée sur l’identité d’un principal, celui-ci peut toujours effectuer les actions autorisées dans la politique basée sur les ressources, sauf lorsque ces actions sont explicitement refusées dans la politique basée sur l’identité.
**Pour refuser l’accès à un principal spécifique dans une politique basée sur les ressources**
1. Reportez-vous à la rubrique [AWS services qui fonctionnent avec IAM](reference_aws-services-that-work-with-iam.md) pour voir si le service prend en charge les politiques basées sur les ressources.
1. Connectez-vous à la console du service AWS Management Console et ouvrez-la. Chaque service dispose d'un emplacement différent dans la console pour associer des politiques.
1. Modifiez la politique basée sur une ressource. Ajoutez une instruction de politique de refus pour spécifier les informations d’identification de l’identifiant :
1. Dans l’élément `Principal`, saisissez le caractère générique (\$1). Le principal sera restreint dans l’élément `Condition`.
1. Dans l’élément `Effect`, saisissez « Deny ».
1. Dans `Action`, saisissez l'espace de noms du service et le nom de l'action à refuser. Pour refuser toutes les actions, utilisez le caractère générique (\$1). Par exemple : `"s3:*"`.
1. Dans l’élément `Resource`, saisissez l’ARN de la ressource cible. Par exemple : `"arn:aws:s3:::amzn-s3-demo-bucket"`.
1. Dans l’élément `Condition`, spécifiez la clé de contexte `aws:PrincipalARN` ou `aws:SourceIdentity`.
Si vous utilisez la clé de contexte `aws:PrincipalARN`, saisissez l’ARN du principal pour lequel refuser l’accès.
Si vous utilisez la clé de contexte `aws:SourceIdentity`, saisissez la valeur d’identité source définie dans la session de rôle pour laquelle refuser l’accès.
1. Enregistrez votre travail.
# Octroi d'autorisations pour créer des informations d'identification de sécurité temporaires
Par défaut, les utilisateurs IAM n’ont pas l’autorisation de créer des informations d’identification de sécurité temporaires pour des sessions d’utilisateurs fédérés et les rôles AWS STS . Vous devez utiliser une politique pour fournir ces autorisations à vos utilisateurs. Bien que vous puissiez accorder des autorisations directement à un utilisateur, nous vous recommandons vivement d'accorder des autorisations à un groupe. Cela facilite la gestion des autorisations. Lorsqu'un utilisateur n'a plus besoin d'effectuer les tâches associées aux autorisations, il vous suffit de le supprimer du groupe. Si un autre utilisateur doit effectuer cette tâche, ajoutez-le au groupe pour lui accorder les autorisations.
Pour accorder à un groupe IAM l’autorisation de créer des informations d’identification de sécurité temporaires pour des sessions d’utilisateurs fédérés ou des rôles AWS STS , vous attachez une politique qui accorde un ou plusieurs des privilèges suivants :
+ Pour que les principaux fédérés OIDC et SAML puissent accéder à un rôle IAM, accordez l'accès à. AWS STS `AssumeRole`
+ Pour les utilisateurs AWS STS fédérés qui n'ont pas besoin de rôle, accordez l'accès à AWS STS `GetFederationToken`.
Pour plus d'informations sur les différences entre les opérations d'API `AssumeRole` et `GetFederationToken`, consultez [Demande d’identifiants de sécurité temporaires](id_credentials_temp_request.md).
Les utilisateurs IAM peuvent également appeler [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) pour créer des informations d'identification de sécurité temporaires. Aucune autorisation n'est requise pour qu'un utilisateur puisse appeler `GetSessionToken`. Le but principal de cette opération est d'authentifier l'utilisateur à l'aide de l'authentification MFA. Vous ne pouvez pas utiliser les politiques pour contrôler l'authentification. Cela signifie que vous ne pouvez pas empêcher les utilisateurs IAM d'appeler `GetSessionToken` pour créer des informations d'identification temporaires.
**Example Exemple de politique qui accorde l'autorisation d'endosser un rôle**
L'exemple de politique suivant accorde l'autorisation d'appeler `AssumeRole` pour le `UpdateApp` rôle dans Compte AWS `123123123123`. Quand `AssumeRole` est utilisé, l'utilisateur (ou l'application) qui crée les informations d'identification de sécurité pour le compte d'un utilisateur fédéré ne peut déléguer aucune autorisation non spécifiée dans la politique d'autorisation de rôle.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123123123123:role/UpdateAPP"
}]
}
```
**Example Exemple de politique qui accorde l'autorisation de créer des informations d'identification de sécurité temporaires pour un utilisateur fédéré**
L'exemple de politique suivant donne l'autorisations d'accéder à `GetFederationToken`.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
}]
}
```
**Important**
Lorsque vous accordez à un utilisateur IAM l’autorisation de créer des informations d’identification de sécurité temporaires pour des utilisateurs fédérés AWS STS avec `GetFederationToken`, sachez que cela lui autorise à déléguer ses propres autorisations. Pour plus d'informations sur la délégation d'autorisations entre les utilisateurs IAM et consultez Comptes AWS. [Exemples de politiques pour la délégation d'accès](id_roles_create_policy-examples.md) Pour plus d'informations sur le contrôle des autorisations dans les informations d'identification de sécurité temporaires, consultez [Autorisations affectées aux informations d’identification de sécurité temporaires](id_credentials_temp_control-access.md).
**Example Exemple de politique qui accorde à un utilisateur une autorisation limitée de créer des informations d'identification de sécurité temporaires pour des utilisateurs fédérés**
Lorsque vous laissez un utilisateur IAM appeler `GetFederationToken`, il s'agit d'une bonne pratique pour limiter les autorisations que l'utilisateur IAM peut déléguer. *Par exemple, la politique suivante indique comment autoriser un utilisateur IAM à créer des informations d'identification de sécurité temporaires uniquement pour les utilisateurs AWS STS fédérés dont le nom commence par Manager.*
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": ["arn:aws:sts::123456789012:federated-user/Manager*"]
}]
}
```
# Octroi d’autorisations pour l’utilisation de sessions de console à identité renforcée
Les sessions de console à identité améliorée permettent AWS IAM Identity Center d'inclure l'utilisateur et IDs la session dans les sessions de AWS console des utilisateurs lorsqu'ils se connectent. Par exemple, Amazon Q Developer Pro utilise des sessions de console à identité renforcée pour personnaliser l’expérience de service. Pour plus d’informations sur les sessions de console à identité renforcée, consultez la section [Activation des sessions de console à identité renforcée](https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-enhanced-sessions.html) dans le *Guide de l’utilisateur AWS IAM Identity Center *. Pour plus d’informations sur la configuration d’Amazon Q Developer, consultez la section [Configuration d’Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/setting-up.html) dans le *Guide de l’utilisateur Amazon Q Developer*.
Pour qu’un utilisateur puisse disposer de sessions de console à identité renforcée, vous devez utiliser une politique basée sur l’identité pour accorder au principal IAM l’autorisation `sts:SetContext` pour la ressource qui représente sa propre session de console.
**Important**
Par défaut, les utilisateurs n’ont pas l’autorisation de définir le contexte de leurs sessions de console à identité renforcée. Pour ce faire, vous devez accorder l’autorisation `sts:SetContext` au principal IAM dans une politique basée sur l’identité, comme indiqué dans l’exemple de politique ci-dessous.
L'exemple de politique basée sur l'identité suivant accorde l'`sts:SetContext`autorisation à un principal IAM, ce qui permet au principal de définir un contexte de session de console à identité améliorée pour ses propres sessions de console. AWS La ressource de politique représente la AWS session de l'appelant. `arn:aws:sts::account-id:self` Le segment ARN `account-id` peut être remplacé par un caractère générique `*` dans les cas où la même politique d’autorisation est déployée sur plusieurs comptes, par exemple lorsque cette politique est déployée à l’aide des ensembles d’autorisations d’IAM Identity Center.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:SetContext",
"Resource": "arn:aws:sts::111122223333:self"
}
]
}
```
------