Giữ log 12 tháng, xoá dữ liệu không chậm trễ: bài toán kiến trúc API

Một bộ quy chuẩn bắt bạn giữ audit log ít nhất 12 tháng. Một bộ luật khác bắt bạn xoá dữ liệu cá nhân “không chậm trễ” khi có căn cứ. Đặt email khách hàng vào một kho log phải sống 12 tháng là tự tạo ra một nơi mà mọi yêu cầu xoá sau này đều phải lần tới.

Đó là bài toán của bất kỳ ai xây API cho hệ thống thanh toán, y tế hay sàn thương mại điện tử có người dùng ở châu Âu và Mỹ. Đọc kỹ từng điều khoản của GDPR, CCPA/CPRA, HIPAA và PCI DSS, phần lớn chúng quy về ba quyết định kỹ thuật: API nhận trường nào, log ghi gì, và dữ liệu nằm ở đâu bao lâu.

Nếu bạn muốn làm FDE, đây là phần đáng đầu tư để hiểu ở mức thiết kế, vì khi chạm vào dữ liệu thật của khách hàng, đó chính là những quyết định bạn sẽ phải đưa ra hoặc giải thích được.

Hai lực kéo ngược nhau trên cùng một bảng log

Lực thứ nhất là “hãy nhớ”. Theo bài phân tích của OneUptime về PCI DSS, Requirement 10.5.1 yêu cầu ít nhất 12 tháng lịch sử audit, trong đó ba tháng gần nhất phải truy xuất được ngay.

Wiz Academy cũng xếp cơ chế log theo dõi mọi API call và response vào nhóm kiểm soát tuân thủ, vì nó ghi lại thời điểm và ngữ cảnh mỗi lần dữ liệu bị truy cập. Traceable thì liệt kê “insufficient logging and monitoring” vào nhóm rủi ro tuân thủ hàng đầu của API.

Lực thứ hai là “hãy quên”. GDPR, áp dụng tại mọi quốc gia thành viên EU từ ngày 25/5/2018, có Điều 25 yêu cầu hệ thống được thiết kế để thực thi các nguyên tắc như tối thiểu hoá dữ liệu. Điều 17 buộc bên xử lý xoá dữ liệu cá nhân không chậm trễ khi có căn cứ.

Và GDPR không chỉ dành cho công ty châu Âu: nó điều chỉnh việc xử lý dữ liệu của người dùng tại EU, nên một team ở Hà Nội phục vụ khách Đức cũng nằm trong phạm vi.

Có điều, hai lực này chỉ va nhau khi log chứa dữ liệu cá nhân. Một dòng log ghi “user 84213 đọc hồ sơ 5521 lúc 09:14, kết quả 200” có thể nằm yên 12 tháng.

Một dòng log chép nguyên response body có tên, email và số điện thoại thì biến kho log thành một database cá nhân thứ hai, và mọi yêu cầu xoá phải lần vào đó.

Lỗ rò thường nằm ở trường “details”

Câu khẩu hiệu “log mọi API call và response” nghe an toàn, nhưng đó cũng là cách dễ nhất để rò dữ liệu. OneUptime chỉ ra một mẫu lỗi rất phổ biến: một object details chung chung trong audit record trở thành đường lọt của PAN, CVV và token xác thực. Lập trình viên thêm nó cho tiện debug, rồi một ngày ai đó nhét cả request body vào.

Với PCI DSS, hậu quả rõ ràng nhất. Mã xác minh thẻ và các dữ liệu xác thực nhạy cảm khác không được giữ lại sau khi giao dịch được authorize. Nếu CVV lọt vào log, và log phải được giữ 12 tháng theo 10.5.1, bạn đã tự đặt mình vào thế vi phạm suốt 12 tháng.

Thử hình dung một endpoint POST /payments. Bản log “tiện” sẽ trông như sau:

{"event":"payment.create","user":"[email protected]","details":{"pan":"4111...","cvv":"123","amount":250000}}

Bản log thiết kế cho tuân thủ chỉ giữ những gì kiểm toán viên cần:

{"event":"payment.create","actor_id":"u_84213","resource":"pay_9f2a","card_ref":"tok_7c1e","result":"authorized","ts":"2026-10-08T09:14:02Z"}

Khác biệt nằm ở cách chặn. OneUptime khuyên chặn payload nhạy cảm ngay ở bước ingest, không trông vào việc mỗi developer nhớ che dữ liệu. Trên thực tế, cách bền nhất là schema dạng allowlist: logger từ chối mọi trường không có trong danh sách, và không tồn tại trường tự do nào.

Quyền xoá là một workflow, không phải một câu DELETE

Nếu log là nơi luật bắt bạn nhớ, thì các quyền của người dùng là nơi luật bắt bạn chứng minh rằng mình biết dữ liệu đang nằm ở đâu.

Wiz Academy tóm lại rằng dưới CCPA/CPRA, API phải hỗ trợ bốn quyền: được biết, được xoá, được từ chối việc bán hoặc chia sẻ, và được sửa, đồng thời minh bạch về việc thu thập, xử lý và lưu giữ.

Văn phòng Tổng chưởng lý California đưa ra con số cụ thể: yêu cầu biết, xoá hoặc sửa phải được phản hồi trong 45 ngày lịch, có thể gia hạn thêm 45 ngày. Đặt vào lịch, một yêu cầu đến ngày 1/3 có hạn mặc định ngày 15/4, và muộn nhất là cuối tháng 5 nếu gia hạn.

Hệ thống của bạn cần lưu ngày nhận, trạng thái và hạn chót cho từng yêu cầu, tức là một bảng privacy_requests có state machine, không phải một ticket Jira trôi nổi.

Quyền xoá theo CCPA cũng đi kèm “một số ngoại lệ”. Vì thế luồng xoá không thể là tuyệt đối: nó phải có bước kiểm tra xem bản ghi nào cần giữ lại vì lý do hợp lệ, xoá phần còn lại, và ghi lại quyết định đó.

GDPR Điều 17 thêm áp lực về tốc độ, và áp lực ấy lan ra mọi nơi dữ liệu có bản sao: database chính, replica, cache, kho log, backup.

Về rủi ro, CCPA nhìn chung không cho cá nhân tự khởi kiện, ngoại trừ trường hợp rò rỉ dữ liệu, nơi mức bồi thường theo luật tính trên từng sự cố, tối đa 750 USD mỗi sự cố. Các vi phạm khác do Tổng chưởng lý hoặc cơ quan bảo vệ quyền riêng tư của bang (CPPA) xử lý.

Rò rỉ là trường hợp hiếm hoi mà người dùng được tự đứng ra kiện, nên một kho log chứa dữ liệu cá nhân chính là phần rủi ro mà kỹ sư có thể cắt bỏ trực tiếp bằng thiết kế.

Điều khoản nào chạm vào lớp nào

Xếp các yêu cầu theo ba lớp kỹ thuật sẽ thấy rõ phần việc của kỹ sư:

Quy định	Điều khoản then chốt	API	Log	Lưu trữ
GDPR	Điều 25: bảo vệ dữ liệu từ thiết kế; Điều 17: quyền được xoá	Chỉ nhận trường thực sự cần	Không chép dữ liệu cá nhân vào log	Xoá được ở mọi bản sao, kể cả backup
CCPA/CPRA	Bốn quyền: biết, xoá, từ chối bán/chia sẻ, sửa; hạn 45 ngày	Có endpoint hoặc luồng cho từng quyền	Ghi lại tiến trình xử lý yêu cầu	Xoá có kiểm tra ngoại lệ
HIPAA	Privacy Rule, Security Rule, Breach Notification Rule	Kiểm soát khi nhận và xử lý ePHI	Đủ dấu vết để phát hiện và thông báo rò rỉ	Áp kiểm soát bảo mật lên ePHI
PCI DSS 4.0	Yêu cầu riêng cho API; Requirement 10.5.1	Xác thực, phân quyền, mã hoá	Giữ 12 tháng, 3 tháng truy xuất ngay	Không giữ CVV sau authorize

Đọc theo cột, lớp log là nơi các yêu cầu giao nhau dày nhất, nên đó là lớp đáng được thiết kế cẩn thận ngay từ ngày đầu.

HIPAA và PCI DSS 4.0 nói thẳng hơn bạn nghĩ

Phần lớn quy định không nhắc chữ “API”. Wiz Academy lưu ý ngoại lệ là PCI DSS 4.0, bộ quy chuẩn đặt ra yêu cầu tuân thủ riêng cho API, gồm xác thực, kiểm soát truy cập, mã hoá và quản lý lỗ hổng.

HIPAA gồm ba quy tắc: Privacy Rule, Security Rule và Breach Notification Rule. Theo cách Wiz diễn giải, API phải kiểm soát cả khâu tiếp nhận lẫn khâu xử lý ePHI, có các biện pháp bảo mật đi kèm, và hỗ trợ được việc thông báo khi rò rỉ.

Quy tắc thứ ba quay lại đúng câu chuyện log: không có dấu vết truy cập đầy đủ, bạn không trả lời được câu hỏi ai đã bị lộ dữ liệu.

Vì thế, nếu chỉ được làm một việc đầu tiên tại hệ thống của khách hàng, hãy vẽ sơ đồ luồng dữ liệu nhạy cảm: nó vào qua endpoint nào, được ghi ra những log nào, sao chép sang kho nào. Bản đồ đó trả lời được cùng lúc câu hỏi của kiểm toán PCI, yêu cầu xoá theo GDPR và nghĩa vụ thông báo theo HIPAA.

Với một FDE, thời điểm hợp lý để làm việc này là tuần đầu tại site khách hàng, trong buổi rà soát luồng dữ liệu trước khi nối bất cứ agent hay pipeline nào vào hệ thống của họ. Phát hiện một trường details chứa số thẻ lúc đó rẻ hơn rất nhiều so với phát hiện nó trong đợt kiểm toán.

Một kỹ năng đáng ghi vào CV

Nếu dự án bạn nhắm tới phục vụ người dùng ở EU hay California, hoặc xử lý dữ liệu thẻ, dữ liệu y tế, các quy định trên sẽ đi theo dự án dù bạn ngồi ở Hà Nội hay TP.HCM.

Khi đọc JD, hãy để ý các từ như PCI, HIPAA, GDPR, audit logging, data retention hay PII handling, và coi đó là tín hiệu bạn sẽ phải ra quyết định thiết kế, không chỉ viết CRUD.

Trên CV, đừng viết “hiểu biết về GDPR”. Hãy viết điều bạn đã xây: một logger dạng allowlist chặn PAN và token ở bước ingest, một workflow xoá dữ liệu có SLA 45 ngày và nhánh ngoại lệ, một chính sách lưu log 3 tháng nóng, 9 tháng lưu trữ lạnh cho đủ 12 tháng.

Người phỏng vấn có thể hỏi sâu vào bất kỳ dòng nào trong đó, và bạn trả lời được bằng chính quyết định mình đã đưa ra.

Luật dữ liệu sẽ còn thay đổi, nhưng nguyên tắc thiết kế thì ổn định: log ghi lại hành động bằng ID, dữ liệu cá nhân nằm ở một nơi duy nhất biết cách tự xoá. Kỹ sư nào thiết kế được như vậy ngay từ ngày đầu sẽ không phải viết lại hệ thống khi kiểm toán viên gõ cửa.