هل ينبغي أن تكون خزانة Vaultwarden عبر VPN فقط؟ ثلاثة شروط

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

الشرط 1: يستطيع مستخدموك الوصول إلى الخادم في اليوم الأول

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

غالباً ما يكون النفق المنقسم أنسب هنا: انقل فقط نقطة نهاية الخزانة ومسار DNS الذي تحتاجه، واترك بقية حركة المستخدم كما هي. وهذا قرار توجيه يُتخذ مع مالك VPN، وليس افتراضاً بأن كل عميل محمول يحترم السياسة نفسها. ويجب أن تتوافق عائلتا العناوين واسم مضيف الخدمة مع هذا الاختيار.

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

الشرط 2: الوصول المخبأ للقراءة فقط، وهذا يكفي

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

curl -sI https://vault.example.com/alive
openssl s_client -connect vault.example.com:443 -servername vault.example.com </dev/null

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

النسخة المخبأة ليست نسخة احتياطية. فهي تعيش على جهاز واحد، وترتبط بحساب واحد، وتختفي مع تسجيل الخروج أو المحو.

الشرط 3: لا تمر الاستعادة عبر الخزانة نفسها

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

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

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

ما تحتفظ به في كل الأحوال: HTTPS والنسخ الاحتياطية والتحديثات

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

النسخ الاحتياطي انضباط منفصل عن الإتاحة. ويخزن Vaultwarden بياناته في قاعدة بيانات، والنسخة المتسقة المأخوذة والخدمة متوقفة، أو نسخة على مستوى قاعدة البيانات، تساوي أكثر من ملف منسوخ من عملية قيد التشغيل. أبقِ النسخة خارج مضيف الخزانة واختبر استعادة. وتحتاج مادة الخزانة المصدَّرة الحماية نفسها التي يحتاجها الأصل، لأن التصدير غير مشفَّر كما هو تخزين الخادم.

sqlite3 /data/db.sqlite3 ".backup '/backup/vault-2026-11-03.sqlite3'"
docker compose ps

ثم أبقِ الخادم والعملاء محدَّثين. فالوصول عبر VPN فقط يقلل التعرض؛ لكنه لا يجعل تطبيقاً فيه ثغرة غير مؤذٍ، ولا يحمي نقطة نهاية مخترقة. والشروط الثلاثة تحدد نموذج الوصول، والصيانة تحدد ما إذا كان ذلك النموذج يصمد للعام.