رمزنگاری یک VPS در نگاه اول یک دستور تکخطی به نظر میرسد — cryptsetup luksFormat، تمام — و بعد بیسروصدا همان چیزی را که مردم فکر میکردند خریدهاند تحویل نمیدهد. روی ماشینی که اجاره کردهاید، یک هایپروایزر زیر کرنل شما نشسته، پس مدل تهدید همان چیزی نیست که رمزنگاری کامل دیسک برای آن طراحی شده بود. این راهنما نسخهٔ صادقانهٔ ماجراست: LUKS روی یک VPS چه چیزی را واقعاً خنثی میکند، چه چیزی را نه، دو مسیر استقرار که واقعاً کار میکنند، و نحوهٔ باز کردن قفل یک root رمزنگاریشده روی SSH تا هرگز از سرور خودتان قفل نشوید.
رمزنگاری روی یک سرور اجارهای واقعاً چه چیزی به شما میدهد
رمزنگاری کامل دیسک از داده در حالت سکون (data at rest) محافظت میکند. این عبارت بار معنایی سنگینی دارد، و روی یک VPS ارزشش را دارد که دقیق مشخص کنیم کدام لحظات «سکون» بهحساب میآیند و کدام نه — شکاف میان این دو، همان جایی است که بیشتر انتظارات نادرست فرو میریزد.
سختافزار از رده خارج
درایوها خراب میشوند، جایگزین میشوند و از رک خارج میشوند. یک ولوم LUKS روی دیسکی مرده، برای هر کسی که بعداً آن را دست میگیرد، فقط یک بلوک نویز است. رمزنگاری این مورد را کاملاً حل میکند.
ولومی جدا یا کپیشده
اگر ولومی از اینستنس شما جدا شود، کلون شود یا وقتی ماشین خاموش است ایمیج گرفته شود، نتیجه فقط متن رمزشده (ciphertext) و یک هدر است — نه فایلهای شما.
یک ماشین در حال اجرا
بهمحض باز شدن ولوم، کلید اصلی در حافظهٔ کرنل زندگی میکند. دسترسی در سطح هایپروایزر، در اصل، میتواند به آن برسد. رمزنگاری در اینجا هزینهٔ دسترسی را بالا میبرد؛ در را کاملاً نمیبندد.
اشتباهات خودتان
swap رمزنگارینشده، بکاپهای متنساده و لاگهایی که پیش از mount نوشته شدهاند، همگی بیرون از این کانتینر قرار دارند. بیشتر نشتیهای واقعی از سرورهای رمزنگاریشده از همینجا رخ میدهد، نه از مسیر الگوریتم رمز.
این محدودیت را صریح بیان کنیم تا بتوانید بر اساس آن برنامهریزی کنید: تا وقتی ولوم باز است، کلید در RAM روی سختافزاری قرار دارد که مالک آن نیستید. LUKS روی یک VPS پاسخی قوی به دسترسی آفلاین است و پاسخی جزئی به دسترسی زنده. آن را با حوزهٔ قضاییای که واقعاً به آن اعتماد دارید ترکیب کنید — به /offshore-hosting نگاه کنید — نه اینکه آن را جایگزین چنین حوزهای بدانید.
پیش از تایپ هر دستوری، شکل کار را انتخاب کنید
چهار چیدمان تقریباً همهٔ نیازهای واقعی را پوشش میدهند. انتخاب اشتباه هزینهاش یک نصب مجدد است، پس همینجا تصمیم بگیرید، نه در نیمهٔ راه.
مسیر A — رمزنگاری یک ولوم داده روی سروری که همین حالا اجرا میکنید
این همان نسخهای است که بیشتر افراد واقعاً میخواهند: ده دقیقه کار، بدون نصب مجدد، و هر چیزی که اهمیت دارد در نهایت درون همین کانتینر قرار میگیرد. ابتدا یک ولوم دوم متصل کنید — روی یک پلن /storage همان دیسک بزرگ است؛ روی یک /vps استاندارد میتوانید هنگام استقرار یکی اضافه کنید.
- 1
دستگاه هدف را شناسایی کنید
lsblk را اجرا کنید و مطمئن شوید دستگاهی که در حال فرمت کردن آن هستید همان دستگاه خالی است. luksFormat هر چیزی را که روی آن باشد از بین میبرد و راه بازگشتی وجود ندارد.
- 2
کانتینر LUKS2 را بسازید
cryptsetup luksFormat --type luks2 /dev/vdb از شما میخواهد YES را با حروف بزرگ تایپ کنید، سپس یک عبارت عبور تنظیم کنید. عبارتی انتخاب کنید که بتوانید آن را درست، روی کنسولی بدون تاریخچه و بدون echo، دوباره تایپ کنید.
- 3
آن را باز کنید و یک فایلسیستم روی آن بسازید
cryptsetup open /dev/vdb cryptdata مسیر /dev/mapper/cryptdata را میسازد. سپس mkfs.ext4 /dev/mapper/cryptdata را اجرا کنید و آن را جایی که دادهها قرار است زندگی کنند mount کنید، مثلاً /srv/data.
- 4
تصمیم بگیرید در بوت چطور باز شود
یا بعد از هر ریبوت عبارت عبور را تایپ کنید، یا با cryptsetup luksAddKey یک keyfile اضافه کنید و آن را روی root ذخیره کنید. keyfile راحت است و قطعاً ضعیفتر — مشخص باشید دارید چه معاملهای میکنید.
- 5
crypttab و fstab را پیکربندی کنید
نگاشت را با استفاده از UUID= بهجای نام دستگاه، به /etc/crypttab اضافه کنید، سپس با nofail از /etc/fstab mount کنید تا یک باز کردن قفل ناموفق هرگز بوت را معلق نکند.
اگر keyfile روی root رمزنگارینشده قرار داشته باشد، دقیق باشید دربارهٔ اینکه چه چیزی دارید: ولوم در برابر دیسکی که رک را ترک میکند یا از اینستنس شما جدا میشود محافظتشده است، نه در برابر یک کپی از کل VM — چون آن کپی حاوی همان کلید هم هست. هر چیز قویتر از این نیاز دارد عبارت عبور از بیرون سرور بیاید.
مسیر B — یک root رمزنگاریشده از یک ISO سفارشی
وقتی الزام این است که هیچچیز قابلخواندنی روی ماشین در حالت خاموش وجود نداشته باشد، خودِ root هم باید درون LUKS باشد. این یعنی یک نصب تازه که از کنسول هدایت میشود، روی ارائهدهندهای که اجازه میدهد ISO خودتان را بوت کنید.
- 1
نصبکننده را از کنسول بوت کنید
یک ISO از نوع netinst مربوط به Debian یا Ubuntu را بهعنوان ISO سفارشی mount کنید و نصب را روی VNC یا سریال هدایت کنید. هیچکدام از اینها روی SSH کار نمیکند — هنوز سیستمی برای اتصال وجود ندارد.
- 2
از پارتیشنبندی هدایتشده با LVM رمزنگاریشده استفاده کنید
نصبکننده یک /boot کوچک را بهصورت رمزنگارینشده باقی میگذارد، چون چیزی باید پیش از باز شدن ولوم اجرا شود، و root و swap را درون یک کانتینر LUKS قرار میدهد.
- 3
عبارت عبوری انتخاب کنید که بدون دیدن آن هم بتوانید درست تایپ کنید
آن را روی SSH و در هر ریبوت، بدون echo و بدون تکمیل خودکار، دوباره تایپ خواهید کرد. یک عبارت عبور پنجکلمهای در اینجا بهتر از انبوهی درهم از نمادهاست.
- 4
پیش از خروج از سیستم، باز کردن قفل از راه دور را راهاندازی کنید
یک root تازه رمزنگاریشده، بعد از ریبوت بعدی، برای همیشه پشت پرامپت عبارت عبور میماند. باز کردن قفل از راه دور را در همان نشست پیکربندی کنید، درحالیکه کنسول هنوز جلوی چشم شماست.
روی پلنهای با 1 تا 2 GB RAM، اشتقاق کلید پیشفرض Argon2id میتواند حافظهای بیشتر از آنچه initramfs در اختیار دارد درخواست کند، و باز کردن قفل در بوت شکست میخورد، حتی اگر عبارت عبور درست باشد. آن را هنگام فرمت با cryptsetup luksFormat --pbkdf-memory 262144 محدود کنید، یا پیش از آنکه به یک اینستنس کوچک برای ریبوت بدون نظارت اعتماد کنید، هدر موجود را با cryptsetup luksDump بررسی کنید.
باز کردن قفل از راه دور روی SSH با dropbear-initramfs
یک root رمزنگاریشده، پیش از آنکه سیستمعامل وجود داشته باشد، به یک عبارت عبور نیاز دارد. dropbear-initramfs یک سرور SSH کوچک درون initramfs قرار میدهد تا بتوانید آن را از هر جایی وارد کنید — همان تفاوت میان یک سرور رمزنگاریشده و یک آجر رمزنگاریشده.
- 1
پکیج را نصب کنید
apt install dropbear-initramfs. این پکیج به فرایند ساخت initramfs قلاب میشود و بهطور خودکار در هر ایمیج کرنل بعدی دوباره ساخته میشود.
- 2
یک کلید را مجاز کنید، و فقط یک دستور
کلید عمومی خود را در /etc/dropbear/initramfs/authorized_keys قرار دهید — روی Debian 11 و نسخههای قدیمیتر، در /etc/dropbear-initramfs/authorized_keys. ابتدای خط را با no-port-forwarding,no-agent-forwarding,no-x11-forwarding,command="cryptroot-unlock" پیشوند بزنید تا یک کلید دزدیدهشده چیزی جز یک پرامپت به دست ندهد.
- 3
به initramfs یک شبکه بدهید
DHCP هرجا ارائهدهنده آن را عرضه کند کار میکند؛ در غیر این صورت یک پارامتر استاتیک ip=ADDRESS::GATEWAY:NETMASK::eth0:off به GRUB_CMDLINE_LINUX اضافه کنید و update-grub را اجرا کنید. با update-initramfs -u -k all کار را تمام کنید تا تغییر در ایمیج قرار بگیرد.
- 4
پیش از تکیه کردن به آن، یک ریبوت کامل را تست کنید
با کنسول ارائهدهنده باز در یک پنجرهٔ دیگر ریبوت کنید، وصل شوید، عبارت عبور را وارد کنید و ادامهٔ بوت را تماشا کنید. یک مسیر باز کردن قفلِ تستنشده یک قابلیت نیست، یک قطعیِ آینده است.
initramfs کلید میزبان SSH خودش را دارد، متفاوت از آنچه سیستمِ بوتشده ارائه میدهد، پس کلاینت شما در هر ریبوت دربارهٔ تغییر کلید میزبان هشدار میدهد. dropbear را روی پورتی جداگانه، از طریق DROPBEAR_OPTIONS در /etc/dropbear/initramfs/dropbear.conf، اجرا کنید، یا با ssh -o HostKeyAlias=box-initramfs وصل شوید، و هر دو fingerprint را ثبت کنید.
مدیریت کلید همان جایی است که رمزنگاری دیسک معمولاً شکست میخورد
الگوریتم رمز بخش ضعیف ماجرا نیست و هرگز هم نبوده است. هر فاجعهٔ قابلجبران که پای LUKS در آن باشد، در نهایت به یک کلید یا یک هدر برمیگردد، پس با هر دو مثل زیرساخت رفتار کنید.
- فوراً از هدر بکاپ بگیرید — cryptsetup luksHeaderBackup /dev/vdb --header-backup-file luks-header.img — و آن را خارج از سرور ذخیره کنید. هدری که با یک dd بیاحتیاطی آسیب دیده، حتی با یک عبارت عبور کامل هم، به معنای از دست رفتن دائمی داده است.
- از دو اسلات استفاده کنید. LUKS2 به شما 32 اسلات میدهد: عبارت عبور خودتان در یکی، یک کلید بازیابی تصادفی و طولانی در دیگری، که در یک مدیر گذرواژه نگه داشته میشود. یک اسلات تنها، یک نقطهٔ شکست واحدِ خودخواسته است.
- روی یک ماشین دور، کلیدها را به ترتیب درست بچرخانید — ابتدا کلید جدید را با luksAddKey اضافه کنید، مطمئن شوید ولوم را باز میکند، سپس کلید قدیمی را با luksKillSlot حذف کنید. هرگز برعکس.
- عبارت عبور و اطلاعات اتصال سرور را در جاهای جداگانه نگه دارید. یک یادداشت افشاشده نباید هم آدرس و هم کلید را یکجا تحویل دهد.
رمزنگاری در عملکرد چه هزینهای دارد
سربار واقعی است، اما معمولاً نامرئی. آن را روی ماشینی که واقعاً در اختیار دارید اندازه بگیرید، نه اینکه به یک بنچمارک از یک دههٔ دیگر اعتماد کنید.
بخشهایی که افراد فراموش میکنند
یک ولوم رمزنگاریشده که از لبههایش متن ساده نشت میکند، یک حس امنیت کاذب است، که از نبود امنیت هم بدتر است. پیش از آنکه کار را تمامشده اعلام کنید، این پنج مورد را ببندید.
- Swap. یک پارتیشن swap رمزنگارینشده میتواند تکههایی از هر چیزی را که از حافظه عبور کرده نگه دارد. آن را با یک کلید تصادفیِ تازه در هر بوت، از طریق یک ورودی /dev/urandom در /etc/crypttab، رمزنگاری کنید.
- لاگهایی که پیش از mount نوشته شدهاند. هر چیزی که وقتی ولوم رمزنگاریشده هنوز بسته است لاگ شود، روی root ساده فرود میآید. لاگهای اپلیکیشن و پایگاهداده را به مسیری درون همان کانتینر هدایت کنید.
- بکاپها. کپی کردن محتوای یک ولوم رمزنگاریشده در یک object storage بهصورت متن ساده، کل این تمرین را بیاثر میکند. بکاپ را جداگانه با restic، borg یا age رمزنگاری کنید، و آن کلیدها را جای دیگری نگه دارید.
- اسنپشاتها. یک اسنپشات ارائهدهنده، دیسک را ثبت میکند، نه RAM شما را، پس ولوم LUKS درون آن همچنان متن رمزشده باقی میماند — اما هر چیزی که روی root رمزنگارینشده مانده، دقیقاً همانطور که بوده ثبت میشود.
- Discard. عبور دادن فلگ discard از میان LUKS، کارکرد trim را روی NVMe زنده نگه میدارد و مشخص میکند کدام بلوکها استفادهنشدهاند — و از همین راه نشت میدهد که فایلسیستم چقدر پر است و تقریباً چه شکلی دارد. آن را آگاهانه انتخاب کنید، نه با کپی کردن یک کانفیگ.
جایی که میزبان هنوز اهمیت دارد
رمزنگاری همان لایهای است که شما کنترلش میکنید: تعیین میکند خواندن دادههای شما، وقتی ماشین خاموش است یا دیسکی ساختمان را ترک میکند، چقدر پرهزینه باشد. لایهٔ دور آن — اینکه چه کسی میتواند دسترسی به سختافزار را تحمیل کند، و چه سوابقی سرور را به شما پیوند میدهند — به ارائهدهنده و حوزهٔ قضاییاش تعلق دارد. ششتا از 15 منطقهٔ ما حوزههای قضایی ردهٔ حریم خصوصی هستند؛ فهرست آنها در /locations آمده، و /offshore-hosting توضیح میدهد این موضوع واقعاً چه چیزی را تغییر میدهد.
سه قابلیت از سمت ارائهدهنده تعیین میکند که آیا مسیرهای بالا اصلاً در دسترس هستند یا نه: بوت ISO سفارشی، که بدون آن مسیر B غیرممکن است؛ دسترسی کنسول خارج از باند برای همان ریبوتی که باز کردن قفل از راه دور در آن برنمیگردد؛ و یک ثبتنام که از همان ابتدا ماشین را به هویت قانونی شما گره نمیزند. هر پلن /offshore-vps و /storage در اینجا یک ISO سفارشی بوت میکند، دسترسی کنسول ارائه میدهد، و از یک موجودی رمزارزیِ پیشپرداختشده و بدون KYC صورتحساب میشود — پس یک دیسک رمزنگاریشده روی یک ردپای کاغذی که از قبل نام شما را در خود دارد سوار نیست. /guides یک مرور صادقانه دارد از اینکه یک میزبان چه چیزی را میتواند و چه چیزی را نمیتواند ببیند.
چکلیست استقرار
- اول تهدید را نام ببرید: درایوهای از رده خارج، ولومهای جداشده و ایمیجهای آفلاین همان چیزهایی هستند که رمزنگاری به آنها پاسخ میدهد — یک هایپروایزر زنده نه.
- اگر سرور همین حالا در حال اجراست، یک ولوم داده رمزنگاری کنید (مسیر A)؛ فقط وقتی خودِ root باید رمزنگاری شود، از یک ISO سفارشی نصب مجدد کنید (مسیر B).
- LUKS2 با aes-xts-plain64، و روی هر پلن با کمتر از 2 GB RAM، حافظهٔ Argon2id را محدود کنید.
- عبارت عبور در یک اسلات کلید، یک کلید بازیابی تصادفی و طولانی در اسلاتی دیگر، هر دو خارج از سرور ذخیره شوند.
- پیش از نوشتن اولین بایت دادهٔ واقعی، از هدر LUKS بکاپ بگیرید.
- dropbear-initramfs روی یک پورت غیرپیشفرض، فقط بر پایهٔ کلید، و محدود به دستور cryptroot-unlock.
- یک چرخهٔ کامل ریبوت-و-باز-کردن-قفل را، درحالیکه کنسول ارائهدهنده هنوز کنار دستتان باز است، تست کنید.
- بکاپهای رمزنگاریشدهٔ خارج از سایت، بهعلاوهٔ یک تمرین بازیابی — یک بکاپ تستنشده یک امید است، نه یک بکاپ.
آیا رمزنگاری دیسک جلوی ارائهدهندهٔ هاستینگم را از خواندن دادههایم میگیرد؟
در حالت سکون، بله: بهمحض خاموش شدن ماشین، ولوم بهصورت متن رمزشده است و عبارت عبور هرگز از ذهن شما بیرون نرفته. تا وقتی سرور با ولومِ باز اجرا میشود، کلید اصلی در RAM روی سختافزاری قرار دارد که ارائهدهنده آن را اداره میکند. رمزنگاری هر مسیر آفلاین را میبندد — درایوهای از رده خارج، ولومهای جداشده، ایمیجهای سرد — و هزینهٔ بقیه را بالا میبرد. این مکمل یک حوزهٔ قضایی قابلاعتماد است، نه جایگزین آن.
آیا میتوانم یک VPS موجود را بدون نصب مجدد رمزنگاری کنم؟
یک ولوم دادهٔ جداگانه، بله، در حدود ده دقیقه — همان مسیر A در بالا. فایلسیستم root را، در واقعیت، نه. cryptsetup reencrypt میتواند یک فایلسیستم را در همانجا تبدیل کند، اما یک اتصال قطعشده یا یک قطعی برق در میانهٔ کار روی یک ماشین دور، یک سرور غیرقابلبوت و یک شب طولانی بهجا میگذارد. نصب مجدد از یک ISO سفارشی سریعتر و بسیار امنتر است.
LUKS چقدر هزینهٔ عملکرد دارد؟
کمتر از آنچه بیشتر افراد انتظار دارند. با AES-NI، هزینهٔ AES-XTS روی بارهای کاریِ معمولِ ترکیبی چند درصد است، و cryptsetup benchmark روی یک هستهٔ مدرن EPYC چندین GB/s گزارش میدهد. موردی که قابلمشاهده است، I/O ترتیبی تکرشتهای در برابر NVMe سریع است، جایی که یک هسته میتواند پیش از خودِ درایو اشباع شود. بهجای حدس زدن، اینستنس خودتان را بنچمارک کنید.
اگر عبارت عبور را فراموش کنم چه اتفاقی میافتد؟
داده از دست رفته است. هیچ مکانیزم بازیابی، هیچ کلید اصلیِ سمت ارائهدهنده و هیچ تیکت پشتیبانیای که این را برگرداند وجود ندارد — همین ویژگی، هدف اصلی طراحی است. با یک اسلات کلید دوم که یک کلید بازیابی تصادفی نگه میدارد، و با یک بکاپ از هدر LUKS که جایی غیر از سرور ذخیره شده، از خودتان محافظت کنید.
آیا اجرای SSH درون initramfs خطرناک است؟
این یک قرارگرفتن در معرض خطرِ کوچک و شناختهشده است. dropbear فقط برای چند ثانیهٔ پیش از وجود فایلسیستم root شما اجرا میشود، فقط کلیدهای عمومی را میپذیرد، و میتواند به یک دستور اجباریِ واحد محدود شود که کاری جز درخواست عبارت عبور نمیکند. روی یک پورت غیرپیشفرض، با کلید میزبانِ initramfs که جداگانه ثبت شده، ریسک عملی در برابر قطعیتِ قفلماندن بدون آن ناچیز است.
