# Skill den offentlige nettkanten fra applikasjonen | SwissOctet Insights https://swissoctet.com/no/insights/separate-the-web-edge-from-the-app/ SwissOctet / Innsikt / Web og onion Web og onion Anvendt · 4 min lese Skill den offentlige webkanten fra applikasjonen Gi webserveren, omvendt proxy og applikasjonen distinkte ansvarsområder, med bevisst opprinnelsestilgang, TLS, forespørselsgrenser og en hendelsesvei. Av SwissOctet Redaksjonell Lagre veiledning Kopier lenke PÅ DENNE SIDEN 01 En nettforpørsel krysser flere ansvarsområder 02 Bruk kanten til å organisere HTTP-atferd 03 En omvendt proxy fjerner ikke origin-ens eksponering 04 Bruk tilgangsbeslutninger inne i applikasjonen 05 Planlegg tjenestenekt på mer enn ett lag 06 Gjør gjenoppretting til en del av publiseringen Din praktiske sjekkliste Kilder og videre lesning Tilbake til biblioteket DET DIREKTE SVARET 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. 01 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. 02 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 03 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. 04 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. 05 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. 06 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. GJØR DET OM TIL HANDLING 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. Last ned sjekkliste VANLIGE SPØRSMÅL 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. PRIMÆRREFERANSER 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. KOBLE KUNNSKAPEN SAMMEN Relatert infrastruktur. Canvas Web Sveits Vector VPS Sveits Pulse NVMe Sveits Transit 40 Sveits HOLD TRÅDEN Dine neste feltnotater. Utforsk alle veiledninger FELTNOTAT / 01 + Drift dag to Anvendt Et Linux VPS-herdingsgrunnlag du kan vedlikeholde Sikre administrasjon, eksponer bare nødvendige tjenester og etabler oppdateringer og gjenoppretting uten å låse deg selv ute. 6 min lesetid Les veiledningen FELTNOTAT / 02 + Web og onion Grunnlag Webhosting eller en VPS: velg arbeidet du vil eie Sammenlign applikasjonskrav, kontroll og vedlikeholdsansvar i stedet for å behandle en VPS som det automatiske neste steget for alle nettsteder. 6 min lesetid Les veiledningen FELTNOTAT / 03 + Web og onion Anvendt En overgangsrunbook for domene, DNS og TLS for en ny server Forbered vertsnavnruting, sertifikater og tilbakerulling sammen, slik at en migrering endrer serveren uten å bryte nettstedets identitet eller sikre tilkoblinger. 4 min lese Les veiledningen