Configuration de l'accès aux API protégé par MFA

Avec les politiques IAM, vous pouvez spécifier quelles opérations d'API un utilisateur est autorisé à appeler. Dans certains cas, vous souhaiterez peut-être renforcer la sécurité en imposant aux utilisateurs de s'authentifier à l'aide de l'authentification multi-facteur (MFA) AWS avant qu'ils soient autorisés à exécuter des actions particulièrement sensibles.

Par exemple, vous disposez peut-être d'une politique qui autorise l'utilisateur à exécuter les actions Amazon EC2 RunInstances, DescribeInstances et StopInstances. Mais vous souhaiterez peut-être restreindre une action destructrice telle que TerminateInstances et vous assurer que les utilisateurs ne peuvent effectuer cette action que s'ils s'authentifient auprès d'un périphérique AWS MFA.

Présentation

L'ajout d'une protection MFA aux opérations d'API nécessite les tâches suivantes :

1. L'administrateur configure un dispositif AWS MFA pour chaque utilisateur qui doit effectuer des demandes d'API nécessitant une authentification MFA. Ce processus est décrit dans la section Activation des appareils MFA pour les utilisateurs de AWS.

2. L'administrateur crée des politiques pour les utilisateurs qui incluent un Condition élément qui vérifie si l'utilisateur s'est authentifié avec un dispositif AWS MFA.

3. L'utilisateur appelle l'une des opérations d' AWS STS API prenant en charge les paramètres MFA AssumeRoleou GetSessionToken, selon le scénario de protection MFA, comme expliqué plus loin. Dans le cadre de l'appel, l'utilisateur inclut l'identifiant du périphérique associé à l'utilisateur. L'utilisateur inclut également 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 opérations d'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 de ces services, veuillez consulter Utilisation d'informations d'identification de sécurité temporaires pour accéder à AWS.

Si l'autorisation échoue, AWS renvoie un message d'erreur de refus d'accès (comme c'est le cas pour tout accès non autorisé). Lorsque des politiques d'API protégées par MFA sont en place, AWS refuse l'accès aux opérations d'API spécifiées dans les politiques si l'utilisateur tente d'appeler une opération d'API sans authentification MFA valide. L'opération est également refusée si l'horodatage de la demande pour l'opération d'API se situe en dehors de la plage autorisée spécifiée dans la politique. 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.

Politiques IAM avec des conditions MFA

Les politiques avec des conditions MFA peuvent être attachées à ce qui suit :

• Un utilisateur ou un groupe IAM

• Une ressource telle qu'un compartiment Amazon S3, une file d'attente Amazon SQS ou une rubrique Amazon SNS

• La politique d'approbation d'un rôle IAM qui peut être endossée par un utilisateur

Vous pouvez utiliser une condition MFA d'une politique pour vérifier les propriétés suivantes :

• Existence : pour vérifier simplement que l'utilisateur s'est authentifié par MFA, vérifiez que la clé aws:MultiFactorAuthPresent est 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 voulez octroyer l'accès uniquement dans un délai spécifié après l'authentification MFA, utilisez un type de condition numérique pour comparer l'âge de la clé aws:MultiFactorAuthAge à une valeur (par exemple 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 politique d'approbation d'un rôle IAM incluant une condition MFA pour tester l'existence de l'authentification MFA. Avec cette politique, les utilisateurs Compte AWS spécifiés dans l'Principalélément (à ACCOUNT-B-ID remplacer par un Compte AWS identifiant valide) peuvent assumer le rôle auquel cette politique est attachée. Toutefois, ces utilisateurs peuvent endosser le rôle uniquement s'ils se sont authentifiés à l'aide de l'authentification MFA.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "ACCOUNT-B-ID"},
    "Action": "sts:AssumeRole",
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }
}

Pour plus d'informations sur les types de conditions pour l'authentification MFA, consultez AWS clés contextuelles de condition globale, Opérateurs de condition numériques et Opérateur de condition pour vérifier l'existence de clés de condition

Choisir entre GetSessionToken et AssumeRole

AWS STS fournit deux opérations d'API qui permettent aux utilisateurs de transmettre des informations MFA : GetSessionToken et. AssumeRole L'opération d'API que l'utilisateur appelle pour obtenir des informations d'identification de sécurité temporaires dépend du scénario applicable parmi les suivants :

Utilisez GetSessionToken pour les scénarios suivants :

• Appelez les opérations d'API qui accèdent aux ressources de la même manière Compte AWS que l'utilisateur IAM qui fait la demande. Notez que les informations d'identification temporaires issues d'une GetSessionToken demande ne peuvent accéder aux opérations IAM et AWS STS API que 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 d'authentification MFA, vous pouvez vérifier l'authentification MFA dans les opérations d'API individuelles effectuées par les informations d'identification.

• Accédez aux ressources protégées par des politiques basées sur les ressources qui incluent une condition MFA.

Le but principal de l'opération GetSessionToken est d'authentifier l'utilisateur à l'aide de l'authentification MFA. Vous ne pouvez pas utiliser de stratégies pour contrôler les opérations d’authentification.

Utilisez AssumeRole pour les scénarios suivants :

• Appeler des opérations d'API qui accèdent à des ressources dans le même Compte AWS ou dans un compte différent. Les appels d'API peuvent inclure n'importe quel IAM ou AWS STS API. Notez que pour protéger l'accès vous devez appliquer l'authentification MFA au moment où l'utilisateur endosse le rôle. Les informations d'identification temporaires renvoyées par AssumeRole n'incluent pas d'informations d'authentification MFA dans ce contexte ; vous ne pouvez donc pas vérifier les opérations d'API individuelles pour l'authentification MFA. C'est pourquoi vous devez utiliser GetSessionToken pour restreindre l'accès aux ressources protégées par des politiques 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 relatifs à la protection MFA pour les opérations d'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 à l'API protégé par MFA avec des informations d'identification. Utilisateur racine d'un compte AWS

• Vous ne pouvez pas utiliser l'accès aux API protégé par MFA avec les clés de sécurité U2F.

• Les utilisateurs fédérés ne peuvent pas se voir attribuer de périphérique MFA à utiliser AWS avec les services. Ils ne peuvent donc pas AWS accéder aux ressources contrôlées par le MFA. (Voir le point suivant.)

• Les autres opérations d' AWS STS API qui renvoient des informations d'identification temporaires ne prennent pas en charge le MFA. Pour AssumeRoleWithWebIdentity etAssumeRoleWithSAML, l'utilisateur est authentifié par un fournisseur externe et AWS ne peut pas déterminer si ce fournisseur a besoin du 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 de l’utilisateur 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 principal 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 opérations d'API, ajoutez des conditions d'authentification MFA aux politiques. Une politique doit inclure la clé de condition aws:MultiFactorAuthPresent pour imposer l'utilisation de l'authentification MFA. Pour la délégation entre comptes, la politique d'approbation du rôle doit inclure la clé de condition.

• Lorsque vous autorisez une autre personne Compte AWS à accéder aux ressources de votre compte, la sécurité de vos ressources dépend de la configuration du compte approuvé (l'autre compte, pas le vôtre). Cela est vrai même lorsque vous imposez une authentification multi-facteur. Toutes les identités du compte approuvé ayant l'autorisation de créer des dispositifs MFA virtuels peut créer une demande de MFA pour satisfaire cette partie de la politique d'approbation de votre rôle. Avant d'autoriser les membres d'un autre compte à accéder à vos AWS ressources qui nécessitent une authentification à plusieurs facteurs, vous devez vous assurer que le propriétaire du compte de confiance suit les meilleures pratiques en matière de sécurité. Par exemple, le compte approuvé doit restreindre l'accès aux opérations d'API sensibles, telles que les opérations d'API de gestion de dispositif MFA, à des identités approuvées spécifiques.

• Si une politique 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 dispositif 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 d'un autre compte, mais uniquement si les utilisateurs sont authentifiés à l'aide d'un appareil MFA AWS . (Pour plus d'informations sur la délégation entre comptes, consultez Termes et concepts relatifs aux rôles.

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 Anaya qui dispose de l'autorisation administrateur. Elle souhaite accorder l'accès à l'utilisateur Richard au compte B (le compte approuvé), mais veut s'assurer que Richard s'est authentifié avec MFA avant d'endosser le rôle.

1. Dans le compte de confiance A, Anaya crée un rôle IAM nommé CrossAccountRole et définit le principal de la politique de confiance du rôle sur l'ID du compte B. La politique de confiance autorise l'action. AWS STS AssumeRole Anaya ajoute également une condition MFA à la politique d'approbation, comme dans l'exemple suivant.

   {
     "Version": "2012-10-17",
     "Statement": {
       "Effect": "Allow",
       "Principal": {"AWS": "ACCOUNT-B-ID"},
       "Action": "sts:AssumeRole",
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }
   }

2. Anaya ajoute une politique d'autorisations au rôle qui spécifie ce que le rôle est autorisé à faire. La politique d'autorisations d'un rôle avec protection MFA est identique à toutes les politiques d'autorisation de rôle. L'exemple suivant montre la politique qu'Anaya ajoute au rôle : elle permet à un utilisateur endossant le rôle d'exécuter toutes les actions Amazon DynamoDB sur la table Books dans le compte A. Cette politique permet également l'action dynamodb:ListTables, qui est nécessaire pour effectuer des actions dans la console.

   Note

   La politique d'autorisations n'inclut pas de condition MFA. Il est important de comprendre que l'authentification MFA sert uniquement à déterminer si un utilisateur peut endosser le rôle. Une fois que l'utilisateur endosse le rôle, aucune autre vérification MFA n'est effectuée.

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "TableActions",
               "Effect": "Allow",
               "Action": "dynamodb:*",
               "Resource": "arn:aws:dynamodb:*:ACCOUNT-A-ID:table/Books"
           },
           {
               "Sid": "ListTables",
               "Effect": "Allow",
               "Action": "dynamodb:ListTables",
               "Resource": "*"
           }
       ]
   }

3. Dans le compte sécurisé B, l'administrateur s'assure que l'utilisateur IAM Richard est configuré avec un appareil AWS MFA et qu'il connaît l'identifiant de l'appareil. L'ID du périphérique est le numéro de série s'il s'agit d'un dispositif MFA matériel, ou l'ARN du périphérique s'il s'agit d'un dispositif MFA virtuel.

4. Dans le compte B, l'administrateur attache la politique suivante à l'utilisateur Richard (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'Anaya a créé à l'étape 1. Notez que cette politique 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, Richard (ou une application qu'il exécute) appelle AssumeRole. L'appel d'API inclut l'ARN du rôle à endosser (arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole), l'ID du dispositif MFA et le TOTP actuel que Richard obtient de ce périphérique.

   Lorsque Richard appelleAssumeRole, il AWS détermine s'il possède des informations d'identification valides, y compris l'exigence du MFA. Le cas échéant, Richard réussit à endosser le rôle et peut exécuter n'importe quelle action DynamoDB sur 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 Appels AssumeRole avec authentification MFA.

Scénario : protection MFA pour l'accès aux opérations d'API du compte actuel

Dans ce scénario, vous devez vous assurer qu'un utilisateur Compte AWS peut accéder aux opérations d'API sensibles uniquement lorsqu'il est authentifié à l'aide d'un dispositif 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 politique qui autorise ces actions Amazon EC2 sensibles.

Dans ce scénario, l'un des utilisateurs approuvé s'appelle Sofía. L'utilisatrice Anaya est administratrice du compte A.

1. Anaya s'assure que Sofía est configurée avec un appareil AWS MFA et que Sofía connaît l'identifiant de l'appareil. L'ID du périphérique est le numéro de série s'il s'agit d'un dispositif MFA matériel, ou l'ARN du périphérique s'il s'agit d'un dispositif MFA virtuel.

2. Anaya crée un groupe appelé EC2-Admins et ajoute l'utilisatrice Sofía au groupe.

3. Anaya attache la politique suivante au groupe EC2-Admins. Cette politique 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.

   {
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Action": [
         "ec2:StopInstances",
         "ec2:TerminateInstances"
       ],
       "Resource": ["*"],
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }]
   }

4. Note

   Pour que cette politique prenne effet, les utilisateurs doivent d'abord se déconnecter et se connecter à nouveau.

   Si l'utilisatrice Sofía a besoin d'arrêter ou de résilier une instance Amazon EC2, elle (ou une application qu'elle exécute) appelle GetSessionToken. Cette opération d'API transmet l'ID du dispositif MFA et le TOTP actuel que Sofía obtient de son périphérique.

5. L'utilisatrice Sofía (ou une application qu'elle utilise) utilise les informations d'identification temporaires fournies par GetSessionToken pour appeler l'action StopInstances ou TerminateInstances Amazon EC2.

   Pour obtenir un exemple d'un programme qui appelle GetSessionToken, consultez Appels GetSessionToken avec authentification MFA ci-après dans ce document.

Scénario : protection MFA des ressources disposant de politiques basées sur les ressources

Dans ce scénario, vous êtes le propriétaire d'un compartiment S3, d'une file d'attente SQS ou d'une rubrique SNS. Vous devez vous assurer que tous les Compte AWS utilisateurs accédant à la ressource sont authentifiés par un dispositif MFA AWS .

Ce scénario illustre un processus permettant de fournir une protection MFA entre comptes sans nécessiter que les utilisateurs endossent d'abord un rôle. Dans ce cas, l'utilisateur peut accéder à la ressource s'il répond à trois conditions : l'utilisateur doit être authentifié par l'authentification MFA, être en mesure d'obtenir des informations d'identification temporaires de GetSessionToken et disposer d'un compte approuvé par la politique de 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 appartenant à plusieurs entités différentes Comptes AWS, mais uniquement s'ils sont authentifiés à l'aide de la MFA.

Dans ce scénario, l'utilisatrice Anaya est une administratrice du compte A. L'utilisateur Nikhil est un utilisateur IAM du compte C.

1. Dans le compte A, Anaya crée un compartiment appelé Account-A-bucket.

2. Anaya ajoute la politique de compartiment au compartiment. La politique autorise n'importe quel utilisateur du compte A, du compte B ou du compte C à exécuter les actions PutObject et DeleteObject Amazon S3 dans le compartiment. La politique inclut une condition MFA.

   {
     "Version": "2012-10-17",
     "Statement": [{
       "Effect": "Allow",
       "Principal": {"AWS": [
         "ACCOUNT-A-ID",
         "ACCOUNT-B-ID",
         "ACCOUNT-C-ID"
       ]},
       "Action": [
         "s3:PutObject",
         "s3:DeleteObject"
       ],
       "Resource": ["arn:aws:s3:::ACCOUNT-A-BUCKET-NAME/*"],
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }]
   }

   Note

   Amazon S3 fournit une fonction de suppression MFA (MFA Delete) pour l'accès au compte racine (uniquement). Vous pouvez activer la fonction de suppression MFA d'Amazon S3 lorsque vous définissez l'état de la gestion des versions du compartiment. La fonction de suppression MFA d'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 des autorisations nécessaires pour supprimer un compartiment ne peut pas le faire si la fonction de suppression MFA Amazon S3 est activée. Pour plus d'informations sur la fonction Supprimer MFA d'Amazon S3, consultez la section Supprimer MFA.

3. Dans le compte C, un administrateur vérifie que l'utilisateur Nikhil est configuré avec un dispositif MFA AWS et qu'il connaît l'ID du dispositif. L'ID du périphérique est le numéro de série s'il s'agit d'un dispositif MFA matériel, ou l'ARN du périphérique s'il s'agit d'un dispositif MFA virtuel.

4. Dans le compte C, Nikhil (ou une application qu'il exécute) appelle GetSessionToken. L'appel inclut l'ID ou l'ARN du dispositif MFA et le TOTP actuel que Nikhil obtient de ce périphérique.

5. Nikhil (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 télécharger un fichier dans Account-A-bucket.

   Pour obtenir un exemple d'un programme qui appelle GetSessionToken, consultez Appels GetSessionToken avec authentification MFA ci-après dans ce document.

   Note

   Les informations d'identification temporaires renvoyées par AssumeRole ne fonctionnent pas dans ce cas. Bien que l'utilisateur puisse fournir les informations MFA lui permettant d'endosser un rôle, les informations d'identification temporaires renvoyées par AssumeRole n'incluent par les informations MFA. Ces informations sont requises pour satisfaire la condition MFA de la politique.