การเข้ารหัสสายของ Firebird 3 กับ VPN เป็นสองขอบเขตที่ต่างกัน

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

สองขอบเขตที่ไม่ทับซ้อนกัน

ขอบเขตของ VPN ปกป้องแพ็กเก็ตระหว่างไคลเอนต์กับเกตเวย์ การเข้ารหัสสายของ Firebird ปกป้องโปรโตคอลฐานข้อมูลระหว่างไลบรารีไคลเอนต์กับโปรเซสเซิร์ฟเวอร์ ทั้งสองอย่างมีอยู่ได้ และไม่มีอันใดแทนที่อีกอัน

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

ขอบเขตแรก: ใครเปิดตัวรับฟังได้

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

จากนั้นพิสูจน์ด้านลบ เส้นทางภายนอกที่ควรถูกปฏิเสธต้องยังคงถูกปฏิเสธ เพราะการเปิดอุโมงค์ไม่ได้จำกัดตัวรับฟังของ Firebird ด้วยตัวเอง

ขอบเขตที่สอง: Firebird เจรจาอะไร

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

ใน บันทึกประจำรุ่นของ Firebird 3 มีการระบุ Arc4 เป็นปลั๊กอินเข้ารหัสสายค่าเริ่มต้นสำหรับรุ่นนั้น Arc4 เป็นค่าเริ่มต้นเชิงประวัติศาสตร์ ไม่ใช่คำแนะนำสำหรับรหัสลับสมัยใหม่ และไม่ใช่สิ่งเดียวกับการป้องกัน VPN ชั้นนอก

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

กับดัก Legacy_Auth

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

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

ตรวจสอบการเชื่อมต่อที่สำคัญ

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

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

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

บันทึกเวอร์ชันไลบรารีไคลเอนต์ บิลด์เซิร์ฟเวอร์ และผลลัพธ์ไว้ด้วยกัน เพราะไม่มีสิ่งใดเพียงอย่างเดียวที่อ่านได้

สิทธิ์และเส้นทางการอัปเกรด

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

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