AppSec 8 — Bảo mật dữ liệu & tuân thủ ngân hàng

Bảy bài trước của series đi từ tổng quan (sec-01), qua OWASP Top 10, đào sâu injection & authentication, access control & mật mã, quản lý bí mật & chuỗi cung ứng, bảo mật API, rồi DevSecOps & công cụ tự động. Tất cả đều là góc nhìn của ứng dụng: bảo vệ code, endpoint, quy trình build.

Bài cuối này đổi trục nhìn. Với một đội dữ liệu ngân hàng, thứ cần bảo vệ cuối cùng không phải là ứng dụng — mà là dữ liệu khách hàng. Ứng dụng chỉ là một trong nhiều nơi dữ liệu chảy qua: nó nằm trong database, đi qua pipeline ETL, đọng lại trong warehouse/lake, phơi ra qua API, xuất thành file CSV gửi đối tác. Bảo vệ một tầng ứng dụng mà để hở các tầng còn lại thì dữ liệu vẫn rò. Bài này trình bày tư duy data-centric security (bảo mật lấy dữ liệu làm trung tâm), rồi khép lại bằng nghĩa vụ tuân thủ đặc thù ngành ngân hàng và một bản đồ toàn series.

Data-centric security là gì

Cách bảo mật truyền thống lấy hạ tầng làm trung tâm: dựng tường lửa, phân vùng mạng, khoá host. Mô hình đó ngầm giả định "trong tường là an toàn". Nhưng dữ liệu ngày nay không nằm yên trong một tường: nó sao chép sang môi trường test, đẩy lên lake, đổ vào công cụ BI, xuất ra máy nhân viên. Mỗi lần dịch chuyển là một lần rơi khỏi lớp bảo vệ hạ tầng cũ.

Data-centric security đảo lại: bảo vệ đi theo chính dữ liệu, bất kể nó đang ở đâu. Bốn bước lõi, áp lên từng loại dữ liệu:

1. Phân loại (classify) — dữ liệu nào nhạy cảm tới mức nào? Không thể bảo vệ đều tay mọi thứ; phải biết đâu là PII, đâu là số thẻ, đâu là dữ liệu công khai. Phân loại là bước quyết định vì mọi biện pháp sau đều căn theo nó.
2. Bảo vệ (protect) — áp mã hoá, tokenization, masking tương ứng mức nhạy cảm. Đây là nội dung gov-05 — mã hoá & masking.
3. Kiểm soát truy cập (control) — ai được đọc dữ liệu nào, least-privilege, row/column-level security. Chi tiết ở gov-06 — access control.
4. Giám sát (monitor) — ghi log ai truy cập dữ liệu nhạy cảm, phát hiện truy cập bất thường, DLP.

Ba mức phân loại thường dùng ở ngân hàng: Public (thông tin lãi suất niêm yết) → Internal (báo cáo nội bộ) → Confidential/PII (tên, CCCD, số điện thoại) → Restricted (số thẻ PAN, số dư, dữ liệu định danh sinh trắc). Mức càng cao, biện pháp bảo vệ càng ngặt: Restricted gần như luôn phải tokenize/mã hoá và giới hạn truy cập tới rất ít người.

Điểm mấu chốt của tư duy này: cùng một trường dữ liệu, bảo vệ nó ở mọi nơi nó xuất hiện — trong DB, trong bản sao lake, trong file export, trong log. Không có "chỗ nội bộ nên khỏi cần".

Bảo mật theo từng thành phần hệ dữ liệu

Dữ liệu ngân hàng chảy qua một chuỗi thành phần. Mỗi thành phần có bề mặt tấn công riêng.

Database

Nơi dữ liệu "nằm yên" nhiều nhất, và là mục tiêu số một.

• Least-privilege account — ứng dụng kết nối bằng account chỉ có đúng quyền cần (đọc/ghi bảng nghiệp vụ), không dùng superuser. Tách account đọc-báo-cáo khỏi account ghi-giao-dịch.
• Mã hoá at-rest — bật encryption ở tầng storage (TDE) và/hoặc mã hoá cột nhạy cảm; xem gov-05.
• Audit — bật log truy cập, đặc biệt các bảng chứa PII/số thẻ.
• Network isolation — DB nằm trong subnet riêng, không expose ra Internet. Chỉ ứng dụng trong VPC gọi được; không mở port 5432/3306 ra ngoài. Rất nhiều vụ rò rỉ đến từ một DB dev bị hở public.
• Không dùng dữ liệu thật ở môi trường phi-production — hoặc mask/tổng hợp trước khi copy sang test.

Pipeline / ETL

Dữ liệu di chuyển — dễ bị bỏ quên vì "chỉ là tạm".

• Secret của pipeline — credential DB nguồn/đích, key API đối tác không được hardcode; dùng secret manager (xem sec-05).
• Dữ liệu tạm (staging/temp) — file trung gian, bảng staging thường chứa PII plaintext và hay bị quên xoá. Phải mã hoá hoặc dọn ngay sau khi dùng.
• Mã hoá in-transit giữa các chặng, kể cả nội bộ.

Data warehouse / lake

Nơi tập trung dữ liệu để phân tích — "mỏ vàng" nếu lọt vào tay sai.

• Phân quyền chặt — least-privilege trên schema/bảng; analyst chỉ thấy phần dữ liệu thuộc phạm vi công việc.
• RLS (Row-Level Security) — lọc dòng theo người dùng: cán bộ chi nhánh A chỉ thấy dòng của chi nhánh A.
• Column masking / che PII — analyst thấy dữ liệu đã mask (0912****78), chỉ vai trò được duyệt mới thấy giá trị thật.
• Lake trên object storage (S3/GCS): cực kỳ dễ misconfig lộ bucket — sẽ nói ở phần threat.

API dữ liệu

Bề mặt tấn công lớn nhất của hệ hiện đại — đã có riêng sec-06 — bảo mật API. Nhắc lại lõi: authorization object-level (chống BOLA/IDOR), rate limit, validate schema, API gateway, không over-fetch dữ liệu nhạy cảm.

File / export

Điểm rò rỉ bị xem thường nhất: dữ liệu rời khỏi hệ thống thành file.

• Kiểm soát tải xuống — ai được export bảng nào, giới hạn số dòng, phê duyệt export lớn.
• Watermark — nhúng dấu định danh người tải vào file/báo cáo để truy vết nguồn rò khi lộ.
• Log mọi lần export dữ liệu nhạy cảm — chính là dữ liệu để giám sát ở phần sau.

Threat với hệ dữ liệu

Hai threat đặc biệt đáng lưu ý ở ngân hàng. Insider threat khó chống nhất vì kẻ trong nội bộ có quyền hợp pháp — phòng thủ dựa vào least-privilege (giới hạn phạm vi), giám sát hành vi (một analyst đột nhiên tải 500 nghìn bản ghi khách hàng lúc 2 giờ sáng), và tách quyền (không ai một mình làm trọn một thao tác nhạy cảm). Misconfig lộ bucket đơn giản nhưng gây phần lớn vụ lộ dữ liệu quy mô lớn trên báo chí — một tick "public" đặt nhầm là toàn bộ lake ra ngoài. Phòng bằng "chặn public truy cập" mặc định ở cấp tổ chức, cộng quét cấu hình tự động (một dạng IaC scanning, xem sec-07).

Giám sát & phát hiện

Bảo vệ và phân quyền là phòng ngừa; giám sát là để phát hiện khi phòng ngừa bị vượt qua. Ba trụ:

• DLP (Data Loss Prevention) — công cụ nhận diện dữ liệu nhạy cảm (số thẻ theo pattern, CCCD) và chặn/cảnh báo khi nó rời hệ thống qua email, upload, export.
• Audit log truy cập dữ liệu nhạy cảm — ghi lại ai, khi nào, truy cập bản ghi nào. Đây là nền của điều tra sự cố. Log phải được bảo vệ chống sửa (append-only) — nếu không, kẻ tấn công xoá dấu vết.
• Phát hiện truy cập bất thường — dựng baseline hành vi bình thường rồi cảnh báo lệch: truy cập ngoài giờ, khối lượng đọc tăng đột biến, truy cập tài khoản không thuộc phạm vi. Đây chính là điểm giao với observability — audit log và metric truy cập nên chảy vào cùng hệ thu thập/cảnh báo mô tả ở obs-01 — tổng quan observability.

Minh hoạ: truy vấn giám sát truy cập bất thường

Một truy vấn giám sát điển hình: đếm và tổng hợp giao dịch theo từng tài khoản trong một cửa sổ thời gian để phát hiện hành vi bất thường (số lượng giao dịch đột biến, tổng giá trị lớn). Ở đây transactions đóng vai "dấu vết truy cập/hoạt động", customers cho biết chủ tài khoản để đội giám sát rà soát:

-- ▶ Chạy được
SELECT c.full_name,
       a.account_no,
       COUNT(t.id)          AS so_giao_dich,
       SUM(t.amount)        AS tong_gia_tri,
       MAX(t.created_at)    AS lan_cuoi
FROM transactions t
JOIN accounts a  ON a.id = t.account_id
JOIN customers c ON c.id = a.customer_id
WHERE t.created_at >= NOW() - INTERVAL '1 day'
GROUP BY c.full_name, a.account_no
HAVING COUNT(t.id) > 50
ORDER BY so_giao_dich DESC;

Ý tưởng: mệnh đề HAVING COUNT(t.id) > 50 lọc ra các tài khoản có số giao dịch trong 24 giờ vượt ngưỡng — ứng viên cho việc rà soát thủ công (có thể là exfiltration, gian lận, hoặc chỉ là tài khoản doanh nghiệp lượng lớn hợp lệ). Trong thực tế, ngưỡng cứng 50 được thay bằng baseline động theo từng tài khoản, và truy vấn này chỉ là một tín hiệu đưa vào hệ cảnh báo, không phải phán quyết. Cùng khuôn mẫu này áp cho giám sát export: đếm số bản ghi một user tải trong ngày, cảnh báo khi vượt baseline.

Incident response

Không hệ thống nào bất khả xâm phạm. Khác biệt giữa "sự cố nhỏ" và "thảm hoạ" nằm ở chuẩn bị trước và phản ứng có quy trình. Quy trình chuẩn 6 giai đoạn:

1. Chuẩn bị — có sẵn playbook, đội IR (incident response), kênh liên lạc, backup, và biết trước nghĩa vụ thông báo (bên dưới). Diễn tập định kỳ.
2. Phát hiện — nhận biết sự cố qua giám sát/DLP/báo cáo; xác định phạm vi: dữ liệu nào, bao nhiêu bản ghi, có PII không.
3. Kiềm chế (containment) — chặn lan rộng: cô lập hệ thống bị xâm nhập, thu hồi credential lộ, chặn IP. Ưu tiên dừng chảy máu trước khi truy nguyên.
4. Xoá bỏ (eradication) — loại nguyên nhân gốc: gỡ mã độc, vá lỗ hổng, đóng cấu hình sai.
5. Khôi phục (recovery) — đưa hệ thống trở lại hoạt động an toàn từ backup sạch; theo dõi kỹ để chắc chắn kẻ tấn công không còn.
6. Bài học (lessons learned) — hậu-sự-cố (post-mortem) không đổ lỗi: chuyện gì xảy ra, vì sao phòng thủ hụt, cải tiến gì. Vòng lặp quay lại "chuẩn bị".

Nghĩa vụ thông báo vi phạm. Với ngân hàng, một vụ rò rỉ PII/dữ liệu khách hàng thường kèm nghĩa vụ pháp lý phải thông báo — cho cơ quan quản lý và/hoặc chủ thể dữ liệu bị ảnh hưởng, trong khung thời gian quy định. Đây không phải lựa chọn kỹ thuật mà là bắt buộc tuân thủ; playbook IR phải ghi rõ khi nào, báo cho ai, trong bao lâu. Chuẩn bị điều này trước sự cố, vì lúc khủng hoảng không còn thời gian đọc luật.

Tuân thủ ngân hàng

Ngân hàng vận hành trong một khung pháp lý dày. Ba nhóm yêu cầu liên quan trực tiếp tới bảo mật dữ liệu ở Việt Nam:

• Nghị định 13/2023/NĐ-CP về bảo vệ dữ liệu cá nhân — khung pháp lý chính về PII tại Việt Nam. Quy định nguyên tắc xử lý dữ liệu cá nhân, quyền của chủ thể dữ liệu, nghĩa vụ của bên xử lý, và yêu cầu bảo vệ. Đây là nội dung gov-07 — quyền riêng tư & tuân thủ; mọi biện pháp phân loại/mã hoá/masking/access control ở trên chính là cách thực thi kỹ thuật cho nghĩa vụ pháp lý này.
• Yêu cầu an toàn thông tin của NHNN — Ngân hàng Nhà nước ban hành các quy định về bảo đảm an toàn hệ thống thông tin trong hoạt động ngân hàng (phân loại hệ thống theo cấp độ, yêu cầu kiểm soát, báo cáo sự cố). Các biện pháp bài này — network isolation, mã hoá, audit, incident response — là những khối xây dựng để đáp ứng.
• PCI-DSS cho dữ liệu thẻ — chuẩn bảo mật dữ liệu thẻ thanh toán (Payment Card Industry Data Security Standard). Nguyên tắc khái quát: không lưu dữ liệu nhạy cảm không cần (đặc biệt không lưu CVV), mã hoá số thẻ (PAN) khi lưu và truyền, hạn chế truy cập tới dữ liệu thẻ, giám sát và kiểm thử bảo mật định kỳ. Tokenization (thay PAN bằng token) là kỹ thuật cốt lõi để giảm phạm vi (scope) phải tuân thủ.

Lưu ý: bài này trình bày tinh thần các yêu cầu để định hướng kỹ thuật, không trích số điều/khoản cụ thể — khi triển khai thực tế phải đối chiếu văn bản pháp lý hiện hành và bộ phận pháp chế/tuân thủ.

Điểm cần thấm: tuân thủ và bảo mật kỹ thuật không tách rời. Nghị định 13, quy định NHNN, PCI-DSS đặt ra yêu cầu; AppSec (7 bài trước) và governance (gov-05, gov-06, gov-07) cung cấp cách thực thi. Một hệ thống "đạt tuân thủ" trên giấy nhưng thủng kỹ thuật là ảo tưởng; ngược lại, kỹ thuật tốt mà không map vào yêu cầu pháp lý thì không chứng minh được khi bị kiểm tra.

Bản đồ toàn series

Tám bài AppSec gộp lại thành một mạch từ nền tảng tới chuyên sâu và tổng kết:

Ba bài đầu xây nền và điểm mặt rủi ro; ba bài giữa đào sâu từng lớp phòng thủ; bài 7 tự động hoá; bài 8 nâng lên góc nhìn dữ liệu và pháp lý. AppSec + governance + tuân thủ khớp thành một bức tranh: AppSec bảo vệ đường đi của dữ liệu, governance bảo vệ bản thân dữ liệu, tuân thủ chứng minh ta làm đúng.

Use case thực tế

Bối cảnh. Đội dữ liệu NCB xây một data lake tập trung để phục vụ phân tích rủi ro và báo cáo. Lake gom dữ liệu từ core banking (khách hàng, tài khoản, giao dịch), thẻ, và kênh số. Trước khi mở quyền cho đội analyst, đội security & governance áp một lần rà soát data-centric theo đúng bốn bước.

1. Phân loại. Quét và gán nhãn: tên/CCCD/SĐT → Confidential (PII); số thẻ PAN & số dư → Restricted; mã sản phẩm → Internal. Phát hiện một bảng staging còn giữ PAN plaintext và một cột CVV (không bao giờ được lưu) — xoá ngay.

2. Bảo vệ. Restricted được tokenize (PAN → token) và mã hoá cột; PII bật masking động: analyst thấy NGUYEN V** A, 0912****78.

3. Kiểm soát truy cập. Áp least-privilege + RLS theo chi nhánh; chỉ 3 vai trò được duyệt mới un-mask, và mỗi lần un-mask đều bị log. Bucket lake chuyển sang chặn public mặc định; quét cấu hình phát hiện 1 bucket dev từng để public — đóng lại.

4. Giám sát. Bật audit log truy cập bảng PII, đẩy vào hệ observability chung; dựng cảnh báo "một user tải > baseline bản ghi/ngày". Ba tuần sau, cảnh báo bắn: một tài khoản analyst tải hơn 200 nghìn bản ghi khách hàng lúc nửa đêm. Kích hoạt incident response: kiềm chế (khoá account, thu hồi token) → điều tra (credential bị lộ qua máy cá nhân nhiễm mã độc) → xoá bỏ (rotate secret, vá) → khôi phục → post-mortem (bổ sung MFA, siết export). Nhờ audit log append-only, đội xác định chính xác phạm vi để thực hiện nghĩa vụ thông báo theo quy định.

Kết quả: sự cố bị chặn trong giai đoạn thử thay vì thành breach quy mô lớn — vì bảo vệ đi theo dữ liệu và giám sát bắt được bất thường.

Ghi nhớ

• Data-centric security: bảo vệ đi theo dữ liệu, không theo hạ tầng — bốn bước phân loại → bảo vệ → kiểm soát truy cập → giám sát, áp cho dữ liệu ở mọi nơi nó xuất hiện.
• Phân loại là bước quyết định — không biết đâu là PII/Restricted thì không thể bảo vệ đúng mức; ngân hàng thường dùng thang Public → Internal → Confidential → Restricted.
• Bảo mật từng thành phần: database (least-privilege, mã hoá, audit, không expose ra ngoài), pipeline (secret, dọn dữ liệu tạm), warehouse/lake (RLS, che PII), API (sec-06), file/export (kiểm soát tải, watermark, log).
• Threat đặc thù: breach, insider threat (khó nhất — chống bằng least-privilege + giám sát hành vi + tách quyền), exfiltration, ransomware, misconfig lộ bucket (gây phần lớn vụ lộ quy mô lớn).
• Giám sát dựa trên DLP, audit log append-only cho dữ liệu nhạy cảm, và phát hiện truy cập bất thường — giao với observability (obs-01).
• Incident response 6 bước: chuẩn bị → phát hiện → kiềm chế → xoá bỏ → khôi phục → bài học; chuẩn bị nghĩa vụ thông báo vi phạm trước sự cố.
• Tuân thủ ngân hàng: Nghị định 13/2023 (PII — gov-07), yêu cầu an toàn thông tin NHNN, PCI-DSS cho dữ liệu thẻ (không lưu CVV, mã hoá/tokenize PAN). Đây là yêu cầu; AppSec + governance là cách thực thi.
• Bức tranh trọn vẹn: AppSec bảo vệ đường đi của dữ liệu, governance bảo vệ chính dữ liệu, tuân thủ chứng minh làm đúng — không tách rời.