控制 Windows 10 裝置的健康情況
本文詳細說明一個端對端解決方案，可藉由強制執行、控制及回報 Windows 10 裝置的健康情況，協助您保護高價值的資產。
簡介
在「攜帶您自己的裝置」(BYOD) 案例中，員工會攜帶商業上可用的裝置來存取工作相關的資源及其個人資料。使用者想要使用自己選擇的裝置，不僅是從內部網路，也可以從任何位置，存取組織的應用程式、資料及資源。這種現象也稱為 IT 消費化。
使用者想要在存取公司應用程式及從其裝置處理組織資料時，擁有最佳的生產力體驗。這表示他們將無法容忍系統在每次他們存取應用程式或檔案伺服器時，提示他們輸入其工作認證。從安全性觀點來看，這也表示使用者將在未受管理的裝置上操縱公司認證和公司資料。
隨著使用 BYOD 情況的增加，將會有更多未受管理且可能狀況不良的系統存取公司服務、內部資源及雲端 app。
即使是受管理的裝置也可能被連累而變成有害。組織需要在發生違反安全性的情況時加以偵測，並及早因應以保護高價值資產。
隨著 Microsoft 的進展，安全性投資越來越專注在安全性預防措施，也專注在偵測和回應能力。
Windows 10 是端對端安全性解決方案的一個重要元件，其焦點不只限於實作安全性預防措施，而且還會將裝置健康情況證明功能新增到整體安全性策略。
健全的端對端安全性解決方案的描述
現今的運算威脅情況正以前所未有的速度增加。犯罪攻擊手法的複雜性不斷提高，並且毫無疑問的，惡意程式碼現在將目標同時指向所有業界的消費者和專業人員。
近幾年來，有一個特殊類別的威脅變得非常普及：進階持續性威脅 (APT)。APT 一詞通常用來描述任何似乎是以個別組織做為目標的持續性攻擊。事實上，這種類型的攻擊通常涉及可能使用任何必要方法或技術的堅決對手。
在 BYOD 現象下，維護不良的裝置即是一個可供選擇的目標。對攻擊者來說，它提供一個簡便的途徑來破壞安全性網路周邊、獲得存取權，然後竊取高價值的資產。
攻擊者以個人做為目標並非特別因為其個人本身，較多是因為其任職單位。即使組織已強化網路周邊或在其防禦姿態上做投資，受感染的裝置仍會將惡意程式碼帶入組織。防禦性策略並不足以應付這些威脅。
不同的方法
不同於傳統將焦點放在防止外洩上，有效的安全性策略會假設堅決的對手將順利衝破任何防線。這表示將焦點從預防性的安全性控制轉移到安全性問題的偵測與回應是必要的。因此，風險管理策略的實作針對在預防、偵測及回應上的投資進行了平衡。
由於使用行動裝置來存取公司資訊的情況越來越常見，因此必須有某種方法來評估裝置的安全性或健康情況。本節說明如何佈建裝置健康情況評估，讓狀況不良的裝置無法存取高價值資產。
用來存取公司資源的裝置必須是受信任的裝置。有效的端對端安全性方法能夠在授與高價值資產的存取權時，評估裝置健康情況並使用目前的安全性狀態。
.png "圖 1")
一個健全的設計需要確立使用者的身分識別、視需要強化驗證方法，以及了解使用者慣常從哪個網路位置連線之類的行為。此外，新式方法必須能夠只有在確定使用者裝置狀況良好且安全的情況下，才釋出敏感性內容。
下圖顯示一個為了從雲端評定裝置健康情況而建置的解決方案。裝置會透過連線到雲端的身分識別提供者來驗證使用者。如果受管理的資產包含高度機密的資訊，身分識別提供者的條件式存取引擎可能就會選擇在授與存取權之前，先確認行動裝置的安全性符合狀況。使用者的裝置能夠證明其健康情況狀態，可隨時或在行動裝置管理 (MDM) 要求時加以傳送。
.png "圖 2")
您可以使用低階硬體技術 (例如整合可延伸韌體介面 (UEFI) 安全開機)，來保護 Windows 裝置不受低階的 Rootkit 和 Bootkit 所侵害。
安全開機是一個韌體驗證程序，可協助防止 Rootkit 攻擊；它是 UEFI 規格的一部分。UEFI 的目的是定義一個可供作業系統與新式硬體進行通訊的標準方式，此方式在執行輸入/輸出 (I/O) 功能上，可以比舊版軟體插斷導向的 BIOS 系統執行得更快且更有效率。
裝置健康情況證明模組可以將受信賴平台模組 (TPM) 保護的測量開機資料傳送給遠端服務。裝置成功開機之後，會使用更安全且防竄改的通訊通道，將開機程序測量資料傳送給信任的雲端服務 (健康情況證明服務)。
遠端健康情況證明服務會執行一系列的測量檢查。它會驗證安全性相關的資料點，包括開機狀態 (安全開機、偵錯模式等項目) 及管理安全性 (BitLocker、Device Guard 等項目) 的元件狀態。然後，它會藉由將已加密健康情況的 blob 傳回裝置，來傳達裝置的健康情況狀態。
MDM 解決方案通常會套用設定原則，並將軟體部署到裝置。MDM 會定義安全性基準，透過定期檢查來查看安裝的軟體、強制執行的組態以及判斷裝置的健康情況狀態，來了解裝置符合規範的情況。
MDM 解決方案會要求裝置傳送裝置健康情況資訊，並將已加密健康情況的 blob 轉送給遠端健康情況證明服務。遠端健康情況證明服務會確認裝置健康情況資料、檢查 MDM 的通訊對象是否是同一個裝置，然後發出裝置健康情況報告以傳回給 MDM 解決方案。
MDM 解決方案會評估健康情況證明，而且根據隸屬於組織的健康情況規則，可以判定裝置是否狀況良好。如果裝置狀況良好且符合規範，MDM 就會將該資訊傳遞給身分識別提供者，以叫用組織的存取控制原則來授與存取權。
接著，會以適用於健康情況狀態及其他條件式元素表示的信任層級，來授與內容的存取權。
視受管理資產的需求和敏感性而定，處理存取要求時，裝置健康情況狀態可以與使用者身分識別資訊結合使用。接著，就會為適當的信任層級授與內容的存取權。條件式存取引擎的結構可設計為允許依受管理資產的敏感性需要進行額外的驗證。例如，如果要求存取的是高價值資料，可能就需要透過在授與存取權之前向使用者發出接聽電話的查詢，建立額外的安全性驗證。
Microsoft 在 Windows 10 的安全性投資
在 Windows 10 中，有三個投資重點：
安全的身分識別：Microsoft 是 FIDO 聯盟的成員，其目標是藉由在本機系統上以及針對所有服務 (例如內部部署資源和雲端資源) 移除使用密碼進行驗證的方式，來提供可互通的安全驗證方法。
資訊保護：Microsoft 正進行投資以允許組織更有效控制可存取重要資料的人員，以及他們可對該資料執行的動作。使用 Windows 10，組織便可利用原則來指定哪些應用程式可明確視為公司應用程式，而可受信任來存取安全資料。
威脅防護：Microsoft 透過使用依賴硬體的安全性防禦措施，協助組織更有效地保護企業資產不受惡意程式碼和攻擊威脅。
保護、控制及回報 Windows 10 裝置的安全性狀態
本節是一個概觀，說明可協助保護高價值資產和資訊不受攻擊者及惡意程式碼危害的端對端安全性解決方案的不同部分。
.png "圖 3")
| 號碼 | 解決方案的部分 | 描述 |
|---|---|---|
1 |
Windows 10 裝置 |
第一次啟動 Windows 10 裝置電源時，會顯示全新體驗 (OOBE) 畫面。安裝期間，裝置可以自動向 Azure Active Directory (AD) 登錄並向 MDM 註冊。 具有 TPM 2.0 的 Windows 10 裝置可以使用所有 Windows 10 版本都提供的健康情況證明服務，隨時回報健康情況狀態。 |
2 |
身分識別提供者 |
Azure AD 包含組織租用戶的使用者、已登錄的裝置及已登錄的應用程式。一個裝置一律隸屬於一位使用者，而一位使用者可以擁有多個裝置。裝置會以具有各種不同屬性 (例如裝置的相容性狀態) 的物件來代表。受信任的 MDM 可以更新相容性狀態。 Azure AD 不只是一個存放庫。Azure AD 能夠驗證使用者和裝置，而且也可以授與受管理資源的存取權。Azure AD 具有一個條件性存取控制引擎，此引擎會在進行信任的存取決策時，利用使用者識別身分、裝置位置，以及裝置的相容性狀態。 |
3 |
行動裝置管理 |
Windows 10 具有 MDM 支援，不需部署任何代理程式，就能夠在現成情況下管理裝置。 MDM 可以是 Microsoft Intune 或任何與 Windows 10 相容的第三方 MDM 解決方案。 |
4 |
遠端健康情況證明 |
健康情況證明服務是由 Microsoft 運作的可信任雲端服務，此服務會執行一系列的健康情況檢查，並向 MDM 報告裝置上啟用了哪些 Windows 10 安全性功能。 安全性驗證包含開機狀態 (WinPE、安全模式、偵錯/測試模式)，以及管理執行階段操作 (BitLocker、Device Guard) 的安全性與完整性的元件。 |
5 |
企業管理的資產 |
企業管理的資產是要保護的資源。 例如，資產可以是 Office 365、其他雲端 app、Azure AD 發佈的內部部署 Web 資源，甚至是 VPN 存取。 |
Windows 10 裝置、身分識別提供者、MDM 及遠端健康情況證明共同建立了一個健全的端對端解決方案，可針對存取高價值資產的裝置進行健康情況和相容性驗證。
保護裝置和企業認證不受威脅影響
本節說明 Windows 10 提供哪些安全性防禦措施，以及可權衡哪個控制項和向哪個控制項回報。
Windows 10 硬體型安全性防禦措施
最具侵略性形式的惡意程式碼會嘗試儘早將自己插入開機程序中，以便在初期就掌控作業系統，並防止保護機制和反惡意程式碼軟體發揮作用。這種類型的惡意程式碼通常稱為 Rootkit 或 Bootkit。避免需要處理低階惡意程式碼的最佳方式就是保護開機程序，讓裝置從一開始就獲得保護。
Windows 10 支援多層開機保護。這其中部分功能只在已安裝特定類型的硬體時才會提供。如需詳細資訊，請參閱硬體需求一節。
.png "圖 4")
Windows 10 支援某些功能，可協助防止在啟動程序期間載入複雜的低階惡意程式碼 (例如 rootkit 和 bootkit)：
**信賴平台模組。**信賴平台模組 (TPM) 是提供唯一安全性功能的硬體元件。
Windows 10 運用 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 10 會使用 TPM 進行密碼編譯計算，以做為健康情況證明的一部分，以及保護 BitLocker、Microsoft Passport、虛擬智慧卡及其他公開金鑰憑證的金鑰。如需詳細資訊，請參閱 Windows 10 中的 TPM 需求。
Windows 10 可辨識由 TCG 所產生的版本 1.2 或 2.0 TPM 規格。針對最新的新式安全性功能，Windows 10 僅支援 TPM 2.0。需要有 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 韌體的裝置可設定為只載入信任的作業系統開機載入器。安全開機不需要 TPM。
最基本的保護是安全開機功能，其為 UEFI 2.2 + 架構的一個標準部分。在具備傳統 BIOS 的電腦上，任何可以控制開機程序的人都能使用替代的 OS 載入器來開機，而且可能會取得系統資源的存取權。啟用安全開機時，您可以只使用 OS 載入器來開機，該載入器是使用儲存於 UEFI 安全開機 DB 中的憑證來簽署。當然，用來以數位方式簽署 Windows 10 OS 載入器的 Microsoft 憑證會位於該存放區中，讓 UEFI 能夠驗證憑證以做為其安全性原則的一部分。根據預設，您必須於 Windows 硬體相容性計畫下已獲 Windows 10 認證的所有電腦上啟用安全開機。
安全開機是以 UEFI 韌體為基礎的功能，能夠在開機期間，對關鍵的開機檔案和驅動程式進行簽署與驗證。安全開機會在開機期間先檢查 Windows 開機管理程式、BCD 存放區、Windows OS 載入器檔案及其他開機關鍵 DLL 的簽章值，然後才允許系統使用建置期間由 OEM 所定義的原則，完全開機到可使用的作業系統。安全開機可以防止許多類型的開機型 rootkit、惡意程式碼，以及針對 Windows 平台進行的其他安全性相關攻擊。不論是否從本機硬碟、USB、PXE 或 DVD 開機，或是開機進入完整的 Windows 或 Windows 修復環境 (RE)，安全開機都會保護作業系統開機程序。
安全開機會藉由驗證關鍵開機元件的簽章以確認惡意活動不會洩漏它們，來保護 Windows 10 安裝的開機環境。載入 Windows 核心檔案 (ntoskrnl.exe) 之後，安全開機保護即會結束。
注意
在 Windows 核心載入之前，安全開機會持續保護平台。然後會由像是 ELAM 的保護接手。
**安全開機設定原則。**將安全開機功能擴充至關鍵的 Windows 10 設定。
受保護的設定資訊範例包括保護停用執行位元 (NX 選項)，或確保無法啟用測試簽署原則 (程式碼完整性)。這可確保電腦的二進位檔案和設定在開機程序完成之後是可信任的。
安全開機設定原則會利用 UEFI 原則來執行此動作。 這些原則簽章的簽署方式與簽署作業系統二進位檔案來與安全開機搭配使用的方式相同。
安全開機設定原則必須使用私密金鑰來簽署，該私密金鑰會對應至儲存於金鑰交換金鑰 (KEK) 清單中的其中一個公開金鑰。Microsoft 憑證授權單位 (CA) 將出現在所有 Windows 認證的安全開機系統的 KEK 清單中。根據預設，由 Microsoft KEK 簽署的原則應該在所有的安全開機系統上運作。BootMgr 必須先針對 KEK 清單驗證簽章，然後再套用已簽署的原則。透過 Windows 10，預設的安全開機設定原則會內嵌於 bootmgr 中。
開機載入器會先驗證 Windows 10 核心的數位簽章，然後再載入該簽章。Windows 10 核心會依次驗證 Windows 啟動程序的每個其他元件，包括開機驅動程式、啟動檔案及 ELAM 元件 。這個步驟很重要，並藉由確認所有的 Windows 開機元件都具有完整性且可信任的，來保護開機程序的其餘部分。
**開機初期啟動的反惡意程式碼 (ELAM)。**ELAM 會在所有驅動程式載入之前先測試，並防止載入未經核准的驅動程式。
傳統的反惡意程式碼 App 會在載入開機驅動程式之後啟動，讓 Rootkit 有機會偽裝成驅動程式來運作。ELAM 是在舊版 Windows 中引進的 Windows 機制，讓反惡意程式碼軟體可以在非常初期的開機順序中執行。因此，反惡意程式碼元件是第一個第三方元件，可在 Windows 作業系統運作之前，執行並控制其他開機驅動程式的初始化。當系統在完整的執行階段環境 (網路存取權、存放區等項目) 中啟動時，即會載入功能完整的反惡意程式碼。
ELAM 可以在所有非 Microsoft 的開機驅動程式和應用程式之前載入 Microsoft 或非 Microsoft 的反惡意程式碼驅動程式，因此會繼續進行由安全開機和信任式開機所建立的信任鏈結。因為作業系統尚未啟動，而且由於 Windows 需要儘快開機，因此，ELAM 會有一個簡單的工作：檢查每個開機驅動程式，並決定其是否位於信任的驅動程式清單上。如果該驅動程式不受信任，Windows 將不會載入。
注意
Windows Defender (Microsoft 預設包含於 Windows 10 中的反惡意程式碼 )支援 ELAM；您可以使用第三方反惡意程式碼相容解決方案來取代。Windows Defender ELAM 驅動程式的名稱是 WdBoot.sys。Windows 10 中的 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 10 的關鍵部分。
虛擬式安全性會將敏感性程式碼 (例如，核心模式程式碼完整性) 或敏感性公司網域認證與 Windows 作業系統的其餘部分隔離。如需詳細資訊，請參閱虛擬式安全性一節。
**HYPER-V 程式碼完整性 (HVCI)。**HYPER-V 程式碼完整性是一項 Device Guard 功能，可確保只允許驅動程式、可執行檔及遵守 Device Guard 程式碼完整性原則的 DLL 執行。
啟用並設定時，Windows 10 就可以啟動 HYPER-V 虛擬式安全性服務，包括 HYPER-V 程式碼完整性 (HVCI)。HVCI 可協助保護系統核心 (Kernel)、具有特殊權限的驅動程式，以及系統防禦措施 (例如反惡意程式碼解決方案)，以防止惡意程式碼在開機程序早期或啟動之後執行。
HVCI 使用虛擬式安全性來隔離程式碼完整性，核心記憶體可以成為可執行的唯一方式是透過程式碼完整性驗證。這表示核心記憶體分頁永遠不能是可寫入且可執行的 (W+X)，而且不能直接修改可執行的程式碼。
注意
使用虛擬式安全性執行核心模式程式碼完整性的 Device Guard 裝置必須具備相容的驅動程式。如需詳細資訊，請閱讀 Windows 10 驅動程式與 Device Guard 的相容性部落格文章。
Device Guard 程式碼完整性功能可讓組織控制哪些程式碼會受到信任可在 Windows 核心中執行，以及哪些應用程式會通過核准可在使用者模式中執行。您可以使用原則來設定。
Device Guard 程式碼完整性原則是 Microsoft 建議您簽署的二進位檔案。簽署程式碼完整性原則，可協助提供保護，防止具備系統管理員權限的惡意使用者嘗試修改或移除目前的程式碼完整性原則。
**Credential Guard。**Credential Guard 會利用硬體式認證隔離來保護公司認證。
在 Windows 10 中，Credential Guard 的目標是保護網域公司認證，免於遭到惡意程式碼竊取或重複使用。利用 Credential Guard，Windows 10 實作了架構變更，基本上可防止目前的傳遞雜湊 (PtH) 攻擊形式。
這會利用 HYPER-V 和新的虛擬式安全性功能建立受保護的容器來完成，而其中信任的程式碼和密碼會從 Windows 核心隔離。這表示即使 Windows 核心遭到洩漏，攻擊者仍無法讀取和擷取起始 PtH 攻擊所需的資料。Credential Guard 可防止發生此情況，因為儲存密碼的記憶體無法再從一般 OS 加以存取，即使是在核心模式 (Hypervisor 會控制可存取記憶體的人員) 中也一樣。
**健康情況證明。**裝置的韌體會記錄開機程序，而 Windows 10 可將它傳送到信任的伺服器，該伺服器可以檢查並評估裝置的健康情況。
Windows 10 會測量 UEFI 韌體，而每個 Windows 和反惡意程式碼元件都會在它們於開機程序期間載入時產生。此外，系統會循序取得並測量它們，而不是同時完成。當這些測量完成時，它們的值會以數位方式簽署並安全地儲存於 TPM 中，而且除非系統重設，否則無法變更。
如需詳細資訊，請參閱安全開機與測量開機：強化開機初期載入的元件不受惡意程式碼攻擊。
在每個後續開機期間，都會測量相同的元件，對預期的基準進行測量比較。針對額外的安全性，可以簽署由 TPM 所測量的值並傳輸到遠端伺服器，然後可執行比較。這個處理程序稱為「遠端裝置健康情況證明」**，讓伺服器能夠驗證 Windows 裝置的健康情況狀態。
健康情況證明需要有 TPM 2.0 版在 Windows 10 上，TPM 2.0 也需要 UEFI 韌體。
雖然安全開機是主動式保護形式，但健康情況證明是開機保護的反應形式。健康情況證明是以停用形式隨附於 Windows 中，可以由反惡意程式碼或 MDM 廠商來啟用。與安全開機不同，健康情況證明將不會停止開機程序，而且會在測量未運作時進入補救措施。但是透過條件式存取控制，健康情況證明將有助於防止存取高價值的資產。
虛擬式安全性
虛擬式安全性提供適用於 Windows 10 的新信任界限。 使用 HYPER-V Hypervisor 技術來增強平台安全性。虛擬式安全性提供安全的執行環境，來執行特定 Windows 信任的程式碼 (trustlet)，以及保護敏感性資料。
虛擬式安全性可以協助防止洩漏核心或抵禦具備系統管理員權限的惡意使用者。請注意，虛擬式安全性不會嘗試提供保護來抵禦實體攻擊者。
下列 Windows 10 服務會受到虛擬式安全性保護：
Credential Guard (LSA 認證隔離)：防止因讀取和傾印 lsass 記憶體內容發生的傳遞雜湊攻擊和企業認證竊取。
Device Guard (Hyper-V 程式碼完整性)：Device Guard 使用 Windows 10 中新的虛擬式安全性，將程式碼完整性服務從 Windows 核心本身隔離出來，讓服務使用由您企業控制的原則所定義的簽章，協助判斷可信任的服務。實際上，程式碼完整性服務會與 Windows Hypervisor 保護之容器中的核心一起執行。
其他隔離的服務：例如，Windows Server Technical Preview 2016 上有一個 vTPM 功能，讓您能夠在伺服器上擁有加密的虛擬機器 (VM)。
注意
虛擬式安全性僅適用於 Windows 10 企業版。虛擬式安全性需要具備 UEFI (2.3.1 或更高版本)的裝置，並啟用安全開機、具備虛擬化擴充功能的 x64 處理器，以及啟用 SLAT。 IOMMU、TPM 2.0，以及覆寫安全記憶體的支援是選擇性的，但建議使用。
下列結構描述是針對具備虛擬式安全性的 Windows 10 的整體檢視。
.png "圖 5")
Credential Guard
在 Windows 10 中啟用 Credential Guard 時，本機安全性授權子系統服務 (lsass.exe) 會在隔離的使用者模式中執行敏感性程式碼，以協助保護資料來抵禦可能會在標準使用者模式中執行的惡意程式碼。這有助於確保受保護的資料不會遭竊以及在遠端電腦上重複使用，可減輕許多 PtH 樣式的攻擊。
Credential Guard 可利用每次開機的金鑰或永續性金鑰來加密認證，藉以協助提供保護：
每次開機的金鑰可用於任何不需要永續性的記憶體內部認證。這類認證的一個範例是票證授權票證 (TGT) 工作階段金鑰。這個金鑰會在每次發生驗證時與金鑰發佈中心 (KDC) 進行交涉，並會受到每次開機的金鑰所保護。
永續性金鑰或某些系出物件可用來協助保護儲存並在重新開機之後重新載入的項目。這類保護適用於長期存放區，並且必須使用一致性金鑰來保護。
Credential Guard 是由登錄機碼所啟用，然後使用 UEFI 變數來啟用。完成之後，就能夠防止遠端修改設定。使用 UEFI 變數意味著需要有實體存取權才能變更設定。當 lsass.exe 偵測到已啟用認證隔離時，它接著會繁衍 LsaIso.exe 做為隔離的程序，以確保它會在隔離的使用者模式中執行。啟動 LsaIso.exe 會在初始安全性支援提供者之前執行，可確保安全模式支援常式會在任何驗證開始之前準備就緒。
Device Guard
Device Guard 是 Windows 10 企業版的新功能，可讓組織鎖定裝置以協助提供保護來防止該裝置執行不受信任的軟體。在這個設定中，只允許執行組織信任的應用程式。
執行程式碼的信任決策是使用 Hyper-V 程式碼完整性來執行，這是在虛擬式安全性中執行，這是可與一般 Windows 一起執行且受 Hyper-V 保護的容器。
HYPER-V 程式碼完整性是一項功能，可在每次將驅動程式或系統檔案載入記憶體時驗證其完整性。程式碼完整性會偵測是否將未簽署的驅動程式或系統檔案載入核心，或者系統檔案是否已由具備系統管理員權限的使用者帳戶所執行的惡意軟體加以修改。在 x64 型版本的 Windows 10 中，核心模式驅動程式必須以數位方式進行簽署。
注意
與啟用 Device Guard 原則無關，Windows 10 預設會引發在核心中執行的列。Windows 10 驅動程式必須經由 Microsoft (更明確地說是 WHQL (Windows 硬體品質實驗室) 入口網站) 所簽署。此外，從2015年 10 月開始，WHQL 入口網站將只接受驅動程式提交，包括核心和使用者模式驅動程式提交，其具備有效的延伸驗證 (「EV」) 程式碼簽署憑證。
利用 Windows 10 中的 Device Guard，組織現在能夠定義自己的程式碼完整性原則，以便在執行 Windows 10 企業版的 x64 系統上使用。 組織能夠設定原則來判斷要信任來執行的項目。這些包含驅動程式和系統檔案，以及傳統型桌面應用程式和指令碼。系統接著會鎖定為只執行組織信任的應用程式。
Device Guard 是 Windows 10 企業版的內建功能，可防止執行不必要的程式碼與應用程式。Device Guard 是使用兩個規則動作來設定 - 允許和拒絕：
允許限制對允許的程式碼清單或信任的發佈者執行應用程式，並封鎖其他所有項目。
拒絕會封鎖特定應用程式的執行，來完成允許信任的發佈者方法。
撰寫本文時，以及根據 Microsoft 的最新研究，有超過 90% 的惡意程式碼是完全未經簽署的。因此，實作基本的 Device Guard 原則只能有效協助封鎖絕大多數的惡意程式碼。事實上，Device Guard 可能會繼續執行，而且也能夠協助封鎖已簽署的惡意程式碼。
Device Guard 需要進行規劃並設定，才能使其真正生效。它不只是啟用或停用的保護。Device Guard 是硬體安全性功能與軟體安全性功能的組合，一起設定時，可以鎖定電腦，協助確保能夠具備最安全且具防禦力的系統。
Windows 10 的 Device Guard 解決方案是由三個不同的部分所組成：
第一個部分是基本的硬體安全性功能組合，這是在先前的 Windows 版本中所引進的。適用於硬體密碼編譯作業的 TPM 和具備最新韌體的 UEFI 以及安全開機，可讓您控制當系統啟動時裝置所要執行的項目。
在硬體安全性功能之後，會有程式碼完整性引擎。在 Windows 10 中，程式碼完整性目前已可完整設定，且現在處於隔離的使用者模式，此為虛擬式安全性所保護之記憶體的一部分。
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 可用來建立與這些資產的安全連線。
同樣地，在公司完全管理的工作站上，其中的應用程式是使用 System Center Configuration Manager、Intune 或任何第三方裝置管理等發佈工具來安裝，則 Device Guard 就非常適用。在該類型的案例中，組織對於平均使用者正在執行的軟體有一個很不錯的想法。
在公司輕度管理的工作站上使用 Device Guard 是具有挑戰性的，通常會允許使用者在他們自己的裝置上安裝軟體。當組織提供絕佳的彈性時，就很難在強制執行模式中執行 Device Guard。不過，Device Guard 可以在稽核模式中執行，而且在這種情況下，事件記錄檔將包含任何違反 Device Guard 原則的二進位檔記錄。在稽核模式中使用 Device Guard 時，組織可以取得與使用者安裝且執行之驅動程式和應用程式相關的豐富資料。
您必須使用 Microsoft 提供的工具來建立程式碼完整性原則，但原則可使用常見的管理工具 (例如群組原則) 來部署，才能因 Device Guard 中所含的保護而受益。程式碼完整性原則是二進位編碼的 XML 文件，其中包含 Windows 10 之使用者與核心模式的組態設定，以及 Windows 10 Script Host 上的限制。Device Guard 程式碼完整性原則會限制可在裝置上執行的程式碼。
注意
Device Guard 原則可在 Windows 10 中簽署，這樣即可新增額外的保護，以防止系統管理使用者變更或移除此原則。
已簽署的 Device Guard 原則會提供更強大的保護，以防止惡意的本機系統管理員嘗試擊敗 Device Guard。
簽署原則之後，原則的 GUID 就會儲存於 UEFI 作業系統前的安全變數中，以提供防竄改的保護。後續更新 Device Guard 原則的唯一方式是提供同一個簽署者所簽署的新版本原則，或者將指定為 Device Guard 原則一部分的簽署者更新到 UpdateSigner 區段。
簽署應用程式的重要性
在具備 Device Guard 的電腦上，Microsoft 建議從未簽署的 app 可在不受任何限制的情況下執行，移至只有已簽署且信任的程式碼才能在 Windows 10 上執行。
透過 Windows 10，組織將可讓組織成員透過 Windows 市集基礎結構來使用企業營運 (LOB) app。更具體來說，LOB app 將能在公用 Windows 市集內的私人存放區中取得。Windows 市集會簽署並發佈通用 Windows app 和傳統型 Windows app。從 Windows 市集下載的所有 app 皆已簽署。
在現今的組織中，絕大多數的 LOB app 都未經簽署。基於各種不同的理由 (像是缺少的程式碼簽署專業知識)，程式碼簽署經常會被視為很難解決的問題。即使程式碼簽署是最好的做法，許多內部應用程式仍未經簽署。
Windows 10 包含的工具可讓 IT 專業人員取得已經封裝的應用程式，並透過建立其他簽章的程序來執行它們，這類簽章可以和現有的應用程式一起發佈。
為什麼仍然需要反惡意程式碼與裝置管理解決方案？
儘管允許清單機制在確保只有信任的應用程式能夠執行方面具有極大的效率，但它們無法防止設計來攻擊已知弱點的惡意內容洩漏信任 (但有弱點) 的應用程式。Device Guard 無法針對透過攻擊弱點來執行的使用者模式惡意程式碼提供保護。
弱點是軟體中的缺點，讓攻擊者能夠洩漏裝置的完整性、可用性或機密性。某些最糟糕的弱點可讓攻擊者在使用者不知情的情況下引發遭洩漏的裝置執行惡意程式碼來進行攻擊。
常見的情況是攻擊者嘗試發佈特別精心設計的內容，來攻擊使用者模式軟體中的已知弱點，例如，瀏覽器 (及其外掛程式)、Java 虛擬機器、PDF 閱讀程式或文件編輯器。截至目前為止，相較於裝載使用者模式應用程式的作業系統和核心模式驅動程式，有 90% 的已知弱點會對它們造成影響。
為了對抗這些威脅，修補是單一的最有效控制項，可透過形成防禦互補層的反惡意程式碼軟體來進行。
大部分的應用程式軟體都不具更新其本身的功能，因此，即使軟體廠商發佈修正弱點的更新，使用者可能不會知道有可用的更新或是取得更新的方式，因而保持容易受到攻擊的狀態。組織仍然需要管理裝置以及修補弱點。
MDM 解決方案是一項越來越普及的輕量型裝置管理技術。Windows 10 擴充了管理功能，使其可供 MDM 使用。Microsoft 已新增到 Windows 10 的其中一個主要功能是能夠針對 MDM，從受管理且已登錄的裝置中取得裝置健康情況的強式聲明。
裝置健康情況證明
裝置健康情況證明會運用 TPM 2.0，針對用來將裝置開機的軟體鏈結提供經密碼編譯且功能強大的可驗證測量。
針對 Windows 10 裝置，Microsoft 導入了新的公用 API，可讓 MDM 軟體存取名為「Windows 健康情況證明服務」的遠端證明服務。 健康情況證明結果 (除了其他元素) 可用來根據裝置是否能夠證明其狀況良好來允許或拒絕存取網路、app 或服務。
如需裝置健康情況證明的詳細資訊，請參閱偵測狀況不良的 Windows 10 裝置一節。
硬體需求
下表詳述虛擬式安全性服務和健康情況證明功能的硬體需求。如需詳細資訊，請參閱最低硬體需求。
| 硬體 | 動機 |
|---|---|
UEFI 2.3.1 或更新版本的韌體且已啟用安全開機 |
需要支援 UEFI 安全開機。 UEFI 安全開機可確保裝置只會使用授權的程式碼開機。 此外，開機完整性 (平台安全開機) 必須支援遵循下列子小節下方的「適用於 Windows 10 系統的硬體相容性規格」中的需求：“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 10 中 IOMMU 的支援增強了系統對於 DMA 攻擊的復原功能。 |
信賴平台模組 (TPM) 2.0 |
必須支援健康情況證明，而且需要針對虛擬式安全性提供額外的金鑰保護。 |
本節顯示在 Windows 10 中數個密切相關控制項的相關資訊。多層防護以及深入的處理方式，有助於在開機順序期間清除低階的惡意程式碼。虛擬式安全性是基本的作業系統架構變更，可增加新的安全性界限。Device Guard 和 Credential Guard 分別可協助封鎖未受信任的程式碼，以及保護公司網域認證免於遭竊和重複使用。本節也將簡短討論管理裝置及修補弱點的重要性。所有的這些技術都可用來強化和鎖定裝置，同時限制攻擊者洩漏它們的風險。
偵測狀況不良的 Windows 10 裝置
截至目前為止，許多組織在裝置通過所呈現的各式各樣檢查之後，就只會考慮它們是否與公司原則相容，例如，作業系統會處於正確的狀態、已正確設定，並已啟用安全性保護。 可惜的是，透過目前提供的系統，這種形式的報告並不完全可靠，因為惡意程式碼可以假造有關系統健康情況的軟體聲明。Rootkit 或類似的低階入侵程式可以向傳統的相容性工具報告錯誤的狀況良好狀態。
對於 rootkit 的最大挑戰在於用戶端無法偵測到它們。因為它們會在反惡意程式碼之前啟動，而且具有系統層級權限，所以它們可以完全隱匿，同時繼續存取系統資源。因此，即使反惡意程式碼正在執行中，感染 rootkit 的傳統型電腦還是會顯示為狀況良好。
如先前所討論，Windows 10 的健康情況保證功能會使用 TPM 2.0 硬體元件，安全地記錄每次開機相關元件的測量，包括韌體、Windows 10 核心，甚至是開機初期的驅動程式。由於健康情況證明會利用 TPM 的硬體式安全性功能，因此，所有開機測量的元件記錄檔都會保留在任何惡意程式碼的可及範圍之外。
透過證明信任的開機狀態，裝置可以證明它們並未執行低階惡意程式碼，該惡意程式碼可能會詐騙稍後進行的相容性檢查。TPM 式健康情況證明會針對包含高價值資料的資產提供可靠的信任錨點。
裝置健康情況的概念為何？
若要了解裝置健康情況的概念，請務必知道 IT 專業人員採用來防止惡意程式碼入侵的傳統測量。惡意程式碼控制技術會高度專注於防止安裝和發佈。
不過，使用傳統的惡意程式碼防止技術 (例如，反惡意程式碼) 或修補解決方案會為 IT 專業人員帶來一組全新的問題：監視和控制存取組織資源之裝置的相容性。
裝置相容性的定義將根據組織已安裝的反惡意程式碼、裝置組態設定、修補管理基準及其他安全性需求而有所不同。 但是，裝置的健康情況是整體裝置相容性原則的一部分。
裝置的健康情況不是二進位檔，並會根據組織的安全性實作而定。健康情況證明服務可將資訊提供回 MDM，其上的安全性功能會在裝置開機期間運用可信任的硬體 TPM 來啟用。
但健康情況證明只會提供資訊，這就是為什麼需要 MDM 解決方案來採取並強制執行決定。
遠端裝置健康情況證明
在 Windows 10 中，健康情況證明指的是下列功能：可在開機程序期間，將產生的測量開機資料傳送到 Microsoft 所操作的遠端裝置健康情況證明服務。
這對於 Windows 10 裝置而言是最安全的方法，可用來偵測安全性防禦力下降的時機。在開機程序期間，TCG 記錄檔和 PCR 值會傳送到遠端的 Microsoft 雲端服務。接著健康情況證明服務會檢查記錄檔，以判斷裝置上發生了哪些變更。
像是 MDM 的信賴憑證者可以檢查遠端健康情況證明服務所產生的報告。
注意
若要使用 Windows 10 的健康情況證明功能，裝置必須配備離散或韌體 TPM 2.0。所有特定版本的 Windows 10 上均無任何限制。
Windows 10 藉由允許應用程式存取基本的健康情況證明設定服務提供者 (CSP) 來支援健康情況證明案例，如此一來，應用程式便能要求健康情況證明權杖。開機順序的測量隨時都能在本機透過反惡意程式碼或 MDM 代理程式來檢查。
結合了 MDM 的遠端裝置健康情況證明會提供硬體根目錄的方法，來報告目前的安全性狀態並偵測任何變更，而不必信任系統上執行的軟體。
如果有惡意程式碼正在裝置上執行，則必須使用遠端伺服器。 如果有 rootkit 存在於裝置上，反惡意程式碼便不再可靠，而它的行為可透過在啟動順序初期執行的惡意程式碼來攔截。這就是為什麼務必使用安全開機和 Device Guard 來控制要在開機順序期間載入哪些程式碼的原因。
反惡意程式碼軟體可進行搜尋，以判斷開機順序是否包含任何惡意程式碼 (例如 rootkit) 的跡象。它也可以將 TCG 記錄檔和 PCR 傳送到遠端健康情況證明伺服器，以提供測量元件和驗證元件之間的分隔。
健康情況證明會在開機程序期間，記錄各種不同的 TPM 平台設定登錄 (PCR) 和 TCG 記錄檔中的測量。
.png "圖 6")
啟動配備 TPM 的裝置時，即會執行不同元件的測量。這包括韌體、UEFI 驅動程式、CPU 微碼， 同時也包括所有類型為「開機啟動」的 Windows 10 驅動程式。原始的測量會儲存於 TPM PCR 暫存器中，而所有事件的詳細資料 (可執行的路徑、授權單位憑證等) 都可在 TCG 記錄檔中取得。
.png "圖 7")
以下為健康情況證明程序的運作方式：
測量硬體開機元件。
測量作業系統開機元件。
如果已啟用 Device Guard，即會測量目前的 Device Guard 原則。
測量 Windows 核心。
防毒軟體已啟動來做為第一個核心模式驅動程式。
測量開機啟動驅動程式。
透過 MDM 代理程式的 MDM 伺服器會利用健康情況證明 CSP 來發出健康情況檢查命令。
開機測量會經由健康情況證明服務來驗證
注意
根據預設，最近 100 個系統開機記錄及所有相關聯的繼續執行記錄都會封存於 %SystemRoot%\logs\measuredboot 資料夾中。
保留的記錄數目可能會使用位於 HKLM\SYSTEM\CurrentControlSet\Services\TPM 機碼下方的登錄 REG_DWORD 值 PlatformLogRetention 來設定。值為 0 將關閉記錄封存，而值為 0xffffffff 將保留所有記錄。
下列程序說明如何將健康情況開機測量傳送到健康情況證明服務：
用戶端 (配備 TPM 2.0 的 Windows 10 裝置) 會利用遠端裝置健康情況證明服務來初始要求。因為健康情況證明伺服器預期是做為 Microsoft 雲端服務，所以已經將 URI 預先佈建於用戶端中。
用戶端接著會傳送 TCG 記錄、AIK 簽署的資料 (PCR 值、開機計數器)，以及 AIK 憑證資訊。
遠端裝置健康情況證明服務接著會執行下列動作：
確認 AIK 憑證是由已知且信任的 CA 所發出，而且該憑證是有效且無法撤銷的。
確認 PCR 引號上的簽章是正確且與 TCG 記錄值一致。
剖析 TCG 記錄中的屬性。
發行裝置健康情況權杖，其中包含健康情況資訊、AIK 資訊，以及開機計數器資訊。健康情況權杖也會包含有效的發行時間。裝置健康情況權杖是加密且經過簽署的，這表示資訊會受到保護，而且只能存取來發行健康情況證明服務。
用戶端會將健康情況加密的 blob 儲存於其本機存放區中。裝置健康情況權杖包含裝置健康情況狀態、裝置識別碼 (Windows AIK)，以及開機計數器。
.png "圖 8")
裝置健康情況證明元件
裝置健康情況證明解決方案牽涉到 TPM、健康情況證明 CSP 及 Windows 健康證明服務等不同元件。本節將說明這些元件。
信賴平台模組
*它就是 TPM 2.0 和簽署憑證。*本節將說明如何使用 PCR (包含系統設定資料)、簽署金鑰 (EK) (可用來做為 TPM 的識別卡)、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 10 的 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 10 根據簽署憑證發行了衍生的證明錨點。此中繼金鑰可證明為簽署金鑰，它是證明識別金鑰 (AIK)，而相對應的憑證稱為 AIK 憑證。這個 AIK 憑證是由 Microsoft 雲端服務所發行。
注意
在裝置可以使用 TPM 2.0 證明功能來報告它的健康情況之前，AIK 憑證必須連同 Microsoft 雲端 CA 服務等第三方服務進行佈建。 佈建之後，就可以使用 AIK 私密金鑰來報告平台設定。Windows 10 會在每次開機時使用 AIK，在平台記錄狀態 (以及單純計數器的值) 上建立簽章。
AIK 是非對稱式 (公開/私密金鑰) 金鑰組，可基於隱私權目的，用作 EK 的替代項目來做為 TPM 的身分識別。AIK 的私密部分永遠都不會顯示，或者會在 TPM 外部使用，而且只能針對一組有限的作業於 TPM 內部使用。此外，它只能用來簽署，而且僅適用於有限制且 TPM 定義的作業。
Windows 10 會建立受 TPM 保護的 AIK，如果有的話，其為 2048 位元的 RSA 簽署金鑰。Microsoft 會裝載稱為 Microsoft 雲端 CA 的雲端服務，並以密碼編譯的方式來建立，而它會與真正的 TPM 進行通訊，且 TPM 擁有所顯示的 AIK。在 Microsoft 雲端 CA 服務建立這些事項之後，它會為 Windows 10 裝置發出 AIK 憑證。
許多將升級到 Windows 10 的現有裝置將不會具備 TPM，或者 TPM 將不會包含簽署憑證。**考慮到這些裝置，Windows 10 允許在沒有簽署憑證的情況下發行 AIK 憑證。**這類 AIK 憑證不是由 Microsoft 雲端 CA 所發行。請注意，這並不像在製造期間燒錄到裝置的簽署憑證一樣值得信任，但它將針對不具 TPM 的 Microsoft Passport 等進階案例提供相容性。
在發行的 AIK 憑證中，會新增特殊的 OID，以證明已在證明程序期間使用該簽署憑證。信賴憑證者可以利用此資訊，來決定是否要拒絕使用 AIK 憑證而不是簽署憑證來證明的裝置，或是接受它們。另一個案例是不允許從 AIK 憑證所證明的裝置存取高價值的資產，而該憑證不會受到簽署憑證所支援。
儲存根金鑰
儲存根金鑰 (SRK) 也是非對稱金鑰組 (長度至少為 2048 位元的 RSA)。SRK 有一個主要角色且可用來保護 TPM 金鑰，所以這些金鑰無法在沒有 TPM 的情況下使用。取得 TPM 的擁有權時，即會建立 SRK 金鑰。
平台設定暫存器
TPM 包含一組暫存器，其是設計來提供軟體的密碼編譯表示法和開機時的系統狀態。這些暫存器稱為平台設定暫存器 (PCR)。
開機順序的測量是以 PCR 和 TCG 記錄為根據。若要建立信任的靜態根，當裝置啟動時，裝置必須能夠先測量韌體程式碼，然後再執行。在此情況下，Core Root of Trust for Measurement (CRTM) 會在開機時執行、計算韌體的雜湊，然後展開暫存器 PCR[0] 來儲存它，並將執行轉移到韌體。
PCR 會在平台開機時設為零，而且它是韌體的工作，可將平台開機以測量開機鏈結中的元件，並記錄 PCR 中的測量。通常，開機元件會採用下一個要執行之元件的雜湊，並記錄 PCR 中的測量。開始測量鏈結的初始元件是以隱含方式來信任。這是 CRTM。平台製造商必須具備適用於 CRTM 的安全更新程序，或者不允許更新它。 PCR 會記錄已測量元件的累積雜湊。
它自己的 PCR 值很難解譯 (它只是雜湊值)，但是平台通常會保存記錄以及已測量項目的詳細資料，而 PCR 只會確保記錄並未遭到竄改。這類記錄稱為 TCG 記錄。每次延伸暫存器 PCR 時，即會在 TCG 記錄中新增一個項目。因此，在整個開機程序期間，會在 TCG 記錄中建立可執行程式碼和設定資料的追蹤。
TPM 佈建
針對要使用 Windows 10 裝置的 TPM，必須先進行佈建。佈建的程序會根據 TPM 版本而不同，但在成功時，它會產生可使用的 TPM，以及適用於本機儲存於登錄中的 TPM 的擁有者授權資料 (ownerAuth)。
佈建 TPM 時，Windows 10 將先嘗試判斷 EK，以及在本機儲存的 ownerAuth 值，方法是查看下列位置中的登錄：HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement
佈建程序期間，裝置可能需重新新啟動。
請注意，Get TpmEndorsementKeyInfo PowerShell Cmdlet 可以與系統管理權限搭配使用，來取得簽署金鑰和 TPM 憑證的相關資訊。
如果無法得知 TPM 擁有權但有 EK 存在，用戶端程式庫將會佈建 TPM，並將所產生的 ownerAuth 值儲存到登錄，前提是原則可讓它將 SRK 公開部分儲存於下列位置：HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin\SRKPub
在佈建程序期間，Windows 10 將使用 TPM 來建立 AIK。執行此作業時，所產生的 AIK 公開部分會儲存於下列位置的登錄中：HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub
注意
若要佈建 AIK 憑證和篩選網際網路存取權，您必須授權下列萬用字元 URL：https://*.microsoftaik.azure.net
Windows 10 健康情況證明 CSP
Windows 10 包含已特殊化來與健康情況證明功能進行互動的設定服務提供者 (CSP)。CSP 是一項元件，可插入至 Windows MDM 用戶端，並針對 MDM 伺服器如何進行設定和管理 Windows 裝置的方式提供已發佈的通訊協定。您可以利用樹狀結構來表示管理通訊協定，該結構可以使用要在 URI 上執行的功能 (例如，「取得」、「設定」、「刪除」等) 指定為 URI。
以下是 Windows 10 健康情況證明 CSP 所執行的功能清單：
收集用來確認裝置健康情況狀態的資料
將資料轉送到健康情況證明服務
佈建健康情況證明憑證，它會從健康情況證明服務接收
根據要求，會將健康情況證明憑證 (接收自健康情況證明服務) 及相關的執行階段資訊轉送至 MDM 伺服器進行驗證
在健康情況證明工作階段期間，健康情況證明 CSP 會透過對健康情況證明服務使用安全通訊通道，來轉送開機期間所測量的 TCG 記錄和 PCR 值。
當 MDM 伺服器驗證裝置已證明為健康情況證明服務時，將為它指定一組聲明並宣告該裝置的開機方式，以及保證裝置不會在證明其健康情況期間和 MDM 伺服器驗證它的期間之間重新開機。
Windows 健康情況證明服務
Windows 健康情況證明服務的角色基本上是評估一組健康情況資料 (TCG 記錄和 PCR 值)、進行一系列偵測 (根據可用的健康情況資料)，以及產生加密的健康情況 blob 或產生 MDM 伺服器的報告。
注意
裝置和 MDM 伺服器都必須能夠在連接埠 443 (HTTPS) 上使用 TCP 通訊協定來存取 has.spserv.microsoft.com。
您可以使用下列數個步驟，來檢查 TPM 證明及相關記錄是有效的：
首先，伺服器必須檢查報告是由可信任的 AIK 所簽署。完成此動作的可能方式如下：檢查 AIK 的公開部分會列於資產的資料庫中，或許已檢查憑證。
檢查金鑰之後，應該檢查簽署的證明 (引號結構)，以查看它是否為 PCR 值上的有效簽章。
接下來應該檢查記錄，以確保它們符合報告的 PCR 值。
最後，MDM 解決方案應該檢查記錄本身，以查看它們是否代表已知或有效的安全性設定。例如，簡單的檢查可能會查看測量的初期 OS 元件是否已知是良好的、ELAM 驅動程式會如預期般運作，以及 ELAM 驅動程式原則檔案是最新狀態。如果所有的這些檢查都成功，就可以發行證明聲明，稍後可用來判斷用戶端是否應該為資源授與存取權。
健康情況證明服務可為 MDM 解決方案提供下列有關裝置健康情況的資訊：
啟用安全開機
啟用開機和核心偵錯
啟用 BitLocker
啟用 VSM
已簽署或未簽署的 Device Guard 程式碼完整性原則測量
載入 ELAM
安全模式開機、啟用 DEP、啟用測試簽署
裝置 TPM 已使用信任的簽署憑證來佈建
如需測量的完整性，請參閱健康情況證明 CSP。
下表列出一些重要項目，可根據 Windows 10 裝置類型回報給 MDM。
| 作業系統類型 | 可以回報的重要項目 |
|---|---|
Windows 10 行動裝置版 |
|
傳統型版本的 Windows 10 |
|
利用 MDM 和健康情況證明服務
為了讓裝置健康情況產生關聯，MDM 解決方案會評估裝置健康情況報告，並設定為組織的裝置健康情況需求。
利用 MDM 和健康情況證明服務的方案包含三個主要部分：
已啟用健康情況證明的裝置。這通常會使用 MDM 提供者做為註冊的一部分來完成 (預設會停用健康情況證明)。
啟用此項目之後且在每次開機之後，裝置將會傳送健康情況測量給 Microsoft 主控的健康情況證明服務，並接收健康情況證明 blob 做為交換。
在此之後的任何時間點，MDM 伺服器都能從裝置要求健康情況證明 blob，並要求健康情況證明服務解密內容並驗證它已經過證明。
.png "圖 9")
在 Windows 10 裝置、健康情況證明服務和 MDM 之間的互動可使用如下的方式來執行：
用戶端會使用 MDM 伺服器來起始工作階段。MDM 伺服器的 URI 是起始要求之用戶端 app 的一部分。此階段的 MDM 伺服器可以使用適當的 CSP URI，來要求健康情況證明資料。
MDM 伺服器會指定 nonce 以及要求。
用戶端接著會傳送 AIK 以引號括住的 nonce + 開機計數器和健康情況 blob 資訊。這個健康情況 blob 會利用健康情況證明服務公開金鑰來加密，該金鑰只有健康情況證明服務能夠解密。
MDM 伺服器：
確認 nonce 會如預期般運作。
將引號括住的資料、nonce 及加密的健康情況 blob 傳遞到健康情況證明服務伺服器。
健康情況證明服務：
解密健康情況 blob。
使用健康情況 blob 中的 AIK 來確認引號中的開機計數器是正確的，並且符合健康情況 blob 中的值。
確認引號中的 nonce 符合而且是傳遞自 MDM 的那一個。
由於開機計數器和 nonce 都會利用來自健康情況 blob 的 AIK 使用引號括起來，因此，它也會證明裝置與產生健康情況 blob 的是同一個裝置。
將資料傳回包含健康情況參數、有效性等項目的 MDM 伺服器。
注意
MDM 伺服器 (信賴憑證者) 永遠不會執行引號或開機計數器驗證本身。它會取得以引號括住的資料和健康情況 blob (這會加密)，並將資料傳送到健康情況證明服務以進行驗證。透過這種方式，MDM 永遠都不會看見 AIK，藉此可以解決隱私權的疑慮。
設定裝置相容性的需求是確保可偵測到和追蹤已登錄但不符合健康情況與相容性需求之裝置的第一個步驟，而且 MDM 解決方案會對其強制採取動作。
嘗試連接到資源的裝置必須已評估它們的健康情況，這樣就能偵測到並回報狀況不良且不相容的裝置。若要完全有效，端對端的安全性解決方案必須加強對於狀況不良裝置的結果，例如，拒絕存取高價值的資產。這就是條件式存取控制的用途 (將在下一節中詳述)。
控制 Windows 10 裝置的安全性然後才能授與存取權
在大部分情況下，目前提供的存取控制技術大多著重於確保正確的人員會取得正確資源的存取權。如果使用者可以進行驗證，他們就能使用裝置取得資源存取權，而組織的 IT 人員及系統對於這一點了解得很少。或許會進行一些檢查，例如，確保在為電子郵件提供存取權之前，會先將裝置加密，但是，如果該裝置受到惡意程式碼感染，該怎麼辦？
遠端裝置健康情況證明程序會使用測量的開機資料，來確認裝置的健康情況狀態。裝置的健康情況接著就可供像是 Intune 的 MDM 解決方案來使用。
注意
如需 Intune 與 Windows 10 功能支援的最新資訊，請參閱 Microsoft Intune 部落格和 Microsoft Intune 的新功能。
下圖顯示如何預期健康情況證明服務會使用 Microsoft 的雲端式 Intune MDM 服務。
.png "圖 10")
MDM 解決方案接著可藉由結合用戶端原則，來利用健康情況狀態聲明並將它們帶到下一個層級，用戶端原則將根據裝置的能力授與條件式存取權來證明它不具惡意程式碼、它的反惡意程式碼系統正在運作且處於最新狀態、防火牆正在執行中，以及裝置修補狀態是相容的。
最後，藉由拒絕無法證明其狀況良好之端點的存取來保護資源。需要存取組織資源的 BYOD 裝置非常需要具備此功能。
Windows 10 中內建的 MDM 支援
Windows 10 具備隨附於作業系統的 MDM 用戶端。這讓 MDM 伺服器能夠管理 Windows 10 裝置，而不需個別的代理程式。
第三方 MDM 伺服器支援
第三方 MDM 伺服器可以使用 MDM 通訊協定來管理 Windows 10。內建的管理用戶端能夠與支援 OMA-DM 通訊協定來執行企業管理工作的相容伺服器進行通訊。如需其他資訊，請參閱將 Azure Active Directory 與 MDM 整合。
注意
MDM 伺服器不需要建立或下載用戶端來管理 Windows 10。如需詳細資訊，請參閱行動裝置管理。
第三方 MDM 伺服器必須具備相同且一致的第一方使用者體驗來註冊，同時也為 Windows 10 使用者提供簡潔性。
透過第三方 MDM 管理 Windows Defender
這個管理基礎結構讓 IT 專業人員能夠使用具備 MDM 功能的產品 (例如 Intune) 來管理健康情況證明、Device Guard 或 Windows 10 裝置上的 Windows Defender，包括未加入網域的 BYOD。IT 專業人員將能管理和設定他們熟悉的所有動作和設定，這些是在低階作業系統上使用 Intune 搭配 Intune Endpoint Protection 來自訂。目前只透過群組原則管理已加入網域之裝置的系統管理將發現使用 MDM，就能很容易地轉換來管理 Windows 10 裝置，因為許多設定和動作都會在這兩種機制上共用。
如需如何使用 MDM 解決方案管理 Windows 10 安全性和系統設定的詳細資訊，請參閱適用於 Windows 10 裝置的自訂 URI 設定。
條件式存取控制
在大部分的平台上，Azure Active Directory (Azure AD) 裝置登錄會在註冊期間自動進行。裝置狀態是透過 MDM 解決方案寫入 Azure AD，然後下次當用戶端嘗試存取 Office 365 相容的工作負載時，由 Office 365 (或任何與 Azure AD 互動的授權 Windows app) 進行讀取。
如果裝置尚未登錄，使用者將收到一則訊息，其中包含如何登錄 (也稱為註冊) 的指示。如果裝置不相容，使用者會收到不同的訊息，將他們重新導向到 MDM Web 入口網站，他們可在其中取得相容性問題及解決方式的詳細資訊。
Azure AD 會驗證使用者與裝置、MDM 會管理相容性和條件式存取原則，而健康情況證明服務會使用已證明的方式來報告裝置的健康情況。
.png "圖 11")
Office 365 條件式存取控制
Azure AD 會強制執行條件式存取原則，以安全存取 Office 365 服務。租用戶系統管理員可以建立條件式存取原則，來封鎖不相容裝置上的使用者，使其無法存取 Office 365 服務。使用者必須先符合公司的裝置原則，才能授與服務的存取權。或者，系統管理員也可以建立一個原則，要求使用者只需註冊他們的裝置，來取得 Office 365 服務的存取權。原則可能會套用到組織的所有使用者，或限制為一些目標群組，並隨時間增強以包含額外的目標群組。
當使用者要求從支援的裝置平台存取 Office 365 服務時，Azure AD 會驗證使用者以及使用者從中啟動要求的裝置；而且只有在使用者符合服務的原則組時，才會授與服務的存取權。系統會針對尚未註冊裝置的使用者提供如何註冊的補救措施指示，並具備存取公司 Office 365 服務的資格。
當使用者註冊時，裝置會使用 Azure AD 來登錄，並使用相容的 MDM 解決方案 (例如 Intune) 來註冊。
注意
Microsoft 會使用第三方 MDM ISV，來支援自動化 MDM 註冊和以原則為基礎的存取檢查。如需使用 Azure AD 和 Intune 開啟自動 MDM 註冊的步驟，請參閱 Windows 10、Azure AD 和 Microsoft Intune：雲端搭載的 MDM 自動註冊！部落格文章。
當使用者成功註冊裝置時，該裝置即會變成信任的。Azure AD 提供單一登入來存取公司應用程式，而且會強制執行條件式存取原則來授與服務的存取權，不只是在使用者第一次要求存取權時，而且會在使用者每次要求更新存取權時。
當登入認證變更、裝置遺失/遭竊或相容性原則在要求更新期間不相符時，將拒絕使用者存取服務。
根據使用者用來線上存取 Exchange 的電子郵件應用程式類型而定，建立安全存取電子郵件的路徑會有些微不同。不過，主要元件 (Azure AD、Office 365/Exchange Online 及 Intune) 是一樣的。IT 體驗和使用者體驗也很類似。
.png "圖 12")
系統將針對下列內容評估嘗試存取 Office 365 的用戶端：
裝置會透過 MDM 管理嗎？
裝置會使用 Azure AD 登錄嗎？
裝置是相容的嗎？
若要取得相容狀態，Windows 10 裝置需要：
使用 MDM 解決方案註冊。
使用 Azure AD 登錄。
符合 MDM 解決方案所設定的裝置原則。
注意
條件式存取原則目前可以選擇性地針對 iOS 和 Android 裝置上的使用者強制執行。如需詳細資訊，請參閱 Azure AD、Microsoft Intune 及 Windows 10 - 使用雲端來將企業行動力現代化！部落格文章。
雲端與內部部署 app 的條件式存取控制
條件式存取控制是內建於 Azure AD 且功能強大的原則評估引擎。它可以為 IT 專業人員提供一個簡單的方法來建立超越 Office 365 的存取規則，評估使用者登入的內容，對於應允許他們存取哪些應用程式進行即時決策。
IT 專業人員可以針對由 Azure AD 所保護的雲端 SaaS 應用程式，甚至是內部部署應用程式，來設定條件式存取控制原則。Azure AD 中的存取規則會利用條件式存取引擎來檢查裝置健康情況及相容 MDM 解決方案 (例如 Intune) 報告的相容性狀態，以判斷是否允許存取。
如需條件式存取的詳細資訊，請參閱適用於 SaaS App 的 Azure 條件式存取預覽。
注意
條件式存取控制是一個 Azure AD Premium 功能，也適用於 EMS。如果您沒有 Azure AD Premium 訂用帳戶，可從 Microsoft Azure 網站取得試用版。
針對內部部署應用程式，有兩個選項可根據裝置的相容性狀態來啟用條件式存取控制：
針對透過 Azure AD 應用程式 Proxy 發佈的內部部署應用程式，您可以設定條件式存取控制原則，就如同您針對雲端應用程式所做的一樣。如需詳細資訊，請參閱更新 Azure AD 條件式存取預覽：現在支援內部部署和自訂 LOB App 部落格文章。
此外，Azure AD Connect 會將裝置相容性資訊從 Azure AD 同步處理到內部部署 AD。Windows Server Technical Preview 2016 上的 ADFS 將根據裝置的相容性狀態支援條件式存取控制。IT 專業人員將在 ADFS 中設定條件式存取控制原則，使用相容 MDM 解決方案所報告的裝置相容性狀態來保護內部部署應用程式的安全。
.png "圖 13")
下列程序說明 Azure AD 條件式存取的運作方式：
使用者已經透過 Workplace 存取/Azure AD 加入使用 MDM 進行註冊，其會使用 Azure AD 來登錄裝置。
當裝置開機或從休眠狀態繼續執行時，會觸發工作「Tpm-HASCertRetr」，在背景中要求健康情況證明 blob。裝置會將 TPM 開機測量傳送到健康情況證明服務。
健康情況證明服務會驗證裝置狀態，並根據健康狀態檢查及檢查失敗 (如果有的話) 的詳細資訊項目，將加密的 blob 發行給裝置。
使用者登入，而 MDM 代理程式會連接 Intune/MDM 伺服器。
MDM 伺服器會降低新原則 (如果有的話)，並查詢健康情況 blob 狀態和其他詳細目錄狀態。
裝置會傳送先前取得的健康情況證明 blob，以及 Intune/MDM 伺服器所要求之另一個狀態詳細目錄的值。
Intune/MDM 伺服器會將健康情況證明 blob 傳送到健康情況證明服務來進行驗證。
健康情況證明服務會驗證傳送健康情況證明 blob 的裝置是狀況良好的，並將此結果傳回 Intune/MDM 伺服器。
Intune/MDM 伺服器會根據相容性以及查詢自裝置的詳細目錄/健康情況證明狀態，來評估相容性。
Intune/MDM 伺服器會根據 Azure AD 中的裝置物件來更新相容性狀態。
使用者會開啟 app，嘗試存取公司管理的資產。
Azure AD 中透過相容性宣告設定閘道的存取權。
如果裝置相容且使用者已獲授權，就會產生一個存取權杖。
使用者可以存取公司管理的資產。
如需 Azure AD 加入的詳細資訊，請參閱 Azure AD 與 Windows 10：最好放在一起以便在公司或學校中使用白皮書。
條件式存取控制是許多組織和 IT 專業人員可能不知道以及他們應該知道的主題。與條件式存取引擎搭配使用時，說明使用者、裝置、相容性及存取內容的不同屬性是功能非常強大的。條件式存取控制是協助組織保護其環境的必要步驟。
重點與摘要
下列清單包含整體的關鍵重點，可改善任何組織的安全性狀態。不過，不應將本節中顯示的幾個重點解譯為安全性最佳做法的完整清單。
了解沒有任何解決方案是絕對安全的
如果具有惡意意圖的堅決對手取得了裝置的實體存取權，他們最終就能突破其安全性層級，並取得控制。
使用健康情況證明搭配 MDM 解決方案
嘗試連接到高價值資產的裝置必須已評估它們的健康情況，這樣就能偵測到並回報狀況不良且不相容的裝置，最終加以封鎖。
使用 Credential Guard
Credential Guard 是一項功能，可大幅協助保護公司網域認證免於受到傳遞雜湊的攻擊。
使用 Device Guard
Device Guard 真正是安全性方面的進階項目，而且是可協助防止惡意程式碼的有效方法。Windows 10 中新的 Device Guard 功能會封鎖未受信任的 app (您組織未授權的 app)。
已簽署的 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 app。
鎖定韌體和設定
安裝 Windows 10 之後，請鎖定韌體開機選項存取。這可防止具備實體存取權的使用者修改 UEFI 設定、停用安全開機或將其他作業系統開機。 此外，為了提供保護以防止系統管理員嘗試停用 Device Guard，請在目前的 Device Guard 原則中新增一個規則，其將拒絕並封鎖 C:\Windows\System32\SecConfig.efi 工具的執行。
健康情況證明是 Windows 10 的一個主要功能，其中包含用戶端和雲端元件，根據使用者及其裝置的身分識別和與公司控管原則的相容性，來控制對高價值資產的存取。組織可以選擇偵測並報告狀況不良的裝置，或是根據自己的需求來設定健康情況強制規則。健康情況證明會提供端對端安全性模型和整合點，廠商與軟體開發人員可用來建置並整合自訂的解決方案。