在企業級 SOA 中使用 Web 服務，第 12 部分: 使用 IBM Rational ClearQuest 在 SO

想要使用 IBM Relational ClearQuest 開發風險管理 Web 服務嗎？本系列的第 12 部分將說明如何開發 Web 服務來管理 SOA 中的風險。將在其中舉出若干個例子，從而說明應該如何對風險生命周期進行擴展，以處理當今世界中范圍更大的威脅、漏洞和風險；并了解為何 Web 服務協調器角色應是較新版本的生命周期中的一個重要部分。

引言

本系列文章的第 10 部分討論了可以如何使用深度防御來保護您的 SOA。在其中介紹了包含三個防御層次的中央模型?？梢允褂眠@個模型來克服一些技術的內在弱點，并通過在最佳資源間動態地操作來進行控制。

每個層次應包含的內容（相對于防御位置而言）視組織包含 SOA 的業務策略和理念而定。您在其中了解了可以如何在技術基礎上構建安全策略和控制——或者反之：技術和控制可以在安全策略和過程的基礎上進行構建。

回頁首

超越深度防御

您不僅只需要深度防御。在 SOA 中開發 Web 服務時，始終存在不確定的東西。當概率分布未知時，就存在不確定性。進入風險就會使得這個概率分布從未知變為已知。風險是構成威脅的個體利用一個或多個漏洞的可能性。

本文將描述 SOA 中的傳統風險生命周期：風險分析、風險評估和風險管理 Web 服務。我們還將討論如何對此生命周期進行擴展，以包括其他 Web 服務：風險預測、風險策略、風險要求和風險監視。您將了解為何在管理以實時方式動態地依賴于其他因素的文件時需要非線性隊列。

回頁首

傳統風險生命周期

風險分析是一種標識風險和評估可能會出現的潛在損失的方法，用于為安全控制和保障措施提供依據。

風險評估是標識資產、威脅和漏洞并度量風險和對風險進行優先排序的過程?？梢允褂枚糠椒ɑ蚨ㄐ苑椒▉泶_定威脅出現的可能性。

估算概率就是定量方法的一個例子。而采用高 (H)、中 (M) 和低 (L) 的風險等級則是定性方法的一個例子。您需要管理每個威脅將利用一個或多個漏洞的風險，并使用合理的替代方法將風險降低到可接受的程度。

風險管理是將風險降低到可接受程度，然后實現正確的保障措施和控制，以保持該風險水平并產生有效的投資回報 (ROI)。每個保障措施的 ROI 都是一項指標，說明您實現的保障措施在降低風險方面的投資所產生的回報情況。

保障措施的實現并不會終止風險的分析、評估和管理過程。將會接受生命周期的早期產生的反饋信息（反映系統資產、漏洞、威脅、策略和管理方面的的重大更改），從而繼續該過程。

為了處理當今世界中更大范圍的威脅、漏洞和風險，我們需要對此風險生命周期進行擴展。為了理解這其中的原因，讓我們以用戶在屏幕上錯誤地輸入數據后創建系統錯誤時的非故意用戶錯誤的風險為例。

回頁首

低風險還是高風險？

在發生較大的系統錯誤前，由于用戶在數據正確輸入數據方面有良好的記錄，因此會認為非故意用戶錯誤的風險影響很低。一個解決辦法是，當存在任何未正確輸入的數據，向用戶發出提示。另一個方法是，為用戶提供系統培訓。首次出現該系統錯誤后，風險的影響就會提高。因此實現了更新的解決辦法，如在第一道防線上提供個人安全，并在驗證過程上提供軟件認證，以在第二道防線上防止系統受到非故意用戶錯誤的影響。

預測需求

如果在用戶意外創建非故意系統錯誤前，我們預測到更改風險等級的需求，則非故意用戶錯誤的風險等級影響將會提前提高，從而在發生錯誤時其他措施已經就位。風險管理預測需要成為生命周期的第一個階段。我們需要在風險分析階段前添加兩個階段。即風險管理策略和要求。

策略輸入

風險管理需求的預測研究成果可為風險管理策略提供輸入信息。應當清楚地說明策略，以便可以將遠景轉換為目標，從而用于度量每個周期階段的成效。例如，當策略需要將墜機的風險降低到可接受的程度時，可度量的目標將是各項指標，如計算年預期損失和保障措施 ROI。

要求規劃

以提出的目標為基礎，我們將對風險管理要求進行規劃，包括給定時間范圍（如三年或更短）內正在開發的軟件系統的重新評估。要求還應該指示為了符合評估和管理風險的安全管理要求而應該使用的文檔類型，從而保護您的系統不受非故意用戶錯誤的影響。

監視更改

完成了風險管理的任務后，我們將在其后添加一個生命周期階段：監視更改。需要監視協調器對風險、威脅、漏洞、管理和組織結構方面的變更的響應情況。在性能達到特定閾值或達到系統過載點時，我們會收到電子郵件警報。

回頁首

主協調器

將這些組合起來，就得到了經過擴展的風險 Web 服務生命周期，該周期包含以下 Web 服務，其中每個 Web 服務表示一個周期階段：

• 預測
• 策略
• 要求
• 分析
• 評估
• 管理
• 監視

雖然風險管理 Web 服務是生命周期的一部分，但同時也是第一級 Web 服務的主協調器。如圖 1 中所示，它以動態方式根據工作流和更改跟蹤標準從這些 Web 服務獲得其風險管理資源的反饋信息。

圖 1. 主協調器
soa-enter12/Figure-1-Risk-Management.gif" width="400" twffan="done"/>

可以使用 IBM Rational ClearQuest 為協調器層次結構完成此工作。

回頁首

第二級協調器

讓我們將風險分析 Web 服務作為第二級協調器。請參見圖 2。

圖 2. 第二級協調器

我們將分析階段劃分為以下 Web 服務：

• 資產標識 Web 服務
• 漏洞標識 Web 服務
• 威脅標識 Web 服務
• 漏洞-威脅映射 Web 服務

一個跨國公司可以使用分析協調器來從位于不同的 SOA 中的組織單元更新資產（人員、技術和工具）信息?？梢詫⒋藚f調器設置為定期發送有關更新不一致的電子郵件警報?？梢詫β┒春屯{標識 Web 服務進行類似的處理。

回頁首

漏洞-威脅映射 Web 服務

風險分析中最有意義的部分就是漏洞-威脅映射服務。此服務將漏洞映射到多個威脅上，即相同的漏洞可能被多個威脅所利用?？赡艹霈F一個 SOA 中的多個威脅和不同 SOA 中的其他威脅利用原始 SOA 中的相同漏洞的情況。

類似地，該服務也將威脅映射到多個漏洞，即相同的威脅可能利用多個漏洞。一個威脅可以利用一個 SOA 中的一組漏洞和另一個 SOA 中的另一組漏洞。威脅可能是無意造成的，也可能是有意造成的，還可能是人為的。

當資產從一個位置移到另一個位置，從一個 SOA 移動到全局網絡中的另一個 SOA 中，會動態地更改威脅、漏洞和風險的范圍，從而使事情變得非常復雜。圖 3 顯示了將映射服務作為另一個協調器對這些更改進行協調的情況。

圖 3. 第三級協調器

通過使用 Rational ClearQuest，可以幫助跟蹤此級別的 Web 服務間的工作流中的更改。

回頁首

非線性協調器隊列

隨著依賴其他 Web 服務完成一系列任務的復雜 Web 服務的增多，始終可能出現 Web 服務所運行的一個或兩個文件等待其他 Web 服務運行的文件的時間不足夠長的情況。處理這種等待時間不夠的文件的一種方法是，在頻繁需要其他 Web 服務的連接的 Web 服務中創建非線性隊列。當接收非線性隊列接收到外部 Web 服務的文件時，原始 Web 服務會將該文件移到另一個非線性隊列，可在此將這些文件與已經等待了這些文件一段時間的其他文件一起進行多線程優化。Rational ClearQuest 能跟蹤文件連接方式的變化。

回頁首

結束語

開發用于跨 SOA 管理風險的 Web 服務要求事前進行規劃，以預測需求、概念化策略、闡明要求、進行分析和評估、管理風險和監視結果。另外，在規劃階段還要確定風險生命周期的哪個部分應為風險生命周期層次結構的不同級別的協調器。應與系統管理員、業務分析師和開發人員組成的團隊進行溝通，討論有關確保恰當管理風險的問題。

您會發現解決這些問題后，您的風險管理 Web 服務開發工作變得容易得多了?？梢允褂?IBM Relational ClearQuest 通過靈活的工作流管理和缺陷與變更跟蹤來實現開發流程的自動化。管理員會發現，解決了這些問題也使得他們的在風險生命周期中的 Web 管理工作變得更加輕松。他們能夠確定在不引起系統過載的前提下可以創建和使用多少文件。

原文轉自：http://www.kjueaiud.com