作者 | 陳峻

審校 | 重樓

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

然而，SaaS應(yīng)用的增長與普及也自然成為了無數(shù)網(wǎng)絡(luò)威脅與攻擊的誘人目標(biāo)。面對各種安全挑戰(zhàn)，SaaS應(yīng)用供應(yīng)商和使用方需要通過全方位的安全措施與測試來積極分析與應(yīng)對。

SaaS面對的主要風(fēng)險

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

目前，此類風(fēng)險大致包括如下方面：

多租戶架構(gòu)缺陷

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

任意訪問的開放性

由于任何人都可以從任何位置訪問SaaS應(yīng)用，因此攻擊者不再受限。他們可以輕松地使用網(wǎng)絡(luò)釣魚詐騙，來獲取用戶憑據(jù)，或通過直接破解弱密碼，來實現(xiàn)未經(jīng)授權(quán)的訪問。

與其他應(yīng)用的集成

SaaS平臺通常使用API來與其他應(yīng)用集成。如果這些API在設(shè)計上具有安全缺陷，那么攻擊者便可以將其作為網(wǎng)關(guān)，滲透到SaaS應(yīng)用以外的多個系統(tǒng)，并竊取敏感數(shù)據(jù)。

故障導(dǎo)致數(shù)據(jù)丟失

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

直接遭遇攻擊

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

責(zé)任共擔(dān)

由于多個應(yīng)用共享同一套云服務(wù)系統(tǒng)與后臺邏輯，因此服務(wù)提供方的配置錯誤、服務(wù)中斷等運營故障，就可能會被SaaS系統(tǒng)的共享結(jié)構(gòu)所放大，進而波及到使用方的業(yè)務(wù)，甚至將網(wǎng)絡(luò)釣魚、惡意軟件、以及勒索攻擊，傳播至使用方的業(yè)務(wù)數(shù)據(jù)上，使其被動承擔(dān)相應(yīng)的責(zé)任。

欠合規(guī)與監(jiān)管

縱然SaaS應(yīng)用的使用方竭力遵循合規(guī)與監(jiān)管的要求，但是一旦疏忽了對其使用到的SaaS供應(yīng)商的合規(guī)性查驗，則會面臨連帶的監(jiān)管風(fēng)險，進而導(dǎo)致巨額的罰款、或讓公司聲譽受損。對此，安全團隊?wèi)?yīng)定期審查SaaS供應(yīng)商對行業(yè)標(biāo)準(zhǔn)和法律法規(guī)的遵守情況。

測試的概念與好處

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

可見，SaaS安全測試不但有助于保障企業(yè)的云端系統(tǒng)、應(yīng)用與數(shù)據(jù)安全，而且能夠滿足各種嚴(yán)格的合規(guī)性要求。

測試關(guān)注的組件

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

連接的安全性

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

應(yīng)用服務(wù)的安全性

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

集成交互的安全性

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

測試的階段

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

收集信息

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

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

  Web應(yīng)用防火墻（WAF）等云安全組件

  可用的外部端口

  負(fù)載均衡和DDoS保護

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

  靜態(tài)和傳輸中的數(shù)據(jù)加密

  服務(wù)器上的端點檢測和響應(yīng)（EDR）和反病毒（AV）方案

  API密鑰的管理與限流

  數(shù)據(jù)與代碼的備份和服務(wù)的高可用性（HA）

  日志記錄和監(jiān)控選項

制定計劃

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

雙方交流

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

自動掃描

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

利用測試

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

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

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

評估報告

在完成了利用測試之后，安全測試團隊?wèi)?yīng)根據(jù)記錄到的漏洞，測算潛在系統(tǒng)的損失、參考CVSS評分、以及核對如下維度實施漏洞分類，影響分析，優(yōu)先級評定，以及按需進行風(fēng)險計算。

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

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

整改重測

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

定期安全測試

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

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

總體而言，我們對于SaaS應(yīng)用安全就是要本著主動發(fā)現(xiàn)、及時管控、按需評測的態(tài)度，保障SaaS應(yīng)用在整個生命周期的安全態(tài)勢。

作者介紹

陳峻（Julian Chen），51CTO社區(qū)編輯，具有十多年的IT項目實施經(jīng)驗，善于對內(nèi)外部資源與風(fēng)險實施管控，專注傳播網(wǎng)絡(luò)與信息安全知識與經(jīng)驗。