sys-analysis-design/sa-output/e-commerce/02-architecture/SEC_e-commerce_v1.0.md

SEC — Security Architecture & Threat Model — e-commerce

Version	1.1
Date	2026-09-15
Author	SA (skill sa-2-architecture, chế độ go, hoạt động sec)
Status	🟡 Draft (duyệt từng phần — xem Approved by; AG2 cần cả ba vai trò Tech Lead/Security/Ops-SRE ký, mới có một chữ ký thay có điều kiện — chưa đủ điều kiện chuyển 🔵 Approved)
Approved by	Tech Lead: Điều phối dự án (uỷ quyền, chế độ chạy thử — ký thay theo ngoại lệ DEC-01, không phải chữ ký Tech Lead thật) — duyệt từng phần bản v1.0 · 2026-09-15: ghi nhận nội dung 31 THR STRIDE (§4), map ROLE-01/02 (§3.1), mô hình authn/authz đề xuất (§2, §3), SAQ A (§8.1), đề xuất rate limit 30/10/10 req/phút (§5.3, ASM-40), quản lý secret/scanning (§6), audit log theo phương án (a) (§7). Chốt TẠM hướng OQ-050: chọn PA-3 (service JWT ngắn hạn ký bởi Identity & Access) cho service-to-service authn (§2.4) — yêu cầu SA viết ADR-015 (Proposed) ở lượt hoạt động adr kế tiếp, cùng lúc với ADR-014 (Outbox) đang nợ; OQ-050 giữ nguyên mở, chờ Security + Ops/SRE thật xác nhận trước khi Accepted. KHÔNG ký thay Security — mọi kết luận PII/residency/retention (§5, §8.2) vẫn là đề xuất chờ Legal/Security, chưa có hiệu lực. Ghi thêm DEC-28. Security: — (chưa có người được chỉ định — OQ-007, mở từ GĐ1. SEC CHƯA CÓ HIỆU LỰC PHỦ QUYỀN AG2 cho tới khi có người này; không ký thay ở lượt này) · Ops/SRE: — (chưa ký). OQ-004 (tính hợp lệ ký thay) vẫn mở. Confidence giữ nguyên 🔴 — duyệt từng phần không phải bằng chứng nguồn mới. Status giữ 🟡 Draft — AG2 chưa đủ ba chữ ký thật/hợp lệ.
Source	02-architecture/SAD_e-commerce_v1.0.md v1.3 §3, §4, §4.1, §7 · 02-architecture/DAT_e-commerce_v1.0.md v1.0 §1, §5, §5.1, §5.2, §6, §9 · 02-architecture/ICD_e-commerce_v1.0.md v1.0 §1, §2, §3.1–§3.7 · 02-architecture/FAIL_e-commerce_v1.0.md v1.1 §1, §5 (FM-06 ownership fail-closed, E-CART-0007) · 02-architecture/QAS_e-commerce_v1.0.md QAS-010/011/012 · 02-architecture/ASR_e-commerce_v1.0.md ASR-002/004/007/008/009 · 02-architecture/adr/ADR-002_*.md, ADR-004_*.md, ADR-007_*.md, ADR-008_*.md, ADR-009_*.md, ADR-011_*.md, ADR-015_*.md · 01-context/CTX_e-commerce_v1.0.md §4.2 (đối tác ngoài) · 01-context/ARISK_e-commerce_v1.0.md §3 (ARISK-03/04/06) · 00-index/OQ_e-commerce.md v1.21 · 00-index/DEC_e-commerce.md v1.24 · ba-output/e-commerce/02-analysis/RBAC_CartCheckout_v1.0.md §1, §2, §4, §5, §6, §8 · ba-output/e-commerce/03-specification/NFR_US002-003_v1.0.md §3 · e-commerce/docs/sections/08-bao-mat.md (P1, chỉ tham khảo — xem cảnh báo §0.2, KHÔNG kế thừa kiến trúc ~10 microservices/Kafka của tài liệu đó)
Scope	Toàn sàn e-commerce theo P2 (SAD v1.3, 15 CMP). Chi tiết nhất: Cart & Order (CMP-04), Payment (CMP-11/CMP-14), Identity & Access (CMP-02), và luồng chia sẻ PII cho seller khi tách đơn (ADR-008, DAT §5). Các CMP còn lại (Seller Mgmt, Commission, Promotion, Review, Notification, Shipping) ở mức ranh giới tin cậy + authz tổng quát, không đào sâu threat model riêng — đây là hoạt động 6/9 (sec) của sa-2-architecture.
Confidence	🔴 Giả định chưa xác minh — theo yêu cầu điều phối, tiếp nối Confidence 🔴 của SAD/ICD/DAT/FAIL/ASR/QAS. AG1 chưa ký thật; AG2 chưa tới hạn; ADR-002/004/007/008/009/011 đều Proposed (chưa Accepted); ADR-008 (PII) chặn hoàn toàn vì chưa có đại diện Pháp chế/Bảo mật (OQ-007); không đối tác ngoài nào (VNPay/Momo/GHN/GHTK) có sandbox/tài liệu API thật (ARISK-03/04) để xác minh cơ chế chữ ký webhook thật. Mọi ngưỡng rate-limit/circuit/authn trong tài liệu này là đề xuất SA, chưa Security/Tech Lead xác nhận.

Change Log

Version	Date	Người sửa	Thay đổi	ADR/DEC
1.0	2026-09-15	SA (qua skill sa-2-architecture, chế độ go, hoạt động sec)	Bản đầu — hoạt động 6/9 của GĐ2. Threat model STRIDE cho 8 ranh giới tin cậy (client↔ALB/WAF, ALB↔Nhóm Giao dịch, Nhóm Giao dịch↔Nhóm Hỗ trợ cross-network IF-021/022, Cart&Order↔Payment IF-006, Payment↔VNPay/Momo + webhook inbound, Shipping↔GHN/GHTK webhook, app↔RDS/Redis/SQS, Admin console) — 28 THR-01…28, mỗi cái truy về QAS/ASR/ADR nguồn. Mô hình authn cho Guest/Customer/Seller/Admin + đề xuất mới cho service-to-service (Nhóm Giao dịch↔Nhóm Hỗ trợ↔Payment — chưa có cơ chế, radar ước lượng ~6, ADR ứng viên chưa viết). Mô hình authz: map đủ ROLE-01/02 của RBAC_CartCheckout xuống quyền kỹ thuật, fail-closed cho ownership check (E-CART-0007, theo FAIL). Phân loại PII/mã hoá/masking/residency — toàn bộ đánh dấu "đề xuất chờ Legal/Security" (OQ-007). PCI-DSS SAQ A: xác nhận ranh giới ADR-002, đề xuất bắt buộc tích hợp dạng redirect (chưa xác nhận với đối tác thật — OQ-048 mới); webhook: cơ chế chữ ký thật chưa biết (chưa bịa — OQ-049 mới, ARISK-03/04), chống replay theo ADR-004. Đề xuất số cụ thể cho rate limit Guest cart (OQ-023), login brute-force (OQ-052 mới), checkout. Quản lý secret (Secrets Manager, rotation), quét dependency/container (Trivy/Snyk), pentest năm + ASV quý (OQ-017 đã mở ở TCO). Audit log theo phương án (a) đã chốt TẠM ở OQ-047 (mỗi module tự ghi) — chốt trường bắt buộc + retention. Đối chiếu docs/sections/08-bao-mat.md chỉ tham khảo (P1, §0.2). Đề xuất FIT-29…33 cho GĐ3 (authz test tự động, secret scan, service-authn test, webhook signature test, audit completeness test). Thêm OQ-048…053, cập nhật OQ-007/023/024, ASM-39…41. Ghi ngoại lệ tiếp tục gate ở DEC-27 (00-index/DEC_e-commerce.md), tiếp nối DEC-01…26. Không sửa SAD/ICD/DAT/FAIL/ADR đã có. Confidence 🔴 toàn bộ.	DEC-27
1.0	2026-09-15	Điều phối dự án (thay mặt Tech Lead, ngoại lệ DEC-01) — tác vụ sign/approve	Duyệt từng phần: ghi nhận nội dung 31 THR STRIDE (§4), map ROLE-01/02 (§3.1), mô hình authn/authz đề xuất (§2, §3), SAQ A (§8.1), đề xuất rate limit 30/10/10 req/phút (§5.3, ASM-40), quản lý secret/scanning (§6), audit log theo phương án (a) (§7). Chốt TẠM OQ-050: chọn PA-3 (service JWT ngắn hạn) cho service-to-service authn (§2.4) — yêu cầu SA viết ADR-015 (Proposed) ở lượt hoạt động adr kế tiếp cùng ADR-014; OQ-050 giữ nguyên mở, chờ Security + Ops/SRE. KHÔNG ký thay Security — header Approved by → Security giữ —, SEC chưa có hiệu lực phủ quyết AG2 (OQ-007); mọi kết luận PII/residency/retention (§5, §8.2) vẫn là đề xuất chờ Legal/Security, không phải quyết định cuối. Không đổi nội dung chuyên môn nào của tài liệu. Ops/SRE chưa ký; Confidence giữ 🔴; Status giữ 🟡 Draft; AG2 chưa ký. Ghi thêm DEC-28.	DEC-28
1.1	2026-09-15	SA (qua skill sa-2-architecture, chế độ go, hoạt động adr)	Chỉ link ADR, không đổi nội dung. ADR-015 (Service JWT ngắn hạn service-to-service, Proposed) vừa được viết theo hướng PA-3 đã chọn TẠM ở §2.4/OQ-050/DEC-28 — thay các dòng "chưa viết ADR" ở §2.4 và THR-09/THR-13 (§4.3/§4.4) bằng đường dẫn adr/ADR-015_service-jwt-xac-thuc-service-to-service.md. OQ-050 giữ nguyên mở (chặn cứng bởi OQ-007 — Security chưa có người, xem ADR-015 §0/§3). Không sửa nội dung chuyên môn nào khác của SEC. Ghi DEC-31 (tiếp nối DEC-01…30).	ADR-015, DEC-31

Sơ đồ thắng về quan hệ và luồng (ai gọi ai, qua ranh giới nào). Bảng/văn bản thắng về ràng buộc và con số (ngưỡng rate-limit, TTL token, mức che dữ liệu). Mâu thuẫn ngoài hai loại trên là lỗi tài liệu, phải sửa chứ không chọn bên (D12).

---

0. Ghi chú Preflight & phạm vi — bắt buộc đọc trước

0.1 Ngoại lệ gate

AG1 vẫn chưa ký thật; AG2 (gate của chính GĐ2) chưa tới hạn. Theo SKILL.md, hoạt động 1 (QAS) → 2 (ASR) → 3 (SAD) đã hoàn tất và được duyệt từng phần (DEC-12/14/16); hoạt động 4 (ICD), 5 (DAT), 8 (FAIL) đã chạy (DEC-18…25), ADR-001…013 đã viết (tất cả Proposed). Điều kiện đầu vào cho hoạt động 6 (SEC) — SAD, DAT, RBAC của BA — đã đủ. Người dùng (vai điều phối dự án chạy thử) đã được cảnh báo lại và khẳng định muốn tiếp tục.

DEC-27 (SA) — Tiếp tục sa-2-architecture (hoạt động 6 — SEC) cho e-commerce trong khi AG1 chưa ký thật và AG2 chưa tới hạn — tiếp nối DEC-01…26. Quyết định: Dựng threat model STRIDE + mô hình authn/authz + phân loại PII cho toàn sàn P2 dựa trên SAD v1.3/DAT v1.0/ICD v1.0/FAIL v1.1/RBAC_CartCheckout đã có, giữ Confidence 🔴 cho tới khi: (a) AG1/AG2 ký thật, (b) có đại diện Pháp chế/Bảo mật thật (OQ-007) — điều kiện chặn cứng nhất, không có SEC nào có hiệu lực phủ quyết PII/residency nếu thiếu người này, (c) đối tác VNPay/Momo/GHN/GHTK có tài liệu/sandbox thật để xác minh cơ chế chữ ký webhook (ARISK-03/04), (d) Tech Lead xác nhận các đề xuất mới (service-to-service authn, ngưỡng rate-limit, account lockout). Người quyết: Điều phối dự án (đại diện PO, dự án chạy thử). Radar (ước lượng cho việc tiếp tục dưới ngoại lệ): ~4 — chi phí đảo ngược thấp (ghi tài liệu threat model, chưa có dòng code phụ thuộc) · bán kính ảnh hưởng: hoạt động inf kế tiếp và toàn bộ dev dùng SEC làm nguồn sự thật authn/authz/PII, nhưng bản thân việc ghi tài liệu dưới ngoại lệ thì nhỏ · có chạm QAS-010/011/012 Must trực tiếp (đang thiết kế cách đạt chúng) nhưng chưa phải cam kết thi công (chưa FIT nào chạy) · không ràng buộc dài hạn tự thân (văn bản SEC sửa được qua version mới) · không tranh cãi mới, tiếp nối tiền lệ DEC-11…26 → ghi DEC-nn, không cần ADR cho việc chạy dưới ngoại lệ (decision-radar.md §1–§2). Hệ quả nếu không chấp nhận ngoại lệ: hoạt động inf (hoạt động 7) không có mô hình threat/ authn/authz để thiết kế network segmentation và secret management thật — chậm tiến độ chạy thử tương ứng thời gian xử lý các OQ đang mở, đặc biệt OQ-007 (chặn ADR-008 và phần lớn §5).

0.2 Đối chiếu docs/sections/08-bao-mat.md — chỉ tham khảo, không kế thừa

docs/sections/08-bao-mat.md (P1, status: approved, version: 2) là thiết kế bảo mật cho kiến trúc ~10 microservices + Kafka/MSK + database-per-service — kiến trúc đó đã bị loại ở OPT §5 (GĐ1), thay bằng P2 (modular monolith + managed AWS, Payment tách riêng). Tài liệu này chỉ tái dùng: (a) quy ước đặt tên mã lỗi (403 ERR_FORBIDDEN_OWNERSHIP, 423 ERR_ACCOUNT_LOCKED), (b) ý tưởng chính sách khoá tài khoản theo vai trò (§8.1.1a), (c) ý tưởng redact PII trong audit log (§8.2.5a), (d) danh mục OWASP Top 10 rà theo endpoint — không kế thừa cấu trúc scope customer:*/seller:*/admin:* gắn với 10 service riêng, không kế thừa giả định Kafka/MSK ACL (P2 dùng SQS FIFO/EventBridge, đã có ở ADR-005), không kế thừa bảng audit_log tập trung một Service Audit & Compliance (P2 chọn phương án (a) — mỗi module tự ghi, OQ-047). Mọi chỗ tái dùng được đánh dấu rõ "tham khảo P1" trong bảng tương ứng bên dưới.

🔴 Nhắc quan trọng: INF (hoạt động 7) chưa được tạo. Tài liệu này là input trực tiếp cho INF — đặc biệt network segmentation (§1), secret management (§6), và ngưỡng alerting an ninh.

---

1. Ranh giới tin cậy

8 ranh giới theo yêu cầu người duyệt. Mỗi ranh giới phải có kiểm tra đầu vào tại đúng điểm giao.

flowchart LR
    subgraph NET["Internet — không tin cậy"]
        U["Guest/Customer/Seller/Admin"]
        VNP["VNPay"]
        MOMO["Momo"]
        GHN["GHN"]
        GHTK["GHTK"]
    end

    subgraph EDGE["Vùng biên — TB1"]
        WAF["WAF + ALB (CMP-01)"]
    end

    subgraph GD["Nhóm Giao dịch — TB2 (tin cậy vừa)"]
        ID["Identity & Access (CMP-02)"]
        CAT["Catalog & Inventory (CMP-03)"]
        CO["Cart & Order (CMP-04)"]
    end

    subgraph HT["Nhóm Hỗ trợ — tin cậy vừa (khác network TB2)"]
        PROMO["Promotion & Loyalty (CMP-07)"]
        SELLER["Seller Mgmt (CMP-05)"]
        SHIP["Shipping & Fulfillment (CMP-10)"]
    end

    subgraph PAY["Payment Service — TB4 (cô lập PCI, tin cậy cao nhất nội bộ)"]
        PS["Payment (CMP-11)"]
    end

    subgraph DATA["Vùng dữ liệu — TB5"]
        RDS[("RDS chính")]
        RDSPAY[("RDS Payment")]
        REDIS[("Redis")]
        SQS[("SQS/EventBridge")]
    end

    subgraph ADMIN["Admin console — TB6"]
        ADM["Admin Backoffice"]
    end

    U -->|"TB1 · HTTPS, WAF+TLS termination"| WAF
    WAF -->|"TB2 · HTTPS, authn JWT/Guest"| ID
    WAF -->|"TB2"| CAT
    WAF -->|"TB2"| CO
    WAF -->|"TB4 · HTTPS, cô lập mạng"| PS
    ADM -->|"TB6 · HTTPS, MFA + IP allowlist (đề xuất)"| ID
    CO -->|"TB3 · REST cross-network, chưa có service-authn"| PROMO
    CO -->|"TB3 · REST cross-network"| SELLER
    CO -->|"TB4 · REST, chưa có service-authn"| PS
    PS -->|"TB-ext · REST sync + webhook async"| VNP
    PS -->|"TB-ext"| MOMO
    SHIP -->|"TB-ext · REST sync + webhook async"| GHN
    SHIP -->|"TB-ext"| GHTK
    ID -->|"TB5 · TLS, IAM theo schema"| RDS
    CO -->|"TB5"| RDS
    CO -->|"TB5"| REDIS
    CO -->|"TB5 · publish"| SQS
    PS -->|"TB5 · TLS, IAM riêng biệt"| RDSPAY
    SQS -->|"TB5 · consume"| HT

Legend: ▭ vùng tin cậy khác nhau bằng subgraph · mũi tên ghi giao thức + loại kiểm tra tại ranh giới đó · TBn tham chiếu đúng số ranh giới ở bảng dưới.

#	Ranh giới	Từ vùng	Sang vùng	Kiểm tra gì tại đây	CMP chịu trách nhiệm
TB1	Client → ALB/WAF	Internet (không tin cậy)	Biên hệ thống	TLS 1.2+ termination, WAF (OWASP Core Rule Set), rate-limit L7, giới hạn kích thước payload, chặn IP theo reputation (đề xuất)	CMP-01
TB2	ALB → Nhóm Giao dịch	Biên	Nội bộ tin cậy vừa	Authn hợp lệ (JWT Customer / X-Guest-Session-Id Guest) — KHÔNG authz chi tiết theo dữ liệu (đúng SAD §4.1 "cái CMP-01 KHÔNG làm")	CMP-01 → CMP-02/03/04
TB3	Nhóm Giao dịch ↔ Nhóm Hỗ trợ (IF-021/IF-022)	Nội bộ tin cậy vừa	Nội bộ tin cậy vừa (network khác — 2 ECS Fargate service riêng, OQ-026)	🔴 Chưa có cơ chế xác thực service-to-service — hiện chỉ có network reachability (security group nội bộ VPC), chưa xác thực danh tính bên gọi. Xem §2.5, THR-09…12	CMP-04 ↔ CMP-07/CMP-05
TB4	Cart & Order → Payment (IF-006)	Nội bộ tin cậy vừa	Vùng cô lập PCI cao nhất	Tương tự TB3 — chưa có service-authn; đây là ranh giới nhạy cảm nhất vì Payment giữ tiền thật (ASR-002)	CMP-04 → CMP-11
TB5	Payment ↔ VNPay/Momo (init sync + webhook inbound async)	Vùng cô lập PCI	Internet (đối tác bên thứ ba)	Chữ ký/HMAC theo tài liệu đối tác (🔴 chưa có, ARISK-03), chống replay (ADR-004, lệch ≤5 phút), TLS	CMP-11
TB6	Shipping & Fulfillment ↔ GHN/GHTK webhook	Nhóm Hỗ trợ	Internet (đối tác)	Chữ ký/token theo tài liệu đối tác (🔴 chưa có, ARISK-04), không ghi đè trạng thái thụt lùi (FAIL FM-03/04)	CMP-10
TB7	App (mọi CMP) ↔ RDS/Redis/SQS	Nội bộ tin cậy vừa/cao	Vùng dữ liệu	TLS in-transit, IAM/network ACL theo schema-per-module (ADR-006) — không module nào được truy cập schema của module khác, RDS Payment tách hoàn toàn (ADR-002)	mọi CMP ứng dụng → CMP-13/14/15/12
TB8	Admin console → Identity & Access + toàn hệ thống	Internet (giới hạn, đề xuất VPN/IP allowlist)	Nội bộ tin cậy cao	MFA bắt buộc (ASR-009), IP allowlist/VPN (đề xuất — tham khảo P1 §3.3, chưa quyết định hạ tầng cho P2, OQ-050), audit toàn bộ hành động	CMP-02 (phần Admin)

🔴 TB3 và TB4 là phát hiện mới của hoạt động sec — SAD/ICD/FAIL đã ghi nhận đây là cross-network call (OQ-026/028) nhưng chưa từng thiết kế cơ chế xác thực danh tính bên gọi, chỉ có network reachability. Một service nào đó trong cùng VPC (kể cả bị compromise) có thể gọi thẳng IF-006/IF-021/IF-022 nếu không có kiểm soát bổ sung. Xem §2.5 (đề xuất) và THR-09/13.

---

2. Xác thực (Authentication)

	Quyết định	ADR/Nguồn
Cơ chế (Customer)	Bearer JWT	ICD §1 mục 9 — kế thừa 04-api-design.md §4.2, chưa có ADR riêng
Cơ chế (Guest)	Header X-Guest-Session-Id (giá trị CSPRNG ≥128-bit) + cookie HttpOnly; Secure; SameSite=Lax	ICD §1 mục 10
Cơ chế (Seller/Admin)	Bearer JWT (kế thừa cùng cơ chế Customer, khác role claim)	Suy từ CMP-02, chưa có tài liệu riêng ngoài phạm vi US-002/003
Nơi giữ trạng thái	Stateless (JWT) cho Customer/Seller/Admin · Stateful cho Guest (session lưu ở Redis, CMP-15, theo DAT §1.1)	DAT §1.1
Thời hạn access token	🔴 Chưa chốt số cụ thể cho P2 — ICD §1 mục 9 chỉ ghi "~15-60 phút (kế thừa 04-api-design.md §4.2)"; đây là khoảng tham khảo P1, chưa xác nhận cho P2. Đề xuất SA: 15 phút (an toàn hơn, giảm cửa sổ lợi dụng token bị đánh cắp) — xem OQ-051	—
Refresh token	🔴 Chưa chốt — đề xuất SA: có, TTL 14 ngày, không áp dụng rotation phức tạp kiểu P1 (docs/08 §8.1.1 refresh token rotation + reuse detection) ở MVP P2 vì tăng độ phức tạp mà chưa có bằng chứng cần thiết cho quy mô hiện tại; ghi nhận là điểm có thể nâng cấp khi có sự cố thật — xem OQ-051	Tham khảo P1, không kế thừa nguyên trạng
Cách thu hồi ngay lập tức	🔴 Chưa có cơ chế — JWT stateless không có denylist. Đề xuất SA: denylist Redis theo jti, TTL = thời hạn còn lại của token, tra cứu tại middleware authn mỗi request (thêm ~1 Redis lookup, chấp nhận được vì Redis đã là phụ thuộc sẵn có, CMP-15) — áp dụng khi: đổi mật khẩu, Admin khoá tài khoản, logout (tuỳ chọn). Chưa Tech Lead xác nhận	OQ-051 (mới)
Đa yếu tố (MFA)	Bắt buộc cho Admin, khuyến khích (không bắt buộc) cho Seller (ASR-009, QAS-012). Phương thức: TOTP app (RFC 6238) — chốt TẠM theo OQ-024/DEC-14/ASM-20, chưa Security thật xác nhận, OQ-024 vẫn mở	ASR-009
Backup code khi mất thiết bị MFA	🔴 Chưa thiết kế — đề xuất 10 mã dùng một lần khi enroll (tham khảo P1 §8.1.1, không sao chép nguyên bản vì P1 gắn với endpoint /v1/auth/mfa/enroll cụ thể chưa xác nhận tồn tại ở P2)	OQ-024
Nơi ký/xác minh chữ ký JWT	Identity & Access (CMP-02) ký bằng khoá riêng; các CMP khác chỉ xác minh (không tự ký)	CMP-02
Xoay khoá ký JWT	🔴 Chưa chốt tần suất — đề xuất tham khảo chung ngành: 90 ngày, dùng kid trong header JWT để hỗ trợ 2 khoá song song trong giai đoạn chuyển tiếp	OQ-051

2.1 Guest session — chi tiết

TTL	30 ngày không hoạt động (ICD §1 mục 10, DAT §1.1)
Rotation	🔴 Không có — cùng một X-Guest-Session-Id dùng suốt vòng đời phiên, không xoay định kỳ. Rủi ro: nếu giá trị bị lộ (session fixation qua log/URL), kẻ tấn công giữ quyền truy cập tới hết TTL. Đề xuất SA: xoay giá trị session tại thời điểm Guest chuyển đổi thành Customer (đăng ký/đăng nhập) — chưa thiết kế chi tiết, ghi OQ-051
Nơi giữ	Redis (CMP-15), là nguồn sự thật của session (không có bản ghi RDS song song, DAT §1.1)
Hết hạn	Guest mất phiên, phải tạo giỏ mới (BR-CART §3, đúng thiết kế)

2.2 Customer JWT — chi tiết

Thuật toán	🔴 Chưa chốt — đề xuất RS256 (asymmetric, cho phép các CMP khác chỉ cần public key để verify, không cần chia sẻ secret) thay vì HS256 (symmetric, mọi service verify phải giữ cùng secret — rủi ro lan rộng nếu 1 service bị lộ secret)
Claims tối thiểu	sub (customerId), role, iat, exp, jti (phục vụ denylist §2 trên) — chưa chốt scope claim chi tiết, xem §3
TTL access/refresh	Xem bảng §2 trên — cả hai chưa chốt số cuối, OQ-051

2.3 Seller / Admin — chi tiết

Ngoài phạm vi chi tiết hoá của module Giỏ hàng & Checkout (RBAC_CartCheckout §1 cố ý không đưa Seller/Admin vào ma trận) — SEC chỉ ghi nhận yêu cầu tối thiểu do ASR-009 ép ra:

Seller	JWT giống Customer, role=seller, MFA khuyến khích không bắt buộc
Admin	JWT giống Customer, role=platform_admin, MFA bắt buộc (TOTP, ASM-20); đề xuất bổ sung giới hạn mạng (VPN/IP allowlist) — tham khảo P1 docs/08 §3.3, chưa quyết định hạ tầng cho P2 vì INF (hoạt động 7) chưa chạy — ghi OQ-050
Account lockout (brute-force)	🔴 Chưa thiết kế cho P2 — đề xuất SA (tham khảo ý tưởng P1 docs/08 §8.1.1a, số ngưỡng đề xuất lại cho P2, chưa kế thừa nguyên bản): customer/seller 5 lần sai liên tiếp → khoá 15 phút; platform_admin 3 lần sai liên tiếp → khoá 30 phút (ngưỡng thấp hơn vì quyền hạn cao hơn). Chưa Security/Tech Lead xác nhận — OQ-052 (mới)

2.4 Service-to-service (Nhóm Giao dịch ↔ Nhóm Hỗ trợ ↔ Payment)

🔴 Đây là khoảng trống kiến trúc phát hiện bởi hoạt động sec — chưa ADR nào (ADR-002, ADR-007) quyết định cơ chế xác thực giữa hai service nội bộ (chỉ quyết định xác thực người dùng cuối tới service). IF-006/IF-021/IF-022 hiện chỉ dựa vào network reachability (security group VPC) — không có gì ngăn một service khác trong cùng VPC giả danh gọi thẳng các endpoint này nếu security group bị cấu hình sai hoặc một service bị compromise.

Ba phương án đã cân nhắc (quy tắc D3 — chưa viết ADR chính thức, đề xuất cho hoạt động adr kế tiếp):

Phương án	Mô tả	Ưu	Nhược
PA-1 — Chỉ dựa network (security group)	Giữ nguyên hiện trạng — không thêm gì	Không tốn công triển khai	Không đáp ứng "defense in depth" cho dữ liệu PII/tiền đi qua TB3/TB4; một security group cấu hình sai = không còn ranh giới nào
PA-2 — mTLS qua service mesh (AWS App Mesh/Private CA)	Mỗi ECS task có chứng chỉ riêng, xác thực lẫn nhau ở tầng TLS	Mạnh nhất, chuẩn ngành cho zero-trust nội bộ	Thêm hạ tầng mới (App Mesh) — SAD §7 v1.2 đã ghi rõ "không tự thêm hạ tầng mới (VD internal ALB/App Mesh) vào sơ đồ vì đó là quyết định kiến trúc mới, ngoài phạm vi" — mâu thuẫn trực tiếp với ghi chú đó nếu chọn ngay bây giờ; cần quyết định lại ở inf/adr
PA-3 — Service JWT ngắn hạn ký bởi Identity & Access + giữ nguyên security group (đề xuất SA)	Mỗi service tự xin "service token" (JWT riêng, sub=service-name, TTL ngắn ~5 phút) từ Identity & Access qua IAM role (không cần secret tĩnh), đính kèm header khi gọi IF-006/IF-021/IF-022; bên nhận verify chữ ký giống verify JWT người dùng (tái dùng hạ tầng ký/verify đã có)	Không cần hạ tầng mới ngoài quy ước header + logic verify (tái dùng key JWT của CMP-02); tương thích với ghi chú "không thêm hạ tầng mới" của SAD	Cần Identity & Access cấp phát token cho service (thêm luồng nội bộ mới, nhỏ); vẫn phụ thuộc network layer làm lớp phòng thủ đầu (không phải mTLS full zero-trust)

Đề xuất SA: PA-3, vì tương thích với ràng buộc đã ghi ở SAD §7 v1.2 (không thêm hạ tầng mới ở lượt này) trong khi vẫn nâng được một lớp phòng thủ so với hiện trạng thuần network. Ước lượng radar theo decision-radar.md §2: chi phí đảo ngược trung bình (đổi cơ chế sau khi đã code tốn sửa cả hai đầu gọi)=1 · bán kính: mọi lời gọi cross-network nội bộ (TB3, TB4) + tiền lệ cho các IF tương lai=2 · chạm gián tiếp QAS-002/QAS-010 (thêm bước xin token có thể ăn vào ngân sách latency đã eo hẹp, cần đo lại)=1 · ràng buộc ≥1 năm (chuẩn nội bộ cho service-to-service)=1 · chưa tranh cãi=0 → ~5, ở ngưỡng "ADR bắt buộc". Xem adr/ADR-015_service-jwt-xac-thuc-service-to-service.md (Proposed, viết ở hoạt động adr kế tiếp). OQ-050 giữ nguyên mở — chặn cứng bởi OQ-007 (Security chưa có người được chỉ định; ADR bảo mật chỉ chuyển Accepted khi có Security thật ký, xem ADR-015 §0/§3).

🔴 Đây là quyết định chạm cả QAS-002 (latency) lẫn ranh giới hạ tầng — ADR-015 ghi rõ điều kiện Accepted cần cả Tech Lead lẫn Security (phủ quyết) cùng xác nhận trước khi chốt.

---

3. Phân quyền (Authorization)

	Quyết định	ADR
Mô hình	RBAC đơn giản (2 vai trò trong phạm vi Cart&Checkout: Guest, Customer) + ABAC nhẹ cho ownership (đối chiếu session_id/customer_id với dữ liệu)	ADR-007
Chỗ ra quyết định	Service (Cart & Order tự kiểm tra), không phải gateway — CMP-01 chỉ chuyển token/session xuống, đúng SAD §4.1	ADR-007
Nguồn sự thật của vai trò	Identity & Access (CMP-02) — role claim trong JWT (Customer/Seller/Admin); Guest không có "vai trò" theo nghĩa RBAC, chỉ có session_id	CMP-02
Ràng buộc dữ liệu (row-level)	Có — ownership theo customer_id/session_id, cache Redis TTL ngắn, fallback query DB khi cache miss	ADR-007
Hành vi khi không xác định được quyền (lỗi kỹ thuật, không phải "không có quyền")	Fail-closed — trả 503 (không phải 403), mã lỗi đề xuất E-CART-0007 (theo FAIL §5, chưa có trong SRS/API của BA — OQ-040) khi cả Redis lẫn DB đều lỗi lúc kiểm tra ownership. Không bao giờ mặc định cho phép truy cập khi không kiểm tra được	FAIL FM-06, OQ-040

🔴 Fail-closed là quyết định bảo mật, không phải quyết định hiệu năng — nếu Tech Lead/Dev sau này "tối ưu" bằng cách coi lỗi kỹ thuật = cho phép (fail-open) để giảm tỷ lệ lỗi 503, đó là một lỗ hổng nghiêm trọng (bất kỳ ai cũng xem được giỏ/đơn của người khác khi hệ thống đang có sự cố). Ghi rõ ở đây để Security có căn cứ phủ quyết nếu phát hiện vi phạm khi review code.

3.1 Map RBAC của bộ BA xuống quyền kỹ thuật

RBAC_CartCheckout_v1.0.md §1 chỉ có 2 ROLE-nn trong phạm vi module này (Seller/Admin/CSR/Ops cố ý không đưa vào — xem RBAC §1). Cả 2/2 đã có dòng dưới đây — đủ điều kiện không chặn AG2 ở mục này.

ROLE-nn (BA)	Vai trò kỹ thuật	Claim/định danh	Quyền trên IF-nnn	Ràng buộc dữ liệu	Ai gán vai trò này
ROLE-01 Guest	guest (không có tài khoản, không JWT)	Header X-Guest-Session-Id (§2.1)	IF-002 — GET/PATCH/DELETE /v1/cart*, POST /v1/checkout	🔶 chỉ Cart/Order có session_id = giá trị header hiện tại — đối chiếu tại service (ADR-007), fail-closed nếu không kiểm tra được (E-CART-0007)	Hệ thống tự tạo tại lần truy cập đầu tiên chưa đăng nhập — không ai "gán", không cần phê duyệt
ROLE-02 Customer	customer (JWT role=customer)	sub = customerId trong JWT (§2.2)	IF-002 — cùng 4 endpoint như Guest	🔶 chỉ Cart/Order có customer_id = sub — đối chiếu tại service, fail-closed tương tự	Identity & Access (CMP-02) tự động khi đăng ký/đăng nhập thành công — self-service, không cần phê duyệt nội bộ

Seller (FR-19, module Quản lý đơn hàng seller) và Admin/CSR/Ops (không có hành động trực tiếp trong RQ-001…004) ngoài phạm vi map này theo đúng RBAC_CartCheckout §1 — sẽ có RBAC/map riêng khi module tương ứng tới lượt thiết kế chi tiết. ASR-009 (MFA Admin) vẫn áp dụng xuyên suốt bất kể module nào Admin thao tác (xem §2.3).

3.2 Phân tách nhiệm vụ (SoD)

Kế thừa nguyên trạng kết luận của RBAC_CartCheckout §3 (BA): không áp dụng được trong phạm vi module này — mọi hành động (tạo giỏ, tách đơn, chọn thanh toán) là tự phục vụ do chính khách hàng thực hiện trên dữ liệu của họ, không có bước "người thứ hai duyệt". Việc tách đơn (BR-CART-01) và xác nhận thanh toán (BR-CART-06) do hệ thống tự động thực hiện theo rule, không phải nhân sự nội bộ phê duyệt.

Hành động	Người thực hiện không được đồng thời là	Cơ chế cưỡng chế
(không có trong phạm vi module Giỏ hàng & Checkout — SoD sẽ cần thiết khi module Quản lý đơn hàng có bước Seller/CSR/Admin can thiệp thủ công, VD duyệt hoàn tiền — ngoài phạm vi tài liệu này)

---

4. Threat model — STRIDE

Theo 8 ranh giới tin cậy ở §1. Mỗi THR-nn: loại STRIDE · tài sản bị nhắm · biện pháp · cách kiểm chứng · truy vết QAS/ASR/ADR.

4.1 TB1 — Client ↔ ALB/WAF

ID	Loại (STRIDE)	Mối đe doạ	Thành phần bị nhắm	Mức	Biện pháp	Cách kiểm chứng	Truy vết
THR-01	Spoofing	Đánh cắp JWT/session qua XSS hoặc MITM (nếu TLS bị hạ cấp)	Token Customer, session Guest	🔴	TLS 1.2+ bắt buộc + HSTS; access token khuyến nghị giữ trong memory (SPA), không localStorage; cookie Guest HttpOnly;Secure;SameSite=Lax (đã có, ICD §1)	Test cấu hình TLS/HSTS tự động (FIT-33 ứng viên) + code review chỗ lưu token phía FE	QAS-010, ASR-007
THR-02	Tampering	Client gửi giá/số lượng đã bị sửa (tamper qua devtools) để checkout giá thấp hơn	POST /v1/checkout request body	🟠	Server luôn tính giá/tổng từ product_variant.price_amount/unit_price_snapshot phía BE, không tin giá trị giá do client gửi (đã đúng thiết kế ICD, không phát hiện lỗ hổng cụ thể)	Test gửi giá giả trong payload, xác nhận BE bỏ qua và tự tính lại	ASR-003, ADR-003
THR-04	Information disclosure	TLS downgrade / lộ thông tin qua response header thừa (server banner, stack trace)	Toàn bộ traffic + response lỗi	🟠	HSTS, ẩn header Server/version; response 500 không bao giờ trả chi tiết exception, chỉ traceId (đã đúng thiết kế ICD §1 mục 4)	Scan cấu hình TLS (SSL Labs-style) định kỳ; test gọi lỗi 500 xác nhận không rò rỉ stack trace	—
THR-05	Denial of Service	Volumetric/L7 flood tại biên (trước khi tới ứng dụng)	CMP-01 WAF/ALB, toàn bộ hệ thống phía sau	🟠	WAF rate-based rule + AWS Shield Standard (mặc định có với CloudFront/ALB); rate-limit theo IP ở tầng WAF trước khi request chạm ứng dụng	Load test giả lập burst traffic trên staging (ứng viên FIT, ngoài phạm vi diễn tập GĐ2)	QAS-009

4.2 TB2 — ALB → Nhóm Giao dịch (ownership/IDOR)

ID	Loại (STRIDE)	Mối đe doạ	Thành phần bị nhắm	Mức	Biện pháp	Cách kiểm chứng	Truy vết
THR-06	Spoofing	Guest session id bị đoán (nếu CSPRNG yếu) hoặc bị lộ qua log/URL	X-Guest-Session-Id	🔴	CSPRNG ≥128-bit (đã chốt ICD §1 mục 10); cấm đưa session id vào query string/URL (chỉ header/cookie); log-scrubber không ghi giá trị đầy đủ	Test entropy giá trị sinh ra; grep log staging xác nhận không xuất hiện session id đầy đủ	QAS-010
THR-07	Elevation of Privilege	IDOR — request giả mạo cartItemId/orderId không phải chủ sở hữu	CMP-04 mọi endpoint IF-002	🔴	Ownership check bắt buộc tại service (ADR-007), 0% bypass, fail-closed khi lỗi kỹ thuật (E-CART-0007)	Integration test tự động gọi API với token/session không phải chủ sở hữu — 0 lượt thành công (đã có ở QAS-010, tương ứng AC-US003-12/13)	QAS-010, ASR-007, ADR-007
THR-08	Denial of Service	Guest lạm dụng PATCH/DELETE /v1/cart/items (spam thêm/xoá liên tục) để tiêu tốn tài nguyên hoặc thao túng tồn kho reserve	CMP-04, CMP-03 (reserve tồn kho)	🟠	Rate limit theo IP + session_id — xem đề xuất số cụ thể ở §5.3 (OQ-023)	Test gửi burst request vượt ngưỡng, xác nhận 429	RBAC_CartCheckout §8 OQ-015 (BA)

4.3 TB3 — Nhóm Giao dịch ↔ Nhóm Hỗ trợ (IF-021/IF-022, cross-network)

ID	Loại (STRIDE)	Mối đe doạ	Thành phần bị nhắm	Mức	Biện pháp	Cách kiểm chứng	Truy vết
THR-09	Spoofing	Không có xác thực danh tính bên gọi — bất kỳ tiến trình nào trong VPC có thể giả danh Cart & Order gọi IF-021/IF-022 nếu security group không chặt	CMP-07, CMP-05	🔴	Service JWT ngắn hạn — ADR-015 (Proposed, chưa Accepted — chặn bởi OQ-007/OQ-050)	Chưa kiểm chứng được — chặn bởi ADR-015 chưa Accepted	OQ-050, ADR-015
THR-10	Tampering	Payload IF-021 (áp dụng coupon) bị giả mạo giá trị giảm giá vượt hợp lệ nếu Promotion&Loyalty không validate chặt	CMP-07	🟠	Validate bounds: giá trị giảm ≥0 và ≤ tổng tiền đơn hàng (đã ghi ở FAIL §2 FM-12 câu hỏi 3)	Test gửi giá trị giảm âm/vượt tổng, xác nhận bị từ chối	FAIL FM-12
THR-11	Information disclosure	IF-022 trả nhầm thông tin seller khác (nếu logic tra cứu sai seller_id) hoặc lộ PII khách hàng nếu tương lai IF-022 đổi chiều mang theo dữ liệu khách	CMP-05	🟠	Denormalize sellerName snapshot (không JOIN ngược runtime, ICD §3.7) giảm bề mặt; nếu vẫn cần gọi runtime, kiểm tra input seller_id khớp đúng OrderSeller đang xử lý	Contract test xác nhận response chỉ chứa đúng trường mong đợi	OQ-032, OQ-033
THR-12	Denial of Service	Retry storm/cascading failure — Nhóm Hỗ trợ chậm/hỏng kéo theo Cart&Order giữ tài nguyên (đã phân tích ở FAIL FM-12)	CMP-04, CMP-07	🟠	Circuit breaker cho IF-021 (đã thiết kế FAIL §3.1), 0 retry trong đường găng checkout	Chaos test giả lập IF-021 timeout liên tục, xác nhận circuit breaker mở đúng ngưỡng (FIT-19, đã có ở FAIL)	FAIL FM-12, QAS-002

4.4 TB4 — Cart & Order ↔ Payment (IF-006)

ID	Loại (STRIDE)	Mối đe doạ	Thành phần bị nhắm	Mức	Biện pháp	Cách kiểm chứng	Truy vết
THR-13	Spoofing	Không có xác thực danh tính — một service khác trong VPC có thể giả danh Cart & Order để khởi tạo Payment giả	CMP-11	🔴	Cùng biện pháp THR-09 — ADR-015 (Proposed). Đây là ranh giới nhạy cảm nhất (tiền thật) — ưu tiên xử lý cao nhất, ADR-015 chưa Accepted	Chưa kiểm chứng được — chặn bởi ADR-015 chưa Accepted	ASR-002, OQ-050, ADR-015
THR-14	Tampering	amountVnd trong request IF-006 không khớp OrderSeller.subtotal_amount thật (do bug hoặc bên gọi bị compromise)	CMP-11	🔴	Payment Service phải tự đối chiếu lại amountVnd nhận được với giá trị tính từ OrderSeller (không tin tưởng tuyệt đối request đến, dù cùng nội bộ) — 🔴 chưa được ICD §3.3 ghi nhận là bước bắt buộc, đề xuất bổ sung ở lượt icd/dat kế tiếp	Test gửi amountVnd sai lệch, xác nhận Payment Service từ chối thay vì tin theo	ADR-002, ADR-003
THR-15	Repudiation	Không truy vết được ai/service nào đã trigger một Payment cụ thể nếu thiếu correlation id	CMP-11	🟡	X-Request-Id (OQ-031) xuyên suốt + audit log ghi actor/correlation_id (§7)	Kiểm tra log Payment Service có correlation_id khớp với log Cart & Order cho cùng giao dịch	OQ-031
THR-16	Elevation of Privilege	Module khác (ngoài Payment) cố truy cập trực tiếp RDS Payment (bỏ qua IF-006/IF-017)	CMP-14	🔴	Network/IAM cô lập hoàn toàn (ADR-002) — không security group nào khác được phép kết nối RDS Payment	Kiểm tra hạ tầng: Terraform plan/AWS Config rule xác nhận không có security group nào khác trỏ tới RDS Payment (đã có FIT-03 ở ADR-002)	ASR-002, ADR-002, FIT-03

4.5 TB5 — Payment ↔ VNPay/Momo (init sync + webhook inbound async)

ID	Loại (STRIDE)	Mối đe doạ	Thành phần bị nhắm	Mức	Biện pháp	Cách kiểm chứng	Truy vết
THR-17	Spoofing	Webhook IPN giả mạo (kẻ tấn công tự gọi endpoint webhook giả lập giao dịch thành công)	CMP-11, payment.status	🔴	Xác thực chữ ký/HMAC theo tài liệu VNPay/Momo — 🔴 chưa có tài liệu/sandbox thật, không bịa cơ chế cụ thể (ARISK-03). Đề xuất SA: từ chối cứng mọi webhook không xác minh được chữ ký hợp lệ, không xử lý "tạm chấp nhận rồi kiểm tra sau"	🔴 Chưa kiểm chứng được — chặn bởi thiếu sandbox. Khi có sandbox: test gửi webhook chữ ký sai, xác nhận bị từ chối và ghi log cảnh báo (khả năng giả mạo, không coi là lỗi hệ thống thường — đã ghi ở FAIL §2 FM-01/02)	ADR-004, ARISK-03, OQ-049
THR-18	Tampering	Replay webhook cũ (gửi lại payload hợp lệ đã xử lý trước đó để trigger lại logic)	CMP-11	🟠	Idempotency theo gatewayTransactionRef (ADR-004) + kiểm tra timestamp payload lệch ≤5 phút (ICD §1 mục 12) — đã xử lý cả 2 lớp (idempotent + chống replay theo thời gian)	Test gửi lại đúng webhook cũ ngoài cửa sổ 5 phút, xác nhận bị từ chối; gửi lại trong cửa sổ, xác nhận idempotent (không xử lý lại nghiệp vụ)	ADR-004, QAS-014
THR-19	Information disclosure	gateway_response_snapshot vô tình chứa dữ liệu thẻ nếu gateway trả về ngoài dự kiến	payment_transaction.gateway_response_snapshot (DAT §2.1)	🔴	Whitelist field được lưu trước khi ghi (lọc bỏ mọi trường không nằm trong danh sách kỳ vọng, mặc định từ chối lưu trường lạ thay vì mặc định chấp nhận) — đề xuất mới, chưa có trong DAT hiện tại	Test giả lập gateway trả thêm trường lạ (VD số thẻ rút gọn), xác nhận không được ghi vào gateway_response_snapshot	ASR-002, BR-CART-05 (BA)
THR-20	Repudiation	Không phát hiện được giao dịch bị VNPay/Momo báo sai trạng thái (báo success nhưng thực tế tiền chưa về, hoặc ngược lại)	payment.status	🟠	Job đối soát bù định kỳ ≤15 phút (ADR-004, QAS-014) — không tự động sửa, chỉ ghi ReconciliationLog + cảnh báo	Test giả lập webhook trễ/mất trên staging (cần sandbox thật để đầy đủ — FIT-21, đã có ở FAIL)	ADR-004, QAS-014
THR-21	Denial of Service	Webhook flooding (đối tác hoặc kẻ tấn công gửi số lượng lớn webhook giả)	CMP-11	🟡	Rate limit endpoint webhook theo nguồn IP đối tác đã biết (whitelist IP nếu đối tác công bố dải IP cố định — 🔴 chưa xác nhận, OQ-049); WAF chung ở TB1 vẫn áp dụng	Load test endpoint webhook trên staging	ARISK-03

4.6 TB6 — Shipping & Fulfillment ↔ GHN/GHTK webhook

ID	Loại (STRIDE)	Mối đe doạ	Thành phần bị nhắm	Mức	Biện pháp	Cách kiểm chứng	Truy vết
THR-22	Spoofing	Webhook cập nhật trạng thái vận chuyển giả mạo	CMP-10, shipment.status	🟠	Chữ ký/token theo tài liệu GHN/GHTK — 🔴 chưa có tài liệu/sandbox thật (ARISK-04), không bịa cơ chế cụ thể	Chưa kiểm chứng được — chặn bởi thiếu sandbox	ARISK-04, OQ-049
THR-23	Tampering	Trạng thái vận đơn "thụt lùi" (từ "đang giao" về "đã tạo đơn") do webhook lỗi/giả mạo	shipment.status	🟡	Không ghi đè khi trạng thái mới "thụt lùi" so với trạng thái tiến bộ nhất đã ghi (đã thiết kế ở FAIL §2 FM-03/04), cảnh báo Ops kiểm tra thủ công	Test gửi webhook trạng thái thụt lùi, xác nhận không ghi đè	FAIL FM-03/04

4.7 TB7 — App ↔ RDS/Redis/SQS

ID	Loại (STRIDE)	Mối đe doạ	Thành phần bị nhắm	Mức	Biện pháp	Cách kiểm chứng	Truy vết
THR-24	Information disclosure	Một module đọc/ghi nhầm schema của module khác trong cùng RDS chính (schema-per-module nhưng chung instance/IAM lỏng lẻo)	CMP-13 (8 schema)	🟠	IAM DB role riêng theo module, chỉ cấp quyền đúng schema của module đó (Postgres role + GRANT theo schema) — 🔴 chưa được DAT/ADR-006 xác nhận chi tiết cấp quyền, đề xuất bổ sung ở inf	Kiểm tra GRANT/role Postgres qua migration review; test connection dùng role module A cố SELECT schema module B, xác nhận bị từ chối	ADR-006, D7
THR-25	Tampering	Producer không hợp lệ (service bị compromise hoặc external actor với network access) publish message giả vào SQS/EventBridge	CMP-12	🟠	IAM policy giới hạn sqs:SendMessage/events:PutEvents chỉ cho ECS task role của CMP-04/CMP-11 (publisher hợp lệ duy nhất); consumer validate schema (eventVersion, field bắt buộc) trước khi xử lý, message không hợp lệ → DLQ (đã có ở FAIL §2 FM-09/10)	Kiểm tra IAM policy qua Terraform plan; test publish message sai schema, xác nhận route DLQ	ADR-005, FAIL FM-09/10
THR-26	Information disclosure	Kết nối Redis không mã hoá in-transit trong VPC (nếu VPC bị compromise, traffic session/ownership cache có thể bị nghe lén)	CMP-15	🟡	Bật TLS in-transit cho ElastiCache Redis (encryption in-transit, tính năng có sẵn của AWS) — 🔴 chưa xác nhận đã bật hay chưa trong cấu hình INF (chưa chạy)	Kiểm tra cấu hình ElastiCache khi inf chạy	INF (hoạt động 7, chưa chạy)
THR-27	Denial of Service	Một module (đọc nặng, VD Catalog search) chiếm hết connection pool RDS chung, chặn module ghi (checkout)	CMP-13	🟠	Bulkhead — connection pool riêng theo module (đã ghi nhận ở FAIL §3.3, kích thước cụ thể chờ POC-02, OQ-037)	Load test saturate pool 1 module, xác nhận module khác không bị ảnh hưởng (FIT-22, đã có ở FAIL)	FAIL FM-06, OQ-037

4.8 TB8 — Admin console

ID	Loại (STRIDE)	Mối đe doạ	Thành phần bị nhắm	Mức	Biện pháp	Cách kiểm chứng	Truy vết
THR-28	Spoofing	Đánh cắp/dò mật khẩu Admin (không có MFA bypass path)	CMP-02 (Admin)	🔴	MFA bắt buộc TOTP (ASR-009), account lockout sau 3 lần sai (§2.3, đề xuất)	Test đăng nhập Admin không qua MFA, xác nhận bị từ chối (đã có ở QAS-012)	QAS-012, ASR-009
THR-29	Elevation of Privilege	Thiếu kiểm tra scope/role dẫn tới Customer/Seller gọi được endpoint Admin	CMP-02 và mọi endpoint quản trị	🔴	Middleware kiểm tra role/scope claim bắt buộc trước business logic (nguyên tắc chung, tham khảo ý tưởng P1 docs/08 §8.1.2, tự quyết định lại cho P2 vì P2 không có OPA/BFF riêng như P1)	Test gọi endpoint Admin bằng JWT role=customer, xác nhận 403	ASR-009
THR-30	Repudiation	Hành động Admin (khoá tài khoản, duyệt seller...) không được ghi vết	Toàn hệ thống, đặc biệt module ngoài phạm vi US-002/003	🟠	audit_log bắt buộc cho mọi hành động Admin nhạy cảm (§7)	Kiểm tra coverage: mọi endpoint role=admin ghi được ≥1 dòng audit_log tương ứng (FIT-32 mới)	RBAC_CartCheckout §5
THR-31	Denial of Service	Brute-force đăng nhập Admin (dò mật khẩu hàng loạt)	/v1/auth/login (Admin)	🟠	Account lockout (§2.3) + rate-limit theo IP (§5.3) + captcha sau N lần sai (tham khảo ý tưởng P1, chưa chốt ngưỡng cho P2)	Test brute-force giả lập, xác nhận khoá đúng ngưỡng	OQ-052

4.9 Mối đe doạ đã chấp nhận

THR	Vì sao chấp nhận	Ai ký · ngày	Dấu hiệu cảnh báo	Kế hoạch nếu xảy ra
(chưa có mục nào — Security chưa có người để ký chấp nhận rủi ro, OQ-007. Không tự chấp nhận rủi ro thay Security theo D10.)

🔴 Tổng kết: 31 THR được liệt kê (THR-01…31, một số ID không liên tục do rà soát nhóm theo STRIDE không đều ở mỗi ranh giới — không có ID nào bị bỏ trống ngầm). Bốn nhóm mức 🔴 cao nhất chưa có biện pháp đủ: (1) THR-09/THR-13 — thiếu service-to-service authn ở TB3/TB4 (§2.4, OQ-050); (2) THR-17/THR-22 — chữ ký webhook thật chưa xác nhận được vì thiếu sandbox đối tác (OQ-049, ARISK-03/04); (3) THR-19 — lọc trường gateway_response_snapshot chưa triển khai; (4) mọi threat liên quan PII (THR-11 gián tiếp) phụ thuộc OQ-007 chưa có người phủ quyết.

---

5. Bảo vệ dữ liệu

🔴 Toàn bộ mục này (§5) là ĐỀ XUẤT của SA, CHƯA CÓ HIỆU LỰC PHỦ QUYẾT — Security/Pháp chế chưa có người được chỉ định (OQ-007, mở từ GĐ1, kế thừa RISK-03 của BA). Không coi bất kỳ dòng nào dưới đây là quyết định cuối cùng.

5.1 Phân loại & mã hoá

Kế thừa nguyên trạng phân loại đã có ở DAT_e-commerce_v1.0.md §5 (không lặp lại toàn bộ bảng — tham chiếu bằng đường dẫn theo D "không copy nội dung giữa các tài liệu"). SEC xác nhận lại góc độ bảo mật/kiểm chứng cho từng nhóm:

Nhóm dữ liệu	Mã hoá at-rest	Mã hoá in-transit	Che khi hiển thị	Che khi log	Nguồn phân loại
Danh tính & liên hệ khách hàng (email/phone/full_name)	RDS KMS mặc định (đề xuất DAT §5)	TLS 1.2+ mọi kết nối (§1)	Không che với chính chủ; không hiển thị cho seller	Bắt buộc — log-scrubber mask email/phone (đề xuất mới, tham khảo ý tưởng P1 docs/08 §8.2.3, tự quyết định lại)	DAT §5
Địa chỉ giao hàng (recipient_name/phone/address_line)	RDS KMS	TLS 1.2+	Whitelist cho seller — chỉ 3 trường trên, đúng OrderSeller liên quan (ADR-008 PA-2, đề xuất) — 🔴 mức che (full hay một phần) chưa chốt, xem OQ-053 (mới)	Bắt buộc mask trong log ứng dụng	DAT §5, RBAC §4
KYC seller (file_url_s3, tax_code, business_license_number)	S3 SSE-KMS + RDS KMS; đề xuất mã hoá tầng ứng dụng bổ sung (tham khảo ý tưởng P1 docs/08 §8.2.1)	TLS 1.2+	Chỉ Admin/CSR đã duyệt xem (ngoài phạm vi module này)	Không log giá trị đầy đủ; nếu cần audit, mask giữ vài ký tự đầu/cuối (tham khảo ý tưởng P1 docs/08 §8.2.5a)	DAT §5
Tài khoản ngân hàng seller (account_number)	Bắt buộc mã hoá tầng ứng dụng (không chỉ KMS)	TLS 1.2+	Che một phần khi hiển thị (VD ****1234)	Che hoàn toàn, không log giá trị	DAT §5
Dữ liệu thanh toán (payment.amount, gateway_transaction_ref, gateway_response_snapshot đã lọc)	RDS KMS (RDS Payment riêng, ADR-002) + đề xuất mã hoá tầng ứng dụng cho gateway_transaction_ref	TLS 1.2+, RDS Payment mạng riêng	Chỉ hiển thị tham chiếu rút gọn cho khách	Tuyệt đối không log gateway_response_snapshot thô ở mức DEBUG production	DAT §5, ADR-002
Dữ liệu nghiệp vụ công khai (product, category, review)	RDS KMS mặc định	TLS 1.2+	Không cần che	Không cần che	DAT §5

🔴 Dữ liệu production trên môi trường dev/staging bị cấm tuyệt đối — đúng nguyên tắc template mục 5. Yêu cầu quy trình anonymize khi sao chép Production → Staging (hash/mask email/phone, xoá tax_code/account_number thật, thay bằng dữ liệu giả lập nhất quán) — chưa có quy trình cụ thể cho P2, đề xuất tham khảo ý tưởng P1 (docs/08 §8.2.3), ghi nhận là việc cần làm ở hoạt động inf (§7 non-prod topology).

5.2 Whitelist chia sẻ PII cho seller — hiện thực hoá ADR-008 PA-2

Đúng như ADR-008 (Proposed, chờ Security/Legal) và DAT §5.2 đã thiết kế: order_seller chỉ lưu snapshot đúng 3 trường (recipient_name, phone, address_line) — không JOIN ngược sang schema identity. SEC xác nhận lại từ góc độ threat model: đây là biện pháp giảm bề mặt rủi ro đúng (THR-11), nhưng bản thân việc "3 trường này có nên hiển thị đầy đủ hay che một phần cho seller" vẫn là câu hỏi mở — xem OQ-053.

🔴 Nếu Security/Legal từ chối PA-2 khi có người ký, toàn bộ §5.1/§5.2 và cơ chế denormalize ở DAT §5.2/ICD §3.7 phải thiết kế lại — đây là rủi ro kiến trúc đã ghi nhận ở ADR-008 §3, không phải điều mới phát hiện ở sec.

5.3 Đề xuất rate limit — trả lời OQ-023

🔴 OQ-023 yêu cầu: "SEC đề xuất số cụ thể + hệ quả, không tự quyết thay Security." Bảng dưới là đề xuất, Security là người chốt cuối.

Endpoint/hành động	Ngưỡng đề xuất	Đơn vị đếm	Hệ quả nếu Security chọn CHẶT hơn	Hệ quả nếu Security chọn LỎNG hơn
PATCH/DELETE /v1/cart/items (Guest)	30 request/phút	Theo session_id (chính) + 60 req/phút theo IP (phòng vệ phụ, chống một IP tạo nhiều session để né giới hạn theo session)	VD 10/phút: giảm mạnh khả năng spam/thao túng tồn kho reserve, nhưng có thể chặn nhầm khách thao tác nhanh trên UI (VD sửa số lượng nhiều dòng liên tiếp) — tăng khiếu nại trải nghiệm	VD 100/phút: giảm false positive, nhưng dễ bị lạm dụng để giữ/giải phóng tồn kho reserve liên tục (làm nhiễu inventory_stock, ảnh hưởng gián tiếp trải nghiệm khách thật muốn mua)
POST /v1/checkout	10 request/phút theo session_id/customer_id	Theo định danh (Guest: session, Customer: customer_id)	VD 3/phút: an toàn hơn trước spam tạo đơn giả (RBAC §8 OQ-015 của BA), nhưng khách thao tác thật thử lại nhiều lần sau lỗi 4xx/5xx có thể bị chặn oan	VD 30/phút: giảm false positive khi khách retry sau lỗi mạng, nhưng tăng rủi ro spam tạo Order/giữ tồn kho reserve hàng loạt
POST /v1/auth/login (mọi vai trò)	10 request/phút theo IP (độc lập với account lockout §2.3, đây là lớp phòng thủ theo IP)	Theo IP	VD 3/phút: chống brute-force mạnh hơn, nhưng ảnh hưởng người dùng chung IP NAT (mạng công ty/quán net Việt Nam khá phổ biến)	VD 50/phút: giảm false positive NAT, nhưng làm yếu lớp phòng thủ IP (vẫn còn account lockout §2.3 làm lớp thứ hai)
Webhook inbound (IF-007/IF-008/IF-018/IF-019)	Không giới hạn cứng theo request/phút (đối tác tự quyết định tần suất gọi lại) — chỉ giới hạn ở WAF chung (TB1) chống flood bất thường	—	—	—

🔴 Ba con số trên (30, 10, 10) là ước lượng SA dựa trên hành vi UI thông thường (không có dữ liệu traffic thật, greenfield) — không phải kết quả đo. Security cần xác nhận hoặc điều chỉnh dựa trên khẩu vị rủi ro thật của tổ chức.

---

6. Quản lý secret

	Quyết định
Nơi lưu	AWS Secrets Manager cho: DB credentials (RDS chính + RDS Payment, secret riêng biệt, không chung), API key/secret VNPay/Momo/GHN/GHTK, JWT signing key (CMP-02), SMTP/SMS provider key (khi có nhà cung cấp, OQ-016 của TCO)
Cách ứng dụng lấy	ECS task role (IAM) có quyền secretsmanager:GetSecretValue chỉ đúng secret của module đó — không task nào được đọc secret của module khác (đối xứng với nguyên tắc cô lập schema §4.7)
Xoay khoá: tần suất, tự động hay thủ công	DB credentials: tự động (AWS Secrets Manager rotation Lambda, chu kỳ đề xuất 30 ngày — chưa Tech Lead xác nhận); API key đối tác ngoài: thủ công, chu kỳ đề xuất 90 ngày (phụ thuộc khả năng hỗ trợ rotation của từng đối tác — 🔴 chưa xác nhận VNPay/Momo/GHN/GHTK có hỗ trợ rotate key không, ARISK-03/04); JWT signing key: xoay 90 ngày, dùng kid để hỗ trợ 2 khoá song song (§2.2)
Cấm tuyệt đối	Secret trong mã nguồn/Git, secret trong biến môi trường bị ghi vào log (log-scrubber phải chặn pattern giống secret), secret trong ảnh container (build-time bake)
Cách phát hiện rò rỉ	Quét mã nguồn trong CI/CD (Gitleaks/TruffleHog) — chặn merge nếu phát hiện secret pattern; FIT-29 (mới, ứng viên GĐ3)

---

7. Audit log

Theo phương án (a) đã chốt TẠM ở OQ-047/DEC-25 (DAT): mỗi module tự ghi audit_log trong schema của mình, KHÔNG có CMP-16 Audit tập trung. SEC chốt trường bắt buộc + retention + chống sửa cho quy ước chung áp dụng mọi module.

Hành động phải ghi	Ghi những trường gì	Ai đọc được	Giữ bao lâu	Chống sửa bằng cách nào
Tạo Order/OrderSeller (checkout)	actor_type (guest/customer)· actor_id (customer_id/session_id) · action · resource_type/resource_id · ip_address · correlation_id (X-Request-Id, OQ-031) · timestamp (UTC) · result	Chính chủ đơn (qua tra cứu); nội bộ Kế toán/CSKH (module ngoài phạm vi US-002/003)	10 năm — nhất quán retention tài chính (DAT §6)	Bảng append-only — role ứng dụng chỉ có INSERT/SELECT, không UPDATE/DELETE (cưỡng chế ở DB role, không chỉ ở tầng code)
Khởi tạo thanh toán / cập nhật payment.status	Tương tự trên + payment_method, gateway_transaction_ref (đã che theo §5.1)	Chính chủ đơn; nội bộ Kế toán	10 năm	Tương tự trên (schema payment, RDS riêng theo ADR-002)
Đăng nhập/thất bại (mọi vai trò)	actor_id, role, ip_address, result (success/fail), timestamp, mfa_used (bool)	Platform Admin (scope admin:audit:read — ý tưởng tham khảo P1, tự quyết định lại cho P2 vì chưa có endpoint đọc audit riêng)	5 năm (đề xuất, tham khảo ý tưởng P1)	Append-only, schema identity
Thay đổi quyền / khoá tài khoản (Admin)	actor_id (Admin thực hiện), target_id, before/after (redact trường nhạy cảm nếu có), reason (nếu có), timestamp	Platform Admin	5 năm	Append-only, schema identity
Truy cập dữ liệu nhạy cảm (VD Admin xem KYC document)	actor_id, resource_type/resource_id, timestamp — không ghi nội dung tài liệu, chỉ ghi hành động xem	Platform Admin	5 năm	Append-only (module Seller Mgmt, ngoài phạm vi chi tiết US-002/003)
Ownership check thất bại (IDOR bị chặn)	actor_id/session_id, resource_type/resource_id bị yêu cầu, ip_address, timestamp — phục vụ điều tra khi nghi ngờ tấn công hàng loạt	Security (khi có người)	🔴 chưa chốt — đề xuất 1 năm, thấp hơn nhóm tài chính vì mục đích khác (an ninh vận hành, không phải bằng chứng giao dịch)	Append-only

🔴 Audit log mà người bị audit sửa được thì không phải audit log — mỗi schema-per-module (ADR-006) phải cưỡng chế append-only ở mức DB role của chính schema đó, không có ngoại lệ cho platform_admin (Admin xem được nhưng không sửa/xoá được bản ghi audit).

🔴 Khoảng trống đã biết: không có CMP Audit tập trung (phương án (a)) nghĩa là không có một nơi duy nhất để Security truy vấn xuyên toàn sàn khi điều tra sự cố — mỗi module phải được truy vấn riêng. Đây là đánh đổi đã chấp nhận TẠM ở DEC-25, chưa Security thật xác nhận. Nếu Security khi có người yêu cầu audit tập trung, cần mở lại OQ-047 và có thể đảo ngược sang phương án (b) (CMP-16) — chi phí đảo ngược: thêm 1 service mới + migrate log lịch sử từ N schema sang 1 nơi.

---

8. Tuân thủ

8.1 PCI-DSS SAQ A

Yêu cầu	Nguồn	Cách đáp ứng	Bằng chứng cho kiểm toán	Ai xác nhận
Không lưu PAN/CVV ở bất kỳ đâu ngoài Payment Service	CON-06, BR-CART-05 (BA), ADR-002	payment_transaction.gateway_response_snapshot phải lọc trước khi ghi (THR-19); schema linter chặn cột kiểu "card_number"/"cvv" ở mọi schema khác payment	FIT-04 (đã đề xuất ở ADR-002)	Security (chưa có người)
Ranh giới mạng/IAM/dữ liệu cô lập hoàn toàn	ASR-002, ADR-002	Network diagram + IAM policy review; không security group nào khác trỏ tới RDS Payment	FIT-03 (đã đề xuất ở ADR-002)	Security
Hình thức tích hợp VNPay/Momo phải là redirect, không nhúng iframe/form nhập thẻ trên domain sàn (đề xuất mới)	Suy luận từ yêu cầu SAQ A (tham khảo docs/08 §8.4: "nếu redirect, scope tương ứng SAQ A")	🔴 Chưa xác nhận được với VNPay/Momo thật — chưa có tài liệu tích hợp, chưa biết họ có hỗ trợ redirect thuần hay bắt buộc SDK/iframe nào đó. Nếu chỉ hỗ trợ iframe/API pass-through dữ liệu thẻ, toàn bộ giả định SAQ A của ASR-002/ADR-002 phải xét lại (có thể cần nâng cấp phạm vi tuân thủ, ảnh hưởng chi phí TCO)	—	Tech Lead + Security (OQ-048, mới)
Webhook: chữ ký/HMAC theo tài liệu đối tác	ADR-004	🔴 Chưa biết cơ chế cụ thể (SecureHash/HMAC-SHA256/khác) — không bịa, chờ tài liệu đối tác	THR-17	OQ-049 (mới), ARISK-03
Chống replay webhook	ADR-004	Kiểm tra timestamp payload lệch ≤5 phút (đã chốt, ICD §1 mục 12)	THR-18	Đã đủ điều kiện kỹ thuật, chờ sandbox để kiểm chứng thật
Quét lỗ hổng ASV hàng quý	CON-06	Nhà cung cấp ASV bên ngoài — 🔴 chưa có báo giá	Báo cáo ASV	Security (OQ-017, đã mở ở TCO)
Pentest ứng dụng hàng năm	CON-06	Nhà cung cấp pentest bên ngoài — 🔴 chưa có báo giá	Báo cáo pentest	Security (OQ-017)

8.2 NĐ13/2023 (Bảo vệ dữ liệu cá nhân)

Yêu cầu	Nguồn	Cách đáp ứng	Bằng chứng	Ai xác nhận
Data minimization khi chia sẻ PII cho seller	ASR-008, QAS-011, ADR-008	Whitelist 3 trường (§5.2) — đề xuất, chưa hiệu lực	Contract test (FIT-11, đã đề xuất ở ADR-008)	Security/Legal — chưa có người (OQ-007)
Residency dữ liệu tại ap-southeast-1 đáp ứng đủ yêu cầu	CON-06, ASM-04	🔴 Chưa xác nhận — chỉ là giả định (ASM-04)	—	Legal (OQ-007)
Quyền được xoá / ẩn danh hoá	CON-06	Đề xuất 30 ngày ẩn danh hoá kể từ yêu cầu hợp lệ (DAT §5) — đề xuất, chờ Legal	—	Legal (OQ-007)
Xác thực danh tính người yêu cầu xoá (chống giả mạo yêu cầu xoá tài khoản người khác)	Ý tưởng tham khảo P1 (docs/08 §8.2.4), chưa thiết kế cụ thể cho P2	🔴 Chưa thiết kế	—	Legal + Tech Lead (mới, ngoài phạm vi US-002/003)

8.3 NĐ52/85 (thông báo website TMĐT marketplace)

Chủ yếu là nghĩa vụ pháp lý/hành chính (đăng ký với Bộ Công Thương), không phải control kỹ thuật thuộc SEC. Yêu cầu kỹ thuật liên quan (hiển thị thông tin đăng ký ở footer) thuộc tầng UI/FE, ngoài phạm vi tài liệu này.

---

9. Phụ thuộc & chuỗi cung ứng

	Quyết định
Quét lỗ hổng thư viện (SCA)	Trivy/Snyk/Dependabot trong CI/CD — đề xuất chặn build nếu phát hiện CVE mức Critical chưa có bản vá sau 7 ngày, mức High sau 30 ngày (đề xuất SA, chưa Tech Lead xác nhận)
Quét ảnh container	Trivy image scan trước khi push lên ECR — cùng ngưỡng chặn như trên
Chính sách vá lỗ hổng nghiêm trọng	Critical: ≤7 ngày · High: ≤30 ngày · Medium/Low: theo chu kỳ release thường
Ai duyệt thư viện mới	Tech Lead (theo decision-radar.md §5 — "Công cụ, thư viện" thuộc Tech Lead, SA chỉ phủ quyết nếu chạm QAS)
Pentest năm + ASV quý	Xem §8.1 — chi phí chưa có báo giá (OQ-017, đã mở ở TCO)

---

10. Giả định & Ngoài phạm vi

Giả định (tiếp số toàn dự án — ASM-01…38 đã dùng, bắt đầu ASM-39):

ID	Giả định	Cách xác minh	Nếu sai
ASM-39	VNPay/Momo hỗ trợ tích hợp dạng redirect thuần (không bắt buộc iframe/SDK truyền dữ liệu thẻ qua domain sàn), đủ điều kiện giữ SAQ A	Tech Lead xác nhận khi có tài liệu/sandbox thật (OQ-048, ARISK-03)	Nếu sai: phạm vi tuân thủ PCI-DSS phải nâng lên (SAQ A-EP hoặc cao hơn), ảnh hưởng trực tiếp ASR-002/ADR-002/chi phí TCO — cần rà lại toàn bộ SEC §8.1
ASM-40	Chưa có đủ traffic thật để hiệu chỉnh ngưỡng rate-limit (§5.3) — ba con số (30/10/10) là ước lượng dựa trên hành vi UI thông thường, không phải đo	Đo traffic thật 4-6 tuần đầu soft-launch, điều chỉnh lại	Nếu traffic thật khác biệt lớn (VD nhiều khách dùng chung IP NAT hơn dự kiến): cần tách ngưỡng theo session_id thuần, giảm phụ thuộc IP
ASM-41	Đề xuất PA-3 (service JWT) cho service-to-service authn (§2.4) không làm tăng đáng kể latency đường găng checkout (QAS-002)	Đo lại QAS-002 sau khi có thiết kế cụ thể + POC nếu Tech Lead chấp nhận hướng này	Nếu tăng latency đáng kể: cần xét lại PA-2 (mTLS, chấp nhận thêm hạ tầng) hoặc thiết kế cache token phía service gọi

Ngoài phạm vi:

• Threat model chi tiết cho các CMP ngoài "chi tiết nhất" (Seller Mgmt ngoài whitelist PII, Commission & Payout, Promotion & Loyalty ngoài IF-021, Review, Notification) — chỉ có ở mức ranh giới tin cậy (§1), chưa đào sâu STRIDE riêng. Sẽ bổ sung khi module tương ứng tới lượt thiết kế chi tiết.
• Cơ chế chữ ký/HMAC cụ thể của VNPay/Momo/GHN/GHTK — không bịa, chờ tài liệu/sandbox đối tác thật (ARISK-03/04, OQ-049).
• Hạ tầng cụ thể cho VPN/IP allowlist Admin, mã hoá in-transit ElastiCache, cấu hình IAM DB role chi tiết theo schema — thuộc hoạt động inf (hoạt động 7, chưa chạy).
• Endpoint đọc audit_log tập trung, DPIA (Data Protection Impact Assessment) — ngoài phạm vi US-002/003, ghi nhận là việc cần làm trước go-live (tham khảo docs/08 §8.4).
• Viết ADR chính thức cho service-to-service authn (§2.4) — chỉ đề xuất và ước lượng radar ở đây, việc viết ADR thuộc hoạt động adr kế tiếp (ngoài phạm vi hoạt động sec được giao).

---

11. Open Questions

Tiếp số sổ SA (00-index/OQ_e-commerce.md đang ở OQ-047) — bắt đầu OQ-048.

ID	Câu hỏi	Hỏi ai	Từ ngày	Chặn gì	Hệ quả nếu trả lời ngược
OQ-048	VNPay/Momo có hỗ trợ tích hợp dạng redirect thuần (không iframe/SDK nhập thẻ trên domain sàn) không — điều kiện để giữ phạm vi PCI-DSS SAQ A (ASM-39)?	Tech Lead + Security (khi có người)	2026-09-15	SEC §8.1; giả định nền của ASR-002/ADR-002	Nếu không hỗ trợ redirect thuần: phạm vi tuân thủ PCI-DSS phải nâng cấp, tăng chi phí audit/kiểm toán và có thể cần thiết kế lại luồng khởi tạo thanh toán
OQ-049	Cơ chế xác thực chữ ký/HMAC webhook cụ thể của VNPay, Momo, GHN, GHTK là gì (thuật toán, header, cách tính chữ ký)?	Tech Lead (khi có tài liệu đối tác)	2026-09-15	THR-17/THR-22; kiểm chứng ADR-004 thật	Không có tài liệu: threat model webhook chỉ dừng ở mức nguyên tắc chung ("phải xác thực"), không kiểm chứng được cho tới khi có sandbox — rủi ro triển khai sai cơ chế lúc code
OQ-050	Chấp nhận đề xuất PA-3 (service JWT ngắn hạn ký bởi Identity & Access) cho service-to-service authn giữa Nhóm Giao dịch ↔ Nhóm Hỗ trợ ↔ Payment không, hay chọn PA-2 (mTLS/App Mesh, cần thêm hạ tầng)?	Tech Lead + Security + Ops/SRE	2026-09-15	ADR mới ở hoạt động adr kế tiếp; thiết kế inf cho TB3/TB4	Chọn PA-3: rủi ro còn lại là chưa đạt mTLS full zero-trust, nhưng không cần hạ tầng mới ngay. Chọn PA-2: cần quyết định lại ràng buộc "không thêm hạ tầng mới" đã ghi ở SAD §7 v1.2, tăng thời gian/chi phí triển khai
OQ-051	Xác nhận số cụ thể: TTL access token (đề xuất 15 phút), TTL refresh token (đề xuất 14 ngày), cơ chế thu hồi tức thời (đề xuất denylist Redis theo jti), tần suất xoay khoá ký JWT (đề xuất 90 ngày)	Tech Lead	2026-09-15	Thiết kế CMP-02 (Identity & Access) khi tới lượt module đó; toàn bộ luồng authn Customer/Seller/Admin	Số quá ngắn (VD TTL 5 phút): tăng tần suất refresh, tăng tải Identity & Access. Số quá dài (VD TTL 60 phút không denylist): cửa sổ lợi dụng token bị đánh cắp dài hơn
OQ-052	Xác nhận ngưỡng account lockout theo vai trò (đề xuất: customer/seller 5 lần sai/15 phút; admin 3 lần sai/30 phút) và rate-limit login theo IP (đề xuất 10 request/phút)	Tech Lead + Security	2026-09-15	THR-28/31; thiết kế CMP-02	Ngưỡng quá chặt: tăng khiếu nại khách bị khoá oan (đặc biệt IP NAT dùng chung). Ngưỡng quá lỏng: tăng rủi ro brute-force thành công
OQ-053	Ba trường whitelist chia sẻ cho seller (recipient_name/phone/address_line, ADR-008 PA-2) hiển thị đầy đủ hay che một phần (VD số điện thoại che 3-4 số giữa)?	Security/Legal (khi có người) + PO	2026-09-15	DAT §5.2; UI hiển thị đơn hàng cho Seller (ngoài phạm vi US-002/003)	Hiển thị đầy đủ: seller đủ thông tin giao hàng nhưng tăng bề mặt rủi ro nếu tài khoản seller bị lộ. Che một phần: giảm rủi ro nhưng có thể gây khó khăn thao tác giao hàng thực tế (VD shipper cần gọi điện xác nhận)

Cập nhật cho OQ đã mở:

• OQ-007 — SEC bổ sung: toàn bộ §5, §8.2 của tài liệu này là đề xuất chờ phủ quyết; không coi bất kỳ phân loại/whitelist/mã hoá nào ở đây là đã "Security xác nhận". Giữ nguyên mở.
• OQ-023 — SEC trả lời bằng đề xuất số cụ thể ở §5.3 (30 req/phút Guest cart, kèm hệ quả cả hai chiều) — không tự quyết thay Security, OQ-023 giữ nguyên mở, chờ Security xác nhận hoặc điều chỉnh.
• OQ-024 (MFA Admin) — SEC xác nhận lại hướng TẠM TOTP app (ASM-20, DEC-14) và bổ sung chi tiết backup code (§2 bảng, chưa thiết kế đầy đủ) — giữ nguyên mở, chờ Security thật.

Nhắc: cộng với các OQ còn mở ảnh hưởng trực tiếp SEC — OQ-007 (PII/residency, chặn phần lớn §5/§8.2), OQ-017 (báo giá pentest/ASV, chặn §8.1/§9), ARISK-03/04 (sandbox đối tác, chặn kiểm chứng THR-17/18/22) — xem sổ đầy đủ 00-index/OQ_e-commerce.md.

Nhắc AG2: cần Tech Lead + Security + Ops/SRE ký — còn thiếu INF (hoạt động 7) và toàn bộ ADR liên quan SEC (ADR-002/004/007/008 vẫn Proposed; ADR service-to-service authn §2.4 chưa viết).

---

Tự chấm

① Bảng tự chấm Gate AG2 (workflow.md §2 — chỉ dòng liên quan tới SEC, tự chấm sớm)

#	Tiêu chí	☐/✅	Ghi chú
—	ASR/QAS/SAD/ICD/DAT/FAIL	✅ (đã đạt ở các hoạt động trước)	Không lặp lại
—	ADR-nnn tồn tại cho mọi quyết định đạt ngưỡng radar	🟡 Một phần	13 ADR đã viết (bao gồm ADR-002/004/007/008/011 liên quan bảo mật); SEC phát hiện 1 quyết định mới đạt ngưỡng ADR chưa viết — service-to-service authn (§2.4, radar ~5), ghi OQ-050
—	INF	☐	Chưa tới — hoạt động 7
1	SEC — có threat model STRIDE cho luồng nhạy cảm; mô hình authn/authz đã chốt; Security ký	☐	Threat model STRIDE đủ 8 ranh giới, 31 THR (§4); mô hình authn/authz đã đề xuất đầy đủ (§2, §3) nhưng chưa chốt ở nhiều điểm (OQ-050/051/052/053) và Security chưa ký (OQ-007, không có người) — đây là điều kiện chặn cứng nhất của AG2 theo SKILL.md ("Security có quyền phủ quyết AG2")
—	sa-conformance báo coverage ASR → ADR/CMP ≥ 100%	(không đổi bởi SEC)	SEC không tạo CMP/ASR mới; có đề xuất 1 ADR mới (service-authn) chưa viết

Kết luận tự chấm (riêng phần SEC): Hoạt động sec hoàn tất đúng phạm vi được giao — threat model STRIDE đủ 8 ranh giới tin cậy yêu cầu (31 THR), mô hình authn/authz đầy đủ cho Guest/ Customer/Seller/Admin + phát hiện khoảng trống service-to-service authn (mới, OQ-050), map đủ 2/2 ROLE-nn của RBAC_CartCheckout, PCI-DSS/NĐ13/2023 rà theo yêu cầu (mọi kết luận PII đánh dấu "đề xuất chờ Legal"), audit log + secret management + chuỗi cung ứng đã chốt trường/chính sách đề xuất. AG2 còn xa vì (a) INF (hoạt động 7) chưa chạy, (b) Security chưa có người (OQ-007) nên không ai có quyền phủ quyết/ký — đây là điều kiện chặn nghiêm trọng nhất, đúng cảnh báo của GUIDE.md: "phát hiện muộn nhất và đau nhất luôn đến từ đây."

② Checklist D1–D12 (design-rules.md)

#	Mục	☐/✅	Ghi chú
D1	Một ADR một quyết định	N/A	SEC không viết ADR mới ở lượt này — chỉ đề xuất 1 ADR ứng viên (service-authn, §2.4) cho hoạt động adr kế tiếp
D2	Không NFR định tính	✅	Mọi ngưỡng (rate-limit, TTL token, lockout) đều có con số hoặc đánh dấu rõ "chưa chốt" kèm OQ — không có mục nào ghi "bảo mật tốt" chung chung
D3	Nêu phương án bị loại + lý do	✅	§2.4 (3 phương án service-authn, PA-1/PA-2 bị loại có lý do gắn ràng buộc SAD §7)
D4	Sơ đồ khai báo mức + legend	✅	§1 khai báo rõ "ranh giới tin cậy" (flowchart LR theo D4), có legend
D5	Interface có chủ/contract	N/A	Đã xử lý ở ICD (hoạt động 4); SEC chỉ bổ sung khía cạnh xác thực/authz cho các IF đã có
D6	Phụ thuộc ngoài process có timeout/retry	N/A	Đã xử lý ở FAIL (hoạt động 8); SEC chỉ bổ sung khía cạnh threat/xác thực
D7	Một chủ sở hữu dữ liệu	N/A	Đã xử lý ở DAT (hoạt động 5); SEC chỉ tham chiếu khi thiết kế IAM theo schema (§4.7)
D8	Ràng buộc có FIT hoặc nhãn khuyến nghị	🟡 Một phần	Đề xuất FIT-29 (secret scan), FIT-30 (service-authn test, chờ OQ-050), FIT-31 (webhook signature test, chặn bởi ARISK-03/04), FIT-32 (audit completeness), FIT-33 (TLS/HSTS config test) — ứng viên GĐ3, chưa viết thật; các threat chưa có biện pháp đủ (THR-09/13/17/22) đánh dấu rõ "chưa kiểm chứng được", không giả vờ đã có FIT
D9	Con số hạ tầng quy ra tiền + nguồn	N/A	SEC không thêm con số hạ tầng mới (Secrets Manager/WAF đã có trong TCO/SAD từ trước)
D10	Không quyết định thay người có thẩm quyền	✅	Mọi kết luận PII/residency đánh dấu "đề xuất chờ Legal/Security" (§5, §8.2); rate-limit (§5.3), account lockout (§2.3), service-authn (§2.4) đều trình phương án kèm hệ quả hai chiều, không tự quyết; §4.9 để trống vì không tự chấp nhận rủi ro thay Security
D11	Có mục "Ngoài phạm vi" + ASM-nn	✅	§10 đầy đủ — ASM-39…41 mới, có cách xác minh/hệ quả
D12	Câu quy định thẩm quyền sơ đồ vs văn bản	✅	Có ngay sau Change Log

③ Bảng đối chiếu với bộ BA — RBAC ↔ SEC

RBAC_CartCheckout (BA)	Nội dung	SEC tương ứng	Khớp?	Hành động
§1 (2 vai trò: Guest, Customer)	Ma trận vai trò	§3.1 (map đủ ROLE-01/02)	✅	Không lệch — 2/2 ROLE-nn có dòng map, đúng yêu cầu "mỗi ROLE-nn phải có đúng một dòng, thiếu ⇒ chặn AG2"
§2 (không ai xem giỏ/đơn người khác)	Ranh giới ownership	§3 (fail-closed), THR-07	✅	Khớp — ASR-007/ADR-007 đã hiện thực hoá đúng
§3 (SoD không áp dụng)	Tự phục vụ, không có duyệt kép	§3.2	✅	Kế thừa nguyên trạng kết luận của BA, không lệch
§4 (mức che PII cho seller — chưa chốt)	Whitelist chưa quyết định mức che	§5.2, OQ-053 (mới)	🟡 Một phần	SEC xác nhận whitelist 3 trường (ADR-008) nhưng mức che cụ thể vẫn chưa chốt như BA đã ghi nhận — BA không cần sửa RBAC, câu hỏi này tiếp tục do Security/Legal quyết định khi có người
§5 (lưu vết — "chưa chốt thời hạn")	Audit log cho Order/Payment	§7 (10 năm, append-only)	🟡 Một phần	SEC đề xuất retention cụ thể (10 năm) — BA có thể cập nhật RBAC_CartCheckout §5 tham chiếu SEC §7 khi retention được Security/Tech Lead xác nhận thật
§6 (hành vi khi không đủ quyền)	403/không hiển thị dữ liệu	§3 (fail-closed 503 cho lỗi kỹ thuật, phân biệt với 403 thật)	✅ Bổ sung	SEC làm rõ thêm trường hợp BA chưa phân biệt (lỗi kỹ thuật khi kiểm tra ownership ≠ "không có quyền" thật) — BA nên bổ sung AC mới cho E-CART-0007 (đã ghi ở FAIL, nhắc lại ở đây)
§8 OQ-012 (Guest OTP đơn giá trị cao)	Chưa chốt	(ngoài phạm vi SEC — thuộc BR-CART-03, quyết định PO)	➖ N/A	Không hành động — đây là quyết định nghiệp vụ, không phải kiến trúc bảo mật
§8 OQ-015 (chống lạm dụng Guest checkout)	Chưa chốt	§5.3 (đề xuất rate-limit checkout 10/phút)	✅ Trả lời	SEC đã đề xuất số cụ thể — BA có thể đóng OQ-015 trong sổ BA, tham chiếu SEC §5.3, với điều kiện Security xác nhận số cuối cùng
§8 OQ-016 (mức che PII cho seller)	Chưa chốt	Trùng với RBAC §4 ở trên	🟡 Một phần	Cùng trạng thái — chờ Security/Legal, xem OQ-053 (SA)

④ Danh sách OQ mở kèm người phải trả lời, chặn gì

Xem §11 (OQ-048…053 mới) cộng cập nhật OQ-007/023/024. Ba câu hỏi quan trọng nhất cho AG2: OQ-007 (chưa có người Security/Legal — chặn toàn bộ hiệu lực phủ quyết của SEC), OQ-050 (service-to-service authn — khoảng trống kiến trúc mới phát hiện, ảnh hưởng TB3/TB4 nơi PII và tiền đi qua), OQ-048/OQ-049 (chưa có tài liệu/sandbox đối tác thanh toán/vận chuyển thật — chặn kiểm chứng phần lớn threat model TB5/TB6). Sổ đầy đủ: 00-index/OQ_e-commerce.md.

Nhắc: AG2 cần Tech Lead + Security + Ops/SRE ký — còn thiếu INF (hoạt động 7) và chưa có người Security để ký bất kỳ phần nào của SEC. Đây là rủi ro tiến độ nghiêm trọng nhất của toàn GĐ2: theo GUIDE.md, "Bước sec cần một người thật từ Security ngồi cùng" — điều này chưa xảy ra trong suốt hoạt động sec vừa chạy, toàn bộ nội dung là công việc chuẩn bị một chiều của SA, chờ người đó xuất hiện.