กฎของ AWS Client VPN อยู่ที่ทรัพยากร ไม่ใช่ที่ซับเน็ต

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

ตำแหน่งของซับเน็ตคือการกำหนดเส้นทาง ไม่ใช่การอนุญาต

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

เริ่มจากข้อกำหนดแทน: ใครเรียก ทรัพยากรใด พอร์ตบริการใด และทิศทางใด จากนั้นเลือกแบบจำลองกฎที่สามารถแสดงสี่สิ่งนั้นที่ปลายทางได้ กรอบความคิดนี้มักกำจัดซับเน็ตส่วนเกินออกจากการออกแบบทั้งหมด

กลุ่มการเชื่อมโยงของ Client VPN คือที่จับนั้น

สำหรับปลายทาง AWS Client VPN ที่เชื่อมโยงกับซับเน็ต การจัดวางตามเอกสารนั้นเฉพาะเจาะจง ใช้กลุ่มความปลอดภัยที่ต้องการกับกลุ่มการเชื่อมโยงเครือข่ายเป้าหมายของปลายทาง จากนั้นอนุญาตทราฟฟิกที่จำเป็นในกลุ่มความปลอดภัยของทรัพยากรโดยใช้กลุ่ม Client VPN นั้นเป็นแหล่งที่มา

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

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

สิ่งที่กลุ่มการเชื่อมโยงเดียวแยกไม่ออก

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

ความแตกต่างที่ละเอียดกว่าขึ้นอยู่กับแอปพลิเคชัน ตัวรับฟังฐานข้อมูลที่ต้องปิดสำหรับพนักงานส่วนใหญ่ได้รับการปกป้องดีกว่าด้วยการไม่สามารถเข้าถึงได้เลยบนคำนำหน้าที่อนุญาต มากกว่าการหวังว่าสมาชิกภาพในกลุ่มจะเรียบร้อย

การเปลี่ยนชื่อกลุ่มไม่ได้สร้างอัตลักษณ์ และการทำสำเนาต่อทีมเพียงแต่เพิ่มการเชื่อมโยงที่ต้องตรวจสอบ

อย่าคัดลอกกฎนั้นไปยังทุกการออกแบบ VPN

เกตเวย์ EC2 VPN ที่จัดการเอง อุปกรณ์ตรวจสอบที่กำหนดเส้นทาง และ Client VPN ที่มีการจัดการเป็นเส้นทางแพ็กเก็ตสามแบบที่แตกต่างกัน กำหนดว่าที่อยู่ต้นทางใดเข้าถึงทรัพยากรจริง มีการแปลที่อยู่ระหว่างทางหรือไม่ และบริการรองรับกลไกการอ้างอิงใดบนเส้นทางนั้น

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

ฮอป NAT หนึ่งครั้งบนเส้นทางก็เพียงพอที่จะทำลายสมมติฐาน และความล้มเหลวดูเหมือนกฎที่มีอยู่แต่ไม่เคยตรงกัน

ทบทวนขอบเขตที่มีผลจริง

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

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

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