保护、保留与证明
另有 28 种语言版本
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
第 6 个模块，共 6 个，属于 Data Architect 课程第 5 章数据质量与治理。每个模块都可以单独阅读。 上一篇：同意与被遗忘权 · 下一篇：下一章主数据与身份
**本模块回答的问题：**如何保护数据，按要求的期限保留它，并证明这一切？
我们已经确定了所有者和策略，把坏数据挡在门外，写好了词典，追溯了血缘，给重要的东西分了类，了解了法律，并为同意建了模。现在我们必须让它运转起来。数据进来，被使用、复制和修改，逐渐老去，最终其中一些必须离开。而总有一天会有人问：证明发生了什么。
治理跟着数据走
Section titled “治理跟着数据走 ”我不把治理看作某一项功能。我思考的是数据从进入的那一刻起，直到我们用完它为止，都经历了什么：
采集 → 分类 → 保护 → 使用 → 保留 → 删除 → 审计
这不是七个技术流程，而是架构必须回答的七个问题。采集和分类我们已经讲过：把代价高昂的错误挡在门外（模块 2），并知道哪些数据是敏感的（模块 3）。分类决定了之后每个阶段会发生什么，所以本模块从那里接着讲。
贯穿数据一生的七个问题。工具支撑策略；它们并不定义策略。
保护：让控制与数据相匹配
Section titled “保护：让控制与数据相匹配 ”谁可以看到它、修改它、接收它？它应该被加密吗，在生产环境之外应该被掩码吗，可以导出吗，智能体可以访问吗？这正是 Salesforce 安全成为数据治理一部分的地方：共享、对象和字段权限、加密、掩码、集成访问。这些主题能占满好几门课，所以我不会重新讲一遍。治理上的要点是：**保护跟随分类和策略。**不是每个字段都需要同样的保护，不是每个用户都需要同样的访问权限，也不是每个下游系统都需要每一个字段。
加密是一种控制，而不等于合规
Section titled “加密是一种控制，而不等于合规 ”对于受监管的数据，可能会要求静态加密，而我的立场是：Shield 是应对这类关键监管需求的答案。Shield Platform Encryption 对静态的字段和文件进行加密。但“我们加密了，所以我们合规了”错了两次。加密只是访问、保留、审计、同意、监控、最小化和删除等众多控制中的一种。而且它有功能上的权衡，需要你在一开始就为之设计。在默认的概率性加密方案下，加密字段不能用在 SOQL 的 WHERE、GROUP BY 或 ORDER BY 子句中，也不能用在数据管理的筛选条件中；确定性加密牺牲一点强度，让你能够按这个字段筛选。加密字段不能驱动基于条件的共享规则，你也不能按它们给列表视图排序（General Shield Platform Encryption Considerations (opens in a new tab)；Filter Encrypted Data with Deterministic Encryption (opens in a new tab)，英文）。所以加密不是最后勾一下的复选框，而是一个架构决定。数据安全那一章会深入讨论。
不要把生产环境的风险复制到沙盒里
Section titled “不要把生产环境的风险复制到沙盒里 ”生产环境被锁得严严实实。然后有人刷新了一个完整沙盒，开发人员、测试人员、外包人员和测试集成现在都持有他们从来不需要的真实个人数据的副本。环境变了；数据的敏感性并没有变。Salesforce 的掩码工具正是为此而存在的。注意一个变化：Data Mask 托管软件包将于 2026 年 12 月 31 日停止服务，它的继任者是 Data Mask & Seed（Data Mask (Legacy) (opens in a new tab)，英文）。但工具是为策略服务的，问题要先问：**这个环境到底需要真实的敏感数据吗？**如果逼真但不敏感的数据就能完成测试，那是更好的答案。
使用：许可不只关乎人
Section titled “使用：许可不只关乎人 ”用户、集成、分析、合作伙伴、自动化和智能体都在使用数据。同意（模块 5）、所有权（模块 1）和分类（模块 3）在运行时于此相遇。这个用户应该看到收货人的电话号码吗？这个集成应该拿到它吗？Snowflake 呢？这个智能体可以把它作为落地依据吗？答案不能是“嗯，技术上可以”。这就是能力和治理的区别：架构决定的是它是否应该。
保留：永远保留一切并不是中性的
Section titled “保留：永远保留一切并不是中性的 ”很多组织都有一种无意中形成的保留策略：永远。没人决定过；存储空间有，数据就留下了。但保留数据是有代价的：存储和性能，扩大的隐私和安全风险，增加的取证义务，以及当有人要求被遗忘时更多需要搜索的地方。对每一个重要的类别都要问：为什么保留它，保留多久，从什么时候开始计时，是否有法律规定的最短期限或隐私上的最长期限，期满时怎么办：归档、删除、去标识化？
而归档并不等于解决了保留问题。“我们归档了。”保留要求消失了吗？隐私要求呢？安全呢？你改变的是数据放在哪里，而不是它是什么。一个档案库需要访问控制、保留和删除规则、取证和审计。把个人数据移到一个大家都忘了的档案库里，治理只会变得更糟。
删除：生命周期需要一个出口
Section titled “删除：生命周期需要一个出口 ”删除不只是为了个人的隐私请求。数据到了保留期限的终点；临时记录在用完之后仍然存在；档案库到期；某个流程在设定的时间后做去标识化。不管策略怎么说，架构都需要一个出口，而不是采集 → 存储 → 存更多 → 永远存储。而正如模块 5 所示，当副本存在于别处时，删除 Salesforce 记录是不够的。
历史也是数据
Section titled “历史也是数据 ”有时当前的值是不够的。一个合作伙伴的法定名称，一个客户的分类，一个同意状态，一个财务属性：业务方或监管机构可能需要知道它以前是什么，什么时候变的，是谁改的。这份历史就是数据，它需要自己的保留决定。
标准的字段历史记录跟踪每个对象最多跟踪 20 个字段，变更最多保留 18 个月，只有通过 API（使用 Data Loader 或 queryAll()）才能访问最多 24 个月的历史（Field History Tracking Overview (opens in a new tab)，英文）。而对于长文本字段，它只记录字段被编辑过，不记录内容：如果那就是你的证据，这就是一个缺口。Field Audit Trail 是 Shield 的一部分，也可以单独购买，每个对象最多跟踪 200 个字段，并且会把历史一直保留到你删除为止，存放在一个通过 API 访问的档案库中（Field Audit Trail (opens in a new tab)，英文）。我的立场是：**标准的字段历史记录是默认选择；当某项法规或合规义务要求更长、可证明的历史时，才使用 Field Audit Trail。**而不是因为“审计听起来不错”。
审计和监控不是一回事
Section titled “审计和监控不是一回事 ”字段历史记录回答的是关于选定字段变更的问题。更广泛的问题（谁登录了，谁导出了数据，调用了哪些 API，谁查看了什么）属于监控，那就是 Event Monitoring。根据我的经验，受监管程度更高的客户通常需要它，而这是我在本章中最坚定的立场：在需要之前就设置好它，并提前把事件汇集到一个存储库中，比如 Splunk 或其他 SIEM。
原因是这样的。没有附加组件时，事件日志文件只保留 1 天，而且只针对部分事件类型；有了 Shield 或 Event Monitoring 附加组件，默认保留 30 天，如果延长保留期，最多可达 365 天（Event Monitoring FAQ (opens in a new tab)，英文）。更早的数据，除非你导出过，否则就没了。而且付费日志无法获取合同开始之前任何时段的数据（同一份 FAQ）：事故发生后再购买附加组件，也找不回过去。所以架构师可能经历的最糟糕的对话之一是这样的：“我们能看看六个月前发生了什么吗？”“不能。”“为什么？”“我们当时没有采集。”**你不会想在遇到问题之后，才发现自己一直没有采集和存储这些事件。**到那时，答案就是没了。
在需要之前就设置好它。
但也不要摆到另一个极端，“什么都记录”。你想证明什么？哪些事件重要，谁需要它们，保留多久，谁可以读取日志，日志本身会不会包含敏感数据？记录日志会产生数据，而这些数据也需要治理。证据也需要一个所有者：谁拥有这个存储库，谁审查告警，谁检查保留是否正常运作，谁会注意到数据源三个月前就悄无声息地断了？没有所有权的技术不是治理；我们又回到了模块 1 的所有者、数据专员和数据保管人。
证明控制措施，而不只是配置
Section titled “证明控制措施，而不只是配置 ”“收货人数据只对分配到该停靠点的配送小组可用。”我们怎么知道？安全配置显示的是应该发生什么。运营证据（谁实际访问了它，异常的导出，某个集成拉取了它，访问控制被修改了）显示的是实际发生了什么。好的治理往往两者都需要。
**考试之外：AI 改变了什么。**随着智能体从回答走向行动，治理需要证据：智能体看到了什么，它决定或生成了什么，它做了什么，以及是谁或什么启动了它，依据的是哪项策略。记录日志的机制会变；需求不会变：如果一个自主行动很重要，现在就设计好以后如何重建它。
Steve Trucking：一个字段上的生命周期
Section titled “Steve Trucking：一个字段上的生命周期 ”拿收货人的电话号码来说。*采集：*它随合作伙伴的装货清单到达；检查它在流程需要的地方是否可用。*分类：*个人数据。*保护：*只有有运营需要的人和系统才能收到它，配送小组只能在当天、只为自己的停靠点看到它。*使用：*配送小组用它协调配送；消息服务把它用于经批准的目的；只有在策略允许时，智能体才能使用它。*保留：*按照经批准的业务和隐私策略规定的期限。*删除或去标识化：*当期限届满或收到有效请求时，在全景中的每一份副本上执行。*审计：*保留控制措施和操作确实发生过的证据。
再拿一个配送中心代码来说。准确地采集它，把它分类为不敏感的参考数据，用普通的运营访问权限保护它，广泛地使用它，按业务需要保留它，如果变更很重要就审计变更。同样的生命周期，不同的控制。这就是分类的用途。
治理永远没有完成的一天
Section titled “治理永远没有完成的一天 ”一项新法规出现了。一个新系统或新集成又制造了一份副本。一个团队又发明了一个字段。一个新平台上线了。一个智能体获得了访问权限。一条保留规则变了。一个新的零售合作伙伴来了。架构在变，治理也随之而变。目标不是完美的数据、无穷无尽的控制，或者一份没人读的治理文档，而是对数据做出有意识的决定，并把它们构建进架构里。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 根据分类、策略和实际使用，每一类数据得到哪些保护控制，包括加密的权衡。
- 数据及其历史保留多久，从什么时候开始计时，期满时怎么办。
- 什么时候标准的字段历史记录就够了，什么时候某项法规要求使用 Field Audit Trail。
- 采集哪些事件，在平台的保留期之外证据存放在哪里，以及谁拥有它。
- 架构如何在事后证明人、集成和智能体的重要操作。
这一章从一个想法开始：治理是设计进 org 的，而不是写在它旁边的。所有者制定策略，架构师负责执行。在重要的地方把坏数据挡在门外。了解你的数据意味着什么、从哪里来、有多敏感。尊重法律，为同意建模，控制个人数据去往何处。按策略保护、保留和删除。并且在任何人要求之前就采集好证据，因为在事件发生六个月后才发现证据只存在了三十天，是一个糟糕透顶的时刻。
- Salesforce Help，General Shield Platform Encryption Considerations (opens in a new tab) 和 Filter Encrypted Data with Deterministic Encryption (opens in a new tab)（英文），查阅日期 2026-10-14。
- Salesforce Help，Field History Tracking Overview (opens in a new tab)（英文），查阅日期 2026-10-14。
- Salesforce Help，Field Audit Trail (opens in a new tab)（英文），查阅日期 2026-10-14。
- Salesforce Help，Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab)（英文），查阅日期 2026-10-14。
- Salesforce Help，Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab)（英文），查阅日期 2026-10-14。