Cardholder Data là gì
Cardholder data (CHD) là thông tin trực tiếp gắn với thẻ thanh toán: PAN (Primary Account Number) tức dãy số thẻ, tên chủ thẻ, ngày hết hạn, và service code. Đây là nhóm dữ liệu mà PCI DSS cho phép lưu trữ với điều kiện bảo vệ đúng cách.
Nhóm thứ hai là Sensitive Authentication Data (SAD): CVV/CVC, PIN, và dữ liệu đọc từ magnetic stripe hoặc chip. Điểm khác biệt quan trọng: SAD không được lưu sau khi giao dịch hoàn tất, kể cả khi đã mã hóa. Không có ngoại lệ.
Nguồn: PCI DSS v4.0.1, Requirement 3. pcisecuritystandards.org
CDE là gì
CDE (Cardholder Data Environment) là toàn bộ người, quy trình, và công nghệ liên quan đến việc lưu trữ, xử lý, hoặc truyền tải CHD hoặc SAD.
Định nghĩa này rộng hơn nhiều người nghĩ. CDE không chỉ là cái database chứa số thẻ. Nó bao gồm:
- Application server giao tiếp với database đó
- Network mà traffic thẻ đi qua
- Logging system ghi lại transaction
- Backup storage chứa dữ liệu lịch sử
- Mọi hệ thống có kết nối trực tiếp hoặc gián tiếp đến các thành phần trên
Nếu một hệ thống có thể nhìn thấy CHD, gửi traffic đến nơi CHD tồn tại, hoặc quản lý quyền truy cập vào CDE, nó thuộc phạm vi PCI DSS.
Phạm vi PCI DSS không chỉ là CDE
PCI DSS áp dụng cho ba nhóm hệ thống:
- Hệ thống trong CDE, tức nơi CHD hoặc SAD thực sự tồn tại.
- Hệ thống kết nối trực tiếp với CDE.
- Hệ thống có thể ảnh hưởng đến bảo mật của CDE dù không chứa CHD, ví dụ monitoring system theo dõi server trong CDE, hoặc Active Directory server cấp quyền cho user vào CDE.
Phạm vi mở rộng theo đúng pattern này. Một jump server dùng để SSH vào production database nằm trong phạm vi. Một log aggregation tool nhận log từ application server xử lý thẻ nằm trong phạm vi. Shared authentication system mà cả CDE lẫn hệ thống khác cùng dùng có thể kéo toàn bộ vùng đó vào phạm vi.
Đây là nguồn gốc của scope creep: shared network, shared credentials, shared tooling. Kết nối kỹ thuật giữa hai hệ thống thường xác định phạm vi rõ hơn bất kỳ tài liệu nào.
Tại sao giảm phạm vi CDE lại quan trọng
Mỗi hệ thống nằm trong phạm vi PCI DSS kéo theo thêm yêu cầu: cấu hình cụ thể, log cần lưu, patch cần áp dụng trong khung thời gian quy định, bằng chứng cần thu thập trước mỗi kỳ assessment.
Phạm vi lớn không chỉ tốn công hơn khi chuẩn bị audit mà còn tốn công hơn mỗi ngày để duy trì. Một đội nhỏ với 30 hệ thống trong phạm vi phải làm việc nhiều hơn đáng kể so với đội có 8 hệ thống trong phạm vi, dù cả hai cùng xử lý lượng giao dịch như nhau.
Hai cách giảm phạm vi CDE hiệu quả nhất
Tokenization
Tokenization thay thế PAN thật bằng một chuỗi token không có giá trị bên ngoài hệ thống của payment processor. Server của bạn nhận token, lưu token, truy vấn token. PAN thật không bao giờ rời khỏi môi trường của processor.
Với Stripe, ứng dụng của bạn nhận payment_method ID hoặc PaymentIntent ID. Database lưu những chuỗi đó. Chuỗi đó bị lộ cũng không cho ai biết số thẻ, không thể dùng để tạo giao dịch giả ở nơi khác. Database lưu token không còn thuộc CDE, và theo đó không thuộc phạm vi PCI DSS.
Redirect và Hosted Payment Page
Khi checkout hoàn toàn chuyển sang trang của payment processor, trình duyệt người dùng submit số thẻ thẳng đến processor, không qua server của bạn. Stripe Checkout, PayPal, VNPay đều có phương án này.
Nếu không có JavaScript nào từ domain của bạn chạy trên trang checkout đó, bạn đủ điều kiện SAQ A, hình thức self-assessment đơn giản nhất trong PCI DSS, với phạm vi kiểm tra thu hẹp đáng kể.
Nếu có JavaScript của bạn chạy trên trang checkout, bạn thuộc SAQ A-EP. Phạm vi rộng hơn vì JavaScript từ domain của bạn có thể, về lý thuyết, đọc dữ liệu nhập vào form thẻ.
Network segmentation
Tách vùng mạng chứa CDE ra khỏi phần còn lại bằng firewall, VLAN, hoặc micro-segmentation. Hệ thống trong vùng mạng riêng biệt, không có đường kết nối đến CDE, không bị tính vào phạm vi PCI DSS.
Điều này không làm giảm yêu cầu bảo mật bên trong CDE. Nhưng các hệ thống hoàn toàn tách biệt về mặt mạng không phải gánh thêm yêu cầu PCI DSS.
Một ví dụ thực tế: marketing platform, internal wiki, và staging environment của team product không cần thiết phải nằm cùng vùng mạng với payment processing service. Khi chúng được tách biệt với firewall rules rõ ràng và không có path kết nối đến CDE, chúng ra khỏi phạm vi.
Sai lầm phổ biến khi định nghĩa phạm vi
Tính chỉ database lưu thẻ. Phần lớn team khi lần đầu xác định phạm vi chỉ nghĩ đến database. Họ quên tính application server query database đó, logging tool ghi lại SQL query, backup storage sao lưu database định kỳ, monitoring system kiểm tra health của database.
Quên tính con người và quy trình. Developer có quyền SSH vào production server chứa CHD thuộc phạm vi PCI DSS. Theo nghĩa rộng hơn trong một số assessment, máy tính cá nhân của họ cũng có thể bị xem xét. Quy trình nào cho phép họ làm điều đó, cách access được approve và revoke, đều là bằng chứng assessor sẽ hỏi.
Dùng tokenization nhưng vẫn log PAN. Đây là lỗi kỹ thuật phổ biến hơn tưởng. Team tích hợp tokenization đúng cách ở tầng thanh toán, nhưng ở tầng application, khi giao dịch thất bại, code log toàn bộ request payload để debug. Nếu payload đó chứa PAN, log file đó là CHD. Log file đó nằm trong phạm vi. Nếu log aggregation tool thu thập file đó, tool đó cũng nằm trong phạm vi.
Nguồn: PCI DSS v4.0.1 scoping guidance. pcisecuritystandards.org
Xác định phạm vi trước, sau đó mới kiểm soát
Phạm vi PCI DSS không phải là con số cố định từ khi ra mắt sản phẩm. Mỗi lần thêm một integration mới, thay đổi kiến trúc mạng, hoặc cấp quyền cho team mới vào production, phạm vi có thể thay đổi.
Thực tế của nhiều team là phạm vi được xác định một lần khi chuẩn bị assessment đầu tiên, rồi không được review lại cho đến kỳ sau. Trong khoảng thời gian đó, hệ thống thay đổi nhưng phạm vi trên giấy không theo kịp.
Cách tiếp cận thực tế hơn là document phạm vi cùng với diagram kiến trúc và giữ cả hai cập nhật khi có thay đổi hạ tầng. Khi assessor hỏi, bạn mô tả hệ thống thực tế, không phải hệ thống từ một năm trước.