AWS Identity and Access Management

Transcription

AWS Identity and
Access Management
Guide de l'utilisateur
AWS Identity and Access
Management Guide de l'utilisateur
AWS Identity and Access Management: Guide de l'utilisateur
Copyright © 2017 Amazon Web Services, Inc. and/or its affiliates. All rights reserved.
Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any
manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other
trademarks not owned by Amazon are the property of their respective owners, who may or may not be affiliated with, connected to,
or sponsored by Amazon.
Table of Contents
En quoi consiste IAM ? .................................................................................................................. 1
Vidéo de présentation de AWS IAM ......................................................................................... 1
Fonctions de IAM .................................................................................................................. 1
Accès à IAM ........................................................................................................................ 2
Présentation : utilisateurs ....................................................................................................... 3
Première accès uniquement : les informations d'identification de votre compte racine ............... 3
Utilisateurs IAM ............................................................................................................ 4
Fédération d'utilisateurs existants .................................................................................... 4
Présentation : Autorisations et stratégies .................................................................................. 5
Stratégies et utilisateurs ................................................................................................. 6
Stratégies et groupes .................................................................................................... 6
Utilisateurs fédérés et rôles ............................................................................................ 7
Stratégies basées sur un utilisateur et basées sur une ressource .......................................... 7
Fonctions de sécurité en dehors d'IAM ..................................................................................... 8
Liens rapides pour les tâches courantes ................................................................................... 9
Configuration .............................................................................................................................. 11
Utilisation de IAM pour accorder aux utilisateurs l'accès à vos ressources AWS. ............................ 11
Dois-je m'inscrire à IAM ? ..................................................................................................... 12
Ressources supplémentaires ................................................................................................. 12
Démarrage ................................................................................................................................. 14
Création d'un utilisateur administrateur et d'un groupe IAM ........................................................ 15
Création d'un utilisateur et d'un groupe IAM administrateur (console) ................................... 16
Création d'un groupe et d'un utilisateur IAM (AWS CLI) ..................................................... 16
Comment les utilisateurs se connectent à votre compte ............................................................ 18
Didacticiels ................................................................................................................................. 21
Didacticiel : Déléguer l'accès à la console de facturation ........................................................... 21
Prérequis ................................................................................................................... 22
Étape 1 : Activer l'accès aux données de facturation de votre compte AWS de test ................. 22
Étape 2 : Créer des stratégies IAM qui accordent des autorisations aux données de
facturation .................................................................................................................. 23
Étape 3 : Attacher des stratégies de facturation à vos groupes ........................................... 24
Étape 4 : Tester l'accès à la console de facturation ........................................................... 24
Ressources connexes .................................................................................................. 25
Récapitulatif ................................................................................................................ 26
Didacticiel : Déléguer l'accès entre des comptes AWS à l'aide de rôles ........................................ 26
Prérequis ................................................................................................................... 27
Etape 1 : Créer un rôle ................................................................................................ 28
Étape 2 : Accorder l'accès au rôle .................................................................................. 30
Étape 3 : Tester l'accès en changeant de rôles ................................................................ 32
Récapitulatif ................................................................................................................ 36
Didacticiel : Créer une stratégie gérée par le client ................................................................... 36
Prérequis ................................................................................................................... 37
Étape 1 : Créer la stratégie ........................................................................................... 37
Étape 2 : Attacher la stratégie ....................................................................................... 38
Étape 3 : Test de l'accès utilisateur ................................................................................ 38
Récapitulatif ................................................................................................................ 38
Didacticiel : Autoriser les utilisateurs à configurer leurs propres informations d'identification et
paramètres MFA ................................................................................................................. 39
Prérequis ................................................................................................................... 39
Etape 1 : Créer une stratégie pour appliquer l'authentification MFA ...................................... 40
Étape 2 : Attacher des stratégies à votre groupe test ........................................................ 42
Étape 3 : Test de l'accès utilisateur ................................................................................ 43
iv
Récapitulatif ................................................................................................................ 43
Bonnes pratiques et cas d'utilisation .............................................................................................. 44
Bonnes pratiques ................................................................................................................ 44
Protéger les clés d'accès (racine) de votre compte AWS ................................................... 45
Créer des utilisateurs IAM ............................................................................................ 45
Utiliser autant que possible des stratégies définies par AWS pour attribuer des autorisations .... 46
Utiliser des groupes pour attribuer des autorisations à des utilisateurs IAM ........................... 46
Accorder les privilèges les plus faibles possible ............................................................... 46
Configurer une stratégie de mot de passe fiable pour vos utilisateurs ................................... 47
Activer MFA pour les utilisateurs privilégiés ..................................................................... 47
Utilisez des rôles pour les applications qui s'exécutent sur des instances Amazon EC2 ........... 47
Utilisez des rôles plutôt que le partage d'informations d'identification pour déléguer ................ 48
Effectuer une rotation régulière des informations d'identification .......................................... 48
Supprimer les informations d’identification inutiles ............................................................ 48
Utiliser les conditions des stratégies pour une plus grande sécurité ..................................... 49
Surveiller l'activité de votre compte AWS ........................................................................ 49
Vidéo de présentation des bonnes pratiques pour IAM ...................................................... 49
Cas d'utilisation commerciaux ............................................................................................... 49
Configuration initiale d'Example Corp ............................................................................. 50
Cas d'utilisation de IAM avec Amazon EC2 ..................................................................... 50
Cas d'utilisation de IAM avec Amazon S3 ....................................................................... 51
La console IAM et la page de connexion ........................................................................................ 53
La page de connexion d'utilisateur ......................................................................................... 54
La page de connexion au compte racine ................................................................................ 54
Contrôle de l'accès utilisateur à AWS Management Console ...................................................... 55
Votre ID de compte AWS et son alias .................................................................................... 56
Identification de votre ID de compte AWS ....................................................................... 56
A propos des alias de compte ....................................................................................... 56
Création, suppression et affichage d'un alias de compte AWS ............................................ 57
Utilisation d'appareils MFA avec votre page de connexion IAM ................................................... 58
Fonction de recherche de la console IAM ............................................................................... 58
Utilisation de la fonction de recherche de la console IAM ................................................... 59
Icônes des résultats de la recherche sur la console IAM .................................................... 59
Exemples de phrases de recherche ............................................................................... 59
Identités ..................................................................................................................................... 61
Utilisateurs IAM ................................................................................................................... 61
Groupes IAM ...................................................................................................................... 61
Rôles IAM .......................................................................................................................... 62
Informations d’identification temporaires .................................................................................. 62
Utilisateur « racine » d'un compte .......................................................................................... 62
Quand créer un utilisateur IAM (au lieu d'un rôle) ..................................................................... 62
Quand créer un rôle IAM (au lieu d'un utilisateur) ..................................................................... 63
Utilisateurs ......................................................................................................................... 64
Comment AWS identifie un utilisateur IAM ...................................................................... 64
Utilisateurs et informations d'identification ....................................................................... 64
Utilisateurs et autorisations ........................................................................................... 65
Utilisateurs et comptes ................................................................................................. 65
Utilisateurs en tant que comptes de service .................................................................... 65
Ajout d'un utilisateur .................................................................................................... 66
Comment les utilisateurs IAM se connectent à votre compte AWS ....................................... 70
Gestion des utilisateurs ................................................................................................ 71
Modification des autorisations pour un utilisateur .............................................................. 75
Mots de passe ............................................................................................................ 78
Clés d'accès ............................................................................................................... 89
Récupération des mots de passe ou clés d'accès perdus .................................................. 93
Multi-Factor Authentication (MFA) .................................................................................. 93
Recherche d'informations d'identification inutilisées ......................................................... 121
Obtention de rapports d'informations d'identification ........................................................ 123
v
Utilisation d'IAM avec AWS CodeCommit : informations d'identification Git, clés SSH et clés
d'accès AWS ............................................................................................................ 127
Utilisation des certificats de serveur ............................................................................. 129
Groupes ........................................................................................................................... 134
Création de groupes .................................................................................................. 135
Gestion des groupes .................................................................................................. 136
Rôles ............................................................................................................................... 140
Termes et concepts ................................................................................................... 140
Scénarios courants .................................................................................................... 142
Fournisseurs d'identité et fédération ............................................................................. 148
Création de rôles ....................................................................................................... 187
Utilisation de rôles ..................................................................................................... 214
Gestion des rôles ...................................................................................................... 233
Rôles comparés aux stratégies basées sur les ressources ............................................... 241
Informations d'identification de sécurité temporaires ................................................................ 244
Régions AWS STS et AWS ........................................................................................ 244
Scénarios courants d'informations d'identification temporaires ........................................... 245
Obtention d'informations d'identification temporaires de sécurité ........................................ 246
Utilisation des informations d'identification de sécurité temporaires pour demander un accès
aux ressources AWS. ................................................................................................. 257
Contrôle des autorisations affectées aux informations d'identification de sécurité
temporaires ............................................................................................................... 262
Activation et désactivation d'AWS STS dans une région AWS ........................................... 274
Exemples d'application qui utilisent des informations d'identification temporaires .................. 277
Ressources supplémentaires pour les informations d'identification temporaires .................... 278
Utilisateur racine ................................................................................................................ 278
Création de clés d'accès pour l'utilisateur racine ............................................................. 279
Suppression des clés d'accès de l'utilisateur racine ......................................................... 279
Activer MFA sur l'utilisateur racine ............................................................................... 280
Modification du mot de passe de l'utilisateur racine ......................................................... 280
Gestion de l'accès ..................................................................................................................... 281
Autorisations ..................................................................................................................... 281
Autorisations basées sur une identité (IAM) et autorisations basées une ressource ............... 282
Des créateurs de ressource ne reçoivent pas automatiquement des autorisations ................. 284
Octroi d'autorisations dans des comptes AWS ............................................................... 284
Autorisations pour qu'un service accède à un autre service .............................................. 284
Délégation des autorisations d'administration des utilisateurs, des groupes et des
informations d'identification IAM ................................................................................... 285
Stratégies ......................................................................................................................... 294
Stratégies gérées et stratégies en ligne ........................................................................ 299
Gestion des versions des stratégies gérées ................................................................... 313
Stratégies gérées par AWS obsolètes ........................................................................... 315
Contrôle de l'accès aux stratégies gérées ..................................................................... 316
Création de stratégies IAM .......................................................................................... 321
Utilisation de stratégies .............................................................................................. 323
Test des stratégies IAM .............................................................................................. 331
Utilisation du programme de validation de stratégies ....................................................... 339
Données sur les services consultés en dernier ............................................................... 342
Exemples de stratégies pour l'accès à AWS .................................................................. 347
Ressources supplémentaires ............................................................................................... 357
Consignation d'événements IAM avec AWS CloudTrail .................................................................... 358
Types d'informations IAM enregistrées dans CloudTrail ........................................................... 358
Exemples d'événements enregistrés dans des fichiers CloudTrail .............................................. 361
Événement d'API IAM dans le fichier journal CloudTrail ................................................... 362
Événement d'API AWS STS dans le fichier journal CloudTrail ........................................... 362
Événement d'échec de connexion dans le fichier journal CloudTrail ................................... 367
Événement d'échec de connexion provoqué par nom d'utilisateur incorrect .......................... 367
Événement de connexion réussie dans le fichier journal CloudTrail .................................... 368
vi
Prévention des entrées de journal en double dans CloudTrail ................................................... 369
Dépannage IAM ........................................................................................................................ 371
Dépannage de problèmes généraux ..................................................................................... 371
J'ai perdu mes clés d'accès. ....................................................................................... 371
Je reçois un message d'accès refusé lorsque j'effectue une demande à un service AWS. ....... 372
Je reçois un message d'accès refusé lorsque j'effectue une demande avec des informations
d'identification de sécurité temporaires. ......................................................................... 372
Les variables de la stratégie ne fonctionnent pas. ........................................................... 373
Les modifications que j'apporte ne sont pas toujours visibles immédiatement ....................... 373
Dépannage de stratégies .................................................................................................... 373
La stratégie comporte plusieurs objets .......................................................................... 374
Plusieurs éléments Statement ..................................................................................... 375
Plusieurs éléments Effect, Action ou Resource dans un élément Statement ......................... 376
Elément Version manquant ......................................................................................... 377
Résolution des problèmes liés aux rôles IAM ......................................................................... 378
Je ne peux pas assumer un rôle. ................................................................................. 378
Dépannage de Amazon EC2 et IAM ..................................................................................... 379
Lors de la tentative de lancement de l'instance, je ne vois pas le rôle attendu dans la liste
IAM role de la console Amazon EC2. ........................................................................... 379
Les informations d'identification sur mon instance concernent le mauvais rôle. ..................... 380
Quand je tente d'appeler le AddRoleToInstanceProfile, je reçois un message d'erreur
AccessDenied. ........................................................................................................ 380
Amazon EC2 : Quand je tente de lancer l'instance avec un rôle, je reçois un message
d'erreur AccessDenied. ............................................................................................. 380
Je ne parviens pas à accéder aux informations d'identification de sécurité temporaires sur
mon instance EC2. .................................................................................................... 381
Que signifient les erreurs dans le document info de la sous-arborescence IAM ? ................ 381
Dépannage d'Amazon S3 et IAM ......................................................................................... 382
Comment accorder un accès anonyme à un compartiment Amazon S3 ? ............................ 382
Je suis connecté en tant qu'utilisateur racine, pourquoi ne puis-je pas accéder à un
compartiment Amazon S3 dans mon compte ? ............................................................... 382
Dépannage sur de la fédération SAML 2.0 avec AWS ............................................................. 383
Comment afficher une réponse SAML dans votre navigateur à des fins de dépannage .......... 383
Error: Your request included an invalid SAML response. To logout, click here. .................... 385
Error: RoleSessionName is required in AuthnResponse (Service:
AWSSecurityTokenService; Status Code: 400; Error Code: InvalidIdentityToken) .................. 385
Error: Not authorized to perform sts:AssumeRoleWithSAML (Service:
AWSSecurityTokenService; Status Code: 403; Error Code: AccessDenied) ......................... 385
Error: RoleSessionName in AuthnResponse must match [a-zA-Z_0-9+=,.@-]{2,64} (Service:
AWSSecurityTokenService; Status Code: 400; Error Code: InvalidIdentityToken) .................. 386
Error: Response signature invalid (Service: AWSSecurityTokenService; Status Code: 400;
Error Code: InvalidIdentityToken) ................................................................................. 386
Error: Failed to assume role: Issuer not present in specified provider
(Service: AWSOpenIdDiscoveryService; Status Code: 400; Error Code:
AuthSamlInvalidSamlResponseException) ..................................................................... 386
Référence ................................................................................................................................. 387
Identifiants IAM ................................................................................................................. 387
Noms conviviaux et chemins ....................................................................................... 387
ARN IAM .................................................................................................................. 388
ID uniques ................................................................................................................ 390
Restrictions ....................................................................................................................... 391
Services AWS qui fonctionnent avec IAM .............................................................................. 394
Services de calcul ..................................................................................................... 394
Services de stockage et de diffusion de contenu ............................................................ 395
Services de base de données ..................................................................................... 396
Services de réseau et de diffusion de contenu ............................................................... 396
Services de migration ................................................................................................. 397
Services et outils de développement ............................................................................ 397
vii
Services et outils de gestion ....................................................................................... 397
Services de sécurité, d'identité et de conformité ............................................................. 398
Services analytiques .................................................................................................. 398
Intelligence artificielle ................................................................................................. 399
Internet des objets ..................................................................................................... 399
Services de développement de jeux ............................................................................. 399
Services mobiles ....................................................................................................... 400
Services applicatifs .................................................................................................... 400
Services de messagerie ............................................................................................. 400
Productivité d'entreprise .............................................................................................. 401
Services Streaming de bureau et d'application ............................................................... 401
Ressources supplémentaires ....................................................................................... 401
Référence de stratégie ....................................................................................................... 402
Références des éléments ........................................................................................... 402
Variables de stratégie ................................................................................................ 430
Conditions avec plusieurs valeurs de clés ..................................................................... 436
Logique d'évaluation de stratégies IAM ......................................................................... 441
Syntaxe de stratégie .................................................................................................. 446
Actions et clés de contexte de condition pour des stratégies IAM ...................................... 452
Ressources .............................................................................................................................. 538
Utilisateurs et groupes ........................................................................................................ 538
Informations d'identification (mots de passe, clés d'accès et appareils MFA) ................................ 538
Autorisations et stratégies ................................................................................................... 539
Fédération et délégation ..................................................................................................... 539
IAM et autres produits AWS ................................................................................................ 540
Utilisation d'IAM avec Amazon EC2 .............................................................................. 540
Utilisation d'IAM avec Amazon S3 ................................................................................ 540
Utilisation d'IAM avec Amazon RDS ............................................................................. 540
Utilisation d'IAM avec Amazon DynamoDB .................................................................... 540
Pratiques de sécurité générales ........................................................................................... 540
Ressources générales ........................................................................................................ 541
Envoi de demandes de requête ................................................................................................... 542
Points de terminaison ......................................................................................................... 543
HTTPS requis ................................................................................................................... 543
Signature des demandes d'API IAM ..................................................................................... 543
Glossaire AWS .......................................................................................................................... 544
Historique du document .............................................................................................................. 545
viii
Vidéo de présentation de AWS IAM
En quoi consiste IAM ?
AWS Identity and Access Management (IAM) est un service web qui vous permet de contrôler l'accès
aux ressources AWS de vos utilisateurs. IAM vous permet de contrôler qui peut utiliser vos ressources
AWS (authentification) et quelles ressources ils peuvent utiliser et de quelle manière (autorisation).
Rubriques
• Vidéo de présentation de AWS IAM (p. 1)
• Fonctions de IAM (p. 1)
• Accès à IAM (p. 2)
• Présentation de la gestion d'identité : utilisateurs (p. 3)
• Présentation de la gestion des accès : Autorisations et stratégies (p. 5)
• Fonctions de sécurité en dehors d'IAM (p. 8)
• Liens rapides pour les tâches courantes (p. 9)
Cette courte vidéo (2:15) offre une brève présentation de AWS IAM.
Fonctions de IAM
IAM vous offre les fonctions suivantes :
Accès partagé à votre compte AWS
Vous pouvez accorder à d'autres utilisateurs l'autorisation d'administrer et d'utiliser les ressources
de votre compte AWS sans avoir à partager votre mot de passe ou clé d'accès.
Autorisations granulaires
Vous pouvez accorder différentes autorisations à différents utilisateurs concernant différentes
ressources. Par exemple, vous pouvez accorder à certains utilisateurs un accès complet à
Amazon Elastic Compute Cloud (Amazon EC2), Amazon Simple Storage Service (Amazon S3),
Amazon DynamoDB, Amazon Redshift et autres AWS. Pour d'autres utilisateurs, vous pouvez
autoriser un accès en lecture seule à certains compartiments S3 ou l'autorisation d'administrer
1
Accès à IAM
certaines instances EC2 seulement, ou encore un accès à vos informations de facturation
uniquement.
Accès sécurisé aux ressources AWS pour les applications s'exécutant sur Amazon EC2
Vous pouvez utiliser les fonctions IAM pour fournir de manière sécurisée aux applications
s'exécutant sur des instances EC2 les informations d'identification dont elle sont besoin pour
accéder à d'autres ressources AWS, comme les compartiments S3 et RDS ou les bases de
données DynamoDB.
Fédération des identités
Vous pouvez autoriser des utilisateurs disposant déjà de mots de passe ailleurs, par exemple,
dans votre réseau d'entreprise ou auprès d'un fournisseur d'identité Internet, à obtenir un accès
temporaire à votre compte AWS.
Informations d'identité par sécurité
Si vous utilisez AWS CloudTrail, vous recevez des enregistrements de journaux incluant des
informations sur les utilisateurs effectuant des demandes concernant les ressources de votre
compte. Ces informations sont basées sur les identités IAM.
Conformité DSS d'PCI
IAM prend en charge le traitement, le stockage et la transmission des données de cartes
bancaires par un commerçant ou un fournisseur de services, et a été validé comme étant
conforme à la norme PCI (Payment Card Industry) DSS (Data Security Standard). Pour plus
d'information sur PCI DSS, et notamment sur la manière de demander une copie de l'AWS PCI
Compliance Package, consultez PCI DSS, niveau 1.
Intégré à différents services AWS
Pour obtenir une liste des services AWS utilisant IAM, consultez Services AWS qui fonctionnent
avec IAM (p. 394).
Cohérence à terme
IAM, comme d'autres services AWS, est cohérent à terme. IAM garantit une haute disponibilité
en répliquant les données sur plusieurs serveurs dans les centres de données d'Amazon du
monde entier. Si une demande de modification de certaines données aboutit, la modification est
réalisée et stockée en toute sécurité. En revanche, cette modification doit être répliquée dans IAM,
ce qui peut prendre un certain temps. Pour de plus amples informations, veuillez consulter Les
modifications que j'apporte ne sont pas toujours visibles immédiatement (p. 373).
Gratuité
AWS Identity and Access Management est une fonction de votre compte AWS proposée
gratuitement. Vous ne serez facturé que pour l'utilisation des autres produits AWS par vos
utilisateurs d'IAM. Pour plus d'informations sur la tarification des autres produits AWS, consultez la
page de tarification d'Amazon Web Services.
AWS Security Token Service est une fonction incluse de votre compte AWS proposée sans
frais supplémentaires. Vous êtes facturé uniquement pour l'utilisation d'autres services AWS qui
sont accessibles par vos informations d'identification de sécurité temporaires AWS STS. Pour
plus d'informations sur la tarification des autres services AWS, consultez la page de tarification
d'Amazon Web Services.
Accès à IAM
Vous pouvez utiliser AWS Identity and Access Management de l'une des façons suivantes.
AWS Management Console
La console est une interface basée sur un navigateur pour gérer les ressources IAM et AWS.
Pour plus d'informations sur l'accès à IAM via la console, consultez La console IAM et la page
de connexion (p. 53). Pour obtenir un didacticiel pour vous guider dans la console, consultez
Création de votre premier utilisateur administrateur et groupe IAM (p. 15).
Outils de ligne de commande AWS
Vous pouvez utiliser les outils de ligne de commande AWS pour émettre des commandes sur la
ligne de commande votre système afin d'effectuer des tâches IAM et AWS, ce qui peut être plus
2
Présentation : utilisateurs
rapide et plus pratique que d'utiliser la console. Les outils de ligne de commande sont également
utiles si vous souhaitez créer des scripts exécutant des tâches AWS.
AWS fournit deux jeux d'outils de ligne de commande : AWS Command Line Interface (AWS CLI)
et Outils AWS pour Windows PowerShell. Pour plus d'informations sur l'installation et l'utilisation
de l'AWS CLI, consultez le document AWS Command Line Interface Guide de l'utilisateur. Pour
plus d'informations sur l'installation et l'utilisation de l'Outils pour Windows PowerShell, consultez
le document Outils AWS pour Windows PowerShell Guide de l'utilisateur.
Kits SDK AWS
AWS fournit des kits SDK (kits de développement logiciel) composés de bibliothèques et
d'exemples de code pour différentes langages et plateformes de programmation (Java, Python,
Ruby, .NET, iOS, Android, etc.). Ils facilitent la création par programmation d'un accès à IAM
et AWS. Par exemple, ils automatisent les tâches telles que la signature cryptographique des
demandes, la gestion des erreurs et les nouvelles tentatives de demande. Pour plus d'informations
sur les kits SDK AWS, y compris les procédures pour les télécharger et les installer, consultez la
page Outils pour Amazon Web Services.
API HTTPS IAM
Vous pouvez accéder à IAM et à AWS par programmation à l'aide de l'API HTTPS IAM, qui
vous permet d'effectuer des demandes HTTPS directement au service. Lorsque vous utilisez
l'API HTTPS, vous devez inclure un code pour signer numériquement les demandes à l'aide de
vos informations d'identification. Pour plus d'informations, consultez Appel de l'API à l'aide de
demandes de requête HTTP (p. 542) et IAM API Reference.
Présentation de la gestion d'identité : utilisateurs
Pour plus de sécurité et une meilleure organisation, vous accordez l'accès à votre compte AWS à des
identités d'utilisateurs spécifiques que vous créez avec des autorisations personnalisées. Vous pouvez
encore simplifier l'accès des utilisateurs en fédérant les identités existantes dans AWS.
Rubriques
• Première accès uniquement : les informations d'identification de votre compte racine (p. 3)
• Utilisateurs IAM (p. 4)
• Fédération d'utilisateurs existants (p. 4)
Première accès uniquement : les informations
d'identification de votre compte racine
Lorsque vous créez un compte AWS, vous créez une identité de compte (ou « racine ») que vous
utilisez pour vous connecter à AWS. Vous pouvez vous connecter à l'AWS Management Console
à l'aide de cette identité racine, c'est-à-dire avec l'adresse e-mail et le mot de passe que vous avez
fournis lors de la création du compte. Cette combinaison de votre adresse e-mail et de votre mot de
passe est également appelée vos informations d'identification de compte racine.
Lorsque vous utilisez vos informations d'identification de compte racine, vous avez un accès complet,
sans restriction, à toutes les ressources de votre compte AWS, notamment à vos informations de
facturation et à la fonctionnalité de modification du mot de passe. Ce niveau d'accès est nécessaire
lorsque vous configurez pour la première fois votre compte. Cependant, nous vous déconseillons
d'utiliser les informations d'identification du compte racine pour un accès quotidien. Nous vous
recommandons en particulier de ne pas divulguer les informations d'identification de votre compte
racine à quiconque, car cela leur fournirait un accès illimité à votre compte. Il n'est pas possible de
restreindre les autorisations accordées au compte racine.
3
Utilisateurs IAM
Les sections suivantes expliquent comment utiliser IAM pour créer et gérer l'identité et les autorisations
de l'utilisateur pour offrir un accès sécurisé et limité à vos ressources AWS à la fois pour vous-même et
pour les utilisateurs qui doivent utiliser vos ressources AWS.
Utilisateurs IAM
L'aspect d'« identité » de AWS Identity and Access Management (IAM) vous aide à répondre à
la question « Qui est cet utilisateur ? », souvent appelé authentification. Au lieu de partager vos
informations d'identification de compte racine avec d'autres utilisateurs, vous pouvez créer des
utilisateurs IAM individuels dans votre compte correspondant aux utilisateurs de votre organisation.
Les utilisateurs IAM ne constituent pas des comptes séparés. Il sont situés dans votre compte. Chaque
utilisateur dispose de son propre mot de passe pour accéder à l'AWS Management Console. Vous
pouvez également créer une clé d'accès individuelle pour chaque utilisateur afin de lui permettre
d'effectuer des demandes par programmation en vue d'utiliser des ressources de votre compte.
Dans l'illustration suivante, les utilisateurs Brad, Jim, DevApp1, DevApp2, TestApp1 et TestApp2
ont été ajoutés à un compte AWS unique. Chaque utilisateur dispose de ses propres informations
d'identification.
Notez que certains des utilisateurs sont en réalité des applications (par exemple, DevApp1). Un
utilisateur IAM n'a pas besoin de représenter une personne réelle. Vous pouvez créer un utilisateur
IAM pour pouvoir générer une clé d'accès pour une application qui s'exécute dans votre réseau
d'entreprise et doit accéder à AWS.
Nous vous recommandons de créer un utilisateur IAM pour vous-même et d'affecter vous-même
des autorisations administratives à ce compte. Vous pouvez ensuite vous connecter en tant que cet
utilisateur pour ajouter des utilisateurs supplémentaires au besoin.
Fédération d'utilisateurs existants
Si vos utilisateurs peuvent déjà s'authentifier, par exemple, en se connectant à votre réseau
d'entreprise, vous pouvez fédérer ces identités d'utilisateurs dans AWS. Un utilisateur déjà connecté
remplace son identité existante par une identité temporaire dans votre compte AWS. Cet utilisateur
peut utiliser l'AWS Management Console. De même, une application qu'utilise l'utilisateur faut des
demandes par programmation à l'aide des autorisations que vous définissez.
La fédération est particulièrement utile dans les cas suivants :
4
Présentation : Autorisations et stratégies
• Vos utilisateurs ont déjà des identités dans un annuaire d'entreprise.
Si votre annuaire d'entreprise est compatible avec Security Assertion Markup Language 2.0
(SAML 2.0), vous pouvez le configurer pour fournir un accès avec authentification unique (SSO)
à l'AWS Management Console pour vos utilisateurs. Pour de plus amples informations, veuillez
consulter Scénarios courants d'informations d'identification temporaires (p. 245).
Si votre annuaire d'entreprise n'est pas compatible avec SAML 2.0, vous pouvez créer une
application de broker d'identités pour fournir un accès avec authentification unique (SSO) à l'AWS
Management Console pour vos utilisateurs. Pour de plus amples informations, veuillez consulter
Création d'une URL qui permet aux utilisateurs fédérés d'accéder à AWS Management Console
(Broker de fédération personnalisé) (p. 178).
Si votre annuaire d'entreprise est Microsoft Active Directory, vous pouvez utiliser AWS Directory
Service pour établir la confiance entre votre annuaire d'entreprise et votre compte AWS.
• Vos utilisateurs disposent déjà d'identités Internet.
Si vous créez une application mobile ou une application basée sur le web permettant aux utilisateurs
de s'identifier à l'aide d'un fournisseur d'entité Internet comme Login with Amazon, Facebook,
Google ou tout autre fournisseur d'identité compatible avec OpenID Connect (OIDC), l'application
peut utiliser la fédération pour accéder à AWS. Pour de plus amples informations, veuillez consulter
A propos de la fédération d'identité web (p. 149).
Tip
Pour utiliser la fédération d'identité avec des fournisseurs d'identité, nous vous
recommandons d'utiliser Amazon Cognito.
Le diagramme suivant explique comment un utilisateur peut utiliser IAM pour obtenir des informations
d'identification de sécurité AWS temporaires pour accéder aux ressources de votre compte AWS.
Présentation de la gestion des accès :
Autorisations et stratégies
L'aspect de « gestion des accès » de AWS Identity and Access Management vous aide à répondre
à la question « Qu'est-ce que l'utilisateur est autorisé à faire dans mon compte » ?, souvent appelé
autorisation. L'outil de base pour accorder des autorisations dans IAM est la stratégie.
Rubriques
• Stratégies et utilisateurs (p. 6)
5
Stratégies et utilisateurs
• Stratégies et groupes (p. 6)
• Utilisateurs fédérés et rôles (p. 7)
• Stratégies basées sur un utilisateur et basées sur une ressource (p. 7)
Stratégies et utilisateurs
Par défaut, les utilisateurs ne peuvent pas accéder à quoi que ce soit dans votre compte. Vous
accordez des autorisations à un utilisateur en créant une stratégie, qui est un document qui répertorie
les actions qu'un utilisateur peut effectuer et les ressources que les actions peuvent concerner.
L'exemple suivant illustre une stratégie.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "dynamodb:*",
"Resource": "arn:aws:dynamodb:us-west-2:123456789012:table/Books"
}
}
Cette stratégie accorde l'autorisation d'effectuer toutes les actions DynamoDB (dynamodb:*) avec
la table Books dans le compte 123456789012. Lorsque vous attachez la stratégie à un utilisateur,
cet utilisateur dispose alors de ces autorisations DynamoDB. En général, différentes stratégies sont
attachées aux utilisateurs dans votre compte, des stratégies qui représentent les autorisations dont les
utilisateurs ont besoin pour utiliser votre compte AWS.
Les actions ou ressources qui ne sont pas explicitement autorisées sont refusées par défaut. Par
exemple, s'il s'agit de la seule stratégie attachée à un utilisateur, cet utilisateur n'est pas autorisé
à effectuer des actions DynamoDB sur une autre table. De même, l'utilisateur n'est pas autorisé à
effectuer des actions dans Amazon EC2, Amazon S3, ou dans n'importe quelle autre produit AWS,
parce que les autorisations d'utiliser ces produits ne sont pas incluses dans la stratégie.
Stratégies et groupes
Vous pouvez organiser les utilisateurs IAM en groupes IAM et attacher une stratégie à un groupe.
Dans ce cas, les utilisateurs disposent toujours de leurs propres informations d'identification, mais
tous les utilisateurs d'un groupe détiennent les autorisations qui sont attachées à ce groupe. Utilisez
des groupes pour faciliter la gestion des autorisations et de suivre nos Bonnes pratiques concernant
IAM (p. 44).
6
Utilisateurs fédérés et rôles
Plusieurs stratégies accordant différentes autorisations peuvent être attachées à des utilisateurs ou
des groupes. Dans ce cas, les autorisations des utilisateurs sont calculées sur la combinaison des
stratégies. Mais le principe de base s'applique toujours : si l'utilisateur n'a pas reçu une autorisation
explicite pour une action et une ressource, il ne dispose pas de cette autorisation.
Utilisateurs fédérés et rôles
Les utilisateurs fédérés n'ont pas d'identités permanentes dans votre compte AWS de la même
manière que les utilisateurs IAM. Pour attribuer des autorisations à des utilisateurs fédérés, vous
pouvez créer une entité appelée rôle et définir des autorisations pour le rôle. Quand un utilisateur
fédéré se connecte à AWS, l'utilisateur est associé au rôle et reçoit les autorisations qui sont
définies dans le rôle. Pour de plus amples informations, veuillez consulter Création d'un rôle pour un
fournisseur d'identité tiers (Fédération) (p. 201).
Stratégies basées sur un utilisateur et basées sur
une ressource
Dans l'exemple précédent, vous avez découvert une stratégie que vous pouvez attacher à un
utilisateur ou à un groupe. Lorsque vous créez une stratégie basée sur l'utilisateur de cette manière,
vous spécifiez les actions autorisées et la ressource (instance EC2, base de données RDS, etc.) à
laquelle l'utilisateur est autorisé à accéder.
Dans certains cas, vous pouvez attacher une stratégie à une ressource en plus de l'attacher à un
utilisateur ou un groupe. Par exemple, dans Amazon S3, vous pouvez attacher une stratégie à un
compartiment. Une stratégie basée sur une ressource contient des informations légèrement différentes
d'une stratégie basées sur un utilisateur. Dans une stratégie basée sur une ressource, vous spécifiez
les actions qui sont autorisées et la ressource concernée (tout comme dans une stratégie basée sur
un utilisateur). Par contre, vous indiquez aussi explicitement qui est autorisé à accéder à la ressource.
(Dans une stratégie basée sur un utilisateur, « qui » est défini par la personne à laquelle la stratégie
est attachée).
L'exemple suivant montre une stratégie de compartiment S3 qui permet une utilisateur IAM nommé
Bob dans le compte AWS 777788889999 de placer des objets dans le compartiment appelé examplebucket.
{
"Version": "2012-10-17",
"Statement": {
7
Fonctions de sécurité en dehors d'IAM
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::777788889999:user/bob"},
"Action": [
"s3:PutObject",
"s3:PutObjectAcl"
],
"Resource": "arn:aws:s3:::example-bucket/*"
}
}
Les stratégies basées sur une ressource incluent un élément Principal qui spécifie qui reçoit les
autorisations. Dans l'exemple précédent, l'élément Principal est défini comme l'Amazon Resource
Name (ARN) d'un utilisateur IAM nommé Bob dans le compte AWS 777788889999 pour indiquer que
la ressource (dans ce cas, le compartiment S3) est accessible à cet utilisateur IAM mais à personne
d'autre.
Fonctions de sécurité en dehors d'IAM
IAM vous permet de contrôler l'accès aux tâches exécutées à l'aide d'AWS Management Console, des
outils de ligne de commande AWS ou d'API de services via les kits SDK AWS. Certains produits AWS
offrent également d'autres moyens de sécuriser leurs ressources. La liste suivante fournit quelques
exemples, mais elle n'est pas exhaustive.
Amazon EC2
Dans Amazon Elastic Compute Cloud, vous vous connectez à une instance à l'aide d'une paire
de clés (pour les instances Linux) ou d'un nom utilisateur et mot de passe (pour les instances
Microsoft Windows).
Pour plus d'informations, consultez la documentation suivante :
• Démarrez avec les instances Linux Amazon EC2 dans le manuel Amazon EC2 Guide de
l'utilisateur pour les instances Linux
• Démarrez avec les instances Windows Amazon EC2 dans le manuel Amazon EC2 Guide de
l'utilisateur pour les instances Windows
Amazon RDS
Dans Amazon Relational Database Service, vous vous connectez au moteur de base de données
à l'aide d'un nom utilisateur et mot de passe qui sont associés à la base de données.
Pour plus d'informations, consultez Démarrez avec Amazon RDS dans le manuel Amazon
Relational Database Service Guide de l'utilisateur.
Amazon EC2 et Amazon RDS
Dans Amazon EC2 et Amazon RDS, vous utilisez des groupes de sécurité pour contrôler le trafic
d'une instance ou base de données.
Pour plus d'informations, consultez la documentation suivante :
• Groupes de sécurité Amazon EC2 pour les instances Linux dans le manuel Amazon EC2 Guide
de l'utilisateur pour les instances Linux
• Groupes de sécurité Amazon EC2 pour les instances Windows dans le manuel Amazon EC2
Guide de l'utilisateur pour les instances Windows
• Groupes de sécurité Amazon RDS dans le manuel Amazon Relational Database Service Guide
de l'utilisateur
Amazon WorkSpaces
Dans Amazon WorkSpaces, les utilisateurs se connectent au bureau à l'aide d'un nom utilisateur
et mot de passe.
8
Liens rapides pour les tâches courantes
Pour plus d'informations, consultez Démarrez avec Amazon WorkSpaces dans le manuel Amazon
WorkSpaces Administration Guide.
Amazon WorkDocs
Dans Amazon WorkDocs, les utilisateurs peuvent accéder à des documents partagés en se
connectant à l'aide d'un nom utilisateur et mot de passe.
Pour plus d'informations, consultez Démarrez avec Amazon WorkDocs dans le manuel Amazon
WorkDocs Guide d'administration.
Ces méthodes de contrôle d'accès n'appartiennent pas à IAM. IAM vous permet de contrôler comment
ces produits AWS sont gérés : création ou fermeture d'une instance Amazon EC2, configuration de
nouveaux bureaux Amazon WorkSpaces etc. Autrement dit, IAM vous aide à contrôler les tâches
exécutées en effectuant des demandes à Amazon Web Services ; vous pouvez également contrôler
l'accès à AWS Management Console. Toutefois, IAM ne vous permet pas de gérer la sécurité de
tâches telles que la connexion à un système d'exploitation (Amazon EC2), une base de données
(Amazon RDS), un bureau (Amazon WorkSpaces) ou un site collaboratif (Amazon WorkDocs).
Lors de l'utilisation d'un produit AWS spécifique, veillez à bien lire la documentation pour connaître les
options de sécurité pour toutes les ressources appartenant à ce produit.
Utilisez les liens suivants pour obtenir de l'aide sur les tâches courantes associées à IAM.
Se connecter en tant qu’utilisateur IAM
Voir Comment les utilisateurs IAM se connectent à votre compte AWS (p. 70).
Gérer les mots de passe des utilisateurs IAM
Un mot de passe est requis pour accéder à AWS Management Console, y compris aux
informations de facturation.
Pour votre compte AWS, consultez Modification du mot de passe (« racine ») du compte
AWS (p. 78).
Pour un utilisateur IAM, consultez Gestion des mots de passe des utilisateurs IAM (p. 83).
Gérer les autorisations des utilisateurs IAM
Les stratégies vous permettent d'accorder des autorisations aux utilisateurs IAM de votre compte
AWS. Lors de leur création, les utilisateurs IAM ne disposent d'aucune autorisation et vous devez
donc ajouter des autorisations pour leur permettre d'utiliser les ressources AWS.
Pour de plus amples informations, veuillez consulter Utilisation de stratégies (p. 323).
Afficher la liste des utilisateurs de votre compte AWS et obtenir les détails de leurs informations
d'identification
Voir the section called “Obtention de rapports d'informations d'identification” (p. 123).
Ajouter l'authentification multi-facteurs (MFA)
Pour ajouter un périphérique MFA virtuel pour votre compte racine AWS, consultez Activer un
périphérique MFA virtuel votre compte racine AWS (AWS Management Console) (p. 97).
Pour ajouter un périphérique MFA physique pour votre compte racine AWS, consultez Activer
un périphérique MFA physique pour l'utilisateur racine du compte AWS (AWS Management
Console) (p. 100).
Pour ajouter un périphérique MFA virtuel pour un utilisateur IAM, consultez Activer un périphérique
MFA virtuel pour un utilisateur IAM (AWS Management Console) (p. 96).
Pour ajouter un périphérique MFA physique pour un utilisateur IAM, consultez Activer un
périphérique MFA physique pour un utilisateur IAM (AWS Management Console) (p. 100).
9
Pour ajouter un périphérique MFA matériel pour votre compte AWS ou un utilisateur IAM,
consultez Activation d'un périphérique MFA physique (AWS Management Console) (p. 99).
Obtenir une clé d'accès
Une clé d'accès est requise si vous souhaitez créer des demandes AWS à l'aide des kits SDK
AWS, des outils de ligne de commande AWS, des Outils pour Windows PowerShell ou des API.
Important
Vous pouvez afficher et télécharger votre clé d'accès secrète uniquement lors de la
création de la clé. Il n'est pas possible d'afficher ou de récupérer une clé d'accès secrète
ultérieurement. Toutefois, si vous perdez votre clé d'accès secrète, vous pouvez en créer
une nouvelle.
Pour votre compte AWS, consultez Gestion des clés d'accès pour un compte AWS.
Pour un utilisateur IAM, consultez Gestion des clés d'accès pour les utilisateurs IAM (p. 89).
10
Utilisation de IAM pour accorder aux
utilisateurs l'accès à vos ressources AWS.
Configuration
AWS Identity and Access Management (IAM) vous permet de contrôler l'accès à Amazon Web
Services (AWS) et vos ressources de compte de façon sécurisée. IAM permet également de rendre
les informations d'identification de votre compte confidentielles. Avec IAM, vous pouvez créer plusieurs
utilisateurs IAM dans le cadre de votre compte AWS ou accorder un accès temporaire par le biais de
la fédération d'identité avec votre annuaire d'entreprise. Dans certains cas, vous pouvez également
accorder l'accès à des ressources dans vos comptes AWS.
En revanche, sans IAM, vous devez créer plusieurs comptes AWS (chacun disposant de sa propre
facturation et de ses propres abonnements aux produits AWS) ou bien vos employés doivent partager
les informations d'identification de sécurité d'un compte AWS unique. De plus, sans IAM, vous ne
pouvez pas contrôler les tâches qu'un utilisateur ou un système spécifique peut effectuer et les
ressources AWS qu'il peut utiliser.
Ce guide fournit une présentation conceptuelle de IAM, décrit des cas d'utilisation commerciaux et
explique les autorisations et les stratégies AWS.
Rubriques
• Utilisation de IAM pour accorder aux utilisateurs l'accès à vos ressources AWS. (p. 11)
• Dois-je m'inscrire à IAM ? (p. 12)
• Ressources supplémentaires (p. 12)
Utilisation de IAM pour accorder aux utilisateurs
l'accès à vos ressources AWS.
Voici comment IAM peut vous aider à contrôler l'accès à vos ressources AWS.
Type d'accès
Pourquoi devrais-je m'utiliser ?
Comment puis-je obtenir plus d'informations ?
Accès aux
utilisateurs
par le biais de
votre compte
AWS
Vous souhaitez ajouter des
utilisateurs dans le cadre de
votre compte AWS et vous
souhaitez utiliser IAM pour
créer des utilisateurs et gérer
leurs autorisations.
Pour savoir comment utiliser la AWS Management
Console pour créer des utilisateurs et gérer leurs
autorisations par le biais de votre compte AWS,
consultez Démarrage (p. 14).
11
Pour en savoir plus sur l'utilisation de l'API IAM
ou de l'AWS Command Line Interface pour créer
des utilisateurs par le biais de votre compte AWS,
Dois-je m'inscrire à IAM ?
Type d'accès
Pourquoi devrais-je m'utiliser ?
Comment puis-je obtenir plus d'informations ?
consultez Création de votre premier utilisateur
administrateur et groupe IAM (p. 15).
Pour plus d'informations sur l'utilisation
d'utilisateurs IAM, consultez Identités (utilisateurs,
groupes et rôles) (p. 61).
Les
utilisateurs
non AWS y
accèdent via
la fédération
d'identité
entre votre
système
d'autorisation
et AWS
Votre système d'identité
et d'autorisation contient
des utilisateurs non AWS
qui doivent accéder à vos
ressources AWS
Pour savoir comment utiliser des jetons de
sécurité pour accorder à vos utilisateurs l'accès
à vos ressources de compte AWS par le biais de
la fédération avec votre annuaire d'entreprise,
accédez à Informations d'identification de sécurité
temporaires (p. 244). Pour plus d'informations
sur l'API AWS Security Token Service, accédez à
Référence de l'API AWS Security Token Service.
Accès entre
Vous souhaitez partager l'accès
comptes AWS à certaines ressources AWS
avec des utilisateurs par le
biais d'autres comptes AWS.
Pour savoir comment utiliser IAM pour accorder
des autorisations à accéder à d'autres comptes
AWS, consultez Termes et concepts relatifs aux
rôles (p. 140).
Dois-je m'inscrire à IAM ?
Si vous n'avez pas encore de compte AWS, vous aurez besoin d'en créer un pour utiliser IAM. Vous
n'avez pas besoin de vous inscrire spécifiquement pour utiliser IAM. L'utilisation du IAM est gratuite.
Note
IAM fonctionne uniquement avec les produits AWS qui sont intégrés à IAM. Pour connaître
la liste des services prenant en charge IAM, consultez Services AWS qui fonctionnent avec
IAM (p. 394).
Pour s'inscrire sur AWS
1.
2.
Ouvrez https://aws.amazon.com/, puis choisissez Create an AWS Account.
Suivez les instructions en ligne.
Dans le cadre de la procédure d'inscription, vous recevrez un appel téléphonique et vous saisirez
un code PIN en utilisant le clavier numérique du téléphone.
Ressources supplémentaires
Voici quelques ressources utiles pour vous aider à débuter avec IAM.
• Gérez vos informations d'identification de compte AWS : Identifiants de sécurité AWS dans le guide
AWS General Reference
• Faites vos premiers pas et découvrez En quoi consiste IAM ? (p. 1)
• Configurez une CLI (interface ligne de commande) avec IAM. Pour plus d'informations sur l'AWS
CLI, inter-plateforme, consultez la documentation sur l'interface de ligne de commande AWS et la
référence sur CLI IAM. Vous pouvez également gérer IAM avec Windows PowerShell. Consultez
12
la documentation sur les outils AWS pour Windows PowerShell et la référence sur Windows
PowerShell IAM.
• Téléchargez un kit SDK AWS pour obtenir un accès par programmation pratique à IAM : Outils pour
Amazon Web Services
• Consultez les notes de mise à jour : Notes de mise à jour
• Consultez la FAQ : FAQ AWS Identity and Access Management
• Consultez le support technique : Centre de support AWS
• Consultez le support technique prémium : Centre de Premium Support AWS
• Trouvez des définitions des termes AWS : Glossaire Amazon Web Services
• Consultez le support communautaire : Forums de discussion IAM
• Contactez AWS : Contactez-nous
13
Démarrage
Cette rubrique vous explique comment accorder l'accès à vos ressources AWS en créant des
utilisateurs dans votre compte AWS. D'abord, vous allez apprendre des concepts que vous devez
comprendre avant de créer des groupes et des utilisateurs, puis vous allez découvrir comment
exécuter les tâches nécessaires à l'aide de l'AWS Management Console. La première tâche consiste
à configurer un groupe d'administrateurs pour votre compte AWS. Il n'est pas exigé que vous ayez un
groupe d'administrateurs pour votre compte AWS. mais c'est fortement recommandé.
L'illustration suivante présente un exemple simple de compte AWS composé de trois groupes. Un
groupe est une sélection d'utilisateurs qui ont des responsabilités similaires. Dans cet exemple, un
groupe est pour les administrateurs (il se nomme Admins). Il y a aussi un groupe Développeurs et un
groupeTest. Chaque groupe a de multiples utilisateurs. Chaque utilisateur peut faire partie d'un ou de
plusieurs groupes, bien que l'illustration ne présente pas cette situation. Vous ne pouvez pas mettre
de groupes à l'intérieur d'autres groupes Vous utilisez des stratégies pour accorder des autorisations à
des groupes.
14
Création d'un utilisateur administrateur et d'un groupe IAM
Dans la procédure qui suit, vous effectuerez les tâches suivantes :
• Créez un groupe Administrateurs et accordez-lui l'autorisation d'accéder à toutes les ressources de
votre compte AWS.
• Créez un utilisateur pour vous-même et ajoutez-le au groupe Administrateurs.
• Créez un mot de passe pour votre utilisateur afin d'accéder à AWS Management Console.
Vous allez accorder au groupe Administrateurs l'autorisation d'accéder à toutes vos ressources
de compte AWS disponibles. Les ressources disponibles correspondent à tous les produits AWS
que vous utilisez ou auxquels vous êtes inscrit. Les utilisateurs du groupe Administrateurs peuvent
également accéder à vos informations de compte AWS, sauf vos informations d'identification de
sécurité du compte AWS.
Rubriques
• Création de votre premier utilisateur administrateur et groupe IAM (p. 15)
• Comment les utilisateurs se connectent à votre compte (p. 18)
Création de votre premier utilisateur
administrateur et groupe IAM
A titre de bonne pratique (p. 45), n'utilisez pas l'utilisateur racine du compte AWS lorsqu'il n'est pas
requis pour une tâche. Au lieu de cela, créez un utilisateur IAM pour chaque personne ayant besoin
d'un accès administrateur. Ensuite, créez ces utilisateurs administrateur en les plaçant dans un groupe
« Administrateurs » auquel vous attachez la stratégie gérée AdministratorAccess.
15
Création d'un utilisateur et d'un
groupe IAM administrateur (console)
Ensuite, les utilisateurs du groupe d'administrateurs doivent configurer les groupes, les utilisateurs,
etc. pour le compte AWS.Toutes les interactions futures doivent être effectuées par l'intermédiaire des
utilisateurs du compte AWS et de leurs propres clés au lieu de l'utilisateur racine.
Création d'un utilisateur et d'un groupe IAM
administrateur (console)
Cette procédure décrit l'utilisation de l'AWS Management Console afin de créer un utilisateur IAM pour
vous-même et l'ajout de cet utilisateur à un groupe disposant des autorisations administratives d'une
stratégie gérée attachée.
Pour créer un administrateur pour vous-même et ajouter l'utilisateur à un groupe
d'administrateurs (console)
1.
Dans le volet de navigation, choisissez Users, puis Add user.
2.
Pour User name, tapez un nom d'utilisateur, par exemple Administrateur. Le nom peut être
constitué de lettres, de chiffres et des caractères suivants : plus (+), égal (=), virgule (,), point
(.), arobas (@), trait de soulignement (_) et tiret (-). Le nom n'est pas sensible à la casse et peut
contenir un maximum de 64 caractères.
3.
Activez la case à cocher en regard de AWS Management Console access, sélectionnez Custom
password, puis tapez le nouveau mot de passe dans la zone de texte. Si vous créez l'utilisateur
pour une autre personne que vous-même, vous pouvez sélectionner si nécessaire Require
password reset afin d'obliger l'utilisateur à créer un nouveau mot de passe lors de sa première
connexion.
4.
Choisissez Next: Permissions.
5.
Sur la page Set permissions for user, choisissez Add user to group.
6.
Choisissez Create group.
7.
Dans la boîte de dialogue Create group, tapez le nom du nouveau groupe. Le nom peut être
constitué de lettres, de chiffres et des caractères suivants : plus (+), égal (=), virgule (,), point
(.), arobas (@), trait de soulignement (_) et tiret (-). Le nom n'est pas sensible à la casse et peut
contenir un maximum de 128 caractères.
8.
Dans la liste des stratégies, activez la case à cocher en regard de l'option AdministratorAccess.
Choisissez ensuite Create group.
9.
De retour dans la liste des groupes, activez la case à cocher du nouveau groupe. Choisissez
Refresh si nécessaire pour afficher le groupe dans la liste.
10. Choisissez Next: Review pour afficher la liste des membres du groupe à ajouter au nouvel
utilisateur. Une fois que vous êtes prêt à continuer, choisissez Create user.
Vous pouvez utiliser ce même processus pour créer d'autres groupes et utilisateurs et pour accorder
à vos utilisateurs l'accès aux ressources de votre compte AWS. Pour en savoir plus sur l'utilisation
des stratégies qui limitent les autorisations utilisateur à des ressources AWS spécifiques, consultez
Gestion de l'accès (p. 281) et Exemples de stratégies de gestion de ressources AWS (p. 347).
Création d'un groupe et d'un utilisateur IAM (AWS
CLI)
Si vous avez suivi les étapes de la section précédente, vous avez utilisé l'AWS Management Console
afin de configurer un groupe d'administrateurs pendant la création de l'utilisateur dans votre compte
AWS. Cette procédure présente un autre moyen de créer un groupe.
16
Création d'un groupe et d'un utilisateur IAM (AWS CLI)
Présentation : configuration d'un groupe d'administrateurs
1. Créez un groupe et donnez-lui un nom (par exemple, Admins). Pour de plus amples informations,
veuillez consulter Création d'un groupe (AWS CLI) (p. 17).
2. Attachez une stratégie qui accorde au groupe des autorisations administratives : l'accès à toutes les
actions et ressources AWS. Pour de plus amples informations, veuillez consulter Attachement d'une
stratégie au groupe (AWS CLI) (p. 18).
3. Ajoutez au moins un utilisateur au groupe. Pour de plus amples informations, veuillez consulter
Création d'un utilisateur IAM dans votre compte AWS (p. 66).
Création d'un groupe (AWS CLI)
Cette section vous montre comment créer un groupe dans le système IAM.
Pour créer un groupe d'administrateurs (AWS CLI)
1.
Tapez la commande aws iam create-group avec le nom que vous avez choisi pour le groupe.
Facultativement, vous pouvez inclure un chemin dans le nom du groupe. Pour plus d'informations
sur les chemins, consultez Noms conviviaux et chemins (p. 387). Le nom peut être constitué
de lettres, de chiffres et des caractères suivants : plus (+), égal (=), virgule (,), point (.), arobas
(@), trait de soulignement (_) et tiret (-). Le nom n'est pas sensible à la casse et peut contenir un
maximum de 128 caractères.
Dans cet exemple, créez un groupe appelé Admins.
aws iam create-group --group-name Admins
{
"Group": {
"Path": "/",
"CreateDate": "2014-06-05T20:29:53.622Z",
"GroupId":"ABCDEFGHABCDEFGHABCDE",
"Arn": "arn:aws:iam::123456789012:group/Admins",
"GroupName": "Admins"
}
}
2.
Tapez la commande aws iam list-groups pour répertorier les groupes dans votre compte
AWS et valider la création du groupe.
aws iam list-groups
{
"Groups": [
{
"Path": "/",
"CreateDate": "2014-06-05T20:29:53.622Z",
"GroupId":"ABCDEFGHABCDEFGHABCDE",
"Arn": "arn:aws:iam::123456789012:group/Admins",
"GroupName": "Admins"
}
]
}
La réponse inclut l'ARN (Amazon Resource Name) de votre nouveau groupe. L'ARN est un format
standard utilisé par AWS pour identifier les ressources. Le numéro à 12 chiffres de l'ARN est votre
ID de compte AWS. Le nom convivial que vous attribuez au compte (Admins) apparait la fin de
l'ARN du groupe.
17
Comment les utilisateurs se connectent à votre compte
Attachement d'une stratégie au groupe (AWS CLI)
Cette section décrit comment attacher une stratégie qui permet à n'importe quel utilisateur du groupe
d'exécuter des actions sur n'importe quelle ressource du compte AWS. Pour cela, vous attachez
la stratégie gérée AWS (p. 299) appelée AdministratorAccess au groupe Admins. Pour plus
d'informations sur les stratégies, consultez Gestion de l'accès (p. 281).
Pour ajouter une stratégie accordant des autorisation administrateur complètes (AWS CLI)
1.
Tapez la commande aws iam attach-group-policy pour attacher la stratégie appelée
AdministratorAccess à votre groupe Admins. La commande utilise l'ARN de la stratégie gérée
AWS appelée AdministratorAccess.
aws iam attach-group-policy --group-name Admins --policy-arn
arn:aws:iam::aws:policy/AdministratorAccess
Si la commande est réussie, il n'y a pas de réponse.
2.
Tapez la commande aws iam list-attached-group-policies pour vérifier que la stratégie
est attachée au groupe Admins.
aws iam list-attached-group-policies --group-name Admins
La réponse liste les noms des lignes de conduite attachées au groupe Admins. Une réponse telle
que la suivante vous indique que la stratégie appelée AdministratorAccess a été attachée au
groupe Admins :
{
"AttachedPolicies": [
{
"PolicyName": "AdministratorAccess",
"PolicyArn": "arn:aws:iam::aws:policy/AdministratorAccess"
}
],
"IsTruncated": false
}
Vous pouvez confirmer le contenu d'une stratégie spécifique avec la commande aws iam getpolicy.
Important
Une fois le groupe administrateurs configuré, vous devez y ajouter au moins un utilisateur.
Pour plus d'informations sur l'ajout d'utilisateurs à un groupe, consultez Création d'un
utilisateur IAM dans votre compte AWS (p. 66).
Comment les utilisateurs se connectent à votre
compte
Une fois que vous avez créé des utilisateurs d'IAM et des mots de passe pour chacun d'entre eux, les
utilisateurs peuvent se connecter à la AWS Management Console pour votre compte AWS avec une
URL spéciale.
18
Par défaut, l'URL de connexion pour votre compte contient votre ID de compte. Vous pouvez créer
une URL de connexion unique pour votre compte afin que l'URL contienne un nom au lieu d'un ID
de compte. Pour de plus amples informations, veuillez consulter Votre ID de compte AWS et son
alias (p. 56).
Le point de terminaison de la connexion suit ce modèle :
https://AWS-account-ID-or-alias.signin.aws.amazon.com/console
L'URL de connexion à un compte se trouve sur le tableau de bord de la console IAM.
Vous pouvez également vous connecter au point de terminaison suivant et entrer l'ID de compte ou
l'alias manuellement, au lieu qu'il soit intégré dans l'URL :
https://signin.aws.amazon.com/console
Conseil
Pour créer un marque-page pour la page unique de connexion à votre compte dans votre
navigateur Web, vous devez entrer manuellement l'URL de connexion de votre compte lors
de la création du marque-page. N'utilisez pas la fonction « Marquer cette page » de votre
navigateur web.
Les utilisateurs d'IAM de votre compte ont accès uniquement aux ressources AWS que vous
spécifiez dans la stratégie associée à l'utilisateur ou à un groupe IAM auquel l'utilisateur appartient.
Pour travailler dans la console, les utilisateurs doivent avoir des autorisations pour effectuer les
actions que la console exécute, telles que l'affichage et la création de ressources AWS. Pour plus
d'informations, consultez Gestion de l'accès (p. 281) et Exemples de stratégies de gestion de
ressources AWS (p. 347).
Note
Si votre organisation dispose d'un système d'identité existant, vous pouvez créer une option
d'authentification unique (SSO) qui donne aux utilisateurs l'accès à la AWS Management
Console pour votre compte, sans les obliger à avoir une identité d'utilisateur d'IAM et sans
les forcer à se connecter séparément au site de votre organisation et à AWS. Pour de plus
amples informations, veuillez consulter Création d'une URL qui permet aux utilisateurs fédérés
d'accéder à AWS Management Console (Broker de fédération personnalisé) (p. 178).
Journalisation des détails de connexion dans CloudTrail
Si vous activez CloudTrail de façon à consigner les événements de connexion dans vos journaux, vous
devez savoir comment CloudTrail choisit l'emplacement de consignation des événements.
• Si les utilisateurs se connectent directement à une console, ils sont redirigés vers un point de
terminaison de connexion international ou régional, si la console de service sélectionnée prend en
charge les régions. Par exemple, la page d'accueil de la console principale prend en charge les
régions, donc si vous vous connectez à l'URL suivante :
https://alias.signin.aws.amazon.com/console
19
vous êtes redirigé vers un point de terminaison de connexion régional, par exemple https://useast-1.signin.aws.amazon.com, ce qui entraîne une entrée de journal CloudTrail régionale
dans le journal régional de l'utilisateur :
En revanche, la console Amazon S3 ne prend pas en charge les régions, donc si vous vous
connectez à l'URL suivante
https://alias.signin.aws.amazon.com/console/s3
AWS vous redirige vers le point de terminaison de connexion international à l'adresse https://
signin.aws.amazon.com, ce qui crée une entrée de journal CloudTrail internationale.
• Vous pouvez demander manuellement un point de terminaison de connexion régional spécifique en
vous connectant à la page d'accueil régionale de la console principale à l'aide d'une syntaxe d'URL
similaire à ce qui suit :
https://alias.signin.aws.amazon.com/console?ap-southeast-1
AWS vous redirige vers le point de terminaison de connexion régional ap-southeast-1, ce qui
crée un événement de journal CloudTrail régional.
Pour plus d'informations sur CloudTrail et IAM, consultez Journalisation des événements IAM avec
AWS CloudTrail .
Si les utilisateurs ont besoin d'un accès par programmation pour utiliser votre compte, vous pouvez
créer une paire de clés d'accès (un ID de clé d'accès et une clé d'accès secrète) pour chaque
utilisateur, comme décrit dans Création, modification et affichage des clés d'accès (AWS Management
Console) (p. 90).
20
Didacticiel : Déléguer l'accès à la console de facturation
Didacticiels IAM
Cette section contient des procédures complètes de bout en bout pour des tâches courantes
que vous pouvez exécuter dans IAM. Elles sont conçues pour une environnement de type labo,
avec des exemples de noms de sociétés, de noms utilisateurs, etc. Leur objectif consiste à fournir
des instructions générales. Elles ne sont pas conçues pour être utilisées directement dans votre
environnement de production sans être préalablement vérifiées et adaptées soigneusement aux
aspects uniques de l'environnement de votre organisation.
Rubriques
• Didacticiel : Déléguer l'accès à la console de facturation (p. 21)
• Didacticiel : Déléguer l'accès entre des comptes AWS à l'aide de rôles IAM (p. 26)
• Didacticiel : Créer et attacher votre première stratégie gérée par le client (p. 36)
• Didacticiel : Autoriser les utilisateurs à configurer leurs propres informations d'identification et
paramètres MFA (p. 39)
Didacticiel : Déléguer l'accès à la console de
facturation
Les titulaires de compte AWS peuvent déléguer l'accès à des utilisateurs IAM spécifiques qui
doivent afficher ou gérer les données AWS Billing and Cost Management de votre compte AWS.
Les instructions qui suivent vous permettront de configurer un scénario préalablement testé pour
vous familiariser avec la configuration d'autorisations de facturation, sans vous préoccuper des
conséquences sur votre principal compte de production AWS.
Ce flux de travail se compose de quatre étapes de base.
21
Prérequis
Étape 1 : Activer l'accès aux données de facturation de votre compte AWS de test (p. 22)
Par défaut, seul le titulaire du compte AWS (compte racine) a accès pour afficher et gérer les
informations de facturation. L'accès à ces données ne peut pas être délégué aux utilisateurs
IAM tant que le titulaire du compte n'a pas activé l'accès aux données de facturation dans les
paramètres du copte.
Étape 2 : Créer des stratégies IAM qui accordent des autorisations aux données de
facturation (p. 23)
Après avoir activé l'accès à la facturation sur votre compte, vous devez toujours accorder
explicitement l'accès aux données de facturation à des utilisateurs ou à des groupes IAM
spécifiques. Vous accordez cet accès avec une stratégie gérée par le client.
Étape 3 : Attacher des stratégies de facturation à vos groupes (p. 24)
Lorsque vous attachez une stratégie à un groupe, tous les membres de celui-ci reçoivent un
ensemble complet d'autorisations d'accès associées à cette stratégie. Dans ce scénario, vous
attachez les nouvelles stratégies de facturation aux groupes de sécurité contenant uniquement les
utilisateurs qui ont besoin de l'accès à la facturation.
Étape 4 : Tester l'accès à la console de facturation (p. 24)
Une fois que vous avez terminé les tâches de base, vous êtes prêt à tester la stratégie. Les tests
permettent de s'assurer que la stratégie fonctionne comme vous le souhaitez.
Prérequis
Créez un compte AWS de test à utiliser avec ce didacticiel. Dans ce compte, créez deux utilisateurs de
test et deux groupes de test comme résumé dans le tableau suivant. Veillez à affecter un mot de passe
à chaque utilisateur afin de pouvoir vous connecter à l'étape 4.
Créer les comptes d'utilisateur
Créer et configurer les compte du groupe
FinanceManager
FullAccess
FinanceManager
FinanceUser
ViewAccess
FinanceUser
Étape 1 : Activer l'accès aux données de facturation
de votre compte AWS de test
Dans la première section, vous vous connectez à votre compte de test avec les informations
d'identification du compte racine et vous accédez à la page des paramètres du compte dans AWS
Management Console. De là, vous activer l'accès de l'utilisateur IAM aux données de la console
Billing and Cost Management. Pour plus d'informations sur la manière de suivre ce processus dans un
environnement de production, consultez Activer l'accès au site web AWS dans le manuel AWS Billing
and Cost Management Guide de l'utilisateur.
Pour activer l'accès aux données de facturation de votre compte AWS de test
1.
Connectez-vous à AWS Management Console avec les informations d'identification de votre
compte racine (l'adresse e-mail et le mot de passe que vous avez utilisés pour créer votre compte
AWS de test).
Note
Cela nécessite les informations d'identification du compte racine et ne peut pas être
effectué par un utilisateur IAM.
2.
Sur la barre de navigation, choisissez le nom de votre compte, puis My Account.
22
3.
Étape 2 : Créer des stratégies IAM qui accordent
des autorisations aux données de facturation
En regard de IAM User Access to Billing Information, choisissez Edit, puis sélectionnez la case à
cocher pour activer l'accès IAM aux pages Billing and Cost Management.
Important
Lorsque vous activez l'accès utilisateur IAM au site web AWS, vous accordez l'accès
complet au site web AWS à tous les utilisateurs qui ont déjà un accès complet aux API
AWS. Vous pouvez restreindre leur accès en appliquant un ensemble d'autorisations plus
limité. Consultez Exemple 4 : Autoriser l'accès complet aux services AWS mais refuser
aux utilisateurs IAM l'accès à la console AWS Billing and Cost Management.
4.
Déconnectez-vous de la console, puis passez à l'Étape 2 : Créer des stratégies IAM qui accordent
des autorisations aux données de facturation (p. 23).
Étape 2 : Créer des stratégies IAM qui accordent
des autorisations aux données de facturation
Ensuite, vous créez des stratégies personnalisées qui accordent des autorisations d'accès en
affichage et complet aux pages de la console Billing and Cost Management. Pour obtenir des
informations générales sur les stratégies d'autorisation IAM, consultez Stratégies gérées et stratégies
en ligne (p. 299).
Pour créer des stratégies IAM qui accordent des autorisations aux données de facturation
1.
Connectez-vous à AWS Management Console en tant qu'utilisateur disposant d'informations
d'identification d'administrateur. Pour respecter les bonnes pratiques IAM, ne vous connectez
pas avec votre compte racine. Pour plus d'informations, consultez Créer des utilisateurs IAM
individuels (p. 45).
2.
Ouvrez la console IAM à l'adresse https://console.aws.amazon.com/iam/.
3.
Dans le volet de navigation, choisissez Policies, puis Create Policy.
4.
En regard de Policy Generator, choisissez Select.
5.
Dans la page Edit Permissions, pour Effect, choisissez Allow.
6.
Pour AWS Service, choisissez AWS Billing.
7.
Suivez ces étapes pour créer deux stratégies :
Accès complet
a. Pour Instance Actions, choisissez All Actions (*).
b. Cliquez sur Add Statement, puis sur Next Step.
c. Sur la page Review Policy, en regard de Policy Name, tapez BillingFullAccess, puis
choisissez Create Policy pour l'enregistrer.
Accès en affichage uniquement
a. Répétez les étapes 3 à 6 (p. 23).
b. Pour Actions, choisissez les autorisations qui commencent par View.
c. Cliquez sur Add Statement, puis sur Next Step.
d. Sur la page Review Policy, en regard de Policy Name, tapez BillingViewAccess, puis choisissez
Create Policy pour l'enregistrer.
Pour consulter les descriptions de chacune des autorisations disponibles dans les stratégies IAM
qui accordent l'accès utilisateur à la console Billing and Cost Management, consultez Descriptions
des autorisations de facturation.
23
Étape 3 : Attacher des stratégies
de facturation à vos groupes
Étape 3 : Attacher des stratégies de facturation à
vos groupes
Maintenant que vous disposez de stratégies de facturation personnalisées, vous pouvez les attacher
à leurs groupes correspondants que vous avez créés ultérieurement. Bien que vous ayez attaché
une stratégie directement à un utilisateur ou à un groupe, nous vous recommandons (conformément
aux bonnes pratiques IAM) d'utiliser plutôt les groupes. Pour plus d'informations, consultez la section
Utiliser des groupes pour attribuer des autorisations à des utilisateurs IAM (p. 46).
Attacher des stratégies de facturation à vos groupes
1.
Dans le volet de navigation, choisissez Policies pour afficher la liste complète des stratégies
disponibles pour votre compte AWS. Pour attacher chaque stratégie à son groupe correspondant,
procédez comme suit :
Accès complet
a. Pour Filter, tapez BillingFullAccess, puis activez la case à cocher située en regard du nom
de la stratégie.
b. Choisissez Policy Actions, puis choisissez Attach.
c. Pour Filter, tapez FullAccess, activez la case à cocher en regard du nom du groupe, puis
choisissez Attach Policy.
a. Pour Filter, tapez BillingViewAccess, puis activez la case à cocher située en regard du nom
de la stratégie.
b. Choisissez Policy Actions, puis choisissez Attach.
c. Pour Filter, tapez ViewAccess, activez la case à cocher en regard du nom du groupe, puis
choisissez Attach Policy.
2.
Déconnectez-vous de la console, puis passez à l'Étape 4 : Tester l'accès à la console de
facturation (p. 24).
Étape 4 : Tester l'accès à la console de facturation
Vous pouvez tester l'accès utilisateur de différentes façons. Dans le cadre de ce didacticiel, nous vous
recommandons de teste l'accès en vous connectant en tant que chacun des utilisateurs de test afin
d'observer les résultats et vous rendre compte de l'expérience que vivent vos utilisateurs. Il existe
une autre façon (facultative) de tester les autorisations d'accès utilisateur, en utilisant le simulateur
de stratégies IAM. Procédez comme suit, si vous souhaitez connaître une autre manière d'afficher les
résultats concrets de ces actions.
Sélectionnez l'une des procédures suivantes basées sur votre méthode de test préférée. La première
méthode consiste à vous connecter aux deux comptes de test pour voir les différences de droits
d'accès.
Pour tester l'accès à la facturation en vous connectant aux deux comptes d'utilisateurs de test
1.
Accédez à l'URL de connexion de votre compte de test AWS. Par exemple, si le nom de
votre compte AWS est CompanyXYZ, votre URL de connexion ressemblera à https://
companyxyz.signin.aws.amazon.com/console. Si vous n'avez pas affecté d'alias
comme CompanyXYZ, utilisez votre numéro d'ID de compte comme dans l'exemple suivant :
https://123456789012.signin.aws.amazon.com/console.
24
Ressources connexes
2.
Connectez-vous à chaque compte à l'aide de la procédure fournie ci-dessous pour comparer les
différentes expériences utilisateur.
Accès complet
a. Connectez-vous à votre compte AWS en tant que l'utilisateur FinanceManager.
b. Sur la barre de navigation, choisissez FinanceManager@<alias ou numéro d'ID du
compte>, puis choisissez Billing & Cost Management.
c. Parcourez les pages et choisissez les différents boutons pour vérifier que vous disposez des
autorisations de modification complètes.
a. Connectez-vous à votre compte AWS en tant que l'utilisateur FinanceUser.
b. Sur la barre de navigation, choisissez FinanceUser@<alias ou numéro d'ID du
compte>, puis choisissez Billing & Cost Management.
c. Parcourez les pages. Notez que vous pouvez afficher les coûts, les états et les données de
facturation sans problèmes. En revanche, si vous choisissez une option pour modifier une
valeur, vous recevez un message Access Denied . Par exemple, sur la page Preferences,
activez n'importe quelle case à cocher de la page, puis choisissez Save preferences. Le
message de la console vous informe que vous devez disposer des autorisations ModifyBilling
pour modifier cette page.
La procédure facultative suivante montre comment vous pouvez également utiliser le simulateur de
stratégies IAM pour tester vos autorisations effectives d'utilisateur délégué aux pages de facturation.
Pour tester l'accès à la facturation en affichant les autorisations effectives dans le simulateur
de stratégies IAM
1.
Ouvrez le simulateur de stratégies IAM à l'adresse https://policysim.aws.amazon.com. (Si vous
n'êtes pas déjà connecté à AWS, vous y êtes invité.)
2.
Sous Users, Groups, and Roles, sélectionnez l'un des utilisateurs faisant partie du groupe auquel
vous avez récemment attaché la stratégie.
3.
Sous Policy Simulator, choisissez Select service, puis Billing.
4.
En regard de Select actions, choisissez Select All.
5.
Choisissez Run Simulation et comparez les autorisations répertoriées pour l'utilisateur avec toutes
les options d'autorisation liées à la facturation possibles pour vous assurer que les droits adéquats
ont été appliqués.
Ressources connexes
Pour obtenir des informations connexes dans le manuel AWS Billing and Cost Management Guide de
l'utilisateur, consultez les ressources suivantes :
• Activer l'accès au site web AWS
• Exemple 4 : Autoriser l'accès complet aux services AWS mais refuser aux utilisateurs IAM l'accès à
la console AWS Billing and Cost Management.
• Descriptions des autorisations de facturation
Pour obtenir des informations connexes dans le manuel IAM Guide de l'utilisateur, consultez les
ressources suivantes :
• Stratégies gérées et stratégies en ligne (p. 299)
25
Récapitulatif
• Contrôle de l'accès utilisateur à AWS Management Console (p. 55)
• Attacher une stratégie à un groupe IAM (p. 137)
Récapitulatif
Vous avez à présent terminé toutes les étapes nécessaires pour déléguer l'accès utilisateur à la
console Billing and Cost Management. Vous avez pu constater par vous-même de l'expérience
que vivront vos utilisateurs avec la console de facturation et vous pouvez à présent procéder à
l'implémentation de cette logique dans votre environnement de production comme bon vous semble.
Didacticiel : Déléguer l'accès entre des comptes
AWS à l'aide de rôles IAM
Dans ce didacticiel, vous allez apprendre comment utiliser un rôle pour déléguer l'accès aux
ressources situées dans différents comptes AWS que vous possédez (Production et Développement).
Vous allez partager les ressources d'un compte avec les utilisateurs d'un autre compte. En configurant
l'accès entre comptes de cette manière, vous n'avez pas besoin de créer des utilisateurs IAM
individuels dans chaque compte, et les utilisateurs n'ont pas besoin de se déconnecter d'un compte
et e se connecter à un autre pour accéder aux ressources situées sur différents comptes AWS. Après
avoir configuré le rôle, vous apprendrez comment utiliser celui-ci dans AWS Management Console,
l'AWS CLI, et l'API.
Dans ce didacticiel, imaginez que le compte Production soit l'emplacement où les applications
dynamiques sont gérées et que le compte Développement est un environnement de test (sandbox)
où les développeurs et les testeurs peuvent tester librement les applications. Dans chaque compte,
les informations de l'application sont stockées dans des compartiments Amazon S3. Vous gérez
des utilisateurs IAM dans le compte Développement, où vous disposez de deux groupes IAM : les
Développeurs et les Testeurs. Les utilisateurs des deux groupes ont des autorisations pour travailler
dans le compte Développement et y accéder aux ressources qui s'y trouvent. De temps à autre,
un développeur doit mettre à jour les applications dynamiques dans le compte Production. Ces
applications sont stockées dans un compartiment Amazon S3 appelé productionapp.
À la fin de ce didacticiel, vous disposerez d'un rôle dans le compte Production (le compte
d'approbation) qui permet aux utilisateurs du compte Développement (le compte approuvé) d'accéder
au compartiment productionapp du compte Production. Les développeurs peuvent se servir du
rôle de l'AWS Management Console pour accéder au compartiment productionapp dans le compte
Production. Ils peuvent également accéder au compartiment à l'aide des appels d'API authentifiés par
les informations d'identification temporaires fournies par le rôle. Les tentatives similaires des testeurs
pour utiliser le rôle échouent.
Ce flux de travail se compose de trois étapes de base.
26
Prérequis
Etape 1 : Créer un rôle (p. 28)
D'abord, vous utilisez AWS Management Console pour établir la confiance entre le compte
Production (numéro d'ID 999999999999) et le compte Développement (numéro d'ID
111111111111) en créant un rôle IAM appelé UpdateApp. Lorsque vous créez le rôle, vous
définissez le compte Développement en tant qu'entité approuvée et spécifier une stratégie
d'autorisations qui autorise les utilisateurs à mettre à jour le compartiment productionapp.
Étape 2 : Accorder l'accès au rôle (p. 30)
Dans cette étape du didacticiel, vous modifiez la stratégie de groupe IAM de sorte que l'accès des
testeurs au rôle UpdateAPP soit refusé. Du fait que les testeurs ont un accès PowerUser dans ce
scénario, nous devons refuser explicitement la capacité d'utiliser le rôle.
Étape 3 : Tester l'accès en changeant de rôles (p. 32)
Enfin, en tant que développeur, vous utilisez le rôle UpdateAPP pour mettre à jour le
compartiment productionapp dans le compte Production. Vous voyez comment accéder au rôle
à l'aide de la console AWS, de l'AWS CLI ou de l'API.
Prérequis
Le didacticiel présume que vous avez déjà ce qui suit en place :
• Deux comptes AWS distincts que vous pouvez utiliser, l'un pour représenter le compte
Développement, et l'autre pour représenter le compte Production.
• Les utilisateurs et les groupes du compte Développement créés et configurés comme suit :
Utilisateur
Groupe
Autorisations
David
Développeurs
Theresa
Testeurs
Les deux utilisateurs peuvent se connecter et utiliser AWS
Management Console. dans le compte Development.
• Vous n'avez pas besoin d'avoir des utilisateurs ou des groupes créés dans le compte Production.
27
Etape 1 : Créer un rôle
• Un compartiment Amazon S3 créé dans le compte Production. Nous l'appelons ProductionApp
dans ce didacticiel, mais du fait que les noms de compartiment S3 doivent être globalement uniques,
vous aurez besoin d'utiliser un compartiment avec un nom différent.
Pour autoriser les utilisateurs d'un compte AWS à accéder aux ressources d'un autre compte AWS,
créez un rôle définissant qui peut y accéder et quelles autorisations il accorde aux utilisateurs qui
basculent vers lui.
Dans cette étape du didacticiel, vous créez le rôle dans le compte Production et spécifiez le compte
Développement compte entité approuvée. Vous limitez également les autorisations du rôle à un accès
en lecture et en écriture seules au compartiment productionapp. Toute personne ayant autorisation
d'utiliser le rôle peut lire et écrire dans le compartiment productionapp.
Avant de créer un rôle, vous avez besoin de l'ID de compte du compte AWS Développement. L'ID de
compte est un identifiant unique attribué à chaque compte AWS.
Pour obtenir l'ID du compte AWS Développement
1.
Accédez au site web Amazon Web Services, arrêtez-vous sur Mon compte, choisissez AWS
Management Console, puis connectez-vous à AWS Management Console pour le compte
Développement.
2.
Dans la barre de navigation, choisissez Support, puis Centre de support. Le Numéro de compte
se situe dans le coin supérieur droit immédiatement sous le menu Support. L'ID de compte est
un numéro à 12 chiffres. Dans ce scenario, imaginons que l'ID du compte Développement est
111111111111. Toutefois, vous devez utiliser un ID de compte valide si vous reproduisez le
scenario dans votre environnement de test.
Pour créer un rôle dans le compte Production qui peut être utilisé par le compte
Développement
1.
Connectez-vous à AWS Management Console en tant qu'administrateur du compte Production, et
ouvrez la console IAM.
2.
Avant de créer le rôle, préparez la stratégie gérée qui définit les autorisations qu'exige le rôle.
Vous attachez cette stratégie au rôle dans une étape ultérieure.
Vous devez définir l'accès en lecture et en écriture au compartiment productionapp. Bien
que AWS fournisse des stratégies gérées Amazon S3, il n'en existe pas qui offre un accès en
lecture et en écriture à un seul compartiment Amazon S3 afin que vous puissiez créer votre propre
stratégie à la place.
Dans le volet de navigation à gauche, choisissez Policies, puis Create Policy.
3.
En regard de Create Your Own Policy, choisissez Select.
4.
Entrez read-write-app-bucket comme nom de stratégie.
5.
Ajoutez les autorisations suivantes au document de stratégie. Assurez-vous de remplacer l'ARN
de la ressource (arn:aws:s3:::productionapp) par le vrai adapté à votre compartiment S3.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"
28
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation"
],
"Resource": "arn:aws:s3:::productionapp"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::productionapp/*"
}
]
}
L'autorisation ListBucket permet aux utilisateurs d'afficher des objets dans le compartiment
productionapp. Les autorisations GetObject, PutObject, DeleteObject permettent
aux utilisateurs d'afficher, de mettre à jour et de supprimer le contenu du compartiment
productionapp.
6.
Choisissez Create Policy.
La nouvelle stratégie apparaît dans la liste des stratégies gérées.
7.
Dans le volet de navigation gauche, choisissez Roles, puis Create New Role.
8.
Tapez UpdateAPP comme nom du rôle, puis choisissez Next Step.
9.
Sous Select Role Type, choisissez Role for Cross-Account Access, et puis Select à côté de
Provide access between AWS accounts you own.
10. Saisissez l'ID du compte Développement.
Pour ce didacticiel, nous utilisons l'exemple d'ID de compte 111111111111 pour le compte
Développement. Vous devez utiliser un ID de compte valide. Si vous utilisez un ID de compte non
valide, comme 111111111111, IAM ne vous laissera pas créer de rôle.
Pour le moment, les utilisateurs ne sont pas obligés d'avoir une authentification multi-facteurs
(MFA) pour assumer le rôle, donc ne cochez pas cette option. Si vous sélectionnez cette option
dans votre environnement, seuls les utilisateurs qui se connectent à l'aide d'un mot de passe
unique (OTP) à un programme ou un périphérique d'authentification multi-facteurs peuvent
assumer le rôle. Notez que l'utilisateur ne peut pas entre l'OTP au moment du changement
de rôle. Il doit être entré lorsque l'utilisateur se connecte pour la première fois. Pour de plus
amples informations, veuillez consulter Utilisation de Multi-Factor Authentication (MFA) dans
AWS (p. 93)
11. Choisissez Next Step pour configurer les autorisations associées au rôle.
12. Sélectionnez la zone située en regard de la stratégie que vous avez créée précédemment.
Tip
Pour Filter, choisissez Customer Managed Policies pour filtrer la liste afin d'inclure
uniquement les stratégies que vous avez créées. Cela masque les stratégies créées par
AWS et permet de rechercher plus facilement celle que vous recherchez.
Choisissez ensuite Next Step.
29
Étape 2 : Accorder l'accès au rôle
13. La page de révision apparaît pour que vous confirmiez les paramètres pour le rôle avant qu'il ne
soit créé. Sur cette page, il est très important que vous notiez le lien que vous pouvez envoyer
aux utilisateurs qui ont besoin d'utiliser ce rôle. Les utilisateurs qui choisissent le lien accèdent
directement à la page Switch Role avec les champs Account ID et Role Name déjà remplis. Vous
pouvez également consulter ce lien ultérieurement sur la page Role Summary pour n'importe quel
rôle entre comptes.
Note
La console IAM met en cache les cinq derniers rôles que vous utilisez afin de faciliter
leur sélection ultérieurement. Si vos utilisateurs requièrent plus de cinq rôles, envisagez
d'utiliser les solutions suivantes pour faciliter l'accès :
• Si seuls quelques utilisateurs changent de rôle, suggérez-leur de créer un marque-page
pour les liens que vous leur envoyez.
• Si de nombreux utilisateurs changent de rôle, envisagez de créer un emplacement
central tel qu'une page web contenant tous les liens nécessaires aux utilisateurs.
Le format du lien est le suivant :
https://signin.aws.amazon.com/switchrole?
account=ACCOUNT_NUMBER&roleName=ROLE_NAME&displayName=DISPLAYNAME
14. Après avoir procédé à la révision du rôle, choisissez Create Role.
Le rôle UpdateAPP est s'affiche dans la liste des rôles.
À présent, vous devez obtenir l'Amazon Resource Name (ARN) du rôle, qui est un identifiant unique
du rôle. Lorsque vous modifiez la stratégie du groupe Développeurs et Testeurs, vous devez spécifier
l'ARN du rôle afin d'accorder ou de refuser des autorisations.
Pour obtenir l'ARN d'UpdateAPP
1.
Dans le volet de navigation de la console IAM, choisissez Roles.
2.
Dans la liste des rôles, choisissez le rôle UpdateAPP.
3.
Dans la section Summary du volet des détails copiez la valeur de Role ARN.
Le compte Production a pour ID de compte 999999999999, l'ARN du rôle ARN est donc
arn:aws:iam::999999999999:role/UpdateAPP. Assurez-vous de fournir l'ID de compte
AWS réel pour votre compte « production ».
À ce stade, vous avez établi une relation de confiance entre les comptes Production et Développement
en créant un rôle dans le compte Production qui identifie le compte Développement en tant que
mandataire approuvé. Vous avez également défini ce que les utilisateurs qui basculent vers le rôle
UpdateApp peuvent faire.
Ensuite, modifiez les autorisations les groupes.
À ce stade, les membres du groupe Testeurs et Développeurs disposent d'autorisations leur
permettant de tester librement des applications dans le compte Développement. Voici la procédure
requise pour ajouter des autorisations visant à autoriser le changement de rôle.
30
Pour modifier le groupe Développeurs afin de les autoriser à basculer vers le rôle UpdateApp
1.
Connectez-vous en tant qu'administrateur dans le compte Développement, et ouvrez la console
IAM.
2.
Choisissez Groups, puis choisissez Developers.
3.
Choisissez l'onglet Permissions, développez la section Inline Policies, puis choisissez Create
Group Policy. S'il existe encore aucune stratégie en ligne, le bouton ne s'affiche pas. À la place,
choisissez le lien situé à la fin de « To create one, click here. »
4.
Choisissez Custom Policy, puis cliquez sur le bouton Select.
5.
Saisissez un nom de stratégie comme allow-assume-S3-role-in-production.
6.
Ajoutez la déclaration de stratégie suivante pour autoriser l'action AssumeRole sur le rôle
UpdateAPP dans le compte Production. Veillez à modifier PRODUCTION-ACCOUNT-ID dans
l'élément Resource pour ajouter l'ID du compte AWS réel du compte Production.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::PRODUCTION-ACCOUNT-ID:role/UpdateAPP"
}
}
L'effet Allow autorise explicitement l'accès du groupe Développeurs au rôle UpdateAPP dans le
compte Production. Tous les développeurs qui essaieront d'accéder au rôle y parviendront.
7.
Choisissez Apply Policy pour ajouter la stratégie au groupe Développeur.
Dans la plupart des environnements, la procédure suivante n'est probablement pas nécessaire. En
revanche, si vous utilisez les autorisations de l'Utilisateur avancé, certains groupes ont peut-être déjà
la capacité de changer de rôles. Les procédures suivantes indiquent comment ajouter une autorisation
« Deny » au groupe Testeurs pour s'assurer qu'ils ne peuvent pas assumer le rôle. Si cette procédure
n'est pas requise dans votre environnement, nous vous recommandons de ne pas l'ajouter. Les
autorisations « Deny » rendent l'ensemble des autorisations plus compliqué à gérer et à comprendre.
Utilisez les autorisations « Deny » uniquement lorsqu'il n'y a pas de meilleure option.
Pour modifier le groupe Testeurs afin de lui refuser l'autorisation d'assumer le rôle UpdateApp
1.
Choisissez Groups, puis choisissez Testers.
2.
Choisissez l'onglet Permissions, développez la section Inline Policies, puis choisissez Create
Group Policy.
3.
Choisissez Custom Policy, puis cliquez sur le bouton Select.
4.
Saisissez un nom de stratégie comme deny-assume-S3-role-in-production.
5.
Ajoutez la déclaration de stratégie suivante pour refuser l'action AssumeRole sur le rôle
UpdateAPP. Veillez à modifier PRODUCTION-ACCOUNT-ID dans l'élément Resource pour ajouter
l'ID du compte AWS réel du compte Production.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Resource": "arn:aws:iam::PRODUCTION-ACCOUNT-ID:role/UpdateAPP"
}
31
Étape 3 : Tester l'accès en changeant de rôles
}
6.
L'effet Deny refuse explicitement l'accès du groupe Testeurs au rôle UpdateAPP dans le compte
Production. Tous les testeurs qui essaieront d'accéder au rôle recevront un message d'accès
refusé.
Choisissez Apply Policy pour ajouter la stratégie au groupe Testeur.
Le groupe Développeurs a maintenant l'autorisation d'utiliser le rôle UpdateAPP dans le compte
Production. Le groupe Testeurs ne peut pas utiliser le rôle UpdateAPP.
Ensuite, vous allez découvrir comment David, un développeur, peut accéder au compartiment
productionapp dans le compte Production à l'aide de l'AWS Management Console, des commandes
de l'AWS CLI et de l'appel d'API AssumeRole.
Après avoir terminé les deux premières étapes de ce didacticiel, vous disposez d'un rôle qui accorde
l'accès à une ressource du compte Production, et d'un groupe dans le compte Développement dont
les utilisateurs sont autorisés à utiliser ce rôle. Le rôle est prêt à être utilisé, et cette étape indique
comment tester le changement pour ce rôle dans AWS Management Console, l'AWS CLI et l'API AWS.
Important
Vous pouvez passer à un rôle uniquement lorsque vous êtes connecté en tant qu'utilisateur
IAM, en tant qu'utilisateur authentifié en externe (p. 148) (SAML (p. 156) ou
OIDC (p. 149)) utilisant déjà un rôle ou lorsqu'il est exécuté depuis une instance Amazon
EC2 attachée à un rôle via son profil d'instance. Il n'est pas possible de passer à un rôle si
vous êtes connecté en tant qu’utilisateur racine du compte AWS.
Changer de rôle à l'aide de l'AWS Management Console
Si David a besoin d'utiliser l'environnement Production dans AWS Management Console, il peut
y parvenir à l'aide de Switch Role. Il indique l'ID de compte ou l'alias et le nom du rôle, et ses
autorisations passent immédiatement à celles autorisées par le rôle. Il peut ensuite utiliser la console
pour travailler avec le compartiment productionapp, mais il ne peut pas utiliser d'autres ressources
de l'environnement Production. Bien que David utilise le rôle, il ne peut pas également utiliser ses
privilèges d'utilisateur avancé dans le compte Développement, car un seul ensemble d'autorisations
peut être effectif à la fois.
Important
Le changement de rôle à l'aide la AWS Management Console fonctionne uniquement avec
les comptes ne nécessitant pas de ExternalID. Si vous accorder l'accès à votre compte à
un tiers et que vous avez besoin d'un ExternalID dans un élément Condition de votre
stratégie d'autorisation, le tiers peut accéder à votre compte uniquement à l'aide de l'API AWS
ou d'un outil de ligne de commande. Le tiers ne peut pas utiliser la console, car elle ne peut
pas fournir de valeur pour ExternalID. Pour plus d'informations sur ce scénario, consultez
Procédure d'utilisation d'un ID externe lorsque vous accordez l'accès à vos ressources AWS à
un tiers (p. 193) et How to Enable Cross-Account Access to the AWS Management Console
dans le Blog sur la sécurité AWS.
David dispose de deux procédures pour accéder à la page Switch Role :
• David reçoit un lien de son administrateur qui dirige vers la configuration Switch Role prédéfinie.
Le lien est fourni à l'administrateur sur la page finale de l'assistant Create Role ou sur la page Role
Summary pour un rôle inter-compte. Si David choisit ce lien, il accède à la page Switch Role avec
32
les champs Account ID et Role Name déjà remplis. Il ne reste plus à David qu'à choisir Switch Role
et il a terminé.
• L'administrateur n'envoie pas le lien dans un e-mail, mais il envoie les valeurs du numéro d'ID de
compte et de nom de rôle. David doit les entrer manuellement pour changer de rôle. La procédure
suivante en est l'illustration.
Pour utiliser un rôle dans AWS Management Console
1.
David se connecte à la console AWS avec son utilisateur normal situé dans le groupe
Développement.
2.
Il choisit le lien que son administrateur lui a envoyé par e-mail. Cela le dirige vers la page Switch
Role avec les informations d'ID de compte ou d'alias et de nom de rôle déjà fournies.
—ou—
Il choisit son nom (menu Identity) dans la barre de navigation, puis sélectionne Switch Role.
Si c'est la première fois que David essaie d'accéder à la page Switch Role de cette manière,
il sera dirigé vers la page Switch Role de mise en route. Cette page fournit des informations
supplémentaires sur la manière dont le changement de rôle peut permettre aux utilisateurs de
gérer des ressources entre des comptes AWS. David doit choisir le bouton Switch Role de cette
page pour effectuer le reste de la procédure.
3.
Ensuite, pour accéder au rôle, David doit entrer manuellement le numéro d'ID (999999999999) et
le nom du rôle (UpdateApp) du compte Production.
De plus, pour lui permettre de savoir quel rôle (et les autorisations associées) est actuellement
actif, il saisit PRODUCTION dans la zone de texte Display Name, sélectionne l'option de couleur
rouge, puis choisit Switch Role.
4.
David peut maintenant utiliser la console Amazon S3 pour travailler avec le compartiment Amazon
S3 ou toute autre ressource pour laquelle le rôle UpdateApp dispose d'autorisations.
5.
Une fois qu'il a terminé son travail, David peut revenir à ses autorisations d'origine en
sélectionnant le nom complet du rôle PRODUCTION dans la barre de navigation, puis en
choisissant Back to David @ 111111111111.
6.
La prochaine fois que David voudra changer de rôle et choisira le menu Identity dans la barre de
navigation, il verra l'entrée PRODUCTION toujours affichée depuis la dernière fois. Il lui suffira de
choisir cette entrée pour changer de rôle immédiatement sans avoir à ressaisir l'ID du compte et le
nom du rôle.
Changer de rôle à l'aide de l'AWS CLI
Si David a besoin d'utiliser l'environnement Production dans la ligne de commande, il peut y parvenir
à l'aide de l'AWS CLI. Il exécute la commande aws sts assume-role et transmet l'ARN du rôle
pour obtenir les informations d'identification de sécurité temporaires de ce rôle. Il configure ensuite
ces informations d'identification dans les variables environnement afin que les commandes AWS CLI
suivantes fonctionnent à l'aide des autorisations du rôles. Bien que David utilise le rôle, il ne peut
pas utiliser ses privilèges d'utilisateur avancé dans le compte Développement, car un seul ensemble
d'autorisations peut être effectif à la fois.
Notez que toutes les clés d'accès et tous les jetons sont des exemples uniquement et ne peuvent pas
être utilisés comme indiqué. Remplacez-les par les valeurs correspondantes de votre environnement
en direct.
Pour utiliser un rôle dans l'AWS CLI
1.
David ouvre la fenêtre d'invite de commande et confirme que le client de l'AWS CLI fonctionne en
exécutant la commande :
33
aws help
Note
L'environnement par défaut de David utilise les informations d'identification de l'utilisateur
David de son profil par défaut qu'il a créé avec la commande aws configure. Pour plus
d'informations, consultez Configuration de l'AWS Command Line Interface dans le manuel
AWS Command Line Interface Guide de l'utilisateur.
2.
Il commence le processus de changement de rôle en exécutant la commande suivante pour
passer au rôle UpdateApp dans le compte Production. Il a obtenu l'ARN du rôle auprès de
l'administrateur ayant créé le rôle. La commande nécessite que vous fournissiez un nom de
session également. Pour cela, vous pouvez choisir n'importe quel texte.
aws sts assume-role --role-arn "arn:aws:iam::999999999999:role/UpdateApp"
--role-session-name "David-ProdUpdate"
David voit ensuite ce qui suit dans la sortie :
{
"Credentials": {
"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
"SessionToken": "AQoDYXdzEGcaEXAMPLE2gsYULo
+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLE
CvSRyh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/
uZEXAMPLECihzFB5lTYLto9dyBgSDy
EXAMPLE9/
g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3Uuysg
sKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP
+4eZScEXAMPLEsnf87e
NhyDHq6ikBQ==",
"Expiration": "2014-12-11T23:08:07Z",
"AccessKeyId": "AKIAIOSFODNN7EXAMPLE"
}
}
3.
David voit les trois éléments dont il a besoin dans la section Credentials de la sortie.
• AccessKeyId
• SecretAccessKey
• SessionToken
David a besoin de configurer l'environnement de l'AWS CLI pour utiliser ces paramètres dans
les appels suivants. Pour plus d'informations sur les différentes manières de configurer vos
informations d'identification, consultez Configuration de l'AWS Command Line Interface. Vous ne
pouvez pas utiliser la commande aws configure, car elle ne prend pas en charge la capture du
jeton de session. En revanche, vous pouvez saisir manuellement les informations dans un fichier
de configuration. Du fait qu'il s'agisse d'informations d'identification temporaires avec un délai
d'expiration relativement court, il est plus facile de les ajouter à environnement de votre session de
ligne de commande actuel.
4.
Pour ajouter les valeurs à l'environnement, David coupe et colle la sortie de l'étape précédente
dans les commandes suivantes. Notez que vous voulez peut-être couper et coller dans un simple
éditeur de texte pour régler les problèmes de retour à la ligne d'adresse dans la sortie du jeton
de session. Elle doit être entrée sous la forme d'une simple chaîne longue, même si elle s'affiche
avec des retours de ligne pour plus de clarté.
34
set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
set AWS_SESSION_TOKEN=AQoDYXdzEGcaEXAMPLE2gsYULo
+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvS
Ryh0FW7jEXAMPLEW+vE/7s1HRpXviG7b+qYf4nD00EXAMPLEmj4wxS04L/
uZEXAMPLECihzFB5lTYLto9dyBgSDyEXA
MPLEKEY9/
g7QRUhZp4bqbEXAMPLENwGPyOj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UusKd
EXAMPLE1TVastU1A0SKFEXAMPLEiywCC/Cs8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP
+4eZScEXAMPLENhykxiHen
DHq6ikBQ==
À ce stade, toutes les commandes seront exécutées avec les autorisations du rôle identifié par
ces informations d'identification. Dans le cas de David, le rôle UpdateApp.
5.
Exécutez la commande pour accéder aux ressources du compte Production. Dans cet exemple,
David répertorie simplement le contenu de son compartiment S3 avec la commande suivante.
aws s3 ls s3://productionapp
Du fait que les noms de compartiments Amazon S3 sont universellement uniques, il n'est pas
nécessaire de spécifier l'ID du compte qui est titulaire du compartiment. Pour accéder aux
ressources d'autres services AWS, consultez la documentation de l'AWS CLI de ce service pour
connaître les commandes et la syntaxe requises pour faire référence à ses ressources.
Utilisation d'AssumeRole dans l'API
Lorsque David a besoin de faire une mise à jour dans le compte Production depuis le code, il
réalise un appel AssumeRole pour prendre le rôle UpdateAPP. L'appel renvoie des informations
d'identification temporaires qu'il peut utiliser pour accéder au compartiment productionapp dans le
compte Production. Avec ces informations d'identification, David peut réaliser des appels d'API afin
de mettre à jour le compartiment productionapp, mais il ne peut pas réaliser des appels d'API pour
accéder aux autres ressources du compte Production, même s'il a des privilèges d'utilisateur avancé
dans le compte Développement.
Pour utiliser un rôle en réalisant des appels d'API
1.
David appelle AssumeRole dans le cadre d'une application. Il doit spécifier l'ARN UpdateAPP :
arn:aws:iam::999999999999:role/UpdateAPP.
La réponse de l'appel AssumeRole inclut les informations d'identification temporaires avec un
AccessKeyId, une SecretAccessKey et un délai d'Expiration qui indique à quel moment les
informations d'identification expireront et vous devrez en demander de nouvelles.
2.
Grâce aux informations d'identification de sécurité temporaires, David réalise un appel
s3:PutObject pour mettre à jour le compartiment productionapp. Il transfère les informations
d'identification à l'appel d'API en tant que paramètre AuthParams. Du fait que les informations
d'identification de rôle temporaires ont uniquement accès en lecture et en écriture au
compartiment productionapp, toute autre action dans le compte Production est refusée.
Pour obtenir un exemple de code (à l'aide Python), consultez Assumer un rôle IAM (API) (p. 225).
35
Ressources connexes
Ressources connexes
• Pour plus d'informations sur les utilisateurs et les groupes IAM, consultez Identités (utilisateurs,
groupes et rôles) (p. 61).
• Pour plus d'informations sur les compartiments Amazon S3, consultez Créer un compartiment avec
Amazon Simple Storage Service dans le Amazon Simple Storage Service Guide de mise en route.
Récapitulatif
Vous avez terminé le didacticiel d'accès aux API entre les comptes. Vous avez créé un rôle pour
établir des relations de confiance avec un autre compte et défini les actions que les entités approuvées
peuvent effectuer. Ensuite, vous avez modifié une stratégie de groupe pour contrôler les utilisateurs
IAM qui peuvent accéder au rôle. Par conséquent, les développeurs du compte Développement
peuvent faire des mises à jour dans le compartiment productionapp du compte Production à l'aide
d'informations d'identification temporaires.
Didacticiel : Créer et attacher votre première
stratégie gérée par le client
Dans ce didacticiel, vous utilisez l'AWS Management Console pour créer une stratégie gérée par le
client (p. 301) que vous attachez à un utilisateur IAM dans votre compte AWS. La stratégie que vous
créez autorise un utilisateur de test IAM à se connecter directement à l'AWS Management Console
avec des autorisations de lecture seule.
Ce flux de travail se compose de trois étapes de base :
Étape 1 : Créer la stratégie (p. 37)
Par défaut, les utilisateurs IAM ne sont autorisés à rien faire. Ils ne peuvent pas accéder à AWS
Management Console ou à gérer les données qu'elle contient sans votre autorisation. Dans cette
étape, vous créez une stratégie gérée par le client qui autorise tous les utilisateurs attachés à se
connecter à l'console.
Étape 2 : Attacher la stratégie (p. 38)
Lorsque vous attachez une stratégie à un utilisateur, celui-ci hérite des autorisations d'accès
associées à cette stratégie. Dans cette étape, vous attachez la nouvelle stratégie à un compte
d'utilisateur de test.
Étape 3 : Test de l'accès utilisateur (p. 38)
Une fois la stratégie attachée, vous pouvez vous connecter en tant que l'utilisateur pour tester la
stratégie.
36
Prérequis
Prérequis
Pour exécuter les étapes de ce didacticiel, vous devez déjà disposer des éléments suivants :
• Un compte AWS auquel vous pouvez vous connecter en tant qu'utilisateur IAM disposant
d'autorisations administratives.
• Un utilisateur IAM de test n'a aucune autorisation attribuée et n'appartient à aucun groupe comme
suit :
Nom utilisateur
Groupe
Autorisations
PolicyUser
<none>
<none>
Étape 1 : Créer la stratégie
Dans cette étape, vous créez une stratégie gérée par le client qui autorise tous les utilisateurs attachés
à se connecter à l'AWS Management Console avec un accès en lecture seule aux données IAM.
Pour créer la stratégie de votre utilisateur de test
1.
Connectez-vous à la console IAM à l'adresse https://console.aws.amazon.com/iam/ avec votre
utilisateur qui dispose d'autorisations d'administrateur.
2.
Dans le volet de navigation, choisissez Policies.
3.
Dans le volet de contenu, choisissez Create Policy.
4.
En regard de Create Your Own Policy, choisissez Select.
5.
Pour Policy Name, tapez UsersReadOnlyAccessToIAMConsole.
6.
Pour Policy Document, collez la stratégie suivante.
{
"Version": "2012-10-17",
"Statement": [ {
"Effect": "Allow",
"Action": [
"iam:GenerateCredentialReport",
"iam:Get*",
"iam:List*"
],
"Resource": "*"
} ]
}
7.
Choisissez Validate Policy et assurez-vous qu'aucune erreur ne s'affiche dans un cadre rouge en
haut de l'écran. Corrigez les erreurs signalées.
Note
Si l'option Use autoformatting est sélectionnée, la stratégie est reformatée chaque fois
que vous ouvrez une stratégie ou choisissez Validate Policy.
8.
Choisissez Create Policy.
Vous disposez à présent d'une stratégie prête à être attachée.
37
Étape 2 : Attacher la stratégie
Étape 2 : Attacher la stratégie
Ensuite, vous attachez la stratégie que vous venez de créer à votre utilisateur IAM de test.
Pour attacher la stratégie à votre utilisateur de test
1.
Dans la console IAM, dans le volet de navigation, choisissez Policies.
2.
En haut de la liste des stratégies, dans la zone de recherche, commencer à taper
UsersReadOnlyAccesstoIAMConsole jusqu'à ce que votre stratégie apparaisse, puis activez la
case à cocher en regard de UsersReadOnlyAccessToIAMConsole dans la liste.
3.
Cliquez sur le bouton Policy Actions, puis choisissez Attach.
4.
Choisissez All Types pour afficher le menu de filtre, puis choisissez Users.
5.
Dans la zone de recherche, commencer à taper PolicyUser jusqu'à ce que l'utilisateur soit
visible dans la liste, puis activez la case à cocher en regard de cet utilisateur dans la liste.
6.
Choisissez Attach Policy.
Vous avez attaché la stratégie à votre utilisateur de test IAM, ce qui signifie que l'utilisateur dispose
maintenant d'un accès en lecture seule à la console IAM.
Étape 3 : Test de l'accès utilisateur
Dans le cadre de ce didacticiel, nous vous recommandons de teste l'accès en vous connectant en tant
que l'utilisateur de test afin d'observer les résultats et vous rendre compte de l'expérience que vivent
vos utilisateurs.
Pour tester l'accès en vous connectant avec votre compte d'utilisateur de test
1.
Connectez-vous à la console IAM via https://console.aws.amazon.com/iam/ avec votre utilisateur
de test PolicyUser.
2.
Parcourez les pages de la console et essayez de créer un nouvel utilisateur ou un nouveau
groupe. Notez que PolicyUser peut afficher des données mais ne peut ni créer, ni modifier des
données IAM existantes.
Ressources connexes
• Créer des utilisateurs IAM (p. 45)
Récapitulatif
Vous avez à présent terminé toutes les étapes nécessaires pour créer et attacher une stratégie gérée
par l'utilisateur. En conséquence, vous pouvez vous connecter à la console IAM avec votre compte de
test et vous avez pu constater par vous-même de l'expérience que vivront vos utilisateurs.
38
Didacticiel : Autoriser les utilisateurs à configurer leurs
propres informations d'identification et paramètres MFA
Didacticiel : Autoriser les utilisateurs à configurer
leurs propres informations d'identification et
paramètres MFA
Vous pouvez permettre à vos utilisateurs de gérer leurs propres périphériques d'authentification
multi-facteurs (MFA) et informations d'identification. La AWS Management Console vous permet de
configurer les informations d'identification (clés d'accès, mots de passe, certificats de signature et clés
publiques SSH) et les périphériques MFA de quelques utilisateurs, mais cette tâche peut vite s'avérer
fastidieuse, à mesure que le nombre d'utilisateurs augmente. En matière de sécurité, les bonnes
pratiques recommandent aux utilisateurs de changer régulièrement leurs mots de passe, d'effectuer
une rotation de leurs clés d'accès, de supprimer ou désactiver les informations d'identification qui ne
sont pas nécessaires, et d'utiliser MFA dans le cadre d'opérations sensibles. L'objectif de ce didacticiel
est de vous montrer comment mettre ces bonnes pratiques en application, sans alourdir la charge de
vos administrateurs.
Ce didacticiel montre comment accorder aux utilisateurs l'accès aux services AWS, mais uniquement
lorsqu'ils s'authentifient à l'aide de MFA. S'ils ne se sont pas authentifiés à l'aide de MFA, toutes les
autorisations leur sont refusées, à l'exception des utilisateurs qui doivent changer leur mot de passe ou
gérer leurs périphériques MFA, y compris pour en mettre un nouveau en service.
Ce flux de travail se compose de trois étapes de base.
Etape 1 : Créer une stratégie pour appliquer l'authentification MFA (p. 40)
Créez une stratégie gérée personnalisée qui interdit toutes les actions excepté quelques API IAM
qui permettent de changer les informations d'identification ou de gérer les périphériques MFA.
Étape 2 : Attacher des stratégies à votre groupe test (p. 42)
Créez un groupe dont les membres disposent d'un accès complet à toutes les actions Amazon
EC2 s'ils s'authentifient à l'aide de MFA, en attachant à la fois la stratégie gérée par AWS appelée
AmazonEC2FullAccess et la stratégie gérée par le client que vous avez créée au cours de la
première étape.
Étape 3 : Test de l'accès utilisateur (p. 43)
Connectez-vous en tant qu'utilisateur test pour vérifier que l'accès à Amazon EC2 est bloqué
jusqu'à ce que l'utilisateur crée un périphérique MFA et s'authentifie à l'aide de celui-ci.
Prérequis
Pour exécuter les étapes de ce didacticiel, vous devez déjà disposer des éléments suivants :
• Un compte AWS auquel vous pouvez vous connecter en tant qu'utilisateur IAM disposant
d'autorisations administratives.
39
Etape 1 : Créer une stratégie pour
appliquer l'authentification MFA
• Votre ID de compte, que vous entrerez dans la stratégie à l'étape 1.
Pour trouver votre ID de compte, dans la barre de navigation située en haut de la page, sélectionnez
Support, puis choisissez Support Center. L'ID de compte se trouve dans le menu Support de cette
page.
• Un utilisateur IAM test qui est membre du groupe suivant :
Créer un compte utilisateur
MFAUser
Créer et configurer un compte de groupe
Désactiver la case à
cocher Generate an
EC2MFA
access key for each
user
MFAUser
Etape 1 : Créer une stratégie pour appliquer
l'authentification MFA
Vous commencez par créer une stratégie gérée personnalisée IAM qui refuse toutes les autorisations,
à l'exception de celles requises par les utilisateurs IAM pour gérer leurs informations d'identification et
périphériques MFA.
1.
2.
Connectez-vous à AWS Management Console en tant qu'utilisateur disposant d'informations
d'identification d'administrateur. Pour respecter les bonnes pratiques IAM, ne vous connectez
pas avec votre compte racine. Pour plus d'informations, consultez Créer des utilisateurs IAM
individuels.
3.
4.
Sur la page Create Policy, choisissez Select en regard de Create Your Own Policy.
5.
Sur la page Review Policy, sous Policy Name, entrez Force_MFA et sous Description, entrez
par exemple Cette stratégie permet aux utilisateurs de gérer leurs propres
mots de passe et périphériques MFA mais rien d'autre, s'ils ne se sont pas
authentifiés à l'aide de MFA.
Dans la fenêtre de l'éditeur Policy Document, collez le texte de stratégie suivant, en remplaçant
toutes les occurrences d'accountid par votre propre ID de compte.
6.
{
"Version": "2012-10-17",
"Statement":[
{
"Sid": "AllowAllUsersToListAccounts",
"Effect": "Allow",
"Action":[
"iam:ListAccountAliases",
"iam:ListUsers",
"iam:GetAccountSummary"
],
"Resource": "*"
},
{
"Sid":
"AllowIndividualUserToSeeAndManageTheirOwnAccountInformation",
"Effect": "Allow",
40
Etape 1 : Créer une stratégie pour
appliquer l'authentification MFA
"Action":[
"iam:ChangePassword",
"iam:CreateAccessKey",
"iam:CreateLoginProfile",
"iam:DeleteAccessKey",
"iam:DeleteLoginProfile",
"iam:GetAccountPasswordPolicy",
"iam:GetLoginProfile",
"iam:ListAccessKeys",
"iam:UpdateAccessKey",
"iam:UpdateLoginProfile",
"iam:ListSigningCertificates",
"iam:DeleteSigningCertificate",
"iam:UpdateSigningCertificate",
"iam:UploadSigningCertificate",
"iam:ListSSHPublicKeys",
"iam:GetSSHPublicKey",
"iam:DeleteSSHPublicKey",
"iam:UpdateSSHPublicKey",
"iam:UploadSSHPublicKey"
],
"Resource": "arn:aws:iam::accountid:user/${aws:username}"
},
{
"Sid": "AllowIndividualUserToListTheirOwnMFA",
"Effect": "Allow",
"Action":[
"iam:ListVirtualMFADevices",
"iam:ListMFADevices"
],
"Resource":[
"arn:aws:iam::accountid:mfa/*",
"arn:aws:iam::accountid:user/${aws:username}"
]
},
{
"Sid": "AllowIndividualUserToManageTheirOwnMFA",
"Effect": "Allow",
"Action":[
"iam:CreateVirtualMFADevice",
"iam:DeactivateMFADevice",
"iam:DeleteVirtualMFADevice",
"iam:RequestSmsMfaRegistration",
"iam:FinalizeSmsMfaRegistration",
"iam:EnableMFADevice",
"iam:ResyncMFADevice"
],
"Resource":[
"arn:aws:iam::accountid:mfa/${aws:username}",
"arn:aws:iam::accountid:user/${aws:username}"
]
},
{
"Sid": "BlockAnyAccessOtherThanAboveUnlessSignedInWithMFA",
"Effect": "Deny",
"NotAction": "iam:*",
"Resource": "*",
"Condition":{ "BoolIfExists":{ "aws:MultiFactorAuthPresent":
"false"}}
41
Étape 2 : Attacher des stratégies à votre groupe test
}
]
}
A quoi sert cette stratégie ?
• La première instruction permet à l'utilisateur de consulter des informations de base concernant
le compte et ses utilisateurs dans la console IAM. Ces trois autorisations doivent se trouver
dans leur propre instruction, car elles ne prennent pas en charge ou n'ont pas besoin de
spécifier d'ARN de ressource particulier et spécifient à la place "Resource" : "*".
• La deuxième instruction permet à l'utilisateur de gérer (notamment de créer et modifier) ses
propres informations d'utilisateur, de mot de passe, de clés d'accès, de certificats de signature,
de clés publiques SSH et de MFA dans la console IAM. L'ARN de ressource limite l'utilisation de
ces autorisations uniquement à l'entité IAM appartenant à l'utilisateur.
• La troisième instruction permet de consulter des informations sur les périphériques MFA et de
savoir lesquels sont associés à l'entité IAM appartenant à l'utilisateur.
• La quatrième déclaration permet à l'utilisateur de mettre en service ou gérer son périphérique
MFA. Notez que les ARN de ressource de la quatrième instruction autorisent uniquement
l'accès à un périphérique MFA ou un utilisateur dont le nom est strictement identique à celui
de l'utilisateur actuellement connecté. Les utilisateurs ne peuvent pas créer ou modifier un
périphérique MFA autre que le leur.
• La dernière déclaration associe "Deny" et "NotAction" pour refuser explicitement toute
action non IAM si l'utilisateur n'est pas authentifié à l'aide de MFA. Si l'utilisateur a été
authentifié à l'aide de MFA, le test "Condition" échoue et la dernière instruction « deny »
n'a aucun effet ; les autres autorisations accordées à l'utilisateur peuvent prendre effet.
Cette dernière instruction garantit que, lorsque l'utilisateur n'est pas connecté à MFA, il ne
peut exécuter que les actions IAM autorisées dans les quatre premières instructions. La
version ...IfExists de l'opérateur Bool s'assure que si l'utilisateur accède à une API
avec des informations d'identification à long terme comme une clé d'accès et que la clé
aws:MultiFactorAuthPresent elle-même manque, la condition renvoie la valeur true,
l'instruction s'applique toujours et l'utilisateur se voit refuser l'accès à l'API non IAM.
7.
Choisissez Validate Policy pour vous assurer que la stratégie est correcte. Rappelez-vous de
remplacer l'espace réservé ci-dessus par votre ID de compte. Une fois la stratégie validée,
choisissez Create Policy.
Étape 2 : Attacher des stratégies à votre groupe test
Vous allez maintenant attacher deux stratégies à votre groupe IAM test. Elles seront utilisées pour
octroyer des autorisations protégées par MFA.
1.
Dans le volet de navigation, choisissez Groups.
2.
Sous Filter, entrez EC2MFA, puis sélectionnez le groupe dans la liste.
3.
Cliquez sur le bouton Group Actions, puis choisissez Attach.
4.
Choisissez l'onglet Permissions, puis cliquez sur Attach Policy.
5.
Sur la page Attach Policy, dans la zone Filter, entrez EC2Full, puis activez la case à cocher
en regard de AmazonEC2FullAccess dans la liste. N'enregistrez pas vos modifications pour le
moment.
6.
Dans la zone Filter, tapez Force, puis activez la case à cocher située en regard de Force_MFA
dans la liste.
7.
Choisissez Attach Policy.
42
Dans cette étape du didacticiel, vous vous connectez en tant qu'utilisateur test afin de vérifier que la
stratégie fonctionne comme prévu.
1.
2.
Connectez-vous à votre compte AWS en tant que MFAUser, avec le mot de passe
affecté dans la section précédente. Utilisez l'URL : https://<alias or account ID
number>.signin.aws.amazon.com/console
Choisissez EC2 pour ouvrir la console Amazon EC2 et vérifier que l'utilisateur ne dispose
d'aucune autorisation.
3.
Dans la barre de navigation, choisissez Services, puis sélectionnez IAM pour ouvrir la console
IAM.
4.
Dans le volet de navigation, choisissez Users, puis sélectionnez l'utilisateur (pas la case à cocher)
MFAUser. Si l'onglet Groups s'affiche par défaut, vous remarquez qu'il indique que vous n'êtes
membre d'aucun groupe. En effet, vous ne disposez (dans ce scénario) d'aucune autorisation
vous permettant de voir votre appartenance à des groupes.
Maintenant, ajoutez un périphérique MFA. Choisissez l'onglet Security Credentials, puis Manage
MFA Device.
5.
6.
Dans ce didacticiel, nous allons utiliser l'authentification MFA basée sur SMS. Choisissez An SMS
MFA device, puis cliquez sur Next Step.
7.
Saisissez votre numéro de téléphone portable, puis choisissez Next Step. Lorsque vous recevez
un sms contenant le code de confirmation sur votre téléphone, tapez le code dans le champ,
choisissez Activate SMS MFA, puis sélectionnez Finish. Vous pouvez désormais utiliser MFA pour
vous connecter en tant que cet utilisateur.
Déconnectez-vous de la console, puis reconnectez-vous en tant que MFAUser. Cette fois, AWS
vous invite à saisir un code MFA à partir de votre téléphone. Lorsque vous recevez le code,
entrez-le dans le champ et choisissez Submit.
Choisissez EC2 pour ouvrir de nouveau la console Amazon EC2. Vous remarquez que toutes
les informations sont maintenant affichées et que vous pouvez effectuer les actions que vous
souhaitez. Si vous accédez à une autre console avec l'identité de cet utilisateur, vous obtiendrez
des messages d'« accès refusé », car les stratégies de ce didacticiel accordent uniquement
l'accès à Amazon EC2.
8.
9.
Ressources connexes
• Utilisation de Multi-Factor Authentication (MFA) dans AWS (p. 93)
• Activation de périphériques MFA (p. 94)
• Utilisation d'appareils MFA avec votre page de connexion IAM (p. 58)
Récapitulatif
Dans ce didacticiel, vous avez appris comment créer une stratégie IAM qui vous permet d'autoriser
uniquement les utilisateurs connectés par le biais d'un périphérique MFA à accéder à des actions. La
stratégie permet à un utilisateur de créer lui-même des mots de passe et clés d'accès et mettre en
service des périphériques MFA. Il peut ainsi créer son propre périphérique MFA s'il n'en possède pas
encore. Cette procédure permet d'optimiser la sécurité globale de votre compte AWS sans pour autant
alourdir la charge des administrateurs, car ils n'ont pas à mettre en service de périphériques MFA pour
vos utilisateurs.
43
Bonnes pratiques
Bonnes pratiques relative à IAM et
cas d'utilisation
Pour tirer profit au maximum de IAM, prenez le temps de découvrir les bonnes pratiques
recommandées. Pour cela, découvrez comment utiliser IAM dans des scénarios concrets afin d'utiliser
les services AWS.
Rubriques
• Bonnes pratiques concernant IAM (p. 44)
• Cas d'utilisation commerciaux (p. 49)
Bonnes pratiques concernant IAM
Pour sécuriser vos ressources AWS, suivez les recommandations suivantes concernant le service
AWS Identity and Access Management (IAM).
Rubriques
• Protéger les clés d'accès (racine) de votre compte AWS (p. 45)
• Créer des utilisateurs IAM (p. 45)
• Utiliser autant que possible des stratégies définies par AWS pour attribuer des
autorisations (p. 46)
• Utiliser des groupes pour attribuer des autorisations à des utilisateurs IAM (p. 46)
• Accorder les privilèges les plus faibles possible (p. 46)
• Configurer une stratégie de mot de passe fiable pour vos utilisateurs (p. 47)
• Activer MFA pour les utilisateurs privilégiés (p. 47)
• Utilisez des rôles pour les applications qui s'exécutent sur des instances Amazon EC2 (p. 47)
• Utilisez des rôles plutôt que le partage d'informations d'identification pour déléguer (p. 48)
• Effectuer une rotation régulière des informations d'identification (p. 48)
• Supprimer les informations d’identification inutiles (p. 48)
• Utiliser les conditions des stratégies pour une plus grande sécurité (p. 49)
• Surveiller l'activité de votre compte AWS (p. 49)
44
Protéger les clés d'accès (racine) de votre compte AWS
• Vidéo de présentation des bonnes pratiques pour IAM (p. 49)
Protéger les clés d'accès (racine) de votre compte
AWS
Vous utilisez une clé d'accès (ID de clé d'accès et secret access key) pour effectuer des demandes par
programmation à AWS. En revanche, n'utilisez pas la clé d'accès (racine) de votre compte AWS. La
clé d'accès de votre compte AWS octroie un accès total à toutes vos ressources pour tous les services
AWS, y compris vos informations de facturation. Vous ne pouvez pas restreindre les autorisations
associées à la clé d’accès de votre compte AWS.
Par conséquent, protégez la clé d'accès de votre compte AWS comme vos numéros de carte de crédit
ou d'autres secrets. Voici quelques moyens d'y parvenir :
• Si vous n'avez pas encore de clé d'accès pour votre compte AWS, n'en créez pas, sauf si c'est
indispensable. À la place, utilisez votre adresse e-mail et mot de passe du compte pour vous
connecter à l'AWS Management Console et créez un utilisateur IAM pour vous-même, doté de
privilèges administratifs, comme expliqué dans la section suivante.
• Si vous avez une clé d'accès pour votre compte AWS, supprimez-la. Si vous devez la conserver,
faites-la tourner (modifiez-la) régulièrement. Pour supprimer ou faire tourner vos clés d'accès de
compte AWS, accédez à la page Security Credentials de l'AWS Management Console et connectezvous avec l'adresse e-mail et le mot de passe de votre compte. Vous pouvez utiliser vos clés d'accès
dans la section Access Keys.
• Ne communiquez jamais le mot de passe de votre compte AWS ou vos clés d'accès à quiconque.
Les sections restantes de ce document vous expliquent les différentes manières d'éviter de
communiquer les informations d'identification de votre compte avec d'autres utilisateurs et de les
intégrer à une application.
• Utilisez un mot de passe fiable pour protéger l'accès au niveau du compte à l'AWS Management
Console. Pour plus d'informations sur la gestion du mot de passe de votre compte AWS, consultez
Modification du mot de passe (« racine ») du compte AWS (p. 78).
• Activez l'authentification multi-facteurs (MFA) AWS sur votre compte AWS. Pour de plus
amples informations, veuillez consulter Utilisation de Multi-Factor Authentication (MFA) dans
AWS (p. 93).
Créer des utilisateurs IAM
N'utilisez pas vos informations d'identification de compte racine AWS pour accéder à AWS et ne
communiquez vos informations d'identification à personne. À la place, créez des utilisateurs individuels
pour tous ceux qui ont besoin d'accéder à votre compte AWS. Créez un utilisateur IAM pour vousmême également, accordez-lui des privilèges d'administrateur et utilisez-le lorsque vous utilisez IAM.
Pour plus d'informations sur la procédure à utiliser, consultez Création de votre premier utilisateur
administrateur et groupe IAM (p. 15).
En créant des utilisateurs IAM individuels pour les personnes accédant à votre compte, vous pouvez
attribuer à chaque utilisateur IAM un jeu d'informations d'identification unique. Vous pouvez également
accorder des autorisations différentes à chaque utilisateur IAM. Au besoin, vous pouvez modifier ou
révoquer les autorisations d'un utilisateur IAM à tout moment. (Si vous communiquez vos informations
d'identification racines AWS, il peut être difficile de les révoquer et il est impossible de restreindre leurs
autorisations.)
Note
Avant de définir des autorisations pour des utilisateurs IAM individuels, lisez le point suivant
concernant les groupes.
45
Utiliser autant que possible des stratégies
définies par AWS pour attribuer des autorisations
Utiliser autant que possible des stratégies définies
par AWS pour attribuer des autorisations
Nous vous recommandons d'utiliser autant que possible les stratégies gérées qui sont créées
et entretenues par AWS pour accorder des autorisations. Un avantage clé de l'utilisation de ces
stratégies est qu’elles sont gérées et mises à jour par AWS au fur et à mesure que de nouveaux
services ou de nouvelles API sont ajoutés.
Les stratégies gérées par AWS sont conçues pour prendre en charge les tâches courantes.
Elles offrent généralement l'accès à un seul service ou à un ensemble limité d'actions. Pour plus
d'informations sur les stratégies gérées par AWS, consultez Stratégies gérées par AWS (p. 300).
Les stratégies gérées par AWS pour les fonctions professionnelles peuvent couvrir plusieurs services
et s'aligner sur les tâches courantes du secteur de l'informatique. Pour obtenir la liste et la description
des stratégies de fonctions professionnelles, consultez la page Stratégies gérées par AWS pour les
activités professionnelles (p. 304).
Utiliser des groupes pour attribuer des autorisations
à des utilisateurs IAM
Au lieu de définir des autorisations pour des utilisateurs IAM individuels, il est souvent plus pratique de
créer des groupes en fonction des tâches (administrateurs, développeurs, comptabilité, etc.), de définir
les autorisations correspondant à chaque groupe, puis d'attribuer des utilisateurs IAM à ces groupes.
Tous les utilisateurs d'un groupe IAM héritent des autorisations attribuées au groupe. Ainsi, vous
pouvez apporter des modifications pour tous les membres d'un groupe à un seul endroit. À mesure que
les personnes évoluent au sein de votre entreprise, il vous suffit de modifier le groupe IAM auquel les
utilisateurs IAM appartiennent.
Pour plus d'informations, consultez les ressources suivantes :
• Création de votre premier utilisateur administrateur et groupe IAM (p. 15)
• Gestion des groupes IAM (p. 136)
Accorder les privilèges les plus faibles possible
Lorsque vous créez des stratégies IAM, suivez le conseil de sécurité standard du moindre privilège,
principe selon lequel il ne faut accorder que les autorisations requises pour une seule tâche.
Déterminez les tâches que les utilisateurs doivent effectuer et élaborez des stratégies leur permettant
de réaliser uniquement ces tâches.
Il est plus sûr de commencer avec un jeu d'autorisations minimal et d'accorder des autorisations
supplémentaires au besoin, plutôt que de commencer avec des autorisations trop permissives et
d'essayer de les restreindre plus tard.
Pour définir le jeu d'autorisations adapté, il est nécessaire d'étudier ce qu'une tâche spécifique
nécessite, les actions prises en charge par un service particulier et les autorisations nécessaires pour
les effectuer.
Pour cela, l'onglet Access Advisor s'avère utile. Il est disponible sur la page Summary de la console
IAM chaque fois que vous examinez un utilisateur, un groupe, un rôle ou une stratégie. Cet onglet
comporte des informations sur les services effectivement utilisés par un utilisateur, un groupe, un rôle
ou quiconque utilise une stratégie. Elles vous permettent d'identifier toute autorisation inutile. Vous
pouvez ainsi peaufiner vos stratégies IAM afin qu'elles respectent au plus près le principe du moindre
46
Configurer une stratégie de mot de
passe fiable pour vos utilisateurs
privilège. Pour de plus amples informations, veuillez consulter Données sur les services consultés en
dernier (p. 342).
• Gestion de l'accès (p. 281)
• Rubriques de stratégies pour des services individuels qui fournissent des exemples de rédaction de
stratégies pour des ressources spécifiques à des services. Exemples:
• Utilisation de IAM pour contrôler l'accès aux ressources DynamoDB dans le manuel Amazon
DynamoDB Guide du développeur
• Utilisation des stratégies de compartiment et des stratégies utilisateur dans le manuel Amazon
Simple Storage Service Manuel du développeur
• Présentation de la liste de contrôle d'accès (ACL) dans le manuel Amazon Simple Storage Service
Manuel du développeur
Configurer une stratégie de mot de passe fiable pour
vos utilisateurs
Si vous autorisez les utilisateurs à modifier leurs propres mots de passe, obligez-les à créer des mots
de passe fiables et à effectuer une rotation régulière de leurs mots de passe. Sur la page Account
Settings de la console IAM, vous pouvez créer une stratégie de mot de passe pour votre compte. Vous
pouvez utiliser la stratégie de mot de passe pour définir les exigences en matière de mot de passe,
comme la longueur minimale, s'il nécessite des caractères non alphabétiques, à quelle fréquence il doit
changer, etc.
Pour de plus amples informations, veuillez consulter Définition d'une stratégie de mot de passe du
compte pour les utilisateurs IAM (p. 79).
Activer MFA pour les utilisateurs privilégiés
Pour plus de sécurité, activez l'authentification multi-facteurs (MFA) pour les utilisateurs IAM
privilégiés (utilisateurs qui sont autorisés à accéder à des ressources sensibles ou à des API). Avec
l'authentification MFA, les utilisateurs disposent d'un périphérique qui génère un code d'authentification
unique (mot de passe unique ou OTP) et ils doivent fournir leurs informations d'identification
normales (comme leur nom utilisateur et leur mot de passe) et l'OTP. Le périphérique MFA peut
être un périphérique physique ou virtuel (par exemple, il peut s'exécuter dans une application sur un
smartphone).
Pour de plus amples informations, veuillez consulter Utilisation de Multi-Factor Authentication (MFA)
dans AWS (p. 93).
Utilisez des rôles pour les applications qui
s'exécutent sur des instances Amazon EC2
Les applications qui s'exécutent sur une instance Amazon EC2 ont besoin d'informations
d'identification pour accéder à d'autres services AWS. Pour fournir des informations d'identification à
l'application de manière sécurisée, utilisez les rôles IAM. Un rôle est une entité qui possède son propre
jeu d'autorisations, mais qui n'est pas ni un utilisateur, ni un groupe. Les rôles ne disposent pas de
leur propre jeu d'informations d'identification à la manière des utilisateurs IAM. Dans le cas de Amazon
EC2, IAM fournit de manière dynamique des informations d'identification temporaires à l'instance EC2
et ces informations d'identification sont changées automatiquement pour vous.
Lorsque vous lancez une instance EC2, vous pouvez spécifier un rôle pour l'instance en tant que
paramètre de lancement. Les applications qui s'exécutent sur l'instance EC2 peuvent utiliser les
47
Utilisez des rôles plutôt que le partage
d'informations d'identification pour déléguer
informations d'identification du rôle lorsqu'elles accèdent aux ressources AWS. Les autorisations du
rôle déterminent ce que l'application est autorisée à faire.
Pour de plus amples informations, veuillez consulter Utilisation d'un rôle IAM pour accorder des
autorisations à des applications s'exécutant sur des instances Amazon EC2 (p. 226).
Utilisez des rôles plutôt que le partage
d'informations d'identification pour déléguer
Vous pouvez avoir besoin d'autoriser des utilisateurs d'un autre compte AWS à accéder à
des ressources de votre compte AWS. Le cas échéant, ne communiquez pas les informations
d'identification de sécurité comme les clés d'accès, entre les comptes. À la place, utilisez des rôles
IAM. Vous pouvez définir un rôle qui spécifie quelles autorisations sont accordées aux utilisateurs IAM
de l'autre compte et les utilisateurs IAM de quels comptes AWS sont autorisés à assumer le rôle.
Pour de plus amples informations, veuillez consulter Termes et concepts relatifs aux rôles (p. 140).
Effectuer une rotation régulière des informations
d'identification
Modifiez vos propres mots de passe et clés d'accès régulièrement et assurez-vous que tous les
utilisateurs IAM de votre compte le font également. Ainsi, si un mot de passe ou une clé d'accès
est compromise sans que vous le sachiez, vous limitez la période pendant laquelle les informations
d'identification peuvent être utilisées pour accéder à vos ressources. Vous pouvez appliquer une
stratégie de mots de passe à votre compte nécessitant que tous vos utilisateurs IAM effectuent la
rotation de leurs mots de passe et vous pouvez en choisir la fréquence.
Pour plus d'informations sur la définition d'un mot de passe dans votre compte, consultez Définition
d'une stratégie de mot de passe du compte pour les utilisateurs IAM (p. 79).
Pour plus d'informations sur la rotation des clés d'accès pour les utilisateurs IAM, consultez Rotation
des clés d'accès (AWS CLI, l'Outils pour Windows PowerShell et l'API AWS) (p. 92).
Supprimer les informations d’identification inutiles
Supprimez les informations d'identification utilisateur IAM (c'est-à-dire le mot de passe et les clés
d'accès) qui ne sont pas nécessaires. Par exemple, un utilisateur IAM utilisé pour une application ne
nécessite pas de mot de passe (les mots de passe sont requis uniquement pour se connecter aux sites
web AWS). De même, si un utilisateur n'utilise pas et n'utilisera jamais les clés d'accès, il n'y a aucune
raison qu'il en ait.
Vous pouvez générer et télécharger un rapport d'informations d'identification qui répertorie tous les
utilisateurs IAM de votre compte et le statut de leurs diverses informations d'identification, notamment
leurs mots de passe, clés d'accès et périphériques MFA. Pour les mots de passe et les clés d'accès, le
rapport d'informations d'identification indique leur dernière date d'utilisation. Les mots de passe et clés
d'accès n'ayant pas été utilisés récemment peuvent être supprimés.
Pour plus d'informations sur les rapports d'informations d'identification IAM, consultez the section
called “Obtention de rapports d'informations d'identification” (p. 123).
En plus d'utiliser des rapports d'informations d'identification, vous pouvez également déterminer quand
un mot de passe ou une clé d'accès a été utilisée pour la dernière fois à l'aide des API IAM suivantes :
• ListUsers (commande AWS CLI : aws iam list-users)
• GetUser (commande AWS CLI : aws iam get-user)
• GetAccessKeyLastUsed (commande AWS CLI : aws iam get-access-key-last-used)
48
Utiliser les conditions des stratégies
pour une plus grande sécurité
Utiliser les conditions des stratégies pour une plus
grande sécurité
Tant que cela est pratique, définissez les conditions dans lesquelles vos stratégies IAM autorisent
l'accès à une ressource. Par exemple, vous pouvez rédigez des conditions visant à spécifier une
plage d'adresses IP autorisées de laquelle doit provenir une demande, vous pouvez spécifier
qu'une demande est autorisée uniquement pendant une plage de dates ou d'heures spécifiée. Vous
pouvez également définir des conditions nécessitant l'utilisation de SSL ou de l'authentification
MFA (authentification multi-facteurs). Par exemple, vous pouvez demander qu'un utilisateur se soit
authentifié avec un périphérique MFA pour l'autoriser à mettre une instance Amazon EC2 hors service.
Pour plus d'informations, consultez Condition (p. 413) dans les Références d'éléments de stratégie
IAM.
Surveiller l'activité de votre compte AWS
Vous pouvez utiliser les fonctions de journalisation de AWS pour déterminer les actions que les
utilisation sont exécutées dans votre compte et les ressources utilisées. Les fichiers journaux
affichent l'heure et la date des actions, l'IP source d'une action, les actions ayant échoué en raison
d'autorisations inadéquates, etc.
Les fonctions de journalisation suivantes sont disponibles dans les services AWS suivants :
• Amazon CloudFront – Journalise les demandes utilisateur reçues par CloudFront. Pour plus
d'informations, consultez Journaux d'accès dans le manuel Amazon CloudFront Manuel du
développeur.
• AWS CloudTrail – Journalise tous les appels d'API AWS et événements associés passés par, ou au
nom d'un compte AWS. Pour plus d'informations, consultez le manuel AWS CloudTrail User Guide.
• Amazon CloudWatch – Surveille vos ressources du cloud AWS et les applications que vous
exécutez sur AWS. Vous pouvez définir des alarmes dans CloudWatch en fonction des métriques
que vous définissez. Pour plus d'informations, consultez le manuel Guide de l'utilisateur Amazon
CloudWatch.
• AWS Config – Fournit des informations historiques détaillées sur la configuration de vos ressources
AWS, notamment vos utilisateurs IAM, groupes, rôles et stratégies. Par exemple, vous pouvez
utiliser AWS Config pour déterminer les autorisations appartenant à un utilisateur ou à un groupe à
un moment spécifique. Pour plus d'informations, consultez le manuel AWS Config Developer Guide.
• Amazon Simple Storage Service (Amazon S3) – Journalise les demandes d'accès à vos
compartiments Amazon S3. Pour plus d'informations, consultez Journalisation des accès au serveur
dans le manuel Amazon Simple Storage Service Manuel du développeur.
Vidéo de présentation des bonnes pratiques pour
IAM
La vidéo suivante inclut une présentation de conférence ayant trait aux bonnes pratiques et fournit des
renseignements supplémentaires sur l'utilisation des fonctions évoquées ici.
AWS re:Invent 2015 - Bonnes pratiques IAM
Cas d'utilisation commerciaux
Pour comprendre comment implémenter le service pour contrôler l'accès à AWS accordé à vos
utilisateurs, vous disposez d'un cas d'utilisation commercial simple de IAM. Celui-ci est décrit dans
49
Configuration initiale d'Example Corp
des termes généraux, sans les mécanismes d'utilisation de l'API de IAM pour obtenir les résultats
escomptés.
Ce cas d'utilisation présente deux manières standard dont une entreprise fictive appelée Example Corp
peut utiliser IAM : la première, avec Amazon Elastic Compute Cloud (Amazon EC2), et la seconde
avec Amazon Simple Storage Service (Amazon S3).
Pour plus d'informations sur l'utilisation de IAM avec d'autres services de AWS, consultez Services
AWS qui fonctionnent avec IAM (p. 394).
Rubriques
• Configuration initiale d'Example Corp (p. 50)
• Cas d'utilisation de IAM avec Amazon EC2 (p. 50)
• Cas d'utilisation de IAM avec Amazon S3 (p. 51)
Configuration initiale d'Example Corp
Joe est le fondateur d'Example Corp. Aux débuts de l'entreprise, il crée son propre compte AWS
et utilise les produits AWS tout seul. Puis il embauche des employés comme développeurs,
administrateurs, testeurs, gestionnaires et administrateurs système.
Joe utilise l'AWS Management Console avec les informations d'identification de sécurité du compte
AWS pour créer un utilisateur pour lui-même appelé Joe et un groupe appelé Admins. Il octroie au
groupe Admins les autorisations nécessaires pour exécuter toutes les actions sur toutes les ressources
du compte AWS (c'est-à-dire des privilèges racines), puis il ajoute l'utilisateur Joe au groupe Admins.
Pour obtenir un guide pas à pas vous permettant de créer un groupe d'administrateurs et un utilisateur
IAM pour vous-même, puis ajouter votre utilisateur au groupe des administrateurs, consultez Création
de votre premier utilisateur administrateur et groupe IAM (p. 15).
À ce stade, Joe peut cesser d'utiliser les informations d'identification du compte AWS pour interagir
avec AWS et commencer à utiliser à la place uniquement ses informations d'identification utilisateur.
Joe crée également un groupe appelé AllUsers afin d'appliquer facilement toutes les autorisations
au niveau du compte à tous les utilisateurs du compte AWS. Il s'ajoute lui-même au groupe. Ensuite,
il crée un groupe appelé Developers, un groupe appelé Testers, un groupe appelé Managers et
un groupe appelé SysAdmins. Il crée des utilisateurs pour chacun de ses employés et place les
utilisateurs dans leurs groupes respectifs. Il les ajoute également au groupe AllUsers. Pour plus
d'informations sur la création de groupes, consultez Création de groupes IAM (p. 135). Pour plus
d'informations sur la création d'utilisateurs, consultez Création d'un utilisateur IAM dans votre compte
AWS (p. 66). Pour plus d'informations sur l'ajout d'utilisateurs à des groupes, consultez Gestion des
groupes IAM (p. 136).
Cas d'utilisation de IAM avec Amazon EC2
Une entreprise comme Example Corp utilise généralement IAM pour interagir avec des services
comme Amazon EC2. Pour comprendre cette partie du cas d'utilisation, vous devez comprendre les
bases de Amazon EC2. Pour plus d'informations sur Amazon EC2, accédez au manuel Amazon EC2
Guide de l'utilisateur pour les instances Linux.
Autorisations Amazon EC2 pour les groupes
Pour fournir un contrôle de « périmètre », Joe attache une stratégie au groupe AllUsers qui refuse les
demandes AWS émises par un utilisateur dont l'adresse IP d'origine est située à l'extérieur du réseau
d'entreprise d'Example Corp.
Chez Example Corp, différents groupes nécessitent des autorisations distinctes :
50
Cas d'utilisation de IAM avec Amazon S3
• Administrateurs système – Nécessitent l'autorisation de créer et de gérer des AMI, des instances,
des instantanés, des volumes, des groupes de sécurité, etc. Joe attache une stratégie au groupe
SysAdmins qui accorde aux membres du groupe l'autorisation d'utiliser toutes les actions Amazon
EC2.
• Développeurs – Nécessitent de pouvoir utiliser des instances uniquement. Joe attache donc une
stratégie au groupe Développeurs qui autorise les développeurs à appeler DescribeInstances,
RunInstances, StopInstances, StartInstances et TerminateInstances.
Note
Amazon EC2 utilise des clés SSH, des mots de passe Windows et des groupes de sécurité
pour contrôler qui a accès au système d'exploitation d'instances Amazon EC2 spécifiques. Il
n'existe aucune méthode dans le système IAM pour autoriser ou refuser l'accès au système
d'exploitation d'une instance spécifique.
• Gestionnaires – Ne doivent pas pouvoir exécuter toutes les actions Amazon EC2, sauf répertorier
les ressources Amazon EC2disponibles actuellement. Par conséquent, Joe attache une stratégie au
groupe Gestionnaires qui les autorise uniquement à appeler des API « Describe » Amazon EC2.
Pour obtenir des exemples de ce à quoi ces stratégies peuvent ressembler, consultez Exemples
de stratégies de gestion de ressources AWS (p. 347) et Utilisation d'AWS Identity and Access
Management dans le manuel Amazon EC2 Guide de l'utilisateur pour les instances Linux.
Changement du rôle de l'utilisateur
À un moment donné, l'un des développeurs, Don, change de rôle et devient gestionnaire. Joe déplace
Don du groupe Développeurs vers le groupe Gestionnaires. Maintenant qu'il fait partie du groupe
Gestionnaires, la capacité de Don à interagir avec des instances Amazon EC2 est limitée. Il ne peut
pas lancer ou démarre des instances. Il ne peut également pas arrêter ou mettre hors service les
instances existantes, même s'il était l'utilisateur qui a lancé ou démarré l'instance. Il peut uniquement
répertorier les instances lancées par les utilisateurs d'Example Corp.
Les entreprises comme Example Corp utilisent aussi généralement IAM avec Amazon S3. Joe a créé
un compartiment Amazon S3 pour l'entreprise appelé example_bucket.
Création d'autres utilisateurs et groupes
En tant qu'employés, Don et Mary ont besoin de créer chacun leurs propres données dans le
compartiment de l'entreprise, ainsi que des données partagée en lecture et en écriture que tous les
développeurs utiliseront. Pour cela, Joe organise logiquement les données dans l'example_bucket à
l'aide d'un schéma de préfixe de clé Amazon S3 présenté dans l'illustration suivante.
/example_bucket
/home
/don
/mary
/share
/developers
/managers
Joe divise l'/example_bucket principal en un ensemble de répertoires de base pour chaque employé
et une zone partagée de groupes de développeurs et de gestionnaires.
À présent, Joe crée un ensemble de stratégies pour attribuer des autorisations aux utilisateurs et aux
groupes :
51
• Accès au répertoire de base de Don – Joe attache une stratégie à Don lui permettant de lire, d'écrire
et de répertorier les objets avec le préfixe de clé Amazon S3 /example_bucket/home/don/
• Accès au répertoire de base de Mary – Joe attache une stratégie à Mary lui permettant de lire,
d'écrire et de répertorier les objets avec le préfixe de clé Amazon S3 /example_bucket/home/
mary/
• Accès au répertoire partagé par le groupe Développeurs – Joe attache une stratégie au groupe qui
permet aux développeurs de lire, d'écrire et de répertorier tous les objets de /example_bucket/
share/developers/
• Accès au répertoire partagé par le groupe Gestionnaires – Joe attache une stratégie au groupe qui
permet aux gestionnaires de lire, d'écrire et de répertorier tous les objets de /example_bucket/
share/managers/
Note
Amazon S3 n'attribue pas automatiquement à un utilisateur qui crée un compartiment ou
un objet l'autorisation d'exécuter d'autres actions sur ce compartiment ou cet objet. Par
conséquent, dans vos stratégies IAM vous devez accorder explicitement l'autorisation aux
utilisateurs d'utiliser les ressources Amazon S3 qu'ils créent.
Pour obtenir des exemples de ce à quoi ces stratégies peuvent ressembler, consultez Contrôle d'accès
dans le manuel Amazon Simple Storage Service Manuel du développeur. Pour plus d'informations sur
la manière dont les stratégies sont évaluées au moment de l'exécution, consultez Logique d'évaluation
de stratégies IAM (p. 441).
Changement du rôle de l'utilisateur
À un moment donné, l'un des développeurs, Don, change de rôle et devient gestionnaire. Nous
supposerons qu'il n'a plus besoin des documents du répertoire share/developers. Joe, en tant
qu'administrateur, déplace Don du groupe Managers vers le groupe Developers. En une simple
réaffectation, Don obtient automatiquement toutes les autorisations accordées au groupe Managers,
mais il en peut plus accéder aux données du répertoire share/developers.
Intégration d'une entreprise tierce
Les organisations travaillent souvent avec des entreprises partenaires, des consultants et des
sous-traitants. Example Corp a un partenaire appelé Widget Company, et une employée de Widget
Company appelé Natalie doit placer des données dans un compartiment à l'intention d'Example Corp.
Joe crée un groupe appelé WidgetCo et une utilisatrice Natalie qu'il ajoute au groupe WidgetCo. Joe
crée également un compartiment spécial appelé example_partner_bucket à l'intention de Natalie.
Joe met à jour les stratégies existantes ou ajoute de nouvelles stratégies pour le partenaire Widget
Company. Par exemple, Joe peut créer une nouvelle stratégie qui refuse aux membres du groupe
WidgetCo de pouvoir exécuter des actions autres que d'écriture. Cette stratégie est nécessaire
uniquement s'il existe une vaste stratégie qui donne à tous les utilisateurs l'accès à un éventail
d'actions Amazon S3.
52
La console IAM et la page de
connexion
L'AWS Management Console permet d'administrer les services AWS sur le web. Vous pouvez vous
connecter à la console pour créer, répertorier et exécuter d'autres tâches avec les services AWS
pour votre compte, comme démarrer et arrêter des instances Amazon EC2 et des bases de données
Amazon RDS, créer des tables Amazon DynamoDB, créer des utilisateurs IAM, etc.
Si vous êtes détenteur d'un compte, vous pouvez connecter directement à la console. Si vous avez
créé des utilisateurs IAM dans votre compte, affecté des mots de passe à ces utilisateurs et accordé
des autorisations aux utilisateurs, ils peuvent se connecter à la console à l'aide d'une URL spécifique à
votre compte.
Cette section fournit des informations sur la page de connexion de l'AWS Management Console sur
laquelle IAM est activé et explique comment créer une URL de connexion unique pour votre compte.
Pour plus d'informations sur la création de mots de passe d'utilisateurs, consultez Gestion des mots de
passe (p. 78).
Note
Rubriques
• La page de connexion d'utilisateur (p. 54)
• La page de connexion au compte racine (p. 54)
• Votre ID de compte AWS et son alias (p. 56)
• Utilisation d'appareils MFA avec votre page de connexion IAM (p. 58)
• Fonction de recherche de la console IAM (p. 58)
53
La page de connexion d'utilisateur
La page de connexion d'utilisateur
Les utilisateurs qui souhaitent utiliser l'AWS Management Console doivent se connecter à votre
compte AWS via une page de connexion spécifique à votre compte. Fournissez à vos utilisateurs l'URL
dont ils ont besoin pour accéder à la page de connexion. L'URL de connexion à votre compte se trouve
sur le tableau de bord de la console IAM.
Important
En plus de fournir aux utilisateurs l'URL de la page de connexion à votre compte, avant que
les utilisateurs se connectent à votre page, vous leur fournir à chacun un mot de passe et, le
cas échéant, un périphérique MFA. Pour obtenir des informations détaillées sur les mots de
passe et les périphériques MFA, consultez Gestion des mots de passe (p. 78) et Utilisation
de Multi-Factor Authentication (MFA) dans AWS (p. 93).
Conseil
Pour localiser votre ID de compte AWS, accédez à la page Informations d'identification de
sécurité AWS. Votre ID de compte se situe dans la section Account Identifiers.
L'URL unique de la page de connexion au compte est créée automatiquement lorsque vous
commencez à utiliser IAM. Vous n'avez rien à faire pour utiliser cette page web de connexion.
https://My_AWS_Account_ID.signin.aws.amazon.com/console/
Vous pouvez personnaliser l'URL de connexion au compte pour votre compte si vous voulez que l'URL
contienne le nom de votre entreprise (ou tout autre identifiant convivial) au lieu du numéro d'ID de
votre compte AWS. Pour plus d'informations sur la personnalisation de l'URL de connexion au compte,
consultez Votre ID de compte AWS et son alias (p. 56).
Conseil
Pour créer un marque-page pour la page de connexion à votre compte dans votre navigateur
web, vous devez entrer manuellement l'URL de connexion de votre compte lors de la création
du marque-page. N'utilisez pas la fonction « Marquer cette page » de votre navigateur web, en
raison des redirections qui cachent l'URL de connexion.
La page de connexion au compte racine
Lorsque les utilisateurs se connecter à votre compte AWS, ils le font via la page de connexion du
compte. Pour leur convenance, cette page de connexion utilise un cookie pour se souvenir du statut
54
Contrôle de l'accès utilisateur
à AWS Management Console
de l'utilisateur afin que la prochaine fois que celui-ci se connecte à l'AWS Management Console, la
console utilise la page de connexion au compte par défaut.
Si vous souhaitez vos connecter à la console avec les informations de connexion de votre compte
racine AWS plutôt que les informations d'identification d'utilisateur IAM, accédez à la page de
connexion du compte et cliquez sur Sign in using root account credentials. La page de connexion
à Amazon Web Services s'affiche pour vous permettre de vous connecter à l'aide des informations
d'identification de votre compte racine AWS.
Contrôle de l'accès utilisateur à AWS
Management Console
Les utilisateurs qui se connectent à votre compte AWS via la page de connexion peuvent accéder à
vos ressources AWS par le biais de AWS Management Console si vous leur en accorder l'autorisation.
La liste suivante illustre les différentes façons d'octroyer aux utilisateurs l'accès aux ressources de
votre compte AWS via AWS Management Console. Elle montre également comment les utilisateurs
peuvent accéder aux autres fonctions d'un compte AWS par le biais du site web d'AWS.
Note
L'utilisation du IAM est gratuite.
Vous créez un mot de passe pour chaque utilisateur devant accéder à AWS Management
Console. Les utilisateurs accèdent à la console via la page de connexion de votre compte AWS
prenant en charge IAM. Pour plus d'informations sur l'accès à la page de connexion, consultez La
console IAM et la page de connexion (p. 53). Pour plus d'informations sur la création de mots
de passe, consultez Gestion des mots de passe (p. 78).
Vos ressources AWS telles que les instances Amazon EC2, les compartiments Amazon S3, etc.
Même si vos utilisateurs ont des mots de passe, ils doivent également disposer d'une autorisation
leur permettant d'accéder à vos ressources AWS. Lorsque vous créez un utilisateur, celui n'a
aucune autorisation par défaut. Pour accorder à vos utilisateurs les autorisations dont ils ont
besoin, vous attachez des stratégies à ceux-ci. Si de nombreux utilisateurs doivent effectuer les
mêmes tâches avec les mêmes ressources, vous pouvez assigner ces utilisateurs à un groupe,
puis attribuer les autorisations à ce groupe. Pour plus d'informations sur la création d'utilisateurs et
de groupes, consultez Identités (utilisateurs, groupes et rôles) (p. 61). Pour plus d'informations
sur l'utilisation de stratégies pour l'octroi d'autorisations, consultez Gestion de l'accès (p. 281).
Forums de discussion AWS
Tout le monde peut lire les messages publiés sur les Forums de discussion AWS. Les utilisateurs
qui souhaitent publier des questions ou des commentaires sur le Forum de discussion AWS
peuvent le faire en utilisant leur nom utilisateur. La première fois qu’un utilisateur publie un
message sur le Forum de discussion AWS, il est invité à entrer un pseudonyme et une adresse email qu'il utilisera uniquement sur les Forums de discussion AWS.
Informations de facturation et d'utilisation de votre compte AWS
Vous pouvez accorder aux utilisateurs l'accès aux informations de facturation et d'utilisation de
votre compte AWS. Pour plus d'informations, consultez Contrôle de l'accès à vos informations de
facturation dans le manuel AWS Billing and Cost Management Guide de l'utilisateur.
Informations de profil de votre compte AWS
Les utilisateurs ne sont pas en mesure d'accéder aux informations de profil de votre compte AWS.
Informations d'identification de sécurité de votre compte AWS
Les utilisateurs ne sont pas en mesure d'accéder aux informations d'identification de sécurité de
votre compte AWS.
55
Votre ID de compte AWS et son alias
Note
Les stratégies IAM contrôlent l'accès, quelle que soit l'interface. Par exemple, vous pouvez
fournir un mot de passe à un utilisateur pour lui permettre d'accéder à AWS Management
Console et les stratégies de cet utilisateur (ou des groupes auxquels il appartient) contrôleront
ce que l'utilisateur peut faire dans AWS Management Console. Vous pouvez également fournir
à l'utilisateur des clés d'accès AWS pour effectuer des appels d'API à destination d'AWS, et
les stratégies contrôleront les actions que l'utilisateur peut appeler via une bibliothèque ou un
client qui utilise ces clés d'accès pour l'authentification.
Votre ID de compte AWS et son alias
Identification de votre ID de compte AWS
Pour trouver votre ID de compte AWS dans AWS Management Console, cliquez sur Support
en haut à droite de la barre de navigation, puis cliquez sur Support Center. Votre ID de
compte actuellement connecté apparaît dans le coin supérieur droit sous le menu Support.
A propos des alias de compte
Si vous voulez que l'URL de votre page de connexion contienne le nom de votre entreprise (ou tout
autre identifiant convivial) au lieu de votre ID de compte AWS, vous pouvez créer un alias pour ce
dernier. Cette section fournit des informations sur les alias de compte AWS et répertorie les actions
d'API que vous pouvez utiliser pour créer un alias.
Par défaut, l'URL de votre page de connexion utilise le format suivant.
https://Your_AWS_Account_ID.signin.aws.amazon.com/console/
Si vous créez un alias de compte AWS pour votre ID de compte AWS, l'URL de votre page de
connexion se présente comme suit.
https://Your_Alias.signin.aws.amazon.com/console/
Note
L'URL d'origine contenant votre ID de compte AWS reste active et vous pouvez continuer à
l'utiliser après avoir créé votre alias de compte AWS.
Conseil
Pour créer un marque-page pour la page de connexion à votre compte dans votre navigateur
web, vous devez entrer manuellement l'URL de connexion lors de la création du marque-page.
N'utilisez pas la fonction « Marquer cette page » de votre navigateur web.
56
Création, suppression et affichage
d'un alias de compte AWS
Création, suppression et affichage d'un alias de
compte AWS
Vous pouvez utiliser AWS Management Console, l'API IAM ou l'interface de ligne de commande pour
créer ou supprimer l'alias de votre compte AWS.
Important
Votre compte AWS ne peut avoir qu'un seul alias. Si vous créez un nouvel alias pour votre
compte AWS, celui-ci remplace l'ancien alias et l'URL contenant l'ancien alias cesse de
fonctionner.
Pour créer ou supprimer un alias de compte
1.
Connectez-vous à la console Identity and Access Management (IAM) à l'adresse https://
console.aws.amazon.com/iam/.
2.
Dans le volet de navigation, sélectionnez Dashboard.
3.
Recherchez le lien de connexion des utilisateurs IAM, puis cliquez sur Customize à droite du lien.
4.
Entrez le nom que vous voulez utiliser pour l'alias, puis cliquez sur Yes, Create.
5.
Pour supprimer l'alias, cliquez sur Customize, puis sur Yes, Delete. L'URL de connexion utilise de
nouveau votre ID de compte AWS.
API ou CLI
Pour créer un alias pour l'URL de votre page de connexion AWS Management Console
• AWS CLI : aws iam create-account-alias
• Outils pour Windows PowerShell : New-IAMAccountAlias
• API AWS : CreateAccountAlias
Pour supprimer un alias d'ID de compte AWS
• AWS CLI :aws iam delete-account-alias
• Outils pour Windows PowerShell : Remove-IAMAccountAlias
• API AWS : DeleteAccountAlias
Pour afficher l'alias de votre ID de compte AWS
• AWS CLI : aws iam list-account-aliases
• Outils pour Windows PowerShell : Get-IAMAccountAlias.html
• API AWS : ListAccountAliases
Note
L'alias de compte doit être unique pour l'ensemble des produits Amazon Web Services. Il ne
peut contenir que des chiffres, des lettres minuscules et des tirets. Pour plus d'informations
57
Utilisation d'appareils MFA avec
votre page de connexion IAM
sur les limitations liées aux entités de compte AWS, consultez Limitations des entités et objets
IAM (p. 391).
Utilisation d'appareils MFA avec votre page de
connexion IAM
Les utilisateurs IAM configurés à l'aide d'appareils d'authentification multi-facteurs (MFA) doivent
utiliser leurs appareils MFA pour se connecter à AWS Management Console. Une fois que l'utilisateur
a tapé son nom utilisateur et son mot de passe, AWS vérifie le compte de l'utilisateur pour déterminer
si MFA est requis pour cet utilisateur. Si tel est le cas, une deuxième page de connexion s'affiche avec
une zone Code MFA dans laquelle l'utilisateur doit entrer le code numérique fourni par un périphérique
jeton MFA ou envoyé sur son appareil mobile sous forme de SMS, selon le type de MFA configuré
pour l'utilisateur.
Si le code MFA est correct, l'utilisateur peut accéder à AWS Management Console. Si le code est
incorrect, l'utilisateur peut refaire une tentative avec un autre code fourni par un périphérique jeton ou
en demandant l'envoi par AWS d'un nouveau code via SMS. Ceci est utile si le premier code n'a pas
été reçu ou ne fonctionne pas.
Il est possible qu'un périphérique jeton MFA ne soit plus synchronisé. Si, après plusieurs tentatives
infructueuses, un utilisateur ne peut toujours pas se connecter à AWS Management Console, il est
invité à synchroniser le périphérique jeton MFA. L'utilisateur peut suivre les instructions affichées à
l’écran pour synchroniser le périphérique jeton MFA. Pour plus d'informations sur la procédure à suivre
pour synchroniser un périphérique pour un utilisateur de votre compte AWS consultez Synchroniser
des périphériques MFA (p. 105).
Fonction de recherche de la console IAM
A mesure que vous explorez IAM Management Console pour gérer différentes ressources IAM, vous
devez rechercher des clés d'accès ou accéder aux ressources IAM profondément imbriquées pour
rechercher les éléments que vous avez besoin d'utiliser. Pour ne pas perdre de temps, utilisez la
page de recherche de la console IAM pour rechercher des clés d'accès associées à votre compte,
des entités IAM (comme des utilisateurs, des groupes, des rôles, des fournisseurs d'identité), des
stratégies par nom et plus encore.
La fonction de rechercher de la console IAM peut rechercher tous les éléments suivants :
• les noms d'entités IAM correspondant à vos mots-clés de recherche (pour des utilisateurs, des
groupes, des rôles, des fournisseurs d'identité et des stratégies)
• les noms de rubriques de la documentation AWS qui correspondent à vos mots-clés de recherche
• les noms de tâches qui correspondent à vos mots-clés de recherche
Chaque ligne des résultats de la recherche est un lien actif. Par exemple, vous pouvez choisir le nom
utilisateur dans le résultat de la recherche, qui vous dirige vers la page détaillée de l'utilisateur. Vous
pouvez également choisir un lien vers une action, par exemple Create user, pour accéder à la page
Create User.
Note
La recherche de clé d'accès nécessite que vous saisissiez l'ID de clé d'accès complet dans la
zone de recherche. Le résultat de la recherche affiche l'utilisateur associé à cette clé. A partir
de cette page, vous pouvez accéder directement à la page de cet utilisateur, d'où vous pouvez
gérer sa clé d'accès.
58
Utilisation de la fonction de recherche de la console IAM
Utilisation de la fonction de recherche de la console
IAM
Utilisez la page Search de la console IAM pour rechercher des éléments associés à ce compte.
Pour rechercher des éléments sur la console IAM
1.
2.
Dans le volet de navigation, choisissez Search.
3.
4.
Dans la zone Search, saisissez vos mots-clés de recherche.
Choisissez un lien dans la liste des résultats de la recherche pour accéder à la partie
correspondante de la console ou de la documentation.
Icônes des résultats de la recherche sur la console
IAM
Les icônes suivantes identifient les types d'éléments renvoyés par une recherche :
Icône
Description
Utilisateurs IAM
Groupes IAM
Rôles IAM
Stratégies IAM
Tâches comme « créer un utilisateur » ou
« attacher une stratégie »
Résultats obtenus avec le mot-clé supprimer
Documentation IAM
Exemples de phrases de recherche
Vous pouvez utiliser les phrases suivantes dans la recherche IAM. Remplacez les termes en italique
par les noms respectifs des utilisateurs, groupes, rôles, clés d'accès, stratégies ou fournisseurs
d'identité IAM que vous souhaitez rechercher.
• user_name ou group_name ou role_name ou policy_name ou identity_provider_name
59
Exemples de phrases de recherche
• access_key
• ajouter l'utilisateur user_name aux groupes ou ajouter des utilisateurs au
groupe group_name
• supprimer l'utilisateur user_name des groupes
• supprimer user_name ou supprimer group_name ou supprimer role_name ou
supprimer policy_name ou supprimer identity_provider_name
• gérer les clés d'accès user_name
• gérer les certificats de serveur user_name
• des utilisateurs
• gérer MFA pour user_name
• gérer le mot de passe de user_name
• créer un rôle
• stratégie de mot de passe
• modifier la stratégie d'approbation du rôle role_name
• afficher le document de stratégie du rôle role_name
• attacher la stratégie à role_name
• créer la stratégie gérée
• créer un utilisateur
• créer un groupe
• attacher la stratégie à group_name
• attacher les entités à policy_name
• détacher les entités à policy_name
• en quoi consiste IAM
• quelle est la marche à suivre pour créer un utilisateur IAM
• comment utiliser la console IAM
• qu'est-ce qu'un utilisateur ou qu'est-ce qu'un groupe ou qu'est-ce qu'une
stratégie ou qu'est-ce qu'un rôle ou qu'est-ce qu'un fournisseur d'identité
60
Utilisateurs IAM
Identités (utilisateurs, groupes et
rôles)
Cette section décrit les identités IAM que vous créez pour fournir de l'authentification aux personnes
et aux processus de votre compte AWS. Cette section décrit également les groupes IAM qui sont
des ensembles d'utilisateurs IAM que vous pouvez gérer en tant qu'unité. Les identités représentent
l'utilisateur et peuvent être authentifiées puis autorisées à exécuter des actions dans AWS. Chacune
d'elles peut être associée à une ou plusieurs stratégies (p. 281) pour déterminer les actions qu'un
utilisateur, un rôle ou le membre d'un groupe peut exécuter avec des ressources AWS et dans quelles
conditions.
Utilisateurs IAM (p. 64)
Un utilisateur (p. 64) IAM est une entité que vous créez dans AWS. L'utilisateur IAM représente
la personne ou le service qui l'utilise pour interagir avec AWS. L'utilisateur IAM est principalement
utilisé pour donner la possibilité aux gens de se connecter à AWS Management Console pour des
tâches interactives et pour faire des demandes programmation aux services AWS à l'aide de l'API ou
CLI. Un utilisateur dans AWS se compose d'un nom, d'un mot de passe, avec lesquels se connecter
dans AWS Management Console et de jusqu'à deux clés d'accès qui peuvent être utilisées avec l'API
ou CLI. Lorsque vous créez un utilisateur IAM, vous lui accordez des autorisations en l'associant
à un groupe auquel sont attachées les stratégies d'autorisation appropriées (recommandé) ou
en lui attachant directement les stratégies. Vous pouvez également cloner les autorisations d'un
utilisateur IAM existant, ce qui permet au nouvel utilisateur de devenir membre des mêmes groupes
automatiquement, tandis que les mêmes stratégies sont attachées.
Groupes IAM (p. 134)
Un groupe (p. 134) IAM est un ensemble d'utilisateurs IAM. Vous pouvez utiliser les groupes pour
spécifier des autorisations pour un ensemble d'utilisateurs, ce qui permet de gérer plus facilement ces
autorisations pour ces utilisateurs. Par exemple, vous pouvez avoir un groupe appelé Administrateurs
et accorder à ce groupe les types d'autorisations dont les administrateurs ont généralement besoin.
Tous les utilisateurs de ce groupe reçoivent automatiquement les autorisations attribuées au groupe.
Si un nouvel utilisateur rejoint votre organisation et doit disposer de privilèges d'administrateur, vous
pouvez lui attribuer les autorisations appropriées en l'ajoutant à ce groupe. De même, si une personne
change de poste dans votre organisation, au lieu de modifier les autorisations de cet utilisateur, vous
pouvez retirer celui-ci de l'ancien groupe et l'ajouter aux nouveaux groupes appropriés. Notez qu'un
groupe n'est pas vraiment une identité, car il ne peut pas être identifié en tant que Principal dans
61
Rôles IAM
une stratégie d'accès. Il s'agit uniquement d'un moyen d'attacher des stratégies à plusieurs utilisateurs
à la fois.
Rôles IAM (p. 140)
Un rôle IAM (p. 140) est très semblable à un utilisateur, car il s'agit d'une identité avec des stratégies
d'autorisation qui déterminent ce que l'identité peut et ne peut pas faire dans AWS. En revanche,
aucune information d'identification (mot de passe ou clés d'accès) n'est associée à celui-ci. Au
lieu d’être associé de manière unique à une personne, un rôle est conçu pour être assumé par
tout utilisateur qui en a besoin. Un utilisateur IAM peut assumer un rôle pour accepter différentes
autorisations temporaires concernant un tâche spécifique. Un rôle peut être attribué à un utilisateur
fédéré (p. 148) qui se connecte à l'aide d'un fournisseur d'identité externe au lieu de IAM. AWS
utilise les informations transmises par le fournisseur d'identité pour déterminer le rôle qui est mappé à
l'utilisateur fédéré.
Informations d’identification temporaires (p. 244)
Les informations d'identification temporaires sont utilisées principalement avec des rôles IAM, mais
il existe également d'autres utilisations. Vous pouvez demander des informations d'identification
temporaires ayant un ensemble d'autorisations plus restreintes que votre utilisateur IAM standard. Cela
vous évite d'effectuer des tâches accidentellement qui ne sont pas autorisées par les informations
d'identification plus restreintes. Les informations d'identification temporaires présentent l'avantage
d'expirer automatiquement après une période définie. Vous contrôlez la durée de validité des
informations d'identification.
Utilisateur « racine » d'un compte (p. 278)
Lorsque vous créez un compte AWS pour la première fois, vous créez une identité de compte (ou
« racine ») que vous utilisez pour vous connecter à AWS. Vous pouvez vous connecter à AWS
Management Console en tant qu'utilisateur racine, c'est-à-dire avec l'adresse e-mail et le mot de passe
que vous fournissez lors de la création du compte. Cette combinaison de votre adresse e-mail et de
votre mot de passe est appelée vos informations d'identification de compte racine.
Lorsque vous vous connectez en tant qu'utilisateur racine, vous avez un accès complet, sans
restriction, à toutes les ressources de votre compte AWS, notamment à vos informations de facturation
et à la fonctionnalité de modification du mot de passe. Ce niveau d'accès est nécessaire lorsque
vous configurez le compte pour la première fois. Cependant, nous vous déconseillons d'utiliser les
informations d'identification du compte racine pour un accès quotidien. Nous vous recommandons en
particulier de ne pas divulguer les informations d'identification de votre compte racine à quiconque, car
cela leur fournirait un accès illimité à votre compte. Il n'est pas possible de restreindre les autorisations
accordées au compte racine. Au lieu de cela, nous vous recommandons vivement de respecter la
bonne pratique qui consiste à avoir recours à l'utilisateur racine uniquement pour créer le premier
utilisateur IAM (p. 45), puis à mettre en sécurité les informations d'identification de l'utilisateur racine.
Quand créer un utilisateur IAM (au lieu d'un rôle)
Du fait qu'un utilisateur IAM est simplement une identité avec des autorisations spécifiques dans votre
compte, vous n'avez pas besoin de créer un utilisateur IAM à chaque occasion pour laquelle des
informations d'identification sont nécessaires. Dans de ombreux cas, vous pouvez utiliser les rôles IAM
et leurs informations d'identification temporaires plutôt que d'utiliser les informations d'identification à
long terme associées à un utilisateur IAM.
62
Quand créer un rôle IAM (au lieu d'un utilisateur)
• Vous avez créé un compte AWS et vous êtes la seule personne qui utilise votre compte.
Il est possible d'utiliser AWS à l'aide des informations d'identification de votre compte racine, mais
nous ne vous le recommandons pas. À la place, nous vous conseillons de créer un utilisateur
IAM pour vous-même et d'utiliser les informations d'identification de cet utilisateur lorsque vous
utilisez AWS. Pour de plus amples informations, veuillez consulter Bonnes pratiques concernant
IAM (p. 44).
• D'autres membres de votre groupe ont besoin d'utiliser votre compte AWS et votre groupe n'emploie
aucun autre mécanisme d'identité.
Créez des utilisateurs IAM pour les personnes qui ont besoin d'accéder à vos ressources AWS,
attribuez les autorisations correspondant à chaque utilisateur et fournissez-leur leurs propres
informations d'identification. Nous vous recommandons vivement de ne jamais partager les
informations d'identification avec plusieurs utilisateurs.
• Vous souhaitez utiliser l'interface de ligne de commande (CLI) avec AWS.
La CLI nécessite des informations d'identification pour pouvoir réaliser des appels avec AWS. Créez
un utilisateur IAM et accordez-lui des autorisations pour exécuter les commandes CLI dont vous
avez besoin. Puis configurez la CLI sur votre ordinateur pour utiliser les informations d'identification
de clé d'accès associées à cet utilisateur IAM.
Quand créer un rôle IAM (au lieu d'un utilisateur)
Créez un rôle IAM dans les situations suivantes :
Vous créez une application qui s'exécute sur une instance Amazon Elastic Compute Cloud (Amazon
EC2) et fait des demandes à AWS.
Ne créez pas d'utilisateur IAM pour transmettre les informations d'identification de l'utilisateur
à l'application ou intégrer les informations d'identification à l'application. À la place, créez un
rôle IAM que vous attachez à l'instance EC2 pour transmettre aux applications qui s'exécutent
sur l'instance des informations d'identification de sécurité temporaires. Ces informations
d'identification disposent des autorisations spécifiées dans les stratégies attachées au rôle. Pour
plus d'informations, consultez Utilisation d'un rôle IAM pour accorder des autorisations à des
applications s'exécutant sur des instances Amazon EC2 (p. 226).
Vous créez une application qui s'exécute sur un téléphone mobile et réalise des appels vers AWS.
Ne créez pas d'utilisateur IAM pour distribuer sa clé d'accès avec l'application. À la place, utilisez
un fournisseur d'identité comme Login with Amazon, Amazon Cognito, Facebook ou Google pour
authentifier les utilisateurs et les mapper à un rôle IAM. L'application utilise le rôle pour obtenir des
informations d'identification de sécurité temporaires qui disposent des autorisations spécifiées par
les stratégies attachées au rôle. Pour plus d'informations, consultez les ressources suivantes :
• Présentation d'Amazon Cognito dans le manuel AWS Mobile SDK pour Android Developer
Guide
• Présentation d'Amazon Cognito dans le manuel AWS Mobile SDK for iOS Developer Guide
• A propos de la fédération d'identité web (p. 149)
Les utilisateurs de votre entreprise sont authentifiés dans votre réseau d'entreprise et souhaitent
pouvoir utiliser AWS sans devoir se reconnecter. Autrement dit, vous souhaitez autoriser les
utilisateurs à se fédérer dans AWS.
Ne créez pas des utilisateurs IAM. Configurez une relation de fédération entre votre système
d'identité d'entreprise et AWS. Vous pouvez effectuer cette opération de deux façons:
• Si le système d'identité de votre entreprise en compatible avec SAML 2.0, vous pouvez établir
une relation de confiance entre le système d'identité de votre entreprise et AWS. Pour de plus
amples informations, veuillez consulter A propos de la fédération SAML 2.0 (p. 156).
• Créez et utilisez un serveur proxy personnalisé qui traduit les identités des utilisateurs de
l'entreprise en rôles IAM qui fournissent des informations d'identification de sécurité AWS
63
Utilisateurs
temporaires. Pour de plus amples informations, veuillez consulter Création d'une URL qui
permet aux utilisateurs fédérés d'accéder à AWS Management Console (Broker de fédération
personnalisé) (p. 178).
Utilisateurs IAM
Un utilisateur IAM est une entité que vous créez dans AWS pour représenter la personne ou le service
qui l'utilise pour interagir avec AWS. Dans AWS, un utilisateur se compose d'un nom et d'informations
d'identification.
Comment AWS identifie un utilisateur IAM
Lorsque vous créez un utilisateur, IAM implémente les éléments suivants pour l'identifier :
• Un « nom convivial » pour l'utilisateur. Il s'agit du nom que vous avez spécifié lors de la création de
l'utilisateur, par exemple Bob ou Alice. Ce sont les noms que vous voyez dans AWS Management
Console.
• Un ARN (Amazon Resource Name) pour l'utilisateur. Vous utilisez l'ARN pour identifier de manière
unique l'utilisateur dans l'ensemble d'AWS, par exemple lorsque vous désignez l'utilisateur en tant
que Principal dans la stratégie IAM d'un compartiment Amazon S3. L'ARN d'un utilisateur IAM
peut se présenter comme suit :
arn:aws:iam::account-ID-without-hyphens:user/Bob
• Un identifiant unique pour l'utilisateur. Cet ID est retourné uniquement lors de la création de
l'utilisateur à l'aide de l'API, des Outils pour Windows PowerShell ou de l'AWS CLI ; il n'est pas
visible dans la console.
Pour plus d'informations sur ces identifiants, consultez Identifiants IAM (p. 387).
Utilisateurs et informations d'identification
Vous pouvez accéder à AWS de différentes façons à l'aide des divers types d'informations
d'identification qui peuvent être associés à un utilisateur :
• Mot de passe de la console (p. 78) : un mot de passe que l'utilisateur peut entrer pour se
connecter à des sessions interactives telles qu'AWS Management Console.
• Clés d'accès (p. 89) : une clé d'accès est la combinaison d'un ID de clé d'accès et d'une clé
d'accès secrète. Vous pouvez en attribuer deux à la fois à un utilisateur. Elles permettent d'effectuer
des appels par programme à AWS lors de l'utilisation de l'API dans le code de programme, ou à une
invite de commande lors de l'utilisation de l'AWS CLI ou des outils AWS pour PowerShell.
• Clés SSH à utiliser avec AWS CodeCommit (p. 127) : une clé publique SSH au format OpenSSH
qui peut être utilisée pour s'authentifier auprès d'AWS CodeCommit.
• Certificats de serveur (p. 129) : certificats SSL/TLS que vous pouvez utiliser pour vous authentifier
auprès de certains services AWS. Nous vous recommandons d'utiliser plutôt AWS Certificate
Manager pour créer et gérer vos certificats.
Par défaut, un nouvel utilisateur IAM ne dispose pas de mot de passe ou de clé d'accès (ni d'ID de clé
d'accès ou de clé d'accès secrète) — il n'a donc aucune information d'identification au départ. Vous
devez créer le type d'informations d'identification d'un utilisateur IAM en fonction des tâches qu'il va
effectuer.
Il est possible d'exploiter les options suivantes pour administrer les mots de passe, clés d'accès et
périphériques MFA :
64
Utilisateurs et autorisations
• Gestion des mots de passe d'utilisateurs IAM (p. 78). Créez et modifiez les mots de passe
permettant d'accéder à AWS Management Console. Définissez une stratégie de mot de passe afin
d'appliquer une complexité minimale pour les mots de passe. Autorisez les utilisateurs à modifier
leurs propres mots de passe.
• Gestion des clés d'accès d'utilisateurs IAM (p. 89). Créez et mettez à jour les clés d'accès afin de
permettre l'accès par programmation aux ressources de votre compte.
• Vous pouvez améliorer la sécurité des informations d'identification de l'utilisateur en activant
l'authentification multi-facteurs (MFA) (p. 93) pour celui-ci. Avec l'authentification MFA, les
utilisateurs doivent fournir à la fois les informations d'identification qui font partie de leur identité
utilisateur (un mot de passe ou une clé d'accès) et un code numérique temporaire qui est généré par
un périphérique matériel ou par une application sur un smartphone ou une tablette, ou envoyé par
AWS sur un appareil mobile capable de recevoir des SMS.
• Recherche de mots de passe et clés d'accès inutilisés (p. 121). Toute personne qui dispose d'un
mot de passe ou de clés d'accès pour votre compte ou un utilisateur IAM de votre compte peut
accéder à vos ressources AWS. En matière de sécurité, les bonnes pratiques consistent à supprimer
les mots de passe et les clés d'accès dont les utilisateurs n'ont plus besoin.
• Téléchargez un rapport d'informations d'identification pour votre compte (p. 123). Vous pouvez
générer et télécharger un rapport d'informations d'identification qui répertorie tous les utilisateurs
IAM de votre compte et le statut de leurs diverses informations d'identification, notamment leurs
mots de passe, clés d'accès et périphériques MFA. Pour les mots de passe et les clés d'accès, le
rapport d'informations d'identification indique leur dernière date d'utilisation.
Utilisateurs et autorisations
Par défaut, un nouvel utilisateur IAM ne dispose d'aucune autorisation (p. 281). L'utilisateur n'est
autorisé à effectuer aucune action AWS et ne peut accéder à aucune ressource AWS. Lorsque vous
configurez des utilisateurs IAM individuels, il est également possible de leur affecter des autorisations
individuellement. Vous pouvez ainsi affecter des autorisations administratives à quelques utilisateurs
et ceux-ci peuvent ensuite gérer vos ressources AWS et même créer et gérer d'autres utilisateurs
IAM. Toutefois, dans la plupart des cas, il est préférable de limiter les autorisations d'un utilisateur aux
tâches (actions AWS) et ressources dont il a besoin pour travailler. Prenons l'exemple d'un utilisateur
nommé Dave. Lorsque vous créez l'utilisateur IAM Dave, vous créez un mot de passe pour celui-ci et
attachez des autorisations à l'utilisateur IAM pour lui permettre de lancer une instance Amazon EC2 et
lire les informations (GET) d'une table de base de données Amazon RDS. Pour les procédures relatives
à la création des utilisateurs et à l'octroi d'informations d'identification initiales, consultez Création d'un
utilisateur IAM dans votre compte AWS (p. 66). Pour les procédures relatives à la modification des
autorisations pour les utilisateurs existants, consultez Modification des autorisations pour un utilisateur
IAM (p. 75). Pour les procédures relatives à la modification des clés d'accès et du mot de passe
de l'utilisateur, consultez Gestion des mots de passe (p. 78) et Gestion des clés d'accès pour les
utilisateurs IAM (p. 89).
Utilisateurs et comptes
Chaque utilisateur IAM est associé à un seul et même compte AWS. Dans la mesure où les utilisateurs
sont définis au sein de votre compte AWS, il n'est pas nécessaire d'enregistrer un mode de paiement
pour ceux-ci dans AWS. Toute activité AWS effectuée par les utilisateurs de votre compte est facturée
à votre compte.
Le nombre d'utilisateurs IAM que peut contenir un compte AWS est limité. Pour de plus amples
informations, veuillez consulter Limitations des entités et objets IAM (p. 391).
Utilisateurs en tant que comptes de service
Un utilisateur IAM ne doit pas nécessairement représenter une personne réelle. Il s'agit d'une simple
identité à laquelle sont associées des informations d'identification et des autorisations. Vous pouvez
65
Ajout d'un utilisateur
créer un utilisateur IAM qui représente une application qui requiert des informations d'identification
pour envoyer des demandes à AWS. En général, ceci est appelé un « compte de service ». Une
application peut avoir son propre compte de service dans votre compte AWS et son propre ensemble
d'autorisations, tout comme les processus disposent de leurs propres comptes de service dans un
système d'exploitation tel que Windows ou Linux.
Création d'un utilisateur IAM dans votre compte
AWS
Vous pouvez créer un ou plusieurs utilisateurs IAM dans votre compte AWS. Il est ainsi possible de
créer un utilisateur IAM lorsqu'une personne rejoint l'organisation ou lorsqu'une nouvelle application
doit effectuer des appels d'API à destination d'AWS.
Rubriques
• Création d'utilisateurs IAM (console) (p. 67)
• Création d'utilisateurs IAM (AWS CLI, Outils pour Windows PowerShell ou API HTTP
IAM) (p. 69)
Pour résumer, le processus de création d'un utilisateur et de sa capacité à effectuer des tâches se
compose des étapes suivantes :
1. Créez l'utilisateur dans AWS Management Console ou à l'aide d'une commande de l'AWS CLI, des
Outils pour Windows PowerShell ou de l'API IAM. Si vous créez l'utilisateur dans AWS Management
Console, les étapes suivantes 1 – 4 sont gérées automatiquement. Si vous créez les utilisateurs par
programme, vous devez exécuter chacune de ces étapes individuellement.
2. Créez les informations d'identification pour l'utilisateur, en fonction du type d'accès dont il a besoin :
• Accès par programme : si l'utilisateur doit effectuer des appels d'API ou utiliser l'AWS CLI ou les
Outils pour Windows PowerShell, créez une clé d'accès (ID de clé d'accès et clé d'accès secrète)
qui lui sera associée.
Accès à l'AWS Management Console : si l'utilisateur a besoin d'accéder aux ressources AWS à
partir de l'AWS Management Console, créez-lui un mot de passe (p. 83).
A titre de bonne pratique, ne créez pas les informations d'identification d'un type d'accès pour un
utilisateur qui n'en aura jamais besoin. Par exemple, pour un utilisateur qui a besoin d'un accès via
l'AWS Management Console seulement, ne créez pas de clés d'accès.
3. Donnez à l'utilisateur les autorisations concernant les tâches requises en l'ajoutant à un ou
plusieurs groupes. Bien que vous puissiez accorder des autorisations en associant des stratégies
d'autorisation IAM directement à l'utilisateur, nous vous recommandons de mettre les utilisateurs
dans les groupes et de gérer les autorisations par le biais des stratégies attachées à ces groupes,
plutôt que directement sur les utilisateurs.
4. Fournissez à l'utilisateur les informations nécessaires à la connexion. Il s'agit notamment du mot de
passe et de l'URL de la page web de connexion au compte sur laquelle l'utilisateur doit entrer ces
informations d'identification. Pour plus d'informations, consultez Comment les utilisateurs IAM se
connectent à votre compte AWS (p. 70).
5. (Facultatif) Configurez multi-factor authentication (MFA) (p. 93) pour l'utilisateur. Dans le cadre
de MFAh, l'utilisateur doit fournir un code à utilisation unique chaque fois qu'il se connecte à l'AWS
Management Console.
6. (Facultatif) Accordez aux utilisateurs les autorisations requises pour gérer leurs propres informations
d'identification. (Par défaut, les utilisateurs ne sont pas autorisés à gérer leurs propres informations
d'identification.) Pour de plus amples informations, veuillez consulter Autorisation des utilisateurs
IAM à modifier leurs propres mots de passe (p. 86).
66
Pour plus d'informations sur les autorisations requises pour créer un utilisateur, consultez Délégation
des autorisations d'administration des utilisateurs, des groupes et des informations d'identification
IAM (p. 285).
Création d'utilisateurs IAM (console)
Pour créer un ou plusieurs utilisateurs IAM à partir de l'AWS Management Console
1.
2.
Dans le volet de navigation, choisissez Users, puis Add user.
3.
Tapez le nom d'utilisateur du nouvel utilisateur. Il s'agit de son nom de connexion pour AWS. Si
vous souhaitez ajouter plusieurs utilisateurs simultanément, choisissez Add another user pour
chaque utilisateur supplémentaire et tapez son nom d'utilisateur. Vous pouvez ajouter jusqu'à
10 utilisateurs à la fois.
Note
Les noms d'utilisateur peuvent combiner jusqu'à 64 lettres, chiffres et caractères
suivants : plus (+), égal (=), virgule (,), point (.), arobase (@) et tiret (-). Les noms doivent
être uniques dans un compte. Ils ne sont pas sensibles à la casse. Par exemple, vous
ne pouvez pas créer deux utilisateurs nommés TESTUSER et testuser. Pour plus
d'informations sur les limitations liées aux entités IAM, consultez Limitations des entités et
objets IAM (p. 391).
4.
Sélectionnez le type d'accès dont disposera cet ensemble d'utilisateurs. Vous pouvez sélectionner
un accès par programme aux API, à l'AWS CLI et aux Outils pour Windows PowerShell, un accès
à l'AWS Management Console, ou les deux.
• Sélectionnez Programmatic access si les utilisateurs ont besoin d'accéder à l'API, à l'AWS
CLI ou aux Outils pour Windows PowerShell. Cela crée une clé d'accès pour chaque nouvel
utilisateur. Vous pouvez afficher ou télécharger les clés d'accès lorsque vous accédez à la page
Final.
• Sélectionnez AWS Management Console access si les utilisateurs ont besoin d'accéder à l'AWS
Management Console. Cela crée un mot de passe pour chaque nouvel utilisateur.
1.
Pour Console password type, choisissez l'une des options suivantes :
• Autogenerated password. Chaque utilisateur obtient un mot de passe généré de façon
aléatoire qui correspond à la stratégie de mot de passe actuelle en vigueur (le cas
échéant). Vous pouvez afficher ou télécharger les mots de passe lorsque vous accédez à
la page Final.
• Custom password. Chaque utilisateur se voit attribuer le mot de passe que vous tapez
dans la zone.
2.
(Facultatif) Nous vous conseillons de choisir Require password reset afin d'obliger les
utilisateurs à changer leur mot de passe lors de leur première connexion.
67
Note
Si vous n'avez pas activé le paramètre de stratégie de mot de passe sur tout le
compte Allow users to change their own password, la sélection de l'option Require
password reset attache automatiquement une stratégie gérée AWS nommée
IAMUserChangePassword aux nouveaux utilisateurs afin de leur accorder
l'autorisation de modifier leurs propres mots de passe.
5.
Choisissez Next: Permissions.
6.
Sur la page Set permissions, spécifiez la façon dont vous souhaitez attribuer des autorisations à
cet ensemble de nouveaux utilisateurs. Choisissez l'une des trois options suivantes :
• Add user to group. Choisissez cette option si vous avez des groupes de stratégies d'autorisation
appropriés qui ont déjà été créés et si vous souhaitez attribuer les utilisateurs à ces groupes.
IAM affiche une liste de tous les groupes actuellement définis, ainsi que les stratégies
attachées. Vous pouvez sélectionner un ou plusieurs groupes existants, ou choisir Create group
pour créer un groupe. Pour plus d'informations, consultez Modification des autorisations pour un
utilisateur IAM (p. 75).
• Copy permissions from existing user. Choisissez cette option pour copier toutes les
appartenances au groupe, les stratégies gérées attachées et les stratégies en ligne intégrées
d'un utilisateur existant dans le profil des nouveaux utilisateurs. IAM affiche une liste des
utilisateurs actuellement définis. Sélectionnez celui dont les autorisations correspondent le
plus aux besoins de vos nouveaux utilisateurs. Chaque nouvel utilisateur obtient la même
appartenance de groupe et les mêmes stratégies attachées que l'utilisateur sélectionné.
• Attach existing policies to user directly Choisissez cette option pour sélectionner des stratégies
gérées existantes ou pour créer des stratégies gérées qui sont attachées aux nouveaux
utilisateurs. IAM affiche une liste des stratégies gérées actuellement définies par le client et
par AWS. Sélectionnez les stratégies que vous souhaitez attacher aux nouveaux utilisateurs
ou choisissez Create policy pour créer une toute nouvelle stratégie. Pour plus d'informations,
consultez l'étape 4 de la procédure Créer une stratégie (p. 321).
7.
Choisissez Next: Review pour afficher tous les choix que vous avez faits jusqu'à présent. Une fois
que vous êtes prêt à continuer, choisissez Create user.
8.
Pour afficher les clés d'accès des utilisateurs (ID de clé d'accès et clés d'accès secrètes),
choisissez Show à côté de chaque mot de passe et clé d'accès secrète que vous voulez voir.
Pour enregistrer les clés d'accès, choisissez Download .csv, puis enregistrez le fichier dans un
emplacement sûr sur votre ordinateur.
Important
C'est votre seule occasion de visualiser ou télécharger les clés d'accès secrètes, et vous
devez fournir ces informations à vos utilisateurs avant de pouvoir utiliser l'API d'AWS.
Enregistrez les nouveaux ID de clé d'accès et clé d'accès secrète de l'utilisateur dans
un endroit sûr et sécurisé. Vous ne pourrez pas accéder aux clés d'accès secrètes à
nouveau après cette étape.
9.
Fournissez à chaque utilisateur ses informations d'identification. Sur la page finale, vous pouvez
choisir Send email en regard de chaque utilisateur. Votre client de messagerie local s'ouvre avec
un modèle que vous pouvez personnaliser et envoyer. Le modèle d'e-mail inclut les informations
suivantes pour chaque utilisateur :
• Nom utilisateur
• URL de la page web de connexion au compte. Utilisez l'exemple suivant, en remplaçant l'ID et
l'alias de compte comme approprié :
68
https://AWS-account-ID or alias.signin.aws.amazon.com/console
Pour de plus amples informations, veuillez consulter Comment les utilisateurs IAM se connectent
à votre compte AWS (p. 70).
Important
Le mot de passe de l'utilisateur n'est pas inclus dans l'e-mail généré. Vous devez les
fournir au client d'une manière conforme aux normes de sécurité de votre organisation.
10. (Facultatif) Accordez aux utilisateurs l'autorisation requise pour gérer leurs propres informations
d'identification. Pour de plus amples informations, veuillez consulter Autoriser les utilisateurs à
gérer leurs propres mots de passe, clés d'accès et clés SSH (p. 288).
Création d'utilisateurs IAM (AWS CLI, Outils pour Windows
PowerShell ou API HTTP IAM)
Pour créer un utilisateur IAM à partir de l'AWS CLI, des Outils pour Windows PowerShell ou de
l'API HTTP IAM
1.
Créez un utilisateur.
• AWS CLI : aws iam create-user
• Outils pour Windows PowerShell : New-IAMUser
• API IAM : CreateUser
2.
(Facultatif) Donnez à utilisateur l'accès à l'AWS Management Console. Un mot de passe est
requis. Vous devez également fournir à l'utilisateur l'URL de la page de connexion à votre
compte. (p. 70)
• AWS CLI : aws iam create-login-profile
• Outils pour Windows PowerShell : New-IAMLoginProfile
• IAM API : CreateLoginProfile
3.
(Facultatif) Donnez à l'utilisateur à un accès par programme. Cela nécessite des clés d'accès.
• AWS CLI : aws iam create-access-key
• Outils pour Windows PowerShell : New-IAMAccessKey
• API IAM : CreateAccessKey
Important
C'est votre seule occasion de visualiser ou télécharger les clés d'accès secrètes, et
vous devez fournir ces informations à vos utilisateurs avant de pouvoir utiliser l'API
d'AWS. Enregistrez les nouveaux ID de clé d'accès et clé d'accès secrète de l'utilisateur
dans un endroit sûr et sécurisé. Vous ne pourrez pas accéder aux clés d'accès secrètes
à nouveau après cette étape.
4.
Ajoutez l'utilisateur à un ou plusieurs groupes. Les stratégies attachées aux groupes que vous
spécifiez doivent accorder les autorisations appropriées à l'utilisateur.
• AWS CLI : aws iam add-user-to-group
• Outils pour Windows PowerShell : Add-IAMUserToGroup
• API IAM : AddUserToGroup
69
5.
Comment les utilisateurs IAM se
connectent à votre compte AWS
(facultatif) Attachez une stratégie à l'utilisateur afin de définir ses autorisations. Remarque : Nous
vous recommandons de gérer les autorisations d'un utilisateur en l'ajoutant à un groupe, puis en
attachant une stratégie au groupe plutôt que directement au niveau de l'utilisateur.
• AWS CLI : aws iam attach-user-policy
• Outils pour Windows PowerShell : Register-IAMUserPolicy
• API IAM : AttachUserPolicy
6.
(Facultatif) Accordez à l'utilisateur l'autorisation requise pour gérer ses propres informations
d'identification. Pour de plus amples informations, veuillez consulter Autoriser les utilisateurs à
gérer leurs propres mots de passe, clés d'accès et clés SSH (p. 288).
Comment les utilisateurs IAM se connectent à votre
compte AWS
Une fois que vous avez créé des utilisateurs d'IAM et des mots de passe pour chacun d'entre eux, les
utilisateurs peuvent se connecter à la AWS Management Console pour votre compte AWS avec une
URL spéciale.
Par défaut, l'URL de connexion pour votre compte contient votre ID de compte. Vous pouvez créer
une URL de connexion unique pour votre compte afin que l'URL contienne un nom au lieu d'un ID
de compte. Pour de plus amples informations, veuillez consulter Votre ID de compte AWS et son
alias (p. 56).
Le point de terminaison de la connexion suit ce modèle :
https://AWS-account-ID-or-alias.signin.aws.amazon.com/console
L'URL de connexion à un compte se trouve sur le tableau de bord de la console IAM.
Conseil
Pour créer un marque-page pour la page unique de connexion à votre compte dans votre
navigateur Web, vous devez entrer manuellement l'URL de connexion de votre compte lors
de la création du marque-page. N'utilisez pas la fonction « Marquer cette page » de votre
navigateur web.
Les utilisateurs d'IAM de votre compte ont accès uniquement aux ressources AWS que vous
spécifiez dans la stratégie associée à l'utilisateur ou à un groupe IAM auquel l'utilisateur appartient.
Pour travailler dans la console, les utilisateurs doivent avoir des autorisations pour effectuer les
actions que la console exécute, telles que l'affichage et la création de ressources AWS. Pour plus
d'informations, consultez Gestion de l'accès (p. 281) et Exemples de stratégies de gestion de
ressources AWS (p. 347).
70
Gestion des utilisateurs
Note
Journalisation des détails de connexion dans CloudTrail
Si vous activez CloudTrail de façon à consigner les événements de connexion dans vos journaux, vous
devez savoir comment CloudTrail choisit l'emplacement de consignation des événements.
• Vous pouvez demander manuellement un point de terminaison de connexion régional spécifique en
vous connectant à la page d'accueil régionale de la console principale à l'aide d'une syntaxe d'URL
https://alias.signin.aws.amazon.com/console?ap-southeast-1
Pour plus d'informations sur CloudTrail et IAM, consultez Journalisation des événements IAM avec
AWS CloudTrail .
Si les utilisateurs ont besoin d'un accès par programmation pour utiliser votre compte, vous pouvez
créer une paire de clés d'accès (un ID de clé d'accès et une clé d'accès secrète) pour chaque
utilisateur, comme décrit dans Création, modification et affichage des clés d'accès (AWS Management
Console) (p. 90).
Gestion des utilisateurs IAM
Amazon Web Services fournit plusieurs outils permettant de gérer les utilisateurs IAM dans votre
compte AWS.
Rubriques
71
• Liste des utilisateurs IAM (p. 72)
• Affectation d'un nouveau nom à un utilisateur IAM (p. 72)
• Suppression d'un utilisateur IAM (p. 73)
Liste des utilisateurs IAM
Vous pouvez répertorier les utilisateurs IAM de votre compte AWS ou dans un groupe IAM spécifique,
et répertorier tous les groupes auxquels appartient un utilisateur. Pour plus d'informations sur les
autorisations requises pour répertorier des utilisateurs, consultez Délégation des autorisations
d'administration des utilisateurs, des groupes et des informations d'identification IAM (p. 285).
Pour répertorier tous les utilisateurs du compte
• AWS Management Console : dans le volet de navigation, sélectionnez Users. La console affiche les
utilisateurs de votre compte AWS.
• AWS CLI : aws iam list-users
• Outils pour Windows PowerShell : Get-IAMUsers
• API AWS : ListUsers
Pour répertorier les utilisateurs d'un groupe spécifique
• AWS Management Console : dans le volet de navigation, sélectionnez Groups, choisissez le nom du
groupe, puis sélectionnez l'onglet Users.
• AWS CLI : aws iam get-group
• Outils pour Windows PowerShell : Get-IAMGroup
• API AWS : GetGroup
Pour répertorier tous les groupes auxquels appartient un utilisateur
• AWS Management Console : dans le volet de navigation, sélectionnez Users, choisissez le nom
utilisateur, puis sélectionnez l'onglet Groups.
• AWS CLI : aws iam list-groups-for-user
• Outils pour Windows PowerShell : Get-IAMGroupForUser
• API AWS : ListGroupsForUser
Affectation d'un nouveau nom à un utilisateur IAM
Pour modifier le nom ou le chemin d'un utilisateur, vous devez utiliser l'AWS CLI, l'Outils pour Windows
PowerShell ou l'API AWS. La console ne comporte aucune option permettant de renommer un
utilisateur. Pour plus d'informations sur les autorisations requises pour renommer un utilisateur,
consultez Délégation des autorisations d'administration des utilisateurs, des groupes et des
informations d'identification IAM (p. 285).
Lorsque vous modifiez le nom ou le chemin d'accès d'un utilisateur, voici ce qui suit se produit :
• Toutes les stratégies attachées à l'utilisateur restent dans l'utilisateur sous le nouveau nom.
• L'utilisateur reste dans les mêmes groupes sous le nouveau nom.
• L'ID unique de l'utilisateur demeure le même. Pour plus d'informations sur les ID uniques, consultez
ID uniques (p. 390).
72
• Toutes les ressources ou stratégies de rôle qui font référence à l'utilisateur en tant que mandataire
(l'utilisateur se voit accorder l'accès) sont mises à jour automatiquement pour utiliser le nouveau nom
ou chemin. Par exemple, toutes les stratégies basées sur des files d'attente dans Amazon SQS ou
les stratégies basées sur des ressources dans Amazon S3 sont mises à jour automatiquement pour
utiliser le nouveau nom ou chemin.
IAM ne met pas automatiquement à jour les stratégies qui font référence à l'utilisateur en tant que
ressource de manière à utiliser le nouveau nom ou chemin ; vous devez le faire manuellement. Par
exemple, imaginons qu'une stratégie est attachée à l'utilisateur Bob et qu'elle lui permet de gérer ses
informations d'identification de sécurité. Si un administrateur renomme Bob en Robert, administrateur
doit également mettre à jour cette stratégie pour changer la ressource de :
arn:aws:iam::account-ID-without-hyphens:user/division_abc/subdivision_xyz/Bob
à :
arn:aws:iam::account-ID-without-hyphens:user/division_abc/subdivision_xyz/
Robert
C'est également vrai si un administrateur modifie le chemin : il doit également mettre à jour la stratégie
pour refléter le nouveau chemin de l'utilisateur.
Pour renommer un utilisateur
• AWS CLI : aws iam update-user
• Outils pour Windows PowerShell : Update-IAMUser
• API AWS : UpdateUser
Suppression d'un utilisateur IAM
Si une personne quitte votre entreprise, vous devrez supprimer l'utilisateur IAM de votre compte.
Si l'utilisateur quitte temporairement votre entreprise, vous pouvez désactiver momentanément les
informations d'identification de l'utilisateur plutôt que de le supprimer entièrement du compte AWS.
Ainsi, vous empêchez l'utilisateur d'accéder aux ressources du compte AWS pendant son absence,
mais vous pouvez le réactiver ultérieurement.
Pour obtenir plus d'informations sur la désactivation d'informations d'identification, consultez Gestion
des clés d'accès pour les utilisateurs IAM (p. 89). Pour plus d'informations sur les autorisations
requises pour supprimer un utilisateur, consultez Délégation des autorisations d'administration des
utilisateurs, des groupes et des informations d'identification IAM (p. 285).
Rubriques
• Suppression d'un utilisateur IAM (AWS Management Console) (p. 73)
• Suppression d'un utilisateur IAM (AWS CLI et Outils pour Windows PowerShell) (p. 74)
Suppression d'un utilisateur IAM (AWS Management Console)
Lorsque vous utilisez AWS Management Console pour supprimer un utilisateur de IAM, IAM supprime
automatiquement les informations suivantes pour vous :
• L'utilisateur
• Toutes ses appartenances à des groupes, c'est-à-dire que l'utilisateur est supprimé de tous les
groupes IAM dont il faisait partie
73
• Tous les mots de passe associés à utilisateur
• Toutes les clés d'accès appartenant à l'utilisateur
• Toutes les stratégies en ligne intégrées à l'utilisateur (stratégies qui sont appliquées à un utilisateur
via les autorisations de groupe ne sont pas affectées)
Note
Toutes les stratégies gérées attachées à l'utilisateur sont détachées de celui-ci quand il
est supprimé. Les stratégies gérées ne sont pas supprimées lorsque vous supprimez un
utilisateur.
• Tous les périphériques MFA associés
Pour utiliser AWS Management Console pour supprimer un utilisateur IAM
1.
2.
Dans le volet de navigation, choisissez Users, puis activez la case à cocher en regard du nom
utilisateur que vous souhaitez supprimer, pas le nom ou la ligne elle-même.
3.
Pour User Actions en haut de la page, sélectionnez Delete User.
4.
Dans la boîte de dialogue de confirmation, vérifiez les dernières données consultées dans
le service qui indiquent quels utilisateurs, parmi ceux sélectionnés, ont accédé en dernier à
un service AWS. Cela vous permet de confirmer si l'utilisateur est actif actuellement. Si vous
souhaitez continuer, choisissez Yes, Delete. Si vous êtes sûr, procédez à la suppression même si
les dernières données consultées dans le service sont toujours en cours de chargement.
Suppression d'un utilisateur IAM (AWS CLI et Outils pour Windows
PowerShell)
Contrairement à l'AWS Management Console, lorsque vous supprimez un utilisateur avec l'AWS CLI
ou l'Outils pour Windows PowerShell vous devez supprimer manuellement les éléments attachés à
l'utilisateur. La procédure suivante illustre ce processus. Pour obtenir un extrait de code PowerShell
complet, consultez l'exemple de la section Remove-IAMUser.
Pour utiliser l'AWS CLI pour supprimer un utilisateur de votre compte
1.
Supprimez les clés et certificats de l'utilisateur. Cela vous permet de vous assurer que l'utilisateur
ne peut pus accéder aux ressources de votre compte AWS. Notez que la suppression d'une
information d'identification de sécurité est définitive et que vous ne pourrez plus récupérer celle-ci.
aws iam delete-access-key et aws iam delete-signing-certificate
2.
Supprimez le mot de passe de l'utilisateur, s'il en a un.
aws iam delete-login-profile
3.
Désactivez le périphérique MFA de l'utilisateur, s'il en a un.
aws iam deactivate-mfa-device
4.
Détachez les stratégies attachées à l'utilisateur.
aws iam list-attached-user-policies (pour répertorier les stratégies attachées à l'utilisateur) et aws
iam detach-user-policy (pour détacher les stratégies)
5.
Obtenez une liste des groupes auxquels appartenait l'utilisateur et supprimez celui-ci de ces
groupes.
aws iam list-groups-for-user et aws iam remove-user-from-group
74
Modification des autorisations pour un utilisateur
6.
Supprimez l'utilisateur.
aws iam delete-user
Pour utiliser l'Outils pour Windows PowerShell pour supprimer un utilisateur de votre compte
1.
Supprimez les clés et certificats de l'utilisateur. Cela vous permet de vous assurer que l'utilisateur
ne peut pus accéder aux ressources de votre compte AWS. Notez que la suppression d'une
information d'identification de sécurité est définitive et que vous ne pourrez plus récupérer celle-ci.
Remove-IAMAccessKey et Remove-IAMSigningCertificate
2.
Supprimez le mot de passe de l'utilisateur, s'il en a un.
Remove-IAMLoginProfile
3.
Désactivez le périphérique MFA de l'utilisateur, s'il en a un.
Disable-IAMMFADevice
4.
Détachez les stratégies attachées à l'utilisateur.
Get-IAMAttachedUserPolicies (pour répertorier les stratégies attachées à l'utilisateur) et RemoveIAMUserPolicy (pour détacher les stratégies).
5.
Obtenez une liste des groupes auxquels appartenait l'utilisateur et supprimez celui-ci de ces
groupes.
Get-IAMGroupForUser et Remove-IAMUserFromGroup.
6.
Supprimez l'utilisateur.
Remove-IAMUser
IAM
Vous pouvez modifier les autorisations d'un utilisateur IAM dans votre compte AWS en modifiant son
appartenance à un groupe ou en attachant et détachant des stratégies gérées. Un utilisateur obtient
ses autorisations via l'une des méthodes suivantes :
Appartenance à un groupe
• Ajoutez ou supprimez un utilisateur dans un groupe.
• Ajoutez, supprimez ou modifiez une stratégie gérée attachée au groupe. Cette stratégie peut
être créée et gérée par le client, ou gérée par AWS.
• Ajoutez, supprimez ou modifiez les stratégies en ligne d'un groupe. Ce type de stratégie est
toujours créé par le client.
Attachement direct de la stratégie
• Ajoutez, supprimez ou modifiez une stratégie gérée attachée directement à un utilisateur. Cette
stratégie peut être créée et gérée par le client, ou gérée par AWS.
• Ajoutez, supprimez ou modifiez les stratégies en ligne d'un utilisateur. Ce type de stratégie est
toujours créé par le client.
Pour plus d'informations sur les autorisations requises pour modifier les autorisations d'un utilisateur,
consultez Délégation des autorisations d'administration des utilisateurs, des groupes et des
informations d'identification IAM (p. 285).
75
Ajout d'autorisations à un utilisateur existant ou nouvellement
créé (console)
Vous pouvez modifier les autorisations associées à un utilisateur en utilisant l'une des trois techniques
suivantes :
• Add user to group (p. 76). Permet à l'utilisateur de devenir membre d'un groupe ayant déjà
des stratégies attachées. Chaque membre du groupe reçoit les autorisations accordées par les
stratégies du groupe.
• Copy permissions from existing user (p. 77). Copie tous les appartenances à un groupe et
stratégies gérées attachées, ainsi que toutes les stratégies en ligne intégrées dans l'utilisateur
source.
• Attach policies directly to user (p. 77). Attache une stratégie gérée directement à l'utilisateur.
A titre de bonne pratique (p. 46), nous vous recommandons plutôt d'attacher vos stratégies à un
groupe, puis d'ajouter les utilisateurs aux groupes appropriés.
Ajout d'autorisations en ajoutant l'utilisateur à un groupe
Pour ajouter des autorisations à un utilisateur en ajoutant celui-ci à un groupe
1.
2.
Dans le volet de navigation, choisissez Users, choisissez le nom de l'utilisateur dont vous
souhaitez modifier les autorisations, puis choisissez l'onglet Permissions.
3.
Choisissez Add permissions, puis sous Grant permissions, choisissez Add user to group.
4.
Activez la case à cocher pour chaque groupe que l'utilisateur doit rejoindre. La liste affiche le nom
de chaque groupe et les stratégies que l'utilisateur reçoit s'il devient membre de ce groupe. Les
autorisations de chaque groupe sélectionné s'appliquent à l'utilisateur dès que vous avez terminé
le processus.
5.
(Facultatif) Outre la sélection de groupes existants, vous pouvez choisir Create group pour définir
un nouveau groupe :
a.
Pour Group name, saisissez un nom pour le nouveau groupe.
Note
Les noms de groupe peuvent combiner jusqu'à 128 lettres, chiffres et caractères
suivants : plus (+), égal (=), virgule (,), point (.), arobase (@) et tiret (-). Les noms
doivent être uniques dans un compte. Ils ne sont pas sensibles à la casse. Par
exemple, vous ne pouvez pas créer deux groupes nommés TESTGROUP et
testgroup. Pour plus d'informations sur les limitations liées aux entités IAM, consultez
Limitations des entités et objets IAM (p. 391).
6.
b.
Activez une ou plusieurs cases à cocher pour les stratégies gérées que vous souhaitez
attacher au groupe. Vous pouvez également créer une stratégie gérée en choisissant Create
policy. Le cas échéant, revenez dans la fenêtre ou l'onglet du navigateur une fois la nouvelle
stratégie créée. Choisissez Refresh, puis choisissez la nouvelle stratégie à attacher à votre
groupe. Pour plus d'informations, consultez Création d'une stratégie (p. 321).
c.
Choisissez Create group.
d.
De retour dans la liste des groupes, activez la case à cocher du nouveau groupe.
Choisissez Next: Review pour afficher la liste des membres du groupe à ajouter à l'utilisateur.
Choisissez ensuite Add permissions.
Les nouvelles autorisations affectent l'utilisateur immédiatement.
76
Ajout d'autorisations en copiant celles d'un autre utilisateur
Pour ajouter des autorisations à un utilisateur en copiant celles d'un autre utilisateur
1.
2.
3.
Choisissez Add permissions, puis sous Grant permissions, choisissez Copy permissions from
existing use. La liste affiche les utilisateurs disponibles ainsi que leur appartenance à un groupe
et les stratégies attachées. Si la liste complète des groupes ou des stratégies ne tient pas sur une
seule ligne, vous pouvez choisir le lien pour and n more pour ouvrir un nouvel onglet de navigateur
et afficher la liste complète des stratégies (onglet Permissions) et des groupes (onglet Groups).
4.
Sélectionnez le bouton radio en regard de l'utilisateur dont vous voulez copier les autorisations.
5.
Choisissez Next: Review pour afficher la liste de modifications apportées à l'utilisateur. Choisissez
ensuite Add permissions.
Ajout d'autorisations en attachant les stratégies directement à l'utilisateur
Pour ajouter des autorisations à un utilisateur en attachant directement les stratégies gérées
1.
2.
3.
Choisissez Add permissions, puis sous Grant permissions, choisissez Attach existing policies
directly to user.
4.
Activez une ou plusieurs cases à cocher pour les stratégies gérées que vous souhaitez attacher
au groupe. Vous pouvez également créer une stratégie gérée en choisissant Create policy. Le cas
échéant, revenez dans l'onglet ou la fenêtre du navigateur une fois la nouvelle stratégie créée.
Choisissez Refresh, puis activez la case à cocher correspondant à la nouvelle stratégie pour
l'attacher à votre utilisateur. Pour plus d'informations, consultez Création d'une stratégie (p. 321).
5.
Choisissez Next: Review pour afficher la liste de stratégies attachées à l'utilisateur. Choisissez
ensuite Add permissions.
Suppression des autorisations d'un utilisateur existant
(console)
Pour annuler les autorisations des utilisateurs IAM (console)
1.
2.
L'onglet Permissions affiche chaque stratégie qui s'applique à l'utilisateur et la façon dont
l'utilisateur obtient cette stratégie.
3.
Si vous souhaitez annuler les autorisations en supprimant une stratégie existante, sélectionnez la
stratégie et affichez la façon dont l'utilisateur obtient cette stratégie :
77
Mots de passe
• Si la stratégie s'applique en raison de l'appartenance à un groupe, choisissez Remove user
from group.
Important
Les utilisateurs peuvent recevoir plusieurs stratégies via l'appartenance à un seul
groupe. Lorsque vous supprimez un utilisateur d'un groupe, il perd l'accès à toutes les
stratégies qu'il reçoit par le biais de cette appartenance au groupe.
• S'il s'agit d'une stratégie gérée, choisissez Detach policy. Cela n'affecte pas la stratégie ellemême ni aucune autre entité à laquelle la stratégie pourrait être attachée.
• S'il s'agit d'une stratégie en ligne intégrée, choisissez Remove policy.
Ajout et suppression d'autorisations d'un utilisateur (AWS API,
AWS CLI, Outils pour Windows PowerShell)
Pour ajouter ou supprimer des autorisations par programme, vous devez ajouter ou supprimer
l'appartenance au groupe, attacher ou détacher les stratégies gérées, ou ajouter ou supprimer les
stratégies en ligne. Pour plus d'informations, consultez les rubriques suivantes :
• Ajout et suppression d'utilisateurs dans un groupe IAM (p. 137)
• Utilisation de stratégies gérées à l'aide de l'AWS CLI ou de l'API IAM (p. 327)
• Utilisation de stratégies en ligne à l'aide de l'AWS CLI ou de l'API IAM (p. 330)
Gestion des mots de passe
Vous pouvez gérer les mots de passe de votre compte AWS et des utilisateurs IAM de votre
compte. Pour accéder à AWS Management Console, les utilisateurs IAM doivent utiliser des mots
de passe. Les utilisateurs n'ont pas besoin de mots de passe pour accéder aux ressources AWS par
programmation lors de l'utilisation de l'AWS CLI, de Outils pour Windows PowerShell, des kits SDK ou
d'API AWS. Pour ces environnements, des clés d'accès (p. 89) sont requises à la place.
Rubriques
• Modification du mot de passe (« racine ») du compte AWS (p. 78)
• Définition d'une stratégie de mot de passe du compte pour les utilisateurs IAM (p. 79)
• Gestion des mots de passe des utilisateurs IAM (p. 83)
• Autorisation des utilisateurs IAM à modifier leurs propres mots de passe (p. 86)
• Comment les utilisateurs IAM modifient leur mot de passe (p. 88)
Modification du mot de passe (« racine ») du compte AWS
Vous pouvez modifier le mot de passe du compte AWS (utilisateur « racine »). Vous devez être
connecté en tant qu'utilisateur racine pour modifier le mot de passe racine.
Pour modifier le mot de passe du compte racine AWS
1.
Utilisez l'adresse e-mail et le mot de passe de votre compte AWS pour vous connecter à l'AWS
Management Console.
Note
Si vous vous êtes précédemment connecté à la console avec des informations
d'identification d'utilisateur IAM, votre navigateur peut se rappeler de cette préférence et
78
Mots de passe
ouvrir la page de connexion spécifique à votre compte. Vous ne pouvez pas utiliser la
page de connexion utilisateur pour vous connecter avec vos informations d'identification
de compte racine. Si la page de connexion utilisateur s'affiche, cliquez sur Sign in using
root account credentials située en regard du bas de la page pour revenir à la page de
connexion racine.
2.
Dans le coin supérieur droit de la console, cliquez sur la flèche située en regard du nom ou du
numéro du compte, puis cliquez sur Security Credentials. Si une invite s'affiche, cliquez sur
Continue to Security Credentials.
3.
Sur la page Your Security Credentials, développez la section Password et cliquez sur Click here.
4.
Sur la ligne Password, cliquez sur Edit pour modifier votre mot de passe.
Définition d'une stratégie de mot de passe du compte pour les
utilisateurs IAM
Vous pouvez définir une stratégie de mots de passe pour votre compte AWS afin de spécifier les
exigences de complexité et les intervalles de rotation obligatoires des mots de passe des utilisateurs
de IAM. Vous pouvez utiliser une stratégie de mot de passe pour ces opérations :
• Définir la longueur minimum du mot de passe.
79
Mots de passe
• Exigez des types de caractère spécifiques, y compris des lettres majuscules, minuscules, chiffres et
caractères non alphanumériques. Prenez soin de rappeler à vos utilisateurs que les mots de passe
sont sensibles à la casse.
• Autoriser tous les utilisateurs de IAM à modifier leurs propres mots de passe.
Note
Lorsque vous autorisez vos utilisateurs IAM à modifier leurs propres mots de passe, IAM les
autorise automatiquement à afficher la stratégie de mot de passe. Les utilisateurs IAM ont
besoin d'une autorisation pour afficher la stratégie de mot de passe du compte afin de créer
un mot de passe respectant la stratégie.
• Demandez aux utilisateurs d'IAM de changer leur mot de passe après une durée spécifiée (activer
l'expiration de mot de passe).
• Empêcher les utilisateurs d'IAM de réutiliser des mots de passe précédents.
• Forcer les utilisateurs d'IAM à contacter un administrateur du compte lorsque l'utilisateur a laissé
expirer son mot de passe.
Important
Les paramètres de mot de passe décrits ici s'appliquent uniquement aux mots de passe
attribués aux utilisateurs IAM et n'affectent pas leurs éventuelles clés d'accès. Si un mot de
passe expire, l'utilisateur ne peut pas se connecter à l'AWS Management Console. Toutefois,
si l'utilisateur dispose de clés d'accès valides, il peut toujours exécuter des commandes
AWS CLI ou Outils pour Windows PowerShell, ou appeler des API via une application qu'il a
l'autorisation d'utiliser.
Lorsque vous créez ou modifiez une stratégie de mot de passe, la plupart des paramètres de celle-ci
sont appliqués la prochaine fois que vos utilisateurs modifient leurs mots de passe, mais certains le
sont immédiatement. Par exemple:
• Lorsque vous définissez des exigences de longueur minimale et de type de caractères, les
paramètres sont appliqués la prochaine fois que vos utilisateurs modifient leurs mots de passe. Les
utilisateurs ne sont pas contraints à modifier leurs mots de passe, même si ceux-ci ne respectent
pas la stratégie de mot de passe modifiée.
• Lorsque vous définissez une période d'expiration de mot de passe, celle-ci est appliquée
immédiatement. Par exemple, lorsque vous définissez une période d'expiration de mot de passe
de 90 jours, tous les utilisateurs IAM ayant un mot de passe antérieur à 90 jours sont contraints de
modifier celui-ci à leur prochaine connexion.
Pour plus d'informations sur les autorisations dont vous devez disposer pour définir une stratégie
de mot de passe, consultez Autorisation des utilisateurs IAM à modifier leurs propres mots de
passe (p. 86).
Rubriques
• Options de stratégie de mot de passe (p. 80)
• Définition d'une stratégie de mot de passe (AWS Management Console) (p. 82)
• Définition d'une stratégie de mot de passe (AWS CLI, l'Outils pour Windows PowerShell ou l'API
AWS) (p. 82)
Options de stratégie de mot de passe
La liste suivante répertorie les options disponibles lorsque vous configurez une stratégie de mot de
passe pour votre compte.
80
Mots de passe
Longueur minimum du mot de passe
Vous pouvez spécifier le nombre minimal de caractères autorisés dans un mot de passe
d'utilisateur IAM. Vous pouvez entrer un chiffre situé entre 6 et 128.
Nécessite au moins une lettre en majuscules
Vous pouvez demander que les mots de passe des utilisateurs IAM contiennent au moins un
caractère majuscule de l'alphabet latin ISO de base (A à Z).
Nécessite au moins une lettre en minuscules
caractère minuscule de l'alphabet latin ISO de base (a à z).
Nécessite au moins un chiffre
caractère numérique (0 à 9).
Nécessite au moins un caractère non alphanumérique
Vous pouvez demander que les mots de passe des utilisateurs IAM contiennent au moins l'un des
caractères non alphanumériques suivants :
! @ # $ % ^ & * ( ) _ + - = [ ] { } | '
Autoriser les utilisateurs à modifier leur propre mot de passe
Vous pouvez permettre à tous les utilisateurs IAM de votre compte d'utiliser la console IAM pour
modifier leur mot de passe, comme décrit dans la section Autorisation des utilisateurs IAM à
modifier leurs propres mots de passe (p. 86).
Sinon, vous pouvez autoriser certains utilisateurs uniquement à gérer les mots de passe, que ce
soit pour eux-mêmes ou pour d'autres. Pour cela, vous désactivez la case à cocher Allow users to
change their own password. Pour plus d'informations sur l'utilisation de stratégies visant à limiter
les utilisateurs pouvant gérer les mots de passe, consultez la section Autorisation des utilisateurs
IAM à modifier leurs propres mots de passe (p. 86).
Note
Lorsque vous autorisez vos utilisateurs IAM à modifier leurs propres mots de passe, IAM
les autorise automatiquement à afficher la stratégie de mot de passe. Les utilisateurs IAM
ont besoin d'une autorisation pour afficher la stratégie de mot de passe du compte afin de
créer un mot de passe respectant la stratégie.
Activer l'expiration du mot de passe
Vous pouvez définir la validité des mots de passe des utilisateurs IAM pendant un nombre de
jours spécifique. Vous pouvez spécifier le nombre de jours pendant lesquels les mots de passe
sont valides après avoir été définis. Par exemple, lorsque vous activez l'expiration de mot de
passe et que vous définissez la période d'expiration des mots de passe sur 90 jours, un utilisateur
IAM peut utiliser un mot de passe pendant 90 jours. Au bout de 90 jours, le mot de passe expire
et l'utilisateur IAM doit définir un nouveau mot de passe avant d'accéder à AWS Management
Console. La période d'expiration d'un mot de passe peut être définie entre 1 et 1 095 jours, inclus.
Note
AWS Management Console avertit les utilisateurs IAM lorsqu'ils se trouvent à 15 jours de
l'expiration du mot de passe. Les utilisateurs IAM peuvent modifier leurs mots de passe à
tout moment (tant qu'ils y sont autorisés). Lorsqu'ils définissent un nouveau mot de passe,
la période de rotation de celui-ci redémarre. Un utilisateur IAM ne peut avoir qu'un mot de
passe valide à la fois.
Empêcher la réutilisation d'un mot de passe
Vous pouvez empêcher les utilisateurs IAM de réutiliser un certain nombre de mots de passe
précédents. Vous pouvez définir le nombre de mots de passe précédents de 1 à 24, inclus.
81
Mots de passe
L'expiration du mot de passe nécessite la réinitialisation de l'administrateur
Vous pouvez empêcher les utilisateurs IAM de choisir un nouveau mot de passe une fois que
leur mot de passe actuel a expiré. Par exemple, si la stratégie de mot de passe spécifie une
période d'expiration de mot de passe, mais qu'un utilisateur IAM échoue à utiliser un nouveau
mot de passe avant la fin de la période d'expiration, celui-ci ne peut pas définir de nouveau mot
de passe. Dans ce cas, l'utilisateur IAM doit demander une réinitialisation du mot de passe à un
administrateur de compte pour avoir à nouveau accès à AWS Management Console. Si vous
laissez cette case à cocher inactive et qu'un utilisateur IAM laisse expirer son mot de passe, il
devra définir un nouveau mot de passe avant d'accéder à l'AWS Management Console.
Caution
Avant d'activer cette option, assurez-vous que votre compte AWS possède plusieurs
utilisateurs disposant d'autorisations administratives (c'est-à-dire, autorisés à réinitialiser
des mots de passe utilisateur IAM) ou que vos administrateurs disposent également de
clés d'accès leur permettant d'utiliser l'AWS CLI ou les Outils pour Windows PowerShell
séparément de l'AWS Management Console. Si cette option est activée et que le mot
de passe d'un administrateur expire, un second administrateur doit se connecter à la
console pour réinitialiser le mot de passe expiré du premier administrateur. Toutefois,
si l'administrateur dont le mot de passe a expiré dispose de clés d'accès valides, il peut
exécuter une commande AWS CLI ou Outils pour Windows PowerShell pour réinitialiser
son mot de passe. Un second administrateur n'est nécessaire que si un mot de passe
expire et que le premier administrateur ne dispose d'aucune clé d'accès.
Définition d'une stratégie de mot de passe (AWS Management Console)
Vous pouvez utiliser AWS Management Console pour créer, modifier ou supprimer une stratégie de
mot de passe. Dans le cadre de la gestion de la stratégie de mot de passe, vous pouvez laisser tous
les utilisateurs gérer leurs propres mots de passe.
Pour créer ou modifier une stratégie de mot de passe
1.
2.
Dans le volet de navigation, cliquez sur Account Settings.
3.
Dans la section Password Policy, sélectionnez les options que vous souhaitez appliquer à votre
stratégie de mot de passe.
4.
Cliquez sur Apply Password Policy.
Pour supprimer une stratégie de mot de passe
1.
2.
Dans le volet de navigation, cliquez sur Account Settings, puis dans la section Password Policy,
sélectionnez Delete Password Policy.
Définition d'une stratégie de mot de passe (AWS CLI, l'Outils pour Windows
PowerShell ou l'API AWS)
Pour gérer une stratégie de mot de passe de compte sur l'AWS CLI, l'Outils pour Windows PowerShell
ou les API AWS, utilisez les commandes suivantes :
Pour créer ou modifier une stratégie de mot de passe
• AWS CLI : aws iam update-account-password-policy
82
Mots de passe
• Outils pour Windows PowerShell : Update-IAMAccountPasswordPolicy
• API AWS : UpdateAccountPasswordPolicy
Pour récupérer la stratégie de mot de passe
• AWS CLI : aws iam get-account-password-policy
• Outils pour Windows PowerShell : Get-IAMAccountPasswordPolicy
• API AWS : GetAccountPasswordPolicy
Pour supprimer une stratégie de mot de passe
• AWS CLI : aws iam delete-account-password-policy
• Outils pour Windows PowerShell : Remove-IAMAccountPasswordPolicy
• APII AWS : DeleteAccountPasswordPolicy
Gestion des mots de passe des utilisateurs IAM
Les utilisateurs IAM qui utilisent l'AWS Management Console pour se servir de vos ressources AWS
doivent disposer d'un mot de passe pour se connecter. Vous pouvez créer, modifier ou supprimer un
mot de passe pour un utilisateur IAM dans votre compte AWS.
Après avoir attribué un mot de passe à un utilisateur, celui-ci peut se connecter à l'AWS Management
Console à l'aide de l'URL de connexion de votre compte qui ressemble à ce qui suit :
https://12-digit-AWS-account-ID or alias.signin.aws.amazon.com/console
Pour plus d'informations sur la connexion des utilisateurs IAM à l'AWS Management Console,
consultez La console IAM et la page de connexion (p. 53).
En plus de créer manuellement des mots de passe individuels pour vos utilisateurs IAM, vous pouvez
créer une stratégie de mot de passe s'appliquant à tous les mots de passe des utilisateurs IAM dans
votre compte AWS. Vous pouvez utiliser une stratégie de mot de passe pour ces opérations :
• Définir la longueur minimum du mot de passe.
• Exigez des types de caractère spécifiques, y compris des lettres majuscules, minuscules, chiffres et
caractères non alphanumériques. Prenez soin de rappeler à vos utilisateurs que les mots de passe
sont sensibles à la casse.
• Autoriser tous les utilisateurs de IAM à modifier leurs propres mots de passe.
Note
Lorsque vous autorisez vos utilisateurs IAM à modifier leurs propres mots de passe, IAM les
autorise automatiquement à afficher la stratégie de mot de passe. Les utilisateurs IAM ont
besoin d'une autorisation pour afficher la stratégie de mot de passe du compte afin de créer
un mot de passe respectant la stratégie.
• Demandez aux utilisateurs d'IAM de changer leur mot de passe après une durée spécifiée (activer
l'expiration de mot de passe).
• Empêcher les utilisateurs d'IAM de réutiliser des mots de passe précédents.
• Forcer les utilisateurs d'IAM à contacter un administrateur du compte lorsque l'utilisateur a laissé
expirer son mot de passe.
Pour plus d'informations sur la gestion de la stratégie de mot de passe de votre compte, consultez
Définition d'une stratégie de mot de passe du compte pour les utilisateurs IAM (p. 79).
83
Mots de passe
Même si vos utilisateurs ont leurs propres mots de passe, ils toujours besoin de votre autorisation
pour accéder à vos ressources AWS. Par défaut, un utilisateur ne dispose d'aucune autorisation. Pour
accorder à vos utilisateurs les autorisations dont ils ont besoin, vous leur attribuez des stratégies ou
aux groupes dont ils font partie. Pour plus d'informations sur la création d'utilisateurs et de groupes,
consultez Identités (utilisateurs, groupes et rôles) (p. 61). Pour plus d'informations sur l'utilisation
de stratégies pour l'octroi d'autorisations, consultez Modification des autorisations pour un utilisateur
IAM (p. 75).
Vous pouvez accorder aux utilisateurs 'autorisation de modifier leurs propres mots de passe. Pour de
plus amples informations, veuillez consulter Autorisation des utilisateurs IAM à modifier leurs propres
mots de passe (p. 86). Pour plus d'informations sur l'accès des utilisateurs à la page de connexion
de votre compte, consultez La console IAM et la page de connexion (p. 53).
Rubriques
• Création, modification ou suppression d'un mot de passe utilisateur IAM (AWS Management
Console) (p. 84)
• Création, modification ou suppression d'un mot de passe utilisateur IAM (AWS CLI, Outils pour
Windows PowerShell et API AWS) (p. 85)
Création, modification ou suppression d'un mot de passe utilisateur IAM (AWS
Management Console)
Vous pouvez utiliser l'AWS Management Console pour gérer les mots de passe de vos utilisateurs
IAM.
Pour utiliser la console afin de définir le mot de passe d'un utilisateur IAM
1.
2.
Dans le volet de navigation, sélectionnez Users.
3.
Choisissez le nom de l'utilisateur dont vous souhaitez créer le mot de passe.
4.
Choisissez l'onglet Security Credentials, puis sous Sign-in Credentials, choisissez Manage
password en regard de Console password.
5.
Dans la boîte de dialogue Manage console access, pour Console access, choisissez Enable si
cette option n'est pas déjà sélectionnée. Si l'accès à la console est désactivé, aucun mot de passe
n'est nécessaire.
6.
Pour Set password, choisissez si vous préférez qu'IAM génère un mot de passe ou si vous voulez
créer un mot de passe personnalisé :
• Pour qu'IAM génère un mot de passe, choisissez Autogenerated password.
• Pour créer un mot de passe personnalisé, choisissez Custom password, puis tapez le mot de
passe.
Note
Le mot de passe que vous créez doit respecter la stratégie de mot de passe (p. 79)
du compte, si une stratégie est définie actuellement.
7.
Pour demander à l'utilisateur de créer un mot de passe lors de sa connexion, choisissez Require
password reset. Choisissez ensuite Apply.
Important
Si vous sélectionnez l'option Require password reset, vérifiez que l'utilisateur est bien
autorisé à modifier son mot de passe. Pour plus d'informations, consultez Autorisation des
utilisateurs IAM à modifier leurs propres mots de passe (p. 86).
84
Mots de passe
8.
Si vous sélectionnez l'option de génération automatique du mot de passe, choisissez Show
dans la boîte de dialogue New password. Cela vous permet d'afficher le mot de passe afin de le
partager avec l'utilisateur.
Important
Pour des raisons de sécurité, vous ne pouvez pas accéder au mot de passe après avoir
effectué cette étape, mais vous pouvez créer un nouveau mot de passe à tout moment.
Pour supprimer un mot de passe utilisateur IAM à l'aide de la console
La suppression du mot de passe d'un utilisateur IAM empêche celui-ci d'utiliser l'AWS Management
Console.
1.
2.
3.
Choisissez le nom de l'utilisateur dont vous souhaitez supprimer le mot de passe.
4.
Choisissez l'onglet Security Credentials, puis sous Sign-in Credentials, choisissez Manage
password en regard de Console password.
5.
Pour Console access, choisissez Disable, puis Apply.
6.
Important
Lorsque vous supprimez le mot de passe d'un utilisateur, ce dernier ne peut plus se
connecter à l'AWS Management Console. Si l'utilisateur avait des clés d'accès actives,
elles continuent de fonctionner et autorisent l'accès via les appels de fonction de l'AWS
CLI, l'Outils pour Windows PowerShell ou l'API AWS.
Création, modification ou suppression d'un mot de passe utilisateur IAM (AWS
CLI, Outils pour Windows PowerShell et API AWS)
Pour gérer les mots de passe des utilisateurs IAM, utilisez les commandes suivantes :
Pour créer un mot de passe
• AWS CLI : aws iam create-login-profile
• Outils pour Windows PowerShell : New-IAMLoginProfile
• API AWS : CreateLoginProfile
Pour déterminer si un utilisateur possède un mot de passe
• AWS CLI : aws iam get-login-profile
• Outils pour Windows PowerShell : Get-IAMLoginProfile
• API AWS : GetLoginProfile
Pour déterminer quand un mot de passe utilisateur a été utilisé pour la dernière fois
• AWS CLI : aws iam get-user
• Outils pour Windows PowerShell : Get-IAMUser
• API AWS : GetUser
Pour modifier le mot de passe d'un utilisateur
85
Mots de passe
• AWS CLI : aws iam update-login-profile
• Outils pour Windows PowerShell : Update-IAMLoginProfile
• API AWS : UpdateLoginProfile
Pour supprimer le mot de passe d'un utilisateur
• AWS CLI : aws iam delete-login-profile
• Outils pour Windows PowerShell : Remove-IAMLoginProfile
• API AWS : DeleteLoginProfile
Note
Si vous utilisez l'AWS CLI, l'Outils pour Windows PowerShell ou l'API AWS pour supprimer
un utilisateur de votre compte AWS, vous devez d'abord supprimer le mot de passe dans
une étape distincte du processus de suppression de l'utilisateur. Pour de plus amples
informations, veuillez consulter Suppression d'un utilisateur IAM (AWS CLI et Outils pour
Windows PowerShell) (p. 74).
Autorisation des utilisateurs IAM à modifier leurs propres mots
de passe
Si vous pouvez accorder des autorisations aux utilisateurs IAM pour modifier leurs propres mots de
passe lors de la connexion à AWS Management Console. Vous pouvez effectuer cette opération de
deux manières :
• Autorisez tous les utilisateurs IAM du compte à modifier leurs propres mots de passe (p. 86).
• Autorisez uniquement les utilisateurs IAM sélectionnés à modifier leurs propres mots de
passe (p. 87). Dans ce scénario, vous désactivez l'option permettant à tous les utilisateurs
de modifier leurs propres mots de passe et vous utilisez une stratégie IAM pour accorder des
autorisations uniquement à certains utilisateurs de modifier leurs propres mots de passe et, en
option, d'autres informations d'identification comme leurs propres clés d'accès.
Important
Nous vous recommandons de définir une stratégie de mot de passe (p. 79) afin que les
utilisateurs créent des mots de passe fiables.
Pour autoriser tous les utilisateurs IAM à modifier leurs propres mots de passe
1.
2.
3.
Dans la section Password Policy, sélectionnez Allow users to change their own password, puis
cliquez sur Apply Password Policy.
4.
Dirigez les utilisateurs vers les instructions suivantes indiquant de quelle manière il
peuvent modifier leurs mots de passe : Comment les utilisateurs IAM modifient leur mot de
passe (p. 88).
Pour plus d'informations sur les commandes de l'AWS CLI, l'Outils pour Windows PowerShell et l'API à
utiliser pour modifier la stratégie de mot de passe du compte (qui inclut autoriser tous les utilisateurs à
86
Mots de passe
modifier leurs propres mots de passe), consultez Définition d'une stratégie de mot de passe (AWS CLI,
l'Outils pour Windows PowerShell ou l'API AWS) (p. 82).
Pour autoriser des utilisateurs IAM sélectionnés à modifier leurs propres mots de passe
1.
2.
3.
Dans la section Account Settings, vérifiez que Allow users to change their own password n'est pas
sélectionné. Si cette case à cocher est activée, tous les utilisateurs peuvent modifier leurs propres
mots de passe. (Reportez-vous à la procédure précédente.)
4.
Créez les utilisateurs qui doivent pouvoir modifier leurs propres mots de passe, s'ils n'existe
pas encore. Pour plus d'informations, consultez Création d'un utilisateur IAM dans votre compte
AWS (p. 66).
5.
Créez un groupe IAM pour les utilisateurs qui doivent être autorisés à modifier leurs mots de
passe, puis ajoutez les utilisateurs de l'étape précédente au groupe. Pour plus d'informations,
consultez Création de votre premier utilisateur administrateur et groupe IAM (p. 15) et Gestion des
groupes IAM (p. 136).
Cette étape est facultative, mais c'est une bonne pratique permettant d'utiliser des groupes
pour gérer les autorisations afin de pouvoir ajouter et supprimer des utilisateurs et modifier les
autorisations du groupe dans son ensemble.
6.
Affectez la stratégie suivante au groupe. Pour plus d'informations, consultez Utilisation de
stratégies (p. 323).
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:GetAccountPasswordPolicy",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:ChangePassword",
"Resource": "arn:aws:iam::account-id-without-hyphens:user/
${aws:username}"
}
]
}
Cette stratégie accorde l'accès à l'action ChangePassword, ce qui permet aux utilisateurs
de ne modifier que leurs propres mots de passe à partir de la console, de l'AWS CLI, de
Outils pour Windows PowerShell ou de l'API. Elle accorde également l'accès à l'action
GetAccountPasswordPolicy qui permet à l'utilisateur d'afficher la stratégie de mot de passe
actuelle. Cette autorisation est requise pour que l'utilisateur puisse afficher la page Change
Password dans la console. L'utilisateur doit pouvoir lire la stratégie de mot de passe actuelle pour
s'assurer que le mot de passe satisfait les exigences de stratégie.
7.
Dirigez les utilisateurs vers les instructions suivantes indiquant de quelle manière il
peuvent modifier leurs mots de passe : Comment les utilisateurs IAM modifient leur mot de
passe (p. 88).
87
Mots de passe
Pour en savoir plus
Pour plus d'informations sur la gestion des informations d'identification, consultez les rubriques
suivantes :
• Autorisation des utilisateurs IAM à modifier leurs propres mots de passe (p. 86)
• Gestion des mots de passe (p. 78)
• Définition d'une stratégie de mot de passe du compte pour les utilisateurs IAM (p. 79)
• Utilisation de stratégies (p. 323)
• Comment les utilisateurs IAM modifient leur mot de passe (p. 88)
Comment les utilisateurs IAM modifient leur mot de passe
Si les utilisateurs ont reçu l'autorisation de modifier leurs mots de passe, ils peuvent effectuer cette
opération à l'aide d'une page spéciale d'AWS Management Console. Il est également possible d'utiliser
l'interface de ligne de commande ou l'API IAM.
Pour plus d'informations sur les autorisations dont les utilisateurs ont besoin pour changer leurs
mots de passe, consultez Autorisation des utilisateurs IAM à modifier leurs propres mots de
passe (p. 86).
Rubriques
• Comment les utilisateurs modifient leur mot de passe (AWS Management Console) (p. 88)
• Comment les utilisateurs modifient leur mot de passe (AWS CLI, Outils pour Windows PowerShell
et API AWS) (p. 89)
Comment les utilisateurs modifient leur mot de passe (AWS Management
Console)
La procédure suivante décrit comment un utilisateur IAM peut utiliser AWS Management Console pour
changer son mot de passe.
Pour utiliser la console pour modifier votre mot de passe en tant qu'utilisateur IAM
1.
Entrez l'URL de connexion à votre compte (p. 18) dans la barre d'adresse du navigateur. Ensuite,
connectez-vous à la console à l'aide de votre nom utilisateur et mot de passe IAM. Si vous utilisez
le point de terminaison global, l'URL se présente comme suit :
https://your_AWS_Account_ID.signin.aws.amazon.com/console/
Pour obtenir l'URL de votre page de connexion, contactez votre administrateur.
2.
Dans la barre de navigation de la console, cliquez sur la flèche en regard de votre nom utilisateur,
puis sur Security Credentials.
88
Clés d'accès
3.
Sous Old Password, entrez votre mot de passe actuel. Entrez un nouveau mot de passe dans les
champs New Password et Confirm New Password. Ensuite, cliquez sur Change Password.
Note
Si le compte est doté d'une stratégie de mot de passe, le nouveau mot de passe doit
respecter les exigences de cette stratégie. Pour de plus amples informations, veuillez
consulter Définition d'une stratégie de mot de passe du compte pour les utilisateurs
IAM (p. 79).
Comment les utilisateurs modifient leur mot de passe (AWS CLI, Outils pour
Windows PowerShell et API AWS)
En tant qu'utilisateur IAM, vous pouvez utiliser l'AWS CLI, les Outils pour Windows PowerShell ou l'API
AWS pour modifier votre mot de passe.
Pour modifier votre mot de passe IAM, utilisez les commandes suivantes
• AWS CLI : aws iam change-password
• Outils pour Windows PowerShell : Edit-IAMPassword
• API AWS : ChangePassword
Gestion des clés d'accès pour les utilisateurs IAM
Note
Si vous avez découvert cette rubrique, car vous essayez de configurer l'API Product
Advertising pour vendre des produits Amazon sur votre site web, consultez les rubriques
suivantes :
• Guide démarrage de l'API Product Advertising
• Guide démarrage en tant que développeur d'API Product Advertising
Les utilisateurs ont besoin de leurs propres clés d'accès pour réaliser des appels par programmation à
AWS dans l'AWS Command Line Interface (AWS CLI), l'Outils pour Windows PowerShell, les kit SDK
89
Clés d'accès
AWS ou des appels HTTP directs à l'aide des API pour les services AWS individuels. Pour répondre à
cette attente, vous pouvez créer, modifier, afficher ou faire tourner les clés d'accès (ID de clés d'accès
et clés d'accès secrètes) pour les utilisateurs IAM.
Lorsque vous créez ou supprimez une clé d'accès, IAM renvoie l'ID de clé d'accès et la clé d'accès
secrète. Vous devez les enregistrer à un emplacement sécurisé et les communiquer à l'utilisateur.
Important
Pour assurer la sécurité de votre compte AWS, la clé d'accès secrète est accessible
uniquement au moment de sa création. Si une clé d'accès secrète est perdue, vous devez la
supprimer pour l'utilisateur associé et en créer une nouvelle. Pour en savoir plus, consultez
Récupération de vos mots de passe ou clés d'accès perdus ou oubliés (p. 93).
Par défaut, lorsque vous créez une clé d'accès, son état est Active, ce qui signifie que l'utilisateur
peut utiliser la clé d'accès pour AWS CLI, 'Outils pour Windows PowerShell et des appels API. Chaque
utilisateur peut disposer de deux clés d'accès actives, ce qui est utile lorsque vous devez effectuer une
rotation des clés d'accès de l'utilisateur. Vous pouvez désactiver la clé d'accès d'un utilisateur, ce qui
signifie qu'elle ne peut pas être utilisée pour les appels API. Vous pouvez procéder ainsi lorsque vous
effectuez une rotation des clés ou pour révoquer l'accès API d'un utilisateur.
Vous pouvez supprimer une clé d'accès à tout moment. Toutefois, la suppression d'une clé d'accès est
définitive et vous ne pourrez plus récupérer celle-ci. (Vous pouvez toujours créer de nouvelles clés.)
Vous pouvez accorder des autorisations à vos utilisateurs pour répertorier et gérer leurs propres clés.
Pour de plus amples informations, veuillez consulter Autoriser les utilisateurs à gérer leurs propres
mots de passe, clés d'accès et clés SSH (p. 288).
Pour plus d'informations sur les informations d'identification utilisées avec AWS et IAM, consultez
Informations d'identification de sécurité temporaires (p. 244) et Types d'informations d'identification
de sécurité dans le manuel Référence générale d'Amazon Web Services.
Rubriques
• Création, modification et affichage des clés d'accès (AWS Management Console) (p. 90)
• Création, modification et affichage des clés d'accès (AWS CLI, l'Outils pour Windows PowerShell
et l'API AWS) (p. 91)
• Rotation des clés d'accès (AWS CLI, l'Outils pour Windows PowerShell et l'API AWS) (p. 92)
Création, modification et affichage des clés d'accès (AWS
Management Console)
Vous pouvez utiliser AWS Management Console pour gérer les clés d'accès des utilisateurs IAM.
Pour répertorier les clés d'accès d'un utilisateur
1.
2.
3.
Choisissez le nom utilisateur souhaité, puis sélectionnez l'onglet Security Credentials. Les clés
d'accès de l'utilisateur et l'état de celles-ci s'affiche.
Note
Seul l'ID de clé d'accès de l'utilisateur est visible. La clé d'accès secrète peut être
récupérée uniquement au moment de la création de la clé.
90
Clés d'accès
Pour créer, modifier ou supprimer les clés d'accès d'un utilisateur
1.
2.
3.
4.
Choisissez le nom utilisateur souhaité, puis sélectionnez l'onglet Security Credentials.
Au besoin, développez la section Access Keys et procédez comme suit :
• Pour créer une clé d'accès, choisissez Create Access Key, puis Download Credentials pour
enregistrer l'ID de clé d'accès et la clé d'accès secrète dans un fichier CSV sur votre ordinateur.
Stockez le fichier dans un emplacement sûr. Vous ne pourrez pas accéder à la clé d'accès
secrète à nouveau une fois que cette boîte de dialogue se sera fermée. Après avoir téléchargé
le fichier CSV, choisissez Close.
• Pour désactiver une clé d'accès active, choisissez Make Inactive.
• Pour réactiver une clé d'accès secrète inactive, choisissez Make Active.
• Pour supprimer une clé d'accès, choisissez Delete, puis Delete pour confirmer.
Création, modification et affichage des clés d'accès (AWS CLI,
l'Outils pour Windows PowerShell et l'API AWS)
Pour gérer les clés d'accès d'un utilisateur dans l'AWS CLI, l'Outils pour Windows PowerShell ou l'API
AWS, utilisez les commandes suivantes :
Pour créer une clé d'accès
• API AWS : CreateAccessKey
Pour désactiver ou réactiver une clé d'accès
• AWS CLI : aws iam update-access-key
• Outils pour Windows PowerShell : Update-IAMAccessKey
• API AWS : UpdateAccessKey
Pour répertorier les clés d'accès d'un utilisateur
• AWS CLI : aws iam list-access-keys
• Outils pour Windows PowerShell : Get-IAMAccessKey
• API AWS : ListAccessKeys
Pour déterminer quand une clé d'accès a été utilisée pour la dernière fois
• AWS CLI : aws iam get-access-key-last-used
• Outils pour Windows PowerShell : Get-IAMAccessKeyLastUsed
• API AWS : GetAccessKeyLastUsed
Pour supprimer une clé d'accès
• AWS CLI : aws iam delete-access-key
91
Clés d'accès
• Outils pour Windows PowerShell : Remove-IAMAccessKey
• API AWS : DeleteAccessKey
Rotation des clés d'accès (AWS CLI, l'Outils pour Windows
PowerShell et l'API AWS)
La bonne pratique en matière de sécurité consiste, en tant qu'administrateur, d'effectuer régulièrement
la rotation (changement) des clés d'accès des utilisateurs IAM de votre compte. Si vos utilisateurs
disposent des autorisations nécessaires, ils peuvent effectuer la rotation de leurs propres clés d'accès.
Pour plus d'informations sur la façon d'accorder des autorisations à vos utilisateurs pour effectuer la
rotation de leurs propres clés d'accès, consultez Autoriser les utilisateurs à gérer leurs propres mots de
passe, clés d'accès et clés SSH (p. 288).
Vous pouvez également appliquer une stratégie de mots de passe à votre compte nécessitant que
tous vos utilisateurs IAM effectuent régulièrement la rotation de leurs mots de passe. Vous pouvez
choisir à quelle fréquence ils peuvent le faire. Pour de plus amples informations, veuillez consulter
Définition d'une stratégie de mot de passe du compte pour les utilisateurs IAM (p. 79).
Important
Si vous utilisez les informations d'identification du compte racine AWS régulièrement, nous
vous recommandons d'effectuer également régulièrement leur rotation. La stratégie de mot de
passe du compte ne s'applique pas aux informations d'identification du compte racine AWS.
Les utilisateurs IAM ne peuvent pas gérer les informations d'identification du compte racine
AWS. Vous devez donc utiliser les informations d'identification du compte racine AWS (pas
celles d'un utilisateur) pour modifier les informations d'identification du compte racine AWS.
Notez que nous vous déconseillons de ne pas utiliser le compte racine AWS pour l'exécution
des tâches quotidiennes dans AWS.
La procédure suivante décrit le processus général permettant la rotation d'une clé d'accès sans
interrompre vos applications. Cette procédure indique les commandes de l'AWS CLI, l'Outils pour
Windows PowerShell et de l'API AWS pour effectuer la rotation des clés d'accès. Vous pouvez
également exécuter ces tâches à l'aide de la console. Pour plus d'informations, consultez Création,
modification et affichage des clés d'accès (AWS Management Console) (p. 90) dans la section cidessus.
1. Pendant que la première clé d'accès est encore active, créez une seconde clé d'accès qui sera
active par défaut. À ce stade, l'utilisateur dispose de deux clés d'accès actives.
2. Mettez à jour toutes les applications et tous les outils pour utiliser la nouvelle clé d'accès.
3. Déterminez si la première clé d'accès est toujours utilisée :
• AWS CLI : aws iam get-access-key-last-used
• Outils pour Windows PowerShell : Get-IAMAccessKeyLastUsed
• API AWS : GetAccessKeyLastUsed
Une des approches possibles consiste à attendre plusieurs jours, puis à vérifier si l'ancienne clé
d'accès a été utilisée avant de poursuivre.
4. Même si l'étape 3 (p. 92) n'indique aucune utilisation de l'ancienne clé, nous vous
recommandons de ne pas supprimer immédiatement la première clé d'accès. Définissez plutôt l'état
de la première clé d'accès sur Inactive.
• AWS CLI : aws iam update-access-key
92
Récupération des mots de passe ou clés d'accès perdus
• Outils pour Windows PowerShell : Update-IAMAccessKey
• API AWS : UpdateAccessKey
5. Utilisez uniquement la nouvelle clé d'accès pour confirmer que vos applications fonctionnent. À
ce stade, toutes les applications et tous les outils qui continuent d'utiliser la clé d'accès d'origine
arrêteront de fonctionner, car ils n'auront plus accès aux ressources AWS. Si vous rencontrer l'une
des application ou l'un de ces outils, vous pouvez définir son état de nouveau sur Active pour
réactiver la première clé d'accès. Revenez ensuite à l'étape 2 (p. 92) et mettez à jour cette
application afin d'utiliser la nouvelle clé.
6. Après avoir attendu un certain temps pour vous assurer que toutes les applications et tous les outils
ont été mis à jour, vus pouvez supprimer la première clé d'accès.
• Procédure de rotation des clés d'accès pour les utilisateurs IAM. Ce billet du Blog de sécurité AWS
fournit des informations supplémentaires sur la rotation des clés.
• Bonnes pratiques concernant IAM (p. 44). Cette page fournit des recommandations générales sur la
sécurisation de vos ressources AWS.
Récupération de vos mots de passe ou clés d'accès
perdus ou oubliés
Pour des raisons de sécurité, vous ne pouvez pas récupérer les mots de passe de la console ou la
partie clé d'accès secrète d'une paire de clés d'accès après leur création. Si vous perdez l'une de
ces informations, elle ne peut plus être récupérée et vous devez demander à votre administrateur de
réinitialiser votre mot de passe ou de créer une clé d'accès pour vous, le cas échéant.
Si vous avez les autorisations nécessaires pour créer vos propres clés d'accès, vous trouverez les
instructions permettant d'en créer de nouvelles à l'adresse Création, modification et affichage des clés
d'accès (AWS Management Console) (p. 90).
Vous devez suivre les bonnes pratiques (p. 48) et changer régulièrement vos clés d'accès AWS et
votre mot de passe. Dans AWS, vous changez les clés d'accès en les faisant tourner. Cela signifie que
vous créez une nouvelle clé d'accès, configurez votre ou vos applications pour l'utiliser et supprimez
l'ancienne. Vous n'êtes pas autorisé à avoir deux paires de clés d'accès actives en même temps pour
cette raison. Pour de plus amples informations, veuillez consulter Rotation des clés d'accès (AWS CLI,
l'Outils pour Windows PowerShell et l'API AWS) (p. 92).
Utilisation de Multi-Factor Authentication (MFA)
dans AWS
Pour plus de sécurité, nous vous recommandons de configurer l'authentification multi-facteurs (MultiFactor Authentication, MFA) pour mieux protéger vos ressources AWS. MFA ajoute une couche de
sécurité supplémentaire, car il est exigé que les utilisateurs entrent un code d'authentification unique à
partir d'un appareil d'authentification approuvé ou d'un SMS lorsqu'ils accèdent à des sites Web ou des
services AWS.
• Basé sur un jeton de sécurité. Ce type de MFA nécessite que vous attribuez un appareil MFA
(matériel ou virtuel) à l'utilisateur IAM ou le compte racine AWS. Un appareil virtuel est une
93
Multi-Factor Authentication (MFA)
application logicielle qui s'exécute sur un téléphone ou un autre appareil mobile qui émule un
appareil physique. Dans les deux cas, l'appareil génère un code numérique à six chiffres basé
sur un algorithme de mot de passe unique synchronisé. L'utilisateur doit entrer un code valide
à partir de l'appareil sur une deuxième page web lors de la connexion. Chaque appareil MFA
attribué à un utilisateur doit être unique ; un utilisateur ne peut pas entrer un code à partir de
l'appareil d'un autre utilisateur pour s'authentifier. Pour plus d'informations sur l'activation de
MFA basé sur un jeton de sécurité, consultez Activation d'un périphérique MFA physique (AWS
Management Console) (p. 99) et Activation d'un périphérique d'authentification multi-facteurs
(MFA) virtuel (p. 96).
• Basé sur SMS. Ce type de MFA nécessite que vous pouvez configuriez l'utilisateur IAM avec le
numéro de téléphone de l'appareil mobile compatible SMS de l'utilisateur. Lorsque l'utilisateur se
connecte, AWS envoie un code numérique à six chiffres par SMS à l'appareil mobile de l'utilisateur
et exige que l'utilisateur entre ce code sur une deuxième page web lors de la connexion. Notez que
MFA basé sur SMS est disponible uniquement pour les utilisateurs IAM. Vous ne pouvez pas utiliser
ce type de MFA avec le compte racine AWS. Pour plus d'informations sur l'activation de MFA basé
sur SMS, consultez EVALUATION - Activation de périphériques MFA basés sur SMS (p. 102).
Note
MFA SMS est actuellement disponible uniquement en tant que programme d'évaluation. Il
est disponible pour toute personne s'inscrivant pour y participer. Pour vous inscrire, suivez
les instructions de la page des détails concernant Multi-Factor Authentication.
Quelle que soit la façon dont l'utilisateur reçoit le code MFA numérique à six chiffres, il le saisit sur une
deuxième page du processus de connexion pour la AWS Management Console ou le transmet comme
paramètre à un appel d'API AWS STS pour obtenir des informations d'identification temporaires.
Cette section vous montre comment configurer MFA pour vos utilisateurs et configurer ces derniers
pour utiliser des périphériques jetons ou des SMS. Elle explique également comment synchroniser et
désactiver des périphériques jetons existants et ce qu'il faut faire lorsqu'un périphérique est perdu ou
ne fonctionne plus.
Note
• Lorsque vous activez MFA pour le compte de compte racine, cela affecte uniquement
les informations d'identification du compte racine. Les utilisateurs IAM du compte sont
des identités distinctes avec leurs propres informations d'identification, et chaque identité
dispose de sa propre configuration MFA.
• Si vous activez MFA sur votre compte AWS (l'utilisateur racine) et sur le compte
Amazon.com associé à la même adresse e-mail, vous serez invité à saisir deux codes MFA
différents chaque fois que vous vous connecterez tant qu'utilisateur racine.
Pour obtenir des réponses aux questions courantes concernant AWS MFA, accédez aux FAQ sur
AWS Multi-Factor Authentication.
Activation de périphériques MFA
La procédure générale suivante décrit comment configurer et utiliser l'authentification MFA et fournit
des liens vers des informations connexes.
1. Obtenez un périphérique jeton MFA ou un appareil mobile compatible avec SMS comme l'un des
périphériques suivants. Vous pouvez activer un seul périphérique MFA par utilisateur de compte
racine AWS ou utilisateur IAM, et ce périphérique peut uniquement être employé par l'utilisateur
spécifié.
• Un périphérique jeton matériel tel que l'un de ceux pris en charge par AWS répertoriés à la page
Authentification multi-facteurs (MFA).
94
• Un périphérique jeton virtuel, qui est une application logicielle conforme à RFC 6238, un
algorithme compatible avec la norme TOTP (Time-Based One-Time Password). Vous pouvez
installer l'application sur un appareil mobile, tel qu’une tablette ou un smartphone. Pour consulter
la liste de quelques applications prises en charge pouvant être utilisées en tant que périphériques
MFA virtuels, reportez-vous à la section Applications MFA virtuelles de la page Authentification
multi-facteurs (MFA).
• Un téléphone mobile capable de recevoir des SMS standard.
Note
Si vous choisissez d'utiliser l'authentification MFA basée sur SMS, des frais relatifs aux
SMS peuvent vous être facturés par votre opérateur mobile.
L'authentification MFA basée sur SMS est uniquement disponible pour les utilisateurs
IAM ; vous ne pouvez pas y avoir recours pour l'utilisateur racine du compte AWS.
2. Activez le périphérique MFA. L'activation d'un périphérique comporte deux étapes. Tout d'abord,
vous créez une entité de périphérique MFA dans IAM. Ensuite, vous associez l'entité de
périphérique MFA à l'utilisateur IAM. Vous pouvez exécuter ces tâches dans AWS Management
Console, l'AWS CLI, les Outils pour Windows PowerShell ou l'API IAM.
Pour plus d'informations sur l'activation de chaque type de périphérique MFA, consultez les
rubriques suivantes :
• Périphérique MFA physique : Activation d'un périphérique MFA physique (AWS Management
Console) (p. 99)
• Périphérique MFA virtuel : Activation d'un périphérique d'authentification multi-facteurs (MFA)
virtuel (p. 96)
• Périphérique MFA basé sur SMS : EVALUATION - Activation de périphériques MFA basés sur
SMS (p. 102)
3. Utilisez le périphérique MFA lorsque vous vous connectez ou accédez aux ressources AWS.
Remarques :
• Pour accéder à un site web d'AWS vous devez obtenir un code MFA du périphérique en plus du
nom utilisateur et du mot de passe habituels. Si AWS détermine que l'authentification MFA basée
sur SMS est activée pour l'utilisateur IAM sous lequel vous vous connectez, le code MFA est
envoyé automatiquement au numéro de téléphone configuré.
• Pour accéder aux API protégées par MFA, vous avez besoin d'un code MFA, de l'identifiant du
périphérique MFA (numéro de série d'un périphérique physique ou ARN d'un périphérique virtuel
ou basé sur SMS défini dans AWS), ainsi que de l'ID de clé d'accès et de la clé d'accès secrète
habituels.
Note
Au cours de la phase d'évaluation publique de l'authentification MFA basée sur SMS,
vous pouvez vous authentifier avec votre périphérique SMS dans AWS Management
Console uniquement. Il n'est pas possible de transmettre les informations MFA d'un
périphérique MFA basé sur SMS à des API AWS STS pour demander des informations
d'identification temporaires.
Pour plus d'informations, consultez Utilisation d'appareils MFA avec votre page de connexion
IAM (p. 58)
Rubriques
• Activation d'un périphérique d'authentification multi-facteurs (MFA) virtuel (p. 96)
• Activation d'un périphérique MFA physique (AWS Management Console) (p. 99)
• EVALUATION - Activation de périphériques MFA basés sur SMS (p. 102)
95
• Activer et gérer des périphériques MFA virtuels (AWS CLI, Outils pour Windows PowerShell ou API
AWS) (p. 103)
Activation d'un périphérique d'authentification multi-facteurs (MFA) virtuel
Un périphérique MFA virtuel utilise une application logicielle pour générer un code d'authentification
à six chiffres compatible avec la norme TOTP (Time-Based One-Time Password), comme décrit
dans le document RFC 6238. L'application peut être exécutée sur n'importe quel appareil mobile,
notamment les smartphones. Avec la plupart des applications MFA virtuelles, vous pouvez héberger
plusieurs périphériques MFA virtuels, ce qui leur confère un avantage pratique par rapport au matériel
MFA. Toutefois, étant donné qu'une application MFA virtuelle peut s'exécuter sur un périphérique
moins sécurisé, tel qu'un smartphone, elle risque de ne pas offrir le même niveau de sécurité qu'un
périphérique MFA matériel.
Vous pouvez activer un seul périphérique MFA par utilisateur de compte AWS ou utilisateur IAM, et ce
périphérique peut uniquement être employé par l'utilisateur spécifié. Bien que certaines applications
logicielles MFA virtuelles semblent prendre en charge plusieurs comptes, chaque compte que vous
ajoutez représente un périphérique MFA virtuel unique qui ne peut être associé qu'à un seul utilisateur.
Pour obtenir une liste des applications MFA virtuelles que vous pouvez utiliser sur des smartphones
et des tablettes (notamment Google Android, Apple iPhone et iPad, et Windows Phone), accédez à
la section Applications MFA virtuelles sur la page http://aws.amazon.com/iam/details/mfa/. Notez que
AWS nécessite une application MFA virtuelle générant un code OTP à six chiffres.
Procédez de la manière suivante pour activer et gérer des périphériques MFA à l'aide de l'AWS
Management Console. Pour activer et gérer des périphériques MFA dans la ligne de commande, ou
pour utiliser l'API, consultez Activer et gérer des périphériques MFA virtuels (AWS CLI, Outils pour
Windows PowerShell ou API AWS) (p. 103).
Important
Lorsque vous configurez un périphérique MFA virtuel pour l'utiliser avec AWS, nous vous
recommandons d'enregistrer une copie du code QR ou la clé secrète dans un emplacement
sécurisé. De cette manière, si vous perdez le téléphone ou si vous devez réinstaller
l'application logicielle MFA pour une raison quelconque, vous pouvez reconfigurer l'application
de sorte qu'elle utilise le même MFA virtuel sans devoir créer à nouveau un MFA virtuel dans
AWS pour l'utilisateur ou le compte racine.
Activer un périphérique MFA virtuel pour un utilisateur IAM (AWS Management Console)
Vous pouvez utiliser IAM dans AWS Management Console pour activer un périphérique MFA virtuel
pour un utilisateur IAM dans votre compte.
Note
Pour configurer l'authentification MFA, vous devez avoir accès physique au matériel sur
lequel le périphérique MFA virtuel de l'utilisateur est hébergé. Par exemple, si vous configurez
l'authentification MFA pour un utilisateur qui utilisera un périphérique MFA virtuel s'exécutant
sur un smartphone, vous devez disposer du smartphone pour terminer l'assistant. De ce fait,
vous pouvez préférer laisser les utilisateurs configurer et gérer leurs propres périphériques
MFA virtuels. Dans ce cas, vous devez accorder aux utilisateurs l'autorisation d'exécuter les
actions IAM nécessaires. Pour obtenir plus d'informations et un exemple de stratégie IAM
accordant ces autorisations, consultez Autoriser les utilisateurs à gérer uniquement leurs
propres appareils MFA virtuels (p. 292).
96
Pour activer un périphérique MFA virtuel pour un utilisateur
1.
2.
3.
Dans la liste User Name, choisissez le nom utilisateur MFA prévu.
4.
Choisissez l'onglet Security Credentials, puis Manage MFA Device.
5.
Dans l'assistant Manage MFA Device, choisissez A virtual MFA device, puis Next Step.
IAM génère et affiche les informations de configuration du périphérique MFA virtuel, notamment
un graphique de code QR. Le graphique est une représentation de la « clé de configuration
secrète » que l'on peut saisir manuellement sur des périphériques qui ne prennent pas en charge
les codes QR.
6.
Ouvrez votre application MFA virtuelle. (Pour obtenir une liste des applications que vous pouvez
utiliser pour héberger des périphériques MFA virtuels, consultez Applications MFA virtuelles.)
Si l'application MFA virtuelle prend en charge plusieurs comptes (plusieurs périphériques MFA
virtuels), choisissez l'option permettant de créer un compte (un nouveau périphérique MFA virtuel).
7.
Déterminez si l'application MFA prend en charge les codes QR, puis effectuez l'une des actions
suivantes :
• Utilisez l'application pour analyser le code QR. Par exemple, vous pouvez choisir l'icône de
caméra ou une option similaire à Scan code, puis utiliser la caméra du périphérique pour
analyser le code.
• Dans l'assistant Manage MFA Device, choisissez Show secret key for manual configuration,
puis saisissez la clé de configuration secrète dans votre application MFA.
Une fois que vous avez terminé, le périphérique MFA virtuel commence à générer des mots de
passe uniques.
8.
Dans l'assistant Manage MFA Device, dans la zone Authentication Code 1, saisissez le mot
de passe unique qui s'affiche actuellement sur le périphérique MFA virtuel. Attendez jusqu'à
30 secondes pour que le périphérique génère un nouveau mot de passe unique. Puis saisissez le
second mot de passe unique dans la zone Authentication Code 2. Choisissez Active Virtual MFA.
Le périphérique MFA virtuel est maintenant prêt à être utilisé avec AWS. Pour plus d'informations sur
l'utilisation de l'authentification MFA avec AWS Management Console, consultez Utilisation d'appareils
MFA avec votre page de connexion IAM (p. 58).
Activer un périphérique MFA virtuel votre compte racine AWS (AWS Management Console)
Vous pouvez utiliser IAM dans AWS Management Console pour configurer et activer un périphérique
MFA virtuel pour votre compte racine AWS.
Important
Pour gérer des périphériques MFA pour le compte AWS, vous devez être connecté à AWS à
l'aide des informations d'identification de votre compte racine. Vous ne pouvez pas gérer les
périphériques MFA pour le compte racine avec d'autres informations d'identification.
Note
Si vous activez l'authentification MFA sur votre compte AWS (l'utilisateur racine) et sur le
compte Amazon.com associé à la même adresse e-mail, vous serez invité à saisir deux codes
MFA différents chaque fois que vous vous connecterez tant qu'utilisateur racine.
97
Pour configurer et activer un périphérique MFA virtuel à utiliser avec votre compte racine
1.
2.
Effectuez l'une des actions suivantes :
• Option 1 : Choisissez Dashboard, et sous Security Status, développez Activate MFA on your
root account.
• Option 2 : À droite de la barre de navigation, choisissez le nom de votre compte, et cliquez sur
Security Credentials. Au besoin, choisissez Continue to Security Credentials. Puis développez
la section Multi-Factor Authentication (MFA) sur la page.
3.
Choisissez Manage MFA ou Activate MFA, en fonction de l'option que vous choisissez à l'étape
précédente.
4.
Dans l'assistant, choisissez A virtual MFA device, puis Next Step.
5.
Confirmez qu'une application MFA virtuelle est installée sur le périphérique, puis choisissez
Next Step. IAM génère et affiche les informations de configuration du périphérique MFA virtuel,
notamment un graphique de code QR. Le graphique est une représentation de la clé de
configuration secrète que l'on peut saisir manuellement sur des périphériques qui ne prennent pas
en charge les codes QR.
6.
Toujours dans l'assistant Manage MFA Device, ouvrez l'application MFA virtuelle sur le
périphérique.
7.
Si le logiciel MFA virtuel prend en charge plusieurs comptes (plusieurs périphériques MFA
virtuels), choisissez l'option permettant de créer un compte (un nouveau périphérique virtuel).
8.
La manière la plus simple de configurer l'application consiste à utiliser l'application pour analyser
le code QR. Si vous ne pouvez pas analyser le code, vous pouvez saisir les informations de
configuration manuellement.
• Pour utiliser le code QR pour configurer le périphérique MFA virtuel, suivez les instructions
de l'application pour l'analyse du code. Par exemple, vous pouvez avoir besoin d'appuyer sur
l'icône de caméra ou sur une commande similaire à Scan account barcode, puis d'utiliser la
caméra du périphérique pour analyser le code QR.
• Si vous ne pouvez pas analyser le code, saisissez les informations de configuration
manuellement en entrant la valeur de Clé de configuration secrète dans l'application. Par
exemple, pour faire cela dans l'application MFA virtuelle AWS, choisissez Manually add
account, puis saisissez la clé de configuration secrète et choisissez Create.
98
Important
Faites une sauvegarde sécurisée du code QR ou de la clé de configuration secrète ou
assurez-vous d'activer plusieurs périphériques MFA virtuels pour votre compte. Si le
périphérique MFA virtuel n'est pas disponible (par exemple, si vous perdez le smartphone
sur lequel le périphérique MFA virtuel est hébergé), vous ne pourrez pas vous connecter
à votre compte et vous devrez contacter le service clientèle pour supprimer la protection
MFA du compte.
Note
Le code QR et la clé de configuration secrète générés par IAM sont liés à votre compte
AWS et ne peuvent pas être utilisés avec un compte différent. En revanche, ils peuvent
être réutilisés pour configurer un nouveau périphérique MFA pour votre compte si vous
perdez l'accès au périphérique MFA d'origine.
Le périphérique commence à générer des numéros à six chiffres.
9.
Dans l'assistant Manage MFA Device, dans la zone Authentication Code 1, entrez le numéro à
six chiffres qui s'affiche actuellement sur le périphérique MFA. Attendez jusqu'à 30 secondes
pour que le périphérique génère un nouveau numéro, puis saisissez celui-ci dans la zone
Authentication Code 2.
10. Cliquez sur Next Step, puis sur Finish.
Le périphérique est prêt à être utilisé avec AWS. Pour plus d'informations sur l'utilisation de
l'authentification MFA avec AWS Management Console, consultez Utilisation d'appareils MFA avec
votre page de connexion IAM (p. 58).
Remplacer un périphérique MFA virtuel ou le soumettre à une « rotation »
Vous pouvez disposer d'un seul périphérique MFA virtuel attribué à un utilisateur à la fois. Si
l'utilisateur perd un périphérique ou a besoin de le remplacer pour une raison quelconque, vous devez
désactiver l'ancien périphérique. Vous pouvez alors ajouter le nouveau périphérique pour l'utilisateur.
• Pour désactiver le périphérique actuellement associé à un utilisateur, consultez la page
Désactivation des périphériques MFA (p. 107).
• Pour ajouter un périphérique MFA virtuel de remplacement pour un utilisateur IAM, suivez les étapes
de la procédure Activer un périphérique MFA virtuel pour un utilisateur IAM (AWS Management
Console) (p. 96) ci-dessus.
• Pour ajouter un périphérique MFA virtuel de remplacement pour l'utilisateur racine du compte, suivez
les étapes de la procédure Activer un périphérique MFA virtuel votre compte racine AWS (AWS
Management Console) (p. 97) ci-dessus.
Activation d'un périphérique MFA physique (AWS Management Console)
Rubriques
• Activer un périphérique MFA physique pour un utilisateur IAM (AWS Management
Console) (p. 100)
• Activer un périphérique MFA physique pour l'utilisateur racine du compte AWS (AWS Management
Console) (p. 100)
• Remplacer un périphérique MFA physique ou le soumettre à une « rotation » (p. 102)
99
Vous pouvez activer un périphérique MFA physique dans l'AWS Management ConsoleAWS
Management Console, l'interface ligne de commande ou les API IAM. La procédure suivante
décrit comment utiliser l'AWS Management Console pour activer le périphérique pour un utilisateur
dans votre compte AWS. Pour activer un périphérique MFA pour votre compte racine, consultez
Activer un périphérique MFA physique pour l'utilisateur racine du compte AWS (AWS Management
Console) (p. 100).
Vous pouvez activer un seul périphérique MFA (de n'importe quel type) par utilisateur racine du
compte ou utilisateur IAM.
Note
Si vous souhaitez activer le périphérique dans la ligne de commande, utilisez aws iam
enable-mfa-device. Pour activer le périphérique MFA avec l'API de IAM, utilisez l'action
EnableMFADevice.
Activer un périphérique MFA physique pour un utilisateur IAM (AWS Management Console)
Pour utiliser l'AWS Management Console pour activer un périphérique MFA physique pour un
utilisateur IAM
1.
2.
3.
Choisissez le nom utilisateur pour lequel vous souhaitez activer l'authentification MFA, puis
sélectionnez l'onglet Security Credentials.
4.
Choisissez Manage MFA Device.
5.
Dans l'assistant Manage MFA Device, choisissez A hardware MFA device, puis Next Step.
6.
Saisissez le numéro de série du périphérique. Le numéro de série se situe généralement l'arrière
du périphérique.
7.
Dans la zone Authentication Code 1, saisissez le numéro à six chiffres affiché sur le périphérique
MFA. Vous devrez peut-être appuyer sur le bouton situé à l'avant du périphérique pour afficher le
numéro.
8.
Attendez 30 secondes que le périphérique actualise le code, puis saisissez le numéro à six
chiffres suivant dans la zone Authentication Code 2. Vous devrez peut-être appuyer à nouveau sur
le bouton situé à l'avant du périphérique pour afficher le second numéro.
9.
Choisissez Next Step.
Le périphérique est prêt à être utilisé avec AWS. Pour plus d'informations sur l'utilisation de
l'authentification MFA avec l'AWS Management Console, consultez Utilisation d'appareils MFA avec
votre page de connexion IAM (p. 58).
Activer un périphérique MFA physique pour l'utilisateur racine du compte AWS (AWS
Management Console)
Vous pouvez gérer les périphériques MFA pour l'utilisateur racine du compte AWS uniquement avec
l'AWS Management Console.
100
Pour utiliser l'AWS Management Console afin d'activer un périphérique MFA pour votre
compte racine AWS
1.
Important
Pour gérer des périphériques MFA pour le compte AWS, vous devez utiliser les
informations d'identification de votre compte racine pour vous connecter à AWS. Vous ne
pouvez pas gérer les périphériques MFA pour le compte racine avec d'autres informations
d'identification.
Note
Si vous activez l'authentification MFA sur votre compte AWS (l'utilisateur racine) et sur le
compte Amazon.com associé à la même adresse e-mail, vous serez invité à saisir deux
codes MFA différents chaque fois que vous vous connecterez tant qu'utilisateur racine.
2.
• Option 1 : Choisissez Dashboard, et sous Security Status, développez Activate MFA on your
root account.
• Option 2 : À droite de la barre de navigation, choisissez le nom de votre compte, et cliquez sur
Security Credentials. Au besoin, choisissez Continue to Security Credentials. Puis développez
la section Multi-Factor Authentication (MFA) sur la page.
3.
Choisissez Manage MFA ou Activate MFA, en fonction de l'option que vous choisissez à l'étape
précédente.
4.
Dans l'assistant, choisissez A hardware MFA device, puis Next Step.
5.
Dans la zone Serial Number, entrez le numéro de série situé à l'arrière du périphérique MFA.
6.
Dans la zone Authentication Code 1, saisissez le numéro à six chiffres affiché sur le périphérique
MFA. Vous devrez peut-être appuyer sur le bouton situé à l'avant du périphérique pour afficher le
numéro.
101
7.
Attendez 30 secondes que le périphérique actualise le code, puis saisissez le numéro à six
chiffres suivant dans la zone Authentication Code 2. Vous devrez peut-être appuyer à nouveau sur
le bouton situé à l'avant du périphérique pour afficher le second numéro.
8.
Choisissez Next Step. Le périphérique MFA est à présent associé au compte AWS.
La prochaine fois que vous utiliserez les informations d'identification de votre compte AWS, vous
devrez saisir un code du périphérique MFA.
Remplacer un périphérique MFA physique ou le soumettre à une « rotation »
Vous pouvez disposer d'un seul périphérique MFA attribué à un utilisateur à la fois. Si l'utilisateur
perd un périphérique ou a besoin de le remplacer pour une raison quelconque, vous devez désactiver
l'ancien périphérique. Vous pouvez alors ajouter le nouveau périphérique pour l'utilisateur.
• Pour désactiver le périphérique actuellement associé à un utilisateur, consultez la page
Désactivation des périphériques MFA (p. 107).
• Pour ajouter un périphérique MFA physique de remplacement pour un utilisateur IAM, suivez
les étapes de la procédure Activer un périphérique MFA physique pour un utilisateur IAM (AWS
Management Console) (p. 100) ci-dessus.
• Pour ajouter un périphérique MFA virtuel de remplacement pour l'utilisateur racine du compte, suivez
les étapes de la procédure Activer un périphérique MFA physique pour l'utilisateur racine du compte
AWS (AWS Management Console) (p. 100) ci-dessus.
EVALUATION - Activation de périphériques MFA basés sur SMS
S'inscrire pour la version d'évaluation
Actuellement, l'authentification MFA basée sur SMS est disponible en tant que programme
d'évaluation uniquement. Elle est accessible à toute personne s'inscrivant pour participer à
l'évaluation. Pour vous inscrire, suivez les instructions de la page de détails se rapportant à
l'authentification multi-facteurs (MFA).
Un périphérique MFA basé sur SMS peut être n'importe quel appareil mobile avec un numéro de
téléphone capable de recevoir des SMS standard. Lorsqu'un code MFA est requis, AWS l'envoie au
numéro de téléphone configuré pour l'utilisateur IAM.
Note
L'authentification MFA basée sur SMS peut être utilisée uniquement pour des utilisateurs
IAM. Elle n'est pas disponible pour le compte racine AWS. Pour protéger l'utilisateur racine
à l'aide de l'authentification MFA, vous devez utiliser un périphérique jeton MFA basé sur le
matériel (p. 99) ou virtuel (basé sur les logiciels) (p. 96).
Rubriques
• Activer un périphérique MFA basé sur SMS pour un utilisateur IAM (AWS Management
Console) (p. 103)
• Modifier le numéro de téléphone d'un utilisateur IAM pour l'authentification MFA basée sur
SMS (p. 103)
102
Activer un périphérique MFA basé sur SMS pour un utilisateur IAM (AWS Management
Console)
Note
Actuellement, vous pouvez gérer MFA SMS uniquement dans l'AWS Management Console.
Dans AWS Management Console, vous pouvez utiliser IAM pour configurer le numéro de téléphone
d'un utilisateur IAM afin d'activer l'authentification MFA basée sur SMS.
Pour activer l'authentification MFA basée sur SMS pour un utilisateur IAM (console)
1.
Inscrivez-vous pour obtenir la version d’évaluation de la fonction d'authentification MFA basée
sur SMS. Pour vous inscrire, suivez les instructions de la page de détails se rapportant à
l'authentification multi-facteurs (MFA).
2.
3.
4.
Dans la liste User Name, sélectionnez le nom (pas la case à cocher) de l'utilisateur MFA requis.
5.
Faites défiler la liste jusqu'à la section Security Credentials, puis choisissez Manage MFA Device.
6.
Dans l'assistant Manage MFA Device, sélectionnez An SMS MFA device, puis Next Step.
7.
Entrez le numéro de téléphone vers lequel envoyer les codes MFA pour cet utilisateur IAM, puis
choisissez Next Step.
8.
Un code d'authentification à six chiffres est immédiatement envoyé au numéro de téléphone
spécifié pour vérification. Tapez le code à six chiffres, puis cliquez sur Next Step. Si vous ne
recevez pas le code dans un laps de temps raisonnable, choisissez Resend Code. Notez que le
service SMS ne garantit pas le délai de livraison.
9.
Si AWS vérifie avec succès le code, l'assistant termine l'opération. Choisissez Finish pour fermer
l'assistant.
Modifier le numéro de téléphone d'un utilisateur IAM pour l'authentification MFA basée sur
SMS
Pour modifier le numéro de téléphone du périphérique MFA basé sur SMS affecté à un utilisateur IAM,
vous devez supprimer le périphérique MFA actuel et en créer un nouveau avec le nouveau numéro de
téléphone. Pour supprimer le périphérique, consultez Désactivation des périphériques MFA (p. 107).
Pour créer un nouveau périphérique, consultez les procédures détaillées précédemment dans cette
rubrique.
Activer et gérer des périphériques MFA virtuels (AWS CLI, Outils pour
Windows PowerShell ou API AWS)
La liste suivante détaille les commandes de ligne de commande ou les actions d'API que vous pouvez
utiliser pour activer un périphérique MFA virtuel.
Note
Vous devez utiliser l'AWS Management Console pour gérer tout périphérique MFA pour
l'utilisateur racine de votre compte AWS. Vous ne pouvez pas gérer le périphérique MFA pour
l'utilisateur racine avec l'API AWS, AWS CLI, Outils pour Windows PowerShell ni avec tout
autre outil de ligne de commande.
Pour l'instant, vous pouvez gérer les périphériques MFA SMS uniquement à l'aide de l'AWS
Management Console.
103
Lorsque vous activez un périphérique MFA à partir de l'AWS Management Console, la console se
charge pour vous d'une grande partie de la procédure. En revanche, si vous créez un périphérique
virtuel à l'aide de l'AWS CLI, des Outils pour Windows PowerShell ou de l'API AWS vous devez
exécuter les étapes manuellement et dans l'ordre approprié. Par exemple, pour créer un périphérique
MFA virtuel, vous devez créer l'objet IAM, extraire le code sous forme de chaîne ou de graphique de
code QR, puis synchroniser le périphérique et l'associer à un utilisateur IAM. Consultez la section
Exemples de New-IAMVirtualMFADevice pour plus d'informations. Dans le cas d'un périphérique
physique, vous ignorez l'étape de création et passez directement à la synchronisation du périphérique
et l'association à un utilisateur.
Pour créer l'entité de périphérique virtuel dans IAM pour représenter un périphérique MFA virtuel
Ces commandes fournissent un ARN pour le périphérique qui est utilisé à la place du numéro de série
dans un grand nombre des commandes suivantes.
• AWS CLI : aws iam create-virtual-mfa-device
• Outils pour Windows PowerShell : New-IAMVirtualMFADevice
• API AWS : CreateVirtualMFADevice
Pour activer un périphérique MFA pour utilisation avec AWS
Ces commandes synchronisent le périphérique avec AWS et l'associent à un utilisateur ou le compte
racine. S'il s'agit d'un périphérique virtuel, utilisez son ARN en tant que numéro de série.
• AWS CLI : aws iam enable-mfa-device
• Outils pour Windows PowerShell : Enable-IAMMFADevice
• API AWS : EnableMFADevice
Pour désactiver un périphérique
Ces commandes dissocient le périphérique de l'utilisateur et le désactivent. S'il s'agit d'un périphérique
virtuel, utilisez son ARN en tant que numéro de série. Vous devez également supprimer l'entité de
périphérique virtuel séparément.
• AWS CLI : aws iam deactivate-mfa-device
• Outils pour Windows PowerShell : Disable-IAMMFADevice
• API AWS : DeactivateMFADevice
Pour afficher la liste des entités de périphériques MFA virtuels
• AWS CLI : aws iam list-virtual-mfa-devices
• Outils pour Windows PowerShell : Get-IAMVirtualMFADevice
• API AWS : ListVirtualMFADevices
Pour resynchroniser un périphérique MFA
Utilisez les commandes suivantes si le périphérique génère des codes qui ne sont pas reconnus par
AWS. S'il s'agit d'un périphérique virtuel, utilisez son ARN en tant que numéro de série.
• AWS CLI : aws iam resync-mfa-device
• Outils pour Windows PowerShell : Sync-IAMMFADevice
• API AWS : ResyncMFADevice
Pour supprimer une entité de périphérique MFA virtuel dans IAM
104
Après avoir dissocié le périphérique de l'utilisateur, vous pouvez supprimer l'entité de périphérique.
• AWS CLI : aws iam delete-virtual-mfa-device
• Outils pour Windows PowerShell : Remove-IAMVirtualMFADevice
• API AWS : DeleteVirtualMFADevice
Vérification du statut de l'authentification MFA
Utilisez la console IAM pour vérifier si un périphérique MFA valide est activé pour un compte racine
AWS ou l'utilisateur IAM.
Pour vérifier le statut de l'authentification MFA d'un compte racine
1.
Connectez-vous à l'AWS Management Console avec les informations d'identification de votre
compte (racine) AWS, puis ouvrez la console IAM à l'adresse https://console.aws.amazon.com/
iam/.
2.
Vérifiez sous Security Status si l'authentification MFA est activée ou désactivée. Si
l'authentification MFA n'a pas été activée, un symbole d'alerte (
Activate MFA on your root account.
) s'affiche en regard de
Si vous souhaitez activer l'authentification MFA pour le compte, consultez Activer un périphérique MFA
virtuel votre compte racine AWS (AWS Management Console) (p. 97) ou Activer un périphérique
MFA physique pour l'utilisateur racine du compte AWS (AWS Management Console) (p. 100).
Pour vérifier le statut de l'authentification MFA d'un utilisateur IAM
1.
2.
3.
Choisissez le nom utilisateur dont vous souhaitez vérifier le statut d'authentification MFA, puis
sélectionnez l'onglet Security Credentials.
4.
Si aucun périphérique MFA n'est actif pour l'utilisateur, la console affiche No en regard de MultiFactor Authentication Device. Si un périphérique MFA est activé pour l'utilisateur, l'élément MultiFactor Authentication Device affiche une valeur pour le périphérique :
• L'ARN dans AWS pour un périphérique virtuel, comme
arn:aws:iam::123456789012:mfa/username
• L'ARN dans AWS pour un périphérique SMS, comme arn:aws:iam::123456789012:smsmfa/username
• Le numéro de série du périphérique physique (généralement le numéro situé à l'arrière du
périphérique), comme GAHT12345678
Si vous souhaitez modifier le paramètre actuel, choisissez Manage MFA Device Pour obtenir des
informations sur le périphérique virtuel, consultez Activation d'un périphérique d'authentification multifacteurs (MFA) virtuel (p. 96). Pour obtenir des informations sur le périphérique physique, consultez
Activation d'un périphérique MFA physique (AWS Management Console) (p. 99).
Synchroniser des périphériques MFA
Il est possible qu'un périphérique MFA ne soit plus synchronisé. Si le périphérique n'est pas
synchronisé lorsque l'utilisateur tente de l'utiliser, la tentative de connexion échoue. Si l'utilisateur
se connecte à AWS Management Console par le biais du périphérique MFA, IAM l'invite à le
resynchroniser.
105
Console IAM
Pour resynchroniser un périphérique MFA pour un utilisateur à l'aide de la console
1.
2.
Dans le volet de navigation, choisissez Users, puis sélectionnez le nom de l'utilisateur dont le
périphérique MFA doit être resynchronisé.
3.
4.
Dans l'assistant Manage MFA Device, choisissez Resynchronize MFA device, puis sélectionnez
Next Step.
5.
Entrez les deux prochains codes générés séquentiellement à partir du périphérique dans les
champs Authentication Code 1 et Authentication Code 2. Choisissez ensuite Next Step.
AWS CLI
AWS CLI : aws iam resync-mfa-device
• Périphérique MFA virtuel : spécifiez l'ARN (Amazon Resource Name) du périphérique en tant que
SerialNumber.
$ aws iam resync-mfa-device --user-name Bob --serial-number
arn:aws:iam::123456789012:mfa/BobsMFA --authentication-code-1 123456 -authentication-code-2 987654
• Périphérique MFA physique : spécifiez le numéro de série du périphérique physique en tant que
SerialNumber. Le format est spécifique au fournisseur.
PS C:\>Sync-IAMMFADevice -SerialNumber ABCD12345678 -AuthenticationCode1
123456 -AuthenticationCode2 987654 -UserName Bob
Outils pour Windows PowerShell
Outils pour Windows PowerShell : Sync-IAMMFADevice
• Périphérique MFA virtuel : spécifiez l'ARN (Amazon Resource Name) du périphérique en tant que
SerialNumber.
PS C:\>Sync-IAMMFADevice -UserName Bob -SerialNumber
arn:aws:iam::123456789012:mfa/BobsMFA -AuthenticationCode1 123456 AuthenticationCode2 987654
• Périphérique MFA physique : spécifiez le numéro de série du périphérique physique en tant que
SerialNumber. Le format est spécifique au fournisseur.
PS C:\>Sync-IAMMFADevice -UserName Bob -SerialNumber ABCD12345678 AuthenticationCode1 123456 -AuthenticationCode2 987654
API IAM
Pour ceux qui préfèrent utiliser l'API, IAM propose un appel d'API qui effectue la synchronisation. Dans
ce cas, nous vous recommandons d'accorder à vos utilisateurs MFA l'autorisation d'accès à cet appel
106
d'API. Vous devez créer un outil basé sur cet appel d'API qui permet aux utilisateurs de resynchroniser
leurs périphériques chaque fois que cela est nécessaire.
API IAM : ResyncMFADevice
Désactivation des périphériques MFA
Vous pouvez désactiver temporairement un périphérique MFA.
Note
Si vous utilisez l'API ou CLI pour supprimer un utilisateur de votre compte AWS, vous devez
désactiver ou supprimer le périphérique MFA de l'utilisateur dans le cadre du processus de
suppression de l'utilisateur. Pour plus d'informations sur la suppression d'utilisateurs, consultez
Gestion des utilisateurs IAM (p. 71).
Pour utiliser la console pour désactiver un périphérique MFA pour un utilisateur
1.
2.
Dans le volet de navigation, choisissez Users, puis sélectionnez le nom de l'utilisateur dont vous
souhaitez que le périphérique MFA soit supprimé.
3.
4.
Dans l'assistant Manage MFA Device, choisissez Deactivate MFA device, puis Next Step.
Le périphérique est supprimé de AWS et ne peut plus être utilisé pour se connecter ou authentifier
des demandes tant qu'il n'est pas réactivé et associé à un utilisateur ou un compte racine AWS.
Pour désactiver le périphérique MFA pour votre compte racine AWS
1.
Utilisez vos informations d'identification racines pour vous connecter à AWS Management
Console.
Important
Pour gérer des périphériques MFA pour le compte AWS, vous devez vous connecter
à AWS avec es informations d'identification de votre compte racine. Vous ne pouvez
pas gérer les périphériques MFA pour le compte racine avec d'autres informations
d'identification.
2.
Sur la barre de navigation, choisissez le nom de votre compte, puis Security Credentials. Si une
invite s'affiche, choisissez Continue to Security Credentials.
107
3.
Développez la section Multi-Factor Authentication (MFA) sur la page.
4.
Sur la ligne du périphérique MFA que vous souhaitez désactiver, choisissez Edit rule.
Le périphérique MFA est désactivé pour le compte AWS.
Pour utiliser l'AWS CLI, l'Outils pour Windows PowerShell ou l'API AWS pour désactiver un
périphérique MFA pour un utilisateur
• AWS CLI : aws iam deactivate-mfa-device
• Outils pour Windows PowerShell : Disable-IAMMFADevice
• API AWS : DeactivateMFADevice
Que faire si un périphérique MFA est perdu ou cesse de
fonctionner ?
Si un périphérique MFA cesse de fonctionner, ou est perdu ou détruit, et que vous ne pouvez pas vous
connecter à AWS Management Console, vous devez désactiver ce périphérique. AWS peut vous aider
à le désactiver. La méthode de résolution est différente, selon que le périphérique MFA est affecté au
compte racine ou à un utilisateur du compte AWS.
Note
Si le périphérique semble fonctionner correctement, mais que vous ne pouvez pas accéder à
vos ressources AWS, il est possible qu'il ne soit simplement plus synchronisé avec le système
AWS. Pour plus d'informations sur la synchronisation d'un périphérique MFA, consultez
Synchroniser des périphériques MFA (p. 105).
Pour obtenir de l'aide pour un périphérique MFA associé à un compte racine AWS.
1.
Accédez à la page AWS Contactez-nous pour obtenir de l'aide pour la désactivation de MFA
AWS et pouvoir accéder temporairement aux pages sécurisées du site web AWS et d'AWS
Management Console en utilisant simplement votre nom utilisateur et mot de passe.
2.
Modifiez votre mot de passe AWS (p. 88) au cas où un pirate aurait volé le périphérique
d'authentification et détiendrait également votre mot de passe actuel.
108
3.
Si vous utilisez un périphérique MFA matériel, contactez le fournisseur tiers pour qu'il dépanne ou
remplace le périphérique. S'il s'agit d'un périphérique MFA virtuel, supprimez son ancienne entité
de périphérique MFA virtuel dans IAM avant d'en créer une nouvelle.
4.
Après la création du nouveau périphérique MFA physique ou la suppression de l'ancienne entrée
sur l'appareil mobile, revenez sur le site web AWS et activez le périphérique MFA pour réactiver
MFA AWS pour votre compte AWS. Pour gérer un périphérique MFA matériel pour votre compte
AWS, accédez à la page Informations d'identification de sécurité AWS.
Pour obtenir de l'aide pour un périphérique MFA associé à un utilisateur IAM
•
Contactez l'administrateur système ou la personne vous ayant fourni le nom utilisateur et le mot
de passe pour l'utilisateur IAM. L'administrateur doit désactiver le périphérique MFA, comme décrit
dans Désactivation des périphériques MFA (p. 107).
Configuration de l'accès aux API protégé par MFA
Avec les stratégies IAM, vous pouvez spécifier les API qu'un utilisateur est autorisé à appeler. Dans
certains cas, vous souhaitez peut-être avoir la sécurité supplémentaire d'imposer qu'un utilisateur soit
authentifié à l'aide l'authentification multi-facteurs (MFA) AWS avant qu'il soit autorisé à exécuter des
actions particulièrement sensibles.
Par exemple, vous disposez peut-être d'une stratégie qui autorise l'utilisateur à exécuter les actions
RunInstances, DescribeInstances et StopInstances Amazon EC2. Mais vous souhaitez
peut-être restreindre une action destructive comme TerminateInstances et vous assurer que les
utilisateurs peuvent exécuter cette action uniquement s'ils s'authentifient avec un périphérique MFA
AWS.
Rubriques
• Présentation (p. 109)
• Scénario : Protection MFA pour la délégation entre comptes (p. 112)
• Scénario : Protection MFA pour l'accès aux API du compte actuel (p. 113)
• Scénario : Protection MFA des ressources disposant de stratégies basées sur les
ressources (p. 114)
Présentation
L'ajout d'une protection MFA aux API nécessite les tâches suivantes :
1. L'administrateur configure un périphérique MFA AWS pour chaque utilisateur qui doit créer des
demandes API nécessitant une authentification MFA. Ce processus est décrit dans la section
Activation de périphériques MFA (p. 94).
2. L'administrateur crée des stratégies pour les utilisateurs qui incluent un élément Condition qui
vérifie si l'utilisateur s'est authentifié avec un périphérique MFA AWS.
3. L'utilisateur appelle l'une des API STS qui prennent en charge les paramètres MFA AssumeRole
ou GetSessionToken, selon le scénario de protection MFA, comme décrit plus loin. Dans le cadre
de l'appel, l'utilisateur inclut identifiant du périphérique associé à l'utilisateur, ainsi que le mot de
passe TOTP (Time-based One-Time Password) que le périphérique génère. Dans tous les cas,
l'utilisateur récupère les informations d'identification de sécurité temporaires qu'il peut ensuite utiliser
pour effectuer des demandes supplémentaires à AWS.
Note
La protection MFA des API d'un service est uniquement disponible si le service prend en
charge les informations d'identification de sécurité temporaires. Pour connaître la liste
109
de ces services, consultez la section Utilisation d'informations d'identification de sécurité
temporaires pour accéder à AWS.
Si l'autorisation échoue, AWS renvoie un message d'erreur « Access Denied » (comme il le fait pour
tout accès non autorisé). Avec les stratégies API protégées par l'authentification MFA en place,
AWS refuse l'accès aux API spécifiées dans les stratégies si l'utilisateur tente d'utiliser une API sans
authentification MFA valide ou si l'horodatage de la demande de l'API se situe en dehors de la plage
autorisée spécifiée dans la stratégie. L'utilisateur doit être à nouveau authentifié avec l'authentification
MFA en demandant de nouvelles informations d'identification de sécurité temporaires avec un code
MFA et un numéro de série de périphérique.
Stratégies IAM avec des conditions MFA
Les stratégies avec des conditions MFA peuvent être attachées à ce qui suit :
• Un utilisateur ou un groupe IAM
• Une ressource comme un compartiment Amazon S3, une file d'attente Amazon SQS ou une
rubrique Amazon SNS
• La stratégie d'approbation d'un rôle IAM qui peut être assumée par un utilisateur
Vous pouvez utiliser une condition MFA d'une stratégie pour vérifier les propriétés suivantes :
• Existence : Pour vous assurer simplement que l'utilisateur s'est bien authentifié avec
l'authentification MFA, vérifiez que la clé aws:MultiFactorAuthPresent a la valeur True dans
une condition Bool. La clé est uniquement présente lorsque l'utilisateur s'authentifie avec des
informations d'identification à court terme. Les informations d'identification à long terme, telles que
les clés d'accès, n'incluent pas cette clé.
• Durée : Si vous souhaitez accorder l'accès uniquement dans un délai spécifié après
l'authentification MFA, utiliser un type de condition numérique pour comparer l'âge de la
clé aws:MultiFactorAuthAge à une valeur (comme 3 600 secondes). Notez que la clé
aws:MultiFactorAuthAge n'est pas présente si l'authentification MFA n'a pas été utilisée.
L'exemple suivant présente la stratégie d'approbation d'un rôle IAM incluant une condition MFA pour
tester l'existence de l'authentification MFA. Avec cette stratégie, les utilisateurs du compte AWS
spécifié dans l'élément Principal (remplacez ACCOUNT-B-ID par un ID de compte AWS valide)
peuvent assumer le rôle auquel cette stratégie est attachée, mais uniquement si l'utilisateur est
authentifié par MFA.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"AWS": "ACCOUNT-B-ID"},
"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}
}
Pour plus d'informations sur les types de conditions pour l'authentification MFA, consultez Clés de
condition disponibles (p. 416), Opérateurs de condition numériques (p. 424) et Opérateur de
condition pour vérifier l'existence de clés de condition (p. 429)
110
Choix entre GetSessionToken et AssumeRole
AWS STS fournit deux API qui permettent à l'utilisateur de transmettre des informations MFA :
GetSessionToken et AssumeRole. L'API que l'utilisateur appelle pour obtenir des informations
d'identification de sécurité temporaires dépend duquel des deux scénarios suivants s'applique :
Utilisez GetSessionToken pour les scénarios suivants :
• Appelez les API qui accèdent aux ressources dans le même compte AWS que l'utilisateur IAM
qui crée la demande. Notez que les informations d'identification temporaires d'une demande
GetSessionToken peuvent accéder aux API IAM et STS uniquement si vous incluez des
informations MFA dans la demande d'informations d'identification. Du fait que les informations
d'identification temporaires renvoyées par GetSessionToken incluent des informations MFA,
vous pouvez rechercher l'authentification MFA dans les appels d'API effectués par les informations
d'identification.
• Accédez aux ressources protégées par des stratégies basées sur les ressources qui incluent une
condition MFA.
Utilisez AssumeRole pour les scénarios suivants :
• Appelez les API qui accèdent aux ressources dans le même compte AWS ou dans un compte
différent. Les appels d'API peuvent inclure n'importe quelle API IAM ou STS. Notez que pour
protéger l'accès vous devez appliquer l'authentification MFA au moment où l'utilisateur assume
le rôle. Les informations d'identification temporaires renvoyées par AssumeRole n'incluent pas
des informations MFA dans ce contexte, vous ne pouvez donc pas rechercher les appels d'API
individuels pour l'authentification MFA. C'est pourquoi vous devez utiliser GetSessionToken pour
restreindre l'accès aux ressources protégées par des stratégies basées sur les ressources.
Vous trouverez des détails sur l'implémentation de ces scénarios ultérieurement dans ce document.
Points importants sur l'accès aux API protégé par MFA
Il est important de comprendre les aspects suivants de la protection MFA pour les API :
• La protection MFA est uniquement disponible avec les informations d'identification de sécurité
temporaires que vous devez obtenir avec AssumeRole ou GetSessionToken.
• Vous ne pouvez pas utiliser l'accès aux API protégé par MFA avec les informations d'identification
du compte racine.
• Les utilisateurs fédérés ne peuvent pas se voir affecter un périphérique MFA à utiliser avec les
services AWS, afin qu'ils ne puissent pas accéder aux ressources AWS contrôlées par MFA. (Voir le
point suivant.)
• D'autres API AWS STS qui renvoient les informations d'identification temporaires ne prennent pas
en charge l'authentification MFA. Pour AssumeRoleWithWebIdentity et AssumeRoleWithSAML,
l'utilisateur est authentifié par un fournisseur externe et AWS ne peut pas déterminer si ce
fournisseur nécessitait l'authentification MFA. Pour GetFederationToken, l'authentification MFA
n'est pas nécessairement associée à un utilisateur spécifique.
• De même, les informations d'identification à long terme (clés d'accès utilisateur IAM et clés d'accès
du compte racine) ne peuvent pas être utilisées avec l'accès aux API protégé par MFA, car elles
n'expirent pas.
• AssumeRole et GetSessionToken peuvent également être appelées sans informations MFA.
Dans ce cas, le mandataire récupère les informations d'identification de sécurité temporaires, mais
les informations de session de ces informations d'identification temporaires n'indiquent pas que
l'utilisateur s'est authentifié avec l'authentification MFA.
• Pour établir la protection MFA pour les API, vous ajouter des conditions MFA aux stratégies. Si une
stratégie n'inclut pas la condition des authentifications MFA, la stratégie n'applique pas l'utilisation de
l'authentification MFA. Pour la délégation entre comptes, si la stratégie d'approbation du rôle n'inclut
111
pas une condition MFA, il n'y a aucune protection MFA concernant les appels d'API effectués avec
les informations d'identification de sécurité temporaires du rôle.
• Lorsque vous autorisez un autre compte AWS à accéder aux ressources de votre compte, même
lorsque vous nécessitez une authentification multi-facteurs, la sécurité de vos ressources dépend de
la configuration du compte approuvé, c'est-à-dire l'autre compte (pas le vôtre). Toutes les identités
du compte approuvé ayant l'autorisation de créer des périphériques MFA virtuels peut créer une
demande de MFA pour satisfaire cette partie de la stratégie d'approbation de votre rôle. Avant
d'autoriser l'accès d'un autre compte à vos ressources AWS qui nécessitent l'authentification multifacteurs, vous devez vérifier que le titulaire du compte approuvé respecte les bonnes pratiques en
matière de sécurité et limite l'accès aux API sensibles, comme les API de gestion de périphérique
MFA, à des identités approuvées spécifiques.
• Si une stratégie inclut une condition MFA, une demande est refusée si les utilisateurs n'ont pas été
authentifiés par MFA ou s'ils fournissent un identifiant de périphérique MFA ou un TOTP non valide.
Scénario : Protection MFA pour la délégation entre comptes
Dans ce scénario, vous souhaitez déléguer l'accès aux utilisateurs IAM dans un autre compte,
mais uniquement si les utilisateurs sont authentifiés par un périphérique AWS MFA. (Pour
plus d'informations sur la délégation entre comptes, consultez Termes et concepts relatifs aux
rôles (p. 140).
Imaginons que vous disposiez d'un compte A (le compte d'approbation qui est titulaire de la ressource
auxquelles les utilisateurs ont accès), avec l'utilisateur IAM Alice qui dispose de l'autorisation
administrateur. Elle souhaite accorder l'accès à l'utilisateur Bob au compte B (le compte approuvé),
mais veut s'assurer que Bob s'est authentifié avec MFA avant d'assumer le rôle.
1. Dans le compte d'approbation A, Alice crée un rôle IAM appelé CrossAccountRole et définit
le mandataire de la stratégie d'approbation du rôle sur l'ID de compte du compte B. La stratégie
d'approbation accorde l'autorisation à l'action AssumeRole AWS STS. Alice ajoute également une
condition MFA à la stratégie d'approbation, comme dans l'exemple suivant.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"AWS": "ACCOUNT-B-ID"},
}
}
2. Alice ajoute une stratégie d'accès au rôle qui spécifie ce que le rôle est autorisé faire. La stratégie
d'accès d'un rôle avec protection MFA est identique à toutes les stratégies d'accès au rôle.
L'exemple suivant indique la stratégie qu'Alice ajoute au rôle : il permet à un utilisateur assumant le
rôle d'exécuter toutes les actions DynamoDB de la table Books dans le compte A.
Note
La stratégie d'accès n'inclut aucune condition MFA. Il est important de comprendre que
l'authentification MFA sert uniquement à déterminer si un utilisateur peut assumer le rôle.
Une fois que l'utilisateur assume le rôle, aucune autre vérification MFA n'est effectuée.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
112
"Action": ["dynamodb:*"],
"Resource": ["arn:aws:dynamodb:region:ACCOUNT-A-ID:table/Books"]
}]
}
3. Dans le compte approuvé B, l'administrateur vérifie que l'utilisateur IAM Bob est configuré avec un
périphérique AWS MFA et qu'il connaît l'ID du périphérique, c'est-à-dire le numéro de série s'il s'agit
d'un périphérique MFA matériel ou l'ARN du périphérique, s'il s'agit d'un périphérique MFA virtuel.
4. Dans le compte B, l'administrateur attache la stratégie suivante à l'utilisateur Bob (ou à un groupe
dont il est membre) qui l'autorise à appeler l'action AssumeRole. La ressource est définie sur l'ARN
du rôle qu'Alice a créé à l'étape 1. Notez que cette stratégie n'inclut aucune condition MFA.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["sts:AssumeRole"],
"Resource": ["arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole"]
}]
}
5. Dans le compte B, Bob (ou une application que Bob exécute) appelle AssumeRole. L'appel d'API
inclut l'ARN du rôle à assumer (arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole), l'ID
du périphérique MFA et le TOTP actuel que Bob obtient de ce périphérique.
Lorsque Bob appelle AssumeRole, AWS détermine s'il dispose d'informations d'identification
valides, notamment l'exigence pour le MFA. Le cas échéant, Bob réussite à assumer le rôle et eut
exécuter n'importe quelle action DynamoDB de la table nommée Books dans le compte A tout en
utilisant les informations d'identification temporaires du rôle.
Pour obtenir un exemple d'un programme qui appelle AssumeRole, consultez Appel de
AssumeRole avec l'authentification MFA (Python) (p. 120).
Scénario : Protection MFA pour l'accès aux API du compte actuel
Dans ce scénario, vous souhaitez vérifier qu'un utilisateur de votre compte AWS peut accéder à des
actions d'API sensibles lorsque les utilisateur est authentifié à l'aide d'un périphérique AWS MFA.
Imaginons que vous ayez un compte A contenant un groupe de développeurs ayant besoin d'utiliser
des instances EC2. Les développeurs standard peuvent utiliser les instances, mais ils n'ont pas
l'autorisation d'utiliser les actions ec2:StopInstances ou ec2:TerminateInstances. Vous
souhaitez limiter ces actions « destructives » réalisées avec des actions à quelques utilisateurs
approuvés uniquement, vous ajoutez donc la protection MFA à la stratégie qui autorise ces actions
Amazon EC2 sensibles.
Dans ce scénario, l'un des utilisateurs approuvé s'appelle Carol. L'utilisatrice Alice est administratrice
du compte A.
1. Alice vérifie que Carole est configurée avec un périphérique AWS MFA et qu'elle connaît l'ID du
périphérique, c'est-à-dire le numéro de série s'il s'agit d'un périphérique MFA matériel ou l'ARN du
périphérique, s'il s'agit d'un périphérique MFA virtuel.
2. Alice crée un groupe appelé EC2-Admins et ajoute l'utilisatrice Carol au groupe.
3. Alice attache la stratégie suivante au groupe EC2-Admins. Cette stratégie autorise également
les utilisateurs à appeler les actions StopInstances et TerminateInstances Amazon EC2
uniquement si l'utilisateur s'est authentifié à l'aide de l'authentification MFA.
{
113
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:StopInstances",
"ec2:TerminateInstances"
],
"Resource": ["*"],
}]
}
4. Si l'utilisatrice Carol a besoin d'arrêter ou de mettre hors tension une instance Amazon EC2, elle (ou
une application qu'elle exécute) appelle GetSessionToken en transmettant l'ID du périphérique
MFA et le TOTP actuel que Carol obtient de son périphérique.
5. L'utilisatrice Carol (ou une application qu'elle utilise) utilise les informations d'identification
temporaires fournies par GetSessionToken pour appeler l'action StopInstances ou
StopInstances Amazon EC2.
Pour obtenir un exemple d'un programme qui appelle GetSessionToken, consultez Appel de
GetSessionToken avec l'authentification MFA (Python et C#) (p. 118) ci-après dans ce document.
Scénario : Protection MFA des ressources disposant de stratégies basées sur
les ressources
Dans ce scénario, vous êtes le titulaire d'un compartiment S3, d'une file d'attente SQS ou d'une
rubrique SNS et vous souhaitez vérifier que n'importe quel utilisateur de votre compte AWS qui accède
à la ressource est authentifié à l'aide d'un périphérique AWS MFA.
Ce scénario illustre un processus permettant de fournir une protection MFA entre comptes
sans nécessiter que les utilisateurs assument d'abord un rôle. Si l'utilisateur est authentifié par
l'authentification MFA et est en mesure d'obtenir des informations d'identification temporaires de
GetSessionToken, et si le compte de l'utilisateur est approuvé par la stratégie de la ressource,
l'utilisateur peut accéder à la ressource.
Imaginons que vous vous trouvez dans le compte A et que vous créez un compartiment S3. Vous
souhaitez accorder l'accès à ce compartiment à des utilisateurs qui se trouvent dans plusieurs comptes
AWS distincts, mais uniquement si ces utilisateurs sont authentifiés avec l'authentification MFA.
Dans ce scénario, l'utilisatrice Alice est une administratrice du compte A. L'utilisateur Charlie est un
utilisateur IAM du compte C.
1. Dans le compte A, Alice crée un compartiment appelé Account-A-bucket.
2. Alice ajoute la stratégie de compartiment au compartiment. La stratégie autorise n'importe quel
utilisateur du compte A, du compte B ou du compte C à exécuter les actions PutObject et
DeleteObject S3 dans le compartiment. La stratégie inclut une condition MFA.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": [
"ACCOUNT-A-ID",
"ACCOUNT-B-ID",
"ACCOUNT-C-ID"
]},
"Action": [
114
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::ACCOUNT-A-BUCKET-NAME/*"],
}]
}
Note
Amazon S3 fournit une fonction Supprimer MFA pour l'accès au compte racine
(uniquement). Vous pouvez activer Supprimer MFA de Amazon S3 lorsque vous définissez
l'état de la gestion des versions du compartiment. La fonction Supprimer MFA de Amazon
S3 ne peut pas être appliquée à un utilisateur IAM et elle est gérée indépendamment
de l'accès à l'API protégé par MFA. Un utilisateur IAM disposant d'une autorisation pour
supprimer un compartiment ne peut pas le faire si la fonction Supprimer MFA de Amazon
S3 est activée. Pour plus d'informations sur la fonction Supprimer MFA de Amazon S3,
consultez la section Supprimer MFA.
3. Dans le compte C, un administrateur vérifie que l'utilisateur Charlier est configuré avec un
périphérique AWS MFA et qu'il connaît l'ID du périphérique, c'est-à-dire le numéro de série s'il s'agit
d'un périphérique MFA matériel ou l'ARN du périphérique, s'il s'agit d'un périphérique MFA virtuel.
4. Dans le compte C, Charlie (ou une application qu'il exécute) appelle GetSessionToken. L'appel
d'ARN inclut l'ID ou l'ARN du périphérique MFA et le TOTP actuel que Charlie obtient de ce
périphérique.
5. Charlie (ou une application qu'il utilise) utilise les informations d'identification temporaires renvoyées
par GetSessionToken pour appeler l'action PutObject Amazon S3 afin de charger un fichier
dans Account-A-bucket.
Pour obtenir un exemple d'un programme qui appelle GetSessionToken, consultez Appel de
GetSessionToken avec l'authentification MFA (Python et C#) (p. 118) ci-après dans ce document.
Note
Les informations d'identification temporaires renvoyées par AssumeRole ne fonctionnent
pas dans ce cas, car bien que l'utilisateur puisse fournir les informations MFA lui permettant
d'assumer un rôle, les informations d'identification temporaires renvoyées par AssumeRole
n'incluent par les informations MFA requises pour satisfaire la condition MFA de la stratégie.
Exemples de stratégies avec des conditions MFA
Les exemples suivants illustrent d'autres méthodes permettant d'ajouter des conditions MFA aux
stratégies.
Note
Les exemples suivants illustrent des stratégies attachées directement à un utilisateur ou un
groupe IAM dans votre propre compte AWS. Pour adapter l'exemple aux API protégées par
MFA dans plusieurs comptes, vous utilisez des rôles IAM à la place et incluez le contrôle de
condition MFA dans la stratégie d'approbation du rôle, plutôt que dans sa stratégie d'accès.
Pour de plus amples informations, veuillez consulter Scénario : Protection MFA pour la
délégation entre comptes (p. 112).
Rubriques
• Exemple 1 : Octroi de l'accès après une authentification MFA récente
(GetSessionToken) (p. 116)
115
• Exemple 2 : Rejet de l'accès à des API spécifiques sans authentification MFA valide
(GetSessionToken) (p. 116)
• Exemple 3 : Rejet de l'accès à des API spécifiques sans authentification MFA valide
(GetSessionToken) récente (p. 117)
Exemple 1 : Octroi de l'accès après une authentification MFA récente
(GetSessionToken)
L'exemple suivant illustre une stratégie attachée à un utilisateur ou un groupe qui accorde l'accès
à Amazon EC2 uniquement si l'utilisateur s'est connecté via l'authentification multi-facteurs (MFA)
au cours de l'heure écoulée (3 600 secondes). Notez que si un utilisateur avec des informations
d'identification à long terme et cette stratégie appellent l'API Amazon EC2, l'appel échoue car la clé
MultiFactorAuthAge n'est jamais présente dans le cadre de la demande pour les informations
d'identification à long terme. Vous pouvez soit autoriser les informations d'identification à long terme en
affectant à l'opérateur le paramètre NumericLessThanIfExists, soit exiger que l'utilisateur obtienne
des informations d'identification à court terme validées au préalable avec une authentification MFA à
l'aide de l'API sts:GetSessionToken.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["ec2:*"],
"Resource": ["*"],
"Condition": {"NumericLessThan": {"aws:MultiFactorAuthAge": "3600"}}
}]
}
Exemple 2 : Rejet de l'accès à des API spécifiques sans authentification MFA
valide (GetSessionToken)
L'exemple suivant illustre une stratégie attachée à un utilisateur ou un groupe qui accorde l'accès à
l'ensemble des API Amazon EC2, mais refuse l'accès à StopInstances et TerminateInstances
si l'utilisateur n'est pas authentifié à l'aide de MFA. La stratégie requiert deux instructions pour
obtenir l'effet voulu. La première instruction (contenant "Sid": "AllowAllActionsForEC2")
autorise toutes les actions Amazon EC2. La deuxième instruction (contenant "Sid":
"DenyStopAndTerminateWhenMFAIsNotPresent") rejette les actions StopInstances et
TerminateInstances lorsque le contexte d'authentification MFA est manquant (c'est-à-dire, quand
l'authentification MFA n'a pas été utilisée).
Note
Le contrôle de la condition MultiFactorAuthPresent de l'instruction Deny ne doit pas être
{"Bool":{"aws:MultiFactorAuthPresent":false}}, car cette clé n'est pas présente et
ne peut pas être évaluée quand l'authentification MFA n'est pas utilisée. Utilisez donc plutôt le
contrôle BoolIfExists pour voir si la clé est présente avant de vérifier la valeur.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAllActionsForEC2",
"Effect": "Allow",
"Action": "ec2:*",
116
"Resource": "*"
},
{
"Sid": "DenyStopAndTerminateWhenMFAIsNotPresent",
"Effect": "Deny",
"Action": [
],
"Resource": "*",
"Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": false}}
}
]
}
Exemple 3 : Rejet de l'accès à des API spécifiques sans authentification MFA
valide (GetSessionToken) récente
L'exemple suivant illustre une stratégie attachée à un utilisateur ou un groupe qui accorde l'accès à
l'ensemble des API Amazon EC2, mais refuse l'accès à StopInstances et TerminateInstances si
l'utilisateur n'a pas été authentifié à l'aide de MFA au cours de l'heure écoulée. Cet exemple développe
celui précédent et requiert trois instructions pour obtenir l'effet voulu. Les deux premières instructions
sont les mêmes que dans l'exemple précédent. La deuxième instruction contient toujours la condition
qui rejette les actions StopInstances et TerminateInstances si l'authentification MFA n'est
pas utilisée du tout (le contexte MFA est manquant). La troisième instruction de l'exemple suivant
(contenant "Sid": "DenyStopAndTerminateWhenMFAIsOlderThanOneHour") contient une
condition supplémentaire qui rejette les actions StopInstances et TerminateInstances lorsque
l'authentification MFA est présente, mais qu'elle a eu lieu plus d'une heure avant la demande. Par
exemple, un utilisateur IAM peut se connecter à AWS Management Console via l'authentification MFA,
puis tenter d'arrêter ou de mettre hors service une instance EC2 deux heures plus tard. La stratégie
suivante empêche cela. Pour arrêter ou mettre hors service une instance EC2 dans ce scénario,
l'utilisateur doit se déconnecter, se connecter à nouveau à l'aide de l'authentification MFA, puis arrêter
ou mettre hors service l'instance dans l'heure qui suit sa connexion.
Note
Le contrôle de condition MultiFactorAuthPresent de la première instruction Deny utilise
"BoolIfExists", car cette clé n'est pas présente et ne peut pas être évaluée quand
l'authentification MFA n'est pas utilisée. Si l'authentification MFA n'est pas utilisée et que la
valeur n'existe pas, elle renvoie la valeur true. L'instruction correspond alors et refuse l'accès.
La condition aws:MultiFactorAuthAge est présente uniquement lorsque le contexte
MFA est présent dans la demande. Donc l'instruction 2 s'applique au cas où MFA n'est
pas présent du tout, et l'instruction 3 s'applique au cas où MFA est présent et évalue si
l'authentification s'est produite dans le délai approprié. Là encore, si la clé n'est pas présente,
la condition ...IfExists entraîne le renvoi de la valeur true lors du test, la correspondance de
l'instruction et l'utilisateur se voit refuser l'accès à ces API.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowAllActionsForEC2",
"Effect": "Allow",
"Action": "ec2:*",
"Resource": "*"
},
117
{
"Sid": "DenyStopAndTerminateWhenMFAIsNotPresent",
"Effect": "Deny",
"Action": [
],
"Resource": "*",
"Condition": {"BoolIfExists": {"aws:MultiFactorAuthPresent": false}}
},
{
"Sid": "DenyStopAndTerminateWhenMFAIsOlderThanOneHour",
"Effect": "Deny",
"Action": [
],
"Resource": "*",
"Condition": {"NumericGreaterThanIfExists": {"aws:MultiFactorAuthAge":
"3600"}}
}
]
}
Exemple de code : Demande d'informations d'identification
avec l'authentification multi-facteurs
Les exemples suivants expliquent comment appeler GetSessionTokenRole et AssumeRole et
réussir l'authentification MFA. Les informations d'identification renvoyées sont ensuite utilisées pour
répertorier tous les compartiments S3 dans le compte.
Appel de GetSessionToken avec l'authentification MFA (Python et C#)
Les exemples suivants, écrits avec AWS SDK for Python (Boto) et Kit AWS SDK pour .NET, expliquent
comment appeler GetSessionToken et transmettre les informations d'authentification MFA. Les
informations d'identification de sécurité temporaires renvoyées par GetSessionTokenRole sont
ensuite utilisées pour répertorier tous les compartiments S3 dans le compte.
La stratégie attachée à l'utilisateur qui exécute ce code (ou un groupe dont fait partie l'utilisateur) est
supposée inclure une vérification MFA. Cette stratégie doit autoriser l'utilisateur à demander l'action
ListBuckets Amazon S3.
Utilisation de Python
import boto
from boto.s3.connection import S3Connection
from boto.sts import STSConnection
# Prompt for MFA time-based one-time password (TOTP)
mfa_TOTP = raw_input("Enter the MFA code: ")
# The calls to AWS STS GetSessionToken must be signed with the access key ID
and secret
# access key of an IAM user. The credentials can be in environment variables
or in
# a configuration file and will be discovered automatically
# by the STSConnection() function. For more information, see the Python SDK
118
# documentation: http://boto.readthedocs.org/en/latest/boto_config_tut.html
sts_connection = STSConnection()
# Use the appropriate device ID (serial number for hardware device or ARN for
virtual device).
# Replace ACCOUNT-NUMBER-WITHOUT-HYPHENS and MFA-DEVICE-ID with appropriate
values.
tempCredentials = sts_connection.get_session_token(
duration=3600,
mfa_serial_number="&region-arn;iam::ACCOUNT-NUMBER-WITHOUT-HYPHENS:mfa/
MFA-DEVICE-ID",
mfa_token=mfa_TOTP
)
# Use the temporary credentials to list the contents of an S3 bucket
s3_connection = S3Connection(
aws_access_key_id=tempCredentials.access_key,
aws_secret_access_key=tempCredentials.secret_key,
security_token=tempCredentials.session_token
)
# Replace BUCKET-NAME with an appropriate value.
bucket = s3_connection.get_bucket(bucket_name="BUCKET-NAME")
objectlist = bucket.list()
for obj in objectlist:
print obj.name
Utilisation de C#
Console.Write("Enter MFA code: ");
string mfaTOTP = Console.ReadLine(); // Get string from user
/* The calls to AWS STS GetSessionToken must be signed using the access key
ID and secret
access key of an IAM user. The credentials can be in environment variables
or in
a configuration file and will be discovered automatically
by the AmazonSecurityTokenServiceClient constructor. For more information,
see
http://docs.aws.amazon.com/AWSSdkDocsNET/latest/DeveloperGuide/net-dgconfig-creds.html
*/
AmazonSecurityTokenServiceClient stsClient =
new AmazonSecurityTokenServiceClient();
GetSessionTokenRequest getSessionTokenRequest = new GetSessionTokenRequest();
getSessionTokenRequest.DurationSeconds = 3600;
// Replace ACCOUNT-NUMBER-WITHOUT-HYPHENS and MFA-DEVICE-ID with appropriate
values
getSessionTokenRequest.SerialNumber = "arn:aws:iam::ACCOUNT-NUMBER-WITHOUTHYPHENS:mfa/MFA-DEVICE-ID";
getSessionTokenRequest.TokenCode = mfaTOTP;
GetSessionTokenResponse getSessionTokenResponse =
stsClient.GetSessionToken(getSessionTokenRequest);
119
// Extract temporary credentials from result of GetSessionToken call
GetSessionTokenResult getSessionTokenResult =
getSessionTokenResponse.GetSessionTokenResult;
string tempAccessKeyId = getSessionTokenResult.Credentials.AccessKeyId;
string tempSessionToken = getSessionTokenResult.Credentials.SessionToken;
string tempSecretAccessKey =
getSessionTokenResult.Credentials.SecretAccessKey;
SessionAWSCredentials tempCredentials = new
SessionAWSCredentials(tempAccessKeyId,
tempSecretAccessKey, tempSessionToken);
// Use the temporary credentials to list the contents of an S3 bucket
// Replace BUCKET-NAME with an appropriate value
ListObjectsRequest S3ListObjectsRequest = new ListObjectsRequest();
S3ListObjectsRequest.BucketName = "BUCKET-NAME";
S3Client = AWSClientFactory.CreateAmazonS3Client(tempCredentials);
ListObjectsResponse S3ListObjectsResponse =
S3Client.ListObjects(S3ListObjectsRequest);
foreach (S3Object s3Object in S3ListObjectsResponse.S3Objects)
{
Console.WriteLine(s3Object.Key);
}
Appel de AssumeRole avec l'authentification MFA (Python)
L'exemple suivant, écrit avec AWS SDK for Python (Boto), explique comment appeler AssumeRole
et transmettre les informations d'authentification MFA. Les informations d'identification de sécurité
temporaires renvoyées par AssumeRole sont ensuite utilisées pour répertorier tous les compartiments
Amazon S3 dans le compte.
Pour plus d'informations sur ce scénario, consultez Scénario : Protection MFA pour la délégation entre
comptes (p. 112).
import boto
from boto.s3.connection import S3Connection
from boto.sts import STSConnection
# Prompt for MFA time-based one-time password (TOTP)
mfa_TOTP = raw_input("Enter the MFA code: ")
# The calls to AWS STS AssumeRole must be signed with the access key ID and
secret
# access key of an IAM user. (The AssumeRole API can also be called using
temporary
# credentials, but this example does not show that scenario.)
# The IAM user credentials can be in environment variables or in
# a configuration file and will be discovered automatically
# by the STSConnection() function. For more information, see the Python SDK
# documentation: http://boto.readthedocs.org/en/latest/boto_config_tut.html
# Use appropriate device ID (serial number for hardware device or ARN for
virtual device)
# Replace ACCOUNT-NUMBER-WITHOUT-HYPHENS, ROLE-NAME, and MFA-DEVICE-ID with
appropriate values
tempCredentials = sts_connection.assume_role(
role_arn="arn:aws:iam::ACCOUNT-NUMBER-WITHOUT-HYPHENS:role/ROLE-NAME",
120
Recherche d'informations d'identification inutilisées
role_session_name="AssumeRoleSession1",
mfa_serial_number="arn:aws:iam::ACCOUNT-NUMBER-WITHOUT-HYPHENS:mfa/MFADEVICE-ID",
mfa_token=mfa_TOTP
)
# Use the temporary credentials to list the contents of an S3 bucket
s3_connection = S3Connection(
aws_access_key_id=tempCredentials.credentials.access_key,
aws_secret_access_key=tempCredentials.credentials.secret_key,
security_token=tempCredentials.credentials.session_token
)
# Replace BUCKET-NAME with a real bucket name
bucket = s3_connection.get_bucket(bucket_name="BUCKET-NAME")
objectlist = bucket.list()
for obj in objectlist:
print obj.name
Lorsque les utilisateurs quittent votre organisation ou que des services ne sont plus utilisés, il est
important de rechercher leurs informations d'identification afin de s'assurer qu'elles ne sont plus
opérationnelles. Idéalement, supprimez les informations d'identification qui ne sont plus requises. Il
est toujours possible de les recréer ultérieurement, si nécessaire. Vous devez au moins modifier les
informations d'identification afin que les anciens utilisateurs ne soient plus en mesure de s'en servir.
La signification du mot« inutilisées » peut bien sûr varier : cela indique généralement que les
informations d'identification n'ont pas été utilisées au cours d'un laps de temps spécifié.
Recherche de mots de passe inutilisés
Vous pouvez utiliser l'AWS Management Console pour télécharger un rapport d'informations
d'identification contenant des données sur la dernière utilisation du mot de passe de console par
chaque utilisateur. Vous pouvez également accéder à ces informations à partir de l'AWS CLI, des
Outils pour Windows PowerShell ou de l'API IAM.
Pour rechercher les mots de passe inutilisés en téléchargeant le rapport d'informations
d'identification dans la console IAM
1.
2.
Dans le volet de navigation, sélectionnez Credential Report.
3.
Choisissez Download Report pour télécharger un fichier de valeurs séparées par des virgules
(CSV) nommé status_reports_<date>T<heure>.csv. La cinquième colonne contient la
colonne password_last_used avec les dates ou l'une des mentions suivantes :
• N/A – Utilisateurs auxquels aucun mot de passe n'est affecté.
• no_information – Utilisateurs n'ayant pas utilisé leur mot de passe depuis le 20 octobre 2014,
date à laquelle IAM a commencé le suivi de l'âge des mots de passe.
Pour rechercher les mots de passe inutilisés à partir de l'AWS CLI, des Outils pour Windows
PowerShell et de l'API IAM
Vous pouvez rechercher les mots de passe inutilisés à l'aide des commandes suivantes :
121
• AWS CLI : aws iam list-users retourne une liste d'utilisateurs, avec une valeur
PasswordLastUsed pour chacun. Si la valeur est manquante, cela signifie que l'utilisateur ne
dispose pas de mot de passe ou qu'il ne l'a pas utilisé depuis le 20 octobre 2014, date à laquelle IAM
a commencé le suivi de l'âge des mots de passe.
• Outils pour Windows PowerShell : Get-IAMUsers retourne une collection d'objets User, avec une
propriété PasswordLastUsed pour chacun. Si la valeur de la propriété est 1/1/0001 12:00:00
AM, cela signifie que l'utilisateur ne dispose pas de mot de passe ou qu'il ne l'a pas utilisé depuis le
20 octobre 2014, date à laquelle IAM a commencé le suivi de l'âge des mots de passe.
• API IAM : ListUsers retourne une collection d'utilisateurs, avec une valeur <PasswordLastUsed>
pour chacun. Si la valeur est manquante, cela signifie que l'utilisateur ne dispose pas de mot de
passe ou qu'il ne l'a pas utilisé depuis le 20 octobre 2014, date à laquelle IAM a commencé le suivi
de l'âge des mots de passe.
Pour plus d'informations sur les commandes à utiliser pour le téléchargement du rapport
d'informations d'identification, consultez Obtention de rapports d'informations d'identification (AWS
CLI, l'Outils pour Windows PowerShell ou l'API IAM) (p. 127).
Recherche des clés d'accès inutilisées
Vous pouvez utiliser l'AWS Management Console pour télécharger un rapport d'informations
d'identification afin de rechercher quand chaque utilisateur s'est servi de ses clés d'accès pour la
dernière fois. Vous pouvez également accéder à ces informations à partir de l'AWS CLI, des Outils
pour Windows PowerShell ou de l'API IAM.
Pour rechercher les clés d'accès inutilisées en téléchargeant le rapport d'informations
d'identification dans la console IAM
1.
2.
Dans le volet de navigation, sélectionnez Credential Report.
3.
Choisissez Download Report pour télécharger un fichier de valeurs séparées par des virgules
(CSV) nommé status_reports_<date>T<heure>.csv. Les colonnes 11 à 13 contiennent
des informations relatives à la dernière date d'utilisation de la clé d'accès 1, ainsi que la dernière
région et le dernier service utilisés par celle-ci, tandis que les colonnes 16 à 18 contiennent les
mêmes informations pour la clé d'accès 2. La valeur est N/A si l'utilisateur ne dispose pas de clé
d'accès ou s'il ne l'a pas utilisée depuis le 22 avril 2015, date à laquelle IAM a commencé le suivi
de l'âge des clés d'accès.
Pour rechercher les clés d'accès inutilisées à partir de l'AWS CLI, des Outils pour Windows PowerShell
et de l'API IAM
Vous pouvez rechercher les clés d'accès inutilisées à l'aide des commandes suivantes :
• AWS CLI :
• aws iam list-access-keys retourne des informations sur les clés d'accès d'un utilisateur, y
compris l'AccessKeyID.
• aws iam get-access-key-last-used utilise un ID de clé d'accès et retourne une sortie qui
inclut la LastUsedDate, la Region dans laquelle la clé d'accès a été utilisée la dernière fois
et le ServiceName du dernier service demandé. Si le champ LastUsedDate est manquant,
ceci indique que la clé d'accès n'a pas été utilisée depuis le 22 avril 2015, date à laquelle IAM a
commencé le suivi de l'âge des clés d'accès.
• Outils pour Windows PowerShell :
• Get-IAMAccessKey retourne une collection d'objets de clé d'accès associés à l'utilisateur
spécifié. Chaque objet est doté d'une propriété AccessKeyId.
122
Obtention de rapports d'informations d'identification
• Get-IAMAccessKeyLastUsed utilise un ID de clé d'accès et retourne un objet avec un objet de
propriété AccessKeyLastUsed. Les méthodes de l'objet incluent la LastUsedDate, la Region
dans laquelle la clé d'accès a été utilisée la dernière fois et le ServiceName du dernier service
demandé. Si la valeur de propriété est 1/1/0001 12:00:00 AM, ceci indique que la clé d'accès
n'a pas été utilisée depuis le 22 avril 2015, date à laquelle IAM a commencé le suivi de l'âge des
clés d'accès.
• API IAM :
• ListAccessKeys retourne une liste de valeurs AccessKeyID pour les clés d'accès associées à
l'utilisateur spécifié.
• GetAccessKeyLastUsed utilise un ID de clé d'accès et retourne une collection de valeurs. Il
s'agit notamment de la LastUsedDate, de la Region dans laquelle la clé d'accès a été utilisée
la dernière fois et du ServiceName du dernier service demandé. Si la valeur est manquante,
cela signifie que l'utilisateur ne dispose pas de clé d'accès ou qu'il ne l'a pas utilisée depuis le
20 octobre 2014, date à laquelle IAM a commencé le suivi de l'âge des clés d'accès.
Pour plus d'informations sur les commandes à utiliser pour le téléchargement du rapport
d'informations d'identification, consultez Obtention de rapports d'informations d'identification (AWS
CLI, l'Outils pour Windows PowerShell ou l'API IAM) (p. 127).
Obtention les rapports d'informations d'identification
de votre compte AWS
Vous pouvez générer et télécharger un rapports d'informations d'identification qui répertorie tous les
utilisateurs de votre compte et l'état de leurs diverses informations d'identification, notamment les mots
de passe, les clés d'accès, les périphériques MFA. Vous pouvez obtenir un rapports d'informations
d'identification à partir de la AWS Management Console, des Kits SDK AWS et des outils de ligne de
commande ou de l'API IAM.
Vous pouvez utiliser les rapports d'informations d'identification à des fins d'audit et de conformité.
Vous pouvez utiliser les rapports pour auditer les effets des exigences en matière de cycle de vie des
informations d'identification, comme la rotation de mot de passe et de clé d'accès. Vous pouvez fournir
les rapports à un auditeur externe ou accorder des autorisations à un auditeur pour qu'il télécharge les
rapports directement.
Vous pouvez générer un rapport d'informations d'identification à quelques heures d'intervalle. Lorsque
vous demandez un rapport, IAM vérifie d'abord si un rapport pour le compte AWS a été généré au
cours des quatre dernières heures. Le cas échéant, le rapport le plus récent est téléchargé. Si le
rapport le plus récent pour le compte a été généré il y a plus de quatre heures, ou qu'il n'y a pas eu
d'autres rapport généré précédemment pour le compte, IAM génère et télécharge un nouveau rapport.
Autorisations nécessaires
• Pour créer un rapport d'informations d'identification : GenerateCredentialReport
• Pour télécharger le rapport : GetCredentialReport
Présentation du format du rapport
Les rapports d'informations d'identification sont formatés comme des fichiers CSV (valeurs séparées
par une virgule). Vous pouvez ouvrir les fichiers CSV avec des logiciels de feuilles de calcul courants
pour effectuer des analyses ou vous pouvez créer une application qui consomme les fichiers CSV par
programmation et effectue des analyses personnalisées.
Le fichier CSV contient les colonnes suivantes :
123
user
arn
Nom convivial de l'utilisateur.
ARN (Amazon Resource Name) de l'utilisateur. Pour plus d'informations sur les ARN, consultez
ARN IAM (p. 388).
user_creation_time
Date et heure de création de l'utilisateur, au format de date et d'heure ISO 8601.
password_enabled
Lorsqu'un utilisateur dispose d'un mot de passe, cette valeur est TRUE. Sinon, la valeur est définie
comme FALSE. La valeur du compte AWS (racine) est toujours not_supported.
password_last_used
Date et heure de la dernière utilisation du mot de passe du compte AWS (racine) ou de l'utilisateur
IAM pour se connecter à un site web AWS, au format de date et d'heure ISO 8601. Les sites
web AWS qui capturent la dernière heure de connexion d'un utilisateur sont AWS Management
Console, les forums de discussion AWS et AWS Marketplace. Quand un mot de passe est utilisé
plusieurs fois dans un intervalle de 5 minutes, seule la première utilisation est enregistrée dans ce
champ.
• La valeur de ce champ est no_information dans les cas suivants :
• Le mot de passe de l'utilisateur n'a jamais été utilisé.
• Aucune donnée de connexion n'est associée au mot de passe, comme lorsque le mot de
passe de l'utilisateur n'a pas été utilisé depuis le 20 octobre 2014, date de début du suivi de
cette information par IAM.
• La valeur de ce champ est N/A (non applicable) lorsque l'utilisateur ne dispose pas de mot de
passe.
password_last_changed
Date et heure de la dernière définition du mot de passe de l'utilisateur, au format de date et
d'heure ISO 8601. Si l'utilisateur ne dispose pas d'un mot de passe, la valeur de ce champ est N/A
(non applicable). La valeur du compte AWS (racine) est toujours not_supported.
password_next_rotation
Lorsque le compte dispose d'une stratégie de mot de passe qui nécessite la rotation du mot
de passe, ce champ contient la date et l'heure, au format de date et d'heure ISO 8601, lorsque
l'utilisateur doit définir un nouveau mot de passe. La valeur du compte AWS (racine) est toujours
not_supported.
mfa_active
Lorsqu'un périphérique d'authentification multi-facteurs (p. 93) (MFA) a été activé pour
l'utilisateur, cette valeur est TRUE. Sinon, la valeur est définie comme FALSE.
access_key_1_active
Lorsque l'utilisateur dispose d'une clé d'accès et que l'état de celle-ci est Active, cette valeur est
TRUE. Sinon, la valeur est définie comme FALSE.
access_key_1_last_rotated
d'heure ISO 8601, lorsque la clé d'accès de l'utilisateur a été créée ou modifiée pour la dernière
fois. Si l'utilisateur ne dispose pas d'une clé d'accès active, la valeur de ce champ est N/A (non
applicable).
access_key_1_last_used_date
Date et heure, au format de date et d'heure ISO 8601, lorsque la clé d'accès de l'utilisateur a
été utilisée pour la dernière fois pour se connecter à une demande d'API AWS. Quand une clé
d'accès est utilisée plusieurs fois dans un intervalle de 15 minutes, seule la première utilisation est
enregistrée dans ce champ.
La valeur de ce champ est N/A (non applicable) dans les cas suivants :
• L'utilisateur ne dispose pas d'une clé d'accès.
• La clé d'accès n'a jamais été utilisée.
124
• La clé d'accès n'a pas été utilisée depuis le 22 avril 2015, date de début du suivi de cette
information par IAM.
access_key_1_last_used_region
Région AWS dans laquelle la clé d'accès a été utilisée pour la dernière fois. Quand une clé
d'accès est utilisée plusieurs fois dans un intervalle de 15 minutes, seule la première utilisation est
enregistrée dans ce champ.
• La clé d'accès a été utilisée pour la dernière fois avant le 22 avril 2015, date de début du suivi
de cette information par IAM.
• Le dernier service utilisé n'est pas spécifique à une région, comme Amazon Simple Storage
Service (Amazon S3).
access_key_1_last_used_service
Dernier service AWS auquel la clé d'accès a permis d'accéder. La valeur de ce champ utilise
l'espace de noms du service, par exemple, s3 pour Amazon S3 et ec2 pour Amazon Elastic
Compute Cloud (Amazon EC2). Quand une clé d'accès est utilisée plusieurs fois dans un intervalle
de 15 minutes, seule la première utilisation est enregistrée dans ce champ.
• La clé d'accès a été utilisée pour la dernière fois avant le 22 avril 2015, date de début du suivi
de cette information par IAM.
access_key_2_active
Lorsque l'utilisateur dispose d'une seconde clé d'accès et que l'état de celle-ci est Active, cette
valeur est TRUE. Sinon, la valeur est définie comme FALSE.
Note
Les utilisateurs peuvent disposer de deux clés d'accès afin de faciliter la rotation. Pour
plus d'informations sur la rotation des clés d'accès, consultez Rotation des clés d'accès
(AWS CLI, l'Outils pour Windows PowerShell et l'API AWS) (p. 92).
access_key_2_last_rotated
d'heure ISO 8601, lorsque la seconde clé d'accès de l'utilisateur a été créée ou modifiée pour
la dernière fois. Si l'utilisateur ne dispose pas d'une seconde clé d'accès active, la valeur de ce
champ est N/A (non applicable).
access_key_2_last_used_date
Date et heure, au format de date et d'heure ISO 8601, lorsque la seconde clé d'accès de
l'utilisateur a été utilisée pour la dernière fois pour se connecter à une demande d'API AWS.
Quand une clé d'accès est utilisée plusieurs fois dans un intervalle de 15 minutes, seule la
première utilisation est enregistrée dans ce champ.
• L'utilisateur ne dispose pas d'une seconde clé d'accès.
• La seconde clé d'accès de l'utilisateur n'a jamais été utilisée.
• La seconde clé d'accès de l'utilisateur a été utilisée pour la dernière fois avant le 22 avril 2015,
date de début du suivi de cette information par IAM.
access_key_2_last_used_region
Région AWS dans laquelle la seconde clé d'accès de l'utilisateur a été utilisée pour la dernière
fois. Quand une clé d'accès est utilisée plusieurs fois dans un intervalle de 15 minutes, seule
125
la première utilisation est enregistrée dans ce champ. La valeur de ce champ est N/A (non
applicable) dans les cas suivants :
• Le dernier service utilisé n'est pas spécifique à une région, comme Amazon S3.
access_key_2_last_used_service
Dernier service AWS auquel la seconde clé d'accès de l'utilisateur a permis d'accéder. La valeur
de ce champ utilise l'espace de noms du service, par exemple, s3 pour Amazon S3 et ec2 pour
Amazon Elastic Compute Cloud (Amazon EC2). Quand une clé d'accès est utilisée plusieurs fois
dans un intervalle de 15 minutes, seule la première utilisation est enregistrée dans ce champ. La
valeur de ce champ est N/A (non applicable) dans les cas suivants :
cert_1_active
Lorsque l'utilisateur dispose d'un certificat de signature X.509 et que l'état de celui-ci est Active,
cette valeur est TRUE. Sinon, la valeur est définie comme FALSE.
cert_1_last_rotated
d'heure ISO 8601, lorsque le certificat de signature de l'utilisateur a été créé ou modifié pour la
dernière fois. Si l'utilisateur ne dispose pas d'un certificat de signature actif, la valeur de ce champ
est N/A (non applicable).
cert_2_active
Lorsque l'utilisateur dispose d'un second certificat de signature X.509 et que l'état de celui-ci est
Active, cette valeur est TRUE. Sinon, la valeur est définie comme FALSE.
Note
Les utilisateurs peuvent disposer de deux certificats de signature X.509 afin de faciliter la
rotation des certificats.
cert_2_last_rotated
d'heure ISO 8601, lorsque le second certificat de signature de l'utilisateur a été créé ou modifié
pour la dernière fois. Si l'utilisateur ne dispose pas d'un second certificat de signature actif, la
valeur de ce champ est N/A (non applicable).
Obtention de rapports d'informations d'identification (AWS
Management Console)
Vous pouvez utiliser AWS Management Console pour télécharger un rapport d'informations
d'identification sous forme de fichier CSV (valeurs séparées par une virgule).
Pour télécharger un rapport d'informations d'identification avec AWS Management Console
1.
2.
Dans le volet de navigation, cliquez sur Credential Report.
3.
Cliquez sur Download Report.
126
Utilisation d'IAM avec AWS CodeCommit : informations
d'identification Git, clés SSH et clés d'accès AWS
Obtention de rapports d'informations d'identification (AWS CLI,
l'Outils pour Windows PowerShell ou l'API IAM)
Pour générer un rapport d'informations d'identification
Vous pouvez créer un rapport d'informations d'identification à l'aide des commandes suivantes :
• AWS CLI: aws iam generate-credential-report
• Outils pour Windows PowerShell : Request-IAMCredentialReport
• API IAM : GenerateCredentialReport
Pour récupérer un rapport d'informations d'identification
Vous pouvez récupérer un rapport d'informations d'identification généré à l'aide des commandes
suivantes :
• AWS CLI: aws iam get-credential-report
• Outils pour Windows PowerShell : Get-IAMCredentialReport
• API IAM : GetCredentialReport
Utilisation d'IAM avec AWS CodeCommit :
informations d'identification Git, clés SSH et clés
d'accès AWS
AWS CodeCommit est un service de contrôle des versions géré qui héberge des référentiels Git privés
dans le cloud AWS. Pour utiliser AWS CodeCommit, vous devez configurer votre client Git de manière
à ce qu'il puisse communiquer avec les référentiels AWS CodeCommit. Lors de cette configuration,
vous fournissez des informations d'identification IAM qu'AWS CodeCommit peut utiliser pour vous
authentifier. IAM prend en charge AWS CodeCommit avec trois types d'informations d'identification :
• Informations d'identification Git, paire mot de passe-nom utilisateur généré par IAM que vous pouvez
utiliser pour communiquer avec des référentiels AWS CodeCommit sur HTTPS.
• Clés SSH, paire de clés publique-privée générée localement que vous pouvez associer à votre
utilisateur IAM pour communiquer avec les référentiels AWS CodeCommit via SSH.
• Clés d'accès AWS (p. 89) que vous pouvez utiliser avec l'assistant d'informations d'identification
inclus dans l'AWS CLI pour communiquer avec les référentiels AWS CodeCommit sur HTTPS.
Pour plus d'informations sur chaque option, consultez les sections suivantes.
Utilisation des informations d'identification Git et HTTPS avec
AWS CodeCommit (recommandé)
Avec les informations d'identification Git, vous générez une paire mot de passe-nom utilisateur statique
pour votre utilisateur IAM, puis utilisez ces informations d'identification pour les connexions HTTPS.
Vous pouvez également utiliser ces informations d'identification avec n'importe quel outil tiers ou
environnement de développement intégré (IDE) prenant en charge les informations d'identification Git
statiques.
Etant donné que ces informations d'identification sont universelles pour tous les systèmes
d'exploitation pris en charge et compatibles avec la plupart des systèmes de gestion des informations
127
Utilisation d'IAM avec AWS CodeCommit : informations
d'identification Git, clés SSH et clés d'accès AWS
d'identification, environnements de développement et autres outils de développement logiciel, c'est la
méthode recommandée. Vous pouvez réinitialiser le mot de passe pour les informations d'identification
Git à tout moment. Vous pouvez également désactiver les informations d'identification ou les supprimer
si vous n'en avez plus besoin.
Note
Pour les informations d'identification Git, vous ne pouvez pas choisir vous-même votre nom
d'utilisateur et votre mot de passe. IAM génère ces informations d'identification pour vous
permettre de respecter les normes de sécurité pour AWS et les référentiels sécurisés dans
AWS CodeCommit. Vous pouvez télécharger les informations d'identification une seule fois,
au moment elles sont générées. Veillez à enregistrer les informations d'identification dans un
emplacement sûr. Si nécessaire, vous pouvez réinitialiser le mot de passe à tout moment,
mais cela invalidera les connexions configurées avec l'ancien mot de passe. Vous devez
reconfigurer les connexions pour qu'elles utilisent le nouveau mot de passe avant de vous
connecter.
Pour plus d'informations, consultez les rubriques suivantes :
• Pour créer un utilisateur IAM, consultez Création d'un utilisateur IAM dans votre compte
AWS (p. 66).
• Pour générer et utiliser les informations d'identification Git avec AWS CodeCommit, consultez Pour
les utilisateurs en HTTPS avec informations d'identification dans le AWS CodeCommit Guide de
l'utilisateur.
Note
Le fait de modifier le nom d'un utilisateur IAM après avoir généré des informations
d'identification Git ne modifie pas le nom utilisateur des informations d'identification Git. Le
nom utilisateur et le mot de passe restent identiques et sont toujours valides.
Pour changer les informations d'identification spécifiques au service
1.
Créez un second ensemble d'informations d'identification spécifiques au service en plus de
l'ensemble actuellement en cours d'utilisation.
2.
Mettez à jour toutes vos applications afin qu'elles utilisent le nouvel ensemble d'informations
d'identification et vérifiez que les applications fonctionnent.
3.
Modifiez l'état des informations d'identification d'origine et utilisez Inactif.
4.
Vérifiez que toutes vos applications fonctionnent toujours.
5.
Supprimer les informations d'identification spécifiques au service inactives.
Utiliser des clés SSH et SSH avec AWS CodeCommit
Avec les connexions SSH, vous créez des fichiers de clé publique et privée sur votre ordinateur local,
utilisés par Git et AWS CodeCommit pour l'authentification SSH. Vous associez la clé publique à votre
utilisateur IAM et stockez la clé privée sur votre ordinateur local. Pour plus d'informations, consultez les
rubriques suivantes :
• Pour créer un utilisateur IAM, consultez Création d'un utilisateur IAM dans votre compte
AWS (p. 66).
• Pour créer une clé publique SSH et l'associer à un utilisateur IAM, consultez Pour des connexions
SSH sous Linux, macOS, or Unix ou Pour des connexions SSH sous Windows dans le AWS
CodeCommit Guide de l'utilisateur.
128
Utilisation des certificats de serveur
Note
IAM accepte les clés publiques au format OpenSSH RSA uniquement. Si vous fournissez
votre clé publique dans un autre format, un message d'erreur vous indiquera que le format de
clé n'est pas valide.
Utilisation du protocole HTTPS avec l'assistant d'informations
d'identification de l'AWS CLI et AWS CodeCommit
Comme alternative aux connexions HTTPS avec informations d'identification Git, vous pouvez
permettre à Git d'utiliser une version signée de manière chiffrée des informations d'identification de
votre utilisateur IAM ou le rôle d'instance Amazon EC2 chaque fois que Git doit s'authentifier auprès
d'AWS pour interagir avec des référentiels AWS CodeCommit. C'est la seule méthode de connexion
aux référentiels AWS CodeCommit qui ne requiert pas d'utilisateur IAM. C'est également la seule
méthode qui fonctionne avec un accès fédéré et des informations d'identification temporaires. Il est
fortement recommandé de créer et d'utiliser des utilisateurs IAM pour l'accès, sauf si votre entreprise
a besoin d'un accès fédéré ou d'informations d'identification temporaires. Pour plus d'informations,
consultez les rubriques suivantes :
• Pour en savoir plus sur l'accès fédéré, consultez Fournisseurs d'identité et fédération (p. 148) et
Fourniture d'accès à des utilisateurs authentifiés en externe (fédération d'identité) (p. 146).
• Pour en savoir plus sur les informations d'identification temporaires, consultez Informations
d'identification de sécurité temporaires (p. 244) et Accès temporaire à des référentiels AWS
CodeCommit.
L'assistant d'informations d'identification de l'AWS CLI n'est pas compatible avec d'autres systèmes
de gestion des informations d'identification, comme Keychain Access ou le système de gestion des
informations d'identification de Windows. Il existe d'autres considérations relatives à la configuration
lorsque vous configurez des connexions HTTPS à l'aide de l'assistant d'informations d'identification.
Pour plus d'informations, consultez Pour les connexions HTTPS sous Linux, macOS, or Unix avec
l'assistant d'informations d'identification de l'AWS CLI ou Pour les connexions HTTPS sous Windows
avec l'assistant d'informations d'identification de l'AWS CLI dans le AWS CodeCommit Guide de
l'utilisateur.
Pour autoriser les connexions HTTPS vers votre site Web ou votre application sur AWS, vous avez
besoin d'un certificat de serveur SSL/TLS. Vous pouvez utiliser un certificat de serveur fourni par AWS
Certificate Manager (ACM) ou un certificat que vous avez obtenu auprès d'un fournisseur externe.
Nous vous recommandons d'utiliser ACM pour mettre en service, gérer et déployer vos certificats
de serveur. Avec ACM, vous pouvez demander un certificat, le déployer vers des ressources AWS
et laisser ACM gérer le renouvellement du certificat pour vous. Les certificats fournis par ACM sont
gratuits. Pour plus d'informations sur l'utilisation d'ACM, consultez le AWS Certificate Manager Guide
de l'utilisateur.
Pour utiliser un certificat que vous avez obtenu auprès d'un fournisseur externe avec votre site Web
ou votre application sur AWS, vous devez charger le certificat vers IAM ou l'importer dans ACM. Nous
vous recommandons d'importer vos certificats dans ACM. Vous pouvez utiliser ACM. pour gérer tous
vos certificats de serveur AWS — ceux qui sont fournis par ACM et que vous avez obtenus auprès
d'un fournisseur externe pour utiliser avec AWS. Vous pouvez utiliser des certificats stockés dans ACM
pour les mêmes services AWS qui prennent en charge les certificats stockés dans IAM (Elastic Load
Balancing, Amazon CloudFront et AWS Elastic Beanstalk). Avec ACM, vous pouvez utiliser un seul
certificat pour plusieurs de ces services simultanément. Vous pouvez importer des certificats dans
ACM à l'aide de la AWS Management Console, ce que vous ne pouvez pas faire avec IAM.
129
Pour plus d'informations sur l'importation de certificats dans ACM, consultez Importation de certificats
dans le AWS Certificate Manager Guide de l'utilisateur.
Pour plus d'informations sur le chargement de certificats dans IAM, consultez les rubriques suivantes.
Rubriques
• Chargement d'un certificat de serveur (API IAM) (p. 130)
• Récupération d'un certificat de serveur (API IAM) (p. 131)
• Liste des certificats de serveur (API IAM) (p. 131)
• Renommage d'un certificat de serveur ou mise à jour de son chemin (API IAM) (p. 131)
• Suppression d'un certificat de serveur (API IAM) (p. 132)
• Dépannage (p. 132)
Chargement d'un certificat de serveur (API IAM)
Pour charger un certificat de serveur dans IAM, vous devez fournir le certificat et sa clé privée
correspondante. Si le certificat n'est pas auto-signé, vous devez également fournir une chaîne de
certificats. (Vous n'avez pas besoin d'une chaîne de certificats lorsque vous chargez un certificat autosigné.) Avant de charger un certificat, vérifiez que vous avez tous ces éléments et qu'ils répondent aux
critères suivants :
• Le certificat doit être valide au moment du chargement. Vous ne pouvez pas charger un certificat
avant le début de sa période de validité (date NotBefore du certificat) ou après son expiration (date
NotAfter du certificat).
• La clé privée doit être non chiffrée. Vous ne pouvez pas charger une clé privée qui est protégée par
un mot de passe ou une phrase passe. Pour obtenir de l'aide pour déchiffrer une clé privée chiffrée,
consultez Dépannage (p. 132).
• Le certificat, la clé privée et la chaîne de certificats doivent être codés PEM. Pour obtenir de l'aide
pour convertir ces éléments au format PEM, consultez Dépannage (p. 132).
Pour utiliser l'API IAM pour charger un certificat, envoyez une demande UploadServerCertificate.
L'exemple suivant montre comment procéder avec l'AWS Command Line Interface (AWS CLI). Dans
cet exemple il est supposé que :
• Le certificat codé PEM est stocké dans un fichier nommé Certificate.pem.
• La chaîne de certificats codée PEM est stockée dans un fichier nommé CertificateChain.pem.
• La clé privée non chiffrée, codée PEM est stockée dans un fichier nommé PrivateKey.pem.
Pour utiliser la commande suivante, remplacez ces noms de fichier par les vôtres et
ExampleCertificate par un nom pour votre certificat chargé. Tapez la commande sur une seule
ligne continue. L'exemple suivant inclut des sauts de ligne et des espace supplémentaires pour le
rendre plus facile à lire.
$ aws iam upload-server-certificate --server-certificatename ExampleCertificate
--certificate-body file://Certificate.pem
--certificate-chain
file://CertificateChain.pem
--private-key file://PrivateKey.pem
Lorsque la commande précédente aboutit, elle renvoie des métadonnées relatives au certificat chargé,
y compris son Amazon Resource Name (ARN), son nom convivial, son identificateur (ID), sa date
d'expiration, etc.
130
Note
Si vous chargez un certificat de serveur pour l'utiliser avec Amazon CloudFront, vous devez
spécifier un chemin à l'aide de l'option --path. Le chemin doit commencer par /cloudfront
et doit inclure une barre oblique de fin (par exemple, /cloudfront/test/).
Pour utiliser les Outils AWS pour Windows PowerShell pour charger un certificat, utilisez PublishIAMServerCertificate.
Récupération d'un certificat de serveur (API IAM)
Pour utiliser l'API IAM pour récupérer un certificat, envoyez une demande GetServerCertificate.
L'exemple suivant montre comment procéder avec l'interface AWS CLI. Remplacez
ExampleCertificate par le nom du certificat à récupérer.
$ aws iam get-server-certificate --server-certificate-name ExampleCertificate
Lorsque la commande précédente aboutit, elle renvoie le certificat, la chaîne de certificats (si une
chaîne de certificats a été chargée) et des métadonnées relatives au certificat.
Note
Vous ne pouvez pas charger ou récupérer une clé privée depuis IAM après l'avoir chargée.
Pour utiliser les Outils AWS pour Windows PowerShell pour récupérer un certificat, utilisez GetIAMServerCertificate.
Liste des certificats de serveur (API IAM)
Pour utiliser l'API IAM pour afficher vos certificats de serveur chargés, envoyez une demande
ListServerCertificates. L'exemple suivant montre comment procéder avec l'interface AWS CLI.
$ aws iam list-server-certificates
Lorsque la commande précédente aboutit, elle renvoie une liste qui contient les métadonnées relatives
à chaque certificat.
Pour utiliser les Outils AWS pour Windows PowerShell pour afficher vos certificats de serveur chargés,
utilisez Get-IAMServerCertificates.
Renommage d'un certificat de serveur ou mise à jour de son
chemin (API IAM)
Pour utiliser l'API IAM pour renommer un certificat de serveur, ou mettre à jour son chemin, envoyez
une demande UpdateServerCertificate. L'exemple suivant montre comment procéder avec l'interface
AWS CLI.
Pour utiliser la commande suivante, remplacez les anciens et nouveaux noms de certificat et le chemin
d'accès du certificat, et tapez la commande sur une seule ligne continue. L'exemple suivant inclut des
sauts de ligne et des espace supplémentaires pour le rendre plus facile à lire.
$ aws iam update-server-certificate --server-certificatename ExampleCertificate
--new-server-certificatename CloudFrontCertificate
131
--new-path /cloudfront/
Lorsque la commande précédente aboutit, elle ne renvoie pas de sortie.
Pour utiliser les Outils AWS pour Windows PowerShell pour renommer un certificat de serveur ou
mettre à jour son chemin, utilisez Update-IAMServerCertificate.
Suppression d'un certificat de serveur (API IAM)
Pour utiliser l'API IAM pour supprimer un certificat de serveur, envoyez une demande
DeleteServerCertificate. L'exemple suivant montre comment procéder avec l'interface AWS CLI.
Pour utiliser la commande suivante, remplacez ExampleCertificate par le nom du certificat à
supprimer.
$ aws iam delete-server-certificate --server-certificatename ExampleCertificate
Lorsque la commande précédente aboutit, elle ne renvoie pas de sortie.
Pour utiliser les Outils AWS pour Windows PowerShell pour supprimer un certificat de serveur, utilisez
Remove-IAMServerCertificate.
Dépannage
Pour pouvoir charger un certificat vers IAM, vous devez vous assurer que le certificat, la clé privée et
la chaîne de certificats sont tous codés PEM. Vous devez également vous assurer que la clé privée est
non chiffrée. Voir les exemples suivantes.
Example Certificat PEM codé
-----BEGIN CERTIFICATE----Base64-encoded certificate
-----END CERTIFICATE-----
Example Clé privée non chiffrée codée PEM
-----BEGIN RSA PRIVATE KEY----Base64-encoded private key
-----END RSA PRIVATE KEY-----
Example Chaîne de certificats codée PEM
Une chaîne de certificats contient un ou plusieurs certificats. L'exemple suivant contient trois certificats,
mais votre chaîne de certificats peut en contenir plus ou moins.
-----BEGIN CERTIFICATE----Base64-encoded certificate
-----END CERTIFICATE---------BEGIN CERTIFICATE----Base64-encoded certificate
-----END CERTIFICATE---------BEGIN CERTIFICATE----Base64-encoded certificate
132
Si ces éléments ne sont pas au bon format pour le chargement vers IAM, vous pouvez utiliser
OpenSSL pour les convertir au format approprié.
Pour convertir un certificat ou une chaîne de certificats DER en PEM
Utilisez la commande OpenSSL x509, comme dans l'exemple suivant. Dans la commande
suivante, remplacez Certificate.der par le nom du fichier qui contient votre certificat codé
DER. Remplacez Certificate.pem par le nom souhaité du fichier de sortie devant contenir le
certificat codé PEM.
$ openssl x509 -inform DER -in Certificate.der -outform PEM out Certificate.pem
Pour convertir une clé privée de DER en PEM
Utilisez la commande OpenSSL rsa, comme dans l'exemple suivant. Dans la commande suivante,
remplacez PrivateKey.der par le nom du fichier qui contient votre clé privée codée DER.
Remplacez PrivateKey.pem par le nom souhaité du fichier de sortie devant contenir la clé
privée codée PEM.
$ openssl rsa -inform DER -in PrivateKey.der -outform PEM out PrivateKey.pem
Pour déchiffrer une clé privée chiffrée (supprimer le mot de passe ou la phrase passe)
Utilisez la commande OpenSSL rsa, comme dans l'exemple suivant. Pour utiliser la commande
suivante, remplacez EncryptedPrivateKey.pem par le nom du fichier qui contient votre clé
privée chiffrée. Remplacez PrivateKey.pem par le nom souhaité du fichier de sortie devant
contenir la clé privée non chiffrée codée PEM.
$ openssl rsa -in EncryptedPrivateKey.pem -out PrivateKey.pem
Pour convertir un ensemble de certificats de PKCS#12 (PFX) en PEM
Utilisez la commande OpenSSL pkcs12, comme dans l'exemple suivant. Dans la commande
suivante, remplacez CertificateBundle.p12 par le nom du fichier qui contient votre ensemble
de certificats codé PKCS#12. Remplacez CertificateBundle.pem par le nom souhaité du
fichier de sortie devant contenir l'ensemble de certificats codé PEM.
$ openssl pkcs12 -in CertificateBundle.p12 -out CertificateBundle.pem nodes
Pour convertir un ensemble de certificats de PKCS#7 en PEM
Utilisez la commande OpenSSL pkcs7, comme dans l'exemple suivant. Dans la commande
suivante, remplacez CertificateBundle.p7b par le nom du fichier qui contient votre ensemble
de certificats codé PKCS#7. Remplacez CertificateBundle.pem par le nom souhaité du
fichier de sortie devant contenir l'ensemble de certificats codé PEM.
$ openssl pkcs7 -in CertificateBundle.p7b -print_certs out CertificateBundle.pem
133
Groupes
Groupes IAM
Un groupe (p. 134) IAM est un ensemble d'utilisateurs IAM. Les groupes vous permettent de spécifier
des autorisations pour plusieurs utilisateurs, ce qui permet de gérer plus facilement les autorisations
pour ces utilisateurs. Par exemple, vous pouvez avoir un groupe appelé Administrateurs et accorder
à ce groupe les types d'autorisations dont les administrateurs ont généralement besoin. Tous les
utilisateurs de ce groupe reçoivent automatiquement les autorisations attribuées au groupe. Si un
nouvel utilisateur rejoint votre organisation et a besoin de privilèges d'administrateur, vous pouvez lui
attribuer les autorisations appropriées en l'ajoutant à ce groupe. De même, si une personne change
de poste dans votre organisation, au lieu de modifier les autorisations de cet utilisateur, vous pouvez
retirer celui-ci de l'ancien groupe et l'ajouter aux nouveaux groupes appropriés.
Notez qu'un groupe n'est pas vraiment une « identité » dans IAM, car il ne peut pas être identifié en
tant que Principal dans une stratégie d'autorisation. Il s'agit simplement d'un moyen d'attacher des
stratégies à plusieurs utilisateurs à la fois.
Voici quelques caractéristiques importantes des groupes :
• Un groupe peut contenir de nombreux utilisateurs et un utilisateur peut appartenir à plusieurs
groupes.
• Les groupes ne peuvent pas être imbriqués ; ils ne peuvent contenir que des utilisateurs, pas
d'autres groupes.
• Il n'existe pas de groupe par défaut qui inclut automatiquement tous les utilisateurs du compte AWS.
Si vous souhaitez disposer d'un groupe de ce type, vous devez le créer et lui affecter chaque nouvel
utilisateur.
• Il existe une limite quant au nombre de groupes dont vous pouvez disposer, et quant au nombre de
groupes auxquels un utilisateur peut appartenir. Pour de plus amples informations, veuillez consulter
Le schéma suivant illustre un exemple simple de petite entreprise. Le propriétaire de l'entreprise crée
un groupe Admins pour que des utilisateurs créent et gèrent d'autres utilisateurs au fur et à mesure
que l'entreprise se développe. Le groupe Admins crée un groupe Developers et un groupe Test.
Chacun de ces groupes se compose d'utilisateurs (personnes et applications) qui interagissent avec
AWS (Jim, Brad, DevApp1, etc.). Chaque utilisateur dispose d'un ensemble individuel d'informations
d'identification de sécurité. Dans cet exemple, chaque utilisateur appartient à un seul groupe.
Cependant, les utilisateurs peuvent appartenir à plusieurs groupes.
134
Création de groupes
Création de groupes IAM
Pour configurer un groupe, vous devez créer le groupe, lui accorder des autorisations en fonction du
type de tâche que les utilisateurs du groupe seront amenés à effectuer, puis ajouter des utilisateurs au
groupe.
Pour plus d'informations sur les autorisations requises pour créer un groupe, consultez Délégation
des autorisations d'administration des utilisateurs, des groupes et des informations d'identification
IAM (p. 285).
135
Gestion des groupes
Pour créer un groupe IAM et attacher des stratégies (AWS Management Console)
1.
2.
Dans le volet de navigation, cliquez sur Groups, puis sur Create New Group.
3.
Dans la zone Group Name, entrez le nom du groupe et cliquez sur Next Step.
Important
Les noms des groupes doivent être uniques dans un compte. La casse majusculesminuscules ne compte pas. Par exemple, vous ne pouvez pas créer des groupes nommés
« ADMINS » et « admins ».
4.
Dans la liste de stratégies, activez la case à cocher en regard de chaque stratégie devant
s'appliquer à tous les membres du groupe. Ensuite, cliquez sur Next Step.
5.
Cliquez sur Create Group.
Pour accéder à un exemple de configuration d'un groupe Administrators, consultez Création de
votre premier utilisateur administrateur et groupe IAM (p. 15).
Pour créer des groupes IAM et attacher des stratégies (AWS CLI, Outils pour Windows PowerShell,
API AWS)
Utilisez l'une des commandes suivantes pour créer un groupe :
• AWS CLI : aws iam create-group
• Outils pour Windows PowerShell : New-IAMGroup
• API AWS : CreateGroup
Gestion des groupes IAM
Amazon Web Services fournit plusieurs outils permettant de gérer les groupes IAM. Pour plus
d'informations sur les autorisations dont vous devez disposer pour ajouter ou supprimer des utilisateurs
dans un groupe, consultez Délégation des autorisations d'administration des utilisateurs, des groupes
et des informations d'identification IAM (p. 285).
Rubriques
• Liste de groupes IAM (p. 136)
• Ajout et suppression d'utilisateurs dans un groupe IAM (p. 137)
• Attacher une stratégie à un groupe IAM (p. 137)
• Affectation d'un nouveau nom à un groupe IAM (p. 138)
• Suppression d'un groupe IAM (p. 138)
Liste de groupes IAM
Vous pouvez répertorier tous les groupes de votre compte, les utilisateurs d'un groupe ou les groupes
auxquels appartient un utilisateur. Si vous utilisez l'AWS CLI, Outils pour Windows PowerShell ou l'API
AWS, vous pouvez afficher tous les groupes avec un préfixe de chemin d'accès spécifique
Pour répertorier tous les groupes de votre compte
• AWS Management Console : dans le volet de navigation, sélectionnez Groups.
136
Gestion des groupes
• AWS CLI : aws iam list-groups
• Outils pour Windows PowerShell : Get-IAMGroups
• API AWS : ListGroups
Pour répertorier les utilisateurs d'un groupe spécifique
• AWS Management Console : dans le volet de navigation, sélectionnez Groups, choisissez le nom du
groupe, puis sélectionnez l'onglet Users.
• AWS CLI : aws iam get-group
• Outils pour Windows PowerShell : Get-IAMGroup
• API AWS : GetGroup
Pour répertorier tous les groupes auxquels appartient un utilisateur
• AWS Management Console : dans le volet de navigation, sélectionnez Users, choisissez le nom
d'utilisateur, puis sélectionnez l'onglet Groups.
• AWS CLI : aws iam list-groups-for-user
• Outils pour Windows PowerShell : Get-IAMGroupForUser
• API AWS : ListGroupsForUser
Ajout et suppression d'utilisateurs dans un groupe IAM
À tout moment, vous pouvez ajouter et supprimer des utilisateurs d'un groupe IAM. Cet utile à mesure
que des utilisateurs arrivent dans votre organisation et la quittent.
Pour ajouter un utilisateur à un groupe IAM
• AWS Management Console : dans le volet de navigation, sélectionnez Groups, puis choisissez le
nom du groupe. Choisissez l'onglet Users, puis sélectionnez Add Users to Group. Sélectionnez les
utilisateurs que vous souhaitez ajouter, puis choisissez Add Users to Group.
• AWS CLI : aws iam add-user-to-group
• Outils pour Windows PowerShell : Add-IAMUserToGroup
• API AWS : AddUserToGroup
Pour supprimer un utilisateur d'un groupe IAM
• AWS Management Console : dans le volet de navigation, sélectionnez Groups, puis choisissez
le nom du groupe. Choisissez l'onglet Users, puis sélectionnez Remove Users from Group.
Sélectionnez les utilisateurs que vous souhaitez ajouter, puis choisissez Remove Users from Group.
• AWS CLI : aws iam remove-user-from-group
• Outils pour Windows PowerShell : Remove-IAMUserFromGroup
• API AWS : RemoveUserFromGroup
Attacher une stratégie à un groupe IAM
Vous pouvez attacher une stratégie gérée par AWS (p. 300), autrement dit une stratégie prédéfinie
fournie par AWS, à un groupe, comme décrit dans les étapes suivantes. Pour attacher une stratégie
gérée par le client, autrement dit une stratégie comportant des autorisations personnalisées que
vous créez, vous devez commencer par créer la stratégie. Pour plus d'informations sur la création de
stratégies gérées par le client, consultez Création de stratégies gérées par le client (p. 325).
137
Gestion des groupes
Pour plus d'informations sur les autorisations et les stratégies, consultez Gestion de l'accès (p. 281).
Pour attacher une stratégie à un groupe (AWS Management Console)
1.
2.
Dans le volet de navigation, sélectionnez Policies.
3.
Dans la liste des stratégies, sélectionnez la case à cocher en regard du nom de la stratégie à
attacher. Vous pouvez utiliser le menu Filter et la zone Search pour filtrer la liste de stratégies.
4.
Cliquez sur Policy Actions, puis sur Attach.
5.
Cliquez sur All Types dans le menu Filter, puis cliquez sur Groups.
6.
Sélectionnez la case à cocher en regard du nom du groupe auquel vous voulez attacher la
stratégie, puis cliquez sur Attach Policy.
Pour attacher une stratégie à un groupe (AWS CLI, Outils pour Windows PowerShell, API)
• AWS CLI : aws iam attach-group-policy
• Outils pour Windows PowerShell : Register-IAMGroupPolicy
• API AWS : AttachGroupPolicy
Affectation d'un nouveau nom à un groupe IAM
Lorsque vous modifiez le nom ou le chemin d'accès d'un groupe, voici ce qui suit se produit :
• Toutes les stratégies attachées au groupe restent dans le groupe sous le nouveau nom.
• Le groupe conserve également tous ses utilisateurs sous le nouveau nom.
• L'ID unique du groupe demeure le même. Pour plus d'informations sur les ID uniques, consultez ID
uniques (p. 390).
IAM ne met pas automatiquement à jour les stratégies qui référencent le groupe de manière à
utiliser le nouveau nom ; vous devez le faire manuellement. Par exemple, supposons que Bob est
responsable des tests pour l'organisation et qu'une stratégie attachée à son entité d'utilisateur IAM lui
permet d'ajouter et supprimer des utilisateurs du groupe Test. Si un administrateur renomme le groupe
Test_1 (ou modifie son chemin d'accès), l'administrateur doit également mettre à jour la stratégie
attachée à Bob afin d'utiliser le nouveau nom (ou le nouveau chemin d'accès). Sinon Bob ne sera plus
en mesure d'ajouter ou de supprimer des utilisateurs du groupe.
Pour modifier le nom d'un groupe IAM
• AWS Management Console : dans le volet de navigation, cliquez sur Groups, puis sélectionnez la
case à cocher en regard du nom du groupe. À partir de la liste Group Actions affichée en haut de la
page, sélectionnez Edit Group Name. Tapez le nom du nouveau groupe, puis cliquez sur Yes, Edit.
• AWS CLI : aws iam update-group
• Outils pour Windows PowerShell : Update-IAMGroup
• API AWS : UpdateGroup
Suppression d'un groupe IAM
Lorsque vous supprimez un groupe dans AWS Management Console, la console supprime
automatiquement tous les membres du groupe, détache toutes les stratégies gérées attachées et
supprime toutes les stratégies en ligne.
138
Gestion des groupes
En revanche, lors de la suppression d'un groupe à l'aide de l'AWS CLI, des Outils pour Windows
PowerShell ou de l'API AWS, avant de pouvoir supprimer le groupe, vous devez supprimer les
utilisateurs du groupe et les stratégies en ligne intégrées au groupe, puis détacher les stratégies
gérées attachées au groupe.
Pour supprimer un groupe IAM (AWS Management Console)
1.
2.
3.
Dans le volet de navigation, sélectionnez Groups.
Dans la liste de groupes, sélectionnez la case à cocher en regard du nom du groupe à supprimer.
Vous pouvez utiliser le menu Filter et la zone Search pour filtrer la liste de stratégies.
4.
Cliquez sur Group Actions, puis sur Delete Group.
5.
Dans la boîte de dialogue de confirmation, cliquez sur Yes, Delete.
Pour supprimer un groupe IAM (AWS CLI, Outils pour Windows PowerShell, API AWS)
1.
Supprimez tous les utilisateurs du groupe.
• CLI : aws iam get-group (pour obtenir la liste des utilisateurs dans le groupe) et aws iam
remove-user-from-group (pour supprimer un utilisateur du groupe)
(Get-IAMGroup -GroupName "GroupToDelete").Users | RemoveIAMUserFromGroup -GroupName "GroupToDelete" -Force
2.
• API AWS : GetGroup (pour obtenir la liste des utilisateurs dans le groupe) et
RemoveUserFromGroup (pour supprimer un utilisateur du groupe)
Supprimez toutes les stratégies en ligne intégrées au groupe.
• CLI : aws iam list-group-policies (pour obtenir la liste des stratégies en ligne du groupe) et aws
iam delete-group-policy (pour supprimer les stratégies en ligne du groupe)
Get-IAMGroupPolicies -GroupName "GroupToReplace" | % { RemoveIAMGroupPolicy -GroupName "GroupToReplace" -PolicyName $_ -Force}
3.
• API AWS : ListGroupPolicies (pour obtenir la liste des stratégies en ligne du groupe) et
DeleteGroupPolicy (pour supprimer les stratégies en ligne du groupe)
Détachez toutes les stratégies gérées attachées au groupe.
• CLI : aws iam list-attached-group-policies (pour obtenir la liste des stratégies gérées attachées
au groupe) et aws iam detach-group-policy (pour détacher une stratégie gérée du groupe)
Get-IAMAttachedUserPolicies -UserName "UserToDelete" | % { UnregisterIAMUserPolicy -PolicyArn $_.PolicyArn -UserName -UserName "UserToDelete"
-Force }
4.
• API AWS : ListAttachedGroupPolicies (pour obtenir la liste des stratégies gérées attachées au
groupe) et DetachGroupPolicy (pour détacher une stratégie gérée du groupe)
Supprimez le groupe.
• CLI : aws iam delete-group
• Outils pour Windows PowerShell : Remove-IAMGroup
139
Rôles
• API AWS : DeleteGroup
Rôles IAM
Un rôle IAM est similaire à un utilisateur, car il s'agit d'une identité AWS avec des stratégies
d'autorisation qui déterminent ce que l'identité peut et ne peut pas faire dans AWS. En revanche, au
lieu d’être associé de manière unique à une personne, un rôle est conçu pour être assumé par tout
utilisateur qui en a besoin. En outre, aucune information d'identification (mot de passe ou clés d'accès)
n'est associée à celui-ci. Au lieu de cela, si un utilisateur est affecté à un rôle, les clés d'accès sont
créées de manière dynamique et fournies à l'utilisateur.
Vous pouvez utiliser des rôles pour déléguer l'accès à des utilisateurs, des applications ou des
services qui n'ont normalement pas accès à vos ressources AWS. Par exemple, vous pouvez accorder
aux utilisateurs de votre compte AWS l'accès à des ressources dont ils ne disposent généralement
pas, ou accorder aux utilisateurs d'un compte AWS, l'accès aux ressources d'un autre compte. Il est
également possible d'autoriser une application mobile à utiliser des ressources AWS, mais sans pour
autant intégrer de clés AWS dans l'application (où leur rotation peut être difficile et d'où les utilisateurs
peuvent éventuellement les extraire). Dans certains cas, vous voulez accorder l'accès à AWS à des
utilisateurs qui ont déjà des identités définies en dehors d'AWS, par exemple dans votre annuaire
d'entreprise. Ou, vous pouvez accorder l'accès à votre compte à des tiers afin de leur permettre de
réaliser un audit de vos ressources.
Pour de tels scénarios, vous pouvez déléguer l'accès aux ressources AWS à l'aide d'un rôle IAM. Cette
section présente les rôles et les différentes façons de les utiliser. Elle explique également quand et
comment choisir les diverses approches et comment créer, gérer, prendre (assumer) et supprimer des
rôles.
Rubriques
• Termes et concepts relatifs aux rôles (p. 140)
• Scénarios courants pour les rôles : utilisateurs, applications et services. (p. 142)
• Fournisseurs d'identité et fédération (p. 148)
• Création de rôles IAM (p. 187)
• Utilisation de rôles IAM (p. 214)
• Gestion des rôles IAM (p. 233)
• Différence entre les rôles IAM et les stratégies basées sur les ressources (p. 241)
Termes et concepts relatifs aux rôles
Voici quelques termes de base pour vous aider à vous familiariser avec les rôles.
Rôle
Un rôle est essentiellement un ensemble d'autorisations d'accès à des actions et ressources dans
AWS. Ces autorisations sont attachées à un rôle, et non pas à un utilisateur ou un groupe IAM.
Les rôles peuvent être utilisés par :
• Un utilisateur IAM qui appartient au même compte AWS que le rôle
• Un utilisateur IAM qui appartient à un compte AWS différent de celui du rôle
• Un service web proposé par AWS tel qu'Amazon Elastic Compute Cloud (Amazon EC2)
• Un utilisateur externe authentifié par un service de fournisseur d'identité (IdP) externe,
compatible avec SAML 2.0 ou OpenID Connect, ou un broker d'identité personnalisé.
Délégation
La délégation octroie à une personne l'autorisation d'accéder aux ressources que vous contrôlez.
Cette procédure implique la mise en place d'une relation d'approbation entre le compte
140
Termes et concepts
propriétaire des ressources (compte d'approbation) et le compte auquel appartiennent les
utilisateurs devant accéder aux ressources (compte approuvé). Les comptes d'approbation et
approuvés peuvent être :
• Un même compte.
• Deux comptes se trouvant tous deux sous votre contrôle (ou celui de votre organisation).
• Deux comptes appartenant à des organisations différentes.
Pour déléguer l'autorisation d'accès à une ressource, vous créez un rôle IAM (p. 187) auquel
sont attachées deux stratégies (p.
). La stratégie d'autorisation accorde à l'utilisateur du rôle
les autorisations nécessaires pour exécuter les tâches requises sur la ressource. La stratégie
d'approbation détermine les comptes approuvés autorisés à accorder à leurs utilisateurs les
autorisations nécessaires pour assumer le rôle. Gardez à l'esprit que vous ne pouvez pas spécifier
de caractère générique (*) comme principal dans la stratégie d'approbation du rôle. La stratégie
d'approbation du rôle dans le compte d'approbation représente la moitié des autorisations.
L'autre moitié est une stratégie d'autorisation attachée à l'utilisateur dans le compte approuvé
qui autorise cet utilisateur à prendre ou assumer le rôle (p. 215). Un utilisateur qui assume un
rôle temporairement abandonne ses propres autorisations, de manière à adopter celles du rôle.
Lorsque l'utilisateur quitte le rôle ou cesse de l'utiliser, ses autorisations d'origine sont restaurées.
Un paramètre supplémentaire appelé ID externe (p. 193) permet de sécuriser l'utilisation de
rôles entre des comptes qui ne sont pas contrôlés par la même organisation.
Fédération
La fédération crée une relation d'approbation entre un fournisseur d'identité externe et AWS.
Les utilisateurs peuvent se connecter à un fournisseur d'identité web tel que Login with Amazon,
Facebook, Google, ou tout autre fournisseur d'identité compatible avec OpenID Connect (OIDC).
Ils peuvent également se connecter à un système d'identité d'entreprise compatible avec SAML
(Security Assertion Markup Language) 2.0 tel que les services ADFS (Active Directory Federation
Services) de Microsoft. Lorsque vous utilisez OIDC et SAML 2.0 pour configurer une relation
d'approbation entre ces fournisseurs d'identité externes et AWS, l'utilisateur est affecté à un rôle
IAM et reçoit des informations d'identification temporaires qui lui permettent d'accéder à vos
ressources AWS.
Stratégie
Une stratégie (p. 402) IAM est un document au format JSON dans lequel vous définissez les
autorisations pour un rôle. Le document est écrit conformément aux règles du langage de stratégie
IAM (p. 402).
Lorsque vous créez un rôle, vous créez deux stratégies distinctes pour celui-ci, à savoir une
stratégie d'approbation qui spécifie qui est autorisé à assumer le rôle (l'entité autorisée, ou
mandataire ; voir le terme suivant) et la stratégie d'autorisation qui définit les actions et les
ressources que le mandataire peut utiliser.
Mandataire
Dans AWS un mandataire est une entité qui peut exécuter des actions et accéder à des
ressources. Un mandataire peut être un compte AWS (l'utilisateur « racine »), un utilisateur IAM
ou un rôle. Vous pouvez accorder des autorisations d'accès à une ressource de l'une des façons
suivantes :
• Vous pouvez attacher une stratégie d'autorisation à un utilisateur (directement, ou indirectement
via un groupe) ou à un rôle.
• Pour les services qui prennent en charge les stratégies basées sur les ressources, vous pouvez
identifier le mandataire dans l'élément Principal d'une stratégie attachée à la ressource.
Si vous référencez un compte AWS en tant que mandataire, il s'agit généralement de n'importe
quel mandataire défini dans ce compte.
Note
Vous ne pouvez pas utiliser de caractère générique (*) dans l'élément Principal d'une
stratégie d'approbation d'un rôle.
141
Scénarios courants
Permettre l'accès entre comptes
L'octroi de l'accès aux ressources d'un compte à un mandataire approuvé d'un autre compte
est souvent appelé accès entre comptes. Les rôles constituent le principal moyen d'accorder
l'accès entre plusieurs comptes. Toutefois, dans le cas de certains services web d'AWS, vous
pouvez attacher une stratégie directement à une ressource (au lieu d'utiliser un rôle en tant
que proxy). Il s'agit là de stratégies basées sur les ressources que vous pouvez utiliser pour
accorder l'autorisation d'accès aux ressources aux mandataires d'un autre compte AWS. Les
services suivants prennent en charge les stratégies basées sur les ressources pour les ressources
spécifiées : compartiments Amazon Simple Storage Service (S3), coffres Amazon Glacier,
rubriques Amazon Simple Notification Service (SNS) et files d'attente Amazon Simple Queue
Service (SQS). Pour de plus amples informations, veuillez consulter Différence entre les rôles IAM
et les stratégies basées sur les ressources (p. 241).
Scénarios courants pour les rôles : utilisateurs,
applications et services.
Avec la plupart des fonctions AWS, vous disposez généralement de deux manières d'utiliser un rôle :
de manière interactive dans la console IAM ou par programmation avec l'AWS CLI, l'Outils pour
Windows PowerShell ou l'API.
• Les utilisateurs IAM de votre compte qui utilisent la console IAM peuvent passer à un rôle leur
permettant d'utiliser temporairement les autorisation du rôle dans la console. Les utilisateurs
abandonnent leurs autorisations d'origine et acceptent les autorisations attribuées au rôle. Lorsque
les utilisateurs quittent le rôle, leurs autorisations d'origine sont restaurées.
• Une application ou un service offerts par AWS (comme Amazon EC2) peut assumer un rôle en
demandant des informations d'identification de sécurité temporaires pour un rôle avec lequel
effectuer des demandes par programmation à AWS. Vous utilisez ce rôle ainsi pour éviter de
partager ou de conserver des informations d'identification de sécurité à long terme (par exemple, en
créant un utilisateur IAM) pour chaque entité qui doit accéder à une ressource.
Note
Ce manuel utilise les phrases passer à un rôle et assumer un rôle de manière
interchangeable.
La solution la plus simple pour utiliser des rôles consiste à accorder à vos utilisateurs IAM des
autorisations pour passer à des rôles que vous créez dans votre propre compte ou un autre compte
AWS. Ils peuvent changer de rôles facilement à l'aide de la console IAM pour utiliser des autorisations
dont vous ne souhaitez pas qu'ils disposent d'ordinaire et il leur suffit de quitter le rôle pour renoncer
à ces autorisations. Cela permet d'empêcher un accès accidentel à des ressources sensibles ou leur
modification involontaire.
Pour utiliser les rôles de manière plus complexe, comme accorder l'accès à des applications et
des services, ou à des utilisateurs externes fédérés, vous pouvez appeler l'API AssumeRole. Cet
appel d'API renvoie un ensemble d'informations d'identification temporaires que l'application peut
utiliser dans les appels d'API suivants. Les tentatives d'actions avec les informations d'identification
temporaires ne disposent que des autorisations accordées par le rôle associé. Une application n'a
pas besoin de « quitter » le rôle de la même manière qu'un utilisateur dans la console. L'application
arrête simplement d'utiliser les informations d'identification temporaires et reprend ses appels avec les
informations d'identification d'origine.
Les utilisateurs fédérés se connectent à l'aide d'informations d'identification émises par un fournisseur
d'identité (IdP). AWS fournit ensuite des informations d'identification temporaires à l'IdP approuvé à
transmettre à l'utilisateur pour qu'il les inclue dans les demandes de ressources AWS suivantes. Ces
informations d'identification fournissent des autorisations accordées au rôle attribué.
142
Scénarios courants
Cette section présente les scénarios suivants :
• Fournir à un utilisateur IAM l'accès à un compte AWS que vous possédez pour qu'il accède à des
ressources se trouvant dans un autre compte que vous possédez (p. 143)
• Fournir à des utilisateurs IAM l'accès à des comptes AWS appartenant à des tiers (p. 145)
• Fournir à des ressources AWS l'accès à des services proposés par AWS (p. 146)
• Fournir l'accès à des utilisateurs authentifiés en externe (fédération d'identité) (p. 146)
Fournissez l'accès à un utilisateur IAM à un autre compte AWS
vous appartenant
Vous pouvez accorder à vos utilisateurs IAM des autorisations pour passer à des rôles dans votre
propre compte AWS ou à des rôles définis dans d'autres comptes AWS vous appartenant.
Note
Si vous souhaitez accorder l'accès à un compte que ne vous appartenant pas ou que vous
ne contrôlez pas, consultez Octroi d'un accès à des comptes AWS appartenant à des
tiers (p. 145) ultérieurement dans cette rubrique.
Imaginons que vous avez des instances Amazon Elastic Compute Cloud (Amazon EC2) qui sont
critiques pour votre organisation. Au lieu d'accorder directement à vos utilisateurs l'autorisation de
mettre fin aux instances, vous pouvez créer un rôle avec ces privilèges et autoriser les administrateurs
à passer au rôle quand ils ont besoin de mettre fin à une instance. Cela ajoute les couches de
protection suivantes aux instances :
• Vous devez accorder explicitement à vos utilisateurs l'autorisation d'assumer le rôle.
• Vos utilisateurs doivent passer activement au rôle à l'aide de l'AWS Management Console.
• Vous pouvez ajouter une protection d'authentification multi-facteurs (MFA) au rôle afin que seuls les
utilisateurs qui se connectent avec un périphérique MFA puissent assumer le rôle.
Nous vous recommandons d'utiliser cette approche pour appliquer le principe du moindre accès, c'està-dire de restreindre l'utilisation d'autorisations d'un niveau élevé aux seules fois où elles sont requises
pour des tâches spécifiques. Grâce aux rôles, vous pouvez empêcher les modifications accidentelles
apportées aux environnements sensibles, en particulier si vous les combinez à des audits (p. 358)
pour vous assurer que les rôles sont utilisés uniquement quand ils sont requis.
Lorsque vous créez un rôle à cette fin, vous spécifiez les comptes en fonction de l'ID des utilisateurs
ayant besoin d'accéder à l'élément Principal de la stratégie d'approbation du rôle. Vous pouvez
ensuite accorder à des utilisateurs spécifiques de ces autres comptes des autorisations à passer au
rôle.
Un utilisateur d'un compte peut passer à un rôle dans le même compte ou dans un autre compte.
Lorsqu'il utilise le rôle, l'utilisateur peut exécuter uniquement les actions et accéder uniquement aux
ressources autorisées par le rôle. Leurs autorisations utilisateur d'origine sont suspendues. Lorsque
l'utilisateur quitte le rôle, ses autorisations utilisateur d'origine sont restaurées.
Dans un autre exemple, imaginons que votre organisation dispose de plusieurs comptes AWS pour
isoler un environnement de développement d'un environnement de production. Les utilisateurs du
compte de développement peuvent occasionnellement avoir besoin d'accéder à des ressources du
compte de production, par exemple, lorsque vous promouvez une mise à jour de l'environnement
de développement vers l'environnement de production. Même si vous pouvez créer des identités
143
Scénarios courants
(et mots de passe) distinctes pour les utilisateurs qui travaillent dans les deux comptes, la gestion
des informations d'identification pour plusieurs comptes rend la gestion des identités difficile. Dans
l'illustration suivante, tous les utilisateurs sont gérés dans le compte de développement, mais certains
développeurs nécessitent un accès limité au compte de production. Le compte de développement
se compose de deux groupes : les Développeurs et les Testeurs, chacun disposant de sa propre
stratégie.
Utiliser un rôle pour déléguer des autorisations à un utilisateur dans un autre compte
1. Dans le compte de production, un administrateur utilise IAM pour créer le rôle UpdateAPP
dans ce compte. Dans le rôle, l'administrateur définit une stratégie d'approbation qui spécifie le
compte de développement en tant que Principal, ce qui signifie que les utilisateurs autorisés
du compte de développement peuvent utiliser le rôle UpdateAPP. L'administrateur utilise définit
également une stratégie d'autorisation pour le rôle qui spécifie que les utilisateurs du rôle ont des
autorisations de lecture et d'écriture pour le compartiment Amazon Simple Storage Service (S3)
appelé productionapp.
L'administrateur partage ensuite le numéro du compte et le nom du rôle (pour les utilisateurs de la
console AWS) ou l'ARN (Amazon Resource Name) (pour l'accès à AWS CLI, l'Outils pour Windows
PowerShell ou à l'API AWS) du rôle avec quiconque a besoin d'assumer le rôle. L'ARN du rôle
peut ressembler à arn:aws:iam::123456789012:role/UpdateAPP, où le rôle est appelé
UpdateAPP et le rôle a été créé dans le numéro de compte 123456789012.
Note
L'administrateur peut, facultativement, configurer le rôle afin que les utilisateurs qui
assument le rôle doivent d'abord être authentifiés à l'aide de l'authentification multi-facteurs
(MFA). Pour de plus amples informations, veuillez consulter Configuration de l'accès aux
API protégé par MFA (p. 109).
2. Dans le compte de développement, un administrateur accorde aux membres du groupe
Développeurs l'autorisation de changer de rôle. Pour cela, il accorde au groupe Développeurs
l'autorisation d'appeler l'API AssumeRole AWS Security Token Service (AWS STS) du rôle
UpdateAPP. Tout utilisateur IAM appartenant au groupe Développeurs dans le compte de
développement peut à présent passer au rôle UpdateAPP du compte de production. Les autres
utilisateurs n'appartenant pas au groupe de développeurs n'ont pas l'autorisation de passer au rôle
et ne peuvent, donc, pas accéder au compartiment S3 dans le compte de production.
3. L'utilisateur demande les changements de rôle :
144
Scénarios courants
• Console AWS : L'utilisateur clique sur le nom du compte dans la barre de navigation et choisit
Switch Role. L'utilisateur spécifie l'ID (ou l'alias) du compte, ainsi que le nom du rôle. Sinon,
l'utilisateur peut cliquer sur un lien envoyé par e-mail par l'administrateur. Le lien dirige l'utilisateur
vers la page Switch Role avec les détails déjà remplis.
• API AWS/Outils pour Windows PowerShell/AWS CLI : Un utilisateur appartenant au groupe
Développeurs du compte de développement appelle la fonction AssumeRole pour obtenir les
informations d'identification du rôle UpdateAPP. L'utilisateur spécifie l'ARN du rôle UpdateAPP
dans le cadre de l'appel. Si un utilisateur du groupe Testeurs fait la même demande, la demande
échoue, car les Testeurs ne sont pas autorisés à appeler AssumeRole pour l'ARN de rôle
UpdateAPP.
4. AWS STS renvoie les informations d’identification temporaires :
• Console AWS : AWS STS vérifie la demande par rapport à la stratégie d'approbation du rôle pour
s'assurer que la demande est émise par une entité approuvée (ce qui est le cas : le compte de
développement). Après vérification, AWS STS renvoie les informations d'identification de sécurité
temporaires à la console AWS.
• API/CLI : AWS STS vérifie la demande par rapport à la stratégie d'approbation du rôle pour
s'assurer que la demande est émise par une entité approuvée (ce qui est le cas : le compte
Développement). Après vérification, AWS STS renvoie les informations d'identification de sécurité
temporaires à l'application.
5. Les informations d'identification temporaires autorisent l'accès à la ressource AWS :
• Console AWS : La console AWS utilise les informations d'identification temporaires pour le
compte de l'utilisateur pour toutes les actions suivantes sur la console, afin de lire et d'écrire dans
le compartiment productionapp. La console ne peut pas accéder à d'autres ressources du
compte de production. Lorsque l'utilisateur quitte le rôle, les autorisations dont ils disposait avant
de changer de rôle sont restaurées.
• API/CLI : L'application utilise les informations d'identification de sécurité temporaires pour mettre
à jour le compartiment productionapp. Avec les informations d'identification de sécurité
temporaires, l'application peut uniquement lire et écrire dans le compartiment productionapp,
mais ne peut pas accéder à d'autres ressources du compte Production. L'application n'a pas
besoin de quitter le rôle. Au contraire, elle arrête d'utiliser les informations d'identification
temporaires et utilise les informations d'identification d'origine dans les appels d'API suivants.
Pour plus d'informations sur la création d'un rôle pour déléguer l'accès aux utilisateurs IAM, consultez
Création d'un rôle pour la délégation d'autorisations à un utilisateur IAM. (p. 187).
Octroi d'un accès à des comptes AWS appartenant à des tiers
Lorsque des tiers ont besoin d'accéder à des ressources AWS de votre organisation, vous pouvez
utiliser des rôles pour leur déléguer l'accès. Par exemple, un tiers peut fournir un service de gestion de
vos ressources AWS. Avec des rôles IAM, vous pouvez accorder à ces tiers l'accès à vos ressources
AWS sans partager vos informations d'identification (credentials) de sécurité AWS. Par contre, le tiers
peut accéder à vos ressources AWS en assumant un rôle que vous créez dans votre compte AWS.
Les tiers doivent vous fournir les informations suivantes pour vous permettre de créer un rôle qu'ils
peuvent assumer :
• Leur ID de compte AWS. Vous spécifiez leur ID de compte AWS en tant que personne habilitée
lorsque vous définissez la stratégie d'approbation pour le rôle.
• Un ID externe que le tiers utilise pour vous associer de manière unique à votre rôle. Vous spécifiez
cet ID fourni par le tiers en tant que condition lorsque vous définissez la stratégie d'approbation pour
le rôle. Pour plus d'informations sur l'ID externe, consultez Procédure d'utilisation d'un ID externe
lorsque vous accordez l'accès à vos ressources AWS à un tiers (p. 193).
• Les autorisations dont le tiers a besoin pour utiliser vos ressources AWS. Vous spécifiez ces
autorisations lors de la définition de la stratégie d'accès du rôle. Cette stratégie définit les actions
que les utilisateurs tiers peuvent entreprendre et les ressources auxquelles ils peuvent accéder.
145
Scénarios courants
Après avoir créé le rôle, vous devez fournir l'Amazon Resource Name (ARN) du rôle au tiers. Ce
dernier a besoin de l'ARN de votre rôle pour utiliser le rôle.
Pour plus d'informations sur la création d'un rôle pour déléguer l'accès à un tiers, consultez Procédure
d'utilisation d'un ID externe lorsque vous accordez l'accès à vos ressources AWS à un tiers (p. 193).
Important
Lorsque vous accordez à des tiers l'accès à vos ressources AWS, ceux-ci peuvent accéder
aux ressources pour lesquelles vous leur octroyez des autorisations. L'utilisation de vos
ressources par ces tiers vous est facturée. Veillez à limiter leur utilisation de vos ressources de
façon appropriée.
Fourniture d'accès à un service AWS
Quelques services AWS utilisent des rôles pour contrôler les ressources auxquelles le service peut
accéder. Chaque service est différent en termes d'utilisation des rôles et de la façon dont les rôles
sont affectés au service. Lorsqu'un service AWS tel qu'une instance EC2 qui exécute votre application
doit accéder à une ressource AWS comme un compartiment S3 ou une table DynamoDB, le service
doit disposer d'informations d'identification de sécurité qui lui accordent des autorisations sur la
ressource. N'intégrez pas ou ne transmettez pas directement les informations d'identification d'un
utilisateur IAM dans une instance, car la distribution ou la rotation d'informations d'identification à long
terme à plusieurs instances s'avère délicate à gérer et présente un risque potentiel sur le plan de la
sécurité. Une meilleure approche consiste à créer un rôle qui est attribué à l'instance Amazon EC2
lors de son lancement. AWS fournit automatiquement des informations d'identification de sécurité
temporaires que l'instance Amazon EC2 utilise pour le compte de ses applications. Pour de plus
amples informations, veuillez consulter Utilisation d'un rôle IAM pour accorder des autorisations à des
Reportez-vous à la documentation AWS de chaque service pour vérifier s'il utilise des rôles et savoir
comment attribuer un rôle au service afin qu'il l'utilise.
Pour plus d'informations sur la création d'un rôle pour déléguer l'accès à un service d'AWS, consultez
Création d'un rôle pour la délégation d'autorisations à un service AWS (p. 197).
Fourniture d'accès à des utilisateurs authentifiés en externe
(fédération d'identité)
Il se peut que vos utilisateurs aient déjà des identités en dehors d'AWS, par exemple, dans un
annuaire d'entreprise. Si ces utilisateurs doivent se servir de ressources AWS (ou travailler avec
des applications qui accèdent à ces ressources), alors ces utilisateurs doivent également disposer
d'informations d'identification de sécurité AWS. A l'aide d'un rôle IAM, vous pouvez définir des
autorisations pour des utilisateurs dont l'identité est fédérée par votre organisation ou un fournisseur
d'identité (IdP) tiers.
Fédération d'utilisateurs d'une application mobile ou web à l'aide d'Amazon
Cognito
Si vous créez une application mobile ou web qui accède à des ressources AWS, celle-ci doit disposer
d'informations d'identification de sécurité pour pouvoir effectuer des demandes par programmation
à AWS. Pour la plupart des scénarios impliquant des applications mobiles, nous recommandons
d'utiliser Amazon Cognito. Vous pouvez utiliser ce service avec le kit SDK AWS Mobile pour iOS et
le kit SDK AWS Mobile pour systèmes d'exploitation Android et Fire pour créer des identités uniques
pour les utilisateurs afin de les authentifier pour un accès sécurisé à vos ressources AWS. Amazon
Cognito prend en charge les mêmes fournisseurs d'identité que ceux répertoriés dans la section
146
Scénarios courants
suivante, ainsi que les identités authentifiées par le développeur et les accès non authentifiés (invité).
Amazon Cognito fournit également des API pour la synchronisation des données utilisateur afin de
les conserver à mesure que les utilisateurs passent d'un périphérique à l'autre. Pour de plus amples
informations, veuillez consulter Utilisation de Amazon Cognito pour applications mobiles (p. 150).
Fédération d'utilisateurs à l'aide de fournisseurs d'identité publics ou d'OpenID
Connect
Chaque fois que cela est possible, utilisez Amazon Cognito pour les scénarios impliquant des
applications mobiles ou web. Amazon Cognito exécute pour vous en arrière-plan la plupart des
échanges avec le fournisseur d'identité public. Il fonctionne avec les mêmes services tiers et prend
également en charge les connexions anonymes. Toutefois, dans le cas de scénarios plus complexes,
vous pouvez avoir directement recours à un service tiers tel que Login with Amazon, Facebook,
Google, ou tout autre IdP compatible avec OpenID Connect (OIDC). Pour plus d'informations sur
l'utilisation de la fédération d'identité web avec l'un des ces services, consultez A propos de la
fédération d'identité web (p. 149).
Fédération d'utilisateurs avec SAML 2.0
Si l'organisation utilise déjà un logiciel de fournisseur d'identité prenant en charge SAML 2.0 (Security
Assertion Markup Language 2.0), vous pouvez créer une relation d'approbation entre l'organisation, en
tant que fournisseur d'identité (IdP), et AWS en tant que fournisseur de services. Il est ensuite possible
d'utiliser SAML pour configurer les utilisateurs avec une connexion avec authentification unique (SSO)
fédérée à AWS Management Console ou avec un accès fédéré permettant d'appeler les API AWS. Par
exemple, si votre entreprise utilise Microsoft Active Directory et Active Directory Federation Services,
vous pouvez utiliser la fédération à l'aide de SAML 2.0. Pour plus d'informations sur la fédération
d'utilisateurs à l'aide de SAML 2.0, consultez A propos de la fédération SAML 2.0 (p. 156).
Fédération d'utilisateurs via la création d'une application de broker d'identité
personnalisé
Si votre base d'identités n'est pas compatible avec SAML 2.0, vous pouvez créer une application
de broker d'identité personnalisé capable d'exécuter une fonction similaire. Le broker authentifie les
utilisateurs, demande des informations d'authentification temporaires pour ceux-ci à partir d'AWS, puis
leur fournit ces informations d'identification pour leur permettre d'accéder aux ressources AWS.
Par exemple, de nombreux employés d'Example Corp. doivent exécuter des applications internes
qui accèdent aux ressources AWS de l'entreprise. Ils disposent déjà d'identités dans le système
d'identité et d'authentification de l'entreprise et, par conséquent, Example Corp. ne souhaite pas créer
un utilisateur IAM séparé pour chacun de ses employés.
Bob est un développeur au sein d'Example Corp. Pour permettre aux applications internes d'Example
Corp. d'accéder aux ressources AWS de l'entreprise, il développe une application de broker
d'identité personnalisé. L'application vérifie que les employés sont connectés au système d'identité
et d'authentification existant d'Example Corp., par exemple LDAP, Active Directory ou un autre
système. L'application de broker d'identité obtient ensuite des informations d'identification de sécurité
temporaires pour les employés. Ce scénario est similaire au précédent (une application mobile qui
utilise un système d'authentification personnalisé), hormis le fait que toutes les applications qui doivent
accéder aux ressources AWS s'exécutent au sein d'un réseau d'entreprise et que l'entreprise dispose
déjà d'un système d'authentification.
Pour obtenir les informations d'identification de sécurité temporaires, l'application de broker
d'identité appelle AssumeRole ou GetFederationToken, selon la façon dont Bob veut gérer
les stratégies des utilisateurs et le délai d'expiration des informations d'identification. (Pour plus
d'informations sur les différences entre ces API, consultez Informations d'identification de sécurité
temporaires (p. 244) et Contrôle des autorisations affectées aux informations d'identification
de sécurité temporaires (p. 262).) L'appel retourne des informations d'identification de sécurité
147
Fournisseurs d'identité et fédération
temporaires constituées d'un ID de clé d'accès AWS, d'une clé d'accès secrète et d'un jeton de
session. L'application de broker d'identité rend ensuite ces informations d'identification de sécurité
temporaires accessibles à l'application interne de l'entreprise. L'application peut alors utiliser ces
informations d'identification de sécurité temporaires pour appeler directement AWS. L'application met
en cache les informations d'identification jusqu'à ce qu'elles parviennent à expiration, puis demande un
nouvel ensemble d'informations d'identification temporaires. L'illustration suivante décrit ce scénario.
Exemple de flux avec une application de broker d'identité personnalisé
Ce scénario utilise les attributs suivants :
• L'application de broker d'identité dispose d'autorisations d'accès à l'API du service de jeton (STS)
d'IAM pour créer des informations d'identification de sécurité temporaires.
• L'application de broker d'identité peut vérifier que les employés sont authentifiés dans le système
d'authentification existant.
• Les utilisateurs peuvent obtenir une URL temporaire (appelée « authentification unique ») qui leur
permet d'accéder à AWS Management Console.
Pour consulter un exemple d'application similaire à l'application de broker d'identité décrite dans ce
scénario, reportez-vous à Exemple d'application de la fédération d'identité pour un cas d'utilisation
d'Active Directory dans les Exemples de code et bibliothèques AWS. Pour plus d'informations sur la
création d'informations d'identification de sécurité temporaires, consultez Obtention d'informations
d'identification temporaires de sécurité (p. 246). Pour plus d'informations sur l'accès des utilisateurs
fédérés à AWS Management Console, consultez Activation de l'accès des utilisateurs fédérés
SAML 2.0 à l'AWS Management Console (p. 176).
Si vous gérez déjà des identités utilisateur en dehors d'AWS, vous pouvez utiliser des fournisseurs
d'identité IAM au lieu de créer des utilisateurs IAM dans votre compte AWS. Un fournisseur d'identité
(IdP) vous permet de gérer vos identités utilisateur en dehors d'AWS et de donner à ces identités
utilisateur externes les autorisations nécessaires pour utiliser les ressources AWS de votre compte.
Ceci est utile si votre organisation dispose déjà de son propre système d'identité, par exemple un
148
répertoire d'utilisateurs d'entreprise. Il en est de même si vous créez une application web ou mobile
devant accéder aux ressources AWS.
Lorsque vous utilisez un fournisseur d'identité, vous n'avez pas à créer de code de connexion
personnalisé ni à gérer vos propres identités utilisateur, car le fournisseur d'identité le fait pour vous.
Vos utilisateurs externes se connectent via un fournisseur d'identité réputé comme Login with Amazon,
Facebook, Google ou de nombreux autres. Vous pouvez accorder à ces identités externes des
autorisations leur permettant d'utiliser les ressources AWS de votre compte. Les fournisseurs d'identité
vous permettent de mieux sécuriser votre compte AWS, car vous n'avez pas à distribuer ou intégrer
d'informations d'identification de sécurité à long terme comme des clés d'accès IAM, dans votre
application.
Pour utiliser un fournisseur d'identité, vous créez une entité de fournisseur d'identité IAM de manière
à établir une relation d'approbation entre votre compte AWS et le fournisseur d'identité. IAM prend en
charge les fournisseurs d'identité compatibles avec OpenID Connect (OIDC) ou SAML 2.0 (Security
Assertion Markup Language 2.0). Pour plus d'informations sur l'utilisation de l'un de ces fournisseurs
d'identité avec AWS, consultez les sections suivantes :
• A propos de la fédération d'identité web (p. 149)
• A propos de la fédération SAML 2.0 (p. 156)
Pour plus d'informations sur la création de l'entité de fournisseur d'identité dans IAM pour établir
une relation d'approbation entre un fournisseur d'identité compatible et AWS, consultez Création de
fournisseurs d'identité IAM (p. 160)
A propos de la fédération d'identité web
Supposons que vous créez une application mobile qui accède à des ressources AWS telles qu'un jeu
qui s'exécute sur un appareil mobile et enregistre les informations relatives aux joueurs et aux scores à
l'aide d'Amazon S3 et de DynamoDB.
Lors de la création de cette application, vous envoyez aux services AWS des demandes qui doivent
être signées à l'aide d'une clé d'accès AWS. Toutefois, nous vous recommandons fortement de ne
pas intégrer ou distribuer d'informations d'identification AWS à long terme avec des applications
qu'un utilisateur télécharge sur un appareil, y compris à partir d'un magasin chiffré. Il est préférable
de créer l'application de façon à ce que celle-ci demande des informations d'identification de sécurité
AWS temporaires de manière dynamique, si nécessaire, à l'aide de la fédération d'identité web. Les
informations d'identification temporaires sont mappées à un rôle AWS qui dispose uniquement des
autorisations nécessaires pour exécuter les tâches requises par l'application mobile.
Lors de l'utilisation de la fédération d'identité web, il n'est pas nécessaire de créer de code de
connexion personnalisé ni de gérer vos propres identités utilisateur. Au lieu de cela, les utilisateurs
de votre application peuvent se connecter à l'aide d'un fournisseur d'identité (IdP) reconnu tel que
Login with Amazon, Facebook, Google, ou tout autre IdP compatible avec OpenID Connect (OIDC),
recevoir un jeton d'authentification, puis échanger ce jeton dans AWS afin d'obtenir des informations
d'identification de sécurité temporaires qui sont mappées à un rôle IAM disposant d'autorisations
permettant d'utiliser les ressources de votre compte AWS. L'utilisation d'un IdP vous permet de mieux
sécuriser votre compte AWS, car vous n'avez pas à intégrer ni distribuer d'informations d'identification
de sécurité à long terme dans votre application.
Pour la plupart des scénarios, il est recommandé d'utiliser Amazon Cognito, car cette application agit
en tant que broker d'identité et effectue la plupart des tâches liées à la fédération pour vous. Pour plus
d'informations, consultez la section Utilisation de Amazon Cognito pour applications mobiles (p. 150).
Si vous n'utilisez pas Amazon Cognito, vous devez écrire le code qui interagit avec un IdP web
(Login with Amazon, Facebook, Google ou tout autre IdP compatible avec OIDC), puis appelle l'API
AssumeRoleWithWebIdentity pour échanger le jeton d'authentification fourni par l'IdP afin d'obtenir
149
des informations d'identification de sécurité temporaires AWS. Si vous avez déjà utilisé cette méthode
pour des applications existantes, vous pouvez continuer à procéder ainsi.
Rubriques
• Utilisation de Amazon Cognito pour applications mobiles (p. 150)
• Utilisation d'API de fédération d'identité web pour les applications mobiles (p. 152)
• Identification des utilisateurs avec la fédération d'identité web (p. 153)
• Ressources supplémentaires sur la fédération d'identité web (p. 155)
Utilisation de Amazon Cognito pour applications mobiles
Le meilleur moyen d'utiliser la fédération d'identité web consiste à utiliser Amazon Cognito. Par
exemple, la développeuse Adèle est en train de créer un jeu pour appareil mobile dans lequel les
données utilisateur, telles que les scores et les profils, sont stockées dans Amazon S3 et Amazon
DynamoDB. Adèle pourrait également stocker ces données en local sur l'appareil et utiliser Amazon
Cognito pour les maintenir synchronisées sur les différents appareils. Elle sait que pour des raisons
de sécurité et de maintenance, des informations d'identification (credentials) de sécurité AWS à long
terme ne doivent pas être distribuées avec le jeu. Elle sait également que le jeu pourrait avoir un grand
nombre d'utilisateurs. Pour toutes ces raisons, elle ne veut pas créer de nouvelles identités dans IAM
pour chaque joueur. Au lieu de cela, elle développe le jeu de sorte que les utilisateurs puissent se
connecter à l'aide d'une identité qu'ils ont déjà établie avec un fournisseur d'identité connu, comme
Login with Amazon, Facebook, Google, ou tout fournisseur d'identité compatible OpenID Connect
(OIDC). Son jeu peut tirer parti du mécanisme d'authentification de l'un de ces fournisseurs afin de
valider l'identité de l'utilisateur.
Pour permettre à l'application mobile d'accéder à ses ressources AWS, Adèle s'enregistre d'abord
pour un ID de développeur auprès du fournisseur d'identités qu'elle a choisi. Elle configure également
l'application avec chacun de ces fournisseurs. Dans son compte AWS qui contient le compartiment
Amazon S3 et la table DynamoDB pour le jeu, Adèle utilise Amazon Cognito pour créer des rôles IAM
qui définissent précisément les autorisations dont le jeu a besoin. Si elle utilise un fournisseur d'identité
OIDC, elle crée une entité de fournisseur d'identité OIDC IAM pour établir la relation d'approbation
entre son compte AWS et le fournisseur d'identité.
Dans le code de l'application, Adèle appelle l'interface de la connexion pour le fournisseur d'identité
l'IdP qu'elle a configuré précédemment. Le fournisseur d'identité traite tous les détails permettant à
l'utilisateur de se connecter, et l'application obtient un jeton d'accès OAuth ou jeton d'ID OIDC du
fournisseur. L'application d'Adèle peut échanger ces informations d'authentification contre un ensemble
d'informations d'identification de sécurité temporaires qui se composent d'un ID de clé d'accès AWS,
d'une clé d'accès secrète et d'un jeton de session. L'application peut ensuite utiliser ces informations
d'identification pour accéder aux services web proposés par AWS. L'application est limitée aux
autorisations qui sont définies dans le rôle qu'elle assume.
La figure suivante illustre un flux simplifié d'un fonctionnement possible, à l'aide de Login with Amazon
comme fournisseur d'identité. Pour l'étape 2, l'application peut également utiliser Facebook, Google ou
tout fournisseur d'identité OIDC compatible, mais ce n'est pas présenté ici.
150
Exemple de flux de travail Amazon Cognito pour fédérer des utilisateurs pour une application
mobile
1. Un client démarre votre application sur un appareil mobile. L'application demande à l'utilisateur de
se connecter.
2. L'application utilise des ressources Login with Amazon pour accepter les informations d'identification
de l'utilisateur.
3. L'application utilise des API Cognito pour échanger le jeton d'ID Login with Amazon contre un jeton
Cognito.
4. L'application demande des informations d'identification de sécurité temporaires à AWS STS en
transmettant le jeton Cognito.
5. Les informations d'identification de sécurité temporaires peuvent être utilisées par l'application
pour accéder aux ressources AWS requises par l'application pour fonctionner. Le rôle associé
aux informations d'identification de sécurité temporaires et les stratégies qui lui sont attribuées
détermine ce qui est accessible.
Utilisez la procédure suivante afin de configurer votre application pour utiliser Amazon Cognito afin
d'authentifier les utilisateurs et de donner à votre application un accès aux ressources AWS. Pour
les étapes spécifiques permettant de réaliser ce scénario, consultez la documentation de Amazon
Cognito.
1. (Facultatif) Connectez-vous en tant que développeur auprès de Login with Amazon, Facebook,
Google ou tout autre fournisseur d'identité compatible OpenID Connect (OIDC) et configurez une
ou plusieurs applications avec le fournisseur. Cette étape est facultative car Amazon Cognito prend
également en charge l'accès non authentifié (invité) pour vos utilisateurs.
2. Accédez à Amazon Cognito sur la AWS Management Console. Utilisez l'assistant Amazon Cognito
pour créer un pool d'identités, qui est un conteneur utilisé par Amazon Cognito pour maintenir
des identités d'utilisateur final organisées pour vos applications. Vous pouvez partager des pools
d'identité entre des applications. Lorsque vous configurez un pool d'identités, Amazon Cognito crée
un ou deux rôles IAM (un pour les identités authentifiées et un pour les identités « invitées » non
authentifiées) qui définissent des autorisations pour les utilisateurs de Amazon Cognito.
3. Téléchargez et intégrez AWS SDK pour iOS ou AWS SDK pour Android à votre application et
importez les fichiers requis pour utiliser Amazon Cognito.
151
4. Créez une instance du fournisseur d'informations d'identification Amazon Cognito en transmettant
l'ID de pool d'identité, votre numéro de compte AWS et l'Amazon Resource Name (ARN) des rôles
que vous avez associés au pool d'identité. L'assistant Amazon Cognito sur la AWS Management
Console fournit des exemples de code pour vous aider à démarrer.
5. Lorsque votre application accède à une ressource AWS, transmettez l'instance de fournisseur
d'informations d'identification à l'objet client, qui transmet les informations d'identification de sécurité
temporaires au client. Les autorisations pour les informations d'identification sont basées sur le ou
les rôles que vous avez définis précédemment.
• Identité Amazon Cognito dans le manuel AWS Mobile SDK pour Android Developer Guide.
• Identité Amazon Cognito dans le manuel AWS Mobile SDK for iOS Developer Guide.
Utilisation d'API de fédération d'identité web pour les applications mobiles
Pour de meilleurs résultats, utilisez Amazon Cognito comme broker d'identité dans la plupart
des scénarios de fédération d'identité web. Amazon Cognito est facile à utiliser et apporte des
capacités supplémentaires, comme l'accès anonyme (sans authentification) et la synchronisation
des données utilisateur entre les périphériques et les fournisseurs. Cependant, si vous avez
déjà créé une application exploitant la fédération d'identité web en appelant manuellement l'API
AssumeRoleWithWebIdentity, vous pouvez continuer à l'utiliser : vos applications fonctionneront
malgré tout.
Note
Pour mieux comprendre le fonctionnement de la fédération d'identité web, vous pouvez
utiliser le site Web Identity Federation Playground. Ce site web interactif vous guide tout au
long du processus d'authentification via Login with Amazon, Facebook ou Google, puis lors
de l'obtention d'informations de sécurité temporaires et de l'utilisation de ces informations
d'identification pour envoyer une demande à AWS.
L'utilisation de la fédération d'identité web sans Amazon Cognito se déroule comme suit :
1. Inscrivez-vous en tant que développeur auprès de l'IdP et configurez votre application avec l'ID
unique qu'il vous donnera. (Dans ce processus, la terminologie est différente selon l'IdP. Cet aperçu
utilise le terme configurer pour le processus d'identification de l'application auprès de l'IdP.) Chaque
IdP vous donne un ID d'application qui est unique à l'IdP. Ainsi, si vous configurez l'application
auprès de plusieurs IdP, elle sera dotée de plusieurs ID d'application. Vous pouvez configurer
plusieurs applications auprès de chaque fournisseur.
Les liens externes suivants fournissent des informations sur quelques uns des fournisseurs
d'identité les plus utilisés :
• Login with Amazon Developer Center
• Add Facebook Login to Your App or Website sur le site des développeurs Facebook.
• Using OAuth 2.0 for Login (OpenID Connect) sur le site des développeurs Google.
Note
Bien qu'Amazon Cognito et Google soient basés sur la technologie OIDC, il n'est pas
nécessaire de créer une entité de fournisseur d'identité dans IAM pour les utiliser. La prise
en charge d'Amazon Cognito et de Google est intégrée dans AWS.
2. Si vous utilisez un IdP web compatible avec OIDC, créez-lui une entité de fournisseur d'identité
dans IAM.
152
3. Dans IAM, créez un ou plusieurs rôles (p. 201). Pour chaque rôle, définissez qui peut assumer
le rôle (stratégie d'approbation) et les autorisations accordées aux utilisateurs de l'application
(stratégie d'autorisation). En général, vous créez un rôle pour chaque IdP pris en charge par
l'application. Par exemple, vous pouvez créer un rôle qui est assumé par une application lorsque
l'utilisateur se connecte via Login with Amazon, un deuxième rôle pour la même application lorsqu'il
se connecte via Facebook, et un troisième rôle lorsqu'il se connecte via Google. Pour la relation
d'approbation, spécifiez l'IdP (par exemple, Amazon.com) en tant que Principal (l'entité de
confiance) et incluez un élément Condition qui correspond à l'ID d'application attribué par l'IdP.
Des exemples de rôles pour différents fournisseurs sont présentés ultérieurement dans cette
rubrique.
4. Dans votre application, authentifiez vos utilisateurs en recourant à l'IdP. La procédure à suivre varie
en fonction de l'IdP utilisé (Login with Amazon, Facebook ou Google) et la plateforme sur laquelle
s'exécute votre application. Par exemple, la méthode d'authentification d'une application Android
peut être différente de celle d'une application iOS ou d'une application web JavaScript.
En règle générale, si l'utilisateur n'est pas déjà connecté, l'IdP affiche une page de connexion.
Une fois qu'il a authentifié l'utilisateur, l'IdP retourne un jeton d'authentification contenant des
informations sur l'utilisateur à l'application. Ces informations dépendent de ce que l'IdP expose et
des informations que l'utilisateur est disposé à partager. Vous pouvez utiliser ces informations dans
votre application.
5. Dans l'application, effectuez un appel non authentifié à l'action AssumeRoleWithWebIdentity
pour solliciter des informations d'identification de sécurité temporaires. Dans la demande, vous
transmettez le jeton d'authentification transmis par l'IdP et spécifiez l'ARN (Amazon Resource
Name) du rôle IAM que vous avez créé pour cet IdP. AWS vérifie que le jeton est approuvé et valide
et, si c'est le cas, le programme retourne des informations d'identification de sécurité temporaires
à votre application, avec notamment des autorisations pour le rôle que vous nommez dans la
demande. La réponse inclut également des métadonnées se rapportant à l'utilisateur provenant de
l'IdP telles que l'ID utilisateur unique que l'IdP associe à l'utilisateur.
6. A l'aide des informations d'identification de sécurité temporaires contenues dans la réponse
AssumeRoleWithWebIdentity, votre application envoie des demandes signées vers les API
AWS. L'ID utilisateur affecté par le fournisseur d'identité peut aider à distinguer les utilisateurs dans
l'application ; ainsi, vous pouvez placer des objets dans des compartiments Amazon S3 dont les
préfixes ou les suffixes incluent l'ID utilisateur. Ceci vous permet de créer des stratégies d'accès
qui verrouillent un dossier, afin que seul l'utilisateur ayant l'ID approprié soit autorisé à y accéder.
Pour plus d'informations, consultez Identification des utilisateurs avec la fédération d'identité
web (p. 153) plus loin dans cette rubrique.
7. Votre application met généralement en cache ces informations d'identification de sécurité
temporaires afin que vous n'ayez pas à en redemander à chaque fois que l'application doit envoyer
une demande à AWS. Par défaut, les informations d'identification restent valides pendant une
heure. Lorsque les informations d'identification expirent (ou avant le délai d'expiration), vous
effectuez un autre appel à AssumeRoleWithWebIdentity pour obtenir un nouvel ensemble
d'informations d'identification de sécurité temporaires. Selon l'IdP utilisé et la façon dont il gère
ses jetons, il sera peut-être nécessaire d'actualiser le jeton de l'IdP avant un nouvel appel à
AssumeRoleWithWebIdentity, car les jetons de l'IdP expirent généralement après un délai
spécifié. Si vous utilisez le kit SDK AWS pour iOS ou le kit SDK AWS pour Android, vous pouvez
avoir recours à l'action AmazonSTSCredentialsProvider qui gère les informations d'identification
temporaires IAM, en les actualisant si nécessaire.
Identification des utilisateurs avec la fédération d'identité web
Lors de la création de stratégies d'accès dans IAM, il est souvent utile de pouvoir spécifier des
autorisations en fonction des applications configurées et de l'ID des utilisateurs qui se sont authentifiés
à l'aide du fournisseur d'identité. Par exemple, votre application mobile qui utilise la fédération
d'identité web peut conserver les informations dans Amazon S3 à l'aide d'une structure similaire à
celle-ci :
153
myBucket/app1/user1
myBucket/app1/user2
myBucket/app1/user3
...
myBucket/app2/user1
myBucket/app2/user2
myBucket/app2/user3
...
Vous souhaitez peut-être également distinguer ces chemins en fonction du fournisseur. Le cas
échéant, la structure peut se présenter comme suit (deux fournisseurs uniquement sont répertoriés par
souci d'espace) :
myBucket/Amazon/app1/user1
...
myBucket/Facebook/app1/user1
...
...
Pour ces structures, app1 et app2 représentent différentes applications, comme différents jeux, et
chaque utilisateur de l'application a un dossier distinct. Les valeurs de app1 et app2 peuvent être des
noms conviviaux que vous affectez (par exemple, mynumbersgame) ou des ID d'application affectés
par les fournisseurs lorsque vous configurez votre application. Si vous décidez d'inclure des noms de
fournisseurs dans le chemin, il peut s'agir de noms conviviaux comme Cognito, Amazon, Facebook
et Google.
Vous pouvez généralement créer les dossiers pour app1 et app2 à l'aide de l'AWS Management
Console, car les noms d'applications sont des valeurs statiques. C'est vrai également si vous
incluez le nom du fournisseur dans le chemin, puisque le nom du fournisseur est aussi une valeur
statique. En revanche, les dossiers spécifiques aux utilisateurs (utilisateur1, utilisateur2,
utilisateur3, etc.) doivent être créés lors de l'exécution dans l'application à l'aide de l'ID
utilisateur disponible dans la valeur SubjectFromWebIdentityToken renvoyée par la demande de
AssumeRoleWithWebIdentity.
Pour écrire des stratégies qui autorisent l'accès exclusif aux ressources à des utilisateurs individuels,
vous pouvez faire correspondre le nom du dossier complet, notamment le nom de l'application et du
fournisseur, si vous utilisez cela. Vous pouvez ensuite inclure les clés de contexte spécifiques au
fournisseur qui font référence à l'ID utilisateur renvoyé par le fournisseur :
• cognito-identity.amazonaws.com:sub
• www.amazon.com:user_id
• graph.facebook.com:id
• accounts.google.com:sub
154
Pour les fournisseurs OIDC, utilisez l'URL complète du fournisseur OIDC avec la clé de sous-contexte,
comme dans exemple suivant :
• server.example.com:sub
L'exemple suivant illustre une stratégie d'accès qui accorde l'accès à un compartiment dans Amazon
S3 uniquement si le préfixe du compartiment correspond à la chaîne :
myBucket/Amazon/mynumbersgame/user1
L'exemple suppose que l'utilisateur s'est connecté à l'aide de Login with Amazon et qu'il utilise une
application appelée mynumbersgame. L'ID unique de l'utilisateur est présenté comme un attribut
appelé user_id.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::myBucket"],
"Condition": {"StringLike": {"s3:prefix": ["Amazon/mynumbersgame/
${www.amazon.com:user_id}/*"]}}
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::myBucket/amazon/mynumbersgame/
${www.amazon.com:user_id}",
"arn:aws:s3:::myBucket/amazon/mynumbersgame/
${www.amazon.com:user_id}/*"
]
}
]
}
Vous devez créer des stratégies similaires pour les utilisateurs qui se connectent à l'aide de Amazon
Cognito, Facebook, Google ou un autre IdP compatible avec OpenID Connect. Ces stratégies utilisent
un nom de fournisseur différent comme partie du chemin, ainsi que des ID d'applications différents.
Pour plus d'informations sur les clés de fédération d'identité web disponibles pour les contrôles de
condition dans les stratégies, consultez Clés disponibles pour la fédération d'identité web (p. 419).
Ressources supplémentaires sur la fédération d'identité web
Les ressources suivantes peuvent vous aider à en savoir plus sur la fédération d'identité web :
• Amazon Cognito Identity dans le manuel AWS Mobile SDK pour Android Developer Guide et
Amazon Cognito Identity dans le manuel AWS Mobile SDK for iOS Developer Guide.
• Le site Web Identity Federation Playground est un site web interactif qui vous guide tout au long des
processus d'authentification via Login with Amazon, Facebook ou Google, , puis lors de l'obtention
d'informations de sécurité temporaires et de l'utilisation de ces informations d'identification pour
envoyer une demande à AWS.
155
• Le billet Web Identity Federation using the AWS SDK for .NET du blog sur le développement .NET
AWS explique comment utiliser la fédération d'identité web avec Facebook et inclut des extraits de
code C# qui montrent comment appeler AssumeRoleWithWebIdentity et utiliser les informations
d'identification de sécurité temporaires de cet appel d'API pour accéder à un compartiment S3.
• Le kit SDK AWS pour iOS et le kit SDK AWS pour Android contiennent des exemples d'applications.
Ces applications contiennent du code qui montre comment appeler les fournisseurs d'identité
et comment utiliser les informations qu'ils fournissent pour obtenir et utiliser des informations
d'identification de sécurité temporaires.
• L'article Fédération d'identité web avec des applications mobiles contient des informations sur la
fédération d'identité web ainsi qu'un exemple d'utilisation pour l'accès au contenu d'un compartiment
Amazon S3.
A propos de la fédération SAML 2.0
AWS prend en charge la fédération d'identité avec SAML 2.0 (Security Assertion Markup
Language 2.0), une norme ouverte utilisée par de nombreux fournisseurs d'identité (IdP). Cette
fonction active l'authentification unique fédérée (SSO), permettant aux utilisateurs de se connecter à
AWS Management Console ou d'appeler les API AWS sans qu'il soit nécessaire de créer un utilisateur
IAM pour chaque membre de l'organisation. L'utilisation de SAML permet de simplifier la configuration
de la fédération avec AWS, car vous utilisez le service de l'IdP au lieu d'écrire du code proxy d'identité
personnalisé.
La fédération IAM prend en charge les cas d'utilisation suivants :
• Accès fédéré permettant à un utilisateur ou une application de l'organisation d'appeler des API
AWS (p. 156). Vous utilisez une assertion SAML (dans le cadre de la réponse d'authentification)
qui est générée dans votre organisation pour l'obtention d'informations d'identification temporaires.
Ce scénario est similaire à d'autres scénarios de fédération pris en charge par IAM, tels que ceux
décrits dans Obtention d'informations d'identification temporaires de sécurité (p. 246) et A propos
de la fédération d'identité web (p. 149). Toutefois, les fournisseurs d'identité SAML 2.0 de votre
organisation gèrent une grande partie des informations lors de l'exécution, pour l'authentification et la
vérification des autorisations. C'est le scénario décrit dans cette rubrique.
• Authentification unique Web (SSO) dans AWS Management Console dans votre
organisation (p. 176). Les utilisateurs peuvent se connecter à un portail de l'organisation, hébergé
par un IdP compatible avec SAML 2.0, – sélectionner une option pour accéder à AWS, puis être
redirigés vers la console sans avoir à fournir d'autres informations de connexion. En plus de pouvoir
utiliser un IdP SAML tiers pour établir un accès SSO à la console, vous pouvez également créer
un IdP personnalisé pour autoriser l'accès de vos utilisateurs externes à la console. Pour plus
d'informations sur la création d'un IdP personnalisé, consultez la page Création d'une URL qui
permet aux utilisateurs fédérés d'accéder à AWS Management Console (Broker de fédération
Utilisation de la fédération SAML pour l'accès à l'API AWS
Supposons que vous voulez permettre aux utilisateurs de votre organisation de copier les données
de leurs ordinateurs dans un dossier de sauvegarde. Vous créez une application que les utilisateurs
peuvent exécuter sur leurs ordinateurs. Sur l'instance principale, l'application lit et écrit les objets
dans un compartiment S3. Les utilisateurs ne disposent pas d'un accès direct à AWS. À la place, le
processus suivant est utilisé :
156
1. A l'aide d'une application cliente, un utilisateur de l'organisation demande son authentification par
l'IdP de l'organisation.
2. L'IdP authentifie l'utilisateur en le comparant à la base d'identités de l'organisation.
3. L'IdP crée une assertion SAML à l'aide des informations concernant l'utilisateur et l'envoie à
l'application client.
4. L'application cliente appelle l'API AssumeRoleWithSAML AWS STS, en transmettant l'ARN du
fournisseur SAML, l'ARN du rôle à assumer et l'assertion SAML fournie par l'IdP.
5. La réponse de l'API à l'application cliente inclut des informations d'identification de sécurité
temporaires.
6. L'application cliente utilise ces informations d'identification de sécurité temporaires pour appeler les
API Amazon S3.
Présentation de la configuration de la fédération SAML 2.0
Avant de pouvoir utiliser la fédération SAML 2.0 comme décrit dans le scénario et le diagramme
précédents, vous devez configurer l'IdP de votre organisation ainsi que votre compte AWS afin d'établir
une relation d'approbation entre eux. La procédure suivante décrit le processus général permettant
de configurer cette relation d'approbation. Votre organisation doit utiliser un IdP prenant en charge
SAML 2.0 (p. 169), comme Microsoft Active Directory Federation Service (services ADFS qui font
partie de Windows Server), Shibboleth, ou tout autre fournisseur compatible avec SAML 2.0.
1. Vous commencez par inscrire AWS auprès de votre IdP. L'inscription d'AWS en tant que fournisseur
de services auprès de l'IdP de votre organisation se fait à l'aide d'un document de métadonnées
SAML que vous obtenez à partir de l'URL suivante :
https://signin.aws.amazon.com/static/saml-metadata.xml
2. A l'aide de l'IdP de l'organisation, vous générez un fichier XML de métadonnées équivalent, capable
de décrire cet IdP en tant que fournisseur d'identité à AWS. Il doit inclure le nom de l'auteur,
une date de création et d'expiration et les clés qu'AWS peut utiliser pour valider les réponses
d'authentification (assertions) de votre organisation.
3. Dans la console IAM, vous créez une entité de fournisseur d'identité SAML. Au cours du processus,
vous téléchargez le document de métadonnées SAML généré par l'IdP de votre organisation à
l'étape 2 (p. 157). Pour de plus amples informations, veuillez consulter Création de fournisseurs
d'identité SAML (p. 166).
157
4. Dans IAM, vous créez un ou plusieurs rôles IAM. Dans la stratégie d'approbation du rôle, vous
définissez le fournisseur SAML en tant que mandataire. Ceci établit une relation d'approbation
entre votre organisation et AWS. La stratégie d'autorisation du rôle détermine les actions
que les utilisateurs de l'organisation sont autorisés à effectuer dans AWS. Pour de plus
amples informations, veuillez consulter Création d'un rôle pour un fournisseur d'identité tiers
(Fédération) (p. 201).
5. Dans l'IdP de l'organisation, vous définissez les assertions qui associent les utilisateurs et
les groupes de l'organisation aux rôles IAM. Notez que différents utilisateurs et groupes de
l'organisation peuvent être associés à différents rôles IAM. La procédure exacte pour leur mappage
dépend de l'IdP utilisé. Dans le scénario précédent (p. 156) impliquant un compartiment
Amazon S3 pour les utilisateurs, tous les utilisateurs peuvent être associés au rôle qui fournit les
autorisations Amazon S3. Pour plus d'informations, consultez Configuration des assertions SAML
pour la réponse d'authentification (p. 171).
Si votre IdP active la connexion avec authentification unique (SSO) à la console AWS, vous pouvez
configurer la durée maximale des sessions de la console. Pour plus d'informations, consultez
Activation de l'accès des utilisateurs fédérés SAML 2.0 à l'AWS Management Console (p. 176).
Note
L'implémentation AWS de la fédération SAML 2.0 ne prend pas en charge les assertions
SAML chiffrées entre le fournisseur d'identité et AWS. Toutefois, le trafic entre le
fournisseur d'identité et AWS emprunte un canal chiffré (TLS).
6. Dans l'application que vous créez, vous appelez l'API AssumeRoleWithSAML AWS Security Token
Service, en lui transmettant l'ARN du fournisseur SAML créé à l'étape 3 (p. 157), l'ARN du rôle à
assumer, créé à l'étape 4 (p. 158), et l'assertion SAML se rapportant à l'utilisateur actuel obtenue
de votre IdP. AWS vérifie que la demande concernant le rôle à assumer provient de l'IdP référencé
dans le fournisseur SAML.
Pour plus d'informations, consultez AssumeRoleWithSAML dans le guide de référence de l'API
AWS Security Token Service.
7. Si la demande aboutit, l'API retourne des informations d'identification de sécurité temporaires
que votre application peut utiliser pour adresser des demandes signées à AWS. Votre application
dispose d'informations sur l'utilisateur actuel et peut accéder aux compartiments Amazon S3
spécifiques à celui-ci, comme décrit dans le scénario précédent.
Présentation du rôle qui autorise l'accès fédéré SAML à vos ressources AWS
Les rôles que vous créez dans IAM définissent les actions que les utilisateurs fédérés de votre
organisation sont en mesure d'effectuer dans AWS. Lorsque vous créez la stratégie d'approbation pour
le rôle, vous spécifiez le fournisseur d'identité SAML créé précédemment en tant que Principal.
Vous pouvez également ajouter une Condition à la stratégie d'approbation, afin d'autoriser
uniquement les utilisateurs correspondant à certains attributs SAML à accéder au rôle. Par exemple, il
est possible de spécifier que seuls les utilisateurs dont l'affiliation SAML est staff (comme stipulé sur
https://openidp.feide.no) sont autorisés à accéder au rôle, comme illustré dans l'exemple de stratégie
suivant :
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:sts::ACCOUNT-ID-WITHOUT-HYPHENS:samlprovider/ExampleOrgSSOProvider"},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"saml:aud": "https://signin.aws.amazon.com/saml",
158
"saml:iss": "https://openidp.feide.no"
},
"ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]}
}
}]
}
Pour plus d'informations sur les clés SAML pouvant être vérifiées dans une stratégie, consultez Clés
disponibles pour la fédération SAML.
Vous spécifiez les autorisations de la stratégie d'accès du rôle comme pour tout autre rôle. Par
exemple, si les utilisateurs de votre organisation sont autorisés à administrer les instances Amazon
Elastic Compute Cloud, vous devez autoriser explicitement les actions Amazon EC2 dans la stratégie
d'autorisation, par exemple comme celles de la stratégie gérée AmazonEC2FullAccess.
Identification unique des utilisateurs dans la fédération SAML
Lors de la création de stratégies d'accès dans IAM, il est souvent utile de pouvoir spécifier des
autorisations en fonction de l'identité des utilisateurs. Par exemple, dans le cas d'utilisateurs fédérés
à l'aide de SAML, une application peut conserver les informations dans Amazon S3 à l'aide d'une
structure similaire à celle-ci :
myBucket/app1/user1
myBucket/app1/user2
myBucket/app1/user3
Vous pouvez créer le compartiment (myBucket) et le dossier (app1) à l'aide de la console Amazon S3
ou de l'AWS CLI, car il s'agit de valeurs statiques. Toutefois, les dossiers spécifiques aux utilisateurs
(utilisateur1, utilisateur2, utilisateur3, etc.) doivent être créés à l'aide de code lors de
l'exécution, car la valeur qui identifie l'utilisateur n'est pas connue jusqu'à la première authentification
de l'utilisateur via le processus de fédération.
Pour créer des stratégies qui référencent des détails spécifiques à l'utilisateur dans le nom d'une
ressource, l'identité de l'utilisateur doit figurer dans des clés SAML pouvant être utilisées dans les
conditions des stratégies. Les clés suivantes sont disponibles pour la fédération SAML 2.0 et peuvent
être utilisées dans des stratégies IAM. Vous pouvez utiliser les valeurs retournées par les clés
suivantes pour créer des identifiants utilisateur uniques pour des ressources comme des dossiers
Amazon S3.
• saml:namequalifier. Valeur de hachage basée sur la concaténation de la valeur de réponse
Issuer (saml:iss) et d'une chaîne avec l'ID de compte AWS et le nom convivial (dernière partie de
l'ARN) du fournisseur SAML dans IAM. La concaténation de l'ID de compte et du nom convivial du
fournisseur SAML est disponible dans les stratégies IAM en tant que clé saml:doc. L'ID de compte
et le nom du fournisseur doivent être séparés par un caractère « / », comme dans « 123456789012/
provider_name ». Pour plus d'informations, reportez-vous à la clé saml:doc dans Clés disponibles
pour la fédération SAML (p. 420).
La combinaison de NameQualifier et Subject permet d'identifier de manière unique un utilisateur
fédéré. L'exemple de pseudo-code suivant montre comment cette valeur est calculée. Dans ce
pseudo-code, + indique une concaténation, SHA1 représente une fonction qui génère un résumé de
message à l'aide de SHA-1 et Base64 représente une fonction qui génère une version encodée en
Base64 de la sortie de hachage.
Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/
MySAMLIdP" ) )
Pour plus d'informations sur les clés de stratégie disponibles pour la fédération SAML, consultez
Clés disponibles pour la fédération SAML (p. 420).
159
• saml:sub (chaîne). Objet de la demande, qui inclut une valeur qui identifie de
manière unique un utilisateur individuel au sein d'une organisation (par exemple,
_cbb88bf52c2510eabe00c1642d4643f41430fe25e3).
• saml:sub_type (chaîne). Cette clé peut être persistent, transient ou l'URI Format complet
des éléments Subject et NameID utilisés dans votre assertion SAML. Une va leur persistent
indique que la valeur de saml:sub reste la même pour l'utilisateur pour toutes les sessions. Si la
valeur est transient, l'utilisateur a une valeur saml:sub différente pour chaque session. Pour plus
d'informations sur l'attribut Format de l'élément NameID, consultez Configuration des assertions
SAML pour la réponse d'authentification (p. 171).
L'exemple suivant illustre une stratégie d'accès qui utilise les clés précédentes pour accorder des
autorisations à un dossier spécifique à un utilisateur dans Amazon S3. La stratégie suppose que
les objets Amazon S3 sont identifiés à l'aide d'un préfixe qui inclut à la fois saml:namequalifier
et saml:sub. Notez que l'élément Condition inclut un test pour vérifier que la valeur de
saml:sub_type est définie sur persistent. Si la valeur est transient, l'élément saml:sub de
l'utilisateur peut être différent pour chaque session et vous ne devez pas combiner les valeurs pour
identifier des dossiers spécifiques aux utilisateurs.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::exampleorgBucket/backup/${saml:namequalifier}/
${saml:sub}",
"arn:aws:s3:::exampleorgBucket/backup/${saml:namequalifier}/
${saml:sub}/*"
],
"Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
}
}
Pour plus d'informations sur le mappage d'assertions de l'IdP et les clés de stratégie, consultez
Configuration des assertions SAML pour la réponse d'authentification (p. 171).
Création de fournisseurs d'identité IAM
Lorsque vous souhaitez configurer une fédération avec un service de fournisseur d'identité externe
(IdP), vous créez un fournisseur d'identité dans la console IAM pour informer AWS de l'IdP et sa
configuration. Cela établit une relation de confiance entre votre compte AWS et l'IdP. Les rubriques
suivantes inclut des détails sur la création d'un fournisseur d'identité dans IAM pour chaque type d'IdP.
Rubriques
• Création de fournisseurs d'identité OpenID Connect (OIDC) (p. 160)
• Création de fournisseurs d'identité SAML (p. 166)
Création de fournisseurs d'identité OpenID Connect (OIDC)
Les fournisseurs d'identité OIDC sont des entités qui, dans IAM, décrivent un service de fournisseur
d'identité (IdP) prenant en charge la norme OpenID Connect (OIDC). Vous utilisez un fournisseur
160
d'identité OIDC lorsque vous voulez établir une relation d'approbation entre un fournisseur d'identité
compatible avec OIDC, tel que Google, Salesforce et de nombreux autres fournisseurs, et votre
compte AWS. Cela est utile si vous créez une application mobile ou une application web qui doit
accéder aux ressources AWS, mais que vous ne voulez pas créer de code de connexion personnalisé
ni gérer vos propres identités utilisateur. Pour plus d'informations sur ce scénario, consultez the section
called “A propos de la fédération d'identité web” (p. 149).
Vous pouvez créer et gérer un fournisseur d'identité OIDC à l'aide de AWS Management Console, de
l'AWS Command Line Interface, de Outils pour Windows PowerShell ou de l'API IAM.
Rubriques
• Création et gestion d'un fournisseur OIDC (AWS Management Console) (p. 161)
• Création et gestion d'un fournisseur d'identité OIDC (AWS CLI, Outils pour Windows PowerShell et
API IAM) (p. 162)
• Obtention de l'empreinte d'un fournisseur d'identité OpenID Connect (p. 163)
Création et gestion d'un fournisseur OIDC (AWS Management Console)
Observez les instructions suivantes pour créer et gérer un fournisseur OIDC dans AWS Management
Console.
Pour créer un fournisseur d'identité OIDC
1.
Avant de créer un fournisseur d'identité OIDC dans IAM, vous devez enregistrer votre application
auprès du fournisseur d'identité afin de recevoir un ID client. L'ID client (également appelé public)
est un identifiant unique pour votre application. Il est émis lorsque vous enregistrez l'application
auprès du fournisseur d'identité. Pour plus d'informations sur l'obtention d'un ID client, consultez la
documentation de votre fournisseur d'identité.
2.
Ouvrez la console Identity and Access Management (IAM) à l'adresse https://
3.
Dans le volet de navigation, cliquez sur Identity Providers, puis sur Create Provider.
4.
Sous Provider Type, cliquez sur Choose a provider type, puis sélectionnez OpenID Connect.
5.
Sous Provider URL, tapez l'URL du fournisseur d'identité. L'URL doit respecter les restrictions
suivantes :
• L'URL est sensible à la casse.
• L'URL doit commencer par https://.
• L'URL ne peut pas contenir de caractère deux-points (:), ce qui signifie qu'il est impossible de
spécifier un numéro de port. Cela implique également que le serveur doit écouter sur le port 443
par défaut.
• Dans votre compte AWS chaque fournisseur d'identité OIDC doit utiliser une URL unique.
6.
Sous Audience, tapez l'ID client de l'application enregistrée auprès du fournisseur d'identité,
reçu dans Step 1 (p. 161), qui exécutera les requêtes vers AWS. Si vous disposez d'ID client
supplémentaires (également appelés publics) pour ce fournisseur d'identité, vous pouvez les
ajouter ultérieurement sur la page de détails du fournisseur. Cliquez sur Next Step.
7.
Utilisez l'empreinte numérique pour vérifier le certificat de serveur de votre fournisseur d'identité.
Pour savoir comment procéder, consultez Obtention de l'empreinte d'un fournisseur d'identité
OpenID Connect (p. 163). Cliquez sur Create.
8.
Dans le message de confirmation qui s'affiche en haut de l’écran, cliquez sur Do this now
pour accéder à l'onglet Roles afin de créer un rôle pour ce fournisseur d'identité. Pour plus
d'informations sur la création d'un rôle pour un fournisseur d'identité OIDC, consultez Création
d'un rôle pour un fournisseur d'identité tiers (Fédération) (p. 201). Les fournisseurs d'identité
OIDC doivent disposer d'un rôle pour accéder à votre compte AWS. Pour ignorer cette étape et
créer le rôle plus tard, cliquez sur Close.
161
Pour ajouter ou supprimer une empreinte numérique ou un ID client (également appelé
audience) pour un fournisseur d'identité OIDC
1.
2.
Dans le volet de navigation, cliquez sur Identity Providers, puis sur le nom du fournisseur d'identité
que vous voulez mettre à jour.
3.
Pour ajouter une empreinte numérique ou une audience, cliquez sur Add a Thumbprint ou Add
an Audience. Pour supprimer une empreinte numérique ou une audience, cliquez sur Remove en
regard de l’élément que vous souhaitez supprimer.
Note
Un fournisseur d'identité OIDC peut avoir entre 1 (minimum) et 5 empreintes numériques.
Un fournisseur d'identité OIDC peut avoir entre 1 (minimum) et 100 audiences.
Lorsque vous avez terminé, cliquez sur Save Changes.
Pour supprimer un fournisseur d'identité OIDC
1.
2.
Dans le volet de navigation, cliquez sur Identity Providers.
3.
Sélectionnez la case à cocher en regard du fournisseur d'identité que vous souhaitez supprimer.
4.
Cliquez sur Delete Providers.
Création et gestion d'un fournisseur d'identité OIDC (AWS CLI, Outils pour Windows
PowerShell et API IAM)
Utilisez les commandes suivantes pour créer et gérer un fournisseur OIDC.
Pour créer un nouveau fournisseur OIDC
• AWS CLI : aws iam create-open-id-connect-provider
• Outils pour Windows PowerShell : New-IAMOpenIDConnectProvider
• API IAM : CreateOpenIDConnectProvider
Pour ajouter un nouvel ID client à un fournisseur OIDC existant
• AWS CLI : aws iam add-client-id-to-open-id-connect-provider
• Outils pour Windows PowerShell : Add-IAMClientIDToOpenIDConnectProvider
• API IAM : AddClientIDToOpenIDConnectProvider
Pour supprimer un ID client d'un fournisseur OIDC existant
• AWS CLI : aws iam remove-client-id-from-open-id-connect-provider
• Outils pour Windows PowerShell : Remove-IAMClientIDToOpenIDConnectProvider
• API IAM : RemoveClientIDFromOpenIDConnectProvider
Pour mettre à jour la liste des empreintes numériques de certificat de serveur pour un fournisseur
OIDC existant
162
• AWS CLI : aws iam update-open-id-connect-provider-thumbprint
• Outils pour Windows PowerShell : Update-IAMOpenIDConnectProviderThumbprint
• API IAM : UpdateOpenIDConnectProviderThumbprint
Pour obtenir la liste de tous les fournisseurs OIDC de votre compte AWS
• AWS CLI : aws iam list-open-id-connect-providers
• Outils pour Windows PowerShell : Get-IAMOpenIDConnectProviders
• API IAM : ListOpenIDConnectProviders
Pour obtenir des informations détaillées sur un fournisseur OIDC
• AWS CLI : aws iam get-open-id-connect-provider
• Outils pour Windows PowerShell :Get-IAMOpenIDConnectProvider:
• API IAM : GetOpenIDConnectProvider
Pour supprimer un fournisseur OIDC
• AWS CLI : aws iam delete-open-id-connect-provider
• Outils pour Windows PowerShell : Remove-IAMOpenIDConnectProvider
• API IAM : DeleteOpenIDConnectProvider
Obtention de l'empreinte d'un fournisseur d'identité OpenID Connect
Lorsque vous créez un fournisseur d'identité OpenID Connect (OIDC) (p. 160) dans IAM, vous devez
fournir une empreinte au fournisseur d'identité (IdP). L'empreinte est une signature pour le certificat
de serveur unique utilisé par l'IdP compatible avec OIDC. Lorsque vous créez un fournisseur d'identité
OIDC dans IAM, vous accordez l'accès à votre compte AWS aux identités authentifiées par cet IdP. En
fournissant l'empreinte de l'IdP OIDC, vous affirmez à AWS que vous souhaitez accorder cet accès à
un IdP OIDC spécifique.
Lorsque vous créez un fournisseur d'identité OIDC à l'aide de l'AWS Command Line Interface, l'Outils
pour Windows PowerShell ou l'API IAM (p. 162), vous devez obtenir manuellement empreinte et la
fournir à AWS. Lorsque vous créez un fournisseur d'identité OIDC à l'aide de la console IAM (p. 160),
la console tente de récupérer l'empreinte pour vous. Nous vous recommandons d'obtenir également
l'empreinte de votre IdP OIDC manuellement et de vérifier que l'empreinte obtenue par la console IAM
correspond à celle que vous attendez de votre fournisseur OIDC.
Vous utilisez un navigateur web et l'outil de ligne de commande OpenSSL pour obtenir l'empreinte
pour un fournisseur OIDC. Pour plus d'informations, consultez les sections suivantes.
Pour obtenir l'empreinte d'un IdP OIDC
1.
Avant d'obtenir l'empreinte pour un IdP OIDC, vous devez obtenir l'outil de ligne de commande
OpenSSL. Cet outil vous permet de télécharger la chaîne de certificats de l'IdP OIDC et de fournir
une empreinte du certificat final dans la chaîne de certificats. Si vous avez besoin d'installer et
de configurer OpenSSL, suivez les instructions des sections Installer OpenSSL (p. 165) et
Configurer OpenSSL (p. 165).
2.
Commencez par l'URL de l'IdP OIDC (par exemple, https://server.example.com),
puis ajoutez /.well-known/openid-configuration pour former l'URL du document de
configuration de l'IdP, comme suit :
https://serveur.exemple.com/.well-known/openid-configuration
163
Ouvrez cette URL dans un navigateur web en remplaçant serveur.exemple.com par le nom du
serveur du votre IdP.
3.
Dans le document affiché dans votre navigateur web, recherchez "jwks_uri". (Utilisez
la fonction Rechercher de votre navigateur web pour rechercher ce texte sur la page.)
Immédiatement après le texte "jwks_uri" vous verrez apparaître deux points (:) suivis d'une
URL. Copiez le nom de domaine complet de l'URL. N'incluez pas le https:// ou le chemin
d'accès qui suit le domaine de niveau supérieur.
4.
Utilisez l'outil de ligne de commande OpenSSL pour exécuter la commande suivante. Remplacez
clés.exemple.com par le nom de domaine que vous avez obtenu dans Step 3 (p. 164).
openssl s_client -showcerts -connect keys.example.com:443
5.
Dans votre fenêtre de commande, faites défiler jusqu'à afficher un certificat similaire à l'exemple
suivant. Si plusieurs certificats sont affichés, recherchez le dernier certificat affiché (au bas de la
sortie de commande).
-----BEGIN CERTIFICATE----MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE=
Copiez le certificat (notamment les lignes -----BEGIN CERTIFICATE----- et -----END
CERTIFICATE-----) et collez-les dans un fichier texte. Puis enregistrez le fichier avec le nom
certificate.crt.
6.
Utilisez l'outil de ligne de commande OpenSSL pour exécuter la commande suivante.
openssl x509 -in certificate.crt -fingerprint -noout
Votre fenêtre de commande affiche l'empreinte du certificat qui semble similaire à l'exemple
suivant :
SHA1
Fingerprint=99:0F:41:93:97:2F:2B:EC:F1:2D:DE:DA:52:37:F9:C9:52:F2:0D:9E
Supprimez les deux points (:) de cette chaîne pour générer l'empreinte finale, comme ceci :
990F4193972F2BECF12DDEDA5237F9C952F20D9E
7.
Si vous créez le fournisseur d'identité IAM avec l'AWS CLI, l'Outils pour Windows PowerShell ou
l'API IAM, fournissez cette empreinte lors de la création du fournisseur.
164
Si vous créez le fournisseur OIDC dans la console IAM, comparez cette empreinte à celle
qui s'affiche dans la console sur la page Verify Provider Information lors de la création d'un
fournisseur OIDC.
Important
Si l'empreinte que vous avez obtenue ne correspond pas à celle qui s'affiche dans la
console, vous ne devez pas créer le fournisseur OIDC dans IAM. À la place, patientez un
instant et réessayez de créer le fournisseur OIDC, en vous assurant que les empreintes
correspondent avant de créer le fournisseur. Si les empreintes ne correspondent toujours
pas après une seconde tentative, visitez le Forum IAM pour contacter AWS.
Installer OpenSSL
Si vous n'avez pas déjà installé OpenSSL, suivez les instructions dans cette section.
Pour installer OpenSSL sous Linux ou Unix
1.
Accédez à OpenSSL : source, tarballs (https://openssl.org/source/).
2.
Téléchargez la dernière version de la source et créez le package.
Pour installer OpenSSL sous Windows
1.
2.
3.
Accédez à OpenSSL : distributions binaires (https://wiki.openssl.org/index.php/Binaries) pour
obtenir la liste des sites à partir desquels vous pouvez installer la version de Windows.
Suivez les instructions sur le site sélectionné pour démarrer l'installation.
Si vous êtes invité à installer Microsoft Visual C++ 2008 Redistributables et qu'il n'est
pas déjà installé sur votre système, cliquez sur le lien de téléchargement approprié pour
votre environnement. Suivez les instructions fournies par l'assistant de configuration de
Microsoft Visual C++ 2008 Redistributables.
Note
4.
5.
Si vous n’êtes pas sûr que Microsoft Visual C++ 2008 Redistributables est déjà installé
sur votre système, vous pouvez essayer d'installer d'abord OpenSSL. Le programme
d'installation d'OpenSSL affiche une alerte si Microsoft Visual C++ 2008 Redistributables
n'est pas encore installé. Assurez-vous que vous installez l'architecture (32 bits ou 64 bits)
qui correspond à la version d'OpenSSL que vous installez.
Une fois que vous avez installé Microsoft Visual C++ 2008 Redistributables, sélectionnez la
version appropriée des fichiers binaires OpenSSL pour votre environnement et enregistrez le
fichier localement. Démarrez l'assistant de configuration d'OpenSSL.
Suivez les instructions fournies dans l'assistant de configuration d'OpenSSL.
Configurer OpenSSL
Avant d'utiliser les commandes OpenSSL, vous devez configurer le système d'exploitation afin qu’il
comporte des informations sur l'emplacement où OpenSSL est installé.
Pour configurer OpenSSL sous Linux ou Unix
1.
Dans la ligne de commande, définissez la variable OpenSSL_HOME sur l'emplacement de
l'installation d'OpenSSL :
export OpenSSL_HOME=path_to_your_OpenSSL_installation
165
2.
Définissez le chemin d'accès pour inclure l'installation d'OpenSSL :
export PATH=$PATH:$OpenSSL_HOME/bin
Note
Toutes les modifications apportées aux variables d'environnement avec la commande
export sont valides uniquement pour la session en cours. Vous pouvez apporter des
modifications persistantes aux variables d'environnement en les définissant dans votre
fichier de configuration de shell. Pour plus d'informations, consultez la documentation de
votre système d'exploitation.
Pour configurer OpenSSL sous Windows
1.
Ouvrez une fenêtre d'invite de commande.
2.
Définissez la variable OpenSSL_HOME sur l'emplacement de l'installation d'OpenSSL :
set OpenSSL_HOME=path_to_your_OpenSSL_installation
3.
Définissez la variable OpenSSL_CONF sur l'emplacement du fichier de configuration de votre
installation d'OpenSSL :
set OpenSSL_CONF=path_to_your_OpenSSL_installation\bin\openssl.cfg
4.
Définissez le chemin d'accès pour inclure l'installation d'OpenSSL :
set Path=%Path%;%OpenSSL_HOME%\bin
Note
Les modifications apportées aux variables d'environnement Windows dans une fenêtre
d'invite de commande sont valides uniquement pour la session actuelle de la ligne
de commande. Vous pouvez apporter des modifications définitives aux variables
d'environnement en les définissant comme propriétés système. La procédure exacte
dépend de la version de Windows que vous utilisez. (Par exemple, dans Windows 7,
ouvrez Panneau de configuration, Système et sécurité, Système. Choisissez ensuite
l'onglet Paramètres système avancés, Avancé, Variables d'environnement.) Pour plus
d'informations, consultez la documentation Windows.
Création de fournisseurs d'identité SAML
Un fournisseur d'identité SAML 2.0 est une entité dans IAM qui décrit un service de fournisseur
d'identité (IdP) prenant en charge le langage SAML 2.0 (Security Assertion Markup Language 2.0)
standard. Vous utilisez un fournisseur d'identité SAML lorsque vous voulez établir une relation
d'approbation entre un IdP compatible avec SAML, tel que Shibboleth ou les services ADFS (Active
Directory Federation Services), afin les utilisateurs de votre organisation puissent accéder aux
ressources AWS. Les fournisseurs d'identité SAML dans IAM sont utilisés en tant que mandataires
dans une stratégie d'approbation IAM.
Pour plus d'informations sur ce scénario, consultez A propos de la fédération SAML 2.0 (p. 156).
Vous pouvez créer et gérer un fournisseur d'identité SAML l'AWS Management Console ou en utilisant
l'AWS CLI, l'Outils pour Windows PowerShell ou des appels d'API AWS.
166
Après avoir créé un fournisseur SAML, vous devez créer un ou plusieurs rôles IAM. Un rôle est une
identité dans AWS qui ne dispose pas de ses propres informations d'identification (comme c'est le
cas pour un utilisateur) mais est, dans ce contexte, affectée dynamiquement à un utilisateur fédéré
qui est authentifié par le fournisseur d'identité (IdP) de votre organisation. Le rôle permet à l'IdP de
votre organisation de demander des informations d'identification de sécurité temporaires pour accéder
à AWS. Les stratégies affectées au rôle déterminent les actions que les utilisateurs fédérés sont
autorisés à exécuter dans AWS. Pour créer un rôle pour la fédération SAML, consultez Création d'un
rôle pour un fournisseur d'identité tiers (Fédération) (p. 201).
Enfin, après avoir créé le rôle, vous devez finaliser la relation d'approbation SAML en configurant votre
IdP à l'aide d'informations sur AWS et sur les rôles que vous voulez affecter à vos utilisateurs fédérés.
Il s'agit de la configuration de la relation d'approbation des parties utilisatrices entre votre IdP et AWS.
Pour configurer la relation d'approbation des parties utilisatrices, consultez Configuration de votre IdP
SAML 2.0 à l'aide d'une relation d'approbation des parties utilisatrices et ajout de requêtes (p. 168).
Rubriques
• Création et gestion d'un fournisseur d'identité SAML (AWS Management Console) (p. 167)
• Gestion d'un fournisseur SAML (AWS CLI, Outils pour Windows PowerShell et l'API
AWS) (p. 168)
• Configuration de votre IdP SAML 2.0 à l'aide d'une relation d'approbation des parties utilisatrices et
ajout de requêtes (p. 168)
• Intégration de prestataires de solution SAML tiers avec AWS (p. 169)
• Configuration des assertions SAML pour la réponse d'authentification (p. 171)
Création et gestion d'un fournisseur d'identité SAML (AWS Management Console)
Vous pouvez utiliser l'AWS Management Console pour créer et supprimer des fournisseurs d'identité
SAML.
Pour créer un fournisseur d'identité SAML
1.
Avant de pouvoir créer un fournisseur d'identité SAML, vous avez besoin du document
de métadonnées SAML que vous obtenez auprès de l'IdP incluant le nom de l'auteur, des
informations relatives à l'expiration et des clés pouvant servir à valider la réponse d'authentification
SAML (assertions) fournies par l'IdP. Pour générer le document de métadonnées, utilisez le
logiciel de gestion des identités qu'utilise votre organisation en guise d'IdP. Pour obtenir des
instructions sur la configuration de bon nombre des IdP disponibles pour les utiliser avec AWS,
notamment comment générer le document de métadonnées SAML requis, consultez Intégration
de prestataires de solution SAML tiers avec AWS (p. 169).
Important
Le certificat x.509 qui est inclus comme partie du document des métadonnées SAML doit
utiliser une taille de clé au moins égale à 1 024 bits. Si la taille est plus petite, la création
d'IdP échoue avec une erreur « Impossible d'analyser les métadonnées ».
2.
3.
Dans le volet de navigation, cliquez sur Identity Providers, puis sur Create Provider.
4.
Sous Provider Type, cliquez sur Choose a provider type, puis cliquez sur SAML.
5.
Saisissez un nom pour le fournisseur d'identité.
6.
Pour Metadata Document, cliquez sur Choose File, spécifiez le document de métadonnées SAML
que vous avez téléchargé dans Step 1 (p. 167), puis cliquez sur Open. Cliquez sur Next Step.
7.
Vérifiez les informations que vous avez fournies, puis cliquez sur Create.
167
Pour supprimer un fournisseur SAML
1.
2.
Dans le volet de navigation, cliquez sur Identity Providers.
3.
4.
Sélectionnez la case à cocher en regard du fournisseur d'identité que vous souhaitez supprimer.
Cliquez sur Delete Providers.
Gestion d'un fournisseur SAML (AWS CLI, Outils pour Windows PowerShell et l'API AWS)
Utilisez les commandes suivantes pour créer et gérer un fournisseur SAML.
Pour créer un fournisseur d'identité et télécharger un document de métadonnées
• AWS CLI : aws iam create-saml-provider
• Outils pour Windows PowerShell : New-IAMSAMLProvider
• API AWS : CreateSAMLProvider
Pour créer un document de métadonnées pour un IdP
• AWS CLI : aws iam update-saml-provider
• Outils pour Windows PowerShell : Update-IAMSAMLProvider
• API AWS : UpdateSAMLProvider
Pour obtenir des informations sur un fournisseur spécifique, comme l'ARN, la date de création et
l'expiration
• AWS CLI : aws iam get-saml-provider
• Outils pour Windows PowerShell : Get-IAMSAMLProvider
• API AWS : GetSAMLProvider
Pour répertorier des informations pour tous les IdP, comme l'ARN, la date de création date et
l'expiration
• AWS CLI : aws iam list-saml-providers
• Outils pour Windows PowerShell : Get-IAMSAMLProviders
• API AWS : ListSAMLProviders
Pour supprimer un IdP
• AWS CLI : aws iam delete-saml-provider
• Outils pour Windows PowerShell : Remove-IAMSAMLProvider
• API AWS : DeleteSAMLProvider
Configuration de votre IdP SAML 2.0 à l'aide d'une relation d'approbation des parties
utilisatrices et ajout de requêtes
Lorsque vous créez un fournisseur SAML et le rôle pour l'accès SAML dans IAM, vous donnez
essentiellement des informations à AWS sur le fournisseur d'identité (IdP) et sur les actions que
les utilisateurs sont autorisés à effectuer. La prochaine étape consiste à définir AWS en tant que
fournisseur de services auprès de l'IdP. Il s'agit là de l'ajout d'une relation d'approbation des parties
utilisatrices entre votre IdP et AWS. Le processus exact utilisé pour ajouter une relation d'approbation
168
des parties utilisatrices dépend de l'IdP que vous utilisez. Pour plus d'informations, reportez-vous à la
documentation de votre logiciel de gestion d'identité.
De nombreux IdP vous permettent de spécifier une URL à partir de laquelle ils peuvent lire un
document XML qui contient des informations sur les parties utilisatrices et des certificats. Pour AWS,
vous pouvez utiliser https://signin.aws.amazon.com/static/saml-metadata.xml
S'il n'est pas possible de spécifier directement une URL, téléchargez le document XML à partir de
l'URL ci-dessus et importez-le dans l'application de votre IdP.
Vous devez également créer les règles de requête appropriées dans votre IdP afin de spécifier
AWS en tant que partie utilisatrice. Lorsque l'IdP envoie une réponse SAML au point de terminaison
AWS, il inclut une assertion SAML qui contient une ou plusieurs requêtes. Une requête contient des
informations sur l'utilisateur et ses groupes. Une règle de requête mappe ces informations à des
attributs SAML. Ceci vous garantit que les réponses d'authentification SAML de votre IdP contiendront
les attributs requis par AWS dans les stratégies IAM pour vérifier les autorisations des utilisateurs
fédérés. Pour plus d'informations, consultez les rubriques suivantes :
• Présentation du rôle qui autorise l'accès fédéré SAML à vos ressources AWS (p. 158). Cette
rubrique décrit les clés spécifiques à SAML dans les stratégies IAM et explique comment les utiliser
pour limiter les autorisations des utilisateurs fédérés SAML.
• Configuration des assertions SAML pour la réponse d'authentification (p. 171). Cette rubrique
explique comment configurer des requêtes SAML contenant des informations sur l'utilisateur. Les
requêtes sont regroupées dans une assertion SAML et intégrées dans la réponse SAML qui est
envoyée à AWS. Vous devez vous assurer que les informations requises par les stratégies AWS
sont incluses dans l'assertion SAML, dans un format qu'AWS est en mesure de lire et d'utiliser.
• Intégration de prestataires de solution SAML tiers avec AWS (p. 169). Cette rubrique contient des
liens vers la documentation fournie par des organisations tierces sur les méthodes utilisées pour
intégrer des solutions d'identité à AWS.
Intégration de prestataires de solution SAML tiers avec AWS
Les liens suivants vous aident à configurer les solutions de fournisseurs d'identité SAML 2.0 tiers afin
qu'ils fonctionnent avec la fédération AWS.
Solution
En savoir plus
Auth0
AWS Integration in Auth0 – Cette page du site Web
de documentation Auth0 décrit comment configurer
l'authentification unique (SSO) avec AWS Management
Console et inclut un exemple JavaScript.
Bitium
Configuring SAML for AWS – Cet article du site de support
Bitium explique comment utiliser Bitium pour configurer
Amazon Web Services (AWS) avec l'authentification unique
(SSO) SAML.
CA Technologies
CA Security SSO Support for AWS – Cette page permet
d'accéder à un runbook détaillé qui décrit la procédure à
suivre pour inclure rapidement l'authentification unique (SSO)
fédérée SAML dans votre environnement CA SiteMinder ou
CA CloudMinder SSO. Remarque : L'inscription est requise.
Centrify
Configure Centrify and Use SAML for SSO to AWS – Cette
page du site Centrify explique comment configurer Centrify
pour l'utilisation de SAML pour l'authentification unique (SSO)
dans AWS.
169
Solution
En savoir plus
CertiVox
Setting up M-Pin SSO as an Identity Provider within
AWS – Cette page du site CertiVox explique comment
configurer un fournisseur de services AWS pour
l'authentification SSO via votre système M-Pin SSO.
Clearlogin
Amazon Web Services Setup – Cet article du Centre
d'assistance Clearlogin explique comment configurer la
fonctionnalité d'authentification unique (SSO) entre Clearlogin
et AWS.
Suite G Google
Application cloud Amazon Web Services – cet article sur
le site de l'aide pour les administrateurs Google G Suite
explique comment configurer G Suite en tant que fournisseur
d'identité SAML 2.0 avec AWS en tant que le fournisseur de
services.
Identacor
Configuring SSO (SAML) for AWS – Cet article du site
web Identacor décrit comment configurer et activer
l'authentification unique (SSO) pour AWS.
Matrix42
Guide de démarrage MyWorkspace - Ce guide décrit
comment intégrer les services AWS Identity à Matrix42
MyWorkspace.
Microsoft Active Directory Federation Services
Enabling Federation to AWS Using Windows Active Directory,
(AD FS)
AD FS, and SAML 2.0 – Ce billet du blog sur la sécurité AWS
montre comment configurer AD FS sur une instance EC2 et
activer la fédération SAML avec AWS.
PowerShell Automation to Give AWS Console Access – Ce
billet du blog de Sivaprasad Padisetty décrit comment utiliser
Windows PowerShell pour automatiser le processus de
configuration d'Active Directory et d'AD FS, et comment
activer la fédération SAML avec AWS.
miniOrange
SSO for AWS – Cette page du site web miniOrange
décrit comment établir un accès sécurisé à AWS pour les
entreprises, ainsi qu'un contrôle complet de l'accès aux
applications AWS.
Okta
Amazon Web Services and Okta Integration Guide – A
partir de cette page du site de support Okta, vous pouvez
télécharger un fichier PDF qui décrit comment configurer
Okta afin de l'utiliser avec AWS.
OneLogin
Configuring SAML Single-Role for AWS – Cet article du
Centre d'assistance OneLogin explique comment configurer
la fonctionnalité d'authentification unique (SSO) entre
OneLogin et AWS.
170
Solution
En savoir plus
Ping Identity
PingFederate AWS Connector – A partir de cette page du site
web Ping Identity, vous pouvez télécharger un fichier PDF
qui décrit comment configurer un serveur PingFederate pour
autoriser l'authentification unique (SSO) pour les comptes
utilisateur avec AWS.
Configuring an SSO connection to AWS – Cette page
Ping Identity décrit comment configurer une connexion
d'authentification unique (SSO) entre PingOne et AWS.
RadiantLogic
Radiant Logic Technology Partners – Le service RadiantOne
Federated Identity Service de Radiant Logic s'intègre à AWS
pour fournir un hub d'identité pour l'authentification unique
(SSO) SAML.
Salesforce.com
How to configure SSO from Salesforce to AWS – Cet article
du site de développeurs Salesforce.com décrit comment
configurer un fournisseur d'identité (IdP) dans Salesforce
et comment configurer AWS en tant que fournisseur de
services.
SecureAuth
AWS - SecureAuth SAML SSO – Cet article du site web
SecureAuth décrit comment configurer l'intégration SAML
avec AWS pour un périphérique SecureAuth.
Shibboleth
How to Use Shibboleth for SSO to the AWS Management
Console – Ce billet du blog sur la sécurité AWS fournit
un didacticiel détaillé qui explique comment configurer
Shibboleth, puis comment le paramétrer en tant que
fournisseur d'identité pour AWS.
Pour plus d'informations, consultez la page Partenaires IAM du site web AWS.
Configuration des assertions SAML pour la réponse d'authentification
Dans votre organisation, une fois l'identité de l'utilisateur vérifiée, l'IdP envoie une
réponse d'authentification au point de terminaison SAML AWS à l'adresse https://
signin.aws.amazon.com/saml. La réponse est une demande POST incluant un jeton SAML
conforme à la norme de liaison HTTP POST pour SAML 2.0 et contenant les éléments suivants, ou
requêtes. Vous les configurez dans votre IdP compatible avec SAML. Pour obtenir des instructions sur
la procédure visant à entrer ces requêtes, consultez la documentation de votre IdP.
Lorsque l'IdP envoie la réponse contenant ces requêtes à AWS, bon nombre des requêtes entrantes
correspondent aux clés de contexte AWS qui peuvent être vérifiées dans les stratégies IAM à l'aide de
l'élément Condition. Pour obtenir une liste des mappages disponibles, consultez la section Attributs
de mappage SAML sur les clés de contexte de stratégie d'approbation AWS (p. 174).
Subject and NameID
L'extrait suivant en présente un exemple. Substituez vos propres valeurs avec les valeurs
marquées. Il doit y avoir exactement 1 élément SubjectConfirmation et la valeur de l'attribut
Recipient à l'intérieur de l'élément SubjectConfirmationData doit correspondre au point de
terminaison AWS (https://signin.aws.amazon.com/saml), comme illustré dans l'exemple
suivant. Pour plus d'informations sur les formats d'identifiant de nom pris en charge pour les
interactions d'authentification unique, consultez Oracle Sun OpenSSO Enterprise Administration
Reference.
171
<Subject>
<NameID Format="urn:oasis:names:tc:SAML:2.0:nameidformat:persistent">_cbb88bf52c2510eabe00c1642d4643f41430fe25e3</NameID>
<SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<SubjectConfirmationData NotOnOrAfter="2013-11-05T02:06:42.876Z"
Recipient="https://signin.aws.amazon.com/saml"/>
</SubjectConfirmation>
</Subject>
AudienceRestriction et Audience
Pour des raisons de sécurité, AWS doit être inclus en tant que public visé par l'assertion SAML
que votre IdP envoie à AWS. Par conséquent, la valeur de l'élément Audience doit correspondre
à l'une des deux valeurs suivantes, soit https://signin.aws.amazon.com/saml, soit
urn:amazon:webservices. AWS teste et applique cette valeur automatiquement. L'exemple
suivant de code XML extrait d'une assertion SAML montre comment cette clé peut être spécifiée
par l'IdP et indique les valeurs valides. Il vous suffit d'en inclure une.
<Conditions>
<AudienceRestriction>
<Audience>https://signin.aws.amazon.com/saml</Audience>
<Audience>urn:amazon:webservices</Audience>
</AudienceRestriction>
</Conditions>
Important
La valeur SAML AudienceRestriction dans l'assertion SAML de l'IdP n'est
pas mappée à la saml:aud clé de contexte que vous pouvez tester dans une
stratégie IAM. À la place, la clé de contexte saml:aud vient de l'attribut destinataire
SAML, qui est l'équivalent SAML du champ du public OIDC, par exemple, par
accounts.google.com:aud.
Un élément Attribute avec l'attribut Name défini sur https://aws.amazon.com/SAML/
Attributes/Role
Cet élément contient un ou plusieurs éléments AttributeValue qui répertorient le rôle IAM et le
fournisseur d'identité SAML auquel l'utilisateur est mappé par votre IdP. Le rôle et le fournisseur
d'identité sont spécifiés sous forme de paire d'ARN séparés par une virgule au même format
que les paramètres RoleArn et PrincipalArn qui sont transmis à AssumeRoleWithSAML.
Cet élément doit contenir au moins une paire rôle-fournisseur, c'est-à-dire, au moins un élément
AttributeValue, et peut contenir plusieurs paires. Si l'élément contient plusieurs paires,
l'utilisateur doit choisir le rôle à assumer lorsqu'il utilise WebSSO pour le connecter à l'AWS
Management Console.
Important
La valeur de l'attribut Name dans la balise Attribute est sensible à la casse. Il doit être
défini sur https://aws.amazon.com/SAML/Attributes/Role précisément.
<Attribute Name="https://aws.amazon.com/SAML/Attributes/Role">
<AttributeValue>arn:aws:iam::account-number:role/rolename1,arn:aws:iam::account-number:saml-provider/provider-name</
AttributeValue>
AttributeValue>
172
AttributeValue>
</Attribute>
Un élément Attribute avec l'attribut Name défini sur https://aws.amazon.com/SAML/
Attributes/RoleSessionName
Cet élément contient un élément AttributeValue qui fournit un identifiant pour les informations
d'identification temporaires AWS qui sont émises pour le SSO et qui sert à afficher les informations
utilisateur dans l'AWS Management Console. La valeur de l'élément AttributeValue doit
comporter 2 à 64 caractères, ne doit contenir que des caractères alphanumériques, des traits de
soulignement et les caractères suivants : + (signe plus), = (signe égal à), , (virgule), . (point), @
(arobase) et - (trait d'union). Il ne doit pas contenir d'espace. La valeur est généralement un ID
utilisateur (bobsmith) ou une adresse e-mail ([email protected]). Il ne peut pas contenir
d'espace, comme dans le nom complet de l'utilisateur (Bob Smith).
Important
La valeur de l'attribut Name dans la balise Attribute est sensible à la casse. Il doit
être défini sur https://aws.amazon.com/SAML/Attributes/RoleSessionName
précisément.
<Attribute Name="https://aws.amazon.com/SAML/Attributes/RoleSessionName">
<AttributeValue>user-id-name</AttributeValue>
</Attribute>
Un élément Attribute facultatif avec l'attribut SessionDuration défini sur https://
aws.amazon.com/SAML/Attributes/SessionDuration
Cet élément contient un élément AttributeValue qui spécifie la durée maximale pendant
laquelle l'utilisateur peut accéder à la AWS Management Console avant d'avoir à demander de
nouvelles informations d'identification temporaires. La valeur est un nombre entier représentant
le nombre de secondes et peut atteindre 43 200 secondes (12 heures) au maximum. Si cet
attribut n'est pas présent, la durée de session maximale par défaut est une d'heure (valeur par
défaut du paramètre DurationSeconds de l'API AssumeRoleWithSAML). Pour utiliser cet
attribut, vous devez configurer le fournisseur SAML afin de fournir un accès à authentification
unique à la AWS Management Console via le point de terminaison Web de connexion à la
console à l'adresse https://signin.aws.amazon.com/saml. Notez que cet attribut
prolonge les sessions uniquement à la AWS Management Console. Il ne peut pas prolonger la
durée de vie des autres informations d'identification. Toutefois, s'il est présent dans un appel
d'API AssumeRoleWithSAML, il peut être utilisé pour réduire la durée de vie des informations
d'identification renvoyées par l'appel à une valeur inférieure à celle de 60 minutes par défaut.
Notez également que si un attribut SessionNotOnOrAfter est également défini, la valeur la
plus faible des deux attributs (SessionDuration ou SessionNotOnOrAfter) établit la durée
maximale de la session de console.
Lorsque vous activez les sessions de console avec une durée prolongée, le risque de divulgation
des informations d'identification augmente. Pour vous aider à réduire ce risque, vous pouvez
immédiatement désactiver les sessions de console actives pour un rôle en choisissant Revoke
Sessions sur la page Role Summary dans la console IAM. Pour plus d'informations, consultez
Révocation des informations d'identification de sécurité temporaires d'un rôle IAM (p. 232).
Important
La valeur de l'attribut Name dans la balise Attribute est sensible à la casse. Il doit
être défini sur https://aws.amazon.com/SAML/Attributes/SessionDuration
précisément.
173
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SessionDuration">
<AttributeValue>7200</AttributeValue>
</Attribute>
Attributs de mappage SAML sur les clés de contexte de stratégie d'approbation AWS
Les tableaux de cette section répertorient les attributs SAML utilisés couramment et leur
correspondance avec les clés de contexte de condition de stratégie d'approbation dans AWS. Vous
pouvez utiliser ces clés pour contrôler l'accès à un rôle en les comparant aux valeurs incluses dans les
affirmations qui accompagnent une demande SAML d'accès à un rôle.
Important
Ces clés sont disponibles uniquement dans les stratégies d'approbation IAM (stratégies
qui déterminent qui peut assumer un rôle) et ne sont pas applicables aux stratégies
d'autorisations.
Dans le tableau des attributs eduPerson et eduOrg, les valeurs sont saisies sous forme de chaînes
ou de listes de chaînes. Pour les valeurs de chaînes, vous pouvez tester ces valeurs dans des
stratégies d'approbation IAM à l'aide des conditions StringEquals ou StringLike. Pour les
valeurs qui contiennent une liste de chaînes, vous pouvez utiliser les opérateurs de définition de
stratégie (p. 436) ForAnyValue et ForAllValues pour tester ces valeurs dans des stratégies
d'approbation.
Note
Vous devez inclure une seule requête par clé de contexte AWS. Si vous incluez plusieurs
requêtes, une seule d'entre elles sera mappée.
Attributs eduPerson et eduOrg
Attribut eduPerson ou eduOrg (Name key)
Est mappé avec cette
clé de contexte AWS (clé
FriendlyName)
urn:oid:1.3.6.1.4.1.5923.1.1.1.1
eduPersonAffiliation Liste de chaînes
urn:oid:1.3.6.1.4.1.5923.1.1.1.2
eduPersonNickname
Liste de chaînes
urn:oid:1.3.6.1.4.1.5923.1.1.1.3
eduPersonOrgDN
String
urn:oid:1.3.6.1.4.1.5923.1.1.1.4
eduPersonOrgUnitDN
Liste de chaînes
urn:oid:1.3.6.1.4.1.5923.1.1.1.5
eduPersonPrimaryAffiliation
String
urn:oid:1.3.6.1.4.1.5923.1.1.1.6
eduPersonPrincipalName
String
urn:oid:1.3.6.1.4.1.5923.1.1.1.7
eduPersonEntitlement Liste de chaînes
urn:oid:1.3.6.1.4.1.5923.1.1.1.8
eduPersonPrimaryOrgUnitDN
String
urn:oid:1.3.6.1.4.1.5923.1.1.1.9
eduPersonScopedAffiliation
Liste de chaînes
urn:oid:1.3.6.1.4.1.5923.1.1.1.10
eduPersonTargetedID
Liste de chaînes
urn:oid:1.3.6.1.4.1.5923.1.1.1.11
eduPersonAssurance
Liste de chaînes
urn:oid:1.3.6.1.4.1.5923.1.2.1.2
eduOrgHomePageURI
Liste de chaînes
174
Type
Attribut eduPerson ou eduOrg (Name key)
Est mappé avec cette
clé de contexte AWS (clé
FriendlyName)
Type
urn:oid:1.3.6.1.4.1.5923.1.2.1.3
eduOrgIdentityAuthNPolicyURI
Liste de chaînes
urn:oid:1.3.6.1.4.1.5923.1.2.1.4
eduOrgLegalName
Liste de chaînes
urn:oid:1.3.6.1.4.1.5923.1.2.1.5
eduOrgSuperiorURI
Liste de chaînes
urn:oid:1.3.6.1.4.1.5923.1.2.1.6
eduOrgWhitePagesURI
Liste de chaînes
urn:oid:2.5.4.3
cn
Liste de chaînes
Attributs Active Directory
Attribut AD
Est mappé à cette
clé de contexte
AWS
Type
http://schemas.xmlsoap.org/ws/2005/05/
identity/claims/name
name
String
http://schemas.xmlsoap.org/claims/
CommonName
commonName
String
identity/claims/givenname
givenName
String
identity/claims/surname
surname
String
identity/claims/emailaddress
mail
String
http://schemas.microsoft.com/ws/2008/06/
identity/claims/primarygroupsid
uid
String
Attributs X.500
Attribut X.500
Est mappé à cette clé de
contexte AWS
Type
2.5.4.3
commonName
String
2.5.4.4
surname
String
2.4.5.42
givenName
String
2.5.4.45
x500UniqueIdentifier
String
0.9.2342.19200300100.1.1
uid
String
0.9.2342.19200300100.1.3
mail
String
0.9.2342.19200300.100.1.45
organizationStatus
String
175
Activation de l'accès des utilisateurs fédérés SAML 2.0 à
l'AWS Management Console
A l'aide d'un rôle, vous pouvez configurer votre IdP SAML 2.0 et AWS de manière à permettre à vos
utilisateurs fédérés d'accéder à l'AWS Management Console. Le rôle accorde aux utilisateurs les
autorisations nécessaires pour effectuer des tâches dans la console. Pour donner aux utilisateurs
fédérés SAML d'autres moyens d'accéder à AWS, consultez l'une des rubriques suivantes :
• AWS CLI : Passer à un rôle IAM (AWS Command Line Interface) (p. 221)
• Outils pour Windows PowerShell : Passer à un rôle IAM (Outils pour Windows PowerShell) (p. 223)
• API AWS : Assumer un rôle IAM (API) (p. 225)
Présentation
Le diagramme suivant illustre le flux d'une authentification unique SAML.
Note
Cette utilisation spécifique de SAML est différente de l'utilisation générale illustrée dans A
propos de la fédération SAML 2.0 (p. 156), car ce flux de travail ouvre AWS Management
Console pour le compte de l'utilisateur. Cette procédure requiert l'utilisation du point de
terminaison SSO AWS au lieu d'un appel direct de l'API AssumeRoleWithSAML. Le
point de terminaison appelle l'API pour l'utilisateur, puis retourne une URL qui redirige
automatiquement le navigateur de l'utilisateur vers AWS Management Console.
Le diagramme suivant illustre les étapes suivantes :
1. L'utilisateur se rend sur le portail de l'organisation, puis choisit d'accéder à l'AWS Management
Console. Le portail de l'organisation est généralement une fonction de votre fournisseur d'identité
(IdP) qui gère l'échange d'approbation entre l'organisation et AWS. Par exemple, dans les services
Active Directory Federation Services, l'URL du portail est : https://ADFSServiceName/adfs/
ls/IdpInitiatedSignOn.aspx
2. Le portail vérifie l'identité de l'utilisateur dans l'organisation.
3. Il génère ensuite une réponse d'authentification SAML contenant des assertions qui identifient
l'utilisateur et incluent des attributs spécifiques à celui-ci. Vous pouvez également configurer votre
IdP pour inclure un attribut d'assertion SAML appelé SessionDuration qui spécifie la durée de
validité de la session de console. Le portail envoie cette réponse au navigateur client.
176
4. Le navigateur client est redirigé vers le point de terminaison d'authentification unique AWS et publie
l'assertion SAML.
5. Le point de terminaison demande des informations d'identification de sécurité temporaires pour le
compte de l'utilisateur et crée une URL de connexion à la console qui utilise ces informations.
6. AWS renvoie ensuite l'URL de connexion au client sous forme de redirection.
7. Le navigateur client est redirigé vers AWS Management Console. Si la réponse d'authentification
SAML inclut des attributs associés à plusieurs rôles IAM, l'utilisateur est d'abord invité à sélectionner
le rôle utilisé pour accéder à la console.
Du point de vue de l'utilisateur, le processus est exécuté de manière transparente. Il commence la
procédure sur le portail interne de l'organisation et termine dans AWS Management Console, sans
avoir à fournir d'informations d'identification AWS.
Consultez les sections suivantes pour une présentation de la configuration de ce comportement, ainsi
que des liens vers des procédures détaillées.
Configurer votre réseau en tant que fournisseur SAML pour AWS
Au sein du réseau de votre organisation, vous configurez votre base d'identités (par ex., Windows
Active Directory) afin qu'il fonctionne de concert avec un fournisseur d'identité (IdP) SAML tel que
Windows Active Directory Federation Services, Shibboleth, etc. A l'aide de l'IdP, vous générez un
document de métadonnées qui décrit votre organisation en tant que fournisseur d'identité et inclut
des clés d'authentification. Vous configurez également le portail de l'organisation afin qu'il achemine
les demandes des utilisateurs vers AWS Management Console vers le point de terminaison SAML
AWS pour l'authentification à l'aide d'assertions SAML. La configuration de l'IdP pour la génération
d'un fichier metadata.xml varie en fonction de l'IdP. Pour savoir comment procéder, reportez-vous à
la documentation de votre IdP, ou consultez Intégration de prestataires de solution SAML tiers avec
AWS (p. 169) pour obtenir des liens vers la documentation web de nombreux fournisseurs SAML pris
en charge.
Créer un fournisseur SAML dans IAM
Ensuite, vous vous connectez à AWS Management Console et accédez à la console IAM. Dans
la console, vous créez un nouveau fournisseur SAML, c'est-à-dire une entité IAM qui contient
des informations sur le fournisseur d'identité de votre organisation. Au cours du processus, vous
téléchargez le document de métadonnées généré par le logiciel de l'IdP de votre organisation à l'étape
précédente. Pour plus d'informations, consultez Création de fournisseurs d'identité SAML (p. 166).
Configurer des autorisations pour vos utilisateurs fédérés dans AWS
La prochaine étape consiste à créer un rôle IAM qui établit une relation d'approbation entre IAM et
l'IdP de votre organisation. Celle-ci identifie votre IdP en tant mandataire (entité de confiance) dans
le cadre de la fédération. Le rôle définit également les actions que les utilisateurs authentifiés par
l'IdP de l'organisation sont en mesure d'effectuer dans AWS. Vous pouvez créer ce rôle à l'aide de
la console IAM. Lorsque vous créez la stratégie d'approbation qui détermine qui peut assumer le
rôle, vous spécifiez le fournisseur SAML créé précédemment dans IAM, de même qu'un ou plusieurs
attributs SAML auxquels un utilisateur doit correspondre pour être autorisé à assumer le rôle. Par
exemple, vous pouvez spécifier que seuls les utilisateurs dont la valeur eduPersonOrgDN SAML est
ExampleOrg sont autorisés à se connecter. L'assistant de rôle ajoute automatiquement une condition
pour tester l'attribut saml:aud pour vérifier que le rôle est assumé uniquement pour la connexion à
AWS Management Console. La stratégie d'approbation du rôle peut se présenter comme suit :
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
177
"Principal": {"Federated": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:samlprovider/ExampleOrgSSOProvider"},
"Condition": {"StringEquals": {
"saml:edupersonorgdn": "ExampleOrg",
"saml:aud": "https://signin.aws.amazon.com/saml"
}}
}]
}
Dans la stratégie d'accès (p. 281) du rôle, vous spécifiez les autorisations comme pour tout autre
rôle, utilisateur ou groupe. Par exemple, si les utilisateurs de votre organisation sont autorisés à
administrer les instances Amazon EC2, vous autorisez explicitement les actions Amazon EC2 dans la
stratégie d'accès. Pour ce faire, vous pouvez affecter une stratégie gérée (p. 324) comme Amazon
EC2 Full Access.
Pour plus d'informations sur la création d'un rôle pour un IdP SAML, consultez Création d'un rôle pour
la fédération SAML 2.0 (AWS Management Console) (p. 208).
Achever la configuration de l'IdP SAML et créer des assertions pour la réponse
d'authentification SAML
Une fois le rôle créé, informez votre IdP SAML qu'AWS est le fournisseur de services utilisé en
installant le fichier saml-metadata.xml qui se trouve à l'adresse https://signin.aws.amazon.com/
static/saml-metadata.xml. L'installation du fichier est différente selon votre IdP. Certains fournisseurs
vous permettent d'entrer l'URL, après quoi ils récupèrent et installent le fichier pour vous. D'autres
fournisseurs exigent que vous téléchargiez le fichier à partir de l'URL afin de le fournir en tant que
fichier local. Pour plus d'informations, reportez-vous à la documentation de votre IdP, ou consultez
Intégration de prestataires de solution SAML tiers avec AWS (p. 169) pour obtenir des liens vers la
documentation web de nombreux fournisseurs SAML pris en charge.
Vous devez également configurer les informations que l'IdP doit transmettre à AWS en tant
qu'attributs SAML dans le cadre de la réponse d'authentification. La plupart de ces informations
s'affichent dans AWS en tant que clés de contexte de condition que vous pouvez évaluer dans
vos stratégies pour garantir que seuls les utilisateurs authentifiés dans les contextes appropriés
recevront des autorisations d'accès à vos ressources AWS. Vous pouvez spécifier des plages qui
limitent les moments où la console peut être utilisée et la durée maximale (jusqu'à 12 heures) pendant
laquelle les utilisateurs peuvent accéder à la console avant d'avoir à actualiser leurs informations
d'identification. Pour plus d'informations, consultez Configuration des assertions SAML pour la réponse
d'authentification (p. 171).
Création d'une URL qui permet aux utilisateurs fédérés
d'accéder à AWS Management Console (Broker de fédération
personnalisé)
Vous pouvez écrire et exécuter du code afin de créer une URL qui permet aux utilisateurs qui se
connectent au réseau de votre organisation d'accéder en toute sécurité à AWS Management Console.
L'URL contient un jeton de connexion qui est émis par AWS et qui authentifie l'utilisateur auprès
d'AWS.
Note
Si votre organisation utilise un fournisseur d'identité (IdP) compatible avec SAML tel que les
services ADFS (Active Directory Federation Services) Microsoft ou Shibboleth open source,
vous pouvez configurer l'accès à AWS Management Console sans écrire de code. Pour
en savoir plus, consultez Activation de l'accès des utilisateurs fédérés SAML 2.0 à l'AWS
Management Console (p. 176).
178
Pour permettre aux utilisateurs de votre organisation d'accéder à AWS Management Console, vous
pouvez créer un « broker d'identité » personnalisé qui effectue les étapes suivantes :
1. Vérifier que l'utilisateur est authentifié par votre système d'identité local.
2. Appeler les API AssumeRole (recommandée) ou GetFederationToken AWS Security Token
Service (AWS STS) pour obtenir des informations d'identification de sécurité temporaires pour
l'utilisateur. Les informations d'identification sont associées à un rôle avec des autorisations qui
contrôlent les actions que l'utilisateur peut effectuer. Ces informations d'identification ont une durée
maximale telle que spécifiée dans le paramètre DurationSeconds de l'appel d'API AssumeRole
ou GetFederationToken utilisé pour les générer.
Important
Si vous utilisez l'API AssumeRole, vous devez l'appeler en tant qu’utilisateur IAM avec des
informations d'identification à long terme. L'appel vers le point de terminaison de fédération
à l’étape 3 fonctionne uniquement si les informations d'identification temporaires sont
demandées par un utilisateur IAM avec des informations d'identification à long terme. Si les
informations d'identification temporaires sont demandées par un utilisateur qui assume le
rôle IAM avec un autre ensemble d'informations d'identification temporaires, l'appel au point
de terminaison de fédération échoue.
3. Appeler le point de terminaison de fédération AWS et fournir les informations d'identification de
sécurité temporaires pour demander un jeton de connexion.
• Si vous avez utilisé l'une des API AssumeRole* pour obtenir les informations d'identification de
sécurité temporaires, cette demande au point de terminaison de fédération AWS peut inclure le
paramètre HTTP SessionDuration pour spécifier la durée de validité de la session de console
fédérée (au maximum, 12 heures).
• Si vous avez utilisé plutôt l'API GetFederationToken pour obtenir les informations
d'identification, vous n'avez pas besoin du paramètre HTTP SessionDuration, car les
informations d'identification temporaires sont déjà valides pendant 36 heures au maximum et
déterminent la durée maximale de la session de console fédérée.
4. Créer une URL incluant le jeton pour la console.
5. Donner l'URL à l'utilisateur ou appeler l'URL pour le compte de l'utilisateur.
L'URL fournie par le point de terminaison de fédération est valide pendant 15 minutes à compter de
sa création. Les informations d'identification de sécurité temporaires associées à l'URL sont valides
pendant la durée spécifiée lors de leur création et ce, à compter du moment où elles sont créées.
Important
Gardez à l'esprit que l'URL accorde l'accès à vos ressources AWS via AWS Management
Console dans la mesure où vous avez activé les autorisations nécessaires dans les
informations d'identification de sécurité temporaires associées. Pour cette raison, vous devez
considérer l'URL comme un secret. Nous vous recommandons de retourner l'URL via une
redirection sécurisée, par exemple, en utilisant un code de statut de réponse HTTP 302 via
une connexion SSL. Pour plus d'informations sur le code de statut de réponse HTTP 302,
reportez-vous à RFC 2616, section 10.3.3.
Pour consulter un exemple d'application qui montre comment mettre en œuvre une solution
d'authentification unique, accédez à l'Exemple de cas d'utilisation de proxy de fédération AWS
Management Console dans les Exemples de code et bibliothèques AWS.
Pour effectuer ces tâches, vous pouvez utiliser l'API de requête HTTPS pour AWS Identity and Access
Management (IAM) et AWS Security Token Service (AWS STS). Vous pouvez également utiliser des
langages de programmation tels que Java, Ruby ou C#, avec le kit SDK AWS approprié. Chacune de
ces méthodes est décrite dans les sections suivantes.
179
Rubriques
• Exemple de code utilisant les API de requête IAM (p. 180)
• Exemple de code utilisant Python (p. 183)
• Exemple de code utilisant Java (p. 184)
• Exemple montrant comment créer l'URL (Ruby) (p. 186)
Exemple de code utilisant les API de requête IAM
Vous pouvez créer une URL qui accorde à vos utilisateurs fédérés un accès direct à AWS
Management Console. Cette tâche utilise l'API de requête HTTPS IAM et AWS STS. Pour plus
d'informations sur les demandes de requête, consultez Envoi de demandes de requête.
Note
La procédure suivante contient des exemples de chaînes de texte. Pour faciliter la lecture, des
sauts de ligne ont été ajoutés aux exemples les plus longs. Lorsque vous créez ces chaînes
pour votre propre utilisation, il convient d'omettre les sauts de ligne.
Pour permettre à un utilisateur fédéré d'accéder à vos ressources à partir de AWS
Management Console
1.
Authentifiez l'utilisateur dans votre système d'identité et d'autorisation.
2.
Obtenez des informations d'identification de sécurité temporaires pour l'utilisateur. Les
informations d'identification temporaires incluent un ID de clé d'accès, une clé d'accès secrète et
un jeton (token) de sécurité. Pour plus d'informations sur la création d'informations d'identification
temporaires, consultez Informations d'identification de sécurité temporaires (p. 244)Création
d'informations d'identification de sécurité temporaires.
Pour obtenir des informations d'identification temporaires, vous appelez l'API AssumeRole
(recommandée) ou l'API GetFederationToken AWS STS. Pour plus d'informations sur les
différences entre ces API, consultez Understanding the API Options for Securely Delegating
Access to Your AWS Account
Important
• Lors de la création d'informations d'identification de sécurité temporaires, vous devez
spécifier les autorisations que ces informations d'identification accordent à l'utilisateur
qui les détient. Pour les API qui commencent par AssumeRole*, vous utilisez un
rôle IAM pour accorder les autorisations. Pour les autres API, le mécanisme varie en
fonction de l'API. Pour en savoir plus, consultez Contrôle des autorisations affectées
aux informations d'identification de sécurité temporaires (p. 262).
• Si vous utilisez l'API AssumeRole, vous devez l'appeler en tant qu’utilisateur
IAM avec des informations d'identification à long terme. L'appel vers le point de
terminaison de fédération à l’étape 3 fonctionne uniquement si les informations
d'identification temporaires sont demandées par un utilisateur IAM avec des
informations d'identification à long terme. Si les informations d'identification temporaires
sont demandées par un utilisateur qui assume le rôle IAM avec un autre ensemble
d'informations d'identification temporaires, l'appel au point de terminaison de fédération
échoue.
3.
Une fois que vous avez obtenu les informations d'identification de sécurité temporaires, insérezles dans une chaîne de « session » JSON pour les échanger contre un jeton de connexion.
L'exemple suivant montre comment encoder les informations d'identification. Vous remplacez le
texte de l'espace réservé par les valeurs appropriées dans les informations d'identification reçues
à l’étape précédente.
180
{"sessionId":"*** temporary access key ID ***",
"sessionKey":"*** temporary secret access key ***",
"sessionToken":"*** security token ***"}
4.
URL-encodez la chaîne de session de l’étape précédente. Dans la mesure où les informations que
vous encodez sont sensibles, nous vous recommandons de ne pas utiliser de service web pour
cette opération. Au lieu de cela, utilisez une fonction installée localement ou une fonctionnalité
de votre boîte à outils de développement pour encoder en toute sécurité ces informations, par
exemple la fonction urllib.quote_plus de Python, la fonction URLEncoder.encode de Java,
ou la fonction CGI.escape de Ruby, comme illustré dans les exemples plus loin dans cette
rubrique.
5.
Envoyez votre demande au point de terminaison de fédération AWS à l'adresse suivante :
https://signin.aws.amazon.com/federation
La demande doit inclure les paramètres Actionet Session, et (facultatif), si vous avez utilisé
AssumeRole, un paramètre HTTP SessionDuration comme illustré dans l'exemple suivant.
Action = getSigninToken
SessionDuration = time in seconds
Session = *** the URL encoded JSON string created in steps 3 & 4 ***
Le paramètre SessionDuration spécifie le nombre de secondes pendant lesquelles les
informations d'identification pour la session de console sont valides. Cette durée est distincte
de celle des informations d'identification temporaires. Vous pouvez spécifier une valeur
SessionDuration maximale de 43 200 (12 heures). Si le paramètre est manquant, la durée
de session correspond par défaut à celle des informations d'identification que vous avez
extraites de AWS STS à l’étape 2 (soit une heure par défaut). Consultez la documentation
de l'API AssumeRole pour des détails sur la façon de spécifier la durée à l'aide du paramètre
DurationSeconds. La possibilité de créer une session de console d'une durée supérieure à une
heure fait partie intégrante de l'action getSigninToken du point de terminaison de fédération.
Vous ne pouvez pas utiliser les API IAM ou STS pour obtenir des informations d'identification
valides pendant plus d'une heure (3 600 secondes).
Note
Vous n'avez pas besoin du paramètre HTTP SessionDuration si vous avez obtenu
les informations d'identification temporaires avec GetFederationToken, car la
session de console peut durer aussi longtemps que le délai de validité des informations
d'identification temporaires (jusqu'à 36 heures).
Lorsque vous activez les sessions de console avec une durée prolongée, le risque de divulgation
des informations d'identification augmente. Pour vous aider à réduire ce risque, vous pouvez
immédiatement désactiver les sessions de console actives pour un rôle en choisissant Revoke
Sessions sur la page Role Summary dans la console IAM. Pour plus d'informations, consultez
Révocation des informations d'identification de sécurité temporaires d'un rôle IAM (p. 232).
Votre demande devrait ressembler à l'exemple suivant : Des retours à la ligne ont été ajoutés ici
pour faciliter la lecture, mais vous devez envoyer une chaîne composée d'une seule ligne.
?Action=getSigninToken
&SessionDuration=43200
&Session=%7B%22sessionId%22%3A%22ASIAEXAMPLEMDLUUAEYQ%22%2C%22sessionKey
%22
181
%3A%22tpSl9thxr2PkEXAMPLETAnVLVGdwC5zXtGDr%2FqWi%22%2C%22sessionToken
%22%3A
%22AQoDYXdzEXAMPLE4BrM96BJ7btBQRrAcCjQIbg55555555OBT7y8h2YJ7woJkRzsLpJBpklC
qPXxS2AjRorJAm%2BsBtv1YXlZF%2FfHljgORxOevE388GdGaKRfO9W4DxK4HU0fIpwL
%2BQ7oX
2Fj%2BJa%2FAb5u0cL%2BzI1P5rJuDzH%2F0pWEiYfiWXXH20rWruXVXpIIO%2FPhMHlV3Jw
%2B
gDc4ZJ0WItuLPsuyP7BVUXWLcAVyTFbxyLy36FBSXF1z8a
%2FvJN7utcj0mJRGIiIZSV7FQuepa
WP5YARYMrOUMqBB3v308LKBU8Z0xYe2%2FqthrLXf1nX0njbU%2FJTrct
%2BEdG9PRb3907qa5n
VbnnnxdVQJ3mPgQchAZpDI9LsDDbGsa67JHUyFYnyUUUkMRfe7G70gjvbz9gQ%EXAMPLE
La réponse du point de terminaison de fédération est un document JSON avec une valeur
SigninToken. Elle sera similaire à l'exemple suivant.
{"SigninToken":"*** the SigninToken string ***"}
6.
Enfin, créez l'URL que vos utilisateurs fédérés utiliseront pour accéder à AWS Management
Console. L'URL est la même URL de point de terminaison de fédération que celle que vous avez
utilisée dans Step 5 (p. 181), à laquelle sont ajoutés les paramètres suivants :
?Action = login
&Issuer = *** the form-urlencoded URL for your internal sign-in page ***
&Destination = *** the form-urlencoded URL to the desired AWS console page
***
&SigninToken = *** the value of SigninToken received in the previous step
***
L'exemple suivant montre comment se présentera l'URL finale. L'URL est valide pendant
15 minutes à partir du moment où elle est créée. Les informations d'identification de sécurité
temporaires et la session de console intégrées dans l'URL sont valides pendant la durée spécifiée
dans le paramètre SessionDuration lors de leur demande initiale.
?Action=login
&Issuer=https%3A%2F%2Fexample.com
&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2Fs
&SigninToken=VCQgs5qZZt3Q6fn8Tr5EXAMPLEmLnwB7JjUc-SHwnUUWabcRdnWsi4DBn-dvC
CZ85wrD0nmldUcZEXAMPLE-vXYH4Q__mleuF_W2BE5HYexbe9y4Ofkje53SsjNNecATfjIzpW1
WibbnH6YcYRiBoffZBGExbEXAMPLE5aiKX4THWjQKC6gg6alHu6JFrnOJoK3dtP6I9a6hi6yPgm
iOkPZMmNGmhsvVxetKzr8mx3pxhHbMEXAMPLETv1pij0rok3IyCR2YVcIjqwfWv32HU2Xlj471u
3fU6uOfUComeKiqTGX974xzJOZbdmX_t_lLrhEXAMPLEDDIisSnyHGw2xaZZqudm4mo2uTDk9Pv
9l5K0ZCqIgEXAMPLEcA6tgLPykEWGUyH6BdSC6166n4M4JkXIQgac7_7821YqixsNxZ6rsrpzwf
nQoS14O7R0eJCCJ684EXAMPLEZRdBNnuLbUYpz2Iw3vIN0tQgOujwnwydPscM9F7foaEK3jwMkg
Apeb1-6L_OB12MZhuFxx55555EXAMPLEhyETEd4ZulKPdXHkgl6T9ZkIlHz2Uy1RUTUhhUxNtSQ
nWc5xkbBoEcXqpoSIeK7yhje9Vzhd61AEXAMPLElbWeouACEMG6Vd3dAgFYd6i5FYoyFrZLWvm
0LSG7RyYKeYN5VIzUk3YWQpyjP0RiT5KUrsUi-NEXAMPLExMOMdoODBEgKQskiu2ozh6r8bxwC
RNhujg
182
Exemple de code utilisant Python
L'exemple suivant montre comment utiliser Python pour créer par programmation une URL qui donne
aux utilisateurs fédérés un accès direct à AWS Management Console. L'exemple utilise AWS SDK for
Python (Boto).
Le code utilise l'API AssumeRole pour obtenir les informations d'identification de sécurité temporaires.
import urllib, json
import requests # 'pip install requests'
from boto.sts import STSConnection # AWS SDK for Python (Boto) 'pip install
boto'
# Step 1: Authenticate user in your own identity system.
# Step 2: Using the access keys for an IAM user in your AWS account,
# call "AssumeRole" to get temporary access keys for the federated user
# Note: Calls to AWS STS AssumeRole must be signed using the access key ID
# and secret access key of an IAM user or using existing temporary
credentials.
# The credentials can be in EC2 instance metadata, in environment variables,
# or in a configuration file, and will be discovered automatically by the
# STSConnection() function. For more information, see the Python SDK docs:
# http://boto.readthedocs.org/en/latest/boto_config_tut.html
assumed_role_object = sts_connection.assume_role(
role_arn="arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:role/ROLE-NAME",
role_session_name="AssumeRoleSession"
)
# Step 3: Format resulting temporary credentials into JSON
json_string_with_temp_credentials = '{'
json_string_with_temp_credentials += '"sessionId":"' +
assumed_role_object.credentials.access_key + '",'
json_string_with_temp_credentials += '"sessionKey":"' +
assumed_role_object.credentials.secret_key + '",'
json_string_with_temp_credentials += '"sessionToken":"' +
assumed_role_object.credentials.session_token + '"'
json_string_with_temp_credentials += '}'
# Step 4. Make request to AWS federation endpoint to get sign-in token.
Construct the parameter string with
# the sign-in action request, a 12-hour session duration, and the JSON
document with temporary credentials
# as parameters.
request_parameters = "?Action=getSigninToken"
request_parameters += "&SessionDuration=43200"
request_parameters += "&Session=" +
urllib.quote_plus(json_string_with_temp_credentials)
request_url = "https://signin.aws.amazon.com/federation" + request_parameters
r = requests.get(request_url)
# Returns a JSON document with a single element named SigninToken.
signin_token = json.loads(r.text)
# Step 5: Create URL where users can use the sign-in token to sign in to
# the console. This URL must be used within 15 minutes after the
# sign-in token was issued.
183
request_parameters = "?Action=login"
request_parameters += "&Issuer=Example.org"
request_parameters += "&Destination=" + urllib.quote_plus("https://
console.aws.amazon.com/")
request_parameters += "&SigninToken=" + signin_token["SigninToken"]
request_url = "https://signin.aws.amazon.com/federation" + request_parameters
# Send final URL to stdout
print request_url
Exemple de code utilisant Java
L'exemple suivant montre comment utiliser Java pour créer par programmation une URL qui donne aux
utilisateurs fédérés un accès direct à AWS Management Console. L'extrait de code suivant utilise le kit
AWS SDK pour Java.
import java.net.URLEncoder;
import java.net.URL;
import java.net.URLConnection;
import java.io.BufferedReader;
import java.io.InputStreamReader;
// Available at http://www.json.org/java/index.html
import org.json.JSONObject;
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient;
import com.amazonaws.services.securitytoken.model.Credentials;
import com.amazonaws.services.securitytoken.model.GetFederationTokenRequest;
import com.amazonaws.services.securitytoken.model.GetFederationTokenResult;
/* Calls to AWS STS APIs must be signed using the access key ID
and secret access key of an IAM user or using existing temporary
credentials. The credentials should not be embedded in code. For
this example, the code looks for the credentials in a
standard configuration file.
*/
AWSCredentials credentials =
new PropertiesCredentials(
AwsConsoleApp.class.getResourceAsStream("AwsCredentials.properties"));
AWSSecurityTokenServiceClient stsClient =
new AWSSecurityTokenServiceClient(credentials);
GetFederationTokenRequest getFederationTokenRequest =
new GetFederationTokenRequest();
getFederationTokenRequest.setDurationSeconds(3600);
getFederationTokenRequest.setName("UserName");
// A sample policy for accessing Amazon Simple Notification Service (Amazon
SNS) in the console.
String policy = "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Action\":
\"sns:*\"," +
"\"Effect\":\"Allow\",\"Resource\":\"*\"}]}";
getFederationTokenRequest.setPolicy(policy);
184
GetFederationTokenResult federationTokenResult =
stsClient.getFederationToken(getFederationTokenRequest);
Credentials federatedCredentials = federationTokenResult.getCredentials();
//
//
//
//
//
The issuer parameter specifies your internal sign-in
page, for example https://mysignin.internal.mycompany.com/.
The console parameter specifies the URL to the destination console of the
AWS Management Console. This example goes to Amazon SNS.
The signin parameter is the URL to send the request to.
String issuerURL = "https://mysignin.internal.mycompany.com/";
String consoleURL = "https://console.aws.amazon.com/sns";
String signInURL = "https://signin.aws.amazon.com/federation";
// Create the sign-in token using temporary credentials,
// including the access key ID, secret access key, and security token.
String sessionJson = String.format(
"{\"%1$s\":\"%2$s\",\"%3$s\":\"%4$s\",\"%5$s\":\"%6$s\"}",
"sessionId", federatedCredentials.getAccessKeyId(),
"sessionKey", federatedCredentials.getSecretAccessKey(),
"sessionToken", federatedCredentials.getSessionToken());
// Construct the sign-in request with the request sign-in token action, a
// 12-hour console session duration, and the JSON document with temporary
// credentials as parameters.
String getSigninTokenURL = signInURL +
"?Action=getSigninToken" +
"&SessionDuration=43200" +
"&SessionType=json&Session=" +
URLEncoder.encode(sessionJson,"UTF-8");
URL url = new URL(getSigninTokenURL);
// Send the request to the AWS federation endpoint to get the sign-in token
URLConnection conn = url.openConnection ();
BufferedReader bufferReader = new BufferedReader(new
InputStreamReader(conn.getInputStream()));
String returnContent = bufferReader.readLine();
String signinToken = new JSONObject(returnContent).getString("SigninToken");
String signinTokenParameter = "&SigninToken=" +
URLEncoder.encode(signinToken,"UTF-8");
// The issuer parameter is optional, but recommended. Use it to direct users
// to your sign-in page when their session expires.
String issuerParameter = "&Issuer=" + URLEncoder.encode(issuerURL, "UTF-8");
// Finally, present the completed URL for the AWS console session to the user
String destinationParameter = "&Destination=" +
URLEncoder.encode(consoleURL,"UTF-8");
String loginURL = signInURL + "?Action=login" +
185
signinTokenParameter + issuerParameter +
destinationParameter;
Exemple montrant comment créer l'URL (Ruby)
L'exemple suivant montre comment utiliser Ruby pour créer par programmation une URL qui donne
aux utilisateurs fédérés un accès direct à AWS Management Console. Cet extrait de code utilise le kit
AWS SDK pour Ruby.
require
require
require
require
require
'rubygems'
'json'
'open-uri'
'cgi'
'aws-sdk'
# Create a new AWS::STS instance.
#
# Note: Calls to AWS STS APIs must be signed using an access key ID
# and secret access key. The credentials can be in EC2 instance metadata
# or in environment variables and will be automatically discovered by
# the default credentials provider in the AWS Ruby SDK.
sts = AWS::STS.new
# The following policy grants permissions to work
# in the AWS SNS console.
policy = AWS::STS::Policy.new
policy.allow(:actions => "sns:*",:resources => :any)
# The following call creates a temporary session that returns
# temporary security credentials and a session token.
session = sts.new_federated_session(
"UserName",
:policy => policy,
:duration => 3600)
# The issuer value is the URL where users are directed (such as
# to your internal sign-in page) when their session expires.
#
# The console value specifies the URL to the destination console.
# This example goes to the Amazon SNS console.
#
# The sign-in value is the URL of the AWS STS federation endpoint.
issuer_url = "https://mysignin.internal.mycompany.com/"
console_url = "https://console.aws.amazon.com/sns"
signin_url = "https://signin.aws.amazon.com/federation"
# Create a block of JSON that contains the temporary credentials
# (including the access key ID, secret access key, and session token).
session_json = {
:sessionId => session.credentials[:access_key_id],
:sessionKey => session.credentials[:secret_access_key],
:sessionToken => session.credentials[:session_token]
}.to_json
#
#
#
#
Call the federation endpoint, passing the parameters
created earlier and the session information as a JSON block.
The request returns a sign-in token that's valid for 15 minutes.
Signing in to the console with the token creates a session
186
Création de rôles
# that is valid for 12 hours.
get_signin_token_url = signin_url +
"?Action=getSigninToken" +
"&SessionDuration=43200" +
"&SessionType=json&Session=" +
CGI.escape(session_json)
returned_content = URI.parse(get_signin_token_url).read
# Extract the sign-in token from the information returned
# by the federation endpoint.
signin_token = JSON.parse(returned_content)['SigninToken']
signin_token_param = "&SigninToken=" + CGI.escape(signin_token)
# Create the URL to give to the user, which includes the
# sign-in token and the URL of the console to open.
# The "issuer" parameter is optional but recommended.
issuer_param = "&Issuer=" + CGI.escape(issuer_url)
destination_param = "&Destination=" + CGI.escape(console_url)
login_url = signin_url + "?Action=login" + signin_token_param +
issuer_param + destination_param
Création de rôles IAM
Pour créer un rôle, vous pouvez aussi utiliser l'AWS Management Console, l'AWS CLI, l'Outils pour
Windows PowerShell ou l'API IAM.
Si vous utilisez l'AWS Management Console, un assistant vous décrit la marche à suivre pour créer un
rôle. L'assistant a des étapes légèrement différents selon que vous créez un rôle pour un service AWS,
pour un compte AWS ou pour un utilisateur fédéré.
Rubriques
• Création d'un rôle pour la délégation d'autorisations à un utilisateur IAM. (p. 187)
• Création d'un rôle pour la délégation d'autorisations à un service AWS (p. 197)
• Création d'un rôle pour un fournisseur d'identité tiers (Fédération) (p. 201)
• Exemples de stratégies pour la délégation d'accès (p. 210)
Création d'un rôle pour la délégation d'autorisations à un
utilisateur IAM.
Vous pouvez utiliser des rôles IAM pour déléguer l'accès à vos ressources AWS. Les rôles IAM
vous permettent d'établir des relations d'approbation entre votre compte d'approbation et d'autres
comptes approuvés AWS. Le compte d'approbation est propriétaire des ressources auxquelles les
utilisateurs ont accès , tandis que le compte approuvé contient les utilisateurs devant accéder aux
ressources. Une fois que vous avez créé la relation d'approbation, un utilisateur ou une application
IAM du compte approuvé peut utiliser l'action d'API AssumeRole AWS Security Token Service
(AWS STS) pour obtenir les informations d'identification de sécurité temporaires qui lui permettront
d'accéder aux ressources de votre compte AWS. Les deux comptes peuvent être contrôlés par vousmême, ou le compte contenant les utilisateurs peut être contrôlé par un tiers. Si le compte contenant
les utilisateurs se trouve dans un compte AWS que vous ne contrôlez pas, il est possible d'utiliser
l'attribut externalID et un identifiant unique fourni par le compte tiers pour s'assurer que l'accès
sera uniquement autorisé dans les contextes appropriés. Pour de plus amples informations, veuillez
consulter Procédure d'utilisation d'un ID externe lorsque vous accordez l'accès à vos ressources AWS
à un tiers (p. 193).
187
Création de rôles
Pour plus d'informations sur la façon d'utiliser les rôles pour déléguer des autorisations, consultez
Termes et concepts relatifs aux rôles (p. 140).
Rubriques
• Création d'un rôle (AWS Management Console) (p. 188)
• Création d'un rôle (AWS Command Line Interface) (p. 190)
• Création d'un rôle (Outils pour Windows PowerShell) (p. 191)
• Création d'un rôle (API AWS) (p. 192)
• Procédure d'utilisation d'un ID externe lorsque vous accordez l'accès à vos ressources AWS à un
tiers (p. 193)
Création d'un rôle (AWS Management Console)
Vous pouvez utiliser AWS Management Console pour créer un rôle vers lequel un utilisateur IAM peut
basculer.
Pour créer un rôle (AWS Management Console)
1.
2.
Dans le volet de navigation de la console, cliquez sur Roles, puis sur Create New Role.
3.
Sous Role Name, tapez un nom de rôle permettant d'identifier l'objectif du rôle. Les noms des
rôles de votre compte AWS doivent être uniques. Une fois le nom entré, cliquez sur Next Step.
Le nombre de caractères des noms de rôles est limité. Dans un compte AWS, une limite
s'applique également au nombre de rôles, ainsi qu'à la taille des stratégies attachées à ces
rôles. Pour de plus amples informations, veuillez consulter Limitations des entités et objets
IAM (p. 391). Notez qu'il n'est pas possible de modifier le nom du rôle après sa création.
Important
Les noms des rôles doivent être uniques dans un compte. La casse majusculesminuscules ne compte pas. Par exemple, vous ne pouvez pas créer des rôles nommés
« PRODROLE » et « prodrole ».
4.
Sur la page Select Role Type, sélectionnez la section Role for Cross-Account Access , puis
choisissez le type de rôle que vous souhaitez créer :
• Sélectionnez Provide access between AWS accounts you own si vous êtes l'administrateur
du compte utilisateur et du compte de ressources, ou si les deux comptes appartiennent à la
même organisation. C'est également l'option à sélectionner lorsque les utilisateurs, le rôle et les
ressources auxquels l'accès est requis se trouvent tous dans le même compte.
• Sélectionnez Allows IAM users from a 3rd party AWS account to access this account si vous
êtes l'administrateur du compte propriétaire des ressources et que vous voulez accorder des
autorisations aux utilisateurs d'un compte que vous ne contrôlez pas. Cette option requiert
la spécification d'un ID externe (que le tiers doit vous fournir) afin de fournir un contrôle
supplémentaire sur les circonstances dans lesquelles le tiers peut utiliser le rôle pour accéder à
vos ressources. Pour de plus amples informations, veuillez consulter Procédure d'utilisation d'un
ID externe lorsque vous accordez l'accès à vos ressources AWS à un tiers (p. 193).
Important
La sélection de cette option autorise l'accès au rôle uniquement par le biais de l'AWS
CLI, de Outils pour Windows PowerShell ou de l'API AWS. Cela est dû au fait que
vous ne pouvez pas utiliser la console AWS pour assumer un rôle dont la stratégie
d'approbation comporte une condition externalID. Vous pouvez néanmoins créer ce
188
Création de rôles
type d'accès par programmation, en écrivant un script ou une application à l'aide du
kit SDK approprié. Pour plus d'informations et un exemple de script, consultez How to
Enable Cross-Account Access to the AWS Management Console dans le Blog sur la
sécurité AWS.
5.
Sur la page suivante, spécifiez l'ID de compte AWS auquel vous voulez accorder l'accès à vos
ressources.
L'administrateur du compte approuvé spécifié peut accorder l'autorisation d'assumer ce rôle
à n'importe quel utilisateur IAM du compte approuvé. Pour ce faire, l'administrateur attache à
l'utilisateur ou à un groupe une stratégie qui accorde l'autorisation pour l'action sts:AssumeRole
et qui spécifie l'ARN du rôle comme Resource.
6.
Si vous avez sélectionné Allows IAM users from a 3rd party AWS account to access this account
sur la page Select Role Type, tapez l'ID externe fourni par l'administrateur du compte tiers.
Cela ajoute automatiquement une condition à la stratégie d'approbation. Cette condition permet
à l'utilisateur d'assumer le rôle uniquement si la demande inclut l'élément sts:ExternalID
approprié. Pour de plus amples informations, veuillez consulter Procédure d'utilisation d'un ID
externe lorsque vous accordez l'accès à vos ressources AWS à un tiers (p. 193).
7.
Si vous souhaitez restreindre le rôle aux utilisateurs qui se connectent via un appareil MFA,
sélectionnez l'option Require MFA. Cela ajoute une condition à la stratégie d'approbation du rôle
qui exige une authentification MFA. Un utilisateur qui veut assumer le rôle doit se connecter avec
un mot de passe unique temporaire à partir d'un appareil MFA configuré. Sans authentification
MFA, les utilisateurs ne peuvent pas assumer le rôle. Pour plus d'informations sur l'authentification
MFA, consultez Utilisation de Multi-Factor Authentication (MFA) dans AWS (p. 93)
8.
Cliquez sur Next Step.
9.
Sur la page Attach Policy, sélectionnez une ou plusieurs stratégies d'autorisation à attacher
au rôle pour spécifier les actions qui peuvent être effectuées sur des ressources spécifiques
(similaire à la définition d'autorisations pour les groupes IAM). Pour plus d'informations sur la
gestion des autorisations à l'aide de stratégies, consultez Présentation des autorisations d'AWS
IAM (p. 281).
Les autorisations que vous spécifiez sont disponibles à toutes les entités qui utilisent le rôle. Par
défaut, un rôle ne dispose d'aucune autorisation.
Activez la case à cocher en regard de la stratégie qui affecte les autorisations que vous voulez
octroyer aux utilisateurs, puis cliquez sur Attach Policy. Vous pouvez choisir de ne sélectionner
aucune stratégie pour le moment, mais de créer les stratégies plus tard et de les attacher au rôle.
10. Cliquez sur Next Step pour vérifier les paramètres du rôle. Notez le lien fourni afin de le donner
aux utilisateurs autorisés à utiliser le rôle. Lorsque l'utilisateur clique sur ce lien, il accède
directement à la page Switch Role sur laquelle les champs Account ID et Role Name sont déjà
renseignés. L'utilisateur doit fournir des informations d'identification s'il n'est pas déjà connecté.
Il peut éventuellement définir un nom complet (Display Name) et sélectionner une couleur
d'affichage (Display Color). Lorsque l'utilisateur clique sur Switch Role, il dispose immédiatement
des nouvelles autorisations.
Note
La console IAM met en cache les cinq derniers rôles que vous utilisez afin de faciliter
leur sélection ultérieurement. Si vos utilisateurs requièrent plus de cinq rôles, envisagez
d'utiliser les solutions suivantes pour faciliter l'accès :
• Si seuls quelques utilisateurs changent de rôle, suggérez-leur de créer un marque-page
pour les liens que vous leur envoyez.
• Si de nombreux utilisateurs changent de rôle, envisagez de créer un emplacement
central tel qu'une page web contenant tous les liens nécessaires aux utilisateurs.
Le format du lien est le suivant :
189
Création de rôles
account=ACCOUNT_NUMBER&roleName=ROLE_NAME&displayName=DISPLAYNAME
11. Cliquez sur Create Role pour terminer la création du rôle.
Important
N'oubliez pas que ceci ne représente que la première moitié de la configuration requise.
Vous devez également accorder à des utilisateurs individuels du compte approuvé les
autorisations leur permettant de changer de rôle. Pour plus d'informations sur cette étape,
consultez Octroi d'autorisations à un utilisateur pour assumer un rôle (p. 215).
Une fois que vous avez créé le rôle et que vous lui avez accordé des autorisations pour effectuer des
tâches AWS ou accéder aux ressources AWS, l'utilisateur peut changer de rôle. Pour de plus amples
informations, veuillez consulter Assumer un rôle (AWS Management Console) (p. 219).
Création d'un rôle (AWS Command Line Interface)
La création d'un rôle à partir de l'AWS CLI comporte plusieurs étapes. Lorsque vous créez un rôle à
partir de la console, la plupart des étapes sont exécutées automatiquement pour vous. En revanche,
lors de l'utilisation de l'AWS CLI, vous devez exécuter explicitement chaque étape vous-même. Vous
devez créer la stratégie et affecter une stratégie d'autorisation au rôle.
Pour créer un rôle pour l'accès entre comptes (AWS CLI)
Utilisez les commandes suivantes :
• Créer un rôle : aws iam create-role
• Attacher une stratégie d'accès gérée au rôle : aws iam attach-role-policy
-ouCréer une stratégie d'accès en ligne pour le rôle : aws iam put-role-policy
L'exemple suivant illustre les deux étapes dans un environnement simple. L'exemple suppose que
vous utilisez un ordinateur client qui exécute Windows et que vous avez déjà configuré votre interface
de ligne de commande à l'aide des informations d'identification et de la région de votre compte. Pour
plus d'informations, consultez Configuration de l'interface de ligne de commande AWS.
L'exemple de stratégie d'approbation référencé dans la première commande contient le code JSON
suivant pour permettre aux utilisateurs du compte 123456789012 d'assumer le rôle , mais uniquement
si l'utilisateur fournit l'authentification MFA. Pour plus d'informations sur l'authentification MFA,
consultez Utilisation de Multi-Factor Authentication (MFA) dans AWS (p. 93).
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
}
}
La stratégie gérée référencée dans la deuxième commande est supposée exister déjà dans IAM ;
elle permet à l'utilisateur qui assume le rôle d'effectuer uniquement l'action ListBucket sur un
compartiment S3 nommé example_bucket. Voici ce à quoi la stratégie devrait ressembler :
190
Création de rôles
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::example_bucket"
}
}
Exécutez les commandes suivantes :
# Create the role and attach the trust policy that allows users in an account
to switch to the role.
aws iam create-role --role-name Test-UserAccess-Role --assume-role-policydocument file://C:\policies\trustpolicyforacct123456789012.json
# Attach the permissions policy (in this example a managed policy) to the
role to specify what it is allowed to do.
aws iam attach-role-policy --role-name Test-UserAccess-Role --policy-arn
arn:aws:iam::123456789012:role/PolicyForRole
Important
N'oubliez pas que ceci ne représente que la première moitié de la configuration requise. Vous
devez également accorder à des utilisateurs individuels du compte approuvé les autorisations
leur permettant de changer de rôle. Pour plus d'informations sur cette étape, consultez Octroi
d'autorisations à un utilisateur pour assumer un rôle (p. 215).
informations, veuillez consulter Passer à un rôle IAM (AWS Command Line Interface) (p. 221).
Création d'un rôle (Outils pour Windows PowerShell)
La création d'un rôle à l'aide de Outils pour Windows PowerShell comporte plusieurs étapes. Lorsque
vous créez un rôle à partir de la console, la plupart des étapes sont exécutées automatiquement pour
vous. En revanche, lors de l'utilisation des applets de commande Windows PowerShell, vous devez
exécuter explicitement chaque étape vous-même. Vous devez créer la stratégie, puis affecter une
stratégie d'accès au rôle.
Pour créer un rôle pour l'accès entre comptes (Outils pour Windows PowerShell)
• Créer un rôle : New-IAMRole
• Attacher une stratégie d'accès gérée au rôle : Register-IAMRolePolicy
-ouCréer une stratégie d'accès en ligne pour le rôle : Write-IAMRolePolicy
L'exemple suivant illustre les deux étapes dans un environnement simple. L'exemple suppose que
vous avez déjà configuré Outils pour Windows PowerShell à l'aide des informations d'identification et
de la région du compte. Pour plus d'informations, consultez Utilisation d'informations d'identification
AWS dans le manuel Outils AWS pour Windows PowerShell Guide de l'utilisateur.
191
Création de rôles
L'exemple de fichier de stratégie d'approbation référencé dans la première commande contient le
code JSON suivant pour permettre aux utilisateurs du compte 123456789012 d'assumer le rôle, mais
uniquement s'ils utilisent l'authentification MFA. Pour plus d'informations sur l'authentification MFA,
consultez Utilisation de Multi-Factor Authentication (MFA) dans AWS (p. 93).
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
}
}
La stratégie gérée référencée dans la deuxième commande est supposée exister déjà dans IAM ;
elle permet à l'utilisateur qui assume le rôle d'effectuer uniquement l'action ListBucket sur un
compartiment S3 nommé example_bucket. Voici ce à quoi la stratégie devrait ressembler :
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
}
}
# Create the role and attach the trust policy that allows users in an account
to switch to the role.
New-IAMRole -RoleName Test-UserAccess-Role -AssumeRolePolicyDocument (GetContent -raw C:\policies\trustpolicyforacct123456789012.json)
# Attach the permissions policy (in this example a managed policy) to the
Register-IAMRolePolicy -RoleName Test-UserAccess-Role --policy-arn
arn:aws:iam::123456789012:role/PolicyForRole
Important
informations, veuillez consulter Passer à un rôle IAM (Outils pour Windows PowerShell) (p. 223).
Création d'un rôle (API AWS)
Vous pouvez utiliser des appels d'API pour créer un rôle vers lequel un utilisateur IAM peut basculer.
Pour créer un rôle dans le code à l'aide de l'API
192
Création de rôles
• Créer un rôle : CreateRole
Vous pouvez spécifier un emplacement de fichier pour la stratégie d'approbation du rôle.
• Attacher une stratégie d'accès gérée au rôle :: AttachRolePolicy
-ouCréer une stratégie d'accès en ligne pour le rôle : PutRolePolicy
Important
informations, veuillez consulter Assumer un rôle IAM (API) (p. 225).
Pour plus d'informations sur l'authentification MFA, consultez Utilisation de Multi-Factor Authentication
(MFA) dans AWS (p. 93).
Procédure d'utilisation d'un ID externe lorsque vous accordez l'accès à vos
ressources AWS à un tiers
Parfois, vous devez accorder à des tiers l'accès à vos ressources AWS (déléguer l'accès). Un aspect
important de ce scénario est l'ID externe, élément d'information facultatif que vous pouvez utiliser dans
une stratégie d'approbation de rôle IAM afin de désigner l'utilisateur autorisé à assumer le rôle.
Par exemple, disons que vous décidez d'embaucher une entreprise tierce appelée Example Corp
pour surveiller votre compte AWS et vous aider à optimiser les coûts. Pour effectuer le suivi de vos
dépenses quotidiennes, Example Corp doit accéder à vos ressources AWS. Example Corp surveille
également de nombreux autres comptes AWS pour d'autres clients.
Bien que vous puissiez accorder à Example Corp l'accès à un utilisateur IAM et à ses informations
d'identification à long terme dans votre compte AWS, de vous devriez plutôt choisir d'adopter la bonne
pratique vivement recommandée qui consiste à utiliser un rôle IAM. Un rôle IAM fournit un mécanisme
visant à autoriser un tiers à accéder à vos ressources AWS sans avoir besoin de communiquer vos
informations d'identification à long terme (par exemple, une clé d'accès IAM d'utilisateur).
Le rôle IAM permet d'établir une relation de confiance entre votre compte AWS et le compte
appartenant à Example Corp. Une fois cette relation établie, l'un des utilisateurs IAM ou l'une des
applications d'Example Corp dans le compte AWS approuvé peut appeler l'API AssumeRole AWS
STS pour obtenir des informations d'identification temporaires qui peuvent ensuite servir à accéder aux
ressources AWS de votre compte.
Note
Pour plus d'informations sur AssumeRole et d'autres API AWS que vous pouvez appeler
pour obtenir des informations d'identification temporaires, consultez Obtention d'informations
d'identification temporaires de sécurité (p. 246).
Voici comment s'articule ce scénario :
193
Création de rôles
1. Vous embauchez Example Corp qui crée un identifiant client unique pour vous. Ils vous fournissent
votre ID client unique et leur numéro de compte AWS. Vous avez besoin de ces informations pour
créer un rôle IAM à l'étape suivante.
Note
Exemple Corp peut utiliser n'importe quelle valeur de chaîne pour l'ExternalId, tant qu'elle
est unique pour chaque client. Il peut s'agir d'un numéro de compte client ou encore d'une
chaîne aléatoire de caractères, à condition que chaque client ait une valeur différente. Elle
n'est pas censée être « secrète ». Example Corp doit fournir la valeur ExternalId à chaque
client. Ce qui compte c'est qu'elle soit générée par Example Corp et non par ses clients.
2. Vous vous connectez à AWS et vous créez un rôle IAM qui accorde à Example Corp l'accès à vos
ressources. Comme tout autre rôle IAM, celui-ci dispose de deux stratégies, une stratégie d'accès
et une stratégie d'approbation. La stratégie d'approbation du rôle spécifie qui peut assumer le
rôle. Dans notre exemple de scénario, la stratégie spécifie le numéro de compte AWS d'Example
Corp comme Principal. Cela permet aux identités de ce compte d'assumer le rôle. De plus,
vous ajoutez un élément Condition à la stratégie d'approbation qui teste la clé de contexte
ExternalID pour vérifier qu'elle correspond à l'ID client unique que Example Corp vous a affecté
lorsque vous l'avez embauchée. Exemples :
"Principal": {"AWS": "Example Corp's AWS Account ID"},
"Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by
Example Corp"}}
3. La stratégie d'accès du rôle spécifie ce que le rôle permet à un utilisateur de faire. Par exemple,
vous pouvez spécifier que le rôle permet à un utilisateur de gérer uniquement vos ressources
Amazon EC2 et Amazon RDS, mais pas vos utilisateurs ou groupes IAM. Dans notre exemple de
scénario, vous utilisez la stratégie d'accès pour accorder à Example Corp un accès en lecture seule
à toutes les ressources de votre compte.
4. Après avoir créé le rôle, vous devez fournir l'Amazon Resource Name (ARN) du rôle à Example
Corp.
5. Lorsque Example Corp doit accéder à vo ressources AWS, quelqu'un de l'entreprise appelle l'API
AWS sts:AssumeRole. L'appel inclut l'ARN du rôle à assumer et le paramètre ExternalID qui
correspond à votre ID client.
Tout ceci a pour résultat que la demande est autorisée uniquement si l'ARN et l'ID externe du rôle
sont corrects, et si la demande émane d'une personne utilisant le compte AWS d'Example Corp. Si
la demande réussit, elle fournit des informations d'identification de sécurité temporaires que Example
Corp peut utiliser pour accéder aux ressources AWS autorisées par votre rôle.
Autrement dit, quand une stratégie de rôle inclut un ID externe, tous ceux qui souhaitent assumer le
rôle doivent non seulement être spécifiés comme mandataires dans le rôle, mais doivent également
inclure l'ID externe correct.
Pourquoi utiliser un ID externe ?
De manière abstraite, l'ID externe autorise l'utilisateur qui assume le rôle d'indiquer les circonstances
dans lesquels il travaille. Il permet également au titulaire du compte d'autoriser que le rôle soit assumé
uniquement dans des circonstances spécifiques. La fonction principale de l'ID externe consiste à traiter
et à prévenir le problème du « député confus ».
Le problème du député confus
Pour continuer avec l'exemple précédent, Example Corp a besoin d'accéder à certaines ressources de
votre compte AWS. Mais, en plus de vous, Example Corp a d'autres clients et doit trouver un moyen
d'accéder aux ressources AWS de chaque client. Plutôt que demander à ses clients leurs clés d'accès
au compte AWS, qui sont des secrets à ne jamais révéler, Example Corp demande un ARN de rôle à
194
Création de rôles
chacun de ses clients. Mais si un autre client d'Example Corp est capable de deviner ou d'obtenir votre
ARN de rôle, il pourra utiliser celui-ci pour accéder à vos ressources AWS par le biais d'Example Corp.
Cette forme d'escalade des privilèges est appelée le « problème du député confus ».
Le graphique suivant illustre le problème du député confus.
Ce diagramme suppose ce qui suit :
• AWS1 est votre compte AWS.
• AWS1:ExampleRole est un rôle de votre compte. La stratégie d'approbation du rôle approuve
Example Corp en désignant le compte AWS d'Example Corp comme celui qui peut assumer le rôle.
Voici ce qui se produit :
1. Lorsque vous commencez à utiliser le service d'Example Corp, vous fournissez l'ARN de
AWS1:ExampleRole à Example Corp.
2. Example Corp utilise cet ARN de rôle pour obtenir des informations d'identification de sécurité
temporaires pour accéder aux ressources de votre compte AWS. Ainsi, vous approuvez Example
Corp en tant que « député » autorisé à agir pour votre compte.
3. Un autre client AWS commence également à utiliser les services d'Example Corp et ce client fournit
également l'ARN de AWS1:ExampleRole pour que Example Corp l'utilise. Supposons que l'autre
client apprenne ou devine AWS1:ExampleRole, qui n'est pas secret.
4. Lorsque l'autre client demande à Example Corp d'accéder aux ressources AWS de (ce qu'il prétend
être) son compte, Example Corp utilise AWS1:ExampleRole pour accéder aux ressources de votre
compte
C'est ainsi que l'autre client peut obtenir un accès non autorisé à vos ressources. Du fait que cet
autre client a été en mesure de tromper Example Corp pour agir involontairement sur vos ressources,
Example Corp est à présent un « député confus ».
Comment l'ID externe empêche-t-il le problème du député confus ?
Pour traiter le problème du député confus, vous incluez le contrôle de la condition ExternalID dans
la stratégie d'approbation du rôle. L'entreprise « député » insert la valeur d'un ID externe unique
pour chaque client dans la demande informations d'identification AWS. L'ID externe est une valeur
d'ID client qui doit être unique pour chaque client d'Example Corp et être hors de portée des clients
d'Example Corp. C'est pourquoi vous l'obtenez d'Example Corp et que vous ne créez pas le vôtre. Cela
permet d'empêcher un client d'usurper l'identité d'un autre client. Example Corp insère toujours l'ID
externe affecté au client, afin que vous ne receviez jamais de demande d'Example Corp avec un ID
externe autre que le vôtre.
Dans notre scénario, imaginez que l'identifiant unique d'Example Corp pour vous soit « 12345 », et
que son identifiant pour l'autre client soit « 67890 ». Ces identifiants sont simplifiés pour ce scénario.
En général, ces identifiants sont des GUID. Supposons que ces identifiants sont uniques pour chaque
client d'Example Corp, ils constituent des valeurs sensibles à utiliser pour l'ID externe.
195
Création de rôles
Example Corp vous attribue la valeur d'ID externe « 12345 ». Vous devez ensuite ajouter un élément
Condition à la stratégie d'approbation du rôle qui nécessite que la valeur de sts:ExternalID soit
12345, comme suit :
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"AWS": "Example Corp's AWS Account ID"},
"Condition": {"StringEquals": {"sts:ExternalId": "12345"}}
}
}
L'élément Condition de cette stratégie autorise Example Corp à assumer le rôle uniquement si l'appel
d'API AssumeRole inclut la valeur d'ID externe « 12345 ». Example Corp s'assure que chaque fois
qu'elle assume un rôle pour le compte d'un client, elle inclut toujours la valeur d'ID externe de ce client
dans l'appel AssumeRole. Comme le montre le diagramme suivant, même si un autre client fournit à
Example Corp votre ARN, celui-ci ne peut pas contrôler l'ID externe que Example Corp inclut dans sa
demande à AWS. Cela permet d'éviter qu'un client non autorisé obtienne l'accès à vos ressources :
1. Comme précédemment, lorsque vous commencez à utiliser le service d'Example Corp, vous
fournissez l'ARN de AWS1:ExampleRole à Example Corp.
2. Lorsque Example Corp utilise cet ARN de rôle pour assumer le rôle AWS1:ExampleRole, Example
Corp inclut votre ID externe (« 12345 ») dans l'appel d'API AssumeRole. Cet ID externe correspond
à la stratégie d'approbation du rôle, afin que l'appel d'API AssumeRole et Example Corp obtiennent
des informations d'identification de sécurité temporaires permettant d'accéder aux ressources de
votre compte AWS.
3. Un autre client AWS commence également à utiliser les services d'Example Corp et, comme
précédemment, ce client fournit également l'ARN de AWS1:ExampleRole pour que Example Corp
l'utilise.
4. Mais cette fois, quand Example Corp tente d'assumer le rôle AWS1:ExampleRole, elle fournit
l'ID externe associé à l'autre client (« 67890 ») et l'autre client est dans l'impossibilité de changer
cela. Example Corp procède ainsi, car la demande pour utiliser le rôle provient de l'autre client,
« 67890 » indique donc les circonstances dans lesquelles Example Corp agit. Du fait que vous
avez ajouté une condition avec votre propre ID externe (« 12345 ») à la stratégie approbation de
AWS1:ExampleRole, l'appel de l'API AssumeRole échoue, et l'autre client n'a pas l'autorisation
d'accéder aux ressources de votre compte (indiqué par la croix « X » rouge dans le diagramme).
L'ID externe permet empêcher tout autre client de tromper Example Corp pour accéder
involontairement à vos ressources : cela résout le problème de « député confus ».
Quand dois-je utiliser l'ID externe ?
Utilisez un ID externe dans les situations suivantes :
196
Création de rôles
• Si vous êtes le titulaire d'un compte AWS et que vous avez configuré un rôle pour qu'un tiers accède
à d'autres comptes AWS en plus du vôtre, demandez à ce tiers un ID externe qu'il inclut quand
il assume votre rôle. Ensuite, vous recherchez cet ID externe dans la stratégie d'approbation de
votre rôle pur vous assurer que le tiers peut assumer votre rôle uniquement lorsqu'il agit pour votre
compte.
• Si vous êtres en mesure d'assumer des rôles pour le compte de différents clients comme Example
Corp dans notre scénario précédent, vous devez affecter un ID externe unique à chacun de vos
clients et leur donner pour instruction d'ajouter l'ID externe à la stratégie d'approbation de leur rôle.
Vous devez ensuite vous assurer de toujours inclure l'ID externe correct dans vos demandes pour
assumer des rôles.
Vous disposez probablement déjà d'un identifiant unique pour chacun de vos clients, et cet ID
unique est suffisant pour être utilisé comme ID externe. L'ID externe n'est pas une valeur spéciale
que vous devez créer de manière explicite, ou suivre séparément, juste à cette fin.
Vous devez toujours spécifier l'ID externe dans vos appels d'API AssumeRole. De plus, lorsqu'un
client vous fournit un ARN de rôle, vérifiez que vous pouvez assumer le rôle avec et sans l'ID
externe correct. Si vous ne pouvez pas assumer le rôle sans l'ID externe correct, ne stockez pas
l'ARN du rôle du client dans votre système tant que votre client n'a pas mis à jour la stratégie
d'approbation du rôle pour demander l'ID externe correct. Ainsi, vous aidez vos clients à faire ce qu'il
faut, ce qui vous permet de vous protéger tous les deux contre le problème du député confus.
Création d'un rôle pour la délégation d'autorisations à un
service AWS
Vous créez un rôle pour un service AWS lorsque vous souhaitez accorder des autorisations à un
service tel qu'Amazon EC2, AWS Data Pipeline, Amazon Elastic Transcoder ou AWS OpsWorks. Ces
services peuvent accéder aux ressources AWS et, par conséquent, vous créez un rôle pour déterminer
la façon dont ils utilisent ces ressources. Dans de nombreux scénarios, vous pouvez sélectionner une
stratégie gérée par AWS qui contient déjà des autorisations prédéfinies. Toutefois, si certaines de vos
exigences ne sont pas prises en compte par une stratégie gérée par AWS, il est possible de créer une
stratégie gérée personnalisée ou de commencer avec la copie d'une stratégie gérée par AWS.
Pour plus d'informations sur la façon dont les rôles vous permettent de déléguer des autorisations,
consultez Termes et concepts relatifs aux rôles (p. 140).
Rubriques
• Création d'un rôle pour un service AWS (AWS Management Console) (p. 197)
• Création d'un rôle pour un service (AWS Command Line Interface) (p. 198)
• Création d'un rôle pour un service (Outils pour Windows PowerShell) (p. 199)
• Création d'un rôle pour un service (API AWS) (p. 201)
Création d'un rôle pour un service AWS (AWS Management Console)
Vous pouvez utiliser AWS Management Console pour créer un rôle IAM pour un service.
Pour créer un rôle pour un service AWS à l'aide de la console AWS
1.
2.
Dans le volet de navigation de la console IAM, cliquez sur Roles, puis sur Create New Role.
3.
Sous Role Name, tapez un nom de rôle permettant d'identifier l'objectif de ce rôle. Les noms des
rôles de votre compte AWS doivent être uniques. Après avoir tapé le nom, cliquez sur Next Step
au bas de la page.
197
Création de rôles
Différentes entités peuvent référencer le rôle et il n'est donc pas possible de modifier son nom
après sa création.
Important
4.
Développez la section AWS Service Roles, puis sélectionnez le service que vous voulez autoriser
à assumer ce rôle.
5.
Activez la case à cocher d'une stratégie gérée qui accorde les autorisations que vous voulez
octroyer au service. Si la stratégie n'existe pas encore, vous pouvez ignorer cette étape, créer la
stratégie ultérieurement, puis l'attacher au rôle.
6.
Cliquez sur Next Step pour vérifier le rôle. Ensuite, cliquez sur Create Role.
Création d'un rôle pour un service (AWS Command Line Interface)
lors de l'utilisation de l'AWS CLI, vous devez exécuter explicitement chaque étape vous-même. Vous
devez créer la stratégie, puis affecter une stratégie d'accès au rôle. Si le service concerné est Amazon
EC2 vous devez également créer un profil d'instance et lui ajouter le rôle.
Pour créer un rôle pour un service AWS à partir de l'AWS CLI, utilisez les commandes suivantes :
• Créer un rôle : aws iam create-role
• Attacher une stratégie d'accès gérée au rôle : aws iam attach-role-policy
ou
Créer une stratégie d'accès en ligne pour le rôle : aws iam put-role-policy
Si vous envisagez d'utiliser le rôle avec Amazon EC2 ou un autre service AWS qui utilise Amazon
EC2, vous devez stocker le rôle dans un profil d'instance. Un profil d'instance est un conteneur
pour un rôle que vous pouvez attacher à une instance Amazon EC2 lorsqu'elle est lancée. Un profil
d'instance ne peut contenir qu'un seul rôle. Si vous créez le rôle avec AWS Management Console,
le profil d'instance est créé pour vous et il a même nom que le rôle. Pour plus d'informations sur les
profils d'instance, consultez Utilisation de profils d'instance (p. 231). Pour plus d'informations sur
le lancement d'une instance EC2 avec un rôle, consultez Utilisation de rôles IAM avec les instances
Amazon EC2 dans le manuel Amazon EC2 Guide de l'utilisateur pour les instances Linux.
Pour créer un profil d'instance et lui ajouter un rôle à partir de l'AWS CLI, utilisez les commandes
suivantes :
• Créer un profil d'instance : aws iam create-instance-profile
• Ajouter le rôle au profil d'instance : aws iam add-role-to-instance-profile
L'exemple suivant illustre les quatre étapes. L'exemple suppose que vous utilisez un ordinateur client
qui exécute Windows et que vous avez déjà configuré votre interface de ligne de commande à l'aide
des informations d'identification et de la région de votre compte. Pour plus d'informations, consultez
Configuration de l'interface de ligne de commande AWS.
suivant pour permettre au service Amazon EC2 d'assumer le rôle.
198
Création de rôles
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Service": "ec2.amazonaws.com"},
"Action": "sts:AssumeRole"
}
}
L'exemple de stratégie d'accès référencé dans la deuxième commande permet au rôle d'effectuer
uniquement l'action ListBucket sur un compartiment S3 nommé example_bucket.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
}
}
Les commandes de l'AWS CLI pour l'exécution de cet exemple sont les suivantes :
# Create the role and attach the trust policy that enables EC2 to assume this
role.
aws iam create-role --role-name Test-Role-for-EC2 --assume-role-policydocument file://C:\policies\trustpolicyforec2.json
# Embed the permissions policy (in this example an inline policy) to the role
to specify what it is allowed to do.
aws iam put-role-policy --role-name Test-Role-for-EC2 --policy-name
Permissions-Policy-For-Ec2 --policy-document file://c:\policies
\permissionspolicyforec2.json
# Create the instance profile required by EC2 to contain the role
aws iam create-instance-profile --instance-profile-name EC2-ListBucket-S3
# Finally, add the role to the instance profile
aws iam add-role-to-instance-profile --instance-profile-name EC2-ListBucketS3 --role-name Test-Role-for-EC2
Lorsque vous lancez l'instance EC2, spécifiez le nom de profil d'instance dans la page Configure
Instance Details si vous utilisez la console AWS, ou le paramètre --iam-instance-profile si vous
utilisez la commande d'interface de ligne de commande aws ec2 run-instances.
Création d'un rôle pour un service (Outils pour Windows PowerShell)
La création d'un rôle à l'aide des Outils pour Windows PowerShell comporte plusieurs étapes. Lorsque
vous. En revanche, lors de l'utilisation des applets de commande Windows PowerShell, vous devez
exécuter explicitement chaque étape vous-même. Vous devez créer la stratégie, puis affecter une
stratégie d'accès au rôle. Si le service concerné est Amazon EC2 vous devez également créer un profil
d'instance et lui ajouter le rôle.
Pour créer un rôle pour un service AWS à partir des Outils pour Windows PowerShell, utilisez les
commandes suivantes :
199
Création de rôles
• Créer un rôle : New-IAMRole
• Attacher une stratégie d'accès gérée au rôle : Register-IAMRolePolicy
ou
Créer une stratégie d'accès en ligne pour le rôle : Write-IAMRolePolicy
EC2, vous devez stocker le rôle dans un profil d'instance. Un profil d'instance est un conteneur
pour un rôle. Un profil d'instance ne peut contenir qu'un seul rôle. Si vous créez le rôle dans AWS
Management Console, le profil d'instance est créé pour vous et il a le même nom que le rôle. Pour plus
d'informations sur les profils d'instance, consultez Utilisation de profils d'instance (p. 231). Pour plus
d'informations sur le lancement d'une instance EC2 avec un rôle, consultez Utilisation de rôles IAM
avec les instances Amazon EC2 dans le manuel Amazon EC2 Guide de l'utilisateur pour les instances
Linux.
• Créer un profil d'instance : New-IAMInstanceProfile
• Ajouter le rôle au profil d'instance : Add-IAMRoleToInstanceProfile
L'exemple suivant illustre les quatre étapes. L'exemple suppose que vous utilisez un ordinateur client
qui exécute Windows et que vous avez déjà configuré votre interface de ligne de commande à l'aide
des informations d'identification et de la région de votre compte. Pour plus d'informations, consultez
Utilisation d'informations d'identification AWS dans le manuel Outils AWS pour Windows PowerShell
Guide de l'utilisateur.
suivant pour permettre au service Amazon EC2 d'assumer le rôle.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Service": "ec2.amazonaws.com"},
}
}
L'exemple de stratégie d'accès référencé dans la deuxième commande permet au rôle d'effectuer
uniquement l'action ListBucket sur un compartiment S3 nommé example_bucket.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
}
}
Les commandes des Outils pour Windows PowerShell pour l'exécution de cet exemple sont les
suivantes :
# Create the role and attach the trust policy that enables EC2 to assume this
role.
200
Création de rôles
New-IAMRole -RoleName Test-Role-for-EC2 -AssumeRolePolicyDocument (GetContent -raw C:\policies\trustpolicyforec2.json)
# Create an permissions policy (in this example an inline policy) for the
Write-IAMRolePolicy -RoleName Test-Role-for-EC2 -PolicyName PermissionsPolicy-For-Ec2 -PolicyDocument (Get-Content -raw c:\policies
\permissionspolicyforec2.json)
# The following two lines are only needed when the role is for the EC2
service
# Create the instance profile required by EC2 to contain the role
New-IAMInstanceProfile -InstanceProfileName EC2-ListBucket-S3
# Finally, add the role to the instance profile
Add-IAMRoleToInstanceProfile -InstanceProfileName EC2-ListBucket-S3 -RoleName
Test-Role-for-EC2
Lors que vous lancez l'instance EC2, spécifiez le nom de profil d'instance dans la page Configure
Instance Details si vous utilisez la console AWS, ou le paramètre -InstanceProfile_Name ou InstanceProfile_Arn si vous utilisez le cmdlet Windows PowerShell New-EC2Instance.
Création d'un rôle pour un service (API AWS)
Pour créer un rôle dans le code qui utilise l'API, utilisez les commandes suivantes.
• Créer un rôle : CreateRole
Vous pouvez spécifier un emplacement de fichier pour la stratégie d'approbation du rôle.
• Attacher une stratégie d'accès gérée au rôle : AttachRolePolicy
ou
Créer une stratégie d'accès en ligne pour le rôle : PutRolePolicy
EC2, vous devez stocker le rôle dans un profil d'instance. Un profil d'instance est un conteneur pour
un rôle. Chaque profil d'instance ne peut contenir qu'un seul rôle. Si vous créez le rôle dans AWS
Management Console, le profil d'instance est créé pour vous et il a le même nom que le rôle. Pour
plus d'informations sur les profils d'instance, consultez Utilisation de profils d'instance (p. 231). Pour
plus d'informations sur le lancement d'une instance Amazon EC2 avec un rôle, consultez Utilisation de
rôles IAM avec les instances Amazon EC2 dans le manuel Amazon EC2 Guide de l'utilisateur pour les
instances Linux.
• Créer un profil d'instance : CreateInstanceProfile
• Ajouter le rôle au profil d'instance : AddRoleToInstanceProfile
Création d'un rôle pour un fournisseur d'identité tiers
(Fédération)
La fédération d'identité permet aux utilisateurs d'accéder aux ressources AWS par le biais d'un
fournisseur d'identité tiers (IdP). Pour configurer la fédération d'identité, vous configurez le fournisseur,
puis créez un rôle IAM qui détermine les autorisations dont disposera un utilisateur fédéré. Pour plus
d'informations sur la fédération et les fournisseurs d'identité, consultez Fournisseurs d'identité et
fédération (p. 148).
201
Création de rôles
Création d'un rôle pour les utilisateurs fédérés (AWS Management Console)
La procédure à suivre pour créer un rôle pour les utilisateurs fédérés varie en fonction des fournisseurs
tiers sélectionnés :
• Pour créer un rôle pour des utilisateurs fédérés avec un fournisseur d'identité web ou
OpenID Connect (OIDC), consultez Création d'un rôle pour la fédération d'identité web ou OpenID
Connect (AWS Management Console) (p. 204).
• Pour créer un rôle pour des utilisateurs fédérés avec un fournisseur d'identité SAML 2.0, consultez
Création d'un rôle pour la fédération SAML 2.0 (AWS Management Console) (p. 208).
Création d'un rôle pour l'accès fédéré (AWS Command Line Interface)
La procédure à suivre pour la création d'un rôle pour les fournisseurs d'identité pris en charge (OIDC
ou SAML) à partir de l'AWS CLI est identique ; la différence porte sur le contenu de la stratégie
d'approbation que vous créez dans les étapes requises. Commencez par suivre les étapes de la
section Prérequis pour le type de fournisseur que vous utilisez :
• Pour un fournisseur OIDC, suivez les étapes de la section Prérequis pour un fournisseur
OIDC (p. 204).
• Pour un fournisseur SAML, suivez les étapes de la section Prérequis pour un fournisseur
SAML (p. 208).
lors de l'utilisation de l'interface de ligne de commande, vous devez exécuter explicitement chaque
étape vous-même. Vous devez commencer par créer la stratégie d'approbation et le rôle, puis affecter
une stratégie d'accès au rôle.
Pour créer un rôle à l'aide de l'AWS CLI
• Pour créer un rôle : aws iam create-role
• Pour attacher une stratégie d'accès au rôle :
aws iam attach-role-policy pour attacher une stratégie gérée existante
ou
aws iam put-role-policy pour créer une stratégie en ligne
L'exemple suivant illustre toutes les étapes dans un environnement simple. L'exemple suppose que
vous utilisez l'AWS CLI sur un ordinateur exécutant Windows et que celle-ci a déjà été configurée à
l'aide de vos informations d'identification. Pour plus d'informations, consultez Configuration de l'AWS
Command Line Interface.
# Create the role and attach the trust policy that enables users in an
account to assume the role.
aws iam create-role --role-name Test-CrossAcct-Role --assume-role-policydocument file://C:\policies\trustpolicyforcognitofederation.json
# Attach the permissions policy to the role to specify what it is allowed to
do.
202
Création de rôles
aws iam put-role-policy --role-name Test-CrossAcct-Role --policy-name
Perms-Policy-For-CognitoFederation --policy-document file://c:\policies
\permspolicyforcognitofederation.json
Création d'un rôle pour l'accès fédéré (Outils pour Windows PowerShell)
La procédure à suivre pour la création d'un rôle pour les fournisseurs d'identité pris en charge (OIDC
ou SAML) est identique ; la différence porte sur le contenu de la stratégie d'approbation que vous
créez dans les étapes requises. Suivez les étapes de la section Prérequis pour le type de fournisseur
que vous utilisez :
OIDC (p. 204).
SAML (p. 208).
La création d'un rôle à l'aide de Outils pour Windows PowerShell comporte plusieurs étapes. Lorsque
vous. En revanche, lors de l'utilisation de Outils pour Windows PowerShell, vous devez exécuter
explicitement chaque étape vous-même. Vous devez commencer par créer la stratégie d'approbation
et le rôle, puis affecter une stratégie d'accès au rôle.
Pour créer un rôle à l'aide de Outils pour Windows PowerShell
• Pour créer un rôle : New-IAMRole
Register-IAMRolePolicy pour attacher une stratégie gérée existante
-ouWrite-IAMRolePolicy pour créer une stratégie en ligne
L'exemple suivant illustre toutes les étapes dans un environnement simple. L'exemple suppose que
vous avez déjà configuré Outils pour Windows PowerShell à l'aide de vos informations d'identification.
Pour plus d'informations, consultez Utilisation d'informations d'identification AWS.
# Create the role and attach the trust policy that enables users in an
account to assume the role.
New-IAMRole -RoleName Test-Federation-Role -AssumeRolePolicyDocument (GetContent -Raw C:\policies\trustpolicyforfederation.json)
# Attach a managed permissions policy to the role to specify what it is
allowed to do.
Register-IAMRolePolicy -RoleName Test-Federation-Role -PolicyArn
arn:aws:iam::aws:policy/PolicyForFederation
Création d'un rôle pour l'accès fédéré (API IAM)
Avant de créer le rôle, vous devez suivre les étapes décrites dans la section Prérequis pour le type de
fournisseur que vous utilisez :
203
Création de rôles
OIDC (p. 204).
SAML (p. 208).
Pour créer un rôle pour la fédération d'identité à l'aide de l'API IAM
• Pour créer un rôle : CreateRole
AttachRolePolicy pour attacher une stratégie gérée existante
ou
PutRolePolicy pour créer une stratégie en ligne
Création d'un rôle pour la fédération d'identité web ou OpenID Connect (AWS
Management Console)
Avant de pouvoir créer un rôle pour la fédération d'identité web, vous devez tout d'abord suivre les
étapes requises suivantes.
Pour préparer la création d'un rôle pour la fédération d'identité web
1.
Commencez par vous connecter en tant que développeur avec un (ou plusieurs) IdP. Vous
configurez également votre application avec le fournisseur. Ainsi, le fournisseur vous fournit un
ID d'application ou de public unique pour votre application. (Les fournisseurs utilisent différentes
terminologies pour ce processus. Ce manuel utilise le terme configurer pour le processus
d'identification de votre application auprès du fournisseur.) Chaque fournisseur vous donne un
ID d'application qui est unique à ce fournisseur. Ainsi, si vous configurez l'application auprès
de plusieurs fournisseurs, elle sera dotée de plusieurs ID d'application. Vous pouvez configurer
plusieurs applications auprès de chaque fournisseur. Les liens externes suivants fournissent des
informations sur l'un des fournisseurs d'identité :
• Login with Amazon Developer Center
• Add Facebook Login to Your App or Website sur le site des développeurs Facebook.
• Using OAuth 2.0 for Login (OpenID Connect) sur le site des développeurs Google.
2.
3.
Après avoir obtenu les informations requises auprès du fournisseur d'identité, vous pouvez créer
un fournisseur d'identité dans IAM. Pour de plus amples informations, veuillez consulter Création
de fournisseurs d'identité OpenID Connect (OIDC) (p. 160).
Préparez les stratégies pour le rôle que les utilisateurs authentifiés auprès de l'IdP vont assumer.
Comme tout autre rôle, un rôle pour une application mobile contient deux stratégies. La première
est la stratégie d'approbation qui spécifie qui est autorisé à assumer le rôle (l'entité approuvée
ou mandataire). L'autre stratégie (la stratégie d'accès) spécifie les actions et les ressources AWS
réelles auxquelles l'application mobile peut ou ne peut pas accéder (semblable à des stratégies
utilisateur ou de ressources).
Pour les fournisseurs d'identité web, nous vous recommandons d'utiliser Amazon Cognito pour
gérer les identités. Dans ce cas, la stratégie d'approbation pour le rôle doit inclure une Statement
{
"Version": "2012-10-17",
"Statement": {
204
Création de rôles
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {"cognito-identity.amazonaws.com:aud": "useast-2:12345678-abcd-abcd-abcd-123456"},
"ForAnyValue:StringLike": {"cognito-identity.amazonaws.com:amr":
"unauthenticated"}
}
}
}
Remplacez us-east-2:12345678-abcd-abcd-abcd-123456 par l'ID du groupe d'identités réel
que Amazon Cognito vous a affecté.
Si vous configurez manuellement un IdP d'identité web, la stratégie d'approbation doit alors
accorder un effet Allow à l'action sts:AssumeRoleWithWebIdentity. Dans ce rôle, vous
utilisez deux valeurs pour garantir que seule votre application peut assumer le rôle :
• Pour l'élément Principal, utilisez la chaîne {"Federated":providerUrl/providerArn}.
• Pour certains IdP OpenID Connect (OIDC) courants, providerUrl est l'URL complète. Les
procédures suivantes sont acceptables pour désigner le mandataire de certains IdP courants :
"Principal":{"Federated":"cognito-identity.amazonaws.com"}
"Principal":{"Federated":"www.amazon.com"}
"Principal":{"Federated":"graph.facebook.com"}
"Principal":{"Federated":"accounts.google.com"}
• Pour les autres fournisseurs OIDC, utilisez l'ARN du fournisseur d'identité OIDC que vous
avez créé dans Step 2 (p. 204), comme dans l'exemple suivant :
"Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/
server.example.com"}
• Dans l'élément Condition, utilisez une condition StringEquals permettant de tester si l'ID
du groupe d'identités (pour Amazon Cognito) ou l'ID d'application, également appelé ID client
ou public, (pour d'autres fournisseurs) dans la demande correspond à l'ID d'application que
vous avez obtenu lors de la configuration de l'application avec l'IdP. Cela permet de vérifier
que la demande provient bien de votre application. Dans l'élément Condition de la stratégie,
vous pouvez tester l'ID d'application dont vous disposez par rapport aux variables de stratégie
suivantes. Celle que vous utilisez dépend de l'IdP auquel vous faites appel :
"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud":
"us-east:12345678-ffff-ffff-ffff-123456"}}
"Condition": {"StringEquals": {"www.amazon.com:app_id":
"amzn1.application-oa2-123456"}}
"Condition": {"StringEquals": {"graph.facebook.com:app_id":
"111222333444555"}}
"Condition": {"StringEquals": {"accounts.google.com:aud":
"666777888999000"}}
Pour les fournisseurs OIDC, utilisez l'URL complète de l'IdP OIDC avec la clé contexte aud,
comme dans exemple suivant :
205
Création de rôles
"Condition": {"StringEquals": {"server.example.com:aud":
"appid_from_oidc_idp"}}
Notez que les valeurs du mandataire dans le rôle sont spécifiques à un IdP. Un rôle ne peut
spécifier qu'un seul mandataire. Par conséquent, si l'application mobile autorise les utilisateurs à
se connecter depuis plusieurs IdP, vous devez créer un rôle pour chaque IdP que vous souhaitez
prendre en charge.
Note
Dans la mesure où la stratégie de l'entité approuvée utilise des variables de stratégie
qui représentent l'IdP et l'ID d'application, vous devez définir l'élément Version de la
stratégie sur 2012-10-17 ou une version ultérieure prise en charge.
L'exemple suivant illustre une stratégie d'approbation pour un rôle conçu pour une
application mobile si l'utilisateur se connecte depuis Login with Amazon. Dans l'exemple,
amzn1.application-oa2-123456 représente l'ID d'application que Amazon a affecté lorsque
vous avez configuré l'application à l'aide de Login with Amazon.
{
"Version": "2012-10-17",
"Id": "RoleForLoginWithAmazon",
"Statement": [{
"Effect": "Allow",
"Principal": {"Federated": "www.amazon.com"},
"Condition": {"StringEquals": {"www.amazon.com:app_id":
"amzn1.application-oa2-123456"}}
}]
}
L'exemple suivant illustre une stratégie d'approbation pour un rôle que l'application mobile peut
assumer si l'utilisateur s'est connecté depuis Facebook. Dans cet exemple, 111222333444555
représente l'ID d'application affecté par Facebook.
{
"Version": "2012-10-17",
"Id": "RoleForFacebook",
"Statement": [{
"Effect": "Allow",
"Principal": {"Federated": "graph.facebook.com"},
"Condition": {"StringEquals": {"graph.facebook.com:app_id":
"111222333444555"}}
}]
}
assumer si l'utilisateur s'est connecté depuis Google. Dans cet exemple, 666777888999000
représente l'ID d'application affecté par Google.
{
"Version": "2012-10-17",
"Id": "RoleForGoogle",
206
Création de rôles
"Statement": [{
"Effect": "Allow",
"Principal": {"Federated": "accounts.google.com"},
"Condition": {"StringEquals": {"accounts.google.com:aud":
"666777888999000"}}
}]
}
assumer si l'application utilise Amazon Cognito. Dans cet exemple, us-east:12345678-ffffffff-ffff-123456 représente l'ID de groupe d'identités affecté par Amazon Cognito.
{
"Version": "2012-10-17",
"Id": "RoleForCognito",
"Statement": [{
"Effect": "Allow",
"Principal": {"Federated": "cognito-identity.amazonaws.com"},
"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud":
"us-east:12345678-ffff-ffff-ffff-123456"}}
}]
}
Après avoir réalisé les étapes requises, vous pouvez créer le rôle proprement dit. La procédure
suivante décrit comment créer une le rôle pour la fédération d'identité web/OIDC dans l'AWS
Management Console. Pour créer un rôle avec l'AWS CLI, l'Outils pour Windows PowerShell ou
l'API AWS, consultez les procédures décrites à l'adresse Création d'un rôle pour un fournisseur
d'identité tiers (Fédération) (p. 201).
Pour créer un rôle IAM pour la fédération d'identité web (console IAM)
Si vous utilisez Amazon Cognito, assurez-vous d'utiliser la console Amazon Cognito pour configurer
les rôles. Sinon, utilisez la console IAM pour créer un rôle pour la fédération d'identité web.
1.
2.
Dans le volet de navigation, cliquez sur Roles, puis sur Create New Role.
3.
rôles de votre compte AWS doivent être uniques. Différentes entités peuvent référencer le rôle et
il n'est donc pas possible d'en modifier le nom après sa création. Après avoir tapé le nom, cliquez
sur Next Step au bas de la page.
Important
4.
Sélectionnez Role for Identity Provider Access, puis cliquez sur le bouton Select pour Grant
access to web identity providers.
5.
Dans la liste Identity Provider, sélectionnez le fournisseur d'identité pour lequel vous créez le rôle :
• Sélectionnez Amazon Cognito si vous créez un rôle pour Amazon Cognito.
207
Création de rôles
Note
Il vous suffit de créer manuellement un rôle à utiliser avec Amazon Cognito lorsque
vous travaillez à un scénario plus avancé. Sinon, Amazon Cognito peut créer des rôles
pour vous pour des scénarios standard. Pour plus d'informations sur Amazon Cognito,
consultez Identité Amazon Cognito dans le manuel Guide du développeur AWS Mobile
SDK pour iOS et Identité Amazon Cognito dans le manuel Guide du développeur AWS
Mobile SDK pour Android.
• Si vous créez un rôle pour un fournisseur d'identité web individuel, sélectionnez le nom du
fournisseur.
Note
Vous devez créer un rôle distinct pour chaque fournisseur d'identité que vous souhaitez
prendre en charge.
6.
Entrez l'ID d'application qui identifie votre application. Le nom de la zone de l'ID varie selon le
fournisseur que vous sélectionnez.
• Si vous créez un rôle pour Amazon Cognito, entrez l'ID du groupe d'identités que vous avez
créé pour vos applications Amazon Cognito dans la zone Identity Pool ID.
• Si vous créez un rôle pour un fournisseur d'identité web, entrez ou sélectionnez l'ID client que le
fournisseur vous a fourni lorsque vous avez enregistré votre application auprès du fournisseur.
7.
(Facultatif) Cliquez sur Add Conditions pour créer des conditions supplémentaires qui doivent être
réunies avant que les utilisateurs de votre application puissent utiliser les autorisations accordées
par le rôle. Par exemple, vous pouvez ajouter une condition qui accorde l'accès aux ressources
AWS uniquement à un ID utilisateur spécifique.
8.
Cliquez sur Next Step pour vérifier le Trust Policy Document, puis cliquez sur Next Step.
9.
Sélectionnez la stratégie gérée qui affecte les autorisations que vous voulez octroyer aux
utilisateurs fédérés, puis cliquez sur Next Step.
10. Vérifiez le rôle, puis cliquez sur Create Role.
Création d'un rôle pour la fédération SAML 2.0 (AWS Management Console)
A l'aide de la fédération d'identité, vous pouvez autoriser l'accès aux ressources AWS aux utilisateurs
qui se connectent via un fournisseur d'identité (IdP) tiers. Pour configurer la fédération d'identité, vous
configurez le fournisseur, puis créez un rôle IAM qui détermine les autorisations dont disposera un
utilisateur fédéré. Pour plus d'informations sur la fédération et les fournisseurs d'identité, consultez
Fournisseurs d'identité et fédération (p. 148).
L'assistant de création de rôle de la console IAM propose deux méthodes. La première
méthode correspond à la création d'un rôle pour authentification unique (SSO) dans
AWS Management Console. L'autre méthode permet la création d'un rôle qui peut être assumé par
programmation. Les procédures suivantes décrivent les deux méthodes. Les rôles créés par les deux
méthodes sont similaires mais, dans le cas de SSO , la stratégie d'approbation du rôle créé inclut
une condition qui garantit explicitement que l'audience SAML (attribut aud) est définie sur le point de
terminaison d'authentification AWS pour SAML (https://signin.aws.amazon.com/saml).
Avant de pouvoir créer un rôle pour la fédération SAML 2.0, vous devez tout d'abord suivre les étapes
requises suivantes :
Pour préparer la création d'un rôle pour la fédération SAML 2.0
1.
Avant de créer un rôle pour la fédération SAML, vous devez créer un fournisseur SAML dans
IAM. Pour de plus amples informations, veuillez consulter Création de fournisseurs d'identité
SAML (p. 166).
208
Création de rôles
2.
Préparez les stratégies pour le rôle que les utilisateurs authentifiés SAML 2.0 vont assumer.
Comme tout autre rôle, un rôle pour la fédération SAML contient deux stratégies. La première
est la stratégie d'approbation qui spécifie qui est autorisé à assumer le rôle (l'entité approuvée
ou mandataire). L'autre stratégie (la stratégie d'accès) spécifie les actions et les ressources AWS
réelles auxquelles l'utilisateur fédéré peut ou ne peut pas accéder (semblable à une stratégie
utilisateur ou de ressources).
Pour les fournisseurs SAML 2.0, la stratégie doit inclure un élément Statement similaire à ce qui
suit :
La stratégie d'approbation doit accorder un effet Allow pour l'action sts:AssumeRoleWithSAML.
Dans ce rôle, vous utilisez deux valeurs pour garantir que le rôle peut être uniquement assumé
par votre application :
• Pour l'élément Principal, utilisez la chaîne {"Federated":ARNofIdentityProvider}.
Remplacez ARNofIdentityProvider par l'ARN du fournisseur d'identité SAML (p. 156) que
vous avez créé dans Step 1 (p. 208).
• Pour l'élément Condition, utilisez une condition StringEquals pour vérifier que l'attribut
saml:aud de la réponse SAML correspond au point de terminaison de fédération SAML pour
AWS.
Note
Dans la mesure où la stratégie de l'entité approuvée utilise des variables de stratégie qui
représentent les valeurs de la réponse SAML, vous devez définir l'élément Version de la
stratégie sur 2012-10-17 ou une version ultérieure prise en charge.
L'exemple suivant illustre une stratégie d'approbation pour un rôle conçu pour un utilisateur fédéré
SAML :
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"Federated": "arn:aws:iam::ACCOUNT-ID-WITHOUTHYPHENS:saml-provider/PROVIDER-NAME"},
"Condition": {"StringEquals": {"SAML:aud": "https://
signin.aws.amazon.com/saml"}}
}
}
Remplacez l'ARN principal par l'ARN réel pour le fournisseur SAML que vous avez créé dans IAM.
Il utilisera votre propre ID de compte et le nom du fournisseur réel.
Après avoir réalisé les étapes requises, vous pouvez créer le rôle proprement dit.
Pour créer un rôle pour la fédération SAML à l'aide de la console IAM
1.
Assurez-vous d'avoir créé un fournisseur SAML dans IAM, comme décrit dans A propos de la
fédération SAML 2.0 (p. 156).
2.
Dans le volet de navigation de la console, cliquez sur Roles, puis sur Create New Role.
3.
rôles de votre compte AWS doivent être uniques. Après avoir tapé le nom, cliquez sur Next Step
au bas de la page.
209
Création de rôles
Différentes entités peuvent référencer le rôle et il n'est donc pas possible de modifier son nom
après sa création.
Important
4.
Cliquez sur Role for Identity Provider Access.
5.
Sélectionnez le type de rôle que vous créez : Grant Web Single Sign-On (SSO) access to SAML
identity providers ou Grant API access to SAML identity providers.
6.
Dans la liste SAML Provider, sélectionnez le fournisseur pour lequel vous créez le rôle.
7.
Si vous créez un rôle pour l'accès aux API, sélectionnez un attribut dans la liste Attribute.
Ensuite, dans la zone Value , tapez une valeur qui sera incluse dans le rôle. Cette valeur
restreint l'accès au rôle aux utilisateurs du fournisseur d'identité dont la réponse d'authentification
SAML (assertion) inclut les attributs que vous avez sélectionnés. Vous devez spécifier au
moins un attribut, afin de garantir la limitation du rôle à un sous-ensemble d'utilisateurs de votre
organisation.
Si vous créez un rôle pour l'authentification unique SAML, l'attribut SAML:aud est
automatiquement ajouté et sa valeur est définie sur l'URL du point de terminaison SAML AWS
(https://signin.aws.amazon.com/saml).
8.
Pour ajouter d'autres conditions liées aux attributs à la stratégie d'approbation, cliquez sur Add
Conditions, sélectionnez une autre condition, spécifiez une valeur, puis cliquez sur Add Condition.
La liste affiche une sélection d'attributs SAML les plus utilisés. IAM prend en charge des attributs
supplémentaires que vous pouvez utiliser pour créer des conditions. (Pour obtenir la liste des
attributs pris en charge, consultez Clés disponibles pour la fédération SAML dans la rubrique
Références des éléments de stratégie IAM (p. 402).) Si vous devez créer une condition pour
un attribut SAML pris en charge ne figurant pas dans la liste, vous pouvez ajouter cette condition
manuellement à l’étape suivante.
9.
Cliquez sur Next Step. L'assistant affiche la stratégie d'approbation du rôle dans une zone
modifiable. La stratégie inclut une ou plusieurs conditions selon les données que vous avez
entrées.
10. Après avoir passé en revue la stratégie et effectué des modifications, si nécessaire, cliquez à
nouveau sur Next Step.
11. Par défaut, les rôles ne disposent d'aucune autorisation. Sélectionnez la stratégie gérée qui
affecte les autorisations que vous voulez octroyer aux utilisateurs fédérés, puis cliquez sur Next
Step.
12. Vérifiez le rôle, puis cliquez sur Create Role.
Après avoir créé le rôle, vous devez finaliser la relation d'approbation SAML en configurant le logiciel
de votre fournisseur d'identité à l'aide d'informations sur AWS et des rôles que vous voulez affecter à
vos utilisateurs fédérés. Il s'agit de la configuration de la relation d'approbation des parties utilisatrices
entre votre fournisseur d'identité et AWS. Pour de plus amples informations, veuillez consulter
Configuration de votre IdP SAML 2.0 à l'aide d'une relation d'approbation des parties utilisatrices et
ajout de requêtes (p. 168).
Exemples de stratégies pour la délégation d'accès
Les exemples suivants montrent comment vous pouvez autoriser ou accorder à un compte AWS
l'accès aux ressources d'un autre compte AWS.
Rubriques
210
Création de rôles
• Utilisation de rôles pour la délégation d'accès aux ressources d'un autre compte AWS (p. 211)
• Utilisation d'une stratégie pour la délégation d'accès à des services (p. 211)
• Utilisation d'une stratégie basée sur les ressources pour la délégation de l'accès à un
compartiment Amazon S3 dans un autre compte (p. 211)
• Utilisation d'une stratégie basée sur les ressources pour la délégation de l'accès à une file d'attente
Amazon SQS dans un autre compte (p. 212)
• Délégation d'accès impossible lorsque l'accès est refusé au compte (p. 213)
Utilisation de rôles pour la délégation d'accès aux ressources d'un autre
compte AWS
Pour vérifier la procédure à suivre pour utiliser des rôles IAM pour accorder aux utilisateurs d'un
compte l'accès aux ressources AWS d'un autre compte, reportez-vous à Didacticiel : Déléguer l'accès
entre des comptes AWS à l'aide de rôles IAM (p. 26).
Utilisation d'une stratégie pour la délégation d'accès à des services
L'exemple suivant illustre une stratégie qui est peut être attachée à un rôle. La stratégie autorise
deux services, à savoir Amazon EMR et AWS Data Pipeline, à assumer le rôle. Les services peuvent
ensuite effectuer toutes les tâches autorisées par la stratégie d'autorisation affectée au rôle (non
illustré). Notez que pour définir plusieurs mandataires de service, vous ne spécifiez pas deux éléments
Service ; vous ne devez en avoir qu'un seul. A la place, vous utilisez un ensemble de plusieurs
mandataires de service comme valeur d'un élément Service unique.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"elasticmapreduce.amazonaws.com",
"datapipeline.amazonaws.com"
]
},
}
]
}
Utilisation d'une stratégie basée sur les ressources pour la délégation de
l'accès à un compartiment Amazon S3 dans un autre compte
Dans cet exemple, le compte A utilise une stratégie basée sur les ressources (une stratégie de
compartiment Amazon S3) pour accorder au compte B l'accès complet au compartiment S3
du compte A. Ensuite, le compte B crée une stratégie d'utilisateur IAM pour déléguer l'accès au
compartiment du compte A à l'un des utilisateurs du compte B.
La stratégie de compartiment S3 du compte A peut se présenter comme suit. Dans cet exemple,
le compartiment S3 du compte A est nommé mybucket, et le numéro de compte du compte B est
111122223333. Il ne spécifie pas d'utilisateurs ou de groupes dans le compte B, simplement le compte
proprement dit.
{
"Version": "2012-10-17",
"Statement": {
211
Création de rôles
"Sid": "AccountBAccess1",
"Effect": "Allow",
"Principal": {"AWS": "111122223333"},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::mybucket",
"arn:aws:s3:::mybucket/*"
]
}
}
Le compte A peut également utiliser des listes de contrôle d'accès (ACL) Amazon S3 pour accorder
au compte B l'accès à un compartiment S3 ou à un objet individuel dans celui-ci. Dans ce cas, seule
change la façon dont le compte A accorde l'accès au compte B. Le compte B utilise toujours une
stratégie pour déléguer l'accès à un groupe IAM dans le compte B, comme décrit dans la dernière
partie de cet exemple. Pour plus d'informations sur le contrôle de l'accès aux compartiments et aux
objets S3, consultez la section Contrôle d'accès du manuel Amazon Simple Storage Service Manuel
du développeur.
L'exemple de stratégie suivant complète l'exemple ci-dessus et illustre la stratégie de groupe (ou
d'utilisateur) IAM que l'administrateur du compte B peut créer pour déléguer l'accès en lecture seule
à un groupe ou utilisateur du compte B. Bien que la stratégie ci-dessus accorde l'accès au compte B,
des groupes et des utilisateurs individuels du compte B ne peuvent pas accéder à la ressource
tant qu'une stratégie de groupe ou d'utilisateur n'accorde pas explicitement des autorisations sur la
ressource. Les autorisations de cette stratégie peuvent uniquement être un sous-ensemble de celles
de la stratégie entre comptes ci-dessus. Le compte B ne peut pas accorder plus d'autorisations à
ses utilisateurs et groupes que le compte A ne lui a accordé dans la première stratégie. Dans cette
stratégie, l'élément Action est défini explicitement pour autoriser uniquement les actions List, tandis
que l'élément Resource de cette stratégie correspond à l'élément Resource pour la stratégie de
compartiment implémentée par le compte A.
Pour implémenter cette stratégie, le compte B utilise IAM pour l'attacher à l'utilisateur (ou au groupe)
approprié dans le compte B.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "s3:List*",
"Resource": [
]
}
}
Utilisation d'une stratégie basée sur les ressources pour la délégation de
l'accès à une file d'attente Amazon SQS dans un autre compte
Dans l'exemple suivant, le compte A est doté d'une file d'attente Amazon SQS qui utilise une stratégie
basée sur les ressources attachée à celle-ci pour accorder au compte B l'accès à la file d'attente.
Le compte B utilise ensuite une stratégie de groupe IAM pour déléguer l'accès à un groupe dans un
compte B.
L'exemple de stratégie de file d'attente suivant accorde au compte B l'autorisation d'effectuer les
actions SendMessage et ReceiveMessage dans la file d'attente du compte A nommée queue1, mais
uniquement entre midi et 15 heures le 30 novembre 2014. Le numéro de compte du compte B est
1111-2222-3333. Le compte A utilise Amazon SQS pour implémenter cette stratégie.
212
Création de rôles
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": {"AWS": "111122223333"},
"Action": [
"sqs:SendMessage",
"sqs:ReceiveMessage"
],
"Resource": ["arn:aws:sqs:*:123456789012:queue1"],
"Condition": {
"DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"},
"DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"}
}
}
}
La stratégie du compte B pour la délégation d'accès à un groupe dans le compte B peut se présenter
comme l'exemple suivant. Le compte B utilise IAM pour attacher cette stratégie à un groupe (ou
utilisateur).
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sqs:*",
"Resource": "arn:aws:sqs:*:123456789012:queue1"
}
}
Dans l'exemple de stratégie utilisateur IAM précédent, le compte B utilise un caractère générique pour
accorder à son utilisateur l'accès à toutes les actions Amazon SQS dans la file d'attente du compte A.
Toutefois, dans la mesure où le compte B peut uniquement déléguer l'accès dont il bénéficie, le groupe
du compte B, qui a la deuxième stratégie, peut uniquement accéder à la file d'attente entre midi et
15 h le 30 novembre 2014, et l'utilisateur peut uniquement effectuer les actions SendMessage et
ReceiveMessage, comme défini dans la stratégie de file d'attente Amazon SQS du compte A.
Délégation d'accès impossible lorsque l'accès est refusé au compte
Par défaut, les autres comptes AWS et leurs utilisateurs ne peuvent pas accéder aux ressources de
votre compte AWS. Toutefois, si vous utilisez une stratégie pour refuser explicitement l'accès à vos
ressources à un compte AWS le refus s'applique à l'ensemble des utilisateurs de ce compte, qu'ils
disposent ou non de stratégies leur accordant l'accès. Ceci signifie qu'un compte AWS ne peut pas
déléguer l'accès aux ressources d'un autre compte si ce dernier a refusé explicitement l'accès au
compte parent de l'utilisateur.
Par exemple, le compte A crée une stratégie de compartiment pour son compartiment S3 qui refuse
explicitement au compte B l'accès à ce compartiment. Mais le compte B crée une stratégie d'utilisateur
IAM qui accorde à un utilisateur du compte B l'accès au compartiment du compte A. Le refus explicite
appliqué au compartiment S3 du compte A est propagé aux utilisateurs du compte B et remplace la
stratégie d'utilisateur IAM qui accorde l'accès aux utilisateurs du compte B. (Pour des informations
détaillées sur la façon dont les autorisations sont évaluées, consultez Logique d'évaluation de
stratégies IAM (p. 441).)
La stratégie de compartiment du compte A peut se présenter comme suit. Dans cet exemple, le
compartiment S3 du compte A est nommé mybucket, et le numéro de compte du compte B est
1111-2222-3333. Le compte A utilise Amazon S3 pour implémenter cette stratégie.
213
Utilisation de rôles
{
"Version": "2012-10-17",
"Statement": {
"Sid": "AccountBDeny",
"Effect": "Deny",
"Principal": {"AWS": "111122223333"},
"Action": "s3:*",
"Resource": "arn:aws:s3:::mybucket/*"
}
}
Pour implémenter la stratégie d'utilisateur IAM suivante, le compte B utilise IAM pour l'attacher à un
utilisateur du compte B.
{
"Version": "2012-10-17",
"Statement":{
"Effect":"Allow",
"Action":"s3:*",
"Resource":"arn:aws:s3:::mybucket/*"
}
}
La stratégie de compartiment du compte A refuse explicitement au compte B l'accès à mybucket. Dans
la mesure où vous déléguez uniquement un sous-ensemble d'autorisations qui vous ont été accordées,
la stratégie d'utilisateur IAM du compte B octroyant à l'utilisateur du compte B l'accès au compartiment
du compte A reste sans effet. L'utilisateur du compte B ne peut pas accéder au compartiment du
compte A.
Utilisation de rôles IAM
Avant qu'un utilisateur, une application ou un service IAM soit en mesure d'utiliser un rôle que
vous avez créé, vous devez lui accorder les autorisations nécessaires pour changer de rôle. Pour
accorder ces autorisations, vous pouvez utiliser n'importe quelle stratégie attachée à l'un des groupes
d'utilisateurs IAM, voire à l'utilisateur lui-même. Cette section décrit comment accorder aux utilisateurs
l'autorisation d'utiliser un rôle, puis comment l'utilisateur peut changer de rôle à l'aide de AWS
Management Console, de Outils pour Windows PowerShell, de l'AWS Command Line Interface (l'AWS
CLI) ou de l'API AssumeRole.
Important
Si vous créez un rôle par programmation plutôt que dans la console IAM, vous avez la
possibilité d'ajouter un Path de 512 caractères maximum à l'élément RoleName qui lui, est de
64 caractères maximum. Toutefois, si vous avez l'intention d'utiliser un rôle avec la fonction
de changement de rôle (Switch Role) dans la console AWS, l'ensemble Path et RoleName ne
doit pas comporter plus de 64 caractères.
Note
Lors de l'utilisation de AWS Management Console, vous devez être connecté en tant
qu'utilisateur IAM pour pouvoir changer de rôle. Il n'est pas possible de changer de rôle si vous
êtes connecté en tant qu’utilisateur racine du compte AWS.
Rubriques
214
• Octroi d'autorisations à un utilisateur pour assumer un rôle (p. 215)
• Octroi d'autorisations à un utilisateur pour transférer un rôle à un service AWS (p. 217)
• Assumer un rôle (AWS Management Console) (p. 219)
• Passer à un rôle IAM (AWS Command Line Interface) (p. 221)
• Passer à un rôle IAM (Outils pour Windows PowerShell) (p. 223)
• Assumer un rôle IAM (API) (p. 225)
• Utilisation d'un rôle IAM pour accorder des autorisations à des applications s'exécutant sur des
instances Amazon EC2 (p. 226)
• Révocation des informations d'identification de sécurité temporaires d'un rôle IAM (p. 232)
Octroi d'autorisations à un utilisateur pour assumer un rôle
Lorsque vous créez un rôle pour un accès entre comptes (p. 187), vous établissez une relation
d'approbation entre le compte qui est propriétaire du rôle et des ressources (compte d'approbation)
et le compte qui contient les utilisateurs (compte approuvé). Pour ce faire, vous spécifiez le numéro
du compte approuvé en tant que Principal dans la stratégie d'approbation du rôle. Cela permet
potentiellement à n'importe quel utilisateur du compte approuvé d'assumer le rôle. Pour achever la
configuration, l'administrateur du compte approuvé doit accorder l'autorisation d'assumer ce rôle à des
groupes ou utilisateurs spécifiques du compte.
Pour accorder à un utilisateur l'autorisation d'assumer un rôle, vous créez une nouvelle stratégie
pour l'utilisateur ou modifiez une stratégie existante de manière à ajouter les éléments requis. Vous
pouvez ensuite envoyer à l'utilisateur un lien qui le dirige vers la page Switch Role dans laquelle tous
les détails sont déjà remplis. Sinon, vous pouvez lui fournir l'ID ou l'alias du compte contenant le
rôle, ainsi que le nom du rôle. L'utilisateur accède ensuite à la page Switch Role et ajoute les détails
manuellement. Pour plus d'informations sur la façon dont un utilisateur assume un rôle, consultez
Assumer un rôle (AWS Management Console) (p. 219).
Notez que pour assumer un rôle, vous devez être connecté en tant qu’utilisateur IAM. Il n'est pas
possible d'assumer un rôle si vous êtes connecté en tant qu’utilisateur racine du compte AWS.
Important
Vous ne pouvez pas échanger de rôles dans AWS Management Console avec un rôle qui
nécessite une valeur ExternalID (p. 193). Vous ne pouvez basculer vers un tel rôle qu'en
appelant l'API AssumeRole qui prend en charge le paramètre ExternalID.
Note
Cette rubrique décrit les stratégies applicables à un utilisateur car au final, nous accordons
des autorisations à un utilisateur pour lui permettre d'effectuer une tâche. Toutefois, la
bonne pratique consiste à ne pas accorder d'autorisations directement à un utilisateur
individuel (p. 46). Pour faciliter la gestion, il est recommandé d'affecter des stratégies et
d'accorder des autorisations à des groupes IAM, puis de faire de ces utilisateurs des membres
des groupes appropriés.
Création ou modification de la stratégie
Une stratégie qui accorde à un utilisateur l'autorisation d'assumer un rôle doit inclure une déclaration
avec l'effet Allow sur l'action sts:AssumeRole et l'ARN (Amazon Resource Name) du rôle dans un
élément Resource, comme illustré dans l'exemple suivant. Les utilisateurs disposant de la stratégie
(via l'appartenance à un groupe ou par la stratégie directement attachée) sont autorisés à assumer le
rôle spécifié.
215
Note
Notez que si Resource est défini sur *, l'utilisateur peut assumer n'importe quel rôle dans
n'importe quel compte faisant confiance au compte de l'utilisateur (la stratégie d'approbation
du rôle spécifie le compte de l'utilisateur en tant que Principal). La bonne pratique consiste
à appliquer le principe du moindre privilège et à spécifier l'ARN complet uniquement pour les
rôles dont l'utilisateur a besoin.
L'exemple suivant illustre une stratégie qui permet à l'utilisateur d'assumer des rôles dans un seul
compte et qui spécifie également, à l'aide d'un caractère générique (*), qu'il peut uniquement assumer
un rôle dans ce compte si le nom du compte commence par les lettres « Test », suivies de n'importe
quelle autre combinaison de caractères.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Resource": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:role/Test*"
}
}
Note
Les autorisations que le rôle octroie à l'utilisateur ne viennent pas s'ajouter aux autorisations
dont il dispose déjà. Lorsqu'un utilisateur assume un rôle, il abandonne temporairement ses
autorisations d'origine, de manière à adopter celles accordées par le rôle. Lorsqu'il quitte
le rôle, ses autorisations d'origine sont automatiquement restaurées. Par exemple, si les
autorisations de l'utilisateur lui permettent d'utiliser des instances Amazon EC2 mais que
la stratégie d'autorisation du rôle n'accorde pas ces autorisations, il n'est pas en mesure
d'utiliser d'instances Amazon EC2 dans la console tant qu'il assume le rôle et les informations
d'identification temporaires obtenues via AssumeRole ne fonctionnent pas par programmation
avec les instances Amazon EC2.
Fourniture d'informations à l'utilisateur
Après avoir créé un rôle et accordé à l'utilisateur les autorisations requises pour assumer le rôle, vous
devez lui fournir le nom du rôle ainsi que l'ID ou l'alias du compte qui contient le rôle. Pour faciliter
la tâche aux utilisateurs, vous pouvez leur envoyer un lien préconfiguré contenant l'ID du compte
et le nom du rôle. Le lien est fourni sur la page finale de l'assistant Create Role ou sur la page Role
Summary pour n'importe quel rôle entre comptes.
Note
Si vous créez le rôle avec l'AWS CLI, les Outils pour Windows PowerShell ou l'API AWS, vous
pouvez inclure un chemin en plus du nom pour le rôle. Dans ce cas, vous devez fournir le
chemin complet et le nom du rôle à vos utilisateurs afin qu'ils les saisissent sur la page Switch
Role d'AWS Management Console. Par exemple : division_abc/subdivision_efg/
role_XYZ.
Important
Si vous créez le rôle par programmation plutôt que dans la console IAM, vous avez la
possibilité d'ajouter un élément Path de 512 caractères maximum à l'élément RoleName
qui lui, est de 64 caractères maximum. Toutefois, pour utiliser un rôle avec la fonction de
216
changement de rôle (Switch Role) dans la console AWS, l'ensemble Path et RoleName ne
Vous pouvez également utiliser le format suivant pour créer le lien manuellement. Remplacez les deux
paramètres de la requête par l'ID ou l'alias de votre compte et le nom du rôle.
account=YourAccountIDorAliasHere&roleName=pathIfAny/YourRoleNameHere
Nous vous recommandons de diriger vos utilisateurs vers la rubrique Assumer un rôle (AWS
Management Console) (p. 219) pour les guider à travers le processus.
Note
Pour des raisons de sécurité, vous pouvez utiliser AWS CloudTrail pour analyser le
changement de rôle. Si CloudTrail est activé pour le compte, IAM consigne dans les journaux
les actions exécutées avec les informations d'identification de sécurité temporaires du rôle.
Pour plus d'informations, consultez Référence des événements CloudTrail dans le manuel
AWS CloudTrail User Guide.
Octroi d'autorisations à un utilisateur pour transférer un rôle à
un service AWS
Pour configurer la plupart des services AWS, vous devez « transférer » un rôle IAM au service qui
définit les opérations que ce service peut effectuer en votre nom. Par exemple, pour fournir des
applications qui s'exécutent sur une instance Amazon EC2 avec des informations d'identification
AWS, vous transférez un rôle à EC2 pour qu'il l'utilise avec l'instance qui fournit ces informations
d'identification. Vous définissez les opérations que les informations d'identification autorisent
les applications à effectuer sur l'instance en attachant une stratégie AWS Identity and Access
Management (IAM) qui accorde les autorisations requises au rôle.
Pour transférer un rôle (et ses autorisations) à un service AWS, un utilisateur doit disposer des
autorisations nécessaires pour « transférer le rôle « au service. Cela permet aux administrateurs de
s'assurer que seuls les utilisateurs autorisés peuvent configurer un service avec un rôle qui accorde
des autorisations. Pour permettre à un utilisateur de transférer un rôle à un service AWS, vous devez
accorder l'autorisation PassRole à l'utilisateur IAM, au rôle ou au groupe de l'utilisateur.
Lorsqu'un utilisateur transfère un ARN de rôle en tant que paramètre à une API qui utilise le rôle pour
attribuer des autorisations au service, le service vérifie que l'utilisateur qui exécute l'action dispose de
l'autorisation iam:PassRole. Pour que l'utilisateur transfère uniquement les rôles approuvés, vous
pouvez filtrer l'autorisation iam:PassRole à l'aide de l'élément Resources de l'instruction de stratégie
IAM.
Exemple 1
Imaginons que vous vouliez accorder à un utilisateur la possibilité de transférer l'un des ensembles de
rôles approuvés au service Amazon EC2 lors du lancement d'une instance. Vous avez besoin de trois
éléments :
• Une stratégie d'autorisations IAM attachée au rôle qui détermine les opérations pouvant être
exécutées par le rôle. Limitez les autorisations aux seules actions nécessaires pour le rôle et aux
seules ressources dont le rôle a besoin pour exécuter ces actions. Vous pouvez utiliser une stratégie
d'autorisations IAM gérée par AWS ou créée par le client.
{
"Version": "2012-10-17",
"Statement": {
217
"Effect": "Allow",
"Action": [ "A list of the permissions the role is allowed to
use" ],
"Resource": [ "A list of the resources the role is allowed to
access" ]
}
}
• Une stratégie d'approbation pour le rôle, qui permet au service d'assumer le rôle. Par
exemple, vous pourriez attacher la stratégie d'approbation suivante au rôle avec l'action
UpdateAssumeRolePolicy. Cette stratégie d'approbation permet à Amazon EC2 d'utiliser le rôle
et les autorisations attachées au rôle.
{
"Version": "2012-10-17",
"Statement": {
"Sid":
"TrustPolicyStatementThatAllowsEC2ServiceToAssumeTheAttachedRole"
"Effect": "Allow",
"Principal": { "Service": "ec2.amazonaws.com" },
}
}
• Une stratégie d'autorisations IAM attachée à l'utilisateur IAM, qui permet à l'utilisateur de transférer
uniquement les stratégies qui sont approuvées. iam:PassRole est généralement accompagné de
iam:GetRole, afin que l'utilisateur puisse obtenir les détails du rôle à transférer. Dans cet exemple,
l'utilisateur peut transférer uniquement les rôles dont les noms commencent par EC2-roles-forXYZ- :
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"iam:GetRole",
"iam:PassRole"
],
"Resource": "arn:aws:iam::*:role/EC2-roles-for-XYZ-*"
}],
}
L'utilisateur peut maintenant démarrer une instance Amazon EC2 avec un rôle affecté. Les applications
qui s'exécutent sur l'instance peuvent accéder à des informations d'identification temporaires pour
le rôle via les métadonnées du profil d'instance. Les stratégies d'autorisations attachées au rôle
déterminent ce que peut faire l'instance.
Exemple 2
Amazon Relational Database Service (Amazon RDS) prend en charge une fonctionnalité appelée
Enhanced Monitoring (surveillance améliorée), qui permet à Amazon RDS de surveiller une instance
de base de données à l'aide d'un agent et d'indiquer des mesures dans les journaux Amazon
CloudWatch. Pour permettre à un utilisateur d'activer la surveillance améliorée pour les bases de
données de votre organisation, vous devez configurer Amazon RDS avec un rôle IAM qu'il assume et
qui lui accorde les autorisations nécessaires pour surveiller et écrire des mesures dans vos journaux.
Si l'utilisateur qui configure Amazon RDS était autorisé à créer des rôles et à leur attacher des
stratégies, l'utilisateur peut utiliser la fonctionnalité de surveillance améliorée dans la console Amazon
218
RDS pour créer le rôle en son nom. Toutefois, dans cet exemple, l'utilisateur ne disposant pas des
autorisations nécessaires pour créer des rôles, vous devez créer le rôle à l'avance. Vous pouvez
ensuite accorder à cet utilisateur l'autorisation de « transférer » ce rôle vers Amazon RDS lors de
l'activation de la fonctionnalité de surveillance améliorée.
Pour créer un rôle pour la surveillance améliorée Amazon RDS
1.
2.
Cliquez sur Roles, puis sur Create new role.
3.
4.
Saisissez un nom pour le rôle, tel que Rôle-surveillance-RDS, puis cliquez sur Next step.
Sur la page Select Role Type, dans la liste AWS Service Roles, recherchez Amazon RDS Role for
Enhanced Monitoring, puis cliquez sur Select.
Sur la page Attach Policy, sélectionnez AmazonRDSEnhancedMonitoringRole, cliquez sur Next
Step, puis sur Create Role.
5.
Le rôle obtient automatiquement une stratégie d'approbation qui accorde au service
monitoring.rds.amazonaws.com les autorisations nécessaires pour assumer le rôle. Une fois
cette opération effectuée, Amazon RDS peut exécuter toutes les actions autorisées par la stratégie
AmazonRDSEnhancedMonitoringRole.
L'utilisateur pour lequel vous souhaitez activer la surveillance améliorée a besoin d'une stratégie
incluant une instruction qui permet à l'utilisateur de transférer le rôle, comme suit. Utilisez votre numéro
de compte et remplacez le nom du rôle par le nom que vous avez indiqué à l’étape 3 :
{
"SID": "PolicyStatementToAllowUserToPassOneSpecificRole",
"Effect": "Allow",
"Action": [ "iam:PassRole" ],
"Resource": "arn:aws:iam:::role/RDS-Monitoring-Role"
}
Vous pouvez combiner cette instruction avec des instructions d'une autre stratégie ou la placer dans
sa propre stratégie. Au lieu de spécifier que l'utilisateur peut transférer un rôle commençant par RDS-,
vous pouvez remplacer le nom du rôle dans l'ARN d'une ressource par un caractère générique, par
exemple :
"Resource": "arn:aws:iam:::role/RDS-*"
Assumer un rôle (AWS Management Console)
Un rôle spécifie un ensemble d'autorisations que vous pouvez utiliser pour accéder aux ressources
AWS dont vous avez besoin. A cet égard, il est similaire à un utilisateur dans AWS Identity and Access
Management (IAM). Lorsque vous vous connectez en tant qu'utilisateur, un ensemble spécifique
d'autorisations vous est affecté. Toutefois, vous ne vous connectez pas au rôle mais, une fois
connecté, vous pouvez assumer un rôle. Ceci annule temporairement vos autorisations utilisateur
d'origine et les remplace par celles affectées au rôle. Le rôle peut être dans votre propre compte ou
dans un autre compte AWS. Pour plus d'informations sur les rôles, leurs avantages et la façon de les
créer, consultez Rôles IAM (p. 140) et Création de rôles IAM (p. 187).
Important
Les autorisations de votre utilisateur IAM et des rôles que vous assumez ne peuvent pas être
cumulées. Un seul ensemble d'autorisations peut être actif à la fois. Lorsque vous assumez
un rôle, vous abandonnez temporairement vos autorisations utilisateur et travaillez avec
219
celles qui sont affectées au rôle. Lorsque vous quittez le rôle, vos autorisations utilisateur sont
automatiquement restaurées.
Cette section décrit comment utiliser la console IAM pour assumer un rôle :
• Pour assumer un rôle, vous devez être connecté en tant qu’utilisateur IAM. Il n'est pas possible
d'assumer un rôle si vous êtes connecté en tant qu’utilisateur racine du compte AWS.
• Si votre administrateur vous fournit un lien, cliquez dessus, puis passez à l'étape Step 5 (p. 221)
de la procédure suivante. Le lien vous dirige vers la page web appropriée et renseigne les
informations relatives à l'ID de compte (ou d'alias) et au nom de rôle pour vous.
Tip
Vous pouvez créer manuellement le lien vous même à l'aide du format suivant :
account=account_id_number&roleName=role_name&displayName=text_to_display
Où l'administrateur vous fournit l''id_de_compte et le nom_de_rôle. Pour le
texte_à_afficher, reportez-vous à l'explication fournie à l'étape 5 de la procédure
suivante.
Important
changement de rôle (Switch Role) dans la console AWS, l'ensemble Path et RoleName ne
• Vous pouvez changer manuellement de rôle à l'aide des informations fournies par votre
administrateur en procédant comme suit :
Pour assumer un rôle
1.
Connectez-vous à AWS Management Console en tant qu'utilisateur IAM et ouvrez la console IAM
à l'adresse https://console.aws.amazon.com/iam/.
2.
Dans la console IAM, cliquez sur votre nom utilisateur dans la barre de
navigation, en haut à droite. Elle devrait afficher les informations suivantes :
nom_utilisateur@ID_de_compte_ou_alias.
3.
Sous Identity, sélectionnez Switch Role. Si vous sélectionnez cette option pour la première fois,
une page contenant plus d'informations s'affiche. Après l'avoir lue, cliquez sur Switch Role. Si
vous désactivez les cookies de votre navigateur, cette page peut s'afficher de nouveau.
4.
Dans la page Switch Role, entrez l'ID ou l'alias de compte, ainsi que le nom du rôle que vous a
fourni l'administrateur.
Note
Si l'administrateur a créé le rôle avec un chemin d'accès tel que division_abc/
subdivision_efg/roleToDoXYZ, vous devez entrer le chemin d'accès complet et le
nom dans le champ Rôle. Si vous entrez uniquement le nom du rôle, la tentative échoue.
Important
220
changement de rôle (Switch Role) dans la console IAM, l'ensemble Path et RoleName ne
doit pas comporter plus de 64 caractères. Cette restriction est imposée par les cookies du
navigateur dans lesquels est stocké le nom du rôle.
5.
(Facultatif) Entrez le texte que vous voulez afficher dans la barre de navigation à la place de
votre nom utilisateur lorsque le rôle est actif. Un nom, basé sur les informations du compte et du
rôle, est suggéré, mais vous pouvez le modifier à votre convenance. Il est également possible
de sélectionner une couleur afin de mettre en évidence le nom d'affichage. Le nom et la couleur
peuvent vous aider à savoir quand le rôle est actif, ce qui modifie vos autorisations. Par exemple,
si un rôle vous permet d'accéder à l'environnement de test, sous Display Name, vous pouvez
utiliser le nom d'affichage Test et sélectionner le vert comme couleur d'affichage sous Display
Color. Pour un rôle qui vous donne accès à la production, sous Display Name, vous pouvez
spécifier le nom d'affichage Production et sélectionner le rouge comme couleur d'affichage sous
Display Color.
6.
Cliquez sur Switch Role. Le nom d'affichage et la couleur remplacent votre nom utilisateur dans
la barre de navigation et vous pouvez commencer à utiliser les autorisations que le rôle vous
accorde.
Tip
Les derniers rôles utilisés sont répertoriés dans le menu Identity. La prochaine fois que vous
devez assumer l'un de ces rôles, cliquez simplement sur son nom. Si le rôle n'est pas affiché
dans le menu Identity, il vous suffit d'entrer manuellement les informations se rapportant au
compte et au rôle.
Pour cesser d'utiliser un rôle
1.
Dans la console IAM, sélectionnez le nom d'affichage du rôle sous Display Name, dans la partie
droite de la barre de navigation.
2.
Sélectionnez Back to UserName. Le rôle et ses autorisations sont désactivés et les autorisations
associées à votre utilisateur et vos groupes IAM sont automatiquement restaurées.
Passer à un rôle IAM (AWS Command Line Interface)
d'autorisations vous est affecté. Toutefois, vous ne vous connectez pas au rôle mais, une fois connecté
en tant qu'utilisateur, vous pouvez passer à un rôle. Ceci annule temporairement vos autorisations
utilisateur d'origine et les remplace par celles affectées au rôle. Le rôle peut être dans votre propre
compte ou dans un autre compte AWS. Pour plus d'informations sur les rôles, leurs avantages
et la façon de les créer et de les configurer, consultez Rôles IAM (p. 140) et Création de rôles
IAM (p. 187).
Important
Vous pouvez exécuter une commande AWS CLI à l'aide d'un rôle uniquement lorsque vous
êtes connecté en tant qu'utilisateur IAM, en tant qu'utilisateur authentifié en externe (p. 148)
221
(SAML (p. 156) ou OIDC (p. 149)) utilisant déjà un rôle ou lorsqu'il est exécuté depuis une instance
Amazon EC2 attachée à un rôle via son profil d'instance. Il n'est pas possible de passer à un rôle si
vous êtes connecté en tant qu’utilisateur racine du compte AWS.
Cette section décrit comment changer de rôles lorsque vous utilisez la ligne de commande avec AWS
Command Line Interface.
Imaginons que vous ayez un utilisateur IAM pour travailler dans l'environnement de développement
et que vous avez occasionnellement besoin d'utiliser l'environnement de production dans la ligne de
commande à l'aide de l'AWS CLI. Un ensemble d'informations d'identification de clé d'accès est déjà
à votre disposition. Il peut s'agir de la paire de clés d'accès affectée à votre utilisateur IAM standard
ou, si vous vous êtes connecté en tant qu'utilisateur fédéré, de la paire de clés d'accès pour le rôle qui
vous a été affecté initialement. Si vos autorisations actuelles vous accordent la capacité d'assumer
un rôle spécifique, vous pouvez identifier ce rôle dans un « profil » dans les fichiers de configuration
de l'AWS CLI. Cette commande est ensuite exécutée avec les autorisations du rôle spécifié, pas
l'identité d'origine. Notez que lorsque vous spécifiez ce profil, et donc que vous utilisez le nouveau rôle,
dans une commande AWS CLI, vous ne pouvez pas faire usage de vos autorisations d'origine dans
le compte de développement au même moment, car seul un ensemble d'autorisations peut être en
vigueur à la fois.
Note
Pour des raisons de sécurité, vous pouvez utiliser AWS CloudTrail pour analyser l'utilisation
des rôles dans le compte. Pour identifier les actions d'un rôle dans les journaux CloudTrail,
vous pouvez utiliser le nom de session du rôle. Lorsque l'AWS CLI assume un rôle pour le
compte d'un utilisateur comme décrit dans cette rubrique, un nom de session du rôle est
créé automatiquement au format AWS-CLI-session-nnnnnnnn, dans lequel nnnnnnnn
est un nombre entier qui représente le temps en Heure Unix (nombre de secondes écoulées
depuis le 1er janvier 1970 à minuit UTC). Pour plus d'informations, consultez Référence à
l'événement CloudTrail dans le manuel AWS CloudTrail User Guide.
Pour changer de rôle à l'aide de l'AWS CLI
1.
Ouvrez une invite de commande et configurez votre profil par défaut pour utiliser la clé d'accès de
votre utilisateur IAM ou de votre rôle fédéré. Si vous avez utilisé l'AWS CLI précédemment, c'est
probablement déjà fait.
$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-west-2
Default output format [None]: json
Pour plus d'informations, consultez Configuration de l'AWS Command Line Interface dans le
manuel AWS Command Line Interface Guide de l'utilisateur.
2.
Créez un profil pour le rôle dans le fichier .aws/config. L'exemple suivant crée un profil appelé
« prodaccess » qui passe au rôle ProductionAccessRole dans le compte 123456789012.
Vous obtenez l'ARN du rôle auprès de l'administrateur du compte ayant créé le rôle. Lorsque
ce profil est appelé, l'AWS CLI utilise les informations d'identification du source_profile pour
demander les informations d'identification du rôle. De ce fait, l'identité référencée en tant que
source_profile doit disposer des autorisations sts:AssumeRole pour le rôle spécifié dans le
role_arn.
[profile prodaccess]
role_arn = arn:aws:iam::123456789012:role/ProductionAccessRole
source_profile = default
222
3.
Après avoir créé le profil, toutes les commandes AWS CLI spécifiant le paramètre -profile prodaccess s'exécute dans le cadre des autorisations attachées au rôle IAM
ProductionAccessRole à la place de l'utilisateur par défaut.
aws iam list-users --profile productionaccess
4.
Cette commande fonctionne si les autorisations affectées au ProductionAccessRole activent le
rattachement des utilisateurs au compte AWS actuel.
Pour revenir aux autorisations accordées par vos informations d'identification d'origine, exécutez
les commandes sans le paramètre --profile. L'AWS CLI utilise de nouveau les informations
d'identification de votre profil par défaut, que vous avez configuré dans Step 1 (p. 222).
Pour plus d'informations, consultez Endossement d'un rôle dans le manuel AWS Command Line
Interface Guide de l'utilisateur.
Passer à un rôle IAM (Outils pour Windows PowerShell)
d'autorisations vous est affecté. Toutefois, vous ne vous connectez pas au rôle mais, une fois
connecté, vous pouvez assumer un rôle. Ceci annule temporairement vos autorisations utilisateur
d'origine et les remplace par celles affectées au rôle. Le rôle peut être dans votre propre compte ou
créer et de les configurer, consultez Rôles IAM (p. 140) et Création de rôles IAM (p. 187).
Important
Cette section décrit comment changer de rôles lorsque vous utilisez la ligne de commande avec Outils
AWS pour Windows PowerShell.
Imaginons que vous ayez un compte dans l'environnement de développement et que vous avez
occasionnellement besoin d'utiliser l'environnement de production dans la ligne de commande à l'aide
de l'Outils pour Windows PowerShell. Un ensemble d'informations d'identification de clé d'accès est
déjà à votre disposition. Il peut s'agir d'une paire de clés d'accès peut être affectée à votre utilisateur
IAM standard ou, si vous vous connectez en tant qu'utilisateur fédéré, d'une paire de clés d'accès
pour le rôle qui vous a été affecté initialement. Ces informations d'identification vous permettent
d'exécuter le cmdlet Use-STSRole qui transmet l'ARN d'un nouveau rôle en tant que paramètre. Cette
commande renvoie es informations d'identification de sécurité temporaires du rôle demandé. Vous
pouvez ensuite utiliser ces informations d'identification dans les commandes PowerShell suivantes
avec les autorisations du rôle pour accéder aux ressources de la production. Bien que vous utilisiez ce
rôle, vous ne pouvez pas utiliser vos privilèges d'utilisateur avancé dans le compte Développement,
car un seul ensemble d'autorisations peut être effectif à la fois.
Note
Pour des raisons de sécurité, vous pouvez utiliser AWS CloudTrail pour analyser
l'utilisation des rôles dans le compte. Le cmdlet Use-STSRole doit inclure un paramètre RoleSessionName avec une valeur d'une longueur entre 2 et 64 caractères pouvant inclure
des lettres, des chiffres et les caractères =,.@-. Le nom de session du rôle identifie les
223
actions dans les journaux CloudTrail qui sont exécutées avec les informations d'identification
de sécurité temporaires. Pour plus d'informations, consultez Référence à l'événement
CloudTrail dans le manuel AWS CloudTrail User Guide.
en direct.
Pour changer de rôle dans l'Outils pour Windows PowerShell
1.
Ouvrez une invite de commande PowerShell et configurez le profil par défaut pour utiliser la
clé d'accès de votre utilisateur IAM actuel ou de votre rôle fédéré. Si vous avez utilisé l'Outils
pour Windows PowerShell précédemment, c'est probablement déjà fait. Notez que vous pouvez
changer de rôle uniquement si vous êtes connecté en tant qu’utilisateur IAM, pas en tant
qu'utilisateur du compte AWS.
PS C:\> Set-AWSCredentials -AccessKey AKIAIOSFODNN7EXAMPLE
-SecretKey wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY StoreAs MyMainUserProfile
PS C:\> Initialize-AWSDefaults -ProfileName MyMainUserProfile -Region uswest-2
Pour plus d'informations, consultez Utilisation d'informations d'identification AWS dans le manuel
Outils AWS pour Windows PowerShell Guide de l'utilisateur.
2.
Pour récupérer les informations d'identification du nouveau rôle, exécutez la commande suivante
pour passer au rôle RoleName dans le compte 123456789012. Vous obtenez l'ARN du rôle
auprès de l'administrateur du compte ayant créé le rôle. La commande nécessite que vous
fournissiez un nom de session également. Pour cela, n'importe quel texte fera l'affaire. La
commande suivante demande les informations d'identification et capture l'objet de propriété
Credentials dans l'objet des résultats renvoyés et le stocke dans la variable $Creds.
$Creds = (Use-STSRole -RoleArn "arn:aws:iam::123456789012:role/RoleName" RoleSessionName "MyRoleSessionName").Credentials
$Creds est un objet qui contient à présent les éléments AccessKeyId, SecretAccessKey et
SessionToken dont vous avez besoin dans la procédure suivante. Les exemples de commandes
suivants illustrent les valeurs habituelles.
PS C:\> $Creds.AccessKeyId
AKIAIOSFODNN7EXAMPLE
PS C:\> $Creds.SecretAccessKey
wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
PS C:\> $Creds.SessionToken
AQoDYXdzEGcaEXAMPLE2gsYULo
+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvSRyh0FW7jEXAMPLEW+vE/7s1HRp
XviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXAMPLE9/
g7QRUhZp4bqbEXAMPLENwGPy
Oj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UuysgsKdEXAMPLE1TVastU1A0SKFEXAMPLE
C
s8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87eNhyDHq6ikBQ==
PS C:\> $Creds.Expiration
Thursday, June 18, 2015 2:28:31 PM
224
3.
Pour utiliser ces informations d'identification dans n'importe quelle commande suivante, incluez-les
dans le paramètre -Credentials. Par exemple, la commande suivante utilise les informations
d'identification du rôle et fonctionne uniquement si le rôle a l'autorisation iam:ListRoles et peut
donc exécuter le cmdlet Get-IAMRoles :
get-iamroles -Credential $Creds
4.
Pour revenir à vos informations d'identification d'origine, il vous suffit d'arrêter d'utiliser le
paramètre -Credentials $Creds et d'autoriser PowerShell à revenir aux informations
d'identification stockées dans le profil par défaut.
Assumer un rôle IAM (API)
Management (IAM). Une application assume un rôle pour recevoir des autorisations pour effectuer les
tâches requises et interagir avec des ressources AWS. Le rôle peut être dans votre propre compte ou
créer et de les configurer, consultez Rôles IAM (p. 140) et Création de rôles IAM (p. 187).
Cette section décrit comment assumer des rôles à partir de code qui utilise l'API AWS.
en direct.
Pour assumer un rôle, une application appelle l'API AssumeRole AWS STS et transmet l'ARN
du rôle à utiliser. L'API AssumeRole retourne un ensemble d'informations d'identification de
sécurité temporaires que vous pouvez ensuite utiliser lors d'appels aux API AWS pour accéder aux
ressources du compte propriétaire du rôle. Les informations d'identification temporaires disposent
des autorisations définies dans la stratégie d'accès du rôle. L'appel de AssumeRole peut également
transmettre une stratégie supplémentaire qui permet de restreindre davantage (filtrer) les autorisations
des informations d'identification de sécurité temporaires retournées par l'API AssumeRole. Pour
appeler AssumeRole, vous devez disposer d'informations d'identification d'un utilisateur IAM ou
d'un rôle IAM. Il n'est pas possible d'appeler AssumeRole avec les informations d'identification d'un
utilisateur racine du compte AWS.
Note
Pour des raisons de sécurité, vous pouvez utiliser AWS CloudTrail pour analyser l'utilisation
des rôles dans le compte. L'appel de AssumeRole doit inclure un nom de session de rôle
comportant entre 2 et 64 caractères et composé de lettres, de chiffres ou des caractères
=,.@-. Le nom de session du rôle est utilisé dans les journaux CloudTrail pour identifier
les actions qui sont exécutées par les informations d'identification de sécurité temporaires.
Pour plus d'informations, consultez Référence à l'événement CloudTrail dans le manuel AWS
CloudTrail User Guide.
L'exemple Python suivant qui utilise l'interface Boto3 pour AWS (AWS SDK for Python (Boto)
V3) montre comment appeler AssumeRole et utiliser les informations d'identification de sécurité
temporaires retournées par AssumeRole pour répertorier tous les compartiments Amazon S3 du
compte propriétaire du rôle.
import boto3
# The calls to AWS STS AssumeRole must be signed with the access key ID
# and secret access key of an existing IAM user or by using existing
temporary
225
#
#
#
#
credentials such as those from antoher role. (You cannot call AssumeRole
with the access key for the root account.) The credentials can be in
environment variables or in a configuration file and will be discovered
automatically by the boto3.client() function. For more information, see
the
# Python SDK documentation:
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html#client
# create an STS client object that represents a live connection to the
# STS service
sts_client = boto3.client('sts')
# Call the assume_role method of the STSConnection object and pass the role
# ARN and a role session name.
assumedRoleObject = sts_client.assume_role(
RoleArn="arn:aws:iam::account-of-role-to-assume:role/name-of-role",
RoleSessionName="AssumeRoleSession1"
)
# From the response that contains the assumed role, get the temporary
# credentials that can be used to make subsequent API calls
credentials = assumedRoleObject['Credentials']
# Use the temporary credentials that AssumeRole returns to make a
# connection to Amazon S3
s3_resource = boto3.resource(
's3',
aws_access_key_id = credentials['AccessKeyId'],
aws_secret_access_key = credentials['SecretAccessKey'],
aws_session_token = credentials['SessionToken'],
)
# Use the Amazon S3 resource object that is now configured with the
# credentials to access your S3 buckets.
for bucket in s3_resource.buckets.all():
print(bucket.name)
Utilisation d'un rôle IAM pour accorder des autorisations à des
applications s'exécutant sur des instances Amazon EC2
Les applications qui s'exécutent sur une instance EC2 doivent inclure des informations d'identification
AWS dans leurs demandes d'API AWS. Vos développeurs peuvent stocker directement les
informations d'identification AWS dans l'instance EC2 et autoriser les applications de cette instance à
les utiliser. Toutefois, dans ce cas, ils doivent gérer les informations d'identification, les transmettre en
toute sécurité à chaque instance, puis mettre à jour chaque instance EC2 lorsqu'il convient d'effectuer
une rotation des informations d'identification. Ceci représente beaucoup de travail supplémentaire.
Au lieu de cela, il est recommandé d'utiliser un rôle IAM pour gérer les informations d'identification
temporaires pour les applications qui s'exécutent sur une instance EC2. Lors de l'utilisation d'un
rôle, il n'est pas nécessaire de distribuer d'informations d'identification à long terme à une instance
EC2. A la place, le rôle fournit des autorisations temporaires que les applications peuvent utiliser lors
d'appels à d'autres ressources AWS. Lorsque vous lancez une instance EC2, vous spécifiez un rôle
IAM à associer à celle-ci. Les applications qui s'exécutent sur l'instance peuvent ensuite utiliser les
informations d'identification de sécurité temporaires fournies pour le rôle pour signer les demandes
d'API.
L'utilisation de rôles pour l'octroi d'autorisations à des applications qui s'exécutent sur des instances
EC2 requiert une configuration supplémentaire. Une application qui s'exécute sur une instance EC2
226
est extraite d'AWS par le système d'exploitation virtuel. En raison de cette séparation supplémentaire,
une autre étape est nécessaire pour affecter un rôle AWS et les autorisations qui lui sont associées
à une instance EC2 et rendre ces dernières disponibles pour toutes ses applications. Cette étape
supplémentaire est la création d'un profil d'instance qui est attaché à l'instance. Le profil d'instance
contient le rôle et peut fournir les informations d'identification du rôle à une application qui s'exécute
sur l'instance. Ces informations d'identification peuvent ensuite être utilisées dans les appels d'API de
l'application pour accéder aux ressources et restreindre l'accès aux ressources spécifiées par le rôle
uniquement. Notez que vous ne pouvez affecter qu'un seul rôle à une instance EC2 à la fois et que
toutes les applications de l'instance partagent le même rôle et les mêmes autorisations.
Une telle utilisation des rôles présente plusieurs avantages. Dans la mesure où les informations
d'identification des rôles sont temporaires et font automatiquement l'objet d'une rotation, vous n'avez
pas à vous soucier de risques de sécurité à long terme. Par ailleurs, si vous utilisez le même rôle pour
plusieurs instances, toute modification apportée au rôle est automatiquement propagée à toutes les
instances.
Important
Un rôle est attribué à une instance EC2 lorsque vous lancez cette dernière. Il ne peut pas être
attribué à une instance en cours d'exécution. Si vous devez ajouter un rôle à une instance
en cours d'exécution, vous pouvez créer une image de l'instance, puis lancer une nouvelle
instance à partir de cette image à laquelle vous avez attribué le rôle souhaité.
Comment fonctionnent les rôles pour les instances EC2 ?
Dans l'illustration suivante, un développeur exécute une application sur une instance EC2 qui
requiert l'accès à un compartiment S3 nommé photos. Un administrateur crée le rôle Get-pics.
Le rôle comprend des stratégies qui accordent des autorisations de lecture pour le compartiment et
permettent au développeur de lancer le rôle avec une instance EC2. Lorsque l'application s'exécute
sur l'instance, elle peut accéder au compartiment photos en utilisant les informations d'identification
temporaires du rôle. L'administrateur n'a pas besoin d'accorder au développeur l'autorisation d'accéder
au compartiment photos et le développeur n'a à aucun moment besoin de partager ou gérer les
Application d'une instance EC2 qui accède à une ressource AWS
1. L'administrateur utilise IAM pour créer le rôle Get-pics. Dans la stratégie d'approbation du rôle,
l'administrateur spécifie que seules les instances EC2 peuvent assumer le rôle. Dans la stratégie
227
d'accès du rôle, l'administrateur définit des autorisations en lecture seule pour le compartiment
photos.
2. Un développeur lance une instance EC2 et lui affecte le rôle Get-pics.
Note
Si vous utilisez la console IAM, le profil d'instance est géré de manière quasiment
transparente pour vous. Toutefois, si vous utilisez l'AWS CLI ou l'API pour créer et gérer le
rôle et l'instance EC2, vous devez également créer le profil d'instance et lui affecter le rôle,
dans une procédure séparée. Ensuite, lorsque vous lancez l'instance, vous devez spécifier
le nom du profil d'instance à la place du nom de rôle.
3. Lorsque l'application est en cours d'exécution, elle obtient des informations d'identification de
sécurité temporaires à partir des métadonnées d'instance Amazon EC2, comme décrit dans
Extraction des informations d'identification de sécurité à partir des métadonnées d'instance. Il s'agit
d'informations d'identification de sécurité temporaires (p. 244) qui représentent le rôle et sont
valides pendant une période limitée.
Dans certains kits SDK AWS, le développeur peut utiliser un fournisseur qui gère de manière
transparente les informations d'identification de sécurité temporaires. (La documentation de chaque
kit SDK AWS décrit les fonctions prises en charge par le kit SDK pour la gestion des informations
d'identification.)
Sinon, l'application peut obtenir les informations d'identification temporaires directement à partir des
métadonnées d'instance de l'instance EC2. Les informations d'identification et les valeurs associées
se trouvent dans la catégorie iam/security-credentials/role-name (dans cet exemple, iam/
security-credentials/Get-pics) des métadonnées. Si l'application extrait les informations
d'identification des métadonnées de l'instance, elle peut les mettre en cache.
4. A l'aide des informations d'identification obtenues, l'application peut accéder au compartiment
photos. Compte tenu de la stratégie attachée au rôle Get-pics, l'application dispose d'autorisations
en lecture.
Les informations d'identification de sécurité temporaires disponibles sur l'instance font
automatiquement l'objet d'une rotation avant leur expiration, afin qu'un ensemble d'informations
d'identification valides soit toujours disponible. L'application doit simplement obtenir un nouvel
ensemble d'informations d'identification à partir des métadonnées de l'instance avant l'expiration
des informations d'identification actuelles. Si le kit SDK AWS gère les informations d'identification,
l'application n'a pas besoin de logique supplémentaire pour actualiser les informations
d'identification. En revanche, si l'application extrait les informations d'identification de sécurité
temporaires des métadonnées d'instance, puis les met en cache, elle doit obtenir un ensemble
d'informations d'identification actualisé toutes les heures, ou au moins 15 minutes avant l'expiration
des informations d'identification actuelles. Le délai d'expiration est inclut dans les informations
retournées dans la catégorie iam/security-credentials/role-name.
Autorisations requises pour l'utilisation de rôles avec Amazon EC2
Pour lancer une instance avec un rôle, le développeur doit avoir l'autorisation de lancer des instances
EC2 et de transmettre des rôles IAM.
Dans l'exemple suivant, la stratégie autorise les utilisateurs à lancer une instance avec un rôle
à l'aide d'AWS Management Console. La stratégie inclut des caractères génériques (*) pour
autoriser un utilisateur à transmettre un rôle et effectuer toutes les actions Amazon EC2. L'action
ListInstanceProfiles permet aux utilisateurs d'afficher tous les rôles disponibles dans le compte
AWS.
228
Example Stratégie qui autorise les utilisateurs à lancer une instance avec n'importe quel rôle à
l'aide de la console Amazon EC2
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"iam:PassRole",
"iam:ListInstanceProfiles",
"ec2:*"
],
"Resource": "*"
}]
}
Limitation des rôles pouvant être transmis à des instances EC2 (Utilisation de PassRole)
Vous pouvez utiliser l'autorisation PassRole pour spécifier les rôles qu'un utilisateur peut transmettre
à une instance EC2 lors de son lancement. Ceci évite que l'utilisateur exécute des applications ayant
davantage d'autorisations qu'il n'en possède, autrement dit qu'il soit en mesure d'obtenir des droits
élevés. Par exemple, supposons qu'une utilisatrice nommée Alice soit uniquement autorisée à lancer
des instances EC2 et à utiliser des compartiments Amazon S3, mais que le rôle qu'elle transmet à une
instance EC2 dispose d'autorisations permettant d'utiliser IAM et Amazon DynamoDB. Dans ce cas, il
est possible qu'Alice soit en mesure de lancer l'instance, de s'y connecter, d'obtenir des informations
d'identification de sécurité temporaires, puis d'effectuer plus d'actions IAM ou DynamoDB qu'elle n'est
autorisée à le faire.
Pour limiter les rôles qu'un utilisateur peut transmettre à une instance EC2, vous pouvez créer une
stratégie qui autorise l'action PassRole. Ensuite, vous attachez la stratégie à l'utilisateur (ou à un
groupe IAM auquel il appartient) qui lancera les instances EC2. Dans l'élément Resource de la
stratégie, vous répertoriez les rôles que l'utilisateur peut transmettre aux instances EC2. Lorsque
l'utilisateur lance une instance et lui associe un rôle, Amazon EC2 vérifie si l'utilisateur est autorisé à
transmettre ce rôle. Il est entendu que vous devez également vous assurer que le rôle que l'utilisateur
est autorisé à transmettre n'inclut pas plus d'autorisations qu'il n'est censé en avoir.
Note
L'action d'API PassRole est différente de RunInstances ou ListInstanceProfiles.
Il s'agit en fait d'une autorisation qu'AWS vérifie chaque fois qu'un rôle ARN est passé
comme paramètre à une API (ou que la console le fait pour l'utilisateur). Elle permet à un
administrateur de contrôler les rôles susceptibles d'être transmis et par quels utilisateurs. Dans
le cas présent, elle veille à ce que l'utilisateur soit autorisé à attacher un rôle spécifique à une
instance Amazon EC2.
229
Example stratégie qui autorise un utilisateur à lancer une instance EC2 avec un rôle spécifique
Dans l'exemple suivant, la stratégie autorise les utilisateurs à lancer une instance avec un rôle à l'aide
de l'API Amazon EC2. L'élément Resource spécifie l'ARN (Amazon Resource Name) d'un rôle. En
spécifiant l'ARN, la stratégie accorde à l'utilisateur l'autorisation de transmettre uniquement le rôle
Get-pics. Si l'utilisateur tente de spécifier un autre rôle lors du lancement d'une instance, l'action
échoue.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ec2:RunInstances",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:role/Get-pics"
}
]
}
Comment bénéficier du service ?
Pour comprendre le fonctionnement des rôles avec les instances EC2, vous devez utiliser la console
IAM pour créer un rôle, lancer une instance EC2 utilisant ce rôle, puis examiner l'instance en cours
d'exécution. Vous pouvez examiner les métadonnées de l'instance pour voir comment les informations
d'identification du rôle sont mises à sa disposition. Il est également possible d'étudier la façon dont une
application exécutée sur l'instance peut utiliser un rôle donné. Consultez les ressources suivantes pour
en savoir plus.
•
• Procédures SDK. La documentation des kits SDK AWS inclut des procédures qui montrent une
application exécutée sur une instance EC2 qui utilise les informations d'identification d'un rôle
pour lire un compartiment Amazon S3. Chacune des procédures suivantes comporte des étapes
similaires, avec un langage de programmation différent :
• Utilisation de rôles IAM pour des instances EC2 avec le kit SDK pour Java dans le manuel AWS
SDK for Java Developer Guide
• Utilisation de rôles IAM pour des instances EC2 avec le kit SDK pour .NET dans le manuel Kit
AWS SDK pour .NET Developer Guide
• Utilisation de rôles IAM pour des instances EC2 avec le kit SDK pour Ruby dans le manuel Kit
SDK AWS pour Ruby Developer Guide
Ces procédures comportent des instructions détaillées pour la création et la compilation d'un
exemple de programme, la création du rôle, le lancement de l'instance, la connexion à l'instance,
puis le déploiement et le test de l'exemple de programme.
Informations connexes
Pour en savoir plus sur la création de rôles pour des instances EC2, consultez les informations
suivantes :
• Pour plus d'informations sur l'utilisation de rôles IAM avec des instances Amazon EC2, consultez le
manuel Amazon EC2 Guide de l'utilisateur pour les instances Linux.
230
• Pour créer un rôle, consultez Création de rôles IAM (p. 187)
• Pour plus d'informations sur l'utilisation d'informations d'identification de sécurité temporaires,
consultez Informations d'identification de sécurité temporaires (p. 244).
• Si vous utilisez l'API ou l'interface de ligne de commande IAM, vous devez créer et gérer les profils
d'instance IAM. Pour plus d'informations sur les profils d'instance, consultez Utilisation de profils
d'instance (p. 231).
• Pour plus d'informations sur les informations d'identification des rôles dans les métadonnées
d'instance, consultez Extraction des informations d'identification de sécurité à partir des
métadonnées d'instance dans le manuel Amazon EC2 Guide de l'utilisateur pour les instances Linux.
Utilisation de profils d'instance
Un profil d'instance est un conteneur pour un rôle IAM que vous pouvez utiliser pour transmettre les
informations liées au rôle à une instance EC2 lorsque celle-ci démarre.
Gestion de profils d'instance à l'aide de la AWS Management Console
Si vous utilisez la AWS Management Console afin de créer un rôle pour Amazon EC2, celle-ci crée
automatiquement un profil d'instance et lui attribue le même nom que le rôle. Lorsque vous utilisez
ensuite la console Amazon EC2 pour lancer une instance avec un rôle IAM, vous pouvez sélectionner
un rôle à associer à l'instance. Sur la console, la liste qui s'affiche est une liste de noms de profils
d'instance. La console ne crée pas de profil d'instance pour un rôle qui n'est pas associé à Amazon
EC2.
Gestion des profils d'instance à l'aide de l'AWS CLI, Outils pour Windows PowerShell et l'API
AWS
Si vous gérez vos rôles à partir de l'AWS CLI, Outils pour Windows PowerShell, ou l'API AWS,
vous créez des rôles et des profils d'instance dans des actions distinctes. Vous pouvez donner aux
rôles et aux profils d'instance des noms différents. Vous devez donc connaître les noms de vos
profils d'instance, ainsi que les noms des rôles que ceux-ci contiennent pour pouvoir choisir le profil
d'instance correct lorsque vous lancez une instance EC2.
Note
Un profil d'instance ne peut contenir qu'un seul rôle IAM. Par contre, un rôle peut être inclus
dans plusieurs profils d'instance.
Vous pouvez utiliser les commandes suivantes pour gérer les profils d'instance dans un compte AWS.
Création d'un profil d'instance
• AWS CLI : aws iam create-instance-profile
• Outils pour Windows PowerShell : New-IAMInstanceProfile
• API AWS : CreateInstanceProfile
Ajout d'un rôle à un profil d'instance
• AWS CLI : aws iam add-role-to-instance-profile
• Outils pour Windows PowerShell : Add-IAMRoleToInstanceProfile
• API AWS : AddRoleToInstanceProfile
Affichage d'une liste de profils d'instance
231
• AWS CLI : aws iam list-instance-profiles, aws iam list-instance-profiles-forrole
• Outils pour Windows PowerShell : Get-IAMInstanceProfiles
• API AWS : ListInstanceProfiles, ListInstanceProfilesForRole
Obtention d'informations sur un profil d'instance
• AWS CLI : aws iam get-instance-profile
• Outils pour Windows PowerShell : Get-IAMInstanceProfile
• API AWS : GetInstanceProfile
Suppression d'un rôle d'un profil d'instance
• AWS CLI : aws iam remove-role-from-instance-profile
• Outils pour Windows PowerShell : Remove-IAMRoleFromInstanceProfile
• API AWS : RemoveRoleFromInstanceProfile
Suppression d'un profil d'instance
• AWS CLI : aws iam delete-instance-profile
• Outils pour Windows PowerShell : Remove-IAMInstanceProfile
• API AWS : DeleteInstanceProfile
Révocation des informations d'identification de sécurité
temporaires d'un rôle IAM
Warning
Si vous suivez les étapes indiquées sur cette page, l'accès à toutes les actions et les
ressources AWS sera refusé à tous les utilisateurs dont les sessions actuelles ont été créées
en assumant le rôle. Cela peut entraîner le risque pour les utilisateurs de perdre leur travail
non sauvegardé.
Lorsque vous permettez aux utilisateurs d'accéder à la AWS Management Console avec une session
de longue durée (par exemple, 12 heures), leurs informations d'identification temporaires n'expirent
pas aussi rapidement. Si les utilisateurs exposent par inadvertance leurs informations d'identification
à un tiers non autorisé, celui-ci dispose d'un accès pendant la durée de la session. Cependant, vous
pouvez révoquer immédiatement toutes les autorisations aux informations d'identification du rôle
émises avant un moment donné, si nécessaire. Toutes les informations d'identification temporaires
pour ce rôle qui ont été émises avant le moment spécifié deviennent non valides. Cela force tous les
utilisateurs à s'authentifier de nouveau et demande de nouvelles informations d'identification.
Lorsque vous révoquez les autorisations d'un rôle à l'aide de la procédure de cette rubrique, AWS
associe au rôle une nouvelle stratégie en ligne qui rejette toutes les autorisations à toutes les actions.
Il inclut une condition qui applique les restrictions uniquement si l'utilisateur a assumé le rôle avant le
moment où vous avez révoqué les autorisations. Si l'utilisateur assume le rôle après la révocation des
autorisations, la stratégie de rejet ne s'applique pas à cet utilisateur.
Important
Notez que cette stratégie de rejet s'applique à tous les utilisateurs du rôle spécifié, pas
seulement à ceux dont les sessions de console durent plus longtemps.
232
Gestion des rôles
Autorisations minimales pour révoquer les autorisations de session d'un rôle
Pour révoquer les autorisations de session d'un rôle avec succès, vous devez disposer de
l'autorisation AttachRolePolicy pour ce rôle. Cela vous permet d'ajouter la stratégie
AWSRevokeOlderSessions au rôle.
Révocation des autorisations de session
Pour révoquer les autorisations de session d'un rôle, procédez comme suit :
Pour refuser immédiatement toutes autorisations à tout utilisateur actuel des informations
d'identification du rôle
1.
2.
Dans le volet de navigation de IAM Dashboard, choisissez Roles, puis choisissez le nom (pas la
case à cocher) du rôle dont vous voulez révoquer les autorisations.
3.
Sur la page Récapitulatif du rôle sélectionné, choisissez l'onglet Revoke Sessions.
4.
Sur l'onglet Revoke Sessions, choisissez Revoke active Sessions.
5.
AWS vous demande de confirmer l'action. Choisissez Revoke active sessions sur la boîte de
dialogue.
IAM associe immédiatement une stratégie nommée AWSRevokeOlderSessions au rôle. La
stratégie refuse tout accès aux utilisateurs qui ont assumé le rôle avant le moment où vous avez
choisi Revoke active sessions. Tout utilisateur qui assume le rôle après que vous ayez choisi
Revoke active sessions n'est pas concerné.
Important
Lorsque vous mettez à jour des autorisations de stratégie existantes ou lorsque vous
appliquez une nouvelle stratégie à un utilisateur ou à une ressource, plusieurs minutes
peuvent s'écouler avant que la mise à jour de la stratégie prenne effet.
Note
Vous n'avez pas à vous soucier de penser à supprimer la stratégie. Tout utilisateur qui
assume le rôle après la révocation des sessions n'est pas concerné par la stratégie. Si, par
la suite, vous choisissez à nouveau de Revoke Sessions, l'horodatage de la stratégie est
actualisé et celle-ci refuse à nouveau toutes autorisations à tout utilisateur ayant assumé le
rôle avant la nouvelle heure spécifiée.
Pour plus d'informations, consultez Désactivation des autorisations affectées aux informations
d'identification de sécurité temporaires (p. 270).
Gestion des rôles IAM
Il peut arriver que vous deviez modifier ou supprimer les rôles que vous avez créés. Pour changer
un rôle, vous pouvez modifier les stratégies associées au rôle, modifier qui peut accéder au rôle et
modifier les autorisations que le rôle accorde aux utilisateurs. Vous pouvez également supprimer les
rôles dont vous n'avez plus besoin. Vous pouvez gérer vos rôles dans AWS Management Console,
l'AWS CLI et l'API.
Rubriques
• Modification d'un rôle (p. 234)
• Suppression de rôles ou de profils d'instance (p. 238)
233
Gestion des rôles
Modification d'un rôle
Vous pouvez changer ou modifier un rôle de différentes manières :
• Pour changer l'utilisateur d'un rôle, modifiez la stratégie d'approbation du rôle.
• Pour modifier les autorisations accordées par le rôle, modifiez la stratégie des autorisations du rôle
(ou les stratégies).
Vous pouvez utiliser l'AWS Management Console, les outils de ligne de commande AWS, l'Outils pour
Windows PowerShell ou l'API IAM pour effectuer ces modifications.
Rubriques
• Modification d'un rôle (AWS Management Console) (p. 234)
• Modification d'un rôle (outils de ligne de commande AWS ou l'API IAM) (p. 236)
Modification d'un rôle (AWS Management Console)
Vous pouvez utiliser l'AWS Management Console pour modifier un rôle.
Pour changer les mandataires approuvés ayant accès au rôle
1.
2.
Dans la liste des rôles de votre compte, choisissez le nom du rôle que vous souhaitez modifier.
3.
Choisissez l'onglet Trust Relationships, puis choisissez Edit Trust Relationship.
4.
Modifiez la stratégie d'approbation au besoin. Pour ajouter des mandataires approuvés, spécifiezles dans l'élément Principal. Rappelez-vous que les stratégies sont écrites au format JSON et
que les tableaux JSON sont entourés de crochets [ ] et séparés par des virgules. Par exemple,
l'extrait de stratégie suivant indique comment faire référence à deux comptes AWS dans l'élément
Principal :
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root",
"arn:aws:iam::444455556666:root"
]
},
Rappelez-vous qu'ajouter un compte à la stratégie d'approbation d'un rôle n'est qu'une partie de la
procédure d'établissement de la relation d'approbation. Par défaut, aucun utilisateur des comptes
approuvés ne peut assumer le rôle tant que l'administrateur de ce compte ne leur accorde pas
l'autorisation d'assumer le rôle en ajoutant l'ARN (Amazon Resource Name) du rôle à un élément
Allow pour l'action sts:AssumeRole. Pour plus d'informations, consultez la procédure suivante
et la rubrique Octroi d'autorisations à un utilisateur pour assumer un rôle (p. 215).
Si votre rôle peut être utilisé par un ou plusieurs services approuvés plutôt que des comptes AWS,
la stratégie peut contenir un élément similaire à ce qui suit :
"Principal": {
"Service": [
"opsworks.amazonaws.com",
"ec2.amazonaws.com"
]
},
234
Gestion des rôles
5.
Lorsque vous avez terminé vos modifications, choisissez Update Trust Policy pour les enregistrer.
Pour plus d'informations sur la syntaxe et la structure de la stratégie, consultez les
sections Présentation des stratégies IAM (p. 294) et Références des éléments de
stratégie IAM (p. 402).
Pour autoriser les utilisateurs d'un compte externe approuvé à utiliser le rôle
Pour plus d'informations sur cette procédure, consultez Octroi d'autorisations à un utilisateur pour
assumer un rôle (p. 215).
1.
Connectez-vous au compte AWS externe approuvé.
2.
Décidez si vous devez attacher les autorisations à un utilisateur ou à un groupe. Dans le volet de
navigation de la console IAM, choisissez Users ou Groups en conséquence.
3.
Choisissez le nom de l'utilisateur ou du groupe auquel vous souhaitez accorder l'accès, puis
sélectionnez l'onglet Permissions.
4.
• Pour modifier une stratégie gérée par le client, choisissez le nom de la stratégie. Si la page
Welcome to Managed Policies s'affiche, vous avez choisi une stratégie gérée AWS. Vous ne
pouvez pas modifier une stratégie gérée AWS. Pour plus d'informations sur la différence entre
les stratégies gérées AWS et les stratégies gérées par le client, consultez la section Stratégies
gérées et stratégies en ligne (p. 299).
• Pour modifier une stratégie en ligne, choisissez Edit Policy en regard du nom de la stratégie.
5.
Dans l'éditeur de stratégies, ajoutez un nouvel élément Statement spécifiant ce qui suit :
{
"Effect": "Allow",
"Resource": "arn:aws:iam::AWS account ID that contains the
role:role/role name"
}
Remplacez les valeurs en rouge avec les valeurs réelles de l'ARN du rôle dans le compte d'origine
que les utilisateurs de ce compte externe approuvé peuvent utiliser.
Rappelez-vous que vous ne pouvez disposer que d'un mot-clé Statement. En revanche, une
instruction peut disposer de plusieurs éléments dans un tableau, séparés par des virgules et
entourés d'accolades { }, et de tous les éléments entourés de crochets [ ].
6.
Suivez les invites à l'écran pour terminer de modifier la stratégie.
Pour plus d'informations sur la modification des stratégies gérées par le client dans l'AWS
Management Console, consultez Modification de stratégies gérées par le client (p. 326).
Pour plus d'informations sur la modification de stratégies en ligne dans l'AWS Management
Console, consultez Utilisation de stratégies en ligne à l'aide d'AWS Management
Console (p. 329).
Pour changer les autorisations autorisées par un rôle
1.
2.
Choisissez le nom du rôle à modifier, puis choisissez l'onglet Permissions.
3.
• Pour modifier une stratégie gérée par le client existante, choisissez le nom de la stratégie.
235
Gestion des rôles
Note
Si la page Welcome to Managed Policies s'affiche, vous avez choisi une stratégie gérée
AWS. Vous ne pouvez pas modifier une stratégie gérée AWS. Pour plus d'informations
sur la différence entre les stratégies gérées AWS et les stratégies gérées par le client,
consultez la section Stratégies gérées et stratégies en ligne (p. 299).
• Pour attacher une stratégie gérée existante, choisissez Attach Policy.
• Pour modifier une stratégie en ligne existante, choisissez Edit Policy en regard du nom de la
stratégie.
• Pour intégrer une nouvelle stratégie en ligne, choisissez Create Role Policy.
Pour obtenir des exemples de stratégies qui délèguent des autorisations par le biais de rôles,
consultez Exemples de stratégies pour la délégation d'accès (p. 210).
Pour plus d'informations sur les autorisations, consultez Présentation des stratégies
IAM (p. 294).
Modification d'un rôle (outils de ligne de commande AWS ou l'API IAM)
Vous pouvez utiliser l'interface ligne de commande AWS ou l'API IAM pour modifier un rôle.
Pour changer les mandataires approuvés ayant accès au rôle
1.
Si vous ne connaissez pas le nom du rôle que vous souhaitez modifier, utilisez l'une des
commandes suivantes pour répertorier les rôles dans votre compte :
• AWS CLI : aws iam list-roles
• Outils AWS pour Windows PowerShell : Get-IAMRoles
• API IAM : ListRoles
2.
(Facultatif) Pour afficher la stratégie d'approbation actuelle d'un rôle, utilisez l'une des commandes
suivantes :
• AWS CLI : aws iam get-role
• Outils AWS pour Windows PowerShell : Get-IAMRole
• API IAM : GetRole
3.
Pour modifier les mandataires approuvés ayant accès au rôle, créez un fichier texte avec la
stratégie d'approbation mise à jour. Vous pouvez utiliser l'éditeur de texte pour créer la stratégie.
Par exemple, l'extrait de stratégie suivant indique comment faire référence à deux comptes AWS
dans l'élément Principal :
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:root",
"arn:aws:iam::444455556666:root"
]
},
Rappelez-vous qu'ajouter un compte à la stratégie d'approbation d'un rôle n'est qu'une partie de la
procédure d'établissement de la relation d'approbation. Par défaut, aucun utilisateur des comptes
approuvés ne peut assumer le rôle tant que l'administrateur de ce compte ne lui en a pas accordé
l'autorisation. Pour ce faire, l'administrateur doit fournir l'ARN (Amazon Resource Name) du rôle à
236
Gestion des rôles
un élément Allow de l'action sts:AssumeRole. Pour plus d'informations, consultez la procédure
suivante et la rubrique Octroi d'autorisations à un utilisateur pour assumer un rôle (p. 215).
4.
Pour mettre à jour la stratégie d'approbation, utilisez l'une des commandes suivantes :
• AWS CLI : aws iam update-assume-role-policy
• Outils AWS pour Windows PowerShell : Update-IAMAssumeRolePolicy
• API IAM : UpdateAssumeRolePolicy
Pour autoriser les utilisateurs d'un compte externe approuvé à utiliser le rôle
Pour plus d'informations sur cette procédure, consultez Octroi d'autorisations à un utilisateur pour
assumer un rôle (p. 215).
1.
Commencez par créer une stratégie qui accorde des autorisations pour assumer le rôle. Par
exemple, la stratégie suivante contient les autorisations nécessaires minimales :
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Resource": "arn:aws:iam::AWS account ID that contains the
role:role/role name"
}
}
Créez un fichier JSON contenant une stratégie similaire à l'exemple précédent. Remplacez les
valeurs en rouge avec les valeurs réelles de l'ARN du rôle que les utilisateurs sont autorisés à
assumer. Après avoir créé la stratégie, utilisez l'une des commandes suivantes pour la charger
dans IAM :
• AWS CLI : aws iam create-policy
• Outils AWS pour Windows PowerShell : New-IAMPolicy
• API IAM : CreatePolicy
Le résultat de cette commande contient l'ARN de la stratégie. Notez cet ARN, car vous aurez
besoin de l'utiliser à une étape ultérieure.
2.
Décidez à quel utilisateur ou groupe attacher la stratégie. Si vous ne connaissez pas le nom de
l'utilisateur ou du groupe que vous souhaitez modifier, utilisez l'une des commandes suivantes
pour répertorier les utilisateurs ou les groupes dans votre compte :
• AWS CLI : aws iam list-users ou aws iam list-groups
• Outils AWS pour Windows PowerShell : Get-IAMUsers ou Get-IAMGroups
• API IAM : ListUsers ou ListGroups
3.
Utilisez l'une des commandes suivantes pour attacher la stratégie que vous avez créée à une
étape précédente à l'utilisateur ou au groupe :
• AWS CLI : aws iam attach-user-policy ou aws iam attach-group-policy
• Outils AWS pour Windows PowerShell : Register-IAMUserPolicy ou Register-IAMGroupPolicy
• API IAM : AttachUserPolicy ou AttachGroupPolicy
237
Gestion des rôles
Pour changer les autorisations autorisées par un rôle
1.
(Facultatif) Pour afficher les autorisations actuelles associées à un rôle, utilisez les commandes
suivantes :
• AWS CLI : aws iam list-role-policies (pour répertorier les stratégies en ligne) et aws iam listattached-role-policies (pour répertorier les stratégies gérées)
• Outils AWS pour Windows PowerShell : Get-IAMRolePolicies (pour répertorier les stratégies en
ligne) et Get-IAMAttachedRolePolicies (pour répertorier les stratégies gérées)
• API IAM : ListRolePolicies (pour répertorier les stratégies en ligne) et ListAttachedRolePolicies
(pour répertorier les stratégies gérées)
2.
La commande permettant de mettre à jour les autorisations du rôle varie selon que vous mettez à
jour une stratégie gérée ou une stratégie en ligne.
Pour mettre à jour une stratégie gérée, utilisez l'une des commandes suivantes pour créer une
nouvelle version de la stratégie gérée :
• AWS CLI : aws iam create-policy-version
• Outils AWS pour Windows PowerShell : New-IAMPolicyVersion
• API IAM : CreatePolicyVersion
Pour mettre à jour une stratégie en ligne, utilisez l'une des commandes suivantes :
• AWS CLI : aws iam put-role-policy
• Outils AWS pour Windows PowerShell : Write-IAMRolePolicy
• API IAM : PutRolePolicy
Suppression de rôles ou de profils d'instance
Si vous n'avez plus besoin d'un rôle, nous vous recommandons de le supprimer, ainsi que ses
autorisations associées afin de ne pas avoir d'entité non utilisée qui n'est pas surveillée ou tenue à jour
activement.
Si le rôle était associé à une instance EC2, vous pouvez également le supprimer du profil d'instance,
puis supprimer ce dernier.
Caution
Assurez-vous qu'aucune instance d'Amazon EC2 n'est en cours d'exécution avec le profil
de rôle ou d'instance que vous êtes sur le point de supprimer. La suppression d'un profil de
rôle ou d'instance qui est associé à une instance en cours d'exécution interrompt toutes les
applications en cours d'exécution sur l'instance.
Rubriques
• Suppression d'un rôle (AWS Management Console) (p. 239)
• Suppression d'un rôle (AWS CLI) (p. 239)
• Suppression d'un rôle (Outils pour Windows PowerShell) (p. 240)
• Suppression d'un rôle (API AWS) (p. 241)
• Informations connexes (p. 241)
238
Gestion des rôles
Suppression d'un rôle (AWS Management Console)
Lorsque vous utilisez l'AWS Management Console pour supprimer un rôle, IAM supprime également
automatiquement les stratégies associées au rôle, ainsi que tous les profils d'instance Amazon EC2
contenant le rôle.
Important
Si un rôle est associé à un profil d'instance Amazon EC2 et que le rôle et le profil d'instance
portent exactement le même nom, vous pouvez utiliser la console AWS pour supprimer le rôle
et le profil d'instance. Cela se produit automatiquement si vous les créez dans la console. Si
vous avez créé le rôle dans l'AWS CLI, l'Outils pour Windows PowerShell ou l'API AWS, le
rôle et le profil d'instance peuvent porter des noms différents et vous ne pouvez pas utiliser la
console pour les supprimer. À la place, vous devez utiliser l'AWS CLI, l'Outils pour Windows
PowerShell ou l'API AWS pour supprimer d'abord le rôle du profil d'instance, puis (dans une
étape distincte) supprimer le rôle.
Pour utiliser AWS Management Console pour supprimer un rôle
1.
2.
Dans le volet de navigation, choisissez Roles, puis activez la case à cocher en regard du nom du
rôle que vous souhaitez supprimer, pas le nom ou la ligne elle-même.
Pour Role Actions en haut de la page, sélectionnez Delete Role.
3.
4.
Dans la boîte de dialogue de confirmation, vérifiez les dernières données consultées dans le
service qui indiquent quels rôles, parmi ceux sélectionnés, ont accédé en dernier à un service
AWS. Cela vous permet de confirmer si le rôle est actif actuellement. Si vous souhaitez continuer,
choisissez Yes, Delete. Si vous êtes sûr, procédez à la suppression même si les dernières
données consultées dans le service sont toujours en cours de chargement.
Note
Vous ne pouvez pas utiliser la console pour supprimer un profil d'instance, sauf s'il porte
exactement le même nom que le rôle et que vous le supprimez dans le cadre du processus
de suppression d'un rôle comme décrit dans la procédure précédente. Pour supprimer un
profil d'instance sans supprimer également le rôle, vous devez utiliser l'AWS CLI, l'Outils pour
Windows PowerShell ou l'API AWS. Pour plus d'informations, consultez les sections suivantes.
Suppression d'un rôle (AWS CLI)
Lorsque vous utilisez l'AWS CLI pour supprimer un rôle, vous devez d'abord supprimer les stratégies
associées au rôle. De plus, si vous voulez supprimer le profil d'instance associé contenant le rôle, vous
devez le supprimer séparément.
Pour utiliser l'AWS CLI pour supprimer un rôle
1.
Si vous ne connaissez pas le nom du rôle que vous souhaitez supprimer, tapez la commande
suivante pour répertorier les rôles dans votre compte :
aws iam list-roles
Une liste de rôles avec leur ARN (Amazon Resource Name) s'affiche. Utilisez le nom du rôle, pas
l'ARN, pour faire référence aux rôles avec les commandes CLI. Par exemple, si un rôle à l'ARN
suivant : arn:aws:iam::123456789012:role/myrole, vous faites référence au rôle en tant
que myrole.
239
Gestion des rôles
2.
Supprimez le rôle de tous les profils d'instance dont il fait partie.
a.
Pour répertorier tous les profils d'instance auxquels un rôle est associé, tapez la commande
suivante :
aws iam list-instance-profiles-for-role --role-name role-name
b.
Pour supprimer le rôle d'un profil d'instance, tapez la commande suivante pour chaque profil
instance :
aws iam remove-role-from-instance-profile --instance-profilename instance-profile-name --role-name role-name
3.
Supprimez toutes les stratégies associées au rôle.
a.
Pour répertorier toutes les stratégies que contient le rôle, tapez la commande suivante :
aws iam list-role-policies --role-name role-name
b.
Pour supprimer chaque stratégie du rôle, tapez la commande suivante pour chaque stratégie :
aws iam delete-role-policy --role-name role-name --policy-name policyname
4.
Tapez la commande suivante pour supprimer le rôle :
aws iam delete-role --role-name role-name
5.
Si vous prévoyez pas de réutiliser les profils d'instance associés au rôle, vous pouvez taper la
commande suivante pour les supprimer :
aws iam delete-instance-profile --instance-profile-name instance-profilename
Suppression d'un rôle (Outils pour Windows PowerShell)
Lorsque vous utilisez Windows PowerShell pour supprimer un rôle, vous devez d'abord supprimer les
stratégies associées au rôle. De plus, si vous voulez supprimer le profil d'instance associé contenant le
rôle, vous devez le supprimer séparément.
Pour utiliser l'Outils pour Windows PowerShell pour supprimer un rôle
1.
Si vous ne connaissez pas le nom du rôle que vous souhaitez supprimer, tapez la commande
suivante pour répertorier les rôles dans votre compte :
PS C:\> Get-IAMRoles | Select RoleName
Utilisez le nom du rôle, pas l'ARN, pour faire référence aux rôles avec les applets de commande
PowerShell. Par exemple, si un rôle à l'ARN suivant : arn:aws:iam::123456789012:role/
myrole, vous faites référence au rôle en tant que myrole.
2.
Supprimez le rôle de tous les profils d'instance dont il fait partie. La commande suivante obtient la
liste de tous les profils d'instance contenant le rôle, supprime le rôle de chaque profil d'instance de
la liste, puis supprime les profils instance désormais vides. Si vous prévoyez pas de réutiliser les
profils d'instance, vous pouvez omettre le dernier applet de commande de la commande.
240
Rôles comparés aux stratégies basées sur les ressources
PS C:\> Get-IAMInstanceProfileForRole -RoleName RoleName | RemoveIAMRoleFromInstanceProfile -RoleName RoleName | Remove-IAMInstanceProfile
3.
Supprimez toutes les stratégies associées au rôle. La commande suivante obtient la liste de
toutes les stratégies attachées au rôle et détache chacune d'elles.
PS C:\> Get-IAMAttachedRolePolicies -RoleName RoleName | UnregisterIAMRolePolicy -RoleName RoleName
4.
Tapez la commande suivante pour supprimer le rôle :
PS C:\> Remove-IAMRole -RoleName RoleName
Suppression d'un rôle (API AWS)
Lorsque vous utilisez l'API IAM pour supprimer un rôle, vous devez d'abord supprimer les stratégies
associées au rôle. De plus, si vous voulez supprimer le profil d'instance associé contenant le rôle, vous
devez le supprimer séparément.
Pour utiliser l'API AWS pour supprimer un rôle
1.
Pour répertorier tous les profils d'instance dont fait partie un rôle, appelez
ListInstanceProfilesForRole.
Pour supprimer le rôle de tous les profils d'instance dont il fait partie, appelez
RemoveRoleFromInstanceProfile. Vous devez transmettre le nom du rôle et le nom du profil
d'instance.
2.
Si vous prévoyez pas de réutiliser un profil d'instance associé au rôle, vous appelez
DeleteInstanceProfile pour le supprimer.
Pour répertorier toutes les stratégies d'un rôle, appelez ListRolePolicies.
Pour supprimer toutes les stratégies associées au rôle, appelez DeleteRolePolicy. Vous devez
transmettre le nom du rôle et le nom de la stratégie.
3.
Appelez DeleteRole pour supprimer le rôle.
Informations connexes
Pour obtenir des informations générales sur les profils d'instance, consultez Utilisation de profils
d'instance (p. 231).
Différence entre les rôles IAM et les stratégies
basées sur les ressources
Pour certains services AWS, vous pouvez accorder un accès entre comptes à vos ressources. Pour
cela, vous attachez une stratégie directement à la ressource que vous souhaitez partager, au lieu
d'utiliser un rôle en tant que proxy. La ressource que vous souhaitez partager doit prendre en charge
les stratégies basées sur des ressources (p. 282). Contrairement à une stratégie basée sur un
utilisateur, une stratégie basée sur une ressource spécifie qui (sous forme de liste de numéros d'ID de
compte AWS) peut accéder à cette ressource.
L'accès entre comptes avec une stratégie basée sur une ressource présente un avantage comparée
à un rôle. Avec une ressource à laquelle on accède à l'aide d'une stratégie basée sur une ressource,
241
l'utilisateur continue d'utiliser le compte approuvé sans devoir renoncer à ses autorisations utilisateur
au profit des autorisations du rôle. Autrement dit, l'utilisateur continue d'avoir accès aux ressources
dans le compte approuvé au même moment où il a accès à la ressource dans le compte approuvé.
Cela est utile les tâches de copie des informations de ou vers la ressources partagée de l'autre
compte.
L'inconvénient est que tous les services ne prennent pas en charge les stratégies basées sur des
ressources. Quelques-uns des services AWS qui prennent en charge les stratégies basées sur des
ressources sont répertoriés ici :
• Compartiments Amazon S3 – la stratégie est attachée au compartiment, mais la stratégie contrôle
l'accès au compartiment et aux objets qu'il contient. Pour en savoir plus, accédez à Contrôle d'accès
• Rubriques Amazon Simple Notification Service (Amazon SNS) – pour plus d'informations, accédez
à Gestion de l'accès à vos rubriques SNS Amazon dans le manuel Amazon Simple Notification
Service Manuel du développeur.
• Files d'attente Amazon Simple Queue Service (Amazon SQS) – pour plus d'informations, accédez
à Annexe : langage de stratégie d'accès dans le manuel Amazon Simple Queue Service Manuel du
développeur.
Pour obtenir une liste complète du nombre croissant de services AWS prenant en charge l'attachement
de stratégie d'approbation aux ressources au lieu de mandataires, consultez Services AWS qui
fonctionnent avec IAM (p. 394) pour rechercher les services pour lesquels Oui figure dans la colonne
Basé sur une ressource.
À propos de la suppression d'autorisations AWS dans une
stratégie basée sur une ressource
Une fois qu'une accorde à votre compte AWS des autorisations comme mandataire dans sa stratégie
basée sur une ressource, vous pouvez ensuite déléguer des autorisations à des utilisateurs ou
groupes spécifiques dans votre compte AWS. Vous attachez une stratégie à l'utilisateur ou au groupe
auquel vous souhaitez déléguer les autorisations. Notez que vous ne pouvez déléguer que des
autorisations égales ou inférieures à celles accordées à votre compte par la ressource titulaire du
compte. Par exemple, si votre compte a l'accès complet aux ressources d'un autre compte AWS, vous
pouvez déléguer l'accès complet, l'accès à la liste ou tout autre accès partiel aux utilisateurs de votre
compte AWS. Si, d'un autre côté, votre compte a accès à la liste uniquement, vous pouvez déléguer
uniquement l'accès à la liste. Si vous essayez de déléguer davantage d'autorisations que n'en possède
votre compte, vos utilisateurs auront toujours accès uniquement à la liste. La figure suivante en est
l'illustration. Pour plus d'informations sur l'attachement d'une stratégie à un utilisateur ou à un groupe,
consultez Utilisation de stratégies (p. 323).
242
1. Le compte A accorde au compte B l'accès complet au compartiment S3 du compte A en nommant
le compte B comme mandataire dans la stratégie. En conséquence, le compte B est autorisé à
effectuer n'importe quelle action sur le compartiment du compte A, et l'administrateur du compte B
peut déléguer l'accès à ses utilisateurs dans le compte B.
2. L'administrateur du compte B accorde à l'utilisateur 1 l'accès en lecture seule au compartiment S3
du compte A. L'utilisateur 1 peut afficher les objets dans le compartiment du compte A. Le niveau
d'accès que le compte B peut déléguer équivaut, ou est inférieur, à l'accès dont dispose le compte.
Dans ce cas, l'accès complet accordé au compte B est limité à la lecture seule pour l'utilisateur 1.
3. L'administrateur du compte B n'accorde pas l'accès à l'utilisateur 2. Du fait que, par défaut, les
utilisateurs n'ont pas d'autorisations, sauf celles qui sont accordées explicitement, l'utilisateur 2 n'a
pas accès au compartiment Amazon S3 du compte A.
Important
Dans l'exemple précédent, si le compte B avait utilisé des caractères de remplacement (*)
pour accorder à l'utilisateur l'accès complet à toutes ses ressources, l'utilisateur 1 aurait eu
automatiquement accès aux ressources auxquelles le compte B a accès, y compris l'accès
accordé par d'autres comptes aux ressources de ces comptes. Dans ce cas, l'utilisateur 1
aurait accès à toutes les ressources du compte A accordées au compte B, en plus de celles
accordées explicitement à l'utilisateur 1.
IAM évalue les autorisations d'un utilisateur au moment où l'utilisateur fait une demande. Par
conséquent, si vous utilisez des caractères de remplacement (*) pour accorder aux utilisateurs
l'accès complet à vos ressources, les utilisateurs sont en mesure d'accéder à n'importe quelle
ressource auxquelles votre compte AWS a accès, même les ressources que vous ajoutez ou
auxquelles vous obtenez l'accès après avoir créé la stratégie de l'utilisateur.
243
Informations d'identification de sécurité temporaires
Pour plus d'informations sur les autorisations, les stratégies et le langage de stratégie d'accès que
vous utilisez pour écrire des stratégies, consultez Gestion de l'accès (p. 281).
Important
Accordez l'accès uniquement aux entités que vous approuvez, et accordez l'accès minimal
nécessaire. Chaque fois que l'entité approuvée est un autre compte AWS, celui-ci peut à son
tour déléguer l'accès à l'un de ses utilisateurs IAM. Le compte AWS approuvé peut déléguer
uniquement l'accès dont il bénéficie. Il ne peut pas déléguer plus d'accès que le compte n'en a
lui-même.
Informations d'identification de sécurité
temporaires
Vous pouvez utiliser AWS Security Token Service (AWS STS) pour créer et fournir aux utilisateurs des
informations d'identification de sécurité temporaires permettant de contrôler l'accès à vos ressources
AWS. Les informations d'identification de sécurité temporaires ont un fonctionnement presque
identique à celui des informations d'identification des clés d'accès à long terme que vos utilisateurs
IAM peuvent utiliser, à quelques différences près :
• Les informations d'identification de sécurité temporaires sont à court terme, comme leur nom
l'indique. Elles peuvent être configurées pour être valides de quelques minutes à plusieurs heures.
Une fois que les informations d'identification arrivent à expiration, AWS ne les reconnaît plus ou
n'autorise plus aucun accès aux demandes d'API effectuées avec elles.
• Les informations d'identification de sécurité temporaires ne sont pas stockées avec l'utilisateur, mais
sont générées automatiquement et fournies à l'utilisateur sur demande. Lorsque (ou même avant)
les informations d'identification de sécurité temporaires arrivent à expiration, l'utilisateur peut en
demander de nouvelles, tant qu'il y est autorisé.
Ces différences offrent les avantages suivants à utiliser des informations d'identification temporaires :
• Vous n'avez pas besoin de distribuer ou d'intégrer des informations d'identification de sécurité AWS
à long terme avec une application.
• Vous pouvez fournir l'accès à vos ressources AWS aux utilisateurs sans devoir définir une identité
AWS pour eux. Les informations d'identification temporaires servent de base aux rôles et à la
fédération d'identité (p. 140).
• Les informations d'identification de sécurité temporaires ont une durée de vie limitée. Vous n'avez
donc pas besoin de les faire tourner ou de les révoquer de manière explicite une fois celles-ci
devenues inutiles. Une fois que les informations d'identification de sécurité temporaires arrivent
à expiration, elles ne peuvent pas être réutilisées. Vous pouvez spécifier le délai de validité des
informations d'identification, jusqu'à une certaine limite.
Régions AWS STS et AWS
Les informations d'identification de sécurité temporaires sont générées par AWS STS. Par défaut,
AWS STS est un service global avec un point de terminaison unique à l'adresse https://
sts.amazonaws.com. Toutefois, vous pouvez choisir également d'effectuer des appels d'API
AWS STS aux points de terminaison dans une autre région prise en charge. Cela permet de réduire
la latence (décalage serveur) en envoyant des demandes aux serveurs situés dans une région
géographiquement plus proche de vous. Quelle que soit la région d'où proviennent vos informations
d'identification, elles fonctionnent dans le monde entier. Pour de plus amples informations, veuillez
consulter Activation et désactivation d'AWS STS dans une région AWS (p. 274).
244
Scénarios courants d'informations
d'identification temporaires
Scénarios courants d'informations d'identification
temporaires
Les informations d'identification temporaires sont utiles dans des scénarios impliquant la fédération
d'identité, la délégation, l'accès entre comptes et les rôles IAM.
Fédération des identités
Vous pouvez gérer vos identités utilisateur dans un système externe situé en dehors d'AWS et
accorder aux utilisateur qui se connectent depuis ces systèmes un accès leur permettant d'effectuer
des tâches AWS et d'accéder à vos ressources AWS. IAM prend en charge deux types de fédérations
d'identités. Dans les deux cas, les identités sont stockées en dehors d'AWS. La distinction réside dans
le fait que votre système externe se situe dans votre centre de données ou un tiers externe sur le web.
Pour plus d'informations sur les fournisseurs d'identité externes, consultez Fournisseurs d'identité et
fédération (p. 148).
• Fédération d'entité d'entreprise – Vous pouvez authentifier les utilisateurs du réseau de votre
organisation, puis leur accorder l'accès à AWS sans créer de nouvelles identités AWS pour eux ni
leur imposer de ses connecter avec un nom utilisateur et un mot de passe distincts. Cette procédure
s'appelle l'authentification unique (SSO) pour un accès temporaire. AWS STS prend en charge
les normes ouvertes comme Security Assertion Markup Language (SAML) 2.0, qui vous permet
d'utiliser Microsoft AD FS pour tirer parti de Microsoft Active Directory. SAML 2.0 vous permet
également de gérer votre propre solution pour fédérer les identités des utilisateurs. Pour de plus
amples informations, veuillez consulter A propos de la fédération SAML 2.0 (p. 156).
• Broker de fédération personnalisé – Vous pouvez utiliser le système d'authentification de votre
organisation pour accorder l'accès aux ressources AWS. Pour obtenir un exemple de scénario,
consultez Création d'une URL qui permet aux utilisateurs fédérés d'accéder à AWS Management
Console (Broker de fédération personnalisé) (p. 178).
• Fédération à l'aide de SAML 2.0 – Vous pouvez utiliser le système d'authentification de votre
organisation et SAML pour accorder l'accès aux ressources AWS. Pour obtenir des informations et
un exemple de scénario, consultez A propos de la fédération SAML 2.0 (p. 156).
• Fédération d'identité web – Vous pouvez autoriser vos utilisateurs à se connecter à un fournisseur
d'identité tiers reconnu comme Login with Amazon, Facebook, Google ou tout autre fournisseur
compatible avec OpenID Connect (OIDC) 2.0. Vous pouvez échanger les informations
d'identification de ce fournisseur avec des informations d'identification temporaires pour utiliser les
ressources de votre compte AWS. Cette procédure s'appelle la fédération d'identité web pour un
accès temporaire. Lorsque vous utilisez la fédération d'identité web pour votre application mobile ou
web, vous n'avez pas besoin de créer un code de connexion personnalisé ni de gérer vos propres
identités utilisateur. La fédération d'identité web vous permet de mieux sécuriser votre compte AWS,
car vous n'avez pas à distribuer d'informations d'identification de sécurité à long terme, comme des
clés d'accès d'utilisateur IAM, dans votre application. Pour de plus amples informations, veuillez
consulter A propos de la fédération d'identité web (p. 149).
La fédération d'identité web AWS STS prend en charge Login with Amazon, Facebook, Google et
tout fournisseur d'identité compatible avec OpenID Connect (OICD).
Note
Pour les applications mobiles, nous vous recommandons d'utiliser Amazon Cognito. Vous
pouvez utiliser ce service avec le kit SDK AWS Mobile pour iOS et le kit SDK AWS Mobile
pour Android et Fire OS pour créer des identités uniques pour les utilisateurs afin de les
authentifier pour un accès sécurisé à vos ressources AWS. Amazon Cognito prend en
charge les mêmes fournisseurs d'identité que AWS STS, ainsi que l'accès non authentifié
(invité) et vous permet de migrer les données utilisateur quand un utilisateur se connecte.
Amazon Cognito fournit également des API pour la synchronisation des données utilisateur
245
Obtention d'informations
d'identification temporaires de sécurité
afin de les conserver à mesure que les utilisateurs passent d'un périphérique à l'autre. Pour
plus d'informations, consultez les ressources suivantes :
• Identité Amazon Cognito dans le Guide du développeur AWS Mobile SDK pour iOS.
• Identité Amazon Cognito dans le Guide du développeur AWS Mobile SDK pour Android.
Rôles pour l'accès entre comptes
De nombreuses organisations gèrent plusieurs comptes AWS. À l'aide des rôles et de l'accès entre
comptes, vous pouvez définir des identités utilisateur dans un compte et utiliser ces identités pour
accéder aux ressources AWS dans d'autres comptes qui appartiennent à votre organisation. Cette
procédure s'appelle la délégation pour un accès temporaire. Pour de plus amples informations, veuillez
consulter Création d'un rôle pour la délégation d'autorisations à un utilisateur IAM. (p. 187).
Rôles pour Amazon EC2
Si vous exécutez des applications sur des instances Amazon EC2et que ces applications doivent
accéder à des ressources AWS, vous pouvez fournir des informations d'identification de sécurité
temporaires à vos instances lorsque vous les lancez. Ces informations d'identification de sécurité
temporaires sont disponibles pour toutes les applications qui s'exécutent sur l'instance, vous n'avez
donc pas besoin de stocker des informations d'identification à long terme sur l'instance. Pour de plus
amples informations, veuillez consulter Utilisation d'un rôle IAM pour accorder des autorisations à des
Autres services AWS
Vous pouvez utiliser des informations d'identification de sécurité temporaires pour accéder à la plupart
des services AWS. Pour obtenir une liste des services qui acceptent les informations d'identification de
sécurité temporaires, consultez la section Services AWS qui fonctionnent avec IAM (p. 394).
Obtention d'informations d'identification temporaires
de sécurité
Pour obtenir des informations d'identification de sécurité temporaires, vous pouvez utiliser les actions
d'API AWS STS.
Un appel d'API peut se faire à l'aide de l'un des kits SDK AWS, disponibles pour de nombreux
langages de programmation et environnements tels que Java, .NET, Python, Ruby, Android et iOS.
Ces kits SDK exécutent des tâches telles que la signature cryptographique de vos demandes, les
nouvelles tentatives de demande, lorsque cela est nécessaire, ainsi que la gestion des réponses
d'erreur. Vous pouvez également utiliser l'API de requête AWS STS, décrite dans AWS Security Token
Service API Reference. Enfin, deux outils de ligne de commande prennent en charge les commandes
AWS STS à savoir l'AWS Command Line Interface et les Outils AWS pour Windows PowerShell.
Les actions d'API AWS STS retournent des informations d'identification temporaires qui incluent
une clé d'accès et un jeton de sécurité. La clé d'accès comprend un ID de clé d'accès et une clé
secrète. Ces informations d'identification permettent aux utilisateurs (ou une application exécutée
par l'utilisateur) d'accéder à vos ressources. Lors de leur création, les informations d'identification
sont associées à une stratégie de contrôle d'accès IAM qui limite les actions que l'utilisateur peut
effectuer à l'aide de ces informations. Pour de plus amples informations, veuillez consulter Utilisation
des informations d'identification de sécurité temporaires pour demander un accès aux ressources
AWS. (p. 257).
Important
Bien que la validité des informations d'identification de sécurité temporaires soit de courte
durée, les utilisateurs disposant d'un accès temporaire à vos ressources AWS peuvent
246
modifier ces dernières de manière durable. Par exemple, si un utilisateur disposant d'un accès
temporaire lance une instance Amazon EC2, l'instance peut continuer à s'exécuter et entraîner
des frais sur votre compte AWS et ce, même après l'expiration des informations d'identification
temporaires de l'utilisateur.
Note
La taille du jeton de sécurité retourné par les API STS n'est pas fixe. Nous vous
recommandons fortement de ne pas formuler d'hypothèses quant à sa taille maximale. A la
date de cette publication, la taille standard du jeton est inférieure à 4 096 octets, mais elle
peut varier. Par ailleurs, les futures mises à jour d'AWS peuvent nécessiter des tailles plus
importantes.
Utilisation d'AWS STS avec les régions AWS
Vous pouvez acheminer les appels d'API AWS STS vers un point de terminaison global ou des
points de terminaison régionaux. En choisissant un point de terminaison plus proche de vous, il est
possible de réduire la latence et d'améliorer les performances de vos appels d'API. Vous pouvez
également diriger vos appels vers un autre point de terminaison régional si vous n'êtes plus en
mesure de communiquer avec le point de terminaison initial. Si vous utilisez un des kits SDK AWS
disponibles, utilisez sa méthode pour sélectionner une région avant d'effectuer l'appel d'API. Si vous
créez manuellement des demandes d'API HTTP, vous devez les diriger vous-même vers le point de
terminaison approprié. Pour plus d'informations, consultez la section AWS STS de Régions et points
de terminaison et Activation et désactivation d'AWS STS dans une région AWS (p. 274).
Voici les API que vous pouvez utiliser pour l'obtention d'informations d'identification temporaires à
utiliser dans votre environnement et vos applications AWS
AssumeRole - Délégation entre comptes et fédération via un
broker d'identité personnalisé
Cette action d'API est utile, car elle permet aux utilisateurs IAM existants d'accéder aux ressources
AWS auxquelles ils n'ont pas encore accès, par exemple les ressources d'un autre compte AWS.
Elle permet également d'octroyer aux utilisateurs IAM existants un accès privilégié temporaire, par
exemple pour fournir l'authentification multi-facteurs (MFA). Vous devez appeler cette API à l'aide des
informations d'identification d'utilisateurs IAM existants. Pour plus d'informations, consultez Création
d'un rôle pour la délégation d'autorisations à un utilisateur IAM. (p. 187) et Configuration de l'accès
aux API protégé par MFA (p. 109).
Cet appel doit être effectué à l'aide d'informations d'identification de sécurité AWS valides. Lorsque
vous effectuez cet appel, vous transmettez les informations suivantes :
• L'ARN (Amazon Resource Name) du rôle que l'application doit assumer.
• Le délai de validité des informations d'identification temporaires. La valeur minimale est 15 minutes
(900 secondes) et la valeur maximale (par défaut) est 1 heure (3 600 secondes). Cette valeur n'est
requise que si le délai d'expiration souhaité pour les informations d'identification temporaires est
inférieur à 1 h. Il ne s'agit pas de la durée d'une session de console que vous pouvez demander
à l'aide de ces informations d'identification. La demande au point de terminaison de fédération
d'un jeton de connexion à la console prend un paramètre SessionDuration qui spécifie la durée
maximale de la session de console, indépendamment du paramètre DurationSeconds sur cette
API. Pour plus d'informations, consultez Création d'une URL qui permet aux utilisateurs fédérés
• Un nom de session de rôle, qui se présente sous la forme d'une valeur de chaîne que vous pouvez
utiliser pour identifier la session. CloudTrail peut consigner cette valeur dans un journal pour vous
aider à distinguer les utilisateurs du rôle lors d'un audit.
247
• Eventuellement, une stratégie (au format JSON). Cette stratégie est combinée à la stratégie
associée au rôle. Si elle est spécifiée, les autorisations correspondent à l'intersection de celles
accordées au rôle et de celles accordées par cette stratégie. Vous pouvez utiliser cette stratégie
pour limiter davantage les autorisations d'accès associées aux informations d'identification
temporaires, au-delà des restrictions déjà en vigueur dans la stratégie d'accès du rôle. Notez qu'il
n'est pas possible d'utiliser cette stratégie pour élever le niveau des autorisations au-delà du niveau
d'accès défini pour le rôle assumé.
• Si la configuration utilise une authentification multi-facteurs (MFA), vous incluez l'identificateur d'un
dispositif MFA et le code unique fourni par ce dispositif.
• Une valeur ExternalID facultative qui peut être utilisée lorsque vous déléguez l'accès à votre compte
à un tiers. Cette valeur permet de s'assurer que seul le tiers spécifié peut accéder au rôle. Pour plus
d'informations, consultez Procédure d'utilisation d'un ID externe lorsque vous accordez l'accès à vos
ressources AWS à un tiers (p. 193).
L'exemple suivant illustre une demande et une réponse qui utilisent AssumeRole. Dans cet exemple,
la demande inclut le nom de la session nommée Bob. Le paramètre Policy inclut un document JSON
qui spécifie que les informations d'identification obtenues disposent d'autorisations d'accès à Amazon
S3 uniquement.
Example Requête
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=AssumeRole
&RoleSessionName=Bob
&RoleArn=arn:aws::iam::123456789012:role/demo
&Policy=%7B%22Version%22%3A%222012-10-17%22%2C%22Statement%22%3A%5B%7B
%22Sid%22%3A%20%22Stmt1%22%2C%22Effect%22%3A%20%22Allow%22%2C%22Action%22%3A
%20%22s3%3A*%22%2C%22Resource%22%3A%20%22*%22%7D%5D%7D
&DurationSeconds=3600
&ExternalId=123ABC
&AUTHPARAMS
Note
La valeur de stratégie indiquée dans l'exemple ci-dessus est la version encodée en URL de la
stratégie suivante :
{"Version":"2012-10-17","Statement":
[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:*","Resource":"*"}]}
Notez également que le paramètre AUTHPARAMS de l'exemple précédent est un espace
réservé destiné aux informations d'authentification, autrement dit à la signature que vous
devez inclure avec les demandes d'API HTTP AWS. Lors de la création de demandes d'API,
nous vous recommandons d'utiliser les kits SDK AWS, car ceux-ci gèrent diverses tâches pour
vous, notamment la signature des demandes. Si vous devez créer des demandes d'API et les
signer manuellement, consultez Signature de demandes AWS à l'aide de Signature Version 4
dans le manuel Référence générale d'Amazon Web Services pour savoir comment procéder.
Cette API prend en charge un paramètre de DurationSeconds qui spécifie le délai de validité des
informations d'identification temporaires. Il ne s'agit pas de la durée d'une session de console qui
peut demander d'utiliser ces informations d'identification temporaires. Vous pouvez demander un
jeton de connexion à la console en appelant le point de terminaison de fédération et en fournissant
les informations d'identification temporaires. Cette demande de console utilise un autre paramètre
SessionDuration de 12 heures au maximum. Pour plus d'informations, consultez Création d'une
248
URL qui permet aux utilisateurs fédérés d'accéder à AWS Management Console (Broker de fédération
Outre les informations d'identification de sécurité temporaires, la réponse inclut l'ARN (Amazon
Resource Name) de l'utilisateur fédéré et la date d'expiration des informations d'identification.
Example Réponse
<AssumeRoleResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<AssumeRoleResult>
<Credentials>
<SessionToken>
AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
+scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCR/oLxBA==
</SessionToken>
<SecretAccessKey>
wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
</SecretAccessKey>
<Expiration>2011-07-15T23:28:33.359Z</Expiration>
<AccessKeyId>AKIAIOSFODNN7EXAMPLE</AccessKeyId>
</Credentials>
<AssumedRoleUser>
<Arn>arn:aws:sts::123456789012:assumed-role/demo/Bob</Arn>
<AssumedRoleId>ARO123EXAMPLE123:Bob</AssumedRoleId>
</AssumedRoleUser>
<PackedPolicySize>6</PackedPolicySize>
</AssumeRoleResult>
<ResponseMetadata>
<RequestId>c6104cbe-af31-11e0-8154-cbc7ccf896c7</RequestId>
</ResponseMetadata>
</AssumeRoleResponse>
Note
AssumeRole stocke la stratégie dans un format compressé. AssumeRole retourne la taille
sous forme de pourcentage de la taxe maximale autorisée, ce qui vous permet d'ajuster les
paramètres d'appel. Pour plus d'informations sur les contraintes de taille applicables à la
stratégie, consultez AssumeRole dans le manuel &guide-sts-api;.
AssumeRoleWithWebIdentity - Fédération via un fournisseur
d'identité web
Cette API retourne un ensemble d'informations d'identification de sécurité temporaires pour des
utilisateurs fédérés authentifiés par le biais d'un fournisseur d'identité public tel que Login with Amazon,
Facebook, Google ou tout autre fournisseur d'identité compatible avec OpenID Connect (OIDC). Cette
API est utile pour créer des applications mobiles ou des applications web basées sur le client qui
requièrent l'accès à AWS et dans lesquelles les utilisateurs ne disposent pas de leurs propres identités
AWS ou IAM. Pour de plus amples informations, veuillez consulter A propos de la fédération d'identité
web (p. 149).
Note
Plutôt que d'appeler directement AssumeRoleWithWebIdentity, il est recommandé
d'appeler Amazon Cognito et le fournisseur d'informations d'identification Amazon Cognito
249
avec les kits SDK AWS pour le développement mobile. Pour plus d'informations, consultez les
Si vous n'utilisez pas Amazon Cognito, vous appelez l'action AssumeRoleWithWebIdentity AWS
STS. Il s'agit d'un appel non signé, ce qui signifie que l'application n'a pas besoin d'accéder aux
informations d'identification AWS pour effectuer l'appel. Lorsque vous effectuez cet appel, vous
transmettez les informations suivantes :
• L'ARN (Amazon Resource Name) du rôle que l'application doit assumer. Si votre application permet
aux utilisateurs de se connecter de plusieurs façons, vous devez définir plusieurs rôles, à raison d'un
rôle par fournisseur d'identité. L'appel de AssumeRoleWithWebIdentity doit inclure l'ARN du rôle
spécifique au fournisseur par le biais duquel l'utilisateur se connecte.
• Le jeton que l'IdP fourni à l'application une fois que celle-ci a authentifié l'utilisateur.
• Le délai de validité des informations d'identification temporaires. La valeur minimale est 15 minutes
(900 secondes) et la valeur maximale (par défaut) est 1 heure (3 600 secondes). Cette valeur n'est
requise que si le délai d'expiration souhaité pour les informations d'identification temporaires est
inférieur à 1 h. Il ne s'agit pas de la durée d'une session de console que vous pouvez demander
à l'aide de ces informations d'identification. La demande au point de terminaison de fédération
d'un jeton de connexion à la console prend un paramètre SessionDuration qui spécifie la durée
maximale de la session de console, indépendamment du paramètre DurationSeconds sur cette
API. Pour plus d'informations, consultez Création d'une URL qui permet aux utilisateurs fédérés
• Un nom de session de rôle, qui se présente sous la forme d'une valeur de chaîne que vous pouvez
utiliser pour identifier la session. CloudTrail peut consigner cette valeur dans un journal pour vous
aider à distinguer les utilisateurs du rôle lors d'un audit.
• Eventuellement, une stratégie (au format JSON). Cette stratégie est combinée à la stratégie
associée au rôle. Si elle est spécifiée, les autorisations correspondent à l'intersection de celles
accordées au rôle et de celles accordées par cette stratégie. Vous pouvez utiliser cette stratégie
pour limiter davantage les autorisations d'accès associées aux informations d'identification
temporaires, au-delà des restrictions déjà en vigueur dans la stratégie d'accès du rôle. Notez qu'il
n'est pas possible d'utiliser cette stratégie pour élever le niveau des autorisations au-delà du niveau
d'accès défini pour le rôle assumé.
Note
L'appel de AssumeRoleWithWebIdentity n'est pas signé (chiffré) et, par conséquent,
vous devez uniquement inclure cette stratégie facultative si la demande n'est pas envoyée
via un intermédiaire non fiable, susceptible de modifier la stratégie pour supprimer les
restrictions.
Lorsque vous appelez AssumeRoleWithWebIdentity, AWS vérifie l'authenticité du jeton. Par
exemple, selon le fournisseur utilisé, AWS peut appeler ce fournisseur et inclure le jeton transmis par
l'application. En supposant que le fournisseur d'identité valide le jeton, AWS retourne les informations
suivantes :
• Un ensemble d'informations d'identification de sécurité temporaires. Il s'agit d'un ID de clé d'accès,
d'une clé d'accès secrète et d'un jeton de session.
• L'ID de rôle et l'ARN du rôle assumé.
• Une valeur SubjectFromWebIdentityToken qui contient l'ID utilisateur unique.
Une fois que vous disposez d'informations d'identification de sécurité temporaires, vous pouvez les
utiliser pour effectuer des appels d'API AWS. Le processus est identique à un appel d'API AWS à
250
l'aide d'informations d'identification de sécurité à long terme, excepté que vous devez inclure le jeton
de session qui permettra à AWS de vérifier la validité des informations d'identification de sécurité
temporaires.
Votre application met en cache les informations d'identification. Comme indiqué précédemment,
par défaut, les informations d'identification expirent au bout d'une heure. Si vous n'utilisez pas
l'action AmazonSTSCredentialsProvider du kit SDK AWS, vous (ou votre application) devez appeler
de nouveau AssumeRoleWithWebIdentity afin d'obtenir un nouvel ensemble d'informations
d'identification de sécurité temporaires avant l'expiration des anciennes.
AssumeRoleWithSAML - Fédération via un fournisseur
d'identité d'entreprise compatible avec SAML 2.0
Cette API retourne un ensemble d'informations d'identification de sécurité temporaires pour les
utilisateurs fédérés qui sont authentifiés par le système d'identité existant de votre organisation
et qui utilisent SAML 2.0 (Security Assertion Markup Language) pour transmettre les informations
d'authentification et d'autorisation à AWS. Cette API s'avère utile pour les organisations qui ont intégré
leurs systèmes d'identité (par exemple, Windows Active Directory ou OpenLDAP) à un logiciel capable
de générer des assertions SAML pour fournir des informations sur l'identité et les autorisations des
utilisateurs (par exemple, Active Directory Federation Services ou Shibboleth). Pour de plus amples
informations, veuillez consulter A propos de la fédération SAML 2.0 (p. 156).
Il s'agit d'un appel non signé, ce qui signifie que l'application n'a pas besoin d'accéder aux informations
d'identification AWS pour effectuer l'appel. Lorsque vous effectuez cet appel, vous transmettez les
informations suivantes :
• L'ARN (Amazon Resource Name) du rôle que l'application doit assumer.
• L'ARN du fournisseur SAML créé dans IAM qui décrit le fournisseur d'identité.
• L'assertion SAML, encodée en Base64, qui a été fournie par le fournisseur d'identité SAML dans sa
réponse d'authentification SAML à la demande de connexion de votre application.
• Le délai de validité des informations d'identification temporaires. La valeur maximale (par défaut)
est 1 heure (3 600 secondes). Cette valeur n'est requise que si le délai d'expiration souhaité pour
les informations d'identification temporaires est inférieur à 1 h. La durée de validité minimale
des informations d'identification est de 15 minutes (900 secondes). Il ne s'agit pas de la durée
d'une session de console que vous pouvez demander à l'aide de ces informations d'identification.
La demande au point de terminaison de fédération d'un jeton de connexion à la console prend
un paramètre SessionDuration qui spécifie la durée maximale de la session de console,
indépendamment du paramètre DurationSeconds sur cette API. Pour plus d'informations,
consultez Création d'une URL qui permet aux utilisateurs fédérés d'accéder à AWS Management
Console (Broker de fédération personnalisé) (p. 178).
• Une stratégie (au format JSON). Cette stratégie est combinée à la stratégie associée au rôle. Si
elle est spécifiée, les autorisations correspondent à l'intersection de celles accordées au rôle et
de celles accordées par cette stratégie. Vous pouvez utiliser cette stratégie pour limiter davantage
les autorisations d'accès associées aux informations d'identification temporaires, au-delà des
restrictions déjà en vigueur dans la stratégie d'accès du rôle. Notez qu'il n'est pas possible d'utiliser
cette stratégie pour élever le niveau des autorisations au-delà du niveau d'accès défini pour le rôle
assumé.
Lorsque vous appelez AssumeRoleWithSAML, AWS vérifie l'authenticité de l'assertion SAML. En
supposant que le fournisseur d'identité valide l'assertion, AWS retourne les informations suivantes :
• Un ensemble d'informations d'identification de sécurité temporaires. Il s'agit d'un ID de clé d'accès,
d'une clé d'accès secrète et d'un jeton de session.
• L'ID de rôle et l'ARN du rôle assumé.
• Une valeur Audience qui contient la valeur de l'attribut Recipient de l'élément
SubjectConfirmationData de l'assertion SAML.
251
• Une valeur Issuer qui contient la valeur de l'élément Issuer de l'assertion SAML.
• Un élément NameQualifier qui contient une valeur de hachage créée à partir de la valeur Issuer,
l'ID de compte AWS et le nom convivial du fournisseur SAML. Lors de la combinaison avec l'élément
Subject, ils identifient de manière unique l'utilisateur fédéré.
• Un élément Subject qui contient la valeur de l'élément NameID dans l'élément Subject de
l'assertion SAML.
• Un élément SubjectType qui indique le format de l'élément Subject. La valeur peut être
persistent, transient ou l'URI Format complet des éléments Subject et NameID utilisés dans
votre assertion SAML. Pour plus d'informations sur l'attribut Format de l'élément NameID, consultez
Configuration des assertions SAML pour la réponse d'authentification (p. 171).
Une fois que vous disposez d'informations d'identification de sécurité temporaires, vous pouvez les
utiliser pour effectuer des appels d'API AWS. Le processus est identique à un appel d'API AWS à
l'aide d'informations d'identification de sécurité à long terme, excepté que vous devez inclure le jeton
de session qui permettra à AWS de vérifier la validité des informations d'identification de sécurité
temporaires.
Votre application met en cache les informations d'identification. Par défaut, les
informations d'identification expirent au bout d'une heure. Si vous n'utilisez pas l'action
AmazonSTSCredentialsProvider du kit SDK AWS, vous (ou votre application) devez appeler de
nouveau AssumeRoleWithSAML afin d'obtenir un nouvel ensemble d'informations d'identification de
sécurité temporaires avant l'expiration des anciennes.
GetFederationToken - Fédération via un broker d'identité
personnalisé
Cette API retourne un ensemble d'informations d'identification de sécurité temporaires pour les
utilisateurs fédérés. La différence entre cette API et AssumeRole réside dans le fait que le délai
d'expiration par défaut est considérablement plus long (jusqu'à 36 heures au lieu d'une heure
maximum). Un délai d'expiration plus long permet de réduire le nombre d'appels à AWS car il n'est
pas nécessaire d'obtenir de nouvelles informations d'identification aussi souvent. Pour de plus
amples informations, veuillez consulter Obtention d'informations d'identification temporaires de
sécurité (p. 246).
L'appel de GetFederationToken retourne des informations d'identification de sécurité temporaires
constituées d'un jeton de sécurité, d'une clé d'accès, d'une clé secrète et d'un délai d'expiration.
Vous pouvez utiliser GetFederationToken si vous souhaiter gérer les autorisations au sein
de l'organisation (par exemple, pour octroyer des autorisations à l'aide de l'application proxy).
Pour consulter un exemple d'application qui utilise GetFederationToken, accédez à l'Exemple
d'application de la fédération d'identité pour un cas d'utilisation d'Active Directory dans les Exemples
de code et bibliothèques AWS.
L'exemple suivant illustre une demande et une réponse qui utilisent GetFederationToken. Dans cet
exemple, la demande inclut le nom d'un utilisateur fédéré nommé Jean. Le paramètre Policy inclut
un document JSON qui spécifie que les informations d'identification obtenues disposent d'autorisations
d'accès à Amazon S3 uniquement. Outre les informations d'identification de sécurité temporaires,
la réponse inclut l'ARN (Amazon Resource Name) de l'utilisateur fédéré et la date d'expiration des
Example Requête
?Version=2011-06-15
&Action=GetFederationToken
&Name=Jean
252
&Policy=%7B%22Version%22%3A%222012-10-17%22%2C%22Statement%22%3A%5B%7B%22Sid
%22%3A%22Stmt1%22%2C%22Effect%22%3A%22Allow%22%2C%22Action%22%3A%22s3%3A*
%22%2C%22Resource%22%3A%22*%22%7D%5D%7D
&AUTHPARAMS
Note
La valeur de stratégie indiquée dans l'exemple ci-dessus est la version encodée en URL de la
stratégie suivante :
{"Version":"2012-10-17","Statement":
[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:*","Resource":"*"}]}
Notez également que le paramètre &AUTHPARAMS de l'exemple précédent est un espace
Example Réponse
<GetFederationTokenResponse xmlns="https://sts.amazonaws.com/
doc/2011-06-15/">
<GetFederationTokenResult>
<Credentials>
<SessionToken>
AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
+scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCEXAMPLE==
</SessionToken>
<SecretAccessKey>
</SecretAccessKey>
<AccessKeyId>AKIAIOSFODNN7EXAMPLE;</AccessKeyId>
</Credentials>
<FederatedUser>
<Arn>arn:aws:sts::123456789012:federated-user/Jean</Arn>
<FederatedUserId>123456789012:Jean</FederatedUserId>
</FederatedUser>
<PackedPolicySize>6</PackedPolicySize>
</GetFederationTokenResult>
<ResponseMetadata>
<RequestId>c6104cbe-af31-11e0-8154-cbc7ccf896c7</RequestId>
</ResponseMetadata>
</GetFederationTokenResponse>
Note
GetFederationToken stocke la stratégie dans un format compressé. L'action retourne la
taille sous forme de pourcentage de la taxe maximale autorisée, ce qui vous permet d'ajuster
253
les paramètres d'appel. Pour plus d'informations sur les contraintes de taille applicables à la
stratégie, consultez GetFederationToken dans le manuel &guide-sts-api;.
Si vous préférez octroyer des autorisations au niveau des ressources (par exemple, pour attacher une
stratégie à un compartiment Amazon S3), vous pouvez omettre le paramètre Policy. Toutefois, si
vous n'incluez pas de stratégie pour un utilisateur fédéré, les informations d'identification de sécurité
temporaires ne lui accordent aucune autorisation. Dans ce cas, vous devez utiliser des stratégies de
ressources pour accorder à l'utilisateur fédéré l'accès à vos ressources AWS.
Par exemple, si votre numéro de compte AWS est 111122223333, et que voulez accorder à
Susan l'accès à un compartiment Amazon S3 bien que ses informations d'identification de sécurité
temporaires n'incluent pas de stratégie pour ce compartiment, vous devez vous assurer que le
compartiment est doté d'une stratégie avec un ARN correspondant à celui de Susan, par exemple
arn:aws:sts::111122223333:federated-user/Susan.
GetSessionToken - Informations d'identification temporaires
pour les utilisateurs qui se trouvent dans des environnements
non fiables
Cette API retourne un ensemble d'informations d'identification de sécurité temporaires pour un
utilisateur IAM existant. Elle est utile pour fournir une sécurité renforcée, par exemple pour autoriser les
demandes AWS uniquement lorsque l'authentification multi-facteurs (MFA) est activée pour l'utilisateur
IAM. Dans la mesure où les informations d'identification sont temporaires, elles offrent une sécurité
améliorée lorsqu'un utilisateur IAM accède à vos ressources par le biais d'un environnement moins
sécurisé tel qu'un périphérique mobile ou un navigateur web. Pour plus d'informations, consultez
Obtention d'informations d'identification temporaires de sécurité (p. 246) ou GetSessionToken dans
le manuel AWS Security Token Service API Reference.
Par défaut, les informations d'identification de sécurité temporaires d'un utilisateur IAM restent valides
pendant 12 heures maximum, mais vous pouvez demander un délai de validité allant de 15 minutes à
36 heures. Pour des raisons de sécurité, la durée de validité du jeton de l'identité racine d'un compte
AWS est limitée à une heure.
GetSessionToken retourne des informations d'identification de sécurité temporaires constituées
d'un jeton de sécurité, d'un ID de clé d'accès et d'une clé d'accès secrète. L'exemple suivant illustre
une demande et une réponse qui utilisent GetSessionToken. La réponse inclut également l'heure
d'expiration des informations d'identification de sécurité temporaires.
Example Requête
?Version=2011-06-15
&Action=GetSessionToken
&AUTHPARAMS
Note
Le paramètre &AUTHPARAMS de l'exemple précédent est un espace réservé destiné aux
informations d'authentification, autrement dit à la signature que vous devez inclure avec
les demandes d'API HTTP AWS. Lors de la création de demandes d'API, nous vous
recommandons d'utiliser les kits SDK AWS, car ceux-ci gèrent diverses tâches pour vous,
notamment la signature des demandes. Si vous devez créer des demandes d'API et les signer
manuellement, consultez Signature de demandes AWS à l'aide de Signature Version 4 dans le
manuel Référence générale d'Amazon Web Services pour savoir comment procéder.
254
Example Réponse
<GetSessionTokenResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<GetSessionTokenResult>
<Credentials>
<SessionToken>
AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/L
To6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3z
rkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtp
Z3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE
</SessionToken>
<SecretAccessKey>
</SecretAccessKey>
<AccessKeyId>AKIAIOSFODNN7EXAMPLE</AccessKeyId>
</Credentials>
</GetSessionTokenResult>
<ResponseMetadata>
<RequestId>58c5dbae-abef-11e0-8cfe-09039844ac7d</RequestId>
</ResponseMetadata>
</GetSessionTokenResponse>
La demande GetSessionToken peut également inclure les valeurs SerialNumber et TokenCode
pour la vérification de l'authentification multi-facteurs (MFA) AWS. Si les valeurs spécifiées sont
valides, AWS STS fournit des informations d'identification de sécurité temporaires qui incluent l'état
de l'authentification MFA afin que les informations d'identification de sécurité temporaires puissent
être utilisées pour accéder à des actions d'API ou des sites web AWS protégés par MFA tant que
l'authentification MFA est valide.
L'exemple suivant illustre une demande GetSessionToken qui inclut un code de vérification et un
numéro de série de périphérique MFA.
?Version=2011-06-15
&Action=GetSessionToken
&SerialNumber=YourMFADeviceSerialNumber
&TokenCode=123456
&AUTHPARAMS
Note
L'appel d'AWS STS peut être dirigé vers un point de terminaison global ou tout point de
terminaison régional pour lequel vous activez votre compte AWS. Pour plus d'informations,
consultez la section AWS STS de Régions et points de terminaison.
Notez également que le paramètre &AUTHPARAMS de l'exemple précédent est un espace
255
Comparaison des API AWS STS
Le tableau suivant compare les fonctions des actions (API) AWS STS qui retournent des informations
d'identification de sécurité temporaires.
Comparaison des options d'API
API
AWS
STS
Qui peut appeler
Durée
Prise en Prise en Restrictions applicables aux
de vie
charge
charge
informations d'identification
des
de
des
temporaires générées
informationsl'authentification
stratégies
d'identification
MFA*
transmises*
(min/
max/par
défaut)
AssumeRole
Utilisateur IAM ou
15 mn/1 h/1 h
Oui
utilisateur disposant
d'informations
d'identification de
sécurité temporaires
existantes
Oui
Impossible d'appeler
GetFederationToken ou
GetSessionToken.
AssumeRoleWithSAML
N'importe quel
utilisateur ; le
mandataire doit
transmettre
une réponse
d'authentification
SAML qui spécifie
l'authentification
par un fournisseur
d'identité reconnu
15 mn/1 h/1 h
Non
Oui
GetSessionToken.
AssumeRoleWithWebIdentity
N'importe quel
utilisateur ; le
mandataire doit
transmettre un
jeton d'identité
web qui spécifie
l'authentification
par un fournisseur
d'identité reconnu
15 mn/1 h/1 h
Non
Oui
GetSessionToken.
GetFederationToken
Utilisateur IAM ou
compte racine
Utilisateur Non
IAM :
15 mn/36 h/12 h
Oui
directement les API IAM.
Connexion avec authentification
unique (SSO) à la console
autorisée.*
Compte
racine :
15 mn/1 h/1 h
GetSessionToken
Utilisateur IAM ou
compte racine
Utilisateur Oui
IAM :
15 mn/36 h/12 h
256
Impossible d'appeler les API
AWS STS à l'exception de
GetCallerIdentity.
Non
Impossible d'appeler les API
IAM si les informations MFA ne
figurent pas dans la demande.
API
AWS
STS
Utilisation des informations d'identification
de sécurité temporaires pour demander
aux ressources
Qui peut appeler un accès
Durée
Prise en AWS.
Prise en
Restrictions applicables aux
de vie
charge
charge
informations d'identification
des
de
des
temporaires générées
informationsl'authentification
stratégies
d'identification
MFA*
transmises*
(min/
max/par
défaut)
Compte
racine :
15 mn/1 h/1 h
Impossible d'appeler les
API AWS STS, à l'exception
de AssumeRole ou
GetCallerIdentity.
La connexion avec
authentification unique (SSO) à
la console n'est pas autorisée,
mais tout utilisateur disposant
d'un mot de passe (utilisateur
racine ou IAM) peut se
connecter à la console.*
• Prise en charge de l'authentification MFA. Lorsque vous appelez les API AssumeRole
et GetSessionToken, vous pouvez inclure des informations relatives à un périphérique
d'authentification multi-facteurs (MFA). De cette façon, les informations d'identification de sécurité
temporaires obtenues lors l'appel d'API peuvent uniquement être utilisées par des utilisateurs
authentifiés à l'aide d'un périphérique MFA. Pour de plus amples informations, veuillez consulter
Configuration de l'accès aux API protégé par MFA (p. 109).
• Prise en charge des stratégies transmises. Vous pouvez transmettre une stratégie IAM en tant
que paramètre à la plupart des API AWS STS afin qu'elle soit utilisée avec d'autres stratégies
affectant l'utilisateur (le cas échéant). Ceci permet de déterminer les actions que ce dernier peut
effectuer à l'aide des informations d'identification temporaires générées par l'appel d'API. Pour plus
d'informations, consultez les rubriques suivantes :
• Autorisations pour AssumeRole, AssumeRoleWithSAML et
AssumeRoleWithWebIdentity (p. 262)
• Autorisations pour GetFederationToken (p. 265)
• Autorisations pour GetSessionToken (p. 269)
• Connexion avec authentification unique (SSO) à la console. Afin de prendre en charge la connexion
avec authentification unique (SSO), AWS vous permet d'appeler un point de terminaison de
fédération (https://signin.aws.amazon.com/federation) et de transmettre des informations
d'identification de sécurité temporaires. Le point de terminaison retourne un jeton que vous pouvez
utiliser pour créer une URL qui connecte directement l'utilisateur à la console, sans avoir besoin
d'un mot de passe. Pour plus d'informations, consultez Activation de l'accès des utilisateurs fédérés
SAML 2.0 à l'AWS Management Console (p. 176) et How to Enable Cross-Account Access to the
AWS Management Console dans le blog sur la sécurité AWS.
Utilisation des informations d'identification de
sécurité temporaires pour demander un accès aux
ressources AWS.
Vous pouvez utiliser des informations d'identification de sécurité temporaires pour effectuer des
demandes par programmation concernant des ressources AWS avec les kits SDK AWS ou les appels
257
unutiliser
accès des
aux informations
ressources AWS.
d'API, tout comme vous pouvez
d'identification de sécurité à long terme
comme les informations d'identification utilisateur IAM. Toutefois, il existe quelques différences :
• Lorsque vous effectuez un appel à l'aide des informations d'identification de sécurité temporaires,
celui-ci doit inclure un jeton de session qui est renvoyé avec ces informations d'identification
temporaires. AWS utilise le jeton de session pour valider les informations d'identification de sécurité
temporaires.
• Les informations d'identification temporaires arrivent à expiration après un intervalle spécifique. Une
fois les informations d'identification arrivées à expiration, tous les appels que vous effectuez avec
elles échoueront. Vous devez donc obtenir un nouvel ensemble d'informations d'identification.
Si vous utilisez les kits SDK AWS, l'AWS Command Line Interface (AWS CLI) ou l'Outils pour Windows
PowerShell, la manière dont vous obtenez et utilisez les informations d'identifications de sécurité
temporaires varie selon le contexte. Si vous exécutez du code, l'AWS CLI, ou les commandes de
l'Outils pour Windows PowerShell situées dans l'instance EC2, vous pouvez tirer profit des rôles
pour Amazon EC2. Sinon, vous pouvez appeler une API AWS STS pour obtenir les informations
d'identification temporaires, puis les utiliser explicitement pour effectuer des appels aux services AWS.
Note
AWS STS est un service global qui dispose d'un point de terminaison par défaut à l'adresse
https://sts.amazonaws.com. Ce point de terminaison se situe dans la région USA
Est (Virginie du Nord), bien que les informations d'identification que vous en obteniez ou
d'autres points de terminaison sont valides mondialement et fonctionnent avec les services et
ressources de n'importe quelle région. Vous pouvez également choisir d'effectuer des appels
d'API AWS STS aux points de terminaison de n'importe quelle région prise en charge. Cela
permet de réduire la latence en effectuant les demandes depuis les serveurs situés dans une
région géographiquement plus proche de vous. Quelle que soit la région d'où proviennent vos
informations d'identification, elles fonctionnent dans le monde entier. Pour de plus amples
informations, veuillez consulter Activation et désactivation d'AWS STS dans une région
AWS (p. 274).
Table des matières
• Utilisation d'informations d'identification temporaires dans les instances Amazon EC2 (p. 258)
• Utilisation d'informations d'identification de sécurité temporaires avec les kits SDK AWS (p. 259)
• Utilisation d'informations d'identification de sécurité temporaires avec l'AWS CLI (p. 259)
• Utilisation d'informations d'identification de sécurité temporaires avec l'Outils pour Windows
PowerShell (p. 260)
• Utilisation d'informations d'identification de sécurité temporaires avec les API (p. 261)
• En savoir plus (p. 261)
Utilisation d'informations d'identification temporaires dans les
instances Amazon EC2
Si vous souhaitez exécuter des commandes AWS CLI ou du code dans une instance EC2, pour
obtenir des informations d'identification nous vous recommandons d'utiliser les rôles pour Amazon
EC2. Vous créez un rôle IAM qui spécifie les autorisations que vous souhaitez accorder aux
applications qui s'exécutent sur les instances EC2. Lorsque vous lancez l'instance, vous associez le
rôle à cette instance.
Les applications, AWS CLI et les commandes Outils pour Windows PowerShell qui s'exécutent sur
l'instance peuvent obtenir des informations d'identification de sécurité temporaires automatiquement
258
un accès
auxn'avez
ressources
auprès des métadonnées d'instance.
Vous
pas àAWS.
obtenir explicitement les informations
d'identification de sécurité temporaires : les kits SDK AWS, l'AWS CLI, et l'Outils pour Windows
PowerShell obtiennent automatiquement les informations d'identification à partir du service des
métadonnées d'instance EC2 et les utilisent. Les informations d'identification temporaires disposent
d'autorisations que vous définissez pour le rôle associé à l'instance.
Pour plus d'informations et d'exemples, consultez ce qui suit :
• Utilisation de rôles IAM pour les instances EC2 avec le kit AWS SDK for Java
• Utilisation de rôles IAM pour les instances Amazon EC2 avec le kit Kit AWS SDK pour .NET
• Utilisation de rôles IAM pour les instances Amazon EC2 avec le kit Kit SDK AWS pour Ruby
• Utilisation de rôles IAM pour les instances Amazon EC2 dans la documentation AWS SDK pour PHP
Utilisation d'informations d'identification de sécurité
temporaires avec les kits SDK AWS
Pour utiliser des informations d'identification de sécurité temporaires dans du code, vous appelez par
programmation une API AWS STS comme AssumeRole, vous extrayez les informations d'identification
et le jeton de session obtenus, puis vous utilisez ces valeurs en tant qu'informations d'identification
pour les prochains appels à AWS. L'exemple de pseudo-code suivant explique comment utiliser des
informations d'identification de sécurité temporaires si vous utilisez utiliser un kit SDK AWS :
assumeRoleResult = AssumeRole(role-arn);
tempCredentials = new SessionAWSCredentials(
assumeRoleResult.AccessKeyId,
assumeRoleResult.SecretAccessKey,
assumeRoleResult.SessionToken);
s3Request = CreateAmazonS3Client(tempCredentials);
Pour obtenir un exemple écrit dans Python (à l'aide du kit AWS SDK for Python (Boto)) indiquant
comment appeler AssumeRole pour obtenir des informations d'identification de sécurité temporaires,
et que vous utilisez ensuite celles-ci pour effectuer un appel à Amazon S3, consultez Assumer un rôle
IAM (API) (p. 225).
Pour plus d'informations sur la manière d'appeler AssumeRole, GetFederationToken et d'autres
API, et sur la manière d'obtenir des informations d'identification de sécurité temporaires et un jeton de
session dans les résultats, consultez la documentation du kit SDK que vous utilisez. La documentation
sur tous les kits SDK AWS se situent sur la page de documentation AWS principale.
Vous devez vérifier que vous obtenez un nouvel ensemble d'informations d'identification avant que les
anciennes arrivent à expiration. Dans certains kits SDK, vous pouvez utiliser un fournisseur qui gère le
processus d'actualisation des informations d'identification pour vous. Consultez la documentation du kit
SDK que vous utilisez.
temporaires avec l'AWS CLI
Vous pouvez utiliser les informations d'identification de sécurité temporaires avec l'AWS CLI. Cela peut
vous être utile lors de test de stratégies.
À l'aide de l'AWS CLI, vous pouvez appeler une API AWS STS comme AssumeRole ou
GetFederationToken, puis capturer la sortie obtenue. L'exemple suivant illustre un appel à
AssumeRole qui envoie la sortie dans un fichier. Dans l'exemple, le paramètre profile est supposé
259
accès aux ressources
AWS.
être un profil dans le fichier de un
configuration
de l'AWS CLI
et faire référence aux informations
d'identification d'un utilisateur IAM disposant des autorisations lui permettant d'assumer le rôle.
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/role-name -role-session-name "RoleSession1" --profile IAM-user-name > /tmp/assume-roleoutput.txt
Une fois l'exécution de la commande terminée, vous pouvez extraire l'ID de clé d'accès, la clé d'accès
secrète et le jeton de session à l'emplacement où vous les avez acheminés, manuellement ou à l'aide
d'un script. Vous pouvez ensuite affecter ces valeurs aux variables d'environnement.
Lorsque vous exécutez des commandes AWS CLI, l'AWS CLI recherche les informations
d'identification dans un ordre spécifique : d'abord dans les variables d'environnement, puis dans le
fichier de configuration. Par conséquent, après avoir placé les informations d'identification temporaires
dans les variables d'environnement, l'AWS CLI les utilise par défaut. (Si vous spécifiez un paramètre
profile dans la commande, l'AWS CLI ignore les variables d'environnement et cherche dans le
fichier de configuration, ce qui vous permet de remplacer les informations d'identification dans les
variables d'environnement au besoin.)
L'exemple de pseudo-code suivant explique comment définir les variables d'environnement pour les
informations d'identification de sécurité temporaires, puis comment appeler une commande AWS CLI.
Du fait qu'aucun paramètre profile n'est inclus dans la commande AWS CLI, l'AWS CLI recherche
d'abord les informations d'identification dans les variables d'environnement et utilise les informations
d'identification temporaires.
Linux
export AWS_ACCESS_KEY_ID=AKIAI44QH8DHBEXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_SESSION_TOKEN=AQoDYXdzEJr...<remainder of security token>
aws ec2 describe-instances --region us-west-1
Windows
SET AWS_ACCESS_KEY_ID=AKIAI44QH8DHBEXAMPLE
SET AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
SET AWS_SESSION_TOKEN=AQoDYXdzEJr...<remainder of token>
aws ec2 describe-instances --region us-west-1
temporaires avec l'Outils pour Windows PowerShell
Vous pouvez utiliser les informations d'identification de sécurité temporaires avec l'Outils AWS pour
Windows PowerShell. Cela peut vous être utile lors de test de stratégies.
À l'aide de l'Outils pour Windows PowerShell, vous pouvez appeler une action d'API AWS STS
comme AssumeRole ou GetFederationToken, puis capturer la sortie obtenue. L'exemple suivant
présente une commande PowerShell qui appelle AssumeRole et stocke l'objet de rôle obtenu
dans la variable $role. Le paramètre StoredCredentials est supposé être un profil dans le
fichier de configuration Outils pour Windows PowerShell configuré par Set-AWSCredentials ou
Initialized-AWSDefaults et faire référence aux informations d'identification d'un utilisateur IAM
disposant des autorisations lui permettant d'assumer le rôle.
260
un accès aux ressources AWS.
PS C:\> $role = Use-STSRole -RoleArn
arn:aws:iam::123456789012:role/MySampleRole -RoleSessionName RoleSession1 StoredCredentials IAM-user-name
Une fois l'exécution de la commande terminée, vous pouvez extraire l'ID de clé d'accès, la clé d'accès
secrète et le jeton de session de la variable.
PS C:\> $role.AssumedRoleUser
Arn
--arn:aws:sts::123456789012:assumed-role/clirole/RoleSession1
AROAJVIFQ5TJISRUTVTUE:RoleSession1
AssumedRoleId
-------------
PS C:\> $role.Credentials.AccessKeyId
AKIAIOSFODNN7EXAMPLE
PS C:\> $role.Credentials.SecretAccessKey
wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
PS C:\> $role.Credentials.SessionToken
AQoDYXdzEPT//////////
wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQWLWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqT
flfKD8YUuwthAx7mSEI/qkPpKPi/
kMcGdQrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU9
HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
+scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYv
KTr4rvx3iSIlTJabIQwj2ICCR/oLxBA==
PS C:\> $role.Credentials.Expiration
Wednesday, July 08, 2015 3:22:32 PM
L'exemple de pseudo-code suivant explique comment utiliser les informations d'identification stockées
dans la variable pour appeler ensuite une commande AWS CLI.
Get-EC2Instance -Region us-west-2 -Credential $role.Credentials
temporaires avec les API
Si vous envoyez directement des requêtes d'API HTTPS à AWS, vous pouvez signer ces requêtes
avec les informations d'identification temporaires obtenues auprès d'AWS Security Token Service
(AWS STS). Pour cela, vous utilisez l'ID de clé d'accès et la clé d'accès secrète que vous recevez
de AWS STS de la même façon que vous utiliseriez des informations d'identification à long terme
pour signer une demande. Vous ajoutez également à votre demande d'API le jeton de session que
vous recevez de AWS STS. Vous ajoutez le jeton de session à un en-tête HTTP ou à un paramètre
de chaîne de requête appelé X-Amz-Security-Token. Vous ajoutez le jeton de session à l'entête HTTP ou au paramètre de chaîne de requête, mais pas les deux. Pour plus d'informations sur la
signature de requêtes d'API HTTPS, consultez Signature de requêtes d'API AWS dans le manuel AWS
General Reference.
En savoir plus
Pour plus d'informations sur l'utilisation de AWS STS avec d'autres services AWS, consultez les liens
suivants :
261
Contrôle des autorisations affectées aux
informations d'identification de sécurité temporaires
• Amazon S3. Voir Demandes grâce aux informations d'identification temporaires de l'utilisateur IAM
ou Demandes grâce aux informations d'identification de sécurité temporaires de l'utilisateur fédéré
• Amazon SNS. Voir Utilisation d'informations d'identification de sécurité temporaires dans le manuel
Amazon Simple Notification Service Manuel du développeur.
• Amazon SQS. Voir Utilisation d'informations d'identification de sécurité temporaires dans le manuel
Amazon Simple Queue Service Manuel du développeur.
• Amazon SimpleDB. Voir Utilisation d'informations d'identification de sécurité temporaires dans le
manuel Amazon SimpleDB Guide du développeur.
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 stratégies et des
autorisations AWS. Pour plus d'informations sur ces rubriques, consultez Gestion de l'accès (p. 281).
Rubriques
• Autorisations pour AssumeRole, AssumeRoleWithSAML et AssumeRoleWithWebIdentity (p. 262)
• Autorisations pour GetFederationToken (p. 265)
• Autorisations pour GetSessionToken (p. 269)
• Désactivation des autorisations affectées aux informations d'identification de sécurité
temporaires (p. 270)
• Octroi d'autorisations pour créer des informations d'identification de sécurité temporaires (p. 273)
Autorisations pour AssumeRole, AssumeRoleWithSAML et
La stratégie d'autorisation du rôle assumé 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.
Vous pouvez également transmettre une stratégie distincte en tant que paramètre de l'appel d'API
AssumeRole, AssumeRoleWithSAML ou AssumeRoleWithWebIdentity. Vous avez utilisé la
stratégie transmise pour définir les autorisations affectées aux informations d'identification de sécurité
temporaires, c'est-à-dire pour autoriser uniquement un sous-ensemble d'autorisations autorisées par
la stratégie d'autorisation du rôle. Vous ne pouvez pas utiliser la stratégie transmise pour octroyer les
autorisations dépassant celles autorisées par la stratégie d'autorisation du rôle. Il s'agit uniquement
d'un filtre. Si vous ne transmettez pas une stratégie en tant que paramètre de l'appel API AssumeRole,
AssumeRoleWithSAML ou AssumeRoleWithWebIdentity, les autorisations attachées aux
informations d'identification de sécurité temporaires sont identiques aux autorisations définies dans les
autorisations du rôle assumé actuellement.
Lorsque les informations d'identification de sécurité temporaires renvoyées par AssumeRole,
AssumeRoleWithSAML et AssumeRoleWithWebIdentity sont utilisées pour effectuer des
demandes AWS, AWS détermine s'il doit autoriser ou refuser l'accès en évaluant toutes les stratégies
suivantes :
262
• La combinaison de la stratégie d'autorisation de rôle du rôle qui était assumé et de la stratégie
transmise en tant que paramètre à l'API, comme évoqué précédemment.
• Toutes les stratégies basées sur des ressources (telles qu'une stratégie de compartiment Amazon
S3) attachées à la ressource à laquelle les informations d'identification de sécurité temporaires
accèdent actuellement.
AWS utilise toutes ces stratégies pour parvenir à une décision d'autorisation ou de refus en accord
avec la logique d'évaluation de stratégie IAM (p. 441).
Il est important de comprendre que les stratégies attachées à l'utilisateur IAM ou que les informations
d'identification ayant effectué l'appel d'origine à AssumeRole ne sont pas évaluées par AWS lors de la
prise de décision d'autorisation ou de refus. L'utilisateur renonce temporairement à ses autorisations
d'origine en faveur de celles affectées au rôle assumé. Dans le cas des API AssumeRoleWithSAML
et AssumeRoleWithWebIdentity, il n'existe aucune stratégie à évaluer, car l'appelant de l'API n'est
pas une identité AWS.
Exemple : Octroi d'autorisations à l'aide d'AssumeRole
Vous pouvez utiliser l'action d'API AssumeRole avec différents types de stratégies. Voici quelques
exemples.
Stratégie d'autorisation de rôle
Dans cet exemple, vous appelez l'API AssumeRole sans inclure le paramètre Policy facultatif.
Les autorisations affectées aux informations d'identification de sécurité temporaires renvoyées par
l'appel à AssumeRole, c'est-à-dire les autorisations affectées à l'utilisateur du rôle assumé, sont
déterminées par la stratégie d'autorisation du rôle assumé actuellement. L'exemple suivant est une
stratégie d'autorisation de rôle qui accorde à l'utilisateur du rôle assumé l'autorisation de répertorier
tous les objets contenus dans un compartiment S3 appelé productionapp et d'obtenir, de placer et
de supprimer des objets dans ce compartiments.
Example Stratégie d'autorisation de rôle
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
}
]
}
Stratégie transmise en tant que paramètre
Imaginons que vous souhaitiez autoriser un utilisateur à assumer le même rôle que dans l'exemple
suivant, mais que vous souhaitiez que le rôle assumé ait uniquement l'autorisation d'obtenir et de
263
placer des objets, sans les supprimer, dans le compartiment S3 productionapp. Pour cela, vous
pouvez créer un rôle et spécifier les autorisations souhaitées dans la stratégie d'autorisation du rôle.
Vous pouvez également appeler l'API AssumeRole et inclure les paramètres Policy facultatifs dans
le cadre de l'appel d'API. Par exemple, imaginons que la stratégie suivante soit transmise en tant
que paramètre de l'appel d'API. L'utilisateur du rôle assumé 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.
Notez que puisque l'autorisation s3:DeleteObject n'est pas spécifiée dans la stratégie suivante,
elle est exclue du filtre et l'utilisateur du rôle assumé n'obtient pas l'autorisation s3:DeleteObject.
Lorsque vous transmettez une stratégie en tant que paramètre de l'appel d'API AssumeRole, les
autorisations effectives de l'utilisateur du rôle assumé se composent uniquement des autorisations
octroyées à la fois dans la stratégie d'autorisation du rôle et la stratégie transmise.
Example Stratégie transmise avec l'appel d'API AssumeRole
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject"
],
}
]
}
Stratégie basée sur une ressource
Certaines ressources AWS prennent en charge les stratégies basées sur des ressources, et
ces dernières fournissent un autre moyen de définir des autorisations affectant 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
stratégies basées sur des ressources. L'exemple suivant développe les exemples précédents, à l'aide
d'un compartiment S3 nommé productionapp. La stratégie suivante est attachée au compartiment.
Lorsque vous attachez la stratégie suivante au compartiment productionapp, tous les utilisateurs
se voient refuser l'autorisation de supprimer des objets du compartiment (notez l'élément Principal
dans la stratégie). Cela inclut tous les utilisateurs du rôle assumé, même si la stratégie d'autorisation
du rôle accorde l'autorisation DeleteObject. Une instruction Deny explicite a toujours priorité sur une
instruction Allow explicite.
264
Example Stratégie de compartiment
{
"Version": "2012-10-17",
"Statement": {
"Principal": {"AWS": "*"},
"Effect": "Deny",
"Action": "s3:DeleteObject",
}
}
Pour plus d'informations sur la manière dont AWS combine et évalue plusieurs stratégies, consultez
Logique d'évaluation de stratégies IAM (p. 441).
Autorisations pour GetFederationToken
Les autorisations octroyées aux informations d'identification de sécurité temporaires retournées par
GetFederationToken sont déterminées par une combinaison de plusieurs des éléments suivant :
• La ou les stratégies qui sont attachées à l'utilisateur IAM dont les informations d'identification sont
utilisées pour l'appel de GetFederationToken.
• La stratégie qui est transmise en tant que paramètre dans l'appel.
La stratégie transmise est attachée aux informations d'identification de sécurité temporaires obtenues
lors l'appel d'API GetFederationToken, autrement dit à l'utilisateur fédéré. Lorsque l'utilisateur
fédéré envoie une requête à AWS AWS évalue la stratégie attachée à l'utilisateur fédéré en la
combinant avec la ou les stratégies attachée(s) à l'utilisateur IAM dont les informations d'identification
ont été utilisées pour l'appel de GetFederationToken.
Important
AWS autorise la requête de l'utilisateur fédéré uniquement si la stratégie attachée et la
stratégie de l'utilisateur IAM autorisent toutes deux explicitement l'utilisateur fédéré à effectuer
l'action demandée.
Les autorisations accordées à l'utilisateur fédéré sont définies dans l'un des éléments suivants :
• La stratégie transmise en tant que paramètre de l'appel d'API GetFederationToken. (Il s'agit du
scénario le plus courant.)
• Une stratégie basée sur les ressources qui nomme explicitement l'utilisateur fédéré dans l'élément
Principal de la stratégie. (Ce scénario est moins courant.)
Cela signifie que dans la plupart des cas, si vous ne transmettez pas de stratégie avec l'appel
d'API GetFederationToken, les informations d'identification de sécurité temporaires générées ne
disposent d'aucune autorisation. La seule exception est lorsque les informations d'identification sont
utilisées pour accéder à une ressource dotée d'une stratégie basée sur les ressources qui référence de
manière spécifique l'utilisateur fédéré dans l'élément Principal de la stratégie.
Les illustrations suivantes sont une représentation visuelle de la façon dont les stratégies interagissent
pour déterminer les autorisations accordées aux informations d'identification de sécurité temporaires
retournées par un appel à GetFederationToken.
265
Exemple : Octroi d'autorisations à l'aide de GetFederationToken
Vous pouvez utiliser l'action d'API GetFederationToken avec différents types de stratégies. Voici
quelques exemples.
Stratégie attachée à un utilisateur IAM
Dans cet exemple, une application cliente basée sur un navigateur s'appuie sur deux services web
principaux. Un service principal est votre propre serveur d'authentification qui utilise votre système
d'identité pour authentifier l'application cliente. L'autre service principal 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 stratégie d'accès 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 envoyer des requêtes directement au service AWS avec les informations d'identification
de sécurité temporaires. Cette architecture permet à l'application cliente d'exécuter des requêtes AWS
sans avoir à intégrer d'informations d'identification AWS à 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, mais les informations
d'identification à long terme de cet utilisateur restent sur votre serveur et ne sont jamais distribuées au
client. L'exemple de stratégie suivant est attaché à l'utilisateur IAM token-app et définit le plus large
ensemble d'autorisations dont vos utilisateurs fédérés (clients) auront besoin. Notez que l'autorisation
sts:GetFederationToken est requise pour que votre service d'authentification puisse obtenir les
informations d'identification de sécurité temporaires pour les utilisateurs fédérés.
Note
AWS fournit un exemple d'application Java à cet effet ; vous pouvez le télécharger ici : Token
Vending Machine for Identity Registration - Sample Java Web Application.
266
Example Stratégie attachée à un utilisateur IAM token-app qui appelle GetFederationToken
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
},
{
"Effect": "Allow",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sqs:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sns:*",
"Resource": "*"
}
]
}
Même si la stratégie précédente accorde plusieurs autorisations, elle n'est pas suffisante pour accorder
des autorisations à l'utilisateur fédéré. Si l'utilisateur IAM disposant des autorisations définies dans
les appels de stratégie GetFederationToken précédents ne transmet pas de stratégie en tant que
paramètre de l'appel d'API, l'utilisateur fédéré qui en résulte n'a de fait aucune autorisation.
Stratégie transmise en tant que stratégie
La méthode la plus courante pour s'assurer que l'autorisation appropriée est octroyée à
l'utilisateur fédéré consiste à transmettre une stratégie en tant que paramètre de l'appel d'API
GetFederationToken. En reprenant l'exemple précédent, il est possible d'imaginer l'appel de
GetFederationToken avec les informations d'identification de l'utilisateur IAM token-app et la
transmission de la stratégie suivante en tant que paramètre de l'appel d'API. L'utilisateur fédéré aurait
l'autorisation d'effectuer uniquement les actions suivantes :
• Afficher le contenu du compartiment Amazon S3 nommé productionapp.
• Effectuer les actions GetObject, PutObject et DeleteObject d'Amazon S3 sur les éléments du
compartiment productionapp.
L'utilisateur fédéré se voit attribuer ces autorisations, car elles ont été accordées à la fois à
l'utilisateur IAM qui a appelé GetFederationToken (via la stratégie attachée à l'utilisateur IAM)
et à l'utilisateur fédéré (via la stratégie transmise). L'utilisateur fédéré n'a pas pu effectuer d'actions
dans Amazon SNS, Amazon SQS, Amazon DynamoDB ni dans aucun compartiment S3 à l'exception
de productionapp, même si ces autorisations sont accordées à l'utilisateur IAM associé à l'appel
GetFederationToken. Ceci est vrai parce que les autorisations effectives de l'utilisateur fédéré se
267
composent uniquement des autorisations octroyées à la fois dans la stratégie de l'utilisateur IAM et
dans la stratégie transmise.
Example Stratégie passée en tant que paramètre de l'appel d'API GetFederationToken
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": ["arn:aws:s3:::productionapp"]
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::productionapp/*"]
}
]
}
Stratégies basées sur les ressources
Certaines ressources AWS prennent en charge les stratégies basées sur les ressources, et ces
dernières fournissent un autre moyen d'accorder des autorisations directement à un utilisateur fédéré.
Seuls quelques services AWS prennent en charge les stratégies basées sur les ressources. Ainsi,
vous pouvez attacher des stratégies à des compartiments Amazon S3 des rubriques Amazon SNS
ou des files d'attente Amazon SQS. Pour consulter la liste de tous les services prenant en charge les
stratégies basées sur les ressources, consultez Services AWS qui fonctionnent avec IAM (p. 394)
et passez en revue la colonne « Basée sur les ressources » des tableaux. Si vous utilisez l'un de
ces services et que les stratégies basées sur les ressources conviennent pour votre scénario, vous
octroyez des autorisations directement à un utilisateur fédéré en spécifiant l'ARN (Amazon Resource
Name) de l'utilisateur dans l'élément Principal de la stratégie basée sur les ressources. L'exemple
suivant illustre ce scénario. L'exemple suivant développe les exemples précédents, à l'aide d'un
compartiment S3 nommé productionapp.
La stratégie suivante est attachée au compartiment. La stratégie permet à un utilisateur fédéré nommé
Carol d'accéder au compartiment. Lorsque la stratégie basée sur les ressources suivante est mise en
œuvre et que l'exemple de stratégie décrit précédemment est attaché à un utilisateur IAM token-app,
l'utilisateur fédéré nommé Carol est autorisé à effectuer les actions s3:GetObject, s3:PutObject et
s3:DeleteObject sur le compartiment nommé productionapp. Cela est vrai même lorsqu'aucune
stratégie n'est transmise en tant que paramètre de l'appel d'API GetFederationToken. En effet,
dans ce cas, la stratégie suivante basée sur les ressources a octroyé explicitement des autorisations à
l'utilisateur fédéré nommé Carol.
Gardez à l'esprit que les autorisations sont accordées à un utilisateur fédéré uniquement si celles-ci
sont explicitement accordées à l'utilisateur IAM et à l'utilisateur fédéré. Les autorisations peuvent être
accordées à l'utilisateur fédéré soit par la stratégie transmise en tant que paramètre de l'appel d'API
GetFederationToken, soit par une stratégie basée sur les ressources qui nomme explicitement
l'utilisateur fédéré dans l'élément Principal de la stratégie, comme dans l'exemple suivant.
268
Example Stratégie de compartiment qui autorise l'accès à l'utilisateur fédéré
{
"Version": "2012-10-17",
"Statement": {
"Principal": {"AWS": "arn:aws:sts::ACCOUNT-ID-WITHOUT-HYPHENS:federateduser/Carol"},
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::productionapp/*"]
}
}
Autorisations pour GetSessionToken
Les autorisations affectées aux informations d'identification de sécurité temporaires retournées par
GetSessionToken correspondent aux autorisations associées à l'utilisateur IAM ou au compte
racine AWS dont les informations d'identification sont utilisées pour appeler l'API 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. De
même, si GetSessionToken est appelée avec les informations d'identification du compte racine, les
informations d'identification de sécurité temporaires disposent des autorisations du compte racine.
Note
Il est recommandé de ne pas appeler GetSessionToken avec les informations d'identification
du compte racine. Mettez plutôt en application nos bonnes pratiques (p. 44) pour créer un ou
plusieurs utilisateurs IAM avec les autorisations nécessaires. Ensuite, utilisez ces utilisateurs
IAM pour les interactions quotidiennes avec AWS.
La raison principale de l'appel de GetSessionToken est le fait qu’un utilisateur doit exécuter
des actions qui sont autorisées uniquement lorsque l'utilisateur est authentifié par le biais de
l'authentification multi-facteurs (MFA). Il est possible d’écrire une stratégie qui autorise certaines
actions uniquement lorsque ces actions sont requises par un utilisateur authentifié à l'aide de MFA.
Pour réussir le contrôle d'autorisation MFA, un utilisateur doit d'abord appeler GetSessionToken
et inclure l'élément facultatif SerialNumber et le paramètre TokenCode dans l'appel d'API
GetSessionToken. Si l'utilisateur transmet des valeurs valides pour les paramètres SerialNumber
et TokenCode ; autrement dit, s'il est correctement authentifié par un appareil MFA, les informations
d'identification retournées par l'appel d'API GetSessionToken incluront le contexte MFA. Les appels
suivants à AWS avec les informations d'identification retournées par GetSessionToken, permettront à
l'utilisateur d'appeler avec succès les API AWS requérant une authentification MFA.
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 à AWS Management Console
en transmettant les informations d'identification au point de terminaison d'authentification unique
de fédération à https://signin.aws.amazon.com/federation. Pour de plus amples
informations, veuillez consulter Création d'une URL qui permet aux utilisateurs fédérés d'accéder à
AWS Management Console (Broker de fédération personnalisé) (p. 178).
• Vous ne pouvez pas utiliser les informations d'identification pour appeler les API IAM ou AWS STS.
Vous pouvez les utiliser pour appeler les API d'autres services AWS.
269
Comparez cette API et ses limitations et fonctionnalités avec les autres API qui créent des informations
d'identification de sécurité temporaires à partir de Comparaison des API AWS STS (p. 256)
Pour plus d'informations sur l'accès aux API protégé par MFA à l'aide de GetSessionToken,
consultez Configuration de l'accès aux API protégé par MFA (p. 109).
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 et elles ne peuvent pas être révoquées. Toutefois, du fait que les autorisations sont
évaluées chaque fois qu'une demande AWS est effectuée utilisant les informations d'identification,
il est possible de révoquer les informations d'identification en modifiant les autorisations pour les
informations d'identification après leur émission. Si vous supprimez toutes les autorisations des
informations d'identification de sécurité temporaires, les demandes AWS suivantes utilisant celles-ci
échoueront. Les mécanismes permettant de modifier ou de supprimer les autorisations octroyées aux
informations d'identification de sécurité temporaires sont expliqués dans les sections suivantes.
Note
Lorsque vous mettez à jour des autorisations de stratégie existantes ou lorsque vous
appliquez une nouvelle stratégie à un utilisateur ou à une ressource, plusieurs minutes
peuvent s'écouler avant que la mise à jour de la stratégie prenne effet.
Rubriques
• Refus d'accès au créateur des informations d'identification de sécurité temporaires (p. 270)
• Refus d'accès aux informations d'identification de sécurité temporaires par nom (p. 271)
• Refus de l'accès aux informations d'identification de sécurité temporaires émises avant une heure
spécifique (p. 272)
Refus d'accès au créateur des informations d'identification de sécurité
temporaires
Pour modifier ou supprimer les autorisations affectées aux informations d'identification de sécurité
temporaires, vous pouvez modifier ou supprimer les autorisations associées au créateur des
informations d'identification. Le créateur des informations d'identification est déterminé par l'API AWS
STS qui a été utilisée pour obtenir les informations d'identification. Les mécanismes permettant de
modifier ou de supprimer les autorisations associées à ce créateur sont expliqués dans les sections
suivantes.
Refuser l'accès aux informations d'identification créées par AssumeRole,
AssumeRoleWithSAML ou AssumeRoleWithWebIdentity
Pour modifier ou supprimer les autorisations affectées aux informations d'identification de
sécurité temporaires obtenues en appelant les API AssumeRole, AssumeRoleWithSAML ou
AssumeRoleWithWebIdentity, vous devez modifier ou supprimer la stratégie d'accès au rôle qui
définit les autorisations du rôle assumé. Les informations d'identification de sécurité temporaires
obtenues en assumant un rôle ne peuvent jamais disposer de plus d'autorisations que celles définies
dans la stratégie d'accès du rôle assumé et les autorisations octroyées aux informations d'identification
de sécurité temporaires sont évaluées chaque fois qu'elles sont utilisées pour faire une demande
AWS. Lorsque vous modifiez ou supprimez la stratégie d'accès d'un rôle, les modifications affectent
es autorisations de toutes es informations d'identification de sécurité temporaires associées à ce rôle,
y compris les informations d'identification émises avant que vous apportiez des changements à la
stratégie d'accès du rôle.
270
Pour plus d'informations sur la modification d'une stratégies d'accès de rôle, consultez Modification
d'un rôle (p. 234).
Refus d'accès aux informations d'identification créées par GetFederationToken ou
GetSessionToken
Pour modifier ou supprimer les autorisations affectées aux informations d'identification de sécurité
temporaires obtenues en appelant les API GetFederationToken ou GetSessionToken, vous devez
modifier ou supprimer les stratégies attachées à l'utilisateur IAM dont les informations d'identification
ont été utilisées pour appeler GetFederationToken ou GetSessionToken. Les informations
d'identification de sécurité temporaires obtenues en appelant les API GetFederationToken ou
GetSessionToken ne peuvent jamais disposer de plus d'autorisations que l'utilisateur IAM dont les
informations d'identification ont été utilisées pour les obtenir. De plus, les autorisations affectées aux
informations d'identification de sécurité temporaires sont évaluées chaque fois qu'elles sont utilisées
pour faire une demande AWS. Il est important de noter que lorsque vous modifiez ou supprimez les
autorisations d'un utilisateur IAM, les modifications affectent l'utilisateur IAM, ainsi que les informations
d'identification de sécurité temporaires créées par l'utilisateur.
Important
Vous ne pouvez pas modifier les autorisations d'un compte racine 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 avec un
compte racine. C'est pour cette raison que nous vous recommandons de ne pas appeler
GetFederationToken ou GetSessionToken avec les informations d'identification du
compte racine.
Pour plus d'informations sur la modification ou la suppression des stratégies associées à l'utilisateur
IAM dont les informations d'identification ont été utilisées pour appeler GetFederationToken ou
GetSessionToken, consultezUtilisation de stratégies (p. 323).
Refus d'accès aux informations d'identification de sécurité temporaires par
nom
Vous pouvez refuser l'accès aux informations d'identification de sécurité temporaires sans affecter les
autorisations de l'utilisateur ou le rôle IAM ayant créé les informations d'identification. Pour cela, vous
spécifiez l'ARN (Amazon Resource Name) des informations d'identification de sécurité temporaires
dans l'élément Principal d'une stratégie basée sur une ressource. (Seuls quelques services AWS
prennent en charge les stratégies basées sur les ressources.)
Refus d'accès aux utilisateurs fédérés
Par exemple, imaginez que vous avez un utilisateur IAM appelé token-app dont les
informations d'identification sont utilisées pour appeler GetFederationToken. L'appel d'API
GetFederationToken a entraîné des informations d'identification de sécurité temporaires associées
à un utilisateur fédéré appelé Bob (le nom utilisateur fédéré provient du paramètre Name de l'appel
API). Pour refuser à l'utilisateur fédéré Bob l'accès à un compartiment S3 appelé EXAMPLE-BUCKET,
vous attachez l'exemple de stratégie de compartiment suivant à EXAMPLE-BUCKET. Il est important
de noter que cela affecte les autorisations Amazon S3 de l'utilisateur uniquement. Toutes les autres
autorisations accordées à l'utilisateur fédéré restent intactes.
{
"Version": "2012-10-17",
"Statement": {
"Principal": {"AWS": "arn:aws:sts::ACCOUNT-ID-WITHOUT-HYPHENS:federateduser/Bob"},
"Effect": "Deny",
"Action": "s3:*",
271
"Resource": "arn:aws:s3:::EXAMPLE-BUCKET"
}
}
Vous pouvez spécifier l'ARN de l'utilisateur IAM dont les informations d'identification ont été utilisées
pour appeler GetFederationToken dans l'élément Principal de la stratégie de compartiment,
plutôt que de spécifier l'utilisateur fédéré. Dans ce cas, l'élément Principal de la stratégie
précédente ressemblerait à ce qui suit :
"Principal": {"AWS": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:user/tokenapp"}
Il est important de noter que la spécification de l'ARN de l'utilisateur IAM token-app dans la stratégie
entraînera le refus de l'accès à tous les utilisateurs fédérés créés par token-app, pas uniquement
l'utilisateur fédéré appelé Bob.
Refus d'accès aux utilisateurs assumant un rôle
Il est également possible de spécifier l'ARN des informations d'identification de sécurité temporaires
créées en assumant un rôle. La différence réside dans la syntaxe utilisée dans l'élément Principal
de la stratégie basée sur une ressource. Par exemple, un utilisateur assume un rôle appelé
Accounting-Role et spécifie un RoleSessionName de Mary (RoleSessionName est un paramètre
de l'appel d'API AssumeRole). Pour refuser l'accès aux informations d'identification de sécurité
temporaires résultant de cet appel d'API, l'élément Principal de la stratégie basée sur une
ressource ressemblerait à ce qui suit :
"Principal": {"AWS": "arn:aws:sts::ACCOUNT-ID-WITHOUT-HYPHENS:assumed-role/
Accounting-Role/Mary"}
Vous pouvez également spécifier l'ARN du rôle IAM dans l'élément Principal d'une stratégie basée
sur une ressource, comme dans exemple suivant. Dans ce cas, la stratégie entraînera le refus de
l'accès à toutes les informations d'identification de sécurité temporaires associées au rôle appelé
Accounting-Role.
"Principal": {"AWS": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:role/
Accounting-Role"}
Refus de l'accès aux informations d'identification de sécurité temporaires
émises avant une heure spécifique
Il est également possible de refuser l'accès uniquement aux informations d'identification de sécurité
temporaires créées avant une date et une heure spécifiques. Pour cela, vous spécifiez une valeur
pour la clé aws:TokenIssueTime dans l'élément Condition d'une stratégie. L'exemple suivant
illustre une stratégie. Vous attachez une stratégie similaire à l'exemple suivant à l'utilisateur IAM
ayant créé les informations d'identification de sécurité temporaires. La stratégie refuse toutes les
autorisations mais uniquement lorsque la valeur de aws:TokenIssueTime est antérieure aux
date et heure spécifiées. La valeur de aws:TokenIssueTime correspond à l'exacte à laquelle les
informations d'identification de sécurité temporaires ont été créées. La valeur aws:TokenIssueTime
est uniquement présente dans le contexte de demandes AWS qui sont signées avec les informations
d'identification de sécurité temporaires. la déclaration Deny dans la stratégie n'affectera pas les
demandes signées avec les informations d'identification à long terme de l'utilisateur IAM.
La stratégie suivante peut également être attachée à un rôle. Dans ce cas, la stratégie affecte
uniquement les informations d'identification de sécurité temporaires créées par le rôle avant la date et
l'heure spécifiées. Si les informations d'identification ont été créées par le rôle après la date et l'heure
spécifiées, l'élément Condition de la stratégie est false et la déclaration Deny n'a aucun effet.
272
Example Stratégie qui refuse toutes les autorisations aux informations d'identification
temporaires par heure d'émission
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {"DateLessThan": {"aws:TokenIssueTime":
"2014-05-07T23:47:00Z"}}
}
}
Octroi d'autorisations pour créer des informations
Par défaut, les utilisateurs IAM n'ont pas l'autorisation de créer des informations d'identification de
sécurité temporaires pour des utilisateurs fédérés et les rôles. Toutefois, par défaut, les utilisateurs IAM
peuvent appeler GetSessionToken avec leurs propres autorisations afin de créer des informations
d'identification temporaires pour d'autres.
Note
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 utilisateurs fédérés ou des groupes, vous attachez une stratégie qui accorde un
ou plusieurs des privilèges suivants :
• Pour que des utilisateurs fédérés accèdent à un rôle IAM, accordez l'accès à AWS STS
AssumeRole.
• Pour les utilisateurs fédérés n'ayant pas besoin d'un rôle, accordez l'accès à AWS STS
GetFederationToken.
Pour plus d'informations sur les différences entre les API AssumeRole et GetFederationToken,
consultez Obtention d'informations d'identification temporaires de sécurité (p. 246).
Example : Stratégie qui accorde l'autorisation d'assumer un rôle
L'exemple de stratégie suivant donne l'autorisation d'appeler AssumeRole pour le rôle UpdateApp
dans le compte AWS 123123123123. Lorsque AssumeRole est utilisé, l'utilisateur (ou 'application)
qui crée les informations d'identification de sécurité pour le compte d'un utilisateur fédéré ne peut pas
déléguer des autorisations non spécifiées dans la stratégie d'accès de rôle.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
273
Activation et désactivation d'AWS
STS dans une région AWS
"Resource": "arn:aws:iam::123123123123:role/UpdateAPP"
}]
}
Example : Stratégie qui accorde l'autorisation de créer des informations d'identification de
sécurité temporaires pour un utilisateur fédéré
L'exemple de stratégie suivant donne l'autorisations d'accéder à GetFederationToken.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"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 avec
GetFederationToken, sachez que cela autorise l'utilisateur IAM à déléguer ses propres
autorisations. Pour plus d'informations sur la délégation des autorisations entre utilisateurs
IAM et comptes AWS, consultez Exemples de stratégies pour la délégation d'accès (p. 210).
Pour plus d'informations sur le contrôle des autorisations dans les informations d'identification
de sécurité temporaires, consultez Contrôle des autorisations affectées aux informations
d'identification de sécurité temporaires (p. 262).
Example : Stratégie 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 pour créer des informations
d'identification de sécurité temporaires pour des utilisateurs fédérés, il est recommandé de restreindre
autant que possible les autorisations que l'utilisateur IAM est autorisé à déléguer. Par exemple,
la stratégie suivante explique comment autoriser un utilisateur IAM à créer des informations
d'identification de sécurité temporaires uniquement pour des utilisateurs fédérés dont les noms
commencent par Manager.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Resource": ["arn:aws:sts::123456789012:federated-user/Manager*"]
}]
}
Activation et désactivation d'AWS STS dans une
région AWS
Par défaut, le service AWS Security Token Service (AWS STS) est un service global et toutes les
demandes AWS STS sont acheminées vers un point de terminaison unique à l'adresse https://
sts.amazonaws.com. Si vous le souhaitez, vous pouvez envoyer vos demandes AWS STS vers des
274
points de terminaison situés dans n'importe laquelle des régions AWS répertoriées dans le tableau
ci-après. Toutes les régions sont activées par défaut, mais vous pouvez désactiver celles dont vous
n'avez pas besoin.
Il est possible d'envoyer des demandes AWS STS vers un point de terminaison régional pour les
raisons suivantes :
• Réduction de latence – En acheminant vos appels AWS STS vers un point de terminaison
géographiquement plus proche de vos services et applications, il est possible d'accéder aux services
AWS STS avec une latence moins élevée et des temps de réponse plus courts.
• Redondance intégrée – En ajoutant du code à votre application afin de diriger vos appels d'API
AWS STS vers une autre région, vous êtes sûr que si la première région ne répond plus, votre
application continuera à fonctionner. Cette redondance n'est pas automatique ; vous devez intégrer
la fonctionnalité dans votre code.
Lors de l'activation d'une région pour un compte, vous permettez aux points de terminaison STS de
cette région d'émettre des informations d'identification temporaires pour les utilisateurs et rôles de ce
compte lorsqu'une demande est transmise à un point de terminaison de la région. Les informations
d'identification sont toujours reconnues et utilisables globalement. La région doit être activée non
pas par le compte du mandataire, mais par le compte à partir duquel les informations d'identification
temporaires sont demandées.
Par exemple, un utilisateur du compte A veut envoyer une demande d'API sts:AssumeRole au point
de terminaison régional STS https://sts.us-west-2.amazonaws.com. La demande concerne les
informations d'identification temporaires du rôle nommé Developer dans le compte B. Etant donné
qu'il s'agit d'une demande de création d'informations d'identification pour une entité du compte B,
ce compte doit activer la région us-west-2. Les utilisateurs du compte A (ou de tout autre compte)
peuvent appeler le point de terminaison us-west-2 pour demander les informations d'identification
pour le compte B, que la région soit activée ou nom dans leurs comptes.
Pour activer ou désactiver AWS STS dans une région
Note
Toutes les régions sont activées par défaut. Activez une région uniquement si celle-ci a été
désactivée.
1.
Connectez-vous en tant qu'utilisateur IAM avec l'autorisation d'effectuer des tâches
administratives IAM ("iam:*") pour le compte pour lequel vous voulez activer AWS STS dans
une nouvelle région.
2.
Ouvrez la console IAM, puis dans le volet de navigation, sélectionnez Account Settings.
3.
Développez la liste Security Token Service Regions, localisez la région que vous voulez utiliser,
puis sélectionnez Activate ou Deactivate.
Ecriture de code pour l'utilisation de régions AWS STS
Après avoir activé une région pour votre compte AWS vous pouvez diriger les appels d'API
AWS STS vers celle-ci. L'extrait de code Java suivant illustre comment configurer un objet
AWSSecurityTokenServiceClient pour effectuer des demandes à partir de la région UE (Irlande)
(eu-west-1) à l'aide de la méthode setEndpoint.
AWSSecurityTokenServiceClient stsClient = new
AWSSecurityTokenServiceClient();
stsClient.setEndpoint("sts.eu-west-1.amazonaws.com");
275
Important
N'utilisez pas la méthode setRegion pour définir un point de terminaison régional pour AWS
STS. En effet, à des fins de rétrocompatibilité, cette méthode résout le point de terminaison en
point de terminaison global unique d'origine sts.amazonaws.com.
Dans l'exemple, la première ligne instancie un objet AWSSecurityTokenServiceClient nommé
stsClient. La seconde ligne configure l'objet stsClient en appelant sa méthode setEndpoint et
en transmettant l'URL du point de terminaison en tant que seul paramètre. Tous les appels d'API qui
utilisent cet objet stsClient sont maintenant dirigés vers le point de terminaison spécifié.
Pour toutes les autres combinaisons de langage et d'environnement de programmation, reportez-vous
à la documentation du kit SDK approprié.
Rien d'autre ne change pour l'utilisation d'AWS STS dans une région. Comme toujours, les
informations d'identification obtenues à partir du point de terminaison AWS STS d'une région ne sont
pas limitées à cette région ; elles peuvent faire l'objet d'une utilisation globale.
Le tableau suivant répertorie les régions et leurs points de terminaison. Il indique les régions activées
par défaut et celles que vous pouvez activer ou désactiver.
Nom de la région
Point de terminaison
Peut être
activée/
désactivée
--Solution internationale--
sts.amazonaws.com
Non
USA Est (Virginie du
Nord)
sts.us-east-1.amazonaws.com
Non
USA Est (Ohio)
sts.us-east-2.amazonaws.com
Oui
USA Ouest (Californie du
Nord)
sts.us-west-1.amazonaws.com
Oui
USA Ouest (Oregon)
sts.us-west-2.amazonaws.com
Oui
Asie-Pacifique (Tokyo)
sts.ap-northeast-1.amazonaws.com
Oui
Asie-Pacifique (Séoul)
sts.ap-northeast-2.amazonaws.com
Oui
Asie-Pacifique (Mumbai)
sts.ap-south-1.amazonaws.com
Oui
Asie-Pacifique
(Singapour)
sts.ap-southeast-1.amazonaws.com
Oui
Asie-Pacifique (Sydney)
sts.ap-southeast-2.amazonaws.com
Oui
UE (Francfort)
sts.eu-central-1.amazonaws.com
Oui
UE (Irlande)
sts.eu-west-1.amazonaws.com
Oui
Amérique du Sud (São
Paulo)
sts.sa-east-1.amazonaws.com
Oui
Note
Les appels à destination de points de terminaison régionaux tels que sts.useast-2.amazonaws.com sont consignés dans AWS CloudTrail comme n'importe quel appel
à un service régional. Les appels vers le point de terminaison global, sts.amazonaws.com,
276
Exemples d'application qui utilisent des
informations d'identification temporaires
sont consignés en tant qu'appels à un service global. Pour de plus amples informations,
veuillez consulter Consignation d'événements IAM avec AWS CloudTrail (p. 358).
Exemples d'application qui utilisent des informations
d'identification temporaires
Pour savoir comment vous pouvez utiliser AWS STS pour gérer des informations d'identification
temporaires, vous pouvez télécharger les exemples d'applications suivants qui implémentent des
exemples de scénarios complets :
• Exemple d'application de fédération d'identité pour un cas d'utilisation d'Active Directory. Explique
comment utiliser des autorisations liées à un utilisateur défini dans Active Directory (.NET/C#) pour
émettre des informations d'identification temporaires permettant d'accéder à des fichiers et des
compartiments Amazon S3.
• Exemple de cas d'utilisation d'un proxy de fédération d'identité AWS Management Console. Explique
comment créer un proxy de fédération permettant d'autoriser l'authentification unique (SSO) afin que
les utilisateurs Active Directory existants puissent se connecter à AWS Management Console (.NET/
C#).
• Intégrer Shibboleth à AWS Identity and Access Management (). Explique comment utiliser
Shibboleth et SAML (p. 156) pour fournir aux utilisateurs un accès avec authentification unique
(SSO) à AWS Management Console.
Exemples de fédération d'identité web
Les exemples d'applications suivants illustrent différentes manières d'utiliser la fédération d'identité
web qui vous permet d'échanger de l'authentification avec un fournisseur d'identité connu
comme Login with Amazon, Amazon Cognito, Facebook ou Google pour obtenir des informations
d'identification de sécurité AWS temporaires que votre application peut utiliser pour accéder aux
services AWS.
Note
Comme alternative aux approches illustrées dans les exemples suivants, nous vous
recommandons d'utiliser Amazon Cognito avec les kit SDK AWS pour le développement
mobile. Amazon Cognito est la manière la plus simple de gérer l'identité pour les applications
mobiles et il fournit des fonctions comme la synchronisation et l'identité entre périphériques.
Pour plus d'informations sur Amazon Cognito, consultez Identité Amazon Cognito dans le
manuel AWS Mobile SDK pour Android Developer Guide et Authentifier les utilisateurs avec
l'identité Amazon Cognito dans le manuel AWS Mobile SDK for iOS Developer Guide.
• Web Identity Federation Playground. Ce site web fournit une démonstration interactive de la
fédération d'identité web (p. 149) et de l'API AssumeRoleWithWebIdentity.
• Build and Deploy a Federated Web Identity Application with AWS Elastic Beanstalk and Login with
Amazon. Ce billet de blog décrit comment utiliser AssumeRoleWithWebIdentity pour obtenir
des informations d'identification temporaires à l'aide de la fédération d'identité web et de Login
with Amazon. Il explique également comment utiliser ces informations d'identification dans une
application web Python qui s'exécute sur Elastic Beanstalk pour réaliser des appels vers AWS.
• Authentification des utilisateurs des applications mobiles AWS avec un Token Vending Machine
dans la section Articles et didacticiels AWS. Cet exemple présente une application proxy basée
sur serveur qui fournit des informations d'identification temporaires à des clients distants (comme
des applications mobiles) afin que les clients puissent signer des demandes web dans AWS.
Cet exemple peut être utilisé avec l'exemple de client qui fait partie de AWS Mobile SDK pour
277
Ressources supplémentaires pour les
informations d'identification temporaires
Android et de AWS Mobile SDK for iOS. Pour plus informations, consultez Gestion des informations
d'identification pour les applications mobiles qui fournit des détails sur la sécurisation des ressources
AWS lorsque vous utilisez le Token Vending Machine (TVM) avec des applications mobiles.
Ressources supplémentaires pour les informations
Les scénarios et applications suivants peuvent vous aider à utiliser les informations d'identification de
sécurité temporaires :
• A propos de la fédération d'identité web (p. 149). Cette section présente la configuration des rôles
IAM lorsque vous utilisez la fédération d'identité web et l'API AssumeRoleWithWebIdentity.
• Configuration de l'accès aux API protégé par MFA (p. 109). Cette rubrique explique comment
utiliser les rôles pour exiger l'authentification multi-facteurs (MFA) afin de protéger les actions d'API
sensibles de votre compte.
• Token Vending Machine pour l’enregistrement de l’identité. Cet exemple d'application web Java
utilise l'API GetFederationToken pour fournir des informations d'identification de sécurité
temporaires aux clients distants.
Pour plus d'informations sur les stratégies et autorisations dans AWS, consultez les rubriques
suivantes :
• Gestion de l'accès (p. 281)
• Logique d'évaluation de stratégies IAM (p. 441).
• Gestion des autorisations d'accès à vos ressources Amazon S3 dans le manuel Amazon Simple
Storage Service Manuel du développeur.
Utilisateur racine d'un compte
Lorsque vous créez un compte Amazon Web Services, vous commencez avec une seule identité de
connexion disposant d'un accès complet à tous les services et ressources AWS du compte. Cette
identité est appelée utilisateur racine et elle est accessible après connexion à l'aide de l'adresse e-mail
et du mot de passe utilisés pour la création du compte.
Important
Il est vivement recommandé de ne pas utiliser l'utilisateur racine pour vos tâches quotidiennes,
y compris pour les tâches administratives. Au lieu de cela, respectez la bonne pratique qui
consiste à avoir recours à l'utilisateur racine uniquement pour créer le premier utilisateur
IAM (p. 45), puis à mettre en sécurité les informations d'identification de l'utilisateur racine.
Pour accéder à un didacticiel expliquant comment configurer cet utilisateur administrateur,
consultez Création de votre premier utilisateur administrateur et groupe IAM (p. 15).
Pour gérer votre utilisateur racine, suivez les procédures suivantes.
Rubriques
• Création de clés d'accès pour l'utilisateur racine (p. 279)
• Suppression des clés d'accès de l'utilisateur racine (p. 279)
• Activer MFA sur l'utilisateur racine (p. 280)
• Modification du mot de passe de l'utilisateur racine (p. 280)
278
Création de clés d'accès pour l'utilisateur racine
Création de clés d'accès pour l'utilisateur racine
Vous pouvez utiliser AWS Management Console ou divers outils de programmation pour créer des
clés d'accès pour l'utilisateur racine.
Pour créer une clé d'accès pour l'utilisateur racine (console)
1.
Connectez-vous à AWS Management Console à l'aide des informations d'identification de votre
compte (et non pas en tant qu'utilisateur IAM ), puis ouvrez la console IAM à partir de https://
console.aws.amazon.com/iam/. Une page utilisateur IAM comporte trois zones de texte ; vous ne
pouvez pas vous connecter en tant qu’utilisateur racine sur cette page. S'il s'avère que vous êtes
sur une page de connexion utilisateur IAM, commencez par sélectionner le lien Sign-in using root
account credentials qui figure sous les zones de texte de la page.
2.
Sur la page IAM Dashboard, choisissez le nom de votre compte dans la barre de navigation, puis
sélectionnez Security Credentials.
3.
Si un avertissement à propos de l'accès aux informations d'identification de sécurité de votre
compte AWS s'affiche, choisissez Continue to Security Credentials.
4.
Développez la section Access Keys (Access Key ID and Secret Access Key).
5.
Choisissez Create New Access Key. Une boîte de dialogue vous avertit qu'il s'agit de la seule fois
où vous serez en mesure d'afficher ou de télécharger la clé d'accès secrète. Vous ne pourrez pas
la récupérer ultérieurement.
• Si vous choisissez Show Access Key, vous pouvez copier l'ID de clé d'accès et la clé secrète à
partir de la fenêtre de votre navigateur et les coller à un autre emplacement.
• Si vous sélectionnez Download Key File, vous recevez un fichier nommé rootkey.csv qui
contient l'ID de clé d'accès et la clé secrète. Enregistrez le fichier à un endroit sûr.
6.
Lorsque vous n'avez plus besoin d'utiliser la clé d'accès, nous vous recommandons de la
supprimer (p. 48), ou du moins de la marquer comme inactive, afin qu’elle ne puisse pas être
utilisée si elle fait l'objet d'une fuite.
Pour créer une clé d'accès pour l'utilisateur racine (par programmation)
Utilisez l'une des commandes suivantes :
Suppression des clés d'accès de l'utilisateur racine
Vous pouvez utiliser AWS Management Console ou divers outils de programmation pour supprimer
des clés d'accès pour l'utilisateur racine.
Pour supprimer une clé d'accès de l'utilisateur racine (console)
1.
Connectez-vous à AWS Management Console à l'aide des informations d'identification de votre
compte (et non pas en tant qu'utilisateur IAM ), puis ouvrez la console IAM à partir de https://
console.aws.amazon.com/iam/. Une page de connexion utilisateur IAM comporte trois zones de
texte ; vous ne pouvez pas vous connecter en tant qu’utilisateur racine sur cette page. S'il s'avère
que vous êtes sur une page de connexion utilisateur IAM, commencez par sélectionner le lien
Sign-in using root account credentials qui figure sous les zones de texte de la page.
2.
Sur la page IAM Dashboard, choisissez le nom de votre compte dans la barre de navigation, puis
sélectionnez Security Credentials.
279
Activer MFA sur l'utilisateur racine
3.
Si un avertissement à propos de l'accès aux informations d'identification de sécurité de votre
compte AWS s'affiche, choisissez Continue to Security Credentials.
4.
5.
Développez la section Access Keys (Access Key ID and Secret Access Key).
Recherchez la clé d'accès que vous souhaitez supprimer, puis, sous la colonne Actions,
choisissez Delete.
Note
Vous pouvez marquer une clé d'accès comme inactive au lieu de la supprimer. Cela vous
permet de la réutiliser ultérieurement sans avoir à modifier l'ID de clé ou la clé secrète.
Lorsqu'elle est inactive, toute tentative d'utilisation dans les requêtes à l'API AWS échoue
avec l’état Accès refusé.
Pour supprimer une clé d'accès pour l'utilisateur racine (par programmation)
Utilisez l'une des commandes suivantes :
Activer MFA sur l'utilisateur racine
Une autre bonne pratique de sécurité consiste à toujours activer l'authentification multi-facteurs (MFA)
pour tout utilisateur autorisé à effectuer des opérations sensibles dans votre compte. Il existe plusieurs
types de MFA. Pour plus d'informations sur l'activation de MFA;, consultez les ressources suivantes :
• Activer MFA virtuel pour l'utilisateur racine (p. 97)
• Activer un appareil MFA physique pour l'utilisateur racine (p. 100)
• Lors de prévisualisation de MFA SMS, il n'est pas possible d'utiliser MFA basé sur SMS pour
l'utilisateur racine (p. 102).
Modification du mot de passe de l'utilisateur racine
Pour plus d'informations sur la modification du mot de passe de l'utilisateur racine, consultez
Modification du mot de passe (« racine ») du compte AWS (p. 78).
280
Autorisations
Gestion de l'accès
Lorsque vous utilisez les informations d'identification racine de votre compte, vous pouvez accéder à
toutes les ressources de votre compte AWS. Par contre, lorsque vous créez des utilisateurs IAM, des
groupes IAM ou des rôles IAM, vous devez explicitement accorder des autorisations à ces entités pour
que les utilisateurs puissent accéder à vos ressources AWS.
Cette section décrit les autorisations qui sont des droits que vous accordez à un utilisateur, groupe
ou rôle pour définir les tâches que des utilisateurs sont autorisés à exécuter dans votre compte AWS.
Pour définir des autorisations, vous utilisez des stratégies qui sont des documents au format JSON.
Pour en savoir plus, nous vous recommandons de lire les sections suivantes :
• Présentation des autorisations d'AWS IAM (p. 281) : Cette section présente les types
d'autorisations, et explique comment accorder et gérer les autorisations.
• Présentation des stratégies IAM (p. 294) : Cette section explique comment spécifier les actions
qui sont autorisées, sur quelles ressources autoriser les actions et l'effet que cela aura sera lorsque
l'utilisateur demande l'accès aux ressources.
• Utilisation de stratégies (p. 323) : Cette section explique comment créer et gérer des stratégies à
l'aide d'AWS Management Console, de la AWS CLI et de l'API IAM.
• Test des stratégies IAM avec le simulateur de stratégies IAM (p. 331) : Cette section explique
comment tester des stratégies d'utilisateur et de groupe à l'aide du simulateur de stratégies IAM.
• Utilisation du programme de validation de stratégies (p. 339) : Cette section explique comment
utiliser le programme de validation de stratégies lorsque vous disposez de stratégies non conformes
à la syntaxe des stratégies AWS.
• Référence de stratégie AWS IAM (p. 402) : Cette section décrit les éléments, les variables et la
logique d'évaluation utilisés dans les stratégies.
• Exemples de stratégies de gestion de ressources IAM (p. 287) : Cette section répertorie des
stratégies qui permettent à des utilisateurs d'exécuter des tâches spécifiques à IAM, comme
administrer des utilisateurs, des groupes et des informations d'identification.
• Exemples de stratégies de gestion de ressources AWS (p. 347) : Cette section répertorie des
stratégies qui permettent à des utilisateurs d'exécuter des tâches liées à d'autres services AWS,
comme Amazon S3, Amazon EC2 et DynamoDB.
Présentation des autorisations d'AWS IAM
Les autorisations vous permettent de spécifier qui a accès aux ressources AWS et quelles actions
peuvent être exécutées sur ces ressources. Chaque utilisateur IAM démarre sans autorisation. En
d'autres termes, par défaut, les utilisateurs ne peuvent rien faire, pas même afficher leurs propres
281
Autorisations basées sur une identité (IAM)
et autorisations basées une ressource
clés d'accès. Pour autoriser un utilisateur à faire quelque chose, vous pouvez ajouter l'autorisation
à l'utilisateur (c'est-à-dire attacher une stratégie à l'utilisateur) ou ajouter l'utilisateur à un groupe
disposant de l'autorisation souhaitée.
Par exemple, vous pourriez accorder à un utilisateur l'autorisation d'afficher ses propres clés d'accès.
Vous pourriez également étendre cette autorisation et permettre également à chaque utilisateur de
créer, mettre à jour et la supprimer ses propres clés.
Lorsque vous accordez des autorisations à un groupe, tous les utilisateurs de ce groupe obtiennent
ces autorisations. Par exemple, vous pouvez accorder au groupe Administrateurs l'autorisation
d'effectuer toutes les actions IAM sur n'importe quelle des ressources de compte AWS. Un autre
exemple : vous pouvez accorder au groupe Gestionnaires l'autorisation de décrire les instances
Amazon EC2 du compte AWS.
Pour plus d'informations sur la façon de déléguer des autorisations de base à vos utilisateurs, groupes
et rôles, consultez Délégation des autorisations d'administration des utilisateurs, des groupes et des
informations d'identification IAM (p. 285). Pour obtenir des exemples supplémentaires de stratégies
illustrant des autorisations de base, consultez Exemples de stratégies de gestion de ressources
IAM (p. 287).
Autorisations basées sur une identité (IAM) et
autorisations basées une ressource
Des autorisations peuvent être attribuées de deux manières : basées sur une identité ou basées sur
une ressource.
• Les autorisations basées sur une identité ou IAM sont attachées à un utilisateur, un groupe
ou un rôle IAM et vous permettent de spécifier ce que peut faire cet utilisateur, ce groupe ou
ce rôle. Par exemple, vous pouvez attribuer des autorisations à l'utilisateur IAM nommé Bob
en indiquant qu'il est autorisé à utiliser l'action Amazon Elastic Compute Cloud (Amazon EC2)
RunInstances et à extraire des éléments d'une table Amazon DynamoDB nommée MyCompany.
Vous pouvez également accorder à l'utilisateur Bob un accès pour gérer ses propres informations
d'identification de sécurité IAM. Les autorisations basées sur une identité peuvent être gérées ou en
ligne (p. 299).
• Les autorisations basées sur une ressource sont attachées à une ressource. Vous pouvez spécifier
des autorisations basées sur une ressources pour des compartiments Amazon S3, des coffres
Amazon Glacier, des rubriques Amazon SNS, des files d'attente Amazon SQS et des clés de
chiffrement AWS Key Management Service. Les autorisations basées sur une ressource vous
permettent de spécifier qui a accès à la ressource et quelles actions peuvent être exécutées. Les
autorisations basées sur une ressource sont en ligne uniquement, pas gérées.
Note
Il existe une différence entre les autorisations basées sur une ressource et les autorisations
de niveau ressource. Les autorisations basées sur une ressource sont les autorisations, que
vous pouvez attacher directement à une ressource, comme décrit dans cette rubrique. Les
autorisations de niveau ressource font référence à la possibilité de spécifier non seulement
les actions que des utilisateurs peuvent exécuter, mais également sur quelles ressources ils
sont autorisés à effectuer ces actions. Certains services AWS vous permettent de spécifier
des autorisations pour des actions, mais ne vous permettent de spécifier les ressources
individuelles pour ces actions. D'autres services vous permettent de spécifier des autorisations
pour une combinaison d'actions et de ressources individuelles.
Les autorisations basées sur une ressource ne sont prises en charge que par certains services
AWS. Pour obtenir la liste des services qui prennent en charge les autorisations de niveau
ressource, consultez Services AWS qui fonctionnent avec IAM (p. 394).
282
Autorisations basées sur une identité (IAM)
et autorisations basées une ressource
La figure suivante illustre les deux types d'autorisations. La première colonne indique les autorisations
attachées à des identités (deux utilisateurs et deux groupes). Certaines de ces autorisations identifient
des ressources spécifiques sur lesquelles les actions peuvent être utilisées. Ces actions prennent en
charge les autorisations de niveau ressource. La deuxième colonne indique les autorisations attachées
aux ressources. Ces services prennent en charge les autorisations basées sur une ressource.
Note
Lorsque vous attachez une stratégie à une ressource AWS (y compris la stratégie
d'approbation d'un rôle IAM), AWS valide, traite et transforme la stratégie que vous écrivez
avant de la stocker. Lorsque AWS renvoie la stratégie n réponse à une requête d'utilisateur,
AWS retransforme la stratégie en un format compréhensible par les utilisateurs. Cela
peut entraîner des différences quant à ce que vous voyez dans la stratégie : des espaces
non significatifs peut être supprimés, des éléments dans des mappes JSON peuvent être
réorganisés et des ID de compte AWS au sein des éléments Principal peuvent être remplacés
par l'ARN de l’utilisateur racine du compte. En raison de ces changements possibles, vous ne
devez pas comparer les documents de stratégie JSON sous forme de chaînes.
Un utilisateur qui dispose d'autorisations spécifiques peut demander une ressource à laquelle des
autorisations sont attachées. Dans ce cas, les deux ensembles d'autorisations sont évalués lorsque
AWS détermine s'il convient d'accorder l'accès à la ressource. Pour plus d'informations sur la manière
dont les stratégies sont évaluées, consultez Logique d'évaluation de stratégies IAM (p. 441).
283
Note
Des créateurs de ressource ne reçoivent
pas automatiquement des autorisations
Amazon S3 prend en charge des stratégies pour les utilisateurs IAM et pour les ressources
(appelées dans Amazon S3 des stratégies de compartiment). En outre, Amazon S3 prend en
charge un mécanisme d'autorisation appelé ACL qui est indépendant des stratégies et des
autorisations IAM. Vous pouvez utiliser des stratégies IAM combinées à des ACL (liste de
contrôle d'accès) Amazon S3. Pour en savoir plus, consultez Contrôle d'accès dans le manuel
Amazon Simple Storage Service Manuel du développeur.
Des créateurs de ressource ne reçoivent pas
automatiquement des autorisations
Une personne qui utilise des informations d'identification de sécurité du compte AWS est autorisée
à effectuer n'importe quelle action sur les ressources qui appartiennent au compte. Toutefois, ce
n'est pas le cas pour les utilisateurs IAM. Un utilisateur IAM peut recevoir un accès pour créer une
ressource, mais les autorisations de cet utilisateur, même pour cette ressource, se limitent à ce qui
a été explicitement accordé. L'autorisation de l'utilisateur peut être révoquée à tout moment par le
propriétaire du compte ou par un autre utilisateur disposant d'un accès pour gérer les autorisations
utilisateurs.
Octroi d'autorisations dans des comptes AWS
Vous pouvez accorder directement à des utilisateurs IAM de votre propre compte un accès à vos
ressources. Si des utilisateurs d'un autre compte ont besoin d'accéder à vos ressources, vous
pouvez créer un rôle IAM qui est une entité incluant des autorisations, mais qui n'est pas associée
à un utilisateur spécifique. Les utilisateurs d'autres comptes peuvent alors utiliser le rôle et accéder
aux ressources selon les autorisations que vous avez attribuées à ce rôle. Pour de plus amples
informations, veuillez consulter Rôles IAM (p. 140).
Note
Pour les services qui prennent en charge des stratégies basées sur les ressources,
comme indiqué dans Autorisations basées sur une identité (IAM) et autorisations basées
une ressource (p. 282) (par exemple Amazon S3, Amazon SNS, et Amazon SQS),
une alternative à l'utilisation des rôles consiste à associer une stratégie à la ressource
(compartiment, rubrique ou file d'attente) que vous souhaitez partager. La stratégie basée sur
les ressources peut spécifier le compte AWS qui dispose des autorisations pour accéder à la
ressource.
Autorisations pour qu'un service accède à un autre
service
De nombreux services AWS accèdent à d'autres services AWS. Par exemple, plusieurs
services AWS, y compris Amazon EMR, Elastic Load Balancing, et Auto Scaling,, gèrent
des instances Amazon EC2. D'autres services AWS utilisent des compartiments Amazon
S3, des rubriques Amazon SNS, des files d'attente Amazon SQS etc.
Le scénario pour gérer des autorisations dans ces cas varie selon le service. Voici des
exemples de la façon dont les autorisations sont gérées pour différents services :
• Dans Auto Scaling, les utilisateurs doivent être autorisé à utiliser Auto Scaling, mais n'ont
pas besoin de recevoir explicitement l'autorisation de gérer des instances Amazon EC2.
284
Délégation des autorisations d'administration
des utilisateurs, des groupes et des
IAM ce que peut faire un pipeline ; les
• Dans AWS Datainformations
Pipeline, und'identification
rôle IAM détermine
utilisateurs ont besoin d'une autorisation pour assumer le rôle. (Pour plus d'informations,
consultez Octroi d'autorisations à des pipelines avec IAM dans le manuel AWS Data
Pipeline Guide du développeur.)
Pour les détails sur la façon de configurer correctement des autorisations pour que le service AWS
soit en mesure d'effectuer les tâches prévues, reportez-vous à la documentation du service que vous
appelez.
Configuration d'un service avec un rôle IAM pour l'exécution d'une tâche en votre nom
Si vous souhaitez configurer un service AWS pour qu'il exécute une tâche en votre nom, vous
fournissez généralement l'ARN d'un rôle IAM qui définit les opérations que le service est autorisé à
effectuer. AWS vérifie que vous disposez des autorisations nécessaires pour transférer un rôle à un
service. Pour plus d'informations, consultez Octroi d'autorisations à un utilisateur pour transférer un
rôle à un service AWS (p. 217).
des utilisateurs, des groupes et des informations
d'identification IAM
Si vous êtes connecté avec les informations d'identification d'un compte (racine) AWS, vous n'avez
aucune restrictions pour administrer des utilisateurs IAM ou des groupes ou pour gérer leurs
informations d'identification. Toutefois, les utilisateurs IAM doivent se voir accorder explicitement des
autorisations pour administrer des utilisateurs ou des informations d'identification pour eux-mêmes ou
d'autres utilisateurs IAM. Cette rubrique décrit les stratégies IAM qui permettent aux utilisateurs IAM de
gérer d'autres utilisateurs et des informations d'identification d'utilisateurs.
Rubriques
• Présentation (p. 285)
• Autorisations pour utiliser l'AWS Management Console (p. 286)
• Exemples de stratégies de gestion de ressources IAM (p. 287)
Présentation
En général, les autorisations requises pour administrer des utilisateurs, des groupes et des
informations d'identification correspondent aux actions d'API de la tâche. Par exemple, pour créer
des utilisateurs, un utilisateur doit disposer de l'autorisation iam:CreateUser (commande API :
CreateUser). Pour autoriser un utilisateur à créer d'autres utilisateurs IAM, vous pouvez attacher une
stratégie comme celle qui suit à cet utilisateur :
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:CreateUser",
"Resource": "*"
}
}
Dans une stratégie, la valeur de l'élément Resource dépend de l'action et des ressources que cette
action peut affecter. Dans l'exemple précédent, la stratégie autorise un utilisateur à créer un autre
285
informations
utilisateur (* est un caractère générique
quid'identification
correspond àIAM
toutes les chaînes). En revanche, une
stratégie qui autorise les utilisateurs à modifier uniquement leurs propres clés d'accès (actions d'API
CreateAccessKey et UpdateAccessKey) dispose généralement d'un élément Resource dans
lequel l'ARN inclut une variable qui renvoie au nom utilisateur actuel, comme dans l'exemple suivant
(remplacez ACCOUNT-ID-WITHOUT-HYPHENS par l'ID de votre compte AWS) :
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:CreateAccessKey",
"iam:UpdateAccessKey"
],
"Resource": "arn:aws:iam::accountid:user/${aws:username}"
}
}
Dans l'exemple précédent, ${aws:username} est une variable qui renvoie au nom utilisateur de
l'utilisateur actuel. Pour plus d'informations sur les variables de stratégie, consultez Présentation des
variables de stratégie IAM (p. 430).
L'utilisation d'un caractère générique (*) dans le nom d'action facilite souvent l'octroi d'autorisations
pour toutes les actions associées à une tâche spécifique. Par exemple, pour autoriser des utilisateurs
à exécuter n'importe quelle action IAM, vous pouvez utiliser iam:* pour l'action. Pour autoriser les
utilisateurs à effectuer n'importe quelle action associée uniquement aux clés d'accès, vous pouvez
utiliser iam:*AccessKey* dans l'élément Action d'une déclaration de stratégie. Cela permet
d'accorder à l'utilisateur l'autorisation d'effectuer les actions CreateAccessKey, DeleteAccessKey,
GetAccessKeyLastUsed, ListAccessKeys et UpdateAccessKey. (Si, à l'avenir, une action est
ajoutée à IAM avec « AccessKey » dans son nom, l'utilisation de iam:*AccessKey* pour l'élément
Action accordera également à l'utilisateur l'autorisation d'exécuter cette action.) L'exemple suivant
indique une stratégie qui permet aux utilisateurs d'exécuter toutes les actions correspondant à leurs
propres clés d'accès (remplacez ACCOUNT-ID-WITHOUT-HYPHENS par l'ID de votre compte AWS) :
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:*AccessKey*",
"Resource": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:user/
${aws:username}"
}
}
Certaines tâches, comme la suppression d'un groupe, impliquent plusieurs actions : vous devez
d'abord supprimer les utilisateurs du groupe, puis détacher ou supprimer les stratégie du groupe et
enfin supprimer réellement le groupe. Si vous souhaitez qu'un utilisateur supprime un groupe, vous
devez vous assurer d'accorder à celui-ci les autorisations nécessaires pour exécuter toutes les actions
associées.
Autorisations pour utiliser l'AWS Management Console
Les exemples précédents illustrent les stratégies autorisant un utilisateur à exécuter les actions avec
l'AWS CLI ou les kits SDK AWS. Si les utilisateurs souhaitent utiliser l'AWS Management Console
pour administrer des utilisateurs, des groupes et des autorisations, ils ont besoin d'autorisations
supplémentaires. À mesure que les utilisateurs se servent de la console, celle-ci envoie des demandes
286
informations
IAMles stratégies associées à un utilisateur ou
à IAM pour répertorier les utilisateurs
et lesd'identification
groupes, obtenir
à un groupe, obtenir des informations de compte AWS, etc.
Par exemple, si l'utilisateur Bob souhaite utiliser la console pour modifier ses propres clés d'accès, il
accède à la console IAM et choisit Users. Cette action indique à la console d'effectuer une demande
ListUsers. Si Bob n'a pas l'autorisation d'exécuter l'action iam:ListUsers, la console se voit
refuser l'accès lorsqu'elle essaie de répertorier les utilisateurs. En conséquence, Bob ne peut accéder
à son propre nom et à ses propres clés d'accès, même s'il a l'autorisation d'exécuter les actions
CreateAccessKey et UpdateAccessKey.
Si vous souhaitez accorder à des utilisateurs les autorisations leur permettant d'administrer des
utilisateurs, des groupes et des informations d'identification avec l'AWS Management Console, vous
devez inclure des autorisations concernant les actions exécutées par la console. Pour obtenir des
exemples de stratégies que vous pouvez utiliser pour accorder ces autorisations à un utilisateur,
consultez Exemples de stratégies de gestion de ressources IAM (p. 287).
Exemples de stratégies de gestion de ressources IAM
Voici des exemples de stratégies IAM qui autorisent les utilisateurs à exécuter des tâches associées à
la gestion des utilisateurs, des groupes et des informations d'identification IAM. Il s'agit notamment de
stratégies permettant aux utilisateurs de gérer leurs propres mots de passe, clés d'accès et appareils
MFA (Multi-Factor Authentication).
Pour des exemples de stratégies qui permettent aux utilisateurs d'exécuter des tâches liées à d'autres
services AWS comme Amazon S3, Amazon EC2 et DynamoDB, consultez Exemples de stratégies de
gestion de ressources AWS (p. 347).
Rubriques
• Autoriser les utilisateurs à gérer leurs propres mots de passe (à partir de la page My
Password) (p. 287)
• Autoriser les utilisateurs à gérer leurs propres mots de passe, clés d'accès et clés SSH (p. 288)
• Autoriser un utilisateur à répertorier les groupes, les utilisateurs et les stratégies d'un compte, ainsi
que d'autres informations à des fins d'élaboration de rapports (p. 289)
• Autoriser un utilisateur à gérer l'adhésion à un groupe (p. 290)
• Autoriser un utilisateur à gérer les utilisateurs IAM (p. 290)
• Autoriser les utilisateurs à définir la stratégie de mot de passe du compte (p. 291)
• Autoriser les utilisateurs à générer et extraire des rapports d'informations d'identification
IAM (p. 292)
• Autoriser les utilisateurs à gérer uniquement leurs propres appareils MFA virtuels (p. 292)
• Autoriser toutes les actions IAM (Accès Admin) (p. 293)
Autoriser les utilisateurs à gérer leurs propres mots de passe (à partir de la
page My Password)
Si la stratégie de mot de passe (p. 79) du compte est configurée de manière à autoriser tous les
utilisateurs à modifier leurs mots de passe, il n'est pas nécessaire d'attacher d'autorisations à
des utilisateurs individuels ou à des groupes. Tous les utilisateurs peuvent accéder à la page My
Password (p. 88) dans AWS Management Console, ce qui leur permet de modifier leur mot de passe.
Si la stratégie de mot de passe du compte n'est pas définie de façon à permettre à tous les utilisateurs
de modifier leurs propres mots de passe, vous pouvez attacher la stratégie suivante aux utilisateurs
ou groupes sélectionnés pour leur permettre de ne changer que leurs propres mots de passe. Cette
stratégie permet uniquement aux utilisateurs d'utiliser la page My Password spéciale de la console ;
elle ne leur octroie pas d'autorisations pour travailler par le biais du tableau de bord de la console IAM.
287
{
informations d'identification IAM
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:GetAccountPasswordPolicy",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:ChangePassword",
${aws:username}"
}
]
}
Si les utilisateurs n'utilisent pas la console pour modifier leur mot de passe, ils n'ont pas besoin
d'autorisation iam:GetAccountPasswordPolicy. Ils peuvent exécuter la commande aws iam
change-password à partir de l'AWS CLI à la place, ou exécuter une requête à l'aide de l'action
ChangePassword.
Pour plus d'informations sur la gestion des mots de passe d'utilisateurs sélectionnés à partir de la
section Users de la console IAM, consultez la section suivante.
Autoriser les utilisateurs à gérer leurs propres mots de passe, clés d'accès et
clés SSH
La stratégie suivante permet aux utilisateurs d'effectuer les actions suivantes dans AWS Management
Console :
• Créer, modifier ou supprimer leur propre mot de passe. Cela inclut les actions
CreateLoginProfile, DeleteLoginProfile, GetLoginProfile et UpdateLoginProfile.
• Créer ou supprimer leur propre clé d'accès (ID de clé d'accès et clé d'accès secrète). Cela inclut les
actions CreateAccessKey, DeleteAccessKey, GetAccessKeyLastUsed, ListAccessKeys et
UpdateAccessKey.
• Créer ou supprimer leurs propres clés SSH. Cela inclut les actions UploadSSHPublicKey,
DeleteSSHPublicKey, GetSSHPublicKey, ListSSHPublicKeys et UpdateSSHPublicKey.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:*LoginProfile",
"iam:*AccessKey*",
"iam:*SSHPublicKey*"
],
${aws:username}"
},
{
"Effect": "Allow",
"Action": [
"iam:ListAccount*",
288
"iam:GetAccountSummary",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
Dans la stratégie précédente, les actions incluent des caractères génériques (par exemple,
iam:*LoginProfile,iam:*AccessKey* et iam:*SSHPublicKey*). Il s'agit là d'un moyen
pratique pour inclure un ensemble d'actions associées. Si vous souhaitez supprimer les autorisations
pour l'une des actions associées, vous devez répertorier individuellement chacune des actions.
Par exemple, si vous ne voulez pas que les utilisateurs puissent supprimer un mot de passe, vous
devez répertorier individuellement iam:CreateLoginProfile, iam:GetLoginProfile et
iam:UpdateLoginProfile, et omettre iam:DeleteLoginProfile.
Le deuxième élément du tableau Statement, y compris les autorisations iam:GetAccountSummary,
iam:GetAccountPasswordPolicy, iam:ListAccount* et iam:ListUsers, permet à l'utilisateur
d'afficher certaines informations sur le tableau de bord de la console IAM, par exemple la présence
éventuelle d'une stratégie de mot de passe, le nombre de groupes d'un compte, l'URL et l'alias du
compte, etc. Par exemple, l'action GetAccountSummary retourne un objet qui contient un ensemble
d'informations relatives au compte qui sont ensuite affichées sur le tableau de bord de la console IAM.
La stratégie suivante est semblable à la précédente, mais elle exclut les autorisations requises
uniquement pour l'accès à la console. Cette stratégie permet aux utilisateurs de gérer leurs
informations d'identification à l'aide de l'AWS CLI, de Outils pour Windows PowerShell, des kits SDK
AWS ou de l'API de requête HTTP IAM.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:*LoginProfile",
"iam:*AccessKey*",
"iam:*SSHPublicKey*"
],
${aws:username}"
}
}
Autoriser un utilisateur à répertorier les groupes, les utilisateurs et les
stratégies d'un compte, ainsi que d'autres informations à des fins d'élaboration
de rapports
La stratégie suivante permet à l'utilisateur d'appeler toute action IAM qui commence par la chaîne Get
ou List.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:Get*",
289
"iam:List*"
],
"Resource": "*"
}
}
L'avantage de l'utilisation des actions Get* et List* réside dans le fait que si de nouveaux types
d'entités sont ajoutés à IAM par la suite, l'accès octroyé dans la stratégie à toutes les actions Get* et
List* permettra automatiquement à l'utilisateur de répertorier ces nouvelles entités.
Autoriser un utilisateur à gérer l'adhésion à un groupe
La stratégie suivante permet à l'utilisateur de mettre à jour l'adhésion à un groupe nommé
MarketingGroup. Pour utiliser la stratégie suivante, remplacez ACCOUNT-ID-WITHOUT-HYPHENS par
votre ID de compte AWS.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:AddUserToGroup",
"iam:RemoveUserFromGroup",
"iam:GetGroup"
],
"Resource": "arn:aws:iam::account-id-without-hyphens:group/
MarketingGroup"
}
}
Autoriser un utilisateur à gérer les utilisateurs IAM
La stratégie suivante permet à un utilisateur d'exécuter toutes les tâches associées à la gestion des
utilisateurs IAM, mais pas d'effectuer d'actions sur d'autres entités, par exemple la création de groupes
ou de stratégies. Les actions autorisées sont notamment :
• Création de l'utilisateur (action CreateUser).
• Suppression de l'utilisateur. Cette tâche requiert des autorisations pour effectuer toutes les actions
suivantes : DeleteSigningCertificate, DeleteLoginProfile, RemoveUserFromGroup et
DeleteUser.
• Liste des utilisateurs du compte et des groupes (actions GetUser, ListUsers et
ListGroupsForUser).
• Liste et suppression des stratégies pour l'utilisateur (actions ListUserPolicies,
ListAttachedUserPolicies, DetachUserPolicy, DeleteUserPolicy)
• Changement de nom ou modification du chemin d'accès pour l'utilisateur (action UpdateUser).
L'élément Resource doit inclure un ARN qui inclut à la fois le chemin d'accès source et le chemin
d'accès cible. Pour plus d'informations sur les chemins d'accès, consultez Noms conviviaux et
chemins (p. 387).
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowUsersToPerformUserActions",
"Effect": "Allow",
290
"Action": [
"iam:CreateUser",
"iam:ListUsers",
"iam:GetUser",
"iam:UpdateUser",
"iam:DeleteUser",
"iam:ListGroupsForUser",
"iam:ListUserPolicies",
"iam:ListAttachedUserPolicies",
"iam:DeleteSigningCertificate",
"iam:DeleteLoginProfile",
"iam:RemoveUserFromGroup",
"iam:DetachUserPolicy",
"iam:DeleteUserPolicy"
],
"Resource": "*"
},
{
"Sid": "AllowUsersToSeeStatsOnIAMConsoleDashboard",
"Effect": "Allow",
"Action": [
"iam:GetAccount*",
"iam:ListAccount*"
],
"Resource": "*"
}
]
}
Plusieurs autorisations incluses dans la stratégie précédente permettent à l'utilisateur d'exécuter
des tâches dans AWS Management Console. Les utilisateurs qui exécutent des tâches liées
à l'utilisateur à partir de l'AWS CLI, des kits SDK AWS ou de l'API de requête HTTP IAM
uniquement peuvent ne pas disposer de certaines autorisations. Par exemple, si les utilisateurs
connaissent déjà l'ARN des stratégies à détacher d'un utilisateur, ils n'ont pas besoin d'autorisation
iam:ListAttachedUserPolicies. La liste exacte des autorisations requises par un utilisateur varie
en fonction des tâches qu'il doit effectuer lorsqu'il gère d'autres utilisateurs.
Les autorisations suivantes de la stratégie permettent l'accès aux tâches utilisateur via AWS
Management Console :
• iam:GetAccount*
• iam:ListAccount*
Autoriser les utilisateurs à définir la stratégie de mot de passe du compte
Vous pouvez accorder à certains utilisateurs des autorisations leur permettant de récupérer et de
mettre à jour la stratégie de mot de passe (p. 79) de votre compte AWS. L'exemple de stratégie suivant
accorde ces autorisations.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:UpdateAccountPasswordPolicy"
],
291
"Resource": "*"
}
}
Autoriser les utilisateurs à générer et extraire des rapports d'informations
d'identification IAM
Vous pouvez autoriser les utilisateurs à générer et télécharger un rapport qui répertorie tous les
utilisateurs de votre compte AWS et l'état de leurs diverses informations d'identification, notamment
les mots de passe, les clés d'accès, les appareils MFA, et les certificats de signature. L'exemple de
stratégie suivant accorde ces autorisations.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:GenerateCredentialReport",
"iam:GetCredentialReport"
],
"Resource": "*"
}
}
Pour plus d'informations sur les rapports d'informations d'identification, consultez the section called
“Obtention de rapports d'informations d'identification” (p. 123).
Autoriser les utilisateurs à gérer uniquement leurs propres appareils MFA
virtuels
Un appareil MFA virtuel (p. 96) est l'implémentation logicielle d'un appareil qui fournit des mots de
passe uniques. Les appareils MFA virtuels sont hébergés sur un périphérique matériel physique
(généralement un smartphone). Pour configurer un appareil MFA virtuel, vous devez avoir accès à
l'appareil physique sur lequel l'appareil MFA virtuel est hébergé. Si vos utilisateurs créent des appareils
MFA virtuels dans une application sur leur propre smartphone, il est peut-être préférable de les laisser
configurer eux-mêmes les appareils. Pour plus d'informations sur l'utilisation d'appareils MFA virtuels
avec IAM, consultez Activation d'un périphérique d'authentification multi-facteurs (MFA) virtuel (p. 96).
La stratégie suivante permet à un utilisateur de configurer et de gérer son propre appareil MFA virtuel
à partir de AWS Management Console ou à l'aide de n'importe quel outil de ligne de commande. La
stratégie autorise uniquement les utilisateurs authentifiés par MFA à désactiver et supprimer leurs
propres appareils MFA virtuels.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowUsersToCreateEnableResyncDeleteTheirOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ResyncMFADevice",
"iam:DeleteVirtualMFADevice"
],
"Resource": [
292
"arn:aws:iam::account-id-without-hyphens:mfa/${aws:username}",
"arn:aws:iam::account-id-without-hyphens:user/${aws:username}"
]
},
{
"Sid": "AllowUsersToDeactivateTheirOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice"
],
"Resource": [
"arn:aws:iam::account-id-without-hyphens:mfa/${aws:username}",
"arn:aws:iam::account-id-without-hyphens:user/${aws:username}"
],
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": true
}
}
},
{
"Sid": "AllowUsersToListMFADevicesandUsersForConsole",
"Effect": "Allow",
"Action": [
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
Note
L'action iam:DeleteVirtualMFADevice ne fait pas l'objet d'un contrôle de condition MFA,
parce qu'elle fait partie de la première instruction au lieu de la deuxième. Cela ne met pas la
sécurité en péril, car vous ne pouvez supprimer un périphérique MFA qu'une fois que vous
l'avez désactivé, ce qu'un utilisateur peut faire uniquement s'il est authentifié MFA. Cela évite
un problème qui peut se produire si vous annulez l'assistant Créer un périphérique MFA
une fois qu'il a créé le périphérique, mais avant qu'il valide les deux codes et qu'il l'associe
à l'utilisateur. Étant donné que l'utilisateur n'est pas encore authentifié MFA à ce stade,
l'assistant (qui fonctionne avec les autorisations de l'utilisateur) ne parvient pas à nettoyer le
périphérique si la stratégie requiert l'authentification MFA pour le supprimer.
Autoriser toutes les actions IAM (Accès Admin)
Il est possible d'accorder à certains utilisateurs des autorisations administratives leur permettant
d'effectuer toutes les actions dans IAM, y compris la gestion des mots de passe et des clés
d'accès, des appareils MFA et des certificats utilisateur. L'exemple de stratégie suivant accorde ces
autorisations.
Caution
Lorsque vous accordez l'accès complet à IAM, à un utilisateur, aucune limite ne s'applique
aux autorisations que cet utilisateur peut octroyer à d'autres utilisateurs ou à lui-même. Ainsi,
l'utilisateur peut créer de nouvelles entités IAM (utilisateurs ou rôles) et leur accorder un accès
total à toutes les ressources de votre compte AWS. Lorsque vous accordez l'accès complet
293
Stratégies
à IAM à un utilisateur, vous lui donnez en réalité un accès total à toutes les ressources
de votre compte AWS. Cela inclut la possibilité de supprimer toutes les ressources. Vous
devez octroyer ces autorisations aux administrateurs approuvés uniquement, et vous devez
également mettre en œuvre l'authentification multi-facteurs (MFA) pour ces administrateurs.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "iam:*",
"Resource": "*"
}
}
Présentation des stratégies IAM
Cette section fournit une présentation des stratégies IAM. Une stratégie est un document qui énonce
de manière formelle une ou plusieurs autorisations.
Pour obtenir des références complètes sur la syntaxe et la grammaire des stratégies IAM, consultez
Référence de stratégie AWS IAM (p. 402).
Rubriques
• Gestion des versions des stratégies gérées (p. 313)
• Stratégies gérées par AWS obsolètes (p. 315)
• Contrôle de l'accès aux stratégies gérées (p. 316)
• Création d'une stratégie (p. 321)
• Utilisation de stratégies (p. 323)
• Test des stratégies IAM avec le simulateur de stratégies IAM (p. 331)
• Utilisation du programme de validation de stratégies (p. 339)
• Données sur les services consultés en dernier (p. 342)
• Exemples de stratégies de gestion de ressources AWS (p. 347)
Introduction
Pour attribuer des autorisations à un utilisateur, un groupe, un rôle ou une ressource, vous devez créer
une stratégie, autrement dit un document qui répertorie explicitement les autorisations. Une stratégie
de base vous permet de spécifier les éléments suivants :
• Actions : Les actions que vous autoriserez. Chaque service AWS dispose de son propre ensemble
d'actions. Par exemple, vous pouvez autoriser un utilisateur à utiliser l'action ListBucket Amazon
S3, qui renvoie des informations sur les éléments d'un compartiment. Les actions que vous n'avez
pas autorisées de façon explicite sont refusées.
• Ressources : Les ressources sur lesquelles vous autorisez l'action. Par exemple, sur quels
compartiments Amazon S3 spécifiques autorisez-vous l'utilisateur à exécuter l'action ListBucket ?
Les utilisateurs ne peuvent pas accéder aux ressources auxquelles vous n'avez pas octroyé un
accès de façon explicite.
• Effet : L'effet produit lorsque l'utilisateur demande l'accès, qui peut être un accord ou un refus. Du
fait que la valeur par défaut spécifie que l'accès aux ressources est refusé aux utilisateurs, vous
spécifiez généralement que vous autoriserez les utilisateurs à accéder aux ressources.
294
Stratégies
Les stratégies sont des documents qui sont créés à l'aide de JSON. Une stratégie comporte une ou
plusieurs déclarations, chacune décrivant un ensemble d'autorisations. Voici un exemple de stratégie
simple.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
}
}
Vous pouvez attacher cette stratégie à un utilisateur ou à un groupe IAM. S'il s'agit de la seule
stratégie de l'utilisateur ou du groupe, celui-ci est autorisé à effectuer uniquement cette action
(ListBucket) sur un seul compartiment Amazon S3 (example_bucket).
Pour spécifier des autorisations basées sur des ressources, vous pouvez attacher une stratégie à la
ressource, comme une rubrique Amazon SNS, un compartiment Amazon S3 ou un coffre Amazon
Glacier. Dans ce cas, la stratégie doit inclure des informations sur la personne qui est autorisée à
accéder à la ressource, appelée le mandataire. (Pour les stratégies basées sur les utilisateurs, le
mandataire correspond à l'utilisateur IAM auquel est attachée la stratégie ou l'utilisateur qui obtient la
stratégie auprès d'un groupe).
L'exemple suivant affiche une stratégie qui peut être attachée à un compartiment Amazon S3 et qui
accorde des autorisations à un compte AWS spécifique pour effectuer des actions Amazon S3 dans
mybucket. Cela inclut l'utilisation du compartiment et les objets qu'il contient. (Du fait que la stratégie
accorde une approbation uniquement au compte, les utilisateurs individuels du compte doivent se voir
accorder des autorisations concernant les actions Amazon S3 spécifiées.)
{
"Version": "2012-10-17",
"Id": "S3-Account-Permissions",
"Statement": [{
"Sid": "1",
"Effect": "Allow",
"Principal": {"AWS": ["arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:root"]},
"Action": "s3:*",
"Resource": [
]
}]
}
Les stratégies IAM contrôlent l'accès, quelle que soit l'interface. Par exemple, vous pouvez fournir
un mot de passe à un utilisateur pour lui permettre d'accéder à AWS Management Console et les
stratégies de cet utilisateur (ou des groupes auxquels il appartient) contrôleront ce que l'utilisateur
peut faire dans AWS Management Console. Vous pouvez également fournir à l'utilisateur des clés
d'accès AWS pour effectuer des appels d'API à destination d'AWS, et les stratégies contrôleront les
actions que l'utilisateur peut appeler via une bibliothèque ou un client qui utilise ces clés d'accès pour
l'authentification.
Pour obtenir des exemples de stratégies de base qui englobent des scénarios courants, consultez
Exemples de stratégies de gestion de ressources AWS (p. 347), Services AWS qui fonctionnent
avec IAM (p. 394) et la page Exemples de stratégies AWS dans la section Exemples de code et
bibliothèques AWS du site web AWS.
295
Stratégies
Les stratégies gérée AWS et le générateur de stratégies sont disponibles dans la console IAM de
l'AWS Management Console. Pour plus d'informations sur la création de stratégies dans la console,
consultez Utilisation de stratégies (p. 323). De plus, vous pouvez utiliser le Générateur de stratégies
AWS en ligne pour créer des stratégies pour des produits AWS sans accéder à la console.
Important
Vous ne pouvez pas enregistrer une stratégie qui n'est pas conforme à la syntaxe établie des
stratégies. Vous pouvez utiliser le programme de validation de stratégies pour détecter et
corriger les stratégies non valides. Un seul clic vous permet d'accéder à un éditeur qui indique
la stratégie existante et contient une copie avec les modifications conseillées. Vous pouvez
accepter les modifications ou en apporter d'autres. Pour de plus amples informations, veuillez
consulter Utilisation du programme de validation de stratégies (p. 339).
Note
Lorsque vous appliquez une stratégie personnalisée, IAM vérifie sa syntaxe. Toutefois, étant
donné qu'IAM évalue les stratégies au moment de l'exécution en utilisant un contexte de
demande spécifique (dans lequel plusieurs stratégies peuvent être en vigueur), il ne peut
pas vérifier la validité de toutes les ressources, actions et autorisations dans une stratégie
personnalisée au moment où vous appliquez la stratégie. Si vous avez besoin d'aide lors de
la création d'une stratégie, nous vous conseillons d'utiliser une stratégie gérée AWS ou le
générateur de stratégies. Pour obtenir de l'aide afin de tester les effets de vos stratégies IAM,
consultez Test des stratégies IAM avec le simulateur de stratégies IAM (p. 331).
Plusieurs déclarations et plusieurs stratégies
Vous pouvez attacher plusieurs stratégies à une entité. Si vous disposez de plusieurs autorisations à
accorder à une entité, vous pouvez les placer dans des stratégies distinctes ou les placer toutes dans
une seule stratégie.
En général, chaque déclaration située dans une stratégie inclut des informations sur une seule
autorisation. Si votre stratégie inclut plusieurs déclarations, un OR logique est appliqué dans les
déclarations au moment de l'évaluation. De même, si plusieurs stratégies sont applicables à une
demande, un OR logique est appliqué dans les stratégies au moment de l'évaluation.
Plusieurs stratégies sont souvent appliquées à des utilisateurs (mais elles ne sont pas nécessairement
attachées à eux). Par exemple, des stratégies peuvent être attachées à l'utilisateur IAM Bob, et
d'autres stratégies peuvent être attachées au groupe dans lequel il se trouve. De plus, il peut accéder
à un compartiment Amazon S3 disposant de sa propre stratégie de compartiment (stratégie basée
sur les ressources). Toutes les stratégies applicables sont évaluées et le résultat indique toujours si
l'accès est accordé ou refusé. Pour plus d'informations sur la logique d'évaluation que nous utilisons,
consultez Logique d'évaluation de stratégies IAM (p. 441).
Structure d'une stratégie
Chaque stratégie est un document JSON. Comme illustré dans l'illustration suivante, une stratégie
inclut :
• Des informations facultatives sur l'ensemble de la stratégie (en haut du document)
• Une ou plusieurs déclarations individuelles
Chaque déclaration inclut des informations de base sur une seule autorisation. Si une stratégie inclut
plusieurs déclarations, AWS applique un OR logique dans les déclarations au moment de l'évaluation.
Si plusieurs stratégies sont applicables à une demande, AWS applique un OR logique dans les
stratégies au moment de l'évaluation.
296
Stratégies
Les informations contenues dans une déclaration sont situées dans une série d'éléments. Pour plus
d'informations sur ces éléments, consultez Références des éléments de stratégie IAM (p. 402).
297
Les stratégies incluent souvent plusieurs
déclarations,
qui accordent chacune des autorisations à
AWS Identity
and Access
un ensemble de ressources distinct
ou
dans
des
conditions
spécifiques. Par exemple, la stratégie
suivante comporte trois déclarations, chacune
accordant
un
ensemble d'autorisations distinct.
Stratégies
Supposons que l'utilisateur ou le groupe auquel la stratégie est attachée se trouve dans un compte
AWS
123456789012
. (Lesplusieurs
stratégiesdéclarations
ne peuvent pas faire référence à des ressources dans d'autres
Example
Stratégie avec
comptes.) Les déclarations exécutent les opérations suivantes :
• La première déclaration, avec un élément Sid (ID de déclaration) défini sur FirstStatement,
permet aux utilisateurs de gérer leurs propres mots de passe. L'élément Resource de cette
déclaration est défini sur « * » (ce qui signifie « toutes les ressources »), mais en pratique, l'API
ChangePassword (ou la commande CLI change-password équivalente) affecte uniquement le mot
de passe de l'utilisateur qui fait la demande.
• La deuxième déclaration ("Sid": "SecondStatement") permet à l'utilisateur de répertorier tous
les compartiments Amazon S3 de son compte AWS. L'élément Resource de cette déclaration
est défini sur "*" (ce qui signifie « toutes les ressources »), mais du fait que les stratégies
n'accordent pas l'accès aux ressources d'autres comptes, l'utilisateur peut uniquement répertorier
les compartiments de son propre compte AWS. (Cette autorisation est nécessaire à l'utilisateur pour
accéder à un compartiment depuis AWS Management Console.)
• La troisième déclaration ("Sid": "ThirdStatement") permet à l'utilisateur de répertorier et
Lorsqu'une
de stratégie
contient
un élément Condition
, la déclaration est effective
de récupérerdéclaration
tous les objets
situés dans
un compartiment
appelé confidential-data
, mais
uniquement
est true.
ce cas,d'identification
la Conditionàest
trueterme
lorsque
uniquement lorsque
une fois l'élément
qu'il s'estCondition
authentifié avec
des Dans
informations
court
l'utilisateur
est
authentifié
MFA.
Si
l'utilisateur
n'est
pas
authentifié
MFA,
cette
Condition
validées par un périphérique d'authentification multi-facteurs (MFA). L'élément Conditionest
de false.
la
Dans
ce
cas,
la
troisième
déclaration
de
cette
stratégie
ne
sera
pas
effective
et
'utilisateur
n'aura
stratégie vérifie si l'utilisateur est authentifié MFA et, le cas échéant, l'utilisateur peut répertorier etpas
accès
au compartiment
.
récupérer
tous les objetsconfidential-data
situés dans le compartiment.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "FirstStatement",
"Effect": "Allow",
"Action": ["iam:ChangePassword"],
"Resource": "*"
},
{
"Sid": "SecondStatement",
"Effect": "Allow",
"Resource": "*"
},
{
"Sid": "ThirdStatement",
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*"
],
"Resource": [
"arn:aws:s3:::confidential-data",
"arn:aws:s3:::confidential-data/*"
],
}
]
}
298
Stratégies gérées et stratégies en ligne
A l'aide d'IAM, vous pouvez affecter des autorisations à des utilisateurs, groupes ou rôles IAM (appelés
entités mandataires) en créant des stratégies. Il est possible de créer deux types de stratégies IAM, ou
basées sur une identité :
• Stratégies gérées – Stratégies autonomes que vous pouvez attacher à plusieurs utilisateurs,
groupes et rôles de votre compte AWS. Les stratégies gérées s'appliquent uniquement aux identités
(utilisateurs, groupes et rôles), et pas aux ressources. Vous pouvez utiliser deux types de stratégies
gérées :
• Stratégies gérées par AWS – Stratégies gérées qui sont créées et gérées par AWS. Si vous n'êtes
pas encore familiarisé avec les stratégies, nous vous recommandons de commencer par utiliser
des stratégies gérées par AWS.
• Stratégies gérées par le client – Stratégies gérées que vous créez et gérez dans votre compte
AWS. Lorsque vous utilisez des stratégies gérées par le client, vous pouvez contrôler les
stratégies avec davantage de précision que lors de l'utilisation de stratégies gérées par AWS.
• Stratégies en ligne – Stratégies que vous créez et gérez et qui sont intégrées directement à un
utilisateur, groupe ou rôle. Les stratégies basées sur les ressources constituent un autre type de
stratégie en ligne. Elles ne sont pas abordées ici. Pour plus d'informations sur les stratégies basées
sur les ressources, consultez Autorisations basées sur une identité (IAM) et autorisations basées
une ressource (p. 282).
Les stratégies basées sur une identité (IAM) peuvent être en ligne ou gérées. Les stratégies basées
sur les ressources sont attachées à des ressources (en ligne) uniquement et ne sont pas gérées.
De manière générale, le contenu des stratégies est identique dans tous les cas. Chaque type de
stratégie définit un ensemble d'autorisations à l'aide d'une structure et syntaxe communes.
Note
Dans le cas de stratégies gérées par AWS et par le client, la valeur de l'élément Version de
la stratégie doit être 2012-10-17. La valeur de l'élément Version des stratégies en ligne
peut être 2012-10-17 ou 2008-10-17. Il est recommandé de définir l'élément Version sur
2012-10-17 pour toutes les stratégies.
Pour plus d'informations sur l'élément Version, consultez Version (p. 403) dans les
Références des éléments de stratégie de ce guide.
Vous pouvez associer des types de stratégies différents. Il n'est pas nécessaire de se limiter à un seul
type.
Les sections suivantes contiennent d'autres informations sur chaque type de stratégie et sur la façon
de les utiliser.
Rubriques
• Stratégies gérées par AWS (p. 300)
• Stratégies gérées par le client (p. 301)
• Stratégies en ligne (p. 302)
• Choix entre les stratégies gérées et les stratégies en ligne (p. 303)
• Stratégies gérées par AWS pour les activités professionnelles (p. 304)
299
Stratégies gérées par AWS
Une stratégie gérée par AWS est une stratégie qui est créée et gérée par AWS. Ces stratégies sont
dites autonomes, ce qui signifie que chaque stratégie a son propre Amazon Resource Name (ARN)
incluant le nom de la stratégie.
Les stratégies gérées par AWS sont conçues pour affecter des autorisations dans de nombreux
cas d'utilisation courants. Par exemple, il existe des stratégies gérées par AWS qui définissent des
autorisations standard pour les administrateurs (tous les accès), les utilisateurs avancés (tous les
accès excepté IAM) et pour divers niveaux d'accès aux services AWS. Les stratégies gérées par AWS
simplifient l'octroi d'autorisations appropriées aux utilisateurs, groupes et rôles et vous évitent d'avoir à
créer vous-même les stratégies.
Une catégorie particulièrement utile de stratégies gérées par AWS sont celles conçues pour les
fonctions professionnelles. Ces stratégies correspondent à des fonctions professionnelles couramment
utilisées dans le secteur de l'informatique. Le but est de faciliter l'accord d'autorisations pour ces
fonctions professionnelles courantes. L'un des avantages clés de l'utilisation des stratégies de
fonctions professionnelles vient du fait qu'elles sont gérées et mises à jour par AWS au fur et à mesure
que de nouveaux services et de nouvelles API sont ajoutés. Pour obtenir la liste et la description
des stratégies de fonctions professionnelles, consultez la page Stratégies gérées par AWS pour les
activités professionnelles (p. 304).
Vous ne pouvez pas modifier les autorisations définies dans les stratégies gérées par AWS.
Occasionnellement, AWS met à jour les autorisations définies dans une stratégie gérée par AWS.
Dans ce cas, la mise à jour affecte toutes les entités mandataires (utilisateurs, groupes et rôles)
auxquelles la stratégie est attachée. Il est probable qu'AWS mette à jour une stratégie gérée par
AWS lors du lancement de nouveaux services AWS ou lorsque la stratégie doit inclure de nouvelles
autorisations pour de nouveaux services ou API. Par exemple, la stratégie gérée par AWS appelée
ReadOnlyAccess fournit un accès en lecture seule à l'ensemble des services et ressources AWS.
Lorsqu'AWS lance un nouveau service, la stratégie ReadOnlyAccess doit être mise à jour pour ajouter
des autorisations d'accès en lecture seule à ce nouveau service. Les autorisations mises à jour
s'appliquent à toutes les entités mandataires auxquelles la stratégie est attachée.
Le diagramme suivant illustre des stratégies gérées par AWS. Il comporte trois stratégies gérées par
AWS, à savoir AdministratorAccess, PowerUserAccess et AWSCloudTrailReadOnlyAccess. Notez
qu'une stratégie gérée par AWS peut être attachée à des entités mandataires de différents comptes
AWS, ainsi qu'à différentes entités mandataires d'un même compte AWS.
300
Stratégies gérées par le client
Vous pouvez créer des stratégies autonomes que vous gérez dans votre propre compte AWS ; cellesci sont appelées stratégies gérées par le client. Vous pouvez ensuite les attacher à plusieurs entités
mandataires de votre compte AWS. Lorsque vous attachez une stratégie à une entité mandataire, vous
accordez à cette dernière les autorisations définies dans la stratégie.
Pour créer une stratégie gérée par le client, une bonne méthode consiste à commencer par copier une
stratégie gérée par AWS. De cette façon, vous êtes sûr que la stratégie est correcte au départ ; il vous
suffit ensuite de la personnaliser en fonction de votre environnement.
Le diagramme suivant illustre des stratégies gérées par le client. Chaque stratégie est une entité dans
IAM avec son propre Amazon Resource Name (ARN) dans lequel figure le nom de la stratégie. Notez
qu'une même stratégie peut être attachée à plusieurs entités mandataires, par exemple la stratégie
DynamoDB-books-app est attachée à deux rôles IAM différents.
301
Stratégies en ligne
Une stratégie en ligne est une stratégie qui est intégrée à une entité mandataire (utilisateur, groupe ou
rôle), autrement dit elle fait partie intégrante de l'entité mandataire. Vous pouvez créer une stratégie et
l'intégrer à une entité mandataire, soit lors de la création de l'entité mandataire, soit plus tard.
Le diagramme suivant illustre des stratégies en ligne. Chaque stratégie fait partie intégrante de
l'utilisateur, du groupe ou du rôle. Notez que deux rôles incluent la même stratégie (stratégie
DynamoDB-books-app), sans toutefois partager une même stratégie, car chacun dispose de sa propre
copie.
302
Choix entre les stratégies gérées et les stratégies en ligne
Les différents types de stratégies correspondent à différents cas d'utilisation. Dans la plupart des cas,
nous vous recommandons d'utiliser des stratégies gérées plutôt que des stratégies en ligne.
Les stratégies gérées fournissent les fonctions suivantes :
Réutilisation
Une même stratégie gérée peut être attachée à plusieurs entités mandataires (utilisateurs,
groupes et rôles). En réalité, vous pouvez créer une bibliothèque de stratégies qui définissent des
autorisations utiles pour votre compte AWS, puis attacher ces stratégies aux entités mandataires
comme requis.
303
Gestion centralisée des modifications
Lorsque vous modifiez une stratégie gérée, le changement est appliqué à toutes les entités
mandataires auxquelles la stratégie est attachée. Par exemple, pour ajouter l'autorisation
nécessaire pour une nouvelle API AWS, vous pouvez mettre à jour la stratégie gérée afin d'y
ajouter l'autorisation. (Si vous utilisez une stratégie gérée par AWS, AWS met à jour la stratégie.)
Une fois la stratégie modifiée, les changements sont appliqués à toutes les entités mandataires
auxquelles la stratégie est attachée. En revanche, pour modifier une stratégie en ligne, vous devez
modifier individuellement chaque entité mandataire contenant la stratégie. Par exemple, si un
groupe et un rôle contiennent tous les deux la même stratégie en ligne, vous devez modifier les
deux entités mandataires pour changer la stratégie.
Versioning et restauration
Les modifications apportées aux stratégies gérées sont mises en œuvre en tant que versions ;
la modification d'une stratégie gérée crée une nouvelle version de la stratégie, avec un nouvel
identificateur de version. Vous pouvez utiliser les versions de stratégie pour restaurer une version
antérieure, si nécessaire.
Pour plus d'informations sur les versions de stratégie, consultez Gestion des versions des
stratégies gérées (p. 313).
Délégation de la gestion des autorisations
Vous pouvez autoriser les utilisateurs de votre compte AWS à attacher et détacher des stratégies,
tout en conservant le contrôle sur les autorisations définies dans ces stratégies. Vous pouvez ainsi
désigner quelques utilisateurs en tant qu'administrateurs disposant de droits complets, autrement
dit autorisés à créer, mettre à jour et supprimer des stratégies. D'autres utilisateurs peuvent
être désignés en tant qu'administrateurs avec des droits limités ; ceux-ci peuvent attacher des
stratégies à d'autres entités mandataires, mais uniquement celles que vous les avez autorisés à
attacher.
Pour plus d'informations sur la délégation de la gestion des autorisations, consultez Contrôle de
l'accès aux stratégies gérées (p. 316).
Mises à jour automatiques de stratégies gérées par AWS
AWS maintient les stratégies gérées par AWS et les met à jour lorsque cela est nécessaire (par
exemple, pour ajouter des autorisations pour de nouveaux services AWS), sans intervention de
votre part. Les mises à jour sont automatiquement appliquées aux entités mandataires auxquelles
vous avez attaché la stratégie gérée par AWS.
Utilisation de stratégies en ligne
Les stratégies en ligne sont utiles pour conserver une relation un-à-un stricte entre une stratégie et
l'entité mandataire à laquelle elle est appliquée. Par exemple, vous voulez éviter que les autorisations
d'une stratégie ne soient accidentellement affectées à une entité mandataire autre que celle à laquelle
elles sont destinées. Lorsque vous utilisez une stratégie en ligne, ses autorisations ne peuvent pas
être attachées par inadvertance à la mauvaise entité mandataire. De plus, lorsque vous supprimez
l'entité mandataire à l'aide d'AWS Management Console, les stratégies intégrées à celle-ci sont
également supprimées, car elles font partie intégrante de l'entité mandataire.
Stratégies gérées par AWS pour les activités professionnelles
Les stratégies gérées par AWS pour les activités professionnelles sont conçues de manière à s'aligner
étroitement sur les tâches courantes du secteur de l'informatique. Vous pouvez utiliser ces stratégies
pour accorder facilement les autorisations nécessaires afin d'exécuter les tâches prévues de la part
quelqu'un occupant une fonction spécifique. Ces stratégies regroupent les autorisations pour de
nombreux services dans une seule stratégie plus facile à utiliser que des autorisations dispersées dans
de nombreuses stratégies.
Vous pouvez lier ces stratégies d'activités professionnelles à n'importe quel groupe, utilisateur ou rôle.
Utiliser des rôles pour combiner les services
304
Certaines des stratégies utilisent des rôles de services IAM pour vous aider à tirer parti des
fonctionnalités disponibles dans d'autres services AWS. Ces stratégies accordent l'accès à
iam:passrole, qui permet à un utilisateur avec la stratégie de passer un rôle à un service AWS. Ce
rôle délègue des autorisations IAM pour que le service AWS puisse exécuter des actions de votre part.
Vous devez créer les rôles selon vos besoins. Par exemple, la stratégie d'administrateur réseau
permet de transmettre un rôle nommé « flow-logs-vpc » au service Amazon CloudWatch. CloudWatch
utilise ce rôle pour enregistrer et capturer le trafic IP pour les VPC créés par l'utilisateur.
Pour s'accorder aux meilleures pratiques de sécurité, les stratégies pour les activités professionnelles
incluent des filtres qui limitent les noms de rôles valides possibles à transmettre. Cela permet d’éviter
d'accorder des autorisations inutiles. Si vos utilisateurs ont besoin des rôles de services facultatifs,
vous devez créer un rôle qui suit la convention d'affectation de noms spécifiée dans la stratégie. Vous
pouvez ensuite accorder des autorisations pour le rôle. L'utilisateur peut alors configurer le service
pour utiliser ce rôle, et lui octroyer toutes les autorisations fournies par le rôle.
Actualisation
Ces stratégies sont toutes gérées par AWS et sont actualisées pour inclure la prise en charge des
nouveaux services et de nouvelles fonctionnalités ajoutés par AWS. Elles ne peuvent pas être
modifiées par les clients. Vous pouvez faire une copie de la stratégie, puis modifier cette copie,
mais elle ne sera pas automatiquement actualisée lorsqu'AWS introduit de nouveaux services et de
nouvelles API.
Activités professionnelles
Noms de stratégies
• Administrateur (p. 305)
• Facturation (p. 305)
• Administrateur de base de données (p. 306)
• Spécialiste des données (p. 307)
• Utilisateur avancé développeur (p. 308)
• Administrateur réseau (p. 308)
• Administrateur système (p. 309)
• Auditeur de sécurité (p. 310)
• Utilisateur du support (p. 310)
• Utilisateur en affichage seul (p. 310)
Dans les sections suivantes, chaque nom de stratégie comporte un lien vers la page des détails de la
stratégie en question dans AWS Management Console où vous pouvez consulter le document de la
stratégie pour connaître les autorisations accordées.
Administrateur
Nom de stratégie gérée par AWS : AdministratorAccess
Cas d'utilisation : cet utilisateur a un accès total et peut déléguer des autorisations à tous les services
et toutes les ressources dans AWS.
Description de la stratégie : cette stratégie permet toutes les actions pour tous les services et toutes les
ressources AWS du compte.
Facturation
Nom de stratégie gérée par AWS : Billing
305
Cas d'utilisation : cet utilisateur a besoin d'afficher les informations de facturation, de préparer un
paiement et d'autoriser un paiement. Il peut surveiller les coûts cumulés pour chaque service AWS.
Description de la stratégie : cette stratégie accorde des autorisations pour la gestion de la facturation
et du contrôle des coûts. Les autorisations comprennent l'affichage et la modification des budgets et
des modes de paiement.
Note
Pour qu’un utilisateur IAM puisse accéder à la console AWS Billing and Cost Management
avec cette stratégie, vous devez tout d'abord activer l'accès à la console Billing and Cost
Management pour le compte. Pour ce faire, suivez les instructions de l'étape 1 du didacticiel
portant sur comment déléguer l'accès à la console de facturation (p. 21).
Administrateur de base de données
Nom de stratégie gérée par AWS : DatabaseAdministrator
Cas d'utilisation : cet utilisateur met en place, configure et gère des bases de données dans le Cloud
AWS.
Description de la stratégie : cette stratégie accorde des autorisations pour créer, configurer et gérer
des bases de données. Elle comprend l'accès à tous les services de base de données AWS, tels que
Amazon DynamoDB, Amazon ElastiCache, Amazon Relational Database Service (RDS), Amazon
Redshift et d'autres services de prise en charge.
Cette stratégie prend en charge la possibilité de transmettre des rôles aux services AWS. Elle accorde
iam:GetRole et iam:PassRole seulement pour les rôles nommés dans le tableau suivant. Pour plus
d'informations, consultez Création des rôles et association des stratégies (p. 310) plus loin dans cette
rubrique.
Rôles de services IAM facultatifs pour la fonction d'administrateur de base de données
Cas d'utilisation
Nom de rôle (*
correspond à un
caractère générique)
Type de rôle
de service à
sélectionner
Sélectionner cette
stratégie gérée par AWS
Permettre à l'utilisateur de
surveiller des bases de
données RDS
rds-monitoring-role
Rôle Amazon
RDS de
surveillance
améliorée
AmazonRDSEnhancedMonitoringRole
Autoriser AWS Lambda
à surveiller votre base de
données et à accéder à
des bases de données
externes
rdbms-lambdaaccess
Amazon EC2
AWSLambdaFullAccess
Autoriser Lambda à
charger des fichiers sur
des clusters Amazon S3
et Amazon Redshift avec
DynamoDB
lambda_exec_role
AWS Lambda
Créer une nouvelle
stratégie gérée, tel que
défini dans le blog AWS
sur le Big Data
Autoriser les fonctions
Lambda à agir comme
déclencheurs pour vos
tables DynamoDB
lambda-dynamodb-*
AWS Lambda
AWSLambdaDynamoDBExecutionRole
306
Cas d'utilisation
Nom de rôle (*
correspond à un
Type de rôle
de service à
sélectionner
Sélectionner cette
stratégie gérée par AWS
Autoriser les fonctions
Lambda pour accéder au
RDS dans un VPC
lambda-vpcexecution-role
Créer un rôle
AWSLambdaVPCAccessExecutionRole
avec une stratégie
d'approbation, tel
que défini dans
le AWS Lambda
Developer Guide
Autoriser AWS Data
Pipeline à accéder à vos
ressources AWS
DataPipelineDefaultRoleCréer un rôle
AWSDataPipelineRole
avec une stratégie
d'approbation, tel
que défini dans
le AWS Data
Pipeline Guide du
développeur
Permettre à vos
applications qui s'exécutent
sur des instances Amazon
EC2 d'accéder à vos
ressources AWS
DataPipelineDefaultResourceRole
Créer un rôle
AmazonEC2RoleforDataPipelineRole
avec une stratégie
d'approbation, tel
que défini dans
le AWS Data
Pipeline Guide du
développeur
Spécialiste des données
Nom de stratégie gérée par AWS : DataScientist
Cas d'utilisation : cet utilisateur exécute des tâches et des requêtes Hadoop. Il accède également à
des informations de données analytiques et d'aide à la décision, et analyse ces informations.
Description de la stratégie : cette stratégie accorde des autorisations pour créer, gérer et exécuter
des requêtes sur un cluster Amazon EMR, et effectuer des analyses de données avec des outils tels
qu'Amazon Quicksight. La stratégie comprend l'accès à AWS Data Pipeline, Amazon EC2, Amazon
Elasticsearch Service, Amazon Elastic File System, Amazon EMR, Amazon Kinesis, Amazon Kinesis
Analytics, Amazon Machine Learning, Amazon RDS et Amazon Redshift.
Cette fonction prend en charge la possibilité de transmettre des rôles à des services AWS. Elle
accorde iam:GetRole et iam:PassRole seulement pour les rôles nommés dans le tableau suivant.
Pour plus d'informations, consultez Création des rôles et association des stratégies (p. 310) plus loin
dans cette rubrique.
Rôles de services IAM facultatifs pour la fonction de spécialiste des données
Cas d'utilisation
Nom de rôle (*
correspond à un
Type de rôle
de service à
sélectionner
Autoriser les instances
Amazon EC2 à accéder aux
services et aux ressources
appropriés pour les clusters
EMREC2_DefaultRole
Amazon Elastic
AmazonElasticMapReduceforEC2Role
MapReduce for EC2
Autoriser Amazon EMR
à accéder au service et
EMR_DefaultRole
Amazon Elastic
MapReduce
307
Stratégie gérée par
AWS à sélectionner
AmazonElasticMapReduceRole
Cas d'utilisation
Nom de rôle (*
correspond à un
Type de rôle
de service à
sélectionner
Autoriser Amazon Kinesis
Analytics à accéder aux
sources de données de
diffusion
kinesis-*
Créer un rôle
avec une stratégie
d'approbation, tel
que défini dans le
blog AWS sur le Big
Data.
Consultez le
blog AWS sur
le Big Data, qui
définit les quatre
options possibles en
fonction de votre cas
d'utilisation
Autoriser AWS Data Pipeline
à accéder à vos ressources
AWS
DataPipelineDefaultRoleCréer un rôle
avec une stratégie
d'approbation, tel
que défini dans
le AWS Data
Pipeline Guide du
développeur
AWSDataPipelineRole
Permettre à vos applications
qui s'exécutent sur des
instances Amazon EC2
d'accéder à vos ressources
AWS
DataPipelineDefaultResourceRole
Créer un rôle
avec une stratégie
d'approbation, tel
que défini dans
le AWS Data
Pipeline Guide du
développeur
AmazonEC2RoleforDataPipelineRole
ressources Amazon EC2 pour
les clusters
Utilisateur avancé développeur
Nom de stratégie gérée par AWS : PowerUserAccess
Cas d'utilisation : cet utilisateur effectue des tâches de développement d'application et peut créer et
configurer des ressources et des services qui prennent en charge le développement d'applications
compatibles avec AWS.
Description de la stratégie : cette stratégie accorde des autorisations d'affichage, de lecture et
d'écriture d'autorisations pour divers services AWS destinés au développement d'applications, y
compris Amazon API Gateway, Amazon AppStream, Amazon CloudSearch, AWS CodeCommit, AWS
CodeDeploy, AWS CodePipeline, AWS Device Farm, Amazon DynamoDB, Amazon Elastic Compute
Cloud, Amazon EC2 Container Service (ECS), AWS Lambda, Amazon RDS, Amazon Route 53,
Amazon Simple Storage Service (S3), Amazon Simple Email Service (SES), Amazon Simple Queue
Service (SQS) et Amazon Simple Workflow Service (SWF).
Administrateur réseau
Nom de stratégie gérée par AWS : NetworkAdministrator
Cas d'utilisation : cet utilisateur est chargé de mettre en place et de gérer les ressources réseau AWS.
Description de la stratégie : cette stratégie accorde des autorisations de création et de gestion des
ressources réseau dans Amazon EC2, Amazon Route 53, Amazon Virtual Private Cloud (VPC) et AWS
Direct Connect.
Cette fonction exige de pouvoir transmettre des rôles à des services AWS. Elle accorde iam:GetRole
et iam:PassRole seulement pour les rôles nommés dans le tableau suivant. Pour plus d'informations,
consultez Création des rôles et association des stratégies (p. 310) plus loin dans cette rubrique.
308
Rôles de services IAM facultatifs pour la fonction d'administrateur réseau
Cas d'utilisation
Nom de rôle (*
correspond à un
Type de rôle
de service à
sélectionner
Permet à Amazon VPC de
créer et de gérer des journaux
CloudWatch de la part de
l'utilisateur pour contrôler le
trafic IP entrant et sortant de
votre VPC
flow-logs-*
Créer un rôle
avec une stratégie
d'approbation, tel
que défini dans le
Amazon VPC Guide
de l'utilisateur
Ce cas d'utilisation
ne dispose pas de
stratégie gérée par
AWS existante, mais
la documentation
répertorie les
autorisations
requises. Consultez
le Amazon VPC
Guide de l'utilisateur.
Administrateur système
Nom de stratégie gérée par AWS : SystemAdministrator
Cas d'utilisation : cet utilisateur établit et gère les ressources pour les opérations de développement.
Description de la stratégie : cette stratégie accorde des autorisations de création et de gestion des
ressources pour un vaste éventail de services AWS, y compris AWS CloudTrail, Amazon CloudWatch,
AWS CodeCommit, AWS CodeDeploy, AWS Config, AWS Directory Service, Amazon EC2, AWS
Identity and Access Management, AWS Key Management Service, AWS Lambda, Amazon RDS,
Amazon Route 53, Amazon S3, Amazon SES, Amazon SQS, AWS Trusted Advisor et Amazon VPC.
Cette fonction exige de pouvoir transmettre des rôles à des services AWS. Elle accorde iam:GetRole
et iam:PassRole seulement pour les rôles nommés dans le tableau suivant. Pour plus d'informations,
consultez Création des rôles et association des stratégies (p. 310) plus loin dans cette rubrique.
Rôles de services IAM facultatifs pour la fonction d'administrateur système
Cas d'utilisation
Nom de rôle (*
correspond à un
Type de rôle
de service à
sélectionner
Autoriser les applications
s'exécutant dans des
instances EC2 d'un cluster
Amazon ECS à accéder à
Amazon ECS
ecr-sysadmin-*
Rôle Amazon EC2
pour EC2 Container
Service
AmazonEC2ContainerServiceforEC2Rol
Permettre à un utilisateur
de surveiller des bases de
données
rds-monitoring-role
Rôle Amazon RDS
de surveillance
améliorée
AmazonRDSEnhancedMonitoringRole
Autorisez les applications
s'exécutant dans des
instances EC2 à accéder aux
ressources AWS.
ec2-sysadmin-*
Amazon EC2
Exemple de
stratégie de rôle qui
accorde l'accès à
un compartiment
S3 comme illustré
dans le Amazon EC2
Guide de l'utilisateur
pour les instances
Linux ; personnaliser
309
Cas d'utilisation
Nom de rôle (*
correspond à un
Type de rôle
de service à
sélectionner
en fonction des
besoins
Autoriser Lambda à lire des
flux DynamoDB et à écrire
dans les journaux CloudWatch
lambda-sysadmin-*
AWS Lambda
AWSLambdaDynamoDBExecutionRole
Auditeur de sécurité
Nom de stratégie gérée par AWS : SecurityAudit
Cas d'utilisation : cet utilisateur surveille les comptes pour leur conformité aux exigences de sécurité. Il
peut accéder aux journaux et aux événements pour rechercher des brèches de sécurité potentielles ou
d'éventuelles activités malveillantes.
Description de la stratégie : cette stratégie accorde des autorisations d'affichage des données de
configuration de nombreux services AWS et permet la consultation de leur journaux.
Utilisateur du support
Nom de stratégie gérée par AWS : SupportUser
Cas d'utilisation : cet utilisateur contacte le support AWS, crée des demandes de support et consulte le
statut des demandes existantes.
Description de la stratégie : cette stratégie accorde des autorisations de création et de mise à jour de
demandes de support AWS.
Utilisateur en affichage seul
Nom de stratégie gérée par AWS : ViewOnlyAccess
Cas d'utilisation : cet utilisateur peut afficher une liste de metadonnées de base et de ressources AWS
du compte sur tous les services. Il ne peut pas lire le contenu des ressources ou les metadonnées audelà des informations de quotas et de listes des ressources.
Description de la stratégie : cette stratégie accorde les accès List* et Describe* aux ressources
pour chaque service AWS.
Création des rôles et association des stratégies
Plusieurs des stratégies mentionnées ci-dessus permettent de configurer des services AWS avec des
rôles qui autorisent ces services à effectuer des opérations de votre part. Les stratégies de fonctions
professionnelles spécifient les noms de rôles exacts à utiliser ou incluent au moins un préfixe qui
indique la première partie du nom qui peut être utilisé. Pour créer un de ces rôles, suivez les étapes de
la procédure ci-dessous.
Pour créer un rôle de service IAM pour une fonction professionnelle
1.
2.
3.
Dans le volet de navigation de la console IAM, choisissez Roles, puis Create New Role.
Pour Role name, tapez un nom de rôle qui correspond aux critères pour le nom spécifié dans la
stratégie gérée pour la fonction (dans la colonne Role Name des tableaux ci-dessus). Après avoir
tapé le nom, sélectionnez Next Step en bas.
310
4.
Si nécessaire, développez la section AWS Service Roles, puis sélectionnez Select pour le type
de rôle de service spécifié dans la colonne Type de rôle de service à sélectionner du tableau
correspondant. Si aucun type de rôle de service n'est spécifié dans le tableau, sélectionnez
Amazon EC2. Vous devrez modifier ultérieurement la stratégie d'approbation pour le rôle afin de
remplacer le point de terminaison de service EC2 par celui qui doit assumer le rôle. Pour plus
d'informations, consultez l'exemple 2 (p. 311).
5.
Si une stratégie gérée est spécifiée dans le tableau, sélectionnez la case à cocher correspondant
à cette stratégie afin d'accorder les autorisations que vous souhaiter octroyer au service. Si le
tableau spécifie autre chose qu’une stratégie gérée existante, vous pouvez ignorer cette étape,
créer la stratégie plus tard selon la documentation et puis l'associer au rôle.
6.
Cliquez sur Next Step pour vérifier le rôle. Ensuite, cliquez sur Create Role.
Exemple 1 : Configuration d'un utilisateur en tant qu’administrateur de base de
données
Cet exemple reprend les étapes requises pour configurer Alice, une utilisatrice IAM, comme
administratrice de base de données (p. 306) au moyen des informations de la première ligne
du tableau de cette section, et lui permettre d'activer la surveillance RDS. Vous devez associer la
stratégie DatabaseAdministrator à l'utilisatrice IAM correspondant à Alice afin de lui permettre de gérer
les services de base de données Amazon. Cette stratégie permet également à Alice de transmettre un
rôle appelé rds-monitoring-role au service RDS qui permet à ce dernier de surveiller les bases
de données RDS de sa part.
1.
2.
Sélectionnez Policies, puis tapez database dans la zone de recherche.
3.
Sélectionnez la stratégie DatabaseAdministrator, sélectionnez Policy Actions, puis Attach.
4.
Dans la liste des utilisateurs, sélectionnez Alice, puis choisissezAttach Policy. Alice peut
désormais administrer les bases de données AWS. Cependant, pour permettre à Alice de
surveiller ces bases de données, vous devez configurer le rôle du service.
5.
Sélectionnez Roles, puis Create New Role.
6.
Le nom du rôle doit figurer parmi ceux spécifiés par la stratégie DatabaseAdministrator qu'Alice
possède désormais. Parmi eux se trouvent rds-monitoring-role. Tapez ce nom de rôle, puis
sélectionnez Next Step.
7.
Selon la première ligne du tableau, sous AWS Service Roles sélectionnez Select en regard de
Amazon RDS Role for Enhanced Monitoring.
8.
Après avoir revu les détails, sélectionnez Create Role.
9.
Alice peut désormais activer RDS Enhanced Monitoring dans la section Monitoring de la console
RDS lorsqu'elle crée une instance de base de données ou un réplica en lecture, ou quand elle
modifie une instance de base de données. Elle doit fournir le nom de rôle qu'elle a créé (rdsmonitoring-role) dans la zone Monitoring Role lorsqu'elle paramètre Enable Enhanced Monitoring
sur Yes.
Exemple 2 : Configuration d'un utilisateur en tant qu’administrateur réseau
Cet exemple reprend les étapes requises pour la configuration de Juan, un utilisateur IAM, comme
administrateur réseau (p. 308) au moyen des informations du tableau de cette section, et lui
permettre de surveiller le trafic IP en provenance et à destination d'un VPC, ainsi que de consigner ces
informations dans des journaux CloudWatch. Vous devez associer la stratégie NetworkAdministrator
à l'utilisateur IAM correspondant à Juan afin de lui permettre de configurer les ressources de réseau
AWS. Cette stratégie permet également à Juan de transmettre un rôle dont le nom commence
par flow-logs* à Amazon EC2 lorsque vous créez un journal de flux. Dans ce scénario, à la
311
différence de l'exemple 1, il n'y a aucun type de rôle de service prédéfini. Vous devez donc procéder
différemment pour certaines étapes.
1.
2.
Dans le volet de navigation, sélectionnez Policies, puis tapez network dans la zone de
recherche.
3.
Sélectionnez la stratégie NetworkAdministrator, choisissez Policy Actions, puis Attach.
4.
Dans la liste des utilisateurs, sélectionnez Juan, puis choisissezAttach Policy. Juan peut
désormais administrer les ressources réseau AWS. Cependant, pour activer la surveillance du
trafic IP dans votre VPC, vous devez configurer le rôle de service.
5.
Comme le rôle de service à créer n'a pas de stratégie gérée prédéfinie, il doit d'abord être créé.
Dans le volet de navigation, sélectionnez Policies, puis Create Policy.
6.
Choisissez Select en regard de Create Your Own Policy.
7.
Pour Policy Name, tapez vpc-flow-logs-policy-for-service-role.
8.
Dans Policy Document, copiez et collez le texte suivant :
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
9.
Sélectionnez Create Policy pour enregistrer vos changements.
10. Sélectionnez Roles, puis Create New Role.
11. Le nom du rôle doit être autorisé par la stratégie NetworkAdministrator que possède désormais
Juan. Tout nom qui commence par flow-logs- est autorisé. Pour cet exemple, tapez flowlogs-for-juan comme nom de rôle, puis sélectionnez Next Step.
12. Sur la page Attach Policy, choisissez la stratégie que vous avez créée plus tôt, vpc-flow-logspolicy-for-service-role, puis sélectionnez Next Step.
13. Après avoir revu les détails, sélectionnez Create Role.
14. Vous pouvez désormais configurer la stratégie d'approbation nécessaire pour ce scénario.
Sélectionnez la stratégie flow-logs-for-juan (le nom, pas la case à cocher), puis l'onglet Trust
Relationships et enfin Edit Trust Relationship.
15. Modifier la ligne « Service » comme suit, en remplaçant l'entrée pour ec2.amazonaws.com :
"Service": "vpc-flow-logs.amazonaws.com"
16. Alice peut désormais créer des journaux de flux pour un VPC ou un sous-réseau dans la console
Amazon EC2. Lorsque vous créez le journal de flux, spécifiez le rôle flow-logs-for-juan. Ce rôle
dispose des autorisations pour créer le journal et y consigner des données.
312
Gestion des versions des stratégies gérées
Lorsque vous apportez des modifications à une stratégie gérée par le client, et que AWS effectue
des changements sur une stratégie gérée AWS, la stratégie modifiée ne remplace pas la stratégie
existante. À la place, IAM crée une nouvelle version de la stratégie gérée. Le diagramme suivant
illustre cela.
Vous pouvez utiliser ces versions pour effectuer le suivi d'une stratégie gérée. Par exemple,
vous pouvez modifier une stratégie gérée et découvrir ensuite que le changement a eu des effets
inattendus. Dans ce cas, vous pouvez revenir à un version précédente de la stratégie gérée en
définissant la version précédente comme version par défaut.
Les sections suivantes expliquent comment utiliser la gestion des versions avec les stratégies gérées.
Rubriques
• Définition de la version par défaut (p. 313)
• Utilisation de versions pour annuler des modifications (p. 314)
• Limites de version (p. 315)
Définition de la version par défaut
L'une des versions d'une stratégie gérée est définie comme la version par défaut. La version par défaut
de la stratégie est la version d'exécution, c'est-à-dire qu'il s'agit de la version en vigueur pour toutes les
entités mandataires (utilisateurs, groupes et rôles) auxquelles la stratégie gérée est attachée.
Lorsque vous créez une stratégie gérée par le client, la stratégie commence par une version unique
identifiée comme v1. Pour les stratégies gérées avec une version unique, cette version est définie
automatiquement comme valeur par défaut. Pour les stratégies gérées par le client avec plusieurs
versions, vous choisissez la version à définir par défaut. Pour les stratégies gérées AWS, la version
par défaut est définie par AWS. Les diagrammes suivants illustrent ce concept.
313
Vous pouvez définir la version par défaut de vos stratégies gérées par le client, mais AWS définit la
version par défaut des stratégies gérées AWS. Vous définissez la version par défaut d'une stratégie
gérée par le client à l'aide de l'AWS Management Console, l'AWS Command Line Interface ou de l'API
IAM.
Utilisation de versions pour annuler des modifications
Lorsque vous apportez des modifications à une stratégie gérée par le client, vos modifications sont
stockées comme des versions de la stratégie. Dans certains cas, vous pouvez souhaiter annuler vos
modifications. Par exemple, imaginez le scénario suivant.
Vous créez une stratégie gérée par le client qui autorise les utilisateurs à administrer un compartiment
Amazon S3 spécifique à l'aide de l'AWS Management Console. À sa création, votre stratégie gérée
par le client dispose d'une version unique, identifiée comme v1. Cette version est donc définie
automatiquement comme valeur par défaut. La stratégie fonctionne comme prévu.
Plus tard, vous mettez à jour la stratégie pour ajouter l'autorisation d'administrer un second
compartiment Amazon S3. IAM crée une nouvelle version de la stratégie, identifiée comme v2,
contenant vos modifications. Vous définissez la version v2 comme version par défaut, et peu de temps
314
Stratégies gérées par AWS obsolètes
après, vos utilisateurs signalent qu'ils ne peuvent pas du tout utiliser la console Amazon S3 en raison
d'une erreur d'autorisation. Dans ce cas, vous pouvez revenir à la version v1 de la stratégie, que
vous savez fonctionner comme prévu. Pour cela, vous définissez la version v1 comme version par
défaut. Vous utilisateurs sont désormais en mesure d'utiliser la console Amazon S3 pour administrer le
compartiment d'origine.
Plus tard, après avoir identifié l'erreur dans la version v2 de la stratégie, vous remettez à jour la
stratégie pour ajouter l'autorisation d'administrer le second compartiment Amazon S3. IAM crée une
autre version de la stratégie, identifiée comme v3. Vous définissez la version v3 comme version
par défaut et cette version fonctionne comme prévu. À ce stade, vous supprimez la version v2 de la
stratégie.
Limites de version
Une stratégie gérée peut avoir jusqu'à cinq versions. Si vous devez modifier une stratégie gérée audelà de cinq versions, vous devez d'abord supprimer une ou plusieurs versions existantes. Vous
pouvez supprimer n'importe quelle version de la stratégie gérée de votre choix, sauf la version par
défaut.
Lorsque vous supprimez une version, les identificateurs de version des versions restantes ne changent
pas. En conséquence, les identificateurs de version peuvent ne pas être séquentiels. Par exemple,
si vous supprimez les versions v2 et v4 d'une stratégie gérée et que vous ajoutez deux nouvelles
versions, les identificateurs de version restants peuvent être v1, v3, v5, v6 et v7.
Stratégies gérées par AWS obsolètes
Pour simplifier l'affectation d'autorisations, AWS fournit des stratégies gérées (p. 299) qui sont des
stratégies prédéfinies, déjà attachées à vos utilisateurs, groupes et rôles IAM.
Dans certains cas, AWS doit ajouter une nouvelle autorisation à une stratégie existante, par exemple
lors de l'implémentation d'un nouveau service. L'ajout d'une nouvelle autorisation à une stratégie
existante n'impacte aucune des fonctions, pas plus qu'elle ne les supprime.
AWS doit néanmoins créer une nouvelle stratégie si les modifications nécessaires risquent
d'impacter les clients lors de leur application à une stratégie existante. Par exemple, la suppression
d'autorisations d'une stratégie existante peut affecter les autorisations d'une entité ou application IAM
qui en dépend, ce qui risque de perturber une opération critique.
Par conséquent, lorsqu'une telle modification est nécessaire, AWS crée une stratégie entièrement
nouvelle, avec les modifications requises, puis la rend accessible à ses clients. L'ancienne stratégie est
ensuite marquée comme étant obsolète. Une icône d'avertissement s'affiche en regard d'une stratégie
gérée obsolète dans la liste Policies de la console IAM.
Les caractéristiques d'une stratégie obsolète sont les suivantes :
• Elle continue à fonctionner pour tous les utilisateurs, groupes et rôles actuellement attachés. Aucun
élément ne cesse de fonctionner.
• Elle ne peut pas être attachée à de nouveaux utilisateurs, groupes ou rôles. Si vous la détachez
d'une entité actuelle, vous ne pouvez plus la rattacher par la suite.
• Une fois qu'elle a été détachée de toutes les entités actuelles, elle n'est plus visible et ne peut plus
être utilisée.
Si elle est requise pour un utilisateur, groupe ou rôle, vous devez attacher la nouvelle stratégie.
Lorsqu'une stratégie est signalée comme étant obsolète, nous vous recommandons de prendre
immédiatement les mesures nécessaires pour attacher l'ensemble des utilisateurs, groupes et rôles
à la stratégie de remplacement et les détacher de la stratégie obsolète. Pour éviter les risques liés à
l'utilisation d'une stratégie obsolète, il convient d'utiliser la stratégie de remplacement.
315
Contrôle de l'accès aux stratégies gérées
Les stratégies gérées vous permettent de contrôler avec précision la façon dont vos utilisateurs
gèrent les stratégies mais également les autorisations des autres utilisateurs. Il est possible de
contrôler séparément qui peut créer, mettre à jour et supprimer des stratégies, et qui peut attacher des
stratégies aux entités mandataires (utilisateurs, groupes et rôles) ou les en détacher. Vous pouvez
également contrôler quelles stratégies peuvent être attachées ou détachées de ces entités.
Dans un scénario standard, vous autorisez un administrateur de compte à créer, mettre à jour et
supprimer des stratégies. Ensuite, vous accordez des autorisations à un responsable d'équipe ou
un autre administrateur disposant de droits limités afin de leur permettre d'attacher et détacher ces
stratégies des entités mandataires gérées par l'administrateur doté de droits limités.
Rubriques
• Contrôle des autorisations pour la création, mise à jour et suppression de stratégies gérées par le
client (p. 316)
• Contrôle des autorisations pour attacher et détacher des stratégies gérées (p. 318)
• Spécification de l'ARN (Amazon Resource Name) de stratégies gérées (p. 319)
Contrôle des autorisations pour la création, mise à jour et
suppression de stratégies gérées par le client
A l'aide de stratégies IAM (p. 294), vous pouvez contrôler qui est autorisé à créer, mettre à jour
et supprimer les stratégies gérées par le client dans votre compte AWS. La liste suivante répertorie
les API utilisées pour la création, mise à jour, suppression et gestion des stratégies ou versions de
stratégies :
• CreatePolicy
• CreatePolicyVersion
• DeletePolicy
• DeletePolicyVersion
• SetDefaultPolicyVersion
Les API ci-dessus correspondent à des actions que vous pouvez autoriser ou refuser, autrement dit
des autorisations que vous accordez à l'aide d'une stratégie IAM.
L'exemple suivant illustre une stratégie qui autorise un utilisateur à créer, mettre à jour (autrement dit,
créer une nouvelle version de stratégie), supprimer et définir une version par défaut pour toutes les
stratégies gérées par le client dans un compte AWS. Cette stratégie permet également à l'utilisateur
d'obtenir des stratégies ou d'en afficher la liste.
316
Example stratégie qui autorise la création, mise à jour, suppression, obtention et définition de
la version par défaut pour toutes les stratégies
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:CreatePolicy",
"iam:CreatePolicyVersion",
"iam:DeletePolicy",
"iam:DeletePolicyVersion",
"iam:GetPolicy",
"iam:GetPolicyVersion",
"iam:ListPolicies",
"iam:ListPolicyVersions",
"iam:SetDefaultPolicyVersion"
],
"Resource": "*"
}
}
Vous pouvez créer des stratégies qui limitent l'utilisation de ces API aux seules stratégies gérées que
vous spécifiez. Par exemple, il est possible d'autoriser un utilisateur à définir la version par défaut et
supprimer des versions de stratégie, mais uniquement pour certaines stratégies gérées par le client.
Pour ce faire, vous spécifiez l'ARN de la stratégie dans l'élément Resource de la stratégie qui accorde
les autorisations.
L'exemple suivant illustre une stratégie qui autorise un utilisateur à supprimer des versions de stratégie
et à définir la version par défaut, mais uniquement pour les stratégies gérées par le client comportant
le chemin /TEAM-A/. L'ARN de la stratégie gérée par le client est spécifié dans l'élément Resource de
la stratégie (dans cet exemple, l'ARN inclut un chemin et un caractère générique et il correspond donc
à toutes les stratégies gérées par le client incluant le chemin /TEAM-A/).
Pour plus d'informations sur l'utilisation de chemins dans les noms de stratégies gérées par le client,
consultez Noms conviviaux et chemins (p. 387).
Example stratégie qui autorise la suppression de versions de stratégies et la définition de la
version par défaut pour des stratégies spécifiques uniquement
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:DeletePolicyVersion",
"iam:SetDefaultPolicyVersion"
],
"Resource": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:policy/TEAM-A/*"
}
}
317
Contrôle des autorisations pour attacher et détacher des
stratégies gérées
Les stratégies IAM vous permettent également d'autoriser les utilisateurs à avoir recours à des
stratégies gérées spécifiques uniquement ; autrement dit, vous contrôlez les autorisations qu'un
utilisateur peut accorder à d'autres entités mandataires.
La liste suivante répertorie les API utilisées pour attacher et détacher des stratégies gérées d'entités
mandataires :
• AttachGroupPolicy
• AttachRolePolicy
• AttachUserPolicy
• DetachGroupPolicy
• DetachRolePolicy
• DetachUserPolicy
Vous pouvez créer des stratégies qui limitent l'utilisation de ces API aux seules stratégies gérées et/ou
entités mandataires que vous spécifiez. Par exemple, il est possible d'autoriser un utilisateur à attacher
des stratégies gérées, mais uniquement celles que vous spécifiez. Ou, il est possible d'autoriser
un utilisateur à attacher des stratégies gérées, mais uniquement aux entités mandataires que vous
spécifiez.
L'exemple suivant illustre une stratégie qui autorise un utilisateur à attacher des stratégies gérées aux
groupes et rôles comportant le chemin /TEAM-A/ uniquement. Les ARN des groupes et des rôles sont
spécifiés dans l'élément Resource de la stratégie (dans cet exemple, les ARN comportent un chemin
et un caractère générique et ils correspondent donc à tous les groupes et rôles incluant le chemin /
TEAM-A/).
Example stratégie qui autorise l'utilisateur à attacher des stratégies gérées à des groupes ou
rôles spécifiques uniquement
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:AttachGroupPolicy",
"iam:AttachRolePolicy"
],
"Resource": [
"arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:group/TEAM-A/*",
"arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:role/TEAM-A/*"
]
}
}
Il est possible de limiter encore davantage les actions de l'exemple précédent, de manière à affecter
uniquement des stratégies spécifiques. Ainsi, vous pouvez contrôler les autorisations qu'un utilisateur
peut attacher aux entités mandataires en ajoutant une condition à la stratégie.
Dans l'exemple suivant, la condition garantit que les autorisations AttachGroupPolicy et
AttachRolePolicy sont octroyées uniquement si la stratégie devant être attachée correspond à
l'une des stratégies spécifiées. La condition utilise la iam:PolicyArn clé de condition (p. 413)
318
pour déterminer quelles stratégies peuvent être attachées. L'exemple de stratégie suivant développe
l'exemple précédent en autorisant l'utilisateur à attacher uniquement les stratégies gérées comportant
le chemin /TEAM-A/ aux groupes et rôles comportant le chemin /TEAM-A/ uniquement.
Example stratégie qui autorise l'utilisateur à attacher uniquement des stratégies gérées
spécifiques à des groupes ou rôles spécifiques uniquement
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": [
"iam:AttachGroupPolicy",
"iam:AttachRolePolicy"
],
"Resource": [
"arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:group/TEAM-A/*",
"arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:role/TEAM-A/*"
],
"Condition": {"ArnLike":
{"iam:PolicyArn": "arn:aws:iam::ACCOUNT-ID-WITHOUT-HYPHENS:policy/TEAMA/*"}
}
}
}
Spécification de l'ARN (Amazon Resource Name) de stratégies
gérées
Pour contrôler l'accès à des stratégies gérées spécifiques, vous utilisez l'ARN (Amazon Resource
Name) (p. 388) de ces stratégies. Dans certains cas, l'ARN de la stratégie gérée est spécifié dans
l'élément Resource de la stratégie, tandis que dans d'autres cas, il figure dans l'élément Condition
de la stratégie.
Les sections suivantes décrivent comment procéder dans chaque cas.
Utilisation de l'élément Resource pour contrôler l'accès aux actions qui affectent
la stratégie gérée
Pour contrôler l'accès à des stratégies gérées spécifiques pour les actions qui affectent la stratégie
gérée, vous spécifiez l'ARN de la stratégie dans l'élément Resource de la stratégie.
La liste suivante répertorie les actions IAM (API) qui affectent une stratégie gérée :
• CreatePolicy
• CreatePolicyVersion
• DeletePolicy
• DeletePolicyVersion
• GetPolicy
• GetPolicyVersion
• ListEntitiesForPolicy
• ListPolicyVersions
319
• SetDefaultPolicyVersion
Vous pouvez limiter l'utilisation de ces actions uniquement aux stratégies gérées que vous spécifiez.
Pour ce faire, vous spécifiez l'ARN de la stratégie dans l'élément Resource de la stratégie qui accorde
les autorisations. Par exemple, pour spécifier l'ARN d'une stratégie gérée par le client :
"Resource": "arn:aws:iam::123456789012:policy/POLICY-NAME"
Vous pouvez également spécifier l'ARN d'une stratégie gérée par AWS dans l'élément Resource
d'une stratégie. L'ARN d'une stratégie gérée par AWS utilise l'alias spécial aws, à la place d'un ID de
compte, par exemple :
"Resource": "arn:aws:iam::aws:policy/AmazonEC2FullAccess"
Utilisation de l'élément Condition pour contrôler l'accès aux actions qui
affectent l'entité mandataire (utilisateur, groupe ou rôle)
Pour contrôler l'accès à des stratégies gérées spécifiques pour les actions qui concernent une
stratégie gérée mais qui affectent une entité mandataire (utilisateur, groupe ou rôle), vous spécifiez
l'ARN de la stratégie gérée dans l'élément Condition de la stratégie. Dans ce cas, l'élément
Resource d'une stratégie est utilisé pour spécifier l'ARN de l'entité mandataire affectée.
La liste suivante répertorie les actions IAM (API) qui concernent une stratégie gérée mais affectent une
entité mandataire :
Vous pouvez limiter l'utilisation de ces actions aux stratégies gérées que vous spécifiez. Pour ce
faire, vous spécifiez l'ARN de la stratégie dans l'élément Condition de la stratégie qui accorde les
autorisations. Par exemple, pour spécifier l'ARN d'une stratégie gérée par le client :
"Condition": {"ArnEquals":
{"iam:PolicyArn": "arn:aws:iam::123456789012:policy/POLICY-NAME"}
}
Vous pouvez également spécifier l'ARN d'une stratégie gérée par AWS dans l'élément Condition
d'une stratégie. L'ARN d'une stratégie gérée par AWS utilise l'alias spécial aws au lieu d'un ID de
compte, comme dans l'exemple suivant :
"Condition": {"ArnEquals":
{"iam:PolicyArn": "arn:aws:iam::aws:policy/AmazonEC2FullAccess"}
}
Vous pouvez utiliser les types de conditions ArnLike ou ArnEquals. Pour plus d'informations
sur ArnLike et ArnEquals, consultez Opérateurs de condition d'ARN (Amazon Resource
Name) (p. 427) dans la section Types de conditions des Références des éléments de stratégie.
320
Création de stratégies IAM
Création d'une stratégie
Il existe plusieurs manières de créer une stratégie d'autorisation IAM. Vous pouvez copier une
stratégie AWS gérée complète, correspondant en partie à ce que vous recherchez, puis la
personnaliser en fonction de vos besoins spécifiques. Vous pouvez également construire la stratégie
en sélectionnant les conditions et les actions dans les listes du générateur de stratégies afin de
développer les instructions nécessaires à votre stratégie, ou créer une stratégie de bout en bout en
écrivant du code JSON.
Une stratégie se compose d'au moins une instruction. Chaque instruction contient généralement toutes
les actions qui partagent le même effet (Allow ou Deny) et les mêmes ressources. Si une action
nécessite un « * » pour la ressource et qu'une autre action spécifie l'ARN d'une ressource spécifique,
elles doivent se trouver dans deux instructions distinctes.
Pour obtenir des informations générales sur les stratégies IAM, consultez Présentation des stratégies
IAM (p. 294). Pour en savoir plus sur le langage de stratégie IAM, consultez Référence de stratégie
AWS IAM (p. 402).
Créer une stratégie
Quelle que soit l'option choisie, elles commencent toutes de la même manière :
Pour commencer à créer une stratégie
1.
2.
Dans la colonne de navigation gauche, sélectionnez Policies.
Si vous choisissez Policies pour la première fois, la page Welcome to Managed Policies s'affiche.
Sélectionnez Get Started.
3.
En haut de la page, sélectionnez Create Policy.
4.
Sur la page Create Policy, choisissez Select pour sélectionner l'une des options suivantes. Puis
suivez les étapes de la procédure sélectionnée :
• Copy an AWS Managed Policy (p. 321) — Copie une stratégie gérée existante et permet de
personnaliser la copie selon sa nouvelle fonction.
• Policy Generator (p. 322) — Crée une stratégie en vous permettant de sélectionner des
éléments dans des listes.
• Create Your Own Policy (p. 323) — Ouvre l'éditeur de stratégie avec une stratégie vide que
vous pouvez saisir ou copier et coller.
Copier une stratégie gérée existante
Un moyen simple de créer une nouvelle stratégie consiste à commencer par copier une stratégie
qui contient déjà certaines des fonctionnalités nécessaires. Vous pouvez ensuite personnaliser cette
stratégie pour qu'elle corresponde à vos nouveaux besoins. Commencez par suivre les étapes de la
procédure précédente, Créer une stratégie (p. 321).
Pour créer une copie d'une stratégie existante
1.
Sur la page Copy an AWS Managed Policy, choisissez Select pour sélectionner la stratégie gérée
qui se rapproche le plus de la stratégie que vous souhaitez créer. Vous pouvez filtrer la liste en
tapant dans la zone Search Policies en haut de la page.
2.
Sur la page Review Policy, entrez un nom de stratégie dans le champ Policy Name, ainsi
qu'une Description (facultatif), puis modifiez la stratégie dans la zone Policy Document pour
321
Création de stratégies IAM
qu'elle corresponde à vos nouveaux besoins. Choisissez Create Policy lorsque vous êtes prêt à
enregistrer.
Construire une stratégie avec le générateur
Le générateur permet de créer une stratégie sans avoir à écrire de syntaxe JSON. Commencez par
suivre les étapes de la procédure Créer une stratégie (p. 321) en haut de cette page.
Utiliser le générateur pour créer une stratégie
1.
Dans la page Edit Permissions, pour Effect, choisissez Allow ou Deny. Parce que le refus est
le comportement par défaut, nous vous recommandons comme bonne pratique de sécurité de
n'autoriser un utilisateur à accéder qu'aux actions et aux ressources nécessaires. Cette méthode
est parfois appelée « liste blanche ». Vous ne devez créer d'instruction contenant un Deny (« liste
noire ») explicite que si vous souhaitez remplacer une autorisation séparément autorisée par une
autre instruction ou stratégie. Nous vous recommandons de limiter le nombre d'instructions Deny
explicites au minimum, car elles peuvent rendre la résolution des problèmes d'autorisation plus
complexe.
2.
Sélectionnez dans la liste le service AWS dont vous voulez autoriser ou refuser les actions.
3.
Choisissez les actions que vous voulez autoriser ou refuser. La liste présente les actions pour le
service que vous avez sélectionné à l’étape 2. Vous pouvez choisir All Actions ou spécifier des
actions individuelles en activant la case en regard de chaque nom d'action. Une fois les actions
sélectionnées, cliquez en dehors de la liste pour fermer la sélection. La liste indique le nombre
d'actions que vous avez sélectionnées.
4.
Tapez les ressources auxquelles vous voulez autoriser ou refuser l'accès. Certaines opérations
autorisent uniquement « Resource » : « * », tandis que d'autres vous permettent de spécifier
l'ARN (Amazon Resource Name) de ressources individuelles. Vous pouvez inclure un astérisque
(*) comme caractère générique dans n'importe quel champ de l'ARN (entre chaque paire
de deux points), ou simplement spécifier un astérisque tout seul pour signifier « toutes les
ressources du compte ». Par exemple, arn:aws:s3:::* représente tous les compartiments
S3 dans le même compte que la stratégie. Pour de plus amples informations, veuillez consulter
Ressource (p. 412).
5.
Vous pouvez ajouter des éléments de Condition pour limiter l'effet d'une instruction. Par exemple,
vous pouvez spécifier qu'un utilisateur n'est autorisé à effectuer les actions sur les ressources
que si la demande de l'utilisateur se produit pendant une période donnée, est authentifiée par un
périphérique d'authentification multi-facteurs ou provient d'une certaine plage d'adresses IP. Pour
obtenir la liste de toutes les clés de contexte que vous pouvez utiliser dans l'élément Condition,
consultez la page Actions et clés de contexte de condition de service AWS à utiliser dans des
stratégies IAM (p. 452). Pour commencer, cliquez sur Add Conditions (optional).
a.
Pour Condition, choisissez le type de comparaison que vous souhaitez effectuer.
b.
Pour Key, choisissez la clé de contexte dont vous voulez évaluer la valeur lorsqu'un utilisateur
effectue une demande.
c.
Pour Value, tapez la valeur que vous voulez comparer à la clé spécifiée.
d.
Choisissez Add Condition pour ajouter cette condition renseignée à l'instruction en cours.
Pour ajouter une autre condition, modifier les paramètres et choisissez Add Condition à
nouveau. Répétez l'opération si nécessaire. Chaque condition s'applique uniquement à
cette seule instruction. Toutes les conditions doivent être remplies pour que l'instruction
d'autorisation soit considérée comme réussie. Vous pouvez considérer que les conditions
sont reliées par un élément « Et » logique.
Pour plus d'informations sur l'élément Condition, consultez la page Condition (p. 413) dans
le Référence de stratégie AWS IAM (p. 402).
6.
Lorsque vous aurez rempli tous les champs nécessaires pour cette instruction, choisissez Add
Statement. Si vous avez besoin d'ajouter davantage d'instructions à la stratégie, répétez les
322
Utilisation de stratégies
étapes précédentes. À chaque fois que vous devez modifier l'effet ou les ressources concernées,
vous devez créer une nouvelle instruction.
7.
Une fois que vous avez ajouté toutes les instructions dont vous avez besoin, choisissez Next
Step pour afficher vos instructions dans l'éditeur de stratégie. Si vous souhaitez apporter des
modifications, vous pouvez encore modifier la stratégie manuellement. Modifiez et enregistrez la
stratégie à l'aide des étapes présentées dans la procédure suivante.
Modifier une stratégie à l'aide de l'éditeur de stratégie
Vous pouvez également utiliser l'éditeur de stratégie pour créer une nouvelle stratégie. Commencez
par suivre les étapes de la procédure Créer une stratégie (p. 321) en haut de cette page.
Pour créer une stratégie dans l'éditeur de stratégie
1.
Pour Policy Name, tapez un nom unique qui vous rappelle l'objectif prévu de votre stratégie.
2.
(Facultatif) Pour Description, tapez une description pour référence ultérieure.
3.
Pour Policy Document, ajoutez ou modifiez les instructions de stratégie. Pour plus d'informations
sur le langage de stratégie IAM, consultez Référence de stratégie AWS IAM (p. 402).
4.
Vous pouvez choisir Validate Policy à n'importe quel moment de l'édition pour vous assurer que la
syntaxe de la stratégie est correcte. Vous ne pouvez enregistrer la stratégie que si la syntaxe est
correcte.
Note
Le programme de validation de stratégie vérifie uniquement la syntaxe et la grammaire
de la stratégie JSON. Il ne valide pas que votre ARN, vos noms d'action ou vos clés de
condition sont corrects.
5.
Une fois votre stratégie terminée, choisissez Create Policy pour l'enregistrer.
6.
Une fois que vous avez créé une stratégie, vous pouvez l'appliquer en l'attachant à vos
utilisateurs, groupes ou rôles. Pour de plus amples informations, veuillez consulter Attachement
de stratégies gérées (p. 324)
Cette section décrit comment créer et gérer tous types de stratégies IAM (stratégies gérées et
stratégies en ligne).
Pour plus d'informations sur les différents types de stratégies IAM, consultez Stratégies gérées et
stratégies en ligne (p. 299).
IAM (p. 294).
Pour ajouter des autorisations à une entité mandataire IAM, c'est-à-dire un utilisateur IAM, un groupe
ou un rôle, vous créez une stratégie et vous l'attachez à l'entité mandataire. Vous pouvez attacher
plusieurs stratégies à une entité mandataire, et chaque stratégie peut contenir plusieurs autorisations.
Pour plus d'informations sur l'évaluation des autorisations lorsque plusieurs stratégies sont en vigueur
pour une entité mandataire IAM donnée, consultez Logique d'évaluation de stratégies IAM (p. 441).
Pour plus d'informations sur les limitations de taille des stratégies et autres quotas, consultez
Rubriques
• Utilisation des stratégies gérées (p. 324)
323
• Utilisation de stratégies en ligne (p. 329)
Utilisation des stratégies gérées
Cette section décrit comment utiliser des stratégies gérées AWS et comment créer et utiliser des
stratégies gérées par le client, c'est-à-dire des stratégies gérées que vous créez vous-même. Vous
pouvez gérer et créer des stratégies gérées à l'aide de l'AWS Management Console, de l'AWS
Command Line Interface (AWS CLI) ou de l'API IAM.
Pour plus d'informations sur les différents types de stratégies IAM, consultez Stratégies gérées et
stratégies en ligne (p. 299).
IAM (p. 294).
Pour plus d'informations sur les limitations de taille des stratégies et autres quotas, consultez
Rubriques
• Utilisation de stratégies gérées à l'aide de l'AWS Management Console (p. 324)
• Utilisation de stratégies gérées à l'aide de l'AWS CLI ou de l'API IAM (p. 327)
Utilisation de stratégies gérées à l'aide de l'AWS Management Console
Cette section décrit comment créer et gérer des stratégies gérées (p. 299) à l'aide de l'AWS
Management Console.
Pour plus d'informations sur la gestion des stratégies gérées à l'aide de l'AWS Command Line
Interface (AWS CLI) ou de l'API IAM, consultez Utilisation de stratégies gérées à l'aide de l'AWS CLI
ou de l'API IAM (p. 327).
Rubriques
• Attachement de stratégies gérées (p. 324)
• Détachement de stratégies gérées (p. 325)
• Création de stratégies gérées par le client (p. 325)
• Modification de stratégies gérées par le client (p. 326)
• Définition de la version par défaut des stratégies gérées par le client (p. 326)
• Suppression des versions des stratégies gérées par le client (p. 327)
• Suppression de stratégies gérées par le client (p. 327)
Attachement de stratégies gérées
Vous pouvez attacher une stratégie gérée à une entité mandataire (utilisateur, groupe ou rôle) pour
appliquer les autorisations de la stratégie à l'entité mandataire. Vous pouvez attacher jusqu'à dix
stratégies gérées à chaque entité mandataire.
Pour attacher une stratégie gérée à l'aide de l'AWS Management Console
1.
2.
3.
attacher. Vous pouvez utiliser le menu Filter et la zone Search pour filtrer la liste de stratégies.
324
4.
Choisissez Policy Actions, puis choisissez Attach.
5.
Sélectionnez les entités mandataires auxquelles attacher la stratégie. Vous pouvez utiliser le
menu Filter et la zone Search pour filtrer la liste des entités mandataires. Après avoir sélectionné
les entités mandataires auxquelles attacher la stratégie, choisissez Attach Policy.
Détachement de stratégies gérées
Vous pouvez détacher une stratégie gérée d'une entité mandataire (utilisateur, groupe ou rôle) pour
supprimer les autorisations de la stratégie de l'entité mandataire.
Pour détacher une stratégie gérée à l'aide de l'AWS Management Console
1.
2.
3.
détacher. Vous pouvez utiliser le menu Filter et la zone Search pour filtrer la liste de stratégies.
4.
5.
Choisissez Policy Actions, puis choisissez Detach.
Sélectionnez les entités mandataires desquelles détacher la stratégie. Vous pouvez utiliser le
menu Filter et la zone Search pour filtrer la liste des entités mandataires. Après avoir sélectionné
les entités mandataires desquelles détacher la stratégie, choisissez Detach Policy.
Création de stratégies gérées par le client
Vous pouvez créer des stratégies gérée par le client pour définir un ensemble d'autorisations à
attacher aux entités mandataires (utilisateurs, groupes, rôles) de votre compte AWS. Pour plus
d'informations sur les stratégies gérées par le client, consultez Stratégies gérées et stratégies en
ligne (p. 299).
Pour créer une stratégie gérée à l'aide de l'AWS Management Console
1.
2.
3.
Choisissez le bouton Select correspondant à la manière dont vous souhaitez créer votre stratégie.
• Copy an AWS Managed Policy. Permet d'afficher une liste de toutes les stratégies existantes,
puis de choisir Select situé en regard de celle que vous souhaitez copier.
• Policy Generator. Permet de créer une stratégie en sélectionnant des éléments parmi les listes
d'options disponibles. Sélectionnez les options Effect, AWS Service et Actions appropriées,
entrez l'ARN (Amazon Resource Name), le cas échéant, et ajoutez les conditions que
vous souhaitez inclure. Ensuite, choisissez Add Statement. Vous pouvez ajouter autant de
déclarations que vous le souhaitez à la stratégie. Une fois que vous avez ajouté toutes les
déclarations, choisissez Next Step.
4.
5.
• Create Your Own Policy. Tapez un Policy Name dans l'espace fourni. Pour Policy Document,
entrez ou collez un document de stratégie dans l'éditeur.
Dans l'éditeur, effectuez toutes les personnalisations dont vous avez besoin pour adapter la
stratégie à votre environnement.
Après avoir effectué les modifications, choisissez Validate Policy et assurez-vous qu'aucune
erreur ne s'affiche dans un cadre rouge en haut de l'écran. Corrigez les erreurs qui sont signalées.
Note
325
6.
Choisissez Create Policy pour enregistrer votre nouvelle stratégie.
Modification de stratégies gérées par le client
Vous modifiez les stratégies gérées par le client pour modifier les autorisations définies dans la
stratégie. Vous ne pouvez pas modifier les stratégies gérées AWS.
Pour modifier une stratégie gérée par le client à l'aide de l'AWS Management Console
1.
2.
3.
Dans la liste des stratégies, choisissez le nom de la stratégie à modifier. Vous pouvez utiliser le
menu Filter et la zone Search pour filtrer la liste de stratégies.
4.
Choisissez l'onglet Policy Document, puis tout à droite, choisissez Edit, puis modifiez le document
de stratégie.
5.
Après avoir effectué les modifications, choisissez Validate Policy et assurez-vous qu'aucune
erreur ne s'affiche dans un cadre rouge en haut de l'écran. Corrigez les erreurs signalées.
Note
Si l'option Use autoformatting est sélectionnée, la stratégie est ensuite reformatée chaque
fois que vous ouvrez une stratégie ou choisissez Validate Policy.
6.
Lorsque vous avez terminé de modifier la stratégie, décidez si vous souhaitez appliquer
immédiatement vos modifications à toutes les entités mandataires (utilisateurs, groupes, rôles)
auxquelles cette stratégie est attachée :
• Pour appliquer immédiatement vos modifications à toutes les entités attachées, activez la case
à cocher Save as default version.
• Pour enregistrer vos modifications sans affecter les entités attachées actuelles, désactivez la
case à cocher Save as default version.
7.
Choisissez Save.
Définition de la version par défaut des stratégies gérées par le client
Vous pouvez spécifier la version par défaut d'une stratégie gérée par le client pour en faire la version
en vigueur pour chaque entités mandataire (utilisateurs, groupes et rôles) à laquelle la stratégie gérée
est attachée. Vous ne pouvez définir la version par défaut d'une stratégies gérées AWS.
Vous pouvez définir la version par défaut d'une stratégie gérée par le client lorsque vous modifiez
celle-ci. Pour définir la version par défaut pendant la modification de la stratégie, consultez Modification
de stratégies gérées par le client (p. 326). Pour définir la version par défaut d'une stratégie gérée par
le client indépendamment de la modification de la stratégie, procédez comme suit.
Pour définir la version par défaut d'une stratégie gérée par le client à l'aide de l'AWS
Management Console
1.
2.
3.
Dans la liste des stratégies, choisissez le nom de la stratégie à définir comme la version par
défaut. Vous pouvez utiliser le menu Filter et la zone Search pour filtrer la liste de stratégies.
4.
Choisissez l'onglet Policy Versions. Activez a case à cocher située en regard de la version que
vous souhaitez définir comme version par défaut, puis choisissez Set as Default.
326
Suppression des versions des stratégies gérées par le client
Vous pouvez supprimer une version d'une stratégie gérée par le client pour vous assurer qu'elle ne
pourra jamais être définie comme version par défaut de la stratégie, c'est-à-dire pour qu'elle ne soit
jamais attachée à aucune entité (utilisateurs, groupes et rôles) de votre compte AWS. Vous ne pouvez
pas supprimer des versions des stratégies gérées AWS.
Pour supprimer une version d'une stratégie gérée par le client à l'aide de l'AWS Management
Console
1.
2.
3.
4.
5.
Choisissez le nom de la stratégie gérée par le client pour en supprimer une version. Vous pouvez
utiliser le menu Filter et la zone Search pour filtrer la liste de stratégies.
Choisissez l'onglet Policy Versions. Activez la case à cocher située en regard de la version à
supprimer, puis choisissez Delete.
Confirmez que vous voulez supprimer la version, puis choisissez Delete.
Suppression de stratégies gérées par le client
Vous pouvez supprimer une stratégie gérée par le client pour la supprimer de votre compte AWS.
Vous ne pouvez pas supprimer les stratégies gérées AWS.
Pour supprimer une stratégie gérée par le client à l'aide de l'AWS Management Console
1.
4.
Activez la case à cocher en regard de la stratégie gérée par le client à supprimer. Vous pouvez
utiliser le menu Filter et la zone Search pour filtrer la liste de stratégies.
Choisissez Policy Actions, puis choisissez Delete.
5.
Confirmez que vous voulez supprimer la stratégie, puis choisissez Delete.
2.
3.
Utilisation de stratégies gérées à l'aide de l'AWS CLI ou de l'API IAM
Cette section décrit comment créer et gérer des stratégies gérées (p. 299) à l'aide de l'AWS
Command Line Interface (AWS CLI) ou de l'API IAM. Les informations contenues dans cette section
s'appliquent aux stratégies gérées AWS et aux stratégies gérées par le client, c'est-à-dire aux
stratégies gérées que vous créez.
Pour plus d'informations sur la gestion des stratégies gérées à l'aide de l'AWS Management Console,
consultez Utilisation de stratégies gérées à l'aide de l'AWS Management Console (p. 324).
Pour répertorier les stratégies gérées
• AWS CLI : list-policies
• API IAM : ListPolicies
Pour récupérer des informations détaillées sur une stratégie gérée
• AWS CLI : get-policy
• API IAM : GetPolicy
Pour répertorier les versions d'une stratégie gérée
327
• AWS CLI : list-policy-versions
• API IAM : ListPolicyVersions
Pour récupérer des informations détaillées sur une version d'une stratégie gérée, notamment le
document de stratégie
• AWS CLI : get-policy-version
• API IAM : GetPolicyVersion
Pour répertorier les entités mandataires (utilisateurs, groupes et rôles) attachées à une stratégie gérée
• AWS CLI : list-entities-for-policy
• API IAM : ListEntitiesForPolicy
Pour répertorier les stratégies gérées attachées à une entité mandataire (utilisateur, groupe et rôle)
• AWS CLI :
• list-attached-group-policies
• list-attached-role-policies
• list-attached-user-policies
• API IAM :
• ListAttachedGroupPolicies
• ListAttachedRolePolicies
• ListAttachedUserPolicies
Pour attacher une stratégie gérée à un groupe, un rôle ou un utilisateur
• AWS CLI :
• attach-group-policy
• attach-role-policy
• attach-user-policy
• API IAM :
Pour détacher une stratégie gérée d'un groupe, d'un rôle ou d'un utilisateur
• AWS CLI :
• detach-group-policy
• detach-role-policy
• detach-user-policy
• API IAM :
Pour créer une stratégie gérée par le client
328
• AWS CLI : create-policy
• API IAM : CreatePolicy
Pour modifier une stratégie gérée par le client
• AWS CLI : create-policy-version
• API IAM : CreatePolicyVersion
Pour définir la version par défaut d'une stratégie gérée par le client
• AWS CLI : set-default-policy-version
• API IAM : SetDefaultPolicyVersion
Pour supprimer une version d'une stratégie gérée par le client
• AWS CLI : delete-policy-version
• API IAM : DeletePolicyVersion
Pour supprimer une stratégie gérée par le client
• AWS CLI : delete-policy
• API IAM : DeletePolicy
Utilisation de stratégies en ligne
Cette section décrit comment créer et gérer des stratégies en ligne (p. 299).
Pour plus d'informations sur la gestion des stratégies gérées, consultez Utilisation des stratégies
gérées (p. 324).
Rubriques
• Utilisation de stratégies en ligne à l'aide d'AWS Management Console (p. 329)
• Utilisation de stratégies en ligne à l'aide de l'AWS CLI ou de l'API IAM (p. 330)
Utilisation de stratégies en ligne à l'aide d'AWS Management Console
Pour créer une stratégie en ligne et l'intégrer à un groupe, un utilisateur ou un rôle
1.
2.
Dans le volet de navigation, sélectionnez Groups, Users, ou Roles.
3.
Dans la liste, sélectionnez le nom du groupe, de l'utilisateur ou du rôle auquel intégrer une
stratégie.
4.
Choisissez l'onglet Permissions et, si nécessaire, développez la section Inline Policies.
5.
Choisissez Create Another Policy sous Groups, Create User Policy sous Users ou Create Role
Policy sous Roles.
6.
Choisissez Policy Generator ou Custom Policy, puis Select.
7.
• Si vous avez choisi Custom Policy, spécifiez un nom pour la stratégie et créez votre document
de stratégie.
329
• Si vous utilisez le générateur pour créer votre stratégie, sélectionnez les options Effect, AWS
Service et Actions appropriées, entrez l'ARN (Amazon Resource Name), le cas échéant, et
ajoutez les conditions que vous souhaitez inclure. Ensuite, choisissez Add Statement. Vous
pouvez ajouter autant de déclarations que vous le souhaitez à la stratégie. Une fois que vous
avez ajouté toutes les déclarations, choisissez Next Step.
8.
Choisissez Validate Policy et assurez-vous qu'aucune erreur ne s'affiche dans un cadre rouge en
haut de l'écran. Corrigez les erreurs signalées.
Note
9.
Lorsque vous êtes satisfait de la stratégie, choisissez Apply Policy.
Pour afficher une stratégie ou la liste de toutes les stratégies associées à un utilisateur, groupe
ou rôle
•
Dans le volet de navigation, sélectionnez Users, Groups ou Roles, choisissez le nom de l'entité à
afficher, puis sélectionnez l'onglet Permissions.
Pour modifier ou supprimer une stratégie en ligne pour un groupe, utilisateur ou rôle
1.
Dans le volet de navigation, sélectionnez Groups, Users, ou Roles.
2.
Choisissez le nom du groupe, de l'utilisateur ou du rôle avec la stratégie que vous voulez modifier,
puis sélectionnez l'onglet Permissions.
3.
Pour modifier une stratégie en ligne, choisissez Edit Policy.
4.
Pour supprimer une stratégie en ligne, choisissez Remove Policy.
Utilisation de stratégies en ligne à l'aide de l'AWS CLI ou de l'API IAM
Pour afficher toutes les stratégies en ligne intégrées à une entité mandataire (utilisateur, groupe ou
rôle)
• AWS CLI :
• list-group-policies
• list-role-policies
• list-user-policies
• API IAM :
• ListGroupPolicies
• ListRolePolicies
• ListUserPolicies
Pour extraire un document de stratégie en ligne qui est intégré à une entité mandataire (utilisateur,
groupe ou rôle)
• AWS CLI :
• get-group-policy
• get-role-policy
• get-user-policy
• API IAM :
• GetGroupPolicy
330
Test des stratégies IAM
• GetRolePolicy
• GetUserPolicy
Pour intégrer une stratégie en ligne à une entité mandataire (utilisateur, groupe ou rôle)
• AWS CLI :
• put-group-policy
• put-role-policy
• put-user-policy
• API IAM :
• PutGroupPolicy
• PutRolePolicy
• PutUserPolicy
Pour supprimer un document de stratégie en ligne qui est intégré à une entité mandataire (utilisateur,
groupe ou rôle)
• AWS CLI :
• delete-group-policy
• delete-role-policy
• delete-user-policy
• API IAM :
• DeleteGroupPolicy
• DeleteRolePolicy
• DeleteUserPolicy
Test des stratégies IAM avec le simulateur de
stratégies IAM
Pour plus d'informations sur la manière d'utiliser les stratégies IAM et pourquoi, consultez Présentation
des stratégies IAM (p. 294).
La vidéo suivante présente l'utilisation du simulateur de stratégies IAM. Guide de démarrage du
simulateur de stratégies IAM
Avec le simulateur de stratégies IAM, vous pouvez tester et dépanner des stratégies IAM et basées sur
des ressources comme suit :
• Testez les stratégies attachées aux utilisateurs IAM, aux groupes ou aux rôles dans votre compte
AWS. Si plusieurs stratégies sont attachées à l'utilisateur, au groupe ou au rôle, vous pouvez
tester toutes les stratégies ou sélectionner des stratégies individuelles à tester. Vous pouvez tester
les actions qui sont autorisées ou refusées par les stratégies sélectionnées pour des ressources
spécifiques.
• Testez les stratégies attachées aux ressources AWS comme les compartiments Amazon S3, les files
d'attente Amazon SQS, les rubriques Amazon SNS ou les coffres Amazon Glacier.
• Testez les nouvelles stratégies pas encore attachées à un utilisateur, un groupe ou un rôle en les
saisissant ou en les copiant dans le simulateur. Elles sont utilisées uniquement dans la simulation et
en sont pas enregistrées. Remarque : vous ne pouvez pas saisir ou copier les stratégies basées sur
des ressources dans le simulateur. Pour cela, vous devez inclure la ressource dans la simulation et
activer la case à cocher pour inclure la stratégie de cette ressource dans la simulation.
331
• Testez les stratégies avec les services, actions et ressources sélectionnés. Par exemple, vous
pouvez effectuer des tests pour vérifier que votre stratégie autorise une entité à exécuter les actions
ListAllMyBuckets, CreateBucket et DeleteBucket dans le service Amazon S3 sur un
compartiment spécifique.
• Simulez des scénarios réels en fournissant des clés de contexte, comme une adresse IP ou une
date, qui sont incluses dans les éléments Condition des stratégies en cours de test.
• Identifiez quelle déclaration spécifique d'une stratégie entraîne l'autorisation ou le refus de l'accès à
une ressource ou une action particulière.
Rubriques
• Fonctionnement du simulateur de stratégies IAM (p. 332)
• Autorisations nécessaires pour utiliser le simulateur de stratégies IAM (p. 332)
• Utilisation du simulateur de stratégies IAM (AWS Management Console) (p. 333)
• Utilisation du simulateur de stratégies IAM (AWS CLI, l'Outils pour Windows PowerShell et l'API
AWS) (p. 338)
Fonctionnement du simulateur de stratégies IAM
Le simulateur évalue les stratégies que vous choisissez et détermine les autorisations en vigueur pour
chacune des actions que vous spécifiez. Le simulateur utilise le même moteur d'évaluation de stratégie
que celui utilisé au cours des demandes réelles aux services AWS. Cependant, le simulateur diffère de
l'environnement AWS en ligne comme suit :
• Le simulateur ne fait pas de demande de service AWS réelle, vous pouvez donc en toute sécurité
tester des demandes susceptibles de faire des modifications indésirables à votre environnement
AWS en ligne.
• Du fait que le simulateur ne simule pas l'exécution des actions sélectionnées, il ne peut rapporter
aucune réponse à la demande simulée. Le seul résultat renvoyé est si l'action demandée serait
autorisée ou refusée.
• Si vous modifiez une stratégie dans le simulateur, ces modifications affectent uniquement le
simulateur. La stratégie correspondante dans votre compte AWS reste inchangée.
Autorisations nécessaires pour utiliser le simulateur de
stratégies IAM
Par défaut, les utilisateurs autorisés à accéder à la console AWS peuvent utiliser le simulateur pour
tester les stratégies qui ne sont pas encore attachées à un utilisateur, à un groupe ou à un rôle. Il
suffit de choisir New Policy dans le menu de mode en haut, puis de choisir Create New Policy sous
Policy Sandbox et de taper ou de copier une stratégie dans le simulateur. Les stratégies ajoutées ici
sont utilisées uniquement dans le cadre de la simulation afin d'éviter de divulguer des informations
sensibles.
Pour autoriser un utilisateur de la console à tester les stratégies attachées à des utilisateurs, groupes
ou rôles IAM, vous devez lui fournir les autorisations de récupération de ces stratégies. Pour permettre
aux utilisateurs de la console de tester les stratégies basées sur les ressources, vous devez leur
accorder l'autorisation de récupérer la stratégie de la ressource.
Pour autoriser les utilisateurs de la console à simuler des stratégies pour un utilisateur
1. Pour les stratégies en ligne, accordez des autorisations relatives aux actions suivantes :
ListUsers
332
GetUser
GetUserPolicy
2. Pour les stratégies gérées, accordez des autorisations relatives aux actions suivantes :
ListUsers
GetUser
GetPolicy
Pour autoriser les utilisateurs de la console à tester les stratégies basées sur les ressources
Accordez une autorisation pour récupérer la stratégie de la ressource.
Par exemple, pour simuler des stratégies basées sur les ressources dans un compartiment Amazon
S3, vous devez autoriser l'utilisateur à effectuer les actions suivantes :
s3:GetBucketPolicy
s3:GetObjects
Pour obtenir des exemples de stratégie qui autorisent l'utilisateur de la console à simuler les stratégies,
consultez Permettre aux utilisateurs d'accéder au simulateur de stratégies (p. 354).
Pour autoriser les utilisateurs à simuler les stratégies transmises directement à l'API sous forme de
chaînes
Accordez des autorisations pour les actions suivantes :
GetContextKeysForCustomPolicy
SimulateCustomPolicy
Pour autoriser les utilisateurs à accéder aux API qui simulent les stratégies attachées à un utilisateur,
un groupe, un rôle ou une ressource IAM spécifiés
Accordez des autorisations pour les actions suivantes :
GetContextKeysForPrincipalPolicy
SimulatePrincipalPolicy
Par exemple, pour autoriser un utilisateur nommé Bob à simuler une stratégie qui est
attribuée à un utilisateur nommé Alice, autorisez Bob à accéder aux ressources suivantes :
arn:aws:iam::777788889999:user/alice.
Pour obtenir des exemples de stratégies d'API autorisant un utilisateur à simuler les stratégies,
consultez Permettre aux utilisateurs d'accéder aux API du simulateur de stratégies (p. 355).
Utilisation du simulateur de stratégies IAM (AWS Management
Console)
Une fois que vous avez reçu les autorisations nécessaires pour utiliser le simulateur de stratégies IAM,
vous pouvez procéder au test d'une stratégie d'utilisateur, de groupe, de rôle ou de ressource IAM.
Pour utiliser le simulateur de stratégies :
1.
Ouvrez le simulateur de stratégies IAM à l'adresse https://policysim.aws.amazon.com/. (Si vous
n'êtes pas déjà connecté à AWS, vous y êtes invité.)
333
Note
Pour vous connecter au simulateur de stratégie en tant qu'utilisateur IAM, utilisez votre
URL de connexion unique pour vous connecter à l'AWS Management Console. Ensuite,
accédez à https://policysim.aws.amazon.com/. Pour plus d'informations sur la connexion
en tant qu'utilisateur IAM, consultez Comment les utilisateurs IAM se connectent à votre
compte AWS (p. 70).
Le simulateur s'ouvre au mode Existing Policies et répertorie les utilisateurs IAM de votre compte
sous Users, Groups, and Roles.
2.
Choisissez l'option appropriée à votre tâche :
Pour tester ceci :
Faites ceci:
Une stratégie
attachée à un
utilisateur
Choisissez Users dans la liste Users, Groups, and Roles. Puis
choisissez l'utilisateur.
Une stratégie
attachée à un groupe
Choisissez Groups dans la liste Users, Groups, and Roles. Puis
choisissez le groupe.
Une stratégie
attachée à un rôle
Choisissez Roles dans la liste Users, Groups, and Roles. Puis
choisissez le rôle.
Une stratégie
attachée à une
ressource
Voir Step 7 (p. 336).
Une stratégie
personnalisée
Sélectionnez New Policy dans la liste des modes dans le coin supérieur
droit. Ensuite, dans le volet Policy Sandbox de gauche, cliquez sur
Create New Policy, entrez ou collez une stratégie, puis cliquez sur
Apply.
Tip
Si vous souhaitez tester une stratégie attachée à un utilisateur ou un groupe, vous pouvez
lancer le simulateur de stratégies IAM directement dans la console IAM : dans le volet de
navigation, cliquez sur Users ou Groups. Choisissez le nom de l'utilisateur ou du groupe
sur lequel vous souhaitez tester une stratégie, puis faites défiler vers le bas jusqu'à la
section Permissions. Dans la section Inline Policies ou Managed Policies, recherchez
la stratégie que vous souhaitez tester. Dans la colonne Actions pour cette stratégie,
choisissez Simulate Policy. Le simulateur de stratégies IAM ouvre une nouvelle fenêtre et
affiche la stratégie sélectionnée dans le volet Policies.
3.
(Facultatif) Pour tester uniquement un sous-ensemble de stratégies attachées à un utilisateur, un
groupe ou un rôle, désactivez la case à cocher située en regard de chaque stratégie que vous
souhaitez exclure.
4.
Sous Policy Simulator, cliquez sur Select service, puis choisissez le service à tester. Puis cliquez
sur Select actions et sélectionnez une ou plusieurs actions à tester. Bien que les menus affichent
les sélections disponibles pour un seul service à la fois, tous les services et actions que vous
avez sélectionnés s'affichent dans Action Setttings and Results. Si vous revenez à une stratégie
pour laquelle vous avez sélectionné des actions, le menu Select actions continue d'afficher vos
sélections.
5.
(Facultatif) Si l'une des stratégies que vous choisissez dans Step 2 (p. 334) et Step 3 (p. 334)
testent la valeur des clés de contexte AWS globales dans un élément Condition, les noms de
334
clés s'affichent dans la section Global Settings. Vous pouvez fournir des valeurs pour ces clés en
développant la section Global Settings et en saisissant des valeurs pour les noms de clés affichés
ici.
Caution
Si vous laissez la valeur d'une clé de condition vide, cette clé est ignorée pendant
la simulation. Dans certains cas, cela entraîne une erreur et la simulation échoue à
s'exécuter. Dans d'autres cas, la simulation s'exécute, mais les résultats ne sont peut-être
pas fiables, car la simulation ne correspond pas aux conditions réelles qui incluent une
valeur pour la clé de condition ou la variable.
6.
(Facultatif) Chaque action sélectionnée s'affiche dans la liste Results avec Not simulated
affiché dans la colonne Permission jusqu'à ce que vous exécutiez réellement la simulation.
Avant d'exécuter la simulation, vous pouvez configurer chaque action avec une ressource.
Pour configurer des actions individuelles pour un scénario spécifique, cliquez sur la flèche
pour développer la ligne de l'action. Si l'action prend en charge les autorisations de niveau de
ressource, vous pouvez saisir l'ARN (Amazon Resource Name) de la ressource spécifique à
laquelle vous souhaitez simuler l'accès. Par défaut, chaque ressource est définie sur un caractère
générique (*). Vous pouvez également spécifier une valeur pour toutes les clés de contexte qui
sont référencées par l'élément Condition de la stratégie. Comme mentionné précédemment, les
clés avec des valeurs vides sont ignorées, ce qui peut entraîner des échecs de simulation ou des
résultats peu fiables.
a.
Développez chaque ligne en cliquant sur la flèche située en regard du nom de l'action pour
configurer les informations supplémentaires requises pour simuler précisément l'action dans
votre scénario. Si l'action nécessite des autorisations de niveau de ressource, vous pouvez
saisir l'ARN (Amazon Resource Name) de la ressource spécifique à laquelle vous souhaitez
simuler l'accès. Par défaut, chaque ressource est définie sur un caractère générique (*).
b.
Si l'action prend en charge une autorisation de niveau de ressource mais qu'elle n'est pas
obligatoire, vous pouvez cliquer sur le bouton Add Resource pour sélectionner le type de
ressource que vous souhaitez ajouter à la simulation.
c.
Si l'une des stratégies sélectionnées inclue un élément Condition qui fait référence à une clé
de contexte pour le service de cette action, ce nom de clé s'affiche sous l'action. Vous pouvez
spécifier la valeur à utiliser pendant la simulation de cette action par rapport à la ressource
spécifiée.
Actions nécessitant différents groupes de types de ressources
Certaines actions nécessitent différents types de ressources dans certaines circonstances.
Chaque groupe de types de ressources est associé à un scénario. Si l'un d'entre eux s'applique
à votre simulation, sélectionnez-le et le simulateur nécessite les types de ressources adaptés à
ce scénario. La liste suivante affiche chacune des options de scénarios prises en charge et les
ressources que vous devez définir pour exécuter la simulation.
Chacun des scénarios EC2 nécessite que vous spécifiiez les ressources instance, image et
security-group. Si votre scénario inclut un volume EBS, vous devez spécifier ce volume en
tant que ressource. Si le scénario EC2 inclut un VPC, vous devez fournir la ressource networkinterface. S'il inclut un sous-réseau IP, vous devez spécifier la ressource subnet. Pour plus
d'informations sur les options de scénarios EC2, consultez Supported Platforms dans le Guide de
l'utilisateur AWS EC2.
• EC2-Classic-InstanceStore
instance, image, groupe de sécurité
• EC2-Classic-EBS
instance, image, groupe de sécurité, volume
335
• EC2-VPC-InstanceStore
instance, image, groupe de sécurité, interface réseau
• EC2-VPC-InstanceStore-Subnet
instance, image, groupe de sécurité, interface réseau, sous-réseau
• EC2-VPC-EBS
instance, image, groupe de sécurité, interface réseau, volume
• EC2-VPC-EBS-Subnet
instance, image, groupe de sécurité, interface réseau, sous-réseau, volume
7.
(Facultatif) Si vous souhaitez inclure une stratégie basée sur les ressources dans votre simulation,
vous devez d'abord sélectionner les actions que vous souhaitez simuler sur cette ressource
dans Step 4 (p. 334). Développez les lignes des actions sélectionnées et saisissez l'ARN
de la ressource avec une stratégie que vous souhaitez simuler. Puis sélectionnez Include
Resource Policy en regard de la zone de texte ARN. Le simulateur de stratégies IAM prend
actuellement en charge les stratégies basées sur des ressources dans les services suivants :
Amazon S3 (stratégies basées sur les ressources uniquement ; les ACL ne sont pas pris en
charge actuellement), Amazon SQS, Amazon SNS et coffres Amazon Glacier déverrouillés (les
coffres verrouillés ne sont pas pris en charge actuellement).
8.
Choisissez Run Simulation dans le coin supérieur droit.
La colonne Permission de chaque ligne de Action Settings and Results affiche le résultat de la
simulation de cette action sur la ressource spécifiée.
9.
Pour voir quelle déclaration d'une stratégie autorise ou refuse explicitement une action, choisissez
le lien N matching statement(s) dans la colonne Permissions pour développer la ligne, puis
choisissez le lien Show statement. Le volet Policies affiche la stratégie correspondant à la
déclaration ayant affecté le résultat de la simulation surlignée.
Note
Si une action est implicitement refusée, c'est-à-dire, si l'action est refusée uniquement
parce qu'elle n'est pas autorisée explicitement, les options List et Show statement ne sont
pas affichées.
Dépannage des messages de la console du simulateur de stratégies IAM
Le tableau suivant répertorie les messages d'information et d'avertissement que vous êtes susceptible
de recevoir lorsque vous utilisez le simulateur de stratégies IAM. Le tableau fournit également des
mesures à prendre pour les résoudre.
Message
Mesures à prendre
This policy has been edited. Changes will not be
saved to your account.
Aucune action requise.
Cannot get the resource policy. Reason:
detailed error message
Le simulateur ne parvient pas à accéder à une
stratégie basée sur des ressources demandée.
Vérifiez que l'ARN de la ressources spécifiée est
336
Ce message est informatif. Si vous modifiez
une stratégie existante dans le simulateur de
stratégies IAM, votre modification d'affecte pas
votre compte AWS. Le simulateur vous permet
de modifier vos stratégies uniquement à des fins
de test.
Message
Mesures à prendre
correct et que l'utilisateur exécutant la simulation
est autorisé à lire la stratégie de la ressource.
One or more policies require values in the
simulation settings. The simulation might fail
without these values.
Ce message s'affiche si la stratégie que vous
testez contient des clés de condition ou des
variables mais que vous n'avez pas entré
de valeurs pour ces clés ou variables dans
Simulation Settings.
Pour ignorer ce message, cliquez sur Simulation
Settings, puis entrez une valeur pour chaque clé
de condition ou variable.
You have changed policies. These results are no
longer valid.
Ce message s'affiche si vous avez modifié la
stratégie sélectionnée tandis que les résultats
sont affichés dans le volet Results. Les résultats
affichés dans le volet Results ne se mettent pas
à jour de manière dynamique.
Pour ignorer ce message, cliquez sur Run
Simulation à nouveau pour afficher les nouveaux
résultats de la simulation basés sur les
modifications apportées dans le volet Policies.
The resource you entered for this simulation
does not match this service.
Ce message s'affiche si vous avez saisi un
ARN (Amazon Resource Name) dans le volet
Simulation Settings qui ne correspond pas au
service que vous avez choisi pour la simulation
actuelle. Par exemple, ce message s'affiche
si vous spécifiez un ARN pour une ressource
Amazon DynamoDB mais que vous choisissez
Amazon Redshift en tant que service à simuler.
Pour ignorer ce message, procédez comme suit :
• Supprimez l'ARN de la zone du volet
Simulation Settings.
• Choisissez le service correspondant à l'ARN
que vous avez spécifié dans Simulation
Settings.
This action belongs to a service that supports
special access control mechanisms in addition
to resource-based policies, such as S3 ACLs
or Glacier vault lock policies. The policy
simulator does not support these mechanisms,
so the results can differ from your production
environment.
337
Ce message est informatif. Dans la version
actuelle, le simulateur évalue les stratégies
attachées aux utilisateurs et aux groupes, et peut
évaluer les stratégies basées sur des ressources
pour Amazon S3, Amazon SQS, Amazon SNS
et Amazon Glacier. Le simulateur de stratégie
ne prend pas en charge tous les mécanismes
de contrôle d'accès pris en charge par d'autres
services AWS.
Message
Mesures à prendre
DynamoDB FGAC is currently not supported.
Ce message est informatif. Il fait référence au
contrôle d'accès précis qui permet d'utiliser des
conditions de stratégie IAM afin de déterminer
qui peut accéder à des éléments de données
et à des attributs individuels dans les tables et
index DynamoDB, ainsi que les actions pouvant
être exécutées sur ceux-ci. La version actuelle
du simulateur de stratégies IAM ne prend pas en
charge ce type de condition de stratégie. Pour
plus d'informations sur le contrôle d'accès précis
à DynamoDB, consultez la section Contrôle
d'accès précis pour DynamoDB.
You have policies that do not comply with the
policy syntax. You can use the Policy Validator to
review and accept the recommended updates to
your policies.
Ce message s'affiche en haut de la liste des
stratégies si vous disposez de stratégies non
conformes à la syntaxe des stratégies IAM. Pour
simuler ces stratégies, suivez les instructions
dans la section Utilisation du programme de
validation de stratégies (p. 339) pour identifier
et corriger ces stratégies.
This policy must be updated to comply with the
latest policy syntax rules.
Ce message s'affiche si vous disposez de
stratégies non conformes à la syntaxe des
stratégies IAM. Pour simuler ces stratégies,
suivez les instructions dans la section
Utilisation du programme de validation de
stratégies (p. 339) pour identifier et corriger ces
stratégies.
Utilisation du simulateur de stratégies IAM (AWS CLI, l'Outils
pour Windows PowerShell et l'API AWS)
Les commandes du simulateur de stratégies nécessitent généralement d'appeler des API pour faire
deux choses :
1. Évaluer les stratégies et renvoyer la liste des clés de contexte auxquelles elles font référence. Vous
devez savoir quelles clés de contexte sont référencées pour pouvoir leur attribuer des valeurs à
l'étape suivante.
2. Simuler les stratégies, en fournissant une liste d'actions, de ressources et de clés de contexte
utilisées pendant la simulation.
Pour des raisons de sécurité, les API ont été réparties en deux groupes :
• Les API qui simulent uniquement les stratégies transmises directement à l'API sous forme de
chaînes. Cet ensemble inclut GetContextKeysForCustomPolicy et SimulateCustomPolicy.
• Les API qui simulent les stratégies attachées à un utilisateur IAM, un groupe, un rôle ou une
ressource spécifiée. Du fait que les API peuvent révéler des informations sur les autorisations
affectées à d'autres entités IAM, vous devez envisager de restreindre l'accès à ces API. Cet
ensemble inclut GetContextKeysForPrincipalPolicy et SimulatePrincipalPolicy. Pour plus
d'informations sur les restrictions appliquées aux API, consultez Permettre aux utilisateurs d'accéder
aux API du simulateur de stratégies (p. 355).
338
Utilisation du programme de validation de stratégies
Dans les deux cas, les API simulent l'effet d'une ou de plusieurs stratégies sur une liste d'actions
et de ressources. Chaque action est appariée à chaque ressource et la simulation détermine si
les stratégies autorisent ou refusent cette action pour cette ressource. Vous pouvez également
fournir des valeurs pour toutes les clés de contexte auxquelles vos stratégies font référence. Pour
obtenir la liste des clés de contexte auxquelles les stratégies font référence en appelant d'abord
GetContextKeysForCustomPolicy ou GetContextKeysForPrincipalPolicy. Si vous ne
fournissez pas de valeur pour une clé de contexte, la simulation s'exécute malgré tout, mais les
résultats ne sont peut-être pas fiables, car le simulateur ne peut pas inclure cette clé de contexte dans
l'évaluation.
Pour obtenir la liste des clés de contexte
Ces commandes évaluent une liste de stratégies et renvoient une liste de clés de contexte utilisées
dans les stratégies.
• AWS CLI : aws iam get-context-keys-for-custom-policy et aws iam get-contextkeys-for-principal-policy
• Outils pour Windows PowerShell : Get-IAMContextKeysForCustomPolicy et GetIAMContextKeysForPrincipalPolicy
• API AWS : GetContextKeysForCustomPolicy et GetContextKeysForPrincipalPolicy
Pour simuler des stratégies IAM
Ces commandes simulent des stratégies IAM pour déterminer les autorisations effectives d'un
utilisateur.
• AWS CLI : aws iam simulate-custom-policy et aws iam simulate-principal-policy
• Outils pour Windows PowerShell : Test-IAMCustomPolicy et Test-IAMPrincipalPolicy
• API AWS : SimulateCustomPolicy et SimulatePrincipalPolicy
Le programme de validation de stratégies examine automatiquement vos stratégies de contrôle
d'accès IAM existantes pour vérifier qu'elles sont conformes à la syntaxe des stratégies IAM.
Une stratégie est un document JSON écrit à l'aide de la syntaxe des stratégies IAM. Il définit les
autorisations d'accès d'un utilisateur AWS, d'un groupe ou d'un rôle auquel vous attachez la stratégie.
Si le programme de validation de stratégies détermine qu'une stratégie n'est pas conforme à la
syntaxe, il vous invite à corriger la stratégie. Le programme de validation de stratégies est disponible
uniquement si vous disposez de stratégies non conformes.
Important
Vous ne pouvez pas enregistrer les nouvelles stratégies ou les stratégies mises à jour si elles
ne sont pas conformes à la syntaxe des stratégies. Si la validation d'une stratégie échoue, elle
ne peut pas être enregistrée tant que l'erreur n'a pas été corrigée. Les stratégies existantes
contenant des erreurs ayant été configurées avant l'introduction du programme de validation
de stratégies continueront de fonctionner. En revanche, vous ne pourrez ni les modifier, ni les
enregistrer tant que les erreurs de syntaxe n'auront pas été corrigées.
Note
Le programme de validation de stratégie vérifie uniquement la syntaxe et la grammaire de la
stratégie JSON. Il ne valide pas que votre ARN, vos noms d'action ou vos clés de condition
sont corrects.
339
Identification et correction des stratégies de contrôle d'accès non conformes pour respecter la
syntaxe des stratégies
1.
Connectez-vous à la console IAM. Si certaines de vos stratégies sont non conformes, une
bannière jaune intitulée Fix policy syntax s'affiche en haut de l'écran de la console. Si cette
bannière ne s'affiche pas, toutes vos stratégies sont conformes et vous pouvez vous arrêter ici.
2.
Cliquez sur le lien Fix Now.
3.
Une liste des stratégies on conformes s'affiche. Sélectionnez la stratégie que vous souhaitez
corriger en cliquant sur son nom.
4.
Un écran similaire à celui qui suit s'affiche avec les modifications recommandées à apporter à
votre stratégie situées en haut de la page dans une fenêtre d'édition et la version originale située
en bas. Dans l'exemple suivant, le moteur de stratégie recommande de modifier deux éléments de
ressource distincts (non valides) en un élément de tableau de ressource unique contenant deux
éléments (valide). Pour plus d'informations sur les règles de stratégies, consultez la Référence de
stratégie AWS IAM.
340
5.
• Si vous souhaitez accepter les modifications recommandées, cliquez sur Apply Changes.
• Si vous souhaitez modifier davantage la stratégie, vous pouvez la modifier directement dans la
zone d'édition supérieure. Si vous apportez des modifications, le bouton Validate est activé. Une
fois que vous avez terminé, vérifiez que la syntaxe respecte les règles en cliquant sur Validate.
Si le programme de validation de stratégies confirme que votre stratégie modifiée est correcte,
cliquez sur Apply Changes. Si des erreurs sont signalées, continuez de modifier la stratégie
jusqu'à ce qu'elle soit validée, puis cliquez sur Apply Changes.
6.
Une liste des stratégies non conformes est renvoyée, le cas échéant. Répétez la procédure pour
chaque stratégie jusqu'à ce que vous ayez corrigé toutes vos stratégies.
Vous pouvez modifier toutes vos stratégies vous-même à tout moment, sans utiliser le programme
de validation de stratégies. Si vous corrigez des problèmes de conformité, ils sont ensuite supprimés
automatiquement de la liste des stratégies non conformes.
341
Données sur les services consultés en dernier
La console IAM indique quand les rôles et les IAM utilisateurs ont tenté pour la dernière fois d'accéder
aux services AWS. Ces informations sont appelées données relatives aux services consultés en
dernier. Elles vous permettent d'identifier toute autorisation inutile. Vous pouvez ainsi peaufiner
vos stratégies IAM afin qu'elles respectent au plus près le principe du « moindre privilège », en
d'autres termes pour qu'elles accordent les autorisations minimales requises pour effectuer une tâche
spécifique.
Vous pouvez obtenir la date et l'heure auxquelles une entité IAM (utilisateur, groupe ou rôle) a accédé
en dernier à un service AWS à l'aide d'autorisations accordées par une stratégie IAM. Ces informations
vous permettent d'identifier des autorisations inutiles et qui n'ont pas été utilisées récemment dans
vos stratégies IAM. Vous pouvez ainsi choisir de supprimer les autorisations des services inutilisés
ou réorganiser les utilisateurs d'un groupe ayant le même modèle d'utilisation afin de mieux sécuriser
le compte. En identifiant la dernière fois qu'une entité IAM a utilisé une autorisation, vous pouvez
supprimer celles qui sont superflues et harmoniser plus facilement vos stratégies IAM.
Important
Les données relatives aux services consultés en dernier comprennent toutes les tentatives
d'accès à une API AWS et pas seulement celles qui ont abouti. Cela inclut toutes les tentatives
d'accès effectuées à l'aide de l'AWS Management Console, de l'API AWS via l'un des kits de
développement logiciel ou avec les outils de ligne de commande. Notez que la présence d'une
entrée inattendue dans les données relatives aux services consultés en dernier ne signifie pas
que votre compte a été mis en danger, car la demande a pu être refusée. Reportez-vous à
vos journaux CloudTrail. Cette source d'informations fiable indique tous les appels d'API et
si l'accès leur a été accordé ou refusé. Pour de plus amples informations, veuillez consulter
Consignation d'événements IAM avec AWS CloudTrail (p. 358).
Cette rubrique décrit la fonctionnalité utilisant les données des services IAM consultés en dernier et
explique comment vous en servir avec la console IAM. Elle inclut également deux scénarios pratiques
détaillés dans lesquels les données relatives aux services consultés en dernier sont utilisées pour
supprimer des autorisations non requises dans une stratégie IAM.
Rubriques
• Affichage des informations d'Access Advisor (p. 342)
• Remarques (p. 344)
• Conseils pour le dépannage (p. 344)
• Exemples de scénario d'utilisation (p. 344)
• Différences régionales de période de suivi (p. 346)
Affichage des informations d'Access Advisor
Vous pouvez accéder aux données dans l'onglet Access Advisor de la console IAM en consultant les
détails d'un utilisateur, groupe, rôle ou stratégie gérée IAM.
Autorisations minimales requises pour consulter les informations d'Access Advisor
En plus des autorisations nécessaires pour afficher les détails de l'utilisateur, du groupe, du
rôle ou de la stratégie dans la console IAM, vous devez avoir au moins l'autorisation suivante
pour afficher les données relatives aux services consultés en dernier :
• iam:GenerateServiceLastAccessedDetails
• iam:GetServiceLastAccessedDetails
342
• iam:GetServiceLastAccessedDetailsWithEntities
• iam:ListPoliciesGrantingServiceAccess
Aucune ne sont des autorisations au niveau des ressources. Elles prennent toutes uniquement
"Resource": "*" dans une stratégie IAM.
Sachez qu'accorder ces autorisations permet à l'utilisateur de voir les utilisateurs, les groupes
ou les rôles attachés à une stratégie gérée, les services auxquels un utilisateur ou un rôle
peut accéder et les services qui ont été consultés, par qui et quand. Cela est semblable
aux autorisations iam:ListEntitiesForPolicy et iam:ListAttached[User/Group/
Role]Policies.
Pour afficher les informations d'Access Advisor
1.
2.
Dans le volet de navigation, choisissez Groupes, Users, Roles ou Policies.
3.
Choisissez un nom d'utilisateur, de groupe, de rôle ou de stratégie pour afficher les détails,
puis sélectionnez l'onglet Access Advisor. L'onglet affiche un tableau comportant les colonnes
suivantes :
Nom du service
Liste de services dotés d'autorisations accordées par une stratégie IAM (si vous vérifiez une
stratégie) ou liste de services dotés d'autorisations accordées à l'entité IAM par toutes les
stratégies IAM (si vous vérifiez un utilisateur, un groupe ou un rôle).
Une ligne affiche un service pour lequel n'importe quelle autorisation a été accordée à l'entité
par une stratégie IAM, que celle-ci soit pour une ou toutes les actions dans le service.
Autorisation d'octrois de stratégies
Nom d'une stratégie et nombre d'autres stratégies qui accordent à cette entité l'autorisation
d'accéder au service spécifié. Cliquez sur le lien indiquant le nom de stratégie et le nombre
pour afficher la liste de toutes les stratégies IAM qui autorisent cette entité à accéder au
service spécifié. La liste inclut également le nom, le type de stratégie (gérée AWS, gérée par
le client ou en ligne) et le groupe (le cas échéant) par lequel un utilisateur obtient la stratégie.
Si vous choisissez le nom d'une stratégie gérée dans la boîte de dialogue Policies Granting
Permissions, IAM ouvre un nouvel onglet de navigateur contenant le texte de la stratégie. Si
vous cliquez sur un nom de groupe dans la boîte de dialogue, IAM ouvre un nouvel onglet de
navigateur qui en affiche les détails.
Dernière consultation
Durée écoulée depuis que cet utilisateur, ce rôle ou un membre d'un groupe a consulté pour
la dernière fois le service spécifié.
Les données des services consultés en dernier remontent à la date de début du suivi pour
votre région (p.
). Le laps de temps écoulé entre cette date et la date actuelle est appelé
période de suivi. Si le service n'a jamais été consulté ou si l'accès s'est produit en dehors de
la période de suivi, le message Non consulté pendant la période de suivi s'affiche à la place
de l'horodatage. Les activités effectuées avant la période de suivi ne sont pas disponibles.
Accès par des membres
(Groupe uniquement) Nom d'un utilisateur et nombre d'autres membres du groupe qui ont
accès à ce service. Cliquez sur le lien pour afficher une liste de tous les utilisateurs IAM
appartenant au groupe et pour voir à quel moment chaque membre a consulté le service
spécifié pour la dernière fois.
Si vous choisissez le nom d'un utilisateur dans la boîte de dialogue, IAM ouvre un nouvel
onglet de navigateur pour afficher ses détails.
343
Accès par les entités
(Stratégie uniquement) Nom d'un utilisateur ou rôle et nombre des autres utilisateurs et rôles
qui ont utilisé cette stratégie pour accéder au service spécifié. Cliquez sur le lien pour afficher
une liste de tous les utilisateurs et rôles auxquels cette stratégie est attachée et pour savoir à
quel moment chacun a consulté le service spécifié pour la dernière fois.
Options supplémentaires
• Utilisez le menu Filtre sur l'onglet Access Advisor pour limiter la liste aux Services consultés ou
Services non consultés. Par exemple, vous pouvez sélectionner Services non consultés pour
une stratégie afin de découvrir les services inclus dans cette stratégie qui ne sont jamais utilisés
et qui peuvent éventuellement en être supprimés. Vous pouvez également entrer un nom (ou
une partie du nom) dans la zone Filtre pour limiter la liste aux entités dont le nom correspond à
ce que vous tapez.
• Sélectionnez des en-têtes de colonne pour trier les informations en fonction de leur contenu.
Sélectionnez l'en-tête à nouveau pour effectuer le tri dans l'ordre inverse.
Remarques
• Les services répertoriés dans le tableau reflètent l'état actuel de vos stratégies IAM, et non pas un
état historique. Par exemple, si la version actuelle de votre stratégie autorise uniquement l'accès
à Amazon S3 et que la précédente permettait d'accéder à d'autre services AWS, les données
relatives aux derniers services consultés affichées dans le tableau incluent uniquement une entrée
pour Amazon S3. Si vous voulez établir l'historique des modifications du contrôle d'accès à votre
compte, ou si vous souhaitez analyser l'historique des accès, nous vous recommandons d'utiliser
AWS CloudTrail.
• En général, la Dernière consultation récente s'affiche dans le tableau en moins de 4 heures. Dans
certaines circonstances, elle peut toutefois prendre jusqu'à 12 heures. Lorsque le fonctionnement du
service est anormalement lent, une notification s'affiche dans la console IAM.
Conseils pour le dépannage
Si le tableau des dernières consultations de service est vide, ceci peut-être dû à plusieurs raisons :
• Vous avez sélectionné un utilisateur auquel aucune stratégie n'est attachée, directement ou via
l'appartenance à des groupes.
• Vous avez sélectionné une stratégie gérée attachée à un groupe ne comportant aucun membre.
• Vous avez sélectionné un utilisateur, groupe ou rôle auquel n'est attachée aucune stratégie en ligne
ou gérée.
• Vous avez sélectionné un utilisateur auquel des autorisations ont été accordées par une stratégie
basée sur les ressources uniquement.
Exemples de scénario d'utilisation
Les exemples suivants montrent l'avantage d'utiliser Access Advisor d'IAM pour les stratégies (premier
exemple) et les mandataires (deuxième exemple).
Réduction de la portée des autorisations d'une stratégie IAM
Prenons l'exemple d'un administrateur qui est responsable de la gestion de l'infrastructure AWS d'une
équipe. L'équipe a créé une application qui s'exécute sur Amazon EC2 et appelle d'autres services
AWS. Ceci signifie que l'administrateur doit mettre en service une instance EC2 pour cette application
et gérer sa configuration, notamment en attachant un rôle IAM à l'instance EC2.
344
Note
Vous pouvez attacher des rôles IAM, à des instances EC2 afin que les applications qui
s'exécutent sur ces instances puissent créer des demandes d'API sans qu'il soit nécessaire
pour vous de gérer manuellement les informations d'identification de sécurité que les
applications utilisent. Au lieu de créer et distribuer vos informations d'identification AWS,
vous pouvez déléguer l'autorisation pour créer des demandes d'API à un rôle IAM affecté à
l'instance. Pour plus d'informations, consultez Rôles IAM pour Amazon EC2.
Toutefois, l'administrateur n'est pas familiarisé avec IAM et lorsqu'il doit attacher le rôle IAM à
l'instance EC2, il n'est pas certain de ce qu'il doit inclure dans la stratégie d'autorisation du rôle.
L'administrateur veut mettre en œuvre un mécanisme de contrôle d'accès complet, mais la priorité
immédiate et de garantir le bon fonctionnement de l'application. Pour ce faire, il copie simplement la
stratégie gérée par AWS PowerUserAccess ci-dessous, dans le but de la modifier ultérieurement,
une fois qu'il aura identifié les autorisations réellement nécessaires. Cette stratégie accorde des
autorisations complètes en lecture-écriture à tous les services et ressources AWS du compte, à
l'exception d'IAM (et elle n'est en aucun cas recommandée comme solution à long terme).
{
"Statement": [
{
"Effect": "Allow",
"NotAction": "iam:*",
"Resource": "*"
}
]
}
Une fois que l'application a été exécutée pendant un moment, l'administrateur peut utiliser les données
relatives aux derniers services consultés pour vérifier les autorisations réellement utilisées et ainsi,
réduire les autorisations affectées à l'application. L'administrateur se connecte à la console IAM et
choisit Policies, puis recherche la stratégie attachée au rôle IAM associé à l'instance EC2 sur laquelle
s'exécute l'application. Après avoir sélectionné le nom de la stratégie pour afficher ses détails, il
sélectionne l'onglet Access Advisor.
L'administrateur passe en revue les horodatages répertoriés dans la colonne Dernière consultation et
remarque que l'application de l'équipe utilise uniquement Amazon DynamoDB, Amazon S3, Amazon
CloudWatch, Amazon Simple Notification Service (Amazon SNS) et Amazon Simple Queue Service
(Amazon SQS). Il peut ensuite choisir l'onglet Document de stratégie et utiliser l'éditeur de stratégies
ou le générateur de stratégies pour modifier l'accès du rôle IAM de façon à inclure uniquement les
autorisations requises pour que l'application s'exécute correctement.
Réduction de la portée des autorisations d'un utilisateur IAM
Prenons l'exemple d'un administrateur informatique qui doit s'assurer que les employés de
l'organisation ne disposent pas d'autorisations AWS trop élevées. Dans le cadre d'un contrôle de
sécurité périodique, l'administrateur passe en revue les autorisations de tous les utilisateurs IAM. L'un
des ces utilisateurs est un développeur d'applications, qui avait précédemment le rôle d'ingénieur
sécurité. Dans la mesure où ses tâches ont évolué, le développeur est à la fois membre du groupe
« app-dev » pour son nouveau poste (qui accorde des autorisations à plusieurs services, notamment
Amazon EC2, Amazon EBS, Auto Scaling, etc.) et du groupe « security-team » pour son ancien poste
(qui accorde des autorisations pour IAM et CloudTrail).
L'administrateur se connecte à la console IAM, choisit Users, sélectionne le nom d'utilisateur IAM du
développeur, puis choisit l'onglet Access Advisor.
Il passe en revue les horodatages de la colonne Dernière consultation et remarque que le développeur
n'a pas récemment accédé à IAM, CloudTrail, Amazon Route 53, Amazon Elastic Transcoder ni à
345
quelques autres services AWS. Il peut maintenant se servir des informations sur les derniers services
consultés. Toutefois, contrairement à l'exemple précédent, les étapes suivantes applicables à un
mandataire tel que l'utilisateur IAM du développeur (qui peut être doté de plusieurs stratégies et
appartenir à plusieurs groupes IAM) requièrent que l'administrateur procède avec précaution pour
éviter de modifier l'accès des autres utilisateurs. Ainsi, la première étape consiste à déterminer
comment ces autorisations sont accordées au développeur.
L'administrateur établit que le travail du développeur ne requiert plus l'accès à IAM et CloudTrail, car il
n'est plus membre de l'équipe de sécurité interne. Après analyse des appartenances et des stratégies
du groupe, l'administrateur se rend compte que, pour ces autorisations, la solution la plus simple
consiste à retirer le développeur des membres du groupe security-team d'IAM plutôt que de modifier
les stratégies.
L'administrateur peut également déduire que l'accès du développeur à Amazon Route 53, Elastic
Transcoder, etc. à partir du groupe app-dev doit être révoqué car inutilisé. Toutefois, avant de
supprimer ces autorisations de la stratégie du groupe app-dev (ce qui risque d'avoir un impact sur les
autres membres du groupe), l'administrateur doit passer en revue les données relatives aux derniers
services consultés pour les stratégies du groupe app-dev group afin de vérifier si ces autorisations ne
sont pas utilisées par l'ensemble des membres du groupe app-dev, ou par ce développeur spécifique
uniquement. Si elles ne sont utilisées par aucun des membres du groupe, l'administrateur peut
sans doute supprimer ces autorisations en toute sécurité de la stratégie du groupe app-dev. Si ce
développeur est le seul à ne pas avoir recours aux autorisations, l'administrateur peut éventuellement
lui définir un ensemble d'autorisations spécifique. Il peut aussi choisir de ne rien faire et accepter le fait
que tous les utilisateurs n'utiliseront pas les autorisations qui leur sont accordées.
Comme illustré dans cet exemple, vous pouvez utiliser les données relatives aux derniers services
consultés comme point de départ pour les mandataires, puis y ajouter diverses étapes en fonction des
services inutilisés, y compris comme suggéré ci-après. Toutefois, en tant qu'administrateur IAM, il vous
appartient de choisir les étapes appropriées selon l'accès requis pour votre organisation et l'application
du principe du moindre privilège.
• Suppression de membres d'un groupe (p. 137)
• Détachement d'une stratégie gérée (p. 325)
• Suppression d'une stratégie gérée (p. 327)
• Suppression d'une stratégie en ligne et conversion en stratégie gérée (p. 329)
• Modification d'une stratégie existante pour supprimer des autorisations (p. 326)
• Ajout d'un refus explicite à une stratégie existante (p. 445)
Différences régionales de période de suivi
AWS a commencé à recueillir les données des services consultés en dernier dans la plupart des
régions le 1er octobre 2015. Comme AWS ajoute la prise en charge des données des services
consultés en dernier de régions supplémentaires, celles-ci ont des dates de début du suivi différentes.
Voici la liste des régions dont les dates de début de la période de suivi sont ultérieures :
Région
Date de début de la période de suivi
Régions initialement prises en charge :
1 octobre 2015
• USA Est (Virginie du Nord) (us-east-1)
• USA Ouest (Californie du Nord) (us-west-1)
• USA Ouest (Oregon) (us-west-2)
• Asie-Pacifique (Tokyo) (ap-northeast-1)
• Asie-Pacifique (Singapour) (ap-southeast-1)
• Asie-Pacifique (Sydney) (ap-southeast-2)
346
Exemples de stratégies pour l'accès à AWS
Région
Date de début de la période de suivi
• UE (Francfort) (eu-central-1)
• UE (Irlande) (eu-west-1)
Amérique du Sud (São Paulo) (sa-east-1)
11 décembre 2015
Asie-Pacifique (Séoul) (ap-northeast-2)
6 janvier 2016
Asie-Pacifique (Mumbai) (ap-south-1)
27 juin 2016
Si une région n'est pas répertoriée dans le tableau précédent, cette région ne fournit pas encore les
dernières données de service consultées.
Exemples de stratégies de gestion de ressources
AWS
Cette section présente des exemples de stratégies contrôlant l'accès aux ressources dans les services
AWS. Pour obtenir des exemples de stratégies qui expliquent comment laisser des utilisateurs IAM
administrer des ressources IAM (par exemple, pour autoriser les utilisateurs à modifier leurs propres
clés d'accès), consultez Exemples de stratégies de gestion de ressources IAM (p. 287).
Rubriques
• Autoriser des utilisateurs à accéder à un compartiment spécifique dans Amazon S3 (p. 347)
• Autoriser des utilisateurs à accéder à un « répertoire de base » personnel dans Amazon
S3 (p. 348)
• Autoriser les utilisateurs connectés à Amazon Cognito à accéder à leur propre dossier Amazon
S3 (p. 349)
• Autoriser tous les utilisateurs à accéder à toutes les actions sur une table DynamoDB dont le nom
correspond au nom utilisateur (p. 350)
• Autoriser les utilisateurs à gérer des volumes Amazon EBS et des instances Amazon EC2 ayant la
balise spécifiée (p. 351)
• Autoriser uniquement une instance Amazon EC2 spécifique à exécuter certaines commandes
AWS (p. 351)
• Utiliser des conditions de restriction lorsque des autorisations sont autorisées (p. 352)
• Refuser tout accès, sauf pour un ensemble spécifique de produits et de ressources AWS (p. 353)
• Bloquer des demandes qui ne proviennent pas d'une adresse IP ou d'une plage d'adresses IP
approuvée (p. 354)
• Permettre aux utilisateurs d'accéder au simulateur de stratégies (p. 354)
• Autoriser les utilisateurs à charger des certificats de serveur et à les utiliser avec Elastic Load
Balancing (p. 357)
Autoriser des utilisateurs à accéder à un compartiment
spécifique dans Amazon S3
La stratégie suivante peut être attachée à un utilisateur IAM ou à un groupe IAM. Elle permet à
l'utilisateur ou aux membres du groupe d'accéder à un compartiment spécifique et à tous les objets
qu'il contient. Les utilisateurs peuvent également répertorier tous les compartiments du compte
(autorisation s3:ListAllMyBuckets). Cette autorisation permet à l'utilisateur d'exécuter d'autres
actions à l'aide de la console Amazon S3.
347
Note
Dans la stratégie suivante, vous devez remplacer EXAMPLE-BUCKET-NAME par le nom de
votre compartiment.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
],
"Resource": "arn:aws:s3:::EXAMPLE-BUCKET-NAME"
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::EXAMPLE-BUCKET-NAME/*"
}
]
}
Autoriser des utilisateurs à accéder à un « répertoire de base »
personnel dans Amazon S3
La stratégie suivante peut être attachée à un groupe IAM. Elle permet à un utilisateur IAM de ce
groupe d'utiliser AWS Management Console pour accéder à un « répertoire de base » dans Amazon
S3 correspondant à son nom utilisateur. Par exemple, l'utilisateur Bob peut accéder à s3://BUCKETNAME/home/Bob/, mais pas à s3://BUCKET-NAME/home/Alice/. Dans son « répertoire de base »,
chaque utilisateur peut exécuter toutes les actions Amazon S3, comme GetObject, ListBucket,
PutObject et DeleteObject.
Note
Dans la stratégie suivante, vous devez remplacer BUCKET-NAME par le nom d'un
compartiment dans lequel vous avez créé un dossier home et des dossiers pour des
utilisateurs individuels.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
348
"s3:ListAllMyBuckets",
],
},
{
"Effect": "Allow",
"Resource": "arn:aws:s3:::BUCKET-NAME",
"Condition": {"StringLike": {"s3:prefix": [
"",
"home/",
"home/${aws:username}/*"
]}}
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::BUCKET-NAME/home/${aws:username}",
"arn:aws:s3:::BUCKET-NAME/home/${aws:username}/*"
]
}
]
}
L'exemple de stratégie précédent utilise une variable de stratégie (p. 430) (${aws:username}) qui
est évaluée lors de l'exécution et qui contient le nom convivial (p. 387) de l'utilisateur IAM à l'origine
de la demande.
L'accès basé sur la console est accordé par les déclarations incluant les actions ListAllMyBuckets,
GetBucketLocation et ListBucket. Celles-ci sont requises pour pouvoir accéder aux listes de
compartiments dans AWS Management Console. Lorsque la stratégie précédente est attachée à un
groupe, chaque utilisateur du groupe peut lire, écrire et répertorier des objets uniquement dans son
répertoire de base. Cette stratégie permet également à l'utilisateur de voir que les répertoires des
autres utilisateurs existent dans le compartiment, sans toutefois qu'il puisse répertorier, lire ou écrire
dans le contenu des répertoires des autres utilisateurs.
Autoriser les utilisateurs connectés à Amazon Cognito à
accéder à leur propre dossier Amazon S3
Amazon Cognito est le meilleur moyen d'utiliser la fédération d'identité web dans votre application
mobile. Grâce à Amazon Cognito, vous pouvez accorder l'accès aux ressources AWS aux utilisateurs
connectés à votre application à l'aide d'un fournisseur d'identité tiers comme Login with Amazon,
Facebook, Google ou tout autre fournisseur d'identité compatible avec OpenID Connect (OIDC) plutôt
que d'utiliser un utilisateur IAM. Pour utiliser Amazon Cognito pour la fédération d'identité web, vous
créez un rôle qui détermine les autorisations dont disposera un utilisateur fédéré. Vous pouvez créer
un rôle pour les utilisateurs authentifiés. Si votre application autorise les utilisateurs non authentifiés
(invités), vous pouvez créer un second rôle définissant les autorisations de ces utilisateurs.
Pour plus d'informations sur Amazon Cognito, consultez les ressources suivantes :
L'exemple suivant illustre une stratégie pouvant être utilisée pour une application mobile qui utilise
Amazon Cognito. La condition vérifie que l'utilisateur a accès aux objets du compartiment Amazon
349
S3 représenté par EXAMPLE-BUCKET-NAME uniquement si le nom de l'objet inclut un nom de
fournisseur (ici, cognito), le nom convivial de l'application (ici, mynumbersgame) et l'ID de l'utilisateur
fédéré.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": ["arn:aws:s3:::EXAMPLE-BUCKET-NAME"],
"Condition": {"StringLike": {"s3:prefix": ["cognito/mynumbersgame/"]}}
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::EXAMPLE-BUCKET-NAME/cognito/mynumbersgame/${cognitoidentity.amazonaws.com:sub}",
"arn:aws:s3:::EXAMPLE-BUCKET-NAME/cognito/mynumbersgame/${cognitoidentity.amazonaws.com:sub}/*"
]
}
]
}
Autoriser tous les utilisateurs à accéder à toutes les actions
sur une table DynamoDB dont le nom correspond au nom
utilisateur
La stratégie suivante peut être attachée à un groupe IAM et accorde à un utilisateur l'autorisation
d'accéder par programmation à une table DynamoDB dont le nom correspond au nom utilisateur. Par
exemple, l'utilisateur Bob peut exécuter toutes les actions DynamoDB de la table appelée Bob. La
stratégie peut être attachée à un groupe contenant les utilisateurs autorisés à gérer chacun leur propre
table DynamoDB.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Resource": "arn:aws:dynamodb:AWS-REGION-IDENTIFIER:ACCOUNT-ID-WITHOUTHYPHENS:table/${aws:username}"
}]
}
La stratégie utilise une variable de stratégie (p. 430) (${aws:username}) qui est évaluée lors de
l'exécution et qui contient le nom convivial (p. 387) de l'utilisateur IAM à l'origine de la demande.
350
Autoriser les utilisateurs à gérer des volumes Amazon EBS et
des instances Amazon EC2 ayant la balise spécifiée
L'exemple de stratégie suivant permet aux utilisateurs d'attacher des volumes Amazon EBS ayant la
balise volume_user=IAM user name aux instances Amazon EC2 ayant la balise department=dev,
et de détacher les volumes de ces instances. Lorsque vous attachez cette stratégie à un groupe IAM,
la variable de stratégie (p. 430) ${aws:username} est résolue en nom utilisateur de l'utilisateur
IAM. La stratégie accorde donc à chaque utilisateur IAM du groupe l'autorisation d'attacher ou de
détacher des volumes ayant une balise nommée volume_user qui a son nom utilisateur IAM comme
valeur.
Pour plus d'informations sur la création de stratégies IAM basées sur les ressources pour contrôler
l'accès aux ressources Amazon EC2, consultez Contrôle de l'accès aux ressources Amazon EC2 dans
le manuel Amazon EC2 Guide de l'utilisateur pour les instances Linux.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": "arn:aws:ec2:AWS-REGION-IDENTIFIER:ACCOUNT-ID-WITHOUTHYPHENS:instance/*",
"Condition": {"StringEquals": {"ec2:ResourceTag/department": "dev"}}
},
{
"Effect": "Allow",
"Action": [
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": "arn:aws:ec2:AWS-REGION-IDENTIFIER:ACCOUNT-ID-WITHOUTHYPHENS:volume/*",
"Condition": {"StringEquals": {"ec2:ResourceTag/volume_user":
"${aws:username}"}}
}
]
}
Autoriser uniquement une instance Amazon EC2 spécifique à
exécuter certaines commandes AWS
Les commandes AWS appelées depuis une instance Amazon EC2 s'exécutent avec l'autorisation
accordée au rôle attaché au profil de l'instance. L'exemple de stratégie suivant, si celle-ci est attachée
à ce rôle, autorise les commandes depuis l'instance d'attacher ou de détacher des volumes associés à
cette instance. L'identité de l'instance est spécifiée avec un ARN dans l'élément Condition. L'ajout de
la condition SourceInstanceArn à une déclaration dans une stratégie qui accorde normalement des
autorisations à de nombreuses instances Amazon EC2 vous permet de spécifier une instance dans un
parc en tant qu'exception permettant d'effectuer une tâche unique que d'autres instances, disposant
de la même stratégie attachée, ne peuvent pas effectuer. Dans l'exemple suivant, seule l'instance
identifiée par instance-id peut attacher (ou détacher) des volumes aux instances du compte, y
compris les siens. D'autres éléments de déclaration susceptibles d'exister dans la stratégie ne sont
affectés par la restriction de cette déclaration.
351
Pour plus d'informations sur la création de stratégies IAM basées sur les ressources pour contrôler
l'accès aux ressources Amazon EC2, consultez Contrôle de l'accès aux ressources Amazon EC2 dans
le manuel Amazon EC2 Guide de l'utilisateur pour les instances Linux.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AttachVolume",
"ec2:DetachVolume"
],
"Resource": [
"arn:aws:ec2:region:account-id:volume/*",
"arn:aws:ec2:region:account-id:instance/*"
],
"Condition": {
"ArnEquals": {
"ec2:SourceInstanceARN": "arn:aws:ec2:region:accountid:instance/instance-id"
}
}
}
]
}
Utiliser des conditions de restriction lorsque des autorisations
sont autorisées
L'exemple de stratégie suivant permet aux utilisateurs d'exécuter toutes les actions Amazon EC2 sur
toutes les ressources Amazon EC2, mais uniquement lorsque l'utilisateur s'est authentifié à l'aide de
l'authentification multi-facteurs (MFA) (p. 93) et uniquement lorsque l'action se produit le 20 avril 2015
et le 24 avril 2015 (UTC), inclus. Cette stratégie présente un exemple de plusieurs conditions qui sont
évaluées à l'aide d'un AND logique.
{
"Version": "2012-10-17",
"Statement": {
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "*",
"Condition": {
"Bool": {"aws:MultiFactorAuthPresent": true},
"DateGreaterThan": {"aws:CurrentTime": "2015-04-20T00:00:00Z"},
"DateLessThan": {"aws:CurrentTime": "2015-04-24T00:00:00Z"}
}
}
}
Pour plus d'informations sur l'ajout de conditions aux stratégies, consultez Condition (p. 413) dans la
référence des éléments de stratégie.
352
Refuser tout accès, sauf pour un ensemble spécifique de
produits et de ressources AWS
La stratégie suivante permet aux utilisateurs d'accéder aux éléments suivants :
• la table DynamoDB dont le nom est représenté par EXAMPLE-TABLE-NAME ;
• le compartiment Amazon S3 d'entreprise du compte AWS dont le nom est représenté par
EXAMPLE-BUCKET-NAME et tous les objets qu'il contient.
La stratégie inclut un refus explicite (p. 442) ("Effect":"Deny"). En conjonction avec les éléments
NotAction et NotResource, cela permet de garantir que les utilisateurs ne peuvent utiliser aucune
action ou ressource AWS excepté celles spécifiées dans la stratégie, même si des autorisations ont
été octroyées dans une autre stratégie. (Une déclaration de refus explicite est prioritaire sur une
déclaration d'autorisation.) Pour de plus amples informations, veuillez consulter Logique d'évaluation
de stratégies IAM (p. 441).
Note
La stratégie suivante fonctionne uniquement pour l'accès aux API. Pour plus d'informations
sur l'octroi d'un accès au compartiment via AWS Management Console, consultez Exemple :
utilisation de stratégies IAM pour contrôler l'accès à votre compartiment dans le manuel
Amazon Simple Storage Service Manuel du développeur.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:*",
"s3:*"
],
"Resource": [
"arn:aws:dynamodb:AWS-REGION-IDENTIFIER:ACCOUNT-ID-WITHOUTHYPHENS:table/EXAMPLE-TABLE-NAME",
"arn:aws:s3:::EXAMPLE-BUCKET-NAME",
"arn:aws:s3:::EXAMPLE-BUCKET-NAME/*"
]
},
{
"Effect": "Deny",
"NotAction": [
"dynamodb:*",
"s3:*"
],
"NotResource": [
"arn:aws:dynamodb:AWS-REGION-IDENTIFIER:ACCOUNT-ID-WITHOUTHYPHENS:table/EXAMPLE-TABLE-NAME",
"arn:aws:s3:::EXAMPLE-BUCKET-NAME",
"arn:aws:s3:::EXAMPLE-BUCKET-NAME/*"
]
}
]
}
353
Bloquer des demandes qui ne proviennent pas d'une adresse
IP ou d'une plage d'adresses IP approuvée
Cette stratégie peut être appliquée à un groupe IAM dont font partie tous les utilisateurs de votre
entreprise. Cette stratégie refuse l'accès à toutes les actions du compte lorsque la demande provient
d'une adresse IP extérieure à la page 192.0.2.0 à 192.0.2.255 ou 203.0.113.0 à 203.0.113.255. (Elle
suppose que les adresses IP de votre entreprise se situent dans les pages d'adresses IP spécifiées.)
Utilisez cette stratégie conjointement à d'autres stratégies qui autorisent des actions spécifiques.
Quelles que soient les actions autorisées à un utilisateur ou à un groupe par le biais d'une autre
stratégie, celle-ci doit s'assurer que les actions seront refusées si la demande provient d'une adresse
IP située en dehors des plages d'adresses IP de l'entreprise.
Important
La clé de condition aws:SourceIp fonctionne uniquement dans une stratégie IAM si vous
appelez l'API que vous testez directement en tant qu'utilisateur. En revanche, si vous utilisez
un service pour appeler le service cible en votre nom, ce service voit l'adresse IP du service
appelant plutôt que celle de l'utilisateur d'origine. Par exemple, cela peut se produire si vous
utilisez AWS CloudFormation pour appeler Amazon EC2 pour créer des instances pour vous.
Actuellement, il n'est pas possible de transmettre l'adresse IP d'origine au service cible via un
service appelant à des fins d'évaluation dans une stratégie IAM. Pour ces types d'appels d'API
de service, vous ne devez pas utiliser la clé de condition aws:SourceIp.
{
"Version": "2012-10-17",
"Statement": {
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {"NotIpAddress": {"aws:SourceIp": [
"192.0.2.0/24",
"203.0.113.0/24"
]}}
}
}
Permettre aux utilisateurs d'accéder au simulateur de
stratégies
Le simulateur de stratégies est un outil de test et de résolution des problèmes des stratégies basées
sur les ressources et IAM. Pour plus d'informations sur l'utilisation du simulateur de stratégies,
consultezTest des stratégies IAM avec le simulateur de stratégies IAM (p. 331). Par défaut, les
utilisateurs peuvent tester les stratégies qui ne sont pas encore attachées à un utilisateur, un groupe
ou à un, rôle en les saisissant ou en les copiant dans le simulateur. Ces stratégies sont utilisées
uniquement dans la simulation et ne divulguent aucune information sensible. Pour permettre aux
utilisateurs de tester les stratégies attachées à des utilisateurs, groupes ou rôles IAM dans votre
compte AWS, vous devez fournir à vos utilisateurs les autorisations de récupération de ces stratégies.
Afin de tester les stratégies basées sur les ressources, les utilisateurs doivent avoir l'autorisation
d'extraire la stratégie de la ressource.
L'exemple suivant autorise l'utilisateur à simuler une stratégie attachée à un utilisateur, groupe ou rôle
du compte AWS courant.
{
354
"Version": "2012-10-17",
"Statement": [{
"Action": [
"iam:GetPolicy",
"iam:GetUserPolicy",
"iam:GetUser",
"iam:ListUsers"
],
"Effect": "Allow",
"Resource":"*"
}]
}
L'exemple suivant autorise l'utilisateur à simuler des stratégies uniquement pour les utilisateurs ayant
pour chemin d'accès developers.
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"iam:GetPolicy",
"iam:GetUserPolicy"
],
"Effect": "Allow",
"Resource": "*"
},
{
"Action": [
"iam:GetUser",
"iam:ListUsers"
],
"Effect": "Allow",
"Resource": "arn:aws:iam::123456789012:user/developers/*"
}]
}
L'exemple suivant permet à un utilisateur IAM nommé bob du compte AWS 777788889999 de simuler
une stratégie basée sur les ressources dans le compartiment S3 example-bucket.
{
"Version": "2012-10-17",
"Statement": [{
"Action": [
"s3:GetBucketPolicy",
"s3:GetObjects"
],
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::777788889999:user/bob"},
"Resource":"arn:aws:s3:::example-bucket/*"
}]
}
Permettre aux utilisateurs d'accéder aux API du simulateur de stratégies
Les API du simulateur de stratégies GetContextKeyForPrincipalPolicy et SimulatePrincipalPolicy
peuvent renvoyer des informations sur les autorisations accordées à un utilisateur, groupe ou
355
rôle IAM à l'utilisateur appelant les API. Vous pouvez vouloir accorder des autorisations pour
ces API uniquement aux utilisateurs approuvées. D'autres utilisateurs peuvent toujours appeler
GetContextKeyForCustomPolicy et SimulateCustomPolicy, car elles évaluent les stratégies fournies
par ces utilisateurs en tant que chaînes. Aucune information sensible n'est divulguée.
L'exemple suivant explique comment accorder l'accès à des API « personnalisées » moins sensibles.
Les API « mandataires » sont restreintes par l'interdiction implicite par défaut. L'utilisateur ne peut donc
pas simuler l'attachement des stratégies aux entités.
{
"Version": "2012-10-17",
"Statement": [{
"Action": [
"iam:GetContextKeysForCustomPolicy",
"iam:SimulateCustomPolicy"
],
"Effect": "Allow",
"Resource": "*"
}]
}
L'exemple suivant autorise l'utilisateur à simuler des stratégies uniquement pour les utilisateurs ayant
pour chemin d'accès developers.
{
"Version": "2012-10-17",
"Statement": [{
"Action": [
"iam:GetContextKeysForPrincipalPolicy",
"iam:SimulatePrincipalPolicy"
],
"Effect": "Allow",
"Resource":"arn:aws:iam::123456789012:user/developers/*"
}]
}
L'exemple suivant autorise l'utilisateur à simuler une stratégie quelconque attachée à n'importe quel
utilisateur dans le compte AWS actuel.
{
"Version" : "2012-10-17",
"Statement" : [{
"Action" : [
"iam:GetContextKeysForCustomPolicy",
"iam:GetContextKeysForPrincipalPolicy",
"iam:SimulateCustomPolicy",
"iam:SimulatePrincipalPolicy"
],
"Effect" : "Allow",
"Resource" : "*"
}]
}
356
Autoriser les utilisateurs à charger des certificats de serveur et
à les utiliser avec Elastic Load Balancing
L'exemple suivant autorise l'utilisateur à télécharger et à gérer des certificats de serveur SSL/TLS et à
les attacher à un équilibreur Elastic Load Balancing.
{
"Version" : "2012-10-17",
"Statement" : [{
"Effect" : "Allow",
"Action" : [
"iam:DeleteServerCertificate",
"iam:GetServerCertificate",
"iam:ListServerCertificates",
"iam:UpdateServerCertificate",
"iam:UploadServerCertificate"
"elasticloadbalancing:SetLoadBalancerListenerSSLCertificate"
],
"Resource": [ "*" ]
}]
}
Ressources pour en savoir plus sur les
autorisations et les stratégies
Pour plus d'informations sur les autorisations et la création de stratégies, consultez les ressources
suivantes :
• Présentation des stratégies IAM (p. 294) – Cette section présente les types d'autorisations, et
explique comment accorder et gérer les autorisations.
• Utilisation de stratégies (p. 323) – Cette section explique comment spécifier les actions qui
sont autorisées, sur quelles ressources autoriser les actions et l'effet que cela aura sera lorsque
l'utilisateur demande l'accès aux ressources.
• Les entrées suivantes du Blog de sécurité AWS présentent les différentes manières d'écrire des
stratégies permettant d'accéder aux compartiments et aux objets Amazon S3.
• Writing IAM Policies: How to Grant Access to an Amazon S3 Bucket
• Writing IAM policies: Grant Access to User-Specific Folders in an Amazon S3 Bucket
• IAM Policies and Bucket Policies and ACLs! Oh My! (Controlling Access to S3 Resources)
• A Primer on RDS Resource-Level Permissions
• Demystifying EC2 Resource-Level Permissions
• Test des stratégies IAM avec le simulateur de stratégies IAM (p. 331) – Cet outil vous permet
de testez les effets des stratégies IAM pour déterminer si elles autorisent ou refusent l'accès aux
actions dans les services AWS.
• Exemples de stratégies de gestion de ressources IAM (p. 287) – Cette section contient des
exemples de stratégies qui expliquent comment exécuter des tâches spécifiques à IAM, comme
administrer des utilisateurs, des groupes et des informations d'identification.
357
Types d'informations IAM enregistrées dans CloudTrail
Consignation d'événements IAM
avec AWS CloudTrail
AWS Identity and Access Management (IAM) est intégré à AWS CloudTrail, un service qui consigne
les événements AWS exécutés par votre compte AWS ou pour le compte de celui-ci. CloudTrail
consigne les appels d'API AWS authentifiés et les événements de connexion AWS, et collecte ces
informations d'événement dans des fichiers qui sont fournis dans des compartiments Amazon S3. À
l'aide des informations recueillies par CloudTrail, vous pouvez déterminer les demandes qui ont été
exécutées avec succès vers des services AWS, qui est à l'origine de la demande, etc.
Pour en savoir plus sur CloudTrail, y compris comment le configurer et l'activer, consultez le document
AWS CloudTrail User Guide.
Rubriques
• Types d'informations IAM enregistrées dans CloudTrail (p. 358)
• Exemples d'événements enregistrés dans des fichiers CloudTrail (p. 361)
• Prévention des entrées de journal en double dans CloudTrail (p. 369)
Types d'informations IAM enregistrées dans
CloudTrail
Les informations IAM sont mises à disposition dans CloudTrail comme suit :
• Demandes d'API à IAM et AWS Security Token Service (AWS STS) – CloudTrail consigne toutes
les demandes d'API authentifiées (effectuées avec des informations d'identification) vers des
API IAM et AWS STS, à l'exception de DecodeAuthorizationMessage. CloudTrail enregistre
également les demandes non authentifiées dans des actions AWS STS AssumeRoleWithSAML et
AssumeRoleWithWebIdentity, et consigne les informations fournies par le fournisseur d'identité.
Vous pouvez utiliser ces informations pour remapper les appels effectués par un utilisateur fédéré
avec un rôle présumé à l'appelant fédéré externe d'origine. Pour AssumeRole, vous pouvez
358
remapper les appels au service AWS d'origine ou au compte de l'utilisateur d'origine. La section
userIdentity des données JSON de l'entrée de journal CloudTrail contient les informations dont
vous avez besoin pour mapper la demande AssumeRole* à un utilisateur fédéré spécifique. Pour
plus d'informations, consultez Élément userIdentity CloudTrail dans le manuel AWS CloudTrail User
Guide.
Par exemple, les appels IAM CreateUser, DeleteRole, ListGroups et les autres opérations
d'API sont tous consignés par CloudTrail.
Des exemples de ce type d'entrée de journal sont présentés ultérieurement dans cette rubrique.
Important
Si vous activez des points de terminaison AWS STS dans des régions autres que le
point de terminaison global par défaut, vous devez également activer la journalisation
CloudTrail dans ces régions pour enregistrer les appels d'API AWS STS effectués dans
ces régions. Pour plus d'informations, consultez Activation de CloudTrail dans des régions
supplémentaires dans le manuel AWS CloudTrail User Guide.
• Demandes d'API à d'autres services AWS – Les demandes authentifiées à d'autres API de service
AWS sont consignées par CloudTrail, et ces entrées de journal contiennent des informations sur
celui qui a généré la demande.
Par exemple, si une demande est effectuée pour lister des instances Amazon EC2 ou créer un
groupe de déploiement AWS CodeDeploy, l'identité d'utilisateur de la personne ou du service qui
a fait la demande est enregistrée dans l'entrée de journal pour cette demande. Les informations
d'identité d'utilisateur figurant dans le journal vous aident à déterminer si la demande a été effectuée
avec un des informations d'identification IAM à l'aide d'informations d'identification de sécurité
temporaires pour un rôle ou un utilisateur fédéré, ou par un autre service AWS.
Pour plus d'informations sur les informations d'identité utilisateur dans les entrées de journal
CloudTrail, consultez Élément userIdentity dans le manuel AWS CloudTrail User Guide.
• Événements de connexion AWS – Les événements de connexion sur la AWS Management Console,
les forums de discussion AWS et AWS Marketplace sont consignés par CloudTrail.
Par exemple, les événements de connexion IAM et d'utilisateur fédéré (ayant réussi ou échoué) sont
consignés par CloudTrail.
Si vous activez CloudTrail de façon à consigner les événements de connexion dans vos journaux,
vous devez savoir comment CloudTrail choisit l'emplacement de consignation des événements.
359
• Vous pouvez demander manuellement un point de terminaison de connexion régional spécifique
en vous connectant à la page d'accueil régionale de la console principale à l'aide d'une syntaxe
d'URL similaire à ce qui suit :
https://alias.signin.aws.amazon.com/console?region=ap-southeast-1
Important
En tant que bonne pratique de sécurité, AWS ne consigne pas le texte du nom utilisateur
saisi lorsque l'échec de la connexion est provoqué par un nom d'utilisateur incorrect. Le
texte du nom utilisateur est masqué par la valeur HIDDEN_DUE_TO_SECURITY_REASONS.
Pour en obtenir un exemple, consultez Événement d'échec de connexion provoqué par nom
d'utilisateur incorrect (p. 367), plus loin dans cette rubrique. La raison pour laquelle le nom
d'utilisateur est masqué est que de tels échecs peuvent être dus à des erreurs utilisateur
comme celles ci-dessous et si le nom d'utilisateur était consigné, cela pourrait exposer des
informations potentiellement sensibles :
• Vous avez tapé par erreur votre mot de passe dans le champ de nom d'utilisateur.
• Vous cliquez sur le lien pour la page de connexion d'un compte AWS, mais vous saisissez
le numéro d'un autre compte.
• Vous oubliez sur quel compte vous vous connectez et vous tapez par erreur le nom de
compte de votre compte de messagerie personnelle, votre identificateur de connexion
bancaire ou un autre ID privé.
L'événement de connexion est considéré comme régional ou international selon la console à laquelle
l'utilisateur se connecte et la construction de l'URL de connexion.
• La console de service est-elle régionalisée ? Le cas échéant, la demande de connexion est
redirigée automatiquement vers un point de terminaison de connexion régional et l'événement
est consigné dans le journal CloudTrail de la région. Par exemple, si vous vous connectez à la
page d'accueil https://alias.signin.aws.amazon.com/console de la console qui est
régionalisée, vous êtes redirigé automatiquement vers un point de terminaison de connexion dans
votre région (par exemple, https://us-east-2.signin.aws.amazon.com) et l’événement est
consigné dans le journal de cette région.
Toutefois, certains services n'ont pas encore été régionalisés. Par exemple, le service
Amazon S3 n'est pas actuellement régionalisé, donc si vous vous connectez à
https://alias.signin.aws.amazon.com/console/s3, vous êtes redirigé vers le point de
terminaison de connexion international à l'adresse https://signin.aws.amazon.com, ce qui
crée un événement dans votre journal international.
• Vous pouvez également demander manuellement un point de terminaison
de connexion régional spécifique en utilisant une syntaxe d'URL similaire à
https://alias.signin.aws.amazon.com/console?region=ap-southeast-1, qui redirige
vers le point de terminaison de connexion régional ap-southeast-1 et crée un événement dans le
journal régional.
• Manière dont les demandes d'informations d'identification temporaires sont consignées – Lorsqu'une
personne habilitée demande des informations d'identification temporaires, le type de personne
habilitée détermine comment CloudTrail enregistre l'événement. Le tableau suivant montre comment
CloudTrail consigne des informations différentes pour chacun des appels d'API qui génèrent des
informations d'identification temporaires.
360
Exemples d'événements enregistrés
dans des fichiers CloudTrail
Type de
personne
habilitée
API IAM/STS
Identifiants root/
de compte
Identité
d'utilisateur
dans le journal
CloudTrail pour
un appel de
compte
Identité de
l'utilisateur
dans le journal
CloudTrail pour
le compte du
propriétaire de
rôle
Identité
d'utilisateur
dans le journal
CloudTrail pour
les appels d'API
suivants
GetSessionToken Identité racine
Le compte du
propriétaire de
rôle est le même
que le compte
appelant
Identité racine
Utilisateur IAM
GetSessionToken Identité
d'utilisateur IAM
Le compte du
propriétaire de
rôle est le même
que le compte
appelant
Identité
d'utilisateur IAM
Utilisateur IAM
GetFederationTokenIdentité
d'utilisateur IAM
Le compte du
propriétaire de
rôle est le même
que le compte
appelant
Identité
d'utilisateur IAM
Utilisateur IAM
AssumeRole
Numéro de
compte et ID
Principal (s'il
s'agit d'un
utilisateur) ou
principal du
service AWS
Identité de rôle
uniquement
(aucun utilisateur)
Utilisateur
authentifié en
externe
AssumeRoleWithSAML
Non applicable
Identité
d'utilisateur
SAML
Identité de rôle
uniquement
(aucun utilisateur)
Utilisateur
authentifié en
externe
Non applicable
Identité
d'utilisateur
OIDC/web
Identité de rôle
uniquement
(aucun utilisateur)
Identité
d'utilisateur IAM
Exemples d'événements enregistrés dans des
fichiers CloudTrail
Les fichiers journaux CloudTrail contiennent des événements qui sont formatés à l'aide de JSON.
Un événement représente une demande d'API ou un événement de connexion unique et inclut des
informations sur l'action demandée, sur tous les paramètres, et sur la date et l'heure de l'action.
361
Événement d'API IAM dans le fichier journal CloudTrail
Événement d'API IAM dans le fichier journal
CloudTrail
L'exemple suivant montre une entrée de journal CloudTrail pour une demande exécutée par l'action
IAM GetUserPolicy.
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "AIDACKCEVSQ6C2EXAMPLE",
"arn": "arn:aws:iam::444455556666:user/Alice",
"accountId": "444455556666",
"accessKeyId": "AKIAI44QH8DHBEXAMPLE",
"userName": "Alice",
"sessionContext": {
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2014-07-15T21:39:40Z"
}
},
"invokedBy": "signin.amazonaws.com"
},
"eventTime": "2014-07-15T21:40:14Z",
"eventSource": "iam.amazonaws.com",
"eventName": "GetUserPolicy",
"awsRegion": "us-east-2",
"sourceIPAddress": "signin.amazonaws.com",
"userAgent": "signin.amazonaws.com",
"requestParameters": {
"userName": "Alice",
"policyName": "ReadOnlyAccess-Alice-201407151307"
},
"responseElements": null,
"requestID": "9EXAMPLE-0c68-11e4-a24e-d5e16EXAMPLE",
"eventID": "cEXAMPLE-127e-4632-980d-505a4EXAMPLE"
}
À partir de ces informations d'événement, vous pouvez déterminer que la demande a été effectuée
pour obtenir une stratégie utilisateur nommée ReadOnlyAccess-Alice-201407151307 pour
l'utilisateur Alice, comme indiqué dans l'élément requestParameters. Vous pouvez également voir
que la demande a été effectuée par un utilisateur IAM nommé Alice le 15 juillet 2014 à 21:40 (UTC).
Dans ce cas, la demande provenait de la AWS Management Console, comme vous pouvez le voir à
partir de l'élément userAgent.
Événement d'API AWS STS dans le fichier journal
CloudTrail
L'utilisateur IAM nommé « Bob » dans le compte 777788889999 appelle l'action AssumeRole AWS
STS pour assumer le rôle EC2-dev dans le compte 111122223333. Les deux exemples suivants
présentent les entrées de journal CloudTrail pour les deux comptes concernés. Le premier exemple
montre l'entrée de journal CloudTrail pour la demande effectuée dans le compte 777788889999

AWS Identity and Access Management

Transcription

Documents pareils

Le mot de passe IAM sera nécessaire pour se connecter au réseau

transition vers le cloud

L`ECOLE DU MICRO D`ARGENT

160622_cr-ateliers-ag - Institut Automobile du Mans

Téléchargez notre flyer Santé

Processus inscription KADAS

enrobeuse crystal 185

Pour ces rappeurs originaires des banlieues marseillaises, l`histoire

pline le jeune - Site des Lettres Académie de Rouen

Un collector pour le fan, une découverte enrichissante pour