# Adskil din offentlige webkant fra applikationen | SwissOctet Insights https://swissoctet.com/da/insights/separate-the-web-edge-from-the-app/ SwissOctet / Indsigter / Web og onion Web og onion Anvendt · 4 min læsning Adskil din offentlige web-edge fra applikationen Giv webserveren, reverse proxyen og applikationen forskellige ansvarsområder med bevidst oprindelsesadgang, TLS, anmodningsgrænser og en hændelsesvej. Af SwissOctet Editorial Gem guide Kopiér link PÅ DENNE SIDE 01 En webanmodning krydser flere ansvarsområder 02 Brug kanten til at organisere HTTP-adfærd 03 En omvendt proxy fjerner ikke oprindelsens eksponering 04 Anvend adgangsbeslutninger inde i applikationen 05 Planlæg denial of service på mere end ét lag 06 Gør gendannelse til en del af offentliggørelsen Din praktiske tjekliste Kilder og videre læsning Tilbage til biblioteket DET DIREKTE SVAR 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. 01 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. 02 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 03 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. 04 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. 05 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. 06 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. GØR DET TIL HANDLING 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. Download tjekliste ALMINDELIGE SPØRGSMÅL 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. PRIMÆRE REFERENCER 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. FORBIND VIDENEN Relateret infrastruktur. Canvas Web Schweiz Vector VPS Schweiz Pulse NVMe Schweiz Transit 40 Schweiz BEHOLD TRÅDEN Dine næste feltnoter. Udforsk alle guider FELTNOTE / 01 + Drift på dag to Anvendt En Linux VPS-hærdningsbaseline, du kan vedligeholde Sikr administration, eksponér kun nødvendige tjenester, og etablér opdateringer og gendannelse uden at låse dig selv ude. 6 min. læsning Læs guiden FELTNOTE / 02 + Web og onion Fundament Webhosting eller en VPS: vælg det arbejde, du vil eje Sammenlign applikationskrav, kontrol og vedligeholdelsesansvar i stedet for at behandle en VPS som det automatiske næste skridt for ethvert website. 6 min. læsning Læs guiden FELTNOTE / 03 + Web og onion Anvendt En runbook til overgang af domæne, DNS og TLS til en ny server Forbered værtsnavnerouting, certifikater og tilbagerulning samlet, så en migrering ændrer serveren uden at bryde webstedets identitet eller sikre forbindelser. 4 min læsning Læs guiden