資料保護模式


深入瞭解 Well-Architected Trust → 資料保護與隱私權

模式

要尋找的位置良好的外觀
資料分類方式✅ 分類方式記錄的層級 (公用、內部、機密、受限制)
✅ 針對每個分類層級提供的業務範例
✅ 符合法規義務的分類方式 (HIPAA、PCI DSS、GDPR)
✅ 已訓練資料建模人員在設計期間一致套用分類
✅ 分類為資料建模流程一部分的新欄位,而非追溯
欄位級分類✅ 套用於欄位層級的分類,而不只是物件層級
✅ 單一物件內的欄位可以有不同的分類
✅ 欄位級安全性會反映分類差異
✅ 未分類的資料預設為最高適當的保護層級
✅ 分類會驅動保護控制項 (加密、存取、保留)
自訂物件與欄位✅ 所有自訂物件都有已記錄的資料分類
✅ 分類為「機密」或「受限制」的敏感欄位 (Salary、SSN、PHI、付款資料)
✅ 文件記錄為「公用」的公用欄位 (公司名稱、網站)
✅ 在欄位描述中收集的分類中繼資料
✅ 在程式碼審查和 ARB 期間檢閱的分類
標準物件✅ 根據分類方式評估的標準物件欄位
✅ 針對受限制的標準欄位啟用 Shield Platform Encryption
✅ 套用至「機密」標準欄位的欄位級安全性
✅ 已篩選報告和清單檢視以防止敏感標準欄位顯示
整合資料✅ 透過實作前分類的整合流動的資料
✅ 已評估和記錄外部系統資料敏感度
✅ 處理受限制資料的整合端點使用以憑證為基礎的驗證
✅ 跨系統界限保留的資料分類
合規性對應✅ 已識別並標記為「受限制」的 HIPAA PHI 欄位
✅ 盡可能避免在 Salesforce 中使用 PCI 持卡人資料—透過付款管道進行權杖化以減少範圍;若必須儲存,請使用 PCI DSS 控制項下的「加密自訂欄位」
✅ 已識別並受隱私權控制的 GDPR 個人資料
✅ 已分類且受限於職責分隔的 SOX 財務資料

反模式

要尋找的位置看起來怎麼壞
統一保護⚡️ 不論敏感度為何,套用至所有欄位的相同保護
⚡️ 低價值資料受到過度保護 (浪費資源),而高價值資料受到保護不足
⚡️ 公用公司資訊的處理方式與 PHI 或付款卡資料相同
⚡️ 每個欄位皆已加密「僅供確保安全」且沒有分類理由
追溯分類⚡️ 部署至生產後分類的資料
⚡️ 透過規範稽核而非設計審查發現的敏感資料
⚡️ 僅在安全性事件之後分類的資料
⚡️ 「稍後我們會找出分類」是開發期間的預設值
僅物件級分類⚡️ 欄位有不同的敏感度時,整個物件會統一分類
⚡️ 未授與敏感欄位欄位欄位級安全性的物件級存取權
⚡️ 帳戶或連絡人物件上假設具有相同分類的所有欄位
⚡️ 作為混合敏感性物件唯一存取控制項的物件權限
部落Knowledge⚡️ 分類未記錄,僅存在於重要人員的 Knowledge 中
⚡️ 開發人員依賴「只要知道」哪些欄位是敏感的
⚡️ 所有資料建模器都無法存取任何撰寫分類方式
⚡️ 沒有分類訓練即可上線的新小組成員

模式

要尋找的位置良好的外觀
靜態加密✅ 透過 Hyperforce 在基礎結構層級加密的所有資料
✅ 針對受限制的資料啟用 Shield Platform Encryption
✅ 根據查詢和唯一性需求選取的加密方式 (可能性、決定性、區分大小寫決定性)
✅ 資料模型設計期間評估的加密權衡
Shield Platform Encryption 策略✅ 用於大多數「受限制」欄位的概率加密 (支援所有查詢作業)
✅ 用於需要完全符合 WHERE 子句或唯一性的欄位決定性加密
✅ 在個案區分對業務邏輯十分重要時使用區分大小寫決定性
✅ 在生產部署前測試的加密欄位行為
✅ 公式欄位參照適當處理的加密欄位 (視需要移至 Apex)
金鑰管理✅ 已記錄和自動化的金鑰輪換程序
✅ 在災害復原演練期間測試的金鑰終結案例
✅ 需要明確金鑰控制的客戶管理金鑰 (BYOK) 評估合規性
✅ 已記錄重要撤銷程序
✅ 根據合規性需求管理的加密金鑰生命週期
傳輸中的加密✅ 所有整合都需要 TLS 1.2 或更高版本
✅ 用於處理受限制資料之整合的以憑證為基礎共同驗證
✅ 針對 Experience Cloud 網站設定的 HSTS 標頭,以防止通訊協定降級
✅ 已監視 TLS 憑證到期並設定自動續約
✅ 弱加密與已停用的通訊協定
程式碼和組態✅ 從未內嵌在程式碼、組態檔案或版本控制項中的認證
✅ 用於集中管理驗證的已命名認證和外部認證
✅ 結構內建的認證輪換功能
✅ 來自程式碼的已命名認證抽象驗證,無須變更程式碼即可啟用更新
AppExchange 封裝✅ 安裝前評估的封裝安全性需求
✅ 只有在業務正確時,封裝才能存取加密欄位
✅ 透過「事件監視」監視的封裝資料存取模式
✅ 需要增強型檢閱的受限制資料存取權的封裝

反模式

要尋找的位置看起來怎麼壞
不含評估的加密⚡️ 未經測試的所有欄位皆啟用概率加密
⚡️ 在生產環境中找到的重要報告會失敗,因為無法彙總加密的欄位
⚡️ 在公式欄位來源上啟用加密,但不受瞭解影響
⚡️ 在未切換至決定性加密的情況下,加密 SOQL LIKE 查詢中使用的欄位
內嵌認證⚡️ 內嵌在程式碼、自訂設定或版本控制中的認證
在 Apex 類別中硬式編碼的 API 金鑰、密碼和憑證
⚡️ 認證認可至來源控制儲存庫
⚡️ 未加密的自訂中繼資料或自訂設定中儲存的認證
寬弱或舊版通訊協定⚡️ 接受 TLS 1.0 或 1.1 (已淘汰且易受攻擊)
⚡️ JWT 承載者可用時允許使用者名稱密碼 OAuth 流程
⚡️ 在生產整合中接受自我簽署憑證
⚡️ 憑證驗證已停用「讓整合運作」
無金鑰管理⚡️ Shield Platform Encryption 未啟用金鑰輪換程序
⚡️ 沒有記錄的金鑰破壞情況
⚡️ 未評估客戶管理金鑰的合規性中使用的預設金鑰
⚡️ 金鑰輪換和撤銷程序從未測試過
過度加密⚡️ 已加密公用或內部分類資料,進而增加成本但沒有益處
⚡️ 在每個欄位上啟用 Shield Platform Encryption,造成不必要的複雜性
⚡️ 當規範不需要時使用 BYOK (新增營運額外費用)
⚡️ 資料分類不正確時強制執行加密

模式

要尋找的位置良好的外觀
Sandbox 策略✅ 受限制的資料永不進入開發或測試環境
✅ 部分 Sandbox 複製會排除「受限制」物件與欄位
✅ Sandbox 範本會依環境類型定義要包含的物件和欄位
✅ 針對需要生產類似資料的 Sandbox 設定的 Data Mask
Data Mask 規則✅ Data Mask 規則會隱藏敏感欄位,同時保留資料特性
✅ 模式會維持參照完整性 (相同的輸入會產生相同的遮蔽輸出)
✅ 電子郵件地址已遮蔽但保持有效格式進行測試
✅ 已遮罩但保持有效格式的電話號碼
✅ 一律改變的日期,維持相對關係
✅ 在實際範圍內隨機排序的數值欄位
合成資料✅ 開發環境使用合成資料產生
✅ 合成資料具有實際的特性,可讓有效測試
✅ 開發不需要任何生產資料
✅ 在開發管道中測試自動產生的資料
非生產環境✅ 從未複製到個人開發人員組織的生產資料
✅ 使用遮蔽或合成資料的螢幕快照和示範
✅ 訓練環境使用合成資料或高度遮蔽的生產資料
✅ 承包商和廠商對限制為「僅限業務使用」分類的非生產資料存取權

反模式

要尋找的位置看起來怎麼壞
Sandbox 中的生產資料⚡️ 使用未遮罩的生產資料重新整理的完整 Sandbox 以供開發
⚡️ 為了方便,將受限制的資料複製到開發人員 Sandbox
⚡️ 開發人員獲得生產資料 Sandbox 的廣泛存取權
⚡️ 已使用敏感資料重新整理 Sandbox,因為實際資料更容易進行測試
無合成資料⚡️ 僅供所有測試使用的生產資料
⚡️ 沒有適用於開發環境的綜合資料產生
⚡️「我們需要實際資料」假設而不評估合成替代項目
⚡️ 可自動產生時建立的手動測試資料

模式

要尋找的位置良好的外觀
資料最小化✅ 僅針對所述業務用途收集的必要資料
✅ 每個欄位新增都會以「此資料需要什麼結構決策?」來挑戰。
✅ 已移除不再提供集合用途的資料
✅ 清楚標記且不需要且不具業務理由的選擇性欄位
✅ 符合法律基礎的歷程記錄資料保留,而非「永遠保留所有內容」
用途限制✅ 權限集會根據工作功能用途限制資料存取
✅ 行銷使用者無法在沒有記錄的理由的情況下存取支援個案詳細資料
✅ 除非工作需要,否則銷售使用者無法存取客戶服務歷程記錄
✅ 跨功能資料存取需要明確的批准與監視
✅ 權限集描述中記錄的資料存取目的
同意管理✅ 針對行銷、分析、選用處理,在個別層級收集的同意
✅ 同意是細微的 (用途特定),非二進位全面同意
✅ 同意撤銷工作流程會跨整合系統移入
✅ 使用時間戳記、版本和機制追蹤的同意決策
✅ 同意使用者介面會清楚說明使用者同意的內容
資料主題權利✅ 存取要求工作流程會在部署的規範法規設定期限內提供資料複本
✅ 透過稽核追蹤修正不正確的工作流程
✅ 刪除工作流程會在法律允許的情況下刪除資料 (考量保留義務)
✅ 可攜性工作流程會以機器可讀取的格式匯出資料
✅ 定期測試資料主題權利工作流程以驗證時間表
✅ 工作流程自動化可確保一致符合法規時程表
隱私權控制✅ 透過技術強制執行隱私權控制,而非僅透過原則
✅ 共用規則實作目的限制
✅ 欄位級安全性可保護敏感屬性
✅ 稽核追蹤會捕捉與隱私權相關的事件
✅ 在 CI/CD 管道中驗證的隱私權控制

反模式

要尋找的位置看起來怎麼壞
收集所有內容⚡️「收集所有可能的資料,可能有一天會需要」方法
⚡️ 未記錄業務用途的欄位
⚡️ 無保留原因的資料會無限期保留
⚡️ 透過將欄位設為必要而收集的選擇性資料
保單同意⚡️ 所有用途的單一「同意條款」同意
⚡️ 在單一核取方塊中結合服務提供的行銷同意
⚡️ 當目的可分開時全部或無內容的同意
⚡️ 隱藏在 20 頁條款與條件中的同意
不強制執行的原則⚡️ 隱私權原則描述未在技術上強制執行的理想作法
⚡️ 使用者訓練以防止不當的資料存取
⚡️ 未實作技術控制項目的隱私權原則已記錄
⚡️ 不經監視與驗證的原則合規性假設
手動資料主題要求⚡️ 花費數月的手動 IT 票證處理 GDPR/CCPA 要求
⚡️ 沒有存取、更正、刪除、可攜性的記錄程序
⚡️ 缺少部署的規範集要求完成視窗
⚡️ 要求在稽核期間找到的工作流程不存在
過量資料共用⚡️ 不含用途理由的跨部門廣泛資料存取權
⚡️ 允許行銷存取支援個案詳細資料
⚡️ 銷售允許無須記錄的客戶服務歷程記錄存取
⚡️ 公用讀/寫 OWD 用於包含個人資料的物件

模式

要尋找的位置良好的外觀
Hyperforce 區域部署✅ 在 Hyperforce 區域中提供的組織符合資料落地需求
✅ 資料儲存與處理會在必要的地理界限內進行
✅ 佈建前已記錄和驗證的區域需求
✅ 視需要透過多組織結構處理的多區域需求
資料流程對應✅ 資料流程會對應資料來源、傳輸和所在的文件
✅ 根據法規識別並評估的跨境資料傳輸
✅ 標準契約子句或具有約束力的國際轉移公司規則
✅ 針對住所合規性評估的資料傳輸路徑,而不只是儲存位置
資料落地範圍✅ 資料儲存位置 ( Hyperforce 區域)
✅ 資料處理位置 (計算區域)
✅ 備份儲存空間位置
✅ 記錄和稽核追蹤儲存位置
✅ 針對跨境資料移動評估的整合傳輸路徑
多組織結構✅ 當單一組織內無法符合法規需求時使用的多組織結構
✅ 在適當區域中為其資料佈建的每個組織
✅ 整合模式遵循資料落地限制
✅ 在 ADR 中記錄的作業複雜性權衡
合規性驗證✅ 由管轄權記錄的資料落地需求
✅ 佈建前根據需求驗證 Hyperforce 區域選取項目
✅ 定期稽核確認資料仍在必要界限內
✅ 對居住法規的變更會觸發結構審查

反模式

要尋找的位置看起來怎麼壞
住所監督⚡️ 合規性稽核期間發現的資料落地違規
⚡️ 未評估區域需求的已佈建組織
⚡️ 假設「雲端是雲端」,但不考量資料位置法規
⚡️ 未檢閱居留權義務的州/省
忽略居住的交通工具⚡️ 忽略傳輸路徑時,僅考量儲存位置
⚡️ 透過合規性界限以外地區路由的資料
⚡️ 不合規區域中使用的整合中介軟體
⚡️ 儲存在與主要資料不同區域的備份
不需要的多組織⚡️ 當具有 Hyperforce 區域的單一組織足夠時使用的多組織結構
⚡️ 運作複雜性、授權成本和整合負擔乘以不需要監管
⚡️ 實作「僅供安全使用」的多組織,沒有特定規範需求
⚡️ 資料分類與存取控制足夠時,預設使用的多組織