VL
Nền tảng phân phối Vietlott qua Internet DOSSIER DỰ ÁN · v1.0
Kênh phân phối điện tử · không phát hành vé · không giữ tiền

Một nền tảng được dựng để bảo vệ ranh giới pháp lý, không chỉ để bán vé.

Mọi vé bán trên Internet đều phát hành chính thức qua hệ thống lõi Vietlott. Nền tảng là kênh phân phối: tiền do tổ chức thanh toán được cấp phép xử lý, vé do lõi Vietlott ký nhận. Gần như toàn bộ kiến trúc kỹ thuật phục vụ đúng ranh giới đó.

3,7M
tài khoản người dùng tối thiểu (NFR-PE-01)
100K
phiên đồng thời đỉnh kỳ quay (NFR-PE-03)
2.000
giao dịch/giây toàn hệ thống (NFR-PE-04)
288
kỳ Keno/ngày — yếu tố định cỡ thật (NFR-PE-05)
99,98%
uptime tầng ứng dụng/năm (SLA-01)
<15′
RTO · RPO < 5′ (NFR-AV-02/03)
Cấp 3
An toàn HTTT theo NĐ 85/2016 (NFR-SE-01)
≥5 năm
lưu trữ dữ liệu giao dịch tại VN (NFR-SE-05)
Bốn trục đáng lưu tâm nhất

Đọc đúng rủi ro trước khi đọc tính năng

Bốn điểm dưới đây quyết định khả thi và tiến độ nhiều hơn bất kỳ danh sách tính năng nào.

RỦI RO #1

API hệ thống lõi Vietlott chưa tồn tại

Giá trị nền tảng lệ thuộc hoàn toàn vào API lõi — mà hợp đồng API bị khóa sau NDA và chỉ chốt ở giai đoạn thiết kế chi tiết (Phần 5). Nhà thầu phải cam kết phát hành vé < 3s và idempotency trên một giao diện chưa được định nghĩa.

BÀI TOÁN THẬT

Keno, không phải con số TPS

288 kỳ/ngày ≈ một chu kỳ khóa kỳ → chốt sổ → mở kỳ mỗi ~5 phút. Cái khó là thundering-herd tại mỗi thời điểm chuyển kỳ. Auto-scaling "trong 30 phút" (NFR-PE-03) vô dụng với spike lặp lại mỗi 5 phút — tải này phải pre-provision theo lịch quay.

CRITICAL PATH

Tích hợp nhà nước, không phải code

VNeID, AML lên NHNN, eTax, báo cáo Bộ Tài chính đều "theo phương thức cơ quan có thẩm quyền phê duyệt tại từng thời điểm". Tiến độ dự án thường chết ở đây, không phải ở app người chơi.

LỚP NỀN

Blockchain = sổ kiểm toán bất biến

Permissioned chain trên VBSN: chỉ ghi hash/tham chiếu, không PII (né Luật BVDLCN 91/2025). Giá trị thật là observer node cho cơ quan quản lý + lưu vết append-only. Cần tách rõ phần nào thực sự cần on-chain.

Vòng đời vé điện tử

T0 → T5, với hai nhánh ngoại lệ

T0 Chọn sản phẩm T1 · PENDING Tạo đơn, khóa kỳ T2 Thanh toán + AML T3 · CONFIRMED Lõi Vietlott phát hành T4 Đối soát kết quả T5 Hoàn tất T-R · Hoàn tiền T-D · Tranh chấp Tuyến tính (bắt buộc) Nhánh ngoại lệ
FR-VE-01 · mọi chuyển trạng thái được lưu vết bất biến; T3 chỉ đạt khi lõi Vietlott trả mã vé chính thức.
Clarification questions · 11 nhóm · ~45 câu

Bộ câu hỏi làm rõ gửi Chủ đầu tư

Mỗi câu có mã tham chiếu để bên kia trả lời truy vết được. Ưu tiên: Chặn không trả lời thì không chào giá nghiêm túc · Quan trọng · Cần làm rõ

01

Phạm vi & ranh giới phần mềm/hạ tầng

Tài liệu tham chiếu “Mục 1.5” ở NFR-SE-03, 6.1, 7.4, 8.4 — nhưng Mục 1.5 không có trong bản nhận được. Toàn bộ báo giá CAPEX/OPEX neo vào nó.

Q-SCOPE-01Cung cấp đầy đủ nội dung Mục 1.5 (ranh giới trách nhiệm phần mềm vs hạ tầng).Chặn
Q-SCOPE-02Ma trận trách nhiệm RACI: hạng mục nào của Nhà thầu, hạng mục nào của bên hạ tầng (DC, HSM, NGFW/WAF/anti-DDoS, mạng, OS/DB license).Chặn
Q-SCOPE-03HSM (FIPS 140-2 L3) do hạ tầng cung cấp — xác nhận. Nhà thầu có môi trường tích hợp HSM từ giai đoạn phát triển?Quan trọng
Q-SCOPE-04DC (PDC+DRC, Tier III) do ai cung cấp/quản lý? Quyền truy cập triển khai của Nhà thầu ở mức nào?Quan trọng
Q-SCOPE-05License OS/DB/middleware (NFR-MA-01) do Nhà thầu chào hay hạ tầng cung cấp?Quan trọng
Q-SCOPE-06Sau triển khai, Nhà thầu vận hành hay bàn giao cho đội Chủ đầu tư? SOC 24/7 do ai chủ trì?Quan trọng
02

Tích hợp hệ thống lõi Vietlott

API contract chỉ chốt ở thiết kế chi tiết sau NDA (Phần 5). Đây là rủi ro & phụ thuộc số 1, nằm ngoài tầm kiểm soát phần mềm.

Q-CORE-01API lõi Vietlott hiện tồn tại ở mức nào (đặc tả, OpenAPI, sandbox)? Hay sẽ xây mới trong dự án này?Chặn
Q-CORE-02Ký NDA để tiếp cận spec là trước hay sau khi nộp đề xuất? Nếu sau, Nhà thầu cam kết dựa trên giả định nào?Chặn
Q-CORE-03Ai chịu trách nhiệm uptime/latency API lõi? Vietlott có cam kết SLA cho API không?Chặn
Q-CORE-04Latency thực tế của API phát hành vé? (NFR-PE-06 loại trừ độ trễ hệ thống ngoài — cần con số để cam kết phần mình.)Chặn
Q-CORE-05Idempotency phía lõi: gọi lại do timeout, lõi có chống phát hành trùng, hay trách nhiệm thuộc Nhà thầu?Quan trọng
Q-CORE-06Ngữ nghĩa lỗi Ticket Submission (INT-01): quy tắc reconcile khi lõi nhận đơn nhưng phản hồi thất bại?Quan trọng
Q-CORE-07Draw Results (INT-02): WebSocket hay Webhook? Tần suất, định dạng, cơ chế replay khi mất kết nối?Quan trọng
Q-CORE-08Reconciliation (INT-04, T+1): định dạng, kênh, bên nào là nguồn sự thật khi lệch?Quan trọng
Q-CORE-09Có sandbox lõi để kiểm thử đầu-cuối trước nghiệm thu? Nếu không, kiểm thử tải đỉnh Keno thế nào?Chặn
03

Năng lực tải, Keno & hiệu năng

Mâu thuẫn: auto-scaling “trong 30 phút” (NFR-PE-03) không xử lý được spike lặp mỗi ~5 phút của Keno (288 kỳ/ngày).

Q-PERF-01Chấp nhận pre-provision theo lịch quay thay cho auto-scaling phản ứng tại spike chuyển kỳ? Nghiệm thu đo thế nào?Quan trọng
Q-PERF-02“≥ 2.000 giao dịch/giây” gồm loại nào (mua vé, tra cứu, callback)? Đo tại lớp nào?Quan trọng
Q-PERF-03Keno chạy 24/7 hay khung giờ giới hạn? Phân bố kỳ theo giờ ảnh hưởng trực tiếp định cỡ.Quan trọng
Q-PERF-04100.000 phiên đỉnh là tổng hệ thống hay riêng lúc đóng kỳ Keno? Tỷ lệ phiên mua vé / xem?Cần làm rõ
Q-PERF-05Có dữ liệu tải lịch sử kênh hiện hành (3,7M tài khoản) để hiệu chỉnh mô hình tải?Cần làm rõ
04

Định danh điện tử (VNeID / eKYC)

Q-ID-01Tích hợp VNeID mức 2 (INT-05): phương thức đã được Bộ Công an phê duyệt cho mô hình này chưa? Qua cổng nào?Chặn
Q-ID-02Chi phí gọi VNeID / CSDL dân cư do ai chịu? Có tính vào OPEX Nhà thầu?Quan trọng
Q-ID-03Nhà cung cấp eKYC (Face Match + Liveness) do Chủ đầu tư chỉ định hay Nhà thầu đề xuất? Đã có đối tác?Quan trọng
Q-ID-04Hành vi khi VNeID/CSDL gián đoạn: hạ cấp xác thực, từ chối, hay hàng đợi?Cần làm rõ
05

Thanh toán

Q-PAY-01FR-PM-01 nhắc “danh mục đối tác do Chủ đầu tư cung cấp” — đề nghị danh sách cụ thể ví/ngân hàng/cổng tối thiểu.Chặn
Q-PAY-02“Không trực tiếp giữ tiền”: tạm giữ (FR-PA-04) & settlement qua tổ chức nào? Mô hình escrow/tài khoản chuyên dùng?Quan trọng
Q-PAY-03Chi trả thưởng (FR-PA-05) qua kênh nào? Ai chịu phí giao dịch chi trả?Quan trọng
Q-PAY-04PCI-DSS luồng thẻ (FR-PM-03): Nhà thầu chịu phạm vi PCI nào, hay ủy thác toàn bộ cho cổng đã đạt PCI?Quan trọng
06

AML/CFT & báo cáo nhà nước

INT-06/07/08 “theo phương thức cơ quan có thẩm quyền phê duyệt tại từng thời điểm” — phụ thuộc bên thứ ba, critical path tiến độ.

Q-RPT-01Kênh báo cáo STR/CTR tới Cục PCRT–NHNN (INT-06) đã có đặc tả/đầu nối sẵn chưa, hay xây mới?Quan trọng
Q-RPT-02eTax (INT-07) khai/nộp thuế TNCN trúng thưởng: đã có spec API áp dụng được cho mô hình này?Quan trọng
Q-RPT-03Định dạng/kênh báo cáo định kỳ Bộ Tài chính (INT-08) đã có mẫu chưa?Cần làm rõ
Q-RPT-04Bên nào xin phê duyệt với các cơ quan này — Nhà thầu hay Chủ đầu tư? Quyết định rủi ro tiến độ.Chặn
07

Blockchain / VBSN

Q-BC-01VBSN là bắt buộc, hay Nhà thầu được đề xuất nền tảng permissioned khác “do Việt Nam vận hành”?Quan trọng
Q-BC-02Ai vận hành các nút (đồng thuận, observer của cơ quan quản lý)? Cơ quan quản lý đã xác nhận yêu cầu giám sát cụ thể?Quan trọng
Q-BC-03Ghi hash lên chain nằm trên critical path phát hành vé (đồng bộ) hay ghi bất đồng bộ? (Ảnh hưởng mục tiêu < 3s.)Quan trọng
Q-BC-04Smart contract (≥05, FR-BC-03) có yêu cầu audit bên thứ ba? Ai chịu chi phí?Cần làm rõ
Q-BC-05Chi phí vận hành chain tính CAPEX hay OPEX, do ai chịu?Cần làm rõ
08

An toàn thông tin & tuân thủ

Q-SEC-01Đánh giá An toàn HTTT Cấp độ 3 (NĐ 85/2016): ai chủ trì hồ sơ, làm việc với Bộ Công an, timeline? Ma trận tiêu chí phân chia lớp ứng dụng/dữ liệu.Quan trọng
Q-SEC-02Pen-test & SAST/DAST: Nhà thầu tự làm hay bắt buộc bên giám định độc lập do Chủ đầu tư chỉ định? Ai chịu phí?Quan trọng
Q-SEC-03Lưu trữ ≥5 năm (NFR-SE-05): chi phí lưu trữ dài hạn thuộc Nhà thầu hay hạ tầng?Cần làm rõ
09

Pháp lý & tiền đề kinh doanh

Q-LEGAL-01Chủ đầu tư đã có giấy phép / cơ sở pháp lý phân phối Vietlott qua Internet chưa, hay đang xin phê duyệt?Chặn
Q-LEGAL-02Đề án phân phối qua Internet đã được phê duyệt chính thức chưa? Tình trạng hiện tại?Chặn
Q-LEGAL-03Đã có thỏa thuận kết nối với Vietlott chưa? Là tiền đề cho mọi cam kết tích hợp.Chặn
10

Thương mại & hợp đồng

Q-COM-01Khung ngân sách (hoặc khoảng) cho phần mềm? Giúp định cỡ giải pháp thay vì over/under-engineer.Quan trọng
Q-COM-02Kỳ vọng timeline triển khai và cột mốc go-live bắt buộc?Quan trọng
Q-COM-03“Toàn bộ thời hạn hợp đồng” cho bảo hành/hỗ trợ (NFR-MA-01, 7.4) là bao nhiêu năm?Quan trọng
Q-COM-04Mô hình thanh toán theo milestone và điều kiện nghiệm thu từng đợt?Cần làm rõ
Q-COM-05Cơ chế phạt/khấu trừ SLA — có loại trừ phần phụ thuộc hệ thống ngoài?Quan trọng
Q-COM-06Tiêu chí & trọng số chấm điểm (kỹ thuật vs tài chính vs năng lực)?Cần làm rõ
Q-COM-07IP & phạm vi cấp quyền (7.3): mã nguồn thuộc về ai sau bàn giao?Cần làm rõ
11

Quy trình nộp đề xuất

Q-PROC-01Hạn nộp, định dạng nộp, đầu mối liên hệ kỹ thuật?Quan trọng
Q-PROC-02Có cửa sổ Q&A chính thức / hội nghị tiền đấu thầu? Hạn gửi câu hỏi?Cần làm rõ
Q-PROC-03Có yêu cầu POC/demo trong vòng đánh giá? Phạm vi & môi trường?Cần làm rõ
Q-PROC-04Quy trình ký NDA tiếp cận spec lõi Vietlott bắt đầu khi nào? (liên kết Q-CORE-02)Quan trọng
Mục 6.1 RFP · checklist theo phiên bản hiện hành

Checklist các tiêu chuẩn cần tuân thủ

Mỗi mục được rút gọn thành checklist hành động và ánh xạ về mã yêu cầu RFP (FR-/NFR-). Nguồn dẫn chứng nằm cuối mỗi tab. Phiên bản đã kiểm tra tại 06/2026.

WLA Security Control Standard 2024

Chuẩn an ninh duy nhất được công nhận quốc tế cho ngành xổ số. Gồm 4 phụ lục: G (tổ chức — bao hàm ISO/IEC 27001 + ~30 control WLA), L (vận hành trò chơi — 62 control), S (phát triển hệ thống — 21 control), M (trò chơi đa khu vực — 11 control). Chứng nhận hiệu lực 3 năm; Level 2 đòi hỏi đồng thời chứng nhận ISO/IEC 27001.

© WLA 2024 · phát hành 10/2024, v1.2 · Level 2 = bậc cao nhất
  • ✓Vận hành ISMS đạt ISO/IEC 27001 với phạm vi bao trùm mọi hoạt động liên quan trò chơi (điều kiện Level 2).↳ NFR-SE-01 · FR-VL-*
  • ✓Section RNG riêng (mới ở 2024): bảo đảm tính ngẫu nhiên, không đoán trước, chống can thiệp cho bộ sinh số — áp dụng cho Quick Pick.↳ FR-VE-02 (chọn nhanh ngẫu nhiên)
  • ✓Tách biệt hệ thống vận hành trò chơi (CGS) và hệ thống kiểm soát nội bộ (ICS); IDS/IPS trên cả hai mạng.↳ NFR-SC-01 · NFR-SE-06
  • ✓Toàn vẹn vòng đời vé & quy trình mở thưởng theo quy định; đối soát kết quả khớp lõi.↳ FR-VE-01/08 · FR-VL-02
  • ✓Định danh người chơi & ví là tài sản trọng yếu; kiểm soát rủi ro gian lận và rửa tiền.↳ FR-PA-* · FR-AM-*
  • ✓Kiểm soát an ninh nhà cung cấp & managed services / cloud (trọng tâm mới của 2024).↳ NFR-SC-02 · Q-SCOPE-02
  • ✓Kiểm thử an ninh (thay cho SAST/DAST cứng nhắc) phản ánh cách hệ thống triển khai thực tế; intrusion testing định kỳ.↳ NFR-SE-06
  • ✓Đánh giá bởi auditor thuộc ASE được WLA công nhận (vd GLI); kế hoạch lộ trình chứng nhận 3 năm.↳ chiến lược chứng nhận, Phần 8.3
  • ✓Lộ trình chuyển đổi: chứng nhận mới theo 2024 từ 30/04/2025; áp dụng đầy đủ đến 31/10/2026.↳ mốc lập kế hoạch

Nguồn dẫn chứng

  • WLA-SCS:2024 Standard (EN), © WLA 2024, phát hành 10/2024 — publications.world-lotteries.org
  • Cấu trúc 4 phụ lục G/L/S/M & điều kiện ISMS Level 2 — WLA-SCS:2024 Standard PDF, world-lotteries.org
  • Lộ trình chuyển đổi (30/04/2025 → 31/10/2026), section RNG & managed services — WLA-SCS:2024 Briefing, world-lotteries.org
  • Hiệu lực chứng nhận 3 năm & Level 1/2 — Guide to Certification for the WLA-SCS, world-lotteries.org

ISO/IEC 27001:2022 + 27017 + 27018

27001:2022 có 93 control trong 4 nhóm: Tổ chức (37, A.5), Con người (8, A.6), Vật lý (14, A.7), Công nghệ (34, A.8) — kèm 11 control mới. 27017 bổ sung hướng dẫn cloud (37 control 27002 + 7 control cloud riêng). 27018 bảo vệ PII trên public cloud (bản 2025 đã đồng bộ 27002:2022). Bản 27001:2013 đã hết hiệu lực từ 31/10/2025.

ISO/IEC 27001:2022 · 27017:2015 · 27018:2025 — chỉ chọn control phù hợp rủi ro, ghi trong SoA
  • ✓Thiết lập ISMS (Clause 4–10) + Statement of Applicability (SoA) nêu rõ control áp dụng & lý do loại trừ.↳ nền tảng cho NFR-SE-01 & WLA L2
  • ✓11 control mới của 2022 cần soi kỹ cho dự án này: 5.7 Threat intelligence · 5.23 An ninh dịch vụ cloud · 5.30 ICT readiness cho BC · 8.9 Configuration mgmt · 8.10 Information deletion · 8.11 Data masking · 8.12 DLP · 8.16 Monitoring · 8.23 Web filtering · 8.28 Secure coding.↳ NFR-SE-02/04/06 · NFR-AV-* · NFR-MA-03
  • ✓Nhóm Công nghệ (A.8): mã hóa, xác thực mạnh, kiểm soát truy cập, an ninh mạng — khớp mã hóa AES-256 / TLS 1.3.↳ NFR-SE-02/04
  • ✓8.28 Secure coding + 8.25 SDLC an toàn: quét SAST/DAST trong CI/CD, review trước release.↳ NFR-SE-06
  • ✓8.11 Data masking + 8.12 DLP cho dữ liệu nhạy cảm (CCCD, SĐT); 8.10 xóa dữ liệu theo vòng đời.↳ NFR-SE-02 (field-level) · Luật BVDLCN 91/2025
  • ✓27017 — 7 control cloud riêng: CLD.6.3.1 phân vai trò dùng chung, CLD.8.1.5 thu hồi tài sản khách hàng, CLD.9.5.1 phân tách trong môi trường ảo hóa.↳ NFR-SC-02 (cloud auto-scaling) · Q-SCOPE-02
  • ✓27018 — nguyên tắc PII processor: đồng thuận, minh bạch, tối thiểu hóa dữ liệu, không dùng PII cho mục đích riêng khi chưa được đồng ý.↳ FR-BC-04 (không ghi PII on-chain) · NĐ 356/2025
  • ✓5.30 ICT readiness for business continuity: hỗ trợ trực tiếp mục tiêu RTO/RPO & thiết kế PDC/DRC.↳ NFR-AV-01/02/03

Nguồn dẫn chứng

  • 93 control / 4 nhóm (37·8·14·34) & 11 control mới — hightable.io, secureframe.com, sprinto.com (tổng hợp ISO/IEC 27001:2022)
  • Bản 27001:2013 hết hiệu lực 31/10/2025 — sprinto.com
  • 27017: 37 control 27002 + 7 control cloud (CLD.6.3.1 / 8.1.5 / 9.5.1) — grcsolutions.io
  • 27018:2025 đồng bộ 27002:2022, nguyên tắc PII — iso.org/standard/27018

OWASP Top 10:2025

Bản mới nhất (công bố 11/2025, bản chính thức 01/2026) — thay thế bản 2021. Hai hạng mục mới: A03 Software Supply Chain Failures và A10 Mishandling of Exceptional Conditions; SSRF gộp vào A01. Là chuẩn bảo mật ứng dụng tham chiếu cho NFR-SE và kiểm thử nghiệm thu.

OWASP Top 10:2025 · 248 CWE / 10 hạng mục
  • A01Broken Access Control (giữ #1, nay gồm BOLA/BFLA của API; SSRF gộp vào đây): kiểm soát truy cập chặt trên mọi endpoint; mỗi thiết bị 1 tài khoản; tài khoản thanh toán trùng chủ.↳ FR-PA-03 · NFR-SE-04 (RBAC, OAuth2+JWT)
  • A02Security Misconfiguration (tăng từ #5 lên #2): hardening, gỡ tài khoản/endpoint mặc định, rà IaC & quyền cloud; header an toàn.↳ NFR-SE-04 · NFR-SC-02
  • A03Software Supply Chain Failures (mới): kiểm soát dependency, build system, SBOM, verify gói trước cài; ký artifact.↳ NFR-MA-01/02 (bản quyền & phiên bản)
  • A04Cryptographic Failures: AES-256 lưu trữ, TLS 1.3 truyền, field-level cho CCCD/SĐT; khóa quản lý bằng HSM.↳ NFR-SE-02/03
  • A05Injection: parameterized query (Prisma), validate đầu vào, ORM an toàn, chống XSS.↳ NFR-SE-06
  • A06Insecure Design: threat modeling cho luồng mua/phát hành vé & idempotency; secure-by-design.↳ FR-VE-05 · INT-01
  • A07Authentication Failures (đổi tên): MFA cho quản trị, chống brute-force, quản lý phiên cross-device an toàn.↳ NFR-SE-04 · NFR-MA-04
  • A08Software or Data Integrity Failures: verify tính toàn vẹn cập nhật & pipeline; chống tamper payment-page (đồng bộ PCI 6.4.3).↳ FR-PM-03 · FR-BC-01
  • A09Security Logging & Alerting Failures (đổi tên — nhấn alerting): log + alert sự kiện then chốt; tích hợp SIEM/SOC; lưu vết bất biến.↳ NFR-SE-06 · FR-AM-06
  • A10Mishandling of Exceptional Conditions (mới): xử lý lỗi an toàn, không fail-open; quan trọng cho timeout phát hành vé & hoàn tiền tự động.↳ FR-VE-09 · T-R

Nguồn dẫn chứng

  • Danh sách & thứ tự 2025 chính thức — owasp.org/Top10/2025
  • Hai hạng mục mới (A03, A10), SSRF gộp vào A01, đổi tên A07/A09 — owasp.org/Top10/2025 Introduction; gitlab.com; aikido.dev
  • Mốc công bố 11/2025 → bản chính thức 01/2026, 248 CWE — parasoft.com

PCI DSS v4.0.1 — luồng thẻ

Bản hiện hành duy nhất (phát hành 11/06/2024; v4.0 hết hiệu lực 31/12/2024). Toàn bộ yêu cầu “future-dated” đã bắt buộc từ 31/03/2025. 12 yêu cầu chính trong 6 nhóm mục tiêu. Chỉ áp dụng cho luồng thẻ — phần nền tảng không giữ tiền nên nên thu hẹp phạm vi CDE tối đa.

PCI DSS v4.0.1 · áp dụng cho luồng thẻ (FR-PM-03) · ưu tiên thu hẹp CDE
  • 1·2Mạng & cấu hình an toàn: network security controls (rà ≥6 tháng/lần); cấu hình an toàn mọi thành phần, gỡ mặc định.↳ NFR-SE-04 (DMZ/Internal, NGFW)
  • 3·4Bảo vệ dữ liệu tài khoản: không lưu dữ liệu thẻ nhạy cảm; mã hóa mạnh khi truyền qua mạng công cộng; token hóa.↳ FR-PM-03 (không lưu thẻ, 3-D Secure)
  • 5·6Quản lý lỗ hổng: chống mã độc; phát triển/duy trì phần mềm an toàn; review code trước production; 6.4.3 kiểm soát & toàn vẹn script trang thanh toán (chống e-skimming/Magecart).↳ FR-PM-03 · NFR-SE-06 · OWASP A08
  • 7·8·9Kiểm soát truy cập mạnh: theo need-to-know; MFA cho mọi truy cập CDE; mật khẩu ≥12 ký tự; hạn chế truy cập vật lý.↳ NFR-SE-04 (RBAC+MFA) · OWASP A07
  • 10·11Giám sát & kiểm thử: log + giám sát mọi truy cập; 11.6.1 phát hiện thay đổi/tamper trang thanh toán; quét lỗ hổng nội bộ có xác thực; pen-test định kỳ.↳ NFR-SE-06 · SLA-03
  • 12Chính sách: chương trình an ninh thông tin; rà phạm vi CDE; 12.8/12.9 quản lý quan hệ với bên cung cấp thanh toán (TPSP) & phân chia trách nhiệm rõ ràng.↳ Q-PAY-02/04 · INT-09
  • ★Chiến lược thu hẹp phạm vi: ủy thác luồng thẻ cho cổng đã đạt PCI (iframe/redirect), nền tảng giảm tối đa CDE → giảm gánh nặng chứng nhận. Cần chốt qua Q-PAY-04.↳ khuyến nghị kiến trúc

Nguồn dẫn chứng

  • v4.0.1 là bản hiện hành, phát hành 11/06/2024; v4.0 hết hiệu lực 31/12/2024 — secureframe.com (PCI DSS v4.0.1)
  • Future-dated bắt buộc từ 31/03/2025; MFA toàn CDE, mật khẩu ≥12 ký tự — securetrust.com; fortra.com
  • 6.4.3 & 11.6.1 (script trang thanh toán, chống e-skimming) — securetrust.com
  • 12 yêu cầu / Requirements & Testing Procedures v4.0.1 — pcisecuritystandards.org
Lưu ý dùng checklist: đây là bản rút gọn để định hướng phạm vi tuân thủ, không thay thế văn bản chuẩn gốc. ISO 27001/27017/27018 và PCI-DSS là tài liệu có bản quyền — khi triển khai cần đối chiếu trực tiếp văn bản chính thức và làm việc với auditor/QSA được công nhận.
Đề xuất kỹ thuật · API-first · microservices

Giải pháp kiến trúc theo mô hình Microservice

Nguyên tắc: mỗi cấu phần nâng cấp độc lập (NFR-SC-01), tích hợp mở (NFR-SC-03), lõi Vietlott là hệ thống ngoài được “khóa”, blockchain là lớp nền lưu vết bất biến. Phần Keno tần suất cao tách thành đường xử lý riêng để pre-provision theo lịch quay.

① KÊNH NGƯỜI CHƠI Web responsive iOS / Android PWA SDK ví điện tử ② BIÊN · DMZ API Gateway · WAF · Anti-DDoS · BFF · OAuth 2.0 / JWT ③ MIỀN NGHIỆP VỤ · MICROSERVICES (mỗi service 1 DB) PAM & Định danheKYC · VNeID · 3 cấp Đơn hàng & VéT0–T5 · idempotency Keno Engine (riêng)288 kỳ · pre-provision Payment Hubđa kênh · refund AML/CFT Engine3 tầng · STR/CTR AI Risk & Fraudgraph · risk scoring Chơi trách nhiệmlimit · self-exclusion Notificationpush · SMS · email Loyalty · CRM · BigDatagamification · insight ④ DỮ LIỆU & SỰ KIỆN PostgreSQL (per-service) · Redis (lock/cache) · Kafka (event bus) · Object storage ⑤ LỚP NỀN · LƯU VẾT BẤT BIẾN Blockchain cấp phép (VBSN) · chỉ hash/tham chiếu, không PII ≥5 smart contract · observer node cơ quan quản lý · cổng kiểm toán ⑥ TÍCH HỢP NGOÀI 🔒 Hệ thống lõi Vietlott mTLS + HMAC-SHA256 · phát hành vé VNeID · CSDL dân cư (mức 2) Đối tác thanh toán (NHNN cấp phép) NHNN · Cục Thuế · Bộ Tài chính ⑦ XUYÊN SUỐT HSM · SIEM/SOC 24/7 Observability · Secrets · CI/CD + SAST/DAST
API-first · NFR-SC-01/02/03 · lõi Vietlott & cơ quan nhà nước là hệ thống ngoài; Keno tách đường riêng để xử lý spike chuyển kỳ.
Microservice nội bộ Cổng / hạ tầng kỹ thuật Hệ thống ngoài Lõi Vietlott / blockchain
VÌ SAO TÁCH KENO

Đường xử lý tần suất cao riêng

Tách Keno Engine khỏi service vé thường giúp pre-provision theo lịch quay, cô lập tài nguyên lúc chuyển kỳ, và không kéo các luồng khác sập theo khi có spike.

VÌ SAO BLOCKCHAIN Ở ĐÁY

Lớp nền, không phải tính năng

Mọi service ghi hash/tham chiếu sau khi xác nhận (bất đồng bộ, không chặn phát hành <3s). Observer node cho cơ quan quản lý truy vấn độc lập. Không PII on-chain.

VÌ SAO API-FIRST

Thêm sản phẩm không xây lại

Mỗi điểm tích hợp có API spec + versioning + sandbox (INT-10). Thêm sản phẩm/kênh/đối tác mới chỉ là thêm adapter, không đụng lõi.

Engine AML/CFT 3 tầng

FR-AM-01 — chặn đồng bộ trước phát hành, gắn cờ song song, phân tích chiều sâu theo lô.

Tầng 1 · CHẶN thời gian thực đồng bộ · trước phát hành vé Tầng 2 · GẮN CỜ song song · không chặn Tầng 3 · PHÂN TÍCH SÂU theo lô · graph + ML STR (Điều 26) · CTR (Điều 25) · Luật PCRT 14/2022/QH15 · QĐ 11/2023/QĐ-TTg
FR-AM-01→06 · báo cáo tự động lên Cục PCRT–NHNN qua kênh có chữ ký số (INT-06).

Công nghệ đề xuất

BACKEND & DỮ LIỆU
NestJS (TypeScript)PostgreSQLPrismaRedisApache KafkaDocker / K8s

Lõi service trên NestJS + PostgreSQL + Prisma + Redis. Riêng Keno Engine nên cân nhắc ngôn ngữ biên dịch (Go/Rust/Java) cho đường chốt sổ tần suất cao — cần xác nhận sau khi có latency API lõi (Q-CORE-04).

HẠ TẦNG & AN NINH
Kubernetes auto-scalingHSM (hạ tầng)NGFW · WAFSIEM/SOCmTLS · HMACVBSN

Triển khai tại VN (NĐ 53/2022), PDC + DRC đồng bộ thời gian thực. HSM & thiết bị an ninh thuộc bên hạ tầng (chờ Mục 1.5 — Q-SCOPE-01/03).

Ước tính lập kế hoạch · chỉ phần mềm

Dự tính nỗ lực · thời gian · chi phí

Đây là ước tính order-of-magnitude để lập kế hoạch, không phải báo giá. Mọi con số phụ thuộc nặng vào các câu hỏi Chặn chưa được trả lời (đặc biệt API lõi Vietlott & tiền đề pháp lý). Không bao gồm hạ tầng vật lý & phần cứng (Mục 1.5).

Điều kiện then chốt: nếu API lõi Vietlott phải xây mới, hoặc tiền đề pháp lý chưa xong (Q-LEGAL-01/02/03), tiến độ & chi phí có thể lệch đáng kể so với khung dưới đây. Khung này giả định lõi Vietlott đã sẵn sàng và có sandbox.

Lộ trình theo giai đoạn

Tổng ~14–18 tháng tới go-live, theo cách tiếp cận thận trọng cho hệ thống chịu giám sát nhà nước.

PHASE 0
~2–3 tháng

Khởi tạo & thiết kế chi tiết

  • NDA, chốt API contract lõi Vietlott, thiết kế chi tiết & ADL
  • Baseline an ninh, chuẩn bị hồ sơ Cấp độ 3, lập SoA (ISO 27001)
  • Dựng môi trường, CI/CD + SAST/DAST, IaC
PHASE 1
~4 tháng

Nền tảng lõi (MVP jackpot)

  • PAM & eKYC/VNeID, vòng đời vé T0–T5, idempotency
  • Payment Hub đa kênh, tích hợp lõi Vietlott (Ticket Submission)
  • Web + mobile cơ bản, thông báo
PHASE 2
~3 tháng

Keno tần suất cao + tuân thủ

  • Keno Engine, pre-provision theo lịch quay, đối soát kết quả
  • AML/CFT 3 tầng + STR/CTR, Chơi có trách nhiệm
  • Đối soát T+1, báo cáo NHNN/Thuế/Bộ Tài chính (khung)
PHASE 3
~3 tháng

Blockchain + AI

  • Lớp lưu vết VBSN, ≥5 smart contract, observer/cổng kiểm toán
  • AI risk scoring, phát hiện gian lận, AI attestation on-chain
PHASE 4
~3 tháng

Hardening · kiểm định · go-live

  • Loyalty/CRM/BigData; tối ưu hiệu năng
  • Pen-test, đánh giá Cấp độ 3, load test (100k phiên / 2.000 TPS / Keno)
  • UAT, đào tạo, pilot → go-live + ổn định hóa

Phân bổ nỗ lực theo cấu phần

Tỷ trọng tương đối (định hướng) — phần tuân thủ & tích hợp chiếm tỷ trọng lớn bất thường so với app thương mại thông thường.

Tích hợp lõi + nhà nước
~20%
PAM / eKYC / Payment
~16%
Vé + Keno Engine
~15%
AML/CFT + AI
~13%
An ninh + Cấp độ 3 + kiểm thử
~14%
Blockchain + smart contract
~9%
Loyalty/CRM/BigData + Frontend
~13%

Đội ngũ & khối lượng (định hướng)

Vai tròQuy mô đỉnhPerson-months (≈)
Solution / Security Architect228
Backend (NestJS) + Keno Engine8–10150
Frontend (Web/Mobile/PWA)4–570
Tích hợp (lõi, VNeID, payment, nhà nước)3–460
Blockchain / smart contract2–334
AI / Data2–334
DevOps / SRE2–340
QA / Security testing3–455
PM / BA / tuân thủ345
Tổng nỗ lực phần mềm (định hướng)≈ 480–520 PM

Khung chi phí phần mềm (CAPEX/OPEX)

Khoảng tham chiếu, USD — cần tinh chỉnh sau khi có câu trả lời các câu Chặn. Không gồm hạ tầng vật lý/phần cứng (Mục 1.5).

Hạng mụcLoạiKhoảng (USD)
Phát triển + tích hợp (build)CAPEX2,4M – 3,6M
Kiểm thử, kiểm định độc lập, Cấp độ 3, pen-testCAPEX280K – 520K
Blockchain (smart contract + audit + tích hợp VBSN)CAPEX220K – 420K
License phần mềm thương mại (nếu thuộc Nhà thầu)CAPEX/OPEXcần Q-SCOPE-05
Đào tạo & chuyển giaoCAPEX80K – 150K
Bảo hành / hỗ trợ / cập nhật phần mềm (/năm)OPEX18–22% giá build/năm
Vận hành SOC 24/7 + cập nhật tuân thủ (/năm)OPEXcần Q-SCOPE-06
Tổng CAPEX phần mềm (định hướng)≈ 3,0M – 5,1M USD
Đọc khung này thế nào: các con số là biên độ rộng có chủ đích vì nhiều biến số còn mở. Khi Q-CORE-* (API lõi) và Q-LEGAL-* (pháp lý) được trả lời, biên độ sẽ thu hẹp nhanh. Phần OPEX bảo trì gắn với độ dài hợp đồng (Q-COM-03) — chưa có thì chưa khóa được tổng chi phí vòng đời. Đây là thông tin tham khảo để hoạch định, không phải tư vấn tài chính hay báo giá ràng buộc.

VIETLOTT INTERNET DISTRIBUTION · DOSSIER NỘI BỘ v1.0 · 06/2026

Tài liệu tổng hợp phục vụ phân tích & chuẩn bị đề xuất. Tiêu chuẩn tham chiếu: WLA-SCS:2024 · ISO/IEC 27001:2022, 27017:2015, 27018:2025 · OWASP Top 10:2025 · PCI DSS v4.0.1. Các ước tính nỗ lực/chi phí là định hướng lập kế hoạch, không phải báo giá ràng buộc.