Comment les stratégies de ressources API Gateway affectent le flux de travail d'autorisation

Lorsque API Gateway évalue la stratégie de ressources attachée à votre API, le résultat est affecté par le type d'authentification que vous avez défini pour l'API, comme illustré dans les diagrammes présentés dans les sections suivantes.

Stratégie de ressources API Gateway uniquement

Dans ce flux de travail, une stratégie de ressources API Gateway est attachée à l'API, mais aucun type d'authentification n'est défini pour l'API. L'évaluation de la stratégie consiste à obtenir une autorisation explicite en fonction des critères entrants de l'appelant. Un refus implicite ou explicite entraîne le refus de l'appelant.

Voici un exemple d'une telle stratégie de ressources.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": "arn:aws:execute-api:region:account-id:api-id/",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": ["192.0.2.0/24", "198.51.100.0/24" ]
                }
            }
        }
    ]
}

Mécanisme d'autorisation et stratégie de ressources Lambda

Dans ce flux de travail, un mécanisme d'autorisation Lambda est configuré pour l'API en plus d'une stratégie de ressources. La stratégie de ressources est évaluée en deux phases. Avant d'appeler le mécanisme d'autorisation Lambda, API Gateway évalue la stratégie et vérifie tout refus explicite. S'il en trouve, l'accès sera immédiatement refusé à l'utilisateur. Sinon, le mécanisme d'autorisation Lambda est appelé et renvoie un document de stratégie évalué avec la stratégie de ressources. Le résultat est déterminé sur la base du tableau A.

Dans l'exemple de stratégie de ressources suivant, les appels sont autorisés uniquement à partir du point de terminaison de VPC dont l'ID est vpce-1a2b3c4d. Pendant l'évaluation d'authentification préalable, seuls les appels provenant du point de terminaison de VPC indiqué dans l'exemple peuvent continuer et évaluer le mécanisme d'autorisation Lambda. Tous les appels restants sont bloqués.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": [
                "arn:aws:execute-api:region:account-id:api-id/"
            ],
            "Condition" : {
                "StringNotEquals": {
                    "aws:SourceVpce": "vpce-1a2b3c4d"
                }
            }
        }
    ]
}

Stratégie de ressources et d'authentification IAM

Dans ce flux de travail, vous configurez l'authentification IAM pour l'API en plus d'une stratégie de ressources. Une fois que vous avez authentifié l'utilisateur auprès du service IAM, l'API évalue à la fois les stratégies attachées à l'utilisateur et la stratégie de ressources. Le résultat varie selon que l'appelant est le même que le propriétaire de l'API Compte AWS ou qu'il est distinct Compte AWS de celui qui l'appelle.

Si l'appelant et le propriétaire de l'API relèvent de comptes distincts, les politiques IAM et la stratégie de ressources autorisent toutes deux explicitement l'appelant à continuer. Pour plus d'informations, consultez le tableau B.

Cependant, si l'appelant et le propriétaire de l'API relèvent du même Compte AWS, les politiques utilisateur IAM ou la stratégie de ressources doivent explicitement autoriser l'appelant à continuer. Pour plus d'informations, consultez le tableau A.

Voici un exemple de stratégie de ressources entre comptes. À supposer que la politique IAM contient un effet Allow (Autoriser), cette stratégie de ressources autorise uniquement les appels du VPC dont l'ID est vpc-2f09a348. Pour plus d'informations, consultez le tableau B.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": [
                "arn:aws:execute-api:region:account-id:api-id/"
            ],
            "Condition" : {
                "StringEquals": {
                    "aws:SourceVpc": "vpc-2f09a348"
                    }
            }
        }
    ]
}

Stratégie de ressources et d'authentification Amazon Cognito

Dans ce flux de travail, un groupe d'utilisateurs Amazon Cognito est configuré pour l'API en plus d'une stratégie de ressources. API Gateway tente d'abord d'authentifier l'appelant via Amazon Cognito. Ceci est généralement effectué via un jeton JWT fourni par l'appelant. Si l'authentification est réussie, la stratégie de ressources est évaluée de façon indépendante, et une autorisation explicite est requise. Un refus ou « ni autoriser ni refuser » entraîne un refus. Voici un exemple de stratégie de ressources pouvant être utilisée avec des groupes d'utilisateurs Amazon Cognito.

Voici un exemple de stratégie de ressources autorisant les appels uniquement à partir des adresses IP source spécifiées, en supposant que le jeton d'authentification Amazon Cognito contienne une autorisation. Pour plus d'informations, consultez le tableau B.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "execute-api:Invoke",
            "Resource": "arn:aws:execute-api:region:account-id:api-id/",
            "Condition": {
                "IpAddress": {
                    "aws:SourceIp": ["192.0.2.0/24", "198.51.100.0/24" ]
                }
            }
        }
    ]
}

Tableaux de résultat des évaluations de stratégies

Le tableau A répertorie le comportement qui en résulte lorsque l'accès à une API API Gateway est contrôlé par une politique IAM ou un autorisateur Lambda et une politique de ressources API Gateway, qui sont toutes deux identiques. Compte AWS

Tableau A : le compte A appelle une API appartenant au compte A
Politique IAM (ou autorisateur Lambda)	Stratégie de ressources API Gateway	Comportement obtenu
Autorisation	Autorisation	Autorisation
Autorisation	Ni autorisation ni refus	Autorisation
Autorisation	Refuser	Refus explicite
Ni autorisation ni refus	Autorisation	Autorisation
Ni autorisation ni refus	Ni autorisation ni refus	Refus implicite
Ni autorisation ni refus	Refuser	Refus explicite
Refuser	Autorisation	Refus explicite
Refuser	Ni autorisation ni refus	Refus explicite
Refuser	Refuser	Refus explicite

Le tableau B répertorie le comportement qui en résulte lorsque l'accès à une API API Gateway est contrôlé par une politique IAM ou un autorisateur de groupes d'utilisateurs Amazon Cognito et par une politique de ressources API Gateway, qui sont différentes. Comptes AWS Si l'un des deux est silencieux (pas d'autorisation ni de refus), l'accès entre comptes est refusé. En effet, l'accès entre comptes nécessite que la politique de ressources et la politique IAM ou l'autorisateur de groupes d'utilisateurs Amazon Cognito accordent explicitement l'accès.

Tableau B : le compte B appelle une API appartenant au compte A
Politique IAM (ou autorisateur de groupes d'utilisateurs Amazon Cognito)	Stratégie de ressources API Gateway	Comportement obtenu
Autorisation	Autorisation	Autorisation
Autorisation	Ni autorisation ni refus	Refus implicite
Autorisation	Refuser	Refus explicite
Ni autorisation ni refus	Autorisation	Refus implicite
Ni autorisation ni refus	Ni autorisation ni refus	Refus implicite
Ni autorisation ni refus	Refuser	Refus explicite
Refuser	Autorisation	Refus explicite
Refuser	Ni autorisation ni refus	Refus explicite
Refuser	Refuser	Refus explicite