تشفير القرص الكامل على VPS

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

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

ما الذي يحميه فعليًا التشفير أثناء السكون

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

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

لماذا لا يشبه VPS جهاز لابتوب

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

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

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

الترتيبات الثلاثة الجديرة بالنشر

لا يوجد إعداد واحد صحيح — بل يوجد الإعداد الذي يمكنك تحمّل نمط فشله. هذه الترتيبات الثلاثة تغطي عمليًا كل حالة حقيقية.

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

تشفير وحدة بيانات على VPS يعمل

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

• ثبّت الأدوات. apt install cryptsetup. إذا منحتك خطتك جهاز كتلة (block device) ثانٍ، استخدمه مباشرة وتجاوز الخطوة التالية.
• أنشئ حاوية. على VPS بقرص واحد، الطريق العملي هو ملف: fallocate -l 40G /var/lib/vault.img. يتصرف كقرص ويمكن توسيعه لاحقًا.
• هيّئه بصيغة LUKS2. cryptsetup luksFormat --type luks2 /var/lib/vault.img. اعتمد الإعدادات الافتراضية للشيفرة؛ يغطي القسم أدناه المعيار الوحيد الذي يستحق التعديل على خادم صغير.
• افتحه وأنشئ نظام ملفات عليه. يمنحك cryptsetup open /var/lib/vault.img vault جهاز /dev/mapper/vault؛ ثم mkfs.ext4 /dev/mapper/vault وmount /dev/mapper/vault /srv/vault.
• انقل البيانات المهمة، ثم وجّه الخدمات إليها. عادة ما يكون التحميل المرتبط (bind mount)، أو rsync مع إيقاف الخدمة، أنظف من الروابط الرمزية — فقواعد البيانات خصوصًا لا تحب أن تُتبَع أينما ذهبت.
• انسخ رأس LUKS احتياطيًا. cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin، ثم انقل ذلك الملف خارج الخادم. بضع كيلوبايتات تالفة في بداية الحاوية تدمّر كل بايت خلفها، نهائيًا، وهذا هو التأمين الوحيد الموجود.
• أغلقها وتحقق من قدرتك على العودة إليها. umount /srv/vault && cryptsetup close vault، ثم افتحها مجددًا من ملاحظاتك لا من ذاكرتك. افعل هذا قبل أن يوجد بداخلها أي شيء ذي قيمة.

بعد إعادة التشغيل تبقى الخزنة مغلقة حتى تسجّل الدخول وتفتحها. هذا ليس قيدًا يجب الالتفاف عليه — بل هو الغاية بأكملها. الوحدة التي تفتح نفسها هي وحدة يوجد مفتاحها على الجهاز.

تشفير كامل للجذر مع فتح عن بُعد عبر SSH

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

• ثبّت مشفّرًا من البداية. أقلع مثبّت التوزيعة عبر رفع صورة ISO مخصصة واختر التقسيم الموجَّه مع LVM مشفّر. تحويل نظام ملفات جذر يعمل بالفعل في مكانه أمر ممكن ولا يستحق المخاطرة.
• أضف خادم SSH لما قبل الإقلاع. apt install dropbear-initramfs، ثم ضع مفتاحك العام في /etc/dropbear/initramfs/authorized_keys. هذه مجموعة مفاتيح منفصلة عن SSH المعتاد لديك — استخدم مفتاحًا مخصصًا.
• أحكم إغلاقه. في /etc/dropbear/initramfs/dropbear.conf، اضبط DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s": بلا تسجيل دخول بكلمة مرور، بلا إعادة توجيه منافذ، منفذ خاص به، ومهلة خمول حتى لا تُبقي جلسة عالقة الإقلاع مفتوحًا.
• امنح الـ initramfs شبكة. أضف معامل ip= ثابتًا إلى GRUB_CMDLINE_LINUX في /etc/default/grub — الصيغة هي ip=address::gateway:netmask::interface:off. الاعتماد على DHCP في هذه المرحلة هو ما يجعل الناس ينتهون خارج النظام.
• أعد البناء وأعد التشغيل. update-initramfs -u && update-grub، ثم أعد التشغيل واتصل عبر ssh -p 2222 root@your-server وشغّل cryptroot-unlock. سيحذّرك عميلك من مفتاح مضيف مجهول: الـ initramfs له مفتاحه الخاص، وهذا متوقَّع ويستحق تثبيته في مُدخل known_hosts منفصل.
• اختبر مسار الفشل قبل أن تعتمد عليه. ثبّت تحديث نواة، أعد التشغيل، افتح القفل مجددًا. تحديثات النواة تعيد توليد الـ initramfs، وذلك بالضبط حين يظهر أي خطأ في الإعداد.

الإعدادان المهمّان، وفخ الـVPS الصغير

يعتمد LUKS2 افتراضيًا على AES-XTS بمفتاح 512 بت واشتقاق مفاتيح Argon2id. كلاهما صحيح. ضبط الشيفرة يدويًا طريقة لتكون أبطأ وأضعف في آن واحد، والإنترنت مليء بأسطر أوامر منسوخة تفعل ذلك بالضبط. لكن أمرين يستحقان انتباهك.

الأداء ليس مشكلة، إلى أن يصبح كذلك

تحقق من التسريع بالعتاد باستخدام grep -m1 -o aes /proc/cpuinfo وقِس الأداء بـ cryptsetup benchmark. على أي CPU يدعم AES-NI — وهذا كل عقدة نشغّلها — ينقل AES-XTS عدة غيغابايتات في الثانية لكل نواة، أعلى بكثير مما يوفّره قرص افتراضي واحد، بحيث تكون التكلفة الظاهرة نسبة بسيطة من CPU تحت إدخال/إخراج ثقيل وزيادة طفيفة في زمن الاستجابة. بدون AES-NI تنعكس الصورة ويصبح التشفير عنق الزجاجة؛ وهذه هي الحالة الوحيدة التي يكون فيها اختيار شيفرة بديلة قرارًا حقيقيًا لا تقليدًا أعمى.

ذاكرة Argon2id هي ما يعضّ

صُمم Argon2id عمدًا ليكون شرهًا للذاكرة، ويُعايره cryptsetup عند وقت التهيئة استنادًا إلى ذاكرة RAM في الجهاز الذي تُهيّئ عليه. هيّئ وحدة على محطة عمل بسعة 32 GB، وانقلها إلى VPS بسعة 1 GB، ويمكن أن يفشل الفتح تمامًا لأن الذاكرة التي يطلبها اشتقاق المفتاح غير موجودة — والأسوأ داخل الـ initramfs، حيث تتوفر ذاكرة أقل بكثير مما يتوفر في نظام يعمل. على الأجهزة الصغيرة، ثبّته عند حد معيّن: cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb يحدّه عند 256 MB. القيمة الأدنى تعني انخفاضًا حقيقيًا في مقاومة هجوم القوة الغاشمة غير المتصل، فعوّض عن ذلك بعبارة مرور أطول.

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

الذاكرة التبديلية، السجلات، اللقطات — الأجزاء التي ينساها الناس

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

• الذاكرة التبديلية (Swap). أي شيء في الذاكرة يمكن ترحيله إلى القرص، بما في ذلك المادة التي وضعتها بعناية في الخزنة. إما عطّل الذاكرة التبديلية، أو امنحها مفتاحًا عشوائيًا عند كل إقلاع بسطر في /etc/crypttab مثل swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256.
• كل ما يكتب حيث لم تنظر. /var/log، و/tmp، ودليل بيانات قاعدة البيانات، و/var/lib/docker، وتاريخ الصدفة، وسجلات systemd. تشفير /srv/vault بينما تكتب PostgreSQL إلى /var/lib/postgresql لا يحقق شيئًا على الإطلاق. عدِّد كل شيء قبل أن تشفّر.
• اللقطات (Snapshots). لقطة على مستوى الكتلة لوحدة مشفّرة هي نص مشفّر وبالتالي لا بأس بها. أما اللقطة التي تلتقط حالة الذاكرة فهي كائن مختلف تمامًا ويمكن أن تحتوي على المفتاح. اعرف أي نوع تلتقطه لوحة تحكم مزوّدك قبل أن تستخدمها.
• النسخ الاحتياطية. الوجهة هي المكان الخاطئ لحل هذه المشكلة. أدوات مثل restic وBorgBackup تشفّر عند المصدر بمفتاح لا تراه الوجهة أبدًا، ولهذا يمكن أن يكون خادم النسخ الاحتياطي جهازًا عاديًا في ولاية قضائية أخرى بدلًا من جهاز موثوق.
• النص الصريح الذي أرسلته بالفعل إلى مكان ما. التشفير أثناء السكون ليس رجعيًا. أي شيء نُسخ أو أُرسل بالبريد أو زُومن إلى مكان آخر بالفعل يقع خارج الحدود التي ترسمها الآن.

مكان إقامة المفتاح هو التصميم بأكمله

كل ترتيب مما سبق هو في الحقيقة تصريح بشأن عهدة المفتاح. توجد أربعة خيارات وهي غير متكافئة:

• في رأسك، يُكتب عند كل إقلاع. أقصى حماية، وأقصى احتكاك تشغيلي. لا يمكن قراءة الجهاز فعليًا دونك.
• في ملف على الجهاز المشفّر. يحمي من إعادة بيع قرص ساذجة ولا شيء غير ذلك. إذا كان ذلك الملف موجودًا على /boot النصي الصريح، فهو لا يحمي من شيء على الإطلاق — الخطأ الأكثر شيوعًا في التشفير المُدار ذاتيًا.
• على جهاز تتحكم فيه، يُجلب عبر الشبكة. Clevis مرتبط بخادم Tang: clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'. يقلع الخادم دون إشراف طالما يستطيع الوصول إلى المنزل، ويرفض الفتح في أي مكان آخر. ممتاز لأساطيل الأجهزة بلا شاشة، ويجعل مضيف Tang هو الشيء الذي يجب الدفاع عنه.
• في TPM. له معنى على عتاد تملكه. على VPS، يوفّر الـTPM الافتراضي المُراقب الافتراضي نفسه الذي تحاول استبعاده، لذا فهو يحل مشكلة الراحة لا مشكلة الثقة.

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

ما يستطيع مضيفك رؤيته، وأين تبدأ الولاية القضائية بالتحكم

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

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

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

تسعة أخطاء تحوّل التشفير إلى مجرد ديكور

• الفتح التلقائي من ملف مفتاح على القرص نفسه. غالبية الخوادم «المشفّرة»، وما يعادل ترك المفتاح في القفل.
• تشفير وحدة لا تصل إليها البيانات الحساسة أبدًا. الخزنة فارغة وقاعدة البيانات ليست بداخلها.
• عدم نسخ رأس LUKS احتياطيًا أبدًا. قطاع تالف واحد في مقدمة الحاوية وكل بايت خلفه يضيع نهائيًا.
• عدم اختبار مسار الفتح أبدًا. ثم يعيد تحديث للنواة توليد الـ initramfs، وتتحول إعادة التشغيل التالية إلى عملية إنقاذ.
• التهيئة على جهاز كبير والفتح على جهاز صغير. يطلب Argon2id ذاكرة لا يستطيع VPS توفيرها، ولن تُفتح الوحدة.
• اختيار عبارة مرور كأنها كلمة مرور تسجيل دخول. لا شيء يحدّ من معدل هجوم غير متصل باستثناء دالة اشتقاق المفتاح. الطول هو ما يشتري الوقت.
• ترحيل نص صريح إلى التشفير وافتراض أن الأصل قد اختفى. على التخزين الافتراضي، لا تمحو الكتابة فوق البيانات بشكل موثوق.
• إرسال عبارة المرور عبر القناة نفسها المستخدَمة لإدارة الجهاز. يتناول أمن التشغيل للخادم مشكلة الترابط التي يخلقها ذلك.
• الخلط بين تشفير مزوّدك وتشفيرك أنت. «كل البنية التحتية مشفّرة أثناء السكون» — بما فيها بنيتنا — يحمي البنية التحتية. مفتاح تملكه أنت وحده هو ما يحميك من البنية التحتية.

فهل يستحق الأمر القيام به على VPS؟

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

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