ยังต้องใช้ VPN ของไซต์อยู่ไหมเมื่อแอปใช้ mTLS และ SSO
ไล่ดูช่องทางที่การเข้าสู่ระบบของแอปไม่เคยครอบคลุม แล้วตัดสินใจว่าการเข้าถึงเครือข่ายส่วนตัวนั้นเกินความจำเป็นหรือยังเป็นทางเดียวไปยังโฮสต์
คุณเข้าสู่ระบบผ่าน mTLS แดชบอร์ดโหลดขึ้น และข้ออ้างว่า VPN ของไซต์ไม่จำเป็นแล้วฟังดูสมเหตุสมผลประมาณจนถึงตอนตีสองที่คุณต้องกู้คืนฐานข้อมูลขอบเขต TLS ของแอปอธิบายช่องทางเดียวเท่านั้นโฮสต์ ฐานข้อมูล ปลายทางสำรองข้อมูล และบัญชีคลาวด์ต่างมีเส้นทางเข้าของตัวเอง มีตัวตนของตัวเอง และมีผู้อนุมัติของตัวเอง และไม่มีสักรายการที่ถูกทดสอบด้วยการเข้าสู่ระบบที่สำเร็จ
เดินออกจากหน้าจอเข้าสู่ระบบ
เข้าสู่ระบบแบบผู้ใช้ทั่วไปและจดทุกจุดที่คำขอแตะ: เบราว์เซอร์ ขอบแอป ตัวรับฟังของแอป ที่เก็บเซสชัน API หลังบ้านทุกจุดมีเจ้าของและการตัดสินใจพิสูจน์ตัวตนตอนนี้ทำเส้นทางเดิมซ้ำสำหรับคนที่แพตช์โฮสต์ และสำหรับงานที่เขียนข้อมูลสำรองยามค่ำคืนเส้นทางเหล่านี้มักแยกจากกันตั้งแต่จุดแรก
การแยกจากกันนั้นคือคำถามที่ควรค่าแก่การตอบVPN ของไซต์จะเกินความจำเป็นก็ต่อเมื่อทุกช่องทางในเส้นทางที่สองนั้นมีนโยบายการเข้าถึงและการอนุญาตที่ยืนได้ด้วยตัวเอง
ห้าช่องทางที่การเข้าสู่ระบบของแอปไม่เคยครอบคลุม
ตารางด้านล่างเป็นแม่แบบการทำบัญชีทรัพย์สิน ไม่ใช่รายการตรวจสอบการติดตั้งเติมคอลัมน์ที่สองด้วยสิ่งที่สภาพแวดล้อมของคุณบังคับใช้จริงในวันนี้
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
การแชร์ผู้ให้บริการตัวตนรายเดียวไม่ได้รวมการอนุญาตเหล่านี้เข้าด้วยกันผู้ใช้ที่ส่งคำขอ API ได้ไม่ได้แปลว่าได้รับอนุญาตให้เปลี่ยนดิสก์ของ VM หรือกู้คืนฐานข้อมูลด้วยข้อมูลรับรองของแอปNIST ในบทสรุปสถาปัตยกรรมความเชื่อศูนย์แยกการพิสูจน์ตัวตนและการอนุญาตของทรัพยากรออกจากตำแหน่งในเครือข่ายด้วยเหตุผลนี้เอง
วิศวกรสนับสนุนที่อ่านตั๋วได้ไม่ได้แปลว่าได้รับอนุญาตให้เปิดคอนโซลบนโฮสต์ที่อยู่ข้างหลัง
เส้นทางจะเป็นจริงได้ก็ต่อเมื่อทางเลือกยังปิดอยู่
การจำกัดการเข้าถึงให้เหลือเฉพาะตัวรับฟังการบริหารส่วนตัวเป็นสิ่งทดแทน VPN ของไซต์ที่ชอบด้วยกฎหมาย โดยต้องบังคับใช้ข้อจำกัดจริง ไม่ใช่แค่วาดไว้ความล้มเหลวที่พบบ่อยคือตัวรับฟังทางเลือกที่ไม่มีใครจำได้: บริการที่ยังผูกกับทุกอินเทอร์เฟซ กฎของกลุ่มความปลอดภัยที่เปิดให้ผู้รับเหมา พอร์ตบริหารที่เข้าถึงได้จากอินเทอร์เน็ต
ตรวจตัวรับฟัง ไม่ใช่แผนภาพบนโฮสต์ ให้ระบุสิ่งที่ผูกอยู่จริงด้วย ss -ltnp และยืนยันว่าพอร์ตบริหารอยู่บนที่อยู่ส่วนตัวในคอนโซลคลาวด์ ให้อ่านกฎขาเข้าของซับเน็ตเวิร์กโหลดงาน และมองหา 0.0.0.0/0 บนสิ่งใดก็ตามที่เป็นการบริหารจากนั้นลองเชื่อมต่อจากภายนอกเส้นทางส่วนตัว เพราะการทดสอบนั้นคือสิ่งที่ตอบคำถาม
กฎเดียวที่เปิดให้ทั้งโลกบน SSH ทำให้ข้อโต้แย้งทั้งหมดของการออกแบบอุโมงค์เป็นโมฆะ
เขียนแผนที่ก่อนเปรียบเทียบการออกแบบ
สำหรับแต่ละแถวของบัญชีทรัพย์สิน ให้บันทึกว่าใครอนุมัติตัวตน ใครอัปเดตกฎการเข้าถึง ใครลบข้อมูลรับรองเมื่อมีคนออกไป และใครดูแลการกู้คืนเมื่อเส้นทางเองพังสี่ชื่อต่อแถวก็เพียงพอที่จะเปิดเผยแถวที่คำตอบคือบัญชีที่ใช้ร่วมกันและหน้าวิกิที่เก่าสามปี
จากนั้นตรวจสอบการอนุญาตหนึ่งรายการและการปฏิเสธหนึ่งรายการต่อช่องทางการอนุญาตพิสูจน์ว่าตัวตนที่ตั้งใจสามารถไปถึงทรัพยากรผ่านเส้นทางที่ตั้งใจการปฏิเสธพิสูจน์ว่าตัวตนที่คล้ายกันไปไม่ถึง และนี่คือการทดสอบที่ผู้คนข้ามไป นั่นคือเหตุผลที่ตัวรับฟังทางเลือกอยู่รอดจากการตรวจสอบเปรียบเทียบการออกแบบที่เสนอกับผลลัพธ์เหล่านี้ ไม่ใช่กับการตั้งค่า TLS ของแอป ซึ่งไม่เคยทดสอบสักรายการเดียว
ที่ซึ่ง VPN ของไซต์ยังคงคุ้มค่ากับที่ของมัน
อุโมงค์หรือเกตเวย์แคบคือคำตอบที่ถูกต้องเมื่อทรัพยากรไม่มีการพิสูจน์ตัวตนของตัวเองต่อคำขอ: พอร์ตบำรุงรักษาฐานข้อมูล ปลายทางสำรองข้อมูล คอนโซลไฮเปอร์ไวเซอร์ การบริหารนอกแบนด์ตัวรับฟังเหล่านั้นไว้วางใจเครือข่าย เครือข่ายจึงต้องเป็นสิ่งที่พิสูจน์ตัวตนผู้เรียก
ไม่ใช่คำตอบเดียวเกตเวย์ที่สิ้นสุดการอนุญาตต่อทรัพยากรสามารถแคบกว่าอุโมงค์ทั้งซับเน็ต และทิ้งร่องรอยการตรวจสอบที่ดีกว่าฮอสต์กระโดดที่ใช้ร่วมกัน
ลำดับงาน: ทำบัญชีทรัพย์สินให้เสร็จ ปิดทางเลือก ตรวจสอบการปฏิเสธหนึ่งรายการต่อแถว แล้วจึงเลิกใช้อุโมงค์ถ้าแถวใดสร้างการปฏิเสธไม่ได้ ให้เก็บเส้นทางส่วนตัวไว้จนกว่าจะทำได้