สองเกต VPN ต่อกัน: แต่ละเกตตัดสินอะไรจริง ๆ
สองขั้นตอน VPN ต่อกันควรหมายถึงการตัดสินอนุญาตสองครั้งแยกกัน ระบุว่าแต่ละเกตตรวจอะไร แล้วทดสอบว่าเกตชั้นในปฏิเสธอะไร
การต่อ VPN สองตัวเป็นทอด ๆ มักถูกขายเป็นข้อมูลเข้ารหัสเพิ่ม ซึ่งเป็นสิ่งที่มันทำได้น่าสนใจน้อยที่สุด ผลิตภัณฑ์จริงคือการตัดสินอนุญาตครั้งที่สอง ซึ่งเจ้าของอีกคนตัดสินต่อทรัพยากรอีกชุดหนึ่ง หากทั้งสองขั้นตอนยอมรับข้อมูลรับรองเดียวกันและไปถึงปลายทางเดียวกัน เกตชั้นในก็เป็นเพียงเครื่องประดับที่เพิ่มความหน่วง การตัดสินว่าการตัดสินครั้งที่สองนั้นคุ้มค่าดำเนินการหรือไม่ เริ่มจากการระบุว่าแต่ละเกตตรวจสอบอะไรจริง ๆ
อุโมงค์หนึ่งชั้น แล้วจึงเป็นการตัดสินครั้งที่สอง
เกตชั้นนอกตอบคำถามกว้าง ๆ ว่า นี่คืออุปกรณ์พนักงานที่ได้รับอนุมัติหรือไม่ และเข้าถึงเครือข่ายภายในทั่วไปได้หรือไม่ เกตชั้นในตอบคำถามที่แคบกว่า ว่าเอกลักษณ์นี้มีสิทธิ์บำรุงรักษาหรือไม่ และเข้าถึงปลายทางการจัดการเฉพาะเหล่านี้ได้หรือไม่ นี่เป็นคำถามต่างกันที่มีเจ้าของต่างกัน และไม่มีอันใดสื่อถึงอีกอัน การมีอยู่ของเส้นทางผ่านทั้งสองขั้นตอนไม่ใช่สิทธิอำนาจในการใช้อะไรที่อยู่หลังขั้นที่สอง การไปถึงทางเข้าที่ไกลพิสูจน์ว่าเส้นทางทำงานได้ และไม่มีอะไรมากกว่านั้น
หลักการนี้เก่าและยังคงถูกละเลย ตำแหน่งในเครือข่ายไม่ได้ให้เหตุผลใด ๆ ด้วยตัวเอง สรุปสถาปัตยกรรมความเชื่อถือศูนย์ของ NIST กล่าวไว้ชัดเจน และปฏิเสธความเชื่อถือโดยนัยที่เกิดจากที่มาของการเชื่อมต่อหรือใครเป็นเจ้าของเครือข่าย เมื่อนำมาใช้ที่นี่ การไปถึงทางเข้าชั้นในเป็นเงื่อนไขเบื้องต้นสำหรับทรัพยากรของมัน ไม่ใช่การอนุญาตให้ใช้ทรัพยากรเหล่านั้นเลย
เขียนลงไปว่าแต่ละเกตตรวจสอบอะไร
สำหรับแต่ละขั้นตอน บันทึกเอกลักษณ์ที่ตรวจ ปลายทางที่อนุญาต และเงื่อนไขที่ข้ามได้ เกตชั้นนอกสามารถอนุญาตบริการภายในทั่วไปบวกตัวรับฟังของเกตชั้นในได้อย่างชอบธรรม และไม่มีอย่างอื่น เกตชั้นในอาจต้องการการอ้างสิทธิ์บทบาทและอนุญาตเฉพาะที่อยู่การจัดการที่ระบุในบันทึกการเปลี่ยนแปลง แอปพลิเคชันที่ปลายไกลยังคงมีคำสุดท้ายว่าบทบาทนั้นทำการใดได้บ้าง ดังนั้นห่วงโซ่จึงเพิ่มเกตโดยไม่แทนที่การอนุญาตของแอปพลิเคชัน
| Gate | Identity it checks | Destinations it permits | How it could be skipped | When it is removed |
|---|---|---|---|---|
| Outer gateway | Employee account plus a managed device posture | General internal services and the inner gateway's listener | Any alternate path to the same destinations, including a public listener | Ordinary work stops and the inner stage becomes unreachable |
| Inner gateway | A maintenance entitlement or role claim on that identity | The named management addresses in the change record | Direct routes from the outer domain to those addresses | Maintenance access ends while general access stays as it was |
การละเว้นสองอย่างทำลายการออกแบบอย่างเงียบ ๆ หากโดเมนชั้นนอกเข้าถึงปลายทางที่ละเอียดอ่อนทุกแห่งโดยตรงอยู่แล้ว เกตชั้นในก็เป็นทางเลือกไม่ใช่ข้อบังคับ หากตัวรับฟังสาธารณะหรือเส้นทางส่วนตัวที่สองให้การเข้าถึงเดียวกัน เส้นทางที่ตั้งใจก็เป็นเพียงหนึ่งในหลายตัวเลือก การกำหนดเจ้าของให้กับชุดกฎแต่ละชุดด้วย และให้สัญญาของพวกเขาระบุบริการปลายทาง เอกลักษณ์ต้นทางที่อนุญาต DNS ส่วนตัว การแปลที่อยู่ และใครตอบเมื่อการส่งต่อล้มเหลว ที่อยู่ที่เชื่อถือได้บนเครือข่ายชั้นนอกต้องไม่แทนที่การอนุญาตของโดเมนชั้นในเลย
ทดสอบกรณีการปฏิเสธ ไม่ใช่เส้นทางที่ราบรื่น
การเชื่อมต่อที่สำเร็จผ่านทั้งสองเกตพิสูจน์ได้น้อยมาก เพราะนั่นคือกรณีที่ทุกคนทดสอบระหว่างการนำไปใช้ กรณีที่น่าสนใจคือกรณีที่ขั้นตอนหนึ่งผ่านและอีกขั้นตอนปฏิเสธ สามกรณีครอบคลุมความเสี่ยงส่วนใหญ่ และแต่ละกรณีมีผลลัพธ์ที่คาดหวังซึ่งตรวจสอบได้แทนที่จะโต้แย้ง
เมื่อการเข้าถึงทั่วไปได้รับอนุมัติและไม่มีบทบาทที่ละเอียดอ่อน งานปกติต้องดำเนินต่อในขณะที่ปลายทางที่ละเอียดอ่อนถูกปฏิเสธ อนุมัติทั้งสองขั้นตอนและชุดที่เข้าถึงได้ควรเป็นปลายทางการบำรุงรักษาที่ระบุในบันทึกการเปลี่ยนแปลง ไม่กว้างกว่านั้น เมื่อสิทธิ์ถูกเพิกถอนกลางเซสชัน นโยบายเซสชันที่ตกลงกันต้องมีผลโดยไม่ฉีกการเข้าถึงทั่วไปที่ไม่เกี่ยวข้อง การเพิกถอนนั้นจะจบเซสชันที่มีอยู่ทันทีหรือในการรับรองความถูกต้องครั้งถัดไปเป็นการตัดสินนโยบายที่สัญญาควรมีอยู่แล้ว ผู้ที่เขียนกรณีการยอมรับไม่ใช่ผู้ที่ควรตีความกรณีเหล่านั้นระหว่างเหตุการณ์
curl --fail --silent --max-time 5 https://maint.corp.internal/health || echo "denied as expected"นับการพึ่งพาที่คุณเพิ่ม
แต่ละขั้นตอนเพิ่มส่วนประกอบที่ล้มเหลวได้และเส้นทางที่ต้องซ้อนอยู่อย่างถูกต้องภายในอุโมงค์ชั้นนอก ระหว่างความล้มเหลวบางส่วน เส้นทางชั้นนอกยังทำงานอยู่ขณะที่ชั้นในเข้าถึงไม่ได้ ผู้ใช้จึงเห็นไอคอน VPN ที่แข็งแรงข้างบริการที่ไม่เคยตอบสนอง
ตรวจสอบเส้นทางและกฎการบล็อกเมื่อเกิดความล้มเหลว ไม่ใช่เฉพาะในกรณีปกติ เส้นทางเริ่มต้นที่ถูกดันโดยอุโมงค์ชั้นนอกอาจจับที่อยู่ของเกตชั้นในเอง ซึ่งเปลี่ยนขั้นตอนที่สองเป็นการเชื่อมต่อที่สร้างขึ้นแล้วหลุด บันทึกว่าอะไรควรยังคงถูกบล็อกขณะไม่มีอุโมงค์ชั้นใน เพราะการถอยกลับโดยบังเอิญรอบ ๆ มันแย่กว่าการหยุดชะงักที่สะอาด ใช้รูปแบบการตรวจสอบเดียวกันบนทั้งสองฮอป เพื่อให้แต่ละอันถูกวัดไม่ใช่สันนิษฐาน ตัวบ่งชี้สถานะที่เชื่อมต่อสองตัวไม่ได้พิสูจน์ทั้งการซ้อนหรือการแยก
สิ่งที่เกตที่สองซื้อให้คุณไม่ได้
ถามว่าสองเกตใช้ข้อมูลรับรองเดียวกัน หน่วยงานออกใบรับรองเดียวกัน หรือระนาบการจัดการเดียวกันหรือไม่ เมื่อใช้ร่วมกัน พวกเขายังใช้โหมดความล้มเหลวที่สำคัญที่สุดร่วมกัน และขั้นตอนที่สองมีต้นทุนมากกว่าความเป็นอิสระที่ดูเหมือนจะเพิ่ม เซสชันการเข้ารหัสแยกกันไม่ได้สร้างการควบคุมด้านการบริหารแยกกัน
เก็บเกตชั้นในไว้ตราบเท่าที่มันบังคับใช้ข้อกำหนดที่คุณระบุและทดสอบได้ เช่นบทบาทที่โดเมนชั้นนอกไม่เคยตรวจ ลบมันออกเมื่องานเดียวของมันคือรับรองเอกลักษณ์เดิมกับปลายทางเดิมอีกครั้ง ไม่ว่าอย่างไร บันทึกข้อกำหนด เจ้าของ และพฤติกรรมเมื่อล้มเหลวไว้ด้วยกัน เพื่อให้การทบทวนครั้งถัดไปโต้แย้งเรื่องข้อกำหนดไม่ใช่แผนภาพ