لماذا تستضيف خزنة كلمات المرور بنفسك
مدير كلمات المرور في قلب حياتك الرقمية. عندما تعيش الخزنة فقط على سحابة شخص آخر، تصبح الانقطاعات وتغيّر السياسات والاختراقات مخاطرك أنت. الاستضافة الذاتية تقلب الافتراض: أنت تختار الجهاز والنسخ الاحتياطي ومن يصل إلى الواجهة.
ما تتحكم به
| تملكه أنت | الخادم لا يحصل عليه أبداً |
|---|---|
| أين يُخزَّن النص المشفّر | كلمة المرور الرئيسية |
| متى تُجرى الترقيات والنسخ الاحتياطي | مفاتيح الخزنة بنص واضح |
أي العملاء يتصلون (CORS_ORIGINS، HTTPS) | أسماء أو كلمات مرور قابلة للقراءة |
| هل المزامنة مفعّلة أصلاً | مرفقات أو مشاركات مفكوكة التشفير |
يعمل تطبيق OpenKey دون اتصال بقاعدة بيانات محلية مشفّرة. وجّه الإعدادات ← البيانات ← خادم مستضاف ذاتياً إلى نسختك عندما تريد مزامنة متعددة الأجهزة — نفس قواعد المعرفة الصفرية في الحالتين. يُفضَّل الإبقاء على نسخة احتياطية محلية مشفّرة واحدة على الأقل؛ الخادم لا يستطيع استعادة كلمة مرور رئيسية منسية.
شكل عملي
يبدأ كثيرون بـ Docker على NAS منزلي أو VPS صغير:
cd openkey_server
cp .env.example .env
openssl rand -hex 32 # JWT_SECRET (32 حرفاً على الأقل؛ القيم النائبة مرفوضة)
docker compose up --build -dضع TLS أمامه (Caddy أو Traefik أو وكيلك العكسي)، عيّن JWT_SECRET طويلاً وفريداً، وقيّد CORS_ORIGINS لأصول تطبيقك والإضافة — ولا تستخدم * أبداً. ثم سجّل من الجهاز الأول وسجّل الدخول من الباقي، واستخدم زامن الآن عندما تريد دفعاً/سحباً صريحاً.
شبكة محلية بلا خادم
إن احتجت أجهزة على شبكة Wi‑Fi نفسها فقط، يمكن لمزامنة خزنة Nearby (Pro) الاقتران وربط الخزائن على الشبكة المحلية دون PostgreSQL. استخدمها للراحة؛ واحتفظ بنسخ احتياطية دون اتصال للطوارئ.
لمن هذا
- أفراد يريدون المزامنة دون خزنة SaaS
- فرق تحتاج مجموعات مشتركة مع إبقاء التشفير على العملاء
- مطورون يشغّلون PostgreSQL مسبقاً ويرتاحون لـ Compose
لا تحتاج الاستضافة الذاتية لاستخدام OpenKey محلياً. تستضيف ذاتياً عندما تريد مستوى مزامنة خاصاً بك — مع تخزين النص المشفّر فقط كقاعدة صارمة.
الخطوات التالية
- تثبيت الخادم — التثبيت والضبط وربط العملاء
- استخدام التطبيق — سير عمل الخزنة و Nearby والاستيراد/التصدير
- الأمان — قائمة التحصين ونموذج التهديد
- نظرة عامة — الحزم ونموذج المعرفة الصفرية