Separa la pubblicazione HTTP dall'esecuzione dell'applicazione e dai dati persistenti. Un reverse proxy può organizzare routing e limiti, ma accesso all'origine, autorizzazione dell'applicazione, capacità upstream e ripristino richiedono ciascuno controlli propri.
Una richiesta web attraversa diverse responsabilità
Un server web riceve richieste HTTP e può servire file statici. Un processo applicativo esegue il comportamento dinamico del progetto, come verificare un account o interrogare un database. Un reverse proxy riceve richieste per conto di quel processo e le inoltra a un upstream. Un programma può svolgere diversi ruoli, ma separare le responsabilità rende configurazione e ripristino più facili da ragionare.
Traccia una richiesta dalla risoluzione del nome host alla risposta. Registra dove termina TLS, quale processo sceglie il percorso e quale componente può leggere i dati dell'applicazione. Fai lo stesso per una richiesta amministrativa. Questo esercizio spesso espone un listener o un nome host creato per i test e rimasto accidentalmente raggiungibile. Il diagramma dovrebbe descrivere il percorso distribuito anziché l'architettura che speravi di costruire.
Usa l'edge per organizzare il comportamento di HTTP
NGINX documenta sia la distribuzione di contenuti statici sia l'inoltro di richieste a un upstream. La sua architettura worker e i moduli HTTP forniscono meccanismi di configurazione, ma è comunque una configurazione specifica a determinare il comportamento. Definire deliberatamente hostname, upstream e root del filesystem. Limitare i file che possono essere serviti affinché configurazione, credenziali e metadati del repository non diventino scaricabili solo perché si trovano vicino all'applicazione.
Impostare limiti adeguati per corpi delle richieste, timeout e connessioni in base all'applicazione. Trattare le cache come una decisione sui dati: i contenuti legati a un utente o a un permesso non possono ereditare in sicurezza una regola di cache condivisa senza una verifica. Testare insieme autenticazione e comportamento della cache. Mantenere una configurazione riproducibile e validare le modifiche prima di ricaricare il servizio, con un percorso noto per tornare alla versione funzionante precedente.
| Livello | Responsabilità utile | Verificare prima del lancio |
|---|---|---|
| Edge web pubblico | TLS, routing degli hostname e limiti HTTP | Certificati, root e hostname previsti |
| Processo applicativo | Logica di business e autorizzazione | Autenticazione, controlli sugli input e guasto delle dipendenze |
| Servizio dati interno | Stato applicativo persistente | Accesso limitato e ripristino testato |
| Rete del provider upstream | Il servizio di rete contrattualizzato | Ambito di protezione e percorso di escalation |
Un reverse proxy non elimina l'esposizione dell'origine
Se l'origine rimane accessibile pubblicamente, un client può raggiungerla senza usare il percorso proxy previsto. Limitare l'accesso all'origine tramite il design di rete e la configurazione dell'applicazione quando il deployment richiede quel confine. Su una singola macchina, un backend può spesso ascoltare su loopback o su un socket locale. Tra macchine diverse, usare route limitate esplicite e una protezione adeguata per la connessione upstream.
Anche gli header inoltrati richiedono una regola di fiducia. Accettare informazioni sul client originale solo da intermediari fidati e impedire che chiamanti arbitrari forniscano valori che l'applicazione considera autorevoli. Decidere cosa compare nei log di accesso e nei report degli errori. Un proxy può cambiare le informazioni disponibili a ogni livello; non cancella gli identificatori dell'account né rende l'applicazione anonima al proprio operatore.
Applica le decisioni di accesso all'interno dell'applicazione
L'architettura Zero Trust di NIST si concentra sulle decisioni di accesso alle risorse anziché sulla fiducia implicita basata solo sulla posizione di rete. Applicare concretamente questo principio: autenticare il chiamante, autorizzare l'operazione richiesta e assegnare agli account di servizio solo l'ambito necessario. Una richiesta che arriva da una sottorete interna non dovrebbe diventare automaticamente una richiesta amministrativa.
Separare le funzioni pubbliche e amministrative dove è praticabile. Ricontrollare i permessi quando un utente accede a un record invece di affidarsi solo al login iniziale. Mantenere distinte le credenziali per proxy, applicazione e database. Introdurre le modifiche in fasi testabili, iniziando da un percorso sensibile ristretto. Definire un deployment Zero Trust è meno utile che dimostrare che un'azione vietata viene effettivamente negata nel componente responsabile di essa.
Pianifica la negazione del servizio a più di un livello
Un collegamento di rete saturo e una richiesta applicativa costosa falliscono in punti diversi. Il rate limiting sull'edge web può aiutare a limitare i pattern di richieste, mentre i limiti applicativi possono circoscrivere attività come ricerche, upload o esportazioni. Il modulo di limitazione delle richieste di NGINX fornisce un meccanismo; la chiave e le soglie devono adattarsi agli utenti reali ed essere testate per evitare di rifiutare traffico legittimo.
Anche le linee guida di OWASP sulla prevenzione degli attacchi denial-of-service affrontano l'esaurimento delle risorse nel comportamento applicativo. Porre limiti di tempo e dimensione attorno alle attività costose, usare code limitate e monitorare i segnali di guasto. I controlli locali non possono creare capacità in un collegamento upstream già saturo. Confermare la protezione di rete specifica inclusa nell'offerta scelta e preparare un percorso di escalation. Non presumere mai che la protezione di Livello 3–4 di un catalogo dimostri anche la protezione per ogni workload HTTP.
Rendi il ripristino parte della pubblicazione
Verificare il sito da un client esterno usando il suo hostname previsto. Controllare HTTPS, redirect, risorse statiche, login e una transazione applicativa rappresentativa. Confermare che i listener amministrativi e i file privati rimangano inaccessibili. Simulare un upstream fermo e verificare che l'edge restituisca un errore controllato invece di esporre dettagli interni o attendere senza limite.
Per Canvas, leggere i controlli disponibili nell'account di hosting. Per un VPS, mantenere l'edge web e l'applicazione come parte del proprio piano operativo. Una porta di rete ampia è una specifica di capacità, non la prova che l'applicazione possa sostenere quel throughput. Mantenere monitoraggio, ripristino e contatti del provider nel runbook. Pubblicare solo dopo aver verificato il percorso effettivo delle richieste e un percorso di ripristino praticabile.
La tua checklist pratica.
- Tracciare una richiesta pubblica e una amministrativa.
- Definire root servite e listener upstream.
- Fidarsi degli header inoltrati solo da intermediari approvati.
- Testare autorizzazione e confini della cache.
- Preparare limiti ed escalation per guasti di rete e applicativi.
I dettagli che contano.
Un web server può anche agire come reverse proxy?+
Sì. NGINX è un esempio documentato. I suoi ruoli dipendono dalla configurazione e l'applicazione necessita comunque di autorizzazione e manutenzione proprie.
Un reverse proxy nasconde automaticamente l'origine?+
No. L'origine può rimanere raggiungibile a meno che routing, firewall e impostazioni dei listener non impongano il confine previsto.
La limitazione delle richieste fermerà ogni attacco DDoS?+
No. Affronta pattern di richieste HTTP selezionati. La saturazione di rete e altri guasti delle risorse richiedono controlli upstream e applicativi adeguati.
Vai alla fonte.
Questi riferimenti supportano i concetti tecnici di questa guida. Segui la documentazione corrente prima di modificare un sistema di produzione.
- NGINX: guida per principianti nginx.org
- NGINX: limitazione delle richieste HTTP nginx.org
- NIST SP 800-207: architettura Zero Trust nvlpubs.nist.gov
- OWASP: prevenzione degli attacchi denial-of-service cheatsheetseries.owasp.org
Guida editoriale di SwissOctet. Gli esempi sono illustrativi. Le specifiche di servizio, le opzioni disponibili e le condizioni contrattuali devono essere verificate separatamente.