Skill HTTP-publisering fra applikasjonskjøring og vedvarende data. En omvendt proxy kan organisere ruting og grenser, men origin-tilgang, applikasjonsautorisasjon, oppstrømskapasitet og gjenoppretting krever hver sine kontroller.
En nettforpørsel krysser flere ansvarsområder
En nettserver mottar HTTP-forespørsler og kan levere statiske filer. En applikasjonsprosess utfører prosjektets dynamiske atferd, for eksempel å sjekke en konto eller spørre en database. En omvendt proxy mottar forespørsler på vegne av den prosessen og videresender dem til en oppstrøm. Ett program kan oppfylle flere roller, men å skille ansvarsområdene gjør konfigurasjon og gjenoppretting enklere å resonnere om.
Spor én forespørsel fra vertsnavnoppslag til svaret. Registrer hvor TLS slutter, hvilken prosess som velger ruten, og hvilken komponent som kan lese applikasjonsdata. Gjør det samme for en administrativ forespørsel. Denne øvelsen avdekker ofte en lytter eller et vertsnavn som ble opprettet for testing og ved et uhell forble tilgjengelig. Diagrammet bør beskrive den utrullede ruten, ikke arkitekturen du håpet å bygge.
Bruk kanten til å organisere HTTP-atferd
NGINX dokumenterer både levering av statisk innhold og videresending av forespørsler til en oppstrøm. Arkitekturen med arbeidere og HTTP-modulene gir konfigurasjonsmekanismer, men en bestemt konfigurasjon avgjør fortsatt atferden. Definer vertsnavn, oppstrømmer og filsystemrøtter bevisst. Begrens filene som kan leveres, slik at konfigurasjon, legitimasjon og repositoriemetadata aldri blir nedlastbare bare fordi de tilfeldigvis ligger nær applikasjonen.
Sett passende grenser for forespørselsorganer, tidsavbrudd og tilkoblinger i samsvar med applikasjonen. Behandle hurtiglagre som en databeslutning: innhold knyttet til en bruker eller tillatelse kan ikke trygt arve en delt hurtiglagringsregel uten gjennomgang. Test autentisering og hurtiglagringsatferd sammen. Hold en reproduserbar konfigurasjon og valider endringer før tjenesten lastes på nytt, med en kjent rute tilbake til den forrige fungerende versjonen.
| Lag | Nyttig ansvar | Sjekk før lansering |
|---|---|---|
| Offentlig nettkant | TLS, vertsnavnruting og HTTP-grenser | Sertifikater, røtter og tiltenkte vertsnavn |
| Applikasjonsprosess | Forretningslogikk og autorisasjon | Autentisering, inndatakontroller og avhengighetsfeil |
| Intern datatjeneste | Vedvarende applikasjonstilstand | Begrenset tilgang og testet gjenoppretting |
| Oppstrømsleverandørnettverk | Den avtalte nettverkstjenesten | Beskyttelsesomfang og eskaleringsvei |
En omvendt proxy fjerner ikke origin-ens eksponering
Hvis origin-en forblir offentlig tilgjengelig, kan en klient nå den uten å bruke den tiltenkte proxy-ruten. Begrens origin-tilgang gjennom nettverksdesign og applikasjonskonfigurasjon når utrullingen krever den grensen. På én maskin kan en backend ofte lytte på loopback eller en lokal socket. På tvers av maskiner, bruk eksplisitte begrensede ruter og passende beskyttelse for oppstrømsforbindelsen.
Videresendte headere trenger også en tillitsregel. Godta informasjon om den opprinnelige klienten bare fra betrodde mellomledd, og hindre vilkårlige kallere i å oppgi verdier som applikasjonen behandler som autoritative. Bestem hva som vises i tilgangslogger og feilrapporter. En proxy kan endre informasjonen som er tilgjengelig på hvert lag; den sletter ikke kontoidentifikatorer eller gjør applikasjonen anonym for sin egen operatør.
Bruk tilgangsbeslutninger inne i applikasjonen
NISTs Zero Trust-arkitektur fokuserer på tilgangsbeslutninger for ressurser i stedet for implisitt tillit kun basert på nettverksplassering. Bruk dette prinsippet konkret: autentiser kalleren, autoriser den forespurte operasjonen og gi tjenestekontoer bare det omfanget de trenger. En forespørsel som kommer fra et internt subnett, bør ikke automatisk bli en administratorforespørsel.
Skill offentlige og administrative funksjoner der det er praktisk. Sjekk tillatelsen på nytt når en bruker får tilgang til en post, i stedet for å stole bare på den første påloggingen. Hold legitimasjon for proxy, applikasjon og database atskilt. Innfør endringer i trinn som kan testes, med start i en smal sensitiv rute. Å kalle en utrulling Zero Trust er mindre nyttig enn å demonstrere at en forbudt handling faktisk avvises i komponenten som er ansvarlig for den.
Planlegg tjenestenekt på mer enn ett lag
En mettet nettverkslenke og en kostbar applikasjonsforespørsel feiler på forskjellige steder. Hastighetsbegrensning ved nettkanten kan bidra til å begrense forespørselsmønstre, mens applikasjonsgrenser kan avgrense arbeid som søk, opplastinger eller eksporter. NGINX' forespørselsbegrensningsmodul gir én mekanisme; nøkkelen og tersklene må passe reelle brukere og testes for å unngå å avvise legitim trafikk.
OWASPs veiledning for tjenestenekt tar også for seg ressursutmattelse i applikasjonsatferd. Sett tids- og størrelsesgrenser rundt kostbart arbeid, bruk avgrensede køer og overvåk feilsignaler. Lokale kontroller kan ikke skape kapasitet i en oppstrømslenke som allerede er mettet. Bekreft den spesifikke nettverksbeskyttelsen som er inkludert i det valgte tilbudet, og forbered en eskaleringsvei. Anta aldri at en katalogs Layer 3–4-beskyttelse også beviser beskyttelse for hver HTTP-arbeidsbelastning.
Gjør gjenoppretting til en del av publiseringen
Sjekk nettstedet fra en ekstern klient ved hjelp av det tiltenkte vertsnavnet. Verifiser HTTPS, omdirigeringer, statiske ressurser, pålogginger og en representativ applikasjonstransaksjon. Bekreft at administrative lyttere og private filer forblir utilgjengelige. Simuler en stoppet oppstrøm og sjekk at kanten returnerer en kontrollert feil i stedet for å eksponere interne detaljer eller vente uten grense.
For Canvas, les kontrollene som er tilgjengelige i hostingkontoen. For en VPS, vedlikehold nettkanten og applikasjonen som en del av din egen driftsplan. En stor nettverksport er en kapasitetsspesifikasjon, ikke bevis på at applikasjonen kan opprettholde den gjennomstrømningen. Hold overvåking, gjenoppretting og leverandørkontakter i runbooken. Publiser bare etter at den faktiske forespørselsruten og en praktisk gjenopprettingsrute er verifisert.
Din praktiske sjekkliste.
- Spor en offentlig og en administrativ forespørsel.
- Definer betjente røtter og oppstrømslyttere.
- Stol på videresendte headere bare fra godkjente mellomledd.
- Test autorisasjon og hurtiglagringsgrenser.
- Forbered grenser og eskalering for nettverks- og applikasjonsfeil.
Detaljene som betyr noe.
Kan en nettserver også fungere som omvendt proxy?+
Ja. NGINX er ett dokumentert eksempel. Rollene avhenger av konfigurasjonen, og applikasjonen trenger fortsatt sin egen autorisasjon og vedlikehold.
Skjuler en omvendt proxy automatisk origin-en?+
Nei. Origin-en kan forbli tilgjengelig med mindre ruting, brannmur og lytterinnstillinger håndhever den tiltenkte grensen.
Vil forespørselsbegrensning stoppe hvert DDoS-angrep?+
Nei. Det håndterer utvalgte HTTP-forespørselsmønstre. Nettverksmetning og andre ressursfeil krever passende oppstrøms- og applikasjonskontroller.
Gå til kilden.
Disse referansene støtter de tekniske konseptene i denne veiledningen. Følg gjeldende dokumentasjon før du endrer et produksjonssystem.
- NGINX: Nybegynnerveiledning nginx.org
- NGINX: HTTP forespørselsbegrensning nginx.org
- NIST SP 800-207: Zero Trust-arkitektur nvlpubs.nist.gov
- OWASP: Forebygging av tjenestenekt cheatsheetseries.owasp.org
Redaksjonell veiledning av SwissOctet. Eksempler er illustrerende. Tjenestespesifikasjoner, tilgjengelige alternativer og kontraktsvilkår må verifiseres separat.