Ihiwalay ang publikasyon ng HTTP mula sa pagpapatupad ng aplikasyon at persistenteng data. Ang reverse proxy ay maaaring mag-ayos ng routing at mga limitasyon, ngunit ang pag-access sa origin, awtorisasyon ng aplikasyon, kapasidad ng upstream at pagbawi ay bawat isa ay nangangailangan ng sariling mga kontrol.
Ang isang web request ay tumatawid sa ilang responsibilidad
Ang isang web server ay tumatanggap ng mga HTTP request at maaaring maghatid ng mga static na file. Ang isang proseso ng aplikasyon ay nagpapatupad ng dinamikong pag-uugali ng proyekto, tulad ng pagsuri ng account o pag-query sa database. Ang isang reverse proxy ay tumatanggap ng mga request sa ngalan ng prosesong iyon at ipinapasa ang mga ito sa isang upstream. Ang isang programa ay maaaring gumanap ng ilang tungkulin, ngunit ang paghihiwalay ng mga responsibilidad ay nagpapadali sa pagsusuri ng configuration at pagbawi.
Subaybayan ang isang request mula sa resolusyon ng hostname hanggang sa tugon. Itala kung saan nagtatapos ang TLS, aling proseso ang pumipili ng ruta at aling bahagi ang makakabasa ng data ng aplikasyon. Gawin ang pareho para sa isang administratibong request. Ang pagsasanay na ito ay madalas na naglalantad ng isang listener o hostname na ginawa para sa pagsubok at aksidenteng nanatiling maabot. Ang diagram ay dapat ilarawan ang na-deploy na landas sa halip na ang arkitekturang inaasahan mong itayo.
Gamitin ang edge upang ayusin ang pag-uugali ng HTTP
Dinodokumento ng NGINX ang parehong paghahatid ng static na nilalaman at pagpapasa ng mga request sa isang upstream. Ang arkitektura ng worker nito at mga module ng HTTP ay nagbibigay ng mga mekanismo ng configuration, ngunit ang isang partikular na configuration ay tumutukoy pa rin sa pag-uugali. Tukuyin ang mga hostname, upstream at filesystem root nang sinasadya. Limitahan ang mga file na maaaring ihain upang ang configuration, mga kredensyal at metadata ng repository ay hindi kailanman maging ma-download dahil lang sa katabi ng aplikasyon.
Magtakda ng angkop na mga limitasyon para sa mga request body, timeout at koneksyon ayon sa aplikasyon. Ituring ang mga cache bilang isang desisyon sa data: ang nilalamang nauugnay sa isang user o pahintulot ay hindi ligtas na magmamana ng isang shared caching rule nang walang pagsusuri. Subukan ang pagpapatotoo at pag-uugali ng cache nang magkasama. Panatilihin ang isang maaaring kopyahin na configuration at i-validate ang mga pagbabago bago i-reload ang serbisyo, na may kilalang ruta pabalik sa nakaraang gumaganang bersyon.
| Antas | Kapaki-pakinabang na responsibilidad | Suriin bago ilunsad |
|---|---|---|
| Pampublikong web edge | TLS, hostname routing at mga limitasyon ng HTTP | Mga sertipiko, root at nilalayong hostname |
| Proseso ng aplikasyon | Lohika ng negosyo at awtorisasyon | Pagpapatotoo, pagsusuri ng input at pagkabigo ng dependency |
| Panloob na serbisyo ng data | Persistenteng estado ng aplikasyon | Pinaghihigpitang pag-access at nasubok na pagpapanumbalik |
| Network ng upstream provider | Ang kontratadong serbisyo ng network | Saklaw ng proteksyon at landas ng pag-escalate |
Hindi inaalis ng reverse proxy ang pagkakalantad ng origin
Kung ang origin ay nananatiling pampublikong maaabot, ang isang kliyente ay maaaring maabot ito nang hindi ginagamit ang nilalayong ruta ng proxy. Limitahan ang pag-access sa origin sa pamamagitan ng disenyo ng network at configuration ng aplikasyon kapag ang deployment ay nangangailangan ng hangganang iyon. Sa isang makina, ang isang backend ay madalas na maaaring makinig sa loopback o isang lokal na socket. Sa mga makina, gumamit ng tahasang pinaghihigpitang mga ruta at angkop na proteksyon para sa koneksyon sa upstream.
Ang mga forwarded header ay nangangailangan din ng panuntunan sa pagtitiwala. Tanggapin ang impormasyon tungkol sa orihinal na kliyente mula lamang sa mga pinagkakatiwalaang tagapamagitan, at pigilan ang mga arbitraryong tumatawag na magbigay ng mga halagang itinuturing ng aplikasyon bilang awtoritatibo. Magpasya kung ano ang lalabas sa mga access log at ulat ng error. Ang isang proxy ay maaaring magbago ng impormasyong makukuha sa bawat layer; hindi nito binubura ang mga identifier ng account o ginagawang anonymous ang aplikasyon sa sarili nitong operator.
Ilapat ang mga desisyon sa pag-access sa loob ng aplikasyon
Ang arkitektura ng Zero Trust ng NIST ay nakatuon sa mga desisyon sa pag-access para sa mga resource sa halip na implicit na pagtitiwala batay lamang sa lokasyon ng network. Ilapat ang prinsipyong iyon nang konkreto: patotohanan ang tumatawag, awtorisahin ang hinihiling na operasyon at bigyan ang mga service account ng kanilang kinakailangang saklaw lamang. Ang isang request na dumarating mula sa isang panloob na subnet ay hindi dapat awtomatikong maging isang administratibong request.
Ihiwalay ang pampubliko at administratibong mga tungkulin kung praktikal. Muling suriin ang pahintulot kapag ang isang user ay nag-access ng isang record sa halip na umasa lamang sa paunang pag-login. Panatilihing magkaiba ang mga kredensyal para sa proxy, aplikasyon at database. Ipakilala ang mga pagbabago sa mga yugto na maaaring subukan, simula sa isang makitid na sensitibong landas. Ang pagtawag sa isang deployment na Zero Trust ay hindi gaanong kapaki-pakinabang kaysa sa pagpapakita na ang isang ipinagbabawal na aksyon ay aktwal na tinatanggihan sa bahaging responsable para dito.
Planuhin ang denial of service sa higit sa isang layer
Ang isang saturated na link ng network at isang magastos na request ng aplikasyon ay nabibigo sa magkaibang lugar. Ang rate limiting sa web edge ay maaaring makatulong na pigilan ang mga pattern ng request, habang ang mga limitasyon ng aplikasyon ay maaaring magtakda ng hangganan sa trabaho tulad ng mga paghahanap, pag-upload o pag-export. Ang request-limit module ng NGINX ay nagbibigay ng isang mekanismo; ang key at mga threshold ay dapat umangkop sa mga tunay na user at masubukan upang maiwasan ang pagtanggi sa lehitimong trapiko.
Ang gabay ng OWASP sa denial-of-service ay tumutugon din sa pagkaubos ng resource sa pag-uugali ng aplikasyon. Maglagay ng mga limitasyon sa oras at laki sa paligid ng magastos na trabaho, gumamit ng bounded na mga queue at subaybayan ang mga senyales ng pagkabigo. Ang mga lokal na kontrol ay hindi makakalikha ng kapasidad sa isang upstream link na saturated na. Kumpirmahin ang partikular na proteksyon ng network na kasama sa piniling alok at maghanda ng landas ng pag-escalate. Huwag kailanman ipagpalagay na ang Layer 3–4 na proteksyon ng isang katalogo ay nagpapatunay din ng proteksyon para sa bawat HTTP workload.
Gawing bahagi ng publikasyon ang pagbawi
Suriin ang site mula sa isang panlabas na kliyente gamit ang nilalayong hostname nito. I-verify ang HTTPS, mga redirect, static na resource, pag-login at isang representatibong transaksyon ng aplikasyon. Kumpirmahin na ang mga administratibong listener at pribadong file ay nananatiling hindi maaabot. Gayahin ang isang huminto na upstream at suriin na ang edge ay nagbabalik ng kontroladong pagkabigo sa halip na ilantad ang panloob na mga detalye o maghintay nang walang limitasyon.
Para sa Canvas, basahin ang mga kontrol na makukuha sa loob ng hosting account. Para sa isang VPS, panatilihin ang web edge at aplikasyon bilang bahagi ng iyong sariling plano sa pagpapatakbo. Ang isang malaking port ng network ay isang spesipikasyon ng kapasidad, hindi patunay na ang aplikasyon ay makakasustine ng throughput na iyon. Panatilihin ang pagsubaybay, pagpapanumbalik at mga kontak ng provider sa runbook. I-publish lamang pagkatapos ma-verify ang aktwal na landas ng request at isang praktikal na landas ng pagbawi.
Ang iyong praktikal na checklist.
- Subaybayan ang isang pampubliko at isang administratibong request.
- Tukuyin ang mga hinahatid na root at upstream listener.
- Pagkatiwalaan ang mga forwarded header mula lamang sa mga aprubadong tagapamagitan.
- Subukan ang awtorisasyon at mga hangganan ng cache.
- Maghanda ng mga limitasyon at pag-escalate para sa mga pagkabigo ng network at aplikasyon.
Ang mga detalyeng mahalaga.
Maaari bang gumanap din ang isang web server bilang reverse proxy?+
Oo. Ang NGINX ay isang dokumentadong halimbawa. Ang mga tungkulin nito ay nakasalalay sa configuration, at ang aplikasyon ay nangangailangan pa rin ng sarili nitong awtorisasyon at pagpapanatili.
Awtomatiko bang itinatago ng reverse proxy ang origin?+
Hindi. Ang origin ay maaaring manatiling maaabot maliban kung ipapatupad ng routing, firewall at mga setting ng listener ang nilalayong hangganan.
Mapipigilan ba ng request limiting ang bawat DDoS attack?+
Hindi. Tinutugunan nito ang mga piling pattern ng HTTP request. Ang saturation ng network at iba pang pagkabigo ng resource ay nangangailangan ng angkop na mga kontrol sa upstream at aplikasyon.
Pumunta sa pinagmulan.
Sinusuportahan ng mga sangguniang ito ang mga teknikal na konsepto sa gabay na ito. Sundin ang kasalukuyang dokumentasyon bago baguhin ang isang production system.
- NGINX: Gabay para sa baguhan nginx.org
- NGINX: Paglilimita ng HTTP request nginx.org
- NIST SP 800-207: Arkitektura ng Zero Trust nvlpubs.nist.gov
- OWASP: Pag-iwas sa Denial of Service cheatsheetseries.owasp.org
Editorial guidance ni SwissOctet. Ang mga halimbawa ay ilustratibo. Ang service specifications, available options at contractual conditions ay dapat beripikahin nang hiwalay.