Bảo vệ, lưu giữ và chứng minh

🌐 Cũng có bằng 28 ngôn ngữ khác

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh

Mô-đun 6 trong 6 của chương Chất lượng và quản trị dữ liệu, chương 5 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Sự đồng ý và quyền được lãng quên · Tiếp theo: chương sau, Dữ liệu chủ và danh tính

Câu hỏi mô-đun này trả lời: Làm thế nào để bảo vệ dữ liệu, giữ nó đủ lâu theo yêu cầu, và chứng minh được điều đó?

Chúng ta đã đặt chủ sở hữu và chính sách, ngăn dữ liệu xấu, viết từ điển, truy vết dòng dõi, phân loại những gì quan trọng, tìm hiểu các luật và mô hình hóa sự đồng ý. Giờ chúng ta phải vận hành nó. Dữ liệu đến, được dùng, được sao chép và thay đổi, già đi, và cuối cùng một phần trong đó phải ra đi. Và một ngày nào đó sẽ có người hỏi: hãy chứng minh điều gì đã xảy ra.

Quản trị đi theo dữ liệu

Tôi không nghĩ về quản trị như một tính năng. Tôi nghĩ về những gì xảy ra với dữ liệu từ lúc nó đi vào cho đến khi chúng ta dùng xong nó:

Thu nhận → Phân loại → Bảo vệ → Sử dụng → Lưu giữ → Xóa → Kiểm toán

Không phải bảy quy trình kỹ thuật: bảy câu hỏi mà kiến trúc phải trả lời. Thu nhận và phân loại chúng ta đã trình bày: ngăn những lỗi đắt giá (mô-đun 2), và biết dữ liệu nào nhạy cảm (mô-đun 3). Việc phân loại quyết định những gì xảy ra ở mọi giai đoạn sau, nên mô-đun này tiếp tục từ đó.

Click to enlarge

Bảy câu hỏi xuyên suốt vòng đời của dữ liệu. Công cụ hỗ trợ chính sách; chúng không định nghĩa chính sách.

Bảo vệ: biện pháp kiểm soát phải phù hợp với dữ liệu

Ai được thấy nó, thay đổi nó, nhận nó? Nó có nên được mã hóa, được che bên ngoài môi trường thật, được xuất ra, được tác tử tiếp cận không? Đây là nơi bảo mật Salesforce trở thành một phần của quản trị dữ liệu: chia sẻ, quyền đối tượng và trường, mã hóa, che dữ liệu, quyền truy cập của tích hợp. Những chủ đề đó lấp đầy cả các khóa học, nên tôi sẽ không dạy lại. Điểm về quản trị: việc bảo vệ đi theo phân loại và chính sách. Không phải trường nào cũng cần cùng mức bảo vệ, không phải người dùng nào cũng cần cùng quyền truy cập, không phải hệ thống phía sau nào cũng cần mọi trường.

Mã hóa là một biện pháp kiểm soát, không phải là tuân thủ

Với dữ liệu chịu quản lý, mã hóa khi lưu trữ có thể là bắt buộc, và lập trường của tôi là Shield là câu trả lời cho các yêu cầu pháp lý then chốt như vậy. Shield Platform Encryption mã hóa các trường và tệp khi lưu trữ. Nhưng “chúng tôi đã mã hóa, nên chúng tôi tuân thủ” sai đến hai lần. Mã hóa là một biện pháp kiểm soát giữa nhiều biện pháp khác: truy cập, lưu giữ, kiểm toán, sự đồng ý, giám sát, tối thiểu hóa và xóa. Và nó có những đánh đổi về chức năng mà bạn phải thiết kế cho chúng từ đầu. Với cơ chế xác suất (probabilistic) mặc định, một trường được mã hóa không dùng được trong các mệnh đề SOQL WHERE, GROUP BY hay ORDER BY hoặc trong bộ lọc quản lý dữ liệu; mã hóa tất định (deterministic) hy sinh một chút độ mạnh để bạn có thể lọc theo trường đó. Trường được mã hóa không thể điều khiển quy tắc chia sẻ dựa trên tiêu chí, và bạn không thể sắp xếp list view theo chúng (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab), tiếng Anh). Vì vậy mã hóa không phải là một ô đánh dấu ở cuối cùng. Đó là một quyết định kiến trúc. Chương về bảo mật dữ liệu đi sâu hơn.

Đừng sao chép rủi ro của môi trường thật vào sandbox

Môi trường thật đã được khóa chặt. Rồi ai đó làm mới một full sandbox, và giờ lập trình viên, người kiểm thử, nhà thầu và các tích hợp kiểm thử đều giữ bản sao dữ liệu cá nhân thật mà họ chưa bao giờ cần. Môi trường đã thay đổi; độ nhạy cảm của dữ liệu thì không. Các công cụ che dữ liệu của Salesforce tồn tại chính là cho việc này. Lưu ý một thay đổi: gói được quản lý Data Mask hết hạn dịch vụ vào 31 tháng 12 năm 2026, và sản phẩm kế nhiệm là Data Mask & Seed (Data Mask (Legacy) (opens in a new tab), tiếng Anh). Nhưng công cụ hỗ trợ chính sách, và câu hỏi đến trước: môi trường này có thực sự cần dữ liệu nhạy cảm thật không? Nếu dữ liệu thực tế nhưng không nhạy cảm làm được việc kiểm thử, đó là câu trả lời tốt hơn.

Sử dụng: sự cho phép không chỉ là chuyện con người

Người dùng, tích hợp, phân tích, đối tác, tự động hóa và tác tử đều dùng dữ liệu. Sự đồng ý (mô-đun 5), quyền sở hữu (mô-đun 1) và phân loại (mô-đun 3) gặp nhau ở đây lúc hệ thống đang chạy. Người dùng này có nên thấy số điện thoại của Người nhận không? Tích hợp này có nên nhận nó không, hay Snowflake, hay tác tử này để neo dữ liệu? Câu trả lời không thể là “ừ thì, về mặt kỹ thuật nó làm được”. Đó là sự khác biệt giữa năng lực và quản trị: kiến trúc quyết định liệu nó có nên không.

Lưu giữ: giữ mọi thứ mãi mãi không phải là trung lập

Nhiều tổ chức có một chính sách lưu giữ vô tình: mãi mãi. Không ai quyết định điều đó; dung lượng có sẵn, nên dữ liệu ở lại. Nhưng giữ dữ liệu tốn dung lượng và hiệu năng, mở rộng mức độ phơi nhiễm về quyền riêng tư và bảo mật, thêm nghĩa vụ khám phá, và cho bạn thêm nhiều chỗ phải tìm khi ai đó yêu cầu được lãng quên. Với mỗi loại dữ liệu quan trọng: vì sao giữ nó, bao lâu, cái gì bắt đầu tính giờ, có mức tối thiểu theo luật hay mức tối đa về quyền riêng tư không, và chuyện gì xảy ra khi hết hạn: lưu trữ, xóa, khử định danh?

Và lưu trữ không giống với giải quyết việc lưu giữ. “Chúng tôi đã lưu trữ nó.” Yêu cầu lưu giữ có biến mất không? Yêu cầu quyền riêng tư? Bảo mật? Bạn đã thay đổi nơi dữ liệu nằm, không phải bản chất của nó. Một kho lưu trữ cần kiểm soát truy cập, quy tắc lưu giữ và xóa, khả năng khám phá và kiểm toán. Chuyển dữ liệu cá nhân vào một kho lưu trữ mà mọi người đều quên, và việc quản trị vừa trở nên tệ hơn.

Xóa: vòng đời cần một lối ra

Việc xóa không chỉ dành cho các yêu cầu quyền riêng tư cá nhân. Dữ liệu đến cuối thời hạn lưu giữ; bản ghi tạm thời sống lâu hơn công dụng của chúng; kho lưu trữ hết hạn; một quy trình khử định danh sau một thời gian xác định. Dù chính sách nói gì, kiến trúc cần một lối ra, không phải thu nhận → lưu → lưu thêm → lưu mãi mãi. Và như mô-đun 5 đã cho thấy, xóa bản ghi Salesforce là không đủ khi các bản sao nằm ở nơi khác.

Lịch sử cũng là dữ liệu

Đôi khi giá trị hiện tại là không đủ. Tên pháp lý của một đối tác, phân loại của một khách hàng, một trạng thái đồng ý, một thuộc tính tài chính: nghiệp vụ hay một cơ quan quản lý có thể cần biết trước đây nó là gì, nó thay đổi khi nào và ai đã thay đổi nó. Lịch sử đó là dữ liệu, và nó cần quyết định lưu giữ riêng.

Theo dõi lịch sử trường chuẩn theo dõi tối đa 20 trường mỗi đối tượng và giữ các thay đổi tối đa 18 tháng, và tối đa 24 tháng chỉ khi truy cập qua API, bằng Data Loader hoặc queryAll() (Field History Tracking Overview (opens in a new tab), tiếng Anh). Và với các trường văn bản dài, nó chỉ ghi nhận rằng trường đã được sửa, chứ không ghi nội dung: một lỗ hổng nếu đó là bằng chứng của bạn. Field Audit Trail, một phần của Shield hoặc mua riêng, theo dõi tối đa 200 trường mỗi đối tượng và giữ lịch sử cho đến khi bạn xóa nó, trong một kho lưu trữ bạn truy cập qua API (Field Audit Trail (opens in a new tab), tiếng Anh). Lập trường của tôi: lịch sử trường chuẩn là mặc định; dùng Field Audit Trail khi một quy định hay nghĩa vụ tuân thủ đòi hỏi lịch sử dài hơn và chứng minh được. Không phải vì “kiểm toán nghe có vẻ hay”.

Kiểm toán và giám sát không giống nhau

Lịch sử trường trả lời các câu hỏi về thay đổi trên những trường được chọn. Những câu hỏi rộng hơn (ai đã đăng nhập, ai đã xuất dữ liệu, API nào đã được gọi, ai đã xem cái gì) là giám sát, và đó là Event Monitoring. Theo kinh nghiệm của tôi, nó thường cần thiết với những khách hàng chịu quản lý chặt hơn, và đây là lập trường mạnh nhất của tôi trong chương này: hãy thiết lập nó trước khi bạn cần, và dẫn các sự kiện vào một kho, như Splunk hay một SIEM khác, từ trước.

Đây là lý do. Tệp nhật ký sự kiện được giữ 1 ngày nếu không có gói bổ sung, và chỉ cho một số loại sự kiện; mặc định 30 ngày với Shield hoặc gói bổ sung Event Monitoring, và tối đa 365 ngày nếu bạn kéo dài thời hạn lưu giữ (Event Monitoring FAQ (opens in a new tab), tiếng Anh). Bất cứ thứ gì cũ hơn sẽ mất, trừ khi bạn đã xuất nó ra. Và nhật ký trả phí không thể truy xuất cho bất kỳ khoảng thời gian nào trước khi hợp đồng của bạn bắt đầu (cùng FAQ đó): mua gói bổ sung sau sự cố không mang quá khứ trở lại. Vì vậy một trong những cuộc trò chuyện tệ nhất mà một kiến trúc sư có thể gặp là: “Chúng ta có xem được chuyện gì đã xảy ra sáu tháng trước không?” “Không.” “Tại sao?” “Chúng ta đã không ghi lại nó.” Đừng để gặp sự cố rồi mới phát hiện ra mình đã không ghi lại và lưu trữ những sự kiện đó. Lúc đó câu trả lời đơn giản là đã mất.

Click to enlarge

Hãy thiết lập trước khi bạn cần.

Nhưng đừng nhảy sang “ghi nhật ký mọi thứ”. Bạn đang cố chứng minh điều gì? Những sự kiện nào quan trọng, ai cần chúng, trong bao lâu, ai được đọc nhật ký, và chính nhật ký có thể chứa dữ liệu nhạy cảm không? Ghi nhật ký tạo ra dữ liệu, và dữ liệu đó cũng cần được quản trị. Và bằng chứng cần một chủ sở hữu: ai sở hữu kho, xem xét các cảnh báo, kiểm tra việc lưu giữ có hoạt động, nhận ra nguồn cấp đã âm thầm thất bại ba tháng trước? Công nghệ mà không có quyền sở hữu thì không phải là quản trị; chúng ta quay lại chủ sở hữu, người quản lý dữ liệu và người vận hành của mô-đun 1.

Chứng minh biện pháp kiểm soát, không chỉ cấu hình

“Dữ liệu Người nhận chỉ có sẵn cho các tổ được phân công cho điểm dừng.” Làm sao chúng ta biết? Cấu hình bảo mật cho thấy điều gì lẽ ra phải xảy ra. Bằng chứng vận hành (ai thực sự đã truy cập nó, những lần xuất dữ liệu bất thường, một tích hợp kéo nó ra, kiểm soát truy cập bị thay đổi) cho thấy điều gì đã xảy ra. Quản trị tốt thường cần cả hai.

Ngoài kỳ thi: AI thay đổi điều gì. Khi tác tử chuyển từ trả lời sang hành động, quản trị cần bằng chứng về những gì tác tử đã thấy, đã quyết định hay đã tạo ra, và đã làm, cùng với ai hay cái gì đã khởi động nó, theo chính sách nào. Các cơ chế ghi nhật ký sẽ thay đổi; yêu cầu thì không: nếu một hành động tự động quan trọng, hãy thiết kế ngay từ bây giờ cách bạn sẽ tái dựng nó sau này.

Steve Trucking: vòng đời trên một trường

Lấy số điện thoại của Người nhận. Thu nhận: nó đến trên bảng kê hàng của đối tác; kiểm tra nó dùng được ở nơi quy trình cần. Phân loại: dữ liệu cá nhân. Bảo vệ: chỉ những người và hệ thống có nhu cầu vận hành mới nhận được nó, và tổ giao hàng chỉ thấy nó cho các điểm dừng của chính họ, trong ngày. Sử dụng: tổ giao hàng phối hợp lần giao; hệ thống nhắn tin dùng nó cho một mục đích đã được phê duyệt; một tác tử chỉ dùng nó nếu chính sách cho phép. Lưu giữ: trong thời gian mà chính sách nghiệp vụ và quyền riêng tư đã phê duyệt quy định. Xóa hoặc khử định danh: khi thời hạn đó kết thúc hoặc có một yêu cầu hợp lệ, trên mọi bản sao trong bản đồ hệ thống. Kiểm toán: giữ bằng chứng rằng các biện pháp kiểm soát và hành động đã diễn ra.

Giờ lấy một mã trung tâm phân phối. Thu nhận nó chính xác, phân loại nó là dữ liệu tham chiếu không nhạy cảm, bảo vệ nó bằng quyền truy cập vận hành thông thường, dùng nó rộng rãi, lưu giữ nó theo nhu cầu nghiệp vụ, và kiểm toán các thay đổi nếu chúng quan trọng. Cùng một vòng đời, biện pháp kiểm soát khác nhau. Đó là mục đích của việc phân loại.

Quản trị không bao giờ kết thúc

Một quy định mới xuất hiện. Một hệ thống hay tích hợp mới tạo thêm một bản sao. Một đội nghĩ ra thêm một trường. Một nền tảng mới đi vào hoạt động. Một tác tử được cấp quyền truy cập. Một quy tắc lưu giữ thay đổi. Một Đối tác bán lẻ mới đến. Kiến trúc dịch chuyển, và quản trị dịch chuyển theo. Mục tiêu không phải là dữ liệu hoàn hảo, biện pháp kiểm soát vô tận hay một tài liệu quản trị không ai đọc. Mà là những quyết định có chủ ý về dữ liệu, được xây vào kiến trúc.

Kiến trúc sư quyết định gì ở đây

• Mỗi loại dữ liệu nhận những biện pháp bảo vệ nào, dựa trên phân loại, chính sách và việc sử dụng thực tế, bao gồm cả những đánh đổi của mã hóa.
• Dữ liệu và lịch sử của nó được giữ bao lâu, cái gì bắt đầu tính giờ, và chuyện gì xảy ra khi hết hạn.
• Khi nào lịch sử trường chuẩn là đủ và khi nào một quy định đòi hỏi Field Audit Trail.
• Những sự kiện nào được ghi lại, bằng chứng được lưu ở đâu vượt quá thời hạn lưu giữ của nền tảng, và ai sở hữu nó.
• Kiến trúc chứng minh những hành động quan trọng của con người, tích hợp và tác tử sau khi chúng xảy ra như thế nào.

Chương này bắt đầu với một ý tưởng: quản trị được thiết kế vào org, không phải viết bên cạnh nó. Chủ sở hữu đặt chính sách và kiến trúc sư thực thi nó. Ngăn dữ liệu xấu ở nơi quan trọng. Biết dữ liệu của bạn có nghĩa là gì, nó đến từ đâu và nó nhạy cảm đến mức nào. Tôn trọng luật, mô hình hóa sự đồng ý, kiểm soát dữ liệu cá nhân đi đâu. Bảo vệ, lưu giữ và xóa theo chính sách. Và thu thập bằng chứng trước khi có ai yêu cầu, vì sáu tháng sau một sự cố là thời điểm tồi tệ để phát hiện ra bằng chứng chỉ tồn tại trong ba mươi ngày.

Tìm hiểu thêm

• Salesforce Help, General Shield Platform Encryption Considerations (opens in a new tab) và Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
• Salesforce Help, Field History Tracking Overview (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
• Salesforce Help, Field Audit Trail (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
• Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
• Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.