# 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ý.