Exemples de stratégie basée sur l'identité d'Amazon API Gateway - Amazon API Gateway
Bonnes pratiques en matière de politiquesAutorisation accordée aux utilisateurs pour afficher leurs propres autorisationsAutorisations de lecture simpleCréer uniquement des mécanismes d'autorisation REQUEST ou JWTExiger que le point de terminaison execute-api par défaut soit désactivéAutoriser les utilisateurs à ne créer ou mettre à jour que des API REST privéesExiger que les routes d'API disposent d'une autorisationEmpêcher un utilisateur de créer ou de mettre à jour un lien VPCExemples de politiques d’utilisation des règles de routage

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 à l'aide de la AWS Management Console, de la AWS CLI ou des kits SDK AWS. Un administrateur IAM doit créer des stratégies 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 :

  • Démarrez avec les politiques gérées par AWS et évoluez vers les autorisations de moindre privilège : pour commencer à accorder des autorisations à vos utilisateurs et charges de travail, utilisez les politiques gérées par AWS qui accordent des autorisations dans de nombreux cas d’utilisation courants. Elles sont disponibles dans votre Compte AWS. Nous vous recommandons de réduire encore les autorisations en définissant des politiques AWS gérées par le client qui sont propres à 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.

  • Accordez 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 d’IAM pour appliquer des autorisations, consultez politiques et autorisations dans IAM dans le Guide de l’utilisateur IAM.

  • Utilisez 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 via un Service AWS spécifique, comme AWS CloudFormation. Pour plus d’informations, consultez Conditions pour éléments de politique JSON IAM dans le Guide de l’utilisateur IAM.

  • Utilisez l’Analyseur d’accès IAM pour valider vos politiques IAM afin de garantir des autorisations sécurisées et fonctionnelles : l’Analyseur d’accès IAM 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 politiques avec IAM Access Analyzer dans le Guide de l’utilisateur IAM.

  • Exigez l’authentification multifactorielle (MFA) : si vous avez un scénario qui nécessite des utilisateurs IAM ou un utilisateur racine dans votre Compte AWS, activez l’authentification multifactorielle pour une sécurité renforcée. Pour exiger la MFA lorsque des opérations d’API sont appelées, ajoutez des conditions MFA à vos politiques. Pour plus d’informations, consultez Sécurisation de l’accès aux API avec 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 stratégie inclut les autorisations nécessaires pour réaliser cette action sur la console ou par programmation à l'aide de l'AWS CLI ou de l'API 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 stratégie donne à un utilisateur l'autorisation d'obtenir des informations sur toutes les ressources d'une API HTTP ou WebSocket avec l'identifiant a123456789 dans la Région AWS 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.

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "apigateway:GET"
      ],
      "Resource": [
        "arn:aws:apigateway:::/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.

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

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

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

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

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.

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

Exemples de politiques d’utilisation des règles de routage

Les exemples de politiques suivants montrent comment utiliser les clés de condition RoutingRule pour contrôler la manière dont les utilisateurs peuvent acheminer le trafic de leurs noms de domaine personnalisés vers leurs API REST. Vous pouvez utiliser ces exemples pour créer des politiques détaillées concernant les règles de routage que les utilisateurs peuvent définir. Pour plus d’informations, consultez Règles de routage pour connecter des étapes d’API REST à un nom de domaine personnalisé.

Méthode pour empêcher un utilisateur de modifier la façon dont un nom de domaine personnalisé achemine une demande

Cette politique empêche un utilisateur de créer ou de mettre à jour BasePathMapping, ApiMapping ou RoutingRule. Toutes ces ressources peuvent modifier la manière dont un nom de domaine personnalisé achemine les demandes vers les API.

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAccessBasePathMappingsApiMappingsRoutingRules",
      "Effect": "Deny",
      "Action": "apigateway:*",
      "Resource": [
        "arn:aws:apigateway:us-east-1::/domainnames/example.com/basepathmappings/*",
        "arn:aws:apigateway:us-east-1::/domainnames/example.com/apimappings/*",
        "arn:aws:apigateway:us-east-1:111122223333:/domainnames/example.com/routingrules/*"
      ]
    }
  ]
}

Autorisation d’un utilisateur à mettre à jour certaines priorités d’une règle de routage

Cette politique autorise un utilisateur à modifier la priorité d’une règle de routage entre 1 001 et 2 000. Vous pouvez utiliser cette règle pour séparer vos règles de production des règles de priorité inférieure, puis autoriser les utilisateurs à modifier les règles de priorité inférieure sans affecter les règles de production.

JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "UpdatingRoutingRulePriorityBetween1001And2000",
      "Effect": "Allow",
      "Action": "apigateway:UpdateRoutingRule",
      "Resource": "arn:aws:apigateway:us-east-1:111122223333:/domainnames/example.com/routingrules/*",
      "Condition": {
        "NumericGreaterThanEquals": {
          "apigateway:Resource/Priority": 1001,
          "apigateway:Request/Priority": 1001
        },
       "NumericLessThanEquals": {
          "apigateway:Resource/Priority": 2000,
          "apigateway:Request/Priority": 2000
        } 
      }
    }
  ]
}

Autorisation d’un utilisateur à mettre à jour une règle de routage ou un mappage de chemin de base pour une certaine valeur de chemin de base

Cette politique autorise un utilisateur à mettre à jour un mappage de chemin de base uniquement pour les chemins de base commençant par orders, ou à mettre à jour une règle de routage correspondant à un chemin de base commençant par orders. Dans cette politique, un utilisateur peut mettre à jour un mappage de chemin de base ou une règle de routage pour orders/create ou orders123, mais pas pour payment/orders.

JSON
{
  "Version": "2012-10-17",
  "Statement": [
      {
        "Sid": "AllowUpdateRoutingRuleUnderPathOrders",
        "Effect": "Allow",
        "Action": "apigateway:UpdateRoutingRule",
        "Resource": "arn:aws:apigateway:us-east-1:111122223333:/domainnames/example.com/routingrules/*",
        "Condition": {
            "ForAllValues:StringLike": {
                "apigateway:Request/ConditionBasePaths": ["orders*"],
                "apigateway:Resource/ConditionBasePaths": ["orders*"]
            },
            "Null":{
                 "apigateway:Request/ConditionBasePaths":"false",
                 "apigateway:Resource/ConditionBasePaths":"false"             
          }
        }
      }
  ]
}

Autorisation d’un utilisateur à mettre à jour des valeurs spécifiques du mode de routage

Cette politique autorise un utilisateur à remplacer le mode de routage par API_MAPPING_ONLY et ROUTING_RULE_THEN_API_MAPPING uniquement. Pour plus d’informations sur le mode de routage, consultez Définition du mode de routage de votre nom de domaine personnalisé.

JSON
{
  "Version": "2012-10-17",
  "Statement": [
        {
           "Sid": "AllowUpdateRoutingModeToAnythingWithApiMapping",
           "Effect": "Allow",
           "Action": ["apigateway:PATCH"],
           "Resource": "arn:aws:apigateway:us-east-1::/domainnames/example.com",
              "Condition": {
               "StringLike": {
                   "apigateway:Request/RoutingMode":"*API_MAPPING*"
               }
           }
       }
    ]
}