共用責任模型 - 模式
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 安全性 | ✅ 結構設計假設實體資料中心的安全性、監視和環境保護由 Salesforce (或 AWS for Hyperforce) 處理 |
| 平台 | 安全性 | ✅ 網路安全性設計利用平台提供的 DDoS 緩解和入侵偵測系統,而無須重複投資 |
| 平台 | 安全性 | ✅ 所有傳輸中 (TLS 1.2+) 和靜態 (AES-256) 的流量加密皆由平台基礎結構提供 |
| 平台 | 安全性 | ✅ 平台強化、漏洞管理和修補程式部署是 Salesforce 的責任;結構設計師會針對排程維護期間進行計畫 |
| 平台 | 安全性 | ✅ 可確保資料分隔是平台提供的保固的多租戶安全性與租戶隔離結構 |
| 平台 | 規範 | ✅ 平台合規性認證 (SOC 1/2/3,ISO 27001/27017/27018,FedRAMP for Government Cloud offerings,HIPAA、PCI DSS、GDPR) 可在 Trust.salesforce.com 和 compliance.salesforce.com 取得 |
| 平台 | 安全性 | ✅ 平台加密服務和備份基礎結構是平台管理的功能,結構設計師可利用這些功能而不負有實作責任 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 安全性 | ⚡️ 結構設計包括自訂實體安全性控制項、網路周邊防禦項,或由平台提供的作業系統層級強化重複功能 |
| 平台 | 安全性 | ⚡️ 安全性檢閱無須諮詢 Trust.salesforce.com 現有控制項的文件,即可解決靜態平台加密或網路安全性問題 |
| 平台 | 規範 | ⚡️ 合規性評估會重新稽核平台基礎結構安全性控制,而非利用現有的 SOC 2/ISO 認證 |
| 平台 | 安全性 | ⚡️ 架構負責修補平台基礎結構或管理多租戶隔離 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 身分 | ✅ 由結構設計師設計及設定身分與存取管理 (角色、設定檔、權限集、MFA、SSO、最低權限) |
| 平台 | 身分 | ✅ 使用者週期管理和存取權重新認證流程會透過記錄的每季檢閱來實作 |
| 平台 | 資料 | ✅ 資料管理 (包括分類、遮罩、物件/欄位/記錄級安全性、CRUD 權限和共用規則) 是結構設計師的責任 |
| 平台 | 整合 | ✅ 整合安全性 (OAuth 2.0、JWT 驗證、已命名認證、安全端點、外部系統驗證) 是由結構設計師設計和維護 |
| 平台 | 安全性 | ✅ 監視與回應功能 (事件監視、稽核追蹤、SIEM 整合、事件回應程序) 由結構設計師實作 |
| 平台 | 開發 | ✅ 應用程式安全性 (包括安全自訂程式碼 (Apex、Lightning)、輸入驗證、防止插入,以及安全開發作法是架構人員和開發人員的責任 |
| 平台 | 規範 | ✅ 解決方案透過符合法規需求的隱私權/同意管理、資料保留原則和合規性組態來維持合規性狀態 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 身分 | ⚡️ 系統會將身分與存取管理視為「平台安全性」,而不會設計角色、設定檔、權限集或 MFA 需求 |
| 平台 | 資料 | ⚡️ 資料管理假設為平台提供;未設定資料分類、共用規則或欄位級安全性 |
| 平台 | 整合 | ⚡️ 整合安全性依賴網路層級控制,無須實作 OAuth、認證管理或端點驗證 |
| 平台 | 安全性 | ⚡️ 監視與事件回應會視為 Salesforce 責任處理;沒有「事件監視」、SIEM 整合或回應程序存在 |
| 平台 | 開發 | ⚡️ 未驗證自訂程式碼安全性;插入漏洞、缺少 CRUD/FLS 強制執行,以及不安全模式會累積 |
| 平台 | 規範 | ⚡️ 從未實作合規性組態;解決方案違反法規要求,儘管平台經過認證 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 規範 | ✅ 合規性文件中將平台認證 (SOC 2 類型 II、ISO 27001、FedRAMP for Government Cloud 產品、HIPAA、PCI DSS、GDPR) 參照為涵蓋基礎結構責任 |
| 平台 | 規範 | ✅ 稽核準備利用 Trust.salesforce.com 和 compliance.salesforce.com 文件來控制平台基礎結構 |
| 平台 | 規範 | ✅ 合規性文件清楚描述平台提供的認證與結構設計師實作的自訂解決方案控制項 |
| 平台 | 結構 | ✅ 自訂物件、Apex 程式碼、整合和組態的設計目的為維持平台提供的合規性狀態 |
| 平台 | 規範 | ✅ 結構文件明確地對應自訂解決方案如何滿足法規需求,同時利用平台認證 |
| 平台 | 規範 | ✅ 區域認證與合規性需求會在組織佈建期間推動 Hyperforce 區域選取 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 規範 | ⚡️ 平台認證會假設涵蓋所有合規義務;不會實作自訂解決方案控制 |
| 平台 | 規範 | ⚡️ 稽核準備嘗試重新稽核平台基礎結構控制,而非參照現有認證 |
| 平台 | 結構 | ⚡️ 自訂程式碼、組態和整合違反規範要求,儘管平台擁有適當的認證 |
| 平台 | 規範 | ⚡️ 規範文件未明確區分平台認證與結構設計師實作的控制項 |
| 平台 | 規範 | ⚡️ 結構缺少有關自訂解決方案如何在利用平台認證時維持合規性狀態的文件對應 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 安全性 | ✅ 事件回應程序文件協同合作:Salesforce 提供平台偵測和回應;結構設計師提供解決方案層級偵測和回應 |
| 平台 | 安全性 | ✅ 系統會清楚記錄漏洞管理責任:Salesforce 修補程式平台;結構設計師修補程式自訂程式碼與已安裝的封裝 |
| 平台 | 安全性 | ✅ 安全性監視結合平台產生的事件 (事件監視) 與結構設計師設定的分析、警示和回應工作流程 |
| 平台 | 結構 | ✅ Trust 支柱中的每個設計原則、主題區段和檢查清單項目都會視為「共用責任模型」內的結構設計師責任 |
| 平台 | 安全性 | ✅ 設計決策會明確參照「共用責任模型」邊界,區分平台提供的控制項和結構設計師設定的控制項 |
| 平台 | 結構 | ✅ 結構決策記錄會記錄安全性控制、規範需求和事件回應的責任邊界 |
| 平台 | 安全性 | ✅ 安全性檢閱會驗證結構設計師的責任 (組態、存取控制、自訂程式碼) 是否在平台提供的基礎上適當地實作 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 安全性 | ⚡️ 事件回應程序會假設 Salesforce 處理所有層面;沒有解決方案層級偵測、回應或復原功能存在 |
| 平台 | 安全性 | ⚡️ 漏洞管理不會解決自訂程式碼;只會考量平台修補程式 |
| 平台 | 安全性 | ⚡️ 安全性監視完全依賴平台原生工具,沒有結構設計師設定的分析或回應工作流程 |
| 平台 | 結構 | ⚡️ 設計決策不會參照「共用責任模型」,因為誰會保護哪些內容,有混淆 |
| 平台 | 結構 | ⚡️ 結構決策記錄會省略責任界限;安全性假設是隱含的,而非明確的 |
| 平台 | 安全性 | ⚡️ 安全性評論假設平台認證會去除結構設計師的安全性責任 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 醫療保健 | HIPAA | ✅ 已針對包含受保護健康資訊 (PHI) 的所有欄位啟用 Shield Platform Encryption |
| 醫療保健 | HIPAA | ✅「欄位稽核追蹤」設定為符合 HIPAA 針對 PHI 存取追蹤的記錄保存需求 (根據管理法規確認目前期間) |
| 醫療保健 | HIPAA | ✅「事件監視」設定為偵測未經授權的 PHI 存取模式,且警示路由至安全性小組 |
| 醫療保健 | HIPAA | ✅ 透過結構設計師組態實作 HIPAA 安全性規則所需的技術保護措施 (存取控制、稽核記錄、傳輸安全性) |
| 金融 | SOX/PCI | ✅ 透過權限集設計實作工作的區隔,讓單一使用者無法建立及批准財務交易 |
| 財務 | PCI DSS | ✅ 盡可能將完整的主要帳戶號碼 (PAN) 保留在 Salesforce 之外,並透過付款處理器進行標記化以減少範圍;若必須儲存 PAN,則會使用 PCI DSS 控制項下的加密自訂欄位 |
| 隱私權 | GDPR/CCPA | ✅ 使用細微的各用途同意追蹤與撤銷工作流程實作同意管理 |
| 隱私權 | GDPR/CCPA | ✅ 資料主題權利工作流程 (存取、修正、刪除、可攜性) 會在回應視窗內完成部署的規範規範集 |
| 隱私權 | GDPR/CCPA | ✅ 資料保留自動化會在同意到期或保留期間結束時清除資料 |
| 政府 | FedRAMP | ✅ Salesforce Government Cloud 用於需要 FedRAMP 規範的監管政府工作量 |
| 政府 | FedRAMP | ✅ NIST 800-53 控制項會對應至 Salesforce 組態,並記錄每個適用的控制項實作 |
| 政府 | FedRAMP | ✅ 透過「事件監視」將持續監視路由至政府 SIEM 基礎結構以進行即時威脅偵測 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 醫療保健 | HIPAA | ⚡️ PHI 會儲存在沒有 Shield Platform Encryption 或 Field Audit Trail 的標準加密欄位中 |
| 醫療保健 | HIPAA | ⚡️「事件監視」未設定為偵測未經授權的 PHI 存取;違規不會偵測到 |
| 金融 | SOX/PCI | ⚡️ 單一使用者可以同時建立和批准財務交易;不會強制執行職務分隔 |
| 財務 | PCI DSS | ⚡️ 完整的主要帳戶號碼 (PAN) 會儲存在不加密的標準 Salesforce 欄位中,而非使用付款處理器權杖化或 PCI DSS 相容的加密儲存空間 |
| 隱私權 | GDPR/CCPA | ⚡️ 未實作同意管理;資料會在沒有細微同意或撤銷功能的情況下處理 |
| 隱私權 | GDPR/CCPA | ⚡️ 資料主題權利要求會透過法律小組手動處理,而非自動化大小達法規回應時段 |
| 隱私權 | GDPR/CCPA | ⚡️ 資料保留是手動的;即使同意或保留期間已到期,資料仍會無限期累積 |
| 政府 | FedRAMP | ⚡️ 受監管的政府工作量會在商業 Salesforce 例項上執行,而非 Government Cloud 上執行 |
| 政府 | FedRAMP | ⚡️ NIST 800-53 控制項缺少 Salesforce 組態的記錄對應;存在合規性缺口 |
| 政府 | FedRAMP | ⚡️「事件監視」未路由至政府 SIEM;不符合繼續監視需求 |
模式
| 要尋找的位置 | 良好的外觀 |
|---|---|
| 平台 | 安全性 | ✅ 具有重要系統權限 (檢視所有資料、修改所有資料、管理使用者) 的使用者會被清點並追蹤為增強權限資產 |
| 平台 | Shield 事件監視 | ✅「事件監視」會針對安全性分析,從涉及登入、報告和資料匯出、權限變更和 API 呼叫的事件記錄中,來取用 |
| 平台 | Shield 事件監視 | ✅ 事件監視記錄會路由至外部 SIEM 平台,以與非 Salesforce 安全性事件相關聯 |
| 整合 | SIEM | ✅ SIEM 關聯性規則會偵測權限升級,例如批准變更視窗外的權限變更,以及高於基準的 API 量異常 |
| 整合 | SIEM | ✅ SIEM 顯示面板可看見安全性資產變更,例如特權使用者授與與資料匯出 |
| 平台 | 文件 | ✅ 安全性資產庫存會記錄資產種類 (使用者、資料、整合、封裝、組態)、擁有者和檢閱步調 |
反模式
| 要尋找的位置 | 看起來怎麼壞 |
|---|---|
| 平台 | 安全性 | ⚡️ 安全性資產庫存會在建立後立即變為過時的試算表中手動維護 |
| 平台 | 安全性 | ⚡️ 系統會透過部落 Knowledge 追蹤安全性資產,但無法在事件期間存取已記錄且可查詢的庫存 |
| 平台 | 安全性 | ⚡️ 安全性稽核只會在年度合規性審查期間發生,且在稽核之間沒有持續監視 |
| 平台 | 安全性 | ⚡️ 系統會收集安全性資產庫存,但不會檢閱;靜止帳戶、孤立的整合和過度權限會永遠持續 |
| 平台 | 安全性 | ⚡️ 系統會追蹤正式整合使用者,但業務單位會建立略過安全審查與認證輪替原則的臨時連線應用程式 |
| 平台 | Shield 事件監視 | ⚡️「事件監視」已啟用,但事件未路由至 SIEM;安全性事件在 Salesforce 中保持隔離,沒有關聯性 |
| 平台 | 整合 | ⚡️ 陰影 IT 整合會略過庫存追蹤;未經授權的 API 活動會建立資料外洩風險 |