หัวข้อหารือ: ยกระดับความปลอดภัย SuperApp
วาระหารือเต็ม — ดัชนีเอกสารทั้งชุด 17 ไฟล์ + สรุปสถานะ "มีเครื่องมือแล้วแต่สวิตช์ปิดอยู่" ก่อนลงรายละเอียดแต่ละหมวด
อัปเดต: 2026-07-07
หัวข้อหารือ: ยกระดับความปลอดภัย SuperApp — จะต้อง Implement อะไรบ้าง
เอกสารนี้คืออะไร: วาระหารือ (discussion topics) สำหรับทีม — รวบรวม “สิ่งที่ต้อง implement เพื่อยกระดับความปลอดภัยของ code” จัดกลุ่มตามหัวข้อที่ทีมเสนอ + เติมส่วนที่หลักฐานจากการ scan ชี้ว่าขาด ทุกหัวข้อมี สถานะจริงวันนี้ / สิ่งที่ต้องทำ / คำถามที่ต้องตัดสินใจในที่ประชุม
วันที่: 7 กรกฎาคม 2026 · สถานะ: Draft รอหารือ
แหล่งข้อมูล: ชุดเอกสาร verified 02/07/2026 (ROADMAP — ผ่าน fact-check 2 รอบ, BASELINE, COMPLIANCE) + design CI scanning (PLAN 01/07 (ยังไม่เผยแพร่)) + Landing Zone HLD + ตัวแทน repo 4 ตัว (Frontend_HostAppSuperApp, Backend_UserService, Backend_SentinelGatewayService, Backend_Iac)
📁 Implementation Plans (เชิงลึกรายหมวด — มี sequence diagram + ระดับไฟล์)
| หมวด | Plan | เนื้อหาหลัก |
|---|---|---|
| 0 | IMPL_PLAN_00_STOP_THE_BLEEDING.md | ถอด credential + rotate flow · ปิด dev-bypass 2 แบบ · ปิด endpoint อันตราย |
| 1 | IMPL_PLAN_01_CI_PIPELINE_SECURITY.md | 5 scanners + regression gates + gate policy ต่อ phase |
| 2 | IMPL_PLAN_02_DATA_IN_TRANSIT.md | ตอบ “FE เอา key จากไหน” · HMAC service-to-service · session-bound key · RSA field encryption |
| 3 | IMPL_PLAN_03_CLIENT_TO_API_EDGE.md | subscription key · เปิด APIM rate limit (SG-20) · validate-jwt ที่ขอบ |
| 4 | IMPL_PLAN_04_AUTHORIZATION_FLOW.md | session TTL · token at-rest · InternalOnly · realm selector · replay |
| 5 | IMPL_PLAN_05_API_SERVICE_HARDENING.md | helper กลาง 5 ตัว + FallbackPolicy rollout ลำดับปลอดภัย |
| 6 | IMPL_PLAN_06_SECRETS_KEY_MANAGEMENT.md | rotate หนี้เก่า · purge history · fail-fast · rotation policy |
| 7 | IMPL_PLAN_07_REDIS_HARDENING.md | token/PII encryption ใน Redis · transport/access · blast radius |
| 8 | IMPL_PLAN_08_PDPA_SENSITIVE_DATA.md | PII inventory (P0-P3) · minimization · masking กลาง · FE audit |
| 9 | IMPL_PLAN_09_INFRA_OBSERVABILITY.md | non-root · NetworkPolicy · ForwardedHeaders · retention/WORM + alerts |
| 10 | IMPL_PLAN_10_FRONTEND_STATIC_CLIENT.md | มุมมอง Angular 21 static บน Cloudflare — subscription key/signature/encryption ฝั่ง client · runtime config · report client rendering · decision D10-1..4 |
| 💰 | COST_PERFORMANCE_TRADEOFFS.md | เงินที่ต้องจ่าย · latency budget (~2-4ms hot path) · trade-off T1-T10 ที่ต้อง sign-off · ของที่แพงเกินคุ้ม ณ ตอนนี้ |
| 📋 | DECISION_REGISTER.md | ทะเบียน decision รวม A1-F3 (แก้เลข D10/D13 ชนกัน) — checklist ที่เดินในห้องประชุม |
| ✅ | MEETING_RESOLUTION_CHECKLIST.md | ใบจดประจำห้อง — 8 วาระ + ช่องข้อสรุป/action items/ประเด็นค้าง + ขั้นตอนปิดประชุม |
| 📄 | MEETING_BRIEF.md | one-pager สำหรับผู้บริหาร — ขอ 3 อย่าง · แผนย่อ · คำตอบคำถามที่คาดว่าจะโดนถาม |
ก่อนเริ่ม — แก้ความเข้าใจ 1 เรื่อง: ระบบเรา “หละหลวม” ตรงไหนกันแน่
จากการ scan ที่ผ่าน fact-check แล้ว ข้อสรุปที่แม่นกว่า “ระบบหละหลวมมาก” คือ:
เครื่องมือป้องกันมีเกือบครบแล้ว แต่ “สวิตช์” หลายตัวยังปิดอยู่ และประตูบางบานเปิดค้างไว้
| มีแล้ว (ของจริง ใช้งานได้) | มีของแต่ปิดอยู่ / ยังไม่ wire | ไม่มีเลย |
|---|---|---|
WAF (Cloudflare + App GW) · APIM session façade · Sentinel OIDC+session store · AesEncryptionService + [Encrypt] · HMAC signature service · Security headers · StrictCORS · FluentValidation · Serilog + [Audit] · Key Vault ทุก service | HMAC validation (comment ปิด) · APIM rate limit (comment ปิด — SG-20) · Token at-rest encryption (code มี key ยังไม่ provision — SG-11) · ApiKeyAuthFilter (บาง service ไม่ register) · JWT validation (โดน dev-bypass ทับบน dev) | CI security scan ทุกชนิด · FallbackPolicy (default-deny) · Partitioned rate limiter ระดับ service · Data classification / PII inventory · Security alerting |
ผลตาม COMPLIANCE: เทียบ API-GL-001 ทั้ง 7 ด้าน = 0/7 ผ่านเต็ม · 6/7 ผ่านบางส่วน · 1/7 ไม่ผ่าน (ด้าน Data Confidentiality — เพราะ secret ค้างใน git)
นัยต่อการหารือ: งานส่วนใหญ่ไม่ใช่ “ซื้อ/สร้างของใหม่” แต่คือ เปิดสวิตช์ + wire ให้ทั่ว + ตั้ง gate กันถอยหลัง — ถูกกว่าและเร็วกว่าที่คิด แต่ต้องทำ ตามลำดับที่ปลอดภัย (บางตัวเปิดผิดลำดับ = ระบบล่มทั้ง platform)
หมวด 0 — ปิดประตูที่เปิดอยู่ก่อน (Prerequisite ของทุกหัวข้อ 1-5)
⚠️ ทำไมต้องมาก่อน: หัวข้อ 1-5 ที่ทีมเสนอเป็น “การเพิ่มชั้นเกราะ” — แต่ถ้าประตูหลังยังเปิด (bypass auth ได้, endpoint anonymous, credential อยู่ใน git) เกราะที่เพิ่มจะไร้ความหมาย ผู้ตรวจ/ผู้โจมตีจะเข้าทางประตูที่เปิดเสมอ
| # | เรื่อง | หลักฐาน (verified 02/07/2026) | งาน |
|---|---|---|---|
| 0.1 | Hardcoded credential ใน source/config 🔴 | Notification DiagnosticsController.cs:144 (password="Exim@2026!" + endpoint [AllowAnonymous]) · ThirdParty appsettings.Production.json:9-11 (ConsumerKey/Secret ค่า prod) | ถอดออก → ย้าย Key Vault → rotate ทันที (ถือว่ารั่วแล้วเพราะอยู่ใน git history) → purge history (BFG/filter-repo) |
| 0.2 | JWT dev-bypass 2 แบบ 🔴 | แบบ A if(isDev) ใน 9 service + Backend_Template (service ใหม่ติดมาฟรี) — active บน dev cluster (ยืนยันแล้ว env=Development) · แบบ B WorkflowService BypassAuthHandler return Admin เสมอ ทุก non-prod · ThirdPartyFXService ไม่มี auth เลยทั้ง repo | แก้ Template ก่อน → guard กลางใน Backend_Package → port JWT จริงให้ WF + ThirdPartyFX (UserService if(false) = แม่แบบที่ถูก) |
| 0.3 | ไม่มี default-deny (FallbackPolicy) + [AllowAnonymous] บน write endpoint 🔴 | grep FallbackPolicy ทั้ง platform = 0 hit · ThirdParty 7 controllers [AllowAnonymous] ระดับ class พร้อม write ops · Consent POST /receipt ไม่มี attribute เลย | AddSuperAppAuthorization helper (FallbackPolicy) + audit [AllowAnonymous] รายตัว — ต้องทำตามลำดับ 5 step ใน ROADMAP §4.2 มิฉะนั้น health probe 401 → pod restart ทั้ง cluster |
| 0.4 | Rate limiting ไม่ทั่วถึง 🟠 | ThirdParty/FileManagement ไม่มีเลย · Consent มีแต่ non-partitioned (self-DoS) · penalty middleware ไม่มี enforcement จริง | Partitioned rate-limit helper ใน Package (key = user sub → API key → forwarded IP, exclude /health) |
คำถามหารือ: ใครเป็น owner ของ Phase 0? กำหนดเสร็จภายในกี่สัปดาห์? การ rotate credential ต้อง coordinate กับใครบ้าง (EXIM token, DGA)?
หมวด 1 — Pipeline CI Security (ตามข้อเสนอ 1.1-1.4 + เสริม)
สถานะจริงวันนี้: pipeline ปัจจุบัน (ci.yml) มีแค่ dotnet test → docker build → push — ไม่มี security scan ใดๆ เลยทั้ง platform · แต่มี design + implementation plan เขียนเสร็จแล้ว ที่ PLAN_SECURITY_SCANNING_CI_INTEGRATION.md (ยังไม่เผยแพร่) (ครอบ Backend_UserService + Frontend_HostAppSuperApp เป็น pilot)
| ข้อเสนอทีม | เครื่องมือตาม design | ตรวจอะไร | สถานะ |
|---|---|---|---|
| 1.1 SonarQube | SonarQube Community (SAST) — deploy บน AKS namespace security | code smell, vulnerability pattern, hardcoded secret ในโค้ด | 📄 design เสร็จ รอ implement |
| 1.2 OWASP | แตกเป็น 2 ตัว: SCA = OWASP Dependency-Track + CycloneDX SBOM (dependency มีช่องโหว่) · DAST = OWASP ZAP (ยิงทดสอบ app ที่รันจริง — Phase 3) | CVE ใน NuGet/npm packages · runtime vulnerability | 📄 SCA design เสร็จ · DAST เคยรัน manual |
| 1.3 Scan Image | Trivy (scan container image ก่อน push ACR) | CVE ใน base image + layers | 📄 design เสร็จ |
| 1.4 Scan Secret | Gitleaks (scan ทุก commit) | secret หลุดเข้า git | 📄 design เสร็จ — ต้องคู่กับ 0.1 purge history |
| (เสริม) 1.5 IaC scan | Checkov | misconfig ใน K8s manifests/Bicep | 📄 design เสร็จ |
| (เสริม) 1.6 Regression gates | custom CI check | fail build ถ้าเจอ: controller ไม่มี [Authorize]/[AllowAnonymous] · pattern if(isDev) bypass · BypassAuthHandler · secret ใหม่ | ❌ ยังไม่มี — สำคัญมาก: กันงานหมวด 0 ไม่ให้ถอยหลัง |
คำถามหารือ:
- Gate policy — เริ่ม non-blocking (รายงานอย่างเดียว) แล้วเปลี่ยนเป็น blocking เมื่อไหร่? เกณฑ์อะไร (เช่น block เฉพาะ Critical/High)?
- SonarQube + Dependency-Track ต้องมีคน host/ดูแลบน AKS — ใคร? (design มี open item: PostgreSQL provisioning, KV secrets, variable group)
- Pilot ที่ UserService + HostApp ก่อน แล้ว rollout ทุก repo — timeline?
- เครื่องมือทั้งหมดผ่านเกณฑ์ compliance ของ ธสน. ไหม (design doc §8 — ยัง pending BOT tool-acceptability)
หมวด 2 — การรับส่งข้อมูล (ตามข้อเสนอ 2.1-2.3 + เสริม)
ข่าวดี: ของที่เสนอ “มีอยู่แล้ว” ใน Backend_Package เกือบทั้งหมด — งานจริงคือเปิดใช้ + บังคับให้ทั่ว
| ข้อเสนอทีม | สถานะจริง | งาน |
|---|---|---|
| 2.1 BodySignature (message-level integrity) | ✅ มี HMAC signature service ใน Package แล้ว — แต่ถูก comment ปิดอยู่ (ThirdParty SecurityExtensions.cs:29-39 + MiddlewarePipelineExtensions.cs:80-81 // app.UseSignatureValidation();) | เปิด validation กลับ + ตัดสินใจ scope: บังคับเฉพาะ external write (ตาม API-GL-001 ข้อ 3.2) หรือทุก write? |
| 2.2 Encryption Field | ✅ มี AesEncryptionService (AES-256-CBC, random IV) + [Encrypt] attribute + MediatR EncryptionBehavior แล้ว — UserService ใช้อยู่ | ทำ data classification ก่อน (หมวด 8) → กำหนดว่า field ไหนบังคับ [Encrypt] → wire ทุก service + CI check |
| 2.3 Parameter Encode | ⚠️ ต้องเคลียร์ความหมายในที่ประชุม — ตีความได้ 3 แบบ (ดูคำถามข้างล่าง) | ขึ้นกับข้อตกลง |
ข้อ 2.3 ตีความได้ 3 แบบ — เลือกในที่ประชุม (ทำได้มากกว่า 1):
- (ก) ห้าม sensitive data ใน URL/query string — เคสจริงที่เจอ: DGA
?ConsumerSecret=(แต่เป็น contract ของ DGA แก้ฝ่ายเดียวไม่ได้ — mitigation คือฝั่ง log ดู ROADMAP §3.1 #4) → ตั้งเป็น กฎทีม + CI check สำหรับ API ของเราเอง - (ข) Encode/escape parameter กัน injection — ฝั่ง SQL ปลอดภัยแล้ว (EF parameterized) · ฝั่ง output encoding Angular ทำให้ default → เหลือ audit จุดที่ bypass framework (raw SQL,
innerHTML,bypassSecurityTrust*) - (ค) Opaque/encoded resource ID กัน IDOR — ไม่ให้ client เดา ID คนอื่น (เช่น sequential int → GUID/encrypted ID) → คู่กับ object-level authorization check (BOLA)
เสริมที่หลักฐานชี้ว่าขาด (in-transit ชั้น infra):
- 🟡 Ingress ไม่มี
tls:block (SG-21) + side-call APIM→service เป็น HTTP ใน cluster ไม่มี mTLS (SG-13) → หารือ: mTLS in-cluster คุ้ม effort ไหม หรือ NetworkPolicy พอก่อน - 🟡 ข้อมูล high-risk พิจารณา JWS/JWE ตามมาตรฐาน (แพงกว่า HMAC — เอาไว้หลัง 2.1 เปิดใช้ได้จริง)
คำถามหารือ: signing key / encryption key ใครถือ + rotate ยังไง (โยงหมวด 6)? · performance cost ของ encrypt/sign ทุก request ยอมรับได้แค่ไหน? · 2.3 เลือกความหมายไหน?
หมวด 3 — Client → API (ตามข้อเสนอ 3.1 + เสริม)
สถานะจริงวันนี้ที่ขอบ (edge): Cloudflare WAF + App GW ✅ · APIM session façade ✅ · แต่ control บน APIM หลายตัว ยังไม่ enforce จริง
| งาน | สถานะ | หมายเหตุ |
|---|---|---|
| 3.1 Subscription key enforcement ที่ APIM (ข้อเสนอทีม) | 🟡 ยังไม่บังคับ | บังคับ per-app/per-client → ได้ identity ของ caller ที่ขอบ + ตัด traffic ไม่รู้ที่มา |
| (เสริม) 3.2 APIM rate limit | 🔴 ถูก comment out อยู่ (SG-20) — ตัวเลข “Bearer 200/60s, Anon 30/60s” เป็น design intent ยังไม่ enforce (QA review M-1) | เปิดกลับ + ยืนยัน scope ครอบทุก route |
| (เสริม) 3.3 JWT pre-validation ที่ APIM | ❌ ตอนนี้ passthrough — malformed/expired ทะลุถึง backend | reject ที่ขอบ ลด load + ลด attack surface |
| (เสริม) 3.4 Payload size validation ที่ APIM | ❌ | คู่กับ RequestSizeLimitMiddleware ที่ backend มีแล้ว |
| (เสริม) 3.5 Verify WAF/DDoS config จริง | ◇ เชื่อตาม HLD ยังไม่เคย verify config | ต้อง audit ก่อนเอาไปตอบผู้ตรวจ |
คำถามหารือ: subscription key แจกระดับไหน (per frontend app / per tenant / per partner)? · ใครเป็นเจ้าของ APIM policy (ทีมไหนแก้ได้)?
หมวด 4 — Authorization Flow (ตามข้อเสนอ 4.1-4.2)
ข่าวดี: flow ที่เสนอ “มีครบแล้ว” — 4.1 IdP Entra → Sentinel ออก cookie (OIDC PKCE S256, token เก็บ server-side ใน Redis ไม่หลุดไป browser) ✅ · 4.2 APIM façade แลก cookie → JWT ✅
งานที่เหลือคือ hardening สิ่งที่มี (จาก COMPLIANCE):
| Gap | หลักฐาน | งาน |
|---|---|---|
| Session TTL ยาวเกิน | 720 ชม. (30 วัน) เมื่อ RememberMe — ขัดหลัก “สั้นเท่าที่จำเป็น” | ตัดสินใจค่า idle/absolute cap (code รองรับแล้ว SG-05 — แค่ยังไม่ตั้งค่า) |
| Token at-rest encryption ยังไม่เปิด | code มีแล้ว (SG-11) — key ยังไม่ provision ใน KV | provision key + เปิดใช้ |
InternalOnly gate ไม่รู้ว่าเปิดจริงไหม | default Enabled=false + ไม่พบ config ใน repo (SG-06) | verify ค่า env จริงใน IaC ทุก env |
| SameSite=None ใน Dev/Sit/Uat | SG-22 | ทบทวนต่อ env |
| Realm selection ตอนไม่มี Origin header | dual-cookie เลือก realm แรกเสมอ (ตกค้างจาก V-001) | fix selector + ?tenant= |
| Replay protection สำหรับ high-risk ops | มีแค่ JWT lifetime — ไม่มี nonce/one-time token | ประเมินว่า API-GL-001 §7(2) ต้องการแค่ไหน |
คำถามหารือ: session TTL target = เท่าไหร่ (เช่น idle 30 นาที / absolute 8-24 ชม.)? กระทบ UX มือถือแค่ไหน?
หมวด 5 — API Service Hardening (ตามข้อเสนอ 5.1-5.2)
| ข้อเสนอทีม | สถานะจริง | งาน |
|---|---|---|
| 5.1 JWT validation ยืนยันกับ Entra IdP | ✅ กลไกมีครบ (ValidateIssuer/Audience/Lifetime/SigningKey + JWKS จาก .well-known, multi-issuer CIAM+Entra) — แต่ถูก dev-bypass ทับ (หมวด 0.2) · UserService = ตัวอย่างที่ปิด bypass แล้ว | = งานหมวด 0.2 นั่นเอง — ปิด bypass ทุก service ผ่าน guard กลาง, JWT validation ที่มีอยู่จะทำงานเอง |
| 5.2 Middleware Decrypt BodySignature / Encryption Field / Parameter Encode | ชิ้นส่วนมีใน Package แล้ว (หมวด 2) แต่เป็น opt-in — แต่ละ service ต้อง wire เอง = ไม่ทั่วถึง | ทำ helper กลางแบบ “เรียกบรรทัดเดียวได้ครบชุด” ใน Backend_Package + แก้ Backend_Template ให้ default |
หลักการที่เสนอให้ยึด (จาก BASELINE §2) — “Pit of Success”:
Backend_Package (จุดคานงัด) — helper กลาง 5 ตัว:
1. AddSuperAppAuthorization → FallbackPolicy + register ApiKeyAuthFilter + fail-fast ถ้า ApiKeys ว่าง
2. dev-bypass guard กลาง → ผูกกับ flag ที่ไม่มีวัน true บน cluster ใดๆ
3. Partitioned rate limiter → per-client, exclude /health
4. ShowPII default → เปิดเฉพาะ local (ตอนนี้ non-prod ทั้งหมด = SIT/UAT รั่ว PII ใน auth error log)
5. Signature/Encryption enforcement → บังคับ external write
→ แก้ Backend_Template ให้ใช้ helper เหล่านี้เป็น default = service ใหม่ได้ของถูกฟรี
→ CI regression gate (หมวด 1.6) = กันถอยหลัง
คำถามหารือ: ลำดับ rollout ต่อ service (เสนอ: UserService นำร่อง — สะอาดสุด → service อื่นตาม)? ใคร own Backend_Package?
หมวด 6 — Secrets & Key Management (KV) (ทีมเอ่ยถึง — เติมเต็ม)
มีแล้ว: Key Vault ทุก service + CSI driver + Workload Identity ✅
| งาน | ที่มา |
|---|---|
| Rotate secret ที่เคยรั่ว เข้า git ทั้งหมด (ถือว่า compromised) | SG-02a + หมวด 0.1 |
| Purge git history (BFG/filter-repo) — ลบไฟล์ตอนนี้ไม่พอ history ยังอยู่ | SG-02b |
| ลบ demo project ที่มี EncryptionKey จริงค้างใน repo | SG-02c |
| Fail-fast ตอน startup ถ้า config เป็น placeholder/ว่าง (กัน prod รันด้วยค่า dummy เงียบๆ) | SG-19 |
| Key rotation policy (encryption key, HMAC signing key, API keys) + expiry alert | หมวด 2 dependency |
| Audit least-privilege ของ Managed Identity ต่อ KV (ใครอ่าน secret ไหนได้) | B5 trust boundary |
คำถามหารือ: rotation cadence เท่าไหร่? ใช้ KV expiration alert อัตโนมัติไหม (มี skill/tooling อยู่แล้ว)?
หมวด 7 — Redis Hardening (ทีมเอ่ยถึง — เติมเต็ม)
Redis คือหัวใจของ session store (Sentinel) + cache — ถ้า Redis หลุด = session hijack ได้ทั้งระบบ
| งาน | ที่มา |
|---|---|
| PII ใน Redis เป็น plaintext (user cache) → เข้ารหัส at-rest หรือลด field ที่ cache | ROADMAP §3.2 |
| Token at-rest encryption ใน session store — เปิดใช้ (code มีแล้ว) | SG-11 |
| Verify: TLS ต่อ Redis + AUTH/ACL + ไม่ expose public endpoint | ตรวจ IaC |
| Rate-limit state / penalty state เก็บใน Redis (ไม่ใช่ in-memory per-pod) — ถ้าจะทำ escalation จริง | ROADMAP §3.1 #5 (M4) |
หมวด 8 — Sensitive Data / PDPA (ทีมเอ่ยถึง — “PII รับส่งระหว่าง FE/BE เยอะ”)
นี่คือหมวดที่ยังไม่มี systematic control เลย — เริ่มจาก inventory ก่อน ห้ามข้าม:
| ลำดับ | งาน | เหตุผล |
|---|---|---|
| 8.1 | Data classification + PII inventory — ไล่ทุก API contract (FE↔BE): field ไหนคือ PII (บัตร ปชช., เบอร์, ที่อยู่, KYC docs), ไหลผ่านไหน, เก็บที่ไหน, ใครเห็น | ไม่มี inventory = ตัดสินใจ [Encrypt]/mask/minimize ไม่ได้ (หมวด 2.2 รอข้อนี้) |
| 8.2 | Data minimization — API ส่งเฉพาะ field ที่หน้าจอใช้จริง (กัน Excessive Data Exposure ตาม API-GL-001 มาตรา 5) | เคสที่ทีมเจอ: “PII ส่งกันหลายที่” มักเพราะ endpoint คืน entity เต็มก้อน |
| 8.3 | ShowPII=true บน non-prod ทุก service → เปลี่ยนเป็นเปิดเฉพาะ local | ยืนยันแล้วครบทุก service หลัก (มาจาก template) — auth error log บน SIT/UAT อาจรั่ว PII/token |
| 8.4 | Log hygiene — audit log sink ว่าไม่มี PII/OTP/token + masking convention กลาง | หมวด 6 compliance |
| 8.5 | ฝั่ง Frontend — audit: ไม่เก็บ PII/token ใน localStorage/sessionStorage · ไม่ log PII ใน console · mask ในหน้าจอ (เลขบัตร ฯลฯ) | HostApp = ตัวแทน |
| 8.6 | PDPA process — การเรียกเก็บ/ตรวจรับหลักฐานการทำลายข้อมูลจาก third party (guideline V3.0 ข้อ 3.1) + retention policy ต่อ data type | ยังไม่มี process |
คำถามหารือ: ใครเป็น data owner/DPO ฝั่งทีม? · ทำ inventory ด้วย format ไหน (ตารางต่อ endpoint?) · PII ตัวไหนบังคับ encrypt at-rest ตั้งแต่ Phase แรก?
หมวด 9 — สิ่งที่ยังไม่มีใน list ทีม แต่หลักฐานชี้ว่าต้องหารือ
| # | เรื่อง | หลักฐาน | ทำไมสำคัญ |
|---|---|---|---|
| 9.1 | Audit log retention ≥ 90 วัน + tamper-proof (WORM) | SG-25 — ยังไม่ verify | API-GL-001 หมวด 6 บังคับ — ผู้ตรวจถามแน่ |
| 9.2 | Security alerting (brute-force, anomaly, auth failure spike) | SG-26 — ยังไม่มี | มาตรฐานสั่ง “ตรวจจับ แจ้งเตือน ตอบสนอง” |
| 9.3 | Container รันเป็น root | SG-17 | K8s hardening พื้นฐาน — runAsNonRoot + securityContext |
| 9.4 | ไม่มี NetworkPolicy ใน cluster | SG-18 | pod ใดๆ คุยกับ pod ใดก็ได้ = ทะลุ 1 จุดไปได้ทั้ง namespace (โยง B4 trust boundary) |
| 9.5 | ForwardedHeaders รับจากทุก proxy | SG-07 | spoof client IP ได้ → rate limit / audit log เพี้ยน (หมวด 0.4 dependency) |
| 9.6 | Swagger UI บน SIT/UAT | ต้อง confirm การเข้าถึงจากภายนอก | reconnaissance surface |
สรุปภาพรวม — ลำดับที่เสนอ (เอาไว้ถกในที่ประชุม)
จัดตาม leverage และ dependency — ตัวเลขอ้างหมวดในเอกสารนี้:
| Phase | งาน | ทำไมลำดับนี้ |
|---|---|---|
| Phase 0 — ห้ามเลือด (สัปดาห์) | 0.1 ถอด+rotate credential · 0.2 ปิด bypass ที่ Template · ปิด endpoint อันตราย (maintenance toggle, whoami) | รั่วอยู่ตอนนี้ ทุกวันที่ปล่อย = เสี่ยงสะสม |
| Phase 1 — รากฐาน (2-6 สัปดาห์) | helper กลาง 5 ตัว (หมวด 5.2) · port JWT ให้ WF/ThirdPartyFX · FallbackPolicy ตามลำดับปลอดภัย · audit [AllowAnonymous] · partitioned rate limit · เปิด HMAC กลับ (2.1) | ปิด root cause เชิงระบบผ่าน Package — ทำครั้งเดียวทุก service ได้ |
| Phase 2 — เป็นระบบ (1-3 เดือน) | CI scanning ทั้งชุด (หมวด 1) · regression gates (1.6) · APIM hardening (หมวด 3) · ShowPII (8.3) · session TTL (หมวด 4) · KV rotation (หมวด 6) · data classification เริ่ม (8.1) | มีรากฐานแล้วค่อยตั้ง gate กันถอยหลัง + ไล่เก็บ medium |
| Phase 3 — ยั่งยืน (ต่อเนื่อง) | DAST ประจำ · alerting + retention (9.1-9.2) · K8s hardening (9.3-9.5) · PDPA process (8.6) · mTLS/JWE ประเมิน (หมวด 2 เสริม) | compliance ระยะยาว |
จุดที่อยากให้ที่ประชุมเห็นตรงกันที่สุด: ข้อเสนอ 1-5 ของทีมถูกทิศทางทั้งหมด — แต่ CI scanning (หมวด 1) จะจับปัญหาใหม่ ไม่ได้แก้ปัญหาเก่าที่เปิดค้าง และ middleware encrypt/sign (หมวด 2, 5.2) จะไร้ผลถ้า auth ยัง bypass ได้ (หมวด 0) → เสนอให้ Phase 0 + helper กลาง มาก่อน CI/encryption เสมอ
การตัดสินใจที่ต้องได้จากการหารือ (Decision Checklist)
- D1 — approve ลำดับ Phase 0→3 ข้างบน (หรือปรับ)
- D2 — owner ต่อหมวด: Phase 0 (ใคร) · Backend_Package helpers (ใคร) · CI scanning infra (ใคร) · data classification (ใคร)
- D3 — ความหมายของ “Parameter Encode” (2.3): เลือก (ก)/(ข)/(ค) หรือทั้งหมด
- D4 — BodySignature scope (2.1): external write เท่านั้น หรือทุก write
- D5 — Session TTL target (หมวด 4): idle / absolute เท่าไหร่
- D6 — CI gate policy (หมวด 1): non-blocking นานแค่ไหน เกณฑ์ block อะไร
- D7 — Subscription key granularity (3.1): per-app / per-tenant / per-partner
- D8 — รับความเสี่ยง BOT tool-acceptability ของ scanner stack (SonarQube/Trivy/ฯลฯ) — เดินหน้าเลยหรือรอ confirm
- D9 — งบ/คนสำหรับ host SonarQube + Dependency-Track บน AKS (PostgreSQL, storage, ดูแลต่อเนื่อง)
อ้างอิง
- SECURITY_MASTER_PLAN_DEFENSE_ROADMAP.md — gap register + evidence file + roadmap 4 phase (ผ่าน fact-check 2 รอบ)
- SECURITY_BASELINE_TARGET_STATE.md — target-state checklist 7 หมวด API-GL-001
- COMPLIANCE_MATRIX.md — Sentinel Gateway vs API-GL-001 (SG-xx findings)
- PLAN_SECURITY_SCANNING_CI_INTEGRATION.md (ยังไม่เผยแพร่) + SONARQUBE_AKS_CI_INTEGRATION_DESIGN.md (ยังไม่เผยแพร่) — CI scanning design พร้อม implement
- ⚠️ งานค้างที่ควรปิดก่อน/พร้อมกัน: review findings ยังไม่ apply 2 ชุด — HANDOFF_SECURITY_MASTER_PLAN_REREVIEW.md (13 findings) + HANDOFF_SECURITY_BASELINE_QA_REVIEW.md (33 findings) — ส่วนใหญ่ merge เข้าเอกสารนี้แล้ว แต่ตัวเอกสารต้นทางยังไม่ได้แก้
- API-GL-001 V3.0 (ธสน./EXIM) · OWASP API Security Top 10 · Azure Landing Zone HLD
🎯 ถ้าเป็นผมจะทำอย่างไร (ความเห็น Fable — สรุปภาพใหญ่ก่อนเข้าประชุม)
ถ้าผมต้องเลือกทำโดยมีคน/เวลาจำกัด นี่คือการจัดลำดับของผม (เหตุผลกำกับในวงเล็บ):
| ลำดับ | งาน | ทำไมก่อน |
|---|---|---|
| 1 | Phase 0 ทั้งหมด (PLAN 00) + F1/F5 ฝั่ง FE (PLAN 10 §9) | รั่วอยู่ตอนนี้ · ส่วนใหญ่ไม่ต้องรอมติใคร |
| 2 | Helper กลาง 5 ตัว + FallbackPolicy (PLAN 05) | จุดคานงัดสูงสุด — แก้ 1 ที่ได้ 14 service |
| 3 | Gitleaks + Regression Gates (เฉพาะ 2 ตัวนี้จาก PLAN 01) | กันงานข้อ 1-2 ไม่ให้ถอยหลัง · ไม่ต้องรอ infra |
| 4 | APIM rate limit + H3 InternalOnly verify (PLAN 03/04) | uncomment + verify config — effort ต่ำ ผลสูง |
| 5 | PII inventory (UserService) → minimization → encrypt/mask | เป็น dependency ของ 4 เรื่อง เริ่มเร็วได้เร็วดี |
| 6 | SonarQube/DT infra · subscription key rollout · session TTL · K8s hardening | สำคัญแต่มี dependency/ต้อง coordinate — เดินขนานตามหลัง |
3 สิ่งที่ผมอยากให้ที่ประชุมเห็นตรงกันมากที่สุด:
- งานส่วนใหญ่คือ “เปิดสวิตช์ + ตั้ง gate” ไม่ใช่ซื้อของใหม่ — อย่าให้ที่ประชุมเขวไปถกเรื่องซื้อ tool ก่อนปิดประตูที่เปิดอยู่
- ตัดสิน decision ที่ block งานอื่นก่อน: D2 (owner), D4 (HMAC scope), D7 (subscription key granularity), D10-2 (signature ครอบ browser ไหม) — decision อื่นเลื่อนได้โดยงานไม่หยุด
- ขอ owner + deadline ต่อหมวดเป็น output ของการประชุม — แผนที่ไม่มี owner = แผนที่สวยที่สุดในโลกที่ไม่เกิดขึ้นจริง
📚 อ้างอิงมาตรฐานหลักของทั้งแผน (สำหรับใช้ในที่ประชุม):
| มาตรฐาน | ใช้อ้างอิงเรื่อง | ลิงก์ |
|---|---|---|
| OWASP API Security Top 10 (2023) | กรอบความเสี่ยง API ทั้งหมด (BOLA, BrokenAuth, Excessive Data, Rate Limit) | owasp.org/API-Security |
| OWASP Top 10 (2021) | ความเสี่ยง web app ทั่วไป (Crypto Failures, Misconfig, Logging) | owasp.org/Top10 |
| OWASP ASVS | target-state checklist ตรวจรับต่อข้อ | owasp.org — ASVS |
| OWASP Cheat Sheet Series | how-to รายหัวข้อ (session, secrets, logging, K8s, CSP) | cheatsheetseries.owasp.org |
| NIST Cybersecurity Framework 2.0 | จัดกลุ่ม Identify→Protect→Detect→Respond→Recover (map กับ Phase 0-3 ได้) | nist.gov/cyberframework |
| Microsoft Zero Trust | verify explicitly · least privilege · assume breach — หลักที่ใช้ตัดสิน defense-in-depth ทั้งแผน | learn.microsoft.com — Zero Trust |
| สคส. (PDPC Thailand) | ข้อกำหนด PDPA หมวด 8 | pdpc.or.th |
แต่ละ IMPL_PLAN มีตารางอ้างอิงเฉพาะหัวข้อท้าย section “ความเห็น Fable” ของแต่ละไฟล์ — หยิบใช้ตามหมวดที่ถูกถามในที่ประชุมได้เลย