#### Salesforce：云的安全性
Salesforce 负责保护和维护 Data 360 平台及其全球基础设施的完整性。这包括：
* **物理和环境安全：**Hyperforce 托管在 AWS 基础设施上，Amazon 受委派负责通过访问控制、监视和环境保障措施来保护他们的全球数据中心。
* **网络和周边防御：**分布式拒绝服务 (DDoS) 缓解、入侵检测，以及对所有传输中（TLS 1.2 及更高版本）和静态 (AES-256) 流量的加密。
* **平台强化和补丁管理：**持续漏洞管理、补丁部署和操作系统级安全基准。
* **合规性和认证：**根据 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 成熟度计划中的关键一步。
#### 按设计的Trust
Salesforce Data 360 通过默认零访问和要求明确的策略定义，通过设计建立 Trust，这是企业数据安全的基础发展。
此方法可确保：
* 未授权访问和数据泄露风险最小化。
* 治理框架是结构性的，而不是选择性的。
* 企业可在各种环境中获得更可预测、可审计和更具弹性的安全状况。
本质上，安全性不再是您添加的功能，而是您开始的基础。
## 身份和访问权限管理：数据网关
**Salesforce Data 360** 中的身份和访问权限管理 (IAM) 是第一层也是最重要的防御层。它控制**谁**可以访问平台，以及他们可以在进入后执行**哪些**操作。实施良好的 IAM 框架是企业保护其客户数据并确保运营完整性的最强有力的控制手段。
### 身份验证：验证“您是谁”
身份验证建立**数字信任,**确认访问 Salesforce Data 360 的每个用户、服务或外部系统都合法。
### 聚合身份管理
Data 360 支持使用 [**SAML 2.0**](https://help.salesforce.com/s/articleView?id=xcloud.sso_saml.htm&type=5)、OpenID Connect([**oidC**](https://help.salesforce.com/s/articleView?id=xcloud.sso_provider_openid_connect.htm&type=5)) 或跨域身份管理系统 ([**SCIM**](https://help.salesforce.com/s/articleView?id=xcloud.identity_scim_overview.htm&type=5)) 与企业级身份提供商 (IdP) 进行**联合身份验证**，例如 [**Microsoft Entra ID (Azure AD)**](https://learn.microsoft.com/en-us/entra/identity/saas-apps/salesforce-tutorial)、[**Okta**](https://help.okta.com/en-us/content/topics/provisioning/salesforce/sfdc-provision.htm) 或 [**Ping Identity**](https://docs.pingidentity.com/configuration_guides/salesforce/config_saml_salesforce_pf.html)。
此联合将企业身份生命周期直接扩展到 Salesforce。当员工加入、转移或离开公司时，他们的访问权限会自动调整，从而减少孤立客户并提高合规性准备。
### 单点登录 (SSO)
通过[**单点登录 (SSO)**](https://help.salesforce.com/s/articleView?id=xcloud.sso_about.htm&type=5)，用户使用公司凭据进行身份验证一次，无需单独密码即可安全访问 Salesforce 应用程序。这会减少凭据疲劳，并最大限度地减少密码重复使用或网络钓鱼的风险。
### 自适应和条件访问
身份提供商 (IdP) 成为身份验证决策的唯一权威机构，强制执行多重身份验证 (MFA)、条件访问和基于风险的控制。身份验证根据用户行为和上下文，从单个事件发展到对 Trust 的持续评估。
联合身份验证提供：
* **集中策略执行：**身份验证标准可在所有 Salesforce 环境中的一个地方进行管理。
* **端到端可跟踪性：**统一审计跟踪会将每个操作链接回已验证的身份。
* **以人为本的经验：**无摩擦、安全的登录流程允许团队专注于见解，而不是凭据。
### 授权：定义“您可以做什么”
验证用户后，授权会定义他们可以访问、查看或修改的内容。它设置保护敏感数据和实施最小权限的操作边界。
**最小特权原则 (PoLP)：**每个用户和系统仅被授予作业功能所需的权限，仅此而已。该原则极大地限制了因凭据被盗或配置错误而造成的潜在损害。
**基于角色的访问控制 (RBAC)：**Salesforce Data 360 使用权限集和权限集组来分配与业务角色一致的精细功能。例如：
* 数据工程师可以在 Data 360 Architect 权限集的帮助下管理接收漏斗和转换。
* 市场营销分析师可以查询统一的数据，但不能在 Data 360 激活管理器权限集的帮助下修改模型。
* 激活管理器可以执行出站市场活动，但无法在 Data 360 激活管理器权限集的帮助下访问源数据
访问权限可集中管理和审计，确保数据生命周期的问责制。当与 IdP（例如 Entra ID、Okta 或 Ping 身份）集成时，访问策略通过 SCIM 配置和 SAML/SSO 联盟在企业中无缝扩展。
### 了解 Data 360 中的标准角色和权限
Salesforce 提供预定义的权限集，封装了职责分离和符合 ISO 27001 等行业标准的最佳实践。
| 角色 | 首要责任 | 访问设计系列 |
|---|---|---|
| 系统管理员 | 环境设置、配置和配置 | 无法访问基础数据集 — 确保系统和数据控制之间的分离 |
| Data 360 架构师 | 数据接收、转换、身份解析和建模 | 无法执行数据激活以维护数据暴露边界 |
| Data 360 激活管理器 | 细分创建、渠道管理和激活 | 对数据模型的只读访问权限；无修改权限 |
| Data 360 用户 | 消耗分析和见解 | 只读；零修改权限 |
| Data 360 One 用户 | 通过同伴组织进行跨组织访问 | 由共享空间权限和范围访问策略控制 |
### 作为控制平面的治理
Data 360 围绕“治理优先”模型构建，确保从接收到见解激活的每个数据交互都是策略感知、可审计和合规的。治理作为中央控制平面发挥作用，管理数据在整个生命周期中的发现、分类和保护方式。
此统一控制平面确保：
* **数据访问是上下文授权**的:只有正确的用户在正确的策略下才能对正确的数据进行操作。
* **治理嵌入到语义层和操作层中**,确保数据建模方式和保护方式的一致性。
* **零信任和最低特权**原则得到执行:在授予访问权限之前实时评估身份、上下文和政策。
通过此架构，Salesforce Data 360 将治理从静态权限管理转变为动态的、策略驱动的编排层。一种持续适应环境、通过设计强制执行合规性并保持企业级 Trust 的方法。
### 带数据空间的逻辑数据隔离
在宏级别，数据空间提供了企业数据域的逻辑隔离和隔离，使具有多品牌、多地区或多租户运营模型的组织能够在单个统一平台中管理数据。数据空间可以与业务域（例如销售、市场营销或客户成功）或监管和地理边界（例如欧盟、AMER 或亚太地区）保持一致，允许治理和访问控制反映组织的运营和合规结构，而不会分散底层数据平台。
* 每个数据空间充当虚拟边界，定义用户或团队可以看到或交互的数据收集。
* 明确授予数据空间内的访问权限，确保没有隐含的权限或交叉污染数据可见性。
* 这实现了联合所有权：每个业务部门都可以独立管理其域，同时保持集中的监督和合规。
通过设计，数据空间提供了第一层治理，在整个企业数据集之间建立了结构清晰度和问责。
### 从 RBAC 到 ABAC：转向上下文授权
在 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 中提供自适应的精细访问控制
### ABAC：多层安全层次结构
Salesforce Data 360 细粒度访问控制的核心是基于属性的访问控制 (ABAC，由 CEDAR 策略语言提供支持)。
与静态的、基于角色的权限不同,ABAC 动态评估*谁*在请求访问、他们试图访问*什么*以及*在什么条件*下访问----确保每次数据交互都符合企业政策和 Trust 边界。
#### 动态策略评估
Data 360 的 ABAC 引擎根据三种核心属性类型的组合评估访问决策：
* **用户属性：**部门、位置、审批级别
* **数据属性：**分类、灵敏性(PII、PHI、财务数据)、数据空间
这种灵活的策略驱动模型允许强制实施随着用户角色、数据分类或运营条件的发展而自动适应，这对于大型、分布式和受监管的企业至关重要。
#### Salesforce Data 360 中的 ABAC 架构组件
Salesforce Data 360 实施基于标准的基于属性的访问控制 (ABAC) 架构，该架构符合策略驱动的数据治理的行业最佳实践。它由三个主要功能组件组成：
* **策略信息点 (PIP) - 策略、丰富元数据和分类：**
* 包含策略定义本身，包括管理企业数据的数据访问、分类、屏蔽、保留和使用策略。
* 维护丰富的元数据，例如标签、分类、业务上下文和端到端谱系。
* 利用 LLM 和 ML 驱动的分类来自动标记敏感数据（例如 PII.Email、PII.Phone、PHI）。
* 标签传播确保分类沿着数据谱系自动流动（DLO → DLO → DMO）。
* 在转换之间保持灵敏性和合规性。
* **策略决策点 (PDP)**:PDP 是解释 CEDAR 策略的决策引擎。
* 从 PEP（用户身份、请求元数据）接收上下文输入，并从 PIP 接收引用属性。
* 确定地评估策略，以提供一致、可解释和可扩展的访问决策。
* 支持实时和批量评估，即使在高用量环境中也能确保性能和精度。
* **策略执行点 (PEP)**:PEP 是在运行时强制执行授权决策的地方。
* 拦截所有交互渠道中的数据访问请求，例如 API、UI 查询、CRM 丰富或 GenAI 检索扩充生成 (RAG) 漏斗。
* 立即应用 PDP 结果，确保每个查询和检索都符合企业访问策略。
PIP-PDP-PEP 三者共同构成了一个分布式治理结构，在所有 Data 360 服务和访问模式中实施一致的、基于策略的控制。
重要的是，Data 360 中的 [ABAC](https://help.salesforce.com/s/articleView?id=data.c360_a_policy_based_governance_dg.htm&type=5) 是配置的，而不是构建的。架构师不会汇编自定义控制平面或强制逻辑。相反，它们填充并连接三个本地架构组件，它们一起作为统一的治理结构运行。
在实践层面，实施遵循一个简单的过程：分类数据，定义策略，并让平台自动实施它们。一旦配置，访问控制将成为系统行为，而不是手动或程序过程。
这种分布式治理结构确保**所有访问渠道**的一致政策执行,在整个 Data 360 中建立统一 Trust 边界。
#### 多级策略实施
Data 360 的 ABAC 框架支持分层访问边界，确保数据不仅在对象级别受到保护，而且在特定字段和记录中受到保护。
* **对象级安全性 (OLS)**:访问控制的最外部边界。
管理对整个数据结构的访问，例如数据湖对象 (DLO) 或数据模型对象 (DMO)。
示例：授予对*客户*对象的访问权限，但不授予对*交易的*访问权限。
* **字段级安全性 (FLS)**:控制对对象中特定字段的访问。
示例：市场营销用户可以看到客户名称，但被限制查看信用卡号码或国家标识符。
* **记录级安全性 (RLS)**：最精细的控制层。
确定用户可以查看或修改数据集中的哪些单个记录。
示例：区域经理仅可以访问与其分配区域相关的客户数据。
* **动态数据掩码 (DDM ) :**启用实时数据保护。作为 ABAC 的补充，DDM 在不更改基础数据集的情况下，强制执行策略驱动的敏感信息模糊。在查询时，DDM 根据用户角色、上下文或合规规则自动屏蔽 PII 或财务数据等字段。
* 敏感数据在 UI 视图、API 和 AI 工作流中受到保护。
* 通过确保所有消耗层之间一致的屏蔽，降低数据泄露风险。
* 保持可审计性。每个屏蔽查询都会在 Data 360 的治理框架内进行记录和跟踪。
此架构将访问控制从静态权限模型转换为动态上下文感知策略结构。通过将 RBAC 的结构简单性与 ABAC 的上下文深度相结合，Salesforce Data 360 实现了：
* 在接收、协调和激活方面实现一致的策略实施。
* 随数据、角色和合规需求而变化的自适应治理。
* 从接收到 AI 激活的整个数据生命周期中的统一 Trust 边界。
#### 与 Salesforce 平台深度集成
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)：**借助外部密钥管理（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 创建了深度防御架构，可以保护客户数据免受外部攻击和内部基础设施威胁。
### Data 360 中的安全系统到系统集成（数据集成）
虽然加密和访问控制保护 Salesforce Data 360 中的数据，但保护数据在系统之间的移动同样重要。现代企业运行在多云和混合环境中，敏感数据在 Salesforce、分析平台、外部 API 和数据湖之间流动。
为了解决这个问题,Salesforce 设计了以命名凭据 (NC) 和外部凭据 (EC) 为中心的安全集成框架 — 为安全连接提供了策略驱动的零信任基础。
#### Salesforce 的安全集成框架
Salesforce 构建了强大的**[安全集成框架](https://developer.salesforce.com/docs/platform/named-credentials/guide/get-started.html)**,其核心是命名凭据 (NC) 和外部凭据 (EC)。它们一起抽象了凭据的复杂性，强制实施最低权限的访问，并在所有集成之间实现了一致的身份验证管理，而不会暴露代码或配置中的秘密。
这一框架抽象了安全复杂性,强制执行了最佳做法,为所有外部连接建立了**政策驱动控制平面**----符合Salesforce的**Zero Trust**和**逐设计安全**原则。
##### 命名凭据
命名凭据 (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 连接器如何利用此框架
虽然 Data 360 的用户界面抽象了大部分底层配置，但命名凭据和外部凭据框架经常被其本机连接器和数据流掩盖起来使用。这意味着，即使管理员只是通过引导式 UI “添加数据连接”，Data 360 仍然在后台应用这种标准化的安全模型。
架构含义：
* **统一安全模型：**每个连接器（无论是外部数据库 、AWS S3 还是企业 API）都受益于命名凭据和外部凭据实施的相同加密、身份验证和密钥管理标准。
* **开发人员抽象：**开发人员和管理员不需要手动处理身份验证流或凭据轮换。Salesforce 管理令牌生命周期、过期和自动刷新。
* **一致的策略执行：**此框架确保所有连接器遵守一致的身份验证、审计和日志记录策略，这对受监管行业的大规模多源接收至关重要。
* **面向未来的扩展性：**随着 Salesforce 增强其身份验证堆栈（例如，支持新的 OAuth 流或 FIDO2 标准），这些改进会自动在所有连接器之间传播，而无需重构或重新部署。
### Data 360 连接器安全和治理
Salesforce Data 360 提供了大量现成的连接器套件，可简化来自各种来源的数据集成。这使得企业能够有效地整合和利用他们的数据。Salesforce 提供多种连接器类型，包括本地 Salesforce 连接器、云存储连接器、数据库连接器以及应用程序和 API 连接器。除了提供的连接器之外，还支持 Zero 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 与 ETL 工具集成，例如 MuleSoft 和 Informatica。
#### 数据安全和 Salesforce Data 360 连接器
Salesforce Data 360 中存储的数据的安全性一直是许多 Data 360 相关对话的重点。作为 Salesforce 对深度防御安全方法承诺的一部分，同等重视保护数据如何接收到 Data 360 环境中。
Salesforce 认识到企业在不同的数据生态系统中运营，通常跨越多个云平台、存储解决方案和分析工具。我们的 Data 360 连接器是这些环境之间的桥梁。该连接器支持安全、可扩展和高效的数据集成，同时保持 Salesforce 的高安全标准。这些连接器促进了无缝的数据流，而不会损害完整性或隐私。
Data 360 连接器安全性的三个重要组件是：
* **身份验证/授权映射**:安全访问管理是数据安全的基础。不同的云连接器使用不同的身份验证和授权机制来验证和控制用户访问。身份验证确保用户或系统是合法实体，而授权定义了授予的访问级别。Salesforce 确保其连接器尽可能利用行业标准。
* **零复制 (ZETL) 功能交互性**:数据重复带来了安全和操作挑战。这也带来了不必要的存储成本、数据不一致和更大的风险。Salesforce 的零提取、转换和加载 (ZETL) 方法可确保无需物理数据复制即可在平台之间实现实时数据共享。这意味着数据可以保留在原始环境中，同时仍然可以访问以处理、报告和分析。此外，这也大大减少了攻击面，增强了对数据驻留法律的潜在遵守。
* **数据联合支持**:在当今的多云环境中，组织需要全面的数据访问，而无需不必要的数据移动。Data 360 连接器聚合数据模型支持基于文件和基于查询的数据聚合，使企业能够实时利用外部数据源。无论是访问结构化数据库、半结构化日志还是非结构化文件，Salesforce 的连接器都可以确保数据在其整个生命周期中保持安全。
Salesforce 旨在为客户提供所需的透明度，以帮助驾驭数据安全和合规的复杂性，即使我们的集成也是如此。无论是与 AWS S3、Google Cloud Storage、Snowflake 还是其他平台集成，我们的 Data 360 连接器都旨在确保Trust、透明度和对关键业务数据的控制。
##### Salesforce Data 360 连接器安全和身份验证映射
| 连接器类型 | 连接类型支持 | 主要身份验证类型 | 关键安全方面和备注 |
|---|---|---|---|
| Salesforce CRM | 不适用（内部） | 基于会话（内部） | 使用 Salesforce 强大的内部身份和访问权限管理 (IAM) 模型。所有数据都在 Salesforce 基础设施中传输和静态加密。 |
| Marketing Cloud 参与 | 仅限公共 Internet | OAuth 2.0，用户名/密码 | 标准 OAuth 2.0 协议用于安全身份验证。数据通过公共互联网进行传输加密 (TLS)。 |
| B2C Commerce | 仅限公共 Internet | OAuth 2.0 | 标准 OAuth 2.0。依赖安全公共互联网协议 (TLS) 进行数据传输。 |
| Web 和移动应用程序 | 仅限公共 Internet | API 密钥，OAuth 2.0 | 通过 API（摄取 API、串流 API）摄取的数据。通过 API 密钥管理和标准 Web 协议管理的安全性。 |
| Amazon S3 | 专用连接和公共 | IAM 角色、外部凭据 | 支持 AWS PrivateLink，以实现安全的专用连接。公共连接使用安全凭据。数据在传输和静态加密（S3 中的客户受管密钥可选）。 |
| Snowflake | 专用连接和公共 | OAuth 2.0、私钥身份验证、用户名/密码 | 支持 VPC 专用连接 (AWS PrivateLink)。公共连接适用于安全身份验证方法。数据可以使用 Snowflake 中的客户密钥加密。 |
| Amazon Redshift | 专用连接和公共 | 用户名/密码，IAM 身份验证 | 支持专用连接 (AWS PrivateLink)。公共连接使用标准安全最佳实践。 |
| Microsoft Azure（存储/SQL） | 仅限公共 Internet | SAS 令牌、OAuth 2.0、用户名/密码 | 连接依赖于安全的 SAS 令牌或 OAuth 进行身份验证。数据通过加密渠道 (TLS) 通过公共互联网。 |
| Google Cloud Storage (GCS) | 仅限公共 Internet | OAuth 2.0，服务帐户 | 连接依赖于安全的 OAuth 2.0。数据通过加密渠道 (TLS) 通过公共互联网。 |
| MuleSoft (API) | 仅限公共 Internet | OAuth 2.0，API 密钥 | 通过 API 连接。安全性通过标准 API 身份验证和通过 MuleSoft Anypoint 平台实施的强大治理策略进行管理。 |
| 阶段 | 机制 | 安全/治理控制 |
|---|---|---|
| 激活配置 | 在 Data 360 激活设置中定义 | 通过命名凭据和外部凭据保护 |
| 数据准备 | 从 DMO 筛选和联接 | 应用的同意和隐私元数据 |
| 出站转移 | 通过 TLS/专用连接加密 | 策略实施和凭据抽象 |
| 外部交付 | SFTP/云存储/API | 访问控制和可审计交付 |
所有通信都保留在 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 安全性的关键功能和特性。
#### 关键 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 调用和登录尝试。客户可以使用这些数据进行审计，并创建事务安全性策略。
* **安全中心**:此功能为所有 Salesforce 组织的安全运行状况、合规性和治理度量提供了单一、统一的视图，简化了监控和管理。
* **字段审计跟踪**:帮助客户跟踪登录和字段历史，监控设置更改，并履行审计和数据保留合规义务。
* **数据治理功能**:包括数据标记和分类、策略实施和动态数据屏蔽，以确保在所有数据接触点（包括通过 API 访问的接触点）之间应用一致的治理策略。
#### 设置和管理 API 安全性：客户旅程
1. 启用核心控制：从启用组织范围的默认值开始，例如 MFA 和 IP 限制。
2. 请求 API 访问控制：通过 Salesforce 支持记录个案，以在贵组织中启用“API 访问控制”功能。
3. 配置连接的应用程序：为每个集成创建特定的连接的应用程序，定义所需的 OAuth 范围，并将其分配到授权的简档/权限集。
4. 实施最低权限：确保所有集成用户拥有“仅限 API”权限和最少的数据访问权限。
5. 监控和审计：定期使用 Event Monitoring and Security Center，以查看 API 使用情况、检测异常并执行漏洞评估。
6. 强制执行最佳实践：始终强制执行 TLS，安全地存储刷新令牌，轮换会话 ID，并验证数据输入。
通过利用这些强大的、客户可配置的功能，企业可以为 Salesforce Data 360 中的所有 API 交互维护一个安全和合规的环境。
### 合规、审计和持续监控
#### 服务可用性和数据驻留
Salesforce Data 360 旨在通过其地理分布式部署模型满足全球数据驻留和主权要求。该服务目前在多个受监管地区提供，包括美国、加拿大、巴西、德国、印度、澳大利亚和日本。
数据驻留通过将每个客户的核心组织实例映射到最近的相应 Data 360 区域实例来确定。例如，位于美国或加拿大的核心组织与美国区域内的 Data 360 实例配对，而欧洲联盟内的核心组织映射到托管在德国的实例。同样，印度、澳大利亚、新西兰或新加坡的核心组织与托管在印度的 Data 360 实例相关联。
Salesforce 的 Hyperforce 基础设施是该模型的基础,为地理数据控制、安全隔离和监管合规提供了基础。Hyperforce 确保客户数据（包括元数据、备份和派生数据集）保持在定义的区域边界内。该架构允许企业满足本地数据驻留和合规要求，例如 GDPR、FFIEC、HIPAA 以及亚太地区和 EMEA 地区的区域隐私法。
Salesforce 继续将 Data 360 的可用性扩展到其他 Hyperforce 区域，以符合不断发展的全球隐私标准、区域合规性要求和客户对主权数据控制的期望。
#### 监管合规支持
Salesforce Data 360 旨在帮助企业满足严格的全球隐私和监管要求，例如 GDPR 和 CCPA。该平台提供本地功能来管理数据主体权利 (DSR)，包括数据访问、导出和删除（“被遗忘的权利”），确保个人数据在其整个生命周期中得到合规处理。
虽然客户保留对合规性的最终责任，但 Salesforce 作为认证的“服务提供商”根据 CCPA 等法规运营，提供平台级控制、安全保证和合同机制，使组织能够高效、大规模地实施其合规框架。
#### Foundational Trust：认证和证明
Trust 是 Salesforce 平台的基石，这种 Trust 是通过独立验证获得的。Salesforce 拥有广泛的全球安全认证和认证产品组合，表明它始终致力于保护客户数据和维护云安全的最高标准。
这些认证不仅仅是复选框 - 它们代表了严格的重复性审计，可以验证 Salesforce 安全控制、流程和基础设施的强度和一致性。它们共同构成了 Salesforce Foundational 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 中的记录、监控和可观察性
在当今快节奏的数字环境中，全方位了解客户数据至关重要，但同样重要的是全方位了解管理这些数据的平台。Salesforce Data 360 提供了强大的内置日志记录、监控和可观察性功能，使客户能够确保数据质量、安全性和性能。
这些工具帮助您从反应式问题解决转向主动式管理，确保您的 Data 360 实施平稳高效地运行。
#### 主动威胁检测和响应
安全不仅仅止于预防 — 而是警惕地发展。在不断变化的威胁环境中，Salesforce 将高级平台监控功能与客户管理的审核流程相结合，以确保主动、持续的保护。
Salesforce 为可见性和威胁检测提供了强大的本机工具：
* **设置审计跟踪**捕获管理更改的完整历史，帮助团队跟踪配置或策略更新。
* **事件监控**提供对用户行为、API 活动和数据访问模式的深入见解。此遥测可与**安全信息和事件**管理 (SIEM) 解决方案无缝集成，以实现集中分析和关联。
#### 1\.Event Monitoring：贵组织的脉搏
Event Monitoring 是 Salesforce Shield 产品的一部分，是跟踪 Salesforce 组织中详细用户活动和系统性能数据的中央中心，包括特定于 Data 360 的操作。它会将大量“事件”捕获到日志文件和对象中，以便进行分析。
* **事件日志文件 (ELF)：**这些提供了用户活动和系统事件的精细详细信息，可在短暂延迟（每小时或每天）后下载。您可以通过 API 或事件日志文件浏览器访问最多 30 天的数据，并选择导出以进行长期存储。
* **实时 Event Monitoring：**对于即时见解，实时事件会作为平台事件流式传输，允许您近乎实时地监控和检测活动。这对于安全和性能至关重要，使您能够在需要时立即采取行动。
* **Data 360 特定事件：**Event Monitoring 包含特定于 Data 360 使用情况的事件类型，例如 Lightning 页面视图、Lightning 交互以及与 Data 360 页面和数据相关的报表事件。
* **与外部工具集成：**Salesforce 有助于与流行的第三方监控解决方案（例如 Splunk、Datadog、New Relic 和 Sumo Logic）无缝集成。您可以将 Event Monitoring 数据流式传输或导出到这些平台，以便在整个技术堆栈中整合可观察性。
#### 2\.性能监控和优化
了解 Data 360 实施的性能是获得卓越用户体验的关键。
* **Lightning Usage应用程序：**该内置应用程序为 Lightning Experience 中的 Data 360 页面提供了性能度量的聚合视图，例如页面加载时间（体验页面时间或 EPT）和浏览器性能。
* **自定义报表和仪表板：**您可以使用 Data 360 对象和 Event Monitoring 数据构建自定义报表和仪表板，包括使用名为 Event Monitoring Plus 的免费 CRM Analytics 模板应用程序。这些可视化可帮助您发现趋势，并快速识别性能瓶颈。
但仅有技术是不够的。真正的弹性需要自动检测和人工审核之间有纪律的合作。自动警报可以显示实时异常，但微妙或长期的威胁，例如有效用户缓慢、未经授权的数据泄露，通常通过定期审计和趋势分析来最好地识别。
Salesforce 提供遥测、审计日志和集成挂钩；客户带来流程严谨、操作节奏和特定于上下文的智能。它们共同构成了一个**深入防御模型** — 将自动化、分析和人工监督结合起来,在威胁成为事件之前对其进行检测、调查和响应。
### 推动明智的决策：Salesforce Data 360 中的报表、仪表板、度量和通知
Salesforce Data 360 不仅仅是统一您的客户数据；它还使该数据具有智能性和可操作性。该价值主张的核心部分是提供强大的报表、强大的仪表板、见解深刻的度量和实时通知功能。这些工具使客户能够在熟悉的 Salesforce 环境中监控数据运行状况、跟踪性能并根据统一数据自动化操作。
#### 报表和仪表板：您的数据可视化中心
Salesforce 的本机报表和仪表板功能无缝扩展到 Data 360，允许您可视化和分析统一数据，而无需离开平台。
#### 基于统一数据构建报表
您可以对存储在 Data 360 中的数据创建标准和自定义报表，包括来自各种来源的统一数据和计算见解。
* **标准和自定义报表类型：**Data 360 引入了专为 Data 360 对象设计的新报表类型，例如数据流、细分、激活、身份解析和计算见解。这允许您使用标准 Salesforce 报表生成器查询统一数据。
* **粒度分析：**报表支持最多 10 行分组，允许对客户属性和趋势进行更精细的细分和详细分析。
* **公式和汇总：**您可以使用行级和汇总公式来评估每个记录或记录组，帮助您在单个报表中跟踪详细的度量和高级聚合汇总。
#### 适用于整体视图的动态仪表板
仪表板直观显示 Data 360 实施中的关键度量和趋势。
* **统一视图：**将多个 Data 360 报表中的数据组合在一起，甚至将 Data 360 报表与标准 CRM 报表混合在一起，以获得运营和客户见解的整体视图。
* **可自定义小部件：**使用各种图表类型（条形图、线形图、饼图、标准图等）和表格，以有效显示报表数据。
* **实时见解：**仪表板可以刷新以提供最新信息，帮助快速做出数据驱动的决策。
#### 度量和 KPI：衡量成功
Data 360 使您能够定义和跟踪与业务目标相关的关键绩效指标 (KPI)。这些可以通过以下方式生成：
* **计算见解：**使用高用量批量处理的数据创建强大的度量。例如，计算“平均客户终身价值”或“有效合同总收入”等度量，并将其用作报表和仪表板中的维度或评测。
* **流见解：**近乎实时地处理来自流源的数据，以构建时间序列聚合，例如网站或移动参与数据。这些度量可以推动即时编排和数据操作。
#### 通知和提醒：保持知情和主动
Salesforce 提供强大的自动化和通知功能，以确保您了解 Data 360 中的关键事件或数据更改。
* **基于流的通知：**您可以设置进程流，以根据数据流、细分和激活等 Data 360 对象中的事件触发操作并发送通知。
* **自定义提醒：**创建自定义通知，触发电子邮件或在满足特定条件时显示在 Salesforce 通知铃声中。例如，如果数据流失败、身份解析规则遇到错误或关键度量超过特定阈值，您会收到警报。
* **事件通知服务 (ENS)：**对于开发人员，API 优先的事件通知服务允许外部系统在特定事件发生时接收通知，从而在您的技术堆栈中实现无缝集成和实时反应。
* **数据操作：**根据流见解，您可以触发数据操作，这些操作可以配置为发送警报、调用平台事件或通过 Webhook 与其他 SaaS 应用程序集成。
通过利用这些全面功能，Salesforce Data 360 客户可以有效监控他们的数据生态系统，可视化关键度量，并及时收到警报，以推动主动参与和卓越运营。
### 企业采用的战略建议
在企业级采用 Salesforce Data 360 需要的不仅仅是技术支持，还需要深思熟虑的安全第一架构。以下战略建议为 CTO 和企业架构师提供了在 Data 360 部署的每一层建立Trust、弹性和合规性的路线图。
* **实施“按设计安全”方法：**安全不应被改造——它应该是基本的。从 Salesforce 的默认 *“拒绝所有”*策略开始，并根据需要明确授予访问权限。在接收或激活数据之前，定义治理、策略和访问框架。从第一天开始构建安全性可以消除隐藏暴露的风险，并简化长期合规性。
* **实施强大的身份和访问权限管理 (IAM) 策略：**通过聚合 SSO 集中身份，并实施多重身份验证 (MFA)，以缓解凭据泄露。按登录 IP 范围限制访问，并使用 Salesforce 的身份提供商 (IdP) 功能在用户和集成之间建立端到端的责任。统一的 IAM 层降低了操作复杂性，并强化了身份验证表面。
* **应用最小权限原则：**设计角色是为了精确，而不是方便。使用 Salesforce 的标准权限集作为职责分离的基础，确保用户只访问必要的内容。避免权限的过度自定义 — 每个偏差都会增加维护开销和意外访问的风险。
* **建立多层数据治理框架：**使用数据空间按业务部门或品牌隔离数据，并使用对象级、字段级和记录级安全性（OLS、FLS、RLS）实施基于属性的访问控制 (ABAC)。使用动态数据屏蔽实时保护敏感信息，而不妨碍分析或可用性。这种分层模型确保了治理在数据跨域扩展时保持一致。
* **战略性地利用加密和安全集成：**对于敏感工作负载，使用客户管理密钥 (CMK) 部署平台加密，以维护加密生命周期的主权。使用命名凭据和专用连接来保护所有系统到系统的集成 — 消除硬编码密码，并确保所有流量保持专用、合规和可审计。
* **构建持续安全操作计划：**安全不仅仅止于配置，它还取决于运营纪律。通过对事件日志和访问跟踪的定期审计审查来补充自动监控。建立专门的安全操作 (SecOps) 功能，以识别异常、调查威胁并验证合规性。目标：及早发现，快速响应，并持续改善姿势。
### 前进路径：构建具有弹性的可信数据 360
通向安全和智能企业的旅程不会因为部署而结束 — 它通过纪律、设计和 Trust 而发展。Salesforce Data 360 提供了架构基础，但当组织将安全、治理和智能作为一个统一的运动来操作时，真正的价值就会显现出来。
企业不应将 Data 360 视为另一个数据平台，而应将其视为一个安全的、可组合的Trust层，在一个治理框架下连接数据、AI 和客户参与。通过采用*安全设计*理念、在每个层强制实施最小权限并将专用连接扩展到所有数据流,组织将合规性从复选框转化为竞争优势。
下一步是持续现代化 — 将审计自动化、策略实施和加密生命周期管理嵌入日常运营。随着企业向 AI 驱动的代理架构发展，今天保护数据的相同原则将成为明天 AI 治理的支柱 — 确保每个模型、代理和决策在设计上都是可解释、策略感知和合规的。
最终,Trust 成为数字转型的新货币。借助 Salesforce Data 360，企业可以自信地扩展其数据生态系统，因为企业知道每个字节、每个连接和每个见解都是安全、受管和完整激活的。
## 关于作者
**Krishna Chalamasandra** 是一位经验丰富的网络安全专家,在信息安全技术和合规方面拥有 25 年以上的经验。在 Salesforce 中,他是客户值得信赖的顾问，也是 CISO 组织内部安全与合规 Customer Trust 职能的主要领导。此前,Krishna 在思科工作了 10 年,领导了 IAM、网络安全和 PKI 的安全架构,并推动了包括 ISO 27001、SOC 1-3、PCI、FedRAMP 和 FIPS 140-2 在内的密钥认证。他还在 Novell 工作了 8 年多，为受监管的全球客户实施基础设施级控制并支持复杂的安全审查。
**Yugandhar Bora** 是 Salesforce 的软件工程架构师,专门从事数据和智能应用程序平台中的数据架构。他领导企业架构审查委员会 (EARB) 专注于数据治理和统一数据模型的举措，同时为自动化平台配置解决方案做出贡献。