身分與存取管理 - 模式


深入瞭解良好結構的 Trust → Identity and Access Management

模式

要尋找的位置良好的外觀
平台 | 結構✅ 無論網路位置或裝置為何,存取控制都會在每個要求上明確驗證身分
平台 | 結構✅ 以身分為基礎的安全性控制會取代以網路為基礎的 Trust 假設
平台 | 組織✅ 存取決策會考量誰要求存取權 (驗證)、他們獲授權執行的動作 (授權),以及內容 (裝置、位置)
平台 | 文件✅ 安全性結構會將身分記錄為主要 Trust 邊界,而非網路邊界

反模式

要尋找的位置看起來怎麼壞
平台 | 結構⚡️ 公司網路或 VPN 上的使用者會被認為值得信任,並僅根據網路位置獲得更廣泛的存取權
平台 | 結構⚡️ 存取控制依賴網路周邊,而非身分驗證
平台 | 組織⚡️ 存取決策不會考量內容訊號 (裝置、位置、時間、行為模式)
平台 | 文件⚡️ 安全性結構會將網路位置視為主要 Trust 邊界

模式

要尋找的位置良好的外觀
平台 | 組織✅ 解決方案利用所有四個 Salesforce 存取層:組織 (授權、功能)、物件 (CRUD)、欄位 (FLS)、記錄 (共用)
平台 | 組織✅ 存取模型是由上而下設計 (組織 → 物件 → 欄位 → 記錄),並由下而上驗證
平台 | 組織✅ 針對包含敏感資料的物件,組織範圍預設值 (OWD) 設為「專用」
平台 | 組織✅ 設為「公用唯讀」的 OWD 僅限於參照物件 (產品、價目手冊),其中廣泛的可視性支援業務,而不暴露風險
平台 | 組織✅ 組織層級限制 (授權、IP 範圍、登入時間、功能權限) 會定義使用者族群的基準功能
平台 | 組織✅ 物件權限 (透過設定檔和權限集) 可控制使用者區段中每個物件的建立、讀取、編輯和刪除存取權
平台 | 組織✅ 欄位級安全性會在授與物件存取權時保護敏感欄位
平台 | 組織✅ 記錄級共用會根據記錄業務需求使用角色階層和共用規則
平台 | 組織✅ 從限制基準刻意展開的存取權,在權限預設值之後不受限制

反模式

要尋找的位置看起來怎麼壞
平台 | 組織⚡️ 存取模式不會利用全部四個層級 (組織、物件、欄位、記錄)
平台 | 組織⚡️ OWD 設為「公用讀/寫」,以便在開發期間使用不受限制的計畫
平台 | 組織⚡️ 在早期設定過度允許的 OWD 會隨著資料量成長和業務流程的結束而難以指數化限制
平台 | 組織⚡️ 未設定欄位級安全性,僅依賴物件或記錄級存取控制

模式

要尋找的位置良好的外觀
平台 | 組織✅ 針對存取生產環境的所有使用者強制執行多因素驗證 (MFA) (使用者介面存取權為必要)
平台 | 組織✅ MFA 延伸至特權營運,包括大量資料匯出、權限變更和管理組態
平台 | 組織✅ 單一登入 (SSO) 使用 SAML 2.0 或 OpenID Connect 通訊協定
平台 | 組織✅ 工作階段逾時設定適當:標準使用者 2 小時,管理員和存取「受限制」資料的使用者 15 到 30 分鐘
平台 | 組織✅ 針對管理設定檔與整合使用者強制執行 IP 限制
平台 | 組織✅ 登入時間會將服務帳戶限制為預期的營運時段
平台 | 組織✅ 本地裝置啟用會驗證來自無法辨識裝置的登入;MFA 和 IP 限制可為高權限帳戶增加保護
平台 | 組織✅ 如果 SSO 已啟用,則已批准的管理員使用者擁有直接登入存取權 (休息玻璃程序)
平台 | 組織✅ 登入 Salesforce 的使用者與實體之間的關係為 1:1 (沒有共用的使用者帳戶)
平台 | 組織✅ API 存取控制可防止使用者透過未經授權的連線應用程式進行驗證
平台 | 已命名認證✅ 已命名認證和外部認證會使用輪替功能集中管理驗證
平台 | 已命名認證✅ 已命名認證從程式碼抽象驗證詳細資料,啟用無須變更程式碼的認證更新
平台 | 已命名認證✅ 認證永遠不會內嵌在程式碼、組態檔案或版本控制
平台 | Apex✅ 執行驗證的方法會使用已命名認證來處理使用者名稱/密碼流程
平台 | Apex✅ 沒有使用者名稱或密碼會以可讀的程式碼顯示 (沒有硬式編碼值或字串)
平台 | Aura✅ 執行驗證的方法會使用已命名認證來處理使用者名稱/密碼流程
平台 | Aura✅ 使用者名稱或密碼不會以可讀的格式顯示在程式碼中
平台 | Lightning Web 元件 (LWC)✅ 執行驗證的方法會使用已命名認證
平台 | Lightning Web 元件 (LWC)✅ 程式碼中不會出現使用者名稱或密碼
整合 | API✅ OAuth 2.0 JWT 承載者流程用於信任環境中的伺服器對伺服器整合 (優先於生產整合)
整合 | API✅ OAuth 2.0 Web 伺服器流程用於需要使用者內容的伺服器對伺服器整合
整合 | API✅ OAuth 2.0 裝置流程用於無周邊裝置;CLI 和 CI/CD 工具會使用 Web 伺服器流程 (sf org login web) 或 JWT 承載者流程 (sf org login jwt) — 自 2025 年 8 月 28 日起,預設 Salesforce CLI 連線應用程式已封鎖裝置流程
整合 | API✅ 不使用使用者名稱密碼 OAuth 流程;依賴該流程的現有整合會移轉至 JWT 承載者或用戶端認證流程

反模式

要尋找的位置看起來怎麼壞
平台 | 組織⚡️ 不會針對生產環境存取強制執行 MFA
平台 | 組織⚡️登入組態不符合 Salesforce MFA 需求
平台 | 組織⚡️ MFA 不會延伸至特權營運 (大量匯出、權限變更、管理組態)
平台 | 組織⚡️ 工作階段逾時未設定或過度允許 (>24 小時)
平台 | 組織⚡️ 工作階段原則不會區分標準使用者與存取「受限制」資料的管理員/使用者
平台 | 組織⚡️ 不會對管理設定檔與整合使用者強制執行 IP 限制
平台 | 組織⚡️ 服務帳戶的登入時間未受限於預期的營運時段
平台 | 組織⚡️ 高權限帳戶依賴裝置啟用以外的任何項目—沒有新增 MFA 或 IP 限制
平台 | 組織⚡️ 如果已啟用 SSO,則沒有任何經批准的管理員使用者擁有直接登入存取權 (沒有斷眼鏡程序)
平台 | 組織⚡️ 使用者與實體之間的關係不是 1:1 (共用使用者帳戶存在)
平台 | 組織⚡️ API 存取控制未啟用
平台 | 已命名認證⚡️ 認證會直接內嵌在程式碼、組態檔案或版本控制
平台 | Apex⚡️ 使用者名稱和密碼會以可讀的程式碼格式顯示
平台 | Apex⚡️ 驗證會在沒有一致實作的情況下臨時處理
平台 | Aura⚡️ 驗證會在不含已命名認證的情況下進行臨時處理
平台 | Aura⚡️ 使用者名稱和密碼會顯示在程式碼中
平台 | Lightning Web 元件 (LWC)⚡️ 驗證會在不含已命名認證的情況下進行臨時處理
平台 | Lightning Web 元件 (LWC)⚡️ 使用者名稱和密碼會顯示在程式碼中
平台 | 公司⚡️ 不存在使用者提供和取消佈建的 SLA 與需求
整合 | API⚡️ 當有更安全的 OAuth 流程可用時,會使用使用者名稱密碼 OAuth 流程
整合 | API⚡️ OAuth 範圍過度允許 (限制範圍足夠時完整存取權)
整合 | API⚡️ 用戶端認證 (用戶端識別碼、用戶端密碼) 會安全地儲存在程式碼或組態檔案中

模式

要尋找的位置良好的外觀
平台 | 組織✅ 角色階層深度上限為 5-7 個層級 (避免效能超額和疑難排解複雜性)
平台 | 組織✅ 權限集和權限集群組提供彈性的附加存取權,而不會導致設定檔擴充
平台 | 組織✅ 權限集授與特定工作功能、申請或暫時增強權限的存取權
平台 | 組織✅ 權限集群組結合相關權限集與例外狀況的靜音功能
平台 | 組織✅ 所有功能存取權會透過權限集和權限集群組 (非設定檔) 授與,隨著工作角色演進提供彈性
平台 | 組織✅ 交易安全性原則會透過即時內容評估擴充授權
平台 | 組織✅ 交易安全性原則會偵測並封鎖異常行為 (大量資料下載超出模式、從非預期的地理位置登入、變更視窗外的權限變更)
平台 | 組織✅ IP 限制適用於高敏感性作業或資料存取
平台 | 組織✅ 針對每個整合設定唯一的 API 整合使用者
平台 | Apex✅ 所有程式碼存取資料都會使用 WITH USER_MODE、WITH SYSTEM_MODE 關鍵字或 Security.stripInaccessible() 方法強制執行 CRUD 和 FLS
平台 | Apex✅ SOQL 查詢會根據業務需求明確使用「具有 USER_MODE」或「具有 SYSTEM_MODE」關鍵字
平台 | Apex✅ DML 作業使用 Security.stripInaccessible() 來在 insert/update/upsert 作業前強制執行存取權
平台 | Apex✅ 資料庫 DML 陳述式明確宣告資料作業的使用者或系統模式
平台 | Apex✅ 資料庫作業使用 stripInaccessible() 方法來篩選查詢和子查詢結果
平台 | Apex✅ 共用關鍵字 (含共用、不含共用、繼承共用) 會根據業務安全性需求適當使用
平台 | 設計標準✅ 使用個案來授與增強權限 (修改所有資料、檢視所有資料) 會以業務理由清楚記錄

反模式

要尋找的位置看起來怎麼壞
平台 | 組織⚡️ 角色階層高於 5-7 層級,在共用計算和疑難排解複雜性中建立效能額外負擔
平台 | 組織⚡️ 角色階層授與無業務理由的廣泛存取權
平台 | 組織⚡️ 設定檔會針對較小的權限變化重複複複製,進而建立有不明確區分的十幾個設定檔
平台 | 組織⚡️ 設定檔包含中繼資料的存取控制項 (應使用權限集)
平台 | 組織⚡️ 未實作「交易安全性」原則來偵測異常行為
平台 | 組織⚡️ IP 限制未針對高敏感性作業或資料存取設定
平台 | 組織⚡️ 未設定 API 僅限使用者,或在多個整合之間共用
平台 | 組織⚡️ 未經記錄的理由授與「檢視所有資料」或「修改所有資料」權限
平台 | Apex⚡️ SOQL/SOSL 查詢和 DML 作業在預設系統模式中執行,無須明確存取檢查
平台 | Apex⚡️ CRUD 與 FLS 強制執行不一致或遺失
平台 | Apex⚡️ SOQL 依賴已移除的 WITH SECURITY_ENFORCED,現在導致編譯錯誤 (以 WITH USER_MODE 取代)
平台 | Apex⚡️ 共用關鍵字使用不一致或完全不使用
平台 | 設計標準⚡️ 未清楚記錄授與增強權限的使用個案

模式

要尋找的位置良好的外觀
平台 | Data 360✅ RBAC (角色、設定檔、權限集) 控制平台存取權 (誰可以使用 Data 360),ABAC 控制資料存取權 (他們根據屬性查看的資料)
平台 | Data 360✅ AI 工作人員會在要求使用者的內容 (代表) 中執行,因此工作人員產生的查詢會受到該使用者的存取權限制,而非透過系統級存取權執行
平台 | 文件✅ 資料分類分類分類已使用屬性定義、強制執行規則和業務理由進行記錄

反模式

要尋找的位置看起來怎麼壞
平台 | Data 360⚡️ 必須遵循資料分類的存取權會透過角色階層與共用 (無法表達) 強制執行,而非透過以屬性為基礎的存取控制
平台 | Data 360⚡️ FLS 略過:沒有欄位級存取權的使用者可透過不強制執行 FLS 的 API 或 SOQL 查詢來提取資料
平台 | Data 360⚡️ AI 工作人員在未在要求使用者內容中執行的情況下查詢資料;工作人員產生的查詢會略過物件、欄位和記錄級存取控制
平台 | Data 360⚡️工作人員執行內容不包含代表使用者的屬性;工作人員使用系統級存取權作業
平台 | 文件⚡️ 資料分類分類分類已取消記錄;屬性定義會因小組建立不一致的強制執行而有所不同

模式

要尋找的位置良好的外觀
平台 | 組織✅ 重要影響帳戶 (系統管理員、整合使用者、自動化程序帳戶) 會在資產庫存中識別並追蹤
平台 | 組織✅ 重要影響帳戶代表高價值目標,因為權限提高,提供廣泛的平台存取權
平台 | 組織✅ MFA 需要硬體安全性金鑰或驗證器應用程式 (非 SMS,這容易受到 SIM 交換)
平台 | 組織✅ 登入 IP 範圍僅限於已知的管理位置
平台 | 組織✅ 登入警示與權限變更通知已啟用
平台 | 組織✅ 每季執行存取審查,並提供已記錄的證明
平台 | 組織✅ 使用後稽核的緊急存取存在斷玻璃程序
整合 | 服務帳戶✅ OAuth 流程用於整合和服務帳戶 (永不使用者名稱密碼)
整合 | 服務帳戶✅ 針對整合使用者強制執行 IP 限制
整合 | 服務帳戶✅ 實作認證輪換排程 (每季或每保單)
整合 | 服務帳戶✅ 透過「事件監視」監視 API 異常用量模式
整合 | 服務帳戶✅ 每個整合都有具有最低必要權限的專屬服務帳戶 (未共用具有寬存取權的整合使用者)
整合 | 服務帳戶✅ 服務帳戶會嚴格套用最低權限,因為其作業時無人出席

反模式

要尋找的位置看起來怎麼壞
平台 | 組織⚡️ 未識別、追蹤或分類重要影響帳戶 (管理員、整合、自動化)
平台 | 組織⚡️ 系統管理員使用 SMS 型 MFA,而非硬體安全性金鑰或驗證器應用程式
平台 | 組織⚡️ 重要影響帳戶沒有登入時數或 IP 限制
平台 | 組織⚡️ 未針對特權帳戶的登入或權限變更設定警示
平台 | 組織⚡️ 重要影響帳戶存取權永遠不會不定期檢閱或檢閱 (非每季)
平台 | 組織⚡️ 沒有緊急存取的斷玻璃程序
整合 | 服務帳戶⚡️ 透過「修改所有資料」權限,在多個整合之間共用單一「API 使用者」帳戶
整合 | 服務帳戶⚡️ 服務帳戶在 OAuth 可用時使用使用者名稱密碼驗證
整合 | 服務帳戶⚡️ 服務帳戶認證使用多年未變更的靜態密碼 (無輪替)
整合 | 服務帳戶⚡️ 服務帳戶具有超出整合所需的權限
整合 | 服務帳戶⚡️ 不會監視服務帳戶的 API 用量異常模式

模式

要尋找的位置良好的外觀
平台 | 程序✅ 身分生命週期包括:佈建 (使用基準存取權建立)、存取權調整 (在角色變更時授與/撤銷)、定期重新認證 (每季驗證)、扣除 (立即撤銷)
平台 | 組織✅ 針對身分提供者的自動佈建實作 SCIM (跨網域身分管理系統)
平台 | 程序✅ 佈建會建立具有基準存取權比對工作函數的帳戶,由 HR 系統事件觸發
平台 | 程序✅ 存取調整會在角色展開時授與額外權限,並在角色變更時撤銷權限
平台 | 程序✅ 每季會進行定期重新認證,經理可在其中檢閱並驗證小組的存取權
平台 | 程序✅ 當雇用結束或角色不再需要 Salesforce 時,淘汰會立即撤銷存取權
平台 | 組織✅ 自動偵測可識別未在 90 天內登入的使用者,並觸發存取審查工作流程
平台 | 組織✅ 及時 (JIT) 佈建會在適當時自動從 SSO 建立使用者

反模式

要尋找的位置看起來怎麼壞
平台 | 組織⚡️ 儘管有身分提供者整合,仍未實作 SCIM 佈建
平台 | 程序⚡️ 無需標準上線程序即可手動建立新使用者
平台 | 程序⚡️ 初始使用者存取權不一致或以複製現有使用者為基礎
平台 | 程序⚡️ 角色變更或轉移的存取權變更延遲或不完整
平台 | 程序⚡️ 離職延遲;前員工在終止後保留存取權 (非同一天停用)
平台 | 組織⚡️ 使用者提供沒有自動化 (僅限手動使用者建立)
平台 | 程序⚡️ 沒有存取權重新認證行銷活動存在 (沒有每季或年度審查)
平台 | 程序⚡️ 重新認證期間識別的非必要存取權不會移除
平台 | 程序⚡️ 對於特權帳戶、跨組織存取權、外部使用者而言,重新認證不嚴格
平台 | 組織⚡️ 靜態帳戶 (在 90+ 天內未登入) 會在未檢閱或停用的情況下累積