安全性的架構及設計檢閱

知道當對架構設計執行徹底的檢閱時應該提出什麼問題。

分析 Web 應用程式架構及設計。

發展及加強現行安全性檢閱辦法。

在設計階段建立一個程序來修補弱點。

識別關鍵應用程式部署及架構安全性考慮事項。

確保順利與安全的 Web 應用程式部署。

將安全性檢閱整合到架構設計程序中。儘快開始，當設計變更時，使用本單元指定的步驟來檢閱異動。

發展安全性檢閱。本單元提供為加強設計的安全性所提出的問題。若要完成此檢閱程序，也需要加入對您獨特應用程式的特定問題。

瞭解可能的潛在威脅。單元 2＜潛在威脅及因應對策＞，列出會影響應用程式中不同元件和層級的潛在威脅。必須瞭解這些潛在威脅才能加強檢閱程序的結果。

「部署及架構」。檢視有關於目標部署環境及相關安全性原則的應用程式設計。同時考慮基礎架構層級安全性所加諸的限制。

應用程式結構及設計。檢視應用程式中關鍵區域的方法，包括驗證、授權、輸入驗證、例外管理、和其他區域。可以使用應用程式弱點類別作為藍圖，以確認在檢閱時沒有遺漏任何關鍵區域。

逐層分析。逐步走過應用程式的各個邏輯層，並且檢查 ASP.NET 網頁及控制元、Web 服務、服務元件、Microsoft .NET 遠端服務、資料存取程式碼、和其他的安全性。

網路是否可以提供安全的通訊？

您的部署拓樸是否包括內部的防火牆？

您的部署拓樸是否包括遠端應用程式伺服器？

架構的安全性加諸了什麼限制？

您是否有考慮 Web 伺服器陣列問題？

目標環境支援什麼樣的信任等級？

下游伺服器如何驗證 Web 伺服器？

如果使用網域帳戶及 Windows 驗證，防火牆是否有開啟需要的連接埠？如果不是，或如果 Web 伺服器及下游伺服器是在不同的網域，可以使用鏡像的本機帳戶。例如，可以複裝最小權限本機 ASPNET 帳戶，用來執行在資料庫伺服器上的 Web 應用程式。

您是否使用分散式交易？

如果 Web 伺服器使用 Microsoft 分散式交易協調器 (DTC) 的服務啟始分散式交易，內部的防火牆是否有開啟 DTC 通訊需要的連接埠？

有關使用 DTC 通過防火牆的詳細資料，請參閱 Microsoft 知識庫文件 250367《INFO: Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall (英文)》網址為：
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q250367。

您是否有使用 Enterprise Services？
如果有的話，是否有限制 DCOM 連接埠的範圍，以及是否有任何內部的防火牆開啟了這些連接埠？

「注意事項」：在一些狀況下，使用中間層 Web 服務做為 Enterprise Services 應用程式的前端是絕佳的設計選擇。使用這個方法，Web 伺服器可以經由連接埠 80 使用簡易物件存取通訊協定 (SOAP) 來和應用程式伺服器彼此通訊。

如需詳細資訊，請參閱下列 Microsoft 知識庫文件：

您是否有使用 .NET 遠端服務？
遠端服務是設計來用在受信任的伺服器的狀況下。網路是否支援 IPSec 原則，以確保只有 Web 伺服器可以存取中間層遠端服務元件？ASP.NET 是否主控遠端元件以支援驗證及授權？

您是否有使用 Web 服務？
如果有的話，中間層 Web 服務如何驗證 Web 應用程式？Web 應用程式是否在 Web 服務 proxy 設定憑證，使 Web 服務可以驗證 Web 伺服器？如果不是的話，Web 服務如何識別呼叫者？

所依靠的服務或通訊協定是否可能會不可用？
在開發及測試環境中可用的服務及通訊協定，在生產環境中不見得可用。和負責架構安全性的小組溝通以瞭解限制及需求。

您是否有依賴機密的帳戶權限？
設計應該使用最小權限程序、服務、和使用者帳戶。是否需要有不被允許的機密權限來執行操作？

例如，應用程式是否需要建立執行緒層級的模擬權杖以建立服務識別身份來存取資源？這需要「充當部分作業系統」的權限，因為與入侵處理程序有關的安全性風險日益增加，因此該權限不應該賦予 Web 伺服器的處理程序。如果需要此項功能，設計上應該區隔化較高的權限，例如，在程序之外的 Enterprise Services 應用程式。

您如何管理工作階段狀態？
在 Web 伺服器陣列的狀況下，不能在 Web 伺服器上管理工作階段狀態。相反的，在設計上應該在陣列所有 Web 伺服器會共同存取的伺服器上加入遠端狀態存放區。有關更多詳細資訊，請參閱本單元稍後的「工作階段管理」。

您是否有使用機器專屬的加密金鑰？
如果計劃加密共用資料來源中的資料，例如資料庫，在陣列所有機器上的加密及解密金鑰必須相同。檢查設計上沒有要求需要機器相似性的加密機制。

您是否有使用表單驗證或受保護檢視狀態？
如果是的話，您信任 <machine key>設定。在 Web 伺服器陣列的狀況下，必須在所有伺服器上使用通用金鑰。

您是否有使用 Secure Sockets Layer (SSL)？
如果使用 SSL 加密瀏覽器和 Web 伺服器之間的資料傳輸，在何處終止 SSL 連線？可行的選項包括 Web 伺服器、有加速卡的 Web 伺服器、或有加速卡的負載平衡器。在有加速卡的負載平衡器上終止 SSL 工作階段通常會提供最佳的效能，特別是對有大量連線的站台。

如果在負載平衡器上終止 SSL，從負載平衡器到 Web 伺服器之間的網路資料傳輸就沒有加密。這表示攻擊者可以竊聽在負載平衡器和 Web 伺服器之間傳輸的已解密網路資料傳輸。可以確保 Web 伺服器環境中實體設備的安全性，或使用 IPSec 原則提供的傳輸層級加密來保護內部的資料中心連結，以應付這個潛在威脅。

您如何驗證輸入資料？

您如何處理輸入資料？

您是否知道您的進入點？
確認設計上有識別應用程式的進入點，如此才能追蹤個別輸入欄位發生了什麼。考慮網頁輸入、輸入到元件及 Web 服務、和來自資料庫的輸入。

您是否知道您的信任界限？
如果輸入是來自在信任界限之內的受信任來源就不一定要驗證輸入，但是如果輸入是來自非信任的來源就要強迫驗證。

您是否有驗證網頁輸入？
不要認為一般使用者是資料的受信任來源。確認有驗證標準和隱藏的表單欄位、查詢字串、及 Cookie。

您是否有驗證傳到元件或 Web 服務的引數？
唯一不這樣做而安全的例子是資料來自現行的信任界限之內。然而，在潛在防衛策略下，建議使用多層驗證。

您是否驗證擷取自資料庫的資料？
如果有別的應用程式也寫入到這個資料庫的話，應該也要驗證這種形式的輸入。不要假設其他的應用程式已經做了徹底的輸入驗證。

您是否使用集中式的方法？
對輸入欄位的一般類型，檢查是否使用一般驗證和篩選程式庫以確保執行一致的驗證規則。

您是否倚賴用戶端的驗證？
請不要。用戶端驗證可用來減少到伺服器的來回次數，但是因為它很容易被跳過，所以不能倚賴做為安全性的依靠。驗證伺服器上所有的輸入。

您的應用程式是否容易受到標準化問題的影響？
檢查應用程式是否使用基於輸入的名稱來做安全性的決定。例如，應用程式是否接受使用者姓名、檔案名稱、或 URL？標準化問題的惡名昭彰，因為一個名稱可以用許多方式來表示。如果應用程式接受名稱做為輸入，在進一步處理之前請檢查它們已經過驗證並轉換成標準的表示法。

您的應用程式是否容易受到 SQL 注入的影響？
請密切注意用來組成 SQL 資料庫查詢的任何輸入欄位。檢查這些欄位已適當地驗證類型、格式、長度、和範圍。同時也檢查這些查詢是如何產生的。如果使用參數化的預存程序，輸入參數會被視為文字而非可執行的程式碼。這可以有效的減輕風險。

您的應用程式是否容易受到 XSS 攻擊的影響？
如果在 HTML 輸出串流中包含輸入欄位，就容易受到 XSS 的影響。檢查輸入是否有經過驗證以及輸出是否有編碼。密切注意接受一個範圍 HTML 字元的輸入欄位被如何處理。

您是否有隔離公共和限制存取？

您是否有識別服務帳戶的需求？

您如何驗證呼叫者？

您如何使用資料庫驗證？

您是否有強制實施增強式帳戶管理實作？

設計是否需要最小權限帳戶？
是否已識別哪個資源和操作需要哪個權限？檢查設計精確地識別每一個帳戶執行它特定的功能所需要的權限，以及在所有的狀況下都使用最小權限帳戶。

應用程式是否需要維護服務帳戶憑證？
如果是的話，確認憑證有加密並保存在限制的位置，例如有限制存取控制清單 (ACL) 的登錄機碼。

您是否有在網路連線上傳遞純文字憑證？
如果使用表單或基本驗證，或如果使用 Web 服務且在 SOAP 標頭傳遞憑證，請確認在傳送時使用 SSL 來保護憑證。

您是否有實施自已的使用者存放區？
如果是的話，檢查使用者憑證會儲存在何處以及如何儲存。一般的錯誤是在使用者存放區儲存純文字或加密密碼。相反的，應該儲存用來做確認的密碼雜湊。

如果驗證 SQL Server 使用者存放區中的憑證，請密切注意輸入的使用者名稱和密碼。檢查 SQL 字元的惡意注入。

您是否有使用表單驗證？
如果有的話，除了使用 SSL 來保護憑證外，使用 SSL 來保護驗證 Cookie。同時也檢查在設計上使用限制工作階段存留期以反制 Cookie 重新執行攻擊的潛在威脅，並且檢查 Cookie 有加密。

有關表單驗證的更多詳細資訊，請參閱單元 10＜建置安全的 ASP.NET 網頁和控制項＞及單元 19＜保障 ASP.NET 應用程式及 Web 服務的安全＞。

您是否有使用 SQL 驗證？
在理想狀況下，設計使用 Windows 驗證來連結到 SQL Server，因為這是一個原本就比較安全的方法。如果使用 SQL 驗證，檢查計劃如何在網路上及在資料庫連結字串中保障憑證的安全。

如果網路架構不提供 IPSec 加密通道，確認在提供自動 SQL 憑證加密的資料庫上安裝了伺服器憑證。同時也檢查計劃如何保障資料庫連結字串的安全，因為這些字串中包含了 SQL 帳戶使用者名稱和密碼。

您是否有使用處理程序帳戶？
如果使用應用程式的處理程序帳戶並使用 Windows 驗證連結到 SQL Server，確認設計上採用最小權限帳戶。本機 ASPNET 帳戶就是為這個目的所提供的，雖然使用本機帳戶，仍需要在資料庫伺服器上建立複製帳戶。

如果計劃使用網域帳戶，確認其為最小權限帳戶並檢查所有在中間的防火牆有開啟相關的連接埠來支援 Windows 驗證。

您是否有使用服務帳戶？
如果在設計上需要有多重的識別身份來支援資料庫中更多漸進等級的授權，檢查計劃如何儲存帳戶憑證 (理想狀況下是使用 Data Protection API (DPAPI) 加密並保存在安全的登錄機碼內) 和將如何使用服務識別身份。

同時也檢查那一個處理程序會被用來使用服務帳戶建立模擬安全性內容。這不應該由 Microsoft Windows 2000 上的 ASP.NET 應用程式處理程序來完成，因為它會強迫增加處理程序帳戶的權限並且賦予「充當部分作業系統」的權限。這應該被避免因為會大幅增加風險的因素。

您是否有考慮使用匿名 Internet 使用者識別身份？
對於使用表單或 Passport 驗證的應用程式，可以針對每一個應用程式設定不同的匿名使用者帳戶。接下來，可以啟用模擬然後使用匿名識別身份來存取資料庫。這個方法適用於在相同 Web 伺服器上不同應用程式的分開授權和識別身份追蹤。

您是否有使用原始使用者的識別身份？
如果設計上要求模擬原始呼叫者，需要考慮到方法在連結集區無效時是否可提供足夠的擴充性。替代方案是將原始呼叫者的識別身份透過受信任的查詢參數保留至應用程式層級。

您如何儲存資料庫連結字串？
如果資料庫連結字串是硬式編碼或以純文字儲存在組態檔案或 COM+ 目錄中，會容易受到攻擊。相反的，應該將其加密或限制到加密資料的存取。

有關連結到 SQL Server 的不同選項和安全地儲存資料庫連結字串的更多詳細資料，請參閱單元 14＜建置安全的資料存取＞。

您的應用程式是否強制實施增強式密碼？
例如，ASP.NET 網頁是否使用規則運算式來確認密碼複雜性規則？

您是否有限制失敗登入嘗試的次數？
如此做可以幫助反制字典攻擊的潛在威脅。

您在失敗事件中是否洩露了太多的資訊？
請確認沒有顯示類似「不正確的密碼 (Incorrect password)」的訊息，因為這會告訴有惡意的使用者「使用者名稱」是正確的。這會使得他們將努力集中在破解密碼。

您是否有強制實施定期變更密碼？
建議如此做，否則很有可能使用者不會變更他們的密碼，而容易受到攻擊。

您是否能夠在入侵事件時快速地停用帳戶」？
如果帳戶被入侵，是否可很容易地停用該帳戶以防止攻擊者繼續利用？

您的應用程式是否有記錄登入的嘗試？
記錄失敗的登入嘗試是偵測嘗試闖入的攻擊者的有效方法。

您如何授與權限給一般使用者？

您如何授與權限給資料庫中的應用程式？

您如何限制對系統層級資源的存取？

您是否有使用潛在防衛策略？
確認設計上沒有依賴單一的閘道管理來強制實施存取控制。考慮如果閘道管理失敗或攻擊跳過它的時候會發生什麼。

您有使用哪些閘道管理？
可行的選項包括 IIS Web 權限、NTFS 權限、ASP.NET 檔案授權 (僅適用於 Windows 驗證)、URL 授權、和主要權限要求。如果沒有使用某些類型，確認原因為何。

您是否有使用以角色為主的方法」？
如果是的話，如何維護角色清單以及管理介面要做到多麼安全？

您的角色是否提供足夠的權限分隔？
設計是否提供足夠的細微性，讓獨特使用者角色的相關權限足以區分？避免只為了滿足某些使用者的需求而對角色賦予高存取權限的狀況。考慮用增加新角色來取代。

應用程式是否有使用預存程序存取資料庫？
建議使用，因為應用程式的登入只能被授予存取特定預存程序的權限。登入可以被限制對資料庫執行直接建立/讀取/更新/刪除 (CRUD) 的作業。

這對安全性有利，同時對效能和未來的可維護性也有益處。有關資料庫授權方法的更多詳細資料，請參閱單元 14＜建置安全的資料存取＞。

您的設計是否有使用程式碼存取安全性？
程式碼存取安全性提供資源限制模型，可以防止程式碼 (及 Web 應用程式) 存取特定類型的系統層級資源。當使用程式碼存取安全性時，難免會影響到設計。識別是否要在設計計劃中納入程式碼存取安全性，然後設計隨著隔離及沙箱特殊權限程式碼，並將資源存取程式碼置入其各自分別的組件中。

您的應用程式使用什麼識別身份？
設計應該識別應用程式所使用的所有識別身份，包括處理序識別身份，以及任何的模擬識別身份，包括匿名 Internet 使用者帳戶和服務識別身份。設計應該也要指出這些識別身份需要存取哪些資源。

在部署時期，可以在系統層級資源設定適當的 ACL，以確保應用程式的識別身份只能存取到所需的資源。

有關程式碼存取安全性設計的更多詳細資訊，請參閱單元 9＜配合 ASP.NET 使用程式碼存取安全性＞。

您是否有支援遠端管理？

您是否有保障組態存放區的安全？

您是否有區分系統管理員權限？

您是否有使用增強式的驗證？
管理介面的所有使用者都需要驗證。使用增強式驗證，例如 Windows 或用戶端憑證驗證。

您是否有加密網路資料傳輸？
使用加密的通訊通道，例如由 IPSec 或虛擬私人網路 (VPN) 連線所提供的。不要在不安全的通道上支援遠端管理。IPSec 容許限制管理伺服器的識別身份和用戶端機器的數量。

您的組態存放區是否在 Web 空間？
組態資料檔案如果是放在 Web 空間內被認為是較放在 Web 空間外不安全。主機組態錯誤或未被發現的問題，可能容許攻擊者在 HTTP 上擷取並下載組態檔案。

在組態存放區中的資料安全嗎？
確認組態資料的關鍵項目，例如資料庫連結字串、加密金鑰、和服務帳戶憑證在存放區中有加密。

您如何限制到組態存放區的存取？
檢查管理介面有提供必要的授權以確保只有已驗證的系統管理員才能存取和操作資料。

您是否有儲存機密？

您如何儲存機密資料？

您是否有在網路上傳送機密資料？

您是否有記錄機密資料？

您是否可避免儲存機密？
如果使用替代實作技術，可以移除儲存機密的需求。例如，如果要做的是確認使用者知道密碼，並不需要儲存密碼。儲存單向密碼雜湊來代替。

同樣的，如果使用 Windows 驗證，可以使用嵌入憑證避免儲存連結字串。

您如何儲存機密？
如果使用加密，如何保障加密金鑰的安全？考慮使用平台提供的 DPAPI 加密來負責金鑰管理。

您將機密儲存在何處？
檢查應用程式如何儲存加密資料。針對最高安全性，應該使用 Windows ACL 來限制加密資料的存取。檢查應用程式沒有以純文字或在原程式碼中儲存機密。

如果使用「本機安全性註冊 (LSA)」，程式碼必須執行系統管理員的權限才能擷取機密，因而增加風險。不需要延伸權限的替代方案是使用 DPAPI。

您如何處理機密？
檢查應用程式如何存取機密，以及純文字形態的機密在記憶體中會保留多久。通常應該根據需要來擷取機密，盡可能在最短的時間內使用它，然後馬上丟棄。

您是否在 Cookie 中儲存機密？
如果是的話，確認 Cookie 有加密而且不是存留在用戶端的電腦中。

您使用什麼加密演算法？應該使用有大型金鑰的增強式加密演算法來加密資料，例如 Triple DES。

您如何保障加密金鑰的安全？只有加密金鑰安全時資料才安全，檢查如何保障金鑰的安全。在理想狀況下，使用 DPAPI 來加密金鑰並將其安全的保存於受限制的位置，例如，登錄機碼。

工作階段識別元如何進行交換？

您是否有限制工作階段的存留期？

您如何保障工作階段狀態存放區的安全？

您是否有在未加密的通道上傳送工作階段識別元？
如果使用工作階段識別元來追蹤工作階段狀態 - 例如，包含在 cookie 中的權杖 - 檢查識別元或 Cookie 僅在加密的通道上進行傳遞，例如 SSL。

您是否有加密工作階段 Cookie？
如果使用表單加密，請確認應用程式使用 <forms>元素上的「protection="All"」屬性來加密驗證 Cookie。除了 SSL 之外，建議使用這個實作來減輕 XSS 攻擊偷取使用者驗證 Cookie 的風險。

您是否有在查詢字串中傳送工作階段識別元」？
確認應用程式沒有在查詢字串中傳送工作階段識別元。在用戶端可以很容易地修改這些字串，而容許使用者以另一使用者的身份存取應用程式、存取其他使用者的私人資料、和可能提升權限。

您為何使用特別的演算法？

您如何保障加密金鑰的安全？

您是否有開發自己的密碼編譯？
請不要。密碼編譯演算法和常式難以開發成功和做正確是有名的。自訂的實作經常會導致安全性不足的保護，而且幾乎都比已證明的平台提供服務不安全。

您是否有使用適當金鑰大小的正確演算法？
檢查應用程式使用什麼演算法以及為什麼目的而用。大型金鑰會增強安全性，但是效能會受損。在延長時間內，增強式加密演算法對於保留在資料存放區中的持續性資料是最重要的。

您如何保障加密金鑰的安全？
如果使用 DPAPI，平台會為您管理金鑰。否則，應用程式會負責管理金鑰。檢查應用程式如何保護加密金鑰。一個好的方法是使用 DPAPI 來加密其他形式加密所需的加密金鑰。然後安全地儲存加密金鑰，例如，將其放在設定有限制 ACL 的登錄機碼之下。

金鑰多久會回收重複使用？
不要濫用金鑰。使用相同金鑰的時間越長，就越可能被發現。設計是否有考慮如何和多久回收金鑰，以及如何散發金鑰和安裝在伺服器上？

您是否有驗證所有的輸入參數？

您是否有在參數中傳送機密資料？

您是否有將 HTTP 標頭資料使用於安全性？

您是否為有機密資料的 Cookie 加密？
如果應用程式使用的 Cookie 中含有機密資料，例如使用者名稱或角色清單，確認有將其加密。

您是否有在查詢字串或表單欄位中傳送機密資料？
不建議如此做，因為防止查詢字串或表單欄位中的資料被操作並不簡單。相反的，考慮使用加密工作階段識別元以及在伺服器的工作階段狀態存放區儲存機密資料。

您是否有保護檢視狀態？
如果網頁或控制元使用檢視狀態來維護 HTTP 要求之間的狀態，檢查有將檢視狀態加密並使用訊息驗證碼 (MAC) 來檢查完整性。這個可以在機器層級或在逐頁的基礎加以設定。

您是否有使用結構化的例外處理？

您是否有洩露太多資訊給用戶端？

您是否有在伺服器上捕捉、處理、和記錄例外？
確認應用程式沒有讓內部的例外狀況傳播到應用程式界限之外。應該在伺服器上捕捉和記錄例外，如果需要，一般性的錯誤訊息應該回覆給用戶端。

您是否有使用集中式的例外管理系統？
在整個應用程式中一致性地處理和記錄例外的最佳方法，是使用正式化的例外管理系統。也可以將這個系統連接到監測系統，供作業小組用來監控狀態及效能。

您是否有定義一組自訂錯誤訊息？
設計上應該定義自訂錯誤訊息，以供應用程式發生嚴重錯誤時使用。確認其中沒有包括任何可被惡意使用者利用的機密資料項目。

有關設計及實作 .NET 應用程式的例外管理架構，請參閱 MSDN 文章，《Exception Management Architecture Guide (英文)》網址為：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/exceptdotnet.asp。

您是否有對識別金鑰活動進行稽核？

您是否有考慮如何保留原始呼叫者識別身份？

您是否有考慮安全的記錄檔案管理原則？

您是否有稽核失敗的登入嘗試？
這容許您偵測非法入侵和密碼破解的嘗試。

您是否有稽核其他的金鑰作業？
檢查有稽核其他金鑰事件，包括資料擷取、網路通訊、和管理功能 (例如啟用和停用記錄)。

您是否有跨不同應用程式層進行稽核？
檢查是否每一層的稽核活動都正常進行。

您如何同步處理多個記錄？
記錄檔案需要有合法的程序來證明個體所做的壞事，或解決否認的案件。如果稽核是在資源存取的時間而且是經由存取資源的相同常式所產生的，通常稽核被認為是最可靠的。確認在記錄檔案中的應用程式設計因素有同步，並且記錄某些要求識別元格式以確認不同記錄檔案的項目互相關聯而且相關回溯到同一要求。

您如何保留原始呼叫者識別身份？
如果不在作業系統層級保留原始呼叫者識別身份，例如，因為方法擴充性的限制，請識別應用程式如何保留原始呼叫者識別身份。對跨層的稽核這是必要的 (對授權可能也是)。

同樣的，如果多個使用者對應到同一個應用程式角色，檢查應用程式有記錄原始呼叫者的識別身份。

如需設計、建置及設定驗證、授權及在分散式 Web 應用程式各層間安全通訊的詳細資料，請參閱《建置安全的 ASP.NET 應用程式: 驗證、授權和安全通訊》網址為：http://www.microsoft.com/taiwan/msdn/books/ataglance/secnetlpMSDN.htm>。

如需可列印的檢查清單，請參閱本指南＜檢查清單＞章節中的＜檢查清單：架構及設計檢閱＞。