ดูแล Raspberry Pi บน LAN โดยไม่มีลิงก์อินเทอร์เน็ต

อุปกรณ์สองเครื่องบน LAN ส่วนตัวสามารถแลกเปลี่ยนทราฟฟิกที่ได้รับการป้องกันได้โดยไม่ต้องมีอัปลิงก์เลย สิ่งที่ทำไม่ได้คือเสกบริการที่โมเดลความปลอดภัยที่เลือกไว้คาดหวัง งานจึงแบ่งครึ่งเป็นการเลือกและการทำบัญชี: เลือกการป้องกันที่เหมาะกับงาน แล้วจัดทำรายการทุกอย่างที่จะเอื้อมถึงอินเทอร์เน็ตอย่างเงียบๆ

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

เลือกการป้องกันตามงาน ไม่ใช่ตามความเคยชิน

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

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

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

จัดทำรายการสิ่งที่จะออกจาก LAN

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

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

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

เก็บการตรวจสอบอัตลักษณ์ไว้ในที่ที่ควรอยู่

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

เวลาสมควรมีบรรทัดของตัวเองในแผน โปรโตคอลจำนวนมากปฏิเสธข้อมูลรับรองที่ถูกต้องตามปกติเมื่อนาฬิกาเพี้ยนไปมากพอ และ Pi ที่ไม่มีแหล่งเวลาจากเครือข่ายอาจเพี้ยนไปอย่างเงียบๆ หลายเดือนก่อนจะมีใครบ่น

ทดสอบในขณะที่อัปลิงก์หายไปจริง

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

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