使用智慧應用程控原則來建置入門原則

注意

商務用應用程控的某些功能僅適用於特定的 Windows 版本。 深入了解 應用程控功能可用性。

本文說明如何使用智慧應用程控原則作為範本來建立商務用應用程控原則。 智慧應用程控 是專為取用者用戶設計的應用程控型安全性解決方案。 它使用與商務用應用程控相同的技術，因此可以輕鬆地作為同樣強固但具彈性的企業原則基礎。

提示

Microsoft建議本文中建立的原則，作為大部分應用程控部署至終端用戶裝置的理想入門原則。 一般而言，不熟悉應用程控的組織，如果從像本文所述的寬鬆原則開始，最為成功。 您可以隨著時間強化原則，以在受應用程控管理的裝置上達到更強大的整體安全性狀態，如後續文章所述。

如同我們在 不同案例中的商務用應用程控部署，讓我們使用 Lamna Healthcare Company (Lamna) 的虛構範例來說明此案例。 Lamna 打算採用更強的應用程式原則，包括使用應用程控來防止垃圾或未經授權的應用程式在其受管理的裝置上執行。

Alice Pena (她/她) 是負責推出應用程控的 IT 小組負責人。 Lamna 目前有寬鬆的應用程式使用原則，以及為使用者提供最大應用程式彈性的文化特性。 因此，Alice 知道他們需要對應用程控採取累加方法，而且可能針對不同的使用者區段使用不同的原則。 但現在，Alice 想要一個可以涵蓋大部分用戶的原則，而不需進行任何修改，Smart App Control 的「已簽署 & 信譽」原則適用於 Lamna。

分析 Smart App Control 的「信任圓圈」如何適合您

Alice 遵循規劃 應用程控原則生命週期管理一文中的指引，並從分析智慧應用程控原則的「信任圈」開始。 Alice 閱讀Microsoft關於智慧應用程控的在線說明文章，以充分瞭解。 從該讀取中，Alice 會瞭解 Smart App Control 只允許 Intelligent Security Graph (ISG) 預測為安全的公開信任簽署程式代碼或未簽署的程式代碼。 公開信任的簽署程式代碼表示簽署憑證的簽發者是Microsoft受信任根計劃中 (CA) 的其中一個證書頒發機構單位。 如果ISG無法預測程式代碼是否安全執行，則會封鎖未簽署的程式代碼執行。 判斷為不安全的程序代碼一律會遭到封鎖。

現在Alice會考慮如何調整原則以供 Lamna 使用。 Alice 想要建立盡可能寬鬆但仍然提供持久安全性價值的初始原則。 Lamna 中的某些人提倡比 Alice 方案更積極的方法。 他們想要立即鎖定終端使用者的裝置，並希望擁有有限的支援。 但領導團隊同意 Alice，Lamna 的應用程式文化在一段時間後形成緩慢，不只是一夜離開，因此初始原則需要很大的彈性。

請考慮組織的重要因素

Alice 接下來會識別 Lamna 環境影響公司「信任圈」的重要因素。原則必須具有彈性，才能滿足短期和中型企業的需求。 這可讓 Lamna 有時間引進新的應用程式管理程式和原則，讓未來更嚴格的應用程控原則更為實用。 關鍵因素也可協助 Alice 選擇要包含在第一個部署中的系統。 Alice 在規劃文件中寫下下列因素：

• 用戶權力： 大部分的使用者都是標準使用者，但幾乎四分之一的使用者在其裝置上具有本機系統管理員許可權，而選擇執行他們選擇的任何應用程式是主要因素。
• 作系統：Windows 11 執行大部分的用戶裝置，但 Lamna 預期在下一個會計年度期間，最多有 10% 的用戶端會保留在 Windows 10，特別是在較小的衛星辦公室。 Lamna 的伺服器和特製化設備目前已超出範圍。
• 用戶端管理：Lamna 會針對部署為雲端原生 Microsoft Entra 的所有 Windows 11 裝置使用 Microsoft Intune。 對於大部分部署為 Microsoft Entra 混合式聯結的 Windows 10 裝置，它們會繼續使用 MICROSOFT 端點 Configuration Manager (MEMCM) 。
• 應用程式管理： Lamna 在其業務單位中有數百個企業營運 (LOB) 應用程式。 Alice 的小組使用 Intune 部署大部分但並非所有應用程式。 小型小組使用一長串應用程式，包括許多「影子 IT」應用程式，這些應用程式沒有正式許可，但對於使用這些應用程式的員工而言至關重要。
• 應用程式開發和程式代碼簽署： Lamna 業務單位不會在開發平臺和架構上標準化，因此可能會有顯著的變異性和複雜性。 幾乎所有應用程式都會使用未簽署或大部分未簽署的程序代碼。 雖然公司現在需要進行程式代碼簽署，但 Lamna 的程式代碼簽署憑證來自其公司公鑰基礎結構 (PKI) ，而且在原則中需要自定義規則。

定義輕量受控裝置的「信任圈」

根據這些因素，Alice 會寫入 Lamna 版本的虛擬規則，Microsoft的 Signed & Reputable policy：

1. 「Windows 和Microsoft認證的核心驅動程式」 允許的一或多個簽署者規則：

   • Windows 及其元件。
   • 由 Windows 硬體質量實驗室 (WHQL) 證書頒發機構單位所簽署的核心驅動程式。

2. 「公開信任的已簽署程序代碼」 允許的一或多個簽署者規則：

   • 由參與 Microsoft受信任根計劃 (“AuthRoot”) 或非 OS 程式代碼Microsoft所簽署之證書頒發機構單位所簽發的憑證簽署程序代碼。

3. Lamna 帶正負號的程序代碼 允許的一或多個簽署者規則：

   • 由 Lamna Codesigning 私人證書頒發機構單位簽發的憑證所簽署的程式代碼， (PCA) ，這是從自己的內部 PKI 發行的中繼憑證。

4. 根據應用程式的「信譽」允許應用程式 原則選項，允許：

   • ISG 預測為「安全」的應用程式。

5. 允許Managed Installer 原則選項，允許：

   • 由原則指定為受管理安裝程序的進程寫入系統的程序代碼。 針對 Lamna 的受控安裝程序原則，Alice 包含 Intune 管理延伸模組，以及廣泛使用之應用程式的已知自動更新程式。 Alice 也包含 filepath 規則 「D：\ Lamna Helpdesk*」，其中 Lamna 的技術服務人員系統管理員會在其中定型以複製用來修復使用者應用程式和系統的應用程式安裝程式和腳本。

6. 管理員 路徑規則下列位置的一或多個檔案路徑規則：

   • “C：\Program Files*”
   • “C：\Program Files (x86) *”
   • “%windir%*”
   • “D：\Lamna Helpdesk*”

修改貴組織的「已簽署 & 信譽」原則範本

Alice 會從 下載應用程控原則精靈 https://aka.ms/appcontrolwizard 並加以執行。

1. 在 [歡迎使用] 頁面上，Alice 看到三個選項：原則建立者、原則 編輯器 和原則合併。 Alice 選取 [ 原則建立者 ]，這會帶她前往下一頁。

2. 在 [選取原則類型] 上，Alice 必須選擇要建立多重原則 格式 或 單一原則格式 原則。 由於所有使用者的裝置都執行 Windows 11 或目前版本的 Windows 10，Alice 會保留預設的多重原則格式。 同樣地， 基底 原則與 補充 原則之間的選擇也很簡單，因此也會選取預設 的 [基底原則 ]。 Alice 選取 [ 下一步 ] 繼續。

3. 下一頁是Alice將 選取原則基底範本的位置。 [應用程控精靈] 提供三個範本原則，以便在建立新的基底原則時使用。 每個範本原則都會套用稍微不同的規則，以改變其原則的信任圈和安全性模型。 三個範本原則如下：

   

   範本基底原則	描述
   默認 Windows 模式	預設 Windows 模式會授權下列元件： Windows作系統元件 - Windows 全新安裝所安裝的任何二進位檔 由 Microsoft Store MarketPlace 簽署者簽署的 MSIX 封裝應用程式 Microsoft Office365 應用程式、OneDrive 和 Microsoft Teams WHQL 帶正負號的驅動程式
   允許Microsoft模式	允許Microsoft模式授權下列元件： 預設 Windows 模式允許的所有程式代碼，加上... 所有Microsoft簽署的軟體
   帶正負號且可繼續運作的模式	已簽署和可信譽模式會授權下列元件： 允許Microsoft模式允許的所有程序代碼，再加上...< 由設定為受控安裝程序的進程所建立或安裝的檔案 每個 Microsoft Defender 的 Intelligent Security Graph 技術都具有良好信譽的檔案

   Alice 會選取 [ 已簽署且可吞吐量] 模式 範本，然後選取 [ 下一步]，接受原則檔名和位置的預設值。

4. 在 [設定原則範本 - 原則規則] 上，Alice 會檢閱為原則啟用的選項集。 範本已依照Microsoft的建議設定大部分選項。 Alice 所做的唯一變更是檢查 Managed Installer 和 Require WHQL 的選項。 如此一來，Intune 或其他任何受管理安裝程式所安裝的應用程式會自動允許，而且只能執行針對 Windows 10 或更新版本建置的核心驅動程式。 選取 [下一步 ] 會推進精靈。

   

5. [ 檔案規則] 頁面會顯示來自 [已簽署] 和 [可信譽] 模式範本原則的規則。 Alice 會新增簽署者規則來信任 Lamna 簽署的程式代碼，以及 filepath 規則，以允許程式代碼位於兩個 Program Files 目錄、Windows 目錄和 Lamna 的 Helpdesk 資料夾底下的僅限 admin-writable 位置。

   若要建立每個規則，Alice 會選取 [+ 新增自定義 ]，以開啟定義規則條件的 [ 自定義 規則] 對話方塊。 針對第一個規則， 規則範圍 和 規則動作 的預設選取專案是正確的。 針對 [ 規則類型] 下拉式清單， [發行 者] 選項是建立簽署者規則的正確選擇。 Alice 接著選取 [ 流覽 ]，然後挑選由 Lamna Codesigning PCA 所簽發憑證簽署的檔案。 精靈會顯示從資源標頭區段提取的簽章資訊 (檔案的 RSRC) ，例如 產品名稱 ，以及每個元素具有複選框的 原始檔名 。 在此情況下，由於 Alice 想要允許以 Lamna 的內部程式代碼簽署憑證簽署所有專案，因此 Alice 只會核取 [發行 CA ] 和 [發行者 ]。 設定 Lamna Codesigning PCA 規則的規則條件後，Alice 會選取 [ 建立規則 ]，並看到規則包含在清單中。 Alice 會針對 Lamna 的其餘自定義規則重複這些步驟。

   

6. 現在，虛擬規則中所述的所有編輯都已完成，Alice 選取 [ 下一步 ]，精靈會建立應用程控原則檔案。 輸出檔案包含 XML 窗體和原則的已編譯二進位形式。 Alice 會對 XML 原則檔案進行大略檢閱，以確認結果看起來不錯，然後關閉精靈。

Alice 會將這兩個檔案上傳至專為 Lamna 的應用程控原則檔案所建立的 GitHub 存放庫。

Alice 的入門原則現在已準備好以稽核模式部署至 Lamna 的受控裝置。

此原則的安全性考慮

為了盡可能降低對用戶生產力造成負面影響的可能性，Alice 定義了一個原則，讓安全性與使用者應用程式彈性之間有幾項取捨。 一些取捨包括：

• 具有系統管理存取權的使用者

  這種取捨是最具影響力的安全性取捨。 它可讓裝置使用者或以使用者許可權執行的惡意代碼，修改或移除裝置上的應用程控原則。 此外，系統管理員可以將任何應用程式設定為受控安裝程式，這可讓他們獲得任何應用程式或二進位檔的持續性應用程式授權。

  可能的緩和措施：

  • 若要防止竄改應用程控原則，請在執行統一可延伸韌體介面 (UEFI) 韌體的系統上使用已簽署的應用程控原則。
  • 若要移除信任受管理安裝程式的需求，請建立和部署已簽署的類別目錄檔案，或將更新的原則部署為一般應用程式部署和應用程式更新程式的一部分。
  • 若要控制對其他公司資源和數據的存取，請使用來自受信任運算群組的應用程式控制組態狀態的開機時間度量 (TCG) 記錄與裝置證明。

• 不帶正負號的原則

  以系統管理員身分執行的任何進程都可以取代或移除未簽署的原則，而不會產生任何結果。 同樣地，不帶正負號的補充原則可以改變包含選項 17 Enabled：Allow Supplemental Policies 之未簽署基底原則的「信任圈」。

  可能的緩和措施：

  • 若要防止竄改應用程控原則，請在執行 UEFI 韌體的系統上使用已簽署的應用程控原則。
  • 若要將風險降至最低，請限制可在裝置上提升給系統管理員的人員。

• Managed 安裝程式

  請參閱 Managed安裝程式的安全性考慮

  可能的緩和措施：

  • 若要移除信任受管理安裝程式的需求，請建立和部署已簽署的類別目錄檔案，或將更新的原則部署為一般應用程式部署和應用程式更新程式的一部分。
  • 若要將風險降至最低，請限制可在裝置上提升給系統管理員的人員。

• Intelligent Security Graph (ISG)

  請參閱 Intelligent Security Graph 的安全性考慮

  可能的緩和措施：

  • 若要移除信任 ISG 的需求，請對現有的應用程式使用量和安裝執行全面的稽核。 將您發現目前未受管理的任何應用程式上線至您的軟體發佈解決方案，例如 Microsoft Intune。 實作原則以要求應用程式由IT管理。 然後從 ISG 轉換為受管理的安裝程式、已簽署的類別目錄檔案和/或更新的原則規則，並將其部署為一般應用程式部署和應用程式更新程式的一部分。
  • 若要收集更多數據以用於安全性事件調查和事件後檢閱，請在稽核模式中部署嚴格限制的應用程控原則。 在應用程控事件記錄檔中擷取的數據，包含所有未由 Windows 簽署執行之程式代碼的實用資訊。 若要防止原則影響您的裝置效能和功能，請確定它最少允許在開機程式中執行的 Windows 程式代碼。

• 補充原則

  補充原則的設計目的是要擴充基底原則所定義的「信任圈」。 如果基底原則也未簽署，則以系統管理員身分執行的任何程式都可以放置未簽署的補充原則，並無限制地展開基底原則的「信任圈」。

  可能的緩和措施：

  • 使用已簽署的應用程控原則，只允許經過授權的已簽署補充原則。
  • 使用限制性稽核模式原則來稽核應用程式使用量和增強弱點偵測。

• FilePath 規則

  查看 檔案路徑規則的詳細資訊

  可能的緩和措施：

  • 限制可在裝置上提升給系統管理員的人員。
  • 從檔案路徑規則轉換為 Managed 安裝程式或以簽章為基礎的規則。

• 已簽署的惡意代碼

  單獨簽署程式代碼並非安全性解決方案，但它確實提供兩個重要的建置組塊，讓應用程控等安全性解決方案成為可能。 首先，程式代碼簽署會將程式代碼與真實世界的身分識別建立強烈關聯...而真實世界的身分識別可能會面臨無名、陰影的圖形不負責不帶正負號惡意代碼的後果。 其次，程式代碼簽署會提供密碼編譯證明，讓執行中的程式代碼在發行者簽署后保持未受控。 需要簽署所有程式代碼或原則明確允許的應用程控原則會引發攻擊者的風險和成本。 但是，有動機的攻擊者仍有一些方法可以簽署並信任其惡意代碼，至少一段時間。 即使軟體來自可信任的來源，也不表示它是安全的執行。 任何程式代碼都可以公開惡意執行者可能利用其惡意意圖的強大功能。 弱點會將最良性的程式代碼轉換成真正危險的程序代碼。

  可能的緩和措施：

  • 使用具有即時保護的可靠反惡意代碼或防病毒軟體，例如 Microsoft Defender，以保護您的裝置免於遭受惡意檔案、廣告軟體和其他威脅。

您接下來應該閱讀的內容

• 深入瞭解受管理的安裝程式：其運作方式、設定方式，以及其在 自動允許受管理安裝程式部署的應用程式中的限制。

• 瞭解如何部署入門原則，並在 部署商務用應用程控原則中查看其運作方式。