在家庭和公司環境中，使用標准用戶帳戶可以提高安全性並降低總體擁有成本。當用戶使用標准用戶權限(而不是管理權限)運行時，系統的安全配置(包括防病毒和防火牆配置)將得到保護。這樣，用戶將能擁有一個安全的區域，可以保護他們的帳戶及系統的其余部分。對於企業部署，桌面 IT 經理設置的策略將無法被覆蓋，而在共享家庭計算機上，不同的用戶帳戶將受到保護，避免其他帳戶對其進行更改。
但是，很久以來，Windows 的用戶一直都在使用管理權限運行。因此，軟件通常都開發為使用管理帳戶運行，並且(通常無意間)依賴於管理權限。為了讓更多軟件能夠使用標准用戶權限運行，並且幫助開發人員編寫能夠使用標准用戶權限正常運行的應用程序，Windows Vista 引入了用戶帳戶控制 (UAC)。UAC 集成了一系列技術，其中包括文件系統和注冊表虛擬化、受保護的系統管理員 (PA) 帳戶、UAC 提升權限提示，以及支持這些目標的 Windows 完整性級別。我在我的會議演示文稿和 TechNet 雜志UAC 內部信息一文中詳細討論了這些內容。
Windows 7 沿用了 UAC 的目標，基礎技術相對未做改變。但是，它引入了 UAC 的 PA 帳戶可以運行的兩種新模式，以及某些內置 Windows 組件的自動提升機制。在此文章中，我將論述推動 UAC 技術發展的因素、重新探討 UAC 和安全性之間的關系、描述這兩種新模式，並介紹自動提升的具體工作方式。請注意，此文章中的信息反映了
Windows 7 預發布版本的行為，該行為在許多方面與 beta 版有所不同。
UAC 技術
UAC 技術的最基本元素和直接效益在於它能使標准用戶更方便地使用 Windows。演示示例展示了 Windows XP 和 Windows Vista 上有關設置時區的權限要求的不同之處。在 Windows XP 上，更改時區需要管理權限，實際上，即使是使用時間/日期控制面板小程序查看時區也需要管理權限。
這是因為 Windows XP 未將更改時間(安全敏感的系統操作)與更改時區(只是影響時間的顯示方式)區分開來。在 Windows Vista(和 Windows 7)中，更改時區不是一項管理操作，並且時間/日期控制面板小程序也將管理操作與標准用戶操作進行了分隔。僅僅這一項更改就讓許多企業能夠為出差的用戶配置標准用戶帳戶，因為用戶將能夠調整時區來反映他們的當前位置。Windows 7 進一步做出了改進，比如刷新系統的 IP 地址、使用 Windows Update 來安裝可選的更新和驅動程序、更改顯示 DPI，以及查看標准用戶可訪問的當前防火牆設置。
文件系統和注冊表虛擬化在後台工作，可以幫助許多無意間使用管理權限的應用程序在沒有管理權限的情況下也能正常運行。對於不必要地使用管理權限而言，最常見的情況是將應用程序設置或用戶數據存儲在注冊表或文件系統中系統所使用的區域內。舉例來說，某些舊版應用程序將其設置存儲在注冊表的系統范圍部分
(HKEY_LOCAL_MACHINE/Software)，而不是每用戶部分 (HKEY_CURRENT_USER/Software)，而注冊表虛擬化會將嘗試寫入系統位置的操作轉到 HKEY_CURRENT_USER (HKCU) 中的位置，同時保持應用程序兼容性。
設計 PA 帳戶的目的是為了鼓勵開發人員將應用程序編寫為只需要標准用戶權限，同時使盡可能多的在管理組件和標准用戶組件之間共享狀態的應用程序能夠繼續工作。默認情況下，Windows Vista 或 Windows 7 系統上的第一個帳戶(在 Windows 的早期版本上為完全權限管理員帳戶)是 PA 帳戶。PA 用戶執行的任何程序都使用標准用戶權限運行，除非用戶明確提升了應用程序，即授予應用程序管理權限。諸如安裝應用程序和更改系統設置等用戶活動會觸發提升權限提示。這些提升權限提示是最顯著的 UAC 技術，表現形式為切換到一個包含允許/取消對話框的屏幕，背景為灰色的桌面快照。
在安裝之後創建的帳戶是標准用戶帳戶，默認情況下，這些帳戶通過一個“即時權限提升”提示提供提升功能，該提示要求提供將用於授予管理權限的管理帳戶的憑據。利用這一便捷功能，只要共享家庭計算機的家庭成員或更注重安全的使用標准用戶帳戶的用戶知道管理帳戶的密碼，他們就能夠用管理權限來運行應用程序，而不必手動切換到其他用戶登錄會話。此類應用程序的常見示例包括安裝程序以及家長控制配置。
在啟用了 UAC 後，所有用戶帳戶(包括管理帳戶)都將使用標准用戶權限運行。這意味著，應用程序開發人員必須考慮他們的軟件默認情況下將沒有管理權限這一事實。這應會提醒他們將其應用程序設計為使用標准用戶權限工作。如果應用程序或其功能的某些部分需要管理權限，它可以利用提升機制來允許用戶解鎖該功能。通常，應用程序開發人員只需進行少許更改就可讓其應用程序使用標准用戶權限正常工作。如有關 UAC 的 E7 博客文章所述，UAC 成功地改變了開發人員編寫軟件的方式。
提升權限提示的另一個優點是：它們能夠在軟件想要對系統進行更改時“通知”用戶，並使用戶有機會來阻止這種情況。例如，如果用戶不信任或不想允許修改系統的軟件包要求管理權限，則它們可以拒絕提示。
提升和惡意軟件安全性
UAC 的主要目標是讓更多用戶能夠使用標准用戶權限運行。但是，其中一項 UAC 技術看起來像是安全功能：許可提示。許多人認為，因為軟件必須要求用戶授予其管理權限，因此他們能夠防止惡意軟件獲得管理權限。提示是一種視覺暗示，它僅為其所述操作獲取管理權限，除此之外，用戶還可以切換到不同桌面來顯示提升對話框，以及使用 Windows 完整性機制，包括用戶界面特權隔離 (UIPI)，這些都使人們更加堅信這一理念。
正如在 Windows Vista 推出之前我們所談到的，提升的主要目的不是安全性，而是其方便性：如果用戶必須通過登錄到管理帳戶或通過“快速用戶切換”切換到管理帳戶，從而切換帳戶以執行管理操作，則大多數用戶都只會切換一次，而不會切換回來。更改應用程序開發人員進行設計所針對的環境將不會有進展。那麼，安全桌面和 Windows 完整性機制的目的是什麼?
為提示切換到不同桌面的主要原因是：標准用戶軟件無法“欺騙”提升權限提示，例如，它們無法通過在對話框上的發布者名稱上繪圖來欺騙用戶，讓用戶認為是 Microsoft 或另一個軟件供應商(而不是這些軟件)生成了提示，從而欺騙提升權限提示。這種替代桌面稱為“安全桌面”，因為它是系統(而不是用戶)所擁有的，就像系統顯示 Windows 登錄對話框的桌面一樣。
使用其他桌面還有一個重要目的，就是為了實現應用程序兼容性：在正在運行其他用戶擁有的應用程序的桌面上，如果內置輔助功能軟件(比如屏幕鍵盤)能夠正常工作，那麼此時就有一個第三方軟件不能正常工作。當本地系統帳戶擁有的提升對話框顯示在用戶擁有的桌面上時，該軟件將無法正常工作。
Windows 完整性機制和 UIPI 的設計目的是在提升的應用程序周圍建立一道保護性屏障。它最初的目標其中之一是防止軟件開發人員投機取巧，利用已經提升的應用程序來完成管理任務。使用標准用戶權限運行的應用程序無法將合成鼠標或鍵盤輸入發送到提升的應用程序中，以使應用程序執行其指令，也無法將代碼注入提升的應用程序以執行管理操作。
Windows 完整性機制和 UIPI 在 Windows Vista 中用於保護模式 Internet Explorer，使得感染 IE 的運行實例的惡意軟件更難於修改用戶帳戶設置，例如，將本身配置為在每次用戶登錄時啟動。盡管 Windows Vista 的一個早期設計目標是使用帶有安全桌面的提升、Windows 完整性機制和 UIPI，在使用標准用戶權限和管理權限運行的軟件之間建立一個堅不可摧的屏障(稱為安全邊界)，但由於以下兩個原因，而導致該目標未能實現，並隨之被放棄：可用性和應用程序兼容性。
首先，考慮提升對話框本身。它顯示將被授予管理權限的主要可執行文件的名稱和發布者。遺憾的是，盡管越來越多的軟件發布者為其代碼添加了數字簽名，但仍然有一些軟件發布者沒有這樣做，並且還有許多未添加簽名的舊版應用程序。對於未簽名的軟件而言，提升對話框只會顯示可執行文件的文件名，因此，對於某些惡意軟件(例如，已采用用戶帳戶運行並且正在監視未簽名 Setup.exe 應用程序安裝程序的提升)而言，將能夠將可執行文件替換為惡意的 Setup.exe，而用戶卻一無所知(請參閱圖 1)。
其次，該對話框不會告知用戶可執行文件在啟動時將會加載哪些 DLL。如果可執行文件位於用戶可以控制的目錄中，則使用用戶標准權限運行的惡意軟件將能夠替換該位置中軟件將使用的任何關聯 DLL。此外，惡意軟件可以使用並行功能，使可執行文件加載應用程序或系統 DLL 的惡意版本。並且，除非用戶警惕地單擊詳細信息按鈕，並仔細查看為提升可執行文件列出的文件路徑，否則惡意軟件可以將可執行文件復制到名稱類似的位置，例如，/ProgramFiles/Vendor/Application.exe(注意應為“Program Files”的內容中缺少的空格)，在該位置中，惡意軟件將可控制應用程序加載哪些 DLL。在圖 2 中，我已將 Microsoft 網絡監視器的一個組件復制到用戶創建的 C:/ProgramFiles 目錄(用戶可控制該目錄)，並啟動了該組件。
最後，為了實現應用程序兼容性，提升的應用程序與標准用戶環境共享實質性狀態，惡意應用程序可以使用該狀態來影響提升的應用程序的行為。就這一點而言，最直觀的示例就是用戶的注冊表配置文件 HKEY_CURRENT_USER (HKCU)。該配置文件是共享的，因為用戶希望他們作為標准用戶注冊的設置和擴展能夠在提升的應用程序中工作。惡意軟件可以使用 HKCU 中注冊的外殼擴展來加載到使用任何外殼浏覽對話框(比如“打開文件”和“保存文件”)的已提升應用程序中。其他各種狀態也是共享的，特別是基本命名對象命名空間，應用程序將在其中創建同步和共享內存對象。舉例來說，惡意軟件可以利用該共享來劫持提升的應用程序使用的共享內存對象，從而對應用程序和系統造成危害。
至於 Windows 完整性機制，由於我前面提到的提升問題，因此它作為屏障的有效性是有限的，而它還存在由於應用程序兼容性而導致的限制。舉例來說，UIPI 不會阻止標准用戶應用程序在桌面上繪圖，這一點可能會被用來欺騙用戶，采用為惡意軟件授予管理權限的方式來與提升的應用程序交互。同時，Windows 完整性機制也不能跨網絡應用。采用 PA 帳戶運行的標准用戶應用程序將能訪問 PA 帳戶具有管理權限的遠程系統上的系統資源。如果解決這些限制，將會對應用程序兼容性造成很大影響。盡管如此，我們一直在探尋提高系統安全性(例如，改善保護模式 IE)，同時解決應用程序兼容性問題並與軟件開發人員密切配合的方法。
那麼，當您在啟用了 UAC 的情況下采用 Windows Vista PA 帳戶運行時，您將得到什麼程度的惡意軟件防護?首先，請記住，要使任何這種情況發生，惡意軟件首先必須進入系統並且開始執行。Windows 具有許多深層防御功能，其中包括數據執行保護 (DEP)、地址空間加載隨機化 (ASLR)、保護模式 IE、IE 8 SmartScreen 篩選器，以及可以幫助防止惡意軟件進入系統並運行的 Windows Defender。
至於惡意軟件通過某種方式成功進入系統的情況，由於惡意軟件作者(比如合法的開發人員)假設用戶使用管理權限運行，因此大多數惡意軟件將無法正常工作。僅這一點可以被視為一種安全優勢。但是，已進入系統並且設計為可利用這些機會的惡意軟件將能夠在用戶第一次提升時獲得管理權限 — 但惡意軟件甚至不需要等待“實際”提升，因為它可以促成提升，而這種提升甚至可以欺騙最注重安全的用戶。我已經在我的 UAC 內部信息和 Windows 安全邊界演示文稿中公開演示過惡意軟件如何能夠劫持提升過程(演示位於安全邊界討論的 1 分 03 秒處)。但是，請記住，如果惡意軟件已經開始運行，它只需使用標准用戶權限就可達到惡意軟件想要達到的大部分目的，其中包括將本身配置為在每次用戶登錄時運行、竊取或刪除所有用戶的數據，或者甚至成為僵屍網絡的一部分。
Windows 7 中的不同之處
我在前面提過，Windows 7 中的某些操作現在可由標准用戶執行，但正如有關 UAC 的 E7 博客文章所述，我們還認識到，我們可以在不影響 UAC 的目標的情況下使 Windows 體驗更加流暢。許多用戶抱怨說，當他們執行常見的系統管理操作時，Windows Vista 本身會頻繁地請求管理權限。使 Windows 能夠針對標准用戶環境正常工作對我們最有利，因為這樣將為我們的客戶帶來利益。但是，提升權限提示並沒有告誡或鼓勵我們這樣做，而是會強制用戶在絕大多數用戶都不理解的對話框中再次單擊。因此，Windows 7 開始從默認 Windows 體驗中最大程度地減少這些提示，並使以管理員身份運行的用戶能夠控制其提示體驗。
為此，我們進一步重構了系統，這樣，擁有標准用戶權限的用戶將能執行更多任務，並且，我們減少了若干多提示方案(例如，在 IE 中安裝 ActiveX 控件)中的提示數量。Windows 7 還引入了兩種新的 UAC 操作模式，可以在新的 UAC 配置對話框(請參閱圖 3)中選擇這些模式。通過轉到控制面板，單擊“用戶帳戶”，單擊“用戶帳戶”，然後單擊“更改用戶帳戶控制設置”，您可以打開該對話框。(您也可以通過單擊提升權限提示上的“顯示這些通知時進行更改”鏈接或通過訪問“操作中心”來進入該對話框。)
圖 3 中顯示的默認設置就是其中一個新級別。與位於滑塊頂部並相當於 Windows Vista 中的默認模式的“始終通知”不同，只有當非 Windows 可執行文件請求提升時，Windows 7 才會默認提示用戶;針對非 Windows 提升的行為與 Windows Vista 相同。
下面接下來的滑塊位置是第二個新設置，它的標簽相同，只是後面附加了“(不降低桌面亮度)”。該模式和默認模式的唯一不同之處在於：提示將出現在用戶的桌面(而不是安全桌面)上。這樣的好處是：用戶可以在提示處於活動狀態的同時與桌面交互，但正如我之前提到的，將會出現第三方輔助功能軟件可能無法在該提示對話框上正常工作的風險。
最後，如果選擇最底部的滑塊位置，將會完全禁用 UAC 技術，這樣，所有采用 PA 帳戶運行的軟件都將使用完全管理權限運行、文件系統和注冊表虛擬化將被禁用，並且保護模式 IE 將被禁用。盡管采用此設置時將沒有提示，但保護模式 IE 的損失是此模式的一個很大的弊端。
自動提升
在采用中間兩種設置時，之所以(大多數)Windows 可執行文件的提升不會產生提示，其原因在於系統“自動提升”了 Windows 可執行文件。首先，在此上下文中，Windows 對 Windows 可執行文件的定義是什麼?答案取決於若干因素，但有兩個條件必須得到滿足：該可執行文件必須經過 Windows Publisher 的數字簽名，Windows Publisher 是用於對 Windows 附帶的所有代碼進行簽名的證書(僅由 Microsoft 進行簽名是不夠的，因此 Windows 未附帶的 Microsoft 軟件不包括在內);並且該可執行文件必須位於其中一個為數不多的“安全”目錄中。安全目錄是指標准用戶無法修改的目錄，並且它們包括 %SystemRoot%/System32(例如，/Windows/System32)及其大多數子目錄、%SystemRoot%/Ehome，以及 %ProgramFiles% 下的少許目錄(其中包括 Windows Defender 和 Windows 日記本)。
同時，視可執行文件是普通 .exe、Mmc.exe 還是 COM 對象而定，自動提升還有一些附加規則。如果 .exe 種類的 Windows 可執行文件(如前面所定義)在其清單中指定了 autoElevate 屬性，這些可執行文件將會自動提升。應用程序也將在該清單中向 UAC 指明它們需要管理權限。此處的 Sysinternals Sigcheck 實用工具通過命令“sigcheck –m %systemroot%/system32/taskmgr.exe”來轉儲任務管理器 (Taskmgr.exe) 的清單，該清單顯示任務管理器已加入自動提升，如圖 4 所示。
在目錄樹中查找自動提升可執行文件的一種簡便方法是，通過如下所示的命令使用 Sysinternals Strings 實用工具：
strings –s *.exe | findstr /i autoelevate
還有一個硬編碼列表，其中包含獲得自動提升處理的 Windows 可執行文件。這些 Windows 可執行文件也並非是 Windows 7 附帶的內部文件，因此它們必須能夠在 autoexecute 屬性會導致錯誤的舊版系統上運行。列表中包括 Migwiz.exe(遷移向導)、Pkgmgr.exe(程序包管理器)和 Spinstall.exe(Service Pack 安裝程序)。
將對 Microsoft 管理控制台 Mmc.exe 進行特殊處理，因為它承載了多個以 DLL 形式實現的系統管理管理單元。Mmc.exe 通過命令行啟動，該命令行指定一個 .MSC 文件，其中列出要加載的管理單元 MMC。Mmc.exe 將在通過 PA 帳戶啟動時請求管理權限，當 Windows 發現這一點時，它將驗證 Mmc.exe 是否為 Windows 可執行文件，然後檢查 .MSC。為了獲得自動提升資格，.MSC 文件必須滿足 Windows 可執行文件條件(由 Windows 在安全的位置中簽名)，並且必須列在自動提升 .MSC 的內部列表中。該列表實際上包括 Windows 附帶的所有 .MSC 文件。
最後，COM 對象可以通過創建一個名為 Elevation 的子項(其名為 Enabled 的值設置為 1)，利用其注冊表項中的注冊表值來指定需要管理權限。圖 5 顯示了外殼的“復制”/“移動”/“重命名”/“刪除”/“鏈接”對象的注冊表項，當用戶對其帳戶沒有權限訪問的位置執行文件系統操作時，資源管理器將使用該對象。
要使 COM 對象能夠自動提升，它還必須是 Windows 可執行文件，並且必須已由 Windows 可執行文件進行實例化。(不過，無需將實例化可執行文件標記為自動提升。)例如，當您使用資源管理器通過 PA 帳戶在 %ProgramFiles% 目錄中創建目錄時，操作將會自動提升，因為 COM 對象請求了提升、對象的 DLL 是 Windows 可執行文件，並且資源管理器是 Windows 可執行文件。
自動提升與 UAC 的目標
那麼，所有特殊自動提升規則背後的原理是什麼?選擇要自動提升哪些程序以及不自動提升哪些程序是由以下問題確定的：“應用程序開發人員是否能夠利用自動提升無意間或不費力地依賴於管理權限?”由於可以使用 Cmd.exe 通過命令行參數來執行批處理腳本，並且普通用戶不需要以提升方式運行命令提示符(大多數用戶甚至不知道命令提示符是什麼)，因此未將 Cmd.exe 列入自動提升的清單。同樣，承載控制面板插件的可執行文件 Rundll32.exe 在 Windows 7 的最終版本中也未自動提升，因為對於任何常見管理任務而言，並不需要對其進行提升，並且，如果 Rundll32.exe 進行了自動提升，則它通過命令行承載任意 DLL 的能力將會導致開發人員要求使用管理員權限，而自己卻未意識到。
自 Windows Vista 測試版發布以來，最終用戶一直在要求 Windows 提供一種向自動提升列表中添加任意應用程序的方法。經常被提及的原因是：他們常用的某個第三方應用程序強制他們不斷單擊提升權限提示，而這已經成為他們日常工作的一部分。就像 Windows Vista 一樣，Windows 7 並未提供這種功能。我們理解這種操作非常繁瑣，並且可能有這些應用程序無法在沒有管理權限的情況下運行的合理原因，但開發人員將會避免將其代碼修正為使用標准用戶權限，而這樣的風險太高。即使有關哪些應用程序進行自動提升的列表只能由管理員訪問，但開發人員只需更改其要求一次性提升的應用程序安裝程序，就可將其應用程序添加到列表中。作為替代，我們選擇進行投資來進行培訓並與應用程序開發人員密切合作，以確保其程序能夠以標准用戶身份正常工作。
很多人發現，采用 PA 帳戶通過標准用戶權限運行的第三方軟件可以利用自動提升來獲取管理權限。例如，軟件可以使用 WriteProcessMemory API 將代碼注入資源管理器，並使用 CreateRemoteThread API 來執行該代碼，這種技術稱為 DLL 注入。由於代碼在資源管理器(一種 Windows 可執行文件)中執行，因此它可以利用自動提升的 COM 對象(比如“復制”/“移動”/“重命名”/“刪除”/“鏈接”對象)來修改系統注冊表項或目錄，並為軟件授予管理權限。如果是這樣，這些步驟將需要蓄意謀劃，而且並非無關緊要，因此，與將其軟件修正為使用標准用戶權限來運行相比較，我們不相信正當的開發人員會選擇進行這些步驟。事實上，我們建議任何應用程序開發人員不要依賴於系統中的提升行為，並且建議應用程序開發人員測試其軟件在標准用戶模式下運行的情況。
接下來的發現是，惡意軟件可以使用同樣的技術獲取管理權限。同樣，情況確實如此，但正如我前面指出的，惡意軟件也可以通過提示的提升來危害系統。從惡意軟件的角度來看，Windows 7 的默認模式並不比“始終通知”模式(“Vista 模式”)安全多少，並且，采用管理權限的惡意軟件在 Windows 7 的默認模式下運行時，將仍然會崩潰。
結論
總而言之，UAC 是一組具有一個整體目標的技術：使用戶能夠以標准用戶身份運行。因為對 Windows 進行了更改，使標准用戶能夠執行以前需要管理權限的更多操作，再結合文件和注冊表虛擬化以及提示，從而共同實現了此目標。最終標准是：默認的 Windows 7 UAC 模式通過減少提示使 PA 用戶的體驗更加流暢、允許用戶控制可以修改其系統的合法軟件，並仍然實現 UAC 的目標，即讓更多的軟件能夠在沒有管理權限的情況下運行，並繼續使軟件生態系統轉變為編寫能夠使用標准用戶權限工作的軟件。
