Trust

在 Salesforce,Trust 是我們的第一個值。這是平台上每個結構決策的基礎。針對結構設計師, Trust 可透過獨特的合作關係達成:Salesforce 提供安全且合規的平台,即基礎結構、中繼資料和工具,使其成為您專屬的平台,同時您設計依賴該基礎的安全解決方案。

此合作夥伴關係透過「共用責任模型」運作,這是明確分配安全性責任的架構:

• Salesforce 負責平台的安全性,包括基礎結構、修補程式和合規性認證。**
• 您 負責平台 上 的安全性,包括組態、存取控制、自訂程式碼和資料管理。

此分部是必要的,因為它定義結構責任。Salesforce 運作多租戶結構,其中有數千個組織共用基礎結構。平台在基礎結構層級提供強大的安全性保護。您的結構決策會決定您的特定解決方案是否能獲得利害關係人的信任。

「共用責任模型」可讓您負責設計安全解決方案,同時為您處理實體安全性、網路保護、平台修補程式和基礎結構加密。這可讓您專注於設計以該基礎為基礎的安全解決方案 (例如身分與存取管理、資料保護、整合安全性、安全開發作法、合規性和法規符合性,以及事件回應功能)。

設計複合技術債務期間忽略 Trust。法規變更時,缺少加密策略會變成昂貴的改造方式。當認證遭到入侵時,未受管理的整合會變成漏洞。從一開始建立 Trust 的成本一直低於稍後重新調整。

Trust 跨越四個結構維度,共同運作:

• 安全性控制會保護系統與資料
• 身分管理管理存取權
• 隱私權作法會遵循使用者代理程式
• 合規架構滿足法規義務

針對全部四個維度進行設計的結構設計師可透過透明度、控制和彈性,建立獲得並維持 Trust 的解決方案。

在工作人員時代,Trust 會延伸至工作人員在其中作業的信任內容。信任內容表示工作人員可存取具有明確身分與權限界限的受管理、已驗證資料,讓 AI 系統能夠代表使用者思考並採取行動,同時維持安全性、稽核性與合規性。設計信任的內容是 Agent Enterprise 結構的基礎。

此支柱會建立每個 Salesforce 解決方案所依賴的平台安全性基準。「工作人員信任」支柱會以該基準為基礎,以處理獨立工作人員獨有的風險,包括提示插入、動作管理,以及工作人員可在思考時間內存取的資料。請務必先設計基準,然後使用「工作人員Trust」指導方針將工作人員特定的控制項目分層。

此支柱與其他架構的關注深度連結。

• 可靠性取決於可抵禦攻擊及從缺口復原的基礎結構。
• 卓越作業需要安全的部署管道和事件回應功能。
• 公平要求資料和演算法決策的透明、道德處理。

這些支柱共同構成一個統一且以解決方案為中心的方法,以便組織 Trust 最敏感的作業。

在「共用責任模型」中,Salesforce 和結構設計師必須履行其各自的責任,才能維持 Trust。讓我們進一步瞭解每個端必須確保的安全性。

Salesforce 負責保護平台及其全域基礎結構的安全,包括:

• 資料中心存取控制、監視和環境保護
• 針對 Hyperforce,基礎雲端提供者 (例如 AWS、Azure 或 Google Cloud,視例項而定) 會透過委派的責任處理實體資料中心安全性。Salesforce 基礎結構與子處理器文件會識別每個服務的提供者和子處理器。

• 網路層安全性控制,包括 DDoS 防護和威脅偵測
• 傳輸中 (TLS 1.2+) 和靜態 (通常為 AES-256) 的流量加密

• 透過 Salesforce 的漏洞回應與平台修補程式部署 (如需安全性顧問的詳細資訊,請造訪 security.salesforce.com)
• 作業系統與基礎結構安全性管理

• **憑證與憑證:**Salesforce 維護 SOC 1/2/3、ISO 27001/27017/27018、FedRAMP 授權 (範圍適用於 Government Cloud Plus 和 MuleSoft Government Cloud,而非商業多租戶平台) 和 PCI DSS 層級 1 驗證。
• **法規支援:**這適用於具有 Business Associate Agreements (BAA) 或 GDPR 合規計畫的符合 HIPAA 資格服務。
• 如需詳細資訊,請造訪 Trust.salesforce.com 和 compliance.salesforce.com。

• **租戶區隔結構:**共用中繼資料驅動的核心會依組織識別碼來分割每個組織的資料和中繼資料,因此一個組織無法存取另一個組織的記錄,即使兩者都在共用基礎結構上執行。核心會對每個查詢強制執行分隔,而非透過您必須維護的組態。
• **靜態和備份基礎結構的基礎結構級加密:**基本平台授權包含 Classic Encryption (AES-128 僅提供自訂文字欄位)。Shield Platform Encryption 需要個別的授權 (AES-256 允許您自帶金鑰,並提供標準和自訂欄位、檔案和附件)。

這些控制項可確保平台保持安全、可靠且符合。

您負責保護資料、組態和作業流程的安全。

• **身分與聯邦:**針對單一登入 (SSO) 和多因素驗證 (MFA),您必須驗證使用者的身分。
• **存取限制:**技術上,IP 範圍與登入時間會限制身分連線的方式與時間。
• **最低權限原則 (PoLP):**使用 PoLP 僅將存取權授與執行個別工作必要的角色、設定檔和權限集。
• 生命週期管理:練習使用者週期管理與存取重新認證指導方針。

• 使用資料分類、遮罩和物件/欄位/記錄級安全性
• 強制執行 CRUD 權限與共用規則
• 擁有、測試並部署已驗證的策略來還原您組織的資料,確保資料遺失或損毀復原保持在您的控制之內。

• 使用 API 驗證 (例如 OAuth 2.0 或 JWT) 和已命名認證。
• 啟用具有 PoLP 權限集的專屬整合使用者,讓每個整合的存取範圍皆可分開與人類使用者進行稽核。
• 保護端點和外部系統驗證。

• 使用「事件監視」、稽核追蹤,以及安全性資訊和事件管理 (SIEM) 整合。
• 遵循事件回應程序和安全性檢閱。

• 使用安全自訂程式碼 (例如 Apex 或 Lightning) 和輸入驗證。
• 在使用者模式中執行 Apex,以在程式碼中強制執行物件、欄位和共用權限。
• 遵循注射預防和安全開發作法。

• 維護解決方案合規性狀態。
• 遵循隱私權/同意管理與資料保留原則。

某些責任需要協同合作:

• 安全性事件回應:雙方皆可參與偵測和回應活動。
• 漏洞管理:Salesforce 會修補平台、結構設計師修補程式自訂程式碼。
• 安全性監視:將平台產生的安全性訊號與結構分析結合。
• 合規性認證:Salesforce 會認證平台 (例如,SOC、ISO 和 FedRAMP for Government Cloud);結構設計師會在經認證狀態內擁有其基礎的物件、程式碼、整合和組態,以提供稽核合規性的證據。
• 身分聯邦:Salesforce 信任結構設計師身分提供者發出的判斷式;結構設計師維持提供者和提供者與 Salesforce 之間的 Trust 關係的安全。
• 金鑰管理:使用自帶金鑰加密,Salesforce 會在結構設計師產生、輪替和撤銷保護資料的金鑰資料時,作業加密服務。

此文件中的每個設計原則、主題區段和檢查清單項目皆代表您身為結構設計師的責任。「共用責任模型」會為您在 Salesforce 平台上達成 Trust 所需的設計和設定建立框架。

邊界延伸至法規義務。Salesforce 會維護平台的認證和認證,並保護基礎結構免受缺口。結構設計師負責附加至資料和管轄權的義務 (例如:適用的法律、資料分類方式、管理資料的保留與同意規則,以及您在您控制之下偵測及報告資料缺口的方式)。與部署的規範法規相反,結構設計師必須根據部署的規範,決定這些義務背後的特定數字 (例如保留期間和通知期限),因為這些數字會因司法管轄區而有所不同,並隨著時間而變化。

使用這些原則來引導您在平台上的結構安全性決策。

• **將 Zero Trust 套用至所有層級。**請勿根據網路位置、使用者熟悉度或系統來源假設 Trust。使用資料、應用程式、整合和基礎結構層級的驗證、授權和加密,明確驗證每個存取要求。多租戶結構表示您與數千個組織共用基礎結構,因此您解決方案執行的網路並非您可以視為信任的周邊。根據每個要求本身的優點 (身分、授權和內容) 進行驗證,而不是依據其起始位置信任要求。
• **依預設授與最低權限。**授與每個使用者、整合和自動程序完成其目的所需的最低存取層級。從最嚴格的設定開始—私人組織範圍預設值 (OWD) 和最低權限—並根據已記錄的業務需求刻意展開。使用四層存取模式 (組織 → 物件 → 欄位 → 記錄),讓每個圖層進一步限制上述圖層。
• **深入實作防禦。**分層多個安全性控制項,讓一個控制項失敗不會影響整個系統。結合預防控制項 (例如 CRUD/FLS 強制執行與封鎖作業的「交易安全性」原則)、偵測控制項 (例如「事件監視」) 和回應控制項 (例如「交易安全性」逐步驗證與通知)。設計每個圖層,就如同相鄰圖層可能會失敗。請記住,即使共用規則過度允許,欄位級安全性仍可保護資料。
• **依設計整合安全性。**將威脅建模、安全性需求和控制驗證從初始概念到持續進化整合至每個結構階段。在建立開始之前,請先執行詐騙、篡改、拒絕、資訊揭露、拒絕服務和權限提升 (STRIDE) 威脅建模。安全性會決定技術選取與設計決策。
• **自動化內嵌的安全性。**將安全性控制項建立在自動化管道、組態範本和平台預設值中。CI/CD 中的 Salesforce Code Analyzer 會在部署前抓出漏洞。Configuration-as-code 會強制執行安全性基準。內嵌安全性可確保一致性,並讓安全性與解決方案複雜度相同。
• **為了隱私而設計.**整合初始結構階段中的隱私權原則。資料最小化 (僅收集必要資料)、用途限制 (依工作功能限制存取權)、同意管理 (強制執行細微、特定用途的同意),以及資料主體權利 (啟用在法規時程表內完成的存取、修正、刪除和可攜性工作流程)。
• **可追溯性的設計。**請先將每個後續動作設定為可歸因且可重建,然後再依賴偵測其中的異常。確保已在稽核追蹤、欄位歷程記錄和事件記錄中捕獲對資料、權限和組態的變更,並將這些記錄保存在防篡的儲存空間中。可追溯性是偵測、鑑識與責任的先決條件。請記住,您無法調查從未記錄的內容。
• **事件回應的設計。**透過「事件監視」進行偵測的設計,以及透過「交易安全性」原則進行即時介入。透過已記錄的程序和隔離邊界啟用快速回應。透過備份功能和鑑識保留來支援復原。透過桌面演練和缺口模擬測試回應。

結構設計師負責在 Salesforce 提供的平台上保護解決方案的安全。

與 Salesforce 互動的工作量越來越多地在核心平台外執行—整合服務、自訂應用程式和無周邊用戶端經常呼叫 Salesforce API,通常代表使用者。為了加速此模式,Salesforce 會將平台的功能公開為 API、工具和指令 (例如 Salesforce Headless 360)。無論誰操作這些應用程式,結構設計師都擁有他們與 Salesforce 會面的 Trust 邊界,以決定他們驗證的方式、他們攜帶的身分與權限、他們持有的機密,以及跨界的資料。

下列原則適用於任何容器化整合平台 (例如 MuleSoft CloudHub)。

當外部用戶端以已命名使用者身分進行驗證時,Salesforce 的平台安全性模型會自動套用—物件權限、欄位級安全性和共用規則會與瀏覽器中的相同方式強制執行。每位使用者驗證會將每個呼叫範圍縮小至該個人的權限,並保留稽核追蹤,這表示立即撤銷使用者的權杖會移除用戶端代表他們採取行動的能力。在為特定使用者完成工作的任何一處,將此項目優先於共用服務帳戶。

以防禦方式設計邊界,因為為許多使用者保留權杖的用戶端會集中 Trust 並成為攻擊者的高價值 Proxy:一個單一竊取的 OAuth 權杖可以跨用戶端提供的每個使用者存取資料。這並非假設。2025 年的 Salesloft Drift 事件看見攻擊者竊取 OAuth 權杖,並使用這些權杖在數百個組織之間存取 Salesforce 資料。

• **傳播使用者身分,不要將其集中。**使用每位使用者驗證或 OAuth 2.0 權杖交換,在服務跳轉之間攜帶使用者的身分 (請參閱工作人員身分與驗證),以便將入侵範圍縮小至一個使用者的內容,而非所有使用者的內容。
• **將 OAuth 用戶端認證與重新整理權杖視為主要目標。**將其儲存在受管理密碼存放區中、經常輪替,並維護設計以立即撤銷。監視訊號為 Proxy 攻擊者的異常模式 API 用量。
• **將兩側的範圍最小化。**將外部用戶端應用程式 (ECA) 的 OAuth 範圍和整合使用者的 Salesforce 權限限制為功能所需的最小值,讓入侵的用戶端無法對非相關資料進行樞紐分析。
• **透過外部用戶端應用程式管理邊界。**ECAs 會定義外部應用程式驗證的方式、允許的流程以及適用的範圍—針對其設計新整合 (請參閱驗證結構)。

當用戶端以「工作人員使用者」或「整合使用者」身分執行時,請特別小心:這些身分可能會在高階環境中作業 (通常是針對不遵循 Salesforce 存取控制項的外部系統),因此使用上述權限與監視規範是讓該權限保持繫結的原因。

當整合在容器化平台中執行時,容器層級隔離本身會視為安全性控制:每個應用程式都會在專屬容器中執行,而應用程式之間沒有共用的執行階段或記憶體。

此隔離提供:

• **租戶強制執行邊界:**入侵的應用程式無法從共用相同環境的鄰近應用程式存取資料或資源。每個容器都有隔離的檔案系統和處理空間。透過防火牆與 TLS 組態強制執行網路隔離,並明確限制輸出流量,而非依賴權限預設值。
• **深度防衛:**容器隔離會在應用程式層級控制之外新增一個安全層級。即使應用程式程式碼有漏洞,容器邊界仍會限制爆炸半徑。
• **規範區段:**受管理的工作量 (例如 PCI 和 HIPAA) 可在專屬容器中隔離,以防止與不相容的工作量一起混合。

設計多應用程式環境的結構設計師必須依賴容器隔離,才能強制分隔工作與安全性網域。處理持卡人資料的金融服務整合必須在與行銷整合不同的容器中執行,即使是在相同的環境中也是如此。

應加密容器之間的流量,並在法規架構需要雙方驗證時套用共同 TLS (mTLS):

運作方式:

• 設定 TLS 內容,在需要時為輸入連線啟用選用的共同 TLS (mTLS)。
• 將平台級 SSL 與用戶端憑證驗證搭配使用,以保護平台服務與複本之間的安全通訊。
• 設定 TLS 內容,在法規架構要求時啟用 mTLS。
• 透過平台的憑證存放區管理憑證,讓生命週期與撤銷保持集中。
• 強制執行網路隔離邊界,以防止容器之間發生未經授權的流量。

在平台層加密流量,為傳輸中的資料提供深度防禦。即使應用程式層 HTTPS 設定錯誤,容器流量仍會保持加密。

透過 VPN 連線至內部部署系統的容器必須結構化,才能保護傳輸中的資料:

• **隧道加密:**透過加密 VPN 管道,將容器與內部部署系統之間的所有流量路由。不論應用程式層 TLS 為何皆適用。深度防禦可確保敏感資料有雙重加密。
• **網路區隔強制執行:**VPN 隧道原則會限制容器可到達的內部部署網路。入侵的容器無法樞紐移至 VPN 允許的網路以外的未經授權內部系統。
• **合規性證明:**VPN 加密是保護雲端環境中傳輸中資料的接受機制之一。檢閱 HIPAA、PCI-DSS 或 SOX 控制項的稽核員預期會在傳輸中記錄混合式整合的加密。

結構設計師必須設計強制執行最低權限網路存取權的 VPN 原則。行銷整合容器不應路由至內部財務系統,即使兩者皆可透過 VPN 存取。

虛名網域 (例如整合 API 的自訂 URL) 需要結構設計師管理 TLS 憑證作為 Trust 安裝:

虛名網域 (例如整合 API 的自訂 URL) 需要結構設計師管理 TLS 憑證作為 Trust 安裝。

• **憑證週期自動化:**實作自動憑證續約與部署。到期憑證會中斷整合 Trust;用戶端會拒絕具有憑證驗證錯誤的連線。
• **憑證撤銷計畫:**針對安全性事件設計憑證輪換程序。已入侵的私人金鑰需要在所有區域之間快速重新核發和部署憑證。
• **加密套件組態:**較舊的 TLS 組態 (TLS 1.0/1.1 與弱加密) 失敗於合規性稽核。強制執行 TLS 1.2+ (最低需求),並將憑證和用戶端組態與組織安全性原則保持一致。
• **憑證透明度記錄:**現代 TLS 憑證由憑證授權機構 (CA) 提交至公用憑證透明度 (CT) 記錄。每個 CT 記錄都會傳回「已簽署憑證時間戳記」(SCT),即記錄的密碼證明,CA 會透過 X.509v3 擴充功能將其內嵌在憑證中。結構設計師應使用如 crt.sh 或自動警示等服務,監視 CT 記錄是否針對其網域核發未經授權的憑證。

憑證管理錯誤會直接影響 Trust 狀況:

• **已到期憑證:**導致顯示為中斷的驗證失敗。監視必須包含在到期前 30 天以上傳送警示,才能讓續約工作流程開始。
• **自我簽署憑證:**為外部用戶端中斷 Trust 鏈。生產整合需要由信任的憑證授權機構 (CA) 簽署的憑證。
• **萬用字元憑證展開:**意指過於寬的萬用字元憑證 (例如 *.company.com),其在遭到入侵時會建立大的爆炸半徑。每個整合網域偏好縮小範圍的憑證。

容器部署區域必須符合資料落地與合規性需求。

• **GDPR 資料落地:**GDPR 要求適當保護離開歐盟 (歐盟) 的個人資料,但不要求歐盟部署。在歐盟區域部署整合可讓容器計算和資料處理保持在法規範圍內,這是滿足此需求的最直接方式。在歐盟境外進行的轉移仍可依據適當性決策、標準契約條款 (SCC) 或繫結公司規則 (BCR) 進行。
• **資料本地化法則:**具有資料本地化需求的國家包括:俄羅斯 (聯邦法 152-FZ 和強制儲存) 和中國 (PIPL/CSL for CIIOs),這可能需要國內容器部署。 2023 年印度的 DPDP 法案 使用不強制執行一般國內儲存權要求的黑名單方法。除非政府通知特別限制,否則允許資料傳輸至任何國家。結構設計師必須瞭解特定管轄區的法規。
• **跨境資料傳輸機制:**當需要多區域部署,但資料必須跨境時,結構設計師必須實作 SCC、密件副本或其他法律轉移機制。
• **合規性認證對齊方式:**容器部署區域必須符合 Salesforce 合規性認證。FedRAMP 授權的工作量需要美國地區部署。針對 HITRUST 認證的整合,您必須確認部署區域在啟用的 HITRUST 憑證範圍內。

區域部署決策是結構設計師的責任,會直接影響法規合規性。財務小組可以要求僅限美國部署 SOX 控制的整合。醫療照護小組可能需要 HITRUST 認證的區域來處理個人健康資訊 (PHI)。

容器需要認證、API 金鑰和加密金鑰的存取權。結構設計師必須設計防止曝光的機密管理流程:

• **無硬式編碼密碼:**請勿在部署至容器的應用程式程式程式碼或組態檔案中內嵌認證。使用平台管理的機密存放區。
• **平台管理的機密插入:**從平台的受管理存放區在執行階段解析密碼 (而不是將其保留在檔案系統),並將保留認證的組態值標記為受保護,以便它們不會在記錄中或主控台上顯示。
• **密碼輪換:**設計整合以順暢地處理旋轉的密碼。OAuth 權杖重新整理模式、API 金鑰輪換工作流程和資料庫密碼變更不需要容器重新部署。
• **最低權限密碼存取權:**僅授與容器其功能所需機密的存取權。行銷整合不應存取財務系統認證,即使它們共用相同的環境也是如此。

公開密碼是常見的整合安全性事件。結構設計師必須設計機密處理流程,以便存取程式碼審查、記錄、錯誤訊息和監視顯示面板,而無須洩漏認證。

Salesforce 邊界的應用程式會產生符合規範記錄需求的稽核事件:

• **要求/回應記錄:**記錄 API 要求、回應和路由決策。合規小組會使用這些記錄進行存取稽核,以決定誰在何時存取了哪些資料。
• **錯誤與例外記錄:**將安全性事件 (例如驗證失敗、授權拒絕和無效憑證) 從容器的記錄中捕捉。SIEM 整合可啟用即時安全性監視。
• **記錄保留原則:**結構設計師必須設定符合法規需求的保留期間。這些最低值是由法規所設定的、因架構而異,且隨著時間而變化,因此必須從維護良好的合規性來源衍生,此來源會根據規範法規驗證每個數字,而非硬式編碼值。
• **記錄加密與存取控制:**稽核記錄可能包含敏感中繼資料。記錄必須在靜態加密,且只能對經過授權的安全性/合規人員進行存取控制。記錄不足會防止事件調查和合規性稽核失敗。結構設計師必須將記錄嚴重性 (例如效能影響和儲存成本) 與合規性和安全性調查需求平衡。

威脅建模必須是設計解決方案的一部分,而不是在解決方案之前或之後發生的個別步驟。一旦您具備候選設計的考量,您便需要模型化其潛在威脅,並在設計進展時重新造訪模型,因此安全性會塑造結構,而不是將其重新調整為線下。當 Salesforce 管理基礎結構安全性時 (例如網路保護、作業系統強化和漏洞管理),您必須識別組態、整合和自訂程式碼中的應用程式層風險。將 STRIDE 架構 (詐騙、篡改、拒絕、資訊揭露、拒絕服務、權限升級) 套用至下列 Salesforce 特定的威脅向量。識別資料跨越系統、網路或權限層級的 Trust 邊界。

將 STRIDE 架構套用至這些 Salesforce 特定的威脅建模考量事項:

• 多組織資料流程會建立額外的 Trust 邊界,在每次交集時都需要明確驗證和授權。
• 外部整合使用 API 和中介軟體,可能會導入略過平台安全性控制的攻擊向量。
• 針對插入、XSS 和強制執行存取控制,自訂 Apex 和 Lightning 元件需要安全的編碼分析。
• Experience Cloud 網站會將攻擊面向延伸至未經驗證或輕量驗證的使用者。
• 第三方和 ISV 程式碼 (例如受管理封裝、AgentExchange 清單、連線的應用程式、第三方連接器、用戶端 JavaScript 程式庫,以及您工作人員呼叫的外部 AI 服務) 是一種供應鏈向量,可在安裝時或執行階段跨越您的 Trust 邊界。

第三方和 ISV 代碼是您 Trust 邊界的一部分。

受管理封裝或 AgentExchange 清單會在貴組織內執行,且具有您授予的權限,因此在您安裝封裝時,其安全性狀態會變成您的安全性狀態。Salesforce 安全性檢閱會在每個列出的封裝到達 AppExchange 或 AgentExchange 之前進行檢查;您擁有該門之後的所有項目:

• 根據您自己的資料分類和風險狀況評估封裝
• 授與其文件化功能所需的最低權限數量
• 透過發行者的版本保持最新狀態
• 透過與您套用至您自己的程式碼相同的「事件監視」和稽核控制項來監視其活動。

在解決方案堆疊的每個層面上套用安全性控制項。請記住,單一層的妥協不能讓整個系統公開。

設計每個圖層,就如同上層與下層可能會失敗一樣。請記住,多個獨立控制會建立彈性。

Zero Trust 會根據網路位置或先前驗證狀態去除隱含 Trust。每個要求都必須獨立驗證和授權。

將零 Trust 套用至:

• 透過使用 MFA、工作階段原則和條件式存取權 (例如 IP、裝置、時間和行為) 的持續驗證來進行使用者存取。
• 透過每個呼叫上的 OAuth 權杖驗證、以憑證為基礎的共同 TLS 和 IP 允許清單來進行整合連線
• 透過明確驗證進行系統間通訊,這也適用於信任的內部系統
• 無論呼叫內容為何,都可透過 CRUD 與 FLS 強制執行每個查詢和作業的 資料存取權

「安全性資產庫存」是安全性設計輸入:您只能模型化威脅、套用最低權限,並監視您先前列出的攻擊面板,因此追蹤與安全性相關的資產屬於依據的設計決策。這與「作業傑出」涵蓋的作業組態管理不同 (例如,版本化組織設定和偵測組態漂移以確保作業穩定性)。換句話說,此處的關注範圍較窄:哪些資產帶來安全性風險,為何?

維護所有安全相關資產的最新庫存,包括儲存敏感資料的自訂物件、外部系統整合、公開 API、特權帳戶、生產生產存取授與,以及具有提升權限的已安裝封裝。

您的安全性資產庫存應包含:

• 包含「機密或受限制」資料的自訂物件與欄位
• 整合端點與驗證機制
• 具有提升權限的使用者 (例如「修改所有資料」、「檢視所有資料」和「管理使用者」)
• 僅 API 整合使用者及其權限範圍
• 外部用戶端應用程式 (ECA) 及其 OAuth 範圍,以及組織中仍存在的任何舊版連線應用程式
• 已安裝的 AgentExchange 封裝及其權限授與
• Experience Cloud 網站及其驗證和外部共用模型
• 含增強型共用模式的自訂 Apex 類別
• 特別注意舊版類別:在 API 66.0 版或更早版本編譯的程式碼會省略共用宣告預設為「不共用」(例如,系統模式,略過執行使用者的記錄存取權)。請記住,從 API 67.0 版 (Summer '26),省略的宣告會改為預設為「具有共用」,且資料庫作業會以使用者模式執行。然而,現有類別會保留舊行為,直到在 v67.0 (或更新版本) 重新編譯為止—因此從較早版本移轉至前的未宣告類別會保持靜音升級。

您有責任設計和設定強制執行最低權限的身分控制。

讓我們進一步瞭解如何使用 PoLP 正確設計和設定控制。

Salesforce 透過四個不同的層級強制執行存取控制:組織、物件、欄位和記錄。您必須設計使用全部四個圖層的解決方案。核心存取控制是以授與為基礎,這表示存取權是可補充的,且使用者必須在每個層級授與存取權才能到達記錄。核心平台中沒有廣義的「拒絕允許覆寫」規則,因此您無法使用目標拒絕來復原已授與之廣泛授與的存取權。

權限較高的層級不需要您限制,但會增加工作量:提早擴大組織範圍預設值或物件權限意味著依賴欄位級安全性和共用組態來解決從未授與的回復存取權。

限制規則與靜音權限是兩種減去存取權的內建例外狀況,但每個規則的範圍很窄—限制規則的記錄級篩選和權限集群組內授與的權限靜音—而不是一般化的拒絕層。

針對包含敏感資料的物件,將 OWD 設為「專用」。將 OWD 開啟為「公用唯讀」(更不用說「公用讀/寫」) 會廣泛公開記錄,並破壞您稍後在沒有潛在重大重新結構的情況下限制存取權的能力。成熟組織中最常見的 Trust 債務源自初始實作期間設定的權限 OWD。

記錄層遵循授與之後限制模型,通常描述為共用金字塔:OWD 會設定限制基準,並從中設定角色階層、共用規則和手動共用開放存取權。兩個控制項會反轉流程,以取回存取權而非授與存取權,這兩者都值得刻意設計。

• 限制規則會篩選使用者可在其已擁有存取權的記錄中看見的內容,因此具有廣泛物件存取權的使用者仍只能看見規則允許的子集。
• 靜音權限會減去權限集群組內的特定權限,因此您可以組合可重複使用群組的存取權,然後移除指定族群不應擁有的項目。
• 當僅以授與為基礎的圖層會迫使您過度佈建或將存取權分割到許多窄的權限集時,請使用這些規則。

針對透過使用者介面登入生產環境的所有使用者強制執行 MFA (多因素驗證),Salesforce 會強制執行此功能作為平台需求。此需求不延伸至僅 API 存取權:使用 JWT 承載者或用戶端認證流程的整合會例外,因此您需要改為使用憑證管理和 IP 限制來保護這些整合。將 MFA 要求延伸至特權營運。

針對 SSO (單一登入),偏好的是 SAML 2.0 或 OpenID Connect 通訊協定。設定工作階段原則以平衡安全性和可用性:

• 工作階段逾時:設定適用於使用者權限層級的工作階段逾時 (高權限帳戶的較短逾時可減少未出席工作階段的風險)。
• IP 限制:對管理設定檔與整合使用者強制執行限制。
• 登入時間:將服務帳戶限制為預期的作業時段。
• **裝置啟用:**依賴 Salesforce 的原生裝置啟用 (來自無法辨識裝置的登入身分驗證),並針對高權限帳戶新增 MFA 和 IP 限制。系統會透過外部身分提供者強制執行原生裝置 Trust 狀態。
• 工作階段 IP 鎖定:將工作階段鎖定為工作階段來源的 IP 位址,以便無法從其他網路位置重新執行竊取的工作階段識別碼。這會強化安全性,但會對行動使用者增加摩擦,並可能會中斷自動化整合—若鎖定無法運作,請在設定檔層級強制執行「在每個要求上強制登入 IP 範圍」作為補償控制。
• 高度保證工作階段:透過「工作階段安全性層級原則」和「存取原則」,針對敏感性作業 (例如存取報告或管理 IP 範圍) 要求高度保證工作階段安全性層級,讓例行登入本身無法達到高影響動作。在 Lightning Experience 中,不支援透過重新提示 MFA 將標準工作階段升級至「高度保證」,因此請瞭解標準工作階段使用者遭到封鎖,而非收到升級提示。
• 工作階段 Cookie 保護:需要 HttpOnly 屬性,讓指令檔無法讀取工作階段識別碼 Cookie,並將工作階段鎖定至其第一次使用的網域,以防止工作階段劫持。
• 整合使用者的僅 API 存取權:將整合和服務帳戶限制為具有「僅 API 使用者」權限的僅 API 驗證,讓他們無法透過使用者介面登入。針對新組建,請使用 Salesforce 整合使用者授權指派「最低存取權 - 僅 API 整合」設定檔;舊版 Salesforce 僅 API 系統整合設定檔不適用於自 Spring '24 起佈建的組織,因此請根據目前的設定檔而非已淘汰的設定檔來設計新整合。

針對 API 驗證,請選取適合整合模式的 OAuth 2.0 流程:

• **JWT 承載者流程:**將這類動作用於以整合使用者身分執行的伺服器對伺服器整合 (以憑證為基礎,偏好可供信任環境使用)。
• Web 伺服器流程 (授權代碼,包含 PKCE):針對需要使用者授權的 Web 應用程式,以及需要維護特定使用者內容的伺服器對伺服器整合 (將重新整理權杖儲存在伺服器端,以避免重複出現瀏覽器提示)。
• **讓授權代碼流程重新執行安全:**強制執行 PKCE,使攔截的授權代碼無法由要求授權代碼的用戶端以外的任何人兌換,並輪替重新整理權杖 (每次使用時核發新的重新整理權杖並使先前的重新整理權杖無效),讓竊取的重新整理權杖具有窄的有效期間。重複使用淘汰的權杖訊號入侵。
• **無周邊身分驗證代碼和認證流程 (含 PKCE):**針對必須在特定使用者環境中執行的真正無周邊無瀏覽器用戶端使用此功能—以重新導向為基礎的 Web 伺服器流程會假設這些用戶端沒有的瀏覽器。
• **裝置流程 (適用於無周邊裝置):**請注意,自 2025 年 8 月 28 日起,Salesforce 已永久封鎖預設 Salesforce CLI 連線應用程式的「OAuth 2.0 裝置流程」。請改用 Web 伺服器流程 (sf 組織登入網頁) 或 JWT 承載者流程 (sf 組織登入 jwt) 作為 CLI 和 CI/CD 工具。

請勿使用「使用者名稱密碼流程」。Salesforce 預設會針對在 Summer '23 或更新版本中建立的組織封鎖,並已針對此流程發佈淘汰計畫。仍依賴「使用者名稱密碼流程」的現有整合應立即移轉至「JWT 承載者流程」或「用戶端認證流程」,而非將移轉視為延後的技術負債。

這些流程是在代表您整合的應用程式註冊上設定的。自 Spring '26 起,Salesforce 將該註冊從「連線的應用程式」移至「外部用戶端應用程式」(ECA):建立新的「連線的應用程式」預設為停用,而 ECA 是設計新整合的建構。現有的「連線的應用程式」仍會保持安裝;不過,當組織移轉後,這些應用程式便不再處理驗證,因此在稽核整合如何驗證,而不是將「連線的應用程式」視為永久模型來考量移轉。

除了選擇驗證流程之外,還可建立應用程式可連線的不同管理:

• **每個整合一個註冊:**針對每個新整合註冊專屬的「外部用戶端應用程式」,並針對每個現有的整合註冊不同的「連線的應用程式」。專屬註冊僅涵蓋每個整合所需的 OAuth 範圍,而非在多個整合之間共用一個廣泛註冊,可讓每個整合的存取權保持獨立稽核且可撤銷。
• **明確預先授權存取權 (建議):**將「外部用戶端應用程式允許的使用者」原則設定為「管理員批准的使用者均獲得預先授權」,讓管理員透過設定檔和權限集授與存取權,而非讓使用者自我授權。管理員可直接在「設定」中進行設定,這是 Salesforce 建議的控制項,可決定誰可以連線。
• **API 存取控制 (嚴格且以允許清單為基礎):**針對更嚴格的控制,API 存取控制會將管理員批准的使用者限制為僅限已加入允許清單的連線應用程式。啟用此步驟需要向 Salesforce 客戶支援提出要求,因此在為其進行設計時,請規劃該步驟,而不是將其視為自助式設定。

請勿將認證內嵌在程式碼、組態檔案或版本控制中。使用已命名認證和外部認證以透過輪替功能集中管理驗證。

不同於傳統使用者驗證,工作人員需要不同的身分模型,且正確的模型取決於工作人員提供員工還是外部使用者。正確設計身分是工作人員安全性的基礎:它決定工作人員可以存取的資料以及工作人員可以接觸的動作。

讓我們進一步瞭解內部和外部工作人員。nts。

• **員工工作人員 (內部):**在登入使用者的環境中執行工作。這些工作會繼承使用者的授權、權限集、欄位級安全性和共用規則,因此不會佈建個別的工作人員身分,且現有安全性架構會管理工作人員可執行的動作。
• **客戶工作人員 (外部):**透過公用管道互動,並以專屬的工作人員使用者身分執行,專門整合使用者而非公用網站來賓使用者。以專屬整合使用者身分執行,可讓工作人員執行後端動作並存取資料 (未經驗證的來賓設定檔無法存取),同時仍受明確且最低權限權限的約束。當您建立客戶工作人員時,請佈建具有最低存取權的新「工作人員使用者」,並僅授與其動作所需的特定權限。

當工作人員的工作跨多個服務時,請在每個服務跳轉之間移入使用者的身分,而非回復為共用或來賓身分。Salesforce OAuth 2.0 權杖交換流程支援:

用戶端會呈現使用者的現有身分提供者權杖,Apex 權杖交換處理常式會將其對應至 Salesforce 使用者並核發 Salesforce 存取權杖,因此原始使用者的內容會遵循要求,而非摺疊至服務帳戶。透過「事件監視」監視工作人員活動,使用工作人員的使用者身分來偵測異常行為。

選擇正確的模型取決於起始連線的人員,以及工作必須在其內容中執行。

常見連線情況會對應至建議的方法,如下所示:

針對資料存取需求 (使用者需要存取其他人擁有的記錄) 設計角色階層,而非管理報告圖表。讓角色階層深度遵循真正的資料存取關係,而不是新增層級以不授與額外存取權,因為每個層級都會增加共用計算額外負擔,這在具有「私人 OWD」設定的組織和大量資料時會帶來較大的考量。

權限集和權限集群組透過提供彈性、可補充的存取權來減少設定檔擴充的需求。透過權限集和權限集群組 (而非設定檔) 授與功能存取權,讓存取權保持為可補充且可稽核。設定檔仍然是必要的:除了登入時間與 IP 限制之外,它們還控制版面配置指派、記錄類型預設值和應用程式可視性。將設定檔視為存取模型的永久部分,而非要去除的建構。

「交易安全性」原則不是基準的一部分,它們是補充功能,可補充核心授權模型:以上的身分、角色、設定檔、權限集和共用控制項已自行建立安全的授權狀態,且「交易安全性」會在頂端新增即時內容評估。設定原則來偵測和封鎖異常行為,包括超過正常模式的大量資料下載、來自非預期的地理位置的登入,以及變更視窗之外的權限變更。

安全性控制會帶來結構責任的可用性權衡。過於廣泛的 IP 限制可能會在網路變更期間鎖定合法使用者,過於積極調整的「交易安全性」原則可能會封鎖有效的業務活動,因此請將這些控制範圍縮小至真正的風險,在強制執行之前將其暫存在僅限監視模式中,並針對控制失敗時設計斷眼鏡路徑。

**您的責任:**設計角色階層、建立權限集、設定「交易安全性」原則。

傳統以角色為基礎的存取控制) 會根據使用者的角色授與權限。ABAC (以屬性為基礎的存取控制) 會根據資料、使用者和內容的屬性做出授權決策。

針對大多數的需求,核心共用模式會完全表達存取權。當存取權必須遵循每個記錄共用無法表達的資料分類時,可使用專屬 ABAC:Data 360 ABAC 透過標記和註釋提供此功能。

Data 360 ABAC 透過以下方式運作:

• 根據套用至資料物件的標記 (例如「個人可識別資訊」(PII)、財務、醫療照護和機密標記) 來定義存取規則的 以標記為基礎原則。
• 註解會套用至資料物件以支援以原則為基礎的授權決策。
• 新組織和現有組織的 預設「全部允許」原則,必須明確刪除才能啟用細微的管治原則。

其主要結構用途是強制執行資料分類—請參閱「資料保護和隱私權」下的「資料分類」,以瞭解分類層級如何推動 ABAC 強制執行。

此層級的細微度會產生營運成本。核心共用會回答「誰可以看見此記錄,以及為什麼?」從一小組可檢查的規則 (OWD、角色階層和共用規則) 取得,而 ABAC 會在評估時間從資料標記、使用者屬性和內容的組合中衍生其回答,因此在原則和標記累積時,有效的存取權會越來越難以解釋和稽核。

強制執行稽核能力作為設計需求:一律套用標記、將原則集保持小,並為其強制執行的分類保持具名,並保留重新建構使用者到達指定記錄原因的能力。將 ABAC 保留給每個記錄共用實際無法表達的分類驅動個案,而不是將其視為擁有權型模型的一般替代項目。

識別並保護具有高權限的帳戶,包括系統管理員、整合使用者和自動流程帳戶。這些帳戶是攻擊者的高價值目標。

將增強型控制套用至重要影響帳戶。

• 需要防網路釣魚的 MFA
• 將登入 IP 範圍限制為已知的管理位置
• 啟用登入警示和權限變更通知
• 針對高權限帳戶執行定期存取審查,並包含有文件的證明,其頻率由組織風險容忍度與合規性需求決定
• 維護緊急存取和使用後稽核的斷玻璃程序

針對整合與服務帳戶:

• 套用 OAuth 流程;切勿使用者名稱密碼流程
• 強制執行 IP 限制
• 實作認證輪替排程
• 透過「事件監視」監視 API 用量異常模式

**您的責任:**識別重要帳戶、套用增強型控制項、執行每季檢閱。

設計自動流程以提供使用者適當的初始存取權、隨著角色演變調整權限,以及在不再需要存取權時立即淘汰。

實作「跨網域身分管理系統」(SCIM),以從身分提供者自動佈建。SAML 或 OpenID Connect 及時佈建是第一次登入時建立使用者的替代方式,但不會取消佈建使用者。換句話說,SCIM 是生命週期的支柱,不是對其的選擇。

身分生命週期包括:

• 佈建:建立具有符合工作功能基準存取權的帳戶,其由 HR 系統事件觸發。
• 存取調整:在角色展開時授與其他權限,並在角色變更時撤銷權限。
• 定期重新認證:每季檢閱並驗證存取權。
• 處理:當就業結束或角色不再需要 Salesforce 存取權時,立即撤銷存取權。

當經理定期檢閱並驗證其小組的權限時,實作存取重新認證流程。檢閱頻率取決於風險與合規性需求。

**您的責任:**實作 SCIM、設計佈建工作流程、執行每季重新認證。

將資料分隔為多個組織有時只會視為成本或落地決策。在結構上,這是一種安全性權衡方式,而監管後果屬於您的存取設計。

隔離是主要優點。個別組織提供資料集之間最嚴格的邊界。沒有集體共用模式,也沒有跨租戶權限流失,但對於需要共用權限的管轄區而言,有明確的監管條列。相同的邊界區段會管理。您只需要在單一組織內維護一次的每個存取控制項 (例如,權限集設計、角色階層、重要影響帳戶強化、健康檢查基準、事件監視和 SIEM 關聯) 現在會乘以每個組織,這表示它必須在所有組織之間保持一致性。組織之間的漂移會建立自己的攻擊表面,因為在一個組織中縮小,在另一個組織中遺漏的權限會造成攻擊者可以尋找和利用的不一致。跨組織整合會新增先前不存在的已驗證 Trust 界限。每個跨組織整合都是您需要保護和監視的連線。

因此,在分割組織之前,請務必將隔離利益與管治乘數加權。為實際無法在單一組織內滿足硬本地化要求或客戶的合約隔離需求的個案保留多組織。當您採用時,您需要設計存取模型、監視和組態基準,以從一開始在每個組織中以相同的方式強制執行。

**您的責任:**將多組織決策視為安全性權衡,而不只是成本權衡。若需要多組織,請一致在每個組織中強制執行存取控制、監視和健康檢查基準,並將每個跨組織整合作為 Trust 邊界保護。

您必須負責分類資料、設定加密及設計隱私權控制。

讓我們進一步瞭解如何適當保護資料與隱私權。

若要正確分類您的資料,您必須瞭解資料。整體的結構工作是瞭解您的業務領域,並維護資料字典,該字典會將您所保留的資料、其意義和敏感資料存在的位置進行目錄。您只能分類或保護您先識別的資料。

建立資料分類方式,以推動適當的保護控制。分類標籤本身不會保護任何內容。這是您套用之控制項的輸入,因此您指派的每個分類都必須對應至具體的加密、存取、保留或監視決策。在資料建模期間所做的分類決策會直接影響加密需求、存取控制、保留原則和合規義務。

在 Salesforce 中,我們使用四層機制,提供可讓您適應組織法規需求和業務需求的架構。許多企業使用符合產業標準的類似模型 (例如 ISO 27001 和 NIST)。您的特定實作應反映您的合規義務 (例如 HIPAA、PCI DSS、GDPR 和產業法規) 和業務內容。

在欄位級套用分類。單一「帳戶」記錄可能包含「公用」欄位 (例如公司名稱)、「機密」欄位 (例如公司收入) 和「受限制」欄位 (例如社會安全號碼)。欄位級安全性必須反映這些差異。

分類會透過以屬性為基礎的存取控制來強制執行,其會讀取您指派的標記並套用存取規則。這是中繼資料驅動的圖層,可補充 OWD 與共用規則。

將 ABAC 與您的分類方式保持一致,可讓平台:

• 從分類本身限制標記為「受限制」或「機密」的資料存取權,而非從每個物件維護的共用規則。
• 視記錄的分類隨著時間變化而調整存取權。新標記為「**受管理」**的記錄會繼承更嚴格的存取權,而不會手動變更規則。
• 將資料屬性 (例如分類和敏感性) 與使用者屬性 (例如部門和清除) 和內容 (例如時間和位置) 結合在單一授權決策中。

設計 ABAC 原則以符合此方式,讓將欄位分類為「受限制」是推動其存取控制的動作,並使強制執行與分類保持固定,而非個別維護共用規則。

**您的責任:**定義分類方式、訓練資料建模人員、在設計期間分類欄位、設定控制,並將 ABAC 原則與分類層級保持一致,以便標記推動強制執行。

StartBegin 使用平台已為每個組織提供的資訊。靜態資料預設為加密。Hyperforce 會套用量級加密,以在 Salesforce 擁有及管理的單一金鑰下保護整個儲存空間。此基準一律為開啟且對您的解決方案具有透明度,但其會在量層級 (非每個欄位) 運作,因此在關鍵生命週期內選擇要加密和控制的項目取決於平台,而不是您。

當基準無法滿足合規性、合約或資料分類義務時,請使用 Shield Platform Encryption。具體而言,當您需要不提供大量加密的三個項目之一時:

• 控制金鑰生命週期,以便您自行產生、輪替和撤銷金鑰資料
• 靜態加密標準欄位、自訂欄位、檔案和附件的選擇性
• 能夠讓 Salesforce 無法存取資料。

受限制的資料與符合明確法規金鑰控制要求的資料 (例如 HIPAA、PCI DSS 和 GDPR) 是常見的觸發。基準已涵蓋其他一切的基礎結構層級保護。

Shield Platform Encryption 會在欄位級加密,並提供兩種可將安全性交換為可查詢性的方式。

機率加密是一個強大且預設的方式,但加密的欄位無法用於篩選條件、排序或彙總函數 (例如 MAX()、MIN() 和 COUNT_DISTINCT() 函數)。

決定性加密可在報告、清單檢視和 SOQL WHERE 子句 (區分大小寫或不區分大小寫) 中啟用完全相符的篩選功能,因為相同的純文字一律產生相同的加密文字。

我們建議依預設使用可能性結構描述進行加密,並為您必須篩選或排序的特定欄位保留決定性加密。在資料建模設計期間評估這些權衡,包括對公式欄位參照、報告彙總和 SOQL 作業的影響。

客戶控制金鑰有兩種不同的形式:

• 自帶金鑰 (BYOK) 可讓您使用自己的加密文件庫、企業金鑰管理系統或硬體安全模組,在 Salesforce 外部產生金鑰資料,並將其提供給平台。
• 僅限快取金鑰服務會將您的資料加密金鑰保存在您控制的金鑰服務中。Salesforce 會依需求提取,而非儲存。

兩種表單皆可讓您依照自己的排程輪換和終結金鑰資料。破壞金鑰資料會使其保護的資料無法復原,這是一種強大且有意的控制方式,而非例行程序。記錄金鑰輪換和撤銷程序也很重要。

所有整合都必須使用 TLS 1.2 或更高版本 (Salesforce 平台會強制執行此操作),但您必須針對處理「受限制」資料的整合 (使用您自己的組態) 實作以憑證為基礎的共同驗證。

**您的責任:**決定平台的量級基準足夠的位置,以及規範、合約或分類義務保證 Shield Platform Encryption 的位置,然後選取加密方式、選擇並操作客戶控制的金鑰策略,並針對敏感整合實作以憑證為基礎的驗證。

使用防止「受限制」資料進入 Sandbox 的策略,保護非生產環境中的敏感資料。

• 部分 Sandbox 複製會從 Sandbox 重新整理中排除「受限制」資料。
• 資料遮蔽規則會使用保留資料特性的模式,混淆 Sandbox 中的敏感欄位值。
• 合成資料產生適用於永不需要生產資料的開發環境。
• Sandbox 範本會定義要包含在每個 Sandbox 類型中的物件和欄位。

規範測試的設計是架構責任。針對具有實際特性的合成資料建立開發和測試週期,讓小組能夠根據類似生產的條件進行驗證,同時監管的資料仍在其生產界限內。

**您的責任:**設計 Sandbox 策略、設定 Data Mask 規則、產生合成測試資料。

透過結構決策設計符合使用者隱私權的解決方案。

• **資料最小化:**僅收集所述業務用途所需的資料。透過詢問「此資料需要什麼結構決策?」來挑戰每個欄位新增。請記住,最安全的資料是您從未收集的資料。
• **用途限制:**設計在技術上強制執行用途限制的資料存取模式。使用權限集和共用規則,根據工作功能的目的限制對資料的存取權。例如,行銷使用者不應存取支援個案詳細資料,除非其工作需要。
• **同意管理:**在行銷、分析和選擇性資料處理的個人層級實作同意追蹤。設計在整合系統中移入的同意撤銷工作流程。換句話說,同意是細微的,且特定於目的。
• **資料主題權利:**建立存取要求的工作流程 (例如提供資料副本)、更正 (例如修正不準確情況)、刪除 (例如在法律允許時刪除資料),以及可攜性 (例如匯出至機器可讀取的格式)。設計這些工作流程以在每個管理架構強制執行的回應期限內完成。這些期限會因管轄區而有所不同,且會定期修改,因此,從維護的合規性來源參數化工作流程的 SLA,並根據規範法規確認每個時段 (而非硬式編碼單一值) 很重要。

**您的責任:**使用最小化設計資料模型、依用途設定存取權、實作同意工作流程,以及建立資料主題權利自動化。

資料落地是您在佈建之前所做的結構性決策選擇,而不是您在之後切換的設定。Hyperforce 提供區域部署—但只有一個區域存在於 Salesforce 營運的區域—且組織的所在位置在佈建時是固定的。您的責任是確定每個資料種類必須位於何處、確認適當區域是否可用,並設計合法跨境的資料傳輸機制。

在開始之前,請務必先將您的居住義務分類,而不是預設為國內儲存。

• **必要本地化。**一小部分的管轄區需要某些資料才能保留在國界內 (有時只適用於受監管的產業)。當 Salesforce 未在國家/地區區域中運作時,原生儲存空間無法自行滿足要求,因此您需要該資料的資料落地重疊或個別組織。由於此清單可能改變,因此根據管理法規確認特定要求十分重要。
• **以責任為基礎的架構。**大多數的制度不會強制執行本地化要求。他們由具有適當跨境轉移機制的區域中心滿足。在這些情況下,決策是以最小化延遲並簡化合規性的區域為基礎。

當資料跨界時,關鍵在於設定前的感知。換句話說,您需要知道會發生哪些轉移,以及會根據何種法律基礎,然後設計存取權,讓資料一併受管理。若存在,則適當性決策會造成最少的摩擦。繫結公司規則 (BCR) 和標準契約子句 (SCC) 涵蓋大多數剩餘的轉移。僅使用明確同意作為最後手段。

將轉移機制與受限制的記錄存取權 (例如私人 OWD 和用途範圍共用) 配對,讓允許的轉移不會變得過於廣泛。文件資料流程對應以顯示每個資料種類的來源、傳輸和所在位置。當法規或區域可用性變更時重新查看。

**您的責任:**依資料種類分類落地義務、在佈建前確認區域可用性、選取跨境流程的轉移機制 (適當性、密件副本/密件副本),以及記錄資料流程地圖。

您有責任設計可維持平台所提供規範狀態的解決方案。

此指引為方向性。法規需求會因管轄和隨時間變化而有所不同。您必須一律根據規範法規 (例如適用的法規、上司機關或 Salesforce 規範文件) 來驗證部署的特定義務。

Salesforce 維護廣泛的合規性認證 (可在 Trust.salesforce.com 和 compliance.salesforce.com 取得):SOC 2 類型 II、ISO 27001、FedRAMP (適用於 Government Cloud 產品)、HIPAA、PCI DSS 和區域認證。這些認證涵蓋 Salesforce 對於平台基礎結構和共用服務的責任。

平台認證可減少您的合規性負擔,但不會消除您的結構責任。您的自訂物件、Apex 程式碼、整合和組態必須維持平台提供的合規性狀態。

**您的責任:**設計維護合規性狀態的解決方案,記錄結構滿足法規需求的方式。

• 針對包含受保護健康資訊 (PHI) 的所有欄位啟用 Shield Platform Encryption。
• 針對 HIPAA 規範,請啟用具有保留原則的「欄位稽核追蹤」,以符合 HIPAA 的記錄保留需求。根據法規確認目前期間。
• 設定「*事件監視」*以偵測未經授權的 PHI 存取模式。
• 實作 HIPAA 安全性規則所要求的所有技術保護措施,包括存取控制、稽核記錄和傳輸安全性。

• 透過權限集設計實作職務分隔 (SoD),以防止單一使用者建立和批准財務交易。
• 針對 PCI 環境,請避免將完整的主要帳戶號碼 (PAN) 儲存在 Salesforce 中,以將 PCI DSS 合規範圍降到最低。
• 如有可能,請使用 payment gateway 權杖化。

• 針對 GDPR 和 LGPD,請設計同意管理,此管理會收集細微的特定用途選擇加入同意。
• CCPA/CPRA 遵循選擇退出模式。提供明確的機制來選擇退出銷售或共用個人資訊,而非細微的用途式同意。
• 建立在每個架構回應期限內完成且根據管理法規確認的資料主題權利工作流程。
• 實作資料保留自動化,在同意到期時清除資料。

• 將 Salesforce Government Cloud 用於受監管的政府工作量。
• 實作對應至 Salesforce 組態的 NIST 800-53 控制項。
• 透過路由至政府 SIEM 基礎結構的「事件監視」來啟用持續監視。

**您的責任:**根據法規需求設定 Shield、欄位稽核追蹤、職務分隔、同意管理、資料保留。

資料保護與隱私權法規在各個司法管轄區中有所不同,且特定義務會快速變更,因此此層級需要決策,而非每個國家之間的表格。

兩個結構杠杆是「住所」和「跨境轉移」,其涵蓋於「資料保護」和「隱私權」。

若要遵循這些法規,您必須:

• 分類每個資料種類必須所在的位置
• 佈建前確認存在適當區域
• 針對跨境的資料設計法律傳輸機制。

如需詳細資訊,請查看「資料落地與主權」,以取得決策架構的詳細資料。

除此之外的所有內容都會視為時間點數字 (例如,司法管轄區使用的同意模型、資料主體要求的期限、違規後通知監管機構或受影響個人的時段,以及稽核記錄的最低保留期間)。這些數字是由法規所設定、各架構不同,且會在監管機構的排程上進行修訂。

請勿在這裡硬式編碼。您需要根據部署的規範 (或提及的維護合規性來源) 來決定後續步驟,並將您的設計調整為作業足跡中最窄的時段。

以下是屬於設計的永久結構後果。

• 以單一數字的天數測量的資料主題要求期限無法透過臨時手動流程達成,因此您在任何短期性司法管轄區中作業時,必須自動化 DSR 履行。使用 Experience Cloud 進行入門、Service Cloud 進行個案追蹤、使用「隱私權中心」進行探索,以及使用「流程」進行履行。
• 缺口通知視窗太窄,無法進行 improvisation,因此您必須提前建立缺口通知工作流程。決定「事件監視」異常規則、預先指派的角色、預先草稿的監管者和資料主體通知,以及假設足跡內最窄期限的升級路徑。個別通知通常是由高風險決定所觸發,因此您必須在工作流程中包含風險評估。
• 某些管轄區需要或建議在國家內保留稽核記錄 (最小值涵蓋數年),因此您需要將 SIEM 保留大小設定為足跡內最長的最小值,並確認記錄是否可以離開管轄區。

**您的責任:**針對「資料保護」與「隱私權」設計落地與轉移,將 DSR 與缺口回應工作流程自動化至您足跡中最嚴格的期限,並根據規範法規確認每個司法管轄區特定的數字,而非寫入此指南的值。

針對持續合規性驗證而非時間點稽核準備而設計。

• 「安全健康檢查」 會根據 Salesforce 安全性基準評估組態,並提供風險分數。定期執行檢查以監視 Salesforce 安全性基準建議的合規性。維護評分高於 80% (「非常好」或「優良」色帶)。
• 「事件監視」 會針對使用者活動、API 呼叫、驗證事件和資料存取模式,來儲存詳細記錄。將「*事件記錄檔案」*路由至外部 SIEM,以取得超過原生保留限制的長期保留。
• 交易安全性會根據原則即時評估事件,並可封鎖事件、要求增加 MFA,或通知您原則違規。

自動化部署管道中的合規性檢查十分重要,以驗證部署不會降低權限模型、停用稽核設定,或導入不合規組態。

**您的責任:**每季執行健康檢查、將「事件監視」路由至 SIEM、設定「交易安全性」原則,並自動化 CI/CD 中的合規性驗證。

根據合規性需求、調查需求和保留義務設計稽核追蹤策略。

針對受監管的環境,請使用外部 SIEM 整合實作「事件監視」,以進行長期記錄保留和跨系統關聯。設計「欄位稽核追蹤」原則,涵蓋受限於法規記錄保存需求的所有「受限制」和「機密」欄位。

**您的責任:**針對敏感欄位啟用「欄位稽核追蹤」,將「事件監視」路由至 SIEM,並設定「交易安全性」原則。

您有責任在整個開發過程中整合安全性,而不是作為後續考量。

在最早的開發階段整合安全性作法。架構階段期間的威脅建模可防止設計層級漏洞。除了功能需求之外,系統也採取的安全性需求讓您無法將安全性視為後續考量。

當在生產環境中發現安全性瑕疵而非在設計或開發階段時,修復安全性瑕疵的成本明顯高。結構檢閱期間發現的設計層級安全性缺陷可能只需要一個交談才能修正。然而,當在生產環境中發現相同的缺陷時,它需要重新架構、資料移轉、規範修復,以及潛在缺口通知。

這就是我們實作排班左側安全性的原因,其重點是:

• 設計完成前的威脅建模
• 使用者情節中的安全性需求
• 開發人員的安全編碼訓練
• 整合至 IDE 的靜態分析
• 以安全性為中心的程式碼審查
• CI/CD 中的自動安全性測試
• 生產部署前的安全性驗證

**您的責任:**執行威脅建模、訓練開發人員、將 Code Analyzer 整合至 CI/CD,並要求感知安全性的程式碼檢閱。

針對 Salesforce 內容中的常見漏洞設計防禦是很重要的。讓我們進一步瞭解如何在 Salesforce 中對應至 2025 年 OWASP 熱門 10 項。

• **A01:2025 - 存取控制中斷:**在所有 Apex 資料存取中以程式設計的方式強制執行 CRUD 和欄位級安全性 (FLS)。
  • 在 API 67.0 或更新版本中,Apex 依預設會在使用者環境中執行,這表示會在程式碼執行期間強制執行目前使用者的權限和 FLS。
    • WITH SECURITYENFORCED 已移除,這會導致編譯錯誤。以 WITH USER_MODE 取代任何現有的使用。平台會在標準 UI 中強制執行存取。
  • 在 API 66.0 版或更早版本中,系統模式為預設。在 SOQL 查詢中與 USERMODE 搭配使用,或在 DML 作業中使用 Security.stripInaccessible()。
• **A01:2025 - 用戶端資料 API:**Lightning Data Service 和 UI API 會自動強制執行執行使用者的 FLS、CRUD 和共用,因此以這些元件為基礎的元件預設會繼承最低權限。
  • 此保護會在元件呼叫自訂 Apex 時遺失。強制執行 Apex 只會在使用者模式中執行時強制執行存取權,因此未經共用宣告的類別會作為略過模型的逸出漏斗。
  • 使用 Lightning Data Service 和 UI API 來存取資料。
  • 您必須針對來自元件的每個強制 Apex 呼叫重新判斷 CRUD、FLS 和共用。
• **A02:2025 - 安全性設定錯誤:**使用「健康檢查」監視組態從安全性基準漂移。
  • 在 Experience Cloud 網站上停用來賓使用者存取權 (除非在經過文件的業務理由下明確要求如此)。
• A05:2025 - 注射:「2025 插入」種類涵蓋 SOQL/SOSL 插入和跨網站指令檔 (XSS)。
  • 針對查詢插入,請針對所有動態查詢使用繫結變數。請勿將使用者輸入直接串連至查詢字串。平台的參數化查詢機制在正確使用時可以消除插入風險。
  • SOQL 或 SOSL 插入的範圍會限定為顯示透過擴大查詢條件而無法接觸的記錄或欄位的讀取。由於這些語言會在寫入執行個別 DML 作業時讀取資料,因此會在未對查詢強制執行物件和欄位權限時產生存取控制和機密性風險,因為它會複雜。
  • 針對 XSS,Lightning Web 元件透過 LWC 呈現引擎提供自動保護。
  • 針對 Aura 元件和 Visualforce,當呈現動態內容時,您必須套用平台編碼函數 (例如 HTMLENCODE、JSENCODE 和 URLENCODE)。

**您的責任:**在自訂程式碼中強制執行 CRUD/FLS、套用編碼函數、使用繫結變數,以及監視組態漂移。

設計 CI/CD 銷售管道,並在每個階段使用安全性門。必須自動化安全性,才能以開發速度調整規模。

讓我們進一步瞭解銷售管道安全性階段。

• 來源控制會使用含必要程式碼檢閱的分行保護規則。主要分支沒有直接認可或已簽署認可。
• 靜態分析使用 Salesforce Code Analyzer,其整合 PMD、ESLint 和 RetireJS 來偵測插入、XSS 和不安全模式。
• 安全性掃描使用 SAST 工具和密碼偵測,以防止認證認可和相依性漏洞掃描。
• 權限驗證使用自動比較技術,以根據安全性基準檢閱權限變更,這會傳送權限擴充的相關警示。
• 針對需要安全性小組批准以擴充權限的變更的重要安全性發現,部署門將中斷部署。
• 部署後監視會針對部署後的異常行為使用「事件監視」警示。

**您的責任:**在 CI/CD 中整合 Code Analyzer、設定分支保護、實作部署門,以及自動驗證權限。

全方位安全性測試包含多個技術,可解決不同的漏洞類別。讓我們進一步瞭解每個策略。

• 靜態分析會在開發人員識別碼中執行 Salesforce Code Analyzer 以取得立即的回饋意見,並在 CI/CD 銷售管道中作為自動化門。靜態分析會在執行應用程式的情況下,識別來源程式碼中的漏洞。
• 滲透測試會針對公開給不受信任使用者 (尤其是 Experience Cloud 網站和公開 API) 的自訂應用程式執行滲透測試。
  • 針對 AppExchange 和 AgentExchange 安全審查,一律需要靜態分析報告。
  • 當解決方案整合第三方 Web 應用程式或服務時,需要動態掃描報告 (滲透測試)。
  • 滲透測試會針對即時應用程式模擬攻擊者技術。
• 以安全性為中心的單元測試會撰寫 Apex 測試,以使用不同權限設定檔的方式執行,以驗證強制執行存取控制。請務必確認 CRUD/FLS 強制執行會封鎖未經授權的存取。
• 相依性掃描會監視 AgentExchange 封裝和 JavaScript 程式庫是否有已知的漏洞。為已安裝的封裝訂閱安全性建議十分重要。

**您的責任:**執行程式碼分析器、執行滲透測試、撰寫安全性單元測試,以及掃描相依性。

在 Salesforce,安全性和資料事件回應專注於偵測、包含及復原缺口、未經授權的存取和惡意資料破壞。事件回應小組會與擁有相鄰責任的兩個鄰近支柱一起工作:

• Operational Excellence 涵蓋事件管理的作業機器 (例如,嚴重性層級、呼叫輪換、升級和事件後審查)
• 可靠性涵蓋對照 RTO 和 RPO 目標的可用性復原,包括備份和災害復原策略。

身為結構設計師,您必須負責針對安全性事件的偵測性、回應和復原進行設計。

可偵測性是您必須明確設計的結構品質。若無全方位監視,安全性事件可能會在長時間內保持未偵測。

透過多個管道實作偵測十分重要。

• 「事件監視」 會收集涵蓋登入、報告和資料匯出、權限變更和 API 呼叫的原始事件記錄。您需要識別哪些事件為異常,這需要在您設定的記錄上決定偵測邏輯的「交易安全性」原則或 SIEM 關聯性。
• 交易安全性原則會即時評估事件,並封鎖可疑動作。您需要設定這些原則。
• 「設定稽核追蹤」 會追蹤平台提供的管理變更,但您必須監視這些變更。
• 您需要實作的 Apex 中,自訂應用程式記錄 會捕捉與安全性相關的事件。

「將事件監視」記錄路由至 SIEM 平台,以與企業安全性遠端測量相關聯。設計警示規則,可偵測可疑模式,同時透過行為基準將假陽性最小化。

**您的責任:**將「事件監視」路由至 SIEM、設定「交易安全性」原則、實作自訂記錄,以及建立行為基準。

在事件發生之前,記錄支援事件回應的結構決策十分重要。

• 隔離邊界設計解決方案,以隔離入侵的元件,而不中斷重要的業務功能。您需要設定權限集撤銷、IP 限制變更和工作階段終止,以提供快速隔離功能。
• 鑑識保留使用「事件監視」提供詳細的活動記錄 (平台功能)。「欄位稽核追蹤」會根據您的組態保留資料變更歷程記錄。設計記錄會路由至固定的儲存空間,讓攻擊者無法修改您的結構。
• 復原程序會記錄常見事件類型的已測試復原程序。務必定期驗證備份完整性。您需要瞭解安全性事件情況的「復原時間目標」(RTO) 和「復原點目標」(RPO)。
• 通訊工作流程設計在事件期間運作的通知機制 (例如,頻外通訊管道、預先草稿的範本,以及不依賴潛在入侵系統的升級程序)。
• 漏洞揭露管道適用於公開的 Experience Cloud 網站。這可讓外部研究人員透過在 RFC 9116 security.txt 標準中發佈的揭露原則,向您報告安全性問題。外部報告通常是事件的第一個訊號,因此建立此入院路徑作為您負責的結構的一部分十分重要。

**您的責任:**記錄隔離程序、將記錄路由至固定的外部儲存空間、每季測試復原程序、建立頻外通訊,以及發佈公開網站的漏洞揭露管道。

在 Salesforce 中,為平台特定情況準備回應功能十分重要。

• 系統會透過「事件監視」登入異常 (例如非預期的地理位置、異常時間和新裝置) 偵測到入侵的使用者帳戶。當帳戶遭到入侵時,請凍結使用者、強制執行認證重設、檢閱「設定稽核追蹤」和資料存取記錄,以決定入侵期間。
• 透過「事件監視」報告匯出和 API 資料存取量異常偵測到 大量資料外洩。發生資料竊取時,請立即撤銷工作階段、限制權限,並識別受影響的記錄和分類層級。
• 透過部署監視和「設定稽核追蹤」組態變更來偵測到未經授權的程式碼部署。部署未經授權的程式碼時,請立即回復部署,並稽核已入侵部署認證中的所有變更。
• 系統會透過「設定稽核追蹤」監視,偵測在已批准變更期間之外的權限變更權限升級。當權限升級發生時,請立即撤銷升級的權限,並稽核以增強的存取權執行的活動。

**您的責任:**記錄平台特定案例的回應程序、設定監視以偵測每個案例、透過桌面演練測試程序。

事件發生後,請務必執行以結構改善為重點的判斷式事件後審查。您需要記錄發生的狀況、現有控制項無法防止或偵測事件的原因,以及減少未來風險所需的結構變更。

事件後審查目標:

• 決定事件時程表與攻擊者技巧。
• 識別啟用事件的控制失敗。
• 記錄事件顯示的所有結構劣勢。
• 根據風險減少來排定補救措施的優先順序。
• 跨小組共用學到的經驗。
• 更新偵測規則和回應程序。

請務必追蹤隨時間的事件度量,以決定平均偵測時間 (MTTD)、平均回應時間 (MTTR) 和影響範圍。

**您的責任:**及時執行事件後審查、記錄 ADR 的改善方式、追蹤 MTTD 和 MTTR 趨勢,以及分享學到的經驗。

在結構檢閱期間、生產部署前,並定期使用此檢查清單進行持續評估。每個項目皆代表您身為 Salesforce 結構設計師的責任。

共用責任

• 記錄 Salesforce 保護的所有內容 (例如基礎結構、平台和合規性認證)。
• 記錄您必須保護的所有內容 (例如組態、存取、自訂程式碼和資料管理)。
• 識別共用責任的區域 (例如事件回應、漏洞管理和監視)。
• 盡可能清楚且簡要地將責任傳達給利害關係人和實作小組。

安全結構

• 開始建立之前,請使用 STRIDE 方法完成威脅建模。
• 在資料、應用程式、身分和整合層面套用深度防禦控制項。
• 實作零信任原則,其需要針對每個存取要求明確驗證。
• 維護目前的安全性資產庫存,涵蓋敏感資料、整合、API 和特權帳戶。
• 記錄 ADR 中的安全性結構決策,包括威脅分析和控制理由。
• 透過移入每個使用者的身分而非集區權杖,在 Salesforce Trust 邊界保護無周邊和代表用戶的安全。
• 透過外部用戶端應用程式儲存、輪替和最低權限範圍 OAuth 認證。
• 針對容器化整合,請強制執行容器隔離作為安全性邊界、使用 mTLS 加密容器間和混合式 VPN 流量 (當架構需要時),並將部署區域與資料落地與合規性認證保持一致

身分與存取管理

• 針對包含敏感資料的物件,將 OWD 設定為「私人」。
• 將「**公用唯讀」**保留給廣泛讀取存取權為已記錄需求的物件。
• 針對所有生產 UI 存取權強制執行 MFA,並針對特權帳戶強制執行硬體安全性金鑰。使用 JWT Bearer 或用戶端認證的僅 API 整合會例外。
• 透過強大的 IdP 驗證,使用 SAML 2.0 或 OpenID Connect 實作 SSO。
• 針對所有 API 驗證使用 OAuth 2.0 (偏好的是 JWT 承載者)。永不將 OAuth 2.0 用於內嵌認證。
• 透過根據已記錄最低權限需求的權限集授與存取權。
• 將增強控制套用至重要影響帳戶 (例如,IP 限制、登入警示和定期存取審查)。
• 針對高權限帳戶執行定期存取審查,其中頻率由組織風險容忍度與合規性需求決定。
• 透過 SCIM 佈建和 90 天靜態帳戶偵測自動化身分生命週期。
• 在登入使用者的內容中執行員工工作人員,並為客戶工作人員佈建專屬且最低權限的工作人員使用者。切勿為公用網站來賓使用者這麼做。
• 使用工作人員例項和機器人定義識別碼實作 JWT 以進行工作人員驗證。
• 定義 ABAC 原則,以符合資料分類和一致的中繼資料標記標準。

資料保護與隱私權

• 分類所有資料,並套用適合每個分類層級的保護控制項。
• 使用文件式金鑰管理,針對 受限制的資料啟用 Shield Platform Encryption。
• 針對所有與以憑證為基礎之驗證的整合,針對 受限制資料,需要 TLS 1.2+。
• 透過遮蔽或排除防止「受限制」的資料進入非生產環境。
• 使用細微的各用途追蹤與提領工作流程實作同意管理。
• 建立在每個管理架構回應期限內完成的資料主題權利工作流程。這些資料應調整為您營運足跡中最窄的時間範圍,並從維護的合規性來源依據管轄法規來進行參數化。
• 記錄資料落地需求並驗證 Hyperforce 區域對齊方式。

規範與法規符合度

• 驗證滿足您行業法規需求的平台認證。
• 針對超過原生保留限制的保留,啟用具有 SIEM 路由的「事件監視」。
• 設定欄位稽核追蹤以涵蓋「受限制」欄位,以確保保留符合法規最低值。
• 維護「安全性健康檢查」評分為 80% 或更高 (極好或極好色帶),並記錄任何例外。
• 在重大違規期間自動化 CI/CD 銷售管道的合規性驗證。
• 實作「交易安全性」原則以進行即時異常偵測和回應。

安全開發生命週期

• 在設計階段期間 (在進行重大建構投資之前) 執行威脅建模。
• 在所有 Apex 環境中強制執行 CRUD/FLS。
• 依賴 API 67.0 版或更新版本的自動使用者模式強制執行,或針對 API 66.0 版或更新版本使用 WITH USERMODE 或 stripInaccessible()。
• 請勿與 API 67.0 版中移除的 SECURITYENFORCED 搭配使用。
• 當重要發現結果封鎖部署時,在 CI/CD 中執行 Salesforce Code Analyzer。
• 所有生產變更都需要由感知安全性的檢閱者進行程式碼審查。
• 針對所有公開應用程式和 Experience Cloud 網站執行滲透測試。
• 驗證並消毒防止在 SOQL、SOSL 和 HTML 內容之間插入的所有使用者輸入。

安全性事件回應

• 設計「事件監視」警示規則,透過行為基準來偵測可疑模式。
• 將記錄路由至固定的外部儲存空間以進行鑑識保留。
• 記錄並測試平台特定案例的事件回應程序。
• 使用 ADR 執行無罪的事件後審查,以瞭解結構改善。
• 追蹤 MTTD 和 MTTR 度量以識別偵測與回應差異。

分享您對良好架構的回饋意見。