تشفير الاتصال في Firebird 3 وشبكة VPN حدّان مختلفان
شبكة VPN عاملة لا تقول شيئًا عن من يحق له فتح مستمع Firebird أو عمّا تفاوض عليه العميل. افحص قابلية الوصول والمصادقة وتشفير الاتصال كلًا على حدة.
تتصل شبكة 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;
شغّله عبر اتصال التطبيق نفسه، لا عبر جلسة مسؤول على الخادم نفسه. الارتباط الإداري المشفر لا يقول شيئًا عن جلسة مكتبة عميل أخرى، وبناء أقدم لا يدعم المتغير ليس دليلًا على أن التشفير معطّل.
سجّل إصدار مكتبة العميل وبناء الخادم والنتيجة معًا، لأن أيًا منها منفردًا غير مقروء.
الصلاحيات ومسار الترقية
تقييد المصادر وتشفير النقل لا يحلّان محل المصادقة أو صلاحيات أقل امتياز. افحص أذونات مستخدم قاعدة البيانات العادي على الكائنات التي يلمسها فعليًا.
أخيرًا، عامل النشر طويل الأمد كمسألة صيانة. النفق لا يجعل مكتبة عميل قديمة آمنة إلى ما لا نهاية، ومسار ترقية مدعوم أرخص من اكتشاف أن الإضافة التي تحتاجها قد أُزيلت.