بهبود امنیت ساختار مجازی سازی Hyper-v با راهکار Shielded VM – قسمت دوم (پایانی)

در قسمت اول مقاله توضیح داده شد که یکی از راهکارهای برقراری امنیت در ساختار مجازی‌سازی Hyper-V  پیاده سازی Shielded VM است که با استفاده از آن می توان Hostها یا ماشین‌های مجازی را از خطر آلوده شدن به نرم افزار های مخربی که یک ماشین مجازی را آلوده کرده است، محافظت نمود. در این قسمت به ادامه بحث می­ پردازیم.

Shielding Data چیست و چرا اهمیت دارد؟ Shielding Data File که Provisioning Data File یا PDK هم نام دارد یک فایل رمزگذاری‌شده است که یک Tenant یا کاربر VM آن را ایجاد می‌کند تا از اطلاعات مهم تنظیمات VM، مانند رمز عبور ادمین، RDP و دیگر مدارک مربوط به هویت، اطلاعات اعتباری برای پیوستن به دامین و غیره محافظت کند. ادمین Fabric در هنگام ایجاد یک Shielded VM از Shielding Data File استفاده می‌کند، اما نمی‌تواند اطلاعات موجود در فایل را ببیند یا از آن‌ها استفاده کند.

یک Shielding Data File، حاوی اطلاعات زیر است:

اطلاعات اعتباری ادمین

Answer File یا unattend.xml

یک پالیسی امنیتی که تعیین کند آیا VMهای ایجاد شده با استفاده از این Shielding Data Fileها به‌صورت حفاظت‌شده یا رمزگذاری تنظیم شده‌اند.

از VMهایی که به‌صورت Shielding تنظیم می‌شوند، درمقابل ادمین‌های Fabric حمایت می‌شود، درحالی‌که VMهای رمزگذاری شده، بدین گونه نیستند.

یک RDP Certificate برای ایمن‌سازی ارتباطات دسکتاپ Remote با VM

یک Volume Signature Catalog که حاوی فهرستی از Signatureهای مورد اعتماد بوده که می‌توان VM جدید را از آن ایجاد کرد.

یک Key Protector یا KP که مشخص می‌کند یک Shielded VM، اجازه دارد روی کدام Guarded Fabricها اجرا شود.

PDK تضمین‌ می‌کند که VM طوری ایجاد گردد که موردنظر Tenant باشد، به‌عنوان مثال، وقتی Tenant یک Answer File (unattend.xml) را در Shielding Data File قرار دهد و آن را به Host Provider ارائه کند، Host Provider نمی‌تواند آن Answer File را ببیند یا تغییری روی آن ایجاد کند. به‌طور مشابه، ارائه‌دهنده‌ی Host ‌در هنگام ایجاد Shielded  VM نمی‌تواند یک VHDX متفاوت را جایگزین کند، زیرا Shielding Data File حاوی Signatureهایی از دیسک‌های مورد اعتماد است که می‌توان shielded VMهایی از آن‌ها ایجاد کرد.

شکل زیر Shielding Data File و عناصر پیکربندی مربوط به آن‌ها را نشان می‌دهد.

روش­های اجرای ماشین مجازی توسط Guarded Fabric

Guarded Fabricها توانایی اجرای VMها را به سه روش زیر دارند:

یک VM عادی که هیچ محافظتی را بیشتر از نسخه‌های قبلی Hyper-V ارائه نمی‌دهد.

یک VM رمزگذاری شده، که حفاظت از‌ آن را می‌توان توسط یک ادمین fabric تنظیم کرد.

یک VM حفاظت‌شده که حفاظت‌های آن همگی فعال هستند و یک ادمین fabric نمی‌تواند آن‌ها را غیرفعال نماید

VMهایی که رمزگذاری شده ­اند، باید درجایی مورد استفاده قرار گیرند که ادمین‌های fabric کاملاً مورداعتماد باشند. برای مثال ممکن است سازمانی برای دستیابی به تطبیق‌پذیری، یک Guarded Fabric را پیاده‌سازی کند تا اطمینان حاصل نماید که دیسک‌های VM به‌صورت At-Rest رمزگذاری شده‌اند. ادمین‌های fabric می‌توانند به استفاده از ویژگی‌های مدیریتی موردنظر خود، مثل PowerShell Direct، اتصالات کنسول VM و دیگر ابزار مدیریت و عیب‌یابی مسیر را ادامه دهند.

Shielded VMها باید در fabricهای مورد استفاده قرار گیرند، که لازم است اطلاعات و وضعیت VM هم از ادمین‌های fabric و هم نرم‌افزارهای غیرقابل‌اعتماد که ممکن است روی Hostهای Hyper-V اجرا شوند محافظت گردد. برای مثال Shielded VMها هرگز اجازه‌ی ارتباط کنسول VM را نمی‌دهند، درحالی‌که یک ادمین fabric می‌تواند این حفاظت را برای VMهای تحت محافظت فعال یا غیرفعال کنند.

نحوه‌ی فعال‌سازی Shielded VM

زمانیکه VM01 فعال‌سازی می‌شود، پیش از اینکه یک Host تحت محافظت بتواند یک Shielded VM را فعال‌سازی کند، باید سلامت آن تائید شود. برای این منظور باید گواهی سلامت را به Key Protection Service یا KPS ارائه کند، این گواهی از طریق فرایند Attestation انجام می‌گیرد.

درخواست Attestation از طرف Host ،Host تحت محافظت درخواست Attestation می‌دهد، نوع این درخواست توسط سرویس Host Guardian تعیین می‌شود:

TPM-Trusted Attestation بدین صورت است که Hyper-V Host اطلاعاتی را ارسال می‌کند که شامل موارد زیر می­باشد:

اطلاعاتی که TPM را شناسایی می‌کنند (کلید تائید آن).

اطلاعاتی در مورد فرایندهایی که در طول جدیدترین Boot Sequence شروع شده‌اند (TCG Log).

اطلاعاتی در مورد Code Integrity Policy یا CI که روی Host اعمال شده است

Attestation وقتی که Host شروع به کار می‌کند، طهر هشت ساعت یک بار انجام می­شود، اگر به هر دلیلی، وقتی که VM می‌خواهد شروع به کار کند، یک Host دارای Certificate Attestation نباشد، این کار نیز باعث Attestation می‌شود.

Host Key Attestation در آن Hyper-V Host بخش عمومی از جفت Key را ارسال می‌کند. HGS تائید می‌کند که Host Key ثبت شده است.

Admin-Trusted Attestation که Hyper-V Host یک Kerberos Ticket را ارسال می‌کند که گروه‌های امنیتی که Host در آن‌ها قرار دارد را شناسایی می‌نماید. HGS تائید می‌کند که Host متعلق به یک گروه امنیتی که قبلاً توسط HGS Admin مورداعتماد، تنظیم شده است.

3. Attestation موفق یا ناموفق می‌شود، شیوه‌ی Attestation تعیین می‌کند که کدام بررسی‌ها لازم هستند که که نشان دهد Host سالم است. با Attestation مورد اعتماد TPM، هویت TPM متعلق به Host، اندازه‌گیری‌های Boot و پالیسی یکپارچگی کد، مورد تائید قرار می‌گیرند. باHost KeyAttestation ، تنها ثبت Host Key مورد تائید قرار می‌گیرد

گواهی Attestation به Host ارسال می‌شود. با فرض اینکه Attestation موفقیت‌آمیز باشد، یک گواهی سلامت به Host ارسال می‌شود و Host تحت محافظت محسوب می‌گردد؛ یعنی مجوز اجرای Shielded VMها را دارد. Host از گواهی سلامت استفاده می‌کند تا به Key Protection Service اجازه دهد به‌طور ایمنی Keyهای موردنیاز برای کار کردن با Shielded VMهای حفاظت‌شده را منتشر کند.

درخواست VM Key توسط Host، Host تحت محافظت دارای Keyهای موردنیاز برای فعال‌سازی روی یک Shielded VM نبوده و برای به‌دست آوردن Keyهای ضروری، Host تحت محافظت باید موارد زیر را برای KPS فراهم کند:

گواهی سلامت

یک Key Protector یا KP، که حاوی Keyهای لازم برای فعال‌سازی VM01 باشد، با استفاده از Keyهای دیگری که KPS می‌شناسد رمزگذاری می‌شود.

برای تعیین گواهی سلامت، KPS آن را بررسی می‌کند. این گواهی نباید منقضی شده باشد و KPS باید به سرویس Attestation که آن را صادر کرده است اعتماد کند.

زمانیکه Key به Host بازگردانده می‌شود، اگر گواهی سلامت معتبر باشد، KPS سعی می‌کند آن­را رمزگشایی کرده و به‌طور ایمنی Keyهای موردنیاز برای فعال‌سازی VM را بازگرداند. باید توجه شود که Keyها برای VBS متعلق به Host تحت حفاظت رمزگذاری می‌شود.

در نهایت Host روی VM01 فعال‌سازی می‌گردد.