I microservizi vengono spesso distribuiti in subnet private all'interno di un Amazon Virtual Private Cloud (VPC), per garantirne l'isolamento e proteggerli dall'accesso diretto da Internet. Per configurare l'accesso esterno ai microservizi esistono due approcci diffusi:
- Private Link: una funzionalità di rete che, tramite interface endpoint, espone in modo sicuro le risorse private del VPC ad API Gateway senza renderle raggiungibili dalla rete pubblica. In questo modo il traffico resta all'interno della rete AWS.
- HTTP Integration (internet-facing): consente ad API Gateway di instradare le richieste verso endpoint HTTP pubblici, come un Application Load Balancer (ALB) internet-facing, rendendo i servizi raggiungibili da un endpoint pubblico.
In questo articolo ci concentriamo sulla messa in sicurezza del secondo approccio: un ALB internet-facing posto dietro un API Gateway. Affronteremo nello specifico il problema di impedire l'accesso diretto all'ALB pubblico, lasciando ai client autorizzati la possibilità di interagire con l'applicazione solo attraverso l'API Gateway.
Il problema
Quando un ALB internet-facing viene configurato dietro un API Gateway tramite HTTP integration, l'ALB resta esposto pubblicamente. Anche se i client autorizzati raggiungono l'applicazione passando per l'API Gateway, questa configurazione introduce un rischio di sicurezza rilevante: l'endpoint pubblico dell'ALB può essere contattato direttamente, aggirando le funzionalità di sicurezza dell'API Gateway.
L'assenza di restrizioni espone l'applicazione a diverse potenziali vulnerabilità. Per preservare la sicurezza e l'integrità dell'applicazione è quindi essenziale impedire l'accesso diretto all'ALB. Facendo transitare tutto il traffico dall'API Gateway si possono applicare controlli di sicurezza fondamentali come validazione delle richieste, throttling, autenticazione e autorizzazione. In assenza di queste protezioni, un attaccante può sfruttare vulnerabilità, eludere i meccanismi di autenticazione e saturare i servizi backend con un carico eccessivo, aprendo la strada a possibili attacchi denial-of-service (DoS).
AWS propone una soluzione basata su REST API Gateway e AWS Web Application Firewall (WAF) per bloccare le richieste prive di un header specifico, ma comporta complessità e costi aggiuntivi. Va detto che, nei casi d'uso che richiedono misure di sicurezza avanzate come la protezione da SQL injection, cross-site scripting (XSS) o bot mitigation, AWS WAF resta uno strumento estremamente efficace.
In questo articolo presentiamo un'alternativa più semplice ed economica. Combinando header personalizzati e condizioni nelle regole dell'ALB si ottiene lo stesso livello di sicurezza senza ricorrere ad AWS WAF. Il metodo funziona senza problemi sia con REST sia con HTTP API Gateway e riduce sensibilmente l'overhead operativo.
**La soluzione proposta**
Questo approccio elimina la necessità di AWS WAF sfruttando le capacità di content-based routing dell'ALB. La soluzione prevede di:
- Aggiungere un header personalizzato con il relativo valore alle richieste HTTP nell'API Gateway.
- Configurare le regole dell'ALB per applicare la validazione dell'header. Solo le richieste con header e valore corretti soddisferanno le regole previste; tutte le altre ricadranno sulla regola predefinita.
- Impostare la regola predefinita dell'ALB in modo che restituisca un codice di errore HTTP, ad esempio 403 Forbidden.
Ecco una panoramica dell'architettura:
Flusso delle richieste HTTP.
**Implementazione passo per passo**
Passaggio 1: definire un header personalizzato in API Gateway
Per HTTP API Gateway, si utilizzano i parameter mapping per modificare le richieste inviate all'integrazione ALB.
- Aprire la console di API Gateway.
- Selezionare la propria HTTP API.
- Nella sezione "Integrations", accedere a "Manage Integrations".
- Creare un parameter mapping che includa l'header personalizzato e il relativo valore.
Configurazione del parameter mapping.
Se l'API Gateway è di tipo REST, seguire questo link per aggiungere un header HTTP personalizzato.
Passaggio 2: configurare le regole dell'ALB
- Aprire la configurazione dell'ALB nella console EC2.
- Per ogni regola del listener (a eccezione di quella predefinita):
- Aggiungere una condizione AND.
- Specificare "HTTP header" come tipo di condizione.
- Indicare il nome dell'header e il valore atteso.
3. Configurare la regola predefinita affinché restituisca una risposta di errore HTTP (ad esempio 403 Forbidden).
Condizioni e azioni delle regole ALB.
Per approfondire il content-based routing su ALB, è possibile consultare questo articolo del blog AWS.
Passaggio 3: testare la configurazione
- Inviare una richiesta direttamente all'ALB senza l'header personalizzato e verificare che venga attivata la regola predefinita dell'ALB con la risposta di errore prevista.
- Inviare una richiesta tramite l'API Gateway e verificare che venga correttamente instradata all'applicazione.
**Conclusioni**
Questa soluzione semplifica l'architettura eliminando la dipendenza da AWS WAF. Sfruttando le funzionalità native di content-based routing dell'ALB, l'approccio descritto consente di limitare in modo sicuro ed efficiente l'accesso diretto all'Application Load Balancer.
Per saperne di più o per valutare i nostri servizi, non esiti a contattarci. Può scriverci qui.