sys-analysis-design/sa-output/e-commerce/02-architecture/adr/ADR-002_payment-service-bien-co-lap-pci-dss.md

ADR-002 — Payment Service là biên cô lập mạng/IAM/dữ liệu riêng cho PCI-DSS SAQ A

Tên file: adr/ADR-002_payment-service-bien-co-lap-pci-dss.md

Status	Proposed
Date	2026-09-15
Người quyết	Security (theo decision-radar.md §5 — "Bảo mật, quyền riêng tư": đề xuất SA, chốt Security, phủ quyết Security). Chưa có Security thật ký — chỉ Điều phối dự án ký thay theo DEC-01/DEC-17
Người đề xuất	SA (qua skill sa-2-architecture, hoạt động adr)
Điểm radar	~7/10
Supersedes	—
Superseded by	—
Liên quan	ASR-002 · CON-06 · BR-CART-05 (BA) · ADR-001 (độc lập với kiểu kiến trúc tổng thể)

⚠️ ADR bất biến sau khi Accepted. Muốn đổi quyết định thì viết ADR mới có Supersedes: ADR-002 và đổi trạng thái bản cũ thành Superseded by.

---

1. Bối cảnh

Sàn phải chấp nhận thanh toán VNPay/Momo/COD không lưu thông tin thẻ để giảm phạm vi tuân thủ PCI-DSS xuống mức SAQ A (CON-06, DRV-03) — đây là ràng buộc pháp lý/hợp đồng, không thương lượng được, và độc lập với việc chọn P1 hay P2 ở ADR-001: dù kiểu kiến trúc tổng thể là gì, Payment vẫn phải là một biên cô lập. BR-CART-05 (BA) đã ghi phát biểu nghiệp vụ: hệ thống sàn không được lưu số thẻ/CVV; mọi xử lý thẻ do VNPay/Momo thực hiện, sàn chỉ lưu gateway_transaction_ref + kết quả.

Ràng buộc đang chi phối:

Nguồn	Nội dung
CON-06	PCI-DSS SAQ A (không lưu thẻ) + NĐ13/2023 — cứng, không thương lượng
ASR-002	Payment phải là ranh giới mạng + IAM + dữ liệu (RDS riêng) hoàn toàn tách biệt
BR-CART-05 (BA)	Không lưu số thẻ/CVV; chỉ lưu gateway_transaction_ref + kết quả
QAS-011	100% trường PII rà soát trước khi chia sẻ — liên quan gián tiếp (Payment không giữ PII giao hàng)

Cái đã biết chắc / cái còn là giả định:

Điều	🟢 Đã kiểm chứng / 🔴 Giả định	Bằng chứng
PCI-DSS SAQ A + không lưu thẻ là ràng buộc cứng	🟢 Đã kiểm chứng	CON-06, pháp luật + hợp đồng đối tác
Payment cô lập network/IAM/DB là cách duy nhất khả thi để giữ SAQ A trong một kiến trúc chung (monolith/microservices)	🟡 Ước lượng có cơ sở	Thực hành PCI-DSS phổ biến (segmentation) — chưa có audit chính thức từ QSA/ASV
VNPay/Momo có sandbox thật để kiểm chứng luồng redirect+IPN không lưu thẻ	🔴 Giả định	CON-04, chưa có sandbox (CTX §4.2)

2. Phương án đã cân nhắc

PA-1 — Payment là module trong monolith, không tách mạng/IAM riêng

Mô tả	Payment logic nằm chung namespace/package với Cart & Order trong cùng monolith, chỉ tách bằng ranh giới code (package riêng), dùng chung RDS/network/IAM
Ưu	Đơn giản triển khai hơn — không cần network segmentation riêng, ít thành phần hạ tầng hơn
Nhược	Không kiểm chứng được phạm vi PCI-DSS thu hẹp — một lỗ hổng ở bất kỳ module nào trong cùng network/IAM có thể mở rộng phạm vi audit PCI-DSS ra toàn bộ hệ thống (vi phạm mục tiêu giảm phạm vi của DRV-03)
Chi phí đảo ngược	Tách ra sau khi đã gộp nhầm cần audit lại toàn bộ luồng thẻ + di chuyển dữ liệu/network — ước > 4 tuần, có rủi ro downtime

PA-2 — Payment Service là container riêng, network + IAM + RDS riêng hoàn toàn (chọn)

Mô tả	Payment chạy trên ECS Fargate riêng, subnet/security group riêng, IAM role riêng, RDS riêng nhỏ — không service nào khác trong hệ thống truy cập trực tiếp RDS Payment; mọi module khác chỉ nhận gateway_transaction_ref/status qua API/event
Ưu	Phạm vi audit PCI-DSS SAQ A thu hẹp rõ ràng, kiểm chứng được bằng network diagram + IAM policy review; độc lập với ADR-001 (áp dụng dù chọn P1 hay P2)
Nhược	Thêm một đơn vị triển khai riêng phải vận hành (đã tính vào ADR-001/TCO); mọi thay đổi cần gọi API/event thay vì truy cập DB trực tiếp — thêm độ trễ mạng cho luồng khởi tạo thanh toán
Chi phí đảo ngược	Thấp — đây là hướng thắt chặt hơn, gộp lại (nếu muốn) tốn ít hơn tách ra

PA-3 — Uỷ thác hoàn toàn cho VNPay/Momo (tokenization phía đối tác, sàn không giữ Payment Service riêng)

Mô tả	Không xây Payment Service nội bộ — mọi trạng thái giao dịch tra cứu trực tiếp qua API đối tác mỗi khi cần, không lưu bản sao nào phía sàn
Ưu	Phạm vi PCI-DSS nhỏ nhất về lý thuyết
Nhược	Không đáp ứng ASR-004 (đối soát bù cần log/trạng thái nội bộ để so khớp); phụ thuộc hoàn toàn uptime của đối tác cho mọi truy vấn trạng thái đơn hàng — vi phạm QAS-002/QAS-014
Chi phí đảo ngược	Cao — thiết kế lại toàn bộ luồng đối soát và trạng thái Order/OrderSeller nếu sau này cần Payment Service nội bộ

Bảng so sánh

Tiêu chí	PA-1	PA-2	PA-3
Thu hẹp phạm vi PCI-DSS (CON-06)	❌ Không kiểm chứng được	✅ Rõ ràng	✅ Nhỏ nhất về lý thuyết
Đáp ứng ASR-004 (đối soát bù)	✅	✅	❌ Không có log nội bộ
Chi phí vận hành thêm	Thấp	Trung bình	Thấp
Độ trễ khởi tạo thanh toán	Thấp nhất	Trung bình (gọi mạng)	Cao (phụ thuộc đối tác mỗi lần)

3. Quyết định

Chọn PA-2 — Payment Service là container riêng, cô lập hoàn toàn network + IAM + dữ liệu.

Vì sao: Đây là cách duy nhất trong 3 phương án vừa thu hẹp được phạm vi PCI-DSS SAQ A (CON-06) vừa đáp ứng được yêu cầu đối soát bù (ASR-004). Độc lập với ADR-001 — áp dụng bất kể kết luận cuối cùng về kiểu kiến trúc tổng thể là gì.

Phạm vi áp dụng: Toàn bộ luồng xử lý thanh toán VNPay/Momo/COD, không có ngoại lệ.

Điều kiện chuyển Proposed → Accepted

Điều kiện	Ai xác nhận	Trạng thái hiện tại
Security xác nhận thiết kế cô lập (network diagram + IAM policy) đạt yêu cầu SAQ A	Security	Chưa có người Security thật (OQ-004)
Không bắt buộc POC (đây là ràng buộc pháp lý đã có sẵn, không phải con số hiệu năng chưa đo)	—	N/A

4. Phương án bị loại và lý do

Phương án	Loại vì	Gắn với	Điều kiện nào thì xét lại
PA-1 — Payment chung network/IAM với monolith	Không kiểm chứng được thu hẹp phạm vi PCI-DSS	CON-06	Không xét lại — vi phạm ràng buộc pháp lý cứng
PA-3 — Uỷ thác hoàn toàn cho đối tác, không Payment Service nội bộ	Không đáp ứng ASR-004 (đối soát bù); phụ thuộc uptime đối tác cho mọi truy vấn	ASR-004, QAS-002, QAS-014	Chỉ xét lại nếu đối tác cung cấp webhook/API đối soát đủ tin cậy để không cần log nội bộ — chưa có bằng chứng

5. Hệ quả

Hệ quả tích cực

• Phạm vi audit PCI-DSS SAQ A thu hẹp rõ ràng, kiểm chứng được bằng network diagram
• Payment Service có thể thay đổi độc lập (thêm kênh thanh toán mới) mà không chạm Nhóm Giao dịch/Nhóm Hỗ trợ (SAD §4.2 "Ranh giới thay đổi")

Hệ quả tiêu cực phải sống chung

• Mọi lời gọi từ Cart & Order tới Payment Service phải qua mạng (không còn truy vấn DB trực tiếp) — thêm độ trễ và cần thiết kế đường lỗi riêng (xem FAIL, hoạt động 8)
• Thêm một RDS instance riêng cần patch/backup/monitor độc lập

Cái quyết định này khoá lại

Muốn đổi về sau thì	Tốn
Gộp Payment vào chung network/IAM với phần còn lại	Phải làm lại toàn bộ audit PCI-DSS, rủi ro pháp lý cao

Việc phát sinh

Việc	Chủ	Hạn	Ghi ở đâu
Thiết kế network diagram + IAM policy chi tiết cho Security review	SA + Security	Hoạt động sec (GĐ2)	SEC_e-commerce §1
Đào tạo team về ranh giới không được vi phạm (không copy code truy cập DB Payment)	Tech Lead	GĐ3 (AGD)	TCO §5

6. Cách kiểm chứng quyết định này được tuân thủ

Cách kiểm	Công cụ	Chạy ở đâu	FIT
Không có security group nào cho phép truy cập trực tiếp từ container khác vào RDS Payment	Kiểm tra hạ tầng (Terraform plan/AWS Config rule)	CI/CD + định kỳ	FIT-03 (ứng viên GĐ3)
Không có trường số thẻ/CVV trong bất kỳ schema nào ngoài Payment	Kiểm tra schema/migration review	CI (schema linter)	FIT-04 (ứng viên)
Pentest/ASV scan hàng quý xác nhận phạm vi SAQ A	Nhà cung cấp pentest bên ngoài	Định kỳ hàng quý	— (thủ công, chưa có báo giá — OQ-017)

7. Điều kiện xét lại

Dấu hiệu	Ngưỡng	Ai theo dõi
Đối tác thanh toán mới yêu cầu mô hình tích hợp khác (không redirect/IPN)	Khi có đối tác mới	Tech Lead
Pentest/audit phát hiện lỗ hổng ở ranh giới cô lập	Bất kỳ phát hiện mức Cao	Security

8. Tham chiếu

• POC: Không áp dụng (ràng buộc pháp lý, không phải quyết định hiệu năng)
• Bài đo: Pentest/ASV scan hàng quý (chưa có báo giá, OQ-017)
• Tài liệu ngoài: BR_CartCheckout_v1.0.md (BA) — BR-CART-05 · CTX_e-commerce_v1.0.md §3 CON-06
• Thảo luận: ASR_e-commerce_v1.0.md §B2 ASR-002

9. Review log (không đổi Status)

Ngày	Người review	Vai trò	Quyết định	Lý do chưa chuyển Accepted
2026-09-15	Điều phối dự án (thay mặt Tech Lead, chế độ chạy thử)	Tech Lead (ký thay, ngoại lệ DEC-01)	Reviewed (Proposed giữ nguyên) — nội dung đủ làm cơ sở thiết kế tiếp (icd/dat/sec/inf/fail)	Chưa có người Security để ký (ADL §8 việc #7) — ngoại lệ dự án chạy thử không thay được chữ ký chuyên môn Security

Đây là ghi nhận review nội dung, không phải "sign" theo nghĩa gate: Status giữ nguyên Proposed. Xem 00-index/ADL_e-commerce.md (Change Log — Review 2026-09-15) và ADL §8 "Việc phải làm" cho điều kiện chuyển Accepted. Confidence tổng thể của lượt review: 🔴 — AG2 chưa ký.