แยกการเผยแพร่ HTTP ออกจากการทำงานของแอปพลิเคชันและข้อมูลถาวร รีเวิร์สพร็อกซีสามารถจัดระเบียบการกำหนดเส้นทางและขีดจำกัดได้ แต่การเข้าถึงต้นทาง การอนุญาตของแอปพลิเคชัน ความจุต้นน้ำ และการกู้คืน ต่างก็ต้องมีการควบคุมของตนเอง
คำขอเว็บข้ามความรับผิดชอบหลายส่วน
เว็บเซิร์ฟเวอร์รับคำขอ HTTP และสามารถให้บริการไฟล์แบบสแตติกได้ กระบวนการแอปพลิเคชันดำเนินการพฤติกรรมไดนามิกของโปรเจกต์ เช่น การตรวจสอบบัญชีหรือการสอบถามฐานข้อมูล รีเวิร์สพร็อกซีรับคำขอในนามของกระบวนการนั้นและส่งต่อไปยังต้นน้ำ โปรแกรมหนึ่งอาจทำหน้าที่หลายอย่าง แต่การแยกความรับผิดชอบทำให้การกำหนดค่าและการกู้คืนเข้าใจได้ง่ายขึ้น
ติดตามคำขอหนึ่งรายการตั้งแต่การแปลงชื่อโฮสต์จนถึงการตอบกลับ บันทึกว่า TLS สิ้นสุดที่ใด กระบวนการใดเลือกเส้นทาง และองค์ประกอบใดสามารถอ่านข้อมูลแอปพลิเคชันได้ ทำเช่นเดียวกันกับคำขอด้านการดูแลระบบ แบบฝึกหัดนี้มักเปิดเผยตัวรับฟังหรือชื่อโฮสต์ที่สร้างขึ้นสำหรับการทดสอบและยังคงเข้าถึงได้โดยไม่ตั้งใจ แผนภาพควรอธิบายเส้นทางที่ปรับใช้จริง แทนสถาปัตยกรรมที่คุณหวังจะสร้าง
ใช้ขอบเพื่อจัดระเบียบพฤติกรรม HTTP
NGINX มีเอกสารทั้งการให้บริการเนื้อหาแบบสแตติกและการส่งต่อคำขอไปยังต้นน้ำ สถาปัตยกรรมเวิร์กเกอร์และโมดูล HTTP มีกลไกการกำหนดค่า แต่การกำหนดค่าเฉพาะยังคงเป็นตัวกำหนดพฤติกรรม กำหนดชื่อโฮสต์ ต้นน้ำ และรากของระบบไฟล์อย่างตั้งใจ จำกัดไฟล์ที่สามารถให้บริการได้ เพื่อให้การกำหนดค่า ข้อมูลรับรอง และข้อมูลเมตาของที่เก็บโค้ดไม่กลายเป็นสิ่งที่ดาวน์โหลดได้เพียงเพราะอยู่ใกล้กับแอปพลิเคชัน
กำหนดขีดจำกัดที่เหมาะสมสำหรับเนื้อหาคำขอ การหมดเวลา และการเชื่อมต่อตามแอปพลิเคชัน ปฏิบัติต่อแคชเป็นการตัดสินใจด้านข้อมูล เนื้อหาที่ผูกกับผู้ใช้หรือสิทธิ์ไม่สามารถสืบทอดกฎแคชที่ใช้ร่วมกันได้อย่างปลอดภัยโดยไม่ตรวจสอบ ทดสอบการรับรองความถูกต้องและพฤติกรรมแคชร่วมกัน เก็บการกำหนดค่าที่ทำซ้ำได้และตรวจสอบความถูกต้องของการเปลี่ยนแปลงก่อนโหลดบริการใหม่ โดยมีเส้นทางกลับไปยังเวอร์ชันที่ใช้งานได้ก่อนหน้าที่รู้จัก
| ชั้น | ความรับผิดชอบที่มีประโยชน์ | ตรวจสอบก่อนเปิดตัว |
|---|---|---|
| ขอบเว็บสาธารณะ | TLS การกำหนดเส้นทางชื่อโฮสต์ และขีดจำกัด HTTP | ใบรับรอง ราก และชื่อโฮสต์ที่ตั้งใจไว้ |
| กระบวนการแอปพลิเคชัน | ตรรกะทางธุรกิจและการอนุญาต | การรับรองความถูกต้อง การตรวจสอบอินพุต และความล้มเหลวของ dependency |
| บริการข้อมูลภายใน | สถานะแอปพลิเคชันแบบถาวร | การเข้าถึงที่จำกัดและการกู้คืนที่ผ่านการทดสอบ |
| เครือข่ายของผู้ให้บริการต้นน้ำ | บริการเครือข่ายตามสัญญา | ขอบเขตการป้องกันและเส้นทางการยกระดับ |
รีเวิร์สพร็อกซีไม่ได้ขจัดความเสี่ยงของต้นทาง
หากต้นทางยังคงเข้าถึงได้แบบสาธารณะ ไคลเอนต์อาจเข้าถึงได้โดยไม่ผ่านเส้นทางพร็อกซีที่ตั้งใจไว้ จำกัดการเข้าถึงต้นทางผ่านการออกแบบเครือข่ายและการกำหนดค่าแอปพลิเคชันเมื่อการปรับใช้ต้องการขอบเขตนั้น บนเครื่องเดียว แบ็กเอนด์มักสามารถรับฟังบนลูปแบ็กหรือซ็อกเก็ตภายในเครื่องได้ ข้ามเครื่อง ให้ใช้เส้นทางที่จำกัดอย่างชัดเจนและการป้องกันที่เหมาะสมสำหรับการเชื่อมต่อต้นน้ำ
เฮดเดอร์ที่ส่งต่อก็ต้องการกฎความเชื่อถือเช่นกัน ยอมรับข้อมูลเกี่ยวกับไคลเอนต์ต้นทางจากตัวกลางที่เชื่อถือได้เท่านั้น และป้องกันไม่ให้ผู้เรียกโดยพลการส่งค่าที่แอปพลิเคชันถือว่าเชื่อถือได้ กำหนดสิ่งที่จะปรากฏในบันทึกการเข้าถึงและรายงานข้อผิดพลาด พร็อกซีสามารถเปลี่ยนข้อมูลที่มีในแต่ละชั้นได้ แต่ไม่ได้ลบตัวระบุบัญชีหรือทำให้แอปพลิเคชันไม่ระบุตัวตนต่อผู้ดำเนินการของตนเอง
ใช้การตัดสินใจด้านการเข้าถึงภายในแอปพลิเคชัน
สถาปัตยกรรม Zero Trust ของ NIST มุ่งเน้นการตัดสินใจด้านการเข้าถึงทรัพยากร แทนความเชื่อถือโดยปริยายจากตำแหน่งเครือข่ายเพียงอย่างเดียว ใช้หลักการนั้นอย่างเป็นรูปธรรม: รับรองความถูกต้องของผู้เรียก อนุญาตการดำเนินการที่ร้องขอ และให้บัญชีบริการมีเพียงขอบเขตที่จำเป็น คำขอที่มาจากซับเน็ตภายในไม่ควรกลายเป็นคำขอของผู้ดูแลระบบโดยอัตโนมัติ
แยกฟังก์ชันสาธารณะและด้านการดูแลระบบออกจากกันเมื่อทำได้ ตรวจสอบสิทธิ์อีกครั้งเมื่อผู้ใช้เข้าถึงบันทึก แทนที่จะพึ่งเฉพาะการเข้าสู่ระบบครั้งแรก เก็บข้อมูลรับรองสำหรับพร็อกซี แอปพลิเคชัน และฐานข้อมูลให้แยกจากกัน นำการเปลี่ยนแปลงมาใช้เป็นขั้นตอนที่ทดสอบได้ เริ่มจากเส้นทางที่ละเอียดอ่อนและแคบ การเรียกการปรับใช้ว่า Zero Trust มีประโยชน์น้อยกว่าการแสดงให้เห็นว่าการกระทำที่ต้องห้ามถูกปฏิเสธจริงที่องค์ประกอบที่รับผิดชอบ
วางแผนการปฏิเสธการให้บริการในมากกว่าหนึ่งชั้น
ลิงก์เครือข่ายที่อิ่มตัวและคำขอแอปพลิเคชันที่มีต้นทุนสูงล้มเหลวในตำแหน่งที่ต่างกัน การจำกัดอัตราที่ขอบเว็บอาจช่วยจำกัดรูปแบบคำขอ ขณะที่ขีดจำกัดของแอปพลิเคชันสามารถจำกัดงาน เช่น การค้นหา การอัปโหลด หรือการส่งออก โมดูลจำกัดคำขอของ NGINX มีกลไกหนึ่งให้ คีย์และเกณฑ์ต้องเหมาะกับผู้ใช้จริงและต้องทดสอบเพื่อหลีกเลี่ยงการปฏิเสธทราฟฟิกที่ถูกต้อง
คำแนะนำเกี่ยวกับการปฏิเสธการให้บริการของ OWASP ยังกล่าวถึงการหมดทรัพยากรในพฤติกรรมของแอปพลิเคชันด้วย กำหนดขีดจำกัดเวลาและขนาดรอบงานที่มีต้นทุนสูง ใช้คิวที่มีขอบเขต และเฝ้าติดตามสัญญาณความล้มเหลว การควบคุมภายในเครื่องไม่สามารถสร้างความจุในลิงก์ต้นน้ำที่อิ่มตัวอยู่แล้วได้ ยืนยันการป้องกันเครือข่ายเฉพาะที่รวมอยู่ในข้อเสนอที่เลือกและเตรียมเส้นทางการยกระดับ อย่าสันนิษฐานว่าการป้องกัน Layer 3–4 ของแค็ตตาล็อกพิสูจน์ได้ว่าป้องกันเวิร์กโหลด HTTP ทุกประเภทด้วย
ทำให้การกู้คืนเป็นส่วนหนึ่งของการเผยแพร่
ตรวจสอบไซต์จากไคลเอนต์ภายนอกโดยใช้ชื่อโฮสต์ที่ตั้งใจไว้ ยืนยัน HTTPS การเปลี่ยนเส้นทาง ทรัพยากรแบบสแตติก การเข้าสู่ระบบ และธุรกรรมแอปพลิเคชันที่เป็นตัวแทน ยืนยันว่าตัวรับฟังด้านการดูแลระบบและไฟล์ส่วนตัวยังคงเข้าถึงไม่ได้ จำลองต้นน้ำที่หยุดทำงานและตรวจสอบว่าขอบส่งคืนความล้มเหลวที่ควบคุมได้ แทนที่จะเปิดเผยรายละเอียดภายในหรือรอโดยไม่มีขีดจำกัด
สำหรับ Canvas ให้อ่านการควบคุมที่มีในบัญชีโฮสติ้ง สำหรับ VPS ให้ดูแลขอบเว็บและแอปพลิเคชันเป็นส่วนหนึ่งของแผนการดำเนินงานของคุณเอง พอร์ตเครือข่ายขนาดใหญ่เป็นข้อกำหนดด้านความจุ ไม่ใช่หลักฐานว่าแอปพลิเคชันสามารถรองรับปริมาณงานนั้นได้ เก็บการเฝ้าติดตาม การกู้คืน และข้อมูลติดต่อผู้ให้บริการไว้ใน runbook เผยแพร่หลังจากตรวจสอบเส้นทางคำขอจริงและเส้นทางการกู้คืนที่ปฏิบัติได้แล้วเท่านั้น
รายการตรวจสอบปฏิบัติของคุณ
- ติดตามคำขอสาธารณะและคำขอด้านการดูแลระบบ
- กำหนดรากที่ให้บริการและตัวรับฟังต้นน้ำ
- เชื่อถือเฮดเดอร์ที่ส่งต่อจากตัวกลางที่ได้รับอนุมัติเท่านั้น
- ทดสอบการอนุญาตและขอบเขตแคช
- เตรียมขีดจำกัดและการยกระดับสำหรับความล้มเหลวของเครือข่ายและแอปพลิเคชัน
รายละเอียดที่สำคัญ
เว็บเซิร์ฟเวอร์สามารถทำหน้าที่เป็นรีเวิร์สพร็อกซีได้ด้วยหรือไม่+
ได้ NGINX เป็นตัวอย่างหนึ่งที่มีเอกสาร บทบาทของมันขึ้นอยู่กับการกำหนดค่า และแอปพลิเคชันยังคงต้องมีการอนุญาตและการบำรุงรักษาของตนเอง
รีเวิร์สพร็อกซีซ่อนต้นทางโดยอัตโนมัติหรือไม่+
ไม่ ต้นทางอาจยังเข้าถึงได้ เว้นแต่การกำหนดเส้นทาง ไฟร์วอลล์ และการตั้งค่าตัวรับฟังจะบังคับใช้ขอบเขตที่ตั้งใจไว้
การจำกัดคำขอจะหยุดการโจมตี DDoS ทุกครั้งได้หรือไม่+
ไม่ มันจัดการรูปแบบคำขอ HTTP ที่เลือกไว้ ความอิ่มตัวของเครือข่ายและความล้มเหลวของทรัพยากรอื่น ๆ ต้องอาศัยการควบคุมต้นน้ำและแอปพลิเคชันที่เหมาะสม
ไปที่ต้นทาง
แหล่งอ้างอิงเหล่านี้สนับสนุนแนวคิดทางเทคนิคในคู่มือนี้ ปฏิบัติตามเอกสารปัจจุบันก่อนเปลี่ยนระบบโปรดักชัน
- NGINX: คู่มือสำหรับผู้เริ่มต้น nginx.org
- NGINX: การจำกัดคำขอ HTTP nginx.org
- NIST SP 800-207: สถาปัตยกรรม Zero Trust nvlpubs.nist.gov
- OWASP: การป้องกันการปฏิเสธการให้บริการ cheatsheetseries.owasp.org
คำแนะนำด้านบรรณาธิการโดย SwissOctet ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก