Exemples de stratégie basée sur l'identité d'Amazon API Gateway

Par défaut, les utilisateurs et rôles IAM ne sont pas autorisés à créer ou modifier les ressources API Gateway. Ils ne peuvent pas non plus effectuer de tâches à AWS Management Console AWS CLI l'aide AWS des SDK. Un administrateur IAM doit créer des politiques IAM autorisant les utilisateurs et les rôles à exécuter des opérations d'API spécifiques sur les ressources spécifiées dont ils ont besoin. Il doit ensuite attacher ces stratégies aux utilisateurs ou aux groupes IAM ayant besoin de ces autorisations.

Pour plus d'informations sur la création de stratégies IAM, consultez la section Création de stratégies sous l'onglet JSON du Guide de l'utilisateur IAM. Pour plus d'informations sur les actions, les ressources et les conditions spécifiques à API Gateway, voir Actions, ressources et clés de condition pour Amazon API Gateway Management et Actions, ressources et clés de condition pour Amazon API Gateway Management V2.

Bonnes pratiques en matière de politiques

Les stratégies basées sur l'identité déterminent si une personne peut créer, consulter ou supprimer des ressources API Gateway dans votre compte. Ces actions peuvent entraîner des frais pour votre Compte AWS. Lorsque vous créez ou modifiez des politiques basées sur l’identité, suivez ces instructions et recommandations :

• Commencez AWS par les politiques gérées et passez aux autorisations du moindre privilège : pour commencer à accorder des autorisations à vos utilisateurs et à vos charges de travail, utilisez les politiques AWS gérées qui accordent des autorisations pour de nombreux cas d'utilisation courants. Ils sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire davantage les autorisations en définissant des politiques gérées par les AWS clients spécifiques à vos cas d'utilisation. Pour plus d’informations, consultez politiques gérées par AWS ou politiques gérées par AWS pour les activités professionnelles dans le Guide de l’utilisateur IAM.

• Accorder les autorisations de moindre privilège : lorsque vous définissez des autorisations avec des politiques IAM, accordez uniquement les autorisations nécessaires à l’exécution d’une seule tâche. Pour ce faire, vous définissez les actions qui peuvent être entreprises sur des ressources spécifiques dans des conditions spécifiques, également appelées autorisations de moindre privilège. Pour plus d’informations sur l’utilisation de IAM pour appliquer des autorisations, consultez politiques et autorisations dans IAM dans le Guide de l’utilisateur IAM.

• Utiliser des conditions dans les politiques IAM pour restreindre davantage l’accès : vous pouvez ajouter une condition à vos politiques afin de limiter l’accès aux actions et aux ressources. Par exemple, vous pouvez écrire une condition de politique pour spécifier que toutes les demandes doivent être envoyées via SSL. Vous pouvez également utiliser des conditions pour accorder l'accès aux actions de service si elles sont utilisées par le biais d'un service spécifique AWS service, tel que AWS CloudFormation. Pour plus d’informations, consultez Conditions pour éléments de politique JSON IAM dans le Guide de l’utilisateur IAM.

• Utilisez IAM Access Analyzer pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles : IAM Access Analyzer valide les politiques nouvelles et existantes de manière à ce que les politiques IAM respectent le langage de politique IAM (JSON) et les bonnes pratiques IAM. IAM Access Analyzer fournit plus de 100 vérifications de politiques et des recommandations exploitables pour vous aider à créer des politiques sécurisées et fonctionnelles. Pour plus d’informations, consultez Validation de politique IAM Access Analyzer dans le Guide de l’utilisateur IAM.

• Exiger l'authentification multifactorielle (MFA) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur root, activez l'authentification MFA pour une sécurité accrue. Compte AWS Pour exiger le MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez Configuration de l’accès aux API protégé par MFA dans le Guide de l’utilisateur IAM.

Pour plus d’informations sur les bonnes pratiques dans IAM, consultez Bonnes pratiques de sécurité dans IAM dans le Guide de l’utilisateur IAM.

Autorisation accordée aux utilisateurs pour afficher leurs propres autorisations

Cet exemple montre comment créer une politique qui permet aux utilisateurs IAM d’afficher les politiques en ligne et gérées attachées à leur identité d’utilisateur. Cette politique inclut les autorisations permettant d'effectuer cette action sur la console ou par programmation à l'aide de l'API AWS CLI or AWS .

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}

Autorisations de lecture simple

Cet exemple de politique autorise un utilisateur à obtenir des informations sur toutes les ressources d'un HTTP ou d'une WebSocket API dont l'identifiant est a123456789 in the AWS Region of us-east-1. La ressource arn:aws:apigateway:us-east-1::/apis/a123456789/* inclut toutes les sous-ressources de l'API, comme les mécanismes d'autorisation et les déploiements.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "apigateway:GET"
      ],
      "Resource": [
        "arn:aws:apigateway:us-east-1::/apis/a123456789/*"
      ]
    }
  ]
}

Créer uniquement des mécanismes d'autorisation REQUEST ou JWT

Cet exemple de stratégie permet à un utilisateur de ne créer des API qu'avec les mécanismes d'autorisation REQUEST ou JWT, y compris par le biais d'une importation. Dans la section Resource de la stratégie, arn:aws:apigateway:us-east-1::/apis/?????????? exige que les ressources comportent un maximum de 10 caractères, ce qui exclut les sous-ressources d'une API. Cet exemple utilise ForAllValues dans la section Condition car les utilisateurs peuvent créer plusieurs mécanismes d'autorisation à la fois en important une API.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "OnlyAllowSomeAuthorizerTypes",
      "Effect": "Allow",
      "Action": [
        "apigateway:PUT",
        "apigateway:POST",
        "apigateway:PATCH"
      ],
      "Resource": [
        "arn:aws:apigateway:us-east-1::/apis",
        "arn:aws:apigateway:us-east-1::/apis/??????????",
        "arn:aws:apigateway:us-east-1::/apis/*/authorizers",
        "arn:aws:apigateway:us-east-1::/apis/*/authorizers/*"
      ],
      "Condition": {
        "ForAllValues:StringEqualsIfExists": {
          "apigateway:Request/AuthorizerType": [
            "REQUEST",
            "JWT"
          ]
        }
      }
    }
  ]
}

Exiger que le point de terminaison execute-api par défaut soit désactivé

Cet exemple de stratégie permet aux utilisateurs de créer, de mettre à jour ou d'importer une API, avec l'exigence que DisableExecuteApiEndpoint soit true. Lorsque DisableExecuteApiEndpoint est true, les clients ne peuvent pas utiliser le point de terminaison execute-api par défaut pour appeler une API.

Nous utilisons la condition BoolIfExists pour gérer un appel visant à mettre à jour une API pour laquelle la clé de condition DisableExecuteApiEndpoint n'est pas renseignée. Lorsqu'un utilisateur tente de créer ou d'importer une API, la clé de condition DisableExecuteApiEndpoint est toujours renseignée.

Étant donné que la ressource apis/* capture également des sous-ressources telles que des mécanismes d'autorisation ou des méthodes, nous l'étendons explicitement aux seules API qui disposent d'une instruction Deny.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DisableExecuteApiEndpoint",
      "Effect": "Allow",
      "Action": [
        "apigateway:PATCH",
        "apigateway:POST",
        "apigateway:PUT"
      ],
      "Resource": [
        "arn:aws:apigateway:us-east-1::/apis",
        "arn:aws:apigateway:us-east-1::/apis/*"
      ],
      "Condition": {
        "BoolIfExists": {
          "apigateway:Request/DisableExecuteApiEndpoint": true
        }
      }
    },
    {
      "Sid": "ScopeDownToJustApis",
      "Effect": "Deny",
      "Action": [
        "apigateway:PATCH",
        "apigateway:POST",
        "apigateway:PUT"
      ],
      "Resource": [
        "arn:aws:apigateway:us-east-1::/apis/*/*"
      ]
    }
  ]
}

Autoriser les utilisateurs à ne créer ou mettre à jour que des API REST privées

Cet exemple de stratégie utilise des clés de condition pour exiger qu'un utilisateur ne crée que des API PRIVATE et pour empêcher les mises à jour susceptibles de remplacer une API de type PRIVATE par un API d’autre type, par exemple REGIONAL.

Nous utilisons ForAllValues pour exiger que chaque EndpointType ajouté à une API soit PRIVATE. Nous utilisons une clé de condition de ressource pour autoriser toute mise à jour d'une API à condition qu'elle soit de type PRIVATE. ForAllValues s’applique uniquement si une clé de condition est présente.

Nous utilisons ? pour établir une correspondance explicite avec les identifiants d'API afin d'éviter d'autoriser des ressources qui ne sont pas des API, telles que des mécanismes d'autorisation.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ScopePutToPrivateApis",
            "Effect": "Allow",
            "Action": [
                "apigateway:PUT"
            ],
            "Resource": [
                "arn:aws:apigateway:us-east-1::/restapis",
                "arn:aws:apigateway:us-east-1::/restapis/??????????"
            ],
            "Condition": {
                "ForAllValues:StringEquals": {
                    "apigateway:Resource/EndpointType": "PRIVATE"
                }
            }
        },
        {
            "Sid": "ScopeToPrivateApis",
            "Effect": "Allow",
            "Action": [
                "apigateway:DELETE",
                "apigateway:PATCH",
                "apigateway:POST"
            ],
            "Resource": [
                "arn:aws:apigateway:us-east-1::/restapis",
                "arn:aws:apigateway:us-east-1::/restapis/??????????"
            ],
            "Condition": {
                "ForAllValues:StringEquals": {
                    "apigateway:Request/EndpointType": "PRIVATE",
                    "apigateway:Resource/EndpointType": "PRIVATE"
                }
            }
        },
        {
            "Sid": "AllowResourcePolicyUpdates",
            "Effect": "Allow",
            "Action": [
                "apigateway:UpdateRestApiPolicy"
            ],
            "Resource": [
                "arn:aws:apigateway:us-east-1::/restapis/*"
            ]
        }
    ]
}

Exiger que les routes d'API disposent d'une autorisation

Cette stratégie entraîne l'échec des tentatives de création ou de mise à jour d'une route (y compris par le biais d'une importation) si celle-ci ne dispose d'aucune autorisation. ForAnyValue prend la valeur false en l'absence de la clé, par exemple lorsqu'une route n'est pas créée ou mise à jour. Nous utilisons ForAnyValue car plusieurs acheminements peuvent être créées par le biais d'une importation.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowUpdatesOnApisAndRoutes",
      "Effect": "Allow",
      "Action": [
        "apigateway:POST",
        "apigateway:PATCH",
        "apigateway:PUT"
      ],
      "Resource": [
        "arn:aws:apigateway:us-east-1::/apis",
        "arn:aws:apigateway:us-east-1::/apis/??????????",
        "arn:aws:apigateway:us-east-1::/apis/*/routes",
        "arn:aws:apigateway:us-east-1::/apis/*/routes/*"
      ]
    },
    {
      "Sid": "DenyUnauthorizedRoutes",
      "Effect": "Deny",
      "Action": [
        "apigateway:POST",
        "apigateway:PATCH",
        "apigateway:PUT"
      ],
      "Resource": [
        "arn:aws:apigateway:us-east-1::/apis",
        "arn:aws:apigateway:us-east-1::/apis/*"
      ],
      "Condition": {
        "ForAnyValue:StringEqualsIgnoreCase": {
          "apigateway:Request/RouteAuthorizationType": "NONE"
        }
      }
    }
  ]
}

Empêcher un utilisateur de créer ou de mettre à jour un lien VPC

Cette politique empêche un utilisateur de créer ou de mettre à jour un lien VPC Un lien VPC vous permet d'exposer des ressources dans un VPC Amazon à des clients en dehors du VPC.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyVPCLink",
      "Effect": "Deny",
      "Action": [
        "apigateway:POST",
        "apigateway:PUT",
        "apigateway:PATCH"
      ],
      "Resource": [
        "arn:aws:apigateway:us-east-1::/vpclinks",
        "arn:aws:apigateway:us-east-1::/vpclinks/*"
      ]
    }
  ]
}