編輯

共用方式為


Azure 機密虛擬機器常見問題集

本文提供了一些關於機密虛擬機器 (VM) 的最常見問題的解答。

什麼是機密 VM?

機密 VM 是適用於具有高安全性和機密性需求的租用戶的 IaaS 解決方案。 機密 VM 提供:

  • 「使用中資料」加密,包括處理器狀態和虛擬機器的記憶體。 金鑰是由處理器產生,而且永遠不會離開它。
  • 主機證明可協助您在資料處理開始之前驗證伺服器的完整健康情況和合規性。
  • 可以連結硬體安全性模組 (HSM) 來保護租用戶專有的機密 VM 磁碟的金鑰。
  • 支援客體 OS 的新 UEFI 開機結構,可以增強安全性設定和功能。
  • 專用虛擬信賴平台模組 (TPM) 可驗證 VM 的健康情況、提供強化的金鑰管理並支援 BitLocker 等使用案例。

為什麼應該使用機密 VM?

機密 VM 可解決客戶對於將敏感性工作負載從外部部署移至雲端的疑慮。 機密 VM 可為來自底層基礎結構和雲端營運商的客戶資料提供更高的保護。 不同於其他方法和解決方案,您不需要調整現有的工作負載以符合平台的技術需求。

什麼是 AMD SEV-SNP,它與 Azure 機密 VM 有何關係?

SEV-SNP 代表安全加密虛擬化-安全嵌套分頁 (Secure Encrypted Virtualization-Secure Nested Paging)。 它是 AMD 所提供的受信任執行環境 (TEE) 技術,提供了多重保護:例如記憶體加密、唯一 CPU 金鑰、處理器暫存器狀態的加密、完整性保護、韌體復原防護、側通道強化,以及中斷和例外狀況行為的限制。 總體而言,AMD SEV 技術可強化客體保護,以拒絕 Hypervisor 和其他主機管理程式碼存取 VM 記憶體和狀態。 機密 VM 運用了 AMD SEV-SNP 與 Azure 技術,例如完整磁碟加密和 Azure Key Vault 受控硬體安全模組 (HSM)。 您可以使用控制的金鑰來加密使用中、傳輸中和待用的資料。 使用內建的 Azure 證明功能,您可以在機密 VM 的安全性健康情況和基礎結構中獨立建立信任。

什麼是 Intel TDX 技術,它們與 Azure 機密 VM 有何關係?

Intel TDX 代表 Intel 信任網域延伸模組 (Intel TDX),它是 Intel 提供的受信任執行環境 (TEE) 技術,提供了多重保護:Intel TDX 使用硬體延伸模組來管理和加密記憶體,並保護 CPU 狀態的機密性和完整性。 此外 Intel TDX 不讓 Hypervisor、其他主機管理程式碼和管理員存取 VM 記憶體和狀態,有助強化虛擬化環境。 機密 VM 結合了 Intel TDX 與完整磁碟加密和 Azure Key Vault 受控硬體安全模組 (HSM) 等 Azure 技術。 您可以使用控制的金鑰來加密使用中、傳輸中和待用的資料。

Azure 機密 VM 如何提供更好的保護,防禦 Azure 雲端基礎結構內外的威脅?

Azure VM 已針對其他租用戶和惡意入侵者提供領先業界的安全性和保護功能。 Azure 機密 VM 透過使用基於硬體的 TEE (例如 AMD SEV-SNP 和 Intel TDX) 來以加密方式隔離和保護資料的機密性和完整性,從而增強這些保護。 主機管理員或主機服務 (包括 Azure Hypervisor) 無法直接檢視或修改機密 VM 的記憶體或 CPU 狀態。 此外,透過完整的證明功能、完整的作業系統磁碟加密和硬體保護的虛擬受信任平台模組,持續狀態會受到保護,使得您的私鑰和記憶體內容不會以未加密的形式暴露於裝載環境中。

系統是否會自動保護連結至機密 VM 的虛擬磁碟?

目前,可以加密和保護機密 VM 的 OS 磁碟。 如需額外的安全性,您可以針對所有資料磁碟機啟用客體層級加密 (例如 BitLocker 或 dm-crypt)。

寫入 Windows 分頁檔 (pagefile.sys) 的記憶體是否受到 TEE 的保護?

是,但只有在 pagefile.sys 是位於加密的 OS 磁碟上時。 在具有暫存磁碟的機密 VM 上,pagefile.sys 檔案可以移至加密的 OS 將 pagefile.sys 移至 c:\ 磁碟機的秘訣

我可以從機密 VM 內產生主機記憶體轉儲嗎?

否,機密 VM 不具備此功能。

如何部署 Azure 機密 VM?

我可以為 AMD 型機密 VM 執行證明嗎?

AMD SEV-SNP 上的 Azure 機密 VM,在啟動階段會進行證明。 此過程對使用者是透明的,並使用 Microsoft Azure 證明和 Azure Key Vault 服務在雲端作業系統中進行。 機密 VM 也允許使用者針對其機密 VM 執行獨立證明。 此證明是使用稱為 Azure 機密 VM 客體證明的全新工具來執行。 客體證明可讓客戶證明其機密 VM 是在已啟用 SEV-SNP 的 AMD 處理器上執行。

我可以為 Intel 型機密 VM 執行證明嗎?

使用 Intel TDX 的 Azure 機密 VM 可以作為開機流程的一部分來進行透明證明,以確保平台合規且是最新的。 此過程對使用者是透明的,並使用 Microsoft Azure 證明和 Azure Key Vault 進行。 如果您想在開機後進一步執行檢查,則可以使用客體內平台證明。 這可讓您驗證您的 VM 是否在正版 Intel TDX 上執行。 若要存取該功能,請造訪我們的預覽分支。 此外我們也為尋求操作員獨立證明的企業,提供 Intel® Trust Authority 支援。 即將推出對完整的客體內證明的支援,類似於 AMD SEV-SNP。 這可讓組織更深入地驗證更多層面,甚至深入客體應用層。

所有 OS 映像是否都與機密 VM 搭配運作?

若要在機密 VM 上執行,OS 映像必須符合特定安全性和相容性需求。 這可讓機密 VM 安全地裝載、證明並隔離在基礎雲端基礎結構之外。 在未來,我們計劃提供相關指引,說明如何取得自訂 Linux 組建和套用一組開放原始碼修補程式,以將它定義為機密 VM 映像。

我可以自訂其中一個可用的機密 VM 映像嗎?

是。 您可以使用 Azure Compute Gallery 來修改機密 VM 映像,例如安裝應用程式。 然後,您可以根據修改過的映像來部署機密 VM。

我是否需要使用完整磁碟加密配置? 我可以改用標準配置嗎?

選用的完整磁碟加密配置是 Azure 最安全的機制且符合機密運算原則。 不過,您也可以使用其他磁碟加密配置搭配或代替完整磁碟加密。 如果您使用多個磁碟加密配置,則雙重加密可能會對效能造成負面影響。

既然 Azure 機密 VM 支援虛擬 TPM,我可以將秘密/金鑰封至我的機密 VM 虛擬 TPM 嗎?

每個 Azure 機密 VM 都有自己的虛擬 TPM,客戶可以在其中密封其秘密/金鑰。 建議客戶驗證 vTPM 狀態 (若為 Windows VM,則透過 TPM.msc)。 如果狀態尚未備妥使用,建議您先將 VM 重新開機,再將秘密/金鑰密封至 vTPM。

我可以在建立 VM 之後啟用或停用新的完整磁碟加密配置嗎?

否。 建立機密 VM 之後,您無法停用或重新啟用完整磁碟加密。 請改為建立新的機密 VM。

我可以控制信賴運算基礎的更多層面,以強制執行操作員獨立金鑰管理、證明和磁碟加密嗎?

開發人員如欲尋求進一步將 TCB 服務與雲端服務提供者「職責分離」,應使用安全性型別「NonPersistedTPM」。

  • 這個體驗只在 Intel TDX 公開預覽版提供。 使用它或透過它提供服務的組織可以控制 TCB 以及隨之而來的責任。
  • 這個體驗繞過原生 Azure 服務,讓您使用自備磁碟加密、金鑰管理和證明解決方案。
  • 每台 VM 仍然有一個 vTPM (應該用來擷取證據),但是 vTPM 狀態不會透過重新開機而持續保留,這表示此解決方案非常適合暫時性的工作負載,以及想要與雲端服務提供者分離的組織。

我可以將非機密 VM 轉換成機密 VM 嗎?

否。 基於安全性考量,您必須從頭開始建立機密 VM。

我可以將 DCasv5/ECesv5 CVM 轉換成 DCesv5/ECesv5 CVM?或將 DCesv5/ECesv5 CVM 轉換成 DCasv5/ECesv5 CVM 嗎?

可以,在共用區域中的 DCasv5/ECasv5 和 DCesv5/ECesv5,可從一個機密 VM 轉換成另一台機密 VM。 如果您使用 Windows 映像,請確認已安裝所有最新更新。 如果您使用 Ubuntu Linux 映像,請確認您使用的 Ubuntu 22.04 LTS 機密映像具有最低核心版本 6.2.0-1011-azure

為什麼在 Azure 入口網站大小選擇器中找不到 DCasv5/ECasv5 或 DCesv5/ECesv5 VM?

請確定您已選取提供機密 VM 的區域。 此外,也請確定在大小選取器中選取 [清除所有篩選]

我可以在機密 VM 上啟用 Azure 加速網路嗎?

否。 機密 VM 不支援加速網路。 您無法在任何機密 VM 部署或執行機密運算的任何 Azure Kubernetes Service 叢集部署中啟用加速網路。

此錯誤的意義為何? 「無法完成作業,因為作業導致超出核准的標準 DCasV5/ECasv5 或 DCesv5/ECesv5 系列核心配額」

您可能會收到錯誤無法完成作業,因為作業導致超過已核准的標準 DCasv5/ECasv5 系列核心配額。 此 Azure Resource Manager 範本 (ARM 範本) 錯誤表示部署失敗,因為缺少 Azure 計算核心。 Azure 免費試用訂用帳戶對於機密 VM 沒有足夠的核心配額。 建立支援要求以提高您的配額

DCasv5 系列/DCesv5 系列和 ECasv5 系列/ECesv5 系列 VM 有何差異?

ECasv5 系列和 ECesv5 系列是記憶體最佳化的 VM 大小,可提供更高記憶體與 CPU 比率。 這些大小特別適用於關聯式資料庫伺服器、中型到大型快取,以及記憶體內部分析。

機密 VM 是否可全域使用?

否。 目前,這些 VM 只在選取的區域提供。 如需可用區域的最新清單,請參閱依區域提供的 VM 產品

如果我需要 Microsoft 協助我維護或存取機密 VM 上的資料,會發生什麼情況?

即便客戶授權存取權限,Azure 也沒有將機密 VM 存取權授與其員工的作業程序。 因此,機密 VM 無法使用各種復原和支援案例。

機密 VM 是否支援虛擬化,例如 Azure VMware 解決方案?

否,機密 VM 目前不支援巢狀虛擬化,例如在 VM 內執行 Hypervisor 的能力。

使用機密 VM 是否需要額外費用?

機密 VM 的計費取決於您的使用量和儲存體,以及 VM 的大小和區域。 機密 VM 會使用數 MB 的小型加密虛擬機器客體狀態 (VMGS) 磁碟。 VMGS 會封裝 vTPM 和 UEFI 開機載入器等元件的 VM 安全性狀態。 此磁碟可能會產生每月儲存體費用。 此外,如果您選擇啟用選用的完整磁碟加密,則加密的 OS 磁碟會產生較高的成本。 如需儲存體費用的詳細資訊,請參閱受控磁碟的價格指南。 最後,針對某些高安全性和隱私權設定,您可以選擇建立連結的資源,例如受控 HSM 集區。 Azure 會將這類資源與機密 VM 成本分開計費。

DCesv5/ECesv5 系列 VM 與 UTC 若有時差,該怎麼辦?

在極少數情況下,有些 DCesv5/ECesv5 系列 VM 與 UTC 可能會有微小時差。 很快就會有一個長期修正程式可以解決這個問題。 這段期間,Windows 和 Ubuntu Linux VM 使用者可採用以下應對措施:

sc config vmictimesync start=disabled
sc stop vmictimesync

對於 Ubuntu Linux 映像,請執行以下指令碼:

#!/bin/bash

# Backup the original chrony.conf file
cp /etc/chrony/chrony.conf /etc/chrony/chrony.conf.bak

# check chronyd.service status
status=$(systemctl is-active chronyd.service)

# check chronyd.service status is "active" or not
if [ "$status" == "active" ]; then
  echo "chronyd.service is active."
else
  echo "chronyd.service is not active. Exiting script."
  exit 1
fi

# Comment out the line with 'refclock PHC /dev/ptp_hyperv'
sed -i '/refclock PHC \/dev\/ptp_hyperv/ s/^/#/' /etc/chrony/chrony.conf

# Uncomment the lines with 'pool ntp.ubuntu.com' and other pool entries
sed -i '/#pool ntp.ubuntu.com/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 0.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 1.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf
sed -i '/#pool 2.ubuntu.pool.ntp.org/ s/^#//' /etc/chrony/chrony.conf

echo "Changes applied to /etc/chrony/chrony.conf. Backup created at /etc/chrony/chrony.conf.bak."

echo "Restart chronyd service"
systemctl restart chronyd.service


echo "Check chronyd status"
systemctl status chronyd.service