نبود اتصال مستقیم به اینترنت، یک کنترل امنیتی مهم است؛ اما اگر آن را معادل امنیت بدانیم، به خطرناکترین نقطهٔ معماری تبدیل میشود. در محیط ایزوله، تهدید حذف نمیشود؛ مسیر ورود، نقطهٔ اعتماد و هزینهٔ واکنش تغییر میکند.
رسانهٔ قابل حمل، لپتاپ مهندسی، زنجیرهٔ تأمین، firmware، دسترسی فیزیکی، فرآیند بوت و بستهٔ بهروزرسانی، همگی میتوانند نقش دروازهٔ بیرونی را بازی کنند. از آن مهمتر، محیط آفلاین معمولاً امکان پایش برخط، واکنش فوری و دریافت سریع اصلاحات را ندارد. بنابراین همان کنترلی که سطح مواجههٔ شبکهای را کم میکند، اگر با معماری اعتماد و تغییر همراه نشود، میتواند زمان ماندگاری تهدید را افزایش دهد.
فرض تهدید در محیط ایزوله متفاوت است
بسیاری از فرضهای رایج امنیت سازمانی در این محیط وجود ندارند. اتصال دائمی، SIEM مرکزی برخط، واکنش سریع تیم بیرونی یا نصب فوری وصله ممکن نیست. در مقابل، سناریوهایی اهمیت بیشتری پیدا میکنند که در محیط ابری یا مرکز دادهٔ عمومی کمتر دیده میشوند.
نخست، دسترسی فیزیکی محدود اما معنادار است. مهاجم شاید نتواند ساعتها با سامانه کار کند، اما ممکن است قطعهای را تعویض کند، از رسانهٔ جانبی بوت کند یا ذخیرهساز را خارج سازد. اگر حفاظت فقط پس از بوت آغاز شود، این کنترلها دیر وارد میدان شدهاند.
دوم، آلودگی میتواند پیش از بهرهبرداری شکل گرفته باشد: در firmware، بوتلودر، image اولیه یا فرآیند آمادهسازی. در محیطی که تغییرها دیر و با فاصله اعمال میشوند، چنین آلودگیای میتواند مدت طولانی پنهان بماند.
سوم، تصمیم عملیاتی پس از کشف رخداد الزاماً توقف فوری نیست. مأموریت، ایمنی فیزیکی یا تداوم سرویس ممکن است اجازهٔ خاموشکردن سامانه را ندهد. در اینجا امنیت باید علاوه بر پیشگیری، «آگاهی قابل اثبات از وضعیت» فراهم کند تا مدیر بداند سامانه در چه وضعی است و با چه ریسکی ادامه میدهد.
اعتماد باید پایینتر از سیستمعامل آغاز شود
یک پرسش ساده تعیینکننده است: نخستین چیزی که به آن اعتماد میکنیم چیست؟ اگر پاسخ «سیستمعامل» باشد، زنجیرهٔ پیش از آن نادیده گرفته شده است. سیستمعامل محصول firmware، UEFI، بوتلودر، کرنل، initramfs و درایورهاست. آلودگی هر حلقه، اعتماد به لایههای بالاتر را بیمعنا میکند.
ریشهٔ اعتماد باید کوچک، محدود، قابل اندازهگیری و تا حد ممکن خارج از دسترس مهاجم نرمافزاری باشد. این ریشه نباید با دسترسی root قابل بازنویسی باشد و نباید سلامت خود را از همان سیستمعاملی بگیرد که قرار است ارزیابی کند.
TPM 2.0 میتواند کلیدهای غیرقابل استخراج تولید و نگهداری کند، عملیات رمزنگاری را درون تراشه انجام دهد و اندازهگیری مراحل بوت را در ثباتهای PCR ثبت کند. حتی اگر مهاجم به root برسد، نباید بتواند کلید خصوصی را خام استخراج یا سابقهٔ اندازهگیری مراحل قبلی را پاک کند.
اما ریشهٔ اعتماد شمشیر دولبه است. اگر کلید، سیاست و مسیر recovery بهدرستی طراحی نشده باشند، همان کنترل امنیتی میتواند سامانه را پس از یک بهروزرسانی یا خرابی سختافزاری قفل کند. مسئله فقط فعالکردن TPM نیست؛ مسئله این است که چه کسی کلیدها را کنترل میکند، چه کسی مجاز به تغییر سیاست است و اگر همهچیز طبق انتظار پیش نرفت، چه کسی هنوز اختیار بازیابی دارد.
بوت امن و بوت اندازهگیریشده یک چیز نیستند
بوت امن در سطح UEFI اجازه میدهد فقط مؤلفههای دارای امضای معتبر، از بوتلودر تا کرنل، اجرا شوند. اگر امضا معتبر نباشد، فرآیند متوقف میشود. این کنترل پیشگیرانه است: جزء ناشناخته نباید اجرا شود.
بوت اندازهگیریشده هر مرحله را پیش از اجرا هش میکند و نتیجه را در TPM ثبت مینماید. این کنترل بهجای توقف الزامی، شواهد تولید میکند: سامانه نشان میدهد واقعاً با چه firmware، بوتلودر و کرنلی بالا آمده است. این شواهد میتوانند با وضعیت طلایی مقایسه یا برای آزادسازی مشروط کلید دیسک استفاده شوند.
در محیط آفلاین، ترکیب این دو اهمیت ویژه دارد. سامانه میتواند فقط image مجاز را اجرا کند و همزمان ثابت کند چه چیزی اجرا شده است. با مهرومومکردن کلید دیسک به مقادیر PCR، کلید فقط زمانی آزاد میشود که زنجیرهٔ بوت با وضعیت تأییدشده مطابقت داشته باشد. تعویض مادربورد، تغییر firmware یا دستکاری بوتلودر در این صورت بهطور مستقیم بر دسترسی به داده اثر میگذارد.
این سختگیری باید مسیر بازیابی کنترلشده داشته باشد. اگر هر تغییر مجاز نیز کلید را برای همیشه غیرقابل دسترس کند، سازمان میان امنیت و تداوم مأموریت گرفتار میشود. سیاست بالغ، وضعیتهای مجاز، فرآیند ثبت تغییر، کلیدهای بازیابی، تفکیک اختیار و ممیزی استفاده از recovery را از پیش تعریف میکند.
وصله در محیط آفلاین، یک زنجیره است
بهروزرسانی بدون اینترنت بیش از آنکه مسئلهٔ ابزار باشد، مسئلهٔ لجستیک و حاکمیت است. هر وصله نمایندهای از دنیای بیرون است و باید مسیر زیر را طی کند:
- دریافت در ناحیهای جدا از محیط عملیاتی؛
- اعتبارسنجی امضا، منشأ و تمامیت بسته؛
- بررسی دامنهٔ تغییر و وابستگیها؛
- ساخت snapshot یا نقطهٔ بازگشت معتبر؛
- آزمون روی سختافزار و بار کاری متناظر در staging؛
- تأیید فنی و پذیرش ریسک عملیاتی؛
- انتقال یکطرفه یا کنترلشده به مخزن داخلی؛
- استقرار مرحلهای و ثبت شواهد نتیجه.
سیستمعامل نباید در خطا یا وضعیت خاص، پنهانی به مخزن عمومی متصل شود. همهٔ منابع باید صریح، داخلی و قابل ممیزی باشند. آینهٔ داخلی نیز تنها زمانی قابل اعتماد است که سازمان بتواند نسخهٔ آن، مجموعهٔ بستهها، کلیدها و تغییرهای اعمالشده را بازتولید کند.
آفلاینبودن، مسئولیت انسان را کم نمیکند
در محیط متصل، بخشی از شکست را میتوان با بازیابی از cloud، دریافت فوری بسته یا کمک بیرونی جبران کرد. محیط ایزوله چنین فرصتهایی ندارد. در نتیجه اتکای پنهان به حافظهٔ مدیر سیستم، رسانهٔ بدون شناسنامه یا دستورالعمل غیرنسخهگذاریشده خطرناکتر است.
سامانه باید بتواند بدون «قهرمانسازی انسانی» تغییر کند و بازگردد. ابزار و معماری باید وضعیت را ثبت کنند، اما تصمیم دربارهٔ پذیرش ریسک، استثنا و ادامهٔ مأموریت همچنان انسانی و سازمانی است. حذف اتصال خارجی، مسئولیت حاکمیتی را حذف نمیکند؛ آن را به درون سازمان منتقل میکند.
محیط ایزوله زمانی امنتر است که سازمان مالک ریشهٔ اعتماد، کلیدها، مخازن، فرآیند تغییر و شواهد وضعیت باشد. در غیر این صورت، Air Gap تنها فاصلهای فیزیکی است که تهدید را کند میکند، اما همزمان دید و سرعت واکنش مدافع را نیز کاهش میدهد. گام بعدی این معماری، حفظ و اثبات وضعیت و امکان بازگشت پس از شکست است.