# Scheid uw publieke webedge van de applicatie | SwissOctet Insights https://swissoctet.com/nl/insights/separate-the-web-edge-from-the-app/ SwissOctet / Insights / Web & onion Web & onion Toegepast · 4 min leestijd Scheid je publieke webrand van de applicatie Geef de webserver, reverse proxy en applicatie afzonderlijke verantwoordelijkheden, met bewuste origintoegang, TLS, verzoeklimieten en een incidentpad. Door SwissOctet Editorial Gids opslaan Link kopiëren OP DEZE PAGINA 01 Een webverzoek raakt meerdere verantwoordelijkheden 02 Gebruik de edge om HTTP-gedrag te organiseren 03 Een reverse proxy haalt de exposure van de origin niet weg 04 Pas toegangsbeslissingen binnen de applicatie toe 05 Plan denial of service op meer dan één laag 06 Maak herstel onderdeel van de publicatie Uw praktische checklist Bronnen & verder lezen Terug naar de bibliotheek HET DIRECTE ANTWOORD Scheid HTTP-publicatie van applicatie-uitvoering en persistente data. Een reverse proxy kan routing en limieten organiseren, maar origin-toegang, applicatie-autorisatie, upstream-capaciteit en herstel vereisen elk hun eigen maatregelen. 01 Een webverzoek raakt meerdere verantwoordelijkheden Een webserver ontvangt HTTP-verzoeken en kan statische bestanden serveren. Een applicatieproces voert het dynamische gedrag van het project uit, zoals het controleren van een account of het opvragen van een database. Een reverse proxy ontvangt verzoeken namens dat proces en stuurt ze door naar een upstream. Eén programma kan meerdere rollen vervullen, maar het scheiden van de verantwoordelijkheden maakt configuratie en herstel makkelijker te doorgronden. Volg één verzoek van hostnaamresolutie tot het antwoord. Leg vast waar TLS eindigt, welk proces de route kiest en welk onderdeel applicatiedata kan lezen. Doe hetzelfde voor een administratief verzoek. Deze oefening legt vaak een listener of hostnaam bloot die voor testen is aangemaakt en per ongeluk bereikbaar is gebleven. Het diagram moet het geïmplementeerde pad beschrijven, niet de architectuur die u hoopte te bouwen. 02 Gebruik de edge om HTTP-gedrag te organiseren NGINX documenteert zowel het serveren van statische content als het doorsturen van verzoeken naar een upstream. De worker-architectuur en HTTP-modules bieden configuratiemechanismen, maar een specifieke configuratie bepaalt nog steeds het gedrag. Definieer hostnamen, upstreams en filesystem-roots bewust. Beperk de bestanden die geserveerd kunnen worden, zodat configuratie, inloggegevens en repository-metadata nooit downloadbaar worden omdat ze toevallig naast de applicatie staan. Stel passende limieten in voor request bodies, time-outs en verbindingen op basis van de applicatie. Behandel caches als een databeslissing: content die aan een gebruiker of machtiging is gekoppeld, kan niet veilig een gedeelde cacheregel overnemen zonder beoordeling. Test authenticatie en cachegedrag samen. Houd een reproduceerbare configuratie bij en valideer wijzigingen voordat u de service herlaadt, met een bekende route terug naar de vorige werkende versie. Laag Nuttige verantwoordelijkheid Controleer vóór de lancering Publieke webedge TLS, hostnaamrouting en HTTP-limieten Certificaten, roots en beoogde hostnamen Applicatieproces Bedrijfslogica en autorisatie Authenticatie, invoercontroles en falen van afhankelijkheden Interne dataservice Persistente applicatiestatus Beperkte toegang en getest herstel Netwerk van upstream-provider De gecontracteerde netwerkservice Beschermingsbereik en escalatiepad 03 Een reverse proxy haalt de exposure van de origin niet weg Als de origin publiek bereikbaar blijft, kan een client deze bereiken zonder de beoogde proxyroute te gebruiken. Beperk origin-toegang via het netwerkontwerp en de applicatieconfiguratie wanneer de implementatie die grens vereist. Op één machine kan een backend vaak luisteren op loopback of een lokale socket. Gebruik over machines heen expliciete beperkte routes en passende bescherming voor de upstream-verbinding. Forwarded headers hebben ook een vertrouwensregel nodig. Accepteer informatie over de oorspronkelijke client alleen van vertrouwde intermediairs en voorkom dat willekeurige aanroepers waarden leveren die de applicatie als gezaghebbend behandelt. Bepaal wat in access logs en foutrapporten verschijnt. Een proxy kan de beschikbare informatie per laag veranderen; hij wist geen account-ID's uit en maakt de applicatie niet anoniem voor de eigen beheerder. 04 Pas toegangsbeslissingen binnen de applicatie toe NIST's Zero Trust-architectuur richt zich op toegangsbeslissingen voor resources in plaats van impliciet vertrouwen op basis van alleen netwerklocatie. Pas dat principe concreet toe: authenticeer de aanroeper, autoriseer de gevraagde bewerking en geef serviceaccounts alleen het vereiste bereik. Een verzoek dat van een intern subnet komt, mag niet automatisch een administratorverzoek worden. Scheid publieke en administratieve functies waar dat praktisch is. Controleer de machtiging opnieuw wanneer een gebruiker een record opent, in plaats van alleen op de initiële login te vertrouwen. Houd inloggegevens voor de proxy, applicatie en database gescheiden. Voer wijzigingen in testbare fasen in, te beginnen met een smal gevoelig pad. Een implementatie Zero Trust noemen is minder nuttig dan aantonen dat een verboden actie daadwerkelijk wordt geweigerd bij het onderdeel dat daarvoor verantwoordelijk is. 05 Plan denial of service op meer dan één laag Een verzadigde netwerkverbinding en een duur applicatieverzoek falen op verschillende plaatsen. Rate limiting aan de webedge kan helpen om verzoekpatronen te beperken, terwijl applicatielimieten werk zoals zoekopdrachten, uploads of exports kunnen begrenzen. NGINX's request-limit-module biedt één mechanisme; de sleutel en drempels moeten bij echte gebruikers passen en worden getest om te voorkomen dat legitiem verkeer wordt geweigerd. OWASP's richtlijnen voor denial of service behandelen ook resource-uitputting in applicatiegedrag. Stel tijd- en groottelimieten rond duur werk, gebruik begrensde wachtrijen en monitor faalsignalen. Lokale maatregelen kunnen geen capaciteit creëren in een upstream-verbinding die al verzadigd is. Controleer welke specifieke netwerkbescherming in het gekozen aanbod is inbegrepen en bereid een escalatiepad voor. Ga er nooit van uit dat Layer 3–4-bescherming uit een catalogus ook bescherming voor elke HTTP-workload aantoont. 06 Maak herstel onderdeel van de publicatie Controleer de site vanaf een externe client met de beoogde hostnaam. Verifieer HTTPS, redirects, statische resources, logins en een representatieve applicatietransactie. Bevestig dat administratieve listeners en privébestanden ontoegankelijk blijven. Simuleer een gestopte upstream en controleer dat de edge een gecontroleerde fout retourneert in plaats van interne details bloot te leggen of zonder limiet te wachten. Lees voor Canvas de beschikbare maatregelen binnen het hostingaccount. Onderhoud voor een VPS de webedge en applicatie als onderdeel van uw eigen operationele plan. Een grote netwerkpoort is een capaciteitsspecificatie, geen bewijs dat de applicatie die doorvoer kan volhouden. Houd monitoring, herstel en providercontacten in het runbook. Publiceer pas nadat het werkelijke verzoekpad en een praktisch herstelpad zijn geverifieerd. ZET HET OM IN ACTIE Uw praktische checklist. ✓ Volg een publiek en een administratief verzoek. ✓ Definieer geserveerde roots en upstream-listeners. ✓ Vertrouw forwarded headers alleen van goedgekeurde intermediairs. ✓ Test autorisatie- en cachegrenzen. ✓ Bereid limieten en escalatie voor bij netwerk- en applicatiefouten. Checklist downloaden VEELGESTELDE VRAGEN De details die ertoe doen. Kan een webserver ook als reverse proxy fungeren? + Ja. NGINX is één gedocumenteerd voorbeeld. De rollen hangen af van de configuratie en de applicatie heeft nog steeds eigen autorisatie en onderhoud nodig. Verbergt een reverse proxy de origin automatisch? + Nee. De origin kan bereikbaar blijven tenzij routing-, firewall- en listenerinstellingen de beoogde grens afdwingen. Stopt request limiting elke DDoS-aanval? + Nee. Het pakt geselecteerde HTTP-verzoekpatronen aan. Netwerkverzadiging en andere resourcefouten vereisen passende upstream- en applicatiemaatregelen. PRIMAIRE REFERENTIES Ga naar de bron. Deze referenties ondersteunen de technische concepten in deze gids. Volg de actuele documentatie voordat u een productiesysteem wijzigt. NGINX: Beginner's guide nginx.org NGINX: HTTP request limiting nginx.org NIST SP 800-207: Zero Trust Architecture nvlpubs.nist.gov OWASP: Denial of Service Prevention cheatsheetseries.owasp.org Redactionele begeleiding door SwissOctet. Voorbeelden zijn illustratief. Dienstspecificaties, beschikbare opties en contractuele voorwaarden moeten afzonderlijk worden geverifieerd. VERBIND DE KENNIS Gerelateerde infrastructuur. Canvas Web Zwitserland Vector VPS Zwitserland Pulse NVMe Zwitserland Transit 40 Zwitserland HOUD DE DRAAD VAST Uw volgende veldnotities. Ontdek elke gids VELDNOTITIE / 01 + Operaties op dag twee Toegepast Een onderhoudbare hardening-basislijn voor Linux VPS Beveilig beheer, stel alleen vereiste services beschikbaar en richt updates en herstel in zonder jezelf buitengesloten te raken. 6 min leestijd Lees de gids VELDNOTITIE / 02 + Web & onion Fundament Webhosting of een VPS: kies het werk dat je wilt beheren Vergelijk applicatievereisten, controle en onderhoudsverantwoordelijkheden in plaats van een VPS te behandelen als de automatische volgende stap voor elke website. 6 min leestijd Lees de gids VELDNOTITIE / 03 + Web & onion Toegepast Een cutover-draaiboek voor domein, DNS en TLS voor een nieuwe server Bereid hostname-routering, certificaten en rollback samen voor, zodat een migratie de server wijzigt zonder de identiteit van de site of beveiligde verbindingen te breken. 4 min leestijd Lees de gids