Choisir un authorizer d'API Gateway

Sécurité AWS pour les développeurs

Rahul Singh

Technical Product Manager

Contrôlé avant l'exécution de votre code

Un appelant passe par l'authorizer d'API Gateway avant d'atteindre votre code ; un appelant rejeté reçoit un 401.

Succès : la requête atteint votre code

Échec : 401 Unauthorized, votre code ne s'exécute pas

Qui effectue le contrôle

Trois authorizers possibles

IAM auth (AWS_IAM) : AWS vérifie une signature

Une pile verticale sur un axe allant d'AWS qui fait le contrôle jusqu'à vous qui le faites. Seule la première carte est remplie : IAM auth, où AWS vérifie une signature.

Qui effectue le contrôle

Trois authorizers possibles

IAM auth (AWS_IAM) : AWS vérifie une signature
Cognito authorizer (COGNITO_USER_POOLS) : AWS valide un jeton
- Signature, iss, aud, exp

La même pile verticale avec deux cartes remplies : IAM auth, où AWS vérifie une signature, et un authorizer Cognito, où AWS valide un jeton.

Qui effectue le contrôle

Trois authorizers possibles

IAM auth (AWS_IAM) : AWS vérifie une signature
Cognito authorizer (COGNITO_USER_POOLS) : AWS valide un jeton
- Signature, iss, aud, exp
Lambda authorizer : votre fonction renvoie allow ou deny
- Pour des jetons non Cognito

Trois authorizers classés de AWS qui fait le contrôle à vous qui le faites : IAM auth où AWS vérifie une signature, un authorizer Cognito où AWS valide un jeton, et un Lambda authorizer où vous écrivez le contrôle.

Faire correspondre la porte à l'appelant

L'appelant décide

Service interne : possède déjà des identifiants AWS

La première de trois lignes appelant→authorizer : un service interne associé à IAM auth.

Faire correspondre la porte à l'appelant

L'appelant décide

Service interne : possède déjà des identifiants AWS
Utilisateur d'app : présente un jeton Cognito

Deux des trois lignes appelant→authorizer : un service interne associé à IAM auth, et un utilisateur d'app associé à un authorizer Cognito.

Faire correspondre la porte à l'appelant

L'appelant décide

Service interne : possède déjà des identifiants AWS
Utilisateur d'app : présente un jeton Cognito
App partenaire : utilise sa propre logique d'autorisation

Trois appelants associés à l'authorizer adapté : un service interne à IAM auth, un utilisateur d'app à un authorizer Cognito, et une app partenaire à un Lambda authorizer.

Attention au type d'API

REST API

Les trois authorizers, plus des stratégies de ressource
Clés d'API, limitation par client, validation des requêtes, WAF

Carte de comparaison pour une REST API, cochant IAM auth, un authorizer Cognito, un Lambda authorizer et une stratégie de ressource. La carte HTTP API à côté n'est pas encore remplie.

Attention au type d'API

REST API

Les trois authorizers, plus des stratégies de ressource
Clés d'API, limitation par client, validation des requêtes, WAF

HTTP API

Authorizer JWT, tout émetteur OIDC
Pas de stratégies de ressource ; moins cher et plus rapide

Deux cartes comparant les authorizers pris en charge par chaque type d'API : une REST API ajoute des stratégies de ressource, tandis qu'une HTTP API remplace l'authorizer Cognito par un authorizer JWT et n'a pas de stratégies de ressource.

L'authorizer se souvient

Mis en cache pour gagner du temps

Premier appel : l'authorizer s'exécute
Appels suivants : lecture de la réponse en cache

Le premier appel exécute l'authorizer et écrit un allow dans un cache avec une durée de vie ; un appel ultérieur lit ce allow du cache sans réexécuter l'authorizer.

L'authorizer se souvient

Mis en cache pour gagner du temps

Premier appel : l'authorizer s'exécute
Appels suivants : lecture de la réponse en cache

Durée de vie du cache (TTL)

authorizerResultTtlInSeconds : 300 s par défaut, 3600 s max
Zéro désactive le cache

Le premier appel exécute l'authorizer et écrit un allow dans un cache avec une durée de vie ; un appel ultérieur lit ce allow du cache sans réexécuter l'authorizer.

Un allow en cache peut survivre à sa permission

Une frise à deux voies. La voie « permission » passe de valide à révoquée au point de révocation, tandis que la voie « allow en cache » montre encore allow après ce point, avec la fenêtre après révocation ombrée.

Au moment de la révocation

Permission : révoquée immédiatement
Allow en cache : accorde encore l'accès

Un allow en cache peut survivre à sa permission

La même frise à deux voies avec la fenêtre entre la révocation et l'expiration du TTL ombrée et indiquée « encore autorisé », où la permission est révoquée mais l'allow en cache continue d'accorder l'accès.

La fenêtre intermédiaire

Permission disparue, cache non informé
Accès jusqu'à expiration du TTL

Un allow en cache peut survivre à sa permission

La même frise avec une flèche sur la fenêtre ombrée montrant qu'un TTL plus court avance l'expiration et réduit la durée où une permission révoquée permet encore l'accès.

Contrôlez cette fenêtre

TTL court si la révocation doit être rapide
TTL 0 sur les routes les plus sensibles

Un appelant évite la porte d'entrée

Un tiers à l'intérieur de votre compte

Endosse un rôle que vous avez créé
Vous transmettez l'ARN du rôle

Un fournisseur de monitoring est placé entre deux cases « client » au-dessus et votre rôle en dessous. Votre case transmet l'ARN de son rôle au fournisseur, qui endosse votre rôle. La seconde case client est grisée et pas encore dans l'histoire.

Un appelant évite la porte d'entrée

Un tiers à l'intérieur de votre compte

Endosse un rôle que vous avez créé
Vous transmettez l'ARN du rôle

L'ARN du rôle n'est pas un secret

Le problème du « deputy » confus

La seconde case client est maintenant active en rouge et transmet votre ARN de rôle comme s'il s'agissait du sien. Deux flèches vont du fournisseur de monitoring vers votre rôle, une par client, sans distinction.

Un appelant évite la porte d'entrée

Un tiers à l'intérieur de votre compte

Endosse un rôle que vous avez créé
Vous transmettez l'ARN du rôle

L'ARN du rôle n'est pas un secret

Le problème du « deputy » confus

La solution : sts:ExternalId

Le fournisseur en génère un par client
Votre stratégie d'approbation exige la correspondance

Votre rôle exige désormais que l'external ID soit égal à 12345. L'appel portant 12345 atteint le rôle, tandis que l'appel portant 99999 est bloqué par une croix rouge avant d'arriver.

Passons à la pratique !

Sécurité AWS pour les développeurs