تشفير القرص الكامل على VPS: LUKS والفتح عن بُعد

ما الذي يستطيع مزوّدك رؤيته فعليًا

ابدأ بالفيزياء لا بالسياسة، لأن السياسة يمكن أن تتغيّر بينما الفيزياء لا تتغيّر. على أي آلة افتراضية، تعيش صورة القرص على عتاد ركّبه شخص آخر. وإن لم تكن تلك الصورة مشفّرة، فهي قابلة للقراءة من قِبل أي شخص ينتهي به الأمر ممسكًا بوحدة التخزين: مشغّل يملك وصولاً إلى الـ hypervisor، أو فني يستبدل قرص NVMe معطوبًا من زوج RAID-1، أو أيًا كان من يستلم ذلك القرص في النهاية عند التخلص منه، و — في الحالة التي يسأل عنها الجميع فعليًا — أي شخص يصل بأمر ملزم صادر عن محكمة ذات اختصاص قضائي على الجهاز. لا شيء من هذا يستلزم سوء نية أو بابًا خلفيًا (backdoor). وحدة التخزين غير المشفّرة هي ببساطة ملف، والملفات يمكن نسخها.

الطبقة الثانية هي الذاكرة. خطط VPS لدينا تعتمد على افتراضية كاملة (full virtualization) بتقنية KVM، فأنت تُشغّل نواتك (kernel) الخاصة بدلاً من مشاركة نواة — لكن الـ hypervisor يبقى مالكًا لذاكرة الوصول العشوائي (RAM) التي يمنحها لك، وبإمكان أي hypervisor من الناحية التقنية فحص ذاكرة نظام ضيف (guest). أما الطبقة الثالثة فهي كل ما لا يلامس القرص إطلاقًا: حركة المرور الخارجة من واجهة شبكتك، والبيانات الوصفية (metadata) التي يُصدرها تطبيقك، ونطاقات DNS التي تحلّها. على مستوى الحساب، نحتفظ بأقل قدر ممكن عن قصد — تجزئة (hash) كلمة المرور بخوارزمية argon2id، ورصيدك وسجله (ledger)، ومواصفات الطلبات، وسجلات الوصول التي تُدوَّر كل 14 يومًا، دون أي اسم أو عنوان أو رقم هاتف أو بطاقة في أي مكان فيها، كما هو مفصّل في صفحة سياسة عدم اشتراط KYC. الاحتفاظ بلا شيء عن هويتك ضمانة مختلفة عن العجز عن قراءة قرصك، وواحدة فقط من هاتين الضمانتين هي ما يمكنك فرضه بنفسك.

ما الذي يُصلحه التشفير الكامل للقرص، وما الذي لا يُصلحه

التشفير الكامل للقرص هو ضابط لحماية البيانات في حالة السكون. وهو يغطي بالضبط السيناريوهات المذكورة أعلاه التي تنتقل فيها وحدة التخزين من يد إلى أخرى بينما الجهاز مطفأ أو تُؤخذ النسخة دون اتصال: قرص أُخرج من الخدمة أو أُعيد ضمن RMA، أو قرص مصوَّر (imaged)، أو وحدة تخزين مستنسخة من طبقة التخزين، أو لقطة (snapshot) باردة سُحبت من تحتك. في كل هذه الحالات، تكون حاوية LUKS المشفّرة كتلة معتمة، ويحتاج من يحملها إلى عبارة مرور (passphrase) لم توجد يومًا إلا في ذهنك أو على حاسوبك المحمول. هذا حد فاصل حقيقي وصلب، وهو أكبر تحسين منفرد يمكن لمعظم الناس إدخاله على خادم مستأجَر.

من المهم بالقدر نفسه أن نكون صرحاء بشأن النصف الآخر. الخادم أثناء التشغيل يحتفظ بالمفتاح في RAM — وهذا ما يجعل نظام الملفات قابلاً للقراءة من قِبل عملياتك (processes) الخاصة — لذا لا يفعل التشفير شيئًا ضد اختراق حيّ يمنح صلاحيات root، أو عملية معادية داخل النظام الضيف، أو نسخة من الذاكرة (memory dump) تُؤخذ والجهاز يعمل، أو hypervisor يفحص تلك الذاكرة. كما أنه لا يشفّر ما يخرج عبر منفذ الشبكة، ولا يفيد إن كان تطبيقك يكتب أسرارًا في سجل (log) ترسله لاحقًا إلى مكان آخر. وإذا كان نموذج التهديد الخاص بك يستبعد فعليًا تفحّص الـ hypervisor، فالجواب الصادق ليس خوارزمية تشفير أفضل: بل خوادم مخصصة ابتداءً من $66.00/شهريًا، حيث لا يوجد أي hypervisor فوقك إطلاقًا. أما في كل ما دون ذلك، فإن التشفير في حالة السكون مع مزوّد لا يحتفظ إلا بأقل القليل يغطي الحالات الواقعية — والمصطلحات المستخدمة هنا معرّفة في القاموس المصطلحي.

وحدة تخزين مشفّرة، أم جذر مشفّر؟

هناك تصميمان يناسبان حالتين مختلفتين. الأول هو وحدة تخزين بيانات مشفّرة: يبقى نظام التشغيل صريحًا (غير مشفّر) بينما تضع كل ما يهم — حالة تطبيقك، وقاعدة بياناتك، ومخزن مستنداتك، ومفاتيحك — داخل حاوية LUKS مثبَّتة (mounted) عند مسار من اختيارك. هذا التصميم قابل للتركيب على خادم قيد التشغيل الفعلي (production) بالفعل، ولا يعطّل أبدًا إعادة الإقلاع، ويحمي المواد التي يرغب أي شخص فعليًا في الوصول إليها. أما ما يتركه قابلاً للقراءة فهو هيئة النظام: قائمة حزمك، ووحدات systemd الخاصة بك، ومضيفات nginx الافتراضية (vhosts)، وسجل أوامر الصدفة (shell history)، وسجلاتك.

أما الثاني فهو الجذر المشفّر، حيث يكون كل شيء داخل الحاوية باستثناء قسم إقلاع صغير. لا شيء في الجهاز يصبح مقروءًا وهو مطفأ، وهذه هي النتيجة التي يتخيّلها معظم الناس حين يقولون إنهم يريدون خادمًا مشفّرًا. لكن الثمن يُدفع عند كل إقلاع: تتوقف إعادة الإقلاع تمامًا عند طلب عبارة مرور (passphrase) على طرفية (console) لا يمكنك رؤيتها، إلى أن تمنحه وسيلة لسؤالك عن بُعد. وهذا هو السبب الكامل وراء وجود القسم التالي. كقاعدة عامة — شفّر الجذر عندما تبني خادمًا من الصفر ويمكنك اختباره قبل أن يحمل أي شيء؛ وشفّر وحدة تخزين بيانات عندما يكون الخادم قائمًا بالفعل ويكون التوقف مكلفًا. التحويل أثناء التشغيل لجذر حيّ باستخدام cryptsetup reencrypt ممكن على LUKS2، لكنه ليس أمرًا ننصح بفعله على خادم قيد التشغيل الفعلي لا يمكنك إعادة بنائه.

الفتح عن بُعد: خادم SSH صغير داخل الـ initramfs

الحيلة التي تجعل الجذر المشفّر عمليًا على جهاز بعيد هي dropbear-initramfs. الـ initramfs هو النظام المصغّر الذي تفكّ النواة (kernel) ضغطه قبل أن يوجد الجذر الحقيقي؛ ولأنك تملك النواة على VPS يعمل بتقنية KVM، يمكنك وضع خادم SSH صغير جدًا (daemon) بداخله. عند الإقلاع، يرفع الجهاز واجهة شبكته، ويشغّل تلك الخدمة (daemon)، وينتظر. تتصل، وتُشغّل أمرًا واحدًا، فتفتح عبارة المرور الحاوية، ويستمر الإقلاع إلى النظام الحقيقي، وتختفي الخدمة الصغيرة. من الخارج، يبدو الأمر كخادم يستغرق ثلاثين ثانية إضافية وإجراءً واحدًا متعمَّدًا كي يعود.

هناك تفصيلان يتسبّبان في معظم الألم تقريبًا. الأول أن خادم SSH الخاص بـ initramfs له مفتاح مضيف (host key) خاص به، يختلف عن ذلك الذي يقدّمه النظام العامل على العنوان نفسه — لذا إن تركته على المنفذ 22 فسيرفض عميلك الاتصال الثاني بسبب تعارض في مفتاح المضيف في كل مرة دون استثناء. امنحه منفذًا منفصلاً وملف known_hosts منفصلاً، وتختفي المشكلة. أما الثاني فهو المهلة الزمنية (timeout): لا ينبغي للخدمة أن تنتظر إلى الأبد إن كنت نائمًا، لكن لا ينبغي لها أيضًا أن تستسلم قبل أن تتمكن من الوصول إلى طرفية. خمس دقائق قيمة افتراضية معقولة. قيّد المفتاح بحيث لا يقدر على فعل شيء سوى الفتح، وعامِل عنوان مستمع الإقلاع (boot listener) هذا على أنه شيء لا تنشره — النزعة نفسها التي تسري عبر إبقاء اسمك بعيدًا عن الخادم.

فتحات المفاتيح، والترويسات، والعطل الذي يصطدم به الجميع

حاوية LUKS2 لا تشفّر بياناتك بعبارة مرورك مباشرة. بل تشفّر مفتاحًا رئيسيًا (master key) بعبارة مرورك، وتخزّن تلك النسخة الملفوفة في فتحة مفتاح (key slot) داخل الترويسة (header)، ثم تشفّر وحدة التخزين بالمفتاح الرئيسي. والنتيجة تستحق أن تُستوعب جيدًا: هناك عدة فتحات، لذا يمكنك تسجيل عبارة مرور ثانية أو ملف مفتاح (keyfile) دون إعادة تشفير بايت واحد، ويمكنك إلغاء إحداها دون المساس بالأخريات. أما النتيجة الأخرى فأكثر حدّة — الترويسة هي البيانات. اكتب فوق أول بضعة ميغابايتات من تلك الوحدة وتختفي كل الفتحات دفعة واحدة، مع أي احتمال للاسترجاع. انسخ الترويسة احتياطيًا، بعيدًا عن الجهاز، لحظة إنشاء الحاوية، ثم مجددًا كلما أضفت مفتاحًا أو أزلته.

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

التسريبات على الأطراف: مساحة التبديل (swap) واللقطات والنسخ الاحتياطية

جذر مشفّر مع قسم swap غير مشفّر هو قفل على باب مع نافذة مفتوحة — فالنواة سترحّل (page out) أي شيء، بما في ذلك مواد المفاتيح، إلى ذلك الـ swap. الحل هو إعادة توليد مفتاح الـ swap عشوائيًا من /dev/urandom عند كل إقلاع، وهذا لا يكلّف شيئًا لأن الـ swap لا يحتاج أبدًا إلى النجاة من إعادة الإقلاع. عامِل /tmp بالمعاملة نفسها عبر tmpfs حيثما أمكن، وعطّل السُّبات (hibernation) على الخادم، وفكّر في خيار discard قبل تفعيله: تمرير TRIM إلى طبقة التخزين مفيد للقرص لكنه يسرّب نمط الكُتَل (blocks) المستخدمة، وهو إفصاح صغير لكنه حقيقي عن مدى امتلاء وحدة تخزينك وأين.

النسخ الاحتياطية تستحق تفكيرًا خاصًا بها، لأن النسخة الاحتياطية هي أصلاً نسخة من بياناتك في مكان آخر لا يصل إليه التشفير الذي أعددته للتو. تُخزّن إضافة النسخ الاحتياطية المشفّرة اليومية لدينا لقطات خارج الخادم (off-host) على خطط VPS، أما اللقطات (snapshots) اليدوية — التي تعيش على الخادم نفسه — فهي وسيلة راحة للتراجع (rollback) لا نسخة احتياطية، كما تذكر الأسئلة الشائعة. إن كنت تعتبر المزوّد ضمن نطاق نموذج التهديد لديك، فشفّر من جهة العميل (client-side) قبل أن يغادر أي شيء الجهاز، بمفتاح غير مخزَّن عليه. هذه العادة الواحدة تجعل أيضًا مسار الاستعادة قابلاً للنقل: النسخة الاحتياطية التي لا يستطيع قراءتها سواك هي نسخة يمكنك استعادتها في أي مكان، بما في ذلك على خطة VPS مختلفة في منطقة مختلفة.

أين يقع التشفير ضمن نموذج التهديد الخارجي

التشفير هو أحد ثلاثة ضوابط تفشل كل منها بشكل مستقل، وهذا بالضبط سبب كون استخدام الثلاثة معًا ليس هوَسًا بل هندسة اعتيادية. الأول هو ما يعرفه المضيف عنك — لا شيء، حين يكون الحساب اسم مستخدم يموَّل برصيد مسبق الدفع بالعملات الرقمية ابتداءً من $30.00، عبر 8 عملة وصيغة شبكة تغطي 7 عملة، دون بطاقة ودون مستند في السلسلة؛ وهذا موضوع الدفع مقابل الاستضافة بشكل مجهول. الثاني هو قانون مَن ينطبق، وهو ما يُحدَّد بموقع الجهاز لا بموقعك أنت، ويُبحث منطقة بمنطقة في أي موقع استضافة خارجي عليك اختياره؟ وقانونيًا في مقارنة الولايات القضائية للاستضافة الخارجية.

الثالث هو ما هو قابل للقراءة في حالة السكون، وهذا وحده من مسؤوليتك أنت — لا يستطيع أي مزوّد أن يتكفّل به نيابة عنك، لأن مزوّدًا يحتفظ بمفتاحك لم يحلّ المشكلة التي كنت قلقًا بشأنها أصلاً. كدِّسها معًا فتغطي كل واحدة عطلاً مختلفًا: تسرّب الهوية لا يكشف القرص، والمفاجأة القضائية لا تُسلّم عبارة مرور، والقرص المسروق لا يُفصح عن اسمك. هناك 6 مناطق للاختيار من بينها عبر مواقعنا، مع خادم VPS يعمل خلال نحو 15 min؛ وعلى خوادم مخصصة، تُسلَّم إليك خلال 2–12 h مع بيانات اعتماد IPMI، يمكنك الذهاب إلى أبعد من ذلك وإقلاع مثبِّتك (installer) الخاص بك بدلاً من الوثوق بصورة (image) يوفرها المزوّد على الإطلاق.

الأداء، والخوادم التي لا تستحق التشفير

مسألة الأداء يحسمها العتاد في معظمها. كل خادم VPS في الأسطول يعمل على معالج AMD EPYC 9354 مزوَّد بـ AES-NI، لذا تنقل aes-xts-plain64 البيانات بمعدل عدة غيغابايتات في الثانية لكل نواة (core) — أبعد بكثير مما يطلبه أي حِمل عمل منفرد من مصفوفة NVMe RAID-1. شغّل cryptsetup benchmark على خادمك واقرأ الأرقام بدلاً من الوثوق بتدوينة، بما فيها تدويناتنا نحن. العبء الذي يمكنك قياسه فعليًا يظهر في زمن الاستجابة (latency) لا في الإنتاجية (throughput)، وفقط على أحمال العمل المقيَّدة أصلاً بـ fsync: قاعدة بيانات علائقية كثيفة الكتابة، أو صندوق بريد مزدحم، أو طابور يُثبّت كل رسالة. أما بالنسبة لخادم ويب، أو خلفية تطبيق، أو نقطة نهاية VPN، أو مخزن ملفات، فالتكلفة تُقرَّب إلى الصفر.

السؤال الأجدى هو أي الأجهزة لا تستحق هذا الجزء المتحرك الإضافي. الخادم الذي لا يحمل أي حالة خاصة لا يكسب شيئًا من التشفير ويكسب في المقابل إعادة إقلاع لا يمكن أن تكتمل دون إشراف — مرآة (mirror) ثابتة عامة، أو عقدة تخزين مؤقت (cache)، أو مرحل Tor أوسط سرّه الوحيد مفتاح هوية يمكنك تدويره في دقيقة. شفّر حيث يوجد ما يمكن خسارته: قاعدة البيانات، ومخزن البريد، وهدف النسخ الاحتياطي، والجهاز الذي يُنهي نفق WireGuard الخاص بك ويحمل مفاتيحه الخاصة. قرّر لكل خادم على حدة، لا للأسطول ككل، ودوِّن أيّها يستحق التشفير وأيّها لا — فالمشغّل بعد ستة أشهر من الآن هو أنت، بسياق أقل ونوم أسوأ.

خطوة بخطوة

1. 01

   حدِّد ما الذي تحميه، واختر التصميم

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

2. 02

   انشر VPS جديدًا وعزِّز أمانه قبل أي شيء آخر

   انشر من لوحة التحكم — يعمل VPS خلال نحو 15 min — ونفّذ العمل المُمل أولاً، على خادم نظيف، بينما لا يزال الخطأ لا يكلّف شيئًا. SSH بالمفاتيح فقط، وجدار حماية بسياسة رفض افتراضية، وتحديثات أمنية تلقائية، وتثبيت cryptsetup.

   apt update && apt full-upgrade -y
   apt install -y cryptsetup ufw unattended-upgrades
   ufw allow OpenSSH
   ufw enable

3. 03

   أنشئ حاوية LUKS2 وضع نظام ملفات بداخلها

   بالنسبة لوحدة تخزين بيانات، الحاوية المدعومة بملف (file-backed) هي الخيار الأقل تدخلاً، وتتصرف تمامًا مثل أي قسم. حدِّد حجمها بحسب ما تحمله، لا بحسب حجم القرص. اختر عبارة مرور يمكنك كتابتها من الذاكرة تحت الضغط — فهذه ليست كلمة مرور ستلصقها من مدير كلمات مرور على جهاز لم يُقلع بعد.

   fallocate -l 40G /var/lib/vault.img
   cryptsetup luksFormat --type luks2 /var/lib/vault.img
   cryptsetup open /var/lib/vault.img vault
   mkfs.ext4 /dev/mapper/vault
   mkdir -p /srv/vault && mount /dev/mapper/vault /srv/vault

4. 04

   سجِّل مفتاحًا ثانيًا وانسخ الترويسة احتياطيًا بعيدًا عن الجهاز

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

   cryptsetup luksAddKey /var/lib/vault.img
   cryptsetup luksHeaderBackup /var/lib/vault.img \
     --header-backup-file /root/vault-header.img
   cryptsetup luksDump /var/lib/vault.img

5. 05

   بالنسبة لجذر مشفّر، ثبِّت خادم SSH الخاص بـ initramfs

   هذه الخطوة ذات صلة فقط إن كان الجذر نفسه مشفّرًا. ضع مفتاحك العام حيث سيجده الـ initramfs، وانقل المستمع بعيدًا عن المنفذ 22 حتى لا يتعارض أبدًا مع مفتاح المضيف الحقيقي، وفعّل الواجهة عبر DHCP، ثم أعد البناء. تغيّرت المسارات في Debian 12: يصبح المسار /etc/dropbear/initramfs/ هناك، مقابل /etc/dropbear-initramfs/ على Debian 11.

   apt install -y dropbear-initramfs
   cat ~/.ssh/id_ed25519.pub > /etc/dropbear/initramfs/authorized_keys
   echo 'DROPBEAR_OPTIONS="-p 2222 -s -j -k -I 300"' \
     >> /etc/dropbear/initramfs/dropbear.conf
   echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
   update-initramfs -u -k all

6. 06

   أعد الإقلاع عمدًا، بينما الخادم لا يزال فارغًا

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

   reboot
   ssh -p 2222 -o UserKnownHostsFile=~/.ssh/known_hosts.boot root@203.0.113.10
   # inside the initramfs:
   cryptroot-unlock

7. 07

   أغلق الأطراف ودوِّن خطة الاسترداد

   أعد توليد مفتاح الـ swap عشوائيًا من /dev/urandom حتى لا تنجو أي صفحة مُرحَّلة من إعادة الإقلاع، وأبقِ السُّبات معطَّلاً، وشفّر النسخ الاحتياطية من جهة العميل قبل أن تغادر الجهاز. ثم دوِّن دليل تشغيل الاسترداد (runbook) — أين تعيش نسخة الترويسة الاحتياطية، وأي فتحة هي أيّ مفتاح، ومسار إعادة النشر والاستعادة الذي ستتبعه حين لا يكون الفتح خيارًا متاحًا. الخطة التي لم تدوّنها هي خطة لا تملكها.

   # /etc/crypttab — swap re-keyed at every boot
   swap  /dev/vda3  /dev/urandom  swap,cipher=aes-xts-plain64,size=256