--- schema_version: "1" id: 42921ffafc9619ec3db410b343b3f23cfbabe14b339dab9497262963fcf13d27 title: 身分與存取管理 - 模式 collection: architect version: current locale: zh-tw portal_url: https://docs.salesforce.com/architect/current/zh-tw/well-architected/guides/trust-identity-access-patterns.md canonical_url: https://architect.salesforce.com/docs/architect/zh-tw/well-architected/guide/trust-identity-access-patterns.html source_site: architect.salesforce.com content_type: documentation content_hash: ff24e1bd2f0a3904d8b9508a720be851da9e12a069f1473696d85ae815fe0279 products: - 結構良好的架構 - Architect Site Content Repo --- # 身分與存取管理 - 模式
深入瞭解良好結構的 [Trust](/docs/architect/zh-tw/well-architected/guide/trust.html) → [Identity and Access Management](/docs/architect/zh-tw/well-architected/guide/trust.html#identity-and-access-management) ## 身分為主要邊界 **模式** | 要尋找的位置 | 良好的外觀 | | --- | --- | | 平台 \| 結構 | ✅ 無論網路位置或裝置為何,存取控制都會在每個要求上明確驗證身分 | | 平台 \| 結構 | ✅ 以身分為基礎的安全性控制會取代以網路為基礎的 Trust 假設 | | 平台 \| 組織 | ✅ 存取決策會考量誰要求存取權 (驗證)、他們獲授權執行的動作 (授權),以及內容 (裝置、位置) | | 平台 \| 文件 | ✅ 安全性結構會將身分記錄為主要 Trust 邊界,而非網路邊界 | **反模式** | 要尋找的位置 | 看起來怎麼壞 | | --- | --- | | 平台 \| 結構 | ⚡️ 公司網路或 VPN 上的使用者會被認為值得信任,並僅根據網路位置獲得更廣泛的存取權 | | 平台 \| 結構 | ⚡️ 存取控制依賴網路周邊,而非身分驗證 | | 平台 \| 組織 | ⚡️ 存取決策不會考量內容訊號 (裝置、位置、時間、行為模式) | | 平台 \| 文件 | ⚡️ 安全性結構會將網路位置視為主要 Trust 邊界 | ## Salesforce 四層存取模型 **模式** | 要尋找的位置 | 良好的外觀 | | --- | --- | | 平台 \| 組織 | ✅ 解決方案利用所有四個 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 | ⚡️ 共用關鍵字使用不一致或完全不使用 | | 平台 \| 設計標準 | ⚡️ 未清楚記錄授與增強權限的使用個案 | ## 以屬性為基礎的存取控制 (ABAC) 和 Data 360 **模式** | 要尋找的位置 | 良好的外觀 | | --- | --- | | 平台 \| 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+ 天內未登入) 會在未檢閱或停用的情況下累積 |