Configuration de l'accès aux API protégé par MFA - AWS Identity and Access Management
PrésentationScé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.

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 souhaitez peut-être restreindre une action destructive comme TerminateInstances et vous assurer que les utilisateurs ne peuvent exécuter cette action que s'ils s'authentifient avec un dispositif MFA AWS.

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 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 des appareils MFA pour les utilisateurs de AWS.

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

  3. L'utilisateur appelle l'une des opérations d'API AWS STS qui prend 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 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 il le fait pour tout accès non autorisé). Lorsque des politiques d'API protégées par l'authentification MFA ont été mises 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 de l'Compte AWS spécifié dans l'élément Principal (remplacez ACCOUNT-B-ID par un ID d'Compte AWS valide) peuvent endosser le rôle auquel cette politique est associé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 d'authentification 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 :

  • Appeler des opérations d'API qui accèdent à des ressources dans le même Compte AWS que l'utilisateur IAM qui effectue la demande. Notez que les informations d'identification temporaires d'une demande GetSessionToken peuvent accéder aux opérations d'API IAM et AWS STS uniquement si vous incluez des informations d'authentification 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 quelle API IAM ou AWS STS. 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 aux API protégé par MFA avec les 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 affecter un dispositif 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.)

  • Les autres opérations d'API AWS STS qui renvoient des 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 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 un autre Compte AWS à accéder aux ressources de votre compte, la sécurité de vos ressources dépend de la configuration du compte approuvé (c'est-à-dire, 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 ressources AWS qui nécessitent l'authentification multi-facteur, vous devez vérifier que le propriétaire du compte approuvé respecte les bonnes 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 dans un autre compte, mais uniquement si les utilisateurs sont authentifiés par un dispositif 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 d'approbation A, Anaya crée un rôle IAM appelé CrossAccountRole et définit le principal de la politique d'approbation du rôle sur l'ID de compte du compte B. La politique d'approbation accorde l'autorisation à 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 approuvé B, l'administrateur s'assure que l'utilisateur IAM Richard 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 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 appelle AssumeRole, AWS détermine s'il dispose d'informations d'identification valides, notamment l'exigence pour le 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 Compte AWS ne peut accéder aux opérations d'API sensibles que lorsqu'il est authentifié à l'aide d'un dispositif MFA AWS.

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 vérifie qu'un dispositif MFA AWS est configuré pour Sofía, et que Sofía 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.

  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 souhaitez vous assurer que tout utilisateur de votre Compte AWS qui accède à la ressource est authentifié 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 qui se trouvent dans plusieurs Comptes AWS distincts, mais uniquement si ces utilisateurs sont authentifiés avec 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.