ย้ายเว็บแอปของบริษัทไปไว้หลัง VPN: คู่มือการตัดเปลี่ยน

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

ขั้นตอนที่ 1: จดบันทึกว่าผู้ใช้ทำอะไรในวันนี้

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

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

ขั้นตอนที่ 2: แยกอุโมงค์ออกจากการล็อกอิน

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

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

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

ขั้นตอนที่ 3: ค้นหาผู้เรียกที่ไม่ใช่พนักงาน

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

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

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

ขั้นตอนที่ 4: เลิกใช้เส้นทางสาธารณะ ไม่ใช่แค่ระเบียน DNS

ไล่ตามห่วงโซ่การเผยแพร่ ทั้ง DNS ตัวรับฟังของโหลดบาลานเซอร์ กฎพร็อกซีย้อนกลับ ไฟร์วอลล์ของโฮสต์ และชื่อทางเลือกใด ๆ ที่ยังชี้ไปยังที่อยู่เดิม ตรวจสอบทั้งสองตระกูลที่อยู่ การเปลี่ยนระเบียน A หลักแทบไม่พิสูจน์อะไรเลยหาก CNAME ที่เก่ากว่าหรือตัวรับฟัง IPv6 ยังให้บริการแอปอยู่

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

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

ขั้นตอนที่ 5: ตรวจรับด้วยตัวเอง

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

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

ขั้นตอนที่ 6: ซ้อมวันแย่ ๆ

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

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

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