در مطلب قبل، نقش Secure Boot در محافظت از Boot Chain و نحوه فعال‌سازی آن را بررسی کردیم. اما فعال‌کردن Secure Boot پایان کار نیست. ممکن است این قابلیت امروز روی یک Host فعال باشد، اما پس از به‌روزرسانی Firmware، تعویض Motherboard، تغییر تنظیمات UEFI، نصب یک Component جدید یا بروز اختلال در TPM و Attestation، وضعیت Trust آن تغییر کند.
اگر سازمان فقط یک‌بار Secure Boot را فعال کند و دیگر وضعیت آن را بررسی نکند، در عمل یک تنظیم امنیتی دارد، نه یک کنترل امنیتی پایدار. کنترل زمانی معنا پیدا می‌کند که بتوان به‌طور مستمر مشخص کرد:
آیا Secure Boot همچنان فعال است؟
آیا Host با زنجیره مورد اعتماد Boot شده است؟
آیا VIB یا Component جدید و غیرمنتظره‌ای نصب شده است؟
آیا vCenter توانسته وضعیت Host را Attest کند؟
آیا تغییر مشاهده‌شده با Change Request مجاز تطابق دارد؟
در صورت ایجاد Alarm، چه کسی و در چه زمانی باید آن را بررسی کند؟
در این راهنما، بررسی و پایش وضعیت امنیتی Hostها را در دو بخش دنبال می‌کنیم:
1. ابتدا اصول پایش Secure Boot در VMware را بررسی می‌کنیم؛
2. سپس به مراحل عملی پایش Secure Boot در VMware می‌پردازیم.
هدف این است که تیم‌های زیرساخت بتوانند کنترل‌های لازم پس از Reboot ،Update و تعمیرات را مشخص کنند، تفاوت میان تغییر مجاز، خطای فنی و رخداد امنیتی را تشخیص دهند و برای بررسی Alarmها، ثبت شواهد و پاسخ‌گویی، مسیر روشنی داشته باشند.
بخش اول: اصول پایش Secure Boot در VMware
در این بخش، مؤلفه‌های اصلی پایش Secure Boot و شواهد لازم برای ارزیابی مداوم وضعیت Trust در Hostهای VMware را بررسی می‌کنیم.
چرا فعال‌بودن Secure Boot کافی نیست؟
Secure Boot یک وضعیت ثابت روی مشخصات سرور نیست. رویدادهای مختلف می‌توانند وضعیت آن یا امکان اثبات Trust را تغییر دهند:
- غیرفعال‌شدن Secure Boot در UEFI
- تغییر Boot Mode از UEFI به Legacy BIOS
- Reset شدن تنظیمات BIOS پس از تعمیر یا Firmware Update
- تعویض Motherboard یا TPM
- تغییر کلیدها و Trust Databaseهای UEFI
- نصب یا Update شدن VIB و Component
- تغییر ESXi Image یا Vendor Add-on
- شکست TPM Attestation
- نامعتبر یا منقضی‌شدن Certificate مورد استفاده در Auto Deploy
- قطع Remote Syslog
- باقی‌ماندن یک Exception موقت پس از پایان زمان مجاز
همه این تغییرات الزاماً امنیتی نیستند. برای مثال، تعویض Motherboard پس از خرابی می‌تواند TPM جدیدی وارد محیط کند. اما همین تغییر اگر بدون Change Record و خارج از Maintenance Window مشاهده شود، نیازمند بررسی جدی است.
بنابراین سؤال اصلی فقط این نیست که «Secure Boot فعال است یا خیر؟» بلکه باید مشخص شود:
وضعیت مورد انتظار چیست، وضعیت فعلی چیست، چه چیزی تغییر کرده و آیا منشأ این تغییر مجاز و قابل اثبات است؟
پایش Secure Boot دقیقاً به چه معناست؟
پایش Secure Boot فقط اجرای دوره‌ای یک Command نیست. یک مدل قابل اتکا باید پنج لایه را در کنار یکدیگر بررسی کند:
| لایه | پرسش اصلی |
|---|---|
| Desired State | هر Host براساس Baseline سازمان باید در چه وضعیتی باشد؟ |
| Observed State | وضعیت فعلی Boot Mode ،Secure Boot و TPM چیست؟ |
| Integrity Evidence | امضای VIBها، Tardiskها و Componentها معتبر است؟ |
| Attestation | آیا vCenter می‌تواند وضعیت Boot و هویت TPM را تأیید کند؟ |
| Change Provenance | آیا تغییر با Ticket، زمان، مسئول و دلیل مشخص تطابق دارد؟ |
اگر فقط وضعیت فعلی جمع‌آوری شود، ممکن است بدانیم Secure Boot خاموش است اما ندانیم چه زمانی و چرا این اتفاق افتاده است.
از طرف دیگر، وجود Change Ticket نیز به‌تنهایی کافی نیست، زیرا ممکن است شواهد فنی با تغییر ثبت‌شده تطابق نداشته باشند.
بنابراین Monitoring زمانی ارزش واقعی ایجاد می‌کند که وضعیت فنی Host ،Evidence و سابقه تغییرات در کنار یکدیگر بررسی شوند.
چرا پایش Secure Boot برای Hypervisor اهمیت بیشتری دارد؟
Hypervisor میزبان ماشین‌های مجازی، شبکه مجازی، مسیرهای Storage ،Agentهای Backup و حساب‌های مدیریتی است. در نتیجه، یک تغییر غیرمجاز روی Host می‌تواند دامنه‌ای بسیار گسترده‌تر از یک سیستم‌عامل داشته باشد.
Mandiant در سال ۲۰۲۲ نمونه‌هایی از VIBهای مخرب را گزارش کرد که برای ایجاد Persistence روی VMware ESXi استفاده شده بودند. مهاجم پس از دستیابی به سطح دسترسی مدیریتی، از VIBها برای اجرای Backdoor، انتقال Command و File، اثرگذاری روی Guestها و دست‌کاری Logging استفاده کرده بود.
این رخداد ناشی از یک Remote Code Execution اثبات‌شده در VMware نبود و مهاجم ابتدا به سطح دسترسی مدیریتی نیاز داشت؛ اما نشان داد Hypervisor و Packageهای آن نیز می‌توانند هدف Persistence پیشرفته قرار گیرند.
Broadcom نیز فعال‌بودن Secure Boot و بررسی VIBهای Unsigned را از کنترل‌های مهم کاهش این ریسک معرفی کرده است.
نکته مهم از دید Monitoring این است که اگر وضعیت Boot ،VIBها و دسترسی‌های مدیریتی فقط هنگام بروز اختلال بررسی شود، ممکن است فاصله زیادی میان ایجاد تغییر و شناسایی آن وجود داشته باشد.
نقش Image Compliance ،Signature Integrity و Attestation
در پایش Secure Boot سه مفهوم باید از یکدیگر تفکیک شوند:
Image Compliance
مشخص می‌کند Base Image ،Vendor Add-on ،Firmware Add-on و Componentهای Host با Desired Image سازمان تطابق دارند یا خیر.
Signature Integrity
بررسی می‌کند Packageهای نصب‌شده Signature معتبر دارند و محتوای Boot می‌تواند بررسی Secure Boot را با موفقیت پشت سر بگذارد یا خیر.
Attestation
مرحله‌ای است که در آن vCenter شواهد Host و TPM را ارزیابی کرده و درباره Trust وضعیت Host گزارش می‌دهد.
این سه مفهوم مکمل یکدیگر هستند و هیچ‌کدام جایگزین دیگری نمی‌شوند.
ممکن است یک Component دارای Signature معتبر باشد، اما در Desired Image سازمان وجود نداشته باشد. همچنین ممکن است Secure Boot فعال باشد، اما Attestation به دلیل تغییر TPM یا مشکل Firmware شکست بخورد.
چهار نوع Drift که باید جداگانه بررسی شوند
برای سازمان‌دهی پایش، در این راهنما تغییرات را در چهار گروه عملیاتی دسته‌بندی می‌کنیم.
Firmware Drift
تغییر در Boot Mode ،Secure Boot ،TPM ،TXT ،UEFI Key یا Firmware.
Software Image Drift
تغییر Base Image ،Vendor Add-on ،Component یا VIB نسبت به Desired Image.
Trust Drift
Secure Boot فعال است، اما Attestation شکست خورده، TPM Identity تغییر کرده یا Certificate Chain قابل اعتماد نیست.
Evidence Drift
خود Host ممکن است سالم باشد، اما Remote Syslog قطع شده، Retention کافی نباشد یا ارتباط Eventها با Change Ticket از بین رفته باشد.
Evidence Drift یک شکاف در Observability است و باید مانند یک ریسک مستقل مدیریت شود.
بخش دوم: مراحل عملی پایش Secure Boot در VMware
در این بخش، مراحل عملی پایش Secure Boot در VMware، از تعریف Baseline و بررسی وضعیت Host تا مدیریت Alarmها و حفظ Evidence را مرور می‌کنیم.
- برای Hostها Baseline تعریف کنید.
- وضعیت واقعی Secure Boot و TPM را بررسی کنید.
- Image و VIBها را با Baseline مقایسه کنید.
- TPM Attestation را در vCenter پایش کنید.
- Alarmهای Secure Boot و TPM را اولویت‌بندی کنید.
- تغییر TPM Endorsement Key را بررسی کنید.
- Logها را به‌صورت مرکزی جمع‌آوری کنید.
- Dashboard پایش Secure Boot طراحی کنید.
- تناوب پایش را مشخص کنید.
- Runbook پاسخ به Secure Boot و Attestation Alarm تعریف کنید.
- تعمیرات سخت‌افزاری را وارد مدل پایش کنید.
- Auto Deploy و Certificateها را پایش کنید.
- همه تغییرات را Auto-Remediate نکنید.
- KPIهای پایش Secure Boot را تعریف کنید.
برای Hostها Baseline تعریف کنید
این فهرست، نمونه‌ای از Baseline برای Hostهای مشمول Policy سازمان است. کنترل‌های TPM، Attestation و Recovery Key باید متناسب با قابلیت سخت‌افزار و پیکربندی هر Host اعمال شوند. این Baseline می‌تواند شامل موارد زیر باشد:
- Boot Mode برابر UEFI
- Secure Boot فعال
- TPM 2.0 فعال و قابل مشاهده برای ESXi/ESX
- Require Secure Boot مطابق Policy سازمان
- Image و Build مصوب
- Firmware و Vendor Add-on مصوب
- VIBها و Componentهای مجاز
- حداقل Acceptance Level مجاز
- Attestation برابر Passed
- Remote Syslog فعال
- Recovery Key ثبت‌شده در محل امن
- نبود Exception منقضی‌شده
Baseline الزاماً برای همه Hostها یکسان نیست. اگر یک سرور قدیمی Secure Boot را پشتیبانی نمی‌کند، باید به‌عنوان Exception مدیریت شود؛ با مالک مشخص، دلیل، Compensating Control و تاریخ پایان.
وضعیت واقعی Secure Boot و TPM را بررسی کنید
/usr/lib/vmware/secureboot/bin/secureBoot.py -s
/usr/lib/vmware/secureboot/bin/secureBoot.py -c
Secure boot can be enabled:
All vib signatures verified.
All tardisks validated.
All acceptance levels validated.
این خروجی، موفقیت بررسی مؤلفه‌ها برای استفاده از Secure Boot را نشان می‌دهد؛ فعال‌بودن فعلی Secure Boot را جداگانه با secureBoot.py -s بررسی کنید.
esxcli hardware trustedboot get
esxcli system settings encryption get
این Commandها موضوعات متفاوتی را بررسی می‌کنند و نتیجه یکی نباید جایگزین دیگری شود.
Image و VIBها را با Baseline مقایسه کنید
در vSphere 7 و نسخه‌های بعدی، Component در کنار VIB در مدیریت Software Image قرار گرفته است و vSphere Lifecycle Manager می‌تواند Hostها را با Desired Image در سطح Cluster مقایسه کند.
در این مرحله دو بررسی لازم است:
Image Compliance
تطابق Base Image ،Vendor Add-on ،Firmware Add-on و Componentها با Image مصوب
Signature Integrity
اعتبار Signature مربوط به Packageهای نصب‌شده و محتوای Boot
ممکن است Host از Desired Image منحرف شده باشد، اما Component جدید Signature معتبر داشته باشد. برعکس، ممکن است نام و Version مطابق انتظار باشند، اما Signature Verification یا Tardisk Validation شکست بخورد.
بنابراین Compliance به‌تنهایی اثبات‌کننده Trust نیست.
TPM Attestation را در vCenter پایش کنید
Attestation به vCenter کمک می‌کند وضعیت Boot و هویت TPM را ارزیابی کند.
وضعیت Passed نشان می‌دهد ارزیابی مورد انتظار با موفقیت انجام شده است، اما Failed شدن Attestation الزاماً به معنای نفوذ نیست.
دلایل احتمالی عبارت‌اند از:
- غیرفعال‌شدن Secure Boot
- اختلال TPM یا TXT
- تعویض Motherboard یا TPM
- تغییر Endorsement Key
- نامعتبر بودن Certificate Chain مربوط به TPM
- ناقص‌بودن Metadata مربوط به Image یا VIB
- مشکل Synchronization میان Host و vCenter
- مشکل Firmware یا Hardware
بنابراین:
Attestation Alarm نقطه شروع بررسی است، نه نتیجه نهایی آن.
Alarmهای Secure Boot و TPM را اولویت‌بندی کنید
شدت Alarm باید براساس نوع تغییر، Context و Evidence موجود مشخص شود.
| رویداد | اولویت پیشنهادی |
|---|---|
| Secure Boot برخلاف Baseline غیرفعال شده | بحرانی |
| VIB یا Tardisk دارای Signature نامعتبر | بحرانی تا زمان تعیین علت |
| Attestation از Passed به Failed تغییر کرده | زیاد |
| TPM Endorsement Key بدون Change ثبت‌شده تغییر کرده | بحرانی |
| Host نسبت به Desired Image Non-compliant شده | متوسط تا زیاد |
| VIB جدید با CommunitySupported مشاهده شده | زیاد |
| Remote Syslog قطع شده | زیاد |
| Attestation پس از تعمیر مصوب شکست خورده | زیاد، اما ابتدا عملیاتی |
| Alarm قدیمی باقی مانده و بررسی‌های فعلی موفق‌اند | کم تا متوسط |
Context تعیین‌کننده است. تغییر TPM در Maintenance Window و با Ticket معتبر، با همان تغییر خارج از زمان مجاز و بدون سابقه یکسان نیست.
Stale Alarm را با Incident اشتباه نگیرید
در سناریوی مشخص شرح‌داده‌شده در KB 445840، هشدار Tardisk پس از Update ممکن است باقی‌مانده یک چرخه Boot قبلی باشد. پیش از استفاده از این راهکار، متن Alarm، نسخه و شرایط محیط را با مستند تطبیق دهید و نتیجه بررسی را ثبت کنید.
در صورت انطباق شرایط محیط با این سناریو، بررسی مؤلفه‌ها را با دستور زیر انجام دهید:
/usr/lib/vmware/secureboot/bin/secureBoot.py -c
پس از تأیید نتیجه بررسی و ثبت Evidence، Alarm مطابق مراحل مستند رسیدگی شود. موفقیت این دستور به‌تنهایی مجوز Reset کردن همه Alarmهای مرتبط با VIB، TPM یا Attestation نیست.
هیچ Alarm امنیتی را فقط برای سبزشدن Dashboard پاک نکنید؛ ابتدا Root Cause، وضعیت فعلی و Evidence را ثبت کنید.
تغییر TPM Endorsement Key را بررسی کنید
TPM دارای Endorsement Key است که به شناسایی آن کمک می‌کند. پس از تعویض Motherboard یا TPM، ممکن است vCenter اعلام کند کلید جدید با مقدار ثبت‌شده در Database مطابقت ندارد.
اگر این تغییر با تعمیر مصوب، Serial Number جدید، گزارش Vendor و Change Ticket تطابق داشته باشد، احتمالاً موضوع مربوط به بازبرقراری Trust است.
اما اگر چنین سابقه‌ای وجود نداشته باشد، باید بررسی امنیتی انجام شود.
در محیط‌های vSAN و VCF نیز حذف و اضافه‌کردن Host برای رفع این Alarm می‌تواند عملیات سنگین و جابه‌جایی Data ایجاد کند. بنابراین این سناریو نباید بدون توجه به معماری Cluster مدیریت شود.
Logها را به‌صورت مرکزی جمع‌آوری کنید
Logهای محلی ESXi ممکن است روی Scratch Volume یا Ramdisk قرار داشته باشند. اگر Host از دسترس خارج شود، Rebuild شود یا Logging مورد دست‌کاری قرار گیرد، اتکا به Logهای محلی کافی نیست.
ارسال Logها به Remote Syslog یا SIEM کمک می‌کند Evidence خارج از Host نگهداری و با Eventهای vCenter، Firewall ،BMC و سامانه مدیریت هویت مرتبط شود.
مهم‌ترین Logها برای این نوع Monitoring عبارت‌اند از:
کاربرد
Log
احراز هویت ESXi Shell
auth.log
فعال‌شدن Shell و Commandهای اجراشده
shell.log
Patch ،Update ،VIB و تغییر Image
esxupdate.log
Taskها و Eventهای Host
hostd.log
Boot و بارگذاری Moduleها
sysboot.log
جزئیات Boot
boot.gz
Eventهای Kernel ،Driver و TPM/TXT
vmkernel.log
Warningها و Alertهای VMkernel
vmkwarning.log
VMkernel Observation Eventها
vobd.log
ارتباط Host با vCenter
vpxa.log
سامانه مرکزی باید بتواند رویدادهایی مانند تغییر Secure Boot، شکست Attestation، تغییر TPM Identity، نصب یا حذف VIB، تغییر Acceptance Level، فعال‌شدن SSH، ورود Root، Reboot خارج از Change Window و قطع Syslog را شناسایی کند.
هیچ Source واحدی تصویر کامل ایجاد نمی‌کند؛ بخشی از اطلاعات از ESXi و vCenter و بخشی از BMC ،Ticketing و ابزارهای Lifecycle جمع‌آوری می‌شوند.
Dashboard پایش Secure Boot طراحی کنید
Dashboard مناسب نباید فقط تعداد Hostهای سبز و قرمز را نمایش دهد.
حداقل اطلاعات مفید عبارت‌اند از:
- Host و Cluster
- ESXi/ESX Build
- Boot Mode
- Secure Boot Status
- TPM Present/Mode
- Attestation Status
- Desired Image Compliance
- VIB Signature Result
- Last Reboot
- Last Firmware Change
- Recovery Key Status
- Syslog Health
- Exception ID/Expiry
- Last Verified
Recovery Key ،Credential یا اطلاعات حساس TPM نباید روی Dashboard نمایش داده شوند. فقط وضعیت وجود، زمان کنترل و محل نگهداری مجاز کافی است.
Trusted and Verified
Secure Boot ،Signature Validation ،TPM ،Attestation ،Desired Image و Syslog مطابق Baseline هستند.
Secure but Not Fully Proven
Secure Boot فعال است، اما بخشی از Evidence یا Attestation کامل نیست.
Trust Violation or Unexplained Change
Secure Boot برخلاف Baseline غیرفعال شده، Signature Verification شکست خورده یا TPM Identity بدون Change مجاز تغییر کرده است.
Approved Exception
Host به دلیل محدودیت Hardware یا Workload فعلاً Baseline را اجرا نمی‌کند، اما Exception رسمی با مالک، Compensating Control و تاریخ پایان دارد.
تناوب پایش را مشخص کنید
همه کنترل‌ها نباید با یک فاصله زمانی اجرا شوند.
| تناوب | کنترل |
|---|---|
| نزدیک به Real-time | vCenter Alarm، شکست Attestation ،BMC Event، تغییر VIB و قطع Syslog |
| پس از هر Reboot | Secure Boot Status ،TPM ،Attestation و Boot Error |
| پس از Patch یا Remediation | Image Compliance ،VIB/Tardisk Validation و Attestation |
| پس از Hardware Change | TPM Identity ،Secure Configuration ،Recovery و Attestation |
| روزانه | Hostهای قرمز و زرد، Exceptionها و سلامت Log Collection |
| هفتگی | Signature Sweep و Drift نسبت به Desired Image |
| ماهانه | Firmware ،Baseline ،Exception و دسترسی‌های مدیریتی |
| فصلی | Recovery Runbook ،Recovery Key و معماری Trust |
این تناوب‌ها باید براساس اندازه محیط، حساسیت Workload، الزامات Compliance و ظرفیت تیم عملیات تنظیم شوند.
Runbook پاسخ به Secure Boot و Attestation Alarm تعریف کنید
پیش از Reset یا Acknowledge، زمان، Host ،Cluster ،Build ،Last Reboot، متن Alarm و وضعیت Change Window ثبت شود.
مشخص شود Patch ،Firmware Update، تعویض Motherboard، تغییر TPM یا عملیات Lifecycle از قبل برنامه‌ریزی شده است یا خیر.
Secure Boot ،VIB/Tardisk ،TPM و Secure Configuration بررسی شوند.
Host با Desired Image مقایسه و VIB یا Component جدید، حذف‌شده یا تغییرکرده شناسایی شود.
Logهای ESXi ،vCenter ،BMC ،Firewall ،PAM و Ticketing در یک بازه زمانی مشترک بررسی شوند تا ارتباط میان Firmware Change، ورود مدیریتی، Reboot و Package Change مشخص شود.
- اگر Root Cause مجاز و Evidence کافی است، اصلاح فنی انجام و Alarm مستند شود.
- اگر علت نامشخص است، موضوع به مسئول پاسخ‌گویی به رخداد امنیتی ارجاع شود. نوع محدودسازی، با توجه به شواهد و اثر احتمالی بر سرویس‌ها تعیین و ثبت شود. اقدامات روی شبکه، Host یا Workload باید مطابق Runbook مصوب سازمان انجام شوند.
- Signature نامعتبر یا دسترسی مدیریتی مشکوک باید به Incident Response ارجاع داده شود.
Reboot ،Reinstall، حذف VIB یا پاک‌کردن Log ممکن است Evidence را تغییر دهد. در رخداد مشکوک، ترتیب اقدامات باید با Incident Response هماهنگ شود.
فقط سبزشدن Alarm کافی نیست. Secure Boot ،Signature Validation ،Attestation ،Desired Image Compliance و Syslog Health باید دوباره بررسی شوند.
تعمیرات سخت‌افزاری را وارد مدل پایش کنید
تعویض Motherboard ،TPM ،CMOS Battery ،CPU یا RAM می‌تواند Firmware و پیکربندی‌های مرتبط با TPM را تحت تأثیر قرار دهد.
پیش از تعمیرات، وضعیت Encryption و وابستگی پیکربندی Host به TPM را بررسی و Configuration Backup تهیه کنید. برای Hostهای TPM-bound، Recovery Key را مطابق مستند نسخه دریافت و در محل امن خارج از Host نگهداری کنید؛ Configuration Backup به‌تنهایی جایگزین آن نیست.
در صورت تعویض قطعه یا برنامه‌ریزی برای ارتقا، بررسی سازگاری سخت‌افزار با نسخه مقصد VMware را نیز در برنامه تغییر قرار دهید.
Runbook تعمیرات باید شامل این موارد باشد:
- ثبت TPM Identity و Attestation پیش از تعمیر
- بررسی Recovery Key بدون قراردادن خود Key در Ticket عمومی
- ثبت Serial Number قطعات قبلی و جدید
- تهیه Configuration Backup
- بررسی UEFI ،Secure Boot و TPM پس از تعمیر
- Re-attestation در vCenter
- بررسی اثر تغییر بر vSAN ،vDS ،vVOL و Cluster Membership
Change زمانی باید بسته شود که وضعیت Host و Evidenceهای مرتبط دوباره با Baseline مورد انتظار تطابق داشته باشند.
Auto Deploy و Certificateها را پایش کنید
در محیط‌های Auto Deploy ،Secure Boot به Certificateها و Boot Fileهای مورد اعتماد UEFI وابسته است.
Monitoring این محیط‌ها باید موارد زیر را نیز پوشش دهد:
- Certificate ثبت‌شده در UEFI
- تاریخ اعتبار و وضعیت ابطال Certificate
- Boot File معرفی‌شده در DHCP
- Hash و منشأ PXE Fileها
- تغییر Ruleها و Image Profileهای Auto Deploy
- موفقیت Boot آزمایشی پس از Firmware یا Certificate Update
ممکن است Host در وضعیت فعلی بدون مشکل کار کند، اما در Reboot بعدی به‌دلیل Certificate یا Boot File قدیمی دچار اختلال شود.
همه تغییرات را Auto-Remediate نکنید
Automation برای جمع‌آوری وضعیت و ایجاد Alarm مفید است، اما بعضی اقدامات باید نیازمند Approval و Maintenance Window باشند:
- تغییر Secure Boot در UEFI
- تغییر TPM Mode یا Secure Boot Enforcement
- حذف VIB ناشناس
- Reset یا Clear کردن TPM
- حذف و اضافه‌کردن Host به vCenter
- تغییر Database برای رفع TPM mismatch
- Reboot کردن Production Host
- Image Remediation در Cluster حساس
- Reset کردن Alarm پیش از ثبت Root Cause
Automation بهتر است ابتدا Evidence جمع‌آوری کند، تغییر را طبقه‌بندی کرده و اقدام مناسب را پیشنهاد دهد.
KPIهای پایش Secure Boot را تعریف کنید
برای گزارش‌های امنیت و عملیات می‌توان KPIهای زیر را دنبال کرد:
- درصد Hostهای دارای Secure Boot فعال
- درصد Hostهای دارای Attestation برابر Passed
- تعداد Hostهای دارای VIB یا Component خارج از Allowlist
- تعداد شکست‌های Signature Validation
- میانگین زمان تشخیص تغییر Secure Boot
- میانگین زمان تعیین Root Cause برای Attestation Alarm
- درصد تغییرات TPM/Firmware دارای Change Ticket معتبر
- درصد Hostهای دارای Remote Syslog سالم
- درصد Hostهای TPM-bound دارای Recovery Key تأییدشده
- تعداد Exceptionهای منقضی‌شده
- مدت باقی‌ماندن Hostها در وضعیت زرد یا قرمز
هدف KPI فقط تولید یک عدد سبز نیست. «تمام Alarmها Reset شده‌اند» شاخص امنیتی معناداری نیست؛ اما «تمام Alarmها دارای Root Cause و Evidence ثبت‌شده‌اند» ارزش عملیاتی بیشتری دارد.
چک‌لیست پایش Secure Boot در VMware
جمع‌بندی؛ Secure Boot باید قابل مشاهده و قابل اثبات باشد
Secure Boot زمانی ارزش عملیاتی کامل پیدا می‌کند که سازمان فقط به فعال‌بودن آن اکتفا نکند و بتواند تداوم Trust را اثبات کند.
Firmware Update ،Hardware Change ،VIB جدید یا شکست Attestation می‌تواند میان Baseline و وضعیت واقعی Host فاصله ایجاد کند.
یک مدل Monitoring مؤثر باید بتواند به چهار سؤال پاسخ دهد:
۱. اکنون چه وضعیتی داریم؟
۲. چه چیزی نسبت به Baseline تغییر کرده است؟
۳. آیا تغییر مجاز و مستند بوده است؟
۴. برای بازگرداندن Trust یا رسیدگی امنیتی چه اقدامی لازم است؟
در محیط VMware، ترکیب Secure Boot Status ،TPM Attestation ،VIB Signature Verification ،Image Compliance ،Remote Logging و Change Management تصویر قابل اتکاتری از وضعیت Host ایجاد می‌کند.
منابع
- Broadcom — UEFI Secure Boot for ESX 9 Hosts
- Broadcom — View ESX Host Attestation Status
- Broadcom — Host TPM Attestation Alarm
- Broadcom — Mitigation and Threat Hunting Guidance for Unsigned VIBs
- Broadcom — Attempting to Mount a Tardisk Without a Valid Signature
- Broadcom — TPM Endorsement Key Mismatch
- Broadcom — Enable TPM on ESXi
- Broadcom — TPM Host Preparation for Hardware Changes
- Broadcom — ESXCLI Software VIB and Component Commands
- Broadcom — Check Compliance Against an Image
- Broadcom — Configuring Syslog on ESXi
- Broadcom — Location and Contents of ESXi Log Files
- Broadcom — UEFI Secure Boot with vSphere Auto Deploy
- Mandiant — Malware Persistence Within ESXi Hypervisors