APIAccès sécurisé avec MFA

L'administrateur configure un AWS MFA appareil pour chaque utilisateur qui doit effectuer des API demandes nécessitant une MFA authentification. Pour de plus amples informations, veuillez consulter AWS Authentification multifactorielle dans IAM.

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 AWS MFA appareil.

L'utilisateur appelle l'une des AWS STS API opérations prenant en charge les MFA paramètres : AssumeRoleou 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 à usage unique basé sur le temps (TOTP) généré par l'appareil. 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.

Dans le compte fiduciaire A, Anaya crée un IAM rôle nommé CrossAccountRole et définit le principal de la politique de confiance du rôle comme étant l'identifiant du compte B. La politique de confiance autorise l' AWS STS AssumeRoleaction. Anaya ajoute également une MFA condition à la politique de confiance, 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"}}
  }
}

Anaya ajoute une politique d'autorisations au rôle qui spécifie ce que le rôle est autorisé à faire. La politique d'autorisation pour un rôle protégé n'est pas différente de toute autre politique d'autorisation de rôle. MFA 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.

{
    "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": "*"
        }
    ]
}

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

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 le ARN rôle créé par Anaya à l'étape 1. Notez que cette politique ne contient aucune MFA condition.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["sts:AssumeRole"],
    "Resource": ["arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole"]
  }]
}

Dans le compte B, Richard (ou une application qu'il exécute) appelle AssumeRole. L'APIappel inclut le ARN rôle à assumer (arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole), l'identifiant de l'MFAappareil et le courant TOTP que Richard reçoit de son appareil.

Lorsque Richard appelleAssumeRole, AWS détermine s'il possède des informations d'identification valides, y compris l'exigence deMFA. 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.

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

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

Anaya attache la politique suivante au groupe EC2-Admins. Cette politique autorise les utilisateurs à appeler Amazon EC2 StopInstances et à effectuer TerminateInstances des actions uniquement si l'utilisateur s'est authentifié en utilisantMFA.

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

Si l'utilisateur Sofía doit arrêter ou mettre fin à une EC2 instance Amazon, elle (ou une application qu'elle exécute) appelleGetSessionToken. Cette API opération transmet l'identifiant de l'MFAappareil et le courant TOTP que Sofía reçoit de son appareil.

L'utilisateur Sofía (ou une application utilisée par Sofía) utilise les informations d'identification temporaires fournies par Amazon GetSessionToken pour appeler Amazon EC2 StopInstances ou TerminateInstances l'action.

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

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

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 MFA condition.

{
  "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"}}
  }]
}

Dans le compte C, un administrateur s'assure que l'utilisateur Nikhil est configuré avec un AWS MFA appareil et qu'il connaît l'identifiant de ce dernier. L'ID de l'appareil est le numéro de série s'il s'agit d'un MFA périphérique matériel, ou celui de l'appareil ARN s'il s'agit d'un MFA appareil virtuel.

Dans le compte C, Nikhil (ou une application qu'il exécute) appelle GetSessionToken. L'appel inclut l'identifiant ARN de l'MFAappareil et le courant TOTP que Nikhil reçoit de son appareil.

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.