# Separați marginea web publică de aplicație | SwissOctet Insights https://swissoctet.com/ro/insights/separate-the-web-edge-from-the-app/ SwissOctet / Perspective / Web și onion Web și onion Aplicat · 4 min de citit Separați marginea web publică de aplicație Acordați serverului web, proxy-ului invers și aplicației responsabilități distincte, cu acces deliberat la origine, TLS, limite de cereri și o cale de incident. De SwissOctet Editorial Salvați ghidul Copiați linkul PE ACEASTĂ PAGINĂ 01 O cerere web traversează mai multe responsabilități 02 Folosiți marginea pentru a organiza comportamentul HTTP 03 Un proxy invers nu elimină expunerea originii 04 Aplicați deciziile de acces în interiorul aplicației 05 Planificați refuzul serviciului la mai multe niveluri 06 Faceți din recuperare parte a publicării Lista dumneavoastră practică de verificare Surse și lecturi suplimentare Înapoi la bibliotecă RĂSPUNSUL DIRECT Separați publicarea HTTP de execuția aplicației și datele persistente. Un proxy invers poate organiza rutarea și limitele, dar accesul la origine, autorizarea aplicației, capacitatea upstream și recuperarea necesită fiecare propriile controale. 01 O cerere web traversează mai multe responsabilități Un server web primește cereri HTTP și poate servi fișiere statice. Un proces de aplicație execută comportamentul dinamic al proiectului, cum ar fi verificarea unui cont sau interogarea unei baze de date. Un proxy invers primește cereri în numele acelui proces și le transmite către un upstream. Un singur program poate îndeplini mai multe roluri, dar separarea responsabilităților face configurarea și recuperarea mai ușor de înțeles. Urmăriți o cerere de la rezolvarea numelui de gazdă până la răspuns. Înregistrați unde se termină TLS, care proces alege ruta și care componentă poate citi datele aplicației. Faceți același lucru pentru o cerere administrativă. Acest exercițiu expune adesea un ascultător sau un nume de gazdă care a fost creat pentru testare și a rămas accesibil din greșeală. Diagrama ar trebui să descrie calea implementată, nu arhitectura pe care sperați să o construiți. 02 Folosiți marginea pentru a organiza comportamentul HTTP NGINX documentează atât servirea conținutului static, cât și transmiterea cererilor către un upstream. Arhitectura sa de workeri și modulele HTTP oferă mecanisme de configurare, dar o anumită configurație determină totuși comportamentul. Definiți în mod deliberat numele de gazdă, upstream-urile și rădăcinile sistemului de fișiere. Restrângeți fișierele care pot fi servite, astfel încât configurația, acreditările și metadatele depozitului să nu devină niciodată descărcabile doar pentru că se află în apropierea aplicației. Stabiliți limite adecvate pentru corpurile cererilor, expirările și conexiunile în funcție de aplicație. Tratați cache-urile ca pe o decizie privind datele: conținutul legat de un utilizator sau de o permisiune nu poate moșteni în siguranță o regulă de cache partajată fără revizuire. Testați împreună autentificarea și comportamentul cache-ului. Păstrați o configurație reproductibilă și validați modificările înainte de a reîncărca serviciul, cu o rută cunoscută de revenire la versiunea funcțională anterioară. Strat Responsabilitate utilă Verificați înainte de lansare Margine web publică TLS, rutarea numelor de gazdă și limitele HTTP Certificate, rădăcini și nume de gazdă prevăzute Proces de aplicație Logica de business și autorizarea Autentificare, verificări de intrare și eșecul dependențelor Serviciu de date intern Stare persistentă a aplicației Acces restricționat și restaurare testată Rețeaua furnizorului upstream Serviciul de rețea contractat Domeniul de protecție și calea de escaladare 03 Un proxy invers nu elimină expunerea originii Dacă originea rămâne accesibilă public, un client o poate atinge fără a folosi ruta de proxy prevăzută. Restrângeți accesul la origine prin proiectarea rețelei și configurația aplicației atunci când implementarea necesită această limită. Pe o singură mașină, un backend poate asculta adesea pe loopback sau pe un socket local. Între mașini, folosiți rute restricționate explicite și protecție adecvată pentru conexiunea upstream. Anteturile transmise necesită și o regulă de încredere. Acceptați informații despre clientul original doar de la intermediari de încredere și împiedicați apelanții arbitrari să furnizeze valori pe care aplicația le tratează ca autoritare. Decideți ce apare în jurnalele de acces și în rapoartele de erori. Un proxy poate schimba informațiile disponibile la fiecare nivel; nu șterge identificatorii de cont și nu face aplicația anonimă față de propriul operator. 04 Aplicați deciziile de acces în interiorul aplicației Arhitectura Zero Trust a NIST se concentrează pe deciziile de acces pentru resurse, mai degrabă decât pe încrederea implicită bazată doar pe locația în rețea. Aplicați acest principiu în mod concret: autentificați apelantul, autorizați operațiunea solicitată și acordați conturilor de serviciu doar domeniul de aplicare necesar. O cerere care sosește dintr-o subrețea internă nu ar trebui să devină automat o cerere de administrator. Separați funcțiile publice de cele administrative acolo unde este practic. Reverificați permisiunea atunci când un utilizator accesează o înregistrare, în loc să vă bazați doar pe autentificarea inițială. Păstrați distincte acreditările pentru proxy, aplicație și baza de date. Introduceți modificările în etape care pot fi testate, începând cu o cale sensibilă îngustă. A numi o implementare Zero Trust este mai puțin util decât a demonstra că o acțiune interzisă este efectiv refuzată la componenta responsabilă pentru ea. 05 Planificați refuzul serviciului la mai multe niveluri O legătură de rețea saturată și o cerere costisitoare a aplicației eșuează în locuri diferite. Limitarea ratei la marginea web poate ajuta la constrângerea tiparelor de cereri, în timp ce limitele aplicației pot limita lucrări precum căutările, încărcările sau exporturile. Modulul de limitare a cererilor din NGINX oferă un mecanism; cheia și pragurile trebuie să se potrivească utilizatorilor reali și să fie testate pentru a evita respingerea traficului legitim. Ghidul OWASP privind refuzul serviciului abordează și epuizarea resurselor în comportamentul aplicației. Stabiliți limite de timp și de dimensiune în jurul lucrărilor costisitoare, folosiți cozi mărginite și monitorizați semnalele de eșec. Controalele locale nu pot crea capacitate într-o legătură upstream deja saturată. Confirmați protecția specifică de rețea inclusă în oferta aleasă și pregătiți o cale de escaladare. Nu presupuneți niciodată că protecția Layer 3–4 a unui catalog dovedește și protecția pentru fiecare sarcină de lucru HTTP. 06 Faceți din recuperare parte a publicării Verificați site-ul de la un client extern folosind numele de gazdă prevăzut. Verificați HTTPS, redirecționările, resursele statice, autentificările și o tranzacție reprezentativă a aplicației. Confirmați că ascultătorii administrativi și fișierele private rămân inaccesibile. Simulați un upstream oprit și verificați că marginea returnează un eșec controlat, în loc să expună detalii interne sau să aștepte fără limită. Pentru Canvas, citiți controalele disponibile în contul de găzduire. Pentru un VPS, mențineți marginea web și aplicația ca parte a propriului plan de operare. Un port de rețea mare este o specificație de capacitate, nu o dovadă că aplicația poate susține acel debit. Păstrați monitorizarea, restaurarea și contactele furnizorului în runbook. Publicați numai după ce calea reală a cererilor și o cale practică de recuperare au fost verificate. TRANSFORMAȚI-O ÎN ACȚIUNE Lista dumneavoastră practică de verificare. ✓ Urmăriți o cerere publică și una administrativă. ✓ Definiți rădăcinile servite și ascultătorii upstream. ✓ Acordați încredere anteturilor transmise doar de la intermediari aprobați. ✓ Testați autorizarea și limitele cache-ului. ✓ Pregătiți limite și escaladare pentru eșecurile de rețea și de aplicație. Descărcați lista de verificare ÎNTREBĂRI FRECVENTE Detaliile care contează. Poate un server web să acționeze și ca proxy invers? + Da. NGINX este un exemplu documentat. Rolurile sale depind de configurație, iar aplicația are în continuare nevoie de propria autorizare și întreținere. Ascunde automat un proxy invers originea? + Nu. Originea poate rămâne accesibilă dacă rutarea, paravanul de protecție și setările ascultătorului nu impun limita prevăzută. Va opri limitarea cererilor fiecare atac DDoS? + Nu. Abordează tipare selectate de cereri HTTP. Saturația rețelei și alte eșecuri de resurse necesită controale adecvate upstream și la nivel de aplicație. REFERINȚE PRINCIPALE Mergeți la sursă. Aceste referințe susțin conceptele tehnice din acest ghid. Urmați documentația actuală înainte de a modifica un sistem de producție. NGINX: Ghid pentru începători nginx.org NGINX: Limitarea cererilor HTTP nginx.org NIST SP 800-207: Arhitectura Zero Trust nvlpubs.nist.gov OWASP: Prevenirea refuzului serviciului cheatsheetseries.owasp.org Îndrumare editorială de SwissOctet. Exemplele sunt ilustrative. Specificațiile serviciilor, opțiunile disponibile și condițiile contractuale trebuie verificate separat. CONECTAȚI CUNOAȘTEREA Infrastructură conexă. Canvas Web Elveția Vector VPS Elveția Pulse NVMe Elveția Transit 40 Elveția PĂSTRAȚI FIRUL Următoarele dumneavoastră note de teren. Explorați fiecare ghid NOTĂ DE TEREN / 01 + Operațiuni din ziua a doua Aplicat O bază de întărire Linux VPS pe care o puteți menține Administrare securizată, expuneți doar serviciile necesare și stabiliți actualizări și recuperare fără a vă bloca accesul. 6 min de citire Citiți ghidul NOTĂ DE TEREN / 02 + Web și onion Fundament Găzduire web sau un VPS: alegeți munca pe care doriți să o dețineți Comparați cerințele aplicației, controlul și responsabilitățile de întreținere, în loc să tratați un VPS ca pe următorul pas automat pentru fiecare site web. 6 min de citire Citiți ghidul NOTĂ DE TEREN / 03 + Web și onion Aplicat Un runbook de comutare pentru domeniu, DNS și TLS către un server nou Pregătiți împreună rutarea numelor de gazdă, certificatele și rollback-ul, astfel încât o migrare să schimbe serverul fără a strica identitatea site-ului sau conexiunile securizate. 4 min de citit Citiți ghidul