Modello Gatekeeper

Proteggere applicazioni e servizi usando un componente dedicato per la gestione delle 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

Molti servizi cloud espongono endpoint che consentono alle applicazioni client di chiamare le API in Internet o in un'altra rete non attendibile. Il codice che implementa 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. È probabile che il codice DELL'API possa 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. Separare il codice usando un livello di facciata che interagisce con i client e instrada le richieste approvate tramite un endpoint interno, una coda o un broker ai componenti del carico di lavoro che gestiscono l'operazione aziendale. Il diagramma offre una panoramica generale di questo modello.

È possibile usare il modello Gatekeeper per proteggere lo spazio di archiviazione oppure usarlo come facciata più completa per proteggere tutte le funzioni dell'applicazione. I fattori importanti includono:

Convalida controllata: Gatekeeper convalida tutte le richieste e rifiuta le richieste che non soddisfano i requisiti di convalida.
Rischio e esposizione limitati: I rischi e l'esposizione sono ridotti perché il gatekeeper non accede alle credenziali o alle chiavi usate dall'host attendibile per accedere alle risorse di archiviazione e ai servizi. Se il gatekeeper diventa compromesso, gli utenti malintenzionati non possono accedere a queste credenziali o chiavi.
Sicurezza appropriata: Gatekeeper viene eseguito in modalità con privilegi limitati, mentre il resto dell'applicazione viene eseguito nella modalità di attendibilità completa necessaria 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. A differenza di un firewall tradizionale, consente al gatekeeper di esaminare in dettaglio le richieste e prendere una decisione guidata dall'applicazione su se passare la richiesta all'host attendibile che esegue le attività necessarie. Questa decisione richiede in genere al gatekeeper di convalidare e purificare il contenuto della richiesta prima di passarlo all'host attendibile. I gatekeeper possono autorizzare la richiesta, cercare contenuto di payload imprevisto o non valido, eseguire la limitazione della frequenza ed eseguire vari altri controlli.

Problemi e considerazioni

Quando si decide come implementare questo modello, tenere presente 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. In pratica, ospitare il gatekeeper e il back-end attendibile in limiti di calcolo separati e mantenere privati gli endpoint back-end.
Il gatekeeper non deve eseguire l'elaborazione correlata all'applicazione o ai servizi o ai dati di accesso. La sua funzione è esclusivamente per convalidare e sanificare 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, ad esempio HTTPS, Secure Sockets Layer (SSL) o TLS (Transport Layer Security) tra il gatekeeper e gli host o le attività attendibili, se possibile. Tuttavia, alcuni ambienti di hosting non supportano HTTPS sugli endpoint interni.
È probabile che l'aggiunta del livello aggiuntivo per implementare il modello Gatekeeper influisca sulle prestazioni a causa dell'elaborazione aggiuntiva e della comunicazione di rete necessaria.
Il gatekeeper può essere un singolo punto di guasto (SPoF). 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à e mantenere la disponibilità.

Quando usare questo modello

Usare questo modello quando:

Le informazioni riservate sono gestite.
Si espongono servizi che richiedono una protezione avanzata dal traffico dannoso.
Si eseguono operazioni cruciali che non possono tollerare l'esposizione diretta dei servizi back-end.
È necessario richiedere la convalida e la purificazione per essere separati dall'elaborazione aziendale principale.

Questo modello potrebbe non essere adatto quando:

È possibile soddisfare i requisiti di sicurezza e convalida tramite controlli della piattaforma predefiniti nel servizio back-end senza aggiungere un livello gatekeeper dedicato.
Aggiunta di hop di rete e la latenza di convalida violano requisiti di latenza end-to-end rigorosi.

Progettazione del carico di lavoro

Valutare come usare il modello Gatekeeper nella progettazione di un carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. La tabella seguente fornisce indicazioni su come questo modello supporta gli obiettivi di ogni pilastro.

Pilastro	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.	Un gatekeeper nel flusso di richiesta consente di centralizzare le funzionalità di sicurezza, ad esempio i web application firewall, la protezione DDoS, il rilevamento dei bot, la manipolazione delle richieste, l'avvio dell'autenticazione e i controlli di autorizzazione. - Controlli di rete SE:06 - SE:10 Monitoraggio e rilevamento delle minacce
l'efficienza delle prestazioni consente al carico di lavoro soddisfare in modo efficiente le richieste tramite ottimizzazioni di ridimensionamento, dati e codice.	È possibile usare questo modello per implementare la limitazione a livello di gatekeeper anziché implementare controlli di frequenza a livello di nodo. Il coordinamento dello stato della frequenza tra tutti i nodi non è intrinsecamente efficiente. - PE:03 Selezionare i servizi

Se questo modello introduce compromessi all'interno di un pilastro, considerarli contro gli obiettivi degli altri pilastri.

Example

Il modello Gatekeeper implementa in genere un percorso di richiesta a più livelli, in cui ogni livello ha una responsabilità specifica e un ambito di attendibilità limitato.

Scaricare un file di Visio di questa architettura.

In questa progettazione, gateway applicazione di Azure con Web application firewall di Azure è il gatekeeper esterno. Controlla il traffico con connessione Internet e applica i controlli di sicurezza prima che il traffico raggiunga il livello API. Gestione API di Azure è il gatekeeper interno. Applica controlli specifici dell'API e inoltra solo il traffico approvato ai back-end privati.

Ad esempio, Web application firewall di Azure può rilevare e bloccare i modelli di scripting SQL injection e cross-site, applicare regole di protocollo e dimensioni delle richieste e applicare il filtro basato su bot e IP prima che le richieste raggiungano Gestione API o back-end privati.

Quando si usa Gestione API nel livello interno, vengono applicati criteri alle richieste in ingresso e alle risposte in uscita nella pipeline del gateway. Per altre informazioni su come Gestione API elabora le richieste e le risposte, vedere Criteri in Gestione API. Per le opzioni dei criteri, ad esempio la convalida del token JSON Web (JWT), la limitazione della frequenza, la trasformazione dell'intestazione e il data shaping delle risposte, vedere Informazioni di riferimento sui criteri di Gestione API.

Usare le identità managed per le risorse Azure in modo coerente per l'autenticazione da servizio a servizio in questo percorso. Ad esempio, Gestione API può usare il autenticazione con criteri di identità gestiti per ottenere token Microsoft Entra per le chiamate back-end senza archiviare segreti.

Il back-end rimane privato. Ad esempio, il back-end può essere un'app Servizio app di Azure che usa un endpoint private, in modo che l'app possa essere accessibile privatamente.

Per i carichi di lavoro in contenitori, un'alternativa può sostituire gestione API più il percorso interno del servizio app con il calcolo in ingresso:

Servizio Azure Kubernetes (AKS), che offre maggiore controllo sulla scelta del controller in ingresso, sui criteri Kubernetes, sulla topologia di rete e sulle operazioni del cluster.
App contenitore di Azure, una piattaforma contenitore gestita serverless che fornisce funzionalità ingress e riduce la gestione dell'infrastruttura.

In queste alternative, l'ingresso può instradare in base all'host o al percorso, terminare TLS ed esporre servizi solo interni. Funzionalità specifiche, ad esempio i limiti delle richieste e le regole di autorizzazione o negazione, dipendono dall'implementazione in ingresso selezionata. In tutti i casi, mantenere i limiti del gatekeeper: applicare la convalida e l'imposizione dei criteri in ingresso e mantenere raggiungibili i servizi back-end solo tramite tale percorso gatekeeper.

Ogni livello in questo percorso genera log e metriche che è necessario centralizzare. Web application firewall di Azure i log di diagnostica registrano le regole corrispondenti e bloccate per ogni richiesta. Gestione API genera log del gateway che acquisisce la durata della richiesta, i codici di risposta e i risultati dei criteri. I servizi back-end generano dati di telemetria a livello di applicazione. Raccogliere questi log e metriche in Monitoraggio di Azure e indirizzarli a un'area di lavoro Log Analytics per l'esecuzione di query unificate. Standardizzare la correlazione delle richieste end-to-end generando o inoltrando un ID di correlazione al perimetro e propagandolo tramite Gestione API e servizi back-end ,ad esempio tramite intestazioni di richiesta e contesto di traccia distribuita, in modo che una singola transazione rimanga tracciabile in tutti i livelli. Usare Microsoft Defender per il cloud per visualizzare le raccomandazioni di sicurezza nei componenti gatekeeper. Configurare avvisi in caso di tassi di blocco anomali Web application firewall di Azure o picchi di errore di Gestione API per rilevare le minacce prima di raggiungere i back-end privati.

Passaggi successivi

Le indicazioni seguenti potrebbero essere rilevanti quando si implementa questo modello:

I modelli di progettazione cloud seguenti vengono spesso usati insieme al modello Gatekeeper:

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-06-03