Alegerea unui autorizator API Gateway

Securitatea AWS pentru dezvoltatori

Rahul Singh

Technical Product Manager

Verificat înainte ca codul tău să ruleze

Un apelant trece prin autorizatorul API Gateway înainte să ajungă la codul tău, iar un apelant respins este blocat cu un 401.

Trece: cererea ajunge la codul tău

Eșuează: 401 neautorizat, codul tău nu rulează niciodată

Cine face verificarea

Trei autorizatori din care poți alege

IAM auth (AWS_IAM): AWS verifică o semnătură

O stivă verticală pe o axă care merge de la AWS, care face verificarea, până la tine, care o faci. Doar primul card este completat: IAM auth, unde AWS verifică o semnătură.

Cine face verificarea

Trei autorizatori din care poți alege

IAM auth (AWS_IAM): AWS verifică o semnătură
Autorizator Cognito (COGNITO_USER_POOLS): AWS verifică un token
- Semnătură, iss, aud, exp

Aceeași stivă verticală cu două carduri completate: IAM auth, unde AWS verifică o semnătură, și un autorizator Cognito, unde AWS verifică un token.

Cine face verificarea

Trei autorizatori din care poți alege

IAM auth (AWS_IAM): AWS verifică o semnătură
Autorizator Cognito (COGNITO_USER_POOLS): AWS verifică un token
- Semnătură, iss, aud, exp
Autorizator Lambda: funcția ta returnează allow sau deny
- Pentru token-uri care nu sunt Cognito

Trei autorizatori ordonați de la AWS, care face verificarea, până la tine, care o faci: IAM auth, unde AWS verifică o semnătură, un autorizator Cognito, unde AWS verifică un token, și un autorizator Lambda, unde tu scrii verificarea.

Potrivește ușa cu apelantul

Apelantul decide

Serviciu intern: deține deja credențiale AWS

Primul din trei rânduri apelant-autorizator: un serviciu intern asociat cu IAM auth.

Potrivește ușa cu apelantul

Apelantul decide

Serviciu intern: deține deja credențiale AWS
Utilizator al aplicației: poartă un token Cognito

Două din trei rânduri apelant-autorizator: un serviciu intern asociat cu IAM auth și un utilizator al aplicației asociat cu un autorizator Cognito.

Potrivește ușa cu apelantul

Apelantul decide

Serviciu intern: deține deja credențiale AWS
Utilizator al aplicației: poartă un token Cognito
Aplicație parteneră: vine cu propria logică de autorizare

Trei apelanți asociați cu autorizatorul de care au nevoie: un serviciu intern cu IAM auth, un utilizator al aplicației cu un autorizator Cognito și o aplicație parteneră cu un autorizator Lambda.

Ai grijă la tipul de API

REST API

Toți cei trei autorizatori, plus politici de resurse
Chei API, limitare per client, validarea cererilor, WAF

Un card de comparație pentru REST API, cu IAM auth, un autorizator Cognito user pool, un autorizator Lambda și o politică de resurse bifate. Cardul HTTP API de alături nu este încă completat.

Ai grijă la tipul de API

REST API

Toți cei trei autorizatori, plus politici de resurse
Chei API, limitare per client, validarea cererilor, WAF

HTTP API

Autorizator JWT, orice emitent OIDC
Fără politici de resurse; mai ieftin și mai rapid

Două carduri care compară ce autorizatori acceptă fiecare tip de API: un REST API adaugă politici de resurse, în timp ce un HTTP API înlocuiește autorizatorul Cognito cu unul JWT și nu are politici de resurse.

Autorizatorul își amintește

Stocat în cache pentru a economisi timp

Primul apel: autorizatorul rulează
Apelurile ulterioare: citesc răspunsul din cache

Primul apel rulează autorizatorul și scrie un allow într-un cache cu un time to live, iar un apel ulterior citește acel allow din cache fără a mai rula autorizatorul din nou.

Autorizatorul își amintește

Stocat în cache pentru a economisi timp

Primul apel: autorizatorul rulează
Apelurile ulterioare: citesc răspunsul din cache

TTL pentru cache

authorizerResultTtlInSeconds: implicit 300s, maxim 3600s
Zero dezactivează cache-ul

Primul apel rulează autorizatorul și scrie un allow într-un cache cu un time to live, iar un apel ulterior citește acel allow din cache fără a mai rula autorizatorul din nou.

Un allow din cache poate supraviețui permisiunii sale

O cronologie cu două benzi. Banda permisiunii trece de la valid la revocat în punctul de revocare, în timp ce banda allow din cache de dedesubt arată în continuare allow după acest punct, iar fereastra de după revocare este umbrită.

În momentul în care revoci

Permisiune: revocată imediat
Allow din cache: acordă în continuare

Un allow din cache poate supraviețui permisiunii sale

Aceeași cronologie cu două benzi, cu fereastra dintre punctul de revocare și expirarea TTL umbrită și marcată ca fiind încă permisă, unde permisiunea este revocată, dar allow-ul din cache continuă să acorde acces.

Fereastra dintre cele două

Permisiunea dispare, cache-ul nu este anunțat
Accesul durează până la expirarea TTL-ului

Un allow din cache poate supraviețui permisiunii sale

Aceeași cronologie cu două benzi, cu o săgeată peste fereastra umbrită care arată că un TTL mai scurt mută expirarea mai devreme și reduce intervalul în care o permisiune revocată încă acordă acces.

Controlează acea fereastră

TTL scurt când revocarea trebuie să fie rapidă
TTL 0 pe rutele cele mai sensibile

Un apelant sare peste ușa din față

O terță parte în interiorul contului tău

Preia un rol pe care l-ai creat
Îi predai ARN-ul rolului

Un furnizor de monitorizare se află între două casete de clienți deasupra și rolul tău dedesubt. Caseta ta predă ARN-ul rolului către furnizor, care preia rolul tău. A doua casetă de client este estompată și nu face încă parte din poveste.

Un apelant sare peste ușa din față

O terță parte în interiorul contului tău

Preia un rol pe care l-ai creat
Îi predai ARN-ul rolului

ARN-ul rolului nu este un secret

Problema confused deputy

A doua casetă de client este acum activă, în roșu, și predă ARN-ul rolului tău ca și cum ar fi al ei. Acum pornesc două săgeți de la furnizorul de monitorizare către rolul tău, câte un apel per client, iar nimic nu le deosebește.

Un apelant sare peste ușa din față

O terță parte în interiorul contului tău

Preia un rol pe care l-ai creat
Îi predai ARN-ul rolului

ARN-ul rolului nu este un secret

Problema confused deputy

Soluția: sts:ExternalId

Furnizorul generează unul pentru fiecare client
Politica ta de încredere impune potrivirea

Rolul tău poartă acum o cerință ca ID-ul extern să fie egal cu 12345. Apelul care conține 12345 ajunge la rol, iar apelul care conține 99999 este oprit de un X roșu înainte să ajungă.

Hai să exersăm!

Securitatea AWS pentru dezvoltatori