本文中，我們將集中討論如何進行設計和開發，以免受到攻擊。
首先，我想介紹兩個非常好的新工具，它們是 Microsoft® 開發的，可使您的 Web 服務器獲米畬蟮陌踩?浴?IS Lockdown Tool（英文）可以最大限度地防止可能的攻擊者對您的 Microsoft® Internet Information Server (IIS) 進行訪問。鎖定工具還提供了“advanced”選項，您可以在其中選擇所需設置。此外還提供了“rollback changes”選項。當您對所做更改不滿意時可選擇該選項。請嘗試該工具。
另一個重要工具是用于 IIS 5.0 的 Hotfix Checking Tool（英文）。該工具會查詢由 Microsoft 發布的所有可用安全性修補程序的 XML 文檔（該文檔是不斷更新的），然后將此文檔與本機安裝的文檔進行比較并報告其差異。使用該工具可以更輕松地管理單個 Web 服務器或大型 Web 領域的安全修補程序。
設計問題
設計 Web 服務時必須認真考慮安全問題，以及如何能夠使遭受攻擊的危險性降到最低。許多在試圖防止攻擊時可能起作用的因素都可以在設計時予以考慮。例如考慮如何進行身份驗證，或希望返回哪類錯誤等問題。
確定安全需求
在 XML Web 服務設計的早期，您需要確定所需的安全級別。某些 XML Web 服務根本不需要身份驗證，而其他服務對于確定使用該服務的用戶有非常嚴格的要求。由 XML Web 服務接收和發送的數據需要何種隱私級別？如果某個 XML Web 服務用戶聲明他們未請求您記錄中所指明的服務，則在工時、處理能力或法律費用方面可能要花費哪些成本？
首先，讓我們來看一下身份驗證。某些種類的身份驗證會比其他身份驗證更容易遭受攻擊。在低端，如果您使用“HTTP 基本身份驗證”，則可以看到網絡上的數據包的所有用戶都能看到您的用戶名和密碼。如果通過 Internet 發送請求，則您無法控制能看到您的數據包的用戶。在身份驗證級別的高端，您可以考慮使用 SSL 客戶端證書進行身份驗證，該證書提供了一個編碼的通道，并使數據包的惡意攻擊者很難進行攻擊。有關身份驗證選項的詳細討論，請參閱 At Your Service 專欄中 Mary Kirtland 的 Authentication and Authorization（英文）。
我們已經間接提到了身份驗證過程中的隱私問題，當涉及到電子欺騙時您應考慮此問題。您還需要知道與所有從 XML Web 服務發送和接收的數據有關的隱私問題，而不僅僅是用戶名和密碼。例如，您可能會為通過身份驗證的用戶生成一個會話密鑰，該用戶將此密鑰隨每個請求一起發送以標識自身。如果此密鑰未加密發送，則數據包的惡意攻擊者可以看到此密鑰，并用它向您的 Web 服務發送自己的請求，這樣您的 Web 服務會將其看作是原來那個合法用戶。
另一個隱私問題是由 Web 服務發送和接收的簡單數據。該數據是否因其敏感性強而需要加密？SSL 加密的代價是 Web 服務會發送和接收整個加密的通道，從而降低性能。您或許可以只加密請求中的敏感項，但您隨后可能需要在客戶端上安裝自定義編寫的軟件以啟用加密/解密。使用 SSL 加密整個通道的一個優點是：目前大多數客戶端平臺都支持基本 SSL 通信，而不需要針對應用程序編寫特定代碼。
就基本安全性設計而言，還必須考慮否認的概念，即一個用戶可以拒絕承認其通過 XML Web 服務執行的操作。例如，如果您提供股票交易服務，而某些人聲稱他們沒有要求您的系統為其出售股票，并且要否認此出售命令。很明顯，與其他服務相比，某些 XML Web 服務對這種問題可能會更為關心，但是您應該確定您的服務可能會遇到的危險，以及在方案中應采取什么樣的有效措施。
使用安全的身份驗證系統肯定是避免出現這類危險的首要步驟。例如，使用 HTTP 基本身份驗證可能是不安全的，但是通過使用 SSL 的加密通道來使用此身份驗證則是安全的。如果用戶使用空密碼或容易猜到的密碼，即使具有安全的身份驗證系統也是沒有用的。強制使用強加密密碼是防止出現此類問題的重要步驟。總之，用戶和服務執行者都有責任防止密碼泄露。
最后，如果不審核通過服務發生的事件，當出現否認情況時，安全的身份驗證和強加密密碼都是毫無意義的。當事務中存在否認威脅時，應記錄這些事務及其用戶、時間、日期等足夠多的信息以標識事務的詳細信息。否則，當出現爭論時，您可能缺少足夠的證據以證實您的觀點。
審核、報告和監視
審核對減少否認危險程度起著重要的作用；在識別其他種類的攻擊過程中，也起著關鍵作用。例如，如果不是您的審核記錄中的統計數據表明您的服務存在異常使用情況，您可能根本意識不到您的服務正在遭受攻擊。例如，您是否注意到某個人正在對登錄方式進行字典攻擊？所以，我們將講述在審核、報告和監視時需要考慮的問題，以保護 XML Web 服務免受攻擊。
審核的概念就是記錄所發生的每個事件的所有信息。但是，當通過 XML Web 服務的數據量很大時，此想法可能是不切實際的。審核記錄至少應包括所有請求的時間、日期和 IP 地址。如果 XML Web 服務經過身份驗證，您需要在每個審核記錄中包括用戶名。如果您的服務支持多種方法或消息格式，您需要標識調用的是哪一個。最后，您需要包括足夠的信息以滿足您標識調用詳細信息的需要。例如，如果 XML Web 服務使用了一種方法，您可能希望記錄傳遞給該方法的所有參數。
您還需要考慮其他需要，例如當站點遭到攻擊時您可能需要回滾事務。而且，您的審核記錄往往是某些報告的最佳信息源。由于審核記錄可能相當大，您需要協調審核設計和備份策略。
審核處理的是通過您的服務同時發生的所有事件的記錄，報告則是向用戶、操作員和管理員匯報系統的使用信息。報告是保護 XML Web 服務免受攻擊的一個重要部分，因為通過它可以觀察服務的使用情況。一種主要的報告類型是報告發生的錯誤。報告 XML Web 服務所遇到的錯誤的能力是最重要的。同樣，您還需要報告那些可能指出惡意客戶端企圖的錯誤。例如，如果所接收請求中的某個參數是一個異常的長字符串，則您需要以一種容易引人注意的方式來報告該錯誤。對于這種類型的錯誤，您應該在應用程序事件日志中創建事件，這樣可以相應地對它們進行監視。有關如何將事件寫入事件日志的詳細信息，請參閱操作系統平臺 SDK 中的 Event Logging（英文）。
另一種對您的服務至關重要的報告類型是匯總服務使用情況的報告。它應該有兩種形式：首先，創建供您個人進行分析的全局報告，您可以使用該報告檢測使用級別或異常模式。應該對正常報告的外觀具有足夠的了解，這樣您才能夠發現異常使用的情況。其次，需要為您的用戶提供報告。您的用戶還應能夠監視他們對服務的使用情況。很有可能出現這樣的情況：在全局報告中未記錄攻擊行為，而個別用戶卻能立即在其各自的報告中發現問題。
