Panduan Perencanaan Guarded Fabric dan Shielded VM untuk Hoster

Berlaku untuk: Windows Server 2022, Windows Server 2019, Windows Server 2016

Topik ini mencakup keputusan perencanaan yang perlu dibuat untuk memungkinkan komputer virtual terlindungi berjalan pada fabric Anda. Baik Anda meningkatkan fabric Hyper-V yang ada atau membuat fabric baru, menjalankan VM terlindungi terdiri dari dua komponen utama:

  • Host Guardian Service (HGS) memberikan pengesahan dan perlindungan kunci sehingga Anda dapat memastikan bahwa VM terlindungi hanya akan berjalan pada host Hyper-V yang disetujui dan sehat. 
  • Host Hyper-V yang disetujui dan sehat tempat VM terlindungi (dan VM reguler) dapat berjalan - ini dikenal sebagai host yang dijaga.

Diagram showing the H G S's attestation and key protection services are linked to the shielded virtual machine's guarded Hyper V hosts.

Keputusan #1: Tingkat kepercayaan dalam fabric

Bagaimana Anda menerapkan Host Guardian Service dan host Hyper-V yang dijaga akan bergantung terutama pada kekuatan kepercayaan yang ingin Anda capai dalam fabric Anda. Kekuatan kepercayaan diatur oleh mode pengesahan. Ada dua opsi yang saling eksklusif:

  1. Pengesahan tepercaya TPM

    Jika tujuan Anda adalah untuk membantu melindungi komputer virtual dari admin berbahaya atau fabric yang disusupi, maka Anda akan menggunakan pengesahan tepercaya TPM. Opsi ini berfungsi dengan baik untuk skenario hosting multi-penyewa serta untuk aset bernilai tinggi di lingkungan perusahaan, seperti pengendali domain atau server konten seperti SQL atau SharePoint. Kebijakan integritas kode yang dilindungi hypervisor (HVCI) diukur dan validitasnya diberlakukan oleh HGS sebelum host diizinkan untuk menjalankan VM terlindungi.

  2. Pengesahan kunci host

    Jika persyaratan Anda terutama didorong oleh kepatuhan yang mengharuskan komputer virtual dienkripsi baik saat tidak aktif maupun dalam penerbangan, maka Anda akan menggunakan pengesahan kunci host. Opsi ini berfungsi dengan baik untuk pusat data tujuan umum di mana Anda nyaman dengan host Hyper-V dan administrator fabric yang memiliki akses ke sistem operasi tamu komputer virtual untuk pemeliharaan dan operasi sehari-hari.

    Dalam mode ini, admin fabric bertanggung jawab penuh untuk memastikan kesehatan host Hyper-V. Karena HGS tidak berperan dalam memutuskan apa yang atau tidak diizinkan untuk dijalankan, malware dan debugger akan berfungsi seperti yang dirancang.

    Namun, debugger yang mencoba melampirkan langsung ke proses (seperti WinDbg.exe) diblokir untuk VM terlindungi karena proses pekerja VM (VMWP.exe) adalah lampu proses yang dilindungi (PPL). Teknik debugging alternatif, seperti yang digunakan oleh LiveKd.exe, tidak diblokir. Tidak seperti VM terlindungi, proses pekerja untuk VM yang didukung enkripsi tidak berjalan sebagai PPL sehingga debugger tradisional seperti WinDbg.exe akan terus berfungsi secara normal.

    Mode pengesahan serupa bernama Pengesahan tepercaya admin (berbasis Direktori Aktif) tidak digunakan lagi dimulai dengan Windows Server 2019.

Tingkat kepercayaan yang Anda pilih akan menentukan persyaratan perangkat keras untuk host Hyper-V Anda serta kebijakan yang Anda terapkan pada fabric. Jika perlu, Anda dapat menyebarkan fabric yang dijaga menggunakan perangkat keras dan pengesahan tepercaya admin yang ada dan kemudian mengonversinya menjadi pengesahan tepercaya TPM ketika perangkat keras telah ditingkatkan dan Anda perlu memperkuat keamanan fabric.

Keputusan #2: Fabric Hyper-V yang ada versus fabric Hyper-V terpisah baru

Jika Anda memiliki fabric yang ada (Hyper-V atau sebaliknya), sangat mungkin Anda dapat menggunakannya untuk menjalankan VM terlindungi bersama dengan VM biasa. Beberapa pelanggan memilih untuk mengintegrasikan VM terlindungi ke dalam alat dan kain yang ada sementara yang lain memisahkan fabric karena alasan bisnis.

Perencanaan admin HGS untuk Layanan Wali Host

Sebarkan Host Guardian Service (HGS) di lingkungan yang sangat aman, baik itu di server fisik khusus, VM terlindungi, VM pada host Hyper-V yang terisolasi (dipisahkan dari fabric yang dilindunginya), atau yang dipisahkan secara logis dengan menggunakan langganan Azure yang berbeda.

Luas Detail
Persyaratan penginstalan
  • Satu server (kluster tiga node direkomendasikan untuk ketersediaan tinggi)
  • Untuk fallback, setidaknya diperlukan dua server HGS
  • Server dapat berupa virtual atau fisik (server fisik dengan TPM 2.0 yang direkomendasikan; TPM 1.2 juga didukung)
  • Penginstalan Server Core Windows Server 2016 atau yang lebih baru
  • Garis pandang jaringan ke fabric yang memungkinkan konfigurasi HTTP atau fallback
  • Sertifikat HTTPS yang direkomendasikan untuk validasi akses
Pengukuran Setiap simpul server HGS ukuran menengah (8 core/4 GB) dapat menangani 1.000 host Hyper-V.
Manajemen Menunjuk orang tertentu yang akan mengelola HGS. Mereka harus terpisah dari administrator fabric. Sebagai perbandingan, kluster HGS dapat dipikirkan dengan cara yang sama seperti Otoritas Sertifikat (CA) dalam hal isolasi administratif, penyebaran fisik, dan tingkat sensitivitas keamanan secara keseluruhan.
Host Guardian Service Active Directory Secara default, HGS menginstal Direktori Aktif internalnya sendiri untuk manajemen. Ini adalah forest mandiri yang dikelola sendiri dan merupakan konfigurasi yang direkomendasikan untuk membantu mengisolasi HGS dari fabric Anda.

Jika Anda sudah memiliki forest Active Directory yang sangat istimewa yang Anda gunakan untuk isolasi, Anda dapat menggunakan forest tersebut alih-alih forest default HGS. Penting bahwa HGS tidak bergabung ke domain di forest yang sama dengan host Hyper-V atau alat manajemen fabric Anda. Melakukannya dapat memungkinkan admin fabric untuk mendapatkan kontrol atas HGS.
Pemulihan dari bencana Ada tiga opsi:
  1. Instal kluster HGS terpisah di setiap pusat data dan otorisasi VM terlindung untuk dijalankan di pusat data utama dan cadangan. Ini menghindari kebutuhan untuk meregangkan kluster di seluruh WAN dan memungkinkan Anda untuk mengisolasi komputer virtual sehingga hanya berjalan di situs yang ditunjuk.
  2. Instal HGS pada kluster stretch antara dua (atau lebih) pusat data. Ini memberikan ketahanan jika WAN turun, tetapi mendorong batas pengklusteran failover. Anda tidak dapat mengisolasi beban kerja ke satu situs; VM yang berwenang untuk dijalankan di satu situs dapat berjalan di situs lain.
  3. Daftarkan host Hyper-V Anda dengan HGS lain sebagai failover.
Anda juga harus mencadangkan setiap HGS dengan mengekspor konfigurasinya sehingga Anda selalu dapat pulih secara lokal. Untuk informasi selengkapnya, lihat Export-HgsServerState dan Import-HgsServerState.
Kunci Layanan Wali Host Layanan Wali Host menggunakan dua pasangan kunci asimetris — kunci enkripsi dan kunci penandatanganan — masing-masing diwakili oleh sertifikat SSL. Ada dua opsi untuk menghasilkan kunci ini:
  1. Otoritas sertifikat internal – Anda dapat membuat kunci ini menggunakan infrastruktur PKI internal Anda. Ini cocok untuk lingkungan pusat data.
  2. Otoritas sertifikat tepercaya publik – gunakan sekumpulan kunci yang diperoleh dari otoritas sertifikat tepercaya publik. Ini adalah opsi yang harus digunakan hoster.
Perhatikan bahwa meskipun dimungkinkan untuk menggunakan sertifikat yang ditandatangani sendiri, tidak disarankan untuk skenario penyebaran selain lab bukti konsep.

Selain memiliki kunci HGS, hoster dapat menggunakan "bring your own key," di mana penyewa dapat menyediakan kunci mereka sendiri sehingga beberapa (atau semua) penyewa dapat memiliki kunci HGS spesifik mereka sendiri. Opsi ini cocok untuk hoster yang dapat menyediakan proses di luar band bagi penyewa untuk mengunggah kunci mereka.
Penyimpanan kunci Layanan Wali Host Untuk keamanan sekuat mungkin, sebaiknya kunci HGS dibuat dan disimpan secara eksklusif dalam Modul Keamanan Perangkat Keras (HSM). Jika Anda tidak menggunakan HSM, menerapkan BitLocker di server HGS sangat disarankan.

Perencanaan admin fabric untuk host yang dijaga

Luas Detail
Perangkat Keras
OS Sebaiknya gunakan opsi Server Core untuk OS host Hyper-V.
Implikasi kinerja Berdasarkan pengujian performa, kami mengantisipasi perbedaan kepadatan sekitar 5% antara menjalankan VM terlindungi dan VM yang tidak terlindungi. Ini berarti bahwa jika host Hyper-V tertentu dapat menjalankan 20 VM yang tidak terlindungi, kami berharap dapat menjalankan 19 VM terlindungi.

Pastikan untuk memverifikasi ukuran dengan beban kerja khas Anda. Misalnya, mungkin ada beberapa outlier dengan beban kerja IO berorientasi tulis intensif yang akan lebih memengaruhi perbedaan kepadatan.
Pertimbangan kantor cabang Dimulai dengan Windows Server versi 1709, Anda dapat menentukan URL fallback untuk server HGS virtual yang berjalan secara lokal sebagai VM terlindung di kantor cabang. URL fallback dapat digunakan ketika kantor cabang kehilangan konektivitas ke server HGS di pusat data. Pada versi Windows Server sebelumnya, host Hyper-V yang berjalan di kantor cabang membutuhkan konektivitas ke Layanan Wali Host untuk menyalakan atau melakukan migrasi langsung VM terlindung. Untuk informasi selengkapnya, lihat Pertimbangan kantor cabang.