安全性

透過軟體限制原則鎖定應用程式

Chris Corio and Durga Prasad Sayana

簡介:

• 軟體限制原則的運作方式
• 清查環境內的應用程式
• 建立及強制原則

當 IT 專業人員期望降低桌上型電腦的擁有權總成本 (即 TCO) 時，通常會聯想到兩大策略。第一個策略是將桌上型電腦的使用者帳戶

從 Administrators 群組中移除。而第二個策略是限制使用者可以執行的應用程式。在企業環境中處理這些問題可能頗具挑戰性，但是 Windows Vista® 提供了一些技術可以幫助您達成這些目標。

Windows Vista 及它的使用者帳戶控制 (UAC) 功能在幫助 IT 專業人員以 Users 群組 (標準使用者) 成員來執行企業使用者方面，可說是向前躍進了一大步。UAC 將所有應用程式的預設安全性內容變更為使用者而非系統管理員的預設安全性內容。移轉到 Users 群組的工作依舊令人畏怯，但是隨著產業開始適應這種新模型，這項工作也會隨著時間而越來越輕鬆。

分析過將使用者移到 Users 群組的挑戰之後，或是在這個過程當中，許多系統管理員都會將使用者需要執行的應用程式加以分類，並考慮只允許執行這些應用程式所需的步驟。軟體限制原則功能就是為了協助 IT 專業人員達到這個目的而設計的。

您只需指定要允許執行的應用程式，然後使用群組原則部署原則就行了。在整個企業內強制這類原則可降低 TCO，因為這種鎖定可限制有關不受支援應用程式的問題 (而且您也可以透過一些有趣且非常極端的方式來應用軟體限制原則，我們在「極簡軟體限制原則」資訊看板裡面會討論到)。

軟體限制原則的運作方式

軟體限制原則的目的是要控制使用者在 Windows Vista 電腦上到底可以執行哪些程式碼。您身為系統管理員，要建立一個原則來定義什麼可以 (或不可以) 在您的環境內執行。無論何時何處有可能執行程式碼時，便會評估這項原則。這包括在處理序建立期間、呼叫 ShellExecute 時，以及指令碼執行時 (我們稍後會詳細說明)。

如果應用程式被判定可以執行，該應用程式就會啟動。然而，若是應用程式被判定不可執行，便會封鎖該應用程式，並通知使用者。比方說，假如您嘗試從 [開始] 功能表執行 [接龍]，但它不被允許，您就會收到一個類似於 [圖 1] 的對話方塊。

[圖 1]** 當應用程式被封鎖時出現的對話方塊 **(按一下影像可放大檢視)

定義軟體限制原則的 UI 是公開在群組原則物件編輯器 (GPOE) 中，這也是編寫鎖定原則的地方。定義哪些程式碼可以執行，而哪些不行的方法有很多。原則一經完成並測試後，您就可以部署它。

定義軟體限制原則

第一個您要做的重大決定，是選擇預設的規則類型，這個決定對於軟體限制原則在您的環境內如何運作有著深遠的影響。您可以採用兩種模式之一來部署軟體限制原則：[允許清單] 或 [拒絕清單]。基本上，您是選擇要建立一個原則來描述允許在環境內執行的各個應用程式，還是要建立一個原則來定義不能執行的各個應用程式。

在 [允許清單] 模式下，您的原則中的預設規則是 [受限制的]，而且會封鎖所有您沒有明確允許執行的所有應用程式。而在 [拒絕清單] 模式下，預設的規則是 [沒有限制]，而且只會限制您明確列出的應用程式。

跟您猜的一樣，如果您想要透過應用程式鎖定大幅降低 TCO 並獲得安全性效益，[拒絕清單] 模式是不切實際的方法。要建立和維護龐大的清單來封鎖所有惡意程式碼和其他有問題的應用程式，幾乎是不可能的；因此，我們建議以 [允許清單] 模式 (也就是 [受限制的] 預設規則) 來實作軟體限制原則。

清查環境內的應用程式

如果您要設計一個原則來指定可以執行的應用程式，您必須判斷您的使用者到底需要哪些應用程式。軟體限制原則功能提供進階的記錄功能，以一個非常簡單的原則來了解您的環境內到底執行了哪些應用程式。

在您的環境裡面的樣本電腦組上，部署軟體限制原則，把預設規則設為 [沒有限制]，並確定移除所有其他規則。目的是要啟用軟體限制原則，但不允許它限制應用程式，反而只是使用它來監視正在執行的項目。

接下來，建立下列登錄值，以便啟用進階記錄功能，並將路徑設定成應該寫入記錄檔的位置：

"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>

現在，當應用程式開始執行，軟體限制原則也評估之後 (即使它允許什麼都可以執行還是會進行評估)，就會在記錄檔中寫入一個項目。

每個記錄項目都包含軟體限制原則的呼叫者及呼叫程序的處理序識別碼 (PID)、要評估的目標、找到的軟體限制原則規則類型，以及規則的識別碼。以下是當使用者按兩下 notepad.exe 時寫入的範例項目：

explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}

這個記錄檔會顯示在啟用軟體限制原則並設為封鎖應用程式時，它將檢查的每段可執行程式碼。也就是說，您必須為記錄檔中的每個項目決定是否應將它列入您的 [允許清單] 中。請注意，您會看到幾個被檢查的二進位檔是屬於 Windows® 的一部分，而且系統必須有它們才能運作。

我們在此說明的記錄方法能夠讓您清楚了解軟體限制規則在您的環境中到底會碰到哪些應用程式。但要完成這樣的工作，它並不是唯一的途徑。

內含在 Microsoft® Application Compatibility Toolkit 5.0 中的 Inventory Collector 可讓您清查環境內所使用的應用程式。這項工具提供各種不同的方法讓您探索您的環境裡面安裝了哪些應用程式，它也會將結果合併到中央資料庫中。

編寫其他規則

有了一份必須在環境內允許執行的應用程式清單，您就可以開始建立實際的規則，允許這些應用程式執行。軟體限制原則功能使用兩種方法來識別原則 — 其中之一是以應用程式的密碼編譯屬性 (例如它的雜湊) 為基礎，而另外一個則會定義信任的應用程式應該放置的信任路徑或資料夾。

[圖 2] 顯示您在 GPOE (gpedit.msc) 的 [軟體限制原則] 節點中，新增允許應用程式執行的規則的位置。在您的環境內定義應用程式最直接了當的方法，就是為您在記錄階段期間遇到的每一個二進位檔建立雜湊規則。

[圖 2]** 使用 gpedit.msc 來編寫軟體限制原則 **(按一下影像可放大檢視)

由於雜湊是針對特定的位元組集合傳回的唯一值，因此原則中的每個二進位檔都會有不同的雜湊。這種方法特別安全，而且只允許原則當中特定的二進位檔執行。

當然啦，這個方法還是有些缺點。比如說，您的環境可能很容易就會有好幾千個二進位檔。要在軟體限制原則 UI 裡面編寫所有這些規則可能不容易，而且隨著規則的數目變得特別大時，效能可能會受到影響。此外，環境內的每次應用程式更新都需要在環境中部署一或多個新的雜湊規則。在更新應用程式時更新規模這麼大的規則，負荷可能不小。

所幸，這種負荷是可以避免的，因為另外還有兩種識別規則的方法，方便在您的環境中使用軟體限制規則。若要冒險採取密碼編譯安全性一途，您可以建立一個規則來允許執行由特定憑證所簽署的二進位檔。

此舉有助於簡化原則清單的維護工作，因為當更新應用程式時，新的二進位檔通常也是由與前一個二進位檔相同的憑證進行簽署。不過，若是您不想要舊版的二進位檔在環境內執行，則必須新增 [受限制的] 雜湊規則，才能防止檔案被允許執行。

根據預設，軟體限制原則會停用憑證規則評估。必須這麼做的理由有二。

其一，軟體限制原則當中的憑證規則是由系統的 [信任的發行者] 存放區的內容定義而成。因為 [信任的發行者] 存放區的用途不光只是軟體限制原則規則而已，因此用來處理軟體限制原則功能時，需要多花時間以及多加考慮。

第二個理由是，為了判斷檔案的簽章是否有效，您必須拿檔案的雜湊與簽章資訊相比較。製作檔案的雜湊是一項非常耗用資源的作業 — 必須從磁碟讀取和處理整個檔案以計算雜湊。

若要啟用憑證規則，請瀏覽至 [軟體限制原則] 節點，並選取結果窗格中的 [強制物件]。然後按兩下以開啟它的內容對話方塊，並選取 [強制執行憑證規則] 選項按鈕。

另外一個識別程式碼的常見方法，是使用本機電腦上的程式碼路徑。這是個實際且有效率的方法，但是它有一個缺點 — 您必須小心確保資料夾上的安全性設定正確。

如果您新增特定的路徑規則，且此路徑允許使用者在該處寫入檔案 (譬如，寫到桌面)，他們只要在那個資料夾裡面放置可執行檔，就可以隨心所欲執行任何程式。然而，若是您的使用者不屬於 Administrators 群組的話，他們一般就無法修改 Program Files 或 Windows 目錄中的任何內容。這表示如果您所有的應用程式都位於 Program Files 目錄中，而且您的使用者不是系統管理員的話，那麼您應該採取路徑規則這個方法來取得簡單又有效率的原則。

路徑規則提供其他一些功能，使它比較適合某些環境。它允許萬用字元，而且可讓您使用環境變數，以便在環境內定義可攜規則 — 畢竟，對每名使用者來說，%systemdrive% 並不一定都是 c:\。

就效能與維護方面，這可能是識別程式碼最不麻煩的方法。路徑規則肯定是值得考慮使用，但是您必須注意其他安全性考量。

網路區域規則

軟體限制原則確實有包含一個稱為網路區域規則的規則類型，但是這個規則類型卻遭到非難。原本這些規則的基本概念是要識別和信任特定可執行程式碼的來源，藉此允許程式碼執行。可惜很難辦到，因此也進展的不順利。目前，軟體限制規則進入點上絕大多數的地方都沒有強制執行此規則類型。

如果大部分應用程式都是安裝在 %Program Files% 目錄，但有其他可執行檔安裝在其他地方，並且由特定的憑證簽署，使用不同類型的規則可能就蠻合理的。試試幾個雜湊規則、幾個路徑規則，就不難找到適合您的原則。

只要記住，處理規則是有順序的 (如 [圖 3]) 所示)。憑證規則最為特定，接下來是雜湊規則，再來是路徑規則，最後是內含萬用字元的路徑規則。因此，如果雜湊規則和路徑規則同時識別出一段程式碼，會以雜湊規則的安全性層級為優先。

[圖 3]** 規則處理順序 **(按一下影像可放大檢視)

強制原則

軟體限制原則功能在要保全的系統上提供的涵蓋範圍相當廣泛。整個構想是，能夠執行程式碼的任何位置都應該與軟體限制原則相整合，進而檢查該原則，查看是否允許執行可執行程式碼。

雖然檢查軟體限制原則的地方不可勝數，但最直接了當的進入點當屬 CreateProcess。在 CreateProcess 期間，會檢查原則以判斷是否允許執行表示應用程式的二進位檔。原則檢查是透過 SaferIdentifyLevel API 完成，這有公開記載。一般的程序如 [圖 4] 所示 (我們稍後會詳細討論 SaferIdentifyLevel)。

[圖 4]** 使用 SaferIdentifyLevel 來判斷二進位檔是否能夠執行 **(按一下影像可放大檢視)

CreateProcess 之後，下一個強制軟體限制原則最常用的 API 是 ShellExecute。這是當使用者在 [開始] 功能表按一下應用程式或在桌面上按兩下時呼叫的 API。

呼叫 ShellExecute 可以使用的檔案格式林林總總。以 .txt 檔案為例，在檔案上呼叫 ShellExecute 實際上並不會執行檔案 — 就技術層面來說，當然是會開啟檔案。有鑑於此，軟體限制原則包含了一份可執行檔類型清單，以便在呼叫 ShellExecute 時控制要檢查的檔案類型。您可以在軟體限制原則 UI 當中自訂這份可執行檔類型清單。

除了 CreateProcess 和 ShellExecute 之外，還有其他兩個重要的整合點：LoadLibrary 與指令碼裝載。LoadLibrary 無疑是檢查可執行程式碼一個重要的地方，但可惜的是 LoadLibrary 有一些特殊的限制。

大多數應用程式都會載入一個可執行檔和數個 DLL。而且系統上通常會執行許多應用程式。也就是說，LoadLibrary 要進行大量的原則檢查作業。視您識別程式碼的原則而定，要強制這個進入點成本可能相當高 — 想像檢查系統上載入的每個 DLL 的雜湊，這包括對二進位檔進行雜湊，然後將它與可能含有上千個雜湊的清單相比較。

這項功能預設會停用，但是可以手動啟用。要啟用的話，瀏覽至 gpedit.msc 中的 [軟體限制原則] 節點，再按兩下 [強制]。之後，再選取 [所有軟體檔案] 選項按鈕。

我們之前有提到，軟體限制原則已與系統當中大部分的指令碼裝載整合。當中包括 cmd、VBScript、Cscript 和 JScript®。這些進入點，還有其他進入點，都是使用主要的軟體限制原則強制 API：SaferIdentifyLevel。

SaferIdentifyLevel API 會查看相關軟體限制原則裡面的識別資訊，藉此判斷是否應該允許執行指定的可執行檔。這是公開記錄的 API。協力廠商指令碼裝載和可執行環境可以也應該使用它，以便與軟體限制原則相整合，如此一來，原則就可以判斷是否應該允許執行某段可執行程式碼。

以標準使用者身分執行

軟體限制原則一個較不為人知的功能，是它可以在特定應用程式啟動時篩選它們的權限。這項功能在 Windows XP 就已引進，但一直到 Windows Vista 才公開於軟體限制原則 UI 中。

在這方面，它可說是 Windows Vista UAC 的先驅，因為您可以使用它以標準使用者的身分來執行應用程式，即使使用者是 Administrators 群組的成員也一樣。當您建立規則，並在其他規則 UI 裡面將安全性層級設定為一般使用者時，就會發生這種情況。

UAC 的權杖篩選功能和軟體限制原則的一般使用者規則，兩者都是利用基本的 API，這個 API 實作的行為與 CreateRestrictedToken API 一樣。不過，整體架構在技術方面相差懸殊。但是 UAC 與軟體限制原則之間有好幾項重大差異。

首先，在有啟用 UAC 的 Windows Vista 中，每個應用程式預設都是使用類似於 Users 群組成員的安全性權杖啟動，即使使用者是系統管理員也是如此。透過軟體限制原則也可以達成，但是無法以使用者實際的系統管理員權杖來啟動應用程式 — 例如，當使用者必須安裝應用程式時。UAC 的主要優點是可以變更預設安全性內容，以及容易存取使用者的完整系統管理員權杖。

第二項差異在於，以可執行檔為例，程式碼本身會公開必要的權限層級以利正常運作。這是很重要的區別，因為獨立軟體廠商 (ISV) 和開發人員了解他們的程式碼有何需求。舉例來說，如果控制台應用程式需要有系統管理員權限才能進行編輯作業，它就可以在資訊清單中指定該項需求。因此，ISV 可以描述應用程式所需的權限，而不是在它上面強施特定的權限層級，卻沒有其他方法可以變更這個層級。

目前來說，除非您了解一般使用者的運作方式，否則最好避免使用它。UAC 是幫助將桌上型電腦使用者移出 Administrators 群組的最佳方法，而且您應該認真考慮在企業環境中保有 UAC。

當今運用的軟體限制原則

使用軟體限制原則時，有好幾個活動組件需要列入考量。但其實它跟您想的不太一樣，事實上，您可能正在使用軟體限制原則而不自知。比方說，假如您在 Windows Vista 系統上執行家長監護，其實就是使用軟體限制原則來控制應用程式的執行。

當 Windows XP 最初引進軟體限制原則時，它可說是一項重要的技術發展。但是應用程式鎖定其實才開始受到 IT 專業人員的注意。

Windows Vista 中的軟體限制原則功能還是有幾處需要琢磨，但很清楚的是，系統管理員希望有更高的掌控能力來控制環境內執行的內容。所幸對我們所有人來說，這項技術將持續精進，更方便 IT 專業人員管理他們的系統，並降低執行 Microsoft Windows 環境的成本。

極簡軟體限制原則

應用軟體限制原則的其中一種方式，就是建立原則將 Windows 鎖定到 Kiosk 模式。Microsoft 實際上推出了可建立此 Kiosk 的工具組，叫做 SteadyState™。然而，如果您只想了解如何鎖定可以執行的應用程式，有更簡單的辦法可以完成。

若要允許登入 Windows Vista 所需的最小數量應用程式組合，可建立原則允許 logonui.exe 和 userinit.exe 從 %windir%\system32 執行。大多數使用者可能也需要允許執行下列的應用程式：

dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....

如果您想要預設的 Windows 殼層，另外也要加入 %windir%\explorer.exe。

或者，您可以選擇直接開機到應用程式，例如 Internet Explorer®。在這種情況下，就有必要列出 iexplore.exe 而不是 explorer.exe。

這種極簡原則的另一方面是，您的使用者不應該屬於 Administrators 群組。這點很重要，因為如此一來，他們就無法略過原則。不過，因為他們只能執行一組非常基本的應用程式，而且沒有系統管理員的權限，所以使用者無權安裝應用程式或維護系統。

針對這些機器，您必須透過其他方式進行這些作業。如果您打算使用系統管理員帳戶從本機登入來更新和維護這些機器，您應該選取將軟體限制原則套用到除本機系統管理員以外的所有使用者的選項按鈕。原則也應該包括 consent.exe 和 cmd.exe。這會允許系統管理員從系統管理員命令提示啟動任何系統管理選項。

要注意的是，UAC 預設會限制使用者的安全性權杖的權限，藉此使它看起來不像是 Administrators 群組成員的權杖。即使您將上述設定設為不將原則套用到系統管理員，它還是會套用到使用者身上。唯有經過 UAC 提高權限體驗後，系統管理員才會真正獲得完整的系統管理員權限，也才不會套用軟體限制原則。

Chris CorioChris Corio 曾在 Microsoft 服務於 Windows 安全性小組超過五年的時間。他在 Microsoft 主要是負責應用程式安全性技術，以及保護 Windows 安全性的管理技術。您可以透過電子郵件與 Chris 連絡：winsecurity@chriscorio.com。

Durga Prasad SayanaDurga Prasad Sayana 是 Windows 核心安全性小組的軟體設計工程師兼測試人員。他的主要興趣是安全性技術和軟體測試。您可以透過電子郵件與 Durga 連絡：durgas@microsoft.com。

© 2008 Microsoft Corporation 和 CMP Media, LLC.保留所有權利；未經允許，嚴禁部分或全部複製.