Salesforce Data 360 會改變企業如何大規模連線、協調和啟用客戶資料。然而,其真正的優勢在於管理整個生命週期資料的安全性。此安全性參考結構提供保護 Data 360 環境的實際端對端藍圖。我們透過最低權限、零 Trust 設計和預設治理的核心原則達成此目標。 在其基礎上,Data 360 中的安全性是共用的責任模型。Salesforce 使用 ISO 27001、SOC 2 和「一般資料保護規則」(GDPR) 等全球標準來保護基礎架構、網路、加密服務、平台、合規性和應用程式本身。Salesforce 管理員透過定義存取權、強制執行隱私權和管理整合,以保護其組織在平台內的資料。這包括實作僅授與必要存取權的強式身分與存取管理 (IAM),強制執行雙因素驗證 (2FA),並遵循最低權限原則和企業與法規要求。 Data 360 Governance 可將這些層級的責任連結在一起,確保安全性和合規性保持一致。其可確保在整個流程中定義角色、原則、權限和資料處理規則,並持續強制執行,從取用到啟用。資料歷程、中繼資料分類和同意感知內建於每個物件和流程中。這會將監管從手動監督功能轉換為作業控制平面。 Salesforce 提供彈性的合規基礎,企業可在此基礎上保留其資料狀態、隱私權設定和整合界限的完整權限。他們共同建立安全性和管治架構,讓每個資料集、原則和使用者動作都可追蹤、一致且固定在 Trust 中。 Data 360 中的安全性超出靜態控制。其會內嵌在資料生命週期的每個階段中。從取用資料開始,系統便會根據企業原則加密、驗證和分類資料。統一並豐富後,會維護中繼資料歷程和同意屬性以確保負責。當針對業務或 AI 使用啟用洞察時,輸出流程會透過加密管道、強式驗證和授權、原則認知的管理和同意強制執行來受到保護,以確保資料從取用到啟用都保持值得信任、合規且安全。

Salesforce Data 360 是完全以 Salesforce Hyperforce 結構為基礎的雲端原生資料平台,為全域作業提供安全、相容且可調整的基礎。

• Hyperforce 會以內建功能提供安全性和合規性,而非附加元件。其提供一組通用的基礎控制項,這些控制項深度整合 Salesforce 平台與應用程式,確保從基礎結構到應用程式體驗的每個層級都以安全性、隱私權與合規性為核心設計。
• Data 360 會直接從 Hyperforce 的基礎控制繼承強大的存取控制、加密和法規合規架構。
• 此預設的安全模型可將漏洞降到最低,並簡化提供信任且合規的資料服務。

• Data 360 會在 Hyperforce (統一的雲端平台) 之上主控的專屬功能網域中執行,以確保隔離、效能和多租戶安全性。
• Data 360 使用微型服務結構,所有服務都會透過 Kubernetes 進行容器化和協調流程。
• Istio 服務網格套用零Trust的原則,可管理安全的服務間通訊,並提供流量管理、可觀察性和保單強制執行。

• Data 360 服務已佈建並使用 Salesforce 受管理的虛擬私人雲端 (VPC) 作業,以啟用區隔、有效控制和最佳化內部網路。
• 此結構支援水平延展性,確保 Data 360 可以處理位元組大小的資料處理工作量。

• Data 360 會顯示可與 Salesforce CRM 應用程式和其他資料來源整合的精確定義 API。
• 其支援第一方 (1P) 和以 Hyperforce 為基礎的 Salesforce CRM 組織,以確保跨環境的廣泛相容性。
• Data Cloud One 可讓客戶將多個 Salesforce CRM 組織與單一 Data 360 例項連線。

Salesforce Data 360 中的安全性在 共用責任模型下運作,此架構也是主要雲端提供者 (例如 Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud) 所使用。 此模型定義明確的邊界 負責雲端安全**,客戶負責雲端安全。**瞭解和運作此區別對於維護彈性、合規性和安全資料生態系統而言至關重要。

Salesforce 負責保護及維護 Data 360 平台及其全域基礎結構的完整性。包括:

• **實體與環境安全性:**Hyperforce 託管在 AWS 基礎結構上,Amazon 會透過存取控制、監視和環境保護來委派其全球資料中心的保護責任。
• **網路和邊界防禦:**針對傳輸中 (TLS 1.2 及以上) 和靜態 (AES-256) 的所有流量,散佈式拒絕服務 (DDoS) 緩解、入侵偵測和加密。
• **平台強化與修補程式管理:**持續漏洞管理、修補程式部署和作業系統層級安全性基準。
• **規範與認證:**根據如 SOC 1/2/3、ISO 27001、ISO 27017、ISO 27018 等標準進行持續稽核,以及針對 GDPR 等架構做好準備。 這些控制項可確保 Data 360 平台保持安全、可靠且符合規範,讓客戶專注於業務邏輯和資料管理,而非基礎結構防禦。

客戶負責保護其 Salesforce Data 360 組織內的資料、組態和作業流程。責任的重要領域包括:

• **身分與存取管理 (IAM):**定義角色、強制執行多因素驗證 (MFA) 和單一登入 (SSO),並套用最低權限原則。
• **資料管理:**分類敏感資料、在需要時套用遮蔽,並強制執行物件、欄位和記錄級存取控制。
• **整合安全性:**使用已命名認證和外部認證,透過 OAuth 2.0、JSON Web 權杖 JWT 和其他驗證標準管理 API 存取。
• **監視與回應:**使用事件監視和稽核追蹤,並將記錄轉送至安全性資訊和事件管理 (SIEM) 系統以進行進階威脅偵測。 Salesforce 提供安全的基礎,但客戶可透過其組態、控制和警覺來決定其實際的安全狀態。

安全性不只是技術建構,也是組織規範。Salesforce Data 360 中的資料保護可透過結構、作業和管治小組的協同合作來達成。 企業應:

• 持續檢閱並淘汰未使用或過度特權的帳戶。
• 使用程式碼和 CI/CD 管道等原則自動執行強制執行。
• 執行桌面演練,模擬事件,例如未經授權的資料啟用或洩漏,以增強回應整備。 Data 360 的效率並非僅依功能而定,而是依客戶負責執行功能的方式來調整。

Salesforce Data 360 採用安全依預設的哲學,其是從反應性控制移至預防性設計。每個新的 Data 360 組織現在都會以「全部拒絕」狀態開始,從第一個部署強制執行零 Trust 原則。

在較舊的環境中,客戶繼承了權限的「允許所有」模式,以加速上線。雖然方便,但這會造成意外過度曝光和設定錯誤的風險。 新的安全依預設結構會反轉此方法:

• 沒有任何使用者或系統具有隱含存取權。
• 必須明確授與所有權限。
• 從第 0 天強制執行資料存取、整合與管治控制。 這會透過設計強制執行最低權限,大幅降低意外曝光或權限升級的風險。

此模型具有技術與行為影響:

• 小組必須刻意規劃存取模型,使權限與合規性和業務界限保持一致。
• 監管會成為內建的設計需求,而不是後續的考量。
• 從一開始就定義資料的擁有權與責任。 針對仍在「全部允許」下運作的舊版 Data 360 組織,管理員必須手動縮小組態以符合新的基準,這是任何安全性現代化或 Data 360 成熟度計畫中的關鍵步驟。

透過預設為零存取權並要求明確的原則定義,Salesforce Data 360 建立Trust依據設計,這是企業資料安全性的基礎演進。 此方法可確保:

• 將未經授權的存取與資料洩漏風險降到最低。
• 會以結構方式強制執行監管架構,而非選擇性執行。
• 企業可在環境之間取得更可預測、更可稽核且更具彈性的安全性狀態。 基本上,安全性不再是您新增的功能。這是您從中開始的基礎。

Salesforce Data 360 中的身分與存取管理 (IAM) 是第一個且最重要的防禦層。它會管理可以存取平台的人員,以及他們可以在內部執行哪些動作。實作良好的 IAM 架構是企業可保護其客戶資料並確保營運完整性的單一最強大控制項。

驗證會建立 **數位 Trust,**確認存取 Salesforce Data 360 的每個使用者、服務或外部系統都是合法的。

Data 360 支援使用 SAML 2.0、OpenID Connect (OIDC) 或跨網域身分管理 (SCIM) 系統等企業級身分提供者 (IdP) 的 聯合驗證,例如 Microsoft Entra ID (Azure AD)、Okta 或 Ping Identity。 此聯合會將您的公司身分生命週期直接延伸至 Salesforce。當員工加入、轉移或離開公司時,其存取權會自動調整,進而減少孤立帳戶並改善合規性整備。

透過 單一登入 (SSO),使用者可以使用其公司認證進行一次驗證,並取得 Salesforce 應用程式的安全存取權,而無須使用個別密碼。這可減少認證疲勞,並將密碼重複使用或網路釣魚的風險降到最低。

身分提供者 (IdP) 會成為驗證決策的單一授權機構,強制執行多因素驗證 (MFA)、條件式存取和以風險為基礎的控制。驗證會從單一事件進化為持續評估 Trust,並根據使用者行為和內容進行回應。 聯合驗證提供:

• **集中強制執行原則:**系統會在所有 Salesforce 環境之間的一個位置管理驗證標準。
• 端對端可追溯性:「統一稽核」追蹤會將每個動作連結回已驗證的身分。
• **以人為本的體驗:**無縫且安全的登入流程可讓小組專注於洞察,而非認證。

使用者驗證後,授權會定義他們可以存取、檢視或修改的內容。它會設定保護敏感資料並強制執行最低權限的作業邊界。 **最低權限原則 (PoLP):**每個使用者和系統只會獲得其工作功能所需的權限,而不會獲得任何權限。此原則會大幅限制認證遭入侵或設定錯誤所造成的潛在損害。 **以角色為基礎的存取控制 (RBAC):**Salesforce Data 360 使用權限集和權限集群組來指派符合業務角色的細微功能。例如:

• 「資料工程師」可在 Data 360 結構設計師權限集的協助之下,管理取用管道和轉換。
• 「行銷分析師」可在「Data 360 啟用管理員」權限集的協助下查詢協調資料,但無法變更模型。
• 「啟用管理員」可以執行輸出行銷活動,但無法透過「Data 360 啟用管理員」權限集的協助存取來源資料 存取權會集中管理且可稽核,以確保在整個資料生命週期中擁有責任。當與如 Entra ID、Okta 或 Ping Identity 等 IdP 整合時,存取原則會透過 SCIM 佈建和 SAML/SSO 聯邦順暢地延伸至整個企業。

Salesforce 提供預先定義的權限集,這些權限集會壓縮職責分隔和符合如 ISO 27001 等產業標準的最佳作法。

此結構權限分隔可確保沒有單一角色可控制整個資料生命週期,並符合如 ISO 27001 和 SOC 2 等架構中的職務分隔 (SoD) 需求。 當新功能可用時,每個版本都會自動更新 Data 360 標準權限集。相較之下,自訂權限集不會自動更新,否則會導致潛在的安全性漏洞或功能遺失。

• **自動保單演進:**Salesforce 會維護並更新標準權限集作為其平台版本的一部分。導入新功能時,權限集會自動對齊,減少管理額外負擔並消除組態漂移。
• **減少的攻擊面積:**細微的存取限制可防止資料錯誤使用或不小心升級權限。
• **稽核與合規性整備:**標準化角色可簡化證明,讓企業在稽核或法規審查期間更容易示範存取控制。
• **可調整的管理:**管理員可以使用 SCIM 佈建和 SAML/SSO 聯邦,將這些角色直接對應至企業 IAM 系統,例如 Okta 和 Microsoft Entra ID,以確保整個 Data 360 和整個企業生態系統的統一安全性狀態。

• **採用標準角色:**使用 Salesforce 的標準權限集,而非複製或自訂,以確保在版本之間自動更新和一致的權限模型
• **與 Enterprise IAM 整合:**透過 SCIM 或身分聯合集中提供存取權,以維持所有身分的可視性和生命週期控制。
• **定期執行存取審查:**實作定期憑證流程以偵測權限流失,並確保符合功能需求。
• **套用及時存取權:**針對增強功能,請根據零 Trust 原則,授與自動到期的暫時權限。 IAM 是將人類身分、系統存取與資料管理連結的控制平面。Salesforce Data 360 為企業提供透過聯合驗證、細微授權和持續發展的權限模型,強制執行 Zero Trust 的工具。但其真正的成效取決於組織如何運作這些控制項—將人員、流程和技術與一個目標保持一致:資料 Trust 無需妥協。

在今天的企業資料生態系統中,監管不再是限制因素,而是可信任情報的關鍵啟用因素。針對結構設計師,其會定義敏捷性和控制、開放式存取權與保證合規性的平衡。 Salesforce Data 360 (Data 360) 的設計核心為此原則。「管治」與 Trust 不會以多個層級新增,而是內建在結構的結構內。資料生命週期的每個階段皆會在統一的管治控制平面下運作,此控制平面定義企業中如何分類、保護、存取及負責使用資料。

Data 360 是根據監管優先的模型所建立,可確保每個資料互動皆符合原則、可稽核且符合,從採取到洞察啟用。管治會作為中心控制層級,管理在整個生命週期中如何探索、分類和保護資料。 此統一控制平面可確保:

• 資料存取權會根據內容授權:只有正確的使用者可以根據正確的原則對正確的資料採取動作。
• 管治內嵌在語意與作業層中,可確保資料建模方式與保護方式之間的一致性。
• 強制執行「零信任」與「最低權限」原則:在授與存取權之前即時評估身分、內容和原則。 透過此結構,Salesforce Data 360 會將管理從靜態權限管理轉換為動態、原則驅動的協調流程層。一種可持續適應內容、透過設計強制執行合規性,並在企業規模維持 Trust。

在巨集層級,資料空間提供企業資料網域的邏輯區隔與隔離,讓具有多品牌、多區域或多租戶作業模型的組織能夠在單一統一平台內管理資料。資料空間可與業務領域 (例如「銷售」、「行銷」或「客戶成功」) 或法規與地理邊界 (例如歐盟、美洲或亞太地區) 保持一致,讓管治與存取控制能夠反映組織的營運與合規結構,而無須分割基本資料平台。

• 每個資料空間都會作為虛擬邊界,定義使用者或小組可以看見或互動的資料集合。
• 系統會明確授與資料空間內的存取權,以確保沒有資料可視性的隱含權限或交叉污染。
• 這可啟用聯合擁有權:每個業務單位可獨立管理其領域,同時維持集中監督與合規。 透過設計,資料空間提供第一層的管治,建立企業資料集的結構清晰度和責任性。 <img style="border:1px solid #e5e5e5;margin:2rem 0rem"

src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_security_architecture/data_360_dataspace.png" alt="Data 360 資料空間" />

在 Salesforce Data 360 中,RBAC 和 ABAC 具有不同的但互補的用途,且會套用至平台的不同層級。 RBAC 主要用於平台和功能存取。它會管理可存取 Data 360 建構和功能 (例如資料空間、流程建立、管理功能和工具存取權) 的使用者。RBAC 透過權限和權限集實作,例如透過特定已啟用功能指派使用者對「資料空間」的存取權。 ABAC 用於強制執行資料存取。ABAC 原則完全負責決定可以存取哪些資料物件和屬性,包括物件級安全性 (OLS)、欄位級存取權和列層級限制。這些決策是在執行階段透過評估動作、使用者屬性和資源屬性來動態做出。 在 ABAC 中,權限會保持為模型的一部分,但原則本身會決定存取權,而非僅限角色。原則會評估內容,例如業務單位、區域、資料敏感度、用途或允許或拒絕存取的法規限制。 例如:

• RBAC 可讓使用者存取 Data 360 資料空間與分析功能。
• ABAC 會決定同一位使用者是否可以讀取特定客戶資料集、他們可以看見哪些列,以及哪些屬性會遭到遮蔽或限制。 此清除區隔可讓 Data 360 安全地調整規模:
• RBAC 提供平台功能與工作流程的控制存取權。
• ABAC 提供精細的原則驅動資料存取權,並符合規範、落地與資料保護需求。 這些動作會共同啟用受管理的資料民主化,而不會將平台權限與資料授權邏輯混合。 基本上,RBAC 會根據權限指派強制執行存取權,而 ABAC 會在內容中評估權限—結合動作、使用者和資源屬性,在整個 Salesforce Data 360 中提供自適應且精細的存取控制

Salesforce Data 360 的精細存取控制中心是以屬性為基礎的存取控制 (ABAC),其由 CEDAR 原則語言提供技術支援。 不同於靜態以角色為基礎的權限,ABAC 會動態評估 誰 要求存取權、他們嘗試存取的 內容,以及 在哪些情況 下—確保每個資料互動皆符合企業原則和信任界限。

Data 360 的 ABAC 引擎會根據三個核心屬性類型的組合評估存取決策:

• **使用者屬性:**部門、位置、排放層級
• **資料屬性:**分類、敏感度 (PII、PHI、財務資料)、資料空間 此彈性原則驅動的模型可讓強制執行會隨著使用者角色、資料分類或營運條件的演變自動調整,這對於大型、分散式和受監管的企業而言至關重要。 <img style="border:1px solid #e5e5e5;margin:2rem 0rem"

src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_security_architecture/attribute_based_access_control.png" alt="以屬性為基礎的原則控制" />

Salesforce Data 360 會實作標準型「屬性型存取控制」(ABAC) 結構,並與行業最佳作法保持一致,以進行原則驅動的資料管理。其由三個主要功能元件所組成:

• 原則資訊點 (PIP) - 原則、增強型中繼資料和分類:
• 包含原則定義本身,包括管理企業資料的資料存取、分類、遮蔽、保留和使用原則。
• 維護豐富的中繼資料,例如標記、分類、業務內容和端對端歷程。
• 使用 LLM 和 ML 驅動分類來自動標記敏感資料 (例如 PII.Email、PII.Phone、PHI)。
• 標記傳播可確保分類在資料歷程 (DLO → DLO → DMO) 中自動流動。
• 在整個轉換中保留敏感性和合規性。
• 原則決策點 (PDP) 是解讀 CEDAR 原則的決策引擎。
• 從 PEP (使用者身分、要求中繼資料) 和 PIP 參照屬性中取用內容輸入。
• 以決定性方式評估原則,以提供一致、可解釋且可調整的存取決策。
• 支援即時與批次評估,即使在大量環境中也能確保效能與精確度。
• 原則執行點 (PEP) 是執行階段強制執行授權決策的位置。
• 攔截所有互動管道的資料存取要求,例如 API、UI 查詢、CRM 增強或 GenAI 尋找增強產生 (RAG) 管道。
• 立即套用 PDP 結果,以確保每個查詢和提取皆符合企業存取原則。 PIP–PDP–PEP triad 會組成分散式監管架構,在所有 Data 360 服務和存取模式之間強制執行一致且以原則為基礎的控制。 請注意,Data 360 中的 ABAC 已設定,非已建立。結構設計師不會組合自訂控制平面或強制執行邏輯。而是會填入並連接三個原生結構元件,這些元件會共同運作為統一的管治架構。 在實際層級,實作遵循簡單的進度:分類資料、定義原則,並讓平台自動強制執行。設定後,存取控制會成為系統行為,而非手動或程序流程。 此分散式管治架構可確保在所有存取管道之間一致強制執行原則,進而在整個 Data 360 中建立統一的 Trust 界限。

Data 360 的 ABAC 架構支援分層存取邊界,確保資料不僅在物件層級受到保護,而且在特定欄位和記錄內受到保護。

• 物件級安全性 (OLS):存取控制的最外部邊界。 管理整個資料結構的存取權,例如資料湖物件 (DLO) 或資料模型物件 (DMO)。 範例:授與 _客戶_物件的存取權,但不授與「_交易」_的存取權。
• 欄位級安全性 (FLS):控制物件內特定欄位的存取權。 範例:行銷使用者可以看見客戶名稱,但受限於檢視信用卡號碼或國家/地區識別碼。
• 記錄級安全性 (RLS):最精確的控制層。 決定使用者可檢視或修改資料集內的個別記錄。 範例:區域經理只能存取與其指派區域繫結的客戶資料。
• **動態資料遮蔽 (DDM):**啟用即時資料保護。補充 ABAC,DDM 會強制執行原則驅動的敏感資訊隱藏,而不會變更基本資料集。在查詢時,DDM 會根據使用者角色、內容或合規性規則自動遮蔽 PII 或財務資料等欄位。
• 敏感資料會在 UI 檢視、API 和 AI 工作流程之間保持受保護。
• 透過確保所有耗用層之間的一致遮蔽來減少資料洩漏風險。
• 維護稽核性。系統會在 Data 360 的管理架構內記錄並追蹤每個遮蔽的查詢。 <img style="border:1px solid #e5e5e5;margin:2rem 0rem"

src="https://a.sfdcstatic.com/developer-website/prod/images/architect/data_360_security_architecture/attribute_based_access_control_in_action.png" alt="動作中以屬性為基礎的原則控制" />

此結構會將存取控制從靜態權限模型轉換為動態且感知內容的原則結構。透過將 RBAC 的結構化簡單度與 ABAC 的內容深度結合,Salesforce Data 360 可達成:

• 在整個採取、調和和啟用之間一致強制執行原則。
• 根據資料、角色和合規性需求而發展的自適應管理。
• 在整個資料生命週期中整合 Trust 界限,從取用到 AI 啟用。

Salesforce Data 360 的監管模型原生內嵌在 Salesforce Platform 中,能夠統一營運與分析資料的安全性、合規性與存取控制。透過繼承 Salesforce 的核心身分識別與存取管理功能 (例如身分識別聯邦、權限集、集中原則編寫和平台加密),Data 360 會在雲端之間套用一致的 Trust 原則,而不會導入並列的管治堆疊。平台不會將隔離、授權和歷程視為個別的問題,而是將這些問題整合到跨越整個資料生命週期的單一認知執行 Trust 架構中。 在結構層級上,此管治架構由三個互補的層所組成:

• 資料空間,可為資料隔離與監管區隔建立明確的邏輯界限
• 以屬性為基礎的存取控制 (ABAC),可根據身分、用途和資料屬性,啟用精細且感知內容的授權決策
• 語意歷程,可在資料從採取移至洞察和啟用時保留業務意義、敏感性和可追溯性 他們共同建立一個可解釋存取決策、自動強制執行,且規範是連續的而非追溯的管治模式。結果是使管治不再是限制因素或後續考慮的平台。而是會變成啟用層,讓結構設計師能夠設計資料產品和 AI 驅動的工作流程,並確信系統本身會強制執行 Trust、隱私權與法規要求。 此組成方法可確保企業資料不僅保持可用性,還能負責任地採取行動—支援大規模洞察、啟用和自動化,而不會影響透明度、安全性或控制。

在 AI 驅動的企業時代,保護資料並非一次性的事件,而是持續的程序,從資訊進入生態系統的那一刻開始,直到資料啟用供業務或 AI 使用為止。 Salesforce Data 360 內嵌在資料生命週期每個階段的安全性與管治控制項,確保資料完整性、機密性與 Trust 皆可保留,無論是從取用到洞察啟用。

Salesforce Data 360 的保護模型核心是 Platform Encryption for Data 360 — 透明且高效能的加密架構,可保護靜態與傳輸中的資料,而不會影響可用性或延展性。

Data 360 Data Lake 中保留的資料會在儲存層級進行自動加密,以確保即使發生實體或未經授權的存取,資料仍無法閱讀。重要功能包括:

• **透明資料湖加密:**系統會使用客戶管理金鑰 (CMK) 在儲存層加密資料湖中存在的所有資料。這可確保即使發生未經授權的實體儲存空間存取,資料仍會保持不可讀和無法解碼。
• **客戶管理金鑰 (CMK):**客戶可完全控制加密金鑰,這是金融服務、醫療照護和政府等受監管產業的重要功能。CMK 可實現細微的資料主權稽核、控制和證明,直接符合 GDPR、HIPAA 和 ISO 27001 等法規要求。
• **外部金鑰管理 (EKM):**透過「外部金鑰管理」,這是 Platform Encryption for Data 360 的功能,客戶將能夠使用儲存在客戶 AWS KMS 帳戶中的金鑰來加密 Data 360 中的資料。這可讓客戶更有彈性,同時確保 Data 360 中的資料安全且受保護。
• **自帶金鑰 (BYOK):**Data 360 現在以 CMK 和 EKM 為基礎,可讓客戶直接在 Salesforce 中上載自己的金鑰資料,以加密靜態資料和搜尋索引。此增強功能針對 PII、敏感、機密和專有資料提供額外一層的保護,而不需要客戶在 AWS KMS 中建立或管理金鑰。
• **金鑰輪換與生命週期管理:**金鑰輪換已妥善處理。新資料會使用新金鑰加密,而舊資料會保持原始金鑰加密,以避免停機或效能降低。此輪換機制可強化合規性,而不會造成營運中斷。

Data 360 服務、API 和連接器之間傳輸的每個資料都會使用「傳輸層安全性」(TLS) 1.2 或更高版本來保護,進而提供端對端加密。 這可確保:

• 在傳輸期間無法攔截或變更資料。
• Salesforce 服務、信任連接器和客戶端點之間的通訊會保持私密且可驗證。
• 安全性會持續延伸至整合管道、調和流程、啟用工作流程和外部 API 整合。 透過結合客戶管理靜態加密與傳輸中的持續加密,Salesforce Data 360 可建立深度防禦結構,以保護客戶資料免受外部攻擊和內部基礎結構威脅。

雖然加密和存取控制會保護 Salesforce Data 360 內的資料,但在整個系統之間安全地移動資料同樣重要。現代企業在多雲與混合式環境中運作,其中敏感資料會在 Salesforce、分析平台、外部 API 和資料湖之間流動。 為了解決此問題,Salesforce 設計了一個以已命名認證 (NC) 和外部認證 (EC) 為中心的安全整合架構,為安全連線提供以原則為導向且符合零 Trust 的基礎。

Salesforce 已建立強大的 安全整合架構,以已命名認證 (NC) 和外部認證 (EC) 為中心。整體,它們會移除認證複雜性、強制執行最低權限存取權,並在所有整合之間啟用一致的驗證管理,而不會在程式碼或組態中顯示密碼。 此架構會抽出安全性複雜性、強制執行最佳作法,並針對所有外部連線建立一個以原則為導向的控制平面,以符合 Salesforce 的 Zero Trust 和 security-by-design 原則。

已命名認證

已命名認證 (NC) 是 Salesforce 安全整合結構的基礎。它們提供定義外部端點及其驗證參數的陳述性集中機制,無須硬式編碼 Apex 程式碼或組態檔案中的使用者名稱、密碼或權杖等敏感認證。開發人員和管理員只需參照已命名認證別名 (例如,SnowflakeConnector_NC),Salesforce 會自動處理基本驗證和連線管理。 結構與安全性優點:

• **簡化維護:**NC 會將外部端點 URL 和驗證參數合併至單一受管理記錄。任何更新 (例如變更端點或輪換認證) 僅需要對 NC 記錄進行變更,以避免在環境之間重新部署程式碼或流程。
• **增強型安全性:**認證會安全地儲存在 Salesforce 的加密密碼存放區中,以避免在程式碼存放庫、組態檔案或記錄中顯示。驗證流程本身會在執行階段自動管理,進而減少人為錯誤和洩漏風險。 **合規性符合度:**將認證與業務邏輯分開可簡化資料保護法規 (例如 GDPR、HIPAA 和 PCI DSS) 的合規性。稽核員可以輕鬆驗證外部資料存取是否遵循企業安全性與管治原則。
• **略過遠端網站設定:**NC 會去除遠端網站設定的舊版需求,簡化組態和部署,特別是大規模或多環境企業實作。

外部認證 (EC) 定義 Salesforce 在連線至外部服務時使用的驗證通訊協定和流程,有效回答「驗證方式」。單一 EC 可在共用相同驗證類型的多個 NC 中重複使用,進而促進組態重複使用和一致的安全性強制執行。 支援的驗證通訊協定:

• OAuth 2.0 (支援所有變體)
• JWT (JSON Web 權杖)
• 基本驗證
• AWS 簽章 v4
• 自訂驗證
• 無驗證 (適用於開放的 API 或公用端點) 外部認證與已命名認證的設計目的為清楚分隔工作。外部認證定義驗證的方式,指定用於連線至外部系統的驗證通訊協定、權杖類型和重新整理行為。另一方面,「已命名認證」會定義要連線的位置—端點 URL,以及要用於該連線的「外部認證」。此設計可確保驗證邏輯與端點組態保持分離,讓 Salesforce 能夠安全地支援多元整合通訊協定,同時在整個企業中維持集中且一致的認證管理。

雖然 Data 360 的使用者介面會抽出大部分的基礎組態,但其原生連接器和資料串流經常利用「已命名認證和外部認證」架構。這表示,即使管理員透過引導式 UI 簡單地「新增資料連線」,Data 360 仍在背景中套用此標準化安全性模型。 結構影響:

• **統一安全性模型:**無論連線至外部資料庫、AWS S3 或企業 API,每個連接器都會受益於「已命名」和「外部認證」強制執行的相同加密、驗證和金鑰管理標準。
• **開發人員摘要:**開發人員與管理員無須手動處理驗證流程或認證輪替。Salesforce 會自動管理權杖生命週期、到期與重新整理。
• **一致的保單強制執行:**此架構可確保所有連接器皆遵循一致的驗證、稽核和記錄原則,這對於受監管產業中大規模的多來源摘要而言至關重要。
• **未來的擴充性:**隨著 Salesforce 增強其驗證堆疊 (例如,支援新的 OAuth 流程或 FIDO2 標準),這些改善會自動在所有連接器之間移入,而不需要重新產生或重新部署。

Salesforce Data 360 提供大量立即可用的連接器,可簡化來自各種來源的資料整合。這可讓企業有效率地合併和利用其資料。Salesforce 提供多種連接器類型,包括原生 Salesforce 連接器、雲端儲存連接器、資料庫連接器,以及應用程式和 API 連接器。除了提供的連接器外,也支援零 ETL 工具。Salesforce 連接器可讓 Salesforce 產品 (例如 Sales Cloud、Service Cloud 和 Marketing Cloud) 與 Data 360 順暢整合。此外,提供與雲端儲存體提供者的各種連接器,包括 Amazon S3、Google Cloud Storage 和 Azure Data Lake。Snowflake、Redshift 和 BigQuery 等資料庫的預先建置連接器可讓企業將現有的資料倉庫與 Data 360 連結。此外,Data 360 為各種第三方應用程式和 API (例如 Google 廣告、Facebook 廣告和其他行銷平台) 提供連接器。為了增強彈性,Data 360 會與如 MuleSoft 和 Informatica 等 ETL 工具整合。

儲存在 Salesforce Data 360 中的資料安全性一直是許多 Data 360 相關對話的重點。作為 Salesforce 對深度防護安全性方法的承諾的一部分,同等重要性重點在於確保資料如何提取至 Data 360 環境。 Salesforce 瞭解企業在多元化的資料生態系統中運作,經常跨越多個雲端平台、儲存解決方案和分析工具。我們的 Data 360 連接器可作為這些環境之間的橋樑。連接器可實現安全、可調整且有效率的資料整合,同時維持 Salesforce 的高安全性標準。這些連接器可協助流程順暢,而不會影響完整性或隱私權。 Data 360 連接器安全性的三個基本元件有:

• 驗證/授權對應:安全存取管理是資料安全性的基礎。不同的雲端連接器會使用不同的驗證和授權機制來驗證和控制使用者存取權。驗證可確保使用者或系統是合法的實體,而授權則可定義授與的存取層級。Salesforce 盡可能確保其連接器符合產業標準。
• 零複製 (ZETL) 功能的互通性:資料重複會造成安全性和營運挑戰。這也會產生不必要的儲存成本、資料不一致,以及增加的風險曝光。Salesforce 的 Zero Extract、Transform 與 Load (ZETL) 方法可確保跨平台進行即時資料共用,而不需要實體資料複製。這表示資料可以保留在其原始環境中,同時仍可供處理、報告和分析使用。此外,這也會大幅減少攻擊面積,並增強對資料落地法律的潛在合規性。
• 資料聯合支援:在今天的多雲環境中,組織需要全方位的資料存取權,而不需要不必要的資料移動。Data 360 連接器聯合資料模型支援檔案型和查詢型資料聯合,讓企業能夠即時利用外部資料來源。無論是存取結構化資料庫、半結構化記錄或非結構化檔案,Salesforce 的連接器都能確保資料在整個生命週期中保持安全。 Salesforce 旨在為客戶提供所需的透明度,以協助其瀏覽資料安全性和合規性的複雜性,即使是我們的整合也是如此。無論是與 AWS S3、Google Cloud Storage、Snowflake 或其他平台整合,我們的 Data 360 連接器都專為確保重要業務資料的Trust、透明度和控制而設計。

Salesforce Data 360 連接器安全性與驗證對應

資料生命週期的最後階段—資料啟用—是將 Salesforce Data 360 內統一且豐富的客戶設定檔安全地散佈至下游應用程式的外部系統,例如個人化行銷、分析或參與協調流程。 此階段代表從「洞察」轉換為「動作」,因此負責維護資料完整性、隱私權合規性和 Trust。

保護輸出資料傳輸

Data 360 透過受管理的加密路徑強制執行安全的輸出連線。所有啟用目標 (無論是 SFTP、Amazon S3、Microsoft Azure Blob、Google Cloud Storage 或廣告網路) 都必須使用透過 Salesforce 的「已命名認證」和「外部認證」架構進行驗證的安全連線定義來進行設定,以確保不以純文字顯示任何認證或端點。 結構安全性控制:

• **加密管道:**所有輸出資料傳輸都會透過 TLS 加密的管道進行,以確保傳輸的機密性和完整性。
• **認證抽取:**輸出端點使用「已命名認證」,利用 Salesforce 的加密密碼存放區和所有 API 金鑰和驗證權杖的集中管理。 這可防止在組態檔案或流程定義中顯示敏感詳細資料。
• **存取管理:**啟用目標可以繫結至具有範圍權限的特定整合使用者,為輸出事件提供精細的存取控制和完整的稽核性。
• **網路安全性:**針對高度安全環境,輸出連線可限制為「私人連線」連結,以確保資料啟用流量保留在私人 AWS 或 Azure 網路內,而非周遊公用網際網路。

Data 360 啟用流程

Data 360 中的安全性超出技術控制,以包含認知原則的管理。啟用時,Salesforce 的 Data 360 Trust 圖層會自動強制執行客戶同意與隱私權原則,以確保只與外部目的地共用符合資格的資料。 關鍵功能:

• 同意感知資料流程 360 會在啟用資料前評估同意標記,例如「請勿共用」、「請勿銷售」或「電子郵件取消選取」。違反這些同意條件的記錄會自動從輸出資料集中排除。
• 法規對齊方式:這些原則強制執行會與全球隱私權架構 (包括 GDPR、CCPA 和 HIPAA) 保持一致,將合規性直接內嵌在資料啟用流程中,而非依賴下游強制執行。
• 自動化歷程和稽核:系統會使用完整的資料歷程中繼資料來記錄每個輸出啟用事件,包括來源 DMO、同意狀態和目的地詳細資料。這可針對監管機構或內部管治小組啟用稽核準備報告。 Salesforce Data 360 內嵌在整個資料生命週期中的安全性、管治與隱私權控制項,可確保客戶資料在每個階段都保持加密、符合原則並信任。Data 360 透過統一「平台加密」、「已命名和外部認證」和感知同意的啟用,提供端對端 Zero Trust 結構,可從來源到業務啟用保護資料完整性、機密性和合規性。

針對許多注意安全性的企業,尤其是受監管產業和公共部門的企業,網際網路受限制的資料環境是其合規性和網路安全策略的核心元件。雖然此種區隔可將外部曝光降到最低,但也會對 Salesforce Data 360 和 Agentforce 帶來整合挑戰,這需要對客戶管理的資料湖進行安全存取。 大多數企業資料湖位於超大規模平台,例如 AWS、Microsoft Azure 或 Google Cloud。由於 Salesforce Data 360 可在 AWS 基礎結構上作業,因此若要安全連線至其他雲端上主控的客戶環境,則需要略過公用網際網路的私人跨雲端網路路徑。

Data 360 透過 AWS PrivateLink 提供私人雲內連線,可在 Data 360 和客戶管理的資料來源之間啟用安全直接存取,包括如 Snowflake (在 AWS 上主控)、Redshift 或 S3 等服務,而無須將流量公開至公用網際網路。 所有通訊都會保留在 AWS 架構內,使用私人 IP 位址和非可建立路線的網路路徑,從而消除傳輸中資料遭到截斷的風險,並符合嚴格的企業與法規安全性需求。 此結構可確保:

• **零網際網路曝光:**資料永不離開 AWS 私人網路。
• **私人 IP 通訊:**流量會保持隔離,且無法在外部處理。
• **合規對齊方式:**符合如 ISO 27001、SOC 2 和 FedRAMP 等安全性標準。

為了支援在多雲端環境中作業的客戶,Salesforce 透過「私人互連」,將相同的安全性原則延伸至 AWS 之外。此功能可在 Data 360 與在 Azure 或 Google Cloud 中主控的資料湖之間啟用跨雲端私人連線,維持私人路由、零網際網路周遊和僅限加密支柱流量的相同保證。 有兩種結構部署模型可供使用:

• **客戶管理的互連:**客戶可將其現有的私人網路電路 (例如 Azure ExpressRoute、Google Cloud Interconnect 或 Equinix Fabric) 直接與 Data 360 VPC 整合。
• **Salesforce 受管理的互連:**Salesforce 會佈建和管理跨雲端連結,以在客戶的目標雲端環境中公開專用服務端點,以進行整備式設定。

Salesforce Data 360 是統一企業資料的強大平台,內建強大且多層級的安全性控制項。針對客戶,管理 API 安全性是全方位資料保護策略的重要部分,讓客戶能夠有效控制存取、管理整合和監視使用狀況。 以下是客戶可在 Salesforce Data 360 內設定、控制和管理 API 安全性的主要功能與功能。

客戶可以利用數個內建的 Salesforce 功能來確保對其 Data 360 例項的 API 安全存取權:

1.強大的驗證和授權 (OAuth 2.0)

Salesforce 要求對其 Data 360 API 進行嚴格驗證,且 OAuth 2.0 是標準和建議通訊協定。

• 連線的應用程式:客戶建立和設定「連線的應用程式」以管理外部應用程式存取。這是驗證和授與 Data 360 取用和查詢 API 存取權的主要機制。
• OAuth 範圍:管理員可以定義特定的 OAuth 範圍 (例如 cdp_ingest_api、api),以要求最低必要權限,並遵循最低權限原則。
• 多因素驗證 (MFA):您可以強制執行 Salesforce Authenticator 和其他 MFA 解決方案,進而增加重要的安全性層級,並確保只有已驗證的使用者可以存取系統,包括透過 API 登入。

2.細微存取控制與權限

客戶可以精細地控制哪些使用者和應用程式可以存取資料,以及他們可以執行的動作。

• API 存取控制 (功能):此功能由 Salesforce 支援啟用後,可讓管理員明確批准可用於存取 API 的連線應用程式。系統會自動封鎖所有未批准的應用程式,大幅減少未經授權的資料解壓風險。
• 權限集與設定檔:管理員透過使用者設定檔或專屬權限集指派「已啟用 API」權限來管理 API 存取權。這可確保使用者僅擁有與其工作功能相關的存取權。
• 以角色為基礎的存取控制 (RBAC):在 Data 360 中,客戶可以建立和管理以角色為基礎的存取控制原則,以定義資料存取層級 (物件、欄位和記錄級安全性),以確保整個平台的一致性與控制。
• 專屬整合使用者:最佳作法建議為整合建立特定「僅 API」使用者,將其權限限制為僅限於 API 呼叫所需的權限,而非使用系統管理員帳戶。

3.網路安全性控制

• IP 白名單/登入 IP 範圍:客戶可以將 API 存取權限制為已定義的信任 IP 位址範圍。任何來自未批准 IP 範圍的登入嘗試都可遭到拒絕或要求進行驗證。
• 私人連線:此功能建立在 AWS PrivateLink 上,可讓管理員管理敏感資料,而無須將端點公開至公用網際網路,從而消除對公開可見端點的攻擊風險。
• 傳輸和靜態加密:所有資料都會在傳輸 (使用 TLS) 和靜態時加密,以保護敏感資訊免受未經授權的存取,即使遭到攔截也是如此。

4.監視、稽核和監管

可視性是安全性的關鍵。Salesforce 提供監視和稽核 API 活動的廣泛工具。

• 事件監視:提供各種事件的近乎即時追蹤,包括 API 呼叫和登入嘗試。客戶可以使用此資料來稽核和建立交易安全性原則。
• Security Center:此功能提供所有 Salesforce 組織之間安全性狀況、合規性與管治度量的單一合併檢視,以簡化監視與管理。
• 欄位稽核追蹤:協助客戶追蹤登入和欄位歷程記錄、監視設定變更,並處理稽核和資料保留合規義務。
• 資料管理功能:包含資料標記與分類、強制執行原則和動態資料遮蔽,以確保在所有資料接觸點 (包括透過 API 存取的資料接觸點) 中套用一致的管治原則。

1. 啟用核心控制:從啟用組織範圍預設值 (例如 MFA 和 IP 限制) 開始。
2. 要求 API 存取控制:向 Salesforce 支援記錄個案,以在您的組織中啟用「API 存取控制」功能。
3. 設定連線的應用程式:為每個整合建立特定連線的應用程式,定義必要的 OAuth 範圍,並將其指派給授權的設定檔/權限集。
4. 實作最低權限:確定所有整合使用者都有「僅 API」權限和最少的資料存取權。
5. 監視和稽核:定期使用「事件監視與安全性中心」檢閱 API 用量、偵測異常,並執行漏洞評估。
6. 強制執行最佳作法:一律強制執行 TLS、安全地儲存重新整理權杖、輪替工作階段識別碼,以及驗證資料輸入。 透過利用這些強大的客戶可設定的功能,企業可以為 Salesforce Data 360 內的所有 API 互動維護安全且符合的環境。

Salesforce Data 360 的設計目的為透過其地理散佈的部署模型,滿足全球資料落地與主權需求。此服務目前適用於多個受監管區域,包括美國、加拿大、巴西、德國、印度、澳大利亞和日本。 資料落地是透過將每個客戶的「核心組織」例項對應至最近對應的 Data 360 區域例項來決定。例如,位於美國或加拿大的核心組織會與美國區域內的 Data 360 例項配對,而歐盟內的核心組織會對應至德國主控的例項。同樣地,印度、澳大利亞、紐西蘭或新加坡的核心組織與在印度主控的 Data 360 例項相關聯。 Salesforce 的 Hyperforce 基礎結構是此模型的基礎,為地理資料控制、安全性隔離和法規合規提供基礎。Hyperforce 可確保客戶資料 (包括中繼資料、備份和衍生的資料集) 保持在定義的區域界限內。此架構可讓企業符合當地資料落地與合規性要求,例如 GDPR、FFIEC、HIPAA 及 APAC 與 EMEA 區域隱私權法規。 Salesforce 持續將 Data 360 的可用性擴展至其他 Hyperforce 區域,以符合不斷演進的全球隱私權標準、區域合規性需求,以及客戶對主權資料控制的期望。

Salesforce Data 360 的設計目的為協助企業符合嚴格的全球隱私權與法規需求,例如 GDPR 與 CCPA。平台提供管理「資料主題權利」(DSR) 的原生功能,包括資料存取、匯出和刪除 (「被遺忘權」),以確保在整個生命週期內遵循個人資料的處理方式。 雖然客戶保留合規性的最終責任,但 Salesforce 會根據如 CCPA 等法規作為經認證的「服務提供者」運作,提供平台層級控制、安全性保證和合約機制,讓組織能夠有效率且大規模地實作其合規架構。

Trust 是 Salesforce 平台的基石,而該 Trust 是透過獨立驗證獲得的。Salesforce 擁有廣泛的全球安全性認證和證明組合,以示範其持續致力於保護客戶資料並維護最高標準的雲端安全性。 這些認證不只是核取方塊,它們代表嚴格的循環稽核,以驗證 Salesforce 安全性控制、流程和基礎結構的強大性和一致性。它們共同構成 Salesforce 基礎 Trust 模型的支柱。 關鍵認證和證明包括:

• **ISO/IEC 27001:**驗證 Salesforce 的全方位資訊安全性管理系統。
• **ISO/IEC 27017:**建立雲端特定安全性控制的最佳作法。
• **ISO/IEC 27018:**重點在於保護雲端中的個人可識別資訊 (PII)。
• **SOC 1、SOC 2 和 SOC 3:**確認 Salesforce 安全性與隱私權控制之設計與營運效率的獨立報告。
• **PCI DSS:**確保付款卡資訊的安全處理與儲存。
• **FedRAMP 高和 DoD 影響層級 4:**認證 Salesforce Government Cloud 供管理敏感性工作負載的美國聯邦機構使用。 透過維護此全方位的認證集,Salesforce 可讓客戶確信其資料是在符合 (且經常高於) 全球合規性和安全性期望的平台內管理的。

在今天的快速數位環境中,擁有客戶資料的全方位檢視至關重要,但擁有管理該資料之平台的全方位檢視同樣重要。Salesforce Data 360 提供強大的內建記錄、監視和可觀察性功能,可讓客戶確保資料品質、安全性和效能。 這些工具可協助您從反應性問題解決移至主動管理,確保 Data 360 實作的執行順利且有效率。

安全性不會與預防結束,它會隨著警覺而發展。在不斷變化的威脅環境中,Salesforce 將進階平台監視功能與客戶管理的審查流程結合在一起,以確保主動且持續的保護。 Salesforce 提供可視性和威脅偵測的強大原生工具:

• 「設定稽核追蹤」 會收集完整的管理變更歷程記錄,協助小組追蹤組態或原則更新。
• 事件監視可提供使用者行為、API 活動和資料存取模式的深入洞察。此遠端測試可與 Security Information and Event Management (SIEM) 解決方案順暢整合,以進行集中分析和關聯。

事件監視是 Salesforce Shield 產品的一部分,是追蹤 Salesforce 組織中詳細使用者活動和系統效能資料 (包括 Data 360 特定動作) 的中心。它會將廣泛的「事件」儲存到記錄檔案和物件中,以供您分析之用。

• **事件記錄檔 (ELF):**這些提供使用者活動和系統事件的細微詳細資料,可在短暫延遲後 (每小時或每天) 下載。您可以透過 API 或「事件記錄檔」瀏覽器存取最多 30 天的資料,並選擇匯出以供較長時間儲存。
• **即時事件監視:**針對立即洞察,即時事件會作為平台事件串流,可讓您近乎即時監視和偵測活動。這對安全性和效能至關重要,可讓您視需要立即採取行動。
• Data 360 特定事件:「事件監視」包含 Data 360 用量的特定事件類型,例如與 Data 360 頁面和資料相關的 Lightning 頁面檢視、Lightning 互動和「報告事件」。
• **與外部工具的整合:**Salesforce 可協助與受歡迎的第三方監視解決方案 (例如 Splunk、Datadog、New Relic 和 Sumo Logic) 順暢整合。您可以將「事件監視」資料串流或匯出至這些平台,以便合併整個技術堆疊的可觀察性。

瞭解 Data 360 實作的效能是獲得絕佳使用者體驗的關鍵。

• **Lightning Usage 應用程式:**此內建應用程式針對 Lightning Experience 中的 Data 360 頁面,提供效能度量的彙總檢視,例如頁面載入時間 (經歷頁面時間或 EPT) 和瀏覽器效能。
• 自訂報告與顯示面板:您可以使用 Data 360 物件和「事件監視」資料建立自訂報告和顯示面板,包括使用稱為 Event Monitoring Plus 的免費 CRM Analytics 範本應用程式。這些視覺效果可協助您快速找出趨勢並找出績效瓶頸。 但技術本身並不夠。真正的彈性需要自動偵測和人力審查之間的紀律合作夥伴關係。自動警示可以呈現即時異常,但微妙或長期威脅 (例如有效使用者緩慢且未經授權的資料洩漏) 通常是透過定期稽核和趨勢分析最佳識別。 Salesforce 提供遠程測試、稽核記錄和整合關聯;客戶提供流程嚴謹、作業步調和內容特定情報。它們共同構成一種深度防禦模型,結合自動化、分析和人力監督,以在威脅變成事件之前偵測、調查和回應威脅。

Salesforce Data 360 不僅用來統一您的客戶資料,還要讓資料變得聰明且可運作。此價值主張的核心部分為提供強大的報告、強大的顯示面板、深入的度量和即時通知功能。這些工具可讓客戶在熟悉的 Salesforce 環境中,根據統一資料監視資料狀況、追蹤效能並自動化動作。

Salesforce 的原生報告與顯示面板功能可順暢地延伸至 Data 360,讓您無須離開平台即可視覺化與分析統一資料。

您可以針對儲存在 Data 360 中的資料建立標準和自訂報告,包括來自各種來源的統一資料和已計算洞察。

• **標準與自訂報告類型:**Data 360 特別針對 Data 360 物件 (例如資料串流、區段、啟用、身分解析和已計算洞察) 導入新報告類型。這可讓您使用標準 Salesforce 報告產生器來查詢統一的資料。
• **粒子分析:**報告支援最多 10 列分組,允許更精細的區隔和詳細分析客戶屬性和趨勢。
• **公式和摘要:**您可以利用列層級公式和摘要公式來評估每個記錄或記錄群組,協助您在單一報告中追蹤詳細的度量和概況彙總摘要。

顯示面板可在整個 Data 360 實作中以視覺化方式顯示主要度量與趨勢。

• **統一檢視:**在單一顯示面板中結合來自多個 Data 360 報告的資料,甚至可以將 Data 360 報告與標準 CRM 報告混合,以全方位檢視您的作業和客戶洞察。
• **可自訂小工具:**使用各種圖表類型 (長條圖、線條圖、圓餅圖、量表等) 和表格,有效顯示報告資料。
• **即時洞察:**您可以重新整理顯示面板以提供最新的資訊,以協助快速的資料驅動決策。

Data 360 可讓您定義和追蹤與業務目標相關的主要績效指標 (KPI)。這些項目可透過以下方式產生:

• **已計算洞察:**使用大量批次處理的資料建立強大度量。例如,計算如「平均客戶終身價值」或「已啟用契約收入總計」等度量,並在報告和顯示面板中使用這些度量或維度。
• **串流洞察:**近乎即時地從串流來源處理資料,以建立時間序列彙總,例如網站或行動參與資料。這些度量可以驅動立即協調流程和資料動作。

Salesforce 提供強大的自動化和通知功能,以確保您瞭解 Data 360 中的重要事件或資料變更。

• **流程型通知:**您可以設定「流程流程」以根據 Data 360 物件 (例如「資料串流」、「區段」和「啟用」) 中的事件觸發動作並傳送通知。
• **自訂警示:**建立觸發電子郵件的自訂通知,或在符合特定條件時顯示在 Salesforce 通知 Bell 中。例如,如果資料串流失敗、身分解析規則發生錯誤,或金鑰度量超過某一特定值,您會收到警示。
• **事件通知服務 (ENS):**針對開發人員,API 第一個「事件通知服務」可讓外部系統在發生特定事件時接收通知,讓整個技術堆疊能夠順暢整合和即時回應。
• **資料動作:**您可以根據串流洞察觸發資料動作,這些動作可設定為傳送警示、叫用平台事件,或透過 Webhook 與其他 SaaS 應用程式整合。 透過利用這些全方位功能,Salesforce Data 360 客戶可以有效監視其資料生態系統、視覺化主要度量,並即時接收警示,以促進主動參與和卓越營運。

企業規模採用 Salesforce Data 360 不需要技術啟用,而需要有意義且以安全性為第一的結構。下列策略性建議為 CTO 和企業結構設計師提供建立 Trust、彈性與合規性的藍圖,讓其在 Data 360 部署的每個層級中都能達到目標。

• **實作「安全依據設計」方法:**安全性不應改良,應該是基礎。從 Salesforce 的預設 「全部拒絕」 原則開始,並視需要明確授與存取權。請先定義監管、原則和存取架構,再取用或啟用資料。從第一天開始建立安全性可消除隱藏曝光的風險,並簡化長期合規性。
• **強制執行強大的身分與存取管理 (IAM) 策略:**透過聯合 SSO 集中身分,並強制執行多因素驗證 (MFA),以減輕認證妥協。透過「登入 IP 範圍」限制存取權,並使用 Salesforce 的身分提供者 (IdP) 功能在使用者和整合之間建立端對端的責任。統一的 IAM 圖層可減少作業複雜度並強化您的驗證表面。
• **套用最低權限原則:**為了精確率而非便利性而設計角色。使用 Salesforce 的標準權限集作為工作分隔的基礎,確保使用者僅可存取必要項目。避免過度自訂權限 - 每個偏差都會增加維護負擔和非預期的存取風險。
• **建立多層資料管理架構:**使用「資料空間」依業務單位或品牌分隔資料,並使用物件、欄位和記錄級安全性 (OLS、FLS、RLS) 強制執行以屬性為基礎的存取控制 (ABAC)。使用「動態資料遮蔽」即時保護敏感資訊,而不會阻礙分析或可用性。此分層模型可確保在資料跨網域規模保持一致的管治。
• **策略地利用加密和安全整合:**針對敏感工作量,請使用客戶管理金鑰 (CMK) 部署「平台加密」,以維持對加密生命週期的主管權。使用「已命名認證」和「私人連線」來保護所有系統對系統整合的安全,以免除硬式編碼密碼,並確保所有流量都保持專用、合規和可稽核。
• **建立連續安全性作業計畫:**安全性並非與組態結束,它在作業規範上茁壯成長。透過事件記錄和存取追蹤的定期稽核檢閱來補充自動監視。建立專屬的安全性作業 (SecOps) 函數,以識別異常、調查威脅並驗證合規性。目標:及早偵測、快速回應,並持續改善狀態。

建立安全且智慧企業的旅程並非透過部署結束,而是透過規範、設計和 Trust 來發展。Salesforce Data 360 提供結構基礎,但當組織將安全性、管治和情報運作為一個統一的動作時,即會出現真正的價值。 企業不應將 Data 360 視為另一個資料平台,而是作為安全且可組成的 Trust 層,以單一管治架構將資料、AI 和客戶參與連接在一起。透過採用 _安全依據設計_的理念、在每個層級強制執行最低權限,並將私人連線延伸至所有資料流程,組織可將合規從核取方塊轉換為競爭優勢。 下一步是持續現代化,將稽核自動化、保單強制執行和加密生命週期管理內嵌在日常作業中。隨著企業發展為代理 AI 驅動的架構,今天保護資料的相同原則將構成明天 AI 治理的支柱,確保每個模型、工作人員和決策都可解釋、注意原則,且設計上符合。 最終,Trust 會成為數位轉換的新貨幣。透過 Salesforce Data 360,企業可以自信地擴展其資料生態系統 — 瞭解每個位元組、每個連線和每個洞察都會以完整性保護、管理和啟用。

Krishna Chalamasandra 是一位經驗豐富的網路安全專家,擁有 25 年以上的資訊安全技術與合規經驗。在 Salesforce,他是客戶的信任顧問,也是 CISO 組織內「安全性和合規性客戶Trust」功能的關鍵領導者。之前,Krishna 在思科工作了 10 年,領導了 IAM、網路安全性和 PKI 的安全性結構,並推動了關鍵認證,包括 ISO 27001、SOC 1–3、PCI、FedRAMP 和 FIPS 140-2。他還在 Novell 花了 8 年以上的時間,為全球受監管的客戶實作基礎架構層級控制,並支援複雜的安全審查。

Yugandhar Bora 是 Salesforce 的軟體工程結構設計師,專門在「資料與情報應用程式」平台內進行資料結構。他負責領導企業結構審查委員會 (EARB) 計畫,專注於資料管理和統一資料模型,同時為自動平台佈建解決方案做出貢獻。