Bài 33 — PCI-DSS, ISO 27001 — Compliance cho BA

Mở đầu — vì sao bài này quan trọng

Hãy hình dung bạn là Technical BA của một ví điện tử đang chuẩn bị tích hợp thanh toán thẻ quốc tế. Mọi thứ về tính năng đều ổn: luồng nạp tiền chạy ngon, API thông suốt, UI mượt mà. Nhưng đến buổi review với đối tác ngân hàng, câu hỏi đầu tiên không phải về tính năng, mà là: "Hệ thống các bạn đã đạt PCI-DSS Level mấy? Số thẻ được lưu ở đâu, mã hóa thế nào, ai có quyền truy cập?" Nếu bạn ấp úng, dự án có thể bị chặn ngay tại cửa, dù code đã viết xong.

Đó chính là lý do bài này quan trọng. Trong các bài trước về security (OWASP Top 10, Authentication, Encryption), bạn đã học cách bảo vệ hệ thống ở mức kỹ thuật. Bài 33 này nói về một lớp khác: compliance — sự tuân thủ các bộ tiêu chuẩn bắt buộc. Compliance không hỏi "code của bạn có an toàn không" mà hỏi "bạn có chứng minh được mình an toàn theo một bộ quy tắc được thừa nhận trên toàn cầu không". Đây là phần mà rất nhiều BA bỏ qua, rồi phải trả giá đắt khi dự án đụng tới tiền, dữ liệu cá nhân, hoặc khách hàng là tổ chức tài chính.

Với Technical BA, compliance không phải việc của riêng đội Security hay Legal. Bạn là người dịch các yêu cầu của tiêu chuẩn thành requirement cụ thể trong spec — và nếu bạn viết sai ngay từ đầu, cả hệ thống có thể phải làm lại. Bài này giúp bạn hiểu đủ sâu hai tiêu chuẩn phổ biến nhất mà BA tại Việt Nam hay gặp: PCI-DSS (cho dữ liệu thẻ) và ISO 27001 (cho quản lý an toàn thông tin tổng thể).

Khái niệm cốt lõi

Compliance là gì và khác gì với Security

Security là trạng thái hệ thống được bảo vệ. Compliance là bằng chứng rằng bạn đã làm theo một bộ quy tắc cụ thể, có thể kiểm toán (audit) được. Một hệ thống có thể rất an toàn về mặt kỹ thuật nhưng vẫn fail compliance vì thiếu tài liệu, thiếu log, hoặc không có quy trình được phê duyệt. Ngược lại, đạt compliance không tự động nghĩa là bất khả xâm phạm — nó là mức sàn tối thiểu, không phải trần.

Điểm mấu chốt BA cần nhớ: compliance tạo ra requirement bắt buộc, không thương lượng. Khi một yêu cầu đến từ PCI-DSS, bạn không thể để Product Owner "deprioritize" nó như một feature thường. Nó là điều kiện để hệ thống được phép vận hành.

PCI-DSS — Tiêu chuẩn bảo mật dữ liệu thẻ thanh toán

PCI-DSS (Payment Card Industry Data Security Standard) là bộ tiêu chuẩn do hội đồng các tổ chức thẻ lớn (Visa, Mastercard, American Express, JCB, Discover) lập ra. Nó bắt buộc với mọi đơn vị xử lý, lưu trữ hoặc truyền dữ liệu thẻ — từ merchant bán hàng online, cổng thanh toán, đến ngân hàng. Phiên bản hiện hành là PCI-DSS v4.0.

PCI-DSS xoay quanh khái niệm CDE — Cardholder Data Environment (môi trường dữ liệu chủ thẻ): tất cả hệ thống chạm vào dữ liệu thẻ. Mục tiêu lớn nhất là thu hẹp CDE càng nhỏ càng tốt — càng ít hệ thống chạm vào số thẻ thì phạm vi phải tuân thủ càng nhỏ, chi phí audit càng thấp.

Tiêu chuẩn có 12 requirement gom thành 6 nhóm mục tiêu:

Xây và duy trì mạng bảo mật: cài firewall bảo vệ CDE; không dùng mật khẩu/cấu hình mặc định của nhà cung cấp (vendor default).
Bảo vệ dữ liệu chủ thẻ: bảo vệ dữ liệu thẻ khi lưu trữ; mã hóa khi truyền qua mạng công cộng.
Quản lý lỗ hổng: dùng và cập nhật anti-virus; phát triển, vận hành hệ thống và ứng dụng an toàn (vá lỗi, secure coding).
Kiểm soát truy cập mạnh: hạn chế truy cập dữ liệu thẻ theo nguyên tắc "cần mới biết" (need-to-know); định danh và xác thực mọi truy cập; hạn chế truy cập vật lý.
Giám sát và kiểm thử mạng: ghi log và theo dõi mọi truy cập vào dữ liệu thẻ và tài nguyên mạng; kiểm thử bảo mật định kỳ (pentest, scan lỗ hổng).
Duy trì chính sách bảo mật thông tin: có policy được phê duyệt và phổ biến tới nhân viên.

Một điểm cực kỳ quan trọng với BA: PCI-DSS phân biệt rạch ròi loại dữ liệu nào được phép lưu và loại nào tuyệt đối cấm. PAN (Primary Account Number — số thẻ) nếu lưu thì phải mã hóa hoặc làm mờ (masking, chỉ hiện 6 số đầu + 4 số cuối). Nhưng dữ liệu xác thực nhạy cảm như CVV/CVV2 (3 số sau thẻ), full track data trên dải từ, và PIN thì tuyệt đối không được lưu trữ sau khi giao dịch hoàn tất — kể cả khi đã mã hóa. Đây là requirement mà BA phải ghi rõ trong data spec, vì lập trình viên rất hay vô tình log CVV ra file log để debug.

PCI-DSS chia merchant thành các Level (1 đến 4) dựa trên số lượng giao dịch mỗi năm. Level 1 (trên 6 triệu giao dịch/năm) phải qua audit độc lập bởi QSA (Qualified Security Assessor); các level thấp hơn có thể tự đánh giá bằng SAQ (Self-Assessment Questionnaire).

ISO 27001 — Hệ thống quản lý an toàn thông tin

Nếu PCI-DSS hẹp và sâu (chỉ về dữ liệu thẻ), thì ISO/IEC 27001 rộng và tổng quát. Đây là tiêu chuẩn quốc tế về ISMS — Information Security Management System (hệ thống quản lý an toàn thông tin). Nó không quy định "phải mã hóa bằng AES-256" mà yêu cầu tổ chức xây dựng một quy trình quản lý rủi ro có hệ thống: nhận diện tài sản thông tin, đánh giá rủi ro, chọn biện pháp kiểm soát, rồi liên tục cải tiến theo vòng PDCA (Plan-Do-Check-Act).

Trái tim của ISO 27001 là Annex A — danh mục các control (biện pháp kiểm soát). Phiên bản ISO 27001:2022 có 93 control chia thành 4 nhóm: tổ chức (organizational), con người (people), vật lý (physical) và công nghệ (technological). Tổ chức không bắt buộc áp dụng cả 93, mà chọn những control phù hợp dựa trên đánh giá rủi ro, rồi giải trình lựa chọn đó trong tài liệu SoA — Statement of Applicability.

Khác biệt then chốt với PCI-DSS: ISO 27001 là tự nguyện (nhưng thường được khách hàng doanh nghiệp yêu cầu như điều kiện hợp đồng), và nó chứng nhận cho tổ chức/quy trình, không phải cho một sản phẩm cụ thể. Một công ty đạt chứng chỉ ISO 27001 nghĩa là họ có hệ thống quản lý an toàn thông tin được kiểm toán bởi bên thứ ba, tái chứng nhận định kỳ (thường 3 năm, audit giám sát hằng năm).

Vai trò của Technical BA trong compliance

BA không phải auditor, nhưng là cầu nối giữa yêu cầu tiêu chuẩn và spec kỹ thuật. Cụ thể bạn sẽ:

Phân loại dữ liệu trong tài liệu nghiệp vụ: cái nào là PAN, cái nào là CVV, cái nào là PII — để biết requirement nào áp lên trường nào.
Viết requirement có thể truy vết (traceable) về tới control của tiêu chuẩn, ví dụ "Yêu cầu REQ-042 ánh xạ tới PCI-DSS Req 3.4 — masking PAN".
Định nghĩa requirement cho audit trail và logging đủ để chứng minh tuân thủ (ai truy cập dữ liệu thẻ, lúc nào).
Đặt câu hỏi đúng trong workshop để lộ ra các điểm CDE ẩn mà team không nhận ra.

Tình huống thực tế

Tình huống 1 — Ví điện tử Việt Nam và bẫy "lưu thẻ cho tiện"

Một ví điện tử tại TP.HCM (gọi là VietPay) muốn thêm tính năng "lưu thẻ để thanh toán nhanh lần sau". Product Owner mô tả: "Khách nhập thẻ một lần, mình lưu lại, lần sau chỉ cần nhập CVV là xong." Nghe rất hợp lý về UX.

BA trong dự án này nếu thiếu kiến thức compliance sẽ viết spec: "Lưu số thẻ, ngày hết hạn và CVV vào bảng saved_cards." Đây là một sai lầm nghiêm trọng — lưu CVV là vi phạm trực tiếp PCI-DSS, không có ngoại lệ nào.

BA giỏi sẽ làm khác: đề xuất dùng tokenization thông qua cổng thanh toán (như cách nhiều fintech Việt tích hợp với NAPAS hoặc các payment gateway quốc tế). Thay vì VietPay tự lưu PAN, cổng thanh toán trả về một token vô nghĩa thay cho số thẻ thật; lần sau khách thanh toán bằng token đó. CVV không bao giờ được lưu — mỗi giao dịch lưu thẻ vẫn yêu cầu nhập lại CVV nhưng chỉ truyền đi, không lưu. Nhờ vậy, hệ thống VietPay gần như không chạm vào PAN thật, CDE thu hẹp đáng kể, và phạm vi audit giảm từ "toàn bộ backend" xuống chỉ vài service tích hợp.

Bài học: BA phải biết rằng giải pháp tuân thủ tốt nhất thường là không tự lưu dữ liệu thẻ. Tokenization và outsourcing cho gateway đạt chứng nhận là cách hợp pháp để giảm gánh nặng compliance — và đây là quyết định kiến trúc mà BA cần nêu ra từ giai đoạn requirement, không phải để dev tự xoay sở.

Tình huống 2 — Công ty SaaS Đông Nam Á và hợp đồng phụ thuộc ISO 27001

Một startup SaaS quản lý nhân sự ở Singapore và Việt Nam (gọi là PeopleHub) đang chốt hợp đồng với một ngân hàng lớn. Đến phần due diligence, bộ phận mua hàng của ngân hàng gửi một bảng câu hỏi dài 120 mục, trong đó dòng đầu tiên: "Nhà cung cấp có chứng chỉ ISO 27001 còn hiệu lực không? Đính kèm certificate và SoA."

PeopleHub chưa có. Hợp đồng trị giá hơn 8 tỷ đồng/năm bị treo. Họ phải khởi động dự án đạt ISO 27001 gấp, và BA được giao việc rà soát toàn bộ luồng dữ liệu để chuẩn bị cho audit.

BA phát hiện nhiều khoảng trống: dữ liệu lương nhân viên (thông tin nhạy cảm) được truyền qua email nội bộ không mã hóa; không có log ai đã export báo cáo lương; quyền truy cập database production được cấp cho cả 12 lập trình viên thay vì theo nguyên tắc least privilege. Mỗi điểm này tương ứng với một control trong Annex A. BA lập bảng ánh xạ requirement–control, biến từng khoảng trống thành một user story có thể đưa vào sprint: ví dụ "Là admin, tôi cần mọi thao tác export dữ liệu lương được ghi audit log để phục vụ ISO 27001 control A.8.15 (Logging)."

Sau 7 tháng, PeopleHub đạt chứng chỉ và ký được hợp đồng.

Bài học: ISO 27001 ngày càng là điều kiện kinh doanh, không chỉ là chuyện kỹ thuật. BA tham gia sớm sẽ biến một loạt yêu cầu trừu tượng của tiêu chuẩn thành backlog cụ thể, traceable — đây chính là giá trị khác biệt của Technical BA so với BA thường.

Tình huống 3 — Log debug làm lộ dữ liệu thẻ

Một merchant thương mại điện tử bán hàng xuyên biên giới (gọi là ShopGlobal) bị QSA đánh trượt audit PCI-DSS dù hệ thống được mã hóa rất tốt. Lý do: trong quá trình xử lý lỗi thanh toán, đội dev đã thêm một dòng log.debug("Payment payload: " + requestBody) để tiện debug. Cái requestBody đó chứa nguyên cả PAN và CVV ở dạng plaintext, nằm rải rác trong file log suốt 6 tháng.

QSA chỉ ra điều này vi phạm cả Requirement 3 (bảo vệ dữ liệu lưu trữ) lẫn quy định cấm lưu CVV. Tệ hơn, các file log đó đã được sao chép sang hệ thống giám sát của bên thứ ba — vô tình mở rộng CDE ra cả nhà cung cấp logging.

Nếu BA đã viết một logging spec rõ ràng từ đầu (như bài "Logging Spec & Audit Trail" trong khóa này đề cập), quy định "không bao giờ log nguyên payload thanh toán, phải masking PAN và loại bỏ CVV trước khi ghi log", lỗi này đã không xảy ra.

Bài học: Compliance fail thường không đến từ thuật toán mã hóa yếu, mà từ những lỗ rò rỉ "vô tình" — log, file tạm, email, màn hình debug. BA có tư duy compliance sẽ chủ động cài các ràng buộc này vào non-functional requirement và logging spec.

Hướng dẫn từng bước

Khi bạn được giao một dự án có yếu tố compliance, đây là quy trình thực dụng:

Xác định tiêu chuẩn nào áp dụng. Hỏi: hệ thống có chạm vào dữ liệu thẻ không? → PCI-DSS. Khách hàng/ngành có yêu cầu ISMS không? → ISO 27001. Có dữ liệu cá nhân không? → còn liên quan tới luật bảo vệ dữ liệu (ở Việt Nam là Nghị định 13/2023 về bảo vệ dữ liệu cá nhân — nằm ngoài phạm vi bài này nhưng nên ghi nhớ).

Vẽ data flow và khoanh vùng phạm vi. Với PCI-DSS, vẽ luồng dữ liệu thẻ để xác định CDE — mọi nơi PAN/CVV đi qua. Mục tiêu là thu hẹp vùng này.

Phân loại dữ liệu trong từng trường. Lập bảng: trường nào là PAN, CVV, PII, dữ liệu thường. Đánh dấu rõ trường nào cấm lưu, trường nào phải mã hóa/masking.

Ánh xạ requirement tới control. Tạo một compliance traceability matrix: mỗi control của tiêu chuẩn → requirement/user story tương ứng → cách verify. Đây là tài liệu vàng khi audit.

Viết requirement cho logging và audit trail. Quy định rõ thao tác nào phải ghi log, log chứa gì, ai xem được, giữ bao lâu — và đặc biệt cái gì cấm xuất hiện trong log.

Đưa các ràng buộc compliance vào NFR và Definition of Done. Để không feature nào được coi là "xong" nếu chưa thỏa control liên quan.

Phối hợp với QSA/auditor và đội Security. BA chuẩn bị tài liệu nghiệp vụ, data flow, và bảng ánh xạ để buổi audit diễn ra suôn sẻ.

Lỗi thường gặp & mẹo

Nhầm "an toàn về kỹ thuật" với "đạt compliance". Hệ thống mã hóa tốt vẫn fail nếu thiếu tài liệu, thiếu log, hoặc quy trình không được phê duyệt. Mẹo: luôn hỏi "ta chứng minh điều này thế nào khi auditor đến?".

Viết spec lưu CVV "cho tiện UX". Đây là vi phạm PCI-DSS phổ biến và nghiêm trọng nhất. Mẹo: ghi đậm trong data spec "CVV chỉ được truyền, tuyệt đối không lưu, không log".

Coi compliance là việc của riêng đội Security. Khi BA bỏ mặc, các yêu cầu tuân thủ lọt khỏi backlog và bị phát hiện muộn. Mẹo: đưa compliance vào ngay từ workshop requirement đầu tiên.

Để CDE phình to không kiểm soát. Mỗi service chạm vào dữ liệu thẻ làm tăng chi phí audit. Mẹo: ưu tiên tokenization và outsourcing cho gateway đạt chuẩn để CDE nhỏ nhất.

Áp dụng cả 93 control ISO 27001 một cách máy móc. ISO 27001 dựa trên rủi ro — chọn control phù hợp và giải trình trong SoA, đừng "tick hết cho chắc".

Quên audit trail. Không log ai truy cập dữ liệu nhạy cảm là điểm trượt kinh điển của cả PCI-DSS lẫn ISO 27001. Mẹo: mỗi truy cập dữ liệu nhạy cảm phải truy vết được tới một danh tính người dùng cụ thể.

Bài tập thực hành

Phân loại dữ liệu. Cho một bảng transactions có các trường: card_number, card_holder_name, cvv, expiry_date, amount, email, transaction_id. Hãy đánh dấu mỗi trường thuộc loại nào (PAN / dữ liệu xác thực nhạy cảm cấm lưu / PII / dữ liệu thường) và ghi rõ yêu cầu xử lý (mã hóa, masking, hay cấm lưu).

Thu hẹp CDE. Mô tả luồng thanh toán hiện tại của một app: app tự nhận số thẻ → lưu vào DB → tự gọi ngân hàng. Hãy đề xuất kiến trúc dùng tokenization để thu hẹp CDE, vẽ sơ đồ luồng dữ liệu trước và sau.

Viết compliance traceability matrix. Chọn 3 requirement của tiêu chuẩn (ví dụ: cấm lưu CVV; masking PAN khi hiển thị; log mọi truy cập dữ liệu thẻ) và viết user story tương ứng kèm tiêu chí verify cho mỗi cái.

Tình huống ISO 27001. Một công ty bị phát hiện cấp quyền truy cập DB production cho toàn bộ dev. Hãy viết 2 user story khắc phục, ánh xạ tới control phù hợp trong Annex A (gợi ý: nhóm kiểm soát truy cập).

Tóm tắt

Compliance là việc chứng minh được hệ thống tuân thủ một bộ quy tắc kiểm toán được, khác với security thuần kỹ thuật. PCI-DSS bắt buộc cho mọi đơn vị chạm vào dữ liệu thẻ, xoay quanh việc thu hẹp CDE và 12 requirement; điểm sống còn là PAN phải mã hóa/masking còn CVV thì tuyệt đối cấm lưu. ISO 27001 rộng hơn, chứng nhận cho hệ thống quản lý an toàn thông tin (ISMS) dựa trên đánh giá rủi ro với 93 control trong Annex A, ngày càng là điều kiện ký hợp đồng B2B.

Vai trò của Technical BA là cầu nối: phân loại dữ liệu, ánh xạ requirement tới control trong một traceability matrix, viết spec logging/audit trail chặt chẽ, và đưa compliance vào backlog ngay từ đầu. Những thất bại đắt giá nhất — lưu CVV, log lộ payload, CDE phình to, quyền truy cập tràn lan — đều bắt nguồn từ việc thiếu tư duy compliance ở giai đoạn requirement. BA chủ động cài các ràng buộc này từ sớm chính là người tạo ra khác biệt thật sự.