Quản trị dữ liệu 8 — Vòng đời dữ liệu, lưu trữ & audit

Một khách hàng gửi email cho phòng dịch vụ: "Tôi đã đóng tài khoản 3 năm trước, yêu cầu ngân hàng xoá toàn bộ dữ liệu của tôi." Cán bộ tuân thủ đối diện một mâu thuẫn thật: Nghị định 13/2023/NĐ-CP cho khách hàng quyền yêu cầu xoá dữ liệu, nhưng Luật Kế toán buộc ngân hàng lưu chứng từ giao dịch tối thiểu 10 năm. Xoá là vi phạm luật kế toán; không xoá là (có vẻ) vi phạm quyền chủ thể. Câu trả lời đúng không phải "xoá" hay "không xoá" — mà là hiểu vòng đời dữ liệu, retention, và cách dung hoà hai nghĩa vụ. Đó là chủ đề của bài cuối cùng trong series này.

Đây là bài số 8, khép lại series Bảo mật & Quản trị dữ liệu ngân hàng. Sau khi đã đi qua tổng quan, catalog/lineage, chất lượng, phân loại/PII, mã hoá/masking, kiểm soát truy cập và quyền riêng tư/tuân thủ, bài này xử lý giai đoạn cuối của vòng đời — dữ liệu được giữ bao lâu, lưu ở đâu, khi nào bị xoá — cùng audit (ghi lại ai làm gì với dữ liệu). Cuối bài là tổng kết operating model và bộ KPI đo lường toàn bộ chương trình governance.

Vòng đời dữ liệu: 5 giai đoạn

Mọi bản ghi dữ liệu đều đi qua một vòng đời có thể quản trị được. Mô hình phổ biến gồm năm giai đoạn:

• Create/Capture — dữ liệu sinh ra: khách mở tài khoản, một giao dịch phát sinh, một hồ sơ vay được nhập. Đây là điểm phải phân loại mật ngay (xem phân loại & PII) và ghi metadata nguồn gốc.
• Store — dữ liệu được lưu trong hệ thống vận hành (OLTP core banking), rồi đưa vào kho phân tích. Quyết định quan trọng: lưu ở tier nào (nóng/ấm/nguội) và mã hoá thế nào (xem mã hoá & masking).
• Use/Share — dữ liệu phục vụ báo cáo, mô hình, API. Đây là nơi kiểm soát truy cập và audit hoạt động mạnh nhất.
• Archive — dữ liệu ít dùng nhưng chưa được phép xoá (vì nghĩa vụ pháp lý) được chuyển sang lưu trữ nguội, giá rẻ, truy cập chậm. Vẫn có thể khôi phục khi kiểm toán hay tranh chấp.
• Destroy/Purge — khi hết cả thời hạn lưu bắt buộc và mục đích sử dụng, dữ liệu được xoá vĩnh viễn hoặc ẩn danh không phục hồi được.

Điểm mấu chốt của quản trị vòng đời: mỗi giai đoạn có chính sách riêng, và việc chuyển giai đoạn phải tự động, có bằng chứng — không phải khi nào nhớ ra mới dọn.

Chính sách retention

Retention policy (chính sách lưu giữ) trả lời câu hỏi: mỗi loại dữ liệu giữ bao lâu, rồi làm gì? Với ngân hàng, retention không phải lựa chọn kỹ thuật mà là nghĩa vụ pháp lý. Thời hạn được đặt theo loại dữ liệu và khung pháp luật ràng buộc.

Các con số trên là minh hoạ khung tư duy; thời hạn chính xác phải tra cứu văn bản pháp luật hiện hành và tư vấn pháp chế. Nguyên tắc là lấy thời hạn dài nhất trong các nghĩa vụ áp dụng lên cùng một bản ghi.

Retention có hai mặt trái nếu làm sai: giữ quá lâu (over-retention) làm tăng chi phí lưu trữ, tăng bề mặt rủi ro rò rỉ, và vi phạm nguyên tắc "tối thiểu hoá dữ liệu" của quyền riêng tư (xem quyền riêng tư & tuân thủ); xoá quá sớm vi phạm nghĩa vụ lưu trữ, mất bằng chứng khi tranh chấp hoặc thanh tra. Governance phải cân bằng chính xác cả hai.

Tiering hot / warm / cold

Không phải dữ liệu nào cũng cần nằm trên hạ tầng nhanh và đắt. Tiering phân tầng lưu trữ theo tần suất truy cập:

Chuyển tier là một quy trình tự động dựa trên created_at (hoặc closed_at) của bản ghi. Để biết cần chuyển gì, việc đầu tiên là tìm các bản ghi cũ. Trên sandbox, ta minh hoạ bằng bảng transactions (cột created_at là TIMESTAMP) — tìm giao dịch cũ hơn 2 năm để đưa xuống cold:

-- ▶ Chạy được
SELECT id, account_id, amount, kind, created_at
FROM transactions
WHERE created_at < NOW() - INTERVAL '2 years'
ORDER BY created_at
LIMIT 100;

Câu này chỉ liệt kê ứng viên để archive — sandbox là read-only nên không xoá/chuyển gì cả; trong thực tế bước tiếp theo là export sang cold storage rồi mới purge khỏi tier nóng theo quy trình có phê duyệt.

Archival và purge

• Archival là chuyển dữ liệu sang lưu trữ nguội để giải phóng hạ tầng nóng, nhưng vẫn giữ được. Dữ liệu archive phải: (1) vẫn mã hoá; (2) vẫn có metadata để tìm lại; (3) kiểm tra tính khôi phục định kỳ (đừng để đến lúc thanh tra mới phát hiện file archive hỏng).
• Purge là xoá vĩnh viễn khi hết retention. Purge phải: (1) có bằng chứng (log ai chạy, xoá cái gì, khi nào, dựa trên chính sách nào); (2) xoá cả bản sao lưu (backup) và bản nhân bản — xoá bảng chính nhưng để lại bản trong warehouse là purge dối; (3) được phê duyệt bởi Data Owner của domain đó.

Một thực hành hữu ích cho việc lập kế hoạch archival là đếm khối lượng dữ liệu theo năm để ước lượng dung lượng cần chuyển. Dùng EXTRACT(YEAR FROM ...):

-- ▶ Chạy được
SELECT EXTRACT(YEAR FROM created_at) AS nam,
       COUNT(*)                      AS so_giao_dich,
       ROUND(SUM(amount), 2)         AS tong_gia_tri
FROM transactions
GROUP BY EXTRACT(YEAR FROM created_at)
ORDER BY nam;

Kết quả cho ta phân bố bản ghi theo năm — cơ sở để quyết định năm nào đủ tuổi chuyển cold và ước lượng chi phí. (Lưu ý khác biệt kiểu dữ liệu giữa các bảng: transactions.created_at là TIMESTAMP như trên, còn customers.created_at là DATE — EXTRACT và so sánh INTERVAL hoạt động với cả hai, nhưng đừng giả định giờ/phút tồn tại ở cột DATE.)

Right to be forgotten và cách dung hoà

Nghị định 13/2023/NĐ-CP trao cho chủ thể dữ liệu quyền xoá (thường gọi theo GDPR là right to be forgotten / right to erasure): khi dữ liệu cá nhân không còn cần cho mục đích đã thu thập, hoặc chủ thể rút đồng ý, họ có quyền yêu cầu xoá.

Nhưng như tình huống mở đầu, quyền này xung đột trực tiếp với nghĩa vụ retention: ngân hàng buộc phải giữ chứng từ giao dịch 10 năm dù khách yêu cầu xoá. Đây không phải bế tắc — luật cho phép ngoại lệ khi có nghĩa vụ pháp lý khác. Cách dung hoà thực tế:

• Nếu không còn nghĩa vụ lưu trữ → xoá thật, gồm cả backup.
• Nếu còn nghĩa vụ nhưng nghĩa vụ đó không cần danh tính → anonymization / pseudonymization. Ví dụ: báo cáo thống kê giao dịch cần số tiền, loại, thời gian nhưng không cần biết ai. Ta gỡ/băm định danh, giữ lại dữ liệu nghiệp vụ. Đây là điểm dung hoà thường dùng nhất.
• Nếu nghĩa vụ bắt buộc giữ định danh (chứng từ giao dịch phải truy được về khách hàng để phục vụ thanh tra) → giữ nhưng hạn chế: chuyển sang cold, thu hẹp quyền truy cập về mức tối thiểu, gắn cờ "chỉ giữ vì nghĩa vụ pháp lý — không dùng cho mục đích khác".

Phân biệt hai kỹ thuật quan trọng (đã bàn kỹ ở phân loại & PII):

• Anonymization (ẩn danh): loại bỏ định danh không thể đảo ngược, không còn liên kết về cá nhân → dữ liệu ra khỏi phạm vi "dữ liệu cá nhân".
• Pseudonymization (bút danh hoá): thay định danh bằng mã giả (token/hash có khoá), có thể đảo ngược nếu giữ khoá → vẫn là dữ liệu cá nhân, nhưng an toàn hơn khi lưu.

Trả lời khách hàng ở đầu bài, đúng nghiệp vụ là: "Chúng tôi không thể xoá chứng từ giao dịch trong thời hạn 10 năm theo Luật Kế toán, nhưng đã ẩn danh dữ liệu cá nhân của quý khách trong các mục đích không bắt buộc (như phân tích, marketing) và hạn chế truy cập phần còn phải giữ."

Audit logging

Audit log ghi lại ai đã truy cập/sửa dữ liệu gì, khi nào, và (lý tưởng) vì sao. Đây là xương sống của accountability: không có audit thì mọi chính sách truy cập chỉ là niềm tin.

Một bản ghi audit tốt cần đủ các trường (mô hình who-what-when-where-how):

Immutable log (log bất biến)

Audit log chỉ có giá trị nếu không thể sửa hay xoá — nếu người vi phạm có thể tự xoá dấu vết thì log vô nghĩa. Các nguyên tắc:

• Append-only: chỉ ghi thêm, không cho update/delete. Người có quyền trên dữ liệu nghiệp vụ không được có quyền sửa log của chính mình (tách quyền — separation of duties).
• WORM (Write Once Read Many): lưu trên hạ tầng chỉ-ghi-một-lần, thường ở tài khoản/hệ thống tách biệt.
• Tamper-evident: gắn hash chuỗi (mỗi bản ghi chứa hash của bản trước) để phát hiện nếu ai đó chèn/sửa giữa chừng — chỉnh một dòng là cả chuỗi hash lệch.
• Đồng bộ thời gian: dùng nguồn thời gian tin cậy (NTP) để mốc thời gian không bị làm giả.

Lưu ý: audit log cũng là dữ liệu, nên cũng có retention riêng (thường 1–5 năm), cũng phải phân tầng và mã hoá như mọi dữ liệu khác.

Giám sát truy cập bất thường

Ghi log là bị động; giá trị thật đến từ giám sát chủ động. Từ audit log, xây các cảnh báo phát hiện bất thường:

• Khối lượng bất thường: một user đọc 50.000 bản ghi khách hàng trong 1 giờ trong khi trung bình là 200/ngày → nghi ngờ trích xuất dữ liệu hàng loạt (data exfiltration).
• Truy cập ngoài giờ / ngoài vùng: đăng nhập lúc 3h sáng, từ IP lạ.
• Truy cập dữ liệu không liên quan vai trò: nhân viên chi nhánh A truy vấn khách hàng chi nhánh B với số lượng lớn.
• Chuỗi hành động rủi ro: GRANT quyền cho chính mình → SELECT PII → EXPORT.
• Truy cập bị từ chối lặp lại: nhiều denied liên tiếp → dò quyền (privilege probing).

Các cảnh báo này thường đẩy về SIEM (Security Information and Event Management) hoặc hệ thống phát hiện bất thường, gắn ngưỡng và mô hình hành vi. Đây cũng là dữ liệu đầu vào cho giám sát rửa tiền — bức tranh audit và AML có nhiều điểm giao.

Tổng kết series: operating model quản trị dữ liệu

Đây là bài cuối, nên hãy lùi lại nhìn toàn cảnh. Toàn bộ 8 bài mô tả một operating model khép kín, trong đó vòng đời và audit của bài này chính là lớp "đóng vòng":

Đọc theo chiều: governance đặt vai trò và luật (tổng quan); catalog/lineage cho biết dữ liệu ở đâu, nghĩa gì; phân loại xác định mức nhạy cảm; mã hoá/masking và kiểm soát truy cập bảo vệ; chất lượng và quyền riêng tư đảm bảo dùng đúng và hợp pháp; vòng đời/audit khép vòng bằng cách quản lý retention và ghi lại mọi thứ — rồi audit và KPI phản hồi ngược về Governance Council để cải tiến. Góc nhìn kỹ thuật bổ trợ ở Governance & Quality nền tảng.

Bộ KPI đo lường toàn chương trình

Governance dễ thành hình thức nếu không đo. Bộ chỉ số tổng hợp cho cả chương trình (mục tiêu là minh hoạ, mỗi tổ chức tự đặt ngưỡng theo mức trưởng thành):

Điểm chốt: KPI phải được Governance Office tổng hợp định kỳ và trình Council, biến governance từ khẩu hiệu thành cơ chế có phản hồi — đúng như mũi tên "phản hồi về" trong sơ đồ trên.

Use case thực tế

Bối cảnh (NCB, minh hoạ): Thanh tra NHNN yêu cầu chứng minh ngân hàng (1) lưu đủ chứng từ giao dịch theo luật, (2) xử lý đúng một yêu cầu xoá dữ liệu của khách hàng đã đóng tài khoản, và (3) có nhật ký truy cập vào dữ liệu khách hàng. Đội governance triển khai:

1. Lập bản đồ retention: Ban hành ma trận retention theo loại dữ liệu — chứng từ giao dịch giữ 10 năm (Luật Kế toán), hồ sơ KYC giữ 5 năm sau khi đóng quan hệ (Luật PCRT). Mỗi bảng trong catalog gắn nhãn thời hạn tương ứng.

2. Kiểm kê dữ liệu cũ: Dùng truy vấn liệt kê giao dịch cũ hơn 2 năm để lập kế hoạch chuyển cold, và truy vấn đếm bản ghi theo năm (EXTRACT(YEAR FROM created_at)) để ước lượng dung lượng archive — hai truy vấn minh hoạ ở trên.

3. Xử lý yêu cầu xoá: Khách yêu cầu xoá còn trong thời hạn 10 năm nghĩa vụ chứng từ → không xoá phần chứng từ, nhưng ẩn danh dữ liệu cá nhân trong các mục đích không bắt buộc (marketing, phân tích), thu hẹp quyền truy cập phần còn giữ, và ghi lại quyết định. Thời gian đáp ứng: 12 ngày, trong hạn luật định.

4. Chứng minh audit: Xuất audit log append-only cho thấy trong 6 tháng, mọi truy vấn vào bảng customers đều có bản ghi who-what-when; hệ thống giám sát đã bắt và chặn 2 trường hợp một tài khoản đọc bất thường > 10.000 bản ghi ngoài giờ.

5. Trình KPI: Báo cáo bộ KPI — data quality score 96%, catalog coverage 84%, dữ liệu được phân loại 91%, retention compliance 99%, audit coverage 100% cho hệ thống nhạy cảm.

Kết quả: thanh tra kết luận đạt yêu cầu về lưu trữ và audit; điểm mấu chốt không phải một công cụ, mà là chính sách retention rõ ràng + kỹ thuật ẩn danh để dung hoà + audit bất biến có giám sát — đúng tinh thần toàn series.

Ghi nhớ

• Vòng đời dữ liệu gồm 5 giai đoạn Create → Store → Use → Archive → Destroy; mỗi giai đoạn có chính sách riêng và việc chuyển giai đoạn phải tự động, có bằng chứng.
• Retention đặt theo loại dữ liệu và pháp luật — chứng từ giao dịch/kế toán ngân hàng lưu tối thiểu 10 năm (Luật Kế toán), KYC ≥ 5 năm (Luật PCRT). Nguyên tắc: lấy thời hạn dài nhất trong các nghĩa vụ; tránh cả over-retention lẫn xoá quá sớm.
• Tiering hot/warm/cold phân tầng lưu theo tần suất truy cập; archival giữ dữ liệu ở cold storage (vẫn mã hoá, vẫn tìm lại được), purge xoá vĩnh viễn gồm cả backup, có phê duyệt Owner và bằng chứng.
• Right to be forgotten xung đột với nghĩa vụ lưu trữ; dung hoà bằng anonymization (xoá định danh không đảo ngược, ra khỏi phạm vi dữ liệu cá nhân) hoặc pseudonymization (mã giả có thể đảo ngược nếu giữ khoá), hoặc giữ-nhưng-hạn-chế khi buộc phải giữ định danh.
• Audit log ghi who-what-when-where; phải bất biến (append-only, WORM, hash chuỗi tamper-evident, tách quyền) và được giám sát chủ động để bắt truy cập bất thường (khối lượng lớn, ngoài giờ, ngoài vai trò, chuỗi rủi ro).
• Toàn series là một operating model khép vòng: governance → catalog → phân loại → bảo vệ → đảm bảo → vòng đời/audit → KPI phản hồi về Council. Bộ KPI cốt lõi: data quality score, catalog coverage, % dữ liệu được phân loại, số sự cố, thời gian đáp ứng yêu cầu chủ thể.