Data masking là gì?

Mục lục

1. Data masking là gì và giải quyết vấn đề gì?
2. Data masking hoạt động như thế nào?
3. Có những loại data masking nào?
4. Các kỹ thuật che dữ liệu phổ biến
5. Ví dụ với dữ liệu Việt Nam: che CCCD, số điện thoại, số tài khoản
6. Data masking khác gì mã hoá, ẩn danh hoá và dữ liệu tổng hợp?
7. Che rồi có còn là dữ liệu cá nhân không?
8. Ưu điểm, hạn chế và rủi ro khi che dữ liệu
9. Công cụ và tính năng có sẵn
10. Khi nào nên và không nên dùng data masking
11. Checklist triển khai và lỗi thường gặp
12. Câu hỏi thường gặp

Data masking là gì và giải quyết vấn đề gì?

Data masking là quá trình tạo ra một phiên bản dữ liệu giả nhưng thực tế (realistic), có cùng định dạng với dữ liệu gốc. Theo mô tả của Imperva, mục tiêu là bảo vệ dữ liệu nhạy cảm nhưng vẫn có bản thay thế dùng được khi không cần dữ liệu thật, ví dụ đào tạo người dùng, demo bán hàng hoặc kiểm thử phần mềm.

Vấn đề thật sự mà masking giải quyết là dữ liệu production bị sao chép ra những nơi kém an toàn hơn. Một bản dump cơ sở dữ liệu khách hàng đưa vào máy tester, gửi cho nhà thầu hoặc nạp vào môi trường UAT thường có ít kiểm soát hơn hệ thống chính. Bằng sáng chế của IBM mô tả đúng tình huống này: masking dùng khi dữ liệu chứa thông tin nhạy cảm cần được sao chép sang môi trường ít tin cậy hơn.

Ba nhóm người dùng dữ liệu hay gặp trong doanh nghiệp Việt Nam:

• Đội phát triển và kiểm thử: cần dữ liệu có hình dạng giống thật (độ dài tên, định dạng số điện thoại, quan hệ giữa các bảng) để bắt lỗi, nhưng không cần biết khách hàng là ai.
• Đội phân tích và báo cáo: cần xu hướng theo độ tuổi, khu vực, giá trị đơn hàng, không cần họ tên.
• Đối tác bên ngoài: đơn vị gia công phần mềm, công ty tư vấn, nhà cung cấp BI cần mẫu dữ liệu để làm việc.

Data masking hoạt động như thế nào?

Về cơ chế, một hệ thống masking gồm ba phần: danh sách cột nhạy cảm cần che, quy tắc che cho từng cột và bộ máy áp dụng quy tắc. Một nghiên cứu mô tả dịch vụ masking dạng chính sách: người dùng chọn vị trí trong dữ liệu cần che, rồi định nghĩa thao tác áp dụng như xoá hoặc mã hoá.

Quy trình triển khai thường đi theo thứ tự sau:

1. Khám phá dữ liệu nhạy cảm: quét schema và nội dung để tìm cột chứa họ tên, số điện thoại, email, CCCD, địa chỉ, số tài khoản, ghi chú tự do. Cột ghi chú (free text) hay bị bỏ sót vì nhân viên có thể gõ cả số điện thoại vào đó. Công cụ data catalog giúp gắn nhãn cột nhạy cảm để việc quét không phải làm lại mỗi lần.
2. Chọn quy tắc theo mục đích dùng: bản cho tester cần giữ định dạng và khoá liên kết; bản cho phân tích cần giữ phân bố thống kê.
3. Giữ tính nhất quán tham chiếu: cùng một khách hàng phải được che ra cùng một giá trị ở mọi bảng, nếu không phép JOIN giữa đơn hàng và khách hàng sẽ gãy.
4. Chạy và kiểm tra bản đã che: đối chiếu số dòng, ràng buộc khoá ngoại, và thử tìm ngược xem có còn giá trị thật nào lọt qua không.
5. Phân phối bản đã che: chỉ bản đã che được đưa sang môi trường ngoài production.

Có những loại data masking nào?

Static data masking (che tĩnh)

Static masking tạo ra một bản sao đã được làm sạch của cơ sở dữ liệu. Theo Imperva, quy trình thường là sao lưu cơ sở dữ liệu production, nạp vào môi trường riêng, loại bỏ dữ liệu không cần thiết rồi che dữ liệu khi nó đang ở trạng thái tĩnh. Đây là lựa chọn phổ biến cho môi trường test, UAT, đào tạo và dữ liệu giao cho nhà thầu. Điểm mạnh là bản che nằm ở nơi khác, nên nếu bị lộ thì không có giá trị thật. Điểm yếu là phải chạy lại mỗi lần làm mới dữ liệu, và bản sao tốn dung lượng.

Dynamic data masking (che động)

Dynamic masking không tạo bản sao. Dữ liệu thật vẫn nằm trong production, còn kết quả trả về được che tuỳ người hỏi. Imperva mô tả đây là một dạng che nội dung (redaction) áp mặt nạ dựa trên người dùng hoặc nhóm để ẩn một phần dữ liệu nhạy cảm. Cùng một câu truy vấn, nhân viên chăm sóc khách hàng thấy số điện thoại dạng che, còn kế toán có quyền thấy đầy đủ.

Các biến thể khác

• On-the-fly masking: che dữ liệu ngay trong luồng chuyển, trước khi nó được ghi vào đích. Phù hợp khi nạp dữ liệu sang môi trường test qua một quy trình ETL mà bạn không muốn dữ liệu thật chạm ổ đĩa trung gian.
• Deterministic masking (tất định): cùng giá trị đầu vào luôn cho cùng giá trị đầu ra, để giữ được quan hệ giữa các bảng và hệ thống.
• Che trên ứng dụng hoặc API: lớp middleware hoặc API gateway che trường nhạy cảm trong JSON trước khi trả về.

Các kỹ thuật che dữ liệu phổ biến

Mỗi kỹ thuật đánh đổi giữa mức bảo vệ và độ hữu dụng của dữ liệu. Bảng dưới đây so sánh các kỹ thuật thường gặp.

Kỹ thuật	Cách làm	Ví dụ minh hoạ	Giữ được gì	Điểm cần cẩn thận
Thay thế (substitution)	Đổi giá trị bằng giá trị giả từ danh sách	Nguyễn Văn An thành Trần Minh Khoa	Định dạng, độ dài tương đối	Danh sách tên quá nhỏ làm trùng nhiều dòng
Xáo trộn (shuffling)	Hoán vị giá trị giữa các dòng trong cùng cột	Đổi lương giữa các nhân viên	Phân bố thống kê của cột	Mỗi giá trị vẫn là thật; giá trị hiếm có thể bị nhận ra
Dịch số và ngày (variance)	Cộng hoặc trừ ngẫu nhiên trong biên độ	Ngày sinh lệch ±30 ngày	Xu hướng theo thời gian, độ tuổi gần đúng	Biên độ nhỏ thì dễ đoán ngược
Che một phần (partial)	Giữ vài ký tự, thay phần còn lại bằng ký hiệu	09****5678	Nhận diện để đối soát với khách hàng	Phần giữ lại không được đủ để tái tạo giá trị
Xoá hoặc NULL	Bỏ giá trị	Cột ghi chú để trống	Cấu trúc bảng	Làm mất khả năng kiểm thử luồng có dùng cột đó
Băm có muối (salted hash)	Băm giá trị cùng một chuỗi muối bí mật	Email thành chuỗi băm	Khả năng JOIN theo cột đã băm	Định dạng bị đổi; lộ muối thì dò ngược được
Token hoá (tokenization)	Thay bằng token, bản gốc nằm trong kho riêng	Số thẻ thành token	Định dạng, khả năng khôi phục có kiểm soát	Kho token trở thành mục tiêu cần bảo vệ riêng

Ví dụ với dữ liệu Việt Nam: che CCCD, số điện thoại, số tài khoản

Các bài hướng dẫn thường lấy ví dụ số thẻ tín dụng Mỹ hoặc số an sinh xã hội. Dữ liệu Việt Nam có những đặc điểm riêng khiến cách che phải khác.

Số CCCD 12 chữ số

Cấu trúc số căn cước công dân gồm 3 chữ số đầu là mã tỉnh hoặc thành phố nơi đăng ký khai sinh, 1 chữ số tiếp theo là mã giới tính và thế kỷ sinh, 2 chữ số tiếp theo là hai số cuối năm sinh, 6 số cuối là dãy ngẫu nhiên. Nghĩa là nếu bạn chỉ che 6 số cuối và giữ 6 số đầu, người xem vẫn biết người đó sinh ở đâu, giới tính nào, năm sinh nào. Với bảng khách hàng có vài trăm người ở một tỉnh nhỏ, 6 số đầu kết hợp với ngày tham gia có thể đủ để nhận ra một người. Ví dụ minh hoạ: để đối soát với khách, bộ phận hỗ trợ chỉ cần thấy 3 số cuối; còn bản test chỉ cần chuỗi 12 số hợp lệ về định dạng, do máy sinh ngẫu nhiên.

Số điện thoại và email

Số điện thoại di động Việt Nam có 10 chữ số, đầu số cho biết nhà mạng. Che dạng 09****5678 đủ để nhân viên xác nhận với khách, nhưng bản test thì nên sinh số giả theo đúng đầu số hợp lệ, để các ô kiểm tra định dạng (validation) vẫn chạy. Với email, giữ nguyên tên miền công ty của khách (ví dụ minh hoạ: [email protected]) có thể làm lộ danh tính khách doanh nghiệp nhỏ; bản test nên đổi cả phần tên miền sang tên miền dành cho thử nghiệm.

Họ tên, địa chỉ và cột ghi chú

Họ tên tiếng Việt có dấu, nên bộ sinh tên giả cần hỗ trợ Unicode, nếu không bản test sẽ không bắt được lỗi hiển thị dấu. Địa chỉ nên được thay ở mức đường và số nhà nhưng giữ quận, huyện nếu bài toán phân tích theo khu vực cần. Cột ghi chú tự do là nơi hay chứa thông tin lọt lưới: nhân viên gõ “khách gọi lại số 09…”, dán email hoặc số tài khoản. Với cột này, cách an toàn là xoá hoặc dùng bộ nhận dạng mẫu (regex) quét các chuỗi giống số điện thoại, email, CCCD rồi thay bằng ký hiệu.

Data masking khác gì mã hoá, ẩn danh hoá và dữ liệu tổng hợp?

Bốn khái niệm này hay bị dùng lẫn. Bảng sau tách ra theo mục đích.

Khái niệm	Đảo ngược được không	Dữ liệu có còn dùng được ngay	Dùng chủ yếu để
Data masking	Thường không (trừ token hoá có kho ánh xạ)	Có, giữ định dạng và cấu trúc	Cho môi trường test, phân tích, đối tác dùng
Mã hoá (encryption)	Có, nếu có khoá	Không, phải giải mã mới đọc được	Bảo vệ dữ liệu khi lưu trữ và truyền tải
Ẩn danh hoá / khử nhận dạng	Mục tiêu là không	Có, ở mức tổng hợp hoặc đã loại định danh	Công bố, chia sẻ, nghiên cứu
Dữ liệu tổng hợp	Không có liên hệ trực tiếp với bản ghi gốc	Có, do mô hình sinh ra	Thay hẳn dữ liệu thật trong thử nghiệm, huấn luyện

Với dữ liệu tổng hợp, bài về synthetic data trình bày riêng cách sinh dữ liệu không xuất phát từ bản ghi thật. Masking khác ở chỗ nó biến đổi chính bản ghi thật, nên vẫn phải kiểm tra nguy cơ nhận ra lại cá nhân.

Che rồi có còn là dữ liệu cá nhân không?

Đây là điểm dễ hiểu nhầm nhất ở Việt Nam. Theo Điều 2 Luật Bảo vệ dữ liệu cá nhân, dữ liệu cá nhân sau khi khử nhận dạng không còn là dữ liệu cá nhân. Nhưng một bản che mà vẫn có thể nhận ra người hoặc có thể ghép ngược bằng bảng ánh xạ chưa phải là khử nhận dạng thật sự. Một phân tích của Lexology nhận xét cách tiếp cận của Việt Nam không thừa nhận mức trung gian là dữ liệu giả danh (pseudonymized), tức loại cho phép đảo ngược kết nối trong điều kiện kiểm soát.

Áp dụng cho masking: bản test được che bằng token hoá kèm kho ánh xạ, hoặc băm không muối trên cột có ít giá trị, có nhiều khả năng vẫn bị coi là dữ liệu cá nhân và phải được bảo vệ như bản gốc. Bản che bằng giá trị ngẫu nhiên, không lưu ánh xạ và đã kiểm tra khả năng ghép ngược mới tiến gần đến khử nhận dạng. Bạn nên để bộ phận pháp chế hoặc người phụ trách bảo vệ dữ liệu xác nhận kết luận cho từng bộ dữ liệu cụ thể, vì bài này không phải tư vấn pháp lý. Bức tranh quản trị rộng hơn nằm ở bài data governance.

Ưu điểm, hạn chế và rủi ro khi che dữ liệu

Ưu điểm

• Thu nhỏ bề mặt rò rỉ: bản sao ở môi trường test không còn giá trị với kẻ lấy cắp.
• Giữ được độ thật của dữ liệu, nên test bắt được lỗi định dạng, độ dài, ký tự đặc biệt mà dữ liệu bịa tay thường bỏ sót.
• Cho phép chia sẻ dữ liệu với nhà thầu mà không phải chuyển bản gốc.

Hạn chế và rủi ro

• Tái nhận dạng bằng ghép nối: ngày sinh, mã bưu chính hoặc mã tỉnh, giới tính khi đi cùng nhau có thể xác định một người dù từng cột đã bị làm mờ. Đây là lý do cần xét cả tổ hợp cột (quasi-identifier), không chỉ từng cột.
• Mất tính nhất quán: che mỗi bảng một kiểu làm gãy khoá ngoại, bản test chạy lỗi vì dữ liệu mâu thuẫn.
• Méo thống kê: thay ngẫu nhiên hoàn toàn khiến báo cáo trên bản che cho kết luận khác bản thật, nên không dùng được để phân tích. Chất lượng đầu vào ảnh hưởng đến kết quả, như bài về GIGO phân tích.
• Dynamic masking không phải rào chắn tuyệt đối: trong SQL Server, Dynamic Data Masking chỉ che kết quả hiển thị và Microsoft khuyến cáo dùng kèm các biện pháp khác như phân quyền; người có quyền truy vấn vẫn có thể suy luận giá trị bằng cách lọc (WHERE) nhiều lần. Hãy xem nó là lớp bổ trợ chứ không phải thay cho kiểm soát truy cập.

Công cụ và tính năng có sẵn

Bạn không nhất thiết phải mua nền tảng riêng. Một số cơ sở dữ liệu có tính năng che động sẵn: SQL Server cung cấp Dynamic Data Masking với các hàm che như default, email, random và partial gắn trực tiếp lên cột. PostgreSQL có tiện ích mở rộng PostgreSQL Anonymizer cho phép khai báo quy tắc che theo cột. Oracle có sản phẩm Data Masking and Subsetting. Ngoài ra còn các nền tảng thương mại chuyên biệt cho masking và sinh dữ liệu test. Hãy kiểm tra tài liệu phiên bản bạn đang dùng trước khi dựa vào một tính năng, vì phạm vi hỗ trợ khác nhau theo phiên bản.

Với kho dữ liệu hoặc data warehouse, nên che ngay ở lớp nạp dữ liệu để các bảng báo cáo phía sau không chứa định danh. Nếu hệ thống của bạn chưa rõ cột nào nằm ở đâu, hãy bắt đầu từ việc nắm cấu trúc cơ sở dữ liệu của mình.

Khi nào nên và không nên dùng data masking

• Nên dùng khi dữ liệu phải rời khỏi production để test, đào tạo, demo, phân tích hoặc giao cho bên thứ ba, và người nhận không cần biết danh tính thật.
• Nên dùng che động khi nhiều vai trò cùng truy cập một hệ thống nhưng chỉ một số được phép xem giá trị đầy đủ, ví dụ tổng đài viên và kế toán cùng xem hồ sơ khách.
• Không đủ khi bạn cần bảo vệ dữ liệu đang lưu hoặc đang truyền trên đường: dùng mã hoá. Masking không thay thế nó.
• Không phù hợp khi mục đích là đối soát từng cá nhân thật (ví dụ chốt công nợ từng khách): bản che không cho phép làm việc đó.
• Cân nhắc dữ liệu tổng hợp khi bộ dữ liệu quá nhỏ hoặc có nhiều giá trị hiếm, vì che từng dòng vẫn dễ lộ người.

Checklist triển khai và lỗi thường gặp

1. Lập danh sách cột nhạy cảm, gồm cả cột ghi chú, tên file đính kèm, trường JSON lồng nhau và log ứng dụng.
2. Gán mỗi cột một quy tắc theo mục đích dùng bản che, và ghi rõ vì sao chọn quy tắc đó.
3. Dùng cùng một hàm che cho cùng một khoá ở mọi bảng để giữ quan hệ JOIN.
4. Giữ định dạng hợp lệ: số điện thoại đúng đầu số, CCCD đủ 12 số, ngày hợp lệ, có dấu tiếng Việt.
5. Kiểm tra tổ hợp cột: đếm xem có nhóm nào chỉ gồm một hoặc hai người sau khi che hay không.
6. Lưu khoá, muối và bảng ánh xạ (nếu có) tách khỏi môi trường dùng bản che.
7. Ghi nhật ký mỗi lần chạy: nguồn, thời điểm, bộ quy tắc, người duyệt. Khi có thay đổi schema, kiểm tra cột mới có bị lọt không; data observability hỗ trợ phát hiện thay đổi như vậy.

Các lỗi hay gặp:

• Che cột chính nhưng quên bản sao khác: file export CSV, bản backup cũ hoặc bảng tạm vẫn chứa dữ liệu thật.
• Dùng số ngẫu nhiên khác nhau ở mỗi lần chạy: test hồi quy không so sánh được giữa các lần.
• Che bằng giá trị cố định cho cả cột: cột trở thành một giá trị duy nhất, làm mất khả năng test điều kiện lọc và sắp xếp.
• Để khoá giải token cạnh bản che: việc này làm mất ý nghĩa của masking.

Câu hỏi thường gặp

Data masking có phải là mã hoá không?

Không. Mã hoá biến dữ liệu thành chuỗi không đọc được và giải ngược được khi có khoá. Masking tạo giá trị thay thế vẫn đọc được, đúng định dạng và thường không có đường quay lại bản gốc. Hai kỹ thuật bổ trợ nhau: mã hoá bảo vệ dữ liệu khi lưu và truyền, masking bảo vệ khi dữ liệu được dùng.

Static masking và dynamic masking, nên chọn loại nào?

Chọn static khi dữ liệu được sao ra môi trường khác như test, UAT hay giao cho nhà thầu. Chọn dynamic khi nhiều vai trò dùng chung một hệ thống production và mỗi vai trò chỉ được xem mức khác nhau. Nhiều doanh nghiệp dùng cả hai: static cho môi trường phi sản xuất, dynamic cho màn hình và báo cáo nội bộ.

Data masking có làm báo cáo phân tích sai không?

Có thể, nếu che quá tay. Thay ngẫu nhiên hoàn toàn sẽ làm sai phân bố theo độ tuổi, khu vực hoặc giá trị đơn. Nếu cần phân tích, hãy dùng kỹ thuật giữ phân bố như xáo trộn giữa dòng hoặc dịch giá trị trong biên độ nhỏ, rồi so sánh vài chỉ số tổng hợp giữa bản gốc và bản che trước khi dùng. Các bước phân tích tiếp theo nằm ở bài phân tích dữ liệu.

Dữ liệu đã che có được coi là dữ liệu cá nhân không?

Tuỳ mức độ. Luật Bảo vệ dữ liệu cá nhân chỉ loại dữ liệu đã khử nhận dạng khỏi định nghĩa dữ liệu cá nhân. Bản che còn nhận ra được người, hoặc còn bảng ánh xạ để khôi phục, nhiều khả năng vẫn bị coi là dữ liệu cá nhân. Hãy nhờ người phụ trách pháp lý xác nhận cho từng bộ dữ liệu.

Data masking có chặn được tấn công nội bộ không?

Chỉ một phần. Che động hạn chế việc người có quyền thấp nhìn thấy giá trị thật, nhưng không thay thế phân quyền, ghi log truy cập và giám sát. Người có quyền đặc biệt hoặc có thể chạy truy vấn tuỳ ý vẫn có thể tìm cách suy luận giá trị.

Có cần công cụ đắt tiền để làm data masking không?

Không bắt buộc. Một số cơ sở dữ liệu có sẵn tính năng che động, và với bản sao test, bạn có thể viết script che theo cột trong luồng nạp dữ liệu. Công cụ chuyên dụng đáng cân nhắc khi số hệ thống lớn, cần giữ nhất quán giữa nhiều cơ sở dữ liệu hoặc cần báo cáo kiểm toán.