Comment dois-je procéder pour limiter, à l'aide de rôles IAM, les appels d'API provenant d'adresses IP spécifiques et s'effectuant en direction de l'AWS Management Console ?

Date de la dernière mise à jour : 21/10/2019

Je souhaite limiter les appels d'API AWS provenant de certaines adresses. Comment dois-je procéder, à l'aide des rôles AWS Identity and Access Management (IAM), pour effectuer cette opération avec les appels d'API se produisant en direction de l'AWS Management Console ?

Courte description

Vous pouvez utiliser la clé de condition globale aws:SourceIp dans l'élément Condition d'une stratégie IAM pour limiter les appels d'API provenant d'adresses IP spécifiques. Cependant, l'accès aux services AWS qui effectuent des appels en votre nom, tels qu'AWS CloudFormation, sera refusé.

Imaginons que vous disposiez d'un rôle de service AWS permettant à AWS CloudFormation d'effectuer des appels en direction d'Amazon Elastic Compute Cloud (Amazon EC2), afin d'interrompre une instance. La demande est refusée car le service cible (Amazon EC2) détecte l'adresse IP du service appelant (AWS CloudFormation) et non celle de l'utilisateur d'origine. Vous ne pouvez pas transmettre au service cible, via un service appelant, l'adresse IP de l'utilisateur d'origine dans le but d'évaluer une stratégie IAM.

Remarque : il est recommandé de ne pas utiliser la clé de condition aws:SourceIp.

Résolution

Créez un rôle IAM profitant du même ensemble d'autorisations que la stratégie IAM associée à l'utilisateur IAM. L'utilisateur IAM dispose uniquement des autorisations nécessaires pour assumer le rôle sts:AssumeRole si la demande provient de l'adresse IP spécifiée. Ceci est dû au fait que le contrôle de restriction aws:SourceIp est exécuté lorsque l'utilisateur tente d'assumer le rôle. Lorsque l'utilisateur assume le rôle IAM, il acquiert les autorisations applicables à la stratégie IAM qui lui est associée. Dans la mesure où la stratégie IAM associée au rôle n'inclut pas la clé de condition aws:SourceIp, l'accès aux services AWS est autorisé.

Créez la stratégie IAM ci-dessous, puis associez-la à un utilisateur IAM disposant d'un accès par programmation. Celle-ci permet à ce même utilisateur d'assumer le rôle AssumeRole avec le nom Bob. Aucune autorisation supplémentaire n'est requise dans ce cas. Toutes les autres nécessaires sont acquises lorsque l'utilisateur IAM assume avec succès le rôle associé au nom Bob.

Remarque : remplacez Bob par votre nom de rôle IAM et EXAMPLEIAMACCOUNTID par votre identifiant de compte.

Exemple de stratégie utilisateur IAM

{
"Version": "2012-10-17",
"Statement": {
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::EXAMPLEIAMACCOUNTID:role/Bob"
}
}

Créez le rôle IAM Bob pour déléguer des autorisations à l'utilisateur IAM. Suivez les instructions de l'article Création d'un rôle IAM (console). Vous pouvez également utiliser l'interface en ligne de commande AWS (CLI AWS) ou l'API AWS.

Remarque : lorsque vous utilisez la console pour créer le rôle, modifiez la stratégie d'approbation du rôle, comme dans cet exemple se rapportant à la stratégie d'approbation Bob. À l'aide de l'interface en ligne de commande create-role ou de l'API CreateRole, vous pouvez, sous la forme d'une valeur dans le paramètre de document --assume-role-policy, faire référence au document applicable à la stratégie concernant les relations de confiance.

Stratégie de rôle Bob IAM : cette stratégie dispose des autorisations nécessaires pour effectuer des appels d'API sur les ressources du compte.

Stratégie d'approbation Bob IAM : cet exemple de stratégie d'approbation permet à l'utilisateur d'assumer le rôle si la demande provient de la plage d'adresses IP 103.15.250.0/24 ou 12.148.72.0/23.

Remarque : la demande doit provenir de la plage d'adresses IP 103.15.250.0/24 ou 12.148.72.0/23, sinon l'utilisateur IAM ne pourra pas assumer le rôle et effectuer des appels d'API.

Exemple de stratégie d'approbation de rôle IAM

Remarque : remplacez EXAMPLEIAMUSERNAME par votre nom d'utilisateur IAM.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::account-id:user/EXAMPLEIAMUSERNAME"
      },
      "Action": "sts:AssumeRole"
    },
    {
      "Effect": "Deny",
      "Principal": {
        "AWS": "arn:aws:iam::account-id:user/EXAMPLEIAMUSERNAME"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "103.15.250.0/24",
            "12.148.72.0/23"
          ]
        }
      }
    }
  ]
}

Remarque : cette méthode a une incidence sur les journaux CloudTrail, car les actions sont exécutées par le rôle IAM assumé par l'utilisateur, et non par l'utilisateur IAM. L'appel d'API assumeRole effectué par l'utilisateur IAM est consigné dans les journaux CloudTrail sous l'utilisateur IAM. Tous les autres appels d'API effectués par le rôle IAM sont consignés dans les journaux CloudTrail sous le nom du rôle.


Cet article vous a-t-il été utile ?

Cette page peut-elle être améliorée ?


Vous avez besoin d'aide ?