یکی از چالش‌های امنیت زیرساخت مجازی، فاصله بین شناسایی یک مشکل و برطرف کردن آن است.
فرض کنید یک Vulnerability جدی در ESXi اعلام شده است. تیم امنیت می‌گوید باید هرچه سریع‌تر Patch را نصب کنیم. اما تیم زیرساخت باید قبل از آن بررسی کند که این Patch با محیط سازگار است یا نه، جابه‌جایی VMها امکان‌پذیر است یا نه و چه زمانی می‌توان تغییر را با کمترین اختلال اجرا کرد.
گاهی شرایط سخت‌تر هم می‌شود؛ چون هنوز Patch منتشر نشده است. یعنی حتی اگر آماده اجرای تغییر باشیم، چیزی برای نصب نداریم.
در این فاصله چه کار باید کرد؟ Vulnerability وجود دارد، اما سرویس‌های سازمان هم باید به کارشان ادامه دهند. نمی‌توانیم زیرساخت را تا زمان انتشار Patch خاموش کنیم.
از طرف دیگر، همه حمله‌ها از یک Vulnerability نرم‌افزاری شروع نمی‌شوند. ممکن است Password حساب root سرقت شده باشد و مهاجم با یک Credential معتبر وارد Host شود. در این حالت، مسئله فقط برطرف کردن یک Bug نیست؛ مهاجم از مسیری وارد شده که ظاهراً مجاز است.
برای من، سؤال اصلی اینجاست: تا زمانی که Patch را نصب نکرده‌ایم، یا وقتی Credential ادمین سرقت شده است، چه چیزی از خود Hypervisor محافظت می‌کند؟
کمپانی Broadcom با معرفی امکان HyperArmor، یا همان لایه امنیتی HyperArmor، روی همین دو مسئله تمرکز کرده است: Vulnerabilityهای Patchنشده و Credentialهای سرقت‌شده. تمرکز این لایه امنیتی، محافظت از خود ESX است. معرفی رسمی HyperArmor توسط Broadcom
چرا امنیت خود Host اهمیت دارد؟
وقتی یک VM دچار مشکل امنیتی می‌شود، حادثه ممکن است از همان سیستم شروع شود و با توجه به دسترسی‌ها و ارتباطاتش به بخش‌های دیگر گسترش پیدا کند.
اما Host، بستر اجرای چندین VM است. اگر خود این لایه آسیب ببیند، دیگر فقط با یک سیستم‌عامل یا یک سرویس روبه‌رو نیستیم؛ چندین سرویس ممکن است هم‌زمان در معرض خطر قرار بگیرند.
به همین دلیل، من امنیت Windows و Linux داخل VMها را ضروری می‌دانم، اما آن را تمام ماجرا نمی‌بینم. باید از لایه‌ای هم محافظت کنیم که این VMها را اجرا می‌کند.
این تهدید فقط یک احتمال نظری نیست. کمپانی VMware در بررسی Ransomwareهای هدف‌گیرنده ESXi، نمونه‌هایی را توضیح داده که VMها را متوقف می‌کنند و بعد فایل‌های مربوط به آن‌ها را رمزگذاری می‌کنند. در چنین حمله‌ای، مهاجم لازم نیست داخل تک‌تک Guest OSها برنامه‌ای اجرا کند تا به سرویس‌های ما آسیب بزند. بررسی فنی Ransomwareهای هدف‌گیرنده ESXi
البته منظورم این نیست که ESXi تاکنون هیچ قابلیت امنیتی نداشته است. Secure Boot و execInstalledOnly از قبل وجود داشته‌اند، اما هرکدام محدوده مشخصی دارند. برای مثال، کمپانی Broadcom محدودیت جلوگیری از اجرای بعضی Scriptها از طریق Interpreter را در نسخه‌های تا 8.x مستند کرده است. مستند Broadcom درباره محدودیت اجرای Scriptها
پس بحث، نبودن کنترل امنیتی نیست؛ بحث این است که کنترل‌های موجود به‌تنهایی همه مسیرهای حمله را پوشش نمی‌دهند.
امکان HyperArmor دقیقاً چه کاری انجام می‌دهد؟
من امکان HyperArmor، یا لایه امنیتی HyperArmor، را یک لایه محافظتی برای خود Host در نظر می‌گیرم؛ لایه‌ای که روی اجرای برنامه‌ها، Scriptها و رفتارهای غیرمجاز در ESX تمرکز دارد.
برای این محافظت، نیازی به نصب Agent داخل همه Guest VMها نیست. محل تمرکز این لایه امنیتی، زیرساختی است که VMها روی آن اجرا می‌شوند.
سه قابلیت اصلی برای لایه امنیتی HyperArmor معرفی شده است:
- Virtual Patching در سطح Hypervisor
- کنترل Execution و جلوگیری از اجرای نرم‌افزارها و Scriptهای غیرمجاز
- اضافه کردن MFA به مسیر SSH خود ESX
این قابلیت‌ها قرار است در کنار کنترل‌های فعلی کار کنند، نه اینکه جای همه آن‌ها را بگیرند. توضیحات فنی VMware درباره HyperArmor
Virtual Patching؛ محافظت قبل از نصب Patch رسمی
اصطلاح Virtual Patching ممکن است این تصور را ایجاد کند که همان Patch رسمی را با روش دیگری نصب می‌کنیم. اما منظور این نیست.
در اینجا هدف، جلوگیری از عملیات مخربی است که از یک Vulnerability سوءاستفاده می‌کند؛ حتی زمانی که Patch رسمی هنوز منتشر نشده یا روی محیط نصب نشده است.
برای مثال، فرض کنید یک Vulnerability می‌تواند به اجرای کد غیرمجاز روی Host منجر شود. راه اصلاح اصلی، نصب نسخه اصلاح‌شده نرم‌افزار است. اما تا زمانی که آن نسخه آماده شود یا امکان نصب آن فراهم شود، یک کنترل محافظتی می‌تواند جلوی عملیات مخربِ تحت پوشش را بگیرد.
در توضیحات لایه امنیتی HyperArmor، جلوگیری از Execution و File Write غیرمجاز به‌عنوان بخشی از این محافظت مطرح شده است. صفحه رسمی VMware HyperArmor
نکته‌ای که من روی آن تأکید دارم این است: جلوگیری از سوءاستفاده، با اصلاح خود نرم‌افزار فرق دارد.
بنابراین Virtual Patching نباید بهانه‌ای برای عقب انداختن Patchهای رسمی باشد. کاربردش این است که فاصله بین شناسایی خطر و نصب Patch، کم‌ریسک‌تر شود.
همچنین باید مشخص باشد که این محافظت، کدام Vulnerabilityها و روش‌های Exploit را پوشش می‌دهد. نباید از عبارت Zero-day Protection نتیجه بگیریم که تمام حمله‌های ناشناخته متوقف خواهند شد.
فقط نرم‌افزاری اجرا شود که اجازه اجرا دارد
قابلیت بعدی، Positive Security است.
منطق آن ساده است: به‌جای اینکه همیشه منتظر بمانیم یک فایل به‌عنوان Malware شناسایی شود، مشخص کنیم چه نرم‌افزارها و Scriptهایی اجازه اجرا دارند.
روی یک ESX Host قرار نیست هر فایل دلخواهی اجرا شود. لایه امنیتی HyperArmor برای Host یک Baseline ایجاد می‌کند و Execution غیرمجاز را کنترل می‌کند.
طبق توضیح کمپانی Broadcom، Scriptهایی که از قبل روی Host وجود دارند Inventory می‌شوند و به‌صورت خودکار اجازه اجرا می‌گیرند. Scriptهای جدید هم می‌توانند تأیید ادمین را دریافت کنند. معرفی رسمی HyperArmor توسط Broadcom
اینجا از نظر من یک نکته اجرایی مهم وجود دارد: اگر فایل‌های فعلی قرار است مبنای اعتماد اولیه باشند، قبل از راه‌اندازی باید بدانیم روی Host چه چیزی داریم.
Scriptهای قدیمی، فایل‌های ناشناخته و ابزارهایی که دیگر استفاده نمی‌شوند، باید بررسی و تعیین تکلیف شوند. اینکه یک فایل از قبل روی Host بوده، به‌تنهایی دلیل سالم بودن آن نیست.
تیم زیرساخت هم باید بداند که اضافه کردن یک Script جدید، فرایند مشخصی دارد. باید معلوم باشد چه کسی آن را بررسی و تأیید می‌کند و تغییرات چگونه ثبت می‌شوند.
MFA برای SSH؛ Password به‌تنهایی کافی نباشد
ممکن است ورود به پنل مدیریتی را با MFA محافظت کرده باشیم، اما دسترسی مستقیم SSH به Host را جداگانه بررسی نکرده باشیم.
امن کردن یک مسیر ورود، به‌صورت خودکار همه مسیرهای دیگر را امن نمی‌کند.
لایه امنیتی HyperArmor قابلیت MFA را به مسیر SSH خود ESX اضافه می‌کند. طبق توضیح رسمی، بعد از Credential معمول SSH، یک TOTP مرتبط با Identity جداگانه هم لازم است. در نتیجه، داشتن Password سرقت‌شده به‌تنهایی برای دسترسی به Command Line کافی نخواهد بود. توضیحات فنی VMware درباره HyperArmor
البته این قابلیت را نباید به همه مسیرهای مدیریتی تعمیم بدهیم. صحبت از SSH است، نه لزوماً تمام APIها، Consoleها و روش‌های دسترسی.
من هنگام ارزیابی این بخش، Automation و دسترسی اضطراری را هم بررسی می‌کنم. باید مشخص باشد Scriptهای مدیریتی چه وضعیتی پیدا می‌کنند و اگر هنگام Incident مشکلی پیش آمد، تیم از چه مسیر پشتیبانی‌شده‌ای به محیط دسترسی خواهد داشت.
تفاوت Virtual Patching و Live Patching چیست؟
این دو قابلیت ممکن است شبیه به نظر برسند، اما کار یکسانی انجام نمی‌دهند.
Live Patching، Patch واقعی را برای موارد و شرایط پشتیبانی‌شده اعمال می‌کند.
Virtual Patching، جلوی روش‌های سوءاستفاده تحت پوشش را می‌گیرد؛ حتی اگر Patch رسمی هنوز نصب نشده باشد.
پس یکی به اجرای اصلاح واقعی کمک می‌کند و دیگری برای محافظت در فاصله قبل از اجرای اصلاح کاربرد دارد. کمپانی VMware هم توضیح داده که Live Patching به وجود Patch وابسته است و فاصله تا انتشار، تست و نصب آن همچنان می‌تواند باقی بماند. توضیحات فنی VMware درباره HyperArmor
من این دو قابلیت را مکمل هم می‌بینم. Virtual Patching کمک می‌کند زمان لازم برای اجرای درست Patch را با ریسک کمتری طی کنیم، نه اینکه برنامه Patch Management را کنار بگذاریم.
منظور از «بدون Agent و بدون Downtime» چیست؟
در معرفی محصول گفته شده که به Agent داخل Guest VM نیازی نیست. این جمله به معنی نبودن هر نوع Component در سطح Host یا Management نیست.
همچنین کمپانی Broadcom می‌گوید Mitigation از طریق Virtual Patching، به Reboot Host یا Software Upgrade نیاز ندارد. این ادعا درباره همان قابلیت محافظتی است و نباید آن را به نصب اولیه، تمام تغییرات آینده یا همه عملیات لایه امنیتی HyperArmor تعمیم بدهیم. معرفی رسمی HyperArmor توسط Broadcom
درباره Performance هم سازنده از Overhead کم صحبت کرده است. اما من بدون تست و اندازه‌گیری، عددی مثل «صفر درصد» برای محیط سازمان در نظر نمی‌گیرم. رفتار واقعی باید در شرایط همان محیط بررسی شود. صفحه رسمی VMware HyperArmor
تکلیف vDefend و امنیت داخل VM چه می‌شود؟
هر ابزار جایگاه خودش را دارد.
لایه امنیتی HyperArmor روی Host تمرکز می‌کند. vDefend در لایه Network و ارتباطات Workloadها نقش دارد. ابزارهای داخل Guest OS هم باید از سیستم‌عامل و Application محافظت کنند.
این همان نگاه Defense in Depth است؛ چند لایه که هرکدام بخشی از ریسک را کنترل می‌کنند. لایه امنیتی HyperArmor هم در توضیح رسمی، در کنار سایر لایه‌های امنیتی VMware معرفی شده است. توضیحات فنی VMware درباره HyperArmor
بنابراین با اضافه شدن آن، Network Isolation، کنترل دسترسی، Backup و برنامه Recovery حذف نمی‌شوند.
اگر Management Network از هر نقطه‌ای قابل دسترسی باشد، حساب‌های ادمین مشترک باشند یا Restore را تست نکرده باشیم، همچنان مشکلات مهمی داریم. من اضافه کردن ابزار جدید را جایگزین برطرف کردن این موارد نمی‌دانم.
آیا برای محیط فعلی ما قابل استفاده است؟
در خبر معرفی، پشتیبانی از ESX 8.x و نسخه‌های بعدی مطرح شده است. در Blog رسمی هم از VCF و VVF نام برده شده است. معرفی رسمی HyperArmor توسط Broadcom توضیحات فنی VMware درباره HyperArmor
اما این اطلاعات به‌تنهایی برای تصمیم Deploy کافی نیست. باید Buildهای دقیق پشتیبانی‌شده، پیش‌نیازها، روش استقرار، Entitlement و وضعیت دسترسی عمومی محصول از مستندات رسمی بررسی شوند.
معرفی یک محصول را نباید با آماده بودن آن برای استفاده در هر محیطی یکی بدانیم.
اگر بخواهم لایه امنیتی HyperArmor را برای یک سازمان ارزیابی کنم، ابتدا در یک محیط محدود سراغ آن می‌روم. بررسی می‌کنم که با Scriptها و ابزارهای فعلی چه رفتاری دارد، چه Eventهایی ثبت می‌کند، موارد مسدودشده چگونه بررسی می‌شوند و دسترسی اضطراری چگونه انجام می‌شود.
برای من، ارزش اصلی این امکان به همان مسئله ابتدای مقاله برمی‌گردد: همیشه نمی‌توانیم هم‌زمان با شناسایی خطر، Patch رسمی را هم نصب کنیم. از طرف دیگر، همه حمله‌ها از یک Bug شروع نمی‌شوند؛ گاهی Credential معتبر در اختیار مهاجم قرار گرفته است.
امکان HyperArmor قرار است برای این فاصله و این نوع دسترسی، یک لایه محافظتی اضافه کند. نه به‌جای Patch و Hardening؛ در کنار آن‌ها و برای محافظت مستقیم‌تر از خود Hypervisor.
