云安全聯盟：面向云客戶的SaaS治理最佳實踐（2022）（67頁）.pdf

《云安全聯盟：面向云客戶的SaaS治理最佳實踐（2022）（67頁）.pdf》由會員分享，可在線閱讀，更多相關《云安全聯盟：面向云客戶的SaaS治理最佳實踐（2022）（67頁）.pdf（67頁珍藏版）》請在三個皮匠報告上搜索。

1、面向云客戶的SaaS治理最佳實踐 2022 云安全聯盟大中華區版權所有3序言序言據 Statista 預測，到 2022 年全球企業服務 SaaS 市場規模將超 1700 億美元，SaaS 成了真正的“軟件終結者”。國內 SaaS 雖然起步較晚但也已經在 2019 年進入了旺盛期，CRM、ERP、HCM、OA、財務、客服、電子簽等垂直領域的 SaaS 蓬勃發展。傳統軟件廠商也紛紛向 SaaS 轉型。尤其是新冠疫情爆發以來，很多企業不得不選擇遠程辦公和使用線上 SaaS 應用，疫情成為 SaaS 發展強有力的助推劑。隨著 SaaS 的普及，企業軟件的安全風險從傳統軟件轉移到了 SaaS 應用。企

2、業的云安全治理范圍也從原來的 IaaS 基礎設施層和 PaaS 平臺層延伸到了 SaaS 應用層。因此，CSA 在發布 CAST 云應用安全可信標準與認證之后，又發布了面向云客戶的 SaaS 治理最佳實踐（以下簡稱實踐）白皮書，供 SaaS 從業人員及相關的 IT 或安全從業人員參考。實踐充分關注到了 SaaS 環境中的數據保護、SaaS 生命周期的風險以及處置等內容。而且基于安全策略、安全組織、資產管理、訪問控制、加密和密鑰管理、安全運維、網絡安全、供應商管理、事件管理、合規等多個安全控制域為業界提供一整套用于 SaaS 治理的指南。實踐圍繞 SaaS 治理中最核心的問題“確保誰在什么場景下

3、、擁有什么樣的權限、可以訪問什么數據”，并從評估、采用、使用和終止四個階段給出了具體措施和建設，同時針對日常應用場景進行了延伸的安全考量。隨著數字化轉型和數字經濟發展浪潮的強勢來襲，企業級 SaaS 的需求量也在與日俱增。各行業也正在大力構建新的數字生產力，發揮數字協同效應，為企業發展提供新的動力。相信通過實踐中提出的詳盡而實用的治理指引，組織及相關從業人員能夠掌握 SaaS 治理的最佳方法和路線，提高 SaaS 安全治理水平，合理管控 SaaS 安全風險，切實保護 SaaS 中的數據安全。李雨航 Yale LiCSA 大中華區主席兼研究院院長 2022 云安全聯盟大中華區版權所有4致謝致謝面

4、向云客戶的SaaS治理最佳實踐(SaaS Governance Best Practices for Cloud Customers)由CSA軟件SaaS工作組專家編寫，CSA大中華區秘書處組織翻譯并審校。中文版翻譯專家中文版翻譯專家（排名不分先后）：組 長：組 長：郭鵬程翻譯組：翻譯組：陳 強侯 俊茆正華 王永霞 薛 琨楊天識審校組：審校組：陳 皓郭鵬程姚凱研究協調員：研究協調員：江瞿天感謝以下單位對本文檔的支持與貢獻：感謝以下單位對本文檔的支持與貢獻：北京北森云計算股份有限公司北京啟明星辰信息安全技術有限公司上海派拉軟件股份有限公司深圳市魔方安全科技有限公司神州數碼集團股份有限公司騰訊云計

5、算（北京）有限責任公司英文版本編寫專家英文版本編寫專家完成項目領導完成項目領導:Chris HughesTim BachMichael RozaAnthony SmithWalter HaydockAndreas PeterAndrew LuhrmannJames UnderwoodAlistair CockeramSaan Vandendriessche完成貢獻者完成貢獻者:Bryan SolariSai HonigAmit KandpalJessica ShouseAbhishek Vyas審核審核:Jerich BeasonKapil BarejaOr EmanuelUdith Wick

6、ramasuriyaPriya Pandey最初的領導和貢獻者最初的領導和貢獻者:Akin AkinbosoyeYao Sing TaoJ.R.SantosMickey LawVani MurthyZeal SomaniPaul LanoisMichael RozaCSA 全球員工全球員工:Shamun Mahmud在此感謝以上專家。如譯文有不妥當之處，敬請讀者聯系CSA GCR秘書處給與雅正!聯系郵箱：researchc-；國際云安全聯盟CSA公眾號。2022 云安全聯盟大中華區版權所有5目錄序言序言.3致謝致謝.41.引言1.引言.71.1 范圍.71.2 適宜讀者.82.概述概述.82.

7、1 方法.82.2 結構.92.3 SaaS 生命周期注意事項.93.信息安全政策信息安全政策.113.1 信息安全策略.113.2 對信息安全政策的審查.304.信息安全組織信息安全組織.304.1 內部組織.304.2 移動設備和遠程辦公.335.資產管理5.資產管理.345.1 資產責任.346.訪問控制6.訪問控制.366.1 訪問控制的業務需求.366.2 用戶訪問管理.366.3 系統和應用訪問控制.387.加密和密鑰管理7.加密和密鑰管理.417.1 SaaS 環境中的數據安全.417.2 加密 SaaS 提供商共享的數據.427.3客戶管理加密密鑰 vs 供應商管理加密密鑰.4

8、57.4 加密和密鑰管理的未來狀態.458.操作安全8.操作安全.478.1 操作程序和職責.478.2 防止惡意軟件.488.3 備份和高可用.498.4 日志和監控.508.5 技術漏洞管理.518.6 信息系統審計注意事項.529.網絡安全管理9.網絡安全管理.539.1 SaaS 提供商網絡控制.539.2 SaaS 消費者網絡控制.5310.供應商關系10.供應商關系.5410.1 供應商關系中的信息安全.5411.事件管理11.事件管理.5811.1 云安全事件管理.5811.2 SaaS 事件響應責任和程序.5811.3 階段 1:準備.5911.4 階段 2:檢測和分析.591

9、1.5 階段 3:遏制、根除和恢復.6011.6 階段 4:總結改進.60 2022 云安全聯盟大中華區版權所有612.合規性12.合規性.6112.1 遵守安全策略和標準.6112.2 遵守法律和合同要求.6212.3 信息安全審查.6213.CASB 的功能和發展方向13.CASB 的功能和發展方向.6314.結論14.結論.6415.參考文獻15.參考文獻.6516.定義16.定義.6617.縮略詞17.縮略詞.67 2022 云安全聯盟大中華區版權所有71.引言1.引言在云安全領域，一直以來關注的重點幾乎都是對基礎設施即服務（IaaS）和平臺即服務（PaaS）的保護。雖然組織一般只使用

10、2-3個IaaS提供商，但通常會使用數十到數百個SaaS產品。云客戶的SaaS治理最佳實踐，是SaaS治理實踐的基線集合,列舉并考慮了SaaS生命周期評估、采用、使用和終止等所有階段的風險以及處理。隨著SaaS的廣泛應用，組織為了應對這種新情況，必須更新網絡安全覆蓋的領域。組織必須更新內部策略，包括關鍵事項，如服務級別協議、安全和隱私要求以及運營影響分析等。同時，應考慮組織運營安全活動受到的影響，例如職責和任務分配，以及對移動設備和遠程辦公的影響。信息是一種資產，在SaaS模式下，涉及到外部服務提供商時，必須考慮信息的分類、標記和存儲需求。雖然SaaS提供商在共享責任模型中承擔了大部分責任，但

11、SaaS客戶仍然主要負責數據治理和訪問控制。這意味著需要明確誰在什么場景下，擁有什么級別的權限，訪問什么數據，尤其是在零信任架構中。組織仍然涉及對加密密鑰管理和安全運營活動（如漏洞管理、備份和存儲）的關鍵決策。組織需要確保將SaaS提供商視為第三方風險管理計劃的一部分，并相應更新事件響應和業務連續性計劃和流程。這一點越來越重要，因為從業務連續性的角度，SaaS通?；谶h程環境提供關鍵功能。SaaS工作模式下，即使責任共擔，組織仍然必須滿足法規合規遵從性和監管要求，以保護其利益相關者及其聲譽，并避免潛在的法律后果。SaaS模式改變了組織處理網絡安全問題的方式，在云廠商和云客戶之間引入了共同責任模

12、型。如果不進行相應調整，可能會造成嚴重后果，如泄露敏感數據、收入損失、失去客戶信任和違反監管要求等。1.1 范圍1.1 范圍本文件:提供一套用于保護SaaS環境數據的SaaS治理最佳實踐基線根據SaaS采用和使用的生命周期列舉并考慮風險從SaaS客戶的角度提供潛在的緩解措施 2022 云安全聯盟大中華區版權所有81.2 適宜讀者1.2 適宜讀者SaaS客戶SaaS云服務提供商SaaS安全解決方案提供商云安全專業人員法務網絡安全主管IT主管風險經理IT審計員和合規人員第三方風險經理2.概述概述軟件即服務（SaaS）用戶和客戶應評估并減輕使用SaaS服務所帶來的信息安全風險。本文檔參考NIST 8

13、00-145，將SaaS定義為“通過使用供應商在云基礎設施上運行的應用程序向消費者提供的能力”。在這種情況下，消費者不會管理或控制云基礎設施、操作系統、關聯的存儲，甚至單個應用程序，特定配置或設置除外。雖然組織選擇的云計算服務和安全領域在不斷發展，但有關SaaS治理和安全的指導并不多。同時，組織中的不同部門偶爾還會更多地利用SaaS服務（也稱影子IT）為其關鍵業務流程和功能提供支持，并經常在SaaS環境中存儲敏感數據。2.1 方法2.1 方法SaaS需要不同的安全治理思維。雖然與其他共享責任框架（即IaaS）的治理有一些相似之處，但SaaS部署和管理需要獨特的方法。對SaaS進行適當的安全和治

14、理，盡職調查必須從較高的層次開始，即了解SaaS應用程序的使用和功能，并深入到細節，如系統中存儲的數據類型以及誰有權訪問?？紤]到適當管理SaaS應用程序的使用以及可能部署的無數SaaS應用程序的獨特復雜性，組織應首先尋求一個適合組織安全、業務和監管需求的框架（如NIST CSF）。該框架將幫助組織塑造安全架構所需的人員、流程和技術。2022 云安全聯盟大中華區版權所有9遵循廣泛采用的安全框架（如NIST CSF）以及本文檔中的最佳實踐和建議，將有助于組織建立SaaS治理和安全流程，以降低與SaaS使用相關的風險。2.2 結構2.2 結構本文檔定義了SaaS安全性的三個必要組件：流程、平臺和應用

15、程序。通過將流程安全性、平臺安全性和應用程序安全性結合到一個內聚的策略中，可以實現SaaS的集成安全性。流程安全保護程序活動的完整性，確保流程的輸入和輸出不容易受到損害。主要涉及管理方面，包括政策和程序，以確保與組織的流程保持一致。平臺安全性涉及平臺的安全強度，即SaaS服務的基礎依賴性。其中包括SaaS基礎設施、操作系統及潛在供應商安全。應用程序安全性處理SaaS應用程序本身的安全性。只有當SaaS應用程序不包含可利用的漏洞，并且實現了符合組織和供應商安全最佳實踐以及法規遵從性要求的強化要求時，才能保持安全。在SaaS模型中，有限的控制措施和可見性主要局限于流程和應用程序安全組件。SaaS消

16、費者無法控制SaaS應用程序的平臺安全組件或底層供應鏈。這些情況導致SaaS用戶需要在其組織內擁有良好的流程安全性，并確保實現應用程序級的安全控制措施。某些部門特定的安全控制措施通常用于滿足隱私、政府或財務合規性。例如FedRAMP、NIST800-53、HIPAA和PCI-DSS。這些需求通常屬于垂直領域，適用于三個SaaS安全領域。2.3 SaaS生命周期注意事項2.3 SaaS生命周期注意事項如果管理得當，企業環境中SaaS應用程序的采用和使用通常遵循三個關鍵生命周期：評估、采用和使用。這些生命周期的常見模式如下。很多組織對SaaS的使用快速有序增長，然而在SaaS應用程序監控方面卻是落

17、后的。這樣的組織在廣泛采用SaaS的同時，實施SaaS安全和治理計劃，使用生命周期將是至關重要的。2.3.1 評估2.3.1 評估評估生命周期發生在采購之前，首先確定可由SaaS應用程序解決的業務需求。在許多組織中，這是在業務范圍內的，可能涉及也可能不涉及集中采購的組織。評估生命周期通常由4個步驟組成：2022 云安全聯盟大中華區版權所有10了解用戶計劃使用的服務市場研究試點工作采購決策如果組織做出了購買決策，那么將開始生命周期中的采用階段，部署SaaS應用程序。雖然理想情況下，相關安全和合規組織的代表會在評估階段出席，但這些代表必須參與到采用階段。當組織構建SaaS安全和治理計劃時，這些組織

18、“檢查點”是安全團隊在SaaS生命周期中的關鍵集成點。2.3.2 采用2.3.2 采用幾乎所有組織的SaaS生命周期采用階段都是一致的。它跨越了SaaS應用程序以初始形式（有時可能是一個擴展的試點項目）采購到全面部署和使用增長，一直到潛在的終止和退役的整個過程。采用生命周期的長短各不相同，對于大型業務關鍵型SaaS應用程序，實際上可能是一個穩定的狀態，但通常由四個步驟組成：評估評估：在評估階段，云消費者評估SaaS應用程序與需求的匹配度。這通常涉及一個試點或概念驗證活動，探索特性、功能和滿足業務需求的能力。采采用用：生命周期的采用階段是云消費者開始正式采用SaaS產品并超越試點或概念驗證的階段

19、。這可能涉及將更敏感的數據遷移到SaaS應用程序中，以及將SaaS應用程序推廣給其他業務部門使用。常規使用和擴展常規使用和擴展：可將常規使用和擴展視為維持階段。此時，消費者通常將SaaS應用程序用于各種業務功能，并有標準的操作程序供其使用。終止終止：生命周期的終止階段表示云消費者決定不再使用SaaS產品。這可能是由于各種原因，如成本、安全性或可能不再滿足業務需求。消費者開始關閉SaaS應用程序的使用，減少敏感數據、賬戶等。2.3.3 使用2.3.3 使用SaaS使用生命周期有助于防范日常運營風險和安全問題，如最小權限、身份和訪問管理。SaaS使用生命周期由四個步驟組成：2022 云安全聯盟大中

20、華區版權所有11資格資格：該個人或非個人實體是否應該成為服務的用戶？服務開通服務開通：需要做什么才能將此人添加到服務中，以及他們的權限是什么？監控監控：此人對SaaS的使用是否符合組織的預期，有無異常使用？服務撤銷服務撤銷：如何將此人從服務中刪除？SaaS使用生命周期描述了組織如何使用CSP和SaaS服務。了解和監控SaaS的整個使用生命周期非常重要。否則很容易將所有精力都集中在優化生命周期的一個階段，如初始化階段，而對企業更輕松或更迅速地實現預期結果卻沒有幫助。3.信息安全政策信息安全政策SaaS客戶應制定SaaS安全戰略，并構建反映該戰略的安全架構。一個強大的安全架構應該包括指導SaaS應

21、用程序部署和維護的安全策略。3.1信息安全策略3.1信息安全策略應制定有關管理SaaS服務的評估、采用、使用和終止的政策。請參閱上述常見SaaS生命周期的描述，并確保組織為每個生命周期階段制定了全面的策略并評估控制措施。3 3.1.1 評估.1.1 評估任何決策都應該以企業架構（architecture）的需求和流程為指導，應符合適宜環境的總體企業架構（評估產品、服務和工具及其解決的需求）。這可以防止不必要的產品、服務和工具重復。如果確定了需求，則可以開始評估產品、服務和工具。SaaS服務的初始評估通常會讓業務、法律和安全利益相關者了解交易的風險并進行相應的處理。關鍵問題是“這是否與我們的風險

22、狀況和企業架構匹配？”3.1.1.1 確定可接受風險3.1.1.1 確定可接受風險評估SaaS服務時，第一步是確定哪些風險與客戶的風險偏好一致。SaaS應用程序可以托管在私有、混合或公有云環境中，應用程序運行在應用程序級別的專用或共享資源上（單實例、多租戶）。與任何云產品、服務或工具一樣，必須理解共享責任模型。根據ISO/IEC 27001，應使用風險管理方法管理信息安全。SaaS客戶應首先確定SaaS服務給組 2022 云安全聯盟大中華區版權所有12織帶來的可接受風險，這構成了評估階段的基線?？梢允褂貌煌姆椒ü芾盹L險，包括國際風險管理標準ISO 31000。圖1：ISO風險管理流程，第5條

23、：流程如果了解組織的風險狀況，SaaS客戶應該能夠確定SaaS服務與組織風險管理要求的符合度?？梢酝ㄟ^了解SaaS服務的使用情境，并考慮以下因素確定SaaS服務的風險狀況：數據：業務流程將存儲哪些數據或需要將哪些數據提供給SaaS應用程序？直接成本（通知受影響個人的成本、股票下跌時股東的損失、競爭對手的大量涌入導致的客戶流失、利潤損失）和間接成本（聲譽損害和錯過的期貨銷售、網絡保險成本增加、關鍵員工的解雇）是什么，如果存儲在此SaaS應用程序中的數據的機密性或完整性受到損害，則會給業務帶來隱形成本（引導員工做出 2022 云安全聯盟大中華區版權所有13響應的成本，違規整改的成本）？流程：此服務

24、是否會影響核心或關鍵業務流程？如果使用SaaS服務，需要修改哪些組織策略和流程？需求：哪些業務需求、法律和法規與此服務相關？在此階段，應評估以下方面對SaaS客戶風險狀況的影響：SaaS提供商SaaS服務SaaS提供商的供應商SaaS服務的使用SaaS客戶對相關SaaS提供商應用持續監控和態勢管理以緩解風險的能力最常見的風險分析方法是經典的CIA分類：保密性完整性可用性有了CIA，應用程序和數據庫將根據您的要求進行風險評分。一旦建立了風險足跡，您就可以開始計算SaaS應用程序帶來的風險。計算風險的方法有很多，開發風險分析框架取決于組織需要和行業類型。雖然可以將風險管理相關的活動轉移到CSP（云

25、服務提供商），但是SaaS客戶本身并不能將其責任外包SaaS客戶本身并不能將其責任外包給CSP。SaaS客戶必須始終記住，風險所有者有責任承擔使用SaaS服務的風險。雖然服務提供商和消費者之間有責任分擔，并且存在服務級別協議（SLA）之類的協議，但消費者最終仍然擁有風險。3.1.1.2 安全和隱私要求3.1.1.2 安全和隱私要求一旦確定了風險水平基線，許多云服務客戶就會參與安全和隱私盡職調查。云服務客戶通常會向云提供商發送評估問卷或信息請求（RFI）以供填寫。2022 云安全聯盟大中華區版權所有14這些調查問卷詢問客戶希望看到的CSP實施的內部安全控制措施，通常解決有關安全和隱私的監管要求問

26、題。CSA STAR共識評估調查問卷等自我評估計劃或第三方評估（如SOC2或FedRAMP），有助于CSP向潛在客戶告知SaaS提供商的安全能力和現有做法。自我評估或第三方報告還詢問云提供商使用和披露個人信息的情況，或個人信息將在何處處理。這些項目還詢問云提供商是否將信息用于自己的目的或將其披露給第三方（例如，向第三方廣告商披露)。注意數據的位置也很重要，因為可能存在數據主權要求。第三方評估的一些關鍵領域包括：認證和標準數據保護訪問控制可審計性災難恢復和業務連續性法律和隱私漏洞和漏洞利用3.1.1.3 溝通要求3.1.1.3 溝通要求這些問卷或報告中的應答允許客戶進一步完善其風險評估，并反饋到

27、云交易的簽約階段。許多云客戶為了加強其風險評估和盡職調查流程，并作為供應商管理的一部分，創建了標準的數據安全和隱私計劃或條款，并包含在云合同中。這些附表或條款的目的是多方面的，可能會產生嚴重后果。一個目的是解決監管問題，例如保證數據滿足特定地區的監管要求。另一個是創建使云供應商遵守合理的安全標準的機制。這些附表或條款還可以約定事件響應義務，并轉移因云供應商造成的數據泄露或隱私侵犯的損失風險。還可以要求在特定時間以特定方式響應數據泄露等問題，包括審計權，以及執行定期監測和控制活動的權利。此外，必須了解CSP和消費者之間執行或管理合同的相關司法管轄區和監管框架。例如：如果您正在尋找一個SaaS平臺

28、存儲或處理員工或客戶PII（個人可識別信息），并且在GDPR的適用范圍，2022 云安全聯盟大中華區版權所有15那么需要查看CSP是否存儲歐盟/歐洲經濟區或提供充分保護的國家的數據。如果沒有，您需要了解適用的法律框架，并根據歐盟法院（CJEU）發布的Schrems II判決，確?？蛻舴仗峁┥逃凶銐虻谋Ｗo和補充技術控制保護數據?？傮w目標是通過合同與云服務提供商無縫銜接，并盡可能降低客戶的風險。供應商管理計劃中的簽約流程有時會進一步細化，允許客戶在與云服務提供商談判期間針對某些條款預先建立“后備”措施。這可能包括在終止合同時如何傳輸數據和其他事項（例如，防止供應商鎖定）?？蛻舻姆▌請F隊和安全團隊

29、通常都會參與這些條款的談判。3.1.1.4 內審3.1.1.4 內審客戶應制定SaaS安全戰略，并構建反映該戰略的安全架構。SaaS客戶應該記住他們負責的云共享責任模型的部分。也就是說，SaaS客戶最終負責SaaS平臺在設計限制內（即客戶權限和責任范圍內）的安全配置、管理和使用。威脅建模和威脅分析是開發SaaS安全策略的關鍵。云安全聯盟發布了云威脅建模，“提供關鍵指導，幫助確定威脅建模安全目標，設定評估范圍，分解系統，識別威脅，識別設計漏洞，制定緩解和控制措施，以及措施的實施和溝通”。SaaS客戶為了應對使用SaaS平臺的有效風險管理和安全控制要求，應制定一個多管齊下的安全戰略，該戰略適用于在

30、此過程早期確定的SaaS應用程序的風險級別和分類。該策略可能包括以下要素：了解可應用于SaaS平臺的云客戶適用的安全控制措施和配置（SSO、MFA、角色分配、團隊/組隔離、導出日志或與安全監控解決方案集成、IP限制等），并加以應用定期審查SaaS的使用情況和適用性針對在SaaS應用程序或平臺之外管理或部署的業務邏輯或流程進行滲透測試對SaaS應用程序的配置進行持續的安全態勢監控，并與組織特定的已批準/預期配置比較持續監控SaaS應用程序生成的審計、事件或其他更改/活動日志，理想的情況是能夠將這些日志與其他SaaS和非SaaS應用程序關聯持續監控對SaaS應用程序中關鍵數據和/或流程的訪問3.1

31、.1.5 服務條款3.1.1.5 服務條款未能就事件響應以及安全和法律評估權進行強有力的談判也可能帶來風險。2022 云安全聯盟大中華區版權所有16如果SaaS提供商違約并且影響到客戶，但沒有履行合同約定的違約通知和補救義務，則SaaS客戶可能無法降低其法律風險并遵守監管義務。不同區域的法律和通知義務可能也有所不同；因此，在采購和合同階段聘請專業的網絡律師非常重要。要考慮的合同控制：服務級別管理服務提供商SLA與組織的SLA要求（應解決資源和支持方面的問題）業務連續性承諾：組織的RPO、RTO與MTPD事件處理和升級備份的可用性法律問題法律和監管要求CSP和SaaS服務的管轄權、法律要求賠償：

32、管轄權遷移、并購通知：安全、隱私、法規遵從性變更和事件終止權利和流程數據可移植性（如果要遷移到其他平臺，則需要考慮數據導出問題）數據刪除、時間表和成功刪除的書面通知外包協議終止時的退出策略3.1.1.6 受影響的數據3.1.1.6 受影響的數據使用云的一個重大風險是，失去對已傳輸到云的數據的絕對控制，以及外包給云的網絡可用性。例如，在更傳統的IT環境中，組織有能力評估和調整其系統，使其符合適用的法規和標準。這可能包括基于組織或其客戶所在地的數據駐留要求。由于許多SaaS提供商使用位于多個司法管轄區的基礎設施服務，因此在不考慮這些要求的情況下使用SaaS服務可能會增加法規遵從性風險。SaaS客戶

33、應該能夠回答以下問題：2022 云安全聯盟大中華區版權所有17SaaS提供商在哪些司法管轄區運營？適用哪些監管要求？哪些數據將傳輸到SaaS服務？SaaS服務可以訪問哪些數據？對SaaS服務的數據依賴程度如何？服務提供商的法律義務是什么？例如，支付提供商為了遵守反洗錢（AML）要求需要根據法律義務保留一些數據。如果政府或軍事實體請求訪問數據，SaaS提供商會怎么做？例如，如果SaaS應用程序中只存儲非敏感數據，而不是敏感數據（例如社會保障號碼或金融賬戶數據），則可能需要較少的供應商審查?？刂拼胧罕Ｃ芤笕Q于數據價值數據分類要求（如HIPAA、PCI）數據和元數據控制：所有權、處理、許可數據

34、位置和主權可用性要求和數據遷移3.1.1.7 隱私3.1.1.7 隱私在使用SaaS提供商時，客戶必須確保他們了解在該提供商中存儲的數據對隱私合規的影響。SaaS客戶應該了解供應商是否允許使用他們存儲在SaaS應用程序中的數據（例如機器學習、匿名數據集評估等）。如果允許使用，則需要滿足SaaS客戶的監管和審計要求。不斷變化的監管環境本身增加了與隱私相關的法規遵從性或數據駐留違規的風險，使一些客戶和某些類型數據的SaaS應用程序的部署變得復雜。國外對美國SaaS提供商存儲歐洲公民數據的擔憂增加了這種潛在風險?？刂疲?022 云安全聯盟大中華區版權所有18SaaS客戶的角色與SaaS服務的角色？控

35、制者（客戶或員工的PII）處理者（控制者提供的PII）隱私政策：SaaS提供商對其服務數據的權利違約義務和責任PII數據清單、可見性數據主體的“同意”管理3.1.1.8 進行3.1.1.8 進行詳細風險評估詳細風險評估的步驟的步驟1.識別資產2.識別威脅3.識別脆弱性4.制定衡量標準5.考慮歷史漏洞數據6.計算成本7.執行風險到資產的動態跟蹤圖2.風險評估周期 2022 云安全聯盟大中華區版權所有193.1.1.9 識別風險3.1.1.9 識別風險識別可能阻礙業務目標的風險領域:數據、財務信息、知識產權/競爭優勢的丟失監管和法律規定企業聲譽威脅、漏洞、攻擊事件管理技術復雜性：人員專業知識財務承

36、諾第三方供應商第三方審計、SOC2報告、STAR注冊表等人為失誤3.1.1.10 評估風險3.1.1.10 評估風險定性/定量風險評估治理風險合規性(GRC)風險容忍度/偏好3.1.1.11 管理風險3.1.1.11 管理風險根據風險容忍度實施物理、技術、管理控制措施將風險轉移給第三方接受風險3.1.1.12 檢查監管3.1.1.12 檢查監管內部、外部審計風險分析 2022 云安全聯盟大中華區版權所有20要識別風險，必須對SaaS服務和CSP進行詳細的風險評估公司資產在上云之前，應進行風險評估。風險評估的詳細程度將因環境而異。例如，客戶可能會決定在一個有限的用例(即沙箱、開發軟件、測試CSP

37、功能、控制等)下開始使用CSP。在這種情況下，可以進行“最小風險評估”。如果CSP的工具和特性滿足CSC的業務目標，那么應該在應用正式上線之前進行更詳細的風險評估。在決定進行SaaS風險評估時，應該仔細檢查三個方面：a)SaaS提供商；b)SaaS提供商的管理實踐；c)SaaS應用程序的技術安全考慮事項。此表列出了需要考慮的值得關注的問題。供應商供應商實踐實踐應用程序應用程序CSP擁有哪些認證文件？CSP采用哪些控制措施從邏輯上限制進出不同區域的數據？應用程序/特權賬戶是否被集中管理（例如，通過IAM、RBAC或賬戶管理工具CSP是否經過第三方評估或審計？CSP是否可以提供SOC II類（時間

38、段）報告（或同等類型的報告）？CSP提供了哪些備份/恢復服務（例如，應用程序、數據、虛擬機）？是否存在安全通道（例如，用于口令、證書、數據的安全傳輸）？CSC數據是否與CSP一起存儲在本地，或者CSP是否與第三方供應商簽訂了合同(用于基礎設施托管服務)？CSP的突發事件管理流程是什么？事件如何分類?是否使用SSO/SAML/MFA進行安全認證?2022 云安全聯盟大中華區版權所有21供應商供應商實踐實踐應用程序應用程序在故障排除、維護等方面，CSC可獲得何種程度的支援?虛擬機鏡像、服務器和數據庫是否定期打補丁?CSP的防病毒管理流程是什么?應用程序/存儲賬戶是否面向公眾（開放權限）?CSP的S

39、LA/OLA是什么?如何管理、存儲加密密鑰等?誰有訪問權限？應用程序/軟件是否獲得了云許可？CSP是否提供了支持SaaS的所有第三方供應商列表?如果是，CSP是否進行背景調查并簽署保密協議?為客戶提供了哪些日志記錄工具？SIEM事件威脅檢測工具?軟件/數據是否符合任何監管/隱私要求？CSP能夠遵守哪些標準和監管要求?CSP基于什么標準(即ISO、NIST、CIS、PCI、HIPAA、GDPR)進行基線控制？CSP提供了哪些IDS/IPS工具？應用程序的開發/維護需要哪些軟件開發過程/工具(如DevSecOps、GitHub.、SDLC)？CSP使用了哪些工具/應用程序來支持此項工作？CSP的底

40、層架構是利用行業最佳實踐或標準來設計或開發的嗎？CSP是否提供虛擬機加固后的鏡像?它們是如何管理/執行的?支持此應用程序需要哪些API?CSP能提供哪些幫助?CSP是否利用/提供云資源的自動化工具、腳本(如vm、IaC、自動修復)?CSP是否提供控制措施以防止未經授權的數據泄露?CSP是否支持應用程序的脆弱性/滲透測試（如有必要）？需要說明的是，上述風險評估具體針對的是SaaS提供商及其SaaS應用程序的底層架構和實現的安全性。它不能替代對SaaS客戶實施和使用SaaS應用程序的持續安全監控和風險審查。為了正確地管理SaaS風險，必須通過不同的視角來理解和看待。只有這樣，才能在一定程度上保證S

41、aaS風險已經得到適當的識別、評估和緩解。風險評估不應被視為“一次性完成”的工作。云風險不是固定的，因此應該定期評估，并且當有重大變化時也要評估。SaaS客戶需要了解他們的解決方案的需求，然后確保SaaS提供商能夠理解并滿足這些需求。假設SaaS提供商無法滿足客戶的需求，SaaS客戶有責任采取補償措施縮小差距或選擇不使用相關提供 2022 云安全聯盟大中華區版權所有22商的服務。3.1.1.13 云提供商審查最佳實踐3.1.1.13 云提供商審查最佳實踐將第三方技術服務視為組織中的一種資產建立一種基于風險的第三方評估方法根據整個組織的關鍵利益相關者的要求制定第三方評估確保業務負責人參與定期審查

42、風險最高的供應商發布授權供應商/應用程序列表在沒有商業理由和批準的情況下，要求僅使用認可的供應商/應用程序考慮在整個組織中使用預先批準的供應商鼓勵或強制使用合規的供應商3.1.1.14 制定政策和程序3.1.1.14 制定政策和程序為了安全地部署和使用SaaS應用程序，SaaS客戶必須制定內部策略和流程，以持續評估和監控其SaaS應用程序的實施和使用情況。如本節前面所述，定期對SaaS提供商的技術、實踐和認證進行風險審查和評估；對于SaaS客戶來說，針對配置和SaaS應用程序的實際使用情況制定監控和評估方法同樣重要，甚至更為重要。這些政策至少應包括：賬戶管理程序集中式身份管理程序數據和系統訪問

43、要求，例如：批準重要訪問的授權，并要求對這些賬戶進行進一步的身份驗證針對服務濫用的可接受使用政策在業務流程上下文中集成用戶生命周期數據分類和標簽集成到現有的服務水平、事件管理和漏洞管理流程中與現有的管理機制集成、按要求創建和提升，即變更控制 2022 云安全聯盟大中華區版權所有23與其他安全計劃一樣，不能把對SaaS應用配置、數據分類和數據訪問的監控看作一次性的事情。SaaS比其他云技術的迭代更新更加快速，并且可以快速重新配置。SaaS客戶管理員只需一個不經意的命令或按鈕點擊，就可以大大改變SaaS應用的安全態勢，這進一步強調了對持續監控計劃的需求。3.1.1.15 配置和安全態勢管理3.1.

44、1.15 配置和安全態勢管理必須對關鍵SaaS應用程序(根據系統中存儲的數據的敏感性，或如果受到損害，可能造成的業務中斷)進行持續監控。這種監控能力，最好是自動化的，應該經常運行，并能夠在重大變更后臨時運行;理想情況下，它們還應該能夠在沙箱或預生產環境中運行，以便在生產SaaS環境中運行之前驗證配置更改。SaaS客戶對關鍵SaaS應用程序的態勢管理至少應該考慮：系統設置的配置基線，特別是與以下內容相關的設置：身份身份驗證和系統訪問，包括MFA、SSO和地理位置或IP限制密碼策略會話控制平臺提供的數據防泄露和審計功能平臺提供的加密和自帶密鑰功能已安裝和批準的第三方插件、集成以及OAuth或與其他

45、云之間的連接將用戶分配給SaaS應用程序中的角色、配置文件、組、團隊和SaaS應用程序中可以授予額外訪問權限或功能的任何實體配置訪問授權元素和對用戶的有效訪問可能顯示敏感或特權操作的管理操作和授權日志跨關鍵SaaS應用程序或環境的操作相關性用戶對關鍵類型的數據或記錄的訪問，以及確定讀?。C密性）和寫入（完整性）離職程序本節中的配置管理指的是配置控制。在NIST 800-53,CM-2中規定，“基線配置作為未來構建、發布或系統變更的基礎，包括安全和隱私控制實現、操作過程、關于系統組件的信息、網絡拓撲結構和組件在系統架構中的邏輯位置?！本S護基線配置需要在組織系統變化時創建新的基線。系統的 2022

46、 云安全聯盟大中華區版權所有24基線配置反映了當前的企業架構?！痹频暮锰幹皇谴龠M了軟件開發人員快速開發新功能、應用程序和服務。在目前主要SaaS應用程序中，通常包括創建和部署控制關鍵業務流程的少量或無代碼應用程序。具有權限的用戶可以快速部署和調整這些集成、工作流和應用程序。因此，這些權限對業務的潛在影響甚至更大，能夠監控和提醒這些功能的錯誤配置或使用是很重要的。此外，SaaS應用程序的快速配置能力和許多SaaS平臺上云應用程序市場的普及，可以允許用戶使用第三方(不是由SaaS客戶或SaaS提供商開發的)應用程序快速擴展SaaS平臺。雖然SaaS應用程序功能強大，但也會引入供應商風險評估和采購

47、程序中的漏洞。因此，安全組織必須具備監控和告警功能，用于檢測第三方應用程序與已批準的SaaS平臺的未經授權的連接，這一點至關重要。舉一個例子，需要將營銷自動化平臺(MAP)與客戶關系管理平臺(CRM)集成，從而將MAP數據提供給CRM。在此場景中，需要考慮并跟蹤數據流動的位置，是從MAP到CRM？還是從CRM到MAP？在這種情況下，數據流將是從MAP到CRM。然后需要檢查CRM是否有預先審核過的市場集成。通常情況下，市場集成更安全。在此之后，將檢查最佳實踐指南，或者聯系支持人員以獲得那些最佳實踐(如果無法自助獲取的話)。最后，需要分析如何確保最少特權并遵守數據最小化原則。此外，理解如何刪除連接

48、也是必要的。再看另一個示例，用戶將其谷歌賬戶與第三方應用程序集成。用戶主要查看第三方應用程序將獲得哪些權限和范圍，以及應用程序能夠代表用戶執行哪些操作，然后根據組織的風險偏好做出判斷，用戶可能需要在這方面獲得安全專家的支持，還可能想知道如何撤銷第三方訪問權限。在開發安全態勢管理策略和規則時，SaaS客戶可以利用行業最佳實踐(例如:微軟365的CIS基準)，與制定了基線安全策略的SaaS安全態勢管理供應商合作，或者在內部努力確定適合組織的最佳實踐和需求。通常，可以將這些方式結合起來制定最全面的政策。3.1.1.16 數據安全3.1.1.16 數據安全SaaS客戶應該監控存儲在SaaS應用程序中的

49、敏感數據的訪問，其方式與監控系統配置和安全狀況類似。同樣，由于SaaS應用程序固有的靈活性和可配置性，用戶對數據的訪問可能會快速變化。因此，與SaaS安全監控的其他部分一樣，關鍵是將對數據的監控訪問視為一個連續的過程，而不是一個時間點的操作。作為任一數據安全和訪問監控解決方案的一部分，SaaS客戶都應該定期(或使用自動化平臺特 2022 云安全聯盟大中華區版權所有25性)對數據按敏感級別、數據類型等進行分類。這種分類，無論是在外部系統中維護還是在SaaS平臺本身上維護，對于設計數據安全策略并根據該策略監控實際狀態至關重要。關于數據安全的其他注意事項，可能可以作為安全態勢監測的一部分進行監測，但

50、仍應明確定義，包括:配置(和用戶訪問)數據導出功能和數據備份功能資產、所有權和責任清單限制內部和外部共享和監控系統配置以匹配安全策略密碼控制和要求，并對系統進行監控，以確保其配置符合預期另一類可以應用于SaaS應用程序的安全解決方案是數據防泄露(DLP)解決方案。DLP解決方案通常與數據的訪問路徑一致，或者作為內置的SaaS應用程序功能，DLP提供更高級別的信息保護。DLP可以防止某些類型的文件的轉移或泄露。DLP解決方案也與數據分類有關系。首先，需要對數據和文檔進行分類，以便DLP解決方案能夠理解分類并進行相應的監控(例如，PII、PCI)。DLP運行主要基于關鍵字、短語和元數據。在DLP邏

51、輯匹配時，它可以執行一個或多個操作，如通知用戶、提醒管理員、阻止傳輸、刪除附件和文檔、編輯敏感數據，并保留數據副本以供檢查/取證目的。SaaS提供商通常為其客戶提供自動化處理的機制或API。當使用大量SaaS系統時，客戶將選擇與SaaS平臺集成的DLP解決方案，以實現無縫管理。3.1.1.17 用戶意識和培訓3.1.1.17 用戶意識和培訓為安全使用此服務制定最佳實踐指南強制執行數據分類和標記用戶了解此服務的安全事件并知道如何報告它們在可行的情況下添加指導策略（例如，用戶得到訪問某個類別的授權服務的提示，或者記錄使用替代選項的理由)為坦誠的報告事件營造良好氛圍 2022 云安全聯盟大中華區版權

52、所有263.1.1.18 內部威脅3.1.1.18 內部威脅離職員工可以將SaaS數據分享給他們的個人賬戶，導致公司數據的泄露員工在內部過度暴露敏感數據（財務和工程可以相互使用彼此的信息）敏感數據分享給錯誤的第三方未落實職責分離平臺配置不當導致數據泄露(例如，包含敏感數據的S3存儲桶被公開暴露)員工允許從系統中獲取大量數據，這可能會導致他們在辭職時泄露或帶走這些數據3.1.1.19 外部威脅3.1.1.19 外部威脅第三方合作者可以永遠訪問你的公司數據您的供應商與他們的供應商共享公司數據，這些供應商從未通過第三方風險評估使用公司數據的第三方合作者使用個人賬戶，而且通常沒有設置多因素身份驗證第三

53、方供應商或其分包商/供應商不受監管實體保護數據的約束3.1.2 用法3.1.2 用法可接受使用政策管理治理3.1.2.1 定期檢查服務/供應商3.1.2.1 定期檢查服務/供應商監控存檔版本發生變更的服務條款和條件安全保證的有效性持續的安全性能CSP供應商管理具有挑戰性 2022 云安全聯盟大中華區版權所有273.1.2.2 告警3.1.2.2 告警監控可疑的登錄和數據訪問監控服務的使用情況和濫用情況監控SLA符合性監控登錄和訪問中的任何異常監控任何有風險的組織范圍內的設置變化監控異常數據訪問服務條款和條件可能會隨時發生變化，導致失去控制。因此，需要使用自動化工具持續監控服務的屬性。很有必要監

54、控配置更改并告警。3.1.2.3 使用情況可見性3.1.2.3 使用情況可見性帶有登錄用戶名和用戶位置的身份驗證日志訪問日志審計日志賬戶配置和撤消配置日志3.1.2.4 持續評估并減少攻擊面3.1.2.4 持續評估并減少攻擊面監控服務的基本屬性，進行完整性檢查審查控制以減少攻擊向量監控潛在的內部故障點3.1.2.5 配置管理3.1.2.5 配置管理監控配置更改，并在必要時發出告警 2022 云安全聯盟大中華區版權所有283.1.2.6 數據3.1.2.6 數據監控對敏感數據、系統和字段的訪問監控管理行為啟用審計監控備份的有效性確保執行數據備份，更重要的是，通過備份還原來測試備份數據的可用性。3

55、.1.3 終止3.1.3 終止SaaS使用的終止需要統籌和有計劃的執行SaaS服務最重要但經常被忽視的風險之一在于CSP提供的合同傳統上，組織與法律部門合作，協商服務提供商的合同條款，使其不那么“對供應商友好”，并通過讓服務提供商承擔財務責任減輕由服務提供商造成的任何損失。但云提供商不愿意提供通常的賠償、責任限制或其他條款，尤其是與隱私和數據安全有關的條款。CSP提出的最普遍的理由是，這些額外的責任和義務會威脅到價格較低的云計算模式，而且，由于CSP不知道他們的客戶在云上存儲了什么，他們不需要承擔隔離和保護客戶數據的責任。然而，CSP必須為客戶提供實現這一目標的方法。云協議中的不利條款可能會增

56、加云客戶的風險。云客戶還可能希望通過合同來限制CSP用于存儲或處理客戶數據的分包商。如果沒有這些限制，客戶可能會發現它的數據實際上是從主CSP中流轉到了多個分包商。3.1.3.1 內部流程3.1.3.1 內部流程通知所有用戶服務終止關閉所有API訪問供應商替換或數據提取的指南提取數據供未來使用或遷移到新的服務存儲在哪里，誰應該負責？確保了解與所有其他系統的集成/數據流 2022 云安全聯盟大中華區版權所有293.1.3.2 數據保留3.1.3.2 數據保留銷毀備份和剩余數據/元數據(例如,系統日志、審計日志、訪問日志,索引)數據保留時間應滿足數據分類要求導出和刪除財務信息導出使用情況和其他報告

57、3.1.3.3 資產收益3.1.3.3 資產收益數據/元數據的導出(例如，審計日志，訪問日志，備份)符合數據位置要求可接受的數據格式交付期、方法及訪問時長3.1.3.4 解除特定于服務的附件3.1.3.4 解除特定于服務的附件特定服務監控服務的安全監控3.1.3.5 服務管理3.1.3.5 服務管理刪除所有與服務的集成確保服務退役確保合同結束 2022 云安全聯盟大中華區版權所有303.2 對信息安全政策的審查3.2 對信息安全政策的審查由于技術變化頻繁，因此有必要定期對政策進行審查。自上一個版本以來，可能需要增加額外的可接受的控制。這還要求SaaS操作仍然滿足組織設定的最低標準。一些解決方案

58、提供商（如CASB）對SaaS服務提供持續的評估和評分，并提供基于這些動態分數設置告警和訪問策略的功能。4.信息安全組織信息安全組織4.1 內部組織4.1 內部組織4.1.1 信息安全角色與責任4.1.1 信息安全角色與責任雖然很多人將SaaS視為外包責任，但是清晰地理解云服務客戶（CSC）和云服務商（CSP）之間的角色與責任是很有必要的。當客戶選擇潛在云服務商，執行盡職調查時，會有助于減少想當然和誤解，并且還將有助于區分云服務商和客戶之間的責任?？梢哉f，了解云服務商不負責什么比了解他們負責什么更為重要。充分理解云服務商和客戶之間的角色與責任劃分（參見“共享責任模型”介紹），將會暴露出很多云客

59、戶無法控制的控制項。一般認為，對于大多數SaaS應用場景，客戶負責如何授予應用和數據的訪問權限。與此同時，云服務商負責其它事項（例如，SaaS客戶無法控制的已知VM漏洞修復問題）。因此，云服務客戶將絕大多數的安全與維護活動委托給云服務商。SaaS解決方案的一些功能需要由客戶負責?？蛻舯仨殤獙μ魬?，投入時間了解風險，并將風險減少到可接受的水平?？紤]到SaaS應用接受低版本TLS協議（例如TLS1.2）的情形，客戶可能禁止使用老舊版本并強制應用程序僅接受TLS1.3協議。另一個例子是可能要求使用活動目錄對用戶進行身份認證。盡管如此，SaaS客戶依舊需要管理與技術控制措施的組合，以保護資產和資源免受

60、因對SaaS平臺依賴而產生的安全和操作風險。下表列出云服務客戶需要掌握的控制措施，請記住，實際的技術控制措施會因云服務商而異。2022 云安全聯盟大中華區版權所有31技術控制措施技術控制措施管理控制措施管理控制措施用于安全審計/日志的系統應用賬號用戶/系統授權特權賬號多因素認證用戶/系統授權特權賬號的系統監控所有特權賬號擁有者的年度認證所有賬號的身份與訪問管理（IAM）經鑒別的加密密鑰的所有權加密密鑰、數字證書的安全存儲庫所有云計算資源/資產的庫存管理安全通訊通道（如HTTPS，SSH，SFTP）獲得網絡/架構團隊的批準統一儀表盤（管理平面）管理所有云資源/資產（如SIEM，日志集成）用戶授權

61、指標度量合規性報告漏洞管理補丁管理修復加固漏洞的分類漏洞的通知事件管理工具CSP和CSC關于事件如何定義，溝通和管理達成一致性風險管理評估工具（包括）：漏洞掃描威脅建模滲透測試風險管理批準/評審關鍵風險指標與利益相關方溝通檢查結果知識轉移備注：請參考CSA企業架構CCM共享責任模型，了解云客戶與云服務商之間共享責任的詳細清單。2022 云安全聯盟大中華區版權所有324.1.2 職責分離4.1.2 職責分離要落實職責分離的安全原則，控制措施必須到位。簡言之，職責分離確保那些關鍵任務要求兩個或更多的人員/實體才能完成，其目的是防止欺詐或串通。NIST 800-145所定義的“云計算”，將“按需自助

62、服務”列為云計算的基本特征?！鞍葱枳灾铡币馕吨跋M者可以單方面提供計算能力，如服務器時間和網絡存儲，根據需要自動實現而不需要人工交互”。換言之，“按需自服務”的特性允許云計算非?？焖俦憬莸貑釉瀑Y源和資產，而不需要最終用戶具備太多專業知識。這也意味著職責分離的實施會變得非常復雜，且易于失控。用戶或應用創建/啟動的云資源可能是各種形式（如用戶/系統/應用的賬號ID，角色和賬戶組）?？蛻舯仨毭靼走@些資源可以訪問云內/云外的什么資源，以及與這些 ID關聯的特權，然后采取適當措施，確保這些賬號執行特定任務時僅擁有最小權限。否則，可能導致某個賬號具有超出預期的資源訪問權限。未能實現職責分離控制的安

63、全風險，包括未經授權披露機密/隱私信息、數據丟失、完整性受損等等。4.1.3 與監管機構的溝通4.1.3 與監管機構的溝通盡管云服務商需要負責大多數維護云解決方案的任務，客戶依舊對云上發生的一切負有責任。這是因為客戶在簽署合同時，同意“條款細則”中云服務商所提供的服務和限制?？蛻魬斢袝孢^程記錄，用以標識關鍵利益相關方，在事故發生時或SLA/OLA（服務級別協議/運行級別協議）改變時，及時發出通知。共享這些記錄給云服務商，以便他們知道發生事故時該通知誰。這些利益相關方應當清晰了解他們業務目標/成果和法律合規/監管要求。4.1.4 與特殊利益群體的聯系4.1.4 與特殊利益群體的聯系云安全面臨

64、的風險每天都在變化，幾乎不可能保持密切跟蹤。因此強烈建議組織指定專門的人員/團隊與這些特別利益群體建立/維護關系。這些群體通常跟蹤最新的，或“0Day”漏洞，同樣地，他們可能分享部分漏洞的可行修復方案。與特殊利益群體建立關系能節省公司的時間（比如尋找一個修復方案時）。另一個好處是，公司可以根據自身需要，選擇特定利益群體（例如按行業、技術、法規）。最終，這些特殊利益群體可以提供各種最新資訊，包括新趨勢、隱私、威脅、漏洞和修復方案。2022 云安全聯盟大中華區版權所有334.2 移動設備和遠程辦公4.2 移動設備和遠程辦公4.2.1 移動設備策略4.2.1 移動設備策略COVID-19（新冠疫情）

65、產生了任何人都無法預測的影響。許多公司不得不匆忙提供居家辦公方案以確保正常運轉。通過適配移動設備的Web前端，或安裝在移動設備上的特定SaaS服務應用，提供基于移動設備的SaaS服務訪問。這些設備形態各異，有個人/企業分派筆記本電腦，個人/企業分派移動電話，或平板電腦。沒有人能確信是否會恢復到新冠之前的正常狀態。因此，必須考慮開發出策略，流程以及指南，支撐安全的持續運營。云客戶必須識別出允許移動設備訪問企業資源的安全風險，以下是需要考慮領域的樣例：誰能訪問公司資源？這些訪問是僅限于內部員工，還是承包商和第三方供應商也能訪問？哪些公司資源是每個人都能訪問的？哪些公司資源應限制承包商/第三方提供商

66、訪問？訪問如何被授權-VPN，軟令牌，多因素認證？個人設備是否被允許訪問公司資源？如果允許個人設備訪問公司資源，我們如何保護資源免遭勒索軟件，釣魚，欺騙等攻擊行為？一旦員工/承包商被授權訪問，我們如何確保他們僅能訪問有明確訪問權限的資源？訪問行為如何被監控或記錄？我們如何確保公司的機密/秘密信息不被盜，或被轉移到異地（或者給了非授權的個人或競爭對手）？如果一名員工決定離開公司，應該采取哪些措施，以確保公司數據不會被離職員工帶走？2022 云安全聯盟大中華區版權所有34除了技術控制措施，下面是一些同樣需要考慮的管理控制措施（未詳盡列舉）：安全意識培訓可接受使用政策數據分類標準/策略機密/秘密數據

67、的處理介質的管理使用移動介質加密（針對公司分派設備）物理管控（針對公司分派設備）數據保留/銷毀5.資產管理5.資產管理要從SaaS服務中獲益，SaaS客戶需要提供特定數據交由SaaS服務處理。因此，對于SaaS客戶來說，數據的管理顯得尤為重要。5.1 資產責任5.1 資產責任5.1.1 資產臺賬5.1.1 資產臺賬SaaS客戶應當能回答以下問題：哪些數據會被轉移給SaaS服務？這些數據是如何轉移的？SaaS服務會訪問哪些數據？我們依賴于SaaS服務的數據是哪些？對數據是否有地理位置的要求，例如監管或客戶服務要求？在全組織范圍內，有多少SaaS應用在使用，是否有“影子SaaS”存在？客戶是否能識

68、別出不再使用的資源？那些不使用（但存活）的資源會迅速增加運行開支。2022 云安全聯盟大中華區版權所有35客戶是否能便捷地識別所有云托管資源？應當具備一個公司級，集中化的資產數據庫，以記錄資產的所有權和管理責任。此外，還應制定一個企業范圍內的標記策略和架構。資產標記使得客戶方便地精確追蹤云托管資源，能支持企業安全治理措施，因為它使得云資源可以按照地理位置，敏感度，法律規定，成本優化以及其它許多屬性進行分類。5.1.2 資產識別5.1.2 資產識別應采取相應的流程和解決方案以持續發現和識別組織內SaaS的使用情況?？梢酝ㄟ^以下4種方式中的一種來實現。通過流程控制的方法，確保IT和安全在所有Saa

69、S服務采購和使用之前都能了解通過分析與評估來自防火墻、Web網關和云訪問安全代理（CASB）的日志通過使用SaaS安全態勢管理解決方案通過分析SaaS相關的支出報告和財務記錄5.1.3 資產歸屬5.1.3 資產歸屬SaaS客戶應當能回答以下問題：誰為存儲在SaaS服務中的數據負責？誰是 SaaS的管理員？5.1.4 可接受的資產使用方式5.1.4 可接受的資產使用方式包括兩個部分：允許SaaS提供商對我們的數據做哪些處理？元數據？我們的SaaS服務用戶可以對數據做哪些處理？數據與元數據的控制：所有權，處理，許可。2022 云安全聯盟大中華區版權所有366.訪問控制6.訪問控制6.1 訪問控制的

70、業務需求6.1 訪問控制的業務需求6.1.1 訪問控制策略6.1.1 訪問控制策略評估一個人是否需要訪問資源識別業務需求和角色基于數據分類的信息清理獲得安全審查和數據所有者（決策人）的批準組織中的用戶通常根據過往經驗或克隆其對等角色訪問權限的方式對應用程序授權。因此，評估一個人是否真正需要一項服務的訪問權限，并識別業務要求和建立角色就非常重要。6.2 用戶訪問管理6.2 用戶訪問管理身份與訪問管理（IAM）的妥善管理和架構設計，對于保護云資源是不可或缺的。當人員入職時，必須考慮安全和業務需求，根據其工作角色或業務要求，將對應的用戶分組、權限隔離和特權要求分配給用戶。擁有適當的IAM實踐有助于落

71、實最小權限和職責分離。6.2.1 用戶注冊與注銷6.2.1 用戶注冊與注銷6.2.1.1 用戶訪問配置6.2.1.1 用戶訪問配置基于最佳實踐的用戶培訓知曉可接受的操作使用，相關策略和程序根據用戶訪問基線創建賬號應作為員工入職、轉崗/調崗、離職相關流程的一部分只要條件允許，利用基于角色的訪問并遵循最小權限計費方：基于用量的分組或負責人了解并設置資源限額 2022 云安全聯盟大中華區版權所有37了解并設置資源限額，始終遵循最小權限原則。6.2.2 特權管理6.2.2 特權管理必須追問發起特權訪問的正當理由，以確保是必需的考慮使用“即時訪問”，需要時才提升為特權權限，并及時恢復到非特權訪問擁有特權

72、訪問的用戶數量應限制在最小規模6.2.3 機密認證信息的管理6.2.3 機密認證信息的管理超級管理員賬號（如租戶管理員）只能用于非常特殊的用途，訪問憑據的存儲要有對應的安全級別，例如使用Key Vault密鑰庫6.2.4 評審用戶訪問權限6.2.4 評審用戶訪問權限需要定期審查訪問權限，確保用戶權限與業務需求匹配6.2.5 移除或調整訪問權限6.2.5 移除或調整訪問權限確保即時賬號終止停止有關賬號的資源付費審計日志和訪問日志必須與業務策略保持一致如果需要進行安全審查更新賬號終止日志和資產庫確保審計日志按安全策略的要求進行復查和存儲。最后，當資源不再使用時，要確保計費停止。該動作應自動執行，并

73、努力消除任何人工操作。2022 云安全聯盟大中華區版權所有386.2.6 用戶訪問監控6.2.6 用戶訪問監控基于基本使用情況設置監控告警對可疑登錄（如地點，時間）和數據訪問（如批量訪問）進行告警遵守密碼策略數據丟失預防監測對可疑行為和登錄進行監控和告警設置，以區分內部員工與外部/承包商的訪問活動利用基于API的解決方案監控“靜態數據”6.3 系統和應用訪問控制6.3 系統和應用訪問控制6.3.1 信息訪問限制6.3.1 信息訪問限制遵循SaaS客戶的企業安全策略，通過身份驗證的用戶僅限于從許可設備上訪問 SaaS應用存儲的信息。鑒于某些應用程序的特性（如與外部合作的應用），這種嚴格的訪問限制

74、不可行，可采用類似反向代理的其它方案，提供細粒度訪問控制?？刹捎没贏PI的解決方案以保護靜態數據，執行適當的共享與DLP策略（例如，有個人可識別信息的任何文檔如果分享到外部域，將自動恢復到僅限于內部用戶訪問）?？紤]到SaaS應用面向互聯網，只要有可能，應當根據許可IP范圍或位置限制訪問范圍。一旦訪問，SaaS應用保存的信息會被下載。應該開發適當的安全策略，以確保信息下載到符合企業安全策略的受許可設備。能夠區分出經過批準和未經批準的SaaS應用實例是非常重要的，還要應用相應的使用策略。對任何第三方的基于API 的訪問都需要經過適當的檢查才能獲得批準，并在滿足業務要求后撤銷。如果SaaS服務商需

75、要訪問SaaS客戶的數據，應該通知客戶，由客戶評估請求并最終決定批準或拒絕。2022 云安全聯盟大中華區版權所有396.3.2 安全登錄程序6.3.2 安全登錄程序不能使用基本認證（Basic Authatication），該方式本身就不安全如果可能，SaaS應用程序應使用商用的身份服務，啟用單點登錄SSO以保障安全地登錄如果沒有SSO，SaaS應用程序應強制密碼復雜度和確保未泄露（例如在網站https:/ 密碼管理系統6.3.3 密碼管理系統如果可能，SaaS應用程序不應管理密碼，而是通過IdD（身份提供商）啟用SSO認證針對SaaS應用本地密碼驗證的情況，密碼存儲應遵循OWASP指南密碼還

76、應被存儲在Key Vault密鑰庫，或類似的用于保護訪問機密性、完整性和可用性的安全設備。需要注意，密碼是一種“憑據”。為了方便討論，“憑據”的形態包含加密密鑰、數字證書，或令牌Token。如果云服務客戶不能管理密鑰，那么強烈建議使用Key Vault密鑰庫或類似安全方案保障密鑰的機密性、完整性和可用性。2022 云安全聯盟大中華區版權所有406.3.4 使用特權實用程序或第三方插件6.3.4 使用特權實用程序或第三方插件不應該允許以編程方式進行基本身份驗證應通過mTLS（雙向TLS）驗證訪問者的身份首選基于令牌的身份驗證（OAuth 2.0）SaaS API應僅在指定的IP范圍內可用建立安全

77、庫并以加密格式存儲特權憑據API的密鑰應安全存儲，并且只能通過HTTPS傳輸SaaS應用程序應該能夠撤銷訪問密鑰和令牌授權應定期審查用于特權程序訪問的身份審查用戶對第三方應用程序的許可監控第三方應用程序的活動6.3.5 程序源代碼訪問控制6.3.5 程序源代碼訪問控制SaaS提供商應限制對源代碼的訪問對產生源代碼的開發管道或環境的訪問控制也應僅限于SaaS提供商源代碼不應向不受SaaS提供商控制的程序或系統提供后門訪問，也不應向SaaS消費者提供源碼訪問SaaS消費者創建的任何源代碼以及備份應只被他們自己訪問CSC應記錄一個流程，描述要實施的安全門，以及在使用CI/CD管道時會觸發安全審查的事

78、件。安全門是一種評估軟件安全風險的安全策略。在軟件進入下一階段前，必須審查和批準所有軟件代碼 2022 云安全聯盟大中華區版權所有417.加密和密鑰管理7.加密和密鑰管理7.1 SaaS環境中的數據安全7.1 SaaS環境中的數據安全使用SaaS服務時需要考慮的最關鍵的方面之一是存儲在該服務中的數據的安全性。在此運營模型中，供應商承擔了應用程序安全的大部分責任。然而，正如共享責任模型所認為的那樣，數據是云消費者的責任。為了確保傳輸并存儲到SaaS提供商的數據是安全的，客戶在與這些供應商接洽時應考慮數據的加密以及對加密密鑰的管理。無論何時從安全的內部位置移動數據，客戶組織都有意外或惡意暴露數據的

79、風險。確保正確的加密和密鑰管理意味著，即使確實發生了對數據的不正當訪問，在不先對數據解密的情況下，數據將無法使用。本節回顧了客戶組織可以采取的步驟，以確保使用管理良好的加密密鑰對存儲在SaaS提供商中的數據進行充分加密。7.1.1 共享責任模式7.1.1 共享責任模式雖然使用SaaS服務將管理和維護應用程序的一些責任從客戶組織轉移到了供應商，但一些責任仍將由客戶承擔。這些責任包括SaaS服務中數據的管理和安全以及其中的訪問模型。責任始終由客戶承擔責任始終由客戶承擔信息和數據信息和數據設備設備(移動端和移動端和PC端端)賬戶和身份賬戶和身份責任因類型而異責任因類型而異身份認證和目錄基礎設施身份認

80、證和目錄基礎設施應用應用網絡控制網絡控制操作系統操作系統責任轉移至云提供商責任轉移至云提供商物理主機物理主機物理網絡物理網絡物理數據中心物理數據中心云提供商負責云客戶負責共享責任責任責任SaaSPaaSIaaS本地On-Prem 2022 云安全聯盟大中華區版權所有427.2 加密SaaS提供商共享的數據7.2 加密SaaS提供商共享的數據如上所述，任何時候從安全的內部位置移動數據，都有意外或惡意泄露的風險。緩解此風險的最佳方法可能是確保數據在傳輸到SaaS提供商或從SaaS提供商傳輸時以及存儲在SaaS提供商系統中時加密。這包括確保應用程序和物理資源內的正確加密，這是SaaS提供商的責任。7

81、.2.1 需要考慮的問題和領域7.2.1 需要考慮的問題和領域需要加密的級別和需要存放的位置取決于對傳輸數據的理解和SaaS提供商的通用做法。在確定數據所需的保護級別時，應考慮以下問題：7.2.1.1 供應商問題7.2.1.1 供應商問題供應商是否提供共享數據的精細控制（例如，僅在內部共享、與選定合作伙伴共享還是與所有人共享等）SaaS提供商是否在傳輸過程中提供數據加密？SaaS提供商是否提供靜態數據加密？SaaS提供商是否支持端到端加密？SaaS提供商支持哪些加密算法和傳輸協議？SaaS提供商是否為每個客戶提供唯一的加密密鑰（單租戶）？SaaS提供商是否有關于其關鍵管理程序的文檔？SaaS提

82、供商是否允許使用客戶管理的加密密鑰？SaaS提供商是否能夠識別和/或屏蔽（遮掩）敏感數據？當需要將生產數據復制到沙盒環境時，SaaS提供商是否支持假名化或修改（重新編輯、替換、刪除等）？SaaS提供商是否為用戶提供了標記敏感數據或字段的機制？2022 云安全聯盟大中華區版權所有437.2.1.2 內部問題7.2.1.2 內部問題上傳到SaaS提供商的數據是否包含任何敏感細節？敏感數據可能包括類似個人可識別信息（PII）或由您的數據隱私和合規需求定義的其他元素。如果數據公開，對客戶組織有何影響？對組織的關鍵管理實踐是否有信心？內部流程是否支持端到端加密？7.2.2 傳輸加密7.2.2 傳輸加密數

83、據從一個位置移動到另一個位置時被視為“傳輸中的數據”，這包括從客戶組織傳輸到SaaS提供商的數據，反之亦然。配置多個互操作層時，數據安全性最強；因此，在數據傳輸過程中，安全性通常認為較低，因為用于保護數據的層較少。為了保護傳輸過程中的數據，建議確保在所有數據傳輸中使用安全的加密網絡協議。在編寫本文時，最佳加密網絡協議是傳輸層安全（TLS）1.2版或更高版本（首選TLS 1.3）。為了提升安全級別，TLS協議使用對稱加密（使用相同的密鑰加密和解密數據）和非對稱加密（使用數學上相關的公鑰和私鑰加密和解密數據）的組合。這種組合的加密方法增強了所傳輸數據的機密性和完整性。TLS 1.3刪除了TLS 1

84、.2中的一些影響性能的步驟，同時又不犧牲安全性。TLS 1.2和1.3的TLS握手和密鑰交換過程示例如下:圖 3.TLS 1.2(完整握手)圖 4.TLS 1.3(完整握手)2022 云安全聯盟大中華區版權所有447.2.3 靜態加密7.2.3 靜態加密如果數據在應用程序、網絡或系統中不移動，則視為“靜態”。如果數據在“靜態”期間沒有充分的保護，對SaaS提供商托管設施進行不當訪問的攻擊者可以公開（或泄露）這些數據或將其用于牟利。對靜態數據加密可確保即使存儲數據的硬件被盜，數據也不可用。數據也可以在應用程序中加密，確保只有SaaS消費者能夠看到他們的數據（因為他們是唯一可以解密數據的人），從而

85、在多租戶SaaS提供商環境中提供了一個邊界。加密的類型和強度取決于數據分類。如果存儲的數據被視為公共數據，則可能不需要像敏感數據那樣嚴格的加密。因此，客戶組織應在向SaaS提供商存儲數據之前做如下審查：數據泄露的業務影響分析(BIA)為了確定數據是否需要在靜態下加密，組織應執行BIA，以了解數據公開后的影響。另外應考慮CSP的其他安全組件，如訪問管理，以確定數據泄露的風險.靜態加密服務的可用性并非所有SaaS提供商都將免費提供靜態數據加密服務。了解購買（或獲?。╈o態加密所需的許可模型。靜態備份數據加密的可用性雖然許多SaaS提供商將提供一種靜態加密形式，但這并不總是適用于數據備份。確保對活動存

86、儲的數據和備份數據進行加密。加密磁盤加密vs文件加密了解提供的靜態加密類型。例如，使用磁盤加密方法雖然是一種合理的控制，但主要用于在磁盤或系統被盜時提供保護。作為一種更為常見的情況，使用文件加密可以保護單個文件和數據在不適當的訪問情況下不被竊取。用于加密靜態數據的加密算法和密鑰長度確保靜態數據的加密方法滿足CSC的需要。NIST 800-57第1部分：密鑰管理建議（參考表2）詳細說明了基于算法和密鑰長度的加密強度。2022 云安全聯盟大中華區版權所有457.3客戶管理加密密鑰 vs 供應商管理加密密鑰7.3客戶管理加密密鑰 vs 供應商管理加密密鑰通常，使用客戶管理的加密密鑰比供應商提供的加密

87、密鑰更安全。然而，是否使用供應商管理的加密密鑰取決于兩個因素。首先，供應商是否允許使用客戶管理的密鑰？并非所有供應商都支持使用你的加密密鑰。其次，確保存儲在供應商中的數據是否能達到使用你自己密鑰同等級別的風險緩解水平，或者使用供應商管理的密鑰的風險是否可以接受？例如，使用供應商管理的加密密鑰的風險水平取決于以下幾個方面：供應商是否提供有關如何創建和管理加密密鑰的信息？在大多數情況下，供應商不會共享其環境中加密密鑰的創建和生命周期管理背后的詳細信息。為了更好地了解供應商的密鑰創建和管理實踐，建議要求提供他們系統中數據在傳輸和使用時如何加密的文檔存儲在供應商系統中的數據有多敏感？例如，被定義為公共

88、級別的數據在使用其加密密鑰時可能幾乎沒有風險。組織是否有良好的加密密鑰管理實踐？除了供應商的安全之外，通過密鑰管理提供的保護還取決于您的組織保護密鑰材料的能力。如果您的組織在實踐方面與供應商相比還不成熟，那么使用供應商管理的密鑰可能最適合您。7.4 加密和密鑰管理的未來狀態7.4 加密和密鑰管理的未來狀態未來考慮的領域:硬件安全模塊即服務(HSMaaS)有時也稱為“云HSM”，這是一種通過SaaS提供的HSM產品創建和管理加密密鑰的方法。經FIPS驗證的HSMaaS提供商，如Fortanix、Microsoft，其他提供商的使用率正在增加。隱私增強加密(PEC)方法 2022 云安全聯盟大中華

89、區版權所有46一組技術，用于在維持功能的同時最大限度地減少系統收集的個人或敏感數據量。為了維護通用服務，SaaS提供商可能不支持使用PEC技術，因為他們需要更多的定制和與用戶系統的交互來實現結果。NIST提供了博客帖子和一個項目來審查PEC技術，并圍繞這些技術制定標準和要求。同態加密涉及對使用中的數據加密，同時仍允許通過位級加密/解密對數據操作。與傳統方法相比，速度非常慢。PEC方法的需求文檔，包括同態加密,仍在由ISO和NIST等組織通過開放聯盟領導開發。機密計算 或 安全飛地使用硬件特性來保護云數據安全，使用中可通過從其他并發工作負載中隔離和處理數據。NIST有可用的文件草案，提供有關云計

90、算和邊緣計算的保密計算技術的進一步信息。后量子密碼技術(PQC)方式可能至少在8年以后。2016年的NIST內部報告（IR）8105指出，到2030年，能夠在數小時內破解2000位RSA的量子計算機可能已經存在。NIST和其他組織，已經有項目在推進后量子加密標準的制定，其中一些組織公開呼吁提交和反饋。2022 云安全聯盟大中華區版權所有478.操作安全8.操作安全8.1 操作程序和職責8.1 操作程序和職責8.1.1 記錄的操作程序8.1.1 記錄的操作程序SaaS產品的靈活性使得有必要了解組織將如何使用此類產品。訪問控制-參見訪問控制章節變更管理容量管理環境隔離終止-參見終止章節8.1.2

91、變更管理8.1.2 變更管理添加SaaS產品應經過深思熟慮，太隨意的添加到組織的生態系統可能會導致問題。因此，應實施強有力的變更管理流程。SaaS產品的變更往往很小而且很頻繁。通常，用戶可能看不到這些變更。然而，下游系統可能會受到影響。重要的是要確定變更是否會影響組織的安全態勢。此類變更可能需要組織修改其他系統。需要審查重大變更（通常是版本變更），并將其作為變更管理流程的一部分。此外，SaaS產品通?？紤]在特定的操作范圍內使用。SaaS應用程序業務功能的后期更改、使用量的增長或使用復雜性的變化可能會導致需要重新考慮與使用SaaS應用程序相關的安全注意事項。建議管理員定期審查SaaS應用程序的使

92、用情況，確保初始安全審查的范圍與當前的使用范圍相匹配。這將確保維護SaaS應用程序的最新安全模型。8.1.3 容量管理8.1.3 容量管理SaaS產品的使用可能對用戶數量有許可限制。監控產品還可能限制被監控或附屬的賬戶數量。根據用戶或賬戶的數量，可能存在定價差異。在提高容量之前，需要考慮了解需求。2022 云安全聯盟大中華區版權所有488.1.4 開發、測試、運行（生產）環境隔離8.1.4 開發、測試、運行（生產）環境隔離與內部開發的系統一樣，有必要進行環境分離，以防生產數據從經批準的生產系統中泄漏。預計SaaS供應商將不斷改進其系統。改進、升級或更新應該在具有非生產數據的非生產環境中測試。S

93、aaS供應商應提供證明，證明不僅存在單獨的環境，而且非生產數據也駐留在這些環境中。此外，應持續評估這些SaaS應用程序的配置，以確保維護安全的環境。識別安全設置中的錯誤配置、跨用戶數據訪問、第三方集成等可以降低發生數據泄漏的風險。應在“過渡到產品（staging to product）”工作流（即產品研發工作流）涉及的環境中進行安全審查，以便在安全問題影響生產環境之前被及時識別。8.2 防止惡意軟件8.2 防止惡意軟件8.2.1 惡意軟件控制8.2.1 惡意軟件控制惡意軟件保護的大部分責任在于SaaS提供商，然而，在SaaS用戶/管理員的控制下，仍然存在一些傳播惡意軟件的媒介。這些用戶控制的媒

94、介包括客戶自定義的靜態文件托管和附件，這些文件托管和附件可以由使用SaaS應用程序/特權用戶的組織員工上傳，或者由普通公眾上傳（如果SaaS應用程序提供面向公眾的門戶）。SaaS管理員及其安全組織應進行典型的威脅建模練習，了解SaaS部署的面向公眾的功能中存在哪些內容上傳功能（如果有的話）。要注意面向公眾的內容或文檔上傳系統，它們旨在存儲或傳輸SaaS應用程序內部的，或特權用戶將下載到企業設備上以其他方式查看的文件。在評估其SaaS部署和配置時，客戶應該熟悉SaaS平臺的內置功能。很多都具有標準化的惡意軟件和病毒掃描功能，可以標記或阻止潛在的惡意上傳。應對SaaS系統的配置進行評估和監控，以（

95、1）最大限度地減少可上傳的外部控制內容的類型和數量，（2）確保啟用內置保護和文件類型限制。2022 云安全聯盟大中華區版權所有498.3 備份和高可用8.3 備份和高可用8.3.1 信息備份8.3.1 信息備份在大多數SaaS應用程序中，在基礎設施或應用程序層出現故障時，管理數據備份、冗余和故障轉移的責任由SaaS提供商承擔。這是合理的責任分配，因為SaaS客戶沒有直接訪問數據庫、創建故障轉移實例/副本等的能力?？蛻魧祿脑L問通常僅限于SaaS平臺支持的API，這通常是創建和管理數據備份的低效方法。如果發生災難性數據丟失事件，SaaS平臺提供商將負責恢復數據。因此，當管理SaaS部署時，信息

96、備份并不像在IaaS或其他部署那樣重要，客戶在較低級別上控制部署即可。也就是說，SaaS客戶仍然需要考慮信息備份方面的問題。如果在SaaS應用程序的預期/允許使用參數范圍內無意或惡意刪除數據(即惡意參與者使用支持的刪除流程、API端點等刪除數據和/或記錄)，SaaS提供商將不負責提供備份并從備份中恢復。作為客戶管理SaaS應用程序的經驗之談。如果平臺按照設計的方式運行，即使配置是不安全的或不正確的，SaaS提供商也沒有責任補救。為了減輕SaaS客戶的此類風險，部署持續配置和數據訪問監控至關重要，以幫助確保不會向任何可能導致數據丟失事件的用戶授予無意或過高的訪問權限。這可能包括管理數據訪問，以便

97、正確授予用戶最小權限，以及監控系統配置，確保邏輯刪除或數據保留設置允許輕松恢復數據。最后，如果SaaS提供商尚未在平臺上提供“回滾”或“備份”解決方案，SaaS客戶應考慮是否提供額外的，基于平臺外的API數據備份解決方案，為關鍵數據提供額外的冗余。除了備份數據外，CSC還應實施快照策略。NIST標準800-125將快照定義為“運行圖像狀態的記錄，通常捕獲圖像與當前狀態之間的差異。例如，快照將記錄虛擬存儲、虛擬內存、網絡連接和其他狀態相關數據的更改?？煺赵试S掛起虛機系統并隨后恢復，而無需關閉或重新啟動虛機。許多（但不是所有）虛擬化系統都能打快照?！笨煺盏囊粋€好處是，與從備份執行恢復相比，可以更快

98、地恢復圖像/數據。8.3.1.1 高可用8.3.1.1 高可用許多SaaS提供商在與SaaS客戶的合同中定義了SLA和OLA，如果他們不能滿足合同要求，通常會有服務承諾支持。也就是說，考慮到SaaS應用程序的需求，SaaS客戶可以選擇不同的冗余選項。不應該僅僅因為它是SaaS，就認為它總是可用的，并且應該探索可用的備選方案，同時考慮到業務對SaaS應用程序可用性問題的影響。2022 云安全聯盟大中華區版權所有508.4 日志和監控8.4 日志和監控8.4.1 事件日志8.4.1 事件日志與安全團隊可能更習慣使用的基礎設施、IaaS、PaaS 或應用程序日志相比，SaaS 部署的事件和訪問日志記

99、錄具有明顯的挑戰。從使用SaaS應用程序日志的安全組織的角度來看，由于安全組織無權訪問運行SaaS應用程序的硬件或軟件的底層日志的事實，因此存在重大限制。在極少數情況下，SaaS提供商可能會通過手動請求流程提供更詳細和（或）更原始（更接近應用程序源）的日志。但是，由于這些選項所涉及的時間延遲、過程成本和財務成本，因此不能視為SaaS日志監控最佳實踐的一部分。對于監控SaaS應用程序安全的安全組織，更為復雜的是，SaaS應用程序日志輸出沒有行業標準的公認格式。像用戶登錄這樣的常見操作在不同SaaS應用程序之間的日志消息格式和內容方面可能會明顯不同，這給希望跨SaaS應用程序關聯日志和活動的安全組

100、織帶來了挑戰。日志交付的及時性也會給希望使用SaaS事件日志作為事件檢測手段的安全組織帶來挑戰。日志條目只有在經過SaaS提供商處理并在API或其他交付設施中提供以供最終用戶自動訪問后，才能供SaaS應用程序用戶使用。從事件發生到事件日志可用性的SLA規定可以是幾分鐘到24小時，取決于SaaS提供商。這些復雜性給使用SaaS事件日志作為監控SaaS應用程序中的安全性和活動的唯一機制帶來挑戰，但這并不能消除監控SaaS事件日志作為整體SaaS安全解決方案一部分的價值。使用SaaS事件日志的安全組織應該確保開發或部署以下功能:從SaaS應用程序或提供商處獲取日志的自動化程度和頻率應該更高SaaS

101、日志首先應標準化為跨SaaS應用程序的通用格式，然后再傳送到 SIEM 或其他日志存儲解決方案。這使安全團隊能夠有效地監控SaaS應用程序的活動包含用戶信息（如用戶名或用戶 ID）的事件、審計、活動和其他的日志條目應標準化為企業身份，以便同一個人在不同SaaS應用程序中的不同用戶賬戶可以關聯每個SaaS應用程序的操作和日志條目可用性的預期、平均和最大延遲應記錄在案，并將由使用日志系統的安全運營團隊理解 2022 云安全聯盟大中華區版權所有518.4.2 日志信息的保護8.4.2 日志信息的保護8.4.2.1 管理員和操作員日志8.4.2.1 管理員和操作員日志許多SaaS 應用程序，尤其是那些

102、具有顯著復雜性的應用程序，都有單獨的日志記錄或審計工具來監控高權限用戶所做的系統級配置更改。該系統可能被稱為“審計跟蹤”、“設置日志”或類似名稱。在許多情況下，這會是與標準訪問和事件日志相比在邏輯上獨立的數據結構，并且可能需要不同的 API 或訪問方法檢索。這些日志對于SaaS 事件監控至關重要，由于它們表示特權、經過身份驗證的操作，可能會對SaaS應用程序的安全狀況產生重大影響。此日志子集應遵循本文檔“事件日志記錄”部分中概述的所有最佳實踐。此外，監控SaaS應用程序的安全團隊應該熟悉這組日志中最受關注的操作類型，并考慮部署可以監控這些日志的安全自動化技術，并提醒安全團隊注意特權用戶（即Sa

103、aS 管理員）所做的影響安全的更改。監控SaaS生態系統中這些預定義的“高風險”活動旨在減少檢測時間，這有助于減少與SaaS數據泄漏相關的損害。8.5 技術漏洞管理8.5 技術漏洞管理確定SaaS 應用程序的所有者，并將這些所有者與安全功能聯系起來。在大多數組織中，SaaS安全屬于企業安全團隊的責任。但是，一些組織將SaaS安全定義為應用程序安全或第三方風險問題。無論誰負責，確定SaaS應用程序的所有者、了解每個SaaS應用程序的業務用例，然后定義漏洞管理的責任都至關重要?？鏢aaS應用程序控制安全性可能是一項重大挑戰。例如SaaS 客戶可能無法緩解發生在SaaS提供商基礎設施中的已知漏洞。但

104、是，大多數SaaS安全問題（以及相關的云安全問題）都發生在客戶共享責任范圍內。這些共享責任包括管理SaaS應用程序的設置和配置，確保它們符合安全最佳實踐。根據 NISTCSF、ISO 27001或NIST 800-53等標準審查策略配置，是降低不合規或不安全配置環境風險的有效做法?？紤]SaaS應用程序接受弱TLS加密套件的情況?？蛻舻牟呗钥梢詮娭破渌杏脩粼谂c該SaaS的連接上使用安全性更強的加密套件，從而減輕此漏洞，直到最終解決為止。此外，需要考慮管理員關閉關鍵安全防護機制（如 xss 防護）以便于為用戶提供更流暢的體驗。在這種情況下，管理員應該通過對這種錯誤配置的持續監控機制得到告警，并修

105、復問題。2022 云安全聯盟大中華區版權所有528.5.1 技術漏洞管理8.5.1 技術漏洞管理SaaS安全只有通過IT應用程序所有者、企業安全團隊和技術領導者之間的跨職能協作才能最有效地得到改善。IT 應用程序所有者必須負責問題的補救，而安全人員必須負責分類和跟進，確保在組織內商定的唯一SLA范圍內補救。必須與組織接受的SLA保持一致，并像對待任何其他安全域一樣遵循。如云安全聯盟博客文章“構建SaaS 安全計劃：快速入門指南”中所述，“了解哪些SaaS應用程序屬于對哪些團隊很重要，因為一旦您確定了問題，就需要與正確的業務團隊溝通以解決它們。不可避免的是，業務關鍵型 SaaS工作流中可能存在一

106、些最緊迫的安全問題。因此，應急響應團隊需要迅速采取行動，清點所有安全漏洞，把它們映射到所有者，并對每個發現的風險做出基于嚴重性的決策，以便他們能夠首先解決最重要的問題?！?.6 信息系統審計注意事項8.6 信息系統審計注意事項8.6.1 信息系統審計控制8.6.1 信息系統審計控制SaaS提供商可能不受客戶的信息系統審計控制。但是，客戶需要（通常通過法規）確保 SaaS提供商具有可接受的控制措施。這可以通過自我證明或第三方證明。雖然自我證明可能是法律要求的最低審查，但也是了解現有安全控制是否有效運行的最不可靠的方法。同樣，仔細閱讀第三方審查結果至關重要，并且要重點關注以下方面：評估范圍-讀者可

107、能會發現參與的第四方不包括在評估范圍內，包括額外的IaaS、PaaS、SaaS或其他第四方解決方案。如果是這種情況，了解供應商管理/第三方風險政策、清單以及所進行評估的范圍和深度將會非常重要。測試和報告方法-選擇放棄現場審查并選擇依賴第三方評估（ISO27001，SOC2 Type II）應由熟練且全面的審核人員考慮和評估，最好具有行業認可的證書，也最好具有實施縱深防御戰略的豐富經驗。第三方評估應讓讀者相信SaaS技術和安全人員接受了訪談，閱讀了安全策略文件，收集了樣本并進行了測試。評估員的專業水平也可以從報告語言中推斷出來。應摒棄對控制語言的簡單重述，以及不存在或不可靠的測試方法。2022

108、云安全聯盟大中華區版權所有53這可以通過在合同中加入條款，要求SaaS提供商遵循特定可接受標準的條款來實現（例如，CSA 的 CCM、FedRamp、NIST、ISO），并提供對這些標準的認證，并定期審查證明控制有效性的證據。云安全聯盟提供基于云控制矩陣(CCM)版本 4 的審計指南。這些指南旨在促進和指導 CCM審計。根據 CCMv4.0 控制規范向審計員提供了一套評估指南，旨在提高控制實施的可審計性并幫助組織更有效地實現合規性。這些指南在本質上既不詳盡，也不具有規范性質。它們代表了評估建議形式的通用指南。審計師將需要定制描述、程序、風險、控制和文件，并根據評估范圍內調整組織和服務的審計工作

109、計劃，解決審計的具體目標。9.網絡安全管理9.網絡安全管理在SaaS服務消費背景下，網絡安全的治理或與數據流安全相關的控制已分為兩個不同的領域;由SaaS提供商擁有和操作的控制措施以及SaaS使用者可能需要考慮的控制措施?？鐑蓚€域的關鍵網絡控制可以概括為傳輸中的數據加密、對指定資源的授權和數據傳輸控制。這里介紹了實現網絡安全的零信任網絡訪問ZTNA和安全訪問服務邊緣SASE方法。9.1 SaaS提供商網絡控制9.1 SaaS提供商網絡控制服務消費者應與SaaS提供商確認有效的TLS證書用于外部連接和微服務的內部保護。證書應該來自知名的、受信任的證書頒發機構，而不是自簽名的。此外，服務消費者應設

110、法確認在SaaS平臺內的離散服務組件之間使用加密的程度。SaaS 提供商可以通過零信任網絡訪問策略在最低特權的基礎上控制網絡數據流。SaaS提供商可以利用網絡流量異常檢測功能作為檢測控制。9.2 SaaS消費者網絡控制9.2 SaaS消費者網絡控制服務消費者在評估與SaaS提供商相關的安全狀況和風險時應考慮以下網絡安全控制。由于與SaaS提供商的連接可能會遍布公共互聯網，通過TLS 1.2及以上版本保護傳輸中的數據是關鍵的安全控制。2022 云安全聯盟大中華區版權所有54訪問SaaS服務可能會為不良行為者提供機會，通過將數據上傳到不受SaaS消費者控制的賬戶泄露數據?？梢允褂迷圃L問安全代理(C

111、ASB)和租賃通道身份驗證控制這種風險。還應考慮數據丟失預防(DLP)控制；這些可能部署在網絡或其他層，具體取決于對有效載荷數據的訪問。服務消費者在構建與SaaS提供商的網絡連接時應考慮可用性要求，例如冗余互聯網線路和容量規劃。SaaS 消費者應考慮使用受保護的DNS(通常是基于SaaS的服務)控制DNS流量?，F代網絡架構可能會利用出站互聯網訪問的分流，從而導致本地分支機構互聯網流量激增。SaaS消費者必須考慮在客戶直接使用SaaS服務的情況下應用上述控制。安全訪問服務邊緣(SASE)模型可以通過充當SaaS消費者和提供商之間的策略執行點促進這種控制狀態。10.供應商關系10.供應商關系10.

112、1 供應商關系中的信息安全10.1 供應商關系中的信息安全SaaS 產品幾乎總是建立在第三方服務之上，包括由供應商直接管理和維護的服務以及第四方IaaS、PaaS 和SaaS 產品。與傳統的客戶管理軟件部署不同，SaaS消費者通常很難理解相關產品的完整依賴項集。因此，對于那些運營SaaS產品的人來說，構建其業務運營所依賴的技術的綜合模型至關重要。與傳統的客戶管理軟件部署一樣，可以為SaaS產品(也稱為 SaaSBOMs)開發軟件物料清單(SBOM)提供這樣的模型?，F有的標準CycloneDX可以促進包含SaaS組件的SBOM的創建。對這些表示的評估可以讓組織識別其技術供應鏈中的已知漏洞，并允許

113、更快速地修復。除了開發和維護組成給定SaaS產品的組件的實時情況外，組織還應該為使用這些組件制定內部風險管理策略。同樣，組織應與CSP協商合同條款，以確保產品的安全性。最后，外部認證制度可以幫助風險管理分析和決策，但使用SaaS服務的組織不應僅僅依賴它們。10.1.1 供應商關系的信息安全政策10.1.1 供應商關系的信息安全政策所有依賴外部方來保障其業務運營的企業（幾乎是現代經濟中的每一個公司）都應該有第三方風險管理政策。除了與組織有直接關系的第三方之外，這些外部方本身也將與第四方建立關系和依賴關系網絡，因此需要制定第三方風險管理政策。2022 云安全聯盟大中華區版權所有55除了組織所依賴的

114、其他技術外，此策略還應針對SaaS產品。至少，這樣的策略應明確以下內容：與第三方的每種關系（及其所有固有的第四方風險）在組織內的單一責任角色或職位。要求提供關于依賴第三方產品或服務的業務運營的關鍵性評估，最好是定量評估。評估事件影響第三方的可能性以及此類事件影響組織業務運營的方法，考慮到上面確定的關鍵性。這可以包括但不限于使用以下內容：外部審計和安全審查（有關詳細信息，請參閱認證保證部分）供應商安全評分/評級工具直接的技術盡職調查，包括由客戶組織進行的審計、滲透測試或對供應商的產品或基礎設施使用自動掃描工具基于上述確定的風險閾值，如果第三方超出此范圍，將觸發第三方（合同規定）、組織本身（通過一

115、些補償控制）或兩者采取補救措施的要求。組織內有權接受上述風險的單一責任角色或職位，以及用于記錄和證明接受此類風險的透明流程10.1.2 解決供應商協議中的安全問題10.1.2 解決供應商協議中的安全問題與供應商的協議應要求采取各種措施確保其SaaS產品的安全可靠運行。SaaS提供商可以代表不同規模和復雜程度的組織，他們的產品可能對組織具有不同程度的重要性。因此，可能有必要為各個供應商量身定制協議。此類合同可以包括：服務級別協議(SLA)，不僅針對產品的可用性（也稱為“正常運行時間”），還針對數據的機密性和完整性。例如，為了達到激勵目的，組織可能會要求供應商同意為每條被惡意行為者暴露或破壞的特定

116、類型的記錄支付預定費用。要求組織進行外部審查（如審計、滲透測試等）并提供審查結果。要求基于對風險的客觀評價，在給定的時間內解決供應商產品中的漏洞或提供緩解措施。如果供應商發現組織可以對其應用采取補償控制以降低漏洞的嚴重性或被利用的可能性，則應要求供應商在特定時間段內通知組織。要求供應商與組織合作調查和補救已影響或可能影響組織數據機密性、完整性或可用性的事件。要求供應商告知數據中心位置和拒絕不合規位置的權利。2022 云安全聯盟大中華區版權所有56與供應商談判的組織應謹慎考慮自己的風險管理能力，避免在合同中添加不切實際的條款。例如，要求供應商將其網絡、系統或軟件中發現的任何漏洞通知組織的要求可能

117、會導致一連串的告警，而這些告警對于組織基本上是無用的。10.1.2.1 外部認證10.1.2.1 外部認證外部認證是指受信任的外部組織證明供應商滿足特定要求的過程。此類認證可以在對CSP進行風險評估時提供幫助，并有助于澄清提供商對其控制措施的聲明以及提供商的實際安全狀況。話雖如此，審查外部證明應該是對全面廣泛的第三方風險管理計劃的補充，而不是替代。并非所有的認證和審計報告都是相同的，相同的報告類型覆蓋的范圍也不相同。ISO/IEC27001等認證表明CSP已按照規定的一組控制措施建立了信息安全管理基線。然而，SOC2鑒證是基于審計師對提供商遵守控制措施能力的評估。而且，與 ISO/IEC 27

118、001不同的是，SOC2 報告本身并不是“認證”?；谡趯彶榈恼J證標準（由提供商選擇），審計師會對提供商是否滿足這些標準的要求發表四種意見之一。審計師報告還將記錄供應商聲稱已實施的控制措施的任何異常情況。許多供應商會聲稱他們“符合 SOC2標準”，這不是審計會給出的結果。如果您正在查看SOC2報告，請務必檢查：考慮了哪些 TSP 標準（安全性、機密性、可用性、處理完整性和隱私）。報告類型是什么SOC2 類型 1 說明服務組織的基于TSC的系統和控制設計。該報告描述了當前的系統和控制措施，對圍繞這些控制措施的文件進行了審查。所有管理、技術和邏輯控制的設計考慮都在特定時間點進行驗證。SOC2類型

119、 2 說明服務組織的系統已經設計并應用了相關控制，以及這些控制是否有效。SOC2 類型 2審計通過收集并分析至少六個月的證據來進行，以查看系統和現有控制是否按照服務組織管理層的描述運行。通常 SOC2 類型 2 報告需要在簽署 MNDA（雙方保密協議）的情況下共享。SOC3-這是與 SOC2類型 2 報告類似的可公開共享的報告。請務必閱讀獨立審計師的評論部分。審計師會說明哪些領域不合規。這可以讓您了解SaaS提供商是否按照他們在政策和程序上的規定進行了落實。無論您查看CSP的哪些報告，密切關注認證/審計的范圍和業務實體或證明。范圍應涵蓋正在考 2022 云安全聯盟大中華區版權所有57慮或使用的

120、SaaS服務，業務實體應為將與之簽訂合同的實體。例如，一些供應商可能會提供其服務運行所依賴的IaaS供應商而不是要審計的內部控制的SOC2報告。這雖然有助于分析第四方風險，但此類報告并不能替代提供商本身的審計。同樣，有必要查看報告以確定是否涵蓋組織將依賴的整個產品，而不僅僅是包含應用程序所使用的數據中心/IaaS云資源。以下是SaaS客戶在評估CSP的安全性時可以使用的部分鑒證報告、認證和證明清單：綜合美國注冊會計師協會(AICPA)-SOC2國際標準化組織(ISO)/國際電工委員會(IEC)-27001HITRUST-通用安全框架(CSF)政府資助美國-FedRAMP新加坡-SS584歐盟

121、通用數據保護條件（GDPR）專注于云安全云安全聯盟-STARISO/IEC-27017專注于金融交易BSI Kitemark 安全數字交易支付卡行業-DSS注重隱私ISO/IEC-27018 2022 云安全聯盟大中華區版權所有5811.事件管理11.事件管理11.1 云安全事件管理11.1 云安全事件管理許多組織都堅持云優先戰略。盡管這通常是一個更受業務驅動的決策，但這些組織必須意識到，必須審查、調整和采用相應的基礎信息安全流程和程序。這其中的關鍵文件之一是安全或網絡事件響應(IR)計劃。作為健全的安全治理的一部分，應審查現有的 IR 流程和程序，并且應該納入企業利用的所有云服務和部署模型。

122、有關云事件響應和各個階段的更多詳細信息，強烈建議查閱 CSA的云事件響應框架。11.2 SaaS事件響應責任和程序11.2 SaaS事件響應責任和程序將數字信息資產轉移到云端并不能完全轉移責任或問責制（盡管可以通過明確的托管合同協議約定例外情況）。最后，資產的所有者全權負責對其云資產（及資產上的數據）的審慎管理，以應對暴露的風險。在三種云服務模型中，SaaS模型與其他模型（即PaaS和IaaS）相比，提供了最全面完整的功能。如CSA的安全指南 v4 第20頁所述-對于 SaaS，云提供商負責幾乎所有層的安全。云服務客戶(CSC)只能管理對應用程序（包括客戶端設備）的身份和訪問、應用程序的信息清

123、除，以及r提供商支持的某些數據加密設置（如自帶密鑰）。CSC無法控制虛擬化、網絡和邊界安全?；ヂ摼W安全中心的共享責任模型如下圖所示，供參考：責任責任本地On-PremIaaSPaaSSaaSFaaS數據分類和責任數據分類和責任客戶端和端點保護客戶端和端點保護身份和訪問管理身份和訪問管理應用級訪問控制應用級訪問控制網絡訪問控制網絡訪問控制主機基礎設施主機基礎設施物理安全物理安全云客戶的責任云提供商的責任共享責任 2022 云安全聯盟大中華區版權所有59在這種模式中，一些技術責任會被轉移，因此，云客戶有必要明確地與云服務提供商簽訂符合企業安全要求和標準基線的合同協議。CSC在采購階段可以參考利用C

124、SA共識評估調查問卷。如前所述，CSC 無論何種關系，仍然具有保護企業信息和資產的責任?？刂茩嗫梢赞D移，但責任不能轉移。必須更新客戶的事件響應計劃，以納入這些技術限制，并維護關鍵CSP聯系人清單。安全和非安全事件的服務級別協議必須通過合同協議達成。11.3 階段 1:準備11.3 階段 1:準備如參考的CSA云事件響應框架所述，事件管理的準備程度與組織對（網絡）安全事件的反應方式直接相關。在SaaS服務方面,必須對企業（經批準的）SaaS環境有一個清楚的了解.在采購過程應審查每個SaaS服務，并包括可靠的第三方風險分析，以符合公司風險容忍度、監管和行業合規要求。任何未受CSC直接（技術）控制的

125、已識別風險必須進行評估，如有必要，應通過合同約束來降低風險.CSC必須了解該服務在供應鏈風險和業務目標連續性方面的重要性（機密性、完整性和可用性的評估）除此之外，對于任何采購的SaaS服務，必須記錄關鍵利益相關者（業務、技術（IT/IT安全）的聯系人列表，并添加到集中的企業資產數據庫中，并告知事件響應者（或CSIRT的任何其他成員）。根據偏好，必須編寫針對SaaS場景的劇本，匹配適用于此服務模型的威脅/濫用場景。如果SaaS提供商違反了條款，則可以準備溝通方案，以通知公司（內部/外部）利益相關者。即使影響尚未明確或完全形成，也可以發布聲明，主動通知客戶/合作伙伴。每個SaaS服務應具有集中存儲

126、的參數或標簽（即CMDB），這將有助于決定應執行何種類型的溝通（即租戶是否管理個人客戶數據？）。11.4 階段 2:檢測和分析11.4 階段 2:檢測和分析因為客戶（CSC）只負責保護數據和訪問數據,此類SaaS環境中的大多數事件將由CSP檢測。CSC應通過利用身份提供商的身份驗證信息和SaaS服務訪問日志密切監控未授權訪問。CSC完全負責檢測數據外泄或偵察活動（即利用蜜罐）。因此，CSC必須始終致力于將任何SaaS服務與企業身份平臺集成，包括多因素身份驗證。其次，CSP發出的告警應與標準CSC事件響應流程相結合。最好通過自動接收告警和分配適當的優先級實現自動化，取決于SaaS服務的業務關鍵性

127、。如果CSP支持，則應將日志發送到CSC SIEM或IDS解決方案。2022 云安全聯盟大中華區版權所有60此外，利用已建立的SaaS CSP干系人合同援引協議中商定的網絡條款并獲得必要的支持以分析任何潛在的違反保密性、完整性或可用性的行為仍然至關重要。最后，CSP的參與對調查取證至關重要。11.5 階段 3:遏制、根除和恢復11.5 階段 3:遏制、根除和恢復與之前的所有階段一樣，CSC在響應行動中會受到限制。CSC只能做到：基于原始IP限制對其租戶的訪問（Allowlist，注意：并非所有SaaS提供商都支持此功能），撤消用戶或賬戶訪問（包括oAuth權限、密鑰輪換、多因素令牌等），以及輪

128、換靜態數據加密密鑰，等等。在恢復方面，請求CSP提供必要的支持以調用CSC數據備份和恢復計劃至關重要。這可以通過CSC利用第三方備份工具或通過請求CSP支持恢復租戶數據來實現。11.6 階段 4:總結改進11.6 階段 4:總結改進永遠不要錯過重要的改進機會；回顧所吸取經驗教訓，是健全IRP的關鍵最后一步。審查整個事件，以確定計劃中哪些要素可以改進。它可以是技術性的，也可是管理性的（如缺少與SaaS提供商的合同協議或缺少過程中的步驟）。關鍵問題可能是：是否及時發現事件，或者是否可以改進？（指標和日志）是否得到了供應商的必要支持？（合同/SLA）是否及時通知利益相關者（合規和溝通）事后的總結報告

129、應作為經驗教訓直接反饋到第1階段，并幫助CSC更好地管理（SaaS）事件。理想情況下，事件后分析應該僅僅回顧時間線和事件，更應該是一個學習過程。這方面的一個很好的例子是“根因分析（how we got here）”或“howie”流程，該流程最初由Jeli、Netflix、Slack和自適應容量實驗室（Adaptive Capacity labs）共同創建，雖然并不是嚴格以安全為中心?；蛘?，必須評估某些事后信息是否對同行或其他CSP有利?？梢韵蚶嫦嚓P者發布公告消息（參見2021 11月16日谷歌云宕機的示例）或利用CSA的云網絡事件共享中心（CloudCISC）。請參閱CSA云事件響應框架第

130、6章，指導信息共享和協調。2022 云安全聯盟大中華區版權所有6112.合規性12.合規性12.1遵守安全策略和標準12.1遵守安全策略和標準使用SaaS應用程序存儲和處理敏感數據必須按照所有相關的內部和外部適用合規標準和安全政策進行評估，評估方式和嚴格程度與公司所有其他系統相同。值得注意的是，這意味著應根據SaaS應用程序中包含的數據的類型和敏感性以及其他相關風險因素（如：風險記錄的數量、組織的依賴性和連續性）對SaaS應用程序進行分類和評估。合規的組織至少必須了解、記錄和監控：SaaS應用程序中的相關數據分類廣泛訪問SaaS應用程序的用戶類型哪些類型的用戶可以訪問SaaS應用程序中哪些類別

131、的數據SaaS應用程序中的訪問控制SaaS應用程序提供的任何審計功能與SaaS消費者相關的合規框架的任何適用合規性評估或認證特別重要的是要注意使用中的任何SaaS應用程序，這些應用程序可能既包含敏感和/或法規遵從性相關數據，又向外部用戶（非員工/非特權）開放訪問門戶或其他訪問入口。這些SaaS應用程序需要額外的審查和監控，因為錯誤配置可能會導致違反合規性要求。例如，向匿名的互聯網用戶或未經授權的用戶泄漏數據。雖然在許多組織中，SaaS應用程序的合規性評估和認證是根據需要進行的，通常是每季度或每年進行一次，但更好的做法是建立一個自動化、連續的監控系統，滿足安全和合規需求。一般來說，建立持續監控系

132、統的前期工作等于驗證單個合規周期的合規性所需的工作。連續監控系統既可以減少未來法規遵從性周期中的工作量，又可以減少系統可能不符合法規的時間，使其成為一項值得長期投資的項目。連續監控系統還促進了近實時的法規遵從性保證，而不是傳統的基于快照的評估活動。2022 云安全聯盟大中華區版權所有62部署此類連續監控解決方案通常需要：確定哪些SaaS應用程序與每個合規框架相關并在其范圍內。確定每個相關SaaS應用程序中哪些用戶組或群組在合規范圍內。將相關合規框架所需的特定于SaaS應用程序的設置和訪問控制映射到它們滿足的框架的元素。利用基于軟件的工具，促進SaaS應用程序的自動連續監控和報告活動。一旦這些工

133、作完成并有了持續監控解決方案，確保SaaS應用程序及其數據始終符合所有相關的內部標準和外部合規框架就變成了一個自動化的過程。這種連續監控可用于根據需要生成合規制品（如監控數據或結果），從而驗證SaaS應用程序是否符合要求，以及是否在給定的時間段內符合要求。請求定制保留時間最好在合同階段協商。如果購買SaaS解決方案是為了完成定制任務，那么何時可以從SaaS解決方案中永久刪除已處理的數據？如果SaaS解決方案有保留數據的法律義務，是否可以每隔一段時間將處理后的數據傳輸到離線存儲？通過請求自定義保留時間，可以顯著降低風險。12.2 遵守法律和合同要求12.2 遵守法律和合同要求12.2.1 適用法

134、律和合同要求的識別12.2.1 適用法律和合同要求的識別請參閱“供應商關系”一節中的“解決供應商協議中的安全問題”。12.2.2 知識產權12.2.2 知識產權云客戶必須審查并理解CSP使用其平臺的“條款和條件”。在某些情況下，服務提供商可能保留訪問客戶數據的權利。服務提供商還可以就某些任務與第三方供應商簽訂合同。這也會導致外部公司訪問云客戶數據的可能性。12.3 信息安全審查12.3 信息安全審查利用如上所述的持續監控工具和實踐，可以促進組織SaaS使用的信息安全審查活動。這些審查可以包括合規性評估、遵守組織和行業安全最佳實踐以及實施充分的安全保護等活動。信息安全審查還應包括評估組織SaaS

135、庫存的活動，以確定潛在的未經批準的SaaS使用情況。2022 云安全聯盟大中華區版權所有6313.CASB的功能和發展方向13.CASB的功能和發展方向云訪問安全代理CASB是隨著SaaS服務的發展而出現的一類服務，其功能聚焦影子IT（即：使用的服務未經公司IT部門批準，因此不受其保護）的可見性、監控和控制。包括以下主要功能：風險洞察：最初的用例是分析客戶出口設備日志以及與單個云服務相關的風險專有數據，以共享洞察，如：客戶環境中的云服務總數；高風險服務的占比（例如，遠程桌面控制、協作應用程序等類別）；上傳到高風險云服務的數據量；利用公司信用卡獲得的任何云訂閱，確定要購買的未經批準的應用程序。這

136、種可見性對于商業決策者來說是前所未有的。當然，下一個問題是關于控制現在可見的風險。API：此模式利用API實現額外的可見性和控制。例如，常見用例是列出下載最大數據量的頂級用戶，撤消任何外部方對公司某個數據子集的訪問等。在此模式下采取的所有策略操作都幾乎是實時的內聯：這種模式提供了最全面的覆蓋范圍，通過將應用程序流量引導到CASB云，解析流量的模式檢測上傳、下載等特定活動，應用細粒度策略，而不是傳統的允許或阻止策略。一個常見的例子是，對于中等風險的云應用程序，只允許下載不違反數據保護策略的數據。另一類服務是SaaS安全態勢管理（SSPM），它通過根據預先構建的符合行業標準（如CIS或NIST）的

137、策略配置文件持續監控SaaS應用程序，從而簡化和自動化SaaS應用程序的配置管理。錯誤配置會迅速觸發警告，用戶甚至可以在問題被利用之前自動修復。這幾類服務將繼續發展并可能融合到一個稱為安全服務邊緣（SSE）的新服務中。對這種演變的詳細分析超出了本文的范圍，但這是云和SaaS安全從業者應該持續關注的問題。2022 云安全聯盟大中華區版權所有6414.結論14.結論很明顯，SaaS的使用正在加速。隨著這種加速，企業運營和利用云產品的方式受到了廣泛的影響。也就是說，與傳統的云安全不同，SaaS的細微差別需要更多的關注和解決。這包括組織如何處理信息安全策略、訪問管理和訪問控制。由于數據不再由消費者控制

138、，因此圍繞加密和密鑰管理的考慮變得至關重要。網絡安全決策可能會對消費者訪問SaaS服務的方式以及從提供商到SaaS消費者的潛在連接產生影響，無論是在內部部署還是在云中。SaaS還代表著一個復雜的供應鏈，通常不僅包括SaaS供應商，還包括底層云或托管提供商。必須重新審視事件管理和業務連續性實踐，因為SaaS產品在業務運營中發揮的作用越來越大。雖然SaaS為企業提供了巨大的機會改變其運營方式、使用創新能力并減輕與創建和維護應用程序相關的許多運營負擔，但并非沒有安全隱患。未能解決這些問題可能會增加與SaaS相關的安全事件的潛在風險和后果。2022 云安全聯盟大中華區版權所有6515.參考文獻15.參

139、考文獻Cloud Security Alliance.(n.d.).Security,Trust,Assurance and Risk(STAR).CSA.Retrieved May 20,2022,from https:/cloudsecurityalliance.org/star/Cloud Security Alliance.(2017,July 26).Security Guidance for Critical Areas of Focus inCloudComputing v4.0.CSA.https:/cloudsecurityalliance.org/artifacts/sec

140、urity-guidance-v4/Cloud Security Alliance.(2021a,May 4).Cloud Incident Response Framework.CSA.https:/cloudsecurityalliance.org/artifacts/cloud-incident-response-framework/Cloud Security Alliance.(2021b,June 7).Cloud Controls Matrix and CAIQ v4.CSA.https:/cloudsecurityalliance.org/artifacts/cloud-con

141、trols-matrix-v4/Cloud Security Alliance.(2021c,June 7).STAR Level 1:Security Questionnaire(CAIQ v4).CSA.https:/cloudsecurityalliance.org/artifacts/star-level-1-security-questionnaire-caiq-v4/Cloud Security Alliance.(2021d,July 29).CloudThreat Modeling.CSA.https:/cloudsecurityalliance.org/artifacts/c

142、loud-threat-modeling/Cloud Security Alliance.(2021e,December 8).CCMv4.0 Auditing Guidelines.CSA.https:/cloudsecurityalliance.org/artifacts/ccm-v4-0-auditing-guidelinesInternational Standards Organization.(2020,December 16).ISO/IEC 27001:2013.ISO.Retrieved May20,2022,from https:/www.iso.org/standard/

143、54534.htmlInternational Standards Organization.(2021,April 15).ISO/IEC 27002:2013.ISO.https:/www.iso.org/standard/54533.htmlInternational Standards Organization.(2022a,February 4).ISO 31000:2018.ISO.https:/www.iso.org/standard/65694.htmlInternational Standards Organization.(2022b,May 4).ISO/IEC 2700

144、0:2018.ISO.https:/www.iso.org/standard/73906.html 2022 云安全聯盟大中華區版權所有6616.定義16.定義云訪問安全代理(CASBs)云訪問安全代理(CASBs)。內部部署或基于云的安全策略執行點，位于云服務消費者和云服務提供商之間，用于在訪問基于云的資源時合并和插入企業安全策略。CASB整合了多種類型的安全策略執行。比如身份驗證、單點登錄、授權、憑據映射、設備分析、加密、令牌化、日志記錄、告警、惡意軟件檢測/預防等1。軟件即服務(SaaS)軟件即服務(SaaS)。提供給消費者的能力是使用提供商在云基礎設施上運行的應用程序?？梢酝ㄟ^瘦客戶端

145、界面（如web瀏覽器）或程序界面從各種客戶端設備訪問應用程序（比如基于web的電子郵件服務）。消費者不管理或控制底層云基礎設施，包括網絡、服務器、操作系統、存儲，甚至是單個應用程序功能，但需要管理特定于用戶的應用程序設置，雖然這些設置功能可能是很有限的2。軟件物料清單軟件物料清單。一種正式記錄，包含構建軟件中使用的各種組件的詳細信息和供應鏈關系。軟件開發人員和供應商通常通過組裝現有的開源和商業軟件組件來創建產品。SBOM列舉產品中的這些組件3。SaaS安全態勢管理(SSPM)SaaS安全態勢管理(SSPM)。提供對基于云的SaaS應用程序（如Slack、Salesforce和Microsoft

146、 365）的自動連續監控，最小化風險配置，防止配置漂移，并幫助安全和IT團隊確保合規。安全服務邊緣(SSE)安全服務邊緣(SSE)。保護對web、云服務和私有應用程序的訪問。這些功能包括訪問控制、威脅保護、數據安全、安全監控，以及通過基于網絡和基于API的集成執行的可接受使用控制。SSE主要以云服務的形式提供，也可能包括內部部署或基于代理的組件。1https:/ 2022 云安全聯盟大中華區版權所有6717.縮略詞17.縮略詞AICPAAICPA-美國注冊會計師協會APIAPI-應用程序接口CASBCASB-云訪問安全代理CIACIA-保密性、完整性、可用性CCMCCM-云控制矩陣CSA CC

147、MCSA CCM-云安全聯盟云控制矩陣CSA STARCSA STAR-云安全聯盟安全、信任、保證和風險CSCCSC-云服務客戶CSPCSP-云服務提供商DLPDLP-數據防泄露FedRAMPFedRAMP-聯邦風險和授權管理計劃HIPAAHIPAA-健康保險攜帶和責任法案HITRUSTHITRUST-健康信息信托聯盟IaaSIaaS-基礎設施即服務IECIEC-國際電工委員會ISMSISMS-信息安全管理體系ISOISO-國際標準化組織NISTNIST-美國國家標準與技術研究院MTDMTD-最大容許宕機時間 2022 云安全聯盟大中華區版權所有68OTPOTP-一次性口令PaaSPaaS-平臺即服務PCIPCI-支付卡行業PIIPII-個人可識別信息RFIRFI-信息請求RTORTO-恢復時間目標RPORPO-恢復時間點目標SaaSSaaS-軟件即服務SASESASE-安全訪問服務邊界SBOMSBOM-軟件物料SIEMSIEM-安全信息與事件管理SLASLA-服務級別協議SOC1SOC1-服務組織控制1SOC2SOC2-服務組織控制2SSESSE-安全服務邊界SSPMSSPM-SaaS安全態勢管理TLSTLS-傳輸層安全協議VMVM-虛擬機ZTNAZTNA-零信任網絡架構