لماذا تحتاج مفاتيح الخادم وبيانات اعتماد المستخدم إلى مالكين منفصلين

المفتاح الذي يثبت أن بوابتك هي نفسها وبيانات الاعتماد التي تقول إن شخصًا ما يجوز له الانضمام سرّان كلاهما، وهنا ينتهي التشابه. أحدهما يعرّف خدمةً أمام كل عميل؛ والآخر يعرّف مستخدمًا واحدًا أمام تلك الخدمة. خلطهما يوفّر خطوة أثناء الإعداد ويكلّف ظهيرة كاملة أثناء حادث، لأن الاستعادة لكل منهما ليست العملية نفسها. الفصل مملّ في إعداده ولا يُنسى عند إهماله.

سرّان، مالكَان مختلفان

تحتفظ البوابة بمفتاح خاص أو شهادة وظيفتها الوحيدة إثبات هويتها أثناء المصافحة. يحتاج العملاء إلى المادة العامة المطابقة للتحقق منها، ولا يحتاجون أبدًا إلى النصف الخاص. هذا التفاوت هو ما يجعل مصادقة الخادم ممكنة دون منح كل مستخدم القدرة على انتحال الخادم.

مادة المستخدم تسير في الاتجاه الآخر. المفتاح الخاص للعميل أو شهادة العميل أو كلمة المرور تثبت أن هذا الشخص أو الجهاز بعينه مُنح حق الوصول. من المتوقع توزيعها ونسخها بين الأجهزة وإلغاؤها في نهاية المطاف.

يجعل WireGuard الفصل واضحًا لأن كل مشارك يملك زوج مفاتيح: يبقى المفتاح الخاص للخادم على الخادم، ويحتوي ملف الإعداد الذي تعطيه للمستخدم على مفتاحه الخاص بالإضافة إلى المفتاح العام للخادم. الملف الشخصي الذي يحتوي على المفتاح الخاص للخادم ليس اختصارًا، بل هو اختراق ينتظر مشاركة ملف.

ثلاثة أسئلة تحدّد الفصل

اسأل من يجب أن يستطيع قراءة السر، وما الذي يسمح به تسريبه للمهاجم، وهل الإصلاح إلغاء واحد أم إعادة بناء للخدمة.

إذا كان بإمكان مستخدم قراءته وكان يثبت هوية البوابة، فجواب السؤال الثاني أن المهاجم يستطيع انتحال خادمك أمام كل عميل — وهو أسوأ نتيجة، لأن العملاء مصممون على الثقة بتلك الهوية. وإذا كان يثبت مستخدمًا واحدًا فقط، فإن التسريب يمنح وصول ذلك المستخدم إلى نظير واحد، والإلغاء عملية روتينية. وإذا كان مفتاح سلطة شهادات، فالتسريب أسوأ من الحالتين، لأن المهاجم يستطيع إصدار هويات تثق بها كل نقطة نهاية.

تنتج تلك الأجوبة الثلاثة قاعدة التخزين: مفتاح CA يعيش دون اتصال أو في خزنة، ومفتاح البوابة يعيش على البوابة، ومفاتيح المستخدمين تعيش مع المستخدمين. وأي ترتيب يضع الثلاثة في دليل واحد من أجل الراحة يكون قد حوّل قرارًا إلى حادث.

ما يحتاجه العميل فعليًا

يحتاج العميل إلى الشهادة العامة أو مفتاح النظير العام، وإلى مادة CA أو بصمتها التي ينبغي أن يثق بها، وإلى مفتاحه الخاص، وإلى تفاصيل نقطة النهاية. ولا تحتوي تلك القائمة على أي شيء يخص الهوية الخاصة للبوابة.

التوثيق هو مكان هذا التسريب. الدليل الذي يقول انسخ دليل الخادم واحذف ما لا تحتاجه يكون قد علّم النموذج الخاطئ سلفًا، لأن الملف الذي يبقى بعد خطوة الحذف نادرًا ما يفحصه أحد.

ألغِ مستخدمًا واحدًا دون المساس بالبوابة

لأن هويات المستخدمين تُصدر منفصلة، يمكن سحبها منفصلة. النشر القائم على الشهادات يلغي شهادة العميل وينشر قائمة إلغاء محدّثة؛ ونشر WireGuard يزيل مدخل النظير من إعداد الخادم. ولا يغيّر أي من هاتين العمليتين مفتاح البوابة نفسه.

احتفظ بسجل الإصدار، وإلا لن تعرف أي هوية تسحب. جدول بيانات يكفي، بشرط أن يسمّي الشخص والجهاز والرقم التسلسلي أو المفتاح العام والتاريخ، وبشرط أن يملكه أحدهم بعد رحيل من بناه.

تفحص الأوامر أدناه شهادة عميل ثم تلغيها عبر سلطة على نمط OpenSSL، وهو التدفق الذي يغلّفه easy-rsa:

openssl x509 -in client.crt -noout -subject -serial
openssl ca -config openssl.cnf -revoke client.crt
openssl ca -config openssl.cnf -gencrl -out crl.pem

انشر القائمة الجديدة حيث يتحقق منها العملاء، وإلا فالإلغاء ملاحظة في ملف لا تغيّر شيئًا. وإذا كانت بوابتك تقبل شهادات العملاء دون الرجوع إلى قائمة إلغاء، فقل ذلك صراحةً بدلًا من الإيحاء بأن الإلغاء يعمل.

احفظ النسخ الاحتياطية منفصلة كفصل الأسرار

تحتوي أرشيف إعادة البناء شرعًا على مفتاح البوابة ومادة CA، لأنه بدونهما لا يمكن للاستعادة أن تعيد إنتاج الخدمة. أما حزمة إعداد العميل فلا يجوز أن تحتويهما، ولا يجوز تخزين الاثنين معًا. صنّف كل أرشيف حسب من يجوز له حمله، لا حسب تاريخ إنشائه. هذا التصنيف هو ما يقرأه مدير متعب في الساعة الثانية صباحًا.

هذا التمييز يحدّد أيضًا من يجوز له استرجاع كل منهما. إدارة البوابة وإصدار هويات المستخدمين وقراءة النسخ الاحتياطية ثلاث سلطات مختلفة، ومن يحتاج إحداها لا يحتاج الأخريين تلقائيًا. اكتب تلك الأذونات، ثم افحصها مقابل ما يسمح به تخزينك فعلًا، لأن وراثة الدلائل تمنح بصمت أكثر مما تقصده السياسة.