Tóm tắt
Giảm phạm vi PCI DSS bằng segmentation, tokenization và trang thanh toán của processor: cái gì thật sự loại hệ thống khỏi phạm vi và cái gì không.
Giảm phạm vi PCI DSS nghĩa là làm cho ít hệ thống hơn lưu, xử lý, truyền hoặc truy cập được dữ liệu thẻ, bằng ba cách chính: segmentation tách CDE khỏi phần còn lại của mạng, tokenization thay PAN bằng token ở các hệ thống không cần PAN, và để processor nhận dữ liệu thẻ qua redirect hoặc iframe. PCI SSC nói rõ không có công nghệ nào loại bỏ được mọi yêu cầu PCI DSS; các cách này chỉ thu nhỏ phần phải đánh giá.
Bài này dành cho CTO và team kỹ thuật của fintech, ví điện tử và thương mại điện tử Việt Nam đã có danh sách hệ thống trong phạm vi và muốn thu nhỏ nó. Cách lập danh sách đó nằm ở hướng dẫn xác định phạm vi PCI DSS; định nghĩa dữ liệu thẻ nằm ở cardholder data trong PCI DSS. Bài này đi tiếp một bước: thay đổi kiến trúc để danh sách ngắn lại.
Vì sao phạm vi PCI DSS thường lớn hơn bạn nghĩ?
Theo hướng dẫn scoping và segmentation của PCI SSC, hệ thống được chia thành ba nhóm theo thứ bậc: CDE systems, connected-to và security-impacting systems, và out-of-scope systems. Một hệ thống chỉ ngoài phạm vi khi không truy cập được bất kỳ hệ thống nào trong CDE, kể cả gián tiếp qua một hệ thống trong phạm vi. Trong mạng phẳng, nơi máy văn phòng, CI/CD và database thanh toán nói chuyện được với nhau, gần như mọi thứ đều thuộc phạm vi.
Hướng dẫn cũng nhấn mạnh rủi ro khi bỏ sót hệ thống connected-to: nhiều vụ xâm phạm bắt đầu từ chính các hệ thống đó. Vì vậy mục tiêu không phải "khai báo ít hệ thống hơn" mà là thay đổi kiến trúc để ít hệ thống thật sự chạm tới CDE.
Các cách giảm phạm vi PCI DSS so với nhau thế nào?
| Cách làm | Thu nhỏ phạm vi bằng cách nào | Vẫn còn trong phạm vi | Nguồn PCI SSC |
|---|---|---|---|
| Network segmentation | Tách CDE bằng firewall, ACL, phân quyền để hệ thống khác không truy cập được CDE | Chính các control segmentation, hệ thống connected-to và security-impacting | Scoping and Segmentation Guidance (2017) và supplement 2024 |
| Tokenization | Hệ thống chỉ giữ token, không giữ PAN, có thể ra ngoài CDE nếu được tách biệt | Toàn bộ hệ thống tokenization, de-tokenization, data vault và mọi thứ truy cập được nó | Tokenization Guidelines (2011) |
| Trang thanh toán của processor (redirect, iframe) | Website của bạn không tạo trang nhận thẻ, nên thường đủ điều kiện SAQ A | Website và hệ thống quản lý cách chuyển khách sang processor; điều kiện chống tấn công script với iframe | FAQ 1291, FAQ 1588, cập nhật SAQ A 30/1/2025 |
| Giải pháp P2PE được PCI SSC liệt kê | Dữ liệu thẻ tại POS được mã hóa từ thiết bị đến processor | Thiết bị, quy trình quản lý thiết bị theo hướng dẫn của giải pháp | Danh sách giải pháp P2PE trên website PCI SSC |
Network segmentation giảm phạm vi thế nào?
Segmentation không phải là yêu cầu bắt buộc của PCI DSS, nhưng PCI SSC "khuyến nghị mạnh" vì nó có thể giảm phạm vi, chi phí và độ khó của đánh giá. Segmentation phải được tạo bằng các control chuyên dụng, chẳng hạn firewall và ACL, để ngăn một hệ thống bị xâm phạm ngoài phạm vi tiến vào dữ liệu thẻ. Hướng dẫn liệt kê thêm các control giúp chứng minh hệ thống ngoài phạm vi không lợi dụng được hệ thống trong phạm vi: firewall hoặc IDS/IPS trên host, kiểm soát truy cập vật lý và logic, MFA, giới hạn quyền quản trị và giám sát kết nối bất thường.
Khi dùng segmentation để thu hẹp phạm vi, bạn phải chứng minh nó hiệu quả bằng pentest. Hướng dẫn năm 2017 viết theo PCI DSS v3.2 (yêu cầu 11.3.4): pentest segmentation ít nhất mỗi năm, và service provider mỗi sáu tháng. Trong PCI DSS v4.0.1, các yêu cầu tương ứng là 11.4.5 cho mọi đơn vị và 11.4.6 cho service provider. Với kiến trúc cloud, micro-segmentation và zero trust, PCI SSC phát hành thêm supplement về scoping và segmentation cho kiến trúc hiện đại ngày 9/9/2024.
Các bước làm segmentation có thể kiểm chứng:
- Vẽ data flow của dữ liệu thẻ và đánh dấu CDE theo 5 bước scoping.
- Đặt CDE vào VPC, subnet hoặc network riêng; chỉ mở đúng các kết nối cần thiết và ghi lý do cho từng rule.
- Tách quản trị: chỉ cho phép quản trị CDE từ jump host hoặc hệ thống trong phạm vi, dùng MFA.
- Đưa các hệ thống còn kết nối vào CDE (log, CI/CD, directory) vào danh sách connected-to và áp control tương ứng.
- Pentest segmentation theo 11.4.5 (và 11.4.6 nếu là service provider), lưu báo cáo làm evidence, và lặp lại sau mỗi thay đổi lớn.
Tokenization giảm phạm vi thế nào?
Theo PCI DSS Tokenization Guidelines, toàn bộ hệ thống tokenization, gồm de-tokenization và nơi lưu PAN (card data vault), là một phần của CDE và luôn trong phạm vi. Mọi hệ thống có thể đổi PAN lấy token, đổi token lấy PAN, hoặc truy cập được hệ thống tokenization cũng trong phạm vi. Những hệ thống được tách biệt khỏi hệ thống tokenization và CDE, chỉ lưu hoặc xử lý token, và không lưu, xử lý, truyền dữ liệu thẻ hay dữ liệu xác thực nhạy cảm, có thể được xem là ngoài CDE và có thể ngoài phạm vi.
Điều kiện quan trọng nhất: nếu merchant vẫn lấy lại được PAN từ token, môi trường của merchant vẫn trong phạm vi. Vì vậy tokenization giảm phạm vi nhiều nhất khi processor hoặc nhà cung cấp tokenization giữ vault và bạn không có khả năng de-tokenize. Khi thuê nhà cung cấp, lấy AOC service provider của họ và ghi rõ trách nhiệm từng bên (yêu cầu 12.8 và 12.9 trong v4.0.1).
Dùng trang thanh toán của processor giảm phạm vi đến đâu?
PCI SSC giải thích trong FAQ 1291 rằng với redirect hoặc iframe, processor tạo trang nhận dữ liệu thẻ nên merchant dùng SAQ A; với direct post, website của merchant tạo một phần hoặc toàn bộ trang thanh toán nên dùng SAQ A-EP. Ngày 30/1/2025, PCI SSC bỏ 6.4.3, 11.6.1 và 12.3.1 khỏi SAQ A và thay bằng điều kiện merchant phải xác nhận website không dễ bị tấn công bằng script có thể ảnh hưởng hệ thống thương mại điện tử, có hiệu lực từ 31/3/2025 (PCI SSC). Theo FAQ 1588, điều kiện này áp dụng cho trang nhúng form của processor (iframe), không áp dụng cho redirect hoặc khi bạn gửi link thanh toán.
Website của bạn vẫn quan trọng: nếu kẻ tấn công sửa trang để chuyển khách sang trang giả, dữ liệu thẻ vẫn bị đánh cắp. Đó là lý do SAQ A vẫn có yêu cầu bảo vệ website và hệ thống chuyển khách đi.
Điều gì không loại hệ thống khỏi phạm vi PCI DSS?
- Chỉ mã hóa dữ liệu thẻ. Mã hóa giảm rủi ro, nhưng hệ thống giữ khóa hoặc giải mã được vẫn trong phạm vi.
- Đặt hệ thống cùng subnet với CDE và "hứa" không truy cập. Thiếu control kỹ thuật có kiểm chứng thì đó không phải segmentation.
- Token có thể đổi ngược thành PAN trong môi trường của bạn. Khả năng de-tokenize kéo môi trường trở lại phạm vi.
- Thuê processor nhưng vẫn ghi PAN vào log, ticket hay file export. Bất kỳ nơi nào PAN xuất hiện đều là CDE.
- Chuyển lên cloud. Nhà cung cấp cloud chịu một phần trách nhiệm theo AOC và ma trận trách nhiệm của họ; cấu hình bạn tự làm vẫn thuộc phạm vi của bạn.
pTrackly giúp gì khi bạn giảm phạm vi?
pTrackly có sẵn framework PCI DSS 4.0.1 với requirement, control và evidence task có ngày review định kỳ, nên sơ đồ data flow, tài liệu phạm vi, báo cáo pentest segmentation và AOC của processor hay nhà cung cấp tokenization được gắn vào đúng yêu cầu. Inventory người, thiết bị và tài sản giúp đối chiếu danh sách system component; module Vendors theo dõi tài liệu của nhà cung cấp, và module Pentest theo dõi lỗ hổng đến khi khắc phục. pTrackly không thiết kế segmentation, không quyết định hệ thống nào ngoài phạm vi và không phải QSA hay ASV; kết luận về phạm vi thuộc về bạn và assessor.
Câu hỏi thường gặp
Segmentation có bắt buộc trong PCI DSS không?
Không bắt buộc, nhưng PCI SSC khuyến nghị mạnh. Không có segmentation thì mọi hệ thống trong mạng phẳng có thể truy cập CDE đều thuộc phạm vi.
Dùng tokenization của processor thì hệ thống của tôi có ra ngoài phạm vi không?
Có thể, nếu hệ thống chỉ giữ token, được tách biệt khỏi CDE và bạn không lấy lại được PAN. Website hoặc ứng dụng vẫn chuyển dữ liệu thẻ sang processor thì phần đó vẫn cần được đánh giá.
Pentest segmentation bao lâu một lần?
Theo PCI DSS v4.0.1, ít nhất mỗi 12 tháng và sau thay đổi lớn với segmentation (11.4.5); service provider phải làm mỗi sáu tháng (11.4.6).
Iframe của processor có còn đủ điều kiện SAQ A sau năm 2025 không?
Có, nhưng từ 31/3/2025 merchant phải xác nhận website không dễ bị tấn công bằng script có thể ảnh hưởng hệ thống thương mại điện tử. Điều kiện này không áp dụng cho redirect.
Muốn biết hình thức xác nhận mình phải làm, đọc cấp độ PCI DSS và SAQ PCI DSS là gì. Danh sách việc cần làm sau khi chốt phạm vi có trong PCI DSS compliance checklist, và PCI DSS trên pTrackly cho thấy cách quản lý evidence.
