رمزگذاری دیسک از چه چیزی محافظت می‌کند؟
رمزگذاری دیسک برای حالتی ارزشمند است که رسانه ذخیره‌سازی از کنترل شما خارج شود. لپ‌تاپ گم‌شده، دیسک تعویض‌شده یا نسخه خامی از یک حجم ذخیره‌سازی می‌تواند داده‌هایی داشته باشد که نباید بدون مجوز خوانده شوند. در لینوکس، dm-crypt لایه‌ای برای رمزگذاری دستگاه بلوکی فراهم می‌کند و LUKS قالبی برای مدیریت اطلاعات لازم این کار است. cryptsetup ابزار مدیریت این مجموعه است. شناخت تفاوت این نام‌ها مهم است: قالب روی دیسک، نگاشت فعال در هسته و برنامه مدیریتی مسئولیت‌های یکسانی ندارند. مشکل در هر لایه نیز با روش متفاوتی بررسی می‌شود.
این حفاظت به معنی امن‌شدن خودکار یک سیستم روشن نیست. وقتی حجم باز شده و فایل‌سیستم روی آن در دسترس است، برنامه دارای مجوز می‌تواند داده را بخواند. مهاجمی که در همان سیستم به دسترسی کافی رسیده باشد ممکن است از همین مسیر استفاده کند. بنابراین رمزگذاری دیسک جایگزین کنترل دسترسی، به‌روزرسانی، جداسازی سرویس یا حفاظت از نشست کاربر نیست. عبارت «دیسک رمز شده» باید همراه با مدل تهدید بیان شود. باید روشن باشد آیا نگرانی سرقت رسانه است، مشاهده داده توسط اپراتور زیرساخت است، یا نفوذ به یک سرویس در حال اجرا؛ پاسخ این سناریوها یکسان نیست.
گذرواژه مستقیماً همه بلوک‌ها را رمز نمی‌کند
یک برداشت رایج این است که گذرواژه کاربر همان کلیدی است که برای رمزکردن هر بلوک استفاده می‌شود. در مدل LUKS، کلید حجم و سازوکار بازکردن آن از یکدیگر جدا هستند. Keyslot اطلاعات لازم برای محافظت از کلید حجم با یک راز ورودی را نگه می‌دارد. این جداسازی اجازه می‌دهد چند روش مجاز برای بازکردن یک حجم تعریف شود. همچنین می‌توان گذرواژه را تغییر داد بدون آنکه الزاماً تمام داده‌های حجم از ابتدا رمز شوند. تفاوت میان تغییر راز ورود و تعویض کلید داده در برنامه نگه‌داری باید صریح باشد.
تابع مشتق‌سازی کلید برای تبدیل گذرواژه به ماده کلیدی مناسب به کار می‌رود و هزینه محاسباتی حمله حدس‌زدن را افزایش می‌دهد. انتخاب تنظیمات آن به توان محیط بازکردن حجم وابسته است. ممکن است سروری با حافظه فراوان تنظیمی را به خوبی اجرا کند اما محیط بازیابی کوچک یا سیستم اولیه راه‌اندازی توان کافی نداشته باشد. این موضوع مجوز انتخاب گذرواژه ضعیف نیست. گذرواژه قوی، نگه‌داری صحیح آن و آزمون مسیر بازیابی همگی لازم‌اند. پارامترهایی که تنها روی ماشین اصلی آزمایش شده‌اند، تضمینی برای بازشدن حجم پس از خرابی آن ماشین ایجاد نمی‌کنند.
Header بخشی حیاتی از دارایی است
سرآیند LUKS فقط یک برچسب شناسایی نیست. اطلاعات رمزنگاری و Keyslotها در آن نقش حیاتی دارند. خراب‌شدن این ناحیه می‌تواند دسترسی به داده‌های سالم موجود در باقی دیسک را نیز از بین ببرد. به همین دلیل نسخه پشتیبان Header باید بخشی از برنامه بازیابی باشد. محل نگه‌داری آن نباید فقط همان دیسک رمزگذاری‌شده باشد؛ چنین نسخه‌ای هنگام از دسترس رفتن دیسک قابل استفاده نیست. فایل پشتیبان نیز اطلاعات حساسی دارد و باید با همان دقتی نگه‌داری شود که برای سایر اجزای امنیتی سامانه در نظر گرفته شده است.
وجود نسخه قدیمی Header یک پیامد مهم دارد: اگر آن نسخه شامل Keyslot مربوط به یک گذرواژه قدیمی باشد، حذف آن گذرواژه از Header فعلی به تنهایی همه نسخه‌های پیشین را باطل نمی‌کند. در تحلیل دسترسی باید هم داده رمز شده و هم نسخه‌های سرآیند را در نظر گرفت. این نکته برای خروج کارکنان، افشای گذرواژه یا تغییر سیاست کلید اهمیت دارد. ثبت اینکه چه زمانی از Header نسخه گرفته شده، چه کسانی به آن دسترسی دارند و چگونه نسخه‌های قدیمی مدیریت می‌شوند، بخشی از چرخه عمر امنیت است؛ صرف اجرای یک فرمان حذف Keyslot پایان این فرایند نیست.
چند Keyslot برای چند مسئولیت
داشتن بیش از یک Keyslot می‌تواند به جداسازی مسیر روزمره و بازیابی کمک کند. برای مثال یک راز برای راه‌اندازی عادی و راز دیگری برای بازیابی اضطراری نگه‌داری می‌شود. این طراحی تنها وقتی مفید است که راز بازیابی واقعاً مستقل، قابل دسترس و آزموده باشد. ذخیره هر دو راز در یک فایل روی همان ماشین، استقلال عملی ایجاد نمی‌کند. همچنین باید بدانیم کدام slot فعال است و هر کدام چه مالک و کاربردی دارد. شماره slot به خودی خود هویت یک فرد را نشان نمی‌دهد؛ ارتباط میان slot و مسئولیت باید در مستندات امن ثبت شود.
پیش از حذف دسترسی قدیمی، مسیر جایگزین باید با یک آزمون واقعی بررسی شود. قبول‌شدن فرمان افزودن کلید، جای آزمایش بازکردن حجم با همان راز را نمی‌گیرد. در سامانه حساس بهتر است تغییر در پنجره نگه‌داری انجام شود و یک مسیر بازگشت روشن وجود داشته باشد. حذف آخرین راه قابل استفاده برای دسترسی می‌تواند داده را عملاً غیرقابل بازیابی کند. عملیات مدیریت کلید را نباید در اسکریپتی قرار داد که فقط کد خروجی را نگاه می‌کند و وضعیت نهایی slotها را ثبت نمی‌کند. مشاهده وضعیت پیش و پس از تغییر، شواهد لازم برای بازبینی را فراهم می‌کند.
دستگاه رمز شده با فایل‌سیستم فرق دارد
پس از بازکردن حجم، یک نگاشت دستگاه در اختیار سیستم قرار می‌گیرد. فایل‌سیستم معمولاً روی این دستگاه نگاشت‌شده قرار دارد، نه روی داده خام رمز شده. این مرزبندی در بازیابی و تعمیر حیاتی است. اجرای ابزار تعمیر فایل‌سیستم روی دستگاه اشتباه می‌تواند به جای اصلاح، ساختار لازم را تخریب کند. پیش از هر کار باید مسیر دیسک فیزیکی، پارتیشن، نگاشت رمزگشایی‌شده و نقطه اتصال مشخص شوند. استفاده از نام‌های موقتی دستگاه بدون بررسی شناسه‌ها در محیطی که دیسک‌های متعدد دارد، احتمال خطای انسانی را افزایش می‌دهد.
همین تفکیک هنگام تهیه نسخه پشتیبان نیز مهم است. پشتیبان در سطح فایل پس از بازشدن حجم، محتوای قابل خواندن را می‌بیند و باید خودش حفاظت مناسبی داشته باشد. تصویربرداری از دستگاه خام، داده رمز شده و ساختار مربوط را ثبت می‌کند، اما سازگاری داده در حال تغییر همچنان مسئله‌ای جداگانه است. رمزگذاری باعث نمی‌شود نسخه خام از یک پایگاه داده فعال خودبه‌خود سازگار شود. انتخاب روش پشتیبان باید با نیاز بازیابی فایل، بازیابی کامل دستگاه و ویژگی برنامه هماهنگ باشد. هر روش هزینه، سرعت و وابستگی‌های متفاوتی دارد که باید پیشاپیش سنجیده شوند.
بازشدن خودکار و مرز اعتماد
در محیط‌های مدیریتی ممکن است بازشدن حجم با کلید ذخیره‌شده، سخت‌افزار امن یا سازوکار شبکه‌ای انجام شود. راحت‌تر شدن راه‌اندازی به معنی حذف مسئله کلید نیست؛ فقط محل و شرایط دسترسی به آن تغییر می‌کند. باید پرسید راز کجا نگه‌داری می‌شود، چه کسی می‌تواند آن را درخواست کند و در خرابی شبکه یا تغییر سخت‌افزار چه اتفاقی می‌افتد. اگر کلید بدون کنترل مناسب کنار داده رمز شده قرار داشته باشد، مهاجم رسانه ممکن است هر دو را به دست آورد. طراحی باید با تهدید مورد نظر سنجیده شود، نه تنها با موفقیت راه‌اندازی بدون دخالت انسان.
Tokenهای LUKS2 می‌توانند اطلاعات مرتبط با سازوکارهای بازکردن حجم را نگه دارند، اما وجود Token به تنهایی تضمین نمی‌کند ابزار یا محیط فعلی از روش مربوط پشتیبانی کند. محیط اولیه راه‌اندازی، نسخه cryptsetup و اجزای مکمل باید سازگار باشند. پس از تغییر پیکربندی، آزمون راه‌اندازی و مسیر بازیابی ضروری است. در سرور دوردست، خرابی بازشدن حجم ممکن است دسترسی مدیریتی را هم از بین ببرد. وجود کنسول مناسب، مسئول پاسخ‌گو و دستورالعملی که بدون اتکا به همان دیسک قابل خواندن باشد، تفاوت میان یک تغییر قابل مدیریت و یک توقف طولانی را ایجاد می‌کند.
کارایی، discard و فرض‌های نادرست
رمزگذاری در مسیر ورودی و خروجی هزینه پردازشی دارد، اما اثر واقعی آن به پردازنده، الگوریتم، اندازه درخواست و الگوی بار وابسته است. نتیجه یک آزمون مصنوعی نباید مستقیماً به پایگاه داده یا فایل‌سرور تعمیم داده شود. باید تأخیر و توان عملیاتی بار واقعی را قبل و بعد از تغییر سنجید. تنظیمی که سرعت ترتیبی را بهتر می‌کند ممکن است برای درخواست‌های کوچک تصادفی اثر متفاوتی داشته باشد. همچنین گلوگاه ممکن است از خود دیسک، صف ورودی و خروجی یا برنامه باشد؛ نسبت‌دادن هر کندی به رمزگذاری بدون شواهد، مسیر بررسی را منحرف می‌کند.
عبور discard یا TRIM می‌تواند اطلاعاتی درباره الگوی استفاده از بلوک‌ها آشکار کند. این موضوع با افشای مستقیم محتوای فایل برابر نیست، اما برای برخی مدل‌های تهدید مهم است. تصمیم درباره فعال‌کردن آن باید با نیاز ذخیره‌سازی و سیاست محرمانگی گرفته شود. همچنین رمزگذاری معمول دستگاه بلوکی را نباید با تضمین جامع تمامیت داده اشتباه گرفت. حفاظت در برابر خواندن غیرمجاز و تشخیص هر نوع تغییر مخرب روی رسانه دو هدف متفاوت‌اند. قابلیت‌های تمامیت و روش پیکربندی آن‌ها نیازمند بررسی جداگانه نسخه و مستندات هستند و نباید از صرف وجود نام LUKS نتیجه گرفته شوند.
سناریوی بازیابی و کنترل نهایی
فرض کنیم سرور دیگر بوت نمی‌شود، ولی دیسک در یک محیط نجات دیده می‌شود. نخست باید سلامت سخت‌افزار و امکان خواندن امن رسانه بررسی شود. سپس بدون نوشتن ناخواسته، نوع دستگاه و وضعیت Header شناسایی می‌شود. اگر خطر خرابی بیشتر وجود دارد، تهیه تصویر مناسب پیش از تلاش‌های تکراری ارزشمند است. مسیر رمزگشایی و مسیر تعمیر فایل‌سیستم دو مرحله جدا هستند. در دسترس نبودن گذرواژه، خرابی Header و خرابی فایل‌سیستم علائم و راهکارهای متفاوتی دارند. امتحان تصادفی فرمان‌های تعمیر، بدون تشخیص این لایه‌ها، می‌تواند فرصت بازیابی را کاهش دهد.
برای ارزیابی آمادگی، یک بازیابی کنترل‌شده روی محیط جدا انجام دهید: اطلاعات کلید را از محل تعیین‌شده دریافت کنید، حجم آزمایشی را باز کنید، فایل‌های نمونه را بخوانید و زمان لازم را ثبت کنید. اگر دستورالعمل به حافظه یک نفر وابسته است، هنوز برنامه بازیابی کامل نیست. پس از هر تغییر در روش بازکردن، وضعیت نسخه پشتیبان Header و دسترسی اضطراری دوباره بررسی می‌شود. ارزش LUKS2 تنها در انتخاب رمز قوی نیست؛ مدیریت دقیق slotها، حفاظت از سرآیند، شناخت مرز دستگاه و فایل‌سیستم و تمرین بازیابی است که رمزگذاری را به کنترل قابل اتکای عملیاتی تبدیل می‌کند.
در بازبینی دوره‌ای، نام و وضعیت slotهای مورد استفاده با فهرست دارندگان دسترسی تطبیق داده شود. خروج یک عضو از تیم فقط تغییر یک رمز روی دستگاه جاری نیست؛ باید نسخه‌های قدیمی سرآیند، مسیرهای نگه‌داری کلید و امکان بازکردن نسخه‌های پشتیبان نیز بررسی شوند. این بازبینی باید بدون نمایش خود عبارت عبور در گزارش انجام شود تا مستندسازی به انتشار راز تبدیل نشود.
