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

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 (vers la fin de cette rubrique).

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, l'authentification IAM est configurée pour l'API en plus d'une stratégie de ressources. Une fois l'utilisateur authentifié avec le service IAM, les stratégies attachées à l'utilisateur IAM en plus de la stratégie de ressources sont évaluées ensemble. Le résultat varie si l'appelant se trouve dans le même compte ou dans un autre compte AWS que le propriétaire de l'API.

Si l'appelant et le propriétaire de l'API sont dans des comptes distincts, les stratégies utilisateur IAM et la stratégie de ressources autorisent toutes deux explicitement l'appelant à continuer. (Voir le Tableau B à la fin de cette rubrique.) En revanche, si l'appelant et le propriétaire de l'API sont dans le même compte, soit les stratégies utilisateur, soit la stratégie de ressources doivent explicitement autoriser l'appelant à continuer. (Consultez le Tableau A ci-dessous.)

Voici un exemple de stratégie de ressources entre comptes. En supposant que la stratégie utilisateur IAM contienne une autorisation, cette stratégie de ressources autorise uniquement les appels à partir du VPC dont l'ID est vpc-2f09a348. (Voir le Tableau B à la fin de cette rubrique.)

{ "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 pools 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. (Voir le Tableau A vers la fin de cette rubrique.)

{ "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 indique le résultat du comportement lorsque l'accès à une API API Gateway est contrôlé par une stratégie IAM (ou un mécanisme d'autorisation des pools d'utilisateurs Lambda ou Amazon Cognito) et une stratégie de ressources API Gateway qui se trouvent toutes les deux dans le même compte AWS.

Tableau A : le compte A appelle une API appartenant au compte A
Stratégie utilisateur IAM (ou mécanisme d'autorisation des pools d'utilisateurs Lambda ou Amazon Cognito) 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 indique le résultat du comportement lorsque l'accès à une API API Gateway est contrôlé par une stratégie IAM (ou un mécanisme d'autorisation des pools d'utilisateurs Lambda ou Amazon Cognito) et une stratégie de ressources API Gateway qui se trouvent dans des comptes AWS différents. 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 stratégie de ressources et la stratégie IAM (ou un mécanisme d'autorisation des pools d'utilisateurs Lambda ou Amazon Cognito) accordent explicitement l'accès.

Tableau B : le compte B appelle une API appartenant au compte A
Stratégie utilisateur IAM (ou mécanisme d'autorisation des pools d'utilisateurs Lambda ou 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