Separera HTTP-publicering från applikationskörning och beständig data. En omvänd proxy kan organisera routning och gränser, men originåtkomst, applikationsauktorisering, uppströmskapacitet och återställning kräver var och en sina egna kontroller.
En webbförfrågan korsar flera ansvarsområden
En webbserver tar emot HTTP-förfrågningar och kan leverera statiska filer. En applikationsprocess kör projektets dynamiska beteende, till exempel att kontrollera ett konto eller fråga en databas. En omvänd proxy tar emot förfrågningar på uppdrag av den processen och vidarebefordrar dem till en uppström. Ett program kan fylla flera roller, men att separera ansvarsområdena gör konfiguration och återställning lättare att resonera kring.
Spåra en förfrågan från värdnamnsuppslagning till svaret. Registrera var TLS slutar, vilken process som väljer vägen och vilken komponent som kan läsa applikationsdata. Gör samma sak för en administrativ förfrågan. Denna övning avslöjar ofta en lyssnare eller ett värdnamn som skapades för testning och av misstag förblev nåbar. Diagrammet bör beskriva den driftsatta vägen snarare än den arkitektur du hoppades bygga.
Använd kanten för att organisera HTTP-beteende
NGINX dokumenterar både servering av statiskt innehåll och vidarebefordran av förfrågningar till en uppström. Dess arbetsarkitektur och HTTP-moduler tillhandahåller konfigurationsmekanismer, men en specifik konfiguration avgör fortfarande beteendet. Definiera värdnamn, uppströmmar och filsystemsrötter medvetet. Begränsa de filer som kan serveras så att konfiguration, autentiseringsuppgifter och arkivmetadata aldrig blir nedladdningsbara bara för att de råkar ligga nära applikationen.
Ange lämpliga gränser för förfrågningskroppar, tidsgränser och anslutningar enligt applikationen. Behandla cachar som ett databeslut: innehåll kopplat till en användare eller behörighet kan inte säkert ärva en delad cachelagringsregel utan granskning. Testa autentisering och cachebeteende tillsammans. Behåll en reproducerbar konfiguration och validera ändringar innan tjänsten laddas om, med en känd väg tillbaka till den tidigare fungerande versionen.
| Lager | Användbart ansvar | Kontrollera före lansering |
|---|---|---|
| Offentlig webbkant | TLS, värdnamnsroutning och HTTP-gränser | Certifikat, rötter och avsedda värdnamn |
| Applikationsprocess | Affärslogik och auktorisering | Autentisering, indatakontroller och beroendefel |
| Intern datatjänst | Beständigt applikationstillstånd | Begränsad åtkomst och testad återställning |
| Uppströmsleverantörens nätverk | Den avtalade nätverkstjänsten | Skyddsomfattning och eskaleringsväg |
En omvänd proxy tar inte bort originens exponering
Om originen förblir offentligt nåbar kan en klient nå den utan att använda den avsedda proxyvägen. Begränsa originåtkomst genom nätverksdesign och applikationskonfiguration när driftsättningen kräver den gränsen. På en maskin kan en backend ofta lyssna på loopback eller en lokal socket. Mellan maskiner, använd explicita begränsade vägar och lämpligt skydd för uppströmsanslutningen.
Vidarebefordrade rubriker behöver också en förtroenderegel. Acceptera information om den ursprungliga klienten endast från betrodda mellanhänder och förhindra att godtyckliga anropare tillhandahåller värden som applikationen behandlar som auktoritativa. Bestäm vad som visas i åtkomstloggar och felrapporter. En proxy kan ändra informationen som är tillgänglig vid varje lager; den raderar inte konton identifierare eller gör applikationen anonym för sin egen operatör.
Tillämpa åtkomstbeslut inuti applikationen
NIST:s Zero Trust-arkitektur fokuserar på åtkomstbeslut för resurser snarare än implicit förtroende enbart baserat på nätverksplats. Tillämpa den principen konkret: autentisera anroparen, auktorisera den begärda åtgärden och ge tjänstekonton endast deras nödvändiga omfattning. En förfrågan som kommer från ett internt subnät bör inte automatiskt bli en administratörsförfrågan.
Separera offentliga och administrativa funktioner där det är praktiskt. Kontrollera behörigheten igen när en användare kommer åt en post i stället för att bara förlita sig på den initiala inloggningen. Håll autentiseringsuppgifter för proxy, applikation och databas åtskilda. Inför ändringar i etapper som kan testas, med början i en smal känslig väg. Att kalla en driftsättning Zero Trust är mindre användbart än att visa att en förbjuden åtgärd faktiskt nekas vid den komponent som ansvarar för den.
Planera överbelastningsattack på mer än ett lager
En mättad nätverkslänk och en dyr applikationsförfrågan misslyckas på olika ställen. Hastighetsbegränsning vid webbkanten kan hjälpa till att begränsa förfrågningsmönster, medan applikationsgränser kan begränsa arbete som sökningar, uppladdningar eller exporter. NGINX:s modul för förfrågningsbegränsning tillhandahåller en mekanism; nyckeln och tröskelvärdena måste passa verkliga användare och testas för att undvika att avvisa legitim trafik.
OWASP:s vägledning för överbelastningsattacker tar också upp resursutmattning i applikationsbeteende. Sätt tids- och storleksgränser kring dyrt arbete, använd begränsade köer och övervaka felsignaler. Lokala kontroller kan inte skapa kapacitet i en uppströmslänk som redan är mättad. Bekräfta det specifika nätverksskydd som ingår i det valda erbjudandet och förbered en eskaleringsväg. Anta aldrig att en katalogs Layer 3–4-skydd också bevisar skydd för varje HTTP-arbetsbelastning.
Gör återställning till en del av publiceringen
Kontrollera webbplatsen från en extern klient med dess avsedda värdnamn. Verifiera HTTPS, omdirigeringar, statiska resurser, inloggningar och en representativ applikationstransaktion. Bekräfta att administrativa lyssnare och privata filer förblir otillgängliga. Simulera en stoppad uppström och kontrollera att kanten returnerar ett kontrollerat fel i stället för att exponera interna detaljer eller vänta utan gräns.
För Canvas, läs de kontroller som är tillgängliga i hostingkontot. För en VPS, underhåll webbkanten och applikationen som en del av din egen driftplan. En stor nätverksport är en kapacitetsspecifikation, inte ett bevis på att applikationen kan upprätthålla den genomströmningen. Behåll övervakning, återställning och leverantörskontakter i runbooken. Publicera först efter att den faktiska förfrågningsvägen och en praktisk återställningsväg har verifierats.
Din praktiska checklista.
- Spåra en offentlig och en administrativ förfrågan.
- Definiera serverade rötter och uppströmslyssnare.
- Lita på vidarebefordrade rubriker endast från godkända mellanhänder.
- Testa auktorisering och cachegränser.
- Förbered gränser och eskalering för nätverks- och applikationsfel.
Detaljerna som spelar roll.
Kan en webbserver också fungera som en omvänd proxy?+
Ja. NGINX är ett dokumenterat exempel. Dess roller beror på konfigurationen, och applikationen behöver fortfarande sin egen auktorisering och underhåll.
Döljer en omvänd proxy automatiskt originen?+
Nej. Originen kan förbli nåbar om inte routning, brandvägg och lyssnarinställningar upprätthåller den avsedda gränsen.
Kommer förfrågningsbegränsning att stoppa varje DDoS-attack?+
Nej. Den hanterar utvalda HTTP-förfrågningsmönster. Nätverksmättnad och andra resursfel kräver lämpliga uppströms- och applikationskontroller.
Gå till källan.
Dessa referenser stöder de tekniska begreppen i denna guide. Följ aktuell dokumentation innan du ändrar ett produktionssystem.
- NGINX: Nybörjarguide nginx.org
- NGINX: HTTP förfrågningsbegränsning nginx.org
- NIST SP 800-207: Zero Trust-arkitektur nvlpubs.nist.gov
- OWASP: Förebyggande av överbelastningsattack cheatsheetseries.owasp.org
Redaktionell vägledning av SwissOctet. Exemplen är illustrativa. Tjänstespecifikationer, tillgängliga alternativ och avtalsvillkor måste verifieras separat.