SaaS 的興起與挑戰

隨著 SaaS（Software-as-a-Service）的廣泛採用，企業應用交付方式產生根本性轉變。傳統的第三方風險管理（TPRM）多半聚焦於供應商的組織安全層面，忽略了 SaaS 應用本身可供客戶操作的安全能力差異，導致安全缺口。不同 SaaS 平台在可配置性、可見性、整合性上缺乏一致性，使得使用者難以落實一致的安全控管，造成資源浪費、採購延誤與風險暴露。

針對此一挑戰，Cloud Security Alliance（CSA）聯合 MongoDB、GuidePoint Security 等業界成員成立 SaaS Working Group，推出 SaaS Security Capability Framework (SSCF)。其目的在於提供一套可配置、可操作、面向客戶的安全能力標準，協助：

1. TPRM 團隊：簡化供應商評估，降低審核負擔。(Third-Party Risk Management, TPRM)
2. SaaS 供應商：統一回覆框架，避免重複填寫不同客製問卷。
3. SaaS 安全工程團隊：獲得基準檢查清單，加速落實安全能力。

SSCF 的核心是 共享安全責任模型（SSRM），強調 SaaS 提供者與客戶在安全責任上的分工，並針對可由客戶直接操作或設定的控制項建立規範。

SSCF的範疇與目標

範疇 (Scope)

1. 聚焦 客戶可見、可操作 的安全控制，例如：

• 日誌與審計功能
• 存取監控與使用者管理
• 安全設定的配置

2. 排除已由現有標準涵蓋或不屬於客戶可管控的項目，例如：

• SaaS 供應商自行處理的資料靜態加密
• 後端基礎設施監控
• 合同規範的資料使用與隱私條款
• 個別產品特定的 GenAI 控制

目標 (Objectives)

1. 建立 SaaS 應用應具備的標準化安全能力。
2. 提供 控制規格（必須）與 實作指引（建議），兼顧一致性與彈性。
3. 協助 SaaS 廠商、客戶及 TPRM 團隊共同提升 SaaS 生態安全成熟度。

評估與架構

1. 評估的必要性

隨著 SaaS 在組織中的普及，單靠傳統的合規認證（如 SOC 2、ISO 27001）已不足以保證特定 SaaS 平台的安全能力能滿足客戶需求。為了確保 SaaS 應用真正具備「可操作的安全控制」，必須建立一致、可量化的評估準則。SSCF 的角色，正是提供一個技術層級的安全控制清單，讓供應商與客戶能以相同基準進行檢視。

2.  控制規格（Control Specifications）

控制規格是 SSCF 的核心，它定義了「必須（Must）」實作的要求。控制項界定了強制性的實施要求：

• 屬於最低安全基準，不可忽略。
• 用於確保 SaaS 應用的安全功能具有一致性。
• 評估時採用 二元判斷：已實作 / 未實作 / 不適用。

實作要求範例：

• IAM-SaaS-12：SaaS 平台必須支援多因子驗證（MFA），並可由管理員強制啟用。
• LOG-SaaS-01：SaaS 平台必須提供登入事件、組態變更等安全事件的日誌。

這些規格是硬性要求，若供應商無法滿足，通常意味著該平台不符合企業安全採購標準。

3. 實作指引（Implementation Guidelines）

與控制規格相對應，實作指引則是「建議（Should）」層級的最佳實務，為客戶與供應商提供落地方向。建議措施有以下的特點：

• 提供具體的操作方法，但保持彈性，避免過度規範。
• 參考業界最佳實務、既有框架與實際案例。
• 允許 SaaS 廠商根據自身技術架構與客戶需求進行調整。

控制項範例：

• IAM-SaaS-12 建議避免使用 SMS 這類易受攔截的 MFA 方法，而應採用 FIDO2、硬體金鑰等抗釣魚機制。
• LOG-SaaS-03 建議支援 API 與 webhook 雙模式的日誌傳送，以因應不同 SIEM 與監控架構。
• 控制規格確保「最低安全底線」，實作指引則引導「最佳安全實踐」。

4. 可擴展性與適用性

SSCF 的一大特色是其 可擴展性，可同時應用於不同規模的組織：

• 小型 SaaS 新創：提供最低可接受的安全功能，協助快速進入企業市場。
• 大型 SaaS 供應商：能以 SSCF 與 SOC 2、ISO 27001 等框架對齊，減少重複投資與問卷應答。
• 跨國企業：用 SSCF 來檢視所有 SaaS 平台，確保安全能力一致，降低整合與稽核複雜度。

為了保持適用性，SSCF 不會對某些特定場景（如 AI 應用、資料駐留地要求）做過度規範，而是聚焦於通用性控制。

5. 與其他框架的對照

SSCF 與既有框架不是競爭，而是互補：

• ISO 27001：強調管理制度與流程，SSCF 則聚焦在 SaaS 應用的技術控制。
• SOC 2：提供高層原則（安全性、可用性等），但未細化 SaaS 功能；SSCF 將其轉化為可檢驗的功能。
• NIST CSF：提供治理與風險管理方向，SSCF 可作為「實作層級」的延伸。

例如：

• ISO 27001:2022 A.5.15 要求「存取控制」，而 SSCF IAM-SaaS-05 則明確規範「啟用 SSO 後必須能停用替代登入方式」。
• NIST CSF PR.PT-1 強調「記錄與事件追蹤」，而 SSCF LOG-SaaS-01 則列舉具體事件（登入、API 金鑰建立、OAuth Token 使用等）。

這種「原則對照實作」的方式，能大幅降低合規落地的模糊性。

6. 控制清單結構設計

SSCF 採用表格化結構，每個控制項包含：

• Control ID：唯一識別碼（如 IAM-SaaS-12）。
• Control Title：標題，簡述控制目標。
• Control Specification：規格，屬於「必須」層級。
• Implementation Guideline：實作建議，屬於「應該」層級。

控制項結構設計的能讓：

• 供應商清楚知道哪些功能必須支援。
• 客戶能快速比對不同 SaaS 平台的安全能力。
• 審計人員能建立客觀的檢核表，避免模糊描述。

六大安全控制領域 (Domains)

SSCF v1.0 定義六大核心領域，對應 CSA Cloud Controls Matrix (CCM) v4 的分類：

1. 變更控制與組態管理（CCC）

確保 SaaS 平台在配置與更新過程中的安全性。CCC控制領域的要求：

• 提供程式化 API 查詢所有安全設定。
• 提供清楚、版本化的安全設定文件。
• 通知客戶安全設定變更或新功能。
• 提供最佳實務的安全組態指引。

2. 資料安全與隱私生命週期管理（DSP）

聚焦於檔案上傳與資料操作的可管控性。DSP控制領域的要求：

• 支援檔案型態允許清單與上傳停用選項。
• 建議導入惡意檔案掃描功能。

3. 身分與存取管理（IAM）

IAM是最關鍵的 SaaS 控制領域，身分與存取管理（IAM）是 SaaS 安全的第一道防線，若身分與存取控制出現漏洞，無論平台功能多完善，資料與服務都可能遭入侵或濫用。CSA CCSF V1.0的36個控制項中，IAM佔了21個，比重超過58%，可見IAM對於資訊安全防護的重要性。IAM主要控制項：

• 使用者可見性與權限查詢。
• 網路存取限制（IP 白名單）。
• 單一登入（SSO）支援與強制。
• 非人類身分識別、存取權限、憑證管理、撤銷機制。
• 使用者憑證管理、密碼強度規範、多因子驗證（MFA）。
• 自動化佈署與停用（SCIM）。
• 安全稽核角色、匿名存取停用、外部未受管使用者限制。
• Session 管理（登出、逾時、權限即時生效）。
• 第三方應用整合允許清單。

4.  互通性與可攜性（IPY）

管控資料大規模匯出與跨應用整合的風險，IPY控制領域的要求：

• 匯出功能僅限管理員，且預設停用一般使用者匯出。
• 整合需顯示來源資訊（如 email domain），確保可驗證性。

5. 日誌與監控（LOG）

提供完整可見性與可追溯性，，IPY控制領域的主要要求：

• 記錄登入、組態變更、API 金鑰操作、使用者模擬、資料匯出等事件。
• 日誌需包含時間戳、使用者/身分 ID、IP、來源與行為。
• 支援程式化日誌提取（API/webhook）。
• 最少保留 7 天（建議 30 天以上）。
• 日誌須於 24 小時內提供，避免延遲。
• 提供日誌文件、格式說明與不可竄改機制。

6. 安全事件管理、電子蒐證與雲端鑑識（SEF）

強化供應商與客戶在事件處理上的協作。SEF控制領域的要求：

• SaaS 平台需支援設定 安全聯絡人，以便事件通報。
• 建議若客戶未設定，平台應定期提醒。

 

共享安全責任模型（SSRM）

1. 供應商責任：保護 SaaS 應用核心與基礎設施，提供安全控制項。
2. 客戶責任：妥善設定、管理與使用供應商提供的安全能力。
3. 核心精神：避免責任落空，確保每一項安全措施皆有明確責任人。

目標對象與應用價值

1. 客戶端：安全專業人員、合規與風險管理團隊、決策主管。可用於評估供應商安全能力，維持一致的安全態勢。
2. 供應商端：特別是新創 SaaS，能藉由 SSCF 了解企業客戶需求，降低合規與審核成本。
3. 整體效益：

• 簡化採購與評估流程。
• 提升供應商與客戶之間的互信。
• 提供跨平台一致的安全基準。

結語與展望

SSCF 的推出標誌著 SaaS 安全進入 標準化與可操作性的新階段。它不僅補足了傳統 TPRM 與合規框架的不足，還將「高層次原則」轉換為「可直接實施的控制項」，兼顧了企業需求與新創廠商的資源限制。未來發展方向包括：

1. 建立專門的 評估方法論，支援自動化檢測與量化安全成熟度。
2. 持續與其他標準（如 SOC 2、ISO 27001、AICM）對齊，避免重複與衝突。
3. 隨著 GenAI、跨域 SaaS 整合 的普及，未來版本可能擴展涵蓋 AI 特殊風險與資料模型控管。
4. SSCF 最終目標是促進 全球 SaaS 生態的信任、效率與安全一致性，為企業提供清晰的安全基準，並推動產業在 安全與創新間達成平衡。

參考資料：SaaS Security Capabiluty Framework Working Group, SaaS Security Capabiluty Framework (SSCF), Cloud Security Alliance,2025/09/23