چرا روشنبودن سرور به معنای قابلاعتمادبودن آن نیست؟
روشنشدن ESXi و کارکرد عادی ماشینهای مجازی، سلامت زنجیره Boot را اثبات نمیکند. Secure Boot پیش از اجرای Hypervisor، اعتبار مؤلفههای راهاندازی را بررسی میکند؛ اما فعالسازی آن باید پس از ارزیابی VIBها، سازگاری سختافزار و در Hostهای مبتنی بر TPM، ذخیره Recovery Key انجام شود.
- خاموشبودن Secure Boot مدرک قطعی نفوذ نیست.
- فعالبودن Secure Boot نیز بهتنهایی امنیت کامل Host را تضمین نمیکند.
- پیش از هر تغییر، سازگاری Host را با secureBoot.py -c بررسی کنید.
- فعالسازی این قابلیت باید ابتدا روی یک Host کمریسک پایلوت شود.
در این مطلب، Secure Boot را در دو بخش بررسی میکنیم:
ابتدا با نحوه محافظت از زنجیره راهاندازی ESXi، دامنه حفاظت، محدودیتها، تفاوت آن با TPM و Attestation و ریسکهای غیرفعالبودن آن آشنا میشویم؛ سپس روش بررسی وضعیت Secure Boot، پیشنیازهای فعالسازی، اهمیت Recovery Key و مسیر پیشنهادی اجرای مرحلهای آن را مرور میکنیم.
راهنمای مطالعه
بخش اول: شناخت Secure Boot و نقش آن در امنیت ESXi
در بخش اول، با نحوه عملکرد Secure Boot، دامنه حفاظت، محدودیتها و تفاوت آن با TPM و Attestation آشنا میشویم.
Secure Boot چیست؟
Secure Boot یکی از قابلیتهای استاندارد UEFI است که اعتبار اجزای اولیه راهاندازی را پیش از اجرا بررسی میکند. اگر فایل یا مؤلفهای تغییر کرده باشد، امضای دیجیتال آن دیگر با محتوای فایل مطابقت ندارد. همچنین اگر امضا به یک مرجع مورد اعتماد متصل نباشد یا در فهرست ابطال قرار گرفته باشد، Firmware نباید اجازه اجرای آن را بدهد.
UEFI و Secure Boot یکسان نیستند. ممکن است سرور در حالت UEFI راهاندازی شود، اما Secure Boot همچنان غیرفعال باشد. بنابراین Boot Mode و وضعیت Secure Boot باید جداگانه بررسی شوند.
چرا زنجیره Boot در VMware اهمیت دارد؟
بیشتر ابزارهای امنیتی مانند EDR ،Agentهای مانیتورینگ و سامانههای ثبت رخداد پس از بالا آمدن سیستمعامل یا Hypervisor فعال میشوند. کدی که پیش از این ابزارها اجرا شود، میتواند موقعیت ممتازی داشته باشد و برخی فعالیتهای خود را پنهان کند.
این موضوع در یک Hypervisor اهمیت بیشتری دارد؛ زیرا آلودگی یا دستکاری ESXi فقط یک سیستم را تهدید نمیکند. یک Host ممکن است میزبان دهها یا صدها ماشین مجازی باشد و به شبکههای مجازی، Credentialهای مدیریتی، Storage و Backup دسترسی داشته باشد.
در سال ۲۰۲۲، Mandiant بدافزارهایی را بررسی کرد که با استفاده از VIBهای مخرب روی ESXi ماندگار میشدند و امکان اجرای فرمان، انتقال فایل و دستکاری Logها را فراهم میکردند. نصب این VIBها به دسترسی مدیریتی نیاز داشت؛ بنابراین Secure Boot جایگزین حفاظت از حسابهای مدیریتی نیست، اما میتواند ایجاد ماندگاری پنهان پس از نفوذ را دشوارتر کند.
Secure Boot در ESXi چگونه کار میکند؟
در یک مدل ساده، زنجیره اعتبارسنجی چنین است:
Firmware مبتنی بر UEFI اجرا میشود.
UEFI امضای Boot Loader را بررسی میکند.
Boot Loader معتبر، VMkernel را اعتبارسنجی میکند.
مؤلفههای ESXi، از جمله VIBها و Tardiskها، بررسی میشوند.
اگر اعتبارسنجی شکست بخورد، راهاندازی Host متوقف میشود یا خطای امنیتی ایجاد میکند.
VMware از vSphere 6.5 به بعد از Secure Boot برای ESXi پشتیبانی میکند و این قابلیت در ESX 9 نیز بخشی از کنترلهای امنیتی Host است.
نکته درباره نامگذاری: در نسخههای پیش از نسل ۹، Hypervisor مستقل VMware با نام ESXi شناخته میشود؛ اما Broadcom در محصولات نسل ۹ از نام ESX استفاده میکند. به همین دلیل، در این مطلب برای نسخههای قبلی از ESXi و برای نسخه ۹ از ESX استفاده شده است.
Secure Boot از چه چیزهایی محافظت میکند؟
Secure Boot احتمال اجرای مؤلفههای غیرمجاز یا دستکاریشده زیر را کاهش میدهد:
- Boot Loader نامعتبر
- Kernel یا Hypervisor تغییریافته
- UEFI Driver و Option ROM غیرقابلاعتماد
- بعضی Bootkitها و Rootkitهای ماندگار
- Image یا ابزار Boot غیرمجاز
- VIBها و Tardiskهای فاقد امضای معتبر در ESXi
بااینحال، داشتن امضای دیجیتال معتبر لزوماً به معنای امن و بدون نقص بودن یک مؤلفه نیست. ممکن است یک نسخه آسیبپذیر، بدون آنکه دستکاری شده باشد، همچنان امضای معتبر Vendor را داشته باشد.
Secure Boot چه کاری انجام میدهد و چه کاری انجام نمیدهد؟
Secure Boot یکی از لایههای دفاع است، نه یک راهکار کامل امنیتی.
قابلیتهای Secure Boot
- اعتبارسنجی Boot Loader و VMkernel
- جلوگیری از اجرای VIB و Tardisk نامعتبر
- کاهش بعضی روشهای ماندگاری در زنجیره Boot
- تقویت اعتماد به مؤلفههای راهاندازی
- پشتیبانی از ارزیابی وضعیت Boot
- محدودکردن اجرای اجزای غیرقابلاعتماد
محدودیتهای Secure Boot) Secure Boot نمیتواند:)
- از سرقت Password، Session یا Token جلوگیری کند.
- Datastore یا دیسک سرور را رمزگذاری کند.
- مانع Exploit شدن سرویسهای در حال اجرا شود.
- جایگزین Patch Management، MFA و RBAC شود.
- از تمام انواع Ransomware جلوگیری کند.
- سلامت تمام فعالیتهای Host پس از Boot را اثبات کند.
برای نمونه، Secure Boot نمیتواند جای نصب Patchهای امنیتی مربوط به آسیبپذیریهایی مانند CVE-2026-47876 در VMware و امکان فرار از VM به میزبان ESXi را بگیرد.
دسترسیهای BMC مانند iLO، iDRAC و IPMI نیز باید بهصورت جدی محافظت شوند. مهاجمی که به تنظیمات Firmware دسترسی داشته باشد، ممکن است Secure Boot را غیرفعال یا تنظیمات Boot را تغییر دهد.
فناوریهای امنیت Boot در VMware چه تفاوتی دارند؟
این فناوریها مکمل یکدیگرند، اما هرکدام وظیفه متفاوتی دارند:
| فناوری | وظیفه اصلی |
|---|---|
| UEFI | آمادهسازی سختافزار و مدیریت فرایند Boot |
| Secure Boot | جلوگیری از اجرای مؤلفهای که امضای معتبر ندارد |
| Measured Boot | ثبت اندازهگیری رمزنگاریشده اجزای مشاهدهشده هنگام Boot |
| TPM | نگهداری امن اندازهگیریها و برخی کلیدها در سختافزار |
| Attestation | ارزیابی شواهد Boot توسط مرجعی بیرونی مانند vCenter |
Secure Boot بدون TPM نیز قابل استفاده است؛ اما در Hostهای جدید VMware، ترکیب UEFI Secure Boot، TPM 2.0 و Attestation سطح اعتماد بیشتری ایجاد میکند. پیش از اجرا نیز باید سازگاری سرور، TPM، BIOS و Firmware در Broadcom Compatibility Guide بررسی شود.
VIBها چه نقشی در امنیت ESXi دارند؟
VIB یا vSphere Installation Bundle بستهای است که برای نصب یا بهروزرسانی مؤلفههای ESXi استفاده میشود. Driverهای شبکه و Storage، Agentهای Backup و برخی ابزارهای مانیتورینگ ممکن است به شکل VIB نصب شوند.
VIBها در سطوحی مانند موارد زیر قرار میگیرند:
VMwareCertified
VMwareAccepted
PartnerSupported
CommunitySupported
Acceptance Level سطح بررسی و پشتیبانی VIB را مشخص میکند؛ اما مشاهده این مقدار بهتنهایی برای اثبات اعتبار VIB کافی نیست و امضای دیجیتال نیز باید بررسی شود. در محیط Production، هر VIB جانبی باید از نظر Vendor، نسخه، سازگاری، امضا و وضعیت Lifecycle ارزیابی شود. اگر یک محصول به VIB بدون امضا وابسته است، راه درست دریافت نسخه امضاشده و پشتیبانیشده از Vendor است، نه غیرفعالکردن دائمی Secure Boot.
اگر Secure Boot غیرفعال باشد چه اتفاقی میافتد؟
ممکن است از نظر عملیاتی هیچ اختلالی مشاهده نشود. ESXi بالا میآید و قابلیتهایی مانند HA، DRS و vMotion نیز کار میکنند. بااینحال، از نظر امنیتی:
- زنجیره Boot فاقد Enforcement رمزنگاریشده کامل است.
- احتمال اجرای مؤلفه دستکاریشده یا غیرقابلاعتماد افزایش مییابد.
- مهاجم دارای دسترسی سطح بالا فرصت بیشتری برای ایجاد ماندگاری پیدا میکند.
- TPM Attestation ممکن است ناموفق شود یا در vCenter هشدار ایجاد کند.
- الزامات Hardening یا Compliance سازمان ممکن است برآورده نشوند.
خاموشبودن Secure Boot مدرک وقوع نفوذ نیست و فعالکردن آن نیز سلامت گذشته Host را ثابت نمیکند. اگر Host مدت زیادی بدون این کنترل کار کرده است، باید VIBها، تغییرات Image، دسترسیهای مدیریتی، وضعیت SSH، هشدارهای Attestation و پیوستگی Logها بررسی شوند. مشاهده VIB مشکوک، امضای نامعتبر یا دسترسی مدیریتی توضیحناپذیر به بررسی Incident Response نیاز دارد. در صورت تأیید آلودگی، ممکن است بازسازی Host با Image مورد اعتماد و تعویض Credentialهای مرتبط ضروری باشد.
آیا فعالسازی Secure Boot میتواند برای ESXi مشکل ایجاد کند؟
بله؛ اگر بدون ارزیابی قبلی انجام شود.
ممکن است زیرساخت از Driver، VIB، روش Boot یا Automation قدیمی استفاده کند که با Secure Boot سازگار نیست. فعالسازی شتابزده میتواند پیامدهای زیر را ایجاد کند:
- Boot نشدن Host
- نمایش PSOD
- از کار افتادن Driver یا Agent جانبی
- شکست PXE یا Auto Deploy
- ایجاد هشدار Attestation
- طولانیشدن Maintenance Window
- نیاز به Rollback یا Recovery Key
بنابراین راه درست، صرفنظرکردن از Secure Boot نیست؛ بلکه باید سازگاری Host پیش از تغییر بررسی و قابلیت ابتدا روی یک Host کمریسک پایلوت شود.
بخش دوم: راهنمای عملی بررسی و فعالسازی Secure Boot
در ادامه، دستورهای بررسی وضعیت، پیشنیازهای فعالسازی، روش نگهداری Recovery Key و مسیر پیشنهادی اجرای مرحلهای Secure Boot را مرور میکنیم.
چگونه وضعیت Secure Boot را در ESXi بررسی کنیم؟
Broadcom ابزار بررسی Secure Boot را در ESXi ارائه کرده است.
/usr/lib/vmware/secureboot/bin/secureBoot.py -c/usr/lib/vmware/secureboot/bin/secureBoot.py -sesxcli hardware trustedboot getesxcli system settings encryption getپیش از فعالسازی Secure Boot چه مواردی را بررسی کنیم؟
پیش از فعالکردن Secure Boot، این موارد را کنترل کنید:
- سازگاری سرور، BIOS، Firmware و TPM با نسخه ESXi یا ESX
- اعتبار و سازگاری VIBها و Driverهای جانبی
- Boot Mode، Boot Media و روش مدیریت Image
- دسترسی به کنسول فیزیکی یا Remote Console
- تهیه Configuration Backup و در صورت استفاده از TPM، ذخیره Recovery Key
- وجود برنامه Rollback و یک Host کمریسک برای پایلوت
نسخه و چرخه پشتیبانی پلتفرم نیز باید در این ارزیابی در نظر گرفته شود. اگر زیرساخت سازمان بر پایه vSphere 8 است، بررسی کنید که با توجه به پایان پشتیبانی عمومی VMware vSphere 8، فعالسازی Secure Boot بخشی از Hardening نسخه فعلی است یا باید در برنامه گستردهتری برای ارتقا و مهاجرت قرار گیرد.
Recovery Key را پیش از خرابی ذخیره کنید
در Hostهایی که Secure Configuration به TPM متصل است، تغییر Motherboard، TPM یا برخی تنظیمات Firmware ممکن است مانع بازیابی پیکربندی رمزگذاریشده شود. در این شرایط، Configuration Backup بهتنهایی کافی نیست.
Recovery Key را زمانی که Host سالم است، با دستور زیر استخراج کنید:
esxcli system settings encryption recovery list
کلید بازیابی را خارج از Host و در یک Vault یا سامانه امن مدیریت اسرار نگهداری کنید. بهتر است Hostname، Asset ID و زمان استخراج نیز همراه آن ثبت شود و دسترسی به کلید محدود و قابل ردیابی باشد.
مسیر پیشنهادی برای فعالسازی مرحلهای
برای کاهش ریسک عملیاتی، فعالسازی را در شش مرحله انجام دهید:
- موجودیبرداری: Hostها، نسخه ESXi یا ESX، Boot Mode، Firmware، TPM و VIBها را ثبت کنید.
- بررسی سابقه: تغییرات Image، دسترسیهای مدیریتی، SSH، Lockdown Mode، BMC، Attestation و Logها را بررسی کنید.
- اعتبارسنجی: دستور secureBoot.py -c را اجرا و هر VIB یا Tardisk نامعتبر را اصلاح کنید.
- طراحی Recovery: از پیکربندی Backup بگیرید و در Hostهای مبتنی بر TPM، Recovery Key را ذخیره کنید. مسیر Rollback و معیار توقف را نیز مشخص کنید.
- اجرای پایلوت: یک Host نماینده و کمریسک را انتخاب و پس از تخلیه VMها، Secure Boot را طبق راهنمای Vendor فعال کنید.
- گسترش کنترلشده: تغییرات را روی گروههای کوچک اجرا و نتیجه هر مرحله را پیش از ادامه ارزیابی کنید.
پس از پایلوت، وضعیت Boot، TPM Attestation، Network، Storage، Backup، Monitoring، HA و Lifecycle Manager را آزمایش کنید. انجام حداقل یک Reboot برنامهریزیشده دیگر نیز به تأیید تکرارپذیری نتیجه کمک میکند.
Secure Boot میزبان با Secure Boot ماشین مجازی تفاوت دارد
در VMware دو زنجیره Boot مستقل وجود دارد:
| سطح | دارایی تحت حفاظت |
|---|---|
| Host Secure Boot | Firmware، Boot Loader، VMkernel و مؤلفههای ESXi یا ESX |
| VM Secure Boot | Boot Loader، Kernel و Driverهای سیستمعامل داخل ماشین مجازی |
| Physical TPM | اندازهگیریها و اسرار Host فیزیکی |
| vTPM | قابلیتهای TPM در اختیار Guest OS |
Host Secure Boot و VM Secure Boot مستقل از یکدیگرند. برای فعالسازی Secure Boot ماشین مجازی، Firmware آن باید معمولاً EFI باشد و Guest OS و Virtual Hardware نیز از این قابلیت پشتیبانی کنند. تغییر مستقیم VM قدیمی از Legacy BIOS به EFI ممکن است مانع Boot شدن آن شود.
Baseline پیشنهادی برای Hostهای جدید VMware
برای نصبهای جدید VCF 9، VVF 9 یا ESX 9، موارد زیر میتوانند بخشی از Baseline امنیتی باشند:
- استفاده از سختافزار، BIOS و Firmware تأییدشده
- Boot در حالت UEFI همراه با Secure Boot و TPM 2.0 سازگار
- استفاده انحصاری از Imageها، Driverها و VIBهای امضاشده و پشتیبانیشده
- جداسازی شبکه مدیریت و BMC و ثبت دسترسیهای iLO، iDRAC و IPMI
- غیرفعالبودن پیشفرض ESXi Shell و SSH و فعالسازی موقت آنها فقط در بازه مصوب
- نگهداری Configuration Backup و Recovery Key خارج از Host
- پایش Attestation و ثبت استثناهای امنیتی همراه با مالک، علت و تاریخ پایان
روشن یا خاموش بودن Secure Boot نباید به تنظیم پیشفرض کارخانه یا سلیقه نصاب وابسته باشد؛ این موضوع باید یک تصمیم معماری مستند باشد.
جمعبندی
کارکرد عادی ESXi و ماشینهای مجازی، سلامت زنجیره Boot را اثبات نمیکند. Secure Boot پیش از اجرای Hypervisor، اعتبار مؤلفههای راهاندازی را بررسی میکند و احتمال اجرای Boot Loader، VMkernel یا VIB دستکاریشده را کاهش میدهد؛ بااینحال، بهتنهایی امنیت کامل Host را تضمین نمیکند. اگر Secure Boot غیرفعال است، مسیر درست شامل بررسی VIBها و سابقه تغییرات، اعتبارسنجی سازگاری، تهیه Configuration Backup، ذخیره Recovery Key در Hostهای مبتنی بر TPM و اجرای پایلوت است. در Hostهای جدید نیز ترکیب UEFI Secure Boot، TPM 2.0، Attestation، VIBهای امضاشده و حفاظت از شبکه مدیریت باید بخشی از Baseline امنیتی باشد.
پرسشهای متداول
- آیا خاموشبودن Secure Boot یعنی Host آلوده شده است؟
خیر. این وضعیت یک شکاف کنترلی است، نه مدرک نفوذ؛ برای نتیجهگیری باید VIBها، Logها، تغییرات Image و دسترسیهای مدیریتی بررسی شوند. - آیا Secure Boot بدون TPM فعال میشود؟
بله. Secure Boot بدون TPM نیز امضای اجزای Boot را بررسی میکند؛ TPM قابلیتهایی مانند Measured Boot و Attestation را تکمیل میکند. - آیا TPM به معنای فعالبودن Secure Boot است؟
خیر. وجود TPM، استفاده از UEFI و فعالبودن Secure Boot سه وضعیت مستقلاند. - آیا Secure Boot امنیت کامل ESXi را تضمین میکند؟
خیر. این قابلیت باید همراه با Patch Management، MFA، RBAC، Logging، Backup و جداسازی شبکه مدیریت استفاده شود. - آیا میتوان Secure Boot را روی تمام Hostها همزمان فعال کرد؟
توصیه نمیشود؛ ابتدا سازگاری را بررسی و فعالسازی را روی یک Host کمریسک پایلوت کنید.
منابع
- Broadcom — Mitigation and Threat Hunting Guidance for Unsigned VIBs in ESXi
- Broadcom — UEFI Secure Boot for ESX 9 Hosts
- Broadcom — VMware vSphere Support of TPM and TXT
- Broadcom — Enable TPM on ESXi
- Mandiant — Malware Persistence Within ESXi Hypervisors
- UEFI Forum — Secure Boot and Driver Signing
- NIST SP 800-193 — Platform Firmware Resiliency Guidelines