受防護的 VM 總覽

本頁說明 Shielded VM 的重要概念和術語。如要開始使用 Shielded VM，請嘗試快速入門導覽課程，或參閱「修改受防護的 VM 選項」。

受防護的 VM 能為您的 Compute Engine VM 執行個體提供可驗證的完整性，因此無須擔心執行個體遭受啟動或核心層級的惡意軟體或 Rootkit 入侵。

受防護的 VM 的主要優點

受防護的 VM 具有多項策略優勢，例如全面防範韌體層級攻擊、開機載入程式修改和核心層級入侵。

  • 營運效益：包括縮短安全事件回應時間、簡化法規遵循管理，以及提升系統完整性可視度。

  • 業務優勢：包括對雲端基礎架構的信心提升、安全漏洞風險降低，以及法規遵循狀態改善。

受防護的 VM 的核心安全架構

受防護的 VM 採用三層防護架構，這個架構可提供全方位的強大保護，詳情請參閱下表。

功能 簡介 這有什麼幫助
安全啟動技術 UEFI 韌體功能，可驗證所有啟動元件 (例如韌體驅動程式、OS 啟動載入程式和核心) 的數位簽章，確保 VM 僅使用經過簽署的真實軟體啟動。
詳情請參閱「安全啟動」。		 防止載入未經授權或遭竄改的開機載入程式和核心，進而阻擋許多 bootkit 和 rootkit。如果元件缺少可信的簽章，就會暫停啟動程序。
虛擬信任平台模組 (vTPM) 虛擬化安全處理器，為每個受防護的 VM 提供專屬的 vTPM，確保硬體層級的安全性。
詳情請參閱「虛擬信任平台模組 (vTPM)」。		 提供下列功能：
  • 測量啟動：取得韌體、系統啟動載入程式、核心和驅動程式等重要啟動元件的加密雜湊，並安全儲存，建立可驗證的啟動鏈。
  • 安全產生及儲存金鑰：產生及儲存加密編譯金鑰 (例如 BitLocker 專用)，且僅在測量開機程序驗證開機狀態為可信任時釋出金鑰。
進階完整性監控 監控系統會在測量啟動期間，建立啟動測量結果的黃金基準。
詳情請參閱「完整性監控」。		 在後續啟動時，比較目前的啟動測量結果與信任的基準。如果偵測到差異，會在 Cloud Logging 和 Security Command Center 中產生警示，方便您主動調查潛在的完整性違規行為。

安全啟動

安全啟動功能會驗證所有啟動元件的數位簽名，若簽名驗證未通過，就會暫停啟動程序，如此可以確保系統所執行的軟體均經過驗證。

受防護的 VM 執行個體會執行經過 Google 憑證授權單位簽署和驗證的執行個體，確保該執行個體韌體未遭修改，並建立安全啟動功能的信任根。統一可延伸韌體介面 (UEFI) 2.3.1 韌體能以安全的方式來管理憑證，這類憑證內有軟體製造商用來簽署系統韌體、系統啟動載入程式和任何載入的二進位檔的金鑰。受防護的 VM 執行個體會使用 UEFI 韌體。

每次啟動時，UEFI 韌體會將每個啟動元件的數位簽章與安全存放區的核准金鑰相互比對。只要是並未適當簽署或完全未簽署的啟動元件，系統就不允許執行。

如果發生這種情況，VM 執行個體的序列控制台記錄會出現含有「UEFI：無法載入圖片」(UEFI: Failed to load image) 和「狀態：違反安全性」(Status: Security Violation) 的字串，以及啟動選項已失敗的說明。如要排解失敗問題，請按照「修改受防護的 VM 選項」一文中的操作說明停用安全啟動功能，以便啟動 VM 執行個體、診斷及解決問題，然後重新啟用安全啟動功能。

虛擬信任平台模組 (vTPM)

vTPM 是虛擬化的信任平台模組，這是一種專用電腦晶片，可用於保護物件 (例如金鑰和憑證)，以驗證系統存取權。受防護的 VM 的 vTPM 與受信任的運算群組 (TPM) 資料庫規格 2.0 完全相容，且使用的是 BoringSSL 程式庫。BoringSSL 程式庫依附於 BoringCrypto 模組。如要瞭解 BoringCrypto 模組的 FIPS 140-2 詳細資料，請參閱 NIST 密碼編譯模組驗證計畫憑證 #3678。

受防護的 VM 的 vTPM 會執行必要的測量作業，建立已知正常的啟動基準，藉此啟用測量啟動功能，此又稱為「完整性政策基準」。完整性政策基準會與後續 VM 啟動的測量結果進行比較，以判斷是否有任何變更。

您也可以使用 vTPM，透過遮蔽或封藏來保護密鑰。如需 Go 語言範例，瞭解如何使用 vTPM 達成此目的，請參閱 GitHub 上的 Go-TPM 專案。

測量啟動

在「測量啟動」期間，系統會在載入每個元件 (例如韌體、開機載入程式或核心) 時建立雜湊，然後將該雜湊與已載入元件的雜湊串連並重新雜湊，如下圖所示：

測量啟動程序圖

這項資訊顯示出兩個載入的元件以及載入順序。

在首次啟動 VM 執行個體時，測量啟動會依據第一組測量數據建立完整性政策基準，接著將這項資料安全地儲存起來。之後每次 VM 執行個體在執行完該項作業後啟動時，系統會再採用這些測量數據，並將其儲存於安全記憶體內，留待下次重新啟動時使用。有了這兩組測量結果，就能啟用完整性監控功能，判斷 VM 執行個體的啟動順序是否有所變更。

完整性監控

完整性監控有助於瞭解 VM 執行個體的狀態，並據此下達決策。

完整性監控需仰賴由測量啟動所建立的測量數據，測量啟動使用平台設定暫存器 (PCR) 來儲存關於元件和元件載入順序的完整性政策基準 (即已知正常的啟動順序)，以及最近的啟動順序。

完整性監控功能會比較最近一次的啟動測量結果與完整性政策基準，並根據兩者是否相符，傳回一組通過或失敗結果，分別對應早期啟動順序和後期啟動順序。早期啟動是指從 UEFI 韌體啟動開始，到其將控制權交給系統啟動載入程式為止的啟動順序。後期啟動是指從系統啟動載入程式到將控制權交給作業系統核心為止的啟動順序。如果最近一次啟動順序的任一部分與基準不符，您就會收到完整性驗證失敗訊息。

如果預期會發生失敗情形 (例如您在該 VM 執行個體上套用系統更新)，則應更新完整性政策基準。更新完整性政策基準時，系統會將基準設為從最近一次的啟動順序擷取到的測量數據。如果不是預期情況，請停止該 VM 執行個體，並調查失敗原因。

您可以在 Cloud Monitoring 中查看完整性報告，並針對完整性失敗設定快訊。您可以在 Cloud Logging 中查看完整性監控結果的詳細資料。詳情請參閱「監控受防護的 VM 執行個體的完整性」。

完整性監控事件

受防護的 VM 會建立下列事件類型的記錄項目：

  • clearTPMEvent：識別 vTPM 是否已清除，清除 vTPM 也會刪除儲存在內的所有密鑰。這個動作不會對受防護的 VM 有任何影響，因此只有在您使用 vTPM 來保護機密資料時，才需要留意這一點，如虛擬信任平台模組 (vTPM) 一文所述。
  • earlyBootReportEvent：識別早期啟動順序是否通過完整性檢查，並提供基準和最近一次啟動順序的 PCR 值詳細資料，交互比對以做出判斷。
  • lateBootReportEvent：識別後期啟動順序是否通過完整性檢查，並提供基準和最近一次啟動順序的 PCR 值詳細資料，交互比對以做出判斷。
  • setShieldedInstanceIntegrityPolicy：每次更新完整性政策基準時，即會記錄。
  • shutdownEvent：每次 VM 執行個體停止時，即會記錄。
  • startupEvent：每次 VM 執行個體啟動時，即會記錄。此事件中最值得注意的資訊就是 bootCounter 值，可識別出這個執行個體重新啟動的次數。
  • updateShieldedInstanceConfig：每次啟用或停用受防護的 VM 選項時，即會記錄。

記錄中常見的事件進程有 startupEvent、earlyBootReportEvent、lateBootReportEvent，以及最終的 shutdownEvent，皆會使用相同的 bootCounter 值，以分辨其所描述的是相同的 VM 執行個體的啟動順序。

如果您更新完整性政策基準，以回應 VM 執行個體上預期的完整性失敗，您會看到額外的 earlyBootReportEvent 和 lateBootReportEvent 事件，說明新的完整性政策基準測量結果。下列範例顯示出的是預期順序：

  • startupEvent
  • earlyBootReportEvent 用來比較原始基準和最近的啟動順序 (成功)
  • lateBootReportEvent 用來比較原始基準和最近的啟動順序 (失敗)
  • setShieldedInstanceIntegrityPolicy 當您更新完整性政策基準時，即可將基準設為從最近一次的啟動順序擷取到的測量數據。
  • earlyBootReportEvent 用來比較新基準和最近的啟動順序 (成功)

  • lateBootReportEvent 用來比較新基準和最近的啟動順序 (成功)

Windows

earlyBootReportEvent

earlyBootReportEvent 包含下列區段和元素：

  • actualMeasurements：含有最近啟動順序的平台設定暫存器 (PCR) 值。PCR 值用於表示最近的啟動順序中使用的啟動元件和元件載入順序，也用於和完整性政策基準 (其值會擷取到 policyMeasurements 區段) 相互比較，以利判斷 VM 執行個體啟動順序是否有任何變動。「actualMeasurements」部分的元素可能會因作業系統、發布方式和設定而異。這個部分通常包含下列元素：

    • 0：含有 PCR0 的值，PCR0 中包含了韌體元件和啟用的記憶體加密技術相關資訊。這個 PCR 與 TCG PCClient 平台韌體設定檔不同，因為它只會測量下列事件：
      • EV_S_CRTM_VERSION，也就是 Compute Engine 韌體版本
      • EV_NONHOST_INFO，代表記憶體加密技術
      • EV_SEPARATOR，指定的分隔符事件韌體會在不再新增 PCR0 事件時測量。也就是說，PCR0 在 VM 的生命週期內具有靜態值。只有在主要版本韌體更新或加密技術變更後，新 VM 的值才會變更。將最近一次的啟動順序與完整性政策基準驗證比對時，不會使用這個值。
    • 1：含有 PCR4 的值，PCR4 包含了 UEFI 啟動管理員代碼和啟動嘗試的相關資訊。
    • 2：含有 PCR5 的值，PCR5 包含了磁碟 GUID 分區表的相關資訊。將最近一次的啟動順序與完整性政策基準驗證比對時，不會使用這個值。
    • 3：含有 PCR7 的值，PCR7 包含了執行個體安全啟動政策的相關資訊。

  • policyEvaluationPassed：辨別指定的啟動順序區段是否通過與完整性政策基準比對的驗證程序。

  • policyMeasurements：含有完整性驗證程序使用的基準 PCR 值 (預期值)。「policyMeasurements」部分可能因 OS、發布和設定而異，但通常包含下列元素：

    • 0：含有 PCR0 的值，PCR0 中包含了韌體元件和啟用的記憶體加密技術相關資訊。這個 PCR 與 TCG PCClient 平台韌體設定檔不同，因為它只會測量下列事件：
      • EV_S_CRTM_VERSION，也就是 Compute Engine 韌體版本
      • EV_NONHOST_INFO，代表記憶體加密技術
      • EV_SEPARATOR，指定的分隔符事件韌體會在不再新增 PCR0 事件時測量。也就是說，PCR0 在 VM 的生命週期內具有靜態值。只有在主要版本韌體更新或加密技術變更後，新 VM 的值才會變更。將最近一次的啟動順序與完整性政策基準驗證比對時，不會使用這個值。
    • 1：含有 PCR4 的值，PCR4 包含了 UEFI 啟動管理員代碼和啟動嘗試的相關資訊。首次啟動時不會包含這個值。
    • 2：含有 PCR7 的值，PCR7 包含了執行個體安全啟動政策的相關資訊。

如要瞭解如何使用 earlyBootReportEvent PCR 值，以便診斷出啟動完整性的驗證失敗問題，請參閱「判斷啟動完整性驗證失敗的原因」一文。

lateBootReportEvent

lateBootReportEvent 包含下列區段和元素：

  • actualMeasurements：含有最近啟動順序的平台設定暫存器 (PCR) 值。PCR 值用於表示最近的啟動順序中使用的啟動元件和元件載入順序，也用於和完整性政策基準 (其值會擷取到 policyMeasurements 區段) 相互比較，以利判斷 VM 執行個體啟動順序是否有任何變動。「actualMeasurements」部分的元素可能會因作業系統、發布方式和設定而異。這個部分通常包含下列元素：

    • 0：含有 PCR0 的值，PCR0 中包含了韌體元件和啟用的記憶體加密技術相關資訊。這個 PCR 與 TCG PCClient 平台韌體設定檔不同，因為它只會測量下列事件：
      • EV_S_CRTM_VERSION，也就是 Compute Engine 韌體版本
      • EV_NONHOST_INFO，代表記憶體加密技術
      • EV_SEPARATOR，指定的分隔符事件韌體會在不再新增 PCR0 事件時測量。也就是說，PCR0 在 VM 的生命週期內具有靜態值。只有在主要版本韌體更新或加密技術變更後，新 VM 的值才會變更。將最近一次的啟動順序與完整性政策基準驗證比對時，不會使用這個值。
    • 1：含有 PCR4 的值，PCR4 包含了 UEFI 啟動管理員代碼和啟動嘗試的相關資訊。
    • 2：含有 PCR5 的值，PCR5 包含了磁碟 GUID 分區表的相關資訊。將最近一次的啟動順序與完整性政策基準驗證比對時，不會使用這個值。
    • 3：含有 PCR7 的值，PCR7 包含了執行個體安全啟動政策的相關資訊。
    • 4：含有 PCR11 的值，PCR11 包含了 BitLocker 雲端硬碟加密存取權控管的相關資訊。
    • 5：含有 PCR12 的值，PCR12 包含了資料事件的相關資訊。將最近一次的啟動順序與完整性政策基準驗證比對時，不會使用這個值。
    • 6：含有 PCR13 的值，PCR13 包含了 Windows 核心和啟動驅動程式的相關資訊。
    • 7：含有 PCR14 的值，PCR14 包含了 Windows 啟動授權單位的相關資訊。

  • policyEvaluationPassed：辨別指定的啟動順序區段是否通過與完整性政策基準比對的驗證程序。

  • policyMeasurements：含有完整性驗證程序使用的基準 PCR 值 (預期值)。「policyMeasurements」部分可能因 OS、發布和設定而異，但通常包含下列元素：

    • 0：含有 PCR0 的值，PCR0 中包含了韌體元件和啟用的記憶體加密技術相關資訊。這個 PCR 與 TCG PCClient 平台韌體設定檔不同，因為它只會測量下列事件：
      • EV_S_CRTM_VERSION，也就是 Compute Engine 韌體版本
      • EV_NONHOST_INFO，代表記憶體加密技術
      • EV_SEPARATOR，指定的分隔符事件韌體會在不再新增 PCR0 事件時測量。也就是說，PCR0 在 VM 的生命週期內具有靜態值。只有在主要版本韌體更新或加密技術變更後，新 VM 的值才會變更。將最近一次的啟動順序與完整性政策基準驗證比對時，不會使用這個值。
    • 1：含有 PCR4 的值，PCR4 包含了 UEFI 啟動管理員代碼和啟動嘗試的相關資訊。
    • 2：含有 PCR7 的值，PCR7 包含了執行個體安全啟動政策的相關資訊。
    • 3：含有 PCR11 的值，PCR11 包含了 BitLocker 雲端硬碟加密存取權控管的相關資訊。
    • 4：含有 PCR13 的值，PCR13 包含了 Windows 核心和啟動驅動程式的相關資訊。
    • 5：含有 PCR14 的值，PCR14 包含了 Windows 啟動授權單位的相關資訊。

如要瞭解如何使用 lateBootReportEvent PCR 值，以便診斷出啟動完整性的驗證失敗問題，請參閱「判斷啟動完整性驗證失敗的原因」一文。

Linux

earlyBootReportEvent

earlyBootReportEvent 包含下列區段和元素：

  • actualMeasurements：含有最近啟動順序的平台設定暫存器 (PCR) 值。PCR 值用於表示最近的啟動順序中使用的啟動元件和元件載入順序，也用於和完整性政策基準 (其值會擷取到 policyMeasurements 區段) 相互比較，以利判斷 VM 執行個體啟動順序是否有任何變動。「actualMeasurements」部分的元素可能會因作業系統、發布方式和設定而異。這個部分通常包含下列元素：

    • 0：含有 PCR0 的值，PCR0 中包含了韌體元件和啟用的記憶體加密技術相關資訊。這個 PCR 與 TCG PCClient 平台韌體設定檔不同，因為它只會測量下列事件：
      • EV_S_CRTM_VERSION，也就是 Compute Engine 韌體版本
      • EV_NONHOST_INFO，代表記憶體加密技術
      • EV_SEPARATOR，指定的分隔符事件韌體會在不再新增 PCR0 事件時測量。也就是說，PCR0 在 VM 的生命週期內具有靜態值。只有在主要版本韌體更新或加密技術變更後，新 VM 的值才會變更。將最近一次的啟動順序與完整性政策基準驗證比對時，不會使用這個值。
    • 1：含有 PCR4 的值，PCR4 包含了作業系統填充碼的相關資訊。
    • 2：含有 PCR7 的值，PCR7 包含了執行個體安全啟動政策的相關資訊。

  • policyEvaluationPassed：辨別指定的啟動順序區段是否通過與完整性政策基準比對的驗證程序。

  • policyMeasurements：含有完整性驗證程序使用的基準 PCR 值 (預期值)。「policyMeasurements」部分可能因 OS、發布和設定而異，但通常包含下列元素：

    • 0：含有 PCR0 的值，PCR0 中包含了韌體元件和啟用的記憶體加密技術相關資訊。這個 PCR 與 TCG PCClient 平台韌體設定檔不同，因為它只會測量下列事件：
      • EV_S_CRTM_VERSION，也就是 Compute Engine 韌體版本
      • EV_NONHOST_INFO，代表記憶體加密技術
      • EV_SEPARATOR，指定的分隔符事件韌體會在不再新增 PCR0 事件時測量。也就是說，PCR0 在 VM 的生命週期內具有靜態值。只有在主要版本韌體更新或加密技術變更後，新 VM 的值才會變更。將最近一次的啟動順序與完整性政策基準驗證比對時，不會使用這個值。
    • 1：含有 PCR4 的值，PCR4 包含了作業系統填充碼的相關資訊。這個值不會計入首次啟動。
    • 2：含有 PCR7 的值，PCR7 包含了執行個體安全啟動政策的相關資訊。

如要瞭解如何使用 earlyBootReportEvent PCR 值，以便診斷出啟動完整性的驗證失敗問題，請參閱「判斷啟動完整性驗證失敗的原因」一文。

lateBootReportEvent

lateBootReportEvent 包含下列區段和元素：

  • actualMeasurements：含有最近啟動順序的平台設定暫存器 (PCR) 值。PCR 值用於表示最近的啟動順序中使用的啟動元件和元件載入順序，也用於和完整性政策基準 (其值會擷取到 policyMeasurements 區段) 相互比較，以利判斷 VM 執行個體啟動順序是否有任何變動。「actualMeasurements」部分的元素可能會因作業系統、發布方式和設定而異。這個部分通常包含下列元素：

    • 0：含有 PCR0 的值，PCR0 中包含了韌體元件和啟用的記憶體加密技術相關資訊。這個 PCR 與 TCG PCClient 平台韌體設定檔不同，因為它只會測量下列事件：
      • EV_S_CRTM_VERSION，也就是 Compute Engine 韌體版本
      • EV_NONHOST_INFO，代表記憶體加密技術
      • EV_SEPARATOR，指定的分隔符事件韌體會在不再新增 PCR0 事件時測量。也就是說，PCR0 在 VM 的生命週期內具有靜態值。只有在主要版本韌體更新或加密技術變更後，新 VM 的值才會變更。將最近一次的啟動順序與完整性政策基準驗證比對時，不會使用這個值。
    • 1：含有 PCR4 的值，PCR4 包含了第二階段系統啟動載入程式和其核心的相關資訊。
    • 2：含有 PCR5 的值，PCR5 包含了磁碟 GUID 分區表的相關資訊。將最近一次的啟動順序與完整性政策基準驗證比對時，不會使用這個值。
    • 3：含有 PCR7 的值，PCR7 包含了執行個體安全啟動政策的相關資訊。

  • policyEvaluationPassed：辨別指定的啟動順序區段是否通過與完整性政策基準比對的驗證程序。

  • policyMeasurements：含有完整性驗證程序使用的基準 PCR 值 (預期值)。「policyMeasurements」部分可能因 OS、發布和設定而異，但通常包含下列元素：

    • 0：含有 PCR0 的值，PCR0 中包含了韌體元件和啟用的記憶體加密技術相關資訊。這個 PCR 與 TCG PCClient 平台韌體設定檔不同，因為它只會測量下列事件：
      • EV_S_CRTM_VERSION，也就是 Compute Engine 韌體版本
      • EV_NONHOST_INFO，代表記憶體加密技術
      • EV_SEPARATOR，指定的分隔符事件韌體會在不再新增 PCR0 事件時測量。也就是說，PCR0 在 VM 的生命週期內具有靜態值。只有在主要版本韌體更新或加密技術變更後，新 VM 的值才會變更。將最近一次的啟動順序與完整性政策基準驗證比對時，不會使用這個值。
    • 1：含有 PCR4 的值，PCR4 包含了第二階段系統啟動載入程式和其核心的相關資訊。
    • 2：含有 PCR7 的值，PCR7 包含了執行個體安全啟動政策的相關資訊。

如要瞭解如何使用 lateBootReportEvent PCR 值，以便診斷出啟動完整性的驗證失敗問題，請參閱「判斷啟動完整性驗證失敗的原因」一文。

搭配受防護的 VM 映像檔使用 BitLocker

您可以為屬於受防護 VM 映像檔的 Windows 開機磁碟啟用 BitLocker。受防護的 VM 映像檔提供符合 UEFI 標準的韌體、安全啟動、vTPM 防護測量啟動與完整性監控等安全性功能。系統預設會啟用 vTPM 和完整性監控功能，Google 建議盡可能啟用安全啟動。

如果您選擇在屬於受防護 VM 映像檔的 Windows 開機磁碟上啟用 BitLocker，我們強烈建議您將備援金鑰儲存在安全的位置，因為如果您沒有備援金鑰，就無法復原資料。

在屬於受防護 VM 映像檔的 Windows 開機磁碟上啟用 BitLocker 之前，請先將下列事項納入考量：

  • 在受防護的 VM 開機磁碟上，BitLocker 會使用 vTPM 儲存加密金鑰，且 vTPM 會和該 vTPM 建立位置的 VM 產生永久關聯。這表示可以將受防護的 VM 開機磁碟的快照還原為另一個永久磁碟，但由於無法取得含有 BitLocker 金鑰的 vTPM，所以無法將其解密。如果有備援金鑰，則可按照 BitLocker 復原指南中的指示復原資料。如果沒有備援金鑰，就無法復原磁碟上的資料。

  • 在受防護的 VM 資料磁碟上，永久磁碟的資料會根據預設受到加密保護。除了永久磁碟加密之外，再多啟用 Bitlocker 也不會影響總處理量，但可能會稍微增加 vCPU 的使用量。如果在附加至 VM 的資料磁碟上啟用 BitLocker，並不會發生與開機磁碟相同的復原問題。這是因為資料磁碟的 BitLocker 加密金鑰並未儲存在 vTPM 上。如果您無法正常解鎖磁碟並取得備援金鑰，可以將磁碟連接至其他未加密的 VM，然後從該磁碟上復原。如果沒有備援金鑰，就無法復原磁碟上的資料。

身分與存取權管理授權

Shielded VM 使用 IAM 進行授權。

下列為受防護的 VM 作業所使用的 Compute Engine 權限：

  • compute.instances.updateShieldedInstanceConfig：允許使用者在 VM 執行個體上變更受防護的 VM 選項。
  • compute.instances.setShieldedInstanceIntegrityPolicy：允許使用者更新 VM 執行個體上的完整性政策基準。
  • compute.instances.getShieldedInstanceIdentity：可允許使用者從 vTPM 擷取簽署金鑰。

系統會賦予下列 Compute Engine 角色受防護的 VM 權限：

  • roles/compute.instanceAdmin.v1
  • roles/compute.securityAdmin

您也可授予自訂角色受防護的 VM 權限。

受防護的 VM 適用的組織政策限制

您可以將constraints/compute.requireShieldedVm 組織政策限制設為 True，要求將受防護的 VM 執行個體做為貴機構內建立的 Compute Engine VM 執行個體。

瞭解如何設定「使用組織政策中的布林限制」一文中的 constraints/compute.requireShieldedVm 限制。必須身為組織政策管理員才能設定限制。

限制

受防護的 VM 不支援裸機執行個體。

後續步驟