PCI DSS cho Developer: Quy tắc xử lý, truyền tải và lưu trữ dữ liệu thẻ
Hướng dẫn PCI DSS v4.0.1 cho Developer khi xử lý dữ liệu thẻ: phạm vi CDE, PAN, CVV, tokenization, encryption, TLS, access control, logging, payment scripts và kiểm thử.
ShanverseUpdated 11 min read— viewsLoading views
Privacy
Payment Systems
Cryptography
PCI DSS là gì và ai phải tuân thủ?
PCI DSS — Payment Card Industry Data Security Standard là bộ yêu cầu kỹ thuật và vận hành nhằm bảo vệ dữ liệu tài khoản thanh toán. Chuẩn áp dụng cho tổ chức lưu trữ, xử lý hoặc truyền Cardholder Data/Sensitive Authentication Data, và cả hệ thống có thể ảnh hưởng đến an ninh của Cardholder Data Environment — CDE.
PCI DSS v4.0.1 là phiên bản nên dùng làm baseline tại thời điểm viết. Đây là chuẩn ngành được hệ sinh thái thanh toán áp dụng theo hợp đồng và chương trình compliance; không nên mô tả đơn giản là “chứng chỉ do PCI SSC cấp”. Hình thức xác nhận có thể là SAQ, ROC và AOC tùy merchant level, payment brand, acquirer và vai trò service provider.
Developer không tự quyết định scope hay loại SAQ. Hãy làm việc với Security/Compliance, QSA và acquirer.
Phân loại dữ liệu trước khi viết code
Cardholder Data — CHD
CHD xoay quanh Primary Account Number — PAN. Các trường có thể đi kèm gồm:
Comments
Tên chủ thẻ.
Ngày hết hạn.
Service code.
PAN là thành phần xác định dữ liệu có phải CHD hay không. Tên hoặc ngày hết hạn đứng riêng có thể không phải CHD theo định nghĩa PCI DSS, nhưng vẫn có thể là dữ liệu cá nhân và chịu quy định khác.
Sensitive Authentication Data — SAD
SAD gồm:
Full track data từ magnetic stripe hoặc dữ liệu tương đương trên chip.
Card verification code/value như CVV, CVC, CID.
PIN và PIN block.
SAD chỉ được giữ tạm trước authorization khi có business need hợp lệ và được bảo vệ chặt. Sau authorization phải xóa không thể khôi phục.
Data flow và CDE
Trước khi code, vẽ data-flow diagram:
Mermaid
Loading diagram…
Inventory tất cả nơi dữ liệu có thể chạm tới:
Browser/mobile app và payment SDK.
CDN, WAF, reverse proxy, load balancer.
Application server và background worker.
API gateway, message broker và event stream.
Database, cache, search index và data warehouse.
Logs, traces, APM, session replay và error tracking.
CI/CD artifacts, test fixtures, screenshots và support tools.
Backups, replicas, snapshots và disaster-recovery environment.
Một service không trực tiếp lưu PAN vẫn có thể security-impacting nếu deploy code, quản lý secrets, định tuyến traffic hoặc kiểm soát truy cập vào CDE.
Thiết kế tốt nhất: không nhận PAN
Hosted payment page
Redirect khách hàng sang trang thanh toán do PSP quản lý. Merchant nhận payment token và trạng thái giao dịch.
Hosted fields/iframe
Các trường số thẻ được PSP phục vụ trực tiếp. PAN đi từ browser tới PSP, không đi qua backend merchant.
Tokenization
PSP/vault đổi PAN thành token. Database merchant lưu token, brand, expiry cần thiết và last four để hiển thị.
Token chỉ giảm scope khi không thể đảo ngược ngoài tokenization system và các hệ thống còn lại được segment đúng. Một token có thể dùng để charge vẫn là dữ liệu nhạy cảm về nghiệp vụ; cần access control, monitoring và chống lạm dụng.
Khi bắt buộc phải lưu PAN
Minimize dữ liệu và retention. Chỉ lưu khi có business/legal need được phê duyệt.
PAN phải được render unreadable bằng phương pháp được chấp nhận, chẳng hạn:
Strong cryptography với key management đúng chuẩn.
Tokenization.
Truncation phù hợp.
One-way hash có khóa khi đáp ứng điều kiện áp dụng.
Không tự tạo thuật toán mã hóa. Không hard-code key trong source, .env commit vào Git, Docker image hoặc CI logs.
Mô hình envelope encryption:
Mermaid
Loading diagram…
Key management phải bao phủ:
Generate bằng CSPRNG.
Lưu trong KMS/HSM hoặc vault phù hợp.
Separation of duties và least privilege.
Rotation/cryptoperiod.
Revocation, retirement và destruction.
Backup/recovery an toàn.
Audit mọi decrypt operation.
Không lưu key cùng ciphertext theo cách triệt tiêu bảo vệ.
Mã hóa không cho phép lưu CVV sau authorization.
Masking, truncation và logging
Khi hiển thị PAN, mặc định chỉ hiện phần tối thiểu, thường là last four. Việc hiển thị nhiều hơn phải có business need được tài liệu hóa và quyền riêng.
Không truyền PAN nguyên vẹn cho generic logger:
Redaction cần đặt ở nhiều lớp:
HTTP request/response logging.
Reverse proxy và API gateway.
OpenTelemetry spans và baggage.
APM/session replay.
Exception serializer.
Queue DLQ và retry payload.
Audit/support export.
Dùng allowlist field thay vì blacklist regex. Regex không bắt được dữ liệu được format lạ, encoded hoặc nested.
Truyền dữ liệu thẻ an toàn
Requirement 4 yêu cầu strong cryptography khi truyền account data qua mạng mở/công cộng.
HTTPS/TLS cho browser, API, webhook và service communication theo scope.
Chứng thư hợp lệ, hostname verification và chain validation.
Không downgrade protocol/cipher yếu.
Không gửi PAN/CVV qua email, chat, URL, query string hoặc redirect parameter.
Không đặt PAN trong JWT hoặc client-readable session cookie.
Không cache payment response chứa CHD ở CDN/browser/proxy.
Certificate lifecycle và expiry monitoring.
mTLS có thể tăng service authentication nhưng không thay thế authorization, segmentation hoặc application-layer controls.
Webhook và API payment
Webhook phải được xác thực bằng signature theo tài liệu provider:
Verify signature trên raw body.
Chống replay bằng timestamp/tolerance nếu protocol hỗ trợ.
Deduplicate theo provider event ID.
Lưu event và business update atomic khi có thể.
Acknowledge sau durable storage.
Không tin return URL hoặc browser callback là xác nhận thanh toán.
Không log raw webhook nếu payload có dữ liệu tài khoản.
API nội bộ cần schema validation, authentication, authorization theo resource, rate limits và idempotency key.
Secure SDLC theo Requirement 6
Developer workflow cần:
Security requirements và threat model từ design.
Coding standard chống injection, XSS, CSRF, SSRF, auth flaws và insecure deserialization.
Peer review bởi người khác tác giả; review tập trung security.
SAST, SCA/dependency scanning và secret scanning trong CI.
DAST/API testing ở môi trường phù hợp.
Inventory custom software và third-party components.
Risk-rank vulnerabilities, patch critical vulnerabilities theo thời hạn áp dụng.
Tách development/test khỏi production.
Không dùng production CHD trong test; dùng synthetic data/token test.
Change control, approval, rollback và audit trail.
Không chạy npm audit fix --force mù quáng. Cần đánh giá exploitability, breaking changes, compensating control và xác nhận bằng test.
Duy trì inventory và justification cho từng script.
Bảo đảm integrity của script.
Phát hiện thay đổi trái phép ở payment page và security-impacting HTTP headers.
Thực hành kỹ thuật:
Giảm third-party JavaScript trên checkout.
Self-host khi hợp lý và pin version.
Dùng Content Security Policy nghiêm ngặt.
Subresource Integrity cho static third-party scripts phù hợp.
Không cho tag manager tự do inject script vào payment page.
Monitor DOM/script/header tampering.
Review CDN, analytics, chat widget và A/B testing như supply-chain dependency.
CSP và SRI hỗ trợ nhưng không tự động chứng minh compliance với toàn bộ Requirement 6.4.3/11.6.1.
Identity, access và secrets
Unique account cho mỗi người; không dùng shared admin.
Least privilege, deny by default và review access định kỳ.
MFA theo phạm vi PCI DSS, đặc biệt truy cập CDE và remote access.
Short-lived credentials cho workload khi có thể.
Secrets trong secrets manager; rotation và audit.
Break-glass account có alert và post-use review.
Tách quyền deploy, quản lý key và truy vấn dữ liệu.
Service account không được interactive login.
Đừng để Developer có production database access chỉ vì “cần debug”. Xây safe diagnostic tooling với masked fields và audited access.
Database và storage checklist
Ưu tiên provider token thay vì PAN.
Không có cột cvv, cvc, track_data hoặc pin.
Retention job và verified deletion cho dữ liệu không còn cần.
Backup/replica/export có protection tương đương production.
Row/database encryption không thay thế access control.
Query auditing cho truy cập CHD.
Segmentation được kiểm thử, không chỉ vẽ trên diagram.
Monitoring và audit logs
Audit log cần ghi:
Login, MFA và privileged access.
Read/decrypt/export CHD.
Key lifecycle operations.
Access-control, firewall và configuration changes.
Deployments và payment-page script changes.
Security alert, scan và incident action.
Log cần time synchronization, tamper resistance, retention theo yêu cầu, review và alert. Log “có tồn tại” nhưng không được xem hoặc không cảnh báo thì không đủ.
Bản thân audit log không được chứa PAN/CVV/full request body.
Kiểm thử bắt buộc và liên tục
Tùy scope và phương thức validation, chương trình gồm:
Vulnerability scans nội bộ và bên ngoài.
ASV scan khi áp dụng.
Penetration testing định kỳ và sau significant change.
Segmentation testing.
Wireless scanning/detection khi áp dụng.
File/payment-page change detection.
Incident-response exercise.
Access review và annual scope confirmation.
Một scan pass không có nghĩa ứng dụng an toàn. Evidence phải thể hiện control vận hành xuyên suốt, không phải cấu hình một lần trước audit.
Incident response: khi dữ liệu thẻ có thể bị lộ
Kích hoạt incident-response plan, không tự ý xóa evidence.
Cô lập hệ thống bị ảnh hưởng nhưng giữ forensic integrity.
Rotate/revoke credentials và key theo kế hoạch điều phối.
Xác định data types, thời gian, hệ thống và account liên quan.
Liên hệ Security/Legal/Compliance, acquirer và payment partners theo nghĩa vụ.
Bảo toàn logs, timeline và chain of custody.
Remediate, validate containment và theo dõi tái xâm nhập.
Developer không tự thông báo công khai hoặc liên hệ cardholder ngoài communication plan.
Những anti-pattern nguy hiểm
Lưu CVV “đã mã hóa để recurring payment”.
Log toàn bộ request khi gateway báo lỗi.
Dùng production PAN trong fixture hoặc screenshot.
Đưa PAN vào URL/query string.
Lưu encryption key trong cùng database.
Tự xây card vault khi PSP tokenization đáp ứng được.
Cho analytics/chat widget chạy tùy ý trên checkout.
Tin rằng WAF thay thế secure coding.
Tin rằng cloud provider “PCI compliant” làm ứng dụng tự compliant.
Tin rằng tokenization loại bỏ toàn bộ scope.
Chỉ chuẩn bị evidence vài ngày trước assessment.
Mapping nhanh 12 nhóm yêu cầu
Pull Request checklist cho Developer
Thay PAN bằng PSP-hosted fields/token nếu có thể.
Không lưu hoặc log CVV, track data, PIN/PIN block.
Không đưa CHD vào URL, metric, trace, queue, DLQ hoặc analytics.
PAN được mask khi hiển thị và unreadable khi lưu.
Key nằm trong KMS/HSM, không nằm trong code/config repository.
TLS verification không bị tắt.
Webhook signature và replay được kiểm tra.
Endpoint có authn, authz, validation, rate limit và idempotency.
Unit/integration tests dùng synthetic data.
Dependency và secret scans đã chạy.
Script mới trên payment page có authorization, integrity và justification.
Logs dùng allowlist và đã có test chống rò rỉ PAN/CVV.
Data-flow diagram, inventory, threat model và runbook được cập nhật.
Security reviewer phê duyệt thay đổi ảnh hưởng CDE.
Kết luận
PCI DSS không chỉ là “bật HTTPS và mã hóa database”. Với Developer, nguyên tắc cốt lõi là giảm scope, không lưu SAD, biến PAN thành token, bảo vệ key, chặn rò rỉ qua telemetry, xây secure SDLC và coi payment page như supply-chain boundary.
Thiết kế an toàn nhất là thiết kế khiến hệ thống của bạn không bao giờ nhận dữ liệu thẻ nguyên bản.
1functionverifyWebhook(rawBody:Buffer, signature:string):Event {2// Verify with the provider's official SDK or documented algorithm.3// Verify against the raw request bytes before parsing JSON.4return provider.webhooks.constructEvent(rawBody, signature, webhookSecret);5}
Codesql
1CREATETABLEpayment_methods (2 id UUID PRIMARY KEY,3 customer_id UUID NOT NULL,4 provider_token TEXTNOT NULLUNIQUE,5 brand TEXTNOT NULL,6 last4 CHAR(4) NOT NULL,7 expiry_month SMALLINT,8 expiry_year SMALLINT,9 created_at TIMESTAMPTZNOT NULLDEFAULTnow()10);
Related posts
More articles with related topics and technologies.
Hướng dẫn xử lý transaction storm trong flash sale và quyết toán lương với RabbitMQ/Kafka, rate limiting, backpressure, circuit breaker, load shedding, idempotency và capacity planning.
Hướng dẫn kiến trúc 2FA cho Mobile Banking: SMS OTP, TOTP/Smart OTP, FIDO2, WebAuthn, passkeys, sinh trắc học cục bộ, đăng ký thiết bị, step-up và khôi phục tài khoản.
Hướng dẫn tích hợp cổng thanh toán VNPay, ZaloPay, MoMo và Stripe: payment flow, chữ ký webhook/IPN, idempotency, retry, reconciliation, refund và vận hành production.
