Proteggere applicazioni e servizi usando un'istanza host dedicata per brokerare le richieste tra i client e l'applicazione o il servizio. Il broker convalida e sanifica le richieste e può fornire un ulteriore livello di sicurezza e limitare la superficie di attacco del sistema.
Contesto e problema
I servizi cloud espongono endpoint che consentono alle applicazioni client di chiamare le API. Il codice usato per implementare i trigger delle API o esegue diverse attività, tra cui l'autenticazione, l'autorizzazione, la convalida dei parametri e alcune o tutte le operazioni di elaborazione delle richieste. Il codice API è probabilmente in grado di accedere all'archiviazione e ad altri servizi per conto del client.
Se un utente malintenzionato compromette il sistema e ottiene l'accesso all'ambiente di hosting dell'applicazione, vengono esposti i meccanismi di sicurezza e l'accesso ai dati e ad altri servizi. Di conseguenza, l'utente malintenzionato può accedere senza restrizioni alle credenziali, alle chiavi di archiviazione, alle informazioni riservate e ad altri servizi.
Soluzione
Una soluzione a questo problema consiste nel separare il codice che implementa endpoint pubblici, dal codice che elabora le richieste e accede all'archiviazione. È possibile ottenere il disaccoppiamento usando una facciata o un'attività dedicata che interagisce con i client e quindi esegue la richiesta, ad esempio tramite un'interfaccia disaccoppiata, agli host o alle attività che gestiscono la richiesta. La figura illustra una panoramica generale di questo modello.
Il modello gatekeeper può essere usato per proteggere lo spazio di archiviazione oppure può essere usato come facciata più completa per proteggere tutte le funzioni dell'applicazione. Di seguito i fattori importanti:
- Convalida controllata. Gatekeeper convalida tutte le richieste e rifiuta le richieste che non soddisfano i requisiti di convalida.
- Rischio ed esposizione limitati. Gatekeeper non ha accesso alle credenziali o alle chiavi usate dall'host attendibile per accedere ai servizi e all'archiviazione. Se il gatekeeper è compromesso, l'autore dell'attacco non potrà accedere a tali credenziali o chiavi.
- Sicurezza appropriata. Gatekeeper viene eseguito in una modalità con privilegi limitati, mentre il resto dell'applicazione viene eseguito nella modalità di totale attendibilità richiesta per accedere alle risorse di archiviazione e ai servizi. Se il gatekeeper risulta compromesso, non può accedere direttamente ai servizi o ai dati dell'applicazione.
Questo modello agisce come un firewall in una tipica topografia di rete. Consente al gatekeeper di esaminare le richieste e di decidere se passare la richiesta all'host attendibile che esegue le attività necessarie. In genere la decisione richiede al gatekeeper di convalidare e purificare il contenuto della richiesta prima di passarlo all'host.
Considerazioni e problemi
Prima di decidere come implementare questo modello, considerare quanto segue:
- Assicurarsi che gli host attendibili espongono solo endpoint interni o protetti, usati solo dal gatekeeper. Gli host attendibili non devono esporre interfacce o endpoint esterni.
- Il gatekeeper deve essere eseguito in modalità con privilegi limitati, che in genere richiede l'esecuzione del gatekeeper e dell'host attendibile in servizi ospitati separati o macchine virtuali.
- Il gatekeeper non deve eseguire alcuna elaborazione correlata all'applicazione o ai servizi o ad accedere ai dati. La sua funzione è esclusivamente quella di convalidare e purificare le richieste. Gli host attendibili potrebbero dover eseguire una convalida aggiuntiva delle richieste, ma il gatekeeper deve eseguire la convalida principale.
- Usare un canale di comunicazione sicuro (HTTPS, SSL o TLS) tra il gatekeeper e gli host o le attività attendibili, laddove possibile. Alcuni ambienti di hosting non supportano il protocollo HTTPS o gli endpoint interni.
- L'aggiunta del livello aggiuntivo per implementare il modello gatekeeper influirà probabilmente sulle prestazioni a causa dell'elaborazione aggiuntiva e della comunicazione di rete necessaria.
- L'istanza del gatekeeper potrebbe rappresentare un singolo punto di guasto. Per ridurre al minimo l'impatto di un errore, valutare la possibilità di distribuire istanze ridondanti e di usare un meccanismo di scalabilità automatica per garantire la capacità di mantenere la disponibilità.
Quando usare questo modello
Questo modello è utile per le applicazioni che:
- gestire le informazioni riservate
- esporre i servizi che richiedono un elevato livello di protezione da attacchi dannosi
- eseguire operazioni cruciali che non possono essere interrotte.
- richiedere l'esecuzione della convalida delle richieste separatamente dalle attività principali o per centralizzare questa convalida per semplificare la manutenzione e l'amministrazione
Progettazione del carico di lavoro
Un architetto deve valutare il modo in cui il modello Gatekeeper può essere usato nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Ad esempio:
| Concetto fondamentale | Come questo modello supporta gli obiettivi di pilastro |
|---|---|
| Le decisioni di progettazione della sicurezza consentono di garantire la riservatezza, l'integrità e la disponibilità dei dati e dei sistemi del carico di lavoro. | L'aggiunta di un gateway nel flusso di richiesta consente di centralizzare funzionalità di sicurezza come web application firewall, protezione DDoS, rilevamento bot, manipolazione delle richieste, avvio dell'autenticazione e controlli di autorizzazione. - controlli di rete edizione Standard:06 - edizione Standard:10 Monitoraggio e rilevamento delle minacce |
| L'efficienza delle prestazioni consente al carico di lavoro di soddisfare in modo efficiente le richieste tramite ottimizzazioni in termini di scalabilità, dati, codice. | Questo modello è il modo in cui è possibile implementare la limitazione a livello di gateway anziché implementare i controlli della frequenza a livello di nodo. Il coordinamento dello stato della velocità tra tutti i nodi non è intrinsecamente efficiente. - PE:03 Selezione dei servizi |
Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.
Esempio
In uno scenario ospitato nel cloud, questo modello può essere implementato separando il ruolo di gatekeeper o la macchina virtuale, dai ruoli e dai servizi attendibili in un'applicazione. L'implementazione può usare un endpoint interno, una coda o un archivio come meccanismo di comunicazione intermedio. La figura illustra l'utilizzo di un endpoint interno.
Risorse correlate
Il Modello Passepartout può essere importante durante l'implementazione del modello Gatekeeper. Quando si comunica tra gatekeeper e ruoli attendibili, è consigliabile migliorare la sicurezza usando chiavi o token che limitano le autorizzazioni per l'accesso alle risorse. Il modello descrive l'uso di un token o di una chiave che fornisce ai client l'accesso limitato e diretto a una risorsa o a un servizio specifico.