View a markdown version of this page

Accès sécurisé aux API avec MFA - AWS Gestion de l’identité et des accès
Présentation deScénario : protection MFA pour la délégation entre comptesScénario : protection MFA pour l'accès aux opérations d'API du compte actuelScénario : protection MFA des ressources disposant de politiques basées sur les ressources

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Accès sécurisé aux API avec MFA

Avec les politiques IAM, vous pouvez spécifier quelles opérations d'API un utilisateur est autorisé à appeler. Vous pouvez renforcer la sécurité en exigeant des utilisateurs qu’ils s’authentifient à l’aide d’une authentification multifactorielle (MFA) avant de les autoriser à effectuer 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, par exemple, TerminateInstances et vous assurer que les utilisateurs ne peuvent effectuer cette action que s'ils s'authentifient auprès d'un appareil AWS MFA.

Présentation de

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

  1. L'administrateur configure un périphérique AWS MFA pour chaque utilisateur qui doit effectuer des demandes d'API nécessitant une authentification MFA. Pour de plus amples informations, veuillez consulter AWS Multi-factor authentification dans IAM.

  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é auprès d'un périphérique AWS MFA.

  3. L'utilisateur appelle l'une des opérations d' AWS STS API qui prennent en charge les paramètres MFA : AssumeRole ou GetSessionToken. 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 d'accès refusé (comme c'est le cas pour tout accès non autorisé). Lorsque les politiques d' MFA-protected API 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é n'est présente que lorsque l'utilisateur s'authentifie avec des informations d'identification à court terme. Long-term les informations d'identification, 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. Grâce à cette politique, les utilisateurs de la zone Compte AWS spécifiée dans l'Principalélément (à ACCOUNT-B-ID remplacer par un Compte AWS identifiant valide) peuvent assumer le rôle auquel cette stratégie est attachée. Toutefois, ces utilisateurs peuvent endosser le rôle uniquement s'ils se sont authentifiés à l'aide de l'authentification MFA.

JSON
{
  "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 de contexte 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 etAssumeRole. 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 peuvent accéder aux opérations IAM et AWS STS API 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 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.

Note

AWS CloudTrail les journaux contiendront des informations MFA lorsque l'utilisateur IAM se connecte avec MFA. Si l'utilisateur IAM assume un rôle IAM, il CloudTrail enregistre également les sessionContext attributs des actions effectuées mfaAuthenticated: true à l'aide du rôle assumé. Cependant, la CloudTrail journalisation est distincte de ce qu'IAM exige lorsque les appels d'API sont effectués avec les informations d'identification du rôle assumé. Pour en savoir plus, consultez Élément CloudTrail userIdentity.

Vous trouverez des détails sur l'implémentation de ces scénarios ultérieurement dans ce document.

Points importants concernant MFA-protected l'accès aux API

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 MFA-protected l'accès API avec des Utilisateur racine d'un compte AWS informations d'identification.

  • Vous ne pouvez pas utiliser MFA-protected l'accès API avec des clés de sécurité U2F.

  • Les utilisateurs fédérés ne peuvent pas se voir attribuer un appareil MFA à utiliser avec les AWS services. Ils ne peuvent donc pas accéder aux AWS ressources contrôlées par 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 requis le 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 utilisateur root) ne peuvent pas être utilisées avec MFA-protected l'accès à l'API 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 sécurisé (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 multifactorielle, vous devez vous assurer que le propriétaire du compte de confiance suit les meilleures pratiques 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 auprès d'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.

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 de compte 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.

    JSON
    {
  "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.

    JSON
    {
    "Version":"2012-10-17",
    "Statement": [
        {
            "Sid": "TableActions",
            "Effect": "Allow",
            "Action": "dynamodb:*",
            "Resource": "arn:aws:dynamodb:*:111122223333: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 périphérique AWS MFA et qu'il connaît l'ID de ce périphérique. 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.

    JSON
    {
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::111122223333: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 de votre réseau ne Compte AWS peut accéder à des opérations d'API sensibles que s'il est authentifié à l'aide d'un appareil 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.

    JSON
    {
  "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 utilisateurs Compte AWS qui accèdent à la ressource sont authentifiés par 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 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 par 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.

    JSON
    {
  "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. Amazon S3 MFA Delete ne peut pas être appliqué à un utilisateur IAM et est géré indépendamment de l'accès à MFA-protected l'API. 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.