Quản trị dữ liệu 4 — Phân loại dữ liệu & PII

Trong hai bài trước, chúng ta đã xây catalog và lineage để biết dữ liệu là gì và đến từ đâu, rồi thiết lập khung chất lượng dữ liệu để biết nó có đúng không. Nhưng còn một câu hỏi chưa được trả lời, và nó là câu hỏi mà đội kiểm toán, đội bảo mật và Ngân hàng Nhà nước quan tâm nhất: dữ liệu này nhạy cảm đến mức nào, và ai được nhìn thấy nó?

Bạn không thể bảo vệ thứ mình chưa phân loại. Không thể masking một cột nếu chưa biết cột đó chứa số CMND. Không thể cấp quyền theo mức nhạy cảm nếu chưa gắn nhãn "Restricted" cho bảng nào. Vì vậy phân loại dữ liệu (data classification) và phát hiện dữ liệu cá nhân (PII discovery) là bước nền móng — nó phải xảy ra trước masking (bài sau) và trước access control (bài kế). Bài này đi từ lý thuyết phân loại đến cách tự động quét và gán nhãn hàng nghìn cột trong một kho dữ liệu ngân hàng thật.

Vì sao phải phân loại dữ liệu

Một ngân hàng cỡ trung có thể có hàng chục nghìn cột dữ liệu trải trên core banking, thẻ, tín dụng, CRM, kho phân tích. Không phải cột nào cũng đáng bảo vệ như nhau: tên chi nhánh là công khai, nhưng số dư tài khoản của khách VIP thì không. Nếu áp cùng một mức kiểm soát cho tất cả, bạn hoặc quá lỏng (rò rỉ dữ liệu nhạy cảm) hoặc quá chặt (analyst không làm việc được, phải xin quyền cho từng bảng vô hại).

Phân loại giải quyết bài toán này bằng cách gắn cho mỗi dữ liệu một nhãn mức nhạy cảm (sensitivity label). Nhãn này trở thành "khóa chính sách": mọi công cụ downstream — masking engine, hệ thống phân quyền, DLP (Data Loss Prevention), log audit — đều đọc nhãn để quyết định hành xử. Phân loại một lần, thực thi nhiều nơi.

Bốn mức nhạy cảm

Mô hình phổ biến nhất trong ngân hàng là thang 4 mức. Tên gọi có thể khác nhau giữa các tổ chức, nhưng logic tăng dần theo mức thiệt hại nếu rò rỉ là nhất quán.

Nguyên tắc vàng: nhãn của bảng/tập dữ liệu bằng nhãn cao nhất của bất kỳ cột nào trong đó (high-water mark). Một bảng dim_customer chứa toàn cột Internal nhưng có thêm cột national_id → cả bảng được đối xử ở mức Restricted về mặt kiểm soát truy cập. Điều này lý giải tại sao ta thường tách cột nhạy cảm ra bảng riêng hoặc token hóa — để phần còn lại được phân tích thoải mái hơn.

PII và dữ liệu cá nhân nhạy cảm theo Nghị định 13/2023

PII (Personally Identifiable Information) — thông tin định danh cá nhân — là bất kỳ dữ liệu nào có thể xác định, trực tiếp hay gián tiếp, một con người cụ thể. Trực tiếp: số CMND, số điện thoại. Gián tiếp: sự kết hợp ngày sinh + mã bưu chính + giới tính có thể định danh một người dù không có tên.

Tại Việt Nam, khung pháp lý chuẩn là Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân (có hiệu lực 01/07/2023). Điểm mấu chốt của nghị định là phân biệt hai loại dữ liệu cá nhân, với mức bảo vệ khác nhau:

• Dữ liệu cá nhân cơ bản (basic personal data): họ tên, ngày/tháng/năm sinh, giới tính, nơi sinh, quê quán, địa chỉ, số điện thoại, số CMND/CCCD/hộ chiếu, số tài khoản, tình trạng hôn nhân, dữ liệu phản ánh hoạt động trên không gian mạng... Đây là nhóm thông tin phổ biến để nhận diện một người.
• Dữ liệu cá nhân nhạy cảm (sensitive personal data): nhóm được bảo vệ đặc biệt vì rò rỉ có thể gây phân biệt đối xử hoặc tổn hại nghiêm trọng. Bao gồm: quan điểm chính trị/tôn giáo, tình trạng sức khỏe, đặc điểm di truyền, đặc điểm sinh học/sinh trắc học, đời sống/xu hướng tình dục, dữ liệu về tội phạm, dữ liệu về tài chính/tài khoản (theo cách hiểu ngành ngân hàng), vị trí địa lý... Xử lý dữ liệu nhạy cảm đòi hỏi điều kiện chặt hơn: sự đồng ý rõ ràng, thông báo cho chủ thể, và các biện pháp bảo vệ tăng cường.

Lưu ý mapping: nghị định phân "cơ bản vs nhạy cảm" theo góc độ pháp lý; còn thang "Public/Internal/Confidential/Restricted" ở trên là góc độ vận hành kỹ thuật. Trong thực tế, dữ liệu cá nhân nhạy cảm theo nghị định thường được map sang Restricted, dữ liệu cá nhân cơ bản sang Confidential. Đội governance cần lập bảng ánh xạ này và ghi vào chính sách.

Hệ quả thực chiến: với dữ liệu tài chính và định danh của khách hàng, ngân hàng phải xử lý ở mức cao (đồng ý, thông báo, lưu vết truy cập). Đây là lý do đội dữ liệu không thể "cứ copy nguyên bảng khách hàng sang môi trường sandbox để test" — hành vi đó có thể là vi phạm.

Dữ liệu ngân hàng nhạy cảm điển hình

Ngoài PII chung, ngành ngân hàng có những trường dữ liệu đặc thù cần nhận diện chính xác:

Điểm cần nhớ về PAN: chuẩn PCI-DSS cho phép hiển thị tối đa 6 chữ số đầu (BIN) và 4 chữ số cuối; phần giữa phải masking. Sinh trắc học nguy hiểm đặc biệt vì không thể cấp lại như mật khẩu — vân tay lộ là lộ vĩnh viễn.

Data discovery: quét PII tự động

Với hàng chục nghìn cột, không thể phân loại thủ công. Ta cần data discovery — quét tự động để tìm dữ liệu giống PII. Có hai kỹ thuật chính, thường kết hợp:

1. Dựa trên mẫu (pattern / regex)

Nhận diện theo định dạng của giá trị. Ví dụ: một cột mà đa số giá trị khớp mẫu 12 chữ số → nghi là CCCD; khớp mẫu email → nghi là email. Kỹ thuật này nhanh, giải thích được (explainable), nhưng dễ dương tính giả (false positive): một mã sản phẩm 12 chữ số cũng khớp mẫu CCCD.

Thường ta tăng độ tin cậy bằng cách kết hợp: (a) mẫu giá trị, (b) tên cột (national_id, cmnd, card_no), (c) checksum (số thẻ hợp lệ phải qua thuật toán Luhn; CCCD có quy tắc mã tỉnh 3 số đầu).

2. Dựa trên ML (ML classifier)

Huấn luyện mô hình phân loại cột dựa trên nhiều đặc trưng: phân bố độ dài, tỷ lệ ký tự số/chữ, entropy, tên cột, mẫu giá trị, và cả NER (Named Entity Recognition) trên nội dung để bắt tên người, địa chỉ. Mạnh hơn với dữ liệu không có định dạng cứng (như địa chỉ, họ tên tự do), nhưng cần dữ liệu huấn luyện và khó giải thích hơn. Các dịch vụ như Google Cloud DLP, AWS Macie, hay Microsoft Purview đóng gói sẵn cả hai cách tiếp cận.

Minh họa: phát hiện dữ liệu giống PII bằng SQL

Trên sandbox PostgreSQL của chúng ta, ta có thể mô phỏng ý tưởng discovery bằng regex. Toán tử ~ trong PostgreSQL kiểm tra chuỗi có khớp biểu thức chính quy hay không.

(a) Tìm các bản ghi trong customers mà full_name chứa chuỗi số dài (nghi là ai đó nhập nhầm CMND/số điện thoại vào ô tên — một lỗi rò rỉ PII kinh điển):

-- ▶ Chạy được
SELECT id, full_name, city
FROM customers
WHERE full_name ~ '[0-9]{6,}'
ORDER BY id;

Mẫu [0-9]{6,} nghĩa là "có ít nhất 6 chữ số liền nhau". Trong dữ liệu sạch, tên người không bao giờ chứa số → mọi kết quả trả về đều là cột phải điều tra. Đây chính là dương tính (positive) mà công cụ discovery muốn báo động.

(b) Đếm xem có bao nhiêu bản ghi nghi ngờ trên tổng số, để ước lượng mức độ nhiễm PII của cột — con số này giúp xếp ưu tiên xử lý:

-- ▶ Chạy được
SELECT
  COUNT(*) FILTER (WHERE full_name ~ '[0-9]{9,12}') AS nghi_ngo_id,
  COUNT(*) FILTER (WHERE city ~ '^[0-9]+$')          AS city_toan_so,
  COUNT(*)                                            AS tong_ban_ghi
FROM customers;

Mẫu [0-9]{9,12} bắt chuỗi 9–12 chữ số (khoảng độ dài CMND/CCCD); ^[0-9]+$ bắt trường hợp cột city lẽ ra là chữ nhưng toàn số. Tỷ lệ nghi_ngo_id / tong_ban_ghi cao là tín hiệu cột này thực sự chứa PII và cần gán nhãn Restricted.

(c) Với số tài khoản, discovery hay phân nhóm theo độ dài để phát hiện định dạng bất thường (số tài khoản đúng chuẩn thường có độ dài cố định; giá trị lệch độ dài là dữ liệu rác hoặc trường bị dùng sai):

-- ▶ Chạy được
SELECT
  LENGTH(account_no)           AS do_dai,
  COUNT(*)                     AS so_luong,
  MIN(account_no)              AS vi_du
FROM accounts
GROUP BY LENGTH(account_no)
ORDER BY so_luong DESC;

Kết quả cho thấy phân bố độ dài của account_no. Nếu 99% có độ dài 12 và vài dòng lẻ có độ dài khác, những dòng lẻ đó đáng ngờ. Trong công cụ discovery thật, "độ dài đồng đều + tất cả là số" là một đặc trưng mạnh để classifier kết luận cột này là số tài khoản → Confidential.

Lưu ý: đây là minh họa ý tưởng trên dữ liệu sandbox không chứa PII thật. Công cụ discovery sản xuất chạy trên metadata và mẫu (sample) dữ liệu thật, kết hợp regex + checksum + ML, chứ không quét toàn tải bằng SQL thủ công như vậy.

Gán nhãn (tagging): nền cho masking & access control

Phát hiện xong thì phải gán nhãn — lưu kết quả phân loại vào metadata, chứ không phải vào một file Excel bị bỏ quên. Nhãn thường lưu ở hai cấp:

• Nhãn kỹ thuật (data class): kiểu cụ thể của cột — NATIONAL_ID, PAN, ACCOUNT_NUMBER, EMAIL, BALANCE. Cho biết cột chứa gì.
• Nhãn nhạy cảm (sensitivity): Public / Internal / Confidential / Restricted. Cho biết phải bảo vệ mức nào.

Tag được đính vào cột trong data catalog (nối tiếp bài catalog & lineage). Sức mạnh nằm ở chỗ tag trở thành đầu vào cho chính sách tự động:

• Masking engine đọc tag PAN → áp quy tắc lộ 4 số cuối (xem bài encryption & masking).
• Hệ thống phân quyền đọc tag Restricted → chỉ role được phê duyệt mới SELECT được (xem bài access control).
• DLP đọc tag để chặn export dữ liệu Restricted ra ngoài.

Đây là mô hình tag-based / attribute-based: bạn viết chính sách một lần theo tag, và nó tự áp cho mọi cột mang tag đó, kể cả cột mới phát hiện tuần sau. Không phải sửa chính sách cho từng bảng.

Sổ đăng ký dữ liệu (Data Inventory / RoPA)

Kết quả phân loại phải được tổng hợp thành một sổ đăng ký — bản kiểm kê chính thức về dữ liệu cá nhân mà tổ chức xử lý. Trong khung GDPR gọi là RoPA (Record of Processing Activities); Nghị định 13/2023 cũng yêu cầu doanh nghiệp lập và lưu hồ sơ đánh giá tác động xử lý dữ liệu cá nhân. Về bản chất, đây là sổ trả lời cho mỗi loại dữ liệu cá nhân:

Sổ đăng ký là thứ đầu tiên cơ quan quản lý (NHNN, cơ quan bảo vệ dữ liệu) yêu cầu xuất trình khi thanh tra hoặc khi có sự cố rò rỉ. Nó cũng là điểm bắt đầu để xử lý quyền của chủ thể dữ liệu (yêu cầu xem/xóa dữ liệu của tôi) — bạn không thể xóa dữ liệu của một người nếu không biết nó nằm ở đâu.

Quy trình discovery → classify → tag → bảo vệ

Toàn bộ luồng từ phát hiện đến bảo vệ có thể hình dung như sau:

Lưu ý discovery không phải làm một lần. Schema thay đổi, bảng mới sinh ra hằng ngày → discovery phải chạy định kỳ (ví dụ hằng tuần) và cảnh báo khi phát hiện cột nhạy cảm chưa gắn nhãn.

Use case thực tế

Bối cảnh: Đội governance NCB chuẩn bị cho một đợt thanh tra tuân thủ Nghị định 13/2023. Kho phân tích có ~8.400 cột trên 620 bảng. Yêu cầu: trong 6 tuần, xác định mọi cột chứa dữ liệu cá nhân, gán nhãn, và lập sổ đăng ký.

Cách làm theo bước:

1. Tuần 1 — Discovery tự động. Chạy công cụ quét (kết hợp regex + checksum Luhn cho PAN, quy tắc mã tỉnh cho CCCD, và ML classifier cho tên/địa chỉ) trên sample 10.000 dòng mỗi bảng. Công cụ đánh dấu 1.150 cột là ứng viên PII với điểm tin cậy.
2. Tuần 2 — Lọc dương tính giả. Data steward review các cột điểm tin cậy trung bình. Phát hiện 90 cột dương tính giả (mã giao dịch 16 số bị nhầm là PAN vì cùng độ dài, nhưng không qua checksum Luhn). Còn lại 1.060 cột PII thật.
3. Tuần 3 — Phân loại & mapping pháp lý. Gán data class và map sang mức nhạy cảm: 210 cột Restricted (CCCD, PAN, sinh trắc học), 640 Confidential (số dư, giao dịch, liên hệ), phần còn lại thấp hơn. Đối chiếu với phân loại "cơ bản vs nhạy cảm" của nghị định.
4. Tuần 4 — Phát hiện rò rỉ. Bằng kỹ thuật như block SQL (a) ở trên, tìm ra 3 cột full_name ở bảng staging chứa chuỗi số dài — đó là số CCCD bị dev nhập nhầm vào ô tên khi test. Xử lý ngay: xóa và cấm bảng staging đó.
5. Tuần 5 — Tag & tích hợp. Đẩy toàn bộ 1.060 tag vào catalog. Masking engine và access control tự động áp chính sách theo tag — không phải cấu hình thủ công từng bảng.
6. Tuần 6 — Sổ đăng ký & bàn giao. Sinh RoPA từ catalog, rà soát cơ sở pháp lý cho từng loại. Xuất trình cho đoàn thanh tra.

Kết quả: Từ trạng thái "không biết PII nằm đâu" sang có bản đồ đầy đủ + bằng chứng tuân thủ, đồng thời chặn được một rò rỉ CCCD thực tế. Chi phí lớn nhất không phải công cụ mà là thời gian steward review — nên đầu tư vào classifier tốt để giảm dương tính giả ngay từ đầu. Discovery này cũng là đầu vào cho hệ thống chống rửa tiền (xem AML tổng quan) vì cùng cần biết dữ liệu định danh khách hàng nằm ở đâu.

Ghi nhớ

• Không phân loại thì không bảo vệ được. Classification + discovery là bước nền, phải xảy ra trước masking và access control.
• Bốn mức nhạy cảm: Public → Internal → Confidential → Restricted, tăng theo mức thiệt hại nếu rò rỉ. Nhãn của bảng = nhãn cao nhất của cột trong đó (high-water mark).
• Nghị định 13/2023 phân biệt dữ liệu cá nhân cơ bản (tên, CMND, số tài khoản, số điện thoại...) và nhạy cảm (sinh trắc học, sức khỏe, tài chính...). Nhạy cảm cần điều kiện xử lý chặt hơn.
• PII ngân hàng điển hình: CMND/CCCD, số thẻ PAN (thuộc PCI-DSS, chỉ lộ 6 đầu + 4 cuối), số tài khoản, số dư/giao dịch, sinh trắc học (không thể cấp lại khi lộ).
• Discovery = regex/pattern (nhanh, dễ dương tính giả) + ML/NER (mạnh với dữ liệu tự do). Tăng độ tin cậy bằng checksum (Luhn, mã tỉnh) và tên cột.
• Tag hai cấp: data class (cột chứa gì) + sensitivity (bảo vệ mức nào). Tag là đầu vào cho chính sách tự động, viết một lần áp mọi nơi.
• Sổ đăng ký / RoPA là bằng chứng tuân thủ và điểm bắt đầu để xử lý quyền chủ thể dữ liệu; là thứ cơ quan quản lý yêu cầu đầu tiên khi thanh tra.
• Discovery phải chạy định kỳ, không phải một lần — schema và bảng luôn thay đổi.