อุปกรณ์ภาคสนาม TLS และ VPN: เส้นแบ่งไหนปกป้องอะไร

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

หากบอกไม่ได้ว่า TLS สิ้นสุดที่ใด ก็บอกไม่ได้เช่นกันว่าแอปพลิเคชันเชื่อถืออะไรจริง ๆ

ค้นหาว่า TLS สิ้นสุดที่ใดจริง ๆ

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

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

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

ตัดสินใจว่าอุปกรณ์ต้องพิสูจน์ตัวตนอะไร

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

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

ใช้ไลบรารีที่รองรับและแนวปฏิบัติปัจจุบัน แนวปฏิบัติสมัยใหม่สำหรับการติดตั้งใช้ TLS ห้ามเจรจา TLS 1.0 และ 1.1 และการอ้างถึง TLSv1 ในบันทึกการออกแบบเก่าไม่ใช่ข้อกำหนด

ปิดเมื่อแฮนด์เชกล้มเหลว

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

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

เขียนกฎการย้อนกลับ หากแฮนด์เชกล้มเหลว มันจะเชื่อมต่อใหม่โดยไม่มี TLS เป็นการตัดสินใจด้านการออกแบบ และควรชัดเจน

ให้ VPN ทำงานเท่าที่ทำได้เท่านั้น

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

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