共用方式為

Azure 安全隔離指引

  • 發行項

Microsoft Azure 是一個超大規模公用多租用戶雲端服務平台，可讓您存取功能豐富的環境，其中納入最新的雲端創新，例如人工智慧、機器學習、IoT 服務、巨量資料分析、智慧邊緣，以及更多功能，以協助您提高效率，並打開對作業和效能的見解。

多租用戶雲端平台表示多個客戶應用程式和資料會儲存在相同的實體硬體上。 Azure 會使用邏輯隔離，將您的應用程式和資料與其他客戶隔離。 這種方法提供多租用戶雲端服務的規模和經濟效益，同時嚴格地協助防止其他客戶存取您的資料或應用程式。

Azure 藉由提供可信任的基礎，使用一組常見的原則，確保多租用戶以密碼編譯方式確定邏輯隔離的雲端服務，來解決資源共用的認知風險：

  1. 搭配驗證和身分識別分隔的使用者存取控制
  2. 用於處理的計算隔離
  3. 網路隔離，包括傳輸中資料加密
  4. 搭配待用資料加密的儲存體隔離
  5. 內嵌在服務設計中的安全性保證流程，用來正確開發邏輯隔離的服務

公用雲端中的多租用戶，可以使用低成本在多個資源之間分散客戶來提升效率；不過，此方法會引進與資源分享相關的感知風險。 Azure 會使用圖 1 中所述的多層式方法，為隔離雲端服務提供值得信任的基礎來解決此風險。

Azure isolation approaches圖 1。Azure 隔離方法

下列是隔離方法的簡短摘要。

  • 具有驗證和身分識別區隔的使用者存取控制 – Azure 中的所有資料，無論類型或儲存位置如何，都與訂用帳戶相關聯。 您可以在註冊 Microsoft 雲端服務時，將雲端租用戶視為貴組織所接收並擁有的 Microsoft Entra 識別符專用執行個體。 身分識別與存取堆疊有助於在訂用帳戶之間強制執行隔離，包括將訂用帳戶內的資源存取限制為僅限授權使用者。

  • 計算隔離 – Azure 提供邏輯和實體計算隔離來處理。 邏輯隔離是透過下列方式實作：

    • Hypervisor 隔離，以密碼編譯方式提供特定隔離的服務，方法是使用不同的虛擬機器和使用 Azure Hypervisor 隔離。
    • Drawbridge 隔離虛擬機器 (VM) 內的服務，這些服務會使用 Drawbridge 提供的隔離，為在相同虛擬機器上執行的工作負載提供密碼編譯特定隔離。 這些服務會使用客戶程式碼提供少量的處理單位。
    • 完全由 Microsoft 控制的程式碼和客戶程式碼所組成的服務的使用者內容型隔離不允許執行。

    除了設計提供給所有 Azure 租用戶的健全邏輯計算隔離之外，如果您想要實體計算隔離，您可以使用 Azure 專用主機或隔離的虛擬機器，這些虛擬機器部署在專用於單一客戶的伺服器硬體上。

  • 網路隔離 - Azure 虛擬網路 (VNet) 可協助確保您的私人網路流量在邏輯上與屬於其他客戶的流量隔離。 服務可以使用公用 IP 或私人 (VNet) IP 進行通訊。 VM 之間的通訊在 VNet 內仍保持私人狀態。 視您的連線選項而定，您可以透過 VNet 對等互連或 VPN 閘道來連線 VNet，包括頻寬、延遲及加密需求。 您可以使用網路安全性群組 (NSG) 來達到網路隔離，並在存取具有公用端點的 Azure 服務時，保護 Azure 資源免於網際網路影響。 您可使用虛擬網路服務標籤來定義網路安全性群組或 Azure 防火牆的網路存取控制。 服務標籤代表來自指定 Azure 服務的一組 IP 位址首碼。 Microsoft 會管理服務標籤包含的位址前置詞，並隨著位址變更自動更新服務標籤，藉此減少網路安全性規則頻繁的更新。 此外，您可以使用 Private Link，透過 VNet 中的私人端點存取 Azure PaaS 服務，以確保 VNet 與服務之間的流量會透過 Microsoft 全球骨幹網路傳輸，從而無需將服務公開到公用網際網路。 最後，Azure 提供對傳輸中的資料進行加密的選項，包括使用金鑰保存庫憑證透過 TLS 終止對網路流量進行傳輸層安全性 (TLS) 端對端加密、使用 IPsec 進行 VPN 加密以及使用具有客戶自控金鑰 (CMK) 支援的 MACsec 的 Azure ExpressRoute 加密。

  • 儲存體隔離 – 為了確保邏輯資料隔離的密碼編譯確定性，Azure 儲存體依賴使用具有多個加密的進階演算法進行待用資料加密。 此流程仰賴多個加密金鑰和服務，例如 Azure Key Vault 和 Microsoft Entra ID，以確保安全金鑰存取和集中式金鑰管理。 Azure 儲存體服務加密可確保資料會在將資料保存至 Azure 儲存體之前自動加密，並在擷取之前解密。 寫入 Azure 儲存體的所有資料都會透過 FIPS 140 驗證的 256 位 AES 加密進行加密，並且您可以將金鑰保存庫用於客戶自控金鑰 (CMK)。 Azure 儲存體服務加密會加密儲存 Azure 虛擬機器磁碟的分頁 Blob。 此外，您可以選擇性地使用 Azure 磁碟加密來加密 Azure Windows 和 Linux IaaS 虛擬機器磁碟，以提高儲存體隔離，並確保儲存在 Azure 中資料的密碼編譯確定性。 此加密包含受控磁碟。

  • 安全性保證流程與做法 – Microsoft 內部使用安全性開發生命週期 (SDL) 和其他強大的安全性保證流程進一步強化 Azure 隔離保證，以保護攻擊面並減輕威脅。 Microsoft 已建立領先業界的流程和工具，以在 Azure 隔離保證中提供高度信賴度。

根據雲端運算中的共同責任模型，當您將工作負載從內部部署資料中心移轉至雲端時，您與雲端服務提供者之間的責任界限會因雲端服務模型而異。 例如，使用基礎結構即服務 (IaaS) 模型，Microsoft 的責任終止於 Hypervisor 層，而您負責虛擬化層上方的所有層級，包括維護客體虛擬機器中的基礎作業系統。 您可以使用 Azure 隔離技術，為部署在雲端中的應用程式和資料達到所需的隔離等級。

在本文中，注標方塊概述重要考量或被視為您責任的一部分的動作。 例如，您可以使用 Azure Key Vault 來儲存秘密，包括保留在您控制下的加密金鑰。

注意

針對客戶管理的金鑰使用 Azure Key Vault 是選擇性的，代表您的責任。

額外資源：

本文提供技術指引，以解決與雲端採用相關的常見安全性和隔離關切事項。 它也會探索 Azure 中可用的設計原則和技術，以協助您達成安全的隔離目標。

提示

有關如何提高 Azure 上部署的應用程式和資料的安全性的建議，應檢閱 Azure 安全性基準文件。

身分識別型隔離

Microsoft Entra ID 是一種身分識別儲存機制和雲端服務，可為使用者、群組和物件提供驗證、授權和存取控制。 Microsoft Entra ID 可以用作獨立雲端目錄，或用作具有現有內部部署 Active Directory 的整合式解決方案，以啟用重要的企業功能，例如目錄同步和單一登入。

每個 Azure 訂用帳戶都會與 Microsoft Entra 租用戶相關聯。 使用 Azure 角色型存取控制 (Azure RBAC)，可以授與該目錄中的使用者、群組及應用程式對 Azure 訂用帳戶中資源的存取權。 例如，儲存體帳戶可以放在資源群組中，以使用 Microsoft Entra ID 控制該特定儲存體帳戶的存取。 Azure 儲存體會定義一組 Azure 內建角色，其中包含用來存取 Blob 或佇列資料的一般權限。 您可以使用 Microsoft Entra 帳戶或儲存體帳戶金鑰來授權 Azure 儲存體的要求。 如此一來，只有特定使用者可以存取 Azure 儲存體中的資料。

零信任架構

不論類型或儲存位置為何，Azure 中的所有資料都與訂用帳戶相關聯。 您可以在註冊 Microsoft 雲端服務時，將雲端租用戶視為貴組織所接收並擁有的 Microsoft Entra 識別符專用執行個體。 Azure 入口網站的驗證是透過 Microsoft Entra ID 使用在 Microsoft Entra ID 中建立的身分識別或與內部部署的 Active Directory 聯合身分執行的。 身分識別與存取堆疊有助於在訂用帳戶之間強制執行隔離，包括將訂用帳戶內的資源存取限制為僅限授權使用者。 此存取限制是零信任模型的首要目標，其假設網路遭到入侵，而且需要從周邊安全性模型進行基本移位。 評估存取要求時，所有要求的使用者、裝置及應用程式都應該視為不受信任，直到其完整性符合零信任設計原則。 Microsoft Entra ID 提供零信任架構中所需的強式、自適性、標準型身分識別驗證。

注意

額外資源：

Microsoft Entra ID

區隔用來管理雲端應用程式的帳戶對於實現邏輯隔離至關重要。 Azure 中的帳戶隔離是使用 Microsoft Entra ID 及其功能來實現，以支援細微的 Azure 角色型存取控制 (Azure RBAC)。 每個 Azure 帳戶都會與一個 Microsoft Entra 租用戶相關聯。 該目錄中的使用者、群組和應用程式可以管理 Azure 中的資源。 您可以使用 Azure 入口網站、Azure 命令列工具或 Azure 管理 API 來指派適當的存取權限。 每個 Microsoft Entra 租用戶都不同，並與其他 Azure AD 分開。 Microsoft Entra 執行個體在邏輯上會使用安全性界限隔離，以防止客戶資料和身分識別資訊傳入，藉此確保一個 Microsoft Entra ID 的使用者和系統管理員無法惡意或意外地存取或入侵另一個 Microsoft Entra 執行個體中的資料。 Microsoft Entra ID 會在邏輯上隔離至專用網路區段的專用伺服器上執行實體隔離，其中主機層級封包篩選和 Windows 防火牆服務會提供不受信任流量的額外保護。

Microsoft Entra ID 會實作廣泛的資料保護功能，包括租用戶隔離和存取控制、傳輸中資料加密、祕密加密和管理、磁碟層級加密、各種 Microsoft Entra 元件所使用的進階密碼編譯演算法、內部人員存取的資料操作考量等等。 詳細資訊可從白皮書 Microsoft Entra Data Security Considerations 取得。

Microsoft Entra ID 中的租用戶隔離牽涉到兩個主要元素：

  • 防止資料外洩和跨租用戶存取，這意味著，屬於租用戶 A 的資料若未經租用戶 A 明確授權，即無法由租用戶 B 的使用者以任何方式取得。
  • 租用戶間的資源存取隔離，這表示租用戶 A 所執行的作業，無法以任何方式影響到租用戶 B 對資源的存取。

如圖 2 所示，透過 Microsoft Entra ID 的存取需要透過 Security Token Service (STS) 進行使用者驗證。 授權系統透過目錄服務 API 和 Azure RBAC 使用有關使用者存在和啟用狀態的資訊來確定工作階段中的使用者是否授權對目標 Microsoft Entra 執行個體的請求存取。 除了直接繫結至使用者的權杖型驗證之外，Microsoft Entra ID 會透過下列方式進一步支援 Azure 中的邏輯隔離：

  • Microsoft Entra 執行個體是離散容器，而且它們之間沒有關聯性。
  • Microsoft Entra 資料會儲存在分割區中，而且每個分割區都有一組預先決定的複本，這些複本會被視為慣用的主要複本。 使用複本可提供 Microsoft Entra 服務的高可用性，以支援身分識別分離和邏輯隔離。
  • 除非 Microsoft Entra 執行個體系統管理員透過同盟或從其他 Microsoft Entra 執行個體佈建使用者帳戶，否則不允許跨 Microsoft Entra 執行個體存取。
  • 實體存取組成 Microsoft Entra 服務和直接存取 Microsoft Entra ID 後端系統的伺服器，受限於使用 Just-In-Time (JIT) 特殊權限存取管理系統適當授權的 Microsoft 操作角色。
  • Microsoft Entra 使用者無法存取實體資產或位置，因此，不可能略過邏輯 Azure RBAC 原則檢查。

Microsoft Entra logical tenant isolation圖 2。Microsoft Entra 邏輯租用戶隔離

總而言之，Azure 邏輯租用戶隔離的方法會使用透過 Microsoft Entra ID 管理的身分識別，作為透過 Azure RBAC 提供租用戶層級資源存取權和授權的第一個邏輯控制界限。

資料加密金鑰管理

Azure 提供各種支援，能使用資料加密來保護您的資料，包括各種加密模型：

  • 在 Azure 中使用服務管理金鑰、客戶自控金鑰，或在客戶控制的硬體中使用客戶自控金鑰的伺服器端加密。
  • 用戶端加密可讓您在內部部署或另一個安全位置中管理和儲存金鑰。

資料加密提供直接繫結至加密 (密碼編譯) 金鑰存取權的隔離保證。 由於 Azure 在資料加密時使用強式加密，因此只有具有密碼編譯金鑰存取權的實體可以存取資料。 刪除或撤銷密碼編譯金鑰會造成對應的資料無法存取。 傳輸中資料加密的詳細資訊，請參閱網路隔離一節，而待用資料加密 請參閱儲存體隔離一節。

Azure 可讓您針對待用資料和傳輸中的資料強制執行雙重加密。 使用此模型時，會啟用兩層以上的加密，以防止任何一層加密遭到入侵。

Azure Key Vault

正確的加密和密碼編譯金鑰的管理對於資料安全至關重要。 Azure Key Vault 是可安全儲存及管理秘密的雲端服務。 金鑰保存庫服務支援本節其餘部分所述的兩種資源類型：

  • Vault 支援受軟體保護和硬體安全性模組 (HSM) 保護的秘密、金鑰及憑證。
  • 受控 HSM 僅支援受 HSM 保護的密碼編譯金鑰。

如果您需要額外的安全性，以在 Azure 服務中儲存最具敏感性的客戶資料，您可以使用您在金鑰保存庫中控制的專屬加密金鑰來加密該資料。

金鑰保存庫服務提供基礎 HSM 的抽象概念。 它提供 REST API，支援從雲端應用程式使用服務並透過 Microsoft Entra ID 進行身分驗證，從而允許您集中和自訂驗證、災害復原、高可用性及彈性。 金鑰保存庫支援密碼編譯密鑰各種類型、大小及曲線，包括 RSA 和橢圓曲線金鑰。 透過受控 HSM，也可提供 AES 對稱金鑰的支援。

使用 Key Vault，您可以在 HSM 中匯入或產生加密金鑰，確保金鑰永遠不會離開 HSM 保護界限，以支援攜帶您自己的金鑰 (BYOK) 案例，如圖 3 所示。

Azure Key Vault support for bring your own key (BYOK)圖 3.攜帶您自己的金鑰的 Azure Key Vault 支援 (BYOK)

在 Key Vault HSM 內產生的金鑰無法匯出 - HSM 外部沒有純文字版本的金鑰。 此繫結由基礎 HSM 強制執行。 金鑰保存庫和受控 HSM 均適用 BYOK 功能。 將受 HSM 保護的金鑰傳輸至金鑰保存庫的方法會因基礎 HSM 而有所不同，如線上文件所述。

注意

Azure Key Vault 的設計、部署及操作使得 Microsoft 及其代理程式無法存取、使用或擷取服務中儲存的任何資料，包括加密金鑰。 如需詳細資訊，請參閱 Azure Key Vault 如何保護您的金鑰？

金鑰保存庫提供強大的加密金鑰生命週期管理解決方案。 每個金鑰保存庫或受控 HSM 在建立後會自動與擁有訂用帳戶的 Microsoft Entra 租用戶產生關聯。 任何嘗試從金鑰保存庫或受控 HSM 中管理或擷取內容的人，都必須經過正確驗證和授權：

  • 驗證會建立呼叫者 (使用者或應用程式) 的身分識別。
  • 授權會根據 Azure 角色型存取控制 (Azure RBAC) 和金鑰保存庫存取原則或受控 HSM 本機 RBAC 的組合，決定呼叫端可執行哪些作業。

Microsoft Entra ID 會強制執行租用戶隔離，並實作強固措施，以防止未經授權方的存取，如先前 Microsoft Entra ID 一節所述。 透過兩個介面或平面 – 管理平面和資料平面 – ，使用 Microsoft Entra ID 進行驗證，來控制金鑰保存庫或受控 HSM 的存取。

  • 管理平面可讓您管理金鑰保存庫或受控 HSM 本身，例如建立和刪除金鑰保存庫或受控 HSM、擷取金鑰保存庫或受控 HSM 屬性，以及更新存取原則。 針對授權，管理平面會使用 Azure RBAC 搭配金鑰保存庫和受控 HSM。
  • 資料平面可讓您使用儲存在金鑰保存庫和受控 HSM 中的資料，包括新增、刪除和修改您的資料。 對於保存庫，儲存的資料可以包含金鑰、秘密及憑證。 針對受控 HSM，儲存的資料僅限於密碼編譯金鑰。 對於授權，資料平面使用金鑰保存庫存取原則和 Azure RBAC 進行具有金鑰保存庫的資料平面操作，或使用具有受控 HSM 的受控 HSM 本機 RBAC。

在 Azure 訂用帳戶中建立金鑰保存庫和受控 HSM 時，它會自動與訂用帳戶的 Microsoft Entra 租用戶建立關聯。 這兩個平面中的所有呼叫者都必須在此租用戶中註冊，並經過驗證才能存取金鑰保存庫或受控 HSM。

您可以控制存取權限，並可從 Azure Key Vault 服務擷取詳細的活動記錄。 Azure Key Vault 會記錄下列資訊：

  • 所有已驗證的 REST API 要求，包括失敗的要求
    • 金鑰保存庫上的作業，例如建立、刪除、設定存取原則等。
    • 金鑰保存庫中金鑰和秘密的作業，包括 a) 建立、修改或刪除金鑰或秘密，以及 b) 簽署、驗證、加密金鑰等。
  • 未經驗證的要求，例如沒有持有人權杖、格式不正確或過期或權杖無效的要求。

注意

透過 Azure Key Vault，您可以監視金鑰保存庫和受控 HSM 的存取方式和時機，以及存取者。

額外資源：

您也可以使用 Azure 監視器中的 Azure Key Vault 解決方案來檢閱金鑰保存庫記錄。 若要使用此解決方案，您需要啟用金鑰保存庫診斷的記錄，並將診斷導向至 Log Analytics 工作區。 使用此解決方案時，不需要將記錄寫入 Azure Blob 儲存體。

注意

如需 Azure Key Vault 安全性建議的完整清單，請參閱金鑰保存庫的 Azure 安全性基準。

保存庫

保存庫 - 提供多租用戶、低成本、易於部署、多租用戶、區域復原 (如果有的話) 及高可用性金鑰管理解決方案，適用於最常見的雲端應用程式案例。 保存庫可以儲存及保護秘密、金鑰及憑證。 它們可受到軟體保護 (標準層)，或由 HSM 保護 (進階層)。 如需標準層與進階層之間的比較，請參閱 Azure Key Vault 定價頁面。 Azure 會使用業界標準演算法和金鑰長度，來保護受軟體保護的祕密、金鑰和憑證。 如果您需要額外的保證，您可以選擇保護受多租用戶 HSM 保護之保存庫中的秘密、金鑰及憑證。 對應的 HSM 會根據 FIPS 140 標準進行驗證，並具有整體安全性層級 2 評等，其中包括實體竄改辨識項和角色型驗證的需求。

保存庫支援客戶自控金鑰 (CMK)，您可以在其中控制自己在 HSM 中的金鑰，使用它們來加密許多 Azure 服務的待用資料。 如先前所述，您可以在 HSM 中匯入或產生加密金鑰，以確保金鑰永遠不會離開 HSM 界限，以支援攜帶您自己的金鑰 (BYOK) 情節。

金鑰保存庫可以處理保存庫中要求和更新憑證，包括傳輸層安全性 (TLS) 憑證，讓您能夠註冊並自動更新受支援公用憑證授權單位的憑證。 金鑰保存庫憑證支援可讓您管理以金鑰為基礎的 X.509 憑證，並提供自動更新功能。 憑證擁有者可以透過 Azure Key Vault 或匯入現有的憑證建立憑證。 支援自我簽署和憑證授權單位產生的憑證。 此外，金鑰保存庫憑證擁有者可以實作安全儲存和管理 X.509 憑證，而不需與私密金鑰互動。

當您在資源群組中建立金鑰保存庫時，您可以使用 Microsoft Entra ID 管理存取，這可讓您指派適當的 Azure 角色，以授與特定範圍層級的存取權。 例如，若要將存取權授與使用者來管理金鑰保存庫，您可以將預先定義的金鑰保存庫參與者角色指派給特定範圍的使用者，包括訂用帳戶、資源群組或特定資源。

重要

您應該嚴格控制誰有金鑰保存庫的「參與者」存取權。 如果使用者具有金鑰保存庫管理平面的參與者權限，使用者可以藉由設定金鑰保存庫存取原則來取得資料平面的存取權。

額外資源：

受控 HSM

受控 HSM 提供單一租用戶、完全受控、高可用性、區域復原性 (其中可用) HSM 即服務來儲存和管理您的密碼編譯金鑰。 這最適用於處理高價值金鑰的應用程式和使用案例。 其也會協助您符合最嚴格的安全性、合規性和法規需求。 受控 HSM 會使用 FIPS 140-2 層級 3 驗證的 HSM 來保護您的密碼編譯金鑰。 每個受控 HSM 集區都是隔離的單一租用戶執行個體，其本身安全性網域由您控制，並以密碼編譯方式與屬於其他客戶的執行個體隔離。 密碼編譯隔離依賴 Intel Software Guard Extensions (SGX) 技術來提供加密的程式碼和資料，以協助您控制密碼編譯金鑰。

建立受控 HSM 時，要求者也會提供資料平面管理員清單。 只有這些管理員才能存取受控 HSM 資料平面，以執行重要作業及管理資料平面角色指派 (受控 HSM 本機 RBAC)。 管理和資料平面的權限模型使用相同的語法，但權限會在不同的層級強制執行，而角色指派會使用不同的範圍。 管理平面 Azure RBAC 由 Azure Resource Manager 強制執行，而資料平面受控 HSM 本機 RBAC 由受控 HSM 本身強制執行。

重要

與金鑰保存庫不同，將受控 HSM 的管理平面來存取受控 HSM 時，完全不授權資料平面來存取金鑰或資料平面角色指派受控 HSM 本機 RBAC。 這種隔離是透過設計實現的，以避免不慎擴張權限，以致越權存取受控 HSM 中儲存的金鑰。

如先前所述，受控 HSM 支援在內部部署 HSM 中產生的金鑰匯入，確保金鑰永遠不會離開 HSM 保護界限，也稱為攜帶您自己的金鑰 (BYOK) 情節。 受控 HSM 支援與 Azure 服務整合，例如 Azure 儲存體、Azure SQL Database、Azure 資訊保護等。 如需使用更完整的受控 HSM Azure 服務清單，請參閱資料加密模型。

受控 HSM 可讓您使用已建立的 Azure Key Vault API 和管理介面。 無論使用何種金鑰管理解決方案，您所有的應用程式都能使用相同的應用程式開發和部署模式：多租用戶保存庫或單一租用戶受控 HSM。

計算隔離

Microsoft Azure 計算平台是以機器虛擬化為基礎。 此方法表示您的程式碼 (部署在 PaaS 背景工作角色中，還是部署在 IaaS 虛擬機器中) 會在 Windows Server Hyper-V Hypervisor 所裝載的虛擬機器中執行。 在每個 Azure 實體伺服器上，也稱為節點，有一個類型 1 Hypervisor 直接在硬體上執行，並將節點分割成可變數目的客體虛擬機器 (VM)，如圖 4 所示。 每個節點都有一個特殊的主機 VM，也稱為根 VM，其運行主機作業系統- 最新 Windows Server 的自訂和強化版本，其被精簡以減少攻擊面，並且僅包含管理節點所需的元件。 從客體 VM 隔離根 VM 以及客體 VM 彼此隔離是 Azure 安全性架構中的重要概念，可形成 Azure 計算隔離的基礎，如 Microsoft 線上文件所述。

Isolation of Hypervisor, Root VM, and Guest VMs圖 4。Hypervisor、根 VM 及客體 VM 的隔離

裝載 VM 的實體伺服器會分組為叢集，並由稱為網狀架構控制器 (FC) 的擴展和備援平台軟體元件獨立管理。 每個 FC 都會管理在其叢集中執行的 VM 生命週期，包括佈建和監視受其控制的硬體健康情況。 例如，FC 負責在判斷伺服器失敗時，在狀況良好的伺服器上重新建立 VM 執行個體。 它也會將基礎結構資源配置給租用戶工作負載，並管理從主機到虛擬機器的單向通訊。 將計算基礎結構分割成叢集、隔離 FC 層級的錯誤，以免特定類別的錯誤影響到出錯叢集以外的伺服器。

FC 是 Azure 計算平台的大腦，主機代理程式是其 Proxy，可將伺服器整合到平台中，讓 FC 能夠部署、監視及管理您和 Azure 雲端服務所使用的虛擬機器。 虛擬機器管理程式/主機作業系統配對，利用 Microsoft 在作業系統安全方面數十年的經驗，包括對 Microsoft Hyper-V 的安全重點投資，以提供客體 VM 強大隔離。 本節稍後會討論 Hypervisor 隔離，包括 Hypervisor 強制執行的強化定義安全性界限保證、深度防禦惡意探索風險降低，以及強大的安全性保證程式。

管理網路隔離

每個計算硬體叢集中都有三個虛擬區域網路 (VLAN)，如圖 5 所示：

  • 主要 VLAN 會互連未受信任的客戶節點，
  • 網狀架構控制器 (FC) VLAN，其中包含受信任的 FC 和支援系統，以及
  • 裝置 VLAN 包含受信任的網路和其他基礎結構裝置。

允許從 FC VLAN 到主要 VLAN 的通訊，但無法起始從主要 VLAN 到 FC VLAN 的通訊。 從 FC VLAN 到主要 VLAN 的橋接器可用來降低整體複雜度，並改善網路的可靠性/復原能力。 連線受到數種方式保護，以確保命令受到信任並成功路由：

  • 從 FC 到網狀架構代理程式 (FA) 的通訊是單向的，需要透過憑證進行相互驗證。 FA 會實作受 TLS 保護的服務，只回應來自 FC 的要求。 它無法起始與 FC 或其他特殊權限內部節點的連線。
  • FC 會將代理程式服務的回應視為不受信任。 與代理程式的通訊會進一步限制為一組授權的 IP 位址，使用每個實體節點上的防火牆規則，以及邊界閘道的路由規則。
  • 節流用於確保客戶虛擬機器不會使網路和管理命令的路由飽和。

從主要 VLAN 到裝置 VLAN 的通訊也會遭到封鎖。 如此一來，即使執行客戶程式碼的節點遭到危害，它也不能攻擊 FC 或裝置 VLAN 上的節點。

這些控制項可確保管理主控台對 Hypervisor 的存取一律有效且可供使用。

VLAN isolation圖 5。VLAN 隔離

Hypervisor 與主機 OS 提供網路封包 - 篩選器，以協助保證不受信任的 VM 無法產生偽裝的流量，或是接收無法定址到它們的流量、將流量導向受保護的基礎架構端點，或傳送/接收不當的廣播流量。 根據預設，建立 VM 時會封鎖流量，然後 FC 代理程式會設定封包篩選器來新增規則和例外狀況，以允許授權的流量。 如需有關網路流量隔離和租用戶流量分隔的詳細資訊，請參閱網路隔離一節。

管理主控台和管理平面

管理主控台和管理平面遵循最低權限的嚴格安全性架構原則，以保護和隔離租用戶處理流程：

  • 管理主控台 (MC) – Azure 雲端中的 MC 是由 Azure 入口網站 GUI 和 Azure Resource Manager API 層所組成。 他們都會使用使用者認證來驗證和授權所有作業。
  • 管理平面 (MP) – 此層會執行實際的管理動作，並且由計算資源提供者 (CRP)、網狀架構控制器 (FC)、網狀架構代理程式 (FA) 和基礎 Hypervisor 組成，其具有自己的 Hypervisor 代理程式與服務通訊。 這些層全都會使用系統內容，這些內容會授與執行其作業所需的最低權限。

Azure FC 會將基礎結構資源配置給租用戶，並管理從主機 OS 到客體 VM 的單向通訊。 Azure FC 的 VM 放置演算法非常複雜，而且幾乎無法預測。 FA 位於主機 OS 中，並管理租用戶 VM。 Azure Hypervisor、主機 OS 與 FA 及客戶 VM 的集合構成計算節點，如圖 4 所示。 FC 管理 FA，儘管 FC 存在於計算節點之外 - 存在單獨的 FC 來管理計算和儲存體叢集。 如果您在 MC 中運行時更新應用程式的組態檔案，則 MC 透過 CRP 與 FC 進行通信，而 FC 則與 FA 進行通信。

CRP 是適用於 Azure 計算的前端服務，透過 Azure Resource Manager 公開一致的計算 API，因此可讓您透過簡單的範本建立和管理虛擬機器資源和延伸模組。

各種元件之間的通訊 (例如，Azure Resource Manager 與 CRP、CRP 到 FC 之間和從 FC、FC 到 Hypervisor 代理程式或從 Hypervisor 代理程式來回通訊)，全都以不同的身分識別和不同的權限集合在不同的通訊通道上運作。 此設計遵循常見的最低權限模型，以確保任何單一層的危害都會防止更多動作。 個別的通訊通道可確保通訊無法略過鏈結中的任何層級。 圖 6 說明 MC 和 MP 如何在 Azure 雲端內安全地通訊，以實現由使用者對 Microsoft Entra ID 的 OAuth 2.0 驗證發起的虛擬機器管理程式互動。

Management Console and Management Plane interaction for secure management flow圖 6。安全管理流程的管理主控台和管理平面互動

所有管理命令都會透過 RSA 簽署的憑證或 JSON Web 權杖 (JWT) 進行驗證。 驗證和命令通道會透過傳輸層安全性 (TLS) 1.2 加密，如傳輸區段中資料加密中所述。 伺服器憑證可用來為使用個別授權機制的驗證提供者提供 TLS 連線，例如 Microsoft Entra ID 或資料中心安全性權杖服務 (dSTS)。 dSTS 是一種權杖提供者，例如 Microsoft Entra ID，會隔離至 Microsoft 資料中心，並用於服務等級通訊。

圖 6 說明與使用者命令對應的管理流程，以停止虛擬機器。 表 1 中列舉的步驟會以相同方式套用至其他管理命令，並使用相同的加密和驗證流程。

資料表 1。 涉及各種 MC 和 MP 元件的管理流程

步驟 描述 驗證 加密
1. 使用者透過 Microsoft Entra ID 驗證，方法是提供認證並發出權杖。 使用者認證 TLS 1.2
2. 瀏覽器向 Azure 入口網站呈現權杖，以驗證使用者。 Azure 入口網站會使用權杖簽章和有效的簽署金鑰來驗證權杖。 JSON Web 權杖 (Microsoft Entra ID) TLS 1.2
3. 使用者在 Azure 入口網站上發出「停止 VM」要求。 Azure 入口網站會向 Azure Resource Manager 傳送「停止 VM」要求，並提供 Microsoft Entra ID 提出的使用者權杖。 Azure Resource Manager 會使用權杖簽章和有效的簽署金鑰來驗證權杖，並授權使用者執行要求的作業。 JSON Web 權杖 (Microsoft Entra ID) TLS 1.2
4. Azure Resource Manager 會根據 Azure Resource Manager 擁有的用戶端憑證，向 dSTS 伺服器要求權杖，讓 dSTS 以正確的身分識別和角色授與 JSON Web 權杖。 用戶端憑證 TLS 1.2
5. Azure 資源管理器會向 CRP 傳送要求。 呼叫是透過 OAuth 驗證，使用 JSON Web 權杖來驗證，此權杖代表來自 dSTS 的 Azure Resource Manager 系統身分識別，因此會從使用者轉換至系統內容。 JSON Web 權杖 (dSTS) TLS 1.2
6. CRP 會驗證要求，並判斷哪些網狀架構控制器可以完成要求。 CRP 會根據其用戶端憑證向 dSTS 要求憑證，以便連線到命令目標的特定網狀架構控制器 (FC)。 如果允許 CRP 與該 FC 通訊，權限只會授與該特定 FC 的權限。 用戶端憑證 TLS 1.2
7. CRP 接著會使用 dSTS 所建立的 JSON Web 權杖，將要求傳送至正確的 FC。 JSON Web 權杖 (dSTS) TLS 1.2
8. 然後 FC 會驗證命令是允許的，而且來自受信任的來源。 然後，它與叢集中正確的 網狀架構代理程式 (FA) 建立安全 TLS 連線，該連接可以使用目標 FA 和 FC 唯一的憑證來執行命令。 建立安全連線之後，就會傳輸命令。 相互憑證 TLS 1.2
9. FA 再次驗證命令是允許的，而且來自受信任的來源。 驗證之後，FA 會使用相互憑證驗證建立安全連線，並將命令發出給只有 FA 可存取的 Hypervisor 代理程式。 相互憑證 TLS 1.2
10. 主機上的 Hypervisor 代理程式會執行內部呼叫來停止 VM。 系統內容 N.A.

通過本節中確定的流程的所有步驟生成並發送到每個節點上的 FC 和 FA 的命令被寫入本地稽核記錄，並分發到多個分析系統進行串流處理，以監視系統健康情況並追蹤安全性事件和模式。 追蹤包含已成功處理的事件，以及無效的事件。 入侵檢測系統會處理無效的要求，以偵測異常狀況。

邏輯隔離實作選項

Azure 透過多層式方法提供計算處理的隔離，包括：

  • Hypervisor 隔離，以密碼編譯方式提供特定隔離的服務，方法是使用不同的虛擬機器和使用 Azure Hypervisor 隔離。 範例：App Service、Azure 容器執行個體、Azure Databricks、Azure Functions、Azure Kubernetes Service、Azure Machine Learning、雲端服務、Data Factory、Service Fabric、虛擬機器、虛擬機擴展集。
  • Drawbridge 隔離 VM 內的服務，這些服務會使用 Drawbridge 提供的隔離，為在相同虛擬機器上執行的工作負載提供密碼編譯特定隔離。 這些服務會使用客戶程式碼提供少量的處理單位。 為了提供安全性隔離，Drawbridge 會在 pico-process內，搭配輕量版的 Windows 核心 (程式庫 OS) 來執行使用者流程。 pico-process 是安全流程，無法直接存取主機系統的服務或資源。 範例：自動化、適用於 MySQL 的 Azure 資料庫、適用於 PostgreSQL 的 Azure 資料庫、Azure SQL Database、Azure 串流分析。
  • 完全由 Microsoft 控制的程式碼和客戶程式碼所組成的服務的使用者內容型隔離不允許執行。 範例：API 管理、應用程式閘道、Microsoft Entra ID、Azure 備份、Azure Cache for Redis、Azure DNS、Azure 資訊保護、Azure IoT 中樞、Azure Key Vault、Azure 入口網站、Azure 監視器 (包括 Log Analytics)、適用於雲端的 Microsoft Defender、Azure Site Recovery、Container Registry、內容傳遞網路、事件格線、事件中樞、負載平衡器、服務匯流排、儲存體、虛擬網路、VPN 閘道、流量管理員。

本節其餘部分將討論這些邏輯隔離選項。

Hypervisor 隔離

Azure 中的 Hypervisor 隔離是以 Microsoft Hyper-V 技術為基礎，可讓 Azure Hypervisor 型隔離受益於數十年來在操作系統安全性和虛擬機器隔離的 Hyper-V 技術投資方面的經驗。 您可以查看有關 Hyper-V 安全性函數的獨立第三方評估報告，包括國家資訊保障合作夥伴 (NIAP) 通用標準評估和驗證計畫 (CCEVS) 報告，例如本文討論的 2021 年 2 月發佈的報告。

評估目標 (TOE) 由 Microsoft Windows Server、Microsoft Windows 10 版本 1909 (2019 年 11 月更新) 和 Microsoft Windows Server 2019 (版本 1809) Hyper-V (“Windows”) 所組成。 TOE 會強制執行下列安全性原則，如報告所述：

  • 安全性稽核 – Windows 能夠收集稽核資料、檢閱稽核記錄、保護稽核記錄免於溢位，以及限制稽核記錄的存取。 系統所產生的稽核資訊包括事件的日期和時間、導致產生事件的使用者身分識別，以及其他事件特定資料。 授權的系統管理員可以檢閱、搜尋及排序稽核記錄。 授權的系統管理員也可以設定稽核系統，以包含或排除根據許多特性稽核的潛在可稽核事件。 在此評估內容中，保護設定檔需求涵蓋生成稽核事件、授權檢閱預存稽核記錄，以及為稽核事件輸入項目提供安全儲存體。
  • 密碼編譯支援 – Windows 提供已驗證的密碼編譯函數，以支援加密/解密、密碼編譯簽章、密碼編譯雜湊及隨機數字產生。 Windows 會實作這些函數，以支援 IPsec、TLS 及 HTTPS 通訊協定實作。 Windows 也可確保其客體 VM 可以存取熵資料，讓虛擬化作業系統可以確保強式密碼編譯的實作。
  • 用戶資料保護 – Windows 可讓客體 VM 使用某些運算服務，但實作一些措施，以確保適當地授與這些服務的存取權，而且這些介面不會造成客體 VM 與 Windows 之間或多個客體 VM 之間未經授權的資料外洩。
  • 識別和驗證 – Windows 提供幾種方法的使用者驗證，其中包括信任通訊協定所需的 X.509 憑證。 Windows 會實作密碼強度機制，並確保使用受暴力密碼破解猜測 (密碼、PIN) 方法的過度失敗驗證嘗試會導致鎖定行為。
  • 安全性管理 – Windows 包含幾種功能來管理安全策略。 系統管理功能的存取權是透過系統管理角色強制執行的。 Windows 也能夠支援管理和操作網路的分離，以及禁止客體 VM 之間的資料共用。
  • 保護 TOE 安全性函數 (TSF) – Windows 會實作各種自我保護機制，以確保它無法當做平台來取得儲存在客體 VM 上資料的未經授權存取權、維護 TSF 及其客體 VM 的完整性，以及客體 VM 只能透過記錄良好的介面存取。
  • TOE Access – 在此評估的內容中，Windows 可讓授權的系統管理員設定系統在登入對話方塊之前顯示登入橫幅。
  • 信任的路徑/通道 – Windows 會實作 IPsec、TLS 及 HTTPS 信任的通道和路徑，以進行遠端管理、將稽核資料傳送至作業環境，以及管理和操作網路的分離。

如需詳細資訊，請從第三方認證報告取得。

透過下列方式提供重要的 Hypervisor 隔離：

  • Hypervisor 強制執行的強定義安全性界限
  • 深層防禦惡意探索風險降低功能
  • 強式安全性保證程序

本節的其餘部分會說明這些技術。 它們可讓 Azure Hypervisor 在多租用戶雲端中為租用戶區隔提供強大的安全性保證。

強式定義的安全性界限

您的程式碼會在 Hypervisor VM 中執行，並受益於 Hypervisor 強制執行的安全性界限，如圖 7 所示。 Azure Hypervisor 是以 Microsoft Hyper-V 技術為基礎。 它將 Azure 節點劃分為數目可變的客體 VM，這些 VM 具有單獨的位址空間，可在其中載入作業系統 (OS) 以及與在節點的根分區中執行的主機作業系統並行運行的應用程式。

Compute isolation with Azure Hypervisor圖 7.Azure Hypervisor 的計算隔離 (請參閱線上詞彙解釋)

Azure Hypervisor 的作用就像微核心，使用虛擬化服務用戶端 (VSC) 將客體 VM 的所有硬體存取要求傳遞至主機 OS，以使用稱為 VMBus 的共用記憶體介面進行處理。 主機 OS 會使用虛擬化服務提供者 (VSP) 來代理硬體要求，以防止使用者取得系統的原始讀取/寫入/執行存取權，並降低共用系統資源的風險。 特殊權限的根分割區，也稱為主機 OS，可以直接存取系統上的實體裝置/周邊，例如儲存體控制器、GPU、網路配接器等。 主機 OS 可讓客體分割區藉由將虛擬裝置公開給每個客體分割區，來共用這些實體裝置。 因此，在客體分割區中執行的作業系統可以存取 VSP 的周邊裝置，這些裝置是由在根分割區中執行的虛擬化服務所提供。 這些虛擬裝置表示法可以採用三種表單之一：

  • 模擬裝置 – 主機 OS 可能會公開與對應實體裝置所提供的介面完全相同的虛擬裝置。 在此情況下，客體分割區中的操作系統會使用與在實體系統上執行時相同的裝置驅動程式。 主機 OS 會模擬實體裝置對客體分割區的行為。
  • 準虛擬裝置 – 主機作業系統可能會使用主機作業系統和客體之間的 VMBus 共用記憶體介面，通過虛擬化特定介面公開虛擬裝置。 在此模型中，客體分割區會使用專為實作虛擬化介面而設計的裝置驅動程式。 這些準虛擬裝置有時稱為 “綜合” 裝置。
  • 硬體加速裝置 – 主機作業系統可能會將實際的硬體周邊直接公開至客體分割區。 此模型允許客體分割區中的高 I/O 效能，因為客體分割區可以直接存取硬體裝置資源，而不需要通過主機作業系統。 Azure 加速網路 是硬體加速裝置的範例。 此模型中的隔離是使用輸入輸出記憶體管理單位 (I/O MMU) 來達成，以提供每個分割區的位址空間和中斷隔離。

主機 CPU 中的虛擬化延伸模組可讓 Azure Hypervisor 強制執行分割區之間的隔離。 下列基本 CPU 功能提供 Hypervisor 隔離的硬體建置區塊：

  • 第二層位址轉換 – Hypervisor 會使用 CPU 的記憶體管理單位 (MMU) 所提供的第二層頁面表格，控制分割區允許存取的記憶體資源。 CPU 的 MMU 會在 Hypervisor 控制下使用第二層位址轉譯，對所執行的記憶體存取強制執行保護：
    • 在分割區內容中執行時的 CPU。
    • 客體分割區直接存取的 I/O 裝置。
  • CPU 內容 – Hypervisor 會使用 CPU 中的虛擬化延伸模組來限制客體分割執行時可存取的權限和 CPU 內容。 Hypervisor 也會在多個分割區之間共用 CPU 時使用這些設施來儲存和還原狀態，以確保分割區之間的 CPU 狀態隔離。

Azure Hypervisor 會大量使用這些處理器設施，在分割區之間提供隔離。 推測性側通道攻擊的出現已經發現其中一些處理器隔離功能的潛在弱點。 在多租用戶架構中，跨不同租用戶的任何跨 VM 攻擊都包含兩個步驟：將敵人控制的 VM 放在與其中一個受害者 VM 相同的主機上，然後違反邏輯隔離界限來執行側通道攻擊。 Azure 藉由使用進階 VM 放置演算法來強制執行記憶體和流程分離，用於邏輯隔離，以及使用 Hypervisor 的密碼編譯確定性來保護網路流量路由，從而提供針對這兩種威脅的保護。 正如本文稍後標題為利用虛擬化技術中的漏洞一節所討論的，Azure Hypervisor 的架構旨在直接在 Hypervisor 內提供強大的隔離，有助於緩解許多複雜的側通道攻擊。

Azure Hypervisor 定義的安全性界限提供基底等級隔離基本類型，以在共用硬體上潛在惡意的多租用戶之間進行強式分割程式碼、資料及資源。 這些隔離基本類型可用來建立多租用戶資源隔離情節，包括：

  • 潛在惡意客體之間的網路流量隔離 –虛擬網路 (VNet) 提供租用戶之間的網路流量隔離，作為其基本設計的一部分，如後續租用戶網路流量分隔一節中所述。 VNet 會形成隔離界限，其中 VNet 內的 VM 只能彼此通訊。 主機不會捨棄從 VNet 或外部寄件者傳送至 VM 的任何流量，且未設定適當的原則。
  • 加密金鑰和密碼編譯資料隔離 – 您可以使用硬體安全性管理員或特製化金鑰儲存體來進一步增強隔離功能，例如，透過 Azure Key Vault，將加密金鑰儲存在 FIPS 140 驗證的硬體安全性模組 (HSM) 中。
  • Azure 設計 – 系統資源的排程，包括保證計算、記憶體、儲存體以及直接和準虛擬化裝置存取的可用性和分割。

Azure Hypervisor 符合表 2 中顯示的安全性目標。

表 2. Azure Hypervisor 安全性目標

目標 來源
隔離 Azure Hypervisor 安全策略不會要求在 VM 之間傳輸任何資訊。 此原則需要 Virtual Machine Manager (VMM) 和硬體中的功能，才能隔離記憶體、裝置、網路及受控資源，例如保存的資料。
VMM 完整性 完整性是虛擬化系統的核心安全性目標。 為了達到系統完整性，會建立和維護各個 Hypervisor 元件的完整性。 此目標只涉及 Hypervisor 本身的完整性，而不是在 VM 內執行之實體平台或軟體的完整性。
平台完整性 Hypervisor 的完整性取決於其所依賴的硬體和軟體是否具有完整性。 雖然 Hypervisor 無法直接控制平台的完整性，但 Azure 依賴硬體和韌體機制，例如 Cerberus 安全性微控制器，目的是保護基礎平台完整性，從而在平台完整性受到損害時防止 VMM 和客體執行。
管理存取 管理功能只會由授權的系統管理員執行，透過安全連線進行連線，並採用更精細的角色存取控制機制強制執行的最低權限原則。
稽核 Azure 提供稽核功能來擷取及保護系統資料，以便稍後進行檢查。
深層防禦惡意探索風險降低功能

為了進一步降低安全性危害的風險，Microsoft 已投資 Azure 系統軟體、硬體和韌體的許多深度防禦防護功能，以提供強大的真實世界隔離保證給 Azure 客戶。 如先前所述，Azure Hypervisor 隔離是以 Microsoft Hyper-V 技術為基礎，可讓 Azure Hypervisor 受益於數十年來在操作系統安全性和虛擬機器隔離的 Hyper-V 技術投資方面的經驗。

以下是 Microsoft 為保護 Hyper-V 而採用的一些重要設計原則：

  • 防止設計層級問題影響產品
    • 進入 Hyper-V 的每個變更都須經過設計檢閱。
  • 使用更安全的編碼來消除常見的弱點類別
    • 某些元件，例如 VMSwitch 會使用正式驗證的通訊協定剖析器。
    • 許多元件都使用 gsl::span 而不是原始指標，這可消除緩衝區溢位和/或超出界限記憶體存取的可能性。 如需詳細資訊，請參閱指導方針支援程式庫 (GSL) 文件。
    • 許多元件會使用智慧型指標來消除釋放後使用錯誤的風險。
    • 大多數 Hyper-V 核心模式程式碼使用在配置時清零的堆積配置器來消除未初始化的記憶體錯誤。
  • 使用編譯器風險降低來消除常見的弱點類別
    • 所有 Hyper-V 程式碼都是使用 InitAll 編譯，排除未初始化的堆疊變數。 因為 Hyper-V 中的許多歷史弱點是由未初始化的堆疊變數所造成，因此已實作此方法。
    • 所有 Hyper-V 程式碼都是使用堆疊 Canaries 編譯，以大幅降低堆疊溢位弱點的風險。
  • 尋找進入產品的問題
    • 所有 Windows 程式碼都有一組靜態分析規則，可在其中執行。
    • 所有 Hyper-V 程式碼都會經過檢閱並模糊。 如需模糊的詳細資訊，請參閱本文後面的安全性保證流程和作法一節。
  • 讓惡意探索剩餘弱點變得更加困難
    • VM 背景工作處理序已套用下列風險降低：
      • 任意程式碼防護 – 動態產生的程式碼無法在 VM 背景工作處理序中載入。
      • 程式碼完整性防護 – VM 背景工作處理序只能載入 Microsoft 簽署的程式碼。
      • 控制流程防護 (CFG) – 提供課程細緻的控制流程保護，以間接呼叫和跳躍。
      • NoChildProcess – 背景工作處理序無法建立子處理序 (適用於略過 CFG)。
      • NoLowImages / NoRemoteImages – 背景工作處理序無法透過網路載入 DLL 或由沙箱流程寫入磁碟的 DLL。
      • NoWin32k - 背景工作處理序無法與 Win32k 通訊，這使得沙箱逸出更加困難。
      • 堆積隨機化 – Windows 隨附任何作業系統的最安全堆積實作之一。
      • 位址空間配置隨機化 (ASLR) – 隨機化位址空間中的堆積、堆疊、二進位檔及其他資料結構的配置，從而降低惡意探索的可靠性。
      • 資料執行防止 (DEP/NX) – 只有想要包含程式碼的記憶體頁面是可執行的。
    • 核心已套用下列風險降低：
      • 堆積隨機化 – Windows 隨附任何作業系統的最安全堆積實作之一。
      • 位址空間配置隨機化 (ASLR) – 隨機化位址空間中的堆積、堆疊、二進位檔及其他資料結構的配置，從而降低惡意探索的可靠性。
      • 資料執行防止 (DEP/NX) – 只有想要包含程式碼的記憶體頁面是可執行的。

Microsoft 直接投資 Hyper-V 安全性權益 Azure Hypervisor。 深度防禦風險降低的目標是讓攻擊者盡可能耗用武器化利用弱點，限制其影響，並將偵測的視窗最大化。 所有惡意探索風險降低都會透過使用敵人可能採用的方法，徹底檢閱 Azure Hypervisor 攻擊面來評估其有效性。 表 3 概述一些防護功能，旨在保護 Hypervisor 隔離界限和硬體主機完整性。

表 3. Azure Hypervisor 深度防禦

風險降低 安全性影響 風險降低詳細資料
控制流程完整性 增加執行控制流程完整性攻擊的成本 (例如，傳回導向的程式設計惡意探索) 控制流程防護 (CFG) 可確保間接控制流程傳輸會在編譯階段進行檢測，並由核心 (使用者模式) 或安全核心 (kernel-mode) 強制執行，以減輕堆疊傳回弱點。
使用者模式程式碼完整性 防止使用者模式中的惡意和不必要二進位執行 在主機分割區中的所有二進位檔上強制位址空間配置隨機化 (ASLR)，所有以 SDL 安全性檢查編譯的程式碼 (例如，strict_gs)，主機處理序上任意程式碼產生限制，防止插入執行階段產生的程式碼。
Hypervisor 強制執行使用者和核心模式程式碼完整性 在驗證程式碼的真實性之前，未將任何程式碼載入標示為執行的字碼頁 虛擬化型安全性 (VBS) 會使用記憶體隔離來建立安全的世界，以強制執行原則並儲存敏感性程式碼和秘密。 使用 Hypervisor 強制執行的程式碼完整性 (HVCI)，安全的世界會用來防止未簽署的程式碼插入一般世界核心。
使用平台安全開機硬體根信任 確保主機只會啟動所需的確切韌體和 OS 映像 Windows 安全開機會驗證 Azure Hypervisor 基礎結構只能在已知的良好設定中開機，且符合 Azure 韌體、硬體和核心生產版本。
減少攻擊面 VMM 防止 VMM 使用者函式中的權限提升 Azure Hypervisor Virtual Machine Manager (VMM) 包含使用者和核心模式元件。 除了許多分層防護功能之外，使用者模式元件也會被隔離，以防止突破核心模式函式。

此外，Azure 已透過 Red Teaming實作假設缺口安全性策略。 這種方法仰賴專門的安全性研究人員和工程師小組，他們使用與即時生產基礎結構的實際對手相同的策略、技術及程序，對 Azure 系統和平台工程或作業小組進行持續測試，而不需要事先認識 Azure 基礎結構和平台工程或作業小組。 此方法會測試安全性偵測和回應功能，並協助識別 Azure Hypervisor 和其他系統中的生產弱點，包括設定錯誤、無效的假設或其他受控制方式的安全性問題。 Microsoft 會大量投資這些創新的安全性措施，以持續降低 Azure 威脅。

強式安全性保證程序

Hyper-V 中的受攻擊面非常清楚。 這是正在進行的研究和徹底的安全性審查的主題。 在 2018 年 Black Hat 會議的公開簡報中，Microsoft 一直對 Hyper-V 攻擊面和基礎安全性架構持透明態度。 Microsoft 支援 Hyper-V 隔離的健全性和品質，$250,000 美元的 Bug 懸賞計劃，用於重大遠端程式碼執行 (RCE)、資訊洩漏，以及 Hyper-V 中報告的拒絕服務 (DOS) 弱點。 藉由在 Windows Server 和 Azure 雲端平台中使用相同的 Hyper-V 技術，公開可用的文件和 Bug 懸賞計劃，可確保 Microsoft 產品和服務的所有使用者都能獲得安全性改進。 表 4 摘要說明 Black Hat 簡報的主要攻擊面點。

表 4. Hyper-V 攻擊面詳細資料

受攻擊面區域 如果遭入侵，則授與的權限 高階元件
Hyper-V Hypervisor：完整的系統危害，並有能力危害其他客體 - Hypercalls
- 攔截處理
主機分割核心模式元件 核心模式中的系統：完整的系統危害，並有能力危害其他客體 - 虛擬基礎結構驅動程式 (VID) 攔截處理
- 核心模式用戶端程式庫
- 虛擬機器匯流排 (VMBus) 通道訊息
- 儲存體虛擬化服務提供者 (VSP)
- 網路 VSP
- 虛擬硬碟 (VHD) 剖析器
- Azure 網路虛擬篩選平台 (VFP) 及虛擬網路 (VNet)
主機分割使用者模式元件 使用者模式中的背景工作處理序：攻擊主機和提升權限的能力有限 - 虛擬裝置 (VDEV)

為了保護這些受攻擊面，Microsoft 已建立領先業界的流程和工具，以在 Azure 隔離保證中提供高度信賴度。 如本文後面安全性保證程式與做法一節所述，此方法包含目的建置模糊、滲透測試、安全性開發生命週期、強制安全性訓練、安全性檢閱、根據客–體主機威脅指標的安全性入侵偵測，以及自動建立攻擊介面區變更的警示。 這種成熟的多維保證流程有助於透過降低安全弱點的風險來增強 Azure Hypervisor 提供的隔離保證。

注意

Azure 採用業界領先的方法，以確保在 Hyper-V 技術中對虛擬機器隔離的 Hyper-V 技術進行強化和改進。 此方法的結果是強固的 Hypervisor，可協助確保租用戶透過 1) 強化定義的安全性界限、2) 深度防禦防護風險降低，以及 3) 強大的安全性保證程式。

Drawbridge 隔離

對於使用客戶程式碼提供少量處理單位的服務，來自多個租用戶的要求會在單一 VM 內執行，並使用 Microsoft Drawbridge 技術隔離。 為了提供安全性隔離，Drawbridge 會在 pico-process 內，搭配輕量版的 Windows 核心 (程式庫 OS) 來執行使用者流程。 pico-process 是輕量型且安全的隔離容器，其核心 API 介面最少，且無法直接存取主機系統的服務或資源。 pico-process 可以進行的唯一外部呼叫是透過 Drawbridge 應用程式二進位介面 (ABI) 對 Drawbridge 安全性監視器，如圖 8 所示。

Process isolation using Drawbridge圖 8.使用 Drawbridge 處理隔離

安全性監視器分為系統裝置驅動程式和使用者模式元件。 ABI 是程式庫 OS 與主機之間的介面。 整個介面由少於 50 個無狀態函式呼叫的封閉集合組成：

  • 從 pico-process 到主機 OS 的呼叫會支援執行緒、虛擬記憶體及 I/O 串流等抽象概念。
  • 啟動對 pico 處理程式的呼叫，執行初始化、傳回例外狀況資訊，並在新的執行緒中執行。

介面的語意是固定的，並支援應用程式從任何作業系統所需的一般抽象概念。 此設計可讓程式庫 OS 和主機個別發展。

ABI 會在兩個元件內實作：

  • 平台適應層 (PAL) 會在 pico-process 中執行。
  • 主機實作會以主機的一部分執行。

pico-process 會分組為 沙盒的隔離單位。 沙箱會定義 pico-processes 可用的應用程式、檔案系統及外部資源。 當在 pico-process 內執行的流程建立新的子處理序時，它會在相同沙箱內的個別 pico-process 中，使用自己的程式庫 OS 來執行。 每個沙箱都會與安全性監視器通訊，而且無法與其他沙箱通訊，但透過允許的 I/O 通道 (通訊端、具名管道等)，這些通道需要由設定明確允許，因為預設選擇加入方法取決於服務需求。 結果是，在 pico-process 內執行的程式碼只能存取自己的資源，而且無法直接攻擊主機系統或任何共置的沙箱。 它只能影響其本身沙箱內的物件。

當 pico-process 需要系統資源時，它必須呼叫 Drawbridge 主機以要求它們。 虛擬使用者流程的一般路徑是呼叫程式庫 OS 以要求資源，然後程式庫 OS 會呼叫 ABI。 除非驅動程式本身已設定資源配置原則，否則安全性監視器會檢查原則以處理 ABI 要求，以查看是否允許要求，然後維護要求。 此機制用於所有系統基本類型，因此可確保在 pico-process 中執行的程式碼無法濫用主計算機的資源。

除了在沙箱內隔離之外，pico-process 也會彼此隔離。 每個 pico-process 都位於自己的虛擬記憶體位址空間中，並使用自己的使用者模式核心執行自己的程式庫 OS 複本。 每次在 Drawbridge 沙箱中啟動使用者流程時，就會啟動新的程式庫 OS 執行個體。 相較於在 Windows 上啟動非隔離流程，這項工作比較耗時，但比在完成邏輯隔離時啟動 VM 的速度要快得多。

一般的 Windows 流程可以呼叫超過 1200 個函式，以存取 Windows 核心；不過，pico-process 的整個介面包含少於 50 個對主機的呼叫。 大部分作業系統服務的應用程式要求都會由程式庫 OS 在 pico-process 位址空間內處理。 Drawbridge 藉由為核心提供明顯較小的介面，可建立更安全且隔離的作業環境，其中應用程式較不容易受到主機系統中的變更和新 OS 版本引進的不相容程度。 更重要的是，Drawbridge pico-process 是一個強化隔離的容器，其中即使是最惡意來源的不受信任程式碼也能執行，而不會危害主機系統的風險。 主機假設 pico-process 內執行的程式碼無法受到信任。 主機會使用安全性檢查驗證來自 pico-process 的所有要求。

就像虛擬機器一樣，pico-process 比傳統 OS 介面更容易保護，因為它明顯較小、無狀態，而且具有固定且容易描述的語意。 小型 ABI / 驅動程式 syscall 介面的另一個新增優點是能夠輕鬆稽核 / 模糊驅動程式程式碼。 例如，syscall 模糊器可以在相對短時間內模糊高涵蓋範圍數字的 ABI。

以使用者內容為基礎的隔離

如果 Azure 服務是由 Microsoft 控制的程式碼所組成，且不允許執行客戶程式碼，則使用者內容會提供隔離。 不允許這些服務只接受使用者設定輸入及處理 – 任意程式碼的資料。 針對這些服務，會提供使用者內容來建立可存取的資料，以及允許哪些 Azure 角色型存取控制 (Azure RBAC) 作業。 此內容是由 Microsoft Entra ID 所建立，如先前身分識別型隔離一節所述。 一旦識別並授權使用者之後，Azure 服務會建立附加至要求的應用程式使用者內容，因為它在執行時會提供保證使用者作業會分開並適當隔離。

實體隔離

除了設計提供給所有 Azure 租用戶的健全邏輯計算隔離之外，如果您想要實體計算隔離，您可以使用 Azure 專用主機或隔離的虛擬機器，這兩者都專用於單一客戶。

注意

實體租用戶隔離會增加部署成本，而且在大部分情況下可能不需要，因為 Azure 所提供的強式邏輯隔離保證。

Azure 專用主機

Azure 專用主機提供可主控一或多個 Azure VM 的實體伺服器，且專屬於單一 Azure 訂閱。 您可以在區域、可用性區域和容錯網域中佈建專用主機。 接著，您可以使用最符合您需求的任何設定，將 Windows、Linux 及 SQL Server 直接放在 Azure VM 上。 專用主機提供實體伺服器層級的硬體隔離，可讓您將 Azure VM 放在隔離且專用的實體伺服器上，此實體伺服器只執行組織的工作負載，以符合公司合規性需求。

注意

您可以使用 Azure 入口網站、Azure PowerShell 及 Azure CLI來部署專用主機。

您可以選取伺服器和 CPU 類型、核心數目及額外功能，將 Windows 和 Linux 虛擬機器部署至專用主機。 專用主機可讓您選擇加入維護期間，以減少對已佈建服務的潛在影響，藉此控制平台維護事件。 大部分的維護事件都不會影響您的 VM；不過，如果您是高管制產業或具有敏感性工作負載，您可能想要控制任何潛在的維護影響。

Microsoft 提供使用 Azure 入口網站、Azure PowerShell 及 Azure CLI 佈建 Windows 和 Linux Azure 虛擬機器的詳細客戶指導。 表 5 摘要說明在 Azure 中佈建虛擬機器的可用安全性指導。

表 5. Azure 虛擬機器的安全性指導

VM 安全性指導
Windows 安全原則
Azure 磁碟加密
內建安全性控制
安全性建議
Linux 安全原則
Azure 磁碟加密
內建安全性控制
安全性建議

隔離的虛擬機器

Azure 計算服務所提供的虛擬機器大小不受特定硬體型別限制，而且為單一客戶專用。 這些 VM 執行個體可讓您的工作負載部署在專用實體伺服器上。 使用隔離的 VM 基本上可確保您的 VM 是唯一在該特定伺服器節點上執行的 VM。 您也可以選擇進一步細分這些隔離 VM 上的資源，方法是使用 Azure 支援巢狀虛擬機器。

網路隔離

公用多租用戶雲端中租用戶基礎結構的邏輯隔離，是維護安全性的基礎。 虛擬化解決方案的首要原則是只允許該虛擬化解決方案操作所需的連線和通訊，預設會封鎖所有其他連接埠和連線。 Azure 虛擬網路 (VNet) 可協助確保您的私人網路流量在邏輯上與屬於其他客戶的流量隔離。 一個 VNet 中的虛擬機器 (VM) 無法與不同 VNet 中的 VM 直接通訊，即使這兩個 VNet 都是由同一個客戶所建立也一樣。 網路隔離可確保 VM 之間的通訊在 VNet 內保持私人狀態。 視您的連線選項而定，您可以透過 VNet 對等互連或 VPN 閘道來連線 VNet，包括頻寬、延遲及加密需求。

本節說明 Azure 如何隔離租用戶之間的網路流量，並強制執行以密碼編譯確定性隔離。

分隔租用戶網路流量

虛擬網路 (VNet) 會在其基本設計中提供租用戶之間的網路流量隔離。 您的 Azure 訂用帳戶可以包含多個邏輯隔離的私人網路 (也包括防火牆、負載平衡，以及網路位址轉譯)。 每個 VNet 預設會與其他 VNet 隔離。 訂用帳戶內的多個部署可以放在相同的 VNet 上，然後透過私人 IP 位址彼此通訊。

VM 的網路存取受限於網路邊緣、負載平衡器及主機 OS 層級的封包篩選。 此外，您可以設定主機防火牆以進一步限制連線能力，並針對每個接聽連接埠指定是否接受來自網際網路的連線，或只從相同雲端服務或 VNet 內的角色執行個體。

Azure 會為每個部署提供網路隔離，並強制執行下列規則：

  • VM 之間的流量一律會透過信任的封包篩選器周遊。
    • 位址解析通訊協定 (ARP)、動態主機設定通訊協定 (DHCP) 和其他來自 VM 的 OSI 層 2 流量等通訊協定是使用速率限制和反詐騙保護來控制。
    • VM 無法擷取網路上任何不適合它們的流量。
  • 您的 VM 無法將流量傳送至 Azure 私人介面和基礎結構服務，或傳送至屬於其他客戶的 VM。 您的 VM 只能與您所擁有的其他 VM 通訊，以及用於公用通訊的 Azure 基礎結構服務端點進行通訊。
  • 當您將 VM 放在 VNet 上時，該 VM 會取得其本身的位址空間，而無法從部署或 VNet 外部的 VM 連線 (除非設定為可透過公用 IP 位址顯示)。 您的環境只會透過您為公用存取指定的連接埠開啟;如果 VM 定義為具有公用 IP 位址，則所有連接埠都會開放以供公用存取。

封包流程和網路路徑保護

Azure 的超大規模網路的設計目的是提供：

  • 伺服器之間的統一高容量。
  • 服務之間的效能隔離，包括客戶。
  • 乙太網路第 2 層語意。

Azure 會使用數個網路實作來達成下列目標：

  • 一般可讓服務執行個體放在網路中的任何位置。
  • 負載平衡以將流量統一分散到網路路徑。
  • 終端系統型位址解析可調整為大型伺服器集區，而不會對網路控制平面造成複雜性。

這些實作會帶給每個服務錯覺，即所有指派給它的伺服器，而只有這些伺服器會透過單一無干擾乙太網路交換器 – 虛擬層 2 (VL2) – 進行連線，並維持這種錯覺，即使每個服務的大小從一部伺服器到數十萬部伺服器也一樣。 此 VL2 實作可達到流量效能隔離，確保某個服務的流量無法受到任何其他服務的流量影響，就好像每個服務都由個別實體交換器連線。

本節說明封包如何流經 Azure 網路，以及拓撲、路由設計和目錄系統如何結合以虛擬化基礎網路網狀架構，建立伺服器連線到大型無干擾資料中心第 2 層交換器的錯覺。

Azure 網路會使用兩個不同的 IP 位址系列：

  • 客戶位址 (CA) 是客戶定義/選擇的 VNet IP 位址，也稱為虛擬 IP (VIP)。 網路基礎結構會使用外部可路由傳送的 CA 運作。 所有交換器和介面都會指派 CA，而且交換器會執行僅傳播這些 CA 的 IP 型 (第 3 層) 連結狀態路由通訊協定。 此設計可讓交換器取得完整的交換器層級拓撲，並將封裝於 CA 的封包轉送至最短路徑。
  • 提供者位址 (PA) 是 Azure 指派的內部網狀架構位址，使用者看不到，也稱為動態 IP (DIP)。 沒有流量直接從網際網路流向伺服器;來自網際網路的所有流量都必須通過軟體負載平衡器 (SLB)，並封裝以僅將封包路由傳送至有效的 Azure 內部 IP 位址和連接埠來保護內部 Azure 位址空間。 網路位址轉譯 (NAT) 會區隔內部網路流量與外部流量。 內部流量會使用 RFC 1918 位址空間或提供者位址 (PAS) – 無法外部路由傳送的私人位址空間。 轉譯會在 SLA 上執行。 外部可路由傳送的客戶位址會轉譯為只能在 Azure 內路由傳送的內部提供者位址 (PAS)。 無論伺服器的位置因虛擬機器移轉或重新佈建而變更的方式，這些位址都會保持不變。

每個 PA 都會與 CA 相關聯，這是伺服器所連線之機架頂端 (ToR) 交換器的識別碼。 VL2 會使用可調整且可靠的目錄系統來儲存和維護 PA 與 CA 的對應，而且當伺服器佈建至服務並指派的 PA 位址時，就會建立此對應。 在每部伺服器的網路堆疊中執行的代理程式，稱為 VL2 代理程式，會呼叫目錄系統的解析服務，以瞭解目的地的實際位置，然後將原始封包通道傳送到該處。

Azure 會指派僅做為名稱的伺服器 IP 位址，且沒有拓撲精確度。 Azure 的 VL2 定址配置會將這些伺服器名稱與其位置 (CA) 分開。 提供第 2 層語意的癥結在於讓伺服器相信它們會共用單一大型 IP 子網路 – 也就是整個 PA 空間 – 與其他相同服務中的伺服器，同時消除困擾大型乙太網路部署的位址解析通訊協定 (ARP) 和動態主機設定通訊協定 (DHCP) 調整瓶頸。

圖 9 描述範例封包流程，其中傳送者 S 會透過使用 IP-in-IP 封裝隨機選擇的中繼交換器，將封包傳送至目的地 D。 PA 來自 20/8，CA 則來自 10/8。 H(ft) 表示由來源 IP、來源連接埠、目的地 IP、目的地連接埠及通訊協定類型所組成的 5 元組雜湊。 ToR 會將 PA 轉譯為 CA，傳送至中繼交換器，該交換器會傳送至目的地 CA ToR 交換器，該交換器會轉譯為目的地PA。

Sample packet flow圖 9.範例封包流程

如果目錄服務拒絕提供封包給 PA，伺服器就無法將封包傳送至 PA，而 CA 可以透過 CA 路由傳送其封包，這表示目錄服務會強制執行存取控制原則。 此外，由於目錄系統知道哪個伺服器在處理查閱時發出要求，因此它可以強制執行精細隔離原則。 例如，它可以強制執行原則，只有屬於相同服務的伺服器可以彼此通訊。

流量流程模式

若要在使用 PA 位址的伺服器之間路由傳送流量，在知道 CA 位址路由的基礎網路上，每部伺服器上的 VL2 代理程式都會從主機擷取封包，並以目的地 ToR 交換器的 CA 位址封裝它們。 一旦封包到達 CA (也就是目的地 ToR 交換器)，目的地 ToR 交換器就將封包解封裝，並將它傳遞給內部標頭中攜帶的目的地 PA。 封包會先傳遞至其中一個中繼交換器，由交換器解封裝、傳遞至 ToR 的 CA、再次解封裝，最後傳送至目的地。 圖 10 中使用兩種可能的流量模式來描述這種方法：1) 透過 Azure ExpressRoute 或網際網路周游至 VNet 的外部流量 (橙色線條)，以及兩個 VNet 之間的 2) 內部流量 (藍色線條)。 這兩個流量都會遵循類似的模式來隔離和保護網路流量。

Separation of tenant network traffic using VNets圖 10.使用 VNet 分隔租用戶網路流量

外部流量 (橙色線條) – 針對外部流量，Azure 會提供多層保證，以根據流量模式強制執行隔離。 當您在 VNet 閘道上放置公用 IP 時，來自公用網際網路或您內部部署網路的流量會路由傳送至網際網路邊緣路由器。 或者，當您透過 ExpressRoute 連線建立私人對等互連時，會透過 VNet 閘道與 Azure VNet 連線。 此設定會對齊實體線路的連線能力，並讓內部部署位置的私人 IP 位址空間可定址。 Azure 接著會使用邊界閘道通訊協定 (BGP) 與內部部署網路共用路由詳細資料，以建立端對端連線。 當通訊從 VNet 內的資源開始時，網路流量會正常周遊，直到到達 Microsoft ExpressRoute Edge (MSEE) 路由器為止。 在這兩種情況下，VNet 都會提供 Azure VM 作為內部部署網路的一部分的方法。 Azure 與內部網路之間建立受密碼編譯保護的 IPsec/IKE 通道 (例如，透過 Azure VPN 閘道或 Azure ExpressRoute 私人對等互連)，讓 VM 安全地連線到內部部署資源，就像直接在該網路上一樣。

在 Internet Edge 路由器或 MSEE 路由器上，封包是使用一般路由封裝 (GRE) 進行封裝。 此封裝會使用 VNet 目的地和目的地位址特有的唯一識別碼，用來適當地將流量路由傳送至已識別的 VNet。 到達 VNet 閘道時，這是一種特殊的 VNet，用來接受來自 Azure VNet 外部的流量，Azure 網路網狀架構會驗證封裝，以確保：a) 接收封包的端點符合用來路由資料的唯一 VNet 識別碼，而 b) 要求的目的地位址存在於此 VNet 中。 驗證之後，封包會路由傳送為從 VNet 閘道到 VNet 內最終要求的目的地位址的內部流量。 這種方法可確保來自外部網路的流量只會移至目的地為 Azure VNet 的 Azure VNet，從而強制執行隔離。

內部流量 (藍色線條) – 內部流量也會使用 GRE 封裝/通道。 當 Azure VNet 中的兩個資源嘗試建立彼此之間的通訊時，Azure 網路網狀架構會觸達屬於 Azure 網路網狀架構的 Azure VNet 路由目錄服務。 目錄服務會使用客戶位址 (CA) 和要求的目的地位址來判斷提供者位址 (PA)。 這項資訊，包括 VNet 識別碼、CA 及 PA，接著會用來封裝具有 GRE 的流量。 Azure 網路會使用這項資訊，使用 PA 將封裝的資料正確路由傳送至適當的 Azure 主機。 封裝是由 Azure 網路網狀架構檢閱，以確認：

  1. PA 是相符的項目，
  2. CA 位於此 PA，且
  3. VNet 識別碼是相符的項目。

驗證這三項之後，封裝就會移除，並路由至 CA 作為一般流量，例如 VM 端點。 此方法會根據雲端服務之間的正確流量路由，提供 VNet 隔離保證。

Azure VNet 會實作數種機制，以確保租用戶之間的流量安全。 這些機制符合現有的業界標準和安全性做法，並防止已知的攻擊媒介，包括：

  • 防止 IP 位址詐騙 – 每當 VNet 傳輸封裝的流量時，服務就會傳回接收端傳輸的相關資訊。 流量會在傳輸開始時獨立查閱並封裝，並在接收端點進行回傳，以確保已適當地執行傳輸。 這項驗證是透過名為 SpoofGuard 的內部 VNet 功能來完成，此功能會驗證來源和目的地是否有效且允許通訊，從而防止預期封裝模式中的不符，否則可能會允許詐騙。 GRE 封裝流程會防止詐騙，因為 Azure 網路網狀架構未完成的任何 GRE 封裝和加密都會被視為已卸除的流量。
  • 在 Azure VNet 實作中提供重疊網路空間的客戶之間的網路分割 – Azure VNet 實作依賴已建立的通道標準，例如 GRE，進而允許在整個雲端使用客戶專屬的唯一識別碼 (VNet 識別碼)。 VNet 識別碼會作為範圍識別碼使用。 這種方法可確保您一律在唯一的位址空間內運作，在租用戶與 Azure 網路網狀架構之間重疊位址空間。 未封裝到有效 VNet 識別碼的任何項目，都封鎖在 Azure 網路網狀架構內。 在先前所述的範例中，會捨棄 Azure 網路網狀架構未執行的任何封裝流量。
  • 防止流量在 VNet 之間交叉 – 防止 VNet 之間的流量通過處理位址重疊並防止詐騙的相同機制來完成。 透過使用每個租用戶建立的唯一 VNet 識別碼並結合對來源和目的地的所有流量的驗證，使 VNet 之間的流量交叉變得不可行。 用戶無法存取依賴這些識別碼來執行封裝的基礎傳輸機制。 因此，任何封裝和模擬這些機制的嘗試都會導致流量中斷。

除了這些金鑰保護之外，預設會卸除源自網際網路的所有非預期流量。 任何進入 Azure 網路的封包都會先遇到 Edge 路由器。 Edge 路由器會刻意允許所有輸入流量進入 Azure 網路，但詐騙流量除外。 此基本流量篩選可保護 Azure 網路免於已知的惡意流量。 Azure 還在網路層實施 DDoS 保護，根據即時和歷史資料分析收集記錄以節流或封锁流量，並根據需要緩解攻擊。

此外，Azure 網路網狀架構會封鎖源自於詐騙 Azure 網路網狀架構空間的任何 IP 的流量。 Azure 網路網狀架構會使用 GRE 和虛擬可延伸 LAN (VXLAN) 來驗證所有允許的流量是否為 Azure 控制的流量，並封鎖所有非 Azure GRE 流量。 藉由使用 GRE 通道和 VXLAN 來使用客戶唯一金鑰來分割流量，Azure 會滿足 RFC 3809 和 RFC 4110。 搭配 ExpressRoute 使用 Azure VPN 閘道時，Azure 會滿足 RFC 4111 和 RFC 4364。 透過包含外部和內部網路流量的完整隔離方法，Azure VNet 可讓您保證 Azure 能夠成功路由傳送 VNet 之間的流量，讓具有重疊位址空間的租用戶進行適當的網路分割，並防止 IP 位址詐騙。

您也可以使用 Azure 服務進一步隔離和保護資源。 使用網路安全性群組 (NSG)，這是 Azure 虛擬網路的一項功能，您可以透過多個輸入和輸出安全性規則，依來源和目的地 IP 位址、連接埠及通訊協定來篩選流量，這些規則 – 基本上可作為分散式虛擬防火牆和 IP 型網路存取控制清單 (ACL)。 您可以將 NSG 套用至虛擬機器中的每個 NIC、將 NSG 套用至 NIC 或其他 Azure 資源所連線的子網路，以及直接套用至虛擬機器擴展集，以更精細地控制您的基礎結構。

在基礎結構層，Azure 會實作 Hypervisor 防火牆，以保護在 Hypervisor 上虛擬機器內執行的所有租用戶免於未經授權的存取。 此 Hypervisor 防火牆會分散為部署至主機的 NSG 規則的一部分、在 Hypervisor 中實作，並由網狀架構控制器代理程式設定，如圖 4 所示。 主機 OS 執行個體使用內建的 Windows 防火牆，以比路由器 ACL 更細微性實作更精細的 ACL - 它們由提供租用戶的相同軟體維護，因此它們永遠不會過時。 細部 ACL 會使用計算機組態檔 (MCF) 套用至 Windows 防火牆。

作業系統堆疊頂端是客體 OS，您用來作為作業系統。 根據預設，此層不允許任何輸入通訊至雲端服務或虛擬網路，基本上使其成為專用網路的一部分。 針對 PaaS Web 和背景工作角色，預設不允許遠端存取。 您可以啟用遠端桌面通訊協定 (RDP) 存取做為明確選項。 針對使用 Azure 入口網站建立的 IaaS VM，預設會開啟 RDP 和遠端 PowerShell 連接埠；不過，會隨機指派連接埠號碼。 針對透過 PowerShell 建立的 IaaS VM，必須明確開啟 RDP 和遠端 PowerShell 連接埠。 如果系統管理員選擇將 RDP 和遠端 PowerShell 連接埠保持開啟至網際網路，則允許建立 RDP 和 PowerShell 連線的帳戶應該使用強式密碼來保護。 即使連接埠已開啟，您也可以視需要在公用 IP 上定義 ACL，以提供額外保護。

服務標籤

您可以使用虛擬網路服務標籤進行網路隔離，以及在存取具有公用端點的 Azure 服務時，防止網際網路存取您的 Azure 資源。 透過服務標籤，您可以定義網路安全性群組或 Azure 防火牆的網路存取控制。 服務標籤代表來自指定 Azure 服務的一組 IP 位址首碼。 Microsoft 會管理服務標籤包含的位址前置詞，並隨著位址變更自動更新服務標籤，藉此減少網路安全性規則頻繁的更新。

注意

您可以建立輸入/輸出網路安全性群組規則，拒絕往返網際網路的流量，允許往返 Azure 的流量。 服務標籤適用於許多 Azure 服務，以用於網路安全性群組規則。

額外資源：

您可以使用 Private Link，透過 VNet 中私人端點存取 Azure PaaS 服務和 Azure 裝載的客戶或合作夥伴服務，以確保 VNet 與服務之間的流量會透過 Microsoft 全球骨幹網路傳輸。 這種方法不需要向公用網際網路公開服務。 您也可以在 VNet 中建立自己的 Private Link 服務，並提供給您的客戶。

Azure 私人端點是一種網路介面，其可以私人且安全的方式連線至 Private Link 所支援服務。 私人端點會使用您 VNet 中的私人 IP 位址，有效地將服務帶入您的 VNet 中。

從網路隔離的觀點來看，Private Link 的主要優點包括：

  • 您可以將 VNet 連線至 Azure 中的服務，而不需要來源或目的地的公用 IP 位址。 Private Link 會透過 Microsoft 全球骨幹網路處理服務與其取用者之間的連線能力。
  • 您可使用私人端點透過 Azure ExpressRoute 私人對等互連、VPN 通道及對等互連虛擬網路，從內部部署裝置存取在 Azure 中執行的服務。 Private Link無須設定公用對等互連或周遊網際網路來存取服務。
  • 您可以私人方式連線至在其他 Azure 區域中執行的服務。

注意

您可以使用 Azure 入口網站來管理 Azure PaaS 資源上的私人端點連線。 對於客戶/合作夥伴擁有的 Private Link 服務，Azure Power Shell 和 Azure CLI 是管理私人端點連線的慣用方法。

額外資源：

傳輸中資料加密

Azure 提供了許多為傳輸中的資料加密的選項。 傳輸中資料加密會隔離網路流量與其他流量，並協助保護資料免於遭到攔截。 傳輸中資料適用於涉及資料在下列位置之間移動的情節：

  • 您的終端使用者與 Azure 服務
  • 您的內部部署資料中心與 Azure 區域
  • 作為預期 Azure 服務作業一部分的 Microsoft 資料中心

終端使用者與 Azure 服務的連線

傳輸層安全性 (TLS) – Azure 會使用 TLS 通訊協定，協助您在使用者與 Azure 服務之間移動時保護資料。 大部分的終端使用者將透過網際網路連線到 Azure，而且網路流量的精確路由將取決於許多為網際網路基礎結構做出貢獻的網路提供者。 正如 Microsoft 產品和服務資料保護增補 (DPA) 所述，Microsoft 不會控制或限制您或您的終端使用者可以存取或移動客戶資料的區域。

重要

您可以啟用傳輸中加密來提高安全性。 例如，您可以使用應用程式閘道來設定網路流量的端對端加密，並依賴 tls 終止金鑰保存庫整合。

在 Azure 服務中，對服務的流量受到 TLS 1.2 保護，使用 RSA-2048 進行金鑰交換，並使用 AES-256 進行資料加密。 對應的密碼編譯模組是驗證為 Microsoft Windows FIPS 驗證方案一部分的 FIPS 140。

TLS 提供增強式驗證、訊息隱私性及完整性。 完美轉寄保密 (PFS) 會針對您起始的每個工作階段產生唯一的工作階段金鑰，以保護客戶端系統和 Microsoft 雲端服務之間的連線。 PFS 可保護過去的工作階段免於遭受未來潛在的主要危害。 在這種組合下，要攔截和存取傳輸中的資料就更加困難了。

VM 的傳輸中加密 – 部署在 Azure 中的 Windows 和 Linux 虛擬機器的遠端工作階段可以通過確保傳輸中資料加密的協定進行。 例如，從用戶端電腦到 Windows 和 Linux VM 起始的遠端桌面通訊協定 (RDP) 會啟用傳輸中資料的 TLS 保護。 您還可以使用 Secure Shell (SSH) 連線到 Azure 中執行的 Linux VM。 SSH 是預設可用的加密連線通訊協定，可用於遠端管理裝載於 Azure 中的 Linux VM。

重要

您應該檢閱網路安全的最佳做法，包括從網際網路停用虛擬機器 RDP/SSH 存取的指導，以減輕暴力密碼破解攻擊以取得 Azure 虛擬機器的存取權。 接著，您可以透過點對站 VPN、站對站 VPN或 Azure ExpressRoute，完成存取遠端管理的 VM。

Azure 儲存體交易 - 透過 Azure 入口網站與 Azure 儲存體互動時，所有交易都會透過 HTTPS 進行。 此外，您可藉由為儲存體帳戶設定「需要安全傳輸」屬性，將儲存體帳戶設定為僅接受來自安全連線的要求。 在 Azure 入口網站中建立儲存體帳戶時，依預設會啟用「需要安全傳輸」選項。

Azure 檔案儲存體提供雲端中完全受控的檔案共用，可透過業界標準伺服器訊息區 (SMB) 通訊協定來存取。 根據預設，所有 Azure 儲存體帳戶都會啟用傳輸中加密。 因此，透過 SMB 掛接共用或透過 Azure 入口網站存取共用時 (或 Azure PowerShell、Azure CLI 及 Azure SDK)，Azure 檔案儲存體服務只有在使用 SMB 3.0+ 進行加密或透過 HTTPS 進行連線時，才會允許連線。

資料中心與 Azure 區域的連線

VPN 加密 - 虛擬網路 (VNet) 會提供一種方法，讓 Azure 虛擬機器 (VM) 作為內部 (內部部署) 網路的一部分。 使用 VNet 時，您可以選擇要指派給 VM 的非全域可路由 IP 位址的位址範圍，使其不會與您在其他地方使用的位址相衝突。 您可以選擇從內部部署基礎結構或遠端位置安全地連線到 VNet。

  • 站對站 (IPsec/IKE VPN 通道) – 在 Azure 與內部網路之間建立密碼編譯保護的「通道」，可讓 Azure VM 連線到後端資源，就像直接在該網路上一樣。 此類型的連線需要位於內部部署的 VPN 裝置，且您已對該裝置指派對外開放的公用 IP 位址。 您可以使用 Azure VPN 閘道，透過公用網際網路傳送 VNet 與內部部署基礎結構之間的加密流量，例如，站對站 VPN 依賴 IPsec 進行傳輸加密。 VPN 閘道支援許多經過 FIPS 140 驗證的加密演算法。 此外，您可以將 VPN 閘道設定為使用自訂 IPsec/IKE 原則搭配特定的密碼編譯演算法和金鑰強度，而不是依賴預設 Azure 原則。 IPsec 會在 IP 層級 (網路層 3) 為資料加密。
  • 點對站 (透過 SSTP、OpenVPN 及 IPsec 的 VPN) – 使用安全通訊端通道通訊協定 (SSTP)、OpenVPN 或 IPsec，從個別用戶端電腦建立安全連線到 VNet。 在點對站 VPN 組態中，您必須安裝憑證和 VPN 用戶端設定套件，讓用戶端電腦連線到 VNet 內的任何 VM。 點對站 VPN 連線不需要 VPN 裝置或公眾公用對應 IP 位址。

除了控制 VPN 連線支援的演算法類型之外，Azure 還可讓您強制執行離開 VNet 的所有流量只能透過 VNet 閘道路由傳送 (例如 Azure VPN 閘道)。 這項強制執行可讓您確保流量在未加密的情況下可能不會離開 VNet。 VPN 閘道可以用於 VNet 對 VNet 連線，同時也可提供使用 IPsec/IKE 的安全通道。 Azure VPN 會使用預先共用金鑰 (PSK) 驗證，Microsoft 會在建立 VPN 通道時產生 PSK。 您可以將自動產生的 PSK 變更為您自己的 PSK。

Azure ExpressRoute 加密 – Azure ExpressRoute 可讓您建立 Microsoft 資料中心與內部部署基礎結構或共置設施之間的私人連線。 ExpressRoute 連線不會經過公用網際網路，並提供比 IPsec 保護的 VPN 連線更低的延遲和更高的可靠性。 ExpressRoute 位置 是 Microsoft 全球網路骨幹的進入點，而且其不一定與 Azure 區域的位置相符。 一旦網路流量進入 Microsoft 骨幹，保證就會周遊該私人網路基礎結構，而不是公用網際網路。 您可以使用 ExpressRoute 搭配數個資料加密選項，包括 MACsec ，可讓您將 MACsec 加密金鑰儲存在 Azure Key Vault 中。 MACsec 會在媒體存取控制 (MAC) 層級為資料加密，也就是資料連結層 (網路層 2)。 AES-128 和 AES-256 區塊編碼器都支援用於加密。 在透過 ExpressRoute Direct 連線至 Microsoft 時，您可以使用 MACsec 加密在其網路裝置與 Microsoft 網路裝置之間的實體連結。 EpressRoute Direct 可讓您在對等互連位置從邊緣直接光纖連線到 Microsoft 企業邊緣路由器。

除了 ExpressRoute Direct 連接埠上的 MACsec 之外，您還可以啟用 IPsec，如圖 11 所示。 使用 VPN 閘道，您可以在本機網路和 Azure VNet 之間透過 ExpressRoute 線路的 Microsoft 對等互連設定 IPsec 通道。 MACsec 可保護內部部署網路與 Microsoft 之間的實體連線。 IPsec 可保護內部部署網路與 Azure 中 VNet 之間的端對端連線。 MACsec 和 IPsec 可以獨立啟用。

VPN and ExpressRoute encryption for data in transit圖 11.傳輸中資料的 VPN 和 ExpressRoute 加密

跨 Microsoft 全球網路骨幹的流量

儲存體和 SQL Database 等 Azure 服務可以設定為進行異地複寫，以協助確保持久性和高可用性，特別是災害復原案例。 Azure 依賴配對區域來提供異地備援儲存體 (GRS)，而且在設定 Azure SQL Database 的作用中異地複寫時，也會建議使用配對區域。 配對的區域位於相同的地理位置內；不過，不保證網路流量一律遵循相同路徑，從一個 Azure 區域到另一個區域。 為了提供 Azure 雲端所需的可靠性，Microsoft 有許多實體網路路徑，皆具有在失敗後自動路由的功能，以獲得最佳的可靠性。

此外，在區域內或區域之間移動的所有 Azure 流量都會由 Microsoft 使用 MACsec 進行加密，而 MACsec 則依賴 AES-128 區塊加密進行加密。 此流量完全保留在 Microsoft 全球網路骨幹內，而且永遠不會進入公用網際網路。 此骨幹是世界上最大的骨幹之一，擁有超過 250,000 公里的光纖和海底電纜系統。

重要

您應該檢閱 Azure 保護傳輸中資料的最佳做法，以協助確保傳輸中所有資料都已加密。 對於金鑰 Azure PaaS 儲存體服務 (例如，Azure SQL Database、Azure SQL 受控執行個體及 Azure Synapse Analytics)，傳輸中的資料加密預設強制執行。

第三方網路虛擬設備

Azure 提供許多功能來協助您達成安全性和隔離目標，包括適用於雲端的 Microsoft Defender、Azure 監視器、Azure 防火牆、VPN 閘道、 網路安全性群組、應用程式閘道、Azure DDoS 保護、網路監看員、Microsoft Sentinel 及 Azure 原則。 除了 Azure 提供的內建功能之外，您還可以使用第三方網路虛擬設備，以配合您的特定網路隔離需求，同時套用現有的內部技能。 Azure 支援許多設備，包括 F5、Palo Alto Networks、Cisco、Check Point、Barracuda、Citrix、Fortinet 等許多設備。 網路設備在您的虛擬網路與部署中，會以 VM 的形態支援網路功能與服務。

網路隔離限制的累積效果是，每個雲端服務的行為就像它在隔離的網路上一樣，在這個網路上，雲端服務中的虛擬機器可以相互通訊，通過它們的來源 IP 位址來識別彼此，確信沒有其他方可以模擬它們的對等虛擬機器。 它們也可以設定為透過特定連接埠和通訊協定接受來自網際網路的連入連線，並確保離開虛擬網路的所有網路流量一律都會加密。

提示

您應該檢閱已發佈的 Azure 網路文件，以取得如何使用原生安全性功能的指導來協助保護您的資料。

額外資源：

儲存體隔離

Microsoft Azure 會將您的 VM 型計算資源與儲存體分隔開來，作為其基本設計的一部分。 這種區隔可讓計算和儲存體各自調整，更容易提供多重租用和隔離。 因此，除了透過邏輯方式，Azure 儲存體會在沒有連到 Azure 計算之網路連線的個別硬體上執行。

每個 Azure 訂用帳戶都能有一或多個儲存體帳戶。 Azure 儲存體支援的各種驗證選項，包括：

  • 共用對稱金鑰 – 建立儲存體帳戶時，Azure 會產生兩個 512 位的儲存體帳戶金鑰，以控制儲存體帳戶的存取權。 您可以在任何時間點輪替和重新產生這些金鑰，而不需與您的應用程式協調。
  • Microsoft Entra ID 型驗證 – Azure 儲存體的存取權可由 Microsoft Entra ID 控制，這會強制執行租用戶隔離，並實作強固措施，以防止未經授權的各方存取，包括 Microsoft 測試人員。 如需 Microsoft Entra 租用戶隔離的詳細資訊，請參閱白皮書 Microsoft Entra 資料安全性考量。
  • 共用存取簽章 (SAS) – 共用存取簽章或「預先簽署的 URL」，可以從共用對稱金鑰建立。 這些 URL 的範圍可大幅限制，以減少可用的受攻擊面，但同時允許應用程式將儲存體存取權授與其他使用者、服務或裝置。
  • 使用者委派 SAS – 委派驗證類似於 SAS，但是以 Microsoft Entra 權杖為基礎而非共用對稱金鑰。 此方法可讓使用 Microsoft Entra ID 進行驗證的服務建立具有有限範圍的預先簽署 URL，並將暫時存取權授與其他使用者、服務或裝置。
  • 匿名公用讀取存取 – 您可以允許部分儲存體在沒有驗證或授權的情況下公開存取。 如果您想要更嚴格的控制，則可以在訂用帳戶層級停用這項功能。

Azure 儲存體提供各種工作負載的儲存體，包括：

  • Azure 虛擬機器 (磁碟儲存體)
  • 巨量資料分析 (HDInsight 的 HDFS、Azure Data Lake Storage)
  • 儲存應用程式狀態、使用者資料 (Blob、佇列、資料表儲存體)
  • 長期資料儲存體 (Azure 封存儲存體)
  • 雲端中的網路檔案共享 (檔案儲存體)
  • 在網際網路上提供網頁 (靜態網站)

雖然 Azure 儲存體支援許多不同的外部客戶儲存體情節，但在內部，上述服務的實體儲存體是由一組常見的 API 所管理。 為了提供持久性和可用性，Azure 儲存體依賴跨租用戶之間共用的儲存體資源的資料複寫和資料分割。 為了確保邏輯資料隔離的密碼編譯確定性，Azure 儲存體依賴使用具有多個加密的進階演算法進行待用資料加密，如本節所述。

資料複寫

Azure 儲存體帳戶中的資料一律會進行複寫，以協助確保持久性及高可用性。 Azure 儲存體會複製資料，以防止暫時性硬體失敗、網路或電源中斷，甚至是大規模的自然災害。 您通常可以選擇在相同資料中心內、相同區域內的多個可用區或不同地理位置的區域之間複製資料。 具體來說，建立儲存體帳戶時，您可以選取下列其中一個備援選項：

  • 本地備援 (LRS) 會複寫三個複本 (或清除編碼的對等項目，如稍後所述) 資料在單一資料中心內。 只有在將資料寫入所有三個複本之後，才會成功傳回 LRS 儲存體帳戶的寫入要求。 每個復本都位於縮放單位內的個別容錯和升級網域 (資料中心內的一組儲存體機架)。
  • 區域備援儲存體 (ZRS) 會以同步方式，將您的資料複寫到單一區域中的三個儲存體叢集。 每個儲存體叢集實際上都與其他叢集分隔並位於自己的可用性區域 (AZ) 中。 只有在將資料寫入三個叢集的所有複本之後，才會成功傳回 ZRS 儲存體帳戶的寫入要求。
  • 異地備援儲存體 (GRS) 將資料複寫到離主要區域數百公里的次要 (配對) 區域。 GRS 儲存體帳戶即使在完整的區域中斷或主要區域無法復原的災害期間也是永久性的。 對於已啟用 GRS 或 RA-GRS 的儲存體帳戶，會使用 LRS 先複寫所有資料。 更新會先認可到主要位置，並使用 LRS 進行複寫。 接著會使用 GRS，以非同步的方式將更新複寫到次要區域。 當資料寫入次要位置時，也會使用 LRS 在該位置中複寫。
  • 讀取權限異地備援儲存體 (RA-GRS) 是以 GRS 為基礎。 除了跨兩個區域異地複寫之外，它還提供對次要位置中資料的唯讀存取權。 使用 RA-GRS，不論 Microsoft 是否起始從主要到次要區域的容錯移轉，您都可以從次要區域讀取。
  • 異地區域備援儲存體 (GZRS) 結合 ZRS 的高可用性，以及 GRS 所提供的區域性中斷保護。 GZRS 儲存體帳戶中資料會複寫到主要區域中的三個 AZ，此外也會複寫到次要地理區域以保護其不受區域災害影響。 每個 Azure 區域都會與相同地理位置內的另一個區域配對，以共同形成區域配對。
  • 讀取權限異地區域備援儲存體 (RA-GZRS) 是以 GZRS 為基礎。 如果您的應用程式需要能夠在主要區域中發生災害後讀取資料，您可以選擇性地使用 RA-GZRS 來啟用次要區域中資料的讀取存取。

高階 Azure 儲存體結構

Azure 儲存體生產系統包含儲存體戳記和位置服務 (LS)，如圖 12 所示。 儲存體戳記是儲存體節點的機架叢集，其中每個機架都會建置為具有備援網路和電源的個別容錯網域。 LS 會管理所有戳記的所有儲存體戳記和帳戶命名空間。 它會將帳戶配置給儲存體戳記，並跨儲存體戳記管理它們，以進行負載平衡和災害復原。 LS 本身會分散到兩個地理位置，以進行自己的災害復原 (Calder 與其他人，2011 年)。

High-level Azure Storage architecture圖 12.高階 Azure 記憶體架構（來源：Calder 與其他人，2011 年）

儲存體戳記內有三層：前端、資料分割和串流。 本節的其餘部分會說明這些層次。

前端層

前端 (FE) 層是由一組無狀態伺服器所組成，這些伺服器會接受連入要求、驗證及授權要求，然後將它們路由傳送至資料分割層中的資料分割伺服器。 FE 層知道要轉送每個要求的資料分割伺服器，因為每個前端伺服器都會快取資料分割對應。 資料分割對應會追蹤要存取之服務的分割區，以及哪些資料分割伺服器正在控制對系統中每個分割區的存取權。 FE 伺服器也直接從資料流串流傳輸大型物件。

透過網際網路傳輸大量資料原本就不可靠。 使用 Azure 區塊 Blob 服務，您可以將大型檔案分成較小的資料區塊，以有效率地上傳和儲存大型檔案。 如此一來，區塊 Blob 會允許將資料分割成個別區塊，以取得大型上傳的可靠性，如圖 13 所示。 每個區塊的大小最多可達 100 MB，區塊 Blob 中最多 50,000 個區塊。 如果區塊無法正確傳輸，則只有該特定區塊需要重新傳送，而不必重新傳送整個檔案。 此外，使用區塊 Blob 時，可以平行傳送多個區塊，以減少上傳時間。

Block blob partitioning of data into individual blocks圖 13.將資料區塊 blob 分割區為單獨的區塊

您可以依任意順序上傳區塊，並且在最後的區塊清單認可步驟中決定其順序。 您也可以上傳新區塊來取代相同區塊識別碼的現有未認可區塊。

分割層

分割層負責：

  • 管理較高層級的資料抽象概念 (Blob、資料表、佇列)，
  • 提供可調整的物件命名空間，
  • 為物件提供交易順序和強式一致性，
  • 將物件資料儲存在串流層頂端，以及
  • 快取物件資料以減少磁碟 I/O。

此層也提供資料的異步異地複寫，並著重於跨戳記複寫資料。 戳記間複寫會在背景中完成，以保留兩個位置的資料複本，以供災害復原之用。

一旦 FE 層擷取 Blob 之後，分割層會負責追蹤和儲存資料放置於串流層的位置。 每個儲存體租用戶可以有大約 200 - 300 個個別的資料分割層節點，而每個節點負責追蹤及服務儲存在該儲存體租用戶中的資料分割。 高輸送量區塊 Blob (HTBB) 功能可讓資料在單一 Blob 內分區化，讓大型 Blob 的工作負載可在多個分割層伺服器之間共用 (圖 14)。 將負載分散到多個分割層伺服器，可大幅改善可用性、輸送量及持久性。

High throughput block blobs spread traffic and data across multiple partition servers and streams圖 14.高輸送量區塊 Blob 會將流量和資料分散到多個資料分割伺服器和資料流

串流層

串流層會將位元儲存在磁碟上，並負責在多部伺服器上散發和複寫資料，以將資料保存在儲存體戳記內。 它會做為戳記內的分散式檔案系統層。 它會處理稱為串流的檔案，這些檔案是排序的資料區塊清單，稱為範圍，類似於實體硬碟上的範圍。 大型 Blob 物件可以儲存在多個範圍中，可能位於多個實體範圍節點上 (EN)。 資料會儲存在串流層中，但可從資料分割層存取。 資料分割伺服器和資料流伺服器會共置在戳記中的每個儲存體節點上。

串流層會跨不同容錯網域中的不同節點提供同步複寫 (內部戳記)，以將資料保存在戳記內。 它負責建立每個範圍的三個本機複寫複本。 串流層管理員可確保這三個複本都會分散到不同容錯和升級網域上的不同實體機架和節點，以便複本能夠復原個別磁碟/節點/機架失敗，以及因升級而規劃停機。

Erasure 編碼 – Azure 儲存體會使用稱為 Erasure 編碼的技術，即使部分資料因磁碟失敗而遺失，仍可重建資料。 這種方法類似於個別磁碟的 RAID 等量分割概念，其中資料分散到多個磁碟，因此如果磁碟遺失，可以使用其他磁碟上資料的同位位元重新建構遺失的資料。 清除程式碼會將範圍分割成儲存在個別 EN 上的相等資料和同位片段，如圖 15 所示。

Erasure Coding further shards extent data across EN servers to protect against failure圖 15.清除跨 EN 伺服器進一步分區範圍資料，以防止失敗

儲存在串流範圍節點中的所有資料區塊都有 64 位元循環冗餘檢查 (CRC) 和由雜湊簽章保護的標頭，以提供範圍節點 (EN) 資料完整性。 在每次磁碟寫入、磁碟讀取及網路接收之前，都會檢查 CRC 和簽章。 此外，清理程式流程會定期讀取所有資料，驗證 CRC 並查找位元衰減。 如果發現不正確的範圍，則會建立該範圍的新複本來取代不正確的範圍。

Azure 儲存體中的資料依賴待用資料加密，以提供邏輯資料隔離的密碼編譯確定性。 您可以選擇 Microsoft 管理的加密金鑰 (也稱為平台管理的加密金鑰) 或客戶管理的加密金鑰 (CMK)。 資料加密和解密的處理對客戶而言是透明的，如下一節所述。

待用資料加密

Azure 提供廣泛的選項進行待用資料加密，以協助您同時使用 Microsoft 管理的加密金鑰和客戶自控加密金鑰時，來保護您的資料並符合您的合規性需求。 如需詳細資訊，請參閱資料加密模型。 此流程仰賴多個加密金鑰和服務，例如 Azure Key Vault 和 Microsoft Entra ID，以確保安全金鑰存取和集中式金鑰管理。

注意

如果您需要額外的安全性和隔離保證，以在 Azure 服務中儲存最具敏感性的資料，您可以使用您在 Azure Key Vault 中控制的專屬加密金鑰來加密該資料。

一般而言，控制金鑰存取，並確保透過下列類型的加密金鑰完成有效大量加密和解密 (如圖 16 所示)，不過其他加密金鑰可以使用，如儲存體服務加密一節中所述。

  • 資料加密金鑰 (DEK) 是對稱的 AES-256 金鑰，用於分割區或資料區塊的大量加密和解密。 密碼編譯模組會以 Windows FIPS 驗證程式的一部分來驗證 FIPS 140。 負責加密和解密特定資料區塊的資源提供者或應用程式執行個體需要存取 DEK。 單一資源可能會有多個分割區和多個 DEK。 使用新金鑰取代 DEK 時，只有其相關聯區塊中的資料才需要使用新金鑰重新加密。 DEK 一律由金鑰加密金鑰 (KEK) 加密儲存。
  • 金鑰加密金鑰 (KEK) 是您選擇性提供的非對稱 RSA 金鑰。 此金鑰加密金鑰可用來使用 Azure Key Vault 或受控 HSM 來加密資料加密金鑰 (DEK)。 如先前資料加密金鑰管理一節所述，Azure Key Vault 可以使用 FIPS 140 驗證的硬體安全性模組 (HSM) 來保護加密金鑰：受控 HSM 一律使用經過 FIPS 140 驗證的硬體安全性模組。 這些金鑰是不可匯出的，並且在 HSM 之外不可能有明文版本的 KEK - 繫結是由底層 HSM 強制執行的。 KEK 絕不會向資源提供者或其他服務直接公開。 KEK 的存取權是由 Azure Key Vault 中的權限所控制，而且必須透過 Microsoft Entra ID 驗證 Azure Key Vault 的存取權。 您可以撤銷這些權限來封鎖此金鑰的存取，並藉由延伸模組來封鎖使用此金鑰作為金鑰鏈結根目錄加密的資料。

Data Encryption Keys are encrypted using your key stored in Azure Key Vault圖 16.使用儲存在 Azure Key Vault 中的金鑰來加密資料加密金鑰

因此，加密金鑰階層同時牽涉到 DEK 和 KEK。 DEK 會使用 KEK 加密，並以個別方式儲存，以供資源提供者在大量加密和解密作業中有效率地存取。 不過，只有具有 KEK 存取權限的實體可以解密這些 DEK。 可存取 KEK 的實體可能不同於需要 DEK 的實體。 因為需要 KEK 才能將 DEK 解密，KEK 實際上就是單一點，藉以透過刪除 KEK 來刪除 DEK。

如需各種資料加密模型的詳細資訊，以及許多 Azure 平台服務的金鑰管理細節，請參閱線上文件。 此外，某些 Azure 服務會提供其他加密模型，包括用戶端加密，以使用更細微的控制進一步加密其資料。 本節的其餘部分涵蓋金鑰 Azure 儲存體情節的加密實作，例如 IaaS 虛擬機器的儲存體服務加密和磁碟加密。

提示

您應該檢閱已發佈的 Azure 資料加密文件，以取得如何保護資料的指導。

額外資源：

儲存體服務加密

Azure 待用資料的儲存體服務加密可確保資料在保存至 Azure 儲存體之前自動加密，並在擷取之前解密。 寫入 Azure 儲存體的所有資料都會透過經過 FIPS 140 驗證的 256 位元 AES 加密進行加密，而且對客戶而言，儲存體服務加密中的加密、解密及金鑰管理處理是透明的。 根據預設，Microsoft 會控制加密金鑰，並負責金鑰輪替、使用方式及存取。 金鑰會安全地儲存在 Microsoft 金鑰存放區中，並受到保護。 此選項提供您最方便的方式，因為所有 Azure 儲存體服務都受到支援。

不過，您也可以藉由指定下列方式，選擇使用您自己的金鑰來管理加密：

  • 客戶自控金鑰，可用來管理 Azure 儲存體加密，讓金鑰儲存在 Azure Key Vault 中。 此選項提供您建立、輪替、停用及撤銷客戶自控金鑰存取權的彈性。 您必須使用 Azure Key Vault 儲存客戶自控金鑰。 支援金鑰保存庫和受控 HSM，如先前在 Azure Key Vault 一節所述。
  • 客戶提供的金鑰，以便加密和解密 Blob 儲存體，只有金鑰可以儲存在 Azure Key Vault 或內部部署的另一個金鑰存放區，以符合法規合規性需求。 客戶提供的金鑰可讓您使用 Blob API 作為讀取或寫入作業的一部分，將加密金鑰傳遞至儲存體服務。

注意

您可以使用 Azure 入口網站、Azure PowerShell 或 Azure CLI，使用 Azure Key Vault 設定客戶自控金鑰 (CMK)。 您可以在 Blob 儲存體的要求上使用 .NET 指定客戶提供的金鑰。

所有全新和現有的儲存體帳戶預設都會啟用儲存體服務加密，且無法將其停用。 如圖 17 所示，加密程式會使用下列金鑰來協助確保待用資料隔離的密碼編譯確定性：

  • 資料加密金鑰 (DEK) 是用於大量加密的對稱 AES-256 金鑰，而且它是 Azure 儲存體中每個儲存體帳戶的唯一金鑰。 Azure 儲存體服務會在建立儲存體帳戶時產生，並用來衍生每個資料區塊的唯一金鑰。 如果客戶已設定客戶管理的金鑰加密，儲存體服務一律會使用戳記金鑰或金鑰加密金鑰來加密 DEK。
  • 金鑰加密金鑰 (KEK) 是由客戶管理的非對稱 RSA (2048 或更新版) 金鑰，並使用 Azure Key Vault 或受控 HSM 加密資料加密金鑰 (DEK)。 它永遠不會直接公開至 Azure 儲存體服務或其他服務。
  • 戳記金鑰 (SK) 是由 Azure 儲存體管理的對稱 AES-256 金鑰。 此金鑰是用來在不使用客戶管理的金鑰時保護 DEK。

這些金鑰會保護寫入 Azure 儲存體的任何資料，並提供 Azure 儲存體中邏輯資料隔離的密碼編譯確定性。 如先前所述，預設會啟用 Azure 儲存體服務加密，且無法停用。

Encryption flow for Storage service encryption圖 17.儲存體服務加密的加密流程

不論儲存體帳戶的效能層級 (標準或進階) 或部署模型 (Azure Resource Manager 或傳統) 為何，都會將其加密。 所有 Azure 儲存體備援選項支援加密，且所有儲存體帳戶複本都會加密。 系統會加密所有 Azure 儲存體資源，包括 Blob、磁碟、檔案、佇列和資料表。 也會加密所有物件中繼資料。

因為資料加密是由儲存體服務執行，因此使用 CMK 的伺服器端加密可讓您針對 VM 使用任何作業系統類型和映像。 針對您的 Windows 和 Linux IaaS VM，Azure 也提供 Azure 磁碟加密，可讓您使用客體 VM 內的 CMK 加密受控磁碟，或加密主機上磁碟資料的 EncryptionAtHost，如以下幾節所述。 Azure 儲存體服務加密也提供待用磁碟資料的雙重加密。

Azure 磁碟加密

Azure 儲存體服務加密會加密儲存 Azure 虛擬機器磁碟的分頁 Blob。 此外，您可以選擇性地使用 Azure 磁碟加密進行加密 Azure Windows 和 Linux IaaS 虛擬機磁碟，以提高儲存體隔離，並確保儲存在 Azure 中資料的密碼編譯確定性。 此加密包含受控磁碟，如本節稍後所述。 Azure 磁碟加密使用 Windows 的業界標準 BitLocker 功能，以及 Linux DM-Crypt 功能，以提供與 Azure Key Vault 整合的 OS 型磁碟區加密。

透過 BitLocker 和 DM-Crypt 進行磁碟驅動程式加密是一項資料保護功能，可與作業系統整合，可因應遺失、遭竊或未經正常管道報廢的電腦資料遭竊或曝光的威脅。 BitLocker 和 DM-Crypt 在與信任平台模組 (TPM) 1.2 版或更高版本搭配使用時，提供最多的保護。 TPM 是一種微控制器，設計用來透過整合式密碼編譯金鑰 – 保護硬體，通常預安裝在較新的電腦上。 BitLocker 和 DM-Crypt 可以使用這項技術來保護用來加密磁碟區的金鑰，並提供電腦開機程式的完整性。

針對受控磁碟，Azure 磁碟加密可讓您加密 IaaS 虛擬機器所使用的 OS 和資料磁碟;不過，若未先加密 OS 磁碟區，就無法加密資料。 解決方案依賴 Azure Key Vault 來協助您控制和管理金鑰保存庫中的磁碟加密金鑰。 您可以提供自己的加密金鑰，這在 Azure Key Vault 中受到保護，以支援 攜帶您自己的金鑰 (BYOK) 情節，如先前資料加密金鑰管理一節所述。

Azure 磁碟加密不支援受控 HSM 或內部部署金鑰管理服務。 只有由 Azure Key Vault 服務管理的金鑰保存庫，才可用來保護適用於 Azure 磁碟加密的客戶自控加密金鑰。 如需與受控 HSM 相關的其他選項，請參閱主機加密。

注意

如需建立和設定 Azure 磁碟加密金鑰保存庫的詳細指示，請參閱 Windows 和 Linux VM。

Azure 磁碟加密依賴兩個加密金鑰來進行實作，如先前所述：

  • 資料加密金鑰 (DEK) 是對稱的 AES-256 金鑰，用來透過 BitLocker 或 DM-Crypt 加密 OS 和資料磁碟區。 DEK 本身會加密並儲存在靠近資料的內部位置。
  • 金鑰加密金鑰 (KEK) – 用來將資料加密金鑰加密的非對稱式 RSA-2048 金鑰。 KEK 會保留在您控制的 Azure Key Vault 中，包括透過 Microsoft Entra 識別元授與存取權限。

以 KEK 加密的 DEK 會分開儲存，只有具有 KEK 存取權的實體才能解密 DEK。 Azure Key Vault 會保護 KEK 的存取權，您可以選擇將金鑰儲存在 FIPS 140 驗證的硬體安全性模組。

針對 Windows VM，Azure 磁碟加密會根據 Windows 版本選取 BitLocker 中的加密方法，例如 Windows Server 2012 或更新版本的 XTS-AES 256 位元。 這些密碼編譯模組是驗證為 Microsoft Windows FIPS 驗證方案一部分的 FIPS 140。 對於 Linux VM，Azure 磁碟加密使用帶有 256 位元磁碟區主金鑰的 aes-xts-plain64 解密預設值，該金鑰經過FIPS 140 驗證，作為 Microsoft Azure Marketplace 中 Linux IaaS VM 映像供應商取得的 DM-Crypt 驗證的一部分。

受控磁碟的伺服器端加密

Azure 受控磁碟是由 Azure 管理，並與 Azure Windows 和 Linux 虛擬機器搭配使用的區塊層級儲存體磁碟區。 它們可為您以透明方式處理儲存體帳戶管理，以簡化 Azure IaaS VM 的磁碟管理。 Azure 受控磁碟預設會使用已驗證 FIPS 140 的 256 位元 AES 加密 自動加密您的資料。 針對加密金鑰管理，您有下列選擇：

  • 平台管理的金鑰是預設選擇，可為由 Microsoft 管理的受控磁碟提供透明資料加密。
  • 客戶自控金鑰使你能夠控制自己的金鑰，這些金鑰可以匯入 Azure Key Vault 或受控 HSM 中或在其中產生。 此方法依賴兩組金鑰，如先前所述：DEK 和 KEK。 DEK 會使用 AES-256 型加密來加密資料，並接著由儲存在 Azure Key Vault 或受控 HSM 中的 RSA KEK 加密。

客戶自控金鑰 (CMK) 可讓您 完全控制加密金鑰。 您可以授與 Azure Key Vault 中受控磁碟的存取權，讓金鑰可用於加密和解密 DEK。 您也可以隨時停用金鑰或撤銷對受控磁碟的存取權。 最後，您對金鑰使用方式進行完整稽核控制，並透過 Azure Key Vault 監視來確保只有受控磁碟或其他授權資源才能存取加密金鑰。

主機加密

主機加密可與伺服器端加密搭配運作，以確保儲存在 VM 主機上的資料會在待用時加密，並將流量加密至儲存體服務。 裝載 VM 的伺服器對資料進行加密，不會影響效能，也不會要求客體 VM 中執行的程式碼，且加密的資料使用為伺服器端加密配置的金鑰流入 Azure 儲存體。 如需詳細資訊，請參閱在主機加密 - VM 資料的端對端加密。 使用 CMK 的主機加密可以使用儲存在受控 HSM 或 Key Vault 中的金鑰，就像受控磁碟的伺服器端加密一樣。

您在 Azure 中一律可控管客戶資料。 您可以視需要存取、擷取及刪除儲存在 Azure 中的客戶資料。 當您終止 Azure 訂用帳戶時，Microsoft 會採取必要步驟，以確保您可以繼續擁有客戶資料。 資料刪除或訂用帳戶終止的常見問題是另一位客戶或 Azure 系統管理員是否可以存取已刪除的資料。 以下各節說明 Azure 中資料删除、保留及銷毀的工作方式。

資料刪除

儲存體會以疏鬆方式配置，這表示在建立虛擬磁碟時，不會為其整個容量配置磁碟空間。 而會改為建立表格，將虛擬磁碟上的位址對應至實體磁碟上的區域，而該表格最初是空的。 第一次將資料寫入虛擬磁碟時，會配置實體磁碟上的空間，然後在表格中放置它的指標。 如需詳細資訊，請參閱 Azure 資料安全性 – 資料清理和外洩。

當您刪除 Blob 或資料表實體時，它會立即從用來尋找和存取主要位置資料的索引中刪除，然後在異地複寫的資料複本上以非同步方式刪除，如果您佈建異地備援儲存體。 在主要位置，您可以立即嘗試存取 Blob 或實體，而且在索引中找不到它，因為 Azure 提供刪除的強式一致性。 因此，您可以直接確認資料已刪除。

在 Azure 儲存體中，所有磁碟寫入都是循序的。 這種方法最大限度地減少磁碟「查找」量，但需要在每次寫入物件時更新指向物件的指標 - 新版本的指標也是按順序寫入的。 此設計的副作用是，您無法藉由以其他資料複寫磁碟上的秘密而消失。 原始資料會保留在磁碟上，而且會循序寫入新的值。 指標將會更新，因此無法再找到已刪除的值。 不過，一旦磁碟已滿，系統必須將新的記錄寫入到已由刪除舊資料釋放的磁碟空間。 記錄檔不是直接從磁碟扇區配置記錄檔，而是在執行 NTFS 的文件系統中建立記錄檔。 在 Azure 儲存體節點上執行的背景執行緒會透過瀏覽最舊的記錄檔，將仍然從該最舊記錄檔參考的區塊複製到目前的記錄檔，以及更新所有指標，以釋出空間。 然後，它會刪除最舊的記錄檔。 因此，磁碟上有兩種可用磁碟空間類別：(1) NTFS 知道是可用的空間，它會從此集區配置新的記錄檔；和 (2) Azure 儲存體知道的記錄檔內的空間是可用的，因為目前沒有指向它的指標。

與已刪除資料相關聯之實體磁碟上的扇區會立即可供重複使用，並在重複使用對應的儲存區塊來儲存其他資料時覆寫。 覆寫的時間會因磁碟使用率和活動而有所不同。 此流程與記錄結構化檔案系統的作業一致，其中所有寫入都會循序寫入磁碟。 此流程不具決定性，而且無法保證特定資料何時會從實體儲存體中消失。 然而，當完全删除的資料遭到覆寫或配置給另一個客戶的相應實體儲存體與金鑰隔離無關時，即删除後無法恢復任何資料：

  • 客戶無法讀取另一個客戶已刪除的資料。
  • 如果有人嘗試讀取尚未寫入的虛擬磁碟上的區域，實體空間將不會配置給該區域，因此只會傳回零。

客戶不會直接存取基礎實體儲存體。 由於客戶軟體只會處理虛擬磁碟，因此無法讓另一位客戶表達要求，要求讀取或寫入配置給您的實體位址或可用的實體位址。

從概念上講，不論追蹤讀取和寫入的軟體為何，這個理由都適用。 針對 Azure SQL Database，它是這項強制執行的 SQL Database 軟體。 針對 Azure 儲存體，它是 Azure 儲存體軟體。 對於 VM 的不可執行磁碟驅動程式，它是主機 OS 的 VHD 處理程式碼。 從虛擬到實體地址的對應會在客戶 VM 外部進行。

最後，如待用資料加密一節所述及如圖 16 所述，加密金鑰階層依賴金鑰加密金鑰 (KEK)，其可保留在您控制下的 Azure Key Vault 中 (也就是客戶自控金鑰 - CMK），並用來加密資料加密金鑰 (DEK)，這會使用 AES-256 對稱加密來加密待用資料。 根據預設，Azure 儲存體中的資料會待用加密，您可以選擇自行控制加密金鑰。 如此一來，您也可以防止存取儲存在 Azure 中的資料。 此外，因為需要 KEK 才能將 DEK 解密，KEK 實際上就是單一點，藉以透過刪除 KEK 來刪除 DEK。

資料保留

在 Azure 訂用帳戶期間，您一律能夠存取、擷取及刪除儲存在 Azure 中的資料。

如果您的訂閱到期或終止，Microsoft 會保留客戶資料 90 天的保留期間，以允許您擷取資料或更新訂閱。 在此保留期間之後，Microsoft 會在另外 90 天內刪除所有客戶資料，也就是說，客戶資料將在到期或終止后的 180 天內永久刪除。 根據資料保留程式，您可以透過使用 Microsoft 結束服務的時間來控制資料儲存的時間長度。 建議您在擷取所有資料之前，不要終止您的服務，以便在您稍後發現遺漏某些項目時，初始 90 天的保留期間可以做為安全緩衝區。

如果您錯誤地刪除整個儲存體帳戶，您應該立即連絡 Azure 支援以取得復原的協助。 您可以在 Azure 入口網站中建立及管理支援要求。 訂用帳戶內刪除的儲存體帳戶會保留兩週，以允許從意外刪除復原，之後就會永久刪除。 不過，當儲存體物件 (例如 Blob、檔案、佇列、資料表) 本身遭到刪除時，刪除作業是立即執行且不可逆的。 除非您進行備份，否則無法復原已刪除的儲存體物件。 針對 Blob 儲存體，您可以透過啟用虛刪除來實現額外的保護，防止意外或錯誤的修改或刪除。 針對儲存體帳戶啟用虛刪除時，該儲存體帳戶中的 Blob、Blob 版本和快照集可在刪除之後加以復原 (在您指定的保留期間內)。 若要避免在儲存體帳戶或訂用帳戶刪除之後保留資料，您可以在刪除儲存體帳戶或訂用帳戶之前個別刪除儲存體物件。

針對涉及 Azure SQL Database 的意外刪除，您應該檢查服務自動執行備份，並使用時間點還原。 例如，完整資料庫備份每週完成，而差異資料庫備份則每小時完成。 此外，個別服務 (例如 Azure DevOps) 可以有自己的意外資料刪除策略。

資料損毀

如果用於儲存體的磁碟機發生硬體故障，則會在解除委任之前安全地清除或銷毀。 磁碟機上的資料會被清除，以確保資料無法以任何方式復原。 當這類裝置解除委任時，Microsoft 會遵循 NIST SP 800-88 R1 處置流程，並將資料分類對齊 FIPS 199 中等安全性。 磁、電子或光學媒體會根據 NIST SP 800-88 R1 中建立的要求進行清除或銷毀，其中條款的定義如下：

  • 清除 -「一種保護資訊機密性免受實驗室攻擊的媒體清理流程」，其中涉及「使用非標準系統在正常操作環境之外的媒體上進行資料恢復嘗試的資源和知識」，使用「訊號處理設備和經過專門訓練的設備人員」。 注意：對於硬碟 (包括 ATA、SCSI、SATA、SAS 等) 韌體層級安全清除命令 (單一傳遞) 是可接受的，或軟體層級的三次傳遞覆寫和驗證 (一、零、隨機)，包括復原區域在內的整個實體媒體。 針對固態硬碟 (SSD)，需要韌體層級安全清除命令。
  • 終結 –「各種方法，包括分解、焚燒、粉碎、切碎及熔化」，之後媒體「無法如原意重複使用」。

清除和終結作業必須使用 Microsoft 安全性核准的工具和流程來執行。 記錄必須保留資產的清除和銷毀。 無法順利完成清除的裝置必須被消磁 (僅適用於磁性媒體) 或被銷毀。

除了啟用 Azure 計算、網路及儲存體隔離的技術實作詳細資料之外，Microsoft 還大量投資安全性保證流程和做法，以正確開發邏輯隔離的服務與系統，如下一節所述。

安全性保證流程和做法

Microsoft 內部使用安全性開發生命週期 (SDL) 和其他強大的安全性保證流程進一步強化 Azure 隔離保證，以保護攻擊面並減輕威脅。 Microsoft 已建立領先業界的流程和工具，以在 Azure 隔離保證中提供高度信賴度。

  • 安全性開發生命週期 (SDL) – Microsoft SDL 會在開發程式的所有階段引進安全性和隱私權考量，協助開發人員建置高度安全的軟體、解決安全性合規性需求，以及降低開發成本。 Microsoft SDL 中的指導方針、最佳做法、工具，以及 Microsoft SDL 中的流程做法，內部用來建置所有 Azure 服務，並建立更安全的產品和服務。 此流程也會公開記載，以與更廣泛的產業分享 Microsoft 的學習，並納入產業意見反應，以建立更強大的安全性開發流程。
  • 工具和流程 – 所有 Azure 程式碼都受限於一組廣泛的靜態和動態分析工具，可識別潛在的弱點、無效的安全性模式、記憶體損毀、使用者權限問題，以及其他重要的安全性問題。
    • 目的建置模糊 – 用來尋找軟體產品和服務中安全性弱點的測試技術。 它包含反覆將修改或模糊的資料饋送至軟體輸入，以觸發停止回應、例外狀況及當機，這些是攻擊者可用來中斷或控制應用程式和服務的錯誤狀況。 Microsoft SDL 建議模糊軟體產品的所有受攻擊面，特別是那些向不受信任的資料公開資料剖析器的表面。
    • 即時網站滲透測試 – Microsoft 正在進行即時網站滲透測試，以改善雲端安全性控制與程式，如本節稍後所述的 Red Teaming 計劃一部分。 滲透測試是對軟體系統的安全性分析，由模擬駭客動作的熟練安全性專業人員所執行。 滲透測試的目標是要找出因程式碼撰寫錯誤、系統設定錯誤或其他操作部署弱點所造成的潛在弱點。 測試會針對 Azure 基礎結構和平台以及 Microsoft 自己的租用戶、應用程式和資料進行。 在 Azure 中裝載的租用戶、應用程式及資料永遠不會設為目標；不過，您可以對部署在 Azure 中的應用程式進行自己的滲透測試。
    • 威脅模型化 – Microsoft SDL 的核心元素。 這是一種工程技術，可用來協助識別可能影響應用程式和服務的威脅、攻擊、弱點及對策。 威脅模型化 是 Azure 常式開發生命週期的一部分。
    • 自動建置警示攻擊介面區變更 – Attack Surface Analyzer 是 Microsoft 開發的開放原始碼安全性工具，可分析目標系統的受攻擊面，並報告軟體或系統設定期間所引入的潛在安全性弱點。 Attack Surface Analyzer 的核心功能是能夠在安裝軟體元件之前和之後，「差異」作業系統的安全性設定。 這項功能很重要，因為大部分的安裝流程都需要更高的權限，而且一旦授與，它們可能會導致非預期的系統設定變更。
  • 強制安全性訓練 – Microsoft Azure 安全性訓練和感知計劃需要負責 Azure 開發和作業的所有人員，根據個別工作需求採取基本訓練和任何額外的訓練。 這些程序提供標準的方法、工具及技術，可用來實作及維持感知計劃。 Microsoft 已實作稱為 STRIKE 的安全性感知計劃，向所有 Azure 工程人員提供每月關於安全性意識的電子郵件通訊，並讓員工註冊參加現場或線上安全性意識訓練。 STRIKE 全年提供一系列安全性訓練活動，加上 STRIKE Central，這是一個集中的線上資源，可用於安全性意識、訓練、文件及社群參與。
  • 錯誤懸賞計劃 – Microsoft 強烈建議您與學術和產業研究人員密切合作，為您和資料提供更高的安全性保證。 安全性研究人員藉由探索軟體開發流程中遺漏的弱點，在 Azure 生態系統中扮演不可或缺的角色。 Microsoft 錯誤懸賞計劃旨在補充和鼓勵相關技術的研究 (例如加密、詐騙、Hypervisor 隔離、特權提升等)，以更佳地保護 Azure 基礎結構和您的資料。 例如，對於 Azure Hypervisor 中發現的每項重大弱點，Microsoft 都會向安全研究人員補償高達 250,000 美元的費用，這是一筆可觀的金額，用於激勵參與和弱點披露。 Azure 服務上弱點報告的賞金範圍高達 60,000 美元。
  • Red Team 活動 – Microsoft 會使用 Red Teaming，這是針對 Microsoft 管理基礎結構、服務及應用程式進行即時網站滲透測試的形式。 Microsoft 會模擬真實世界缺口、持續監視安全性，以及實作安全性事件回應，以測試及改善 Azure 安全性。 Red Teaming 的述詞是假設入侵安全性策略，並由兩個核心群組執行：紅隊 (攻擊者) 和藍隊 (防禦者)。 這種方法的設計目的是使用與實際對手相同的策略、技術及程序來測試 Azure 系統和作業，而不需事先確認基礎結構和平台工程或作業小組。 此方法會測試安全性偵測和回應能力，協助以受控管的方式找出生產環境弱點、設定錯誤、無效的假設或其他安全性問題。 每個 Red Team 入侵之後，接著 Red Team 與 Blue Team 就會完全揭露以找出落差、處理所發現的狀況，並大幅改善缺口回應。

如果您習慣於傳統的內部部署資料中心部署，您通常會進行風險評估來測量威脅暴露程度，並在移轉至雲端時制訂緩和措施。 在上述許多情況下，傳統內部部署的安全性考量往往很容易理解，而對應的雲端選項通常是新的。 下一節旨在協助您進行這項比較。

邏輯隔離考慮

多租用戶雲端平台表示多個客戶應用程式和資料會儲存在相同的實體硬體上。 Azure 會使用邏輯隔離，將您的應用程式和資料與其他客戶隔離。 這種方法提供多租用戶雲端服務的規模和經濟效益，同時嚴格協助強制執行旨在防止其他客戶存取您資料或應用程式的控制項。 如果您要從傳統的內部部署實體隔離基礎結構移轉至雲端，本節將解決您可能感興趣的問題。

實體與邏輯安全性考量

表 6 提供實體隔離內部部署 (裸機) 與邏輯隔離雲端式部署 (Azure) 的重要安全性考量摘要。 在檢查識別為共用雲端環境的特定風險之前，先檢閱這些考量相當實用。

表 6. 實體與邏輯隔離的重要安全性考量

安全性考量 內部部署 Azure
防火牆、網路 - 實體網路強制執行 (交換機等)
- 實體主機型防火牆可由遭入侵的應用程式操作
- 兩層強制執行		 - 實體網路強制執行 (交換機等)
- Hyper-V 主機虛擬網路交換機強制執行無法從 VM 內部變更
- VM 主機型防火牆可由遭入侵的應用程式操作
- 三層強制執行
受攻擊面區域 - 暴露在複雜工作負載的大型硬體攻擊面，可啟用韌體型進階持續性威脅 (APT) - 未直接公開至 VM 的硬體，APT 無法從 VM 保存韌體
- 小型軟體型 Hyper-V 攻擊介面區，且暴露在 VM 上具有低歷程記錄錯誤計數
側邊通道攻擊 - 側邊通道攻擊可能是一個因素，儘管與共享硬體相比有所減少 - 側邊通道攻擊會假設控制跨應用程式放置的 VM 位置；在大型雲端服務中可能不實用
修補 - 跨主機系統套用的有效修補原則
- 硬體和韌體高度變動/脆弱更新		 - 跨主機和 VM 套用的統一修補原則
安全性分析 - 安全性分析相依於主機型安全性解決方案，假設主機/安全性軟體未遭入侵 - 外部 VM (Hypervisor 型) 鑑識/快照功能允許評估可能遭入侵的工作負載
安全性原則 - 安全性原則驗證 (修補程序掃描、弱點掃描等) 可能會遭到遭入侵的主機遭到竄改
- 跨客戶實體套用的安全性原則不一致		 -
安全性原則的外部 VM 驗證 - 可在客戶實體之間強制執行統一的安全性原則
記錄和監視 - 不同的記錄和安全性分析解決方案 - 常見的 Azure 平台記錄和安全性分析解決方案
- 大部分現有的內部部署/不同的記錄和安全性分析解決方案也能夠運作
惡意測試人員 - 系統管理員可以在僱用期間提高存取權限所造成的持續性威脅 - 大幅降低威脅，因為系統管理員沒有預設存取權限

以下列出在容納敏感資料和工作負載時可能需要解決的共用雲端環境特有的主要風險。

惡意探索虛擬化技術中的弱點

相較於傳統的內部部署託管系統，Azure 針對透過 Hypervisor 分層的主機作業系統使用鎖定的 Windows Server 核心，提供大幅降低攻擊面。 此外，根據預設，客體 PaaS VM 沒有任何使用者帳戶可接受連入遠端連線，且預設的 Windows 系統管理員帳戶已停用。 預設情況下，PaaS VM 中的軟體僅限於在低權限帳戶下執行，這有助於保護您的服務免受其自身終端使用者的攻擊。 您可以修改這些權限，您也可以選擇設定 VM 以允許遠端系統管理存取。

PaaS VM 比傳統實體伺服器解決方案提供更進階的防護，以防範持續性惡意程式碼感染，因為如果遭到攻擊者入侵，即使弱點得到修正也難以將其清除。 攻擊者可能已經對允許重新進入的系統進行修改，而且尋找所有這類變更是一項挑戰。 在極端的情況下，系統必須從頭重新安裝映像，並重新安裝所有軟體，有時會導致應用程式資料遺失。 使用 PaaS VM，重新製作映像是作業的常規部分，而且其有助於清除甚至未偵測到的入侵。 這種方法會使入侵更加難以持續。

旁路攻擊

Microsoft 一直處於緩和推測性執行旁路攻擊的最前沿，利用使用超執行緒的新式處理器中硬體弱點。 在許多方面，這些問題與 2018 年披露的 Spectre (變體2) 旁路攻擊類似。 Intel 和 AMD 在 2022 年披露多個新的推測性執行側邊通道問題。 為了解決這些弱點，Microsoft 已開發並最佳化 Hyper-V HyperClear，這是全面且高效能的側邊通道弱點風險降低架構。 HyperClear 依賴三個主要元件來確保 VM 間的強式隔離：

  • 核心排程器，以避免共用 CPU 核心的私人緩衝區和其他資源。
  • 虛擬處理器位址空間隔離，以避免推測性存取另一部虛擬機器的記憶體或另一個虛擬 CPU 核心的私人狀態。
  • 敏感資料清除，以避免在虛擬處理器私人位址空間內的 Hypervisor 記憶體中，將私人資料留在 Hypervisor 記憶體中的任何位置，以便未來無法推測存取此資料。

這些保護已部署至 Azure，並可在 Windows Server 2016 及更高版本支援的版本中使用。

注意

Hyper-V HyperClear 結構已證明是一種容易延伸的設計，可協助針對各種推測性執行側邊通道攻擊提供強大的隔離界限，對效能造成微不足道的影響。

當屬於不同客戶的 VM 在同一部實體伺服器上執行時，這是 Hypervisor 作業，以確保他們無法瞭解其他客戶的 VM 執行什麼工作。 Azure 可透過設計協助封鎖未經授權的直接通訊；不過，有一些微妙的影響，其中一個客戶可能會描述另一個客戶正在完成的工作。 其中最重要的影響是不同虛擬機器競爭相同資源時的計時影響。 透過仔細比較 CPU 上的操作計數和運行時間，虛擬機器可以瞭解同一伺服器上其他虛擬機器正在執行的操作。 這些惡意探索在學術媒體中引起大量關注，研究人員一直在尋求深入瞭解對等 VM 中發生狀況的更具體資訊。

特別感興趣的是，藉由測量特定記憶體存取的時間，並推斷受害者的 VM 正在讀取和更新的快取行，來瞭解對等 VM 密碼編譯金鑰。 在使用超執行緒 VM 的受控制條件下，已針對密碼編譯演算法的商業可用實作示範成功的攻擊。 除了 Azure 正在使用的 Hyper-V HyperClear 風險降低結構之外，Azure 中還有數個額外的風險降低，可降低這類攻擊的風險：

  • 標準 Azure 密碼編譯程式庫是設計來抵制這類攻擊，因為沒有快取存取模式取決於所使用的密碼編譯金鑰。
  • Azure 會使用高度複雜且幾乎不可能預測的進階 VM 主機放置演算法，這有助於降低將受敵人控制的 VM 放置在與目標 VM 相同的主機上的機會。
  • 所有 Azure 伺服器至少有 8 個實體核心，有些伺服器還有更多。 增加共用各種 VM 所放置負載的核心數目，會給已經很弱的訊號新增雜訊。
  • 您可以使用 Azure 專用主機或隔離的 VM，在單一客戶專用的硬體上佈建 VM，如實體隔離一節所述。 然而，實體租用戶隔離會增加部署成本，而且在大部分情況下可能不需要，因為 Azure 所提供的強式邏輯隔離保證。

整體而言，PaaS – 或任何自動建立 VM – 的工作負載都會導致 VM 放置變換，導致隨機化的 VM 配置。 VM 的隨機放置讓攻擊者更難進入相同的主機。 此外，主機存取的強化方式會大幅降低攻擊面，使得這些類型的惡意探索難以維持。

摘要

多租用戶雲端平台表示多個客戶應用程式和資料會儲存在相同的實體硬體上。 Azure 會使用邏輯隔離，將您的應用程式和資料與其他客戶隔離。 這種方法提供多租用戶雲端服務的規模和經濟效益，同時嚴格地協助防止其他客戶存取您的資料或應用程式。

Azure 藉由提供可信任的基礎，使用一組常見的原則，確保多租用戶以密碼編譯方式確定邏輯隔離的雲端服務，來解決資源共用的認知風險：

  • 使用 Microsoft Entra ID 和 Azure 角色型存取控制 (Azure RBAC) 進行驗證和身分識別分隔的使用者存取控制。
  • 用於處理的計算隔離，包括邏輯和實體計算隔離。
  • 網路隔離包括網路流量和傳輸中的資料加密區隔。
  • 使用具有多個加密和加密金鑰的進階演算法，以及 Azure Key Vault 中由客戶自控金鑰 (CMK) 佈建的儲存體隔離與待用資料加密。
  • 內嵌在服務設計中的安全性保證流程，以正確開發邏輯隔離的服務，包括安全性開發生命週期 (SDL) 和其他強大的安全性保證流程，以保護受攻擊面並降低風險。

根據雲端運算中的共同責任模型，本文提供您屬於您責任之活動的指導。 它也會探索 Azure 中可用的設計原則和技術，以協助您達成安全的隔離目標。

下一步

深入了解：