作者 | 陳峻

審校 | 重樓

SaaS（軟件即服務）應用在過去幾年中得到了迅速發展。截至2023年，全球已有超過30,000家SaaS初創公司。SaaS應用程序已成為無數行業在線業務的重要組成部分和首要選擇。憑借著簡化的流程，便捷的交付和可擴展性，越來越多的應用數據和業務邏輯已從本地被遷移到了SaaS云端環境中。

然而，SaaS應用的增長與普及也自然成為了無數網絡威脅與攻擊的誘人目標。面對各種安全挑戰，SaaS應用供應商和使用方需要通過全方位的安全措施與測試來積極分析與應對。

SaaS面對的主要風險

由于SaaS應用通常被托管在服務提供商的云服務器上，并讓用戶設備通過互聯網進行訪問，因此這種交付模式具有更低的成本和更易維護的優點。不過，攻擊者一旦發現SaaS應用上存在安全漏洞，就會想方設法通過獲取應用服務的訪問權限，如探囊取物般批量獲取使用方和客戶的數據信息。

目前，此類風險大致包括如下方面：

多租戶架構缺陷

在多租戶SaaS架構中，來自不同客戶的數據駐留在同一臺服務器上。一旦租戶之間的邏輯隔離不到位，那么某個租戶就可能無意、甚至刻意訪問到另一個租戶的數據，進而出現隱私信息的泄露，機密性的缺失。

任意訪問的開放性

由于任何人都可以從任何位置訪問SaaS應用，因此攻擊者不再受限。他們可以輕松地使用網絡釣魚詐騙，來獲取用戶憑據，或通過直接破解弱密碼，來實現未經授權的訪問。

與其他應用的集成

SaaS平臺通常使用API來與其他應用集成。如果這些API在設計上具有安全缺陷，那么攻擊者便可以將其作為網關，滲透到SaaS應用以外的多個系統，并竊取敏感數據。

故障導致數據丟失

雖然SaaS的云服務保障了應用的可用性，但是云服務器上的數據安全性可能因網絡問題、設備故障、甚至是自然災難而丟失或損壞。對此，安全團隊在檢查SaaS業務時，應注意數據備份策略的可靠性，以避免因為數據丟失而造成服務的完整性欠缺。

直接遭遇攻擊

根據開放式Web應用安全項目（OWASP）列出的典型十大Web應用和API風險，我們可以知道SaaS應用上一旦存在邏輯漏洞和技術問題，就會被黑客通過互聯網，發起直接攻擊和利用，也就可能產生服務中斷、數據泄露、以及隱私侵犯等不利影響。

責任共擔

由于多個應用共享同一套云服務系統與后臺邏輯，因此服務提供方的配置錯誤、服務中斷等運營故障，就可能會被SaaS系統的共享結構所放大，進而波及到使用方的業務，甚至將網絡釣魚、惡意軟件、以及勒索攻擊，傳播至使用方的業務數據上，使其被動承擔相應的責任。

欠合規與監管

縱然SaaS應用的使用方竭力遵循合規與監管的要求，但是一旦疏忽了對其使用到的SaaS供應商的合規性查驗，則會面臨連帶的監管風險，進而導致巨額的罰款、或讓公司聲譽受損。對此，安全團隊應定期審查SaaS供應商對行業標準和法律法規的遵守情況。

測試的概念與好處

鑒于SaaS應用為用戶簡化了復雜的服務處理與提供機制，而其自身通常會保留使用方和最終用戶的大量敏感商業信息與個人數據，因此SaaS安全測試可以通過對SaaS業務的所有組成部分采取深入掃描、利用與評估，以發現并修復應用在界面、網絡、通信、API、第三方集成、基礎代碼、用戶輸入、以及角色權限等方面的安全漏洞，進而降低SaaS應用的運營風險，改進其安全態勢。

可見，SaaS安全測試不但有助于保障企業的云端系統、應用與數據安全，而且能夠滿足各種嚴格的合規性要求。

測試關注的組件

對于SaaS應用的安全測試而言，安全團隊通常需要關注和檢查如下三個方面的基本組件：

連接的安全性

客戶端設備與SaaS應用的連接是一個值得關注的重要風險點。鑒于SaaS應用的特點，服務提供商需要為使用方實施必要的信道保護、身份驗證、權限管理、以及行為監控等連接上的準入與保障。而本著“從不信任，始終驗證”的零信任原則，應用使用方的安全團隊有必要通過了解，來為后續的安全測試做好規劃。

應用服務的安全性

SaaS應用雖然簡化了使用方的自我構建，對于后端復雜的調用邏輯，使用方往往通過API、以及配套的管理控制臺來實現調用。不過，在開展應用安全測試之前，使用方的安全人員有必要通過與SaaS服務供應商的交互，獲悉其平臺應用本身的基本業務類型，了解其技術架構可能存在的挑戰，API的權限管控，管理控制臺的設置與操作邏輯。

集成交互的安全性

使用方往往需要將由SaaS平臺提供的服務與數據，通過API集成等方式，為自己的前端應用提供擴展的功能、自動化的工作流、以及與其他服務的交互。鑒于此類集成往往是一次性完成的，因此使用方的安全團隊應當根據職責分離（SoD）和最小權限（PoLP）原則，審查前端應用與SaaS平臺集成及交互的必要性與可控性。

測試的階段

為了避免出現“拆盲盒”的不確定性，使用方的安全團隊可以參考如下步驟，分階段開展SaaS安全測試：

收集信息

安全團隊在考慮對SaaS應用開展安全測試之前，需要對待測的應用的架構、網絡、業務邏輯、數據流轉、以及角色權限有所了解。這是制定有效的測試策略的基礎。鑒于安全團隊可能并非在應用項目開始時就參與其中，因此我們可以通過如下簡單的問卷列表，來獲取“第一手資料”：

• 該應用能夠提供哪些基本功能？
• 哪些團隊會在哪些場景下使用到該應用？
• 該應用對于前端業務的重要程度？
• 該應用中將存儲哪些業務數據類型，它們的敏感度如何？
• 最終用戶會使用受管理的設備、還是個人終端訪問該應用？
• 用戶會使用受管理的私密網絡、還是互聯網連接訪問該應用？
• 訪問該應用的方式是瀏覽器、還是由使用方提供的應用接口？
• 平臺供應商是否能給出應用的架構、通信、以及配置等信息？特別是如下安全控制信息：

  Web應用防火墻（WAF）等云安全組件

  可用的外部端口

  負載均衡和DDoS保護

  基于身份認證管理（IAM）的單點登錄（SSO）集成、或多因素身份驗證（MFA）的訪問控制

  靜態和傳輸中的數據加密

  服務器上的端點檢測和響應（EDR）和反病毒（AV）方案

  API密鑰的管理與限流

  數據與代碼的備份和服務的高可用性（HA）

  日志記錄和監控選項

制定計劃

安全測試團隊根據了解到待測應用的信息與復雜程度，與各個利益方討論潛在的限制、預估的成本，最終創建一個全面的安全測試計劃，其中包括：明確的范圍、標準、方法、深度、以及測試所需的系統配置、工具、及腳本。

雙方交流

安全測試團隊通過與被測應用供應商交流，確定將要執行測試的人員以及聯系方式，給將要使用的測試工具開放端口，并將其IP地址放入白名單，按需開放跳板主機，以及開通測試工具的安裝許可。

自動掃描

該階段，安全團隊通過專業的掃描工具，采用自動化的方式，仔細尋找被測應用的顯著漏洞。此類工具往往具有一定的侵入性。也就是說，它們可以通過模擬潛在的攻擊者，來爬取應用中的每個請求，進而快速地發現潛在的安全弱點和漏洞。

利用測試

針對自動化掃描到的漏洞，安全測試團隊需要綜合運用PoC（漏洞驗證程序）和EXP（漏洞利用程序）里的各種工具、Selenium腳本、及策略，通過手動測試的方式，按照計劃所制定的標準與范圍，先后對應用開展黑盒、白盒、以及灰盒（按需）等類型的利用和測試。參照OWASP Top 10，典型的測試要點包括：

• 注入滲透
• 服務器配置審查
• 模糊輸入
• 數據篡改
• 文件上傳
• 跨站腳本（XSS）

通過模擬攻擊的真實場景，我們可以獲悉被測應用的抗攻擊能力、以及攻擊得逞后，可能泄露的數據、篡改的系統、以及中斷的服務。值得一提的是，安全測試人員除了使用手動測試技術，也可以利用自動化工具模擬人類的交互，以社會工程的方式非法獲取應用的訪問授權。

評估報告

在完成了利用測試之后，安全測試團隊應根據記錄到的漏洞，測算潛在系統的損失、參考CVSS評分、以及核對如下維度實施漏洞分類，影響分析，優先級評定，以及按需進行風險計算。

• IAM – 基于角色的訪問控制（RBAC）、SSO、MFA
• 數據安全 – 數據加密、數據分級、數據泄露保護（DLP）
• 可見性 – 日志記錄（SIEM）、監控、警報
• 配置 – 安全設置、訪問控制列表（ACL）、IP白名單、接入的第三方應用
• 網絡 – WAF、入侵檢測、DDoS保護
• 合規–認證（ISO 27001、SOC 2 Type II、PCI DSS等）、隱私（PII、HIPAA、GDPR、CCPA等）

此外，通過結果保存與按需截屏的方式，安全測試團隊最終出具高準確度的報告，并向利益相關方給出修復建議。

整改重測

針對被確認的漏洞，應用使用團隊將協同安全團隊著手整改。而對于實難整改的部分，則可以按需引入云訪問安全代理（CASB）和云安全態勢管理（CSPM）等元安全組件以輔助加固。完成后，安全測試團隊將進入重新測試的階段，以確認漏洞是否被修復，且無新的漏洞產生，進而達到提高SaaS應用程序的整體安全態勢。

定期安全測試

我們常說：“安全態勢只是一時，并非一世”。這個概念在SaaS應用安全測試領域亦然。為此，我們需要通過定期開展安全測試（有時也稱為道德黑客攻擊），來驗證應用的安全預防措施的持續有效。

與此同時，我們也需要定期從開源情報（OSINT）處，收集并獲悉有關被測SaaS應用的其他公開報道、共享信息、客戶與合作伙伴反饋等，以根據各種突發的事件，及時開展安全測評工作。

總體而言，我們對于SaaS應用安全就是要本著主動發現、及時管控、按需評測的態度，保障SaaS應用在整個生命周期的安全態勢。

作者介紹

陳峻（Julian Chen），51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗。