Adskil HTTP-offentliggørelse fra applikationskørsel og vedvarende data. En omvendt proxy kan organisere routing og grænser, men oprindelsesadgang, applikationsgodkendelse, upstream-kapacitet og gendannelse kræver hver deres egne kontroller.
En webanmodning krydser flere ansvarsområder
En webserver modtager HTTP-anmodninger og kan levere statiske filer. En applikationsproces udfører projektets dynamiske adfærd, såsom at kontrollere en konto eller forespørge en database. En omvendt proxy modtager anmodninger på vegne af denne proces og videresender dem til en upstream. Et program kan opfylde flere roller, men adskillelse af ansvarsområderne gør konfiguration og gendannelse lettere at gennemskue.
Følg én anmodning fra værtsnavnsopløsning til svaret. Registrér, hvor TLS slutter, hvilken proces der vælger ruten, og hvilken komponent der kan læse applikationsdata. Gør det samme for en administrativ anmodning. Denne øvelse afslører ofte en listener eller et værtsnavn, der blev oprettet til test og ved et uheld forblev tilgængeligt. Diagrammet bør beskrive den udrullede vej i stedet for den arkitektur, du håbede at bygge.
Brug kanten til at organisere HTTP-adfærd
NGINX dokumenterer både levering af statisk indhold og videresendelse af anmodninger til en upstream. Dets worker-arkitektur og HTTP-moduler tilbyder konfigurationsmekanismer, men en bestemt konfiguration bestemmer stadig adfærden. Definer værtsnavne, upstreams og filsystemrødder bevidst. Begræns de filer, der kan leveres, så konfiguration, legitimationsoplysninger og repository-metadata aldrig bliver downloadbare, fordi de tilfældigvis ligger tæt på applikationen.
Angiv passende grænser for anmodningsorganer, timeouts og forbindelser i overensstemmelse med applikationen. Behandl caches som en databeslutning: indhold knyttet til en bruger eller tilladelse kan ikke sikkert arve en delt cache-regel uden gennemgang. Test godkendelse og cache-adfærd sammen. Behold en reproducerbar konfiguration, og validér ændringer, før tjenesten genindlæses, med en kendt vej tilbage til den tidligere fungerende version.
| Lag | Nyttigt ansvarsområde | Kontrollér før lancering |
|---|---|---|
| Offentlig webkant | TLS, værtsnavnsrouting og HTTP-grænser | Certifikater, rødder og tilsigtede værtsnavne |
| Applikationsproces | Forretningslogik og godkendelse | Godkendelse, inputkontrol og afhængighedsfejl |
| Intern datatjeneste | Vedvarende applikationstilstand | Begrænset adgang og testet gendannelse |
| Upstream-udbydernetværk | Den kontraherede netværkstjeneste | Beskyttelsesomfang og eskaleringsvej |
En omvendt proxy fjerner ikke oprindelsens eksponering
Hvis oprindelsen forbliver offentligt tilgængelig, kan en klient nå den uden at bruge den tilsigtede proxy-rute. Begræns oprindelsesadgang gennem netværksdesign og applikationskonfiguration, når udrulningen kræver denne grænse. På én maskine kan en backend ofte lytte på loopback eller en lokal socket. På tværs af maskiner skal du bruge eksplicitte begrænsede ruter og passende beskyttelse af upstream-forbindelsen.
Videresendte headers har også brug for en tillidsregel. Accepter kun information om den oprindelige klient fra betroede mellemled, og forhindr vilkårlige kaldere i at levere værdier, som applikationen behandler som autoritative. Beslut, hvad der vises i adgangslogs og fejlrapporter. En proxy kan ændre den information, der er tilgængelig på hvert lag; den sletter ikke kontoidentifikatorer eller gør applikationen anonym for sin egen operatør.
Anvend adgangsbeslutninger inde i applikationen
NISTs Zero Trust-arkitektur fokuserer på adgangsbeslutninger for ressourcer i stedet for implicit tillid udelukkende baseret på netværksplacering. Anvend dette princip konkret: godkend kalderen, autorisér den ønskede handling, og giv kun tjenestekonti det nødvendige omfang. En anmodning, der ankommer fra et internt subnet, bør ikke automatisk blive en administratoranmodning.
Adskil offentlige og administrative funktioner, hvor det er praktisk. Kontrollér tilladelsen igen, når en bruger tilgår en post, i stedet for kun at stole på det indledende login. Hold legitimationsoplysninger for proxy, applikation og database adskilt. Indfør ændringer i etaper, der kan testes, begyndende med en smal følsom vej. At kalde en udrulning Zero Trust er mindre nyttigt end at demonstrere, at en forbudt handling faktisk afvises i den komponent, der er ansvarlig for den.
Planlæg denial of service på mere end ét lag
Et mættet netværkslink og en dyr applikationsanmodning fejler forskellige steder. Hastighedsbegrænsning ved webkanten kan hjælpe med at begrænse anmodningsmønstre, mens applikationsgrænser kan begrænse arbejde som søgninger, uploads eller eksporter. NGINX' anmodningsbegrænsningsmodul leverer én mekanisme; nøglen og tærsklerne skal passe til rigtige brugere og testes for at undgå at afvise legitim trafik.
OWASPs vejledning om denial of service behandler også ressourceudtømning i applikationsadfærd. Sæt tids- og størrelsesgrænser omkring dyrt arbejde, brug afgrænsede køer, og overvåg fejlsignaler. Lokale kontroller kan ikke skabe kapacitet i et upstream-link, der allerede er mættet. Bekræft den specifikke netværksbeskyttelse, der er inkluderet i det valgte tilbud, og forbered en eskaleringsvej. Antag aldrig, at et katalogs Layer 3–4-beskyttelse også beviser beskyttelse for enhver HTTP-arbejdsbelastning.
Gør gendannelse til en del af offentliggørelsen
Kontrollér webstedet fra en ekstern klient ved hjælp af dets tilsigtede værtsnavn. Verificér HTTPS, omdirigeringer, statiske ressourcer, logins og en repræsentativ applikationstransaktion. Bekræft, at administrative listenere og private filer forbliver utilgængelige. Simulér en stoppet upstream, og kontrollér, at kanten returnerer en kontrolleret fejl i stedet for at eksponere interne detaljer eller vente uden grænse.
For Canvas skal du læse de kontroller, der er tilgængelige i hostingkontoen. For en VPS skal du vedligeholde webkanten og applikationen som en del af din egen driftsplan. En stor netværksport er en kapacitetsspecifikation, ikke bevis for, at applikationen kan opretholde denne gennemstrømning. Behold overvågning, gendannelse og udbyderkontakter i runbooken. Offentliggør først, efter den faktiske anmodningsvej og en praktisk gendannelsesvej er blevet verificeret.
Din praktiske tjekliste.
- Følg en offentlig og en administrativ anmodning.
- Definer leverede rødder og upstream-listenere.
- Stol kun på videresendte headers fra godkendte mellemled.
- Test godkendelse og cache-grænser.
- Forbered grænser og eskalering for netværks- og applikationsfejl.
De detaljer, der betyder noget.
Kan en webserver også fungere som omvendt proxy?+
Ja. NGINX er et dokumenteret eksempel. Dets roller afhænger af konfigurationen, og applikationen har stadig brug for sin egen godkendelse og vedligeholdelse.
Skjuler en omvendt proxy automatisk oprindelsen?+
Nej. Oprindelsen kan forblive tilgængelig, medmindre routing-, firewall- og listenerindstillinger håndhæver den tilsigtede grænse.
Stopper anmodningsbegrænsning enhver DDoS-angreb?+
Nej. Det håndterer udvalgte HTTP-anmodningsmønstre. Netværksmætning og andre ressourcefejl kræver passende upstream- og applikationskontroller.
Gå til kilden.
Disse referencer understøtter de tekniske begreber i denne guide. Følg den aktuelle dokumentation, før du ændrer et produktionssystem.
- NGINX: Begynderguide nginx.org
- NGINX: HTTP anmodningsbegrænsning nginx.org
- NIST SP 800-207: Zero Trust-arkitektur nvlpubs.nist.gov
- OWASP: Forebyggelse af denial of service cheatsheetseries.owasp.org
Redaktionel vejledning af SwissOctet. Eksempler er illustrative. Servicespecifikationer, tilgængelige valgmuligheder og kontraktvilkår skal verificeres separat.