保護、保留與證明
另有 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。