Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Protezione dei carichi di lavoro con endpoint pubblici
Per i carichi di lavoro accessibili pubblicamente, AWS fornisce una serie di funzionalità e servizi che possono aiutare a mitigare determinati rischi. In questa sezione viene trattata l'autenticazione e l'autorizzazione degli utenti delle applicazioni e la protezione degli endpoint delle API.
Autenticazione e autorizzazione
L'autenticazione si riferisce all'identità mentre l'autorizzazione si riferisce alle operazioni. Usa l'autenticazione per controllare chi può richiamare una funzione Lambda, quindi usa l'autorizzazione per controllare cosa può fare. Per molte applicazioni, IAM è sufficiente per gestire entrambi i meccanismi di controllo.
Per le applicazioni con utenti esterni, come le applicazioni Web o per dispositivi mobili, è comune utilizzare JSON Web Tokens
Puoi implementare JWT con Amazon Cognito, un servizio di elenchi utenti in grado di gestire la registrazione, l'autenticazione, il ripristino dell'account e altre comuni operazioni di gestione degli account. Framework Amplify
Dato il ruolo fondamentale di sicurezza di un servizio di identity provider, è importante utilizzare strumenti professionali per salvaguardare l'applicazione. Non è consigliabile scrivere servizi propri per gestire l'autenticazione o l'autorizzazione. Qualsiasi vulnerabilità nelle librerie personalizzate potrebbe avere implicazioni significative per la sicurezza del carico di lavoro e dei relativi dati.
Protezione degli endpoint API
Per le applicazioni serverless, il modo preferito per servire pubblicamente un'applicazione di backend consiste nell'utilizzare Gateway Amazon API. Ciò può aiutarti a proteggere un'API da utenti malintenzionati o da picchi di traffico.
API Gateway offre due tipi di endpoint per gli sviluppatori serverless: REST API e API HTTP. Entrambi supportano l'autorizzazione tramite AWS Lambda IAM o Amazon Cognito. Quando si utilizza IAM o Amazon Cognito, le richieste in entrata vengono valutate e se mancano di un token richiesto o contengono un'autenticazione non valida, la richiesta viene rifiutata. Queste richieste non ti vengono addebitate e non vengono conteggiate ai fini delle quote di limitazione.
Le route API non autenticate sono accessibili da chiunque sulla rete Internet pubblica, quindi è consigliabile limitare l'uso di API non autenticate. Se devi utilizzare API non autenticate, è importante proteggerle dai rischi comuni, come gli attacchi denial-of-service (DoS). https://en.wikipedia.org/wiki/Denial-of-service_attack
In molti casi, la funzionalità fornita da un'API non autenticata può essere ottenuta con un approccio alternativo. Ad esempio, un'applicazione web potrebbe fornire un elenco dei negozi al dettaglio dei clienti da una tabella DynamoDB agli utenti che non hanno effettuato l'accesso. Questa richiesta potrebbe provenire da un'applicazione web frontend o da qualsiasi altra fonte che richiama l'endpoint URL. Questo diagramma mette a confronto tre soluzioni:
-
Questa API non autenticata può essere chiamata da chiunque su Internet. In un attacco denial of service, è possibile esaurire i limiti di limitazione delle API, la concorrenza Lambda o la capacità di lettura fornita da DynamoDB su una tabella sottostante.
-
Una CloudFront distribuzione davanti all'endpoint API con una configurazione time-to-live (TTL) appropriata assorbirebbe la maggior parte del traffico in un attacco DoS, senza modificare la soluzione sottostante per il recupero dei dati.
-
In alternativa, per i dati statici che cambiano raramente, la CloudFront distribuzione potrebbe fornire i «dati» contenuti in un bucket Amazon S3.