مدير كلمات المرور المستضاف ذاتياً: ما يتطلبه حقاً

الاستضافة الذاتية لمدير كلمات المرور تعني تشغيل خادم المزامنة المشفّرة بنفسك. يشفّر عميلاك على الجهاز؛ والخادم الذي تشغّله يخزّن النص المشفّر ويصادّقك. واختراق ذلك الخادم ينتج كتلة مشفّرة، لا قائمة كلمات مرور.

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

ما الذي تغيّره الاستضافة الذاتية فعلاً

كن دقيقاً هنا، فهنا الموضع الذي تخطّئ فيه التوقعات:

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

ادعاء السرّية لا يتغير. ما يتغير هو التحكم في مستوى التخزين ومن في سلسلة الثقة. الاستضافة الذاتية تزيل طرفاً ثالثاً؛ وهي لا تضيف تشفيراً.

متى يستحق ذلك

• أنت تشغّل خدمات بالفعل ولديك NAS أو مختبر منزلي أو VPS صغير.
• نموذج تهديدك يتضمّن «المزوّد مخترق أو مُكره عليه».
• أنت في ولاية قضائية يكون فيها استضافة بيانات شخص آخر عبئاً على من يقوم بها.
• تريد مجموعات مشتركة لفريق على بنية تحتية تدقّقها بنفسك.
• أنت من نوع الناس الذي يستمتع بتكوين Docker Compose من خمس دقائق ومهمة cron.

متى لا يستحق ذلك

• لم تشغّل وكيلاً عكسياً قط وستحتاج إلى تعلّم TLS و DNS وقواعد الجدار الناري أولاً.
• لن يتذكّر أحد الترقيع. الخادم غير المرقَّع عبء مسؤولية، لا مكسب أمني.
• أنت المستخدم الوحيد، على جهاز واحد. عندئذ تخطَّ الخادم تماماً واستخدم خزنة محلية.
• تحتاج توفّراً مضموناً لنظام بالغ الأهمية دون خطة نسخ احتياطي.

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

الضبط في خمس دقائق

OpenKey Server تطبيق FastAPI مع PostgreSQL، يُشحن كمكدس Docker Compose.

cd openkey_server
cp .env.example .env
openssl rand -hex 32      # paste this into JWT_SECRET in .env
docker compose up --build -d

ثم تأكّد أنه سليم:

العنوان	الغرض
http://localhost:8000	أساس API
http://localhost:8000/docs	توثيق OpenAPI
http://localhost:8000/health	فحص الصحة

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

قائمة التحصين

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

غير قابل للتفاوض

1. JWT_SECRET فريد من 32 محرفاً على الأقل. تُرفض القيم النائبة عند البدء. ولّد واحداً؛ لا تنسخ مثالاً.
2. HTTPS بشهادة صالحة. يستخدم العملاء مكدس TLS في المنصة دون تثبيت للشهادات، لذا فإن عنوان http:// مكتوب خطأً أو شهادة سيئة تتيح هجوماً على منتصف الاتصال عند تسجيل الدخول والمزامنة. أنهِ TLS عند Caddy أو nginx أو موازن الحمل لديك.
3. قائمة سماح صريحة لـ CORS_ORIGINS. أبداً *. إن كنت تستخدم إضافة المتصفح، فأضف أصلي chrome-extension:// و moz-extension:// صراحةً.
4. Postgres والمنفذ الخام لـ API يبقيان خاصين. لا تعرّض إلا الوكيل العكسي.
5. HSTS عند الوكيل، كي لا تسقط المتصفحات إلى HTTP أبداً بعد الزيارة الأولى.

موصى به بشدة

6. حدود معدل عند الوكيل العكسي. محدّد API المدمج موجود في الذاكرة ولكل عملية عامل، لذا مع عدة عمال أو نسخ يتضاعف الحد الفعّال. أضف limit_req في nginx أو حدود معدل في Caddy عند الحافة.
7. اضبط TRUST_PROXY_HEADERS=true فقط إذا كان الوكيل يكتب فوق X-Forwarded-For وأنت تثق بهذا المسار. وإلا فستنطبق حدودك لكل IP على الوكيل لا على المستخدم.
8. كن واعياً لاستكشاف عناوين البريد. يعيد POST /auth/prelogin و POST /auth/lookup-public-key خطأ 404 لعناوين البريد المجهولة، وهو ما يساعد العملاء الشرعيين لكنه يتيح لأحدهم استكشاف العناوين المسجّلة. ضع حدود معدل صارمة، و TLS، و VPN أو قائمة سماح بعناوين IP اختيارياً للنشرات عالية الحساسية.
9. انسخ Postgres واختبر الاستعادة. خادم مدير كلمات مرور لم تُستعد منه نسخة احتياطية قط ليس سوى فرضية.
10. راقب /health وسجلات API؛ ونبّه إن توقف عن الاستجابة.

ما يستطيعه خادم المزامنة المستضاف ذاتياً وما لا يستطيع

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

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

دلالات المزامنة التي ينبغي أن تعرفها قبل الاعتماد عليها

• آخر كتابة تفوز حسب revision لكل عنصر، وليست CRDT. التعديلات المتزامنة على جهازين قد تدهس بعضها. حرّر على جهاز واحد في كل مرة إن كان الأمر مهماً.
• تزامن عمليات الحذف كشواهد (tombstones) حتى تلحق الأجهزة القرينة، فالحذف ليس فورياً في كل مكان.
• مزامنة Nearby على LAN تستخدم قاعدة آخر-كتابة-تفوز نفسها بين الأجهزة المقترنة والمربوطة بالخزنة.
• لا شيء من ذلك نسخة احتياطية. احتفظ بنسخة احتياطية محلية مشفّرة واحدة على الأقل (.okbak في OpenKey).

النقطة الأخيرة هي التي يخطئ فيها الناس أكثر من غيرها، وهي الفرق بين «نقلت خزني إلى خادمي الخاص» و«لدي خطة استعادة».

الأمن التشغيلي للمشغّل

• شغّل الخادم على مضيف تُرقّعه وفق جدول. غير المرقَّع أسوأ من المستضاف لدى المزوّد.
• احتفظ بـ JWT_SECRET في مدير أسرار أو على الأقل في ملف بصلاحية 600، لا في سجل أوامرك.
• الاحتفاظ بالسجلات عبء مسؤولية: فسجلات المزامنة تكشف التوقيتات والأحجام. دوّرها وحدّها.
• انسخ قاعدة البيانات، لا المجلد فقط، وتحقّق من الاستعادة كل ثلاثة أشهر.
• لا تعرّض API أبداً على شبكة غير موثوقة بلا TLS.
• إن كنت تحتاج ضمانات توفر، ضع مضيفاً ثانياً خلف موازن حمل واقبل أن حل تعارض المزامنة يظل آخر-كتابة-تفوز.

كيف يبقى OpenKey الخادم عديمة الفائدة أمام المهاجم

• يشتق العملاء مفتاحاً رئيسياً بـ Argon2id من البريد + كلمة المرور الرئيسية + ملح.
• يرسل تسجيل الدخول auth_hash، وهو يثبت المعرفة دون كشف كلمة المرور.
• يشفّر مفتاح الخزنة أسماء المجموعات وحمولات الإدخالات بـ AES-256-GCM. ولا يخزّن الخادم سوى مفتاح خزنة ملفوف.
• رموز JWT للوصول قصيرة العمر؛ ورموز التحديث مجزّأة أثناء التخزين وتُدار بالتناوب عند الاستخدام.
• تُزامن المرفقات كنص مشفّر، بحد أقصى 20 MB لكل منها.

نسخة تفريغ مسروقة من postgres تعطي المهاجم الأملاح ومعاملات KDF والمفاتيح الملفوفة والكتل. وكسرها يعني مهاجمة Argon2id، ثم يظلون مع النص المشفّر الذي لا يستطيعون قراءته دون المفتاح. هذه هي حجة الأمان كاملة، وهي تصمد تحديداً لأن كلمة المرور الرئيسية لم تغادر عميلاً أبداً.

ما تقوله بيانات البحث

الاستضافة الذاتية عنقود صغير لكنه حقيقي، وهو يتجمّع حول عبارة «open source» أكثر مما يتجمّع حول «self-hosted». من Google Trends (عالمي، آخر 12 شهراً)، مقارنة هذه المصطلحات ببعضها:

الاستعلام	الاهتمام النسبي داخل العنقود
passbolt	100
open source password manager	55
password manager self hosted	13
self-hosted password manager	4
keepass alternative	1

الاستنتاج هو أن «open source» هي العبارة التي يلجأ إليها الناس، و«self-hosted» هي العبارة التي ينتهي إليها الأمر لاحقاً — بحث يبدأ كتفضيل ويصبح تنفيذاً. والاستعلامات ذات الصلة تحت «open source password manager» تشير إلى الاتجاه نفسه: KeePass عند 100، و«open source password manager self hosted» عند 84، وPassbolt عند 78. اثنان من أعلى ثلاثة أسماء يقارنها الناس، لا أوصاف لميزة.

وتبقى هذه أرقاماً صغيرة إلى جانب الكلمة الرئيسية. «self-hosted password manager» شريحة داخل شريحة، والاستنتاج الصادق أن معظم الباحثين عن هذه العبارة مستخدمون تقنيون يعرفون أصلاً ما يريدون.

المنهجية: Google Trends، عالمي، آخر 12 شهراً، سُحب في سبتمبر 2026. القيم اهتمام نسبي مُطبَّع (0–100)، وليست أحجام بحث.

النسخة في خمس دقائق

الاستضافة الذاتية تستبدل المزوّد بك في سلسلة الثقة. فهي لا تضيف تشفيراً، بل تضيف TLS والنسخ الاحتياطي والترقيع وحدود المعدل إلى قائمتك. إن كنت تشغّل خدمات بالفعل: مكدس Compose، و JWT_SECRET فريداً، و HTTPS بشهادة صالحة، و CORS_ORIGINS صريحة، ونسخاً احتياطية مختبَرة. وإن لم تكن كذلك، فاستخدم خزنة محلية مشفّرة ومزامنة Nearby على LAN بدلاً من ذلك، واحتفظ بنسخة احتياطية مشفّرة واحدة دون اتصال في الحالتين.

الخطوات التالية

• لماذا تستضيف خزنة كلمات المرور بنفسك — الحالة التي تقنعك بها
• شرح مزامنة بلا معرفة — البروتوكول
• إعداد الخادم — التثبيت والضبط والتحصين للإنتاج
• الأمان — نموذج التهديد وقائمة المشغّل