Scelta di un authorizer per API Gateway

Uso di AWS Security per sviluppatori

Rahul Singh

Technical Product Manager

Controlli prima che il codice giri

Una chiamata passa dall'authorizer di API Gateway prima di raggiungere il tuo codice; se rifiutata, riceve un 401.

Passa: la richiesta raggiunge il tuo codice

Non passa: 401 Unauthorized, il tuo codice non parte mai

Chi fa il controllo

Tre authorizer tra cui scegliere

IAM auth (AWS_IAM): AWS verifica una firma

Una pila verticale su un asse da «controlla AWS» a «controlli tu». Solo la prima scheda è compilata: IAM auth, dove AWS verifica una firma.

Chi fa il controllo

Tre authorizer tra cui scegliere

IAM auth (AWS_IAM): AWS verifica una firma
Cognito authorizer (COGNITO_USER_POOLS): AWS verifica un token
- Firma, iss, aud, exp

La stessa pila verticale con due schede: IAM auth, dove AWS verifica una firma, e un authorizer Cognito, dove AWS verifica un token.

Chi fa il controllo

Tre authorizer tra cui scegliere

IAM auth (AWS_IAM): AWS verifica una firma
Cognito authorizer (COGNITO_USER_POOLS): AWS verifica un token
- Firma, iss, aud, exp
Lambda authorizer: la tua funzione restituisce allow o deny
- Per token diversi da Cognito

Tre authorizer ordinati da «controlla AWS» a «controlli tu»: IAM auth (firma verificata da AWS), Cognito authorizer (AWS verifica un token) e Lambda authorizer (scrivi tu il controllo).

Abbina la porta a chi chiama

Decide chi chiama

Servizio interno: ha già credenziali AWS

La prima di tre righe chiamante→authorizer: un servizio interno associato a IAM auth.

Abbina la porta a chi chiama

Decide chi chiama

Servizio interno: ha già credenziali AWS
Utente dell'app: porta un token Cognito

Due delle tre righe chiamante→authorizer: un servizio interno associato a IAM auth e un utente dell'app a un authorizer Cognito.

Abbina la porta a chi chiama

Decide chi chiama

Servizio interno: ha già credenziali AWS
Utente dell'app: porta un token Cognito
App partner: usa la propria logica di autorizzazione

Tre chiamanti mappati all'authorizer adeguato: servizio interno→IAM auth, utente app→authorizer Cognito, app partner→Lambda authorizer.

Occhio al tipo di API

REST API

Tutti e tre gli authorizer, più resource policies
API key, throttling per client, convalida richieste, WAF

Scheda di confronto per una REST API, con spunta su IAM auth, authorizer Cognito, Lambda authorizer e resource policy. La scheda HTTP API accanto non è ancora compilata.

Occhio al tipo di API

REST API

Tutti e tre gli authorizer, più resource policies
API key, throttling per client, convalida richieste, WAF

HTTP API

JWT authorizer, qualsiasi issuer OIDC
Niente resource policies; più economica e veloce

Due schede che confrontano gli authorizer supportati: una REST API aggiunge resource policies, mentre una HTTP API sostituisce l'authorizer Cognito con un JWT authorizer e non ha resource policies.

L'authorizer se lo ricorda

Cache per risparmiare tempo

Prima chiamata: l'authorizer gira
Chiamate successive: si legge la risposta in cache

La prima chiamata esegue l'authorizer e scrive un allow in cache con TTL; una chiamata successiva legge l'allow dalla cache senza rieseguire l'authorizer.

L'authorizer se lo ricorda

Cache per risparmiare tempo

Prima chiamata: l'authorizer gira
Chiamate successive: si legge la risposta in cache

TTL della cache

authorizerResultTtlInSeconds: 300s default, 3600s max
Zero disattiva la cache

La prima chiamata esegue l'authorizer e scrive un allow in cache con TTL; una chiamata successiva legge l'allow dalla cache senza rieseguire l'authorizer.

Un allow in cache può superare il suo permesso

Una timeline a due corsie. La corsia «permesso» passa da valido a revocato al punto di revoca, mentre sotto la corsia «allow in cache» mostra ancora allow oltre quel punto; la finestra dopo la revoca è evidenziata.

Nel momento della revoca

Permesso: revocato subito
Allow in cache: continua a concedere

Un allow in cache può superare il suo permesso

Stessa timeline: la finestra tra revoca e scadenza TTL è evidenziata e segnata come «ancora consentito», perché il permesso è revocato ma l'allow in cache mantiene l'accesso.

La finestra in mezzo

Permesso revocato, cache non aggiornata
Accesso finché il TTL non scade

Un allow in cache può superare il suo permesso

Stessa timeline con una freccia sulla finestra evidenziata: un TTL più breve anticipa la scadenza e riduce l'intervallo in cui un permesso revocato concede ancora accesso.

Controlla quella finestra

TTL breve quando serve revocare in fretta
TTL 0 sulle rotte più sensibili

Un chiamante aggira la porta d'ingresso

Un terzo all'interno del tuo account

Assume un ruolo che hai creato
Tu gli fornisci l'ARN del ruolo

Un fornitore di monitoraggio tra due riquadri cliente sopra e il tuo ruolo sotto. Il tuo riquadro passa l'ARN del ruolo al fornitore, che assume il tuo ruolo. Il secondo cliente è in grigio e non ancora nel racconto.

Un chiamante aggira la porta d'ingresso

Un terzo all'interno del tuo account

Assume un ruolo che hai creato
Tu gli fornisci l'ARN del ruolo

L'ARN del ruolo non è un segreto

Il problema del «deputy confuso»

Il secondo riquadro cliente ora è attivo in rosso e consegna il tuo ARN di ruolo come se fosse il suo. Due frecce vanno dal fornitore di monitoraggio al tuo ruolo, una per cliente, indistinguibili.

Un chiamante aggira la porta d'ingresso

Un terzo all'interno del tuo account

Assume un ruolo che hai creato
Tu gli fornisci l'ARN del ruolo

L'ARN del ruolo non è un segreto

Il problema del «deputy confuso»

La soluzione: sts:ExternalId

Il fornitore ne genera uno per cliente
La tua trust policy richiede la corrispondenza

Il tuo ruolo ora richiede che l'external ID sia uguale a 12345. La chiamata con 12345 arriva al ruolo; quella con 99999 è bloccata da una croce rossa prima di arrivare.

Esercitiamoci!

Uso di AWS Security per sviluppatori