控制 Windows 裝置的健康情況

本文詳述端對端解決方案，可藉由強制執行、控制及報告 Windows 裝置的健康情況，協助您保護高價值資產。

簡介

針對自備裝置 (BYOD) 案例，員工會帶入商業可用的裝置來存取工作相關資源及其個人資料。 使用者想要使用自己選擇的裝置，不僅從內部網路，也從任何地方存取組織的應用程式、數據和資源。 這種現象也稱為 IT 取用。

使用者想要在存取公司應用程式，以及從其裝置處理組織數據時，擁有最佳的生產力體驗。 這表示不容許每次存取應用程式或文件伺服器時，系統都會提示他們輸入工作認證。 從安全性觀點來看，這也表示使用者在非受控裝置上操作公司認證和公司數據。

隨著 BYOD 的使用量增加，將會有更多非受控且可能狀況不良的系統存取公司服務、內部資源和雲端應用程式。

即使是受控裝置也可能遭到入侵並變成有害。 組織必須偵測安全性何時遭到入侵，並儘早回應，以保護高價值資產。

隨著 Microsoft 的前進，安全性投資逐漸著重於安全性預防性防禦，以及偵測和回應功能。

Windows 是端對端安全性解決方案的重要元件，不僅著重於安全性預防性防禦的實作，還可將裝置健康情況證明功能新增至整體安全性策略。

強固端對端安全性解決方案的描述

現今的運算威脅環境正以從未遇到過的速度增加。 犯罪攻擊的複雜性日益增加，因此，惡意代碼現在會同時以所有產業的消費者和專業人員為目標。

近些年來，威脅的其中一個特定類別已變得普遍：進階持續性威脅 (APT) 。 APT 一詞通常用來描述任何似乎持續以個別組織為目標的攻擊。 事實上，這種類型的攻擊通常牽涉到可能使用任何必要方法或技術的已判斷敵人。

在 BYOD 現象中，維護不良的裝置代表選擇的目標。 對於攻擊者而言，這是一種簡單的方法，可入侵安全性網路周邊、取得存取權，然後竊取高價值資產。

攻擊者的目標是個人，這並不是因為其身分為何，而是因為其工作物件。 受感染的裝置會將惡意代碼帶入組織，即使組織已強化網路周邊，或已投資其防禦狀態也一般。 防禦策略不足以抵禦這些威脅。

不同的方法

有效的安全性策略會假設已判定的敵人會成功入侵任何防禦，而不是傳統著重於防止入侵。 這表示必須將焦點從預防性安全性控制轉移到偵測和回應安全性問題。 因此，風險管理策略的實作可平衡預防、偵測和響應的投資。

由於行動裝置正逐漸用來存取公司資訊，因此需要某種方式來評估裝置安全性或健康情況。 本節說明如何布建裝置健康情況評估，讓高價值資產可以受到保護，以防止狀況不良的裝置。

必須信任用來存取公司資源的裝置。 有效率的端對端安全性方法能夠評估裝置健康情況，並在授與高價值資產的存取權時使用目前的安全性狀態。

圖 1.

強固的設計需要建立使用者的身分識別、視需要加強驗證方法，以及了解使用者定期連線的網路位置等行為。 此外，只有當使用者裝置判斷為狀況良好且安全時，新式方法才必須能夠釋放敏感性內容。

下圖顯示建置的解決方案，以評估來自雲端的裝置健康情況。 裝置會透過與雲端中識別提供者的連線來驗證使用者。 如果受控資產包含高度機密資訊，識別提供者的條件式存取引擎可能會選擇在授與存取權之前驗證行動裝置的安全性合規性。 用戶的裝置能夠證明隨時可以傳送的健康情況狀態，或在行動裝置管理 (MDM) 要求時傳送健康狀態。

圖 2。

您可以使用低階硬體技術，例如統一可延伸韌體介面 (UEFI) 安全開機，來保護 Windows 裝置免於低階 rootkit 和 bootkit。

安全開機是一種韌體驗證程式，可協助防止 rootkit 攻擊;它是 UEFI 規格的一部分。 UEFI的目的是要定義一種標準方式，讓操作系統與新式硬體通訊，這可以比舊版軟體中斷驅動的 BIOS 系統更快速且更有效率地執行輸入/輸出 (I/O) 功能。

裝置健康情況證明模組可以將受信賴平臺模組保護的測量開機數據 (TPM) 通訊至遠端服務。 裝置成功開機之後，開機程式測量數據會傳送至受信任的雲端服務 (健康情況證明服務) 使用更安全且防竄改的通道。

遠端健康情況證明服務會對度量執行一系列的檢查。 它會驗證安全性相關數據點，包括安全開機 (開機狀態、偵錯模式等) ，以及管理 BitLocker、Device Guard 等安全性 (元件) 的狀態。 然後將健康情況加密的 Blob 傳送回裝置，以傳達裝置的健康情況狀態。

MDM 解決方案通常會套用設定原則，並將軟體部署至裝置。 MDM 會定義安全性基準，並知道裝置的合規性層級，並定期檢查安裝的軟體和強制執行的設定，以及判斷裝置的健康情況狀態。

MDM 解決方案會要求裝置傳送裝置健康情況資訊，並將健康情況加密的 Blob 轉送至遠端健康情況證明服務。 遠端健康情況證明服務會驗證裝置健康情況數據、檢查 MDM 是否正在與相同的裝置通訊，然後將裝置健康情況報告發回 MDM 解決方案。

MDM 解決方案會評估健康情況判斷提示，並根據屬於組織的健全狀況規則，決定裝置是否狀況良好。 如果裝置狀況良好且符合規範，MDM 會將該資訊傳遞給識別提供者，以便叫用組織的訪問控制原則來授與存取權。

接著，無論健康狀態和其他條件元素指出什麼，內容的存取權都會授權為適當的信任層級。

根據受控資產的需求和敏感度，處理存取要求時，裝置健康狀態可以與使用者身分識別信息結合。 接著，內容的存取權會獲得適當信任層級的授權。 條件式存取引擎可以進行結構化，以允許受控資產的敏感度需要進行更多驗證。 例如，如果要求存取高價值數據，則可能需要在授與存取權之前，先查詢使用者接聽電話，以建立進一步的安全性驗證。

Microsoft 對 Windows 的安全性投資

在 Windows 中，有三個投資要件：

  • 安全身分識別。 Microsoft 是 FIDO 聯盟的一部分，其目的是要提供安全驗證的互操作方法，方法是不使用密碼進行驗證，無論是在本機系統上，以及內部部署資源和雲端資源等服務。
  • 資訊保護。 Microsoft 正在進行投資，讓組織能夠更妥善地控制誰可以存取重要數據，以及他們可以使用該數據執行哪些動作。 使用 Windows 時，組織可以利用原則來指定哪些應用程式被視為公司應用程式，並可信任以存取安全的數據。
  • 威脅抵禦。 Microsoft 正透過使用依賴硬體的安全性防禦，協助組織更妥善地保護企業資產免於遭受惡意代碼和攻擊的威脅。

保護、控制及報告 Windows 型裝置的安全性狀態

本節概觀說明端對端安全性解決方案的不同部分，可協助保護高價值資產和資訊免於攻擊者和惡意代碼攻擊。

圖 3。

數字 解決方案的一部分 描述
1 以 Windows 為基礎的裝置 第一次開啟以 Windows 為基礎的裝置時，會顯示 OOBE) 畫面 (全新體驗。 在安裝期間，裝置可以自動向 Microsoft Entra ID 註冊，並在 MDM 中註冊。
具有 TPM 的 Windows 裝置可以使用所有支援的 Windows 版本所提供的「健康情況證明服務」，隨時報告健康情況狀態。
2 識別提供者 Microsoft Entra ID 包含使用者、已註冊的裝置，以及組織租使用者的已註冊應用程式。 裝置一律屬於使用者，且使用者可以有多個裝置。 裝置會以具有不同屬性的物件表示，例如裝置的合規性狀態。 受信任的 MDM 可以更新合規性狀態。
Microsoft Entra ID 不只是存放庫。 Microsoft Entra ID 能夠驗證使用者和裝置，也可以授權存取受控資源。 Microsoft Entra ID 具有條件式訪問控制引擎，其使用使用者的身分識別、裝置的位置，以及裝置在進行信任存取決策時的合規性狀態。
3 行動裝置管理 Windows 具有 MDM 支援，可讓裝置全新管理，而不需要部署任何代理程式。
MDM 可以 Microsoft Intune 或任何與 Windows 相容的第三方 MDM 解決方案。
4 遠端健康情況證明 健康情況證明服務是由 Microsoft 營運的受信任雲端服務，會對 MDM 執行一系列的健康情況檢查和報告裝置上啟用的 Windows 安全性功能。
安全性驗證包括開機狀態 (WinPE、安全模式、偵錯/測試模式) 以及管理 BitLocker、Device Guard) (運行時間作業安全性和完整性的元件。
5 企業受控資產 企業受控資產是要保護的資源。
例如，資產可以 Office 365、其他雲端應用程式、Microsoft Entra ID 所發佈的內部部署 Web 資源，或甚至是 VPN 存取權。

Windows 型裝置、身分識別提供者、MDM 和遠端健康情況證明的組合會建立強大的端對端解決方案，以驗證存取高價值資產之裝置的健康情況和合規性。

保護裝置和企業認證免於威脅

本節說明 Windows 在安全性防禦方面提供哪些功能，以及可以測量和報告哪些控件。

Windows 硬體型安全性防禦

最積極形式的惡意代碼會嘗試儘早將自己插入開機程式，使其能夠及早控制操作系統，並防止保護機制和反惡意代碼軟體運作。 這種類型的惡意代碼通常稱為rootkit或bootkit。 避免必須處理低階惡意代碼的最佳方式是保護開機程式，讓裝置從一開始就受到保護。 Windows 支援多層開機保護。 只有在安裝特定類型的硬體時，才能使用其中一些功能。 如需詳細資訊，請參閱 硬體需求 一節。

圖 4。

Windows 支援可協助防止在啟動程式期間載入 rootkit 和 bootkit 等複雜低階惡意代碼的功能：

  • 信賴平台模組。 信賴平臺模組 (TPM) 是提供獨特安全性功能的硬體元件。

    Windows 會使用 TPM 的安全性特性來測量開機完整性順序 (，並據此解除鎖定受 BitLocker 保護的磁碟驅動器) 、保護認證或進行健康情況證明。

    TPM 會實作符合信賴運算群組 (TCG) 所述規格的控件。 在撰寫本文時，TCG 所產生的 TPM 規格有兩個版本彼此不相容：

    • 第一個 TPM 規格 1.2 版是由 TCG 於 2005 年 2 月發布，並根據 ISO / IEC 11889 標準進行標準化。
    • 最新的 TPM 規格稱為 TPM 2.0，已於 2014 年 4 月發行，並已由 ISO/IEC 聯合技術委員會核准， (JTC) 為 ISO/IEC 11889：2015。

    Windows 會使用 TPM 進行密碼編譯計算作為健康情況證明的一部分，並保護 BitLocker、Windows Hello、虛擬智慧卡和其他公鑰憑證的密鑰。 如需詳細資訊，請參閱 Windows 中的 TPM 需求。

    Windows 可辨識 TCG 所產生的 1.2 版和 2.0 版 TPM 規格。 針對最新且新式的安全性功能，Windows 僅支援 TPM 2.0。

    TPM 2.0 針對 TPM 1.2 的功能提供重大修訂：

    • 更新密碼編譯強度以符合新式安全性需求

      • 支援適用於 PCR 的 SHA-256
      • 支援 HMAC 命令

    • 密碼編譯演算法可彈性地支援政府需求

      • TPM 1.2 在可支援哪些演算法方面受到嚴格限制
      • TPM 2.0 可以透過 TCG 規格檔的次要更新來支援任意演算法

    • 跨實作的一致性

      • TPM 1.2 規格可讓廠商在選擇實作詳細數據時提供廣泛的緯度
      • TPM 2.0 會將大部分的行為標準化

  • UEFI 安全開機 具有 UEFI 韌體的裝置可以設定為只載入受信任的作業系統開機載入器。 安全開機不需要 TPM。

    最基本的保護是安全開機功能，這是 UEFI 2.2+ 架構的標準部分。 在具有傳統 BIOS 的電腦上，可以掌控開機程式的任何人都可以使用替代 OS 載入器來開機，並可能取得系統資源的存取權。 啟用安全開機時，您只能使用使用儲存在 UEFI 安全開機資料庫中的憑證簽署的 OS 載入器來開機。 當然，用來數字簽署 Windows OS 載入器的 Microsoft 憑證位於該存放區中，可讓 UEFI 在其安全策略中驗證憑證。 根據預設，必須在 Windows 硬體相容性計劃下通過 Windows 認證的所有電腦上啟用安全開機。

    安全開機是以 UEFI 韌體為基礎的功能，可讓您在開機時簽署和驗證重要的開機檔案和驅動程式。 安全開機會在開機時檢查 Windows 開機管理員、BCD 存放區、Windows OS 載入器檔案及其他開機關鍵 DLL 的簽章值，然後才允許系統在建置階段使用 OEM 所定義的原則完全開機到可用的操作系統。 安全開機可防止許多類型的開機型 rootkit、惡意代碼，以及其他針對 Windows 平臺的安全性相關攻擊。 安全開機可保護操作系統開機程式，無論是從本機硬碟、USB、PXE 或 DVD 開機，或開機到完整的 Windows 或 Windows 復原環境 (RE) 。 安全開機會驗證重要開機組件的簽章，以確認惡意活動不會危害它們，以保護 Windows 安裝的開機環境。 載入 Windows 核心檔案 (ntoskrnl.exe) 之後，安全開機保護就會結束。

    注意

    安全開機會保護平臺，直到載入 Windows 核心為止。 然後，ELAM 之類的保護就會接管。

  • 安全開機設定原則。 將安全開機功能延伸至重要的 Windows 設定。

    受保護組態資訊的範例包括保護 [停用執行位 (NX 選項) ，或確保無法啟用測試簽署原則 (程式代碼完整性) 。 此保護動作可確保在開機程式完成之後，可以信任計算機的二進位檔和組態。 安全開機設定原則會使用 UEFI 原則執行此保護動作。 這些原則的這些簽章的簽署方式，與操作系統二進位檔簽署以搭配安全開機使用的方式相同。

    安全開機設定原則必須由私鑰簽署，該私鑰對應至儲存在密鑰交換金鑰 (KEK) 清單中的其中一個公鑰。 Microsoft 證書頒發機構單位 (CA) 會出現在所有 Windows 認證安全開機系統的 KEK 清單中。 根據預設，由 Microsoft KEK 簽署的原則應適用於所有安全開機系統。 在套用已簽署的原則之前，BootMgr 必須先驗證 KEK 清單的簽章。 使用 Windows 時，預設的安全開機設定原則會內嵌在 bootmgr 中。

    開機載入器在載入 Windows 核心的數位簽章之前，會先對其進行驗證。 接著，Windows 核心會驗證 Windows 啟動程式的所有其他元件，包括開機驅動程式、啟動檔案和 ELAM 元件。 此步驟很重要，並藉由確認所有 Windows 開機組件都具有完整性且可受到信任，來保護開機程式的其餘部分。

  • 開機初期啟動的反惡意程式碼 (ELAM)。 ELAM 在所有驅動程式載入之前會先進行測試，並阻止未經核准的驅動程式載入。

    傳統反惡意代碼應用程式要等到載入開機驅動程序之後才會啟動，這可讓 rootkit 以驅動程式提供工作的機會。 ELAM 是舊版 Windows 中引進的 Windows 機制，可讓反惡意代碼軟體在開機順序中提早執行。 因此，反惡意代碼元件是第一個執行並控制其他開機驅動程式初始化的第三方元件，直到 Windows 操作系統運作為止。 當系統開始使用完整的運行時間環境 (網路存取、記憶體等) 時，就會載入功能完整的反惡意代碼軟體。

    ELAM 可以在所有非 Microsoft 開機驅動程式和應用程式之前載入 Microsoft 或非 Microsoft 反惡意代碼驅動程式，進而繼續安全開機和信任開機所建立的信任鏈結。 由於操作系統尚未啟動，而且因為 Windows 需要儘快開機，ELAM 有一個簡單的工作：檢查每個開機驅動程式，並判斷它是否在受信任的驅動程式清單中。 如果不受信任，Windows 將不會載入它。

    注意

    Windows Defender，Windows 中預設包含的 Microsoft 反惡意代碼軟體支援 ELAM;它可以取代為第三方反惡意代碼相容解決方案。 WdBoot.sys Windows Defender ELAM 驅動程式的名稱。 Windows Defender 使用其 ELAM 驅動程式，在下次重新啟動時復原對 Windows Defender 驅動程式所做的任何惡意變更。 這可防止核心模式惡意代碼在關機或重新啟動之前，持續變更 Windows Defender 的迷你篩選器驅動程式。

    ELAM 簽署的驅動程式會在任何其他第三方驅動程式或應用程式之前載入，這可讓反惡意程式碼軟體嘗試載入未簽署或不受信任的程式代碼，以偵測並封鎖任何竄改開機程式的嘗試。

    ELAM 驅動程式是小型驅動程式，具有小型原則資料庫，其範圍較窄，著重於在系統啟動時提早載入的驅動程式。 原則資料庫會儲存在也測量為 TPM 的登錄區中，以記錄 ELAM 驅動程式的作業參數。 ELAM 驅動程式必須由 Microsoft 簽署，且相關聯的憑證必須包含互補的 EKU (1.3.6.1.4.1.311.61.4.1) 。

  • 以虛擬化為基礎的安全性 (Hyper-V + 安全核心) 。 虛擬化型安全性是新的強制執行安全性界限，可讓您保護 Windows 的重要部分。

    虛擬化型安全性會將核心模式程式代碼完整性或敏感性公司網域認證等敏感性程式代碼與 Windows 操作系統的其餘部分隔離。 如需詳細資訊，請參閱 虛擬化型安全性 一節。

  • 受 Hypervisor 保護的程式代碼完整性 (HVCI) 。 受 Hypervisor 保護的程式代碼完整性是 Device Guard 的一項功能，可確保只允許執行符合 Device Guard 程式代碼完整性原則的驅動程式、可執行檔和 DLL。

    啟用並設定后，Windows 可以啟動 Hyper-V 虛擬化型安全性服務。 HVCI 可協助保護系統核心 (核心) 、特殊許可權驅動程式和系統防禦，例如反惡意代碼解決方案、防止惡意代碼在開機程式初期或啟動之後執行。

    HVCI 會使用虛擬化型安全性來隔離程式代碼完整性，核心記憶體成為可執行檔的唯一方法是透過程式代碼完整性驗證。 這種對驗證的相依性表示核心記憶體頁面永遠無法寫入，而且無法直接修改可執行檔 (W+X) 和可執行程式碼。

    注意

    以虛擬化為基礎的安全性執行內核模式程式代碼完整性的Device Guard裝置必須具有相容的驅動程式。 如需詳細資訊，請閱讀 Windows 中 Driver 與 Device Guard 的相容性 部落格文章。

    Device Guard 程式代碼完整性功能可讓組織控制受信任的程式代碼，以在 Windows 核心中執行，以及哪些應用程式已核准在使用者模式中執行。 其可使用原則進行設定。 Device Guard 程式代碼完整性原則是 Microsoft 建議您簽署的二進位檔。 簽署程式代碼完整性原則有助於防範具有系統管理員許可權嘗試修改或移除目前程序代碼完整性原則的惡意使用者。

  • Credential Guard。 Credential Guard 會使用硬體型認證隔離來保護公司認證。

    在 Windows 中，Credential Guard 旨在保護網域公司認證免於遭惡意代碼竊取和重複使用。 使用 Credential Guard，Windows 實作架構變更，基本上可防止目前形式的傳遞哈希 (PtH) 攻擊。

    此無攻擊狀態是使用 Hyper-V 和新的虛擬化型安全性功能來建立受保護的容器，其中信任的程式代碼和秘密會與 Windows 核心隔離。 這項成就表示即使 Windows 核心遭到入侵，攻擊者也無法讀取和擷取起始 PtH 攻擊所需的數據。 Credential Guard 會防止這個未經授權的存取，因為儲存秘密的記憶體無法再從一般 OS 存取，即使在內核模式中也一樣 ， Hypervisor 會控制可存取記憶體的人員。

  • 健康情況證明。 裝置的韌體會記錄開機程式，而 Windows 可以將它傳送至信任的伺服器，以檢查和評估裝置的健康情況。

    Windows 會測量 UEFI 韌體，並在開機程式期間載入每個 Windows 和反惡意代碼元件。 此外，系統會循序進行取用和測量，而不是一次全部。 當這些度量完成時，其值會以數位方式簽署並安全地儲存在 TPM 中，而且除非系統重設，否則無法變更。

    如需詳細資訊，請參閱 安全開機和測量開機：針對惡意代碼強化早期開機組件。

    在每次後續開機期間，都會測量相同的元件，以便根據預期的基準比較度量。 為了提高安全性，TPM 所測量的值可以簽署並傳輸至遠端伺服器，然後執行比較。 此程式稱為 遠端裝置健康情況證明，可讓伺服器驗證 Windows 裝置的健康情況狀態。

    雖然安全開機是主動式保護形式，但健康情況證明是一種回應式開機保護形式。 健康情況證明會在 Windows 中停用，並由反惡意代碼軟體或 MDM 廠商啟用。 不同於安全開機，健康情況證明不會停止開機程式，並在測量無法運作時進入補救。 但是使用條件式訪問控制，健康情況證明將有助於防止存取高價值資產。

虛擬式安全性

虛擬化型安全性為 Windows 提供新的信任界限，並使用 Hyper-V Hypervisor 技術來增強平台安全性。 虛擬化型安全性提供安全的執行環境，可 (trustlet) 執行特定的 Windows 信任程式代碼，以及保護敏感數據。

虛擬化型安全性有助於防範遭入侵的核心或具有系統管理員許可權的惡意使用者。 虛擬化型安全性並未嘗試防範實體攻擊者。

下列 Windows 服務受到虛擬化型安全性的保護：

  • Credential Guard (LSA 認證隔離) ：藉由讀取和傾印 lsass 記憶體的內容，防止發生傳遞哈希攻擊和企業認證竊取
  • Device Guard (Hyper-V 程式代碼完整性) ：Device Guard 會使用 Windows 中新的虛擬化型安全性，將程式代碼完整性服務與 Windows 核心本身隔離，讓服務使用由企業控制的原則所定義的簽章，協助判斷值得信任的專案。 實際上，程式代碼完整性服務會與 Windows Hypervisor 保護容器中的核心一起執行。
  • 其他隔離的服務：例如，在 Windows Server 2016 上，有一個 vTPM 功能可讓您在伺服器上) VM (加密的虛擬機。

注意

虛擬化型安全性僅適用於 Enterprise 版本。 虛擬化型安全性需要具有 UEFI (2.3.1 或更新版本) 且已啟用安全開機的裝置、已啟用虛擬化延伸模組和 SLAT 的 x64 處理器。 IOMMU，TPM 2.0。 和 對安全記憶體覆寫的支持是選擇性的，但建議使用。

下列架構是具有虛擬化型安全性的 Windows 高階檢視。

圖 5。

Credential Guard

在 Windows 中，啟用 Credential Guard 時，本地安全機構子系統服務 (lsass.exe) 在隔離的使用者模式中執行敏感性程式代碼，以協助保護數據免於在一般使用者模式下執行的惡意代碼。 此程式代碼執行可協助確保受保護的數據不會遭竊，並在遠端電腦上重複使用，以減輕許多 PtH 樣式的攻擊。

Credential Guard 會使用每個開機或持續性密鑰加密認證，以協助保護認證：

  • 每個開機金鑰 用於任何不需要持續性的記憶體內部認證。 這類認證的範例是 TGT) 工作話金鑰 (票證授與票證。 每次進行驗證時，此金鑰都會與金鑰發佈中心 (KDC) 交涉，並以每個開機密鑰進行保護。
  • 永續性金鑰或某些衍生金鑰可用來協助保護重新啟動後儲存和重載的專案。 這類保護適用於長期儲存，而且必須使用一致的密鑰來保護。 Credential Guard 會由登錄機碼啟動，然後使用 UEFI 變數啟用。 這項啟用是為了防止遠端修改組態而完成。 使用 UEFI 變數表示需要實體存取才能變更組態。 當 lsass.exe 偵測到已啟用認證隔離時，它會將 LsaIso.exe 繁衍為隔離的程式，以確保它在隔離的使用者模式下執行。 啟動 LsaIso.exe 會在初始化安全性支援提供者之前執行，這可確保安全模式支援例程在任何驗證開始之前都已就緒。

Device Guard

Device Guard 是 Windows 企業版的一項功能，可讓組織鎖定裝置，以協助防止裝置執行不受信任的軟體。 在此設定中，唯一允許執行的應用程式是組織信任的應用程式。

執行程序代碼的信任決策是使用 Hyper-V 程式代碼完整性來執行，該完整性是在虛擬化型安全性中執行，這是一個與一般 Windows 一起執行的 Hyper-V 保護容器。

Hyper-V 程式代碼完整性是一項功能，可在每次載入記憶體時驗證驅動程式或系統檔案的完整性。 程式代碼完整性會偵測未簽署的驅動程式或系統檔案是否正在載入核心，或系統檔案是否已由具有系統管理員許可權的使用者帳戶所執行的惡意軟體修改。 在以 x64 為基礎的 Windows 版本上，內核模式驅動程式必須經過數字簽署。

注意

與啟用Device Guard原則無關，Windows 驅動程式必須由 Microsoft 簽署，更具體地說，由 WHQL (Windows 硬體質量實驗室) 入口網站簽署。 此外，從 2015 年 10 月開始，WHQL 入口網站只會接受具有有效擴充驗證 (“EV”) 程式代碼簽署憑證的驅動程式提交，包括核心和使用者模式驅動程式提交。

使用Device Guard，組織現在可以定義自己的程式代碼完整性原則，以在執行 Windows Enterprise 的 x64 系統上使用。 組織能夠設定決定受信任執行項目的原則。 其中包括驅動程式和系統檔案，以及傳統型應用程式和腳本。 系統接著會鎖定，只執行組織信任的應用程式。

Device Guard 是 Windows 企業版的內建功能，可防止執行不必要的程式代碼和應用程式。 Device Guard 可以使用兩個規則動作來設定 - 允許和拒絕：

  • 允許 將應用程式的執行限制為允許的程式代碼或受信任發行者清單，並封鎖所有其他專案。
  • 拒絕 會封鎖特定應用程式的執行，以完成允許信任的發行者方法。

在撰寫本文時，根據 Microsoft 的最新研究，超過 90% 的惡意代碼完全未簽署。 因此，實作基本的 Device Guard 原則可以簡單且有效地協助封鎖惡意代碼。 事實上，Device Guard 有可能更進一步，也可以協助封鎖已簽署的惡意代碼。

Device Guard 必須規劃並設定為真正有效。 它不只是啟用或停用的保護。 Device Guard 是硬體安全性功能和軟體安全性功能的組合，在一起設定時，可以鎖定計算機，以協助確保最安全且最能抵禦的系統。

在 Windows 中，有三個不同的元件組成 Device Guard 解決方案：

  • 第一個部分是舊版 Windows 引進 的一組基本硬體安全性功能 。 用於硬體密碼編譯作業的 TPM 和具有新式韌體的 UEFI，以及安全開機，可讓您控制裝置在系統啟動時執行的內容。
  • 在硬體安全性功能之後，會有程序代碼完整性引擎。 在 Windows 中， 程式代碼完整性現在已完全可 設定，且現在位於隔離的使用者模式中，這是受虛擬化型安全性保護的記憶體一部分。
  • Device Guard 的最後一個部分是 管理性。 程序代碼完整性設定是透過特定 群組原則 物件、PowerShell Cmdlet 和 MDM 設定服務提供者公開， (CSP) 。

如需如何在企業中部署 Device Guard 的詳細資訊，請參閱 Device Guard 部署指南。

Device Guard 案例

如先前所述，Device Guard 是鎖定系統的強大方式。 Device Guard 不適合廣泛使用，可能不一定適用，但有一些高興趣的案例。

Device Guard 非常有用，適用於固定工作負載系統，例如收款機、kiosk 計算機、安全 管理員 工作站 (SAW) 或受管理良好的桌面。 Device Guard 與具有妥善定義軟體且預期執行且不會太頻繁變更的系統高度相關。 它也可以協助保護資訊工作者 (IW) 不只是 SAW，只要它們需要執行哪些專案是已知的，而且應用程式集不會每天變更。

SAW 是專為大幅降低惡意代碼入侵風險、網路釣魚攻擊、假名網站和 PtH 攻擊，以及其他安全性風險而建置的電腦。 雖然 SAW 無法視為這些攻擊的「銀項目符號」安全性解決方案，但這些類型的客戶端對於安全性進行分層、深入防禦的方法很有説明。

為了保護高價值資產，SAW 可用來對這些資產進行安全連線。

同樣地，在公司完全受控的工作站上，使用 Microsoft Configuration Manager、Intune 或任何第三方裝置管理等散發工具來安裝應用程式，則適用 Device Guard。 在該類型的案例中，組織非常瞭解一般使用者正在執行的軟體。

在通常允許使用者自行安裝軟體的公司、輕量管理的工作站上使用Device Guard可能會是一項挑戰。 當組織提供絕佳的彈性時，很難在強制模式中執行 Device Guard。 不過，Device Guard 可以在稽核模式中執行，在此情況下，事件記錄檔會包含違反 Device Guard 原則的任何二進位檔記錄。 在稽核模式中使用 Device Guard 時，組織可以取得使用者安裝和執行之驅動程式和應用程式的豐富數據。

您必須先使用 Microsoft 提供的工具來建立程式代碼完整性原則，才能從 Device Guard 中所包含的保護獲益，但原則可以使用一般管理工具部署，例如 群組原則。 程式代碼完整性原則是二進位編碼的 XML 檔，其中包含 Windows 使用者和內核模式的組態設定，以及 Windows 腳本主機的限制。 Device Guard 程式代碼完整性原則會限制哪些程式代碼可以在裝置上執行。

注意

Device Guard 原則可以在 Windows 中登入，這可為系統管理用戶變更或移除此原則提供額外的保護。

已簽署的 Device Guard 原則提供更強大的保護，可防止惡意的本機系統管理員嘗試破壞 Device Guard。

簽署原則時，原則的 GUID 會儲存在提供竄改保護的 UEFI 操作系統前安全變數中。 稍後更新 Device Guard 原則的唯一方法，是提供由相同簽署者所簽署的新版本原則，或是從指定為 Device Guard 原則一部分的簽署者到 UpdateSigner 區段。

簽署應用程式的重要性

在使用 Device Guard 的電腦上，Microsoft 建議從不帶正負號的應用程式可以執行但不受限制的世界移至只允許在 Windows 上執行已簽署和受信任程式代碼的世界。

使用 Windows 時，組織會透過 Microsoft Store 基礎結構，將企業營運 (LOB) 應用程式提供給組織成員。 更具體來說，LOB 應用程式將可在公用 Microsoft Store 內的私人市集中使用。 Microsoft Store 會簽署並散發通用 Windows 應用程式和傳統 Windows 應用程式。 所有從 Microsoft Store 下載的應用程式都會簽署。

在現今的組織中，許多LOB應用程式都未簽署。 程式代碼簽署經常被視為因各種原因而難以解決的問題，例如缺少程式代碼簽署專業知識。 即使程式代碼簽署是最佳做法，許多內部應用程式也不會簽署。

Windows 包含的工具可讓 IT 專業人員採用已封裝的應用程式，並透過程式執行這些應用程式，以建立更多可與現有應用程式一起散發的簽章。

為什麼仍然需要反惡意代碼軟體和裝置管理解決方案？

雖然允許清單機制有效率地確保只能執行受信任的應用程式，但無法防止受信任的 (入侵，但會因為惡意內容設計來惡意探索已知弱點而易受攻擊) 應用程式。 Device Guard 不會利用弱點來防止使用者模式惡意代碼執行。

弱點是軟體中的弱點，可能會讓攻擊者危害裝置的完整性、可用性或機密性。 某些最糟的弱點可讓攻擊者利用遭入侵的裝置，使其在使用者不知情的情況下執行惡意代碼。

通常會看到攻擊者散發特別製作的內容，以嘗試利用使用者模式軟體中的已知弱點，例如網頁瀏覽器 (及其外掛程式) 、Java 虛擬機、PDF 讀取器或文件編輯器。 目前，相較於裝載它們的操作系統和內核模式驅動程式，90% 探索到的弱點會影響使用者模式應用程式。

為了對抗這些威脅，修補是最有效的單一控制措施，反惡意代碼軟體會形成互補的防禦層。

大部分的應用程式軟體沒有更新本身的功能，因此即使軟體廠商發佈可修正弱點的更新，使用者可能不知道更新可用或如何取得它，因此仍然容易遭受攻擊。 組織仍然需要管理裝置並修補弱點。

MDM 解決方案正逐漸成為羽量型裝置管理技術。 Windows 擴充了 MDM 可用的管理功能。 Microsoft 已將其中一個重要功能新增至 Windows，就是 MDM 能夠從受控和已註冊的裝置取得強式裝置健康情況聲明。

裝置健康情況證明

裝置健康情況證明會使用 TPM，針對用來開機裝置的軟體鏈結，提供密碼編譯強式且可驗證的測量。

針對以 Windows 為基礎的裝置，Microsoft 引進新的公用 API，可讓 MDM 軟體存取稱為 Windows 健康情況證明服務的遠端證明服務。 健康情況證明結果除了其他元素之外，還可以根據裝置是否證明狀況良好，用來允許或拒絕網路、應用程式或服務的存取。

如需裝置健康情況證明的詳細資訊，請參閱 偵測狀況不良的 Windows 裝置一 節。

Windows 版本和授權需求

下表列出支援裝置健康情況證明服務的 Windows 版本：

Windows 專業版 Windows 企業版 Windows 專業教育版/SE Windows 教育版
是 是 是 是

裝置健康情況證明服務授權權利由下列授權授與：

Windows 專業版/專業教育版/SE Windows 企業版 E3 Windows 企業版 E5 Windows 教育版 A3 Windows 教育版 A5
是 是 是 是 是

如需 Windows 授權的詳細資訊，請參閱 Windows 授權概觀。

硬體需求

下表詳細說明虛擬式安全性服務和健康情況證明功能的硬體需求。 如需詳細資訊，請參閱 最低硬體需求。

硬體 動機
已啟用安全開機的 UEFI 2.3.1 或更新版本韌體 支援 UEFI 安全開機的必要專案。 UEFI 安全開機可確保裝置只會開機授權的程序代碼。 此外，必須遵循 Windows 系統硬體相容性規格中下列小節“System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby” 中的需求，支持平臺安全開機 (開機完整性)
必須啟用虛擬化擴充功能，例如 Intel VT-x、AMD-V 和 SLAT 支援虛擬化型安全性的必要專案。 注意： Device Guard 可在不使用虛擬化型安全性的情況下啟用。
X64 處理器 支援使用 Windows Hypervisor 之虛擬化型安全性的必要專案。 只有 x64 處理器 (才支援 Hyper-V，x86) 則不支援。 直接記憶體存取 (DMA) 保護可以啟用以提供額外的記憶體保護，但需要處理器包含 DMA 保護技術。
IOMMU，例如 Intel VT-d，AMD-Vi Windows 中的 IOMMU 支援可增強系統對 DMA 攻擊的復原能力。
信賴平台模組 (TPM) 支援健康情況證明的必要專案，以及虛擬化型安全性之其他密鑰保護的必要專案。 支援 TPM 2.0。 從 Windows 10 1607 版 (RS1 開始新增 TPM 1.2 的支援)

本節提供 Windows 中數個密切相關控件的相關信息。 多層式防禦和深度方法有助於在開機順序期間消除低階惡意代碼。 虛擬化型安全性是基本的操作系統架構變更，可新增安全性界限。 Device Guard 和 Credential Guard 分別有助於封鎖不受信任的程式代碼，並防止公司網域認證遭到竊取和重複使用。 本節也簡短討論管理裝置和修補弱點的重要性。 所有這些技術都可以用來強化和鎖定裝置，同時限制攻擊者危害裝置的風險。

偵測狀況不良的 Windows 裝置

從今天起，許多組織只有在通過各種檢查之後，才會將裝置視為符合公司原則，例如，操作系統處於正確狀態、設定正確且已啟用安全性保護。 可惜的是，在現今的系統中，這種形式的報告並不完全可靠，因為惡意代碼可能會詐騙有關系統健康情況的軟體聲明。 rootkit 或類似的低層級惡意探索，可能會向傳統合規性工具回報狀況不良的狀態。

rootkit 的最大挑戰是客戶端無法偵測到它們。 因為它們會在反惡意代碼軟體之前啟動，而且具有系統層級許可權，因此可以在繼續存取系統資源時完全自定義。 因此，即使執行反惡意代碼軟體，受 rootkit 感染的傳統電腦看起來仍狀況良好。

如先前所述，Windows 的健康情況證明功能會使用 TPM 硬體元件，安全地記錄每個開機相關元件的度量，包括韌體、Windows 核心，甚至是早期開機驅動程式。 由於健康情況證明使用 TPM 的硬體型安全性功能，因此所有開機測量元件的記錄檔仍無法受到任何惡意代碼的控制。

在裝置證明受信任的開機狀態之後，它們可以證明它們未執行低階惡意代碼，可能會詐騙後續的合規性檢查。 TPM 型健康情況證明為包含高價值數據的資產提供可靠的信任錨點。

裝置健康情況的概念為何？

若要了解裝置健康情況的概念，請務必瞭解 IT 專業人員為了防止惡意代碼外泄所採取的傳統措施。 惡意代碼控制技術高度著重於防止安裝和散發。

不過，使用傳統惡意代碼防護技術，例如反惡意代碼軟體或修補解決方案，會為IT專業人員帶來一組新的問題：監視和控制存取組織資源之裝置合規性的能力。

裝置合規性的定義會根據組織安裝的反惡意代碼、裝置組態設定、修補程式管理基準和其他安全性需求而有所不同。 但裝置的健康情況是整體裝置合規性原則的一部分。

裝置的健康情況不是二進位檔，且取決於組織的安全性實作。 健康情況證明服務會使用可信任的硬體 TPM，將資訊提供給在裝置開機期間啟用安全性功能的 MDM。

但健康情況證明只會提供資訊，這就是為什麼需要 MDM 解決方案來採取並強制執行決策的原因。

遠端裝置健康情況證明

在 Windows 中，健康情況證明是指一項功能，其中在開機程式期間產生的測量開機數據會傳送至由 Microsoft 操作的遠端裝置健康情況證明服務。

這種方法是 Windows 型裝置最安全的方法，可在安全性防禦關閉時偵測。 在開機程式期間，TCG 記錄檔和 PCR 的值會傳送至遠端 Microsoft 雲端服務。 然後健康情況證明服務會檢查記錄，以判斷裝置上已發生哪些變更。

MDM 之類的信賴憑證者可以檢查遠端健康情況證明服務所產生的報告。

注意

若要使用 Windows 的健康情況證明功能，裝置必須配備離散或韌體 TPM。 任何特定版本的 Windows 都沒有任何限制。

Windows 支援健康情況證明案例，方法是允許應用程式存取基礎健康情況證明設定服務提供者 (CSP) ，讓應用程式可以要求健康情況證明令牌。 反惡意代碼或 MDM 代理程式隨時可以在本機檢查開機順序的測量。

與 MDM 結合的遠端裝置健康情況證明提供硬體根方法，可報告目前的安全性狀態並偵測任何變更，而不需要信任在系統上執行的軟體。

在裝置上執行惡意代碼的情況下，必須使用遠端伺服器。 如果裝置上有rootkit，反惡意代碼就不再可靠，而且其行為可能受到在啟動序列早期執行的惡意代碼所危害。 這是因為使用安全開機和 Device Guard 來控制在開機順序期間載入的程式代碼非常重要。

反惡意代碼軟體可以搜尋以判斷開機順序是否包含任何惡意代碼的徵兆，例如 rootkit。 它也可以將 TCG 記錄和 PCR 傳送至遠端健康情況證明伺服器，以提供測量元件與驗證元件之間的區隔。

健康情況證明會記錄在開機程式期間，各種 TPM 平台組態緩存器 (PCR) 和 TCG 記錄中的度量。

圖 6.

當您啟動配備 TPM 的裝置時，會執行不同元件的測量。 這些元件包括韌體、UEFI 驅動程式、CPU 微碼，以及類型為開機啟動的所有 Windows 驅動程式。 原始度量會儲存在 TPM PCR 快取器中，而 TCG 記錄中提供所有事件 (可執行路徑、授權單位認證等) 的詳細數據。

圖 7.

健康情況證明程序的運作方式如下：

  1. 系統會測量硬體開機組件。
  2. 系統會測量操作系統開機組件。
  3. 如果已啟用 Device Guard，則會測量目前的 Device Guard 原則。
  4. 已測量 Windows 核心。
  5. 防病毒軟體會作為第一個內核模式驅動程序啟動。
  6. 系統會測量開機啟動驅動程式。
  7. 透過 MDM 代理程式的 MDM 伺服器會使用健康情況證明 CSP 發出健康情況檢查命令。
  8. 開機測量會由健康情況證明服務進行驗證

注意

根據預設，最後 100 個系統開機記錄和所有相關聯的繼續記錄會封存在 %SystemRoot%\logs\measuredboot 資料夾中。 您可以使用 HKLM\SYSTEM\CurrentControlSet\Services\TPM 機碼下的登錄REG_DWORD值 PlatformLogRetention 來設定保留的記錄數目。 值 0 會關閉記錄封存，而 值為 0xffffffff 會保留所有記錄。

下列程式描述如何將健康情況開機測量傳送至健康情況證明服務：

  1. 用戶端 (具有 TPM 的 Windows 裝置) 使用遠端裝置健康情況證明服務來起始要求。 由於健康情況證明伺服器預期為 Microsoft 雲端服務，因此 URI 已在用戶端中預先布建。

  2. 用戶端接著會傳送 TCG 記錄檔、AIK 簽署數據 (PCR 值、開機計數器) 和 AIK 憑證資訊。

  3. 遠端裝置健康情況證明服務，然後：

    1. 確認 AIK 憑證是由已知且受信任的 CA 所簽發，且憑證有效且未撤銷。
    2. 確認 PCR 引號上的簽章正確且與 TCG 記錄值一致。
    3. 剖析 TCG 記錄中的屬性。
    4. 發出包含健康情況資訊、AIK 資訊和開機計數器資訊的裝置健康情況令牌。 健康情況令牌也包含有效的發行時間。 裝置健康情況令牌會經過加密和簽署，這表示資訊會受到保護，且只能供發出健康情況證明服務存取。

  4. 用戶端會將健康情況加密的 Blob 儲存在其本地存儲中。 裝置健康情況令牌包含裝置健康情況狀態、Windows AIK) (裝置識別碼，以及開機計數器。

圖 8。

裝置健康情況證明元件

裝置健康情況證明解決方案包含 TPM、健康情況證明 CSP 和 Windows 健康情況證明服務等不同元件。 本節將說明這些元件。

信賴平台模組

本節說明包含系統設定數據) 、簽署金鑰 (EK) (做為 TPM) 身分識別卡的 PCR (、可保護金鑰) 的 SRK (，以及可報告平臺狀態) 的 AIK (如何用於健康情況證明報告。

以簡化的方式，TPM 是資源有限的被動元件。 它可以計算隨機數、RSA 金鑰、解密簡短數據、儲存開機裝置時所用的哈希。

TPM 會併入單一元件中：

  • RSA 2048 位金鑰產生器
  • 隨機數產生器
  • 用於儲存 EK、SRK 和 AIK 金鑰的非迴旋記憶體
  • 加密、解密和簽署加密的密碼編譯引擎
  • 儲存 PCR 和 RSA 金鑰的揮發性記憶體

簽署金鑰

TPM 具有稱為簽署密鑰的內嵌唯一密碼編譯密鑰。 TPM 簽署金鑰是一組非對稱金鑰， (RSA 大小 2048 位) 。

簽署金鑰公鑰用於傳送安全敏感性參數，例如當取得包含定義擁有者密碼哈希的 TPM 時。 建立 AIK 之類的次要金鑰時，會使用 EK 私鑰。

簽署金鑰可作為 TPM 的身分識別卡。 如需詳細資訊，請 參閱瞭解 TPM 簽署金鑰。

簽署金鑰通常會伴隨一或兩個數字憑證：

  • 一個憑證是由 TPM 製造商所產生，稱為 簽署憑證。 簽署憑證可用來證明 TPM (的真實性，例如，它是由特定晶片製造商所製造的實際 TPM，) 到本機進程、應用程式或雲端服務。 簽署憑證會在製造期間建立，或第一次透過與在線服務通訊來初始化 TPM。
  • 另一個憑證是由平臺建立器所產生，並稱為 平台憑證 ，表示特定 TPM 已與特定裝置整合。 對於使用 Intel 或 Qualcomm 所產生之韌體型 TPM 的特定裝置，在 Windows 的 OOBE 期間初始化 TPM 時，會建立簽署憑證。

注意

安全開機會保護平臺，直到載入 Windows 核心為止。 接著，信任開機、Hyper-V 程式代碼完整性和 ELAM 等保護會接管。 使用 Intel TPM 或 Qualcomm TPM 的裝置會從已建立晶片的製造商在線取得已簽署的憑證，然後將已簽署的憑證儲存在 TPM 記憶體中。 若要讓作業成功，如果您要篩選來自用戶端裝置的因特網存取，您必須授權下列 URL：

  • 針對 Intel 韌體 TPM： https://ekop.intel.com/ekcertservice
  • 針對 Qualcomm 韌體 TPM： https://ekcert.spserv.microsoft.com/

證明身分識別金鑰

因為每個裝置的簽署憑證都是唯一的，而且不會變更，所以其使用方式可能會顯示隱私權考慮，因為理論上可以追蹤特定裝置。 為了避免此隱私權問題，Windows 會根據簽署憑證發出衍生證明錨點。 此中繼金鑰可證明為簽署密鑰，是 AIK) (證明身分識別密鑰，而對應的憑證稱為 AIK 憑證。 此 AIK 憑證是由 Microsoft 雲端服務所發行。

注意

裝置必須與 Microsoft Cloud CA 服務等第三方服務一起布建 AIK 憑證，才能使用 TPM 證明函式報告其健康情況。 布建之後，AIK 私鑰可用來報告平台設定。 Windows 會在平台記錄狀態 (上建立簽章，並使用 AIK 在每個開機時) 單純計數器值。

AIK 是非對稱 (公用/私用) 密鑰組，用來替代 EK 作為 TPM 的身分識別，以供隱私權使用。 AIK 的私人部分永遠不會在 TPM 外部顯示或使用，而且只能在 TPM 內用於一組有限的作業。 此外，它只能用於簽署，而且只能用於有限的 TPM 定義作業。

Windows 會建立受 TPM 保護的 AIK，如果有的話，也就是 2048 位 RSA 簽署密鑰。 Microsoft 正在裝載稱為 Microsoft Cloud CA 的雲端服務，以密碼編譯方式建立其正在與實際 TPM 通訊，且 TPM 擁有呈現的 AIK。 在 Microsoft 雲端 CA 服務建立這些事實之後，它會向以 Windows 為基礎的裝置發出 AIK 憑證。

許多將升級至 Windows 10 的現有裝置都不會有 TPM，或 TPM 不會包含簽署憑證。 為了容納這些裝置，Windows 10 允許發行 AIK 憑證，而不需要簽署憑證。 這類 AIK 憑證不是由 Microsoft Cloud CA 簽發。 這些憑證不像在製造期間刻錄到裝置的簽署憑證一樣值得信任，但它可提供進階案例的相容性，例如 Windows Hello 企業版 不含 TPM。

在發行的 AIK 憑證中，會新增特殊的 OID，以證明在證明程式期間使用了簽署憑證。 信賴憑證者可以使用這項資訊來決定是否拒絕使用 AIK 憑證證明的裝置，而不需簽署憑證或接受這些憑證。 另一個案例可能是不允許從不受簽署憑證支援的 AIK 憑證所證明的裝置存取高價值資產。

儲存器根金鑰

SRK) (儲存器根金鑰也是 RSA (非對稱密鑰組，其長度至少為 2048 位) 。 SRK 具有主要角色，並用來保護 TPM 金鑰，因此沒有 TPM 就無法使用這些金鑰。 取得 TPM 的擁有權時，會建立 SRK 金鑰。

平台組態緩存器

TPM 包含一組緩存器，其設計目的是要提供已開機之軟體和系統狀態的密碼編譯表示法。 這些快取器稱為平臺設定緩存器 (PCR) 。

開機順序的測量是以 PCR 和 TCG 記錄為基礎。 若要建立靜態信任根目錄，當裝置啟動時，裝置必須能夠在執行之前測量韌體程序代碼。 在此情況下，會從開機執行測量核心根信任 (CRTM) 、計算韌體的哈希，然後展開緩存器 PCR[0] 並傳輸執行至韌體。

當平臺開機時，PCR 會設定為零，而韌體會啟動平臺來測量開機鏈結中的元件，並在 PCR 中記錄度量。 一般而言，開機組件會採用要執行之下一個元件的哈希，並在 PCR 中記錄度量。 啟動測量鏈結的初始元件是隱含信任的。 此元件為CRTM。 平臺製造商必須有CRTM的安全更新程式，或不允許更新。 PCR 會記錄已測量元件的累計哈希。

PCR 本身的值很難解譯 (它只是哈希值) ，但平臺通常會保留記錄檔，其中包含已測量的詳細數據，而 PCR 只會確保記錄檔並未遭到竄改。 記錄稱為 TCG 記錄。 每次擴充緩存器 PCR 時，都會將專案新增至 TCG 記錄檔。 因此，在整個開機程式中，會在 TCG 記錄中建立可執行程式碼和組態數據的追蹤。

TPM 布建

若要讓 Windows 裝置的 TPM 可供使用，必須先布建它。 布建的程式會根據 TPM 版本而有所不同，但成功時，會導致 TPM 可供使用，且擁有者授權數據 (ownerAuth) ，以供儲存在登錄本機的 TPM 使用。

布建 TPM 時，Windows 會先嘗試判斷 EK 和本機儲存的 ownerAuth 值，方法是查看下列位置的登錄： HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement

在布建程式期間，可能需要重新啟動裝置。

Get-TpmEndorsementKeyInfo PowerShell Cmdlet 可以搭配系統管理許可權使用，以取得 TPM 簽署密鑰和憑證的相關信息。

如果 TPM 擁有權未知，但 EK 存在，用戶端連結庫會布建 TPM，並在原則允許將 SRK 公用部分儲存在下列位置時，將產生的 ownerAuth 值儲存到登錄中：HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\管理員\SRKPub

在布建程式中，Windows 會使用 TPM 建立 AIK。 執行此作業時，產生的 AIK 公用部分會儲存在登錄中的下列位置： HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub

注意

若要布建 AIK 憑證並篩選因特網存取，您必須授權下列通配符 URL： https://\*.microsoftaik.azure.net

Windows 健康情況證明 CSP

Windows 包含組態服務提供者 (CSP) 專門用來與健康情況證明功能互動。 CSP 是插入 Windows MDM 用戶端的元件，並提供 MDM 伺服器如何設定及管理 Windows 裝置的已發佈通訊協定。 管理通訊協定會以樹狀結構表示，可指定為 URI，其中包含要在 URI 上執行的函式，例如 “get”、“set”、“delete” 等等。

下列清單是 Windows 健康情況證明 CSP 所執行的函式：

  • 收集用來驗證裝置健康情況狀態的數據
  • 將數據轉送至健康情況證明服務
  • 布建從健康情況證明服務接收到的健全狀況證明憑證
  • 在要求時，將健康情況證明憑證 (從健康情況證明服務收到) 和相關的運行時間信息轉送至 MDM 伺服器進行驗證

在健康情況證明會話期間，健康情況證明 CSP 會使用安全通道，將開機期間測量的 TCG 記錄和 PCR 值轉送至健康情況證明服務。

當 MDM 伺服器驗證裝置是否已向健康情況證明服務證明時，系統會提供一組有關該裝置開機方式的語句和宣告，並保證裝置在證明其健康情況的時間和 MDM 伺服器驗證該裝置的時間之間不會重新啟動。

Windows 健康情況證明服務

Windows 健康情況證明服務的角色基本上是評估一組健康情況數據， (TCG 記錄和 PCR 值) 、根據可用的健康情況數據) (一系列偵測，以及產生加密的健康情況 Blob 或產生 MDM 伺服器的報告。

注意

裝置和 MDM 伺服器都必須能夠在埠 443 上使用 TCP 通訊協定存取 has.spserv.microsoft.com (HTTPS) 。

檢查 TPM 證明和相關聯的記錄是否有效，需要執行數個步驟：

  1. 首先，伺服器必須檢查報表是否已由 可信任的 AIK 簽署。 這項驗證可能是藉由檢查 AIK 的公用部分是否列在資產資料庫中，或可能是已檢查憑證來完成。
  2. 核取金鑰之後，應該檢查帶正負號的證明 (引號結構) ，以查看其是否 為 PCR 值的有效簽章。
  3. 接下來，應該檢查記錄，以確保它們符合所報告的 PCR 值。
  4. 最後，MDM 解決方案應該檢查記錄本身，以查看它們是否代表 已知或有效的安全性設定。 例如，簡單的檢查可能是要查看所測量的早期 OS 元件是否已知良好、ELAM 驅動程式是否如預期般，以及 ELAM 驅動程式原則檔案是否為最新狀態。 如果所有這些檢查都成功，則可以發出證明語句，以便稍後用來判斷是否應該將資源的存取權授與用戶端。

健康情況證明服務會提供下列有關裝置健康情況的 MDM 解決方案資訊：

  • 安全開機啟用
  • 開機和核心偵錯啟用
  • BitLocker 啟用狀態
  • 已啟用 VSM
  • 已簽署或未簽署的 Device Guard 程式代碼完整性原則測量
  • 已載入 ELAM
  • 安全模式開機， DEP 啟用， 測試簽署啟用
  • 已使用受信任的簽署憑證布建裝置 TPM

如需度量的完整性，請參閱 健康情況證明 CSP。

下列清單顯示一些可回報給 Windows 裝置 MDM 的重要專案：

  • PCR0 度量
  • 已啟用安全開機
  • 安全開機資料庫符合預期
  • 安全開機 dbx 是最新的
  • 必須符合安全開機原則 GUID
  • 已啟用 BitLocker
  • 已啟用虛擬化型安全性
  • 已載入 ELAM
  • 程式代碼完整性版本是最新的
  • 必須符合程式代碼完整性原則哈希

使用 MDM 和健康情況證明服務

為了使裝置健康情況相關，MDM 解決方案會評估裝置健康情況報告，並設定為組織的裝置健康情況需求。

使用 MDM 和健康情況證明服務的解決方案包含三個主要部分：

  1. 已啟用健康情況證明的裝置。 這項啟用會在註冊 MDM 提供者時完成， (健康情況證明預設會停用) 。

  2. 啟用此服務之後，每次開機之後，裝置都會將健康情況測量傳送至 Microsoft 所裝載的健康情況證明服務，並會收到健康情況證明 Blob 作為傳回。

  3. 在這個周期之後的任何時間點，MDM 伺服器都可以向裝置要求健康情況證明 Blob，並要求健康情況證明服務解密內容，並驗證其是否已通過證明。

    圖 9。

Windows 裝置、健康情況證明服務和 MDM 之間的互動可以執行，如下所示：

  1. 用戶端會起始與 MDM 伺服器的工作階段。 MDM 伺服器的 URI 會是起始要求之用戶端應用程式的一部分。 目前 MDM 伺服器可以使用適當的 CSP URI 來要求健康情況證明數據。

  2. MDM 伺服器會指定 nonce 以及要求。

  3. 用戶端接著會傳送 AIK 引號 nonce + 開機計數器和健康情況 Blob 資訊。 此健康情況 Blob 會使用只有健康情況證明服務可以解密的健康情況證明服務公鑰來加密。

  4. MDM 伺服器：

    1. 驗證 nonce 是否如預期般。
    2. 將引號數據、nonce 和加密的健康情況 Blob 傳遞至健康情況證明服務伺服器。

  5. 健康情況證明服務：

    1. 解密健康情況 Blob。
    2. 使用健康情況 Blob 中的 AIK，並符合健康情況 Blob 中的值，確認引號中的開機計數器正確無誤。
    3. 確認 nonce 符合引號和從 MDM 傳遞的 nonce。
    4. 因為開機計數器和 nonce 是以健康情況 Blob 中的 AIK 加上引號，所以也會證明裝置與已產生健康情況 Blob 的裝置相同。
    5. 將數據傳送回 MDM 伺服器，包括健康情況參數、有效性等等。

注意

MDM 伺服器 (信賴憑證者) 永遠不會自行執行引號或開機計數器驗證。 它會取得已) 加密的引號數據和健康情況 Blob (，並將數據傳送至健康情況證明服務進行驗證。 如此一來，MDM 就永遠看不到 AIK，因而解決隱私權問題。

設定裝置合規性需求的第一個步驟，是確保偵測到不符合健康情況和合規性需求的已註冊裝置，並由 MDM 解決方案強制執行動作。

嘗試連線到資源的裝置必須評估其健康情況，才能偵測並報告狀況不良和不符合規範的裝置。 若要完全有效率，端對端安全性解決方案必須對狀況不良的裝置造成後果，例如對高價值資產的存取。 造成裝置狀況不良的原因是條件式訪問控制的目的，如下一節所述。

在授與存取權之前控制 Windows 裝置的安全性

在大部分情況下，現今的訪問控制技術著重於確保適當的人員能夠存取正確的資源。 如果使用者可以進行驗證，他們可以使用組織IT人員和系統幾乎不知道的裝置來存取資源。 或許有一些檢查，例如確保裝置在提供電子郵件存取權之前已加密，但如果裝置受到惡意代碼感染，該怎麼辦？

遠端裝置健康情況證明程式會使用測量的開機數據來驗證裝置的健康情況狀態。 裝置的健康情況接著可供 MDM 解決方案使用，例如 Intune。

注意

如需 Intune 和 Windows 功能支援的最新資訊，請參閱 Microsoft Intune 的新功能。

下圖顯示健康情況證明服務應該如何與 Microsoft 的雲端式 Intune MDM 服務搭配運作。

圖 10。

然後，MDM 解決方案可以使用健全狀況狀態語句，並結合客戶端原則，讓條件式存取能夠根據裝置證明其無惡意代碼、其反惡意代碼系統正常運作且最新狀態、防火牆正在執行，以及裝置修補狀態符合規範，來將其帶到下一個層級。

最後，拒絕存取無法證明其狀況良好的端點，即可保護資源。 需要存取組織資源的 BYOD 裝置需要這項功能。

Windows 中 MDM 的內建支援

Windows 有一個 MDM 用戶端，隨附於作業系統中。 此 MDM 用戶端可讓 MDM 伺服器管理以 Windows 為基礎的裝置，而不需要個別的代理程式。

非 Microsoft MDM 伺服器支援

非 Microsoft MDM 伺服器可以使用 MDM 通訊協定來管理 Windows。 內建管理客戶端能夠與支援 OMA-DM 通訊協定的相容伺服器通訊，以執行企業管理工作。 如需詳細資訊，請參閱 Microsoft Entra 與 MDM 整合。

注意

MDM 伺服器不需要建立或下載用戶端來管理 Windows。 如需詳細資訊，請 參閱行動裝置管理。

第三方 MDM 伺服器在註冊時會有相同的一致第一方用戶體驗，這也可為 Windows 使用者提供簡易性。

由第三方 MDM 管理 Windows Defender

此管理基礎結構可讓 IT 專業人員使用支援 MDM 的產品，例如 Intune、管理 Windows 裝置上的健康情況證明、Device Guard 或 Windows Defender，包括未加入網域的 BYOD。 IT 專業人員將能夠在下層操作系統上使用 Intune Endpoint Protection 的 Intune，來管理和設定他們熟悉的所有動作和設定。 目前僅透過 群組原則 管理已加入網域之裝置的系統管理員，會發現使用 MDM 輕鬆轉換為管理以 Windows 為基礎的裝置，因為這兩種機制會共用許多設定和動作。

如需如何使用 MDM 解決方案管理 Windows 安全性和系統設定的詳細資訊，請參閱 Windows 裝置的自定義 URI 設定。

條件式訪問控制

在大部分的平臺上，Microsoft Entra 裝置註冊會在註冊期間自動進行。 MDM 解決方案會將裝置狀態寫入 Microsoft Entra ID，然後由 Office 365 (讀取，或由下次客戶端嘗試存取 Office 365 相容工作負載時，與 Microsoft Entra ID) 互動的任何授權 Windows 應用程式讀取。

如果裝置未註冊，使用者會收到一則訊息，其中包含如何註冊 (也稱為註冊) 。 如果裝置不符合規範，使用者會收到不同的訊息，將它們重新導向至 MDM 入口網站，讓他們可以在其中取得合規性問題及其解決方式的詳細資訊。

Microsoft Entra ID 驗證使用者和裝置，MDM 會管理合規性和條件式存取原則，而健康情況證明服務會以證明方式報告裝置的健康情況。

圖 11。

Office 365 條件式訪問控制

Microsoft Entra ID 會強制執行條件式存取原則，以保護對 Office 365 服務的存取。 租用戶系統管理員可以建立條件式存取原則，以封鎖不符合規範裝置上的使用者存取 Office 365 服務。 用戶必須符合公司的裝置原則，才能將存取權授與服務。 或者，系統管理員也可以建立原則，要求用戶只註冊其裝置，才能存取 Office 365 服務。 原則可以套用至組織的所有使用者，或限制為少數目標組，並隨著時間增強以包含更多目標組。

當使用者從支援的裝置平臺要求存取 Office 365 服務時，Microsoft Entra 驗證用戶啟動要求的使用者和裝置;而且只有在使用者符合服務的原則集合時，才會授與服務的存取權。 未註冊其裝置的用戶會獲得補救指示，說明如何註冊並符合公司 Office 365 服務的存取規範。

當用戶註冊時，裝置會向 Microsoft Entra ID 註冊，並使用相容的 MDM 解決方案註冊，例如 Intune。

注意

Microsoft 正與第三方 MDM ISV 合作，以支援自動化的 MDM 註冊和原則型存取檢查。 Windows、Microsoft Entra ID 和 Microsoft Intune：由雲端提供技術的自動 MDM 註冊！ 部落格文章說明使用 Microsoft Entra ID 和 Intune 開啟自動 MDM 註冊的步驟。

當使用者成功註冊裝置時，裝置會變成受信任。 Microsoft Entra ID 提供單一登錄來存取公司應用程式，並強制執行條件式存取原則，不僅會在使用者第一次要求存取權時，每次使用者要求更新存取權時，授與服務的存取權。

當登入認證變更、裝置遺失/遭竊，或在要求更新時不符合合規性原則時，將會拒絕使用者存取服務。

根據員工用來存取 Exchange Online 的電子郵件應用程式類型，建立安全存取電子郵件的路徑可能稍有不同。 不過，主要元件：Microsoft Entra ID、Office 365/Exchange Online 和 Intune 相同。 IT 體驗和用戶體驗也很類似。

圖 12。

嘗試存取 Office 365 的用戶端將會針對下列屬性進行評估：

  • 裝置是否由 MDM 管理？
  • 裝置是否向 Microsoft Entra ID 註冊？
  • 裝置是否符合規範？

若要達到符合規範的狀態，以 Windows 為基礎的裝置必須：

  • 使用 MDM 解決方案註冊。
  • 向 Microsoft Entra ID 註冊。
  • 符合 MDM 解決方案所設定的裝置原則。

注意

目前，條件式存取原則會選擇性地在iOS和Android裝置上的用戶上強制執行。 如需詳細資訊，請參閱 Microsoft Entra ID、Microsoft Intune 和 Windows - 使用雲端將企業行動力現代化！ 部落格文章。

雲端和內部部署應用程式條件式訪問控制

條件式訪問控制是內建於 Microsoft Entra ID 的強大原則評估引擎。 它可讓 IT 專業人員輕鬆地建立 Office 365 以外的存取規則，以評估使用者登入的內容，以即時決定應該允許他們存取的應用程式。

IT 專業人員可以為受 Microsoft Entra ID 甚至內部部署應用程式保護的雲端 SaaS 應用程式設定條件式訪問控制原則。 Microsoft Entra ID 中的存取規則會使用條件式存取引擎來檢查相容 MDM 解決方案所報告的裝置健康情況和合規性狀態，例如 Intune，以判斷是否允許存取。

如需條件式存取的詳細資訊，請參閱適用於 SaaS 應用程式的 Azure 條件式 Access 預覽版。

注意

條件式訪問控制是 #D4ABEC79A7DC74B1387FA294FAAD06396 P1 或 P2 功能，也可在 EMS 中使用。 如果您沒有 Microsoft Entra ID P1 或 P2 訂用帳戶，您可以從 Microsoft Azure 網站取得試用版。

對於內部部署應用程式，有兩個選項可根據裝置的合規性狀態來啟用條件式訪問控制：

  • 針對透過 Microsoft Entra 應用程式 Proxy 發佈的內部部署應用程式，您可以設定條件式訪問控制原則，就像針對雲端應用程式一樣。 如需詳細資訊，請參閱使用 Microsoft Entra 應用程式 Proxy 發佈遠端使用者的內部部署應用程式。
  • 此外，Microsoft Entra Connect 會將裝置合規性資訊從 Microsoft Entra ID 同步至內部部署 AD。 Windows Server 2016 上的ADFS將支援以裝置合規性狀態為基礎的條件式訪問控制。 IT 專業人員會在ADFS中設定條件式存取控制原則，以使用相容 MDM 解決方案所報告的裝置合規性狀態來保護內部部署應用程式。

圖 13。

下列程序說明 Microsoft Entra 條件式存取的運作方式：

  1. 用戶已透過工作場所存取/Azure AD Join 向 MDM 註冊，這會向 Microsoft Entra ID 註冊裝置。
  2. 當裝置從休眠開機或繼續時，會觸發工作 「Tpm-HASCertRetr」 在背景要求健康情況證明 Blob。 裝置會將 TPM 開機測量傳送至健康情況證明服務。
  3. 健康情況證明服務會驗證裝置狀態，並根據健康情況狀態將加密的 Blob 簽發給裝置，如有任何) ，則會提供失敗檢查 (的詳細數據。
  4. 使用者登入且 MDM 代理程式會連絡 Intune/MDM 伺服器。
  5. 如果有可用，MDM 伺服器會向下推送新的原則，並查詢健康情況 Blob 狀態和其他清查狀態。
  6. 裝置會傳送先前取得的健康情況證明 Blob，以及 Intune/MDM 伺服器要求的其他狀態清查值。
  7. Intune/MDM 伺服器會將健康情況證明 Blob 傳送至要驗證的健康情況證明服務。
  8. 健康情況證明服務會驗證傳送健康情況證明 Blob 的裝置狀況良好，並將此結果傳回 Intune/MDM 伺服器。
  9. Intune/MDM 伺服器會根據裝置的合規性和查詢的清查/健康情況證明狀態來評估合規性。
  10. Intune/MDM 伺服器會針對 Microsoft Entra ID 中的裝置物件更新合規性狀態。
  11. 用戶開啟應用程式，嘗試存取公司受控資產。
  12. Microsoft Entra ID 中的合規性宣告所限制的存取權。
  13. 如果裝置符合規範且用戶獲得授權，則會產生存取令牌。
  14. 用戶可以存取公司管理的資產。

如需 Microsoft Entra 加入的詳細資訊，請參閱 Microsoft Entra ID & Windows： Better Together for Work or School，這是一份白皮書。

條件式訪問控制是許多組織和IT專業人員可能不知道且應該知道的主題。 當與條件式存取引擎搭配使用時，描述使用者、裝置、合規性和存取內容的不同屬性功能強大。 條件式訪問控制是協助組織保護其環境的重要步驟。

重點和摘要

下列清單包含改善任何組織安全性狀態的高階重點。 不過，本節中提供的一些重點不應解譯為完整的安全性最佳做法清單。

  • 了解沒有 100% 安全的解決方案

    如果具有惡意意圖的已判定敵人取得裝置的實體存取權，他們最終可能會突破其安全性層級並加以控制。

  • 使用健康情況證明搭配 MDM 解決方案

    嘗試連線到高價值資產的裝置必須評估其健康情況，才能偵測、報告及最終封鎖狀況不良和不符合規範的裝置。

  • 使用 Credential Guard

    Credential Guard 是一項功能，可大幅協助保護公司網域認證免於遭受哈希傳遞攻擊。

  • 使用 Device Guard

    Device Guard 是安全性方面真正的進階，也是協助防範惡意代碼的有效方式。 Windows 中的 Device Guard 功能會封鎖不受信任的應用程式， (貴組織未授權的應用程式) 。

  • 簽署 Device Guard 原則

    簽署的 Device Guard 原則有助於防範具有系統管理員許可權的用戶嘗試破壞目前的原則。 簽署原則時，稍後修改 Device Guard 的唯一方法是提供由相同簽署者簽署的新版本原則，或從指定為 Device Guard 原則一部分的簽署者來簽署。

  • 使用虛擬化型安全性

    當您有受虛擬化型安全性保護的核心模式程式代碼完整性時，即使弱點允許未經授權的核心模式記憶體存取，程式代碼完整性規則仍會強制執行。 請記住，使用虛擬化型安全性執行核心程式代碼完整性的 Device Guard 裝置必須具有相容的驅動程式。

  • 開始使用稽核模式部署 Device Guard

    在稽核模式中將 Device Guard 原則部署至目標電腦和裝置。 監視程式代碼完整性事件記錄檔，指出如果在強制模式中設定 Device Guard，程式或驅動程式會遭到封鎖。 調整 Device Guard 規則，直到達到高信賴度為止。 測試階段完成之後，Device Guard 原則可以切換為強制模式。

  • 部署Device Guard時建置隔離的參考機器

    由於公司網路可能包含惡意代碼，因此您應該開始設定與您主要公司網路隔離的參考環境。 之後，您可以建立程式代碼完整性原則，其中包含您想要在受保護裝置上執行的信任應用程式。

  • 在有意義時使用AppLocker

    雖然 AppLocker 不被視為新的 Device Guard 功能，但在某些情況下，它可補充 Device Guard 功能，例如能夠拒絕特定使用者或使用者群組的特定通用 Windows 應用程式。

  • 鎖定韌體和設定

    安裝 Windows 之後，鎖定韌體開機選項存取。 此鎖定可防止具有實體存取權的使用者修改 UEFI 設定、停用安全開機或開機其他操作系統。 此外，為了防止系統管理員嘗試停用 Device Guard，請在目前的 Device Guard 原則中新增規則，以拒絕並封鎖 C：\Windows\System32\SecConfig.efi 工具的執行。

健康情況證明是 Windows 的重要功能，其中包含用戶端和雲端元件，可根據使用者及其裝置的身分識別，以及公司治理原則的合規性來控制高價值資產的存取權。 組織可以選擇偵測和報告狀況不良的裝置，或根據其需求設定健全狀況強制規則。 健康情況證明提供端對端安全性模型和整合點，供廠商和軟體開發人員用來建置和整合自定義解決方案。