سه حالت، و همان یکی که این صنعت نمیفروشد
میگویند داده همیشه در یکی از سه حالت قرار دارد، و کل این صفحه دربارهٔ همین تفکیک است. در حالت سکون یعنی دیسکی که کسی آن را نمیخواند. در حال انتقال یعنی بستهای روی یک سیم. در حال استفاده یعنی فرآیندی که متنسادهٔ داده را در حافظه نگه داشته تا کاری با آن انجام دهد.
دو موردِ اول حلشدهاند و هر ارائهدهندهای آنها را میفروشد. سیم، TLS است و صفحاتِ زیرِ پای شما تقریباً قطعاً رمزنگاریشدهاند. دربارهٔ سومی خیلی کم صحبت میشود، چون سومی همان جایی است که ارائهدهنده در آن ایستاده: یک سرورِ در حال اجرا، والیومش باز است، کلید در حافظه حاضر است، و داده بهصورت خوانا. این نقصی در رمزنگاری نیست. این یعنی «در حال اجرا بودن».
وقتی یک میزبان میگوید “رمزنگاریشده در حالت سکون”، منظورش چیست
رمزنگاری در حالت سکون در سمتِ ارائهدهنده واقعی است و ارزشِ داشتن دارد. یعنی درایو، آرایه، یا فضای ذخیرهٔ اسنپشاتها با کلیدی رمزنگاری شده که ارائهدهنده مدیریتش میکند، پس دیسکی که ساختمان را ترک میکند — خرابشده، تعویضشده، فروختهشده، دزدیدهشده — چیزی جز یک قطعهٔ بیمصرف نیست، نه نسخهای از پایگاهدادهٔ شما. هر پلتفرمِ جدی این کار را انجام میدهد و برای شما هیچ هزینهای ندارد.
کاری که این روش نمیتواند انجام دهد، کنار گذاشتنِ ارائهدهنده است، چون ارائهدهنده طبقِ تعریف، کلید را در اختیار دارد. این کنترلی در برابرِ اسکلهٔ بارگیری است، نه در برابرِ اپراتور. میزبانی که به پرسشی دربارهٔ دسترسیِ خودش، با توصیفِ رمزنگاری در حالت سکون پاسخ میدهد، به پرسشِ دیگری پاسخ داده، و معمولاً خودش هم میداند.
نسخهای که واقعاً ارائهدهنده را کنار میگذارد، همان نسخهای است که کلید هرگز به دستش نمیرسد. این دادوستد در راهنمای عملیاتیِ مربوطه نوشته شده: اسنپشاتها در اینجا رمزنگاریشده ذخیره میشوند، این مجموعه هیچ کلیدی برای محتوای دیسکی که خودتان رمزنگاری کردهاید ندارد، و به همین دلیل نمیتواند آن دیسک را هم برایتان نجات دهد. هر دو نیمهٔ این جمله یک واقعیتِ واحدند، و میزبانی که فقط نیمهٔ اول را عرضه میکند، دارد کلیدی را نگه میدارد.
سه دستگاه، سه پاسخِ متفاوت
“آیا میزبان من میتواند دیسکم را بخواند” پاسخِ متفاوتی میگیرد بسته به اینکه روی یک نمونهٔ اشتراکی باشید، روی یک ماشین کامل، یا در کابینتی که واحد به واحد اجاره میکنید. ارزش دارد این تفاوتها را باز کنیم، چون معمولاً همگی بهعنوان یک محصول واحد، با اعدادی متفاوت، فروخته میشوند.
| چه چیزی اجاره میکنید | اپراتور، در حینِ اجرا، به چه چیزی دسترسی دارد | این برای شما چه معنایی دارد |
|---|---|---|
| VPS اشتراکی | هایپروایزر حافظهٔ ماشین مهمانِ شما را در اختیار دارد. RAM ماشین مهمان را میتوان دامپ گرفت، و یک مهاجرتِ زنده، طبق طراحی، آن را به میزبانی دیگر کپی میکند. | هر کلیدی که در RAM شما باشد، در دسترس است. رمزنگاری از والیومِ ذخیرهشده محافظت میکند، نه از ماشین مهمانِ در حال اجرا. |
| سرور اختصاصی | هیچ هایپروایزری بالای سر شما نیست. کنترلر مدیریت — IPMI، BMC، یا هر نامی که سازنده رویش بگذارد — کامپیوتر دومی روی برد است که عمرش از سیستمعامل شما بیشتر است. | سطحی بسیار کوچکتر، اما نه سطحی خالی. آن کنترلر میتواند رسانه سوار کند و کنسول را تماشا کند. |
| Colocation | سختافزارِ شما، فرمورِ شما، دیسکهای شما. درِ ورودی، برق، و دستانِ کس دیگری. | آنچه باقی میماند یک پرسشِ فیزیکی است، تنها نوعی که میتوانید با یک قفل به آن پاسخ دهید. |
هیچکدام از این ردیفها استدلالی بر ضدِ محصولِ بالای خودش نیست. اینها استدلالیاند برای اینکه بدانید در برابر کدام تهدید خرید میکنید. اپراتوری که هایپروایزر را اجرا میکند میتواند حافظهٔ ماشین مهمانِ روی آن را بخواند، و ارائهدهندهای که خلاف این را ادعا کند، زیرساختِ خودش را درست نشناخته است. آنچه او میخواند یا دادههای شماست یا صرفاً نویز، و اینکه کدامیک، ماهها پیش و با تصمیمِ اینکه کلید را کجا گذاشتهاید مشخص شده.
آیین کلید، تمامِ تضمین است
هرآنچه در بالا آمد، به یک پرسشِ عملیاتی خلاصه میشود: در لحظهای که دستگاه بوت میشود، کلید از کجا میآید؟ در عمل سه پاسخ برای این پرسش وجود دارد، و از نظر استحکام اصلاً به هم نزدیک نیستند.
- روی خود دستگاه ذخیره شده. یک فایل کلید روی همان والیوم، یا عبارت عبوری که داخل اسکریپت تدارک جاسازی شده، تا سرور بتواند بدون دخالت کسی بوت شود. این رمزنگاری در حد یک تیکگزینه است: هرکس بتواند دیسک را بخواند، کلیدی را هم که کنارش افتاده میتواند بخواند.
- نزد ارائهدهنده نگهداری میشود. راحت است، قابلبازیابی است، و دقیقاً همان ترتیبی است که یک دستور قانونی میتواند روی آن اثر بگذارد. کلید وجود دارد، کسی آن را در اختیار دارد، و در اختیار داشتنِ آن چیزی است که دادگاه میتواند در یک سند نام ببرد.
- در هر بوت توسط خودتان وارد میشود. دستگاه وارد یک initramfs میشود و تا وقتی متصل نشوید و عبارت عبور را ندهید، کاری انجام نمیدهد. کلید فقط در حافظهٔ همان دستگاه وجود دارد، فقط تا وقتی روشن است، و در هیچ جای دیگری از کرهٔ زمین.
فقط سومی پرسش را از قلمرو حقوقی بیرون میبرد. یک دستور میتواند ارائهدهنده را وادار کند هرچه در اختیار دارد ارائه دهد؛ اما نمیتواند وادارش کند کلیدی را ارائه دهد که هرگز به او داده نشده. این تفاوتی در نوع است، نه در درجه، و به همین دلیل است که warrant canary امضاشده در اینجا ادعای جداگانهای دربارهٔ تضعیفِ اجباریِ یک حفاظتِ رمزنگارانه مطرح میکند. وعدهای دربارهٔ رفتار و واقعیتی دربارهٔ محاسبه، دو ابزار متفاوتاند، و فقط یکی از آن دو از کسی که آن را ساخته بادوامتر است.
رمزنگاری کامل دیسک چه چیزی را همچنان بهصورت خوانا باقی میگذارد
فایلسیستم ریشهٔ رمزنگاریشده یک جعبهٔ سیاه نیست. چند چیز، بنا به ساختار، بیرون از آن قرار دارند، و دانستن اینکه کدامها، تفاوتِ میان یک مدل تهدید و یک احساس است.
- زنجیرهٔ بوت.
/bootو initramfs پیش از آنکه چیزی بتواند رمزگشایی شود خوانده میشوند، پس رمزنگارینشدهاند و، روی سختافزار اجارهای که نمیتوانید فرمور آن را تصدیق کنید، تأییدنشده باقی میمانند. هرکس بتواند آنجا بنویسد، میتواند چیزی بنویسد که عبارت عبور شما را ضبط کند. - Swap و هایبرنیشن. فضای swap رمزنگارینشده، بدون هیچ اعتراضی صفحاتی از حافظهٔ رمزگشاییشده را نگه میدارد. یا آن را رمزنگاری کنید یا خاموشش کنید؛ گزینهٔ سومِ امنی وجود ندارد.
- شکل ظاهری دستگاه. اندازهٔ پارتیشنها، هدر LUKS، میزان فضای استفادهشده از والیوم، و همین واقعیت ساده که اصلاً رمزنگاری شده است.
- هر آنچه فرآیند در حال اجرا در اختیار دارد. پایگاهداده در کش صفحه، کلید خصوصی TLS که وبسرور هنگام راهاندازی بارگذاری کرده، متغیرهای محیطی، سوکتهای باز. این بزرگترین دسته در این فهرست است و رمزنگاری در حالت سکون هیچکدام از آنها را لمس نمیکند.
- ترافیک شما. با چه کسی، چه زمانی و چقدر صحبت میکنید، دقیقاً مثل قبل. این موضوعِ راهنمای بدونلاگ است، نه این صفحه.
زنجیرهٔ بوت همان چیزی است که مردم دستکمش میگیرند. اگر initramfs جایی است که عبارت عبور را در آن تایپ میکنید، پس initramfs اکنون به یک درخواستِ اعتبارنامه روی دستگاهی تبدیل شده که از نظر فیزیکی در کنترل شما نیست — پس اثر انگشتِ کلید میزبانِ SSH آن، بههماناندازهٔ خودِ عبارت عبور اهمیت دارد. این کلید با کلیدی که سیستمِ در حال اجرا نشان میدهد فرق دارد، و دقیقاً به همین دلیل است که یک اثر انگشتِ تغییریافته در بوت، بدون توجه رد میشود. بار اول آن را ثبت کنید و هر بار بعدی بررسیاش کنید. یک پیام که درست به نظر میرسد اما نیست، کلِ حمله است.
چه چیزی را متوقف میکند، و چه چیزی را نه
| تهدید | آیا رمزنگاری دیسک کمکی میکند؟ | چرا |
|---|---|---|
| دیسکی که ساختمان را ترک میکند | بله، کاملاً | خرابشده، تعویضشده، فروختهشده یا دزدیدهشده — والیومی که خاموش است، چیزی جز متن رمزشده نیست. |
| توقیفِ دستگاهی خاموش | بله | آنچه گرفته میشود، همان وضعیتی است که والیوم در لحظهٔ قطعِ برق داشته. وقتی هیچ کلیدی در ساختمان نباشد، آن وضعیت چیزی جز نویز نیست. |
| توقیف در حالی که روشن است | خیر | کلید در RAM است و فایلسیستم سوار شده. این همان حالتی است که تبلیغات هرگز توصیفش نمیکند. |
| دستوری که به ارائهدهنده ابلاغ شده | نه بهطور مستقیم، و نکته دقیقاً همین است | به دستور، با آنچه وجود دارد پاسخ داده میشود. کلیدی که هرگز داده نشده، قابل ارائه نیست، هرچه آن سند بگوید. |
| خواندنِ فایلهای شما توسط ارائهدهنده | فقط در سومین ترتیبِ بالا | کلیدی که ارائهدهنده مدیریت میکند، یعنی دسترسیِ ارائهدهنده. کلید خودتان یعنی دسترسیِ خودتان، و بس. |
| بهخطرافتادن سرور در حال اجرا | خیر | مهاجمی که روی دستگاهی با والیومِ سوارشده به دسترسی روت برسد، درونِ مرز رمزنگاری است، نه بیرون آن. |
| اشتباههای خودتان | خیر | عبارت عبوری که در یک تیکت پشتیبانی جایگذاری شود، یا در یک پیامِ تأییدنشده تایپ شود، تضمین را همانقدر از بین میبرد که انگار از اول وجود نداشته. |
ستون میانی را از بالا به پایین بخوانید. رمزنگاری دقیقاً در مواردی تعیینکننده است که دستگاه خاموش است یا کلید هرگز تحویل داده نشده، و در هر موردی که دستگاه روشن است و کسی از قبل درونش است، بیربط. این ضعفی نیست که بشود با مهندسی دورش زد. رمزنگاری دقیقاً همین است، و صفحهای که خلاف این را القا کند، دارد چیزی میفروشد.
هزینه، پیش از آنکه به آن متعهد شوید بیان شده
این بخشی است که صفحاتِ تبلیغکنندهٔ “هاستینگ رمزنگاریشده” ندارند، و دلیلش این است که هر مورد در آن، یک ناراحتیِ واقعی است که ظرف یک ماه با آن روبهرو میشوید.
- بدون راهاندازی مجدد خودکار. یک بهروزرسانی هسته، یک قطعی برق، یا جابهجایی میزبان، دستگاه را پشت یک پیامِ درخواستِ عبارت عبور نگه میدارد تا کسی برسد. در دسترسبودنِ سرویس اکنون تابعی از برنامهٔ خواب شماست.
- بدون امکان نجات. ارائهدهندهای که نتواند والیوم را بخواند، نمیتواند آن را هم تعمیر کند. بررسی فایلسیستم، بازیابی داده، و “میشود فقط پیکربندی را از رویش کپی کنید” همگی فقط بر عهدهٔ خودتان میشوند.
- پشتیبانها متن رمزشدهاند. این درست است، و یعنی بازیابی هم به کلید نیاز دارد. پشتیبانی که نتوانید بازش کنید، پشتیبان نیست.
- هدر آسیبدیده مرگبار است. هدر LUKS کلید اصلی رمزگذاریشده را در ناحیهای کوچک در ابتدای والیوم نگه میدارد. همان روز اول آن را از روی دستگاه بیرون ببرید؛ بدون آن، حتی عبارت عبور درست هم هیچچیز را باز نمیکند.
- سربار وجود دارد. واقعی است، در یک بنچمارک قابلمشاهده است، و بهندرت محدودکنندهٔ یک بار کاری — هر پردازندهٔ امروزی، AES را در سختافزار انجام میدهد. آن را روی همان ماشینی که اجاره کردهاید بسنجید تا اینکه دربارهٔ آن بحث کنید.
طوری راهاندازیاش کنید که واقعاً ارزشِ داشتن داشته باشد
دستورها در پایگاه دانش هستند. آنچه در ادامه میآید، ترتیبِ اجرای آنهاست، که همان بخشی است که یک دستور نیست.
- دسترسی کنسول را پیش از شروع کار ردیف کنید، نه پس از آن. اولین اشتباه درست در پیامِ بوت رخ میدهد، و SSH دقیقاً همان چیزی است که آنجا در دسترس نیست.
- ابتدا یک والیوم دوم را رمزنگاری کنید. داده روی یک دیسکِ رمزنگاریشدهٔ جداگانه، بیشتر مزیت را با کسری از ریسکِ عملیاتی به شما میدهد، و حالتهای خرابی را روی دستگاهی که همچنان خودش بالا میآید به شما یاد میدهد.
- فایلسیستم ریشه را فقط زمانی پشت آن ببرید که این کار برایتان به یک روال عادی تبدیل شده باشد، همراه با یک سرور SSH کوچک در initramfs که هنگام بوت عبارت عبور را دریافت کند.
- اثر انگشتِ کلید میزبانِ initramfs را در اولین بازگشایی ثبت کنید و در هر بازگشاییِ بعدی آن را بررسی کنید. این کلید همان کلیدی نیست که سیستمِ در حال اجرا نشان میدهد، و عادیشمردنِ یک تغییر، دقیقاً همان راهی است که یک عبارت عبور جمعآوری میشود.
- از هدر LUKS نسخهٔ پشتیبان بگیرید و آن را جایی غیر از همان دستگاه نگه دارید، سپس ثابت کنید که آن نسخهٔ پشتیبان واقعاً والیوم را باز میکند، نه اینکه فقط فرض کنید باز میکند.
- swap را رمزنگاری یا غیرفعال کنید، و بعد بررسی کنید واقعاً چه چیزی ساختهاید:
lsblk -o NAME,FSTYPE,MOUNTPOINTنشان میدهد چه چیزی پشتِ mapper قرار دارد و چه چیزی بیسروصدا آنجا نیست. - یک بار، عمداً و پیش از آنکه چیزی رویش باشد که دلتان برایش تنگ شود، آن را راهاندازی مجدد کنید. اولین راهاندازی مجددِ بدوننظارت در ساعت سه بامداد، لحظهٔ مناسبی برای یادگرفتنِ روال نیست.
چگونه در ده دقیقه ادعای رمزنگاریِ یک میزبان را بررسی کنیم
همان آزمونی که در جایجای این قفسه هست: هر پرسشِ زیر یا سندی بهعنوانِ پاسخ دارد، یا اصلاً پاسخی ندارد.
- چیزی که رمزنگاری میشود پلتفرم است، والیوم است، یا ماشین مهمان — و کدامیک از اینها همان چیزی بود که شما دربارهٔ آن پرسیدید؟
- کلید را چه کسی تولید میکند، کجا نگهداری میشود، و وقتی مشتری آن را گم کند، رویه چیست؟ یک مسیرِ بازیابی، یعنی یک کلیدِ دوم، و کلیدِ دوم، یعنی چیزِ دومی که میشود دستور به ارائهاش داد.
- آیا میتوانید کلید خودتان را بیاورید و از بهاشتراکگذاشتنش امتناع کنید؟ اگر پاسخ بله است، بپرسید چه چیزی از کار میافتد. اگر هیچچیز از کار نیفتد، یعنی آن رمزنگاری اصلاً کاری انجام نمیداده است.
- آیا کنسولی هست که وقتی دستگاه بالا نمیآید هم کار کند، و آیا در قیمت گنجانده شده یا ساعتی صورتحساب میشود؟
- ارائهدهنده میگوید بعد از اینکه شما رمزنگاری کردید، دیگر چه کاری از دستش برنمیآید؟ میزبانی که هم مدعیِ حریمِ خصوصیِ کامل است و هم پشتیبانیِ کامل، یا این موضوع را تا انتها فکر نکرده، یا دارد کلیدی را توصیف میکند که در اختیار دارد.
آخرین مورد، همان نشانهی افشاگر است. هر پاسخِ صادقانه در این حوزه برای ارائهدهنده هزینهای دارد، و ادعایی که هیچ هزینهای ندارد، دارد یک محصول را توصیف میکند، نه یک تضمین. اینکه این مجموعه چه میکند و چه نمیکند، در راهنمای مجریان قانون آمده و در گزارش شفافیت شمارش شده.
پرسشهایی که واقعاً پرسیده میشوند
آیا ارائهدهندهٔ هاستینگ من میتواند فایلهایم را بخواند؟
روی والیومِ رمزنگارینشده، بله — نزد هر ارائهدهندهای، در هر کشوری، صرفنظر از هرچه دربارهٔ لاگگیری یا حوزهٔ قضایی گفته باشد. این از اجرا کردنِ سختافزار ناشی میشود، نه از یک انتخابِ سیاستی. با رمزنگاری کامل دیسک که کلیدش را خودتان در هر بوت وارد میکنید، پاسخ در زمانی که دستگاه خاموش است میشود «نه»، و در طول یک توقیف هم «نه» باقی میماند، چون هیچچیز در این مجموعه نمیتواند آن را رمزگشایی کند.
آیا رمزنگاریِ دیسکم جلوی یک دستور دادگاه را میگیرد؟
خیر، و ارزش دارد این تمایز را حفظ کنیم. یک دستور، ارائهدهنده را وادار میکند هرچه دارد ارائه دهد. اما کلیدی را که هرگز داده نشده از نیستی خلق نمیکند، پس آنچه آن دستور تولید میکند، متن رمزشده است. پرسش از قلمرو حقوقی به قلمرو ریاضی منتقل میشود، و پاسخ ریاضی با تغییرِ دادگاه تغییر نمیکند.
آیا یک VPS رمزنگاریشده از سوی ارائهدهنده، همان چیز است؟
معمولاً نه. تقریباً همیشه این عبارت یعنی رمزنگاریِ در حالت سکون در سطحِ پلتفرم، با کلیدی که ارائهدهنده مدیریت میکند، که از دیسکی که ساختمان را ترک میکند محافظت میکند و ارائهدهنده را کنار نمیگذارد. ارزشِ داشتن دارد، اما چیزی نیست که بیشتر مردم بهخاطرش آن را میخرند. بپرسید وقتی دستگاه روشن است، کلید نزد کیست.
وقتی یک سرورِ رمزنگاریشده راهاندازی مجدد میشود، چه اتفاقی میافتد؟
متوقف میشود و منتظر شما میماند. این هزینهٔ این ترتیب است و نسخهای بدون آن وجود ندارد، چون دستگاهی که بتواند خودش قفلش را باز کند، دستگاهی است که کلید خودش را نگه داشته. طوری برنامهریزی کنید که یک بهروزرسانی هسته به معنیِ یک بازکردنِ قفلِ زمانبندیشده باشد، و برای بوتی که خراب از آب درمیآید، دسترسی کنسول را آماده نگه دارید.
آیا رمزنگاری کامل دیسک سرور را کند میکند؟
در یک بنچمارک، بهوضوح؛ در یک بار کاری، بهندرت. هر پردازندهٔ امروزی، AES را در سختافزار انجام میدهد و گلوگاهِ معمول همانجایی میماند که از قبل بود. اجرای cryptsetup benchmark روی همان دستگاهی که واقعاً اجاره کردهاید، بهتر از هر عددی که روی یک صفحه چاپ شده به این پرسش پاسخ میدهد.
آیا رمزنگاریِ یک والیوم دوم کافی است؟
برای بیشتر افراد این اولین گامِ معقول است و اغلب هم آخرین گام: داده را روی والیومِ رمزنگاریشده بگذارید و سیستمعامل خواندنی باقی میماند، که یعنی راهاندازی مجدد خودکار و ابزارهای نجات همچنان کار میکنند. آنچه این کار پوشش نمیدهد، چیزی است که سیستم جای دیگری نوشته — لاگها، swap، فایلهای موقت، کش صفحه. این را آگاهانه تصمیم بگیرید، نه بهصورت پیشفرض.
آیا میتوانم این کار را روی سرور اختصاصی هم انجام دهم؟
بله، و در برابرِ سطحی کوچکتر از یک نمونهٔ اشتراکی، چون هیچ هایپروایزری بالای سرتان حافظهٔ شما را در اختیار ندارد. کنترلر مدیریت همچنان آنجاست و همچنان عمرش از سیستمعاملِ شما بیشتر است، پس زنجیرهٔ بوت به همان دقت نیاز دارد. روی سختافزاری که خودتان مالکش هستید، در کابینتی که اجاره میکنید، آنچه باقی میماند یک پرسشِ فیزیکی است.
پس تکلیفِ حافظهٔ رمزنگاریشده، یا محاسبات محرمانه، چه میشود؟
این واقعی است و هدفِ درستی هم هست: AMD SEV-SNP و Intel TDX حافظهٔ ماشین مهمان را در برابر هایپروایزر رمزنگاری میکنند، که دقیقاً همان شکافی است که کل این صفحه دربارهٔ آن نوشته شده. آن بخشی که به این موضوع معنا میدهد، تأیید از راه دور است — اثباتی، برای شما، مبنی بر اینکه دستگاهی که با آن در ارتباطید دقیقاً همان چیزی را اجرا میکند که فکر میکنید، و در همان حالتی که فکر میکنید. ارائهدهندهای که “RAM رمزنگاریشده” را عرضه میکند بدون تأییدی که خودتان بتوانید راستیآزمایی کنید، در حال عرضهٔ یک ادعاست، نه یک کنترل.
هر قیمت در این مجموعه بهطور کامل و در یک مکان منتشر شده است. کل کاتالوگ را ببینید