# แยกขอบเว็บสาธารณะออกจากการทำงานของแอปพลิเคชัน | SwissOctet Insights

https://swissoctet.com/th/insights/separate-the-web-edge-from-the-app/

SwissOctet / ข้อมูลเชิงลึก / เว็บและ onion เว็บและ onion ประยุกต์ · อ่าน 4 นาที

แยกขอบเว็บสาธารณะออกจากแอปพลิเคชัน

ให้เว็บเซิร์ฟเวอร์ รีเวิร์สพร็อกซี และแอปพลิเคชันมีหน้าที่ชัดเจน พร้อมการเข้าถึงต้นทางอย่างตั้งใจ TLS ขีดจำกัดคำขอ และเส้นทางเหตุการณ์

โดย SwissOctet Editorial บันทึกคู่มือ คัดลอกลิงก์

ในหน้านี้ 01 คำขอเว็บข้ามความรับผิดชอบหลายส่วน 02 ใช้ขอบเพื่อจัดระเบียบพฤติกรรม HTTP 03 รีเวิร์สพร็อกซีไม่ได้ขจัดความเสี่ยงของต้นทาง 04 ใช้การตัดสินใจด้านการเข้าถึงภายในแอปพลิเคชัน 05 วางแผนการปฏิเสธการให้บริการในมากกว่าหนึ่งชั้น 06 ทำให้การกู้คืนเป็นส่วนหนึ่งของการเผยแพร่ รายการตรวจสอบปฏิบัติของคุณ แหล่งอ้างอิงและอ่านเพิ่มเติม กลับไปยังคลัง คำตอบตรงประเด็น แยกการเผยแพร่ HTTP ออกจากการทำงานของแอปพลิเคชันและข้อมูลถาวร รีเวิร์สพร็อกซีสามารถจัดระเบียบการกำหนดเส้นทางและขีดจำกัดได้ แต่การเข้าถึงต้นทาง การอนุญาตของแอปพลิเคชัน ความจุต้นน้ำ และการกู้คืน ต่างก็ต้องมีการควบคุมของตนเอง

01 คำขอเว็บข้ามความรับผิดชอบหลายส่วน

เว็บเซิร์ฟเวอร์รับคำขอ HTTP และสามารถให้บริการไฟล์แบบสแตติกได้ กระบวนการแอปพลิเคชันดำเนินการพฤติกรรมไดนามิกของโปรเจกต์ เช่น การตรวจสอบบัญชีหรือการสอบถามฐานข้อมูล รีเวิร์สพร็อกซีรับคำขอในนามของกระบวนการนั้นและส่งต่อไปยังต้นน้ำ โปรแกรมหนึ่งอาจทำหน้าที่หลายอย่าง แต่การแยกความรับผิดชอบทำให้การกำหนดค่าและการกู้คืนเข้าใจได้ง่ายขึ้น

ติดตามคำขอหนึ่งรายการตั้งแต่การแปลงชื่อโฮสต์จนถึงการตอบกลับ บันทึกว่า TLS สิ้นสุดที่ใด กระบวนการใดเลือกเส้นทาง และองค์ประกอบใดสามารถอ่านข้อมูลแอปพลิเคชันได้ ทำเช่นเดียวกันกับคำขอด้านการดูแลระบบ แบบฝึกหัดนี้มักเปิดเผยตัวรับฟังหรือชื่อโฮสต์ที่สร้างขึ้นสำหรับการทดสอบและยังคงเข้าถึงได้โดยไม่ตั้งใจ แผนภาพควรอธิบายเส้นทางที่ปรับใช้จริง แทนสถาปัตยกรรมที่คุณหวังจะสร้าง

02 ใช้ขอบเพื่อจัดระเบียบพฤติกรรม HTTP

NGINX มีเอกสารทั้งการให้บริการเนื้อหาแบบสแตติกและการส่งต่อคำขอไปยังต้นน้ำ สถาปัตยกรรมเวิร์กเกอร์และโมดูล HTTP มีกลไกการกำหนดค่า แต่การกำหนดค่าเฉพาะยังคงเป็นตัวกำหนดพฤติกรรม กำหนดชื่อโฮสต์ ต้นน้ำ และรากของระบบไฟล์อย่างตั้งใจ จำกัดไฟล์ที่สามารถให้บริการได้ เพื่อให้การกำหนดค่า ข้อมูลรับรอง และข้อมูลเมตาของที่เก็บโค้ดไม่กลายเป็นสิ่งที่ดาวน์โหลดได้เพียงเพราะอยู่ใกล้กับแอปพลิเคชัน

กำหนดขีดจำกัดที่เหมาะสมสำหรับเนื้อหาคำขอ การหมดเวลา และการเชื่อมต่อตามแอปพลิเคชัน ปฏิบัติต่อแคชเป็นการตัดสินใจด้านข้อมูล เนื้อหาที่ผูกกับผู้ใช้หรือสิทธิ์ไม่สามารถสืบทอดกฎแคชที่ใช้ร่วมกันได้อย่างปลอดภัยโดยไม่ตรวจสอบ ทดสอบการรับรองความถูกต้องและพฤติกรรมแคชร่วมกัน เก็บการกำหนดค่าที่ทำซ้ำได้และตรวจสอบความถูกต้องของการเปลี่ยนแปลงก่อนโหลดบริการใหม่ โดยมีเส้นทางกลับไปยังเวอร์ชันที่ใช้งานได้ก่อนหน้าที่รู้จัก

ชั้น ความรับผิดชอบที่มีประโยชน์ ตรวจสอบก่อนเปิดตัว

ขอบเว็บสาธารณะ TLS การกำหนดเส้นทางชื่อโฮสต์ และขีดจำกัด HTTP ใบรับรอง ราก และชื่อโฮสต์ที่ตั้งใจไว้

กระบวนการแอปพลิเคชัน ตรรกะทางธุรกิจและการอนุญาต การรับรองความถูกต้อง การตรวจสอบอินพุต และความล้มเหลวของ dependency

บริการข้อมูลภายใน สถานะแอปพลิเคชันแบบถาวร การเข้าถึงที่จำกัดและการกู้คืนที่ผ่านการทดสอบ

เครือข่ายของผู้ให้บริการต้นน้ำ บริการเครือข่ายตามสัญญา ขอบเขตการป้องกันและเส้นทางการยกระดับ

03 รีเวิร์สพร็อกซีไม่ได้ขจัดความเสี่ยงของต้นทาง

หากต้นทางยังคงเข้าถึงได้แบบสาธารณะ ไคลเอนต์อาจเข้าถึงได้โดยไม่ผ่านเส้นทางพร็อกซีที่ตั้งใจไว้ จำกัดการเข้าถึงต้นทางผ่านการออกแบบเครือข่ายและการกำหนดค่าแอปพลิเคชันเมื่อการปรับใช้ต้องการขอบเขตนั้น บนเครื่องเดียว แบ็กเอนด์มักสามารถรับฟังบนลูปแบ็กหรือซ็อกเก็ตภายในเครื่องได้ ข้ามเครื่อง ให้ใช้เส้นทางที่จำกัดอย่างชัดเจนและการป้องกันที่เหมาะสมสำหรับการเชื่อมต่อต้นน้ำ

เฮดเดอร์ที่ส่งต่อก็ต้องการกฎความเชื่อถือเช่นกัน ยอมรับข้อมูลเกี่ยวกับไคลเอนต์ต้นทางจากตัวกลางที่เชื่อถือได้เท่านั้น และป้องกันไม่ให้ผู้เรียกโดยพลการส่งค่าที่แอปพลิเคชันถือว่าเชื่อถือได้ กำหนดสิ่งที่จะปรากฏในบันทึกการเข้าถึงและรายงานข้อผิดพลาด พร็อกซีสามารถเปลี่ยนข้อมูลที่มีในแต่ละชั้นได้ แต่ไม่ได้ลบตัวระบุบัญชีหรือทำให้แอปพลิเคชันไม่ระบุตัวตนต่อผู้ดำเนินการของตนเอง

04 ใช้การตัดสินใจด้านการเข้าถึงภายในแอปพลิเคชัน

สถาปัตยกรรม Zero Trust ของ NIST มุ่งเน้นการตัดสินใจด้านการเข้าถึงทรัพยากร แทนความเชื่อถือโดยปริยายจากตำแหน่งเครือข่ายเพียงอย่างเดียว ใช้หลักการนั้นอย่างเป็นรูปธรรม: รับรองความถูกต้องของผู้เรียก อนุญาตการดำเนินการที่ร้องขอ และให้บัญชีบริการมีเพียงขอบเขตที่จำเป็น คำขอที่มาจากซับเน็ตภายในไม่ควรกลายเป็นคำขอของผู้ดูแลระบบโดยอัตโนมัติ

แยกฟังก์ชันสาธารณะและด้านการดูแลระบบออกจากกันเมื่อทำได้ ตรวจสอบสิทธิ์อีกครั้งเมื่อผู้ใช้เข้าถึงบันทึก แทนที่จะพึ่งเฉพาะการเข้าสู่ระบบครั้งแรก เก็บข้อมูลรับรองสำหรับพร็อกซี แอปพลิเคชัน และฐานข้อมูลให้แยกจากกัน นำการเปลี่ยนแปลงมาใช้เป็นขั้นตอนที่ทดสอบได้ เริ่มจากเส้นทางที่ละเอียดอ่อนและแคบ การเรียกการปรับใช้ว่า Zero Trust มีประโยชน์น้อยกว่าการแสดงให้เห็นว่าการกระทำที่ต้องห้ามถูกปฏิเสธจริงที่องค์ประกอบที่รับผิดชอบ

05 วางแผนการปฏิเสธการให้บริการในมากกว่าหนึ่งชั้น

ลิงก์เครือข่ายที่อิ่มตัวและคำขอแอปพลิเคชันที่มีต้นทุนสูงล้มเหลวในตำแหน่งที่ต่างกัน การจำกัดอัตราที่ขอบเว็บอาจช่วยจำกัดรูปแบบคำขอ ขณะที่ขีดจำกัดของแอปพลิเคชันสามารถจำกัดงาน เช่น การค้นหา การอัปโหลด หรือการส่งออก โมดูลจำกัดคำขอของ NGINX มีกลไกหนึ่งให้ คีย์และเกณฑ์ต้องเหมาะกับผู้ใช้จริงและต้องทดสอบเพื่อหลีกเลี่ยงการปฏิเสธทราฟฟิกที่ถูกต้อง

คำแนะนำเกี่ยวกับการปฏิเสธการให้บริการของ OWASP ยังกล่าวถึงการหมดทรัพยากรในพฤติกรรมของแอปพลิเคชันด้วย กำหนดขีดจำกัดเวลาและขนาดรอบงานที่มีต้นทุนสูง ใช้คิวที่มีขอบเขต และเฝ้าติดตามสัญญาณความล้มเหลว การควบคุมภายในเครื่องไม่สามารถสร้างความจุในลิงก์ต้นน้ำที่อิ่มตัวอยู่แล้วได้ ยืนยันการป้องกันเครือข่ายเฉพาะที่รวมอยู่ในข้อเสนอที่เลือกและเตรียมเส้นทางการยกระดับ อย่าสันนิษฐานว่าการป้องกัน Layer 3–4 ของแค็ตตาล็อกพิสูจน์ได้ว่าป้องกันเวิร์กโหลด HTTP ทุกประเภทด้วย

06 ทำให้การกู้คืนเป็นส่วนหนึ่งของการเผยแพร่

ตรวจสอบไซต์จากไคลเอนต์ภายนอกโดยใช้ชื่อโฮสต์ที่ตั้งใจไว้ ยืนยัน 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 ตัวอย่างมีไว้เพื่อประกอบ ข้อมูลจำเพาะของบริการ ตัวเลือกที่มี และเงื่อนไขตามสัญญาต้องได้รับการตรวจสอบแยกต่างหาก

เชื่อมโยงความรู้ โครงสร้างพื้นฐานที่เกี่ยวข้อง

Canvas Web สวิตเซอร์แลนด์ Vector VPS สวิตเซอร์แลนด์ Pulse NVMe สวิตเซอร์แลนด์ Transit 40 สวิตเซอร์แลนด์

รักษาสายไว้ บันทึกภาคสนามถัดไปของคุณ

สำรวจทุกคู่มือ

บันทึกภาคสนาม / 01

+

การดำเนินงานวันที่สอง ประยุกต์

เกณฑ์พื้นฐานการเสริมความปลอดภัย Linux VPS ที่คุณดูแลรักษาได้

ดูแลระบบอย่างปลอดภัย เปิดเผยเฉพาะบริการที่จำเป็น และกำหนดการอัปเดตและการกู้คืนโดยไม่ล็อกตัวเองออก

อ่าน 6 นาที อ่านคู่มือ

บันทึกภาคสนาม / 02

+

เว็บและ onion พื้นฐาน

เว็บโฮสติ้งหรือ VPS: เลือกงานที่คุณต้องการรับผิดชอบ

เปรียบเทียบข้อกำหนดของแอปพลิเคชัน การควบคุม และความรับผิดชอบด้านการบำรุงรักษา แทนที่จะถือว่า VPS เป็นขั้นตอนถัดไปอัตโนมัติสำหรับทุกเว็บไซต์

อ่าน 6 นาที อ่านคู่มือ

บันทึกภาคสนาม / 03

+

เว็บและ onion ประยุกต์

คู่มือปฏิบัติงานสำหรับการสลับโดเมน DNS และ TLS ไปยังเซิร์ฟเวอร์ใหม่

เตรียมการกำหนดเส้นทางโฮสต์เนม ใบรับรอง และการย้อนกลับไปพร้อมกัน เพื่อให้การโยกย้ายเปลี่ยนเซิร์ฟเวอร์โดยไม่ทำลายตัวตนของเว็บไซต์หรือการเชื่อมต่อที่ปลอดภัย

อ่าน 4 นาที อ่านคู่มือ