站在云端的SaaS之云安全（下）

致遠軟件研發中心技術總監 吳玉民

（接上期）

安全實施方法論

安全領域內三個比較主流的實施方法論分別是：等級保護、ISMS和微軟SDL。其中，等級保護是我國信息安全方面的標準規范，為國家級的大型軟件系統定級和等保實施提供指導，涵蓋了技術和非技術領域的安全措施和指導。ISMS是國際信息安全規范ISO 27001的實施體系規范，主要以風險驅動的方式進行信息系統安全建設。微軟SDL是以軟件工程的方式，針對軟件開發生命周期各個階段定義相應的安全方法和措施，對軟件研發過程具有重要的指導意義。 在SaaS系統的整個生命周期中，可以將這三種安全實施方法進行融合并結合使用。在SaaS軟件開發階段，采用微軟SDL方法論進行產品研發；實施運維階段采用等級保護實施方法論；在安全風險的處置方面，可以借鑒ISMS的體系規范。

微軟SDL方法論

SDL全稱Security Development Lifecycle，即安全開發生命周期，是微軟公司為了實現比爾·蓋茨(Bill Gates)在2002年寫下的“Trustworthy Computing—可信計算”備忘錄的目標，是微軟全部產品經過多年實踐積累的一套軟件安全開發生命周期方法論，如圖15-15所示。不同于等級保護和ISMS信息安全實施方法論，微軟的SDL更側重從軟件工程的角度指導整個軟件產品的安全開發過程，而不包含諸如系統運維管理等非技術安全方面的指導。

1.Pre SDL需求—— 培訓

軟件開發團隊的所有成員都應該接受合適的針對性培訓，以增加對安全基礎知識和安全及隱私方面趨勢的了解。軟件開發團隊的每個人都應該每年至少參加一次安全培訓。安全培訓能夠幫助確認軟件是在安全和隱私了然于胸的情況下被創造出來的，同時也能夠幫助開發團隊直面當前的安全問題。項目團隊成員應該被鼓勵去積極尋求更多的安全和隱私方面的教育機會。

圖15-15 SDL過程

2.第1階段—— 需求

SDL的需求階段包含項目的啟動階段，當你在最基礎的層面考慮安全和隱私以及成本分析問題時，需要考慮是否為符合業務需要而改進安全和隱私，并因此付出開發和支撐的成本。 項目啟動階段在基本的層面考慮安全和隱私問題是系統開發的原則。建立可信軟件的最好機會是在軟件的初始計劃階段，因為開發團隊能夠結合安全和隱私識別關鍵目標，減少方案和計劃失敗的可能。主要工作內容如下：

● 確定是否在所研發的軟件中采用SDL。

● 確定負責跟蹤和管理軟件研發過程中安全問題的團隊或個人。

● 確定bug跟蹤工具能夠跟蹤安全問題并且能夠隨時動態查找到所有安全問題。

● 定義并文檔化項目的安全bug條。

成本分析在投入設計和實現之前，了解考慮數據隱私問題的成本和需求是很重要的。隱私風險會增加開發和支持的成本，所以改進安全和隱私需要和商業需求一并考慮。這里的主要工作內容如下：

● 完成風險評估

3.第2階段—— 設計

設計階段是構建如何貫穿SDL的剩余流程的計劃，從實現到驗證，再到發布。在設計階段，通過功能和設計規范的方法建立要遵循最佳實踐，并且進行風險分析以識別軟件的威脅和弱點。

影響軟件可信計算設計的最佳時間是在生命周期的早期。功能說明需要描述直接被暴露給用戶的安全或隱私功能，比如在高風險隱私功能被使用之前，需要用戶身份驗證才能訪問特定數據或用戶許可。設計說明應該描述如何實現這些功能，以及如何實現所有的安全特性。安全特性是關于安全的工程化設計的功能性特征，比如在所有數據處理之前做嚴格的校驗，或者強制使用加密API。當功能設計時，仔細并盡早考慮安全和隱私是很重要的，要避免在軟件開發臨近結束時再去加強安全和隱私。主要工作內容如下：

● 創建描述直接暴露給用戶的安全功能的功能性說明。

● 設計說明應該描述如何實現這些功能，以及如何實現所有的安全特性。

風險分析，在軟件研發的設計階段，仔細檢查(Review)安全和隱私需求以及期望，以識別安全問題和隱私風險。在設計階段識別和設法解決這些問題和風險是更有效率的。對于安全方面的問題，威脅建模(Threat Modeling)是用來識別軟件當中威脅和缺陷的系統化過程，如圖15-16所示。必須在軟件設計階段完成威脅建模。只有真正了解需要保護的資產、軟件的威脅和缺陷以及軟件如何減輕這些威脅的細節，團隊才可能構建出安全的軟件。這里的主要工作內容如下：

● Review安全需求和期望以識別安全問題。

● 完成對成本分析階段識別的功能進行威脅建模。

4.第3階段—— 實現

圖15-16 SaaS系統威脅樹

實現階段要牢記軟件的最終用戶是最重要的。在這個階段，創建由用戶使用的文檔和工具是為了讓用戶了解并決策如何安全地部署軟件。實現過程中，要在開發生命周期中建立開發最佳實踐，以盡早檢測并排除安全和隱私問題。創建文檔和工具，每一個軟件程序的發布都應該在它的默認配置和部署當中被設計為安全的。然而，人們的使用方式不同，并且不是每個人都使用默認配置。因此需要提供給用戶足夠的安全信息，讓他們能夠了解并決策如何安全地部署軟件。因為安全和易用性是沖突的，所以有必要在決定如何部署和操作軟件時，告知用戶存在的風險以及需要在風險和功能之間權衡。 在開發計劃和功能說明穩定之前，很難討論特定的安全文檔需求。一旦架構趨于穩定，用戶體驗團隊就可以完成安全文檔計劃和安排。提交關于如何安全地使用軟件系統的文檔，這和交付系統本身同樣重要。主要工作內容如下：

● 定義安全最佳實踐文檔和工具。

建立并遵循開發最佳實踐，在軟件開發早期檢測并排除安全問題，有利于建立、傳達并遵循開發安全代碼的有效實踐。很多資源、工具和流程可以幫助達到這一目標。投入時間和精力來盡早運用有效實踐，可以幫助消除安全問題，并且要避免在開發后期甚至在軟件發布之后對這些問題進行響應，因為這將是代價昂貴的。主要工作內容如下：

● 建立、傳達并遵循能夠在軟件開發過程中，盡早發現并排除安全問題的開發安全代碼的有效實踐。

5.第4階段—— 驗證

驗證階段的主要目的是確保開發的代碼滿足在上一階段確定的安全和隱私原則。為達到這一目的，可以利用安全和隱私測試以及安全推動，這是全團隊范圍聚焦在威脅模型更新、代碼Review、測試、全面的文檔Review和編輯。公共發行的隱私Review也將在驗證階段完成。安全和隱私測試，在代碼完成之后快速開始安全測試。需要在實現階段之后進行一次全面的測試并獲得通過，因為潛在的問題和缺陷可能會在代碼開發期間發生改變。 安全測試在SDL中是很重要的。設計師和說明書可以勾勒安全設計，開發人員可以勤奮地編寫安全的代碼，但是測試過程將最終決定產品在真實世界是否安全。這里的主要工作內容如下：

● 定義模糊測試、滲透和運行時測試。

確定對哪種文件格式做模糊測試。

確定對哪種網絡接口做模糊測試。

確定采用什么工具做文件和網絡接口的模糊測試。

● 重新評估攻擊面。

● 重新評估威脅模型。

安全推動是全團隊范圍聚焦在威脅模型更新、代碼Review、測試和全面的文檔Review和編輯。安全推動不是對缺乏安全準則的補充，它是有組織性的努力，以發現在開發時可能產生的變化，改進任何遺留代碼的安全，識別并處理任何遺留的缺陷。不管怎樣，應該注意，僅僅憑借安全推動是不可能構建安全的軟件的。安全推動在產品進入驗證階段之后(代碼/功能完成)出現，通常在beta測試開始時啟動。安全推動的結果可能改變產品的默認配置和行為，因此應該在安全推動完成以及所有的問題和需要的更改都解決之后，進行一次最終的beta測試復查。 注意，安全推動的目標是發現缺陷，而不是修復它們。修復缺陷的時間應該是在完成安全推動之后。主要工作內容如下：

● 決定是否需要做安全推動。

● 定義安全推動的步驟。

確定安全推動的時間表。

確定是否需要在安全推動之前加強人員培養。

確定是否存在任何其他需要加強關注的任務。

定義安全缺陷如何被跟蹤。

公共發行隱私Review 在任何公共發行(包括alpha和beta測試發布)之前，對于驗證期間產生的任何重要的隱私變更，都要更新相應的SDL隱私調查表。重要變更包括改變許可的形式、提示語言的重大變更、收集不同的數據類型和呈現新的行為。 隱私需求必須在任何代碼的公共發行之前定稿，安全需求則不必。不管怎樣，必須在最終發布之前完成最終安全Review。主要工作內容如下：

● 對于驗證期間產生的任何重要的隱私變更，都要更新相應的SDL隱私調查表。

● 與隱私顧問和法定代表一同創建經過審批的隱私公告。

● 公共發行之前，在合適的網站發布隱私公告。

6.第5階段—— 發布

發布階段是軟件已經準備好向公共消費者發行，更重要的是，整個團隊已經為軟件到了用戶手中即將發生的事情做好了準備。發布階段的核心是制訂行動計劃，決定任何的安全或隱私缺陷都是在發布中被公開，還是從響應執行的角度將其推遲到下一版實現。另外，需要在發布之前完成最終安全Review(Final Security Review，FSR)和隱私Review。任何軟件都可能伴隨著未知的安全或隱私問題而被發布，哪怕再多的努力和計劃都是如此。甚至在有著未知缺陷的軟件發布那一刻，才發現新的緊急并且需要采取行動的威脅。同樣，隱私倡導者們也會在軟件發布之后提出隱私問題。因此，必須在軟件發布之前做好響應潛在安全和隱私事件的準備工作。通過合適的計劃，能夠應對一般商業操作中發生的很多事件。 團隊還必須準備應對軟件安全突發事件。如果在軟件發布之前制定了應急響應計劃，在由于安全或隱私原因而需要應急響應時，將節省時間、金錢并降低影響。主要工作內容如下：

● 確定誰負責安全服務。

● 提供負責安全突發事件響應的聯系人信息。

● 確保處理所有類型的安全問題的流程到位，比如代碼重用或繼承于其他團隊和第三方授權的代碼。

● 創建文檔持續模型，跟蹤記錄為了響應安全缺陷而立即發布的補丁，而不是完全依賴于不常發布的服務補丁包。

最終安全Review和隱私Review 作為軟件開發項目活動的結束，需要確信軟件足夠安全。FSR將幫助做出這項決定。應該由安全團隊完成FSR，在產品團隊的幫助下確保軟件符合所有SDL需求和任何由安全團隊識別的附加安全需求(比如滲透測試或附加模糊測試)。 FSR可能會持續幾天到6個星期，依賴于問題的數量和團隊做出必要修改的能力。仔細地安排FSR非常重要。在Review時要有足夠的時間找出任何嚴重問題，還需要有足夠的時間做深入的分析，不足的時間可能導致在FSR完成之后還需要做出重大改變。主要工作內容如下：

● 定義軟件開發結束時間以開展FSR。

● Review威脅模型。

● Review在當前發布中被延期或拒絕的安全問題。

● 所有安全工具的驗證結果。

● 為Review提交請求給安全顧問。

發布到制造工廠/網站軟件發布到制造工廠(Release to Manufacturing，RTM)或網站(Release to Web，RTW)是SDL過程結束的條件。指派給本次發布的安全顧問必須證實軟件團隊已經滿足了安全需求。與之相似，對于帶有P1級隱私影響的組件的所有產品，隱私顧問必須在軟件上市之前證實軟件團隊是否滿足了隱私需求。

7.Post SDL需求—— 響應

安全服務和響應執行。軟件發布之后，產品開發團隊必須準備應對任何可能的安全缺陷或隱私問題。另外，需要完成響應計劃，以應對潛在的軟件發布之后的問題。

等級保護實施過程

等級保護的相關實施過程方法論，對于SaaS系統在安全方面的建設實施具有很好的借鑒和指導意義。等級保護的實施過程分為信息系統定級、總體安全規劃、安全設計與實施、安全運行與維護以及信息系統終止5大階段，如圖15-17所示。

信息系統定級

信息系統定級階段的目標是信息系統運營，使用單位按照國家有關管理規范和GB/T AAAA-AAAA，確定信息系統的安全保護等級。信息系統運營、使用單位有主管部門的，應當經主管部門審核批準。

總體安全規劃

總體安全規劃階段的目標是，根據信息系統的劃分情況、信息系統的定級情況、信息系統承載業務情況，通過分析明確信息系統安全需求，設計合理的、滿足等級保護要求的總體安全方案，并制定出安全實施計劃，以指導后續的信息系統安全建設工程實施。對于已運營(運行)的信息系統，需求分析應當首先分析判斷信息系統的安全保護現狀與等級保護要求之間的差距。

安全設計與實施

安全設計與實施階段的目標是按照信息系統安全總體方案的要求，結合信息系統安全建設項目計劃，分期、分步落實安全措施。

安全運行與維護

安全運行與維護是等級保護實施過程中確保信息系統正常運行的必要環節，涉及的內容較多，包括：安全運行與維護機構的建立，環境、資產、設備、介質的管理，網絡、系統的管理，密碼、密鑰的管理，運行、變更的管理，安全狀態監控和安全事件處置，安全審計和安全檢查等內容。在等級保護實施指南中則重點關注運行管理和控制、變更管理和控制、安全狀態監控、安全事件處置和應急預案、安全檢查和持續改進以及監督檢查等過程。

圖15-17 等級保護實施過程

信息系統終止

本活動的目標是在信息系統終止處理過程中，對于可能會在另外的信息系統中使用的信息采取適當的方法，將其安全地轉移或暫存到可以恢復的介質中，確保將來可以繼續使用，同時采用安全的方法清除要終止的信息系統中的信息。

信息安全管理體系(ISMS)

信息安全管理體系(Information Security Management System，ISMS)使得組織能夠系統地管理信息安全。通過ISMS實施，組織能夠基于對每個獨立問題的技術應對措施的自身風險評估，確定必要的安全級別，制訂計劃并發布信息資產。ISMS的主要理念就是，要妥善地維護和改進組織中應該被保護的信息資產的保密性、完整性和可用性。特別是，通過ISMS風險評估衡量控制實現的影響，組織能夠以更加有效果和有效率的方式改進信息安全。信息安全的三個目標：

● 保密性—— 信息對未經授權的個人、實體或流程不可用或不被暴露的屬性。

● 完整性—— 保障信息資產的準確和完整的特性。

● 可用性—— 信息可按授權實體的需要而被訪問和使用。

PDCA模型

通過應用“Plan-Do-Check-Act(PDCA)”模型處理信息安全相關問題，可以按照期望管理信息安全并達到滿意效果。利益相關者的信息安全需求和期望，能夠在流程中作為輸出被產生，同時這些需求和期望也將作為流程的輸入。關鍵是通過應用PDCA模型，可以實現流程持續改進的效果，如圖15-18所示。

表15-3 PDCA解釋

ISMS實施框架

在ISMS實施框架中，分為如下3個階段（參見圖15-19）。

階段1：確定ISMS的范圍和策略（步驟1和步驟2），組織應該依據業務、組織、地理位置、資產和技術等方面特性，定義ISMS的范圍和邊界。然后定義ISMS策略，包括戰略風險管理環境，ISMS建立和維護的組織環境，信息安全的總體方向和原則等方面內容。當定義ISMS策略時，組織應該著重考慮源于業務和法律的，或良好需求和風險評定的信息安全需求。 階段2：基于風險評估確定應對措施（步驟 3-步驟 7）。

圖15-18 PDCA模型

圖15-19 ISMS實施框架

基于ISMS的范圍和策略，組織應該定義風險評估方式。然后，通過對可能引起需要保護的信息資產的保密性、完整性和可用性造成損失的威脅和缺陷的識別，以及對業務的潛在影響來識別風險。在風險評估過程中，應當根據由于安全問題造成和可能造成的商業損失的評估結果來估計風險級別。然后，利用風險可接受標準，確定風險是可接受的還是需要被處置的。假如風險不可接受，組織應當選擇采取哪種風險處置方案以應對風險，比如應用應對措施、接受風險、規避風險或轉移風險。根據風險處置決策，選擇合適的控制目標和應對措施。有必要的話，還有可能采取更多的控制目標和應對措施。

階段3：計劃適當的處置風險（步驟8-步驟10），組織應該為達到既定控制目標和應對措施而提議的殘余風險取得管理層批準，并且取得實施ISMS的管理層授權。最后，組織應該準備一份適用性聲明，描述選定的控制目標、應對措施和選擇或排除的原因。

SaaS用戶需要關注的安全問題

安全壓倒一切。大多數用戶只是問問SaaS廠商是不是采用了安全套接層(SSL)技術，而安全性涵蓋的不僅僅只有這個方面。要向潛在的SaaS廠商詢問下列問題：

● 放置服務器的數據中心有沒有24×7全天候的物理安全措施？

● 數據中心有沒有得到保護(保安是不是24小時在周圍至少巡視一次)？

● 誰有權訪問這些服務器(只有內部員工可以訪問，還是承包商也可以訪問)？

● 有沒有日志記錄誰何時進入，何時離開？如果有日志，那么隔多長時間審計這些日志？

● 應用程序有沒有使用基于行業標準的128位加密技術？

● 如果多個客戶使用的應用程序放在同一臺服務器上，那么它們有沒有采用邏輯或物理分隔，從而確保你的數據不被未授權的人看到？

● SaaS廠商中可以訪問你企業數據的工作人員有沒有經過犯罪背景調查？知道被定罪的重罪犯是不能訪問企業那些敏感的個人數據的，這很重要。

● 廠商有沒有正規的業務連續性方案(BCP)？對方愿不愿意與你共享該方案，它能消除你的擔憂嗎？

企業的數據至關重要，所以在挑選SaaS廠商時，要務必確認對方有相應的備份機制，這一點很關鍵。至少，除了每周一次的異地備份外，還需要每晚進行一次備份。要問的其他問題還有：服務供應商隔多長時間測試數據庫恢復？遇到緊急情況這家廠商能不能從容地恢復大量數據等？