Cost · Performance · Trade-offs
สรุปราคาที่ต้องจ่ายต่อแผน 00-10 — เงิน, latency budget, trade-off ที่ต้อง sign-off ก่อน approve
อัปเดต: 2026-07-07
COST · PERFORMANCE · TRADE-OFFS — สิ่งที่ต้องจ่ายและต้องยอมรับ
วันที่: 07/07/2026 · สถานะ: ⏳ รอ verify · ใช้คู่กับ SECURITY_UPLIFT_DISCUSSION_TOPICS.md เอกสารนี้คืออะไร: ทุก control ในแผน 00-10 มีราคา — เป็นเงิน, เป็น latency, หรือเป็นความสะดวกที่หายไป เอกสารนี้รวบให้เห็นก่อนตัดสินใจ เพื่อไม่ให้ที่ประชุม approve แผนโดยไม่รู้ว่ากำลัง sign อะไร
§1 ภาพรวม — cost/perf/trade-off ต่อแผน
| Plan | 💰 Cost (เงิน/คน) | ⚡ Performance | ⚖️ Trade-off ที่ต้องยอมรับ |
|---|---|---|---|
| 00 Stop the Bleeding | ~ศูนย์ (เวลา dev + coordinate EXIM/DGA) | ไม่มี | dev เสียความสะดวก — ต้องใช้ token จริงบน dev cluster |
| 01 CI Security | สูงสุดในชุด — SonarQube+DT ต้องมี PostgreSQL + node resources + คนดูแลถาวร · Gitleaks/Trivy/Checkov ฟรี | build time +5-15 นาที/pipeline (Sonar หนักสุด) | gate blocking = delivery ช้าลงเมื่อเจอ finding · false positive ต้องมี allowlist process |
| 02 Data in Transit | ~ศูนย์ (ของมีแล้ว) — ยกเว้น RSA ผ่าน KV มีค่า ops | HMAC = µs (negligible) · RSA decrypt ผ่าน KV = +20-100ms/field + KV throttling limit | RSA ใช้ได้เฉพาะ form ปริมาณต่ำ — ห้ามใช้กับ hot path |
| 03 APIM Edge | ศูนย์ (Premium จ่ายแล้ว — policy ไม่คิดเพิ่ม) | validate-jwt +~1ms (JWKS cached) · rate-limit sub-ms | subscription key โผล่ใน devtools (by design) · client ที่ตกหล่นตอน enforce = 401 |
| 04 Session/Token | ศูนย์ | encrypt token ก่อนเขียน Redis = µs · idle-check = Redis op เดิม | idle 30 นาที = login บ่อยขึ้น (UX มือถือ) · H2 migration = ทุก user หลุด login 1 ครั้ง |
| 05 Helper/FallbackPolicy | ศูนย์ (เวลา dev ต่อ service ~0.5-1 วัน) | FallbackPolicy = ศูนย์ · in-process rate limiter = sub-ms | ความเสี่ยงช่วง rollout (probe 401) — คุมด้วยลำดับ 5 step |
| 06 Secrets/KV | KV ops คิดต่อ 10k transactions — negligible | fail-fast = boot ช้าขึ้น ms | purge history = force-push ทุกคน re-clone · fail-fast = pod ไม่ boot ถ้า config ขาด (by design แต่ต้องเตรียมค่า) |
| 07 Redis | อาจต้องแยก instance (blast radius) = ค่า Redis เพิ่ม 1 instance ถ้าเลือกทางนั้น | encrypt/decrypt ต่อ session op = µs · TTL cache สั้น = cache-miss มากขึ้น → DB load เพิ่ม | ลด field cache = consumer ที่แอบใช้ field พัง (breaking) |
| 08 PDPA | เวลาคนทำ inventory (มากสุดในหมวด) | minimization ทำให้ payload เล็กลง = เร็วขึ้น (ได้กำไร) | API contract เปลี่ยน = FE/BE ต้อง coordinate · admin เห็นข้อมูลเต็มต้องผ่าน endpoint แยก (ขั้นตอนเพิ่ม) |
| 09 Infra/Observability | Log retention ≥90 วัน = ค่า Log Analytics ต่อ GB + WORM storage (ถูกแต่ไม่ฟรี) | NetworkPolicy/non-root = negligible | immutable storage ลบไม่ได้จริง (รวมเราเอง) · readOnlyRootFilesystem อาจทำ service ที่เขียนไฟล์พัง |
| 10 Frontend | ศูนย์ | RSA บน form submit = ครั้งเดียวต่อ submit, รับได้ · config.json fetch = +1 request ตอน bootstrap | MSAL → sessionStorage = tab ใหม่ต้อง silent re-auth · sanitize=true อาจ strip formatting บาง content |
§2 เงินจริงที่ต้องจ่าย (เรียงจากมากไปน้อย)
ตัวเลขเป็น order-of-magnitude — ก่อน commit งบให้กด Azure Pricing Calculator ด้วยค่า config จริง
| # | รายการ | ประเภท | ประมาณการ | หมายเหตุ |
|---|---|---|---|---|
| 1 | คนดูแล SonarQube + Dependency-Track | ค่าคนถาวร | ~10-20% ของ 1 FTE ต่อเนื่อง | ค่าที่แพงที่สุดและถูกลืมบ่อยที่สุด — upgrade, DB maintenance, triage support · ถ้าไม่มีคน = tool ตาย ภายใน 6 เดือน |
| 2 | Azure PostgreSQL Flexible (Sonar+DT) | infra รายเดือน | B-series 2 vCPU พอสำหรับเริ่ม | open item จาก design 01/07 อยู่แล้ว |
| 3 | AKS node resources (namespace security) | infra | ~2-4 vCPU / 8-16GB รวม 2 app | อาจ fit ใน node pool เดิมถ้ามี headroom |
| 4 | Log Analytics retention 90 วัน | รายเดือน ต่อ GB | ต่อจาก 31 วันแรก คิด per-GB-month | ลดได้ด้วย table-level retention (เก็บยาวเฉพาะ audit table ไม่ใช่ทุก log) — ราคา |
| 5 | WORM/immutable blob storage | รายเดือน | Cool tier พอ — ถูก | ตั้ง lifecycle จาก LAW export |
| 6 | Redis แยก instance (ถ้าเลือก) | รายเดือน | 1 instance เพิ่ม | ทางเลือกถูกกว่า: DB index + ACL แยก (ดู IMPL_PLAN_07) |
| 7 | KV operations (fail-fast, RSA decrypt, CSI refresh) | per-10k ops | negligible ที่ scale ปัจจุบัน | ระวังเฉพาะ RSA ที่ volume สูง — ดู §3 |
| 8 | CI minutes เพิ่ม | per-build | +5-15 นาที/build | ADO parallel jobs อาจต้องเพิ่มถ้า queue ยาว |
ของที่ฟรีทั้งหมด (ย้ำในที่ประชุม): Gitleaks, Trivy, Checkov, regression gates, FallbackPolicy, rate limiter, ForwardedHeaders, HMAC, ShowPII fix, subscription key/rate-limit/validate-jwt บน APIM Premium ที่จ่ายอยู่แล้ว — ~70% ของแผนไม่มี infra cost ใหม่เลย
§3 Performance Budget — latency ที่เพิ่มต่อ request
Hot path (ทุก API call หลังเปิดครบ Phase 1-2)
| ชั้น | Latency เพิ่ม | หมายเหตุ |
|---|---|---|
| Subscription key check (APIM) | ~0 | in-memory lookup |
| rate-limit-by-key (APIM) | <1ms | counter ใน gateway |
| validate-jwt (APIM) | ~1ms | JWKS cache (default 1 ชม.) — cold miss ครั้งแรก +50-200ms |
| resolve-session (มีอยู่แล้ว) | 0 เพิ่ม | flow เดิม |
| Backend: FallbackPolicy | 0 | แค่ policy evaluation เดิม |
| Backend: partitioned rate limiter | <1ms | in-process |
| Backend: HMAC validate (endpoint ที่ติด) | <0.1ms | SHA-256 บน payload ปกติ |
| Token decrypt จาก Redis (H2) | <0.5ms | AES บน token ขนาด KB |
| รวม hot path | ~2-4ms ต่อ request | ต่ำกว่า network jitter ปกติ — ไม่มีข้ออ้างเรื่อง performance ที่จะไม่เปิด |
Cold/เฉพาะจุด — ตัวที่ต้องระวังจริง
| จุด | Impact | ทางคุม |
|---|---|---|
| RSA-OAEP decrypt ผ่าน KV Keys API | +20-100ms ต่อ field ต่อ request (network ไป KV) + KV มี throttling limit ต่อ vault (service limits) | ใช้เฉพาะ form P0 ปริมาณต่ำ (KYC submit) — ถ้าอนาคต volume สูง เปลี่ยนเป็น envelope encryption (KV ถือ KEK, service ถือ DEK ใน memory) — บันทึกเป็น upgrade path ไว้เลย |
| Session TTL สั้นลง | re-auth ถี่ขึ้น = load ที่ Entra/Sentinel + Redis churn | ตั้ง sliding idle (ไม่ใช่ fixed) — user ที่ active ไม่โดน |
| Serilog masking enricher | ~µs ต่อ log event แต่คูณด้วย volume ทั้ง platform | benchmark ก่อน rollout — ทำใน Package ครั้งเดียว |
| CI scanners | +5-15 นาที/build | รัน SAST/SBOM แบบ parallel stage ไม่ block test stage · PR build รันเฉพาะ Gitleaks+gates (เร็ว), full scan บน main |
| Cache TTL สั้นลง (Redis PII 15 นาที) | cache-miss → DB query เพิ่ม | ดู DB metrics หลังปรับ — ถ้า load ขึ้นชัด ค่อยถกค่า TTL ใหม่ด้วยข้อมูลจริง |
§4 Trade-offs ที่ต้องให้ที่ประชุม “ยอมรับเป็นลายลักษณ์อักษร” (ไม่ใช่แค่รับทราบ)
เรียงตามความเจ็บ — แต่ละข้อควรมีชื่อคน sign-off ใน minutes
| # | Trade-off | ใครเจ็บ | ความเจ็บ | ทำไมคุ้ม |
|---|---|---|---|---|
| T1 | Idle timeout 30 นาที | user ทุกคน (โดยเฉพาะ mobile) | login บ่อยขึ้น | มาตรฐาน assurance (NIST 800-63B) — 30 วันแบบไม่มี idle cap คือ finding ที่ผู้ตรวจไม่ปล่อยผ่าน |
| T2 | Invalidate ทุก session ตอนเปิด token encryption (H2) | user ทุกคน 1 ครั้ง | หลุด login พร้อมกัน | จ่ายครั้งเดียว vs dual-read code path ถาวร — ทำนอก peak + ประกาศล่วงหน้า |
| T3 | Dev ใช้ token จริงบน dev cluster (ปิด bypass) | ทีม dev ทุกวัน | ขอ token เพิ่มขั้นตอน | นี่คือ root cause อันดับ 1 ของทั้ง scan — ลดความเจ็บด้วย Swagger auth helper + test users |
| T4 | Gate blocking ใน CI | ทีม dev ตอน merge | build แดงเมื่อเจอ finding | กันถอยหลัง — ผ่อนด้วย phase non-blocking→blocking + exception process มี expiry |
| T5 | Force-push หลัง purge history | ทุกคนที่ clone repo | re-clone + PR เก่า diff เพี้ยน | ทำเฉพาะ repo ที่มี secret prod จริง (ดูความเห็น Fable ใน IMPL_PLAN_06) |
| T6 | MSAL → sessionStorage | user เปิดหลาย tab | tab ใหม่ silent re-auth (~วินาที) | ตัด token-theft-at-rest จาก localStorage — ทดสอบ UX ก่อน ถ้า silent SSO ทำงาน user แทบไม่รู้สึก |
| T7 | text-editor sanitize=true default | content ที่มี HTML แปลก | formatting บางส่วนถูก strip | ปิด stored-XSS surface — จุดที่เสียจริงค่อย opt-out รายตัวพร้อมเหตุผล |
| T8 | Admin เห็น PII เต็มต้องผ่าน endpoint แยก + audit | ทีม ops/admin | ขั้นตอนเพิ่ม | PDPA + ผู้ตรวจต้องการ audit trail การเข้าถึง P0 |
| T9 | Console strip ใน production build | dev ตอน debug prod issue | debug หน้างานยากขึ้น | ใช้ App Insights + source map ภายในแทน — PII ไม่ควรอยู่ใน console ตั้งแต่แรก |
| T10 | Subscription key มองเห็นได้ใน devtools | — (ความรู้สึก) | ดู “ไม่ปลอดภัย” ในสายตาคนไม่รู้บริบท | มันคือ app identity ไม่ใช่เกราะ — เตรียมคำอธิบายไว้ใน IMPL_PLAN_03 §3.1 แล้ว |
§5 ของที่ “แพงเกินคุ้ม ณ ตอนนี้” — เสนอ ไม่ทำ/เลื่อน (พร้อมเงื่อนไข re-visit)
| ของ | ทำไมยังไม่คุ้ม | Re-visit เมื่อ |
|---|---|---|
| mTLS in-cluster / service mesh | operational cost ถาวร (upgrade, debug, sidecar/ambient overhead) ต่อทีมขนาดนี้ · NetworkPolicy + private cluster ครอบ risk ส่วนใหญ่ | ผู้ตรวจระบุเป็นลายลักษณ์อักษร หรือ platform โต >30 services |
| JWS/JWE ต่อ message | แพงกว่า HMAC ทั้ง compute และ complexity — ยังไม่มี requirement ชี้ | มี integration ที่ contract บังคับ (เช่น partner ธนาคาร) |
| Session-bound signing key (Phase 2 ของ PLAN 02) | effort สูง (Sentinel+APIM+FE+Package) แต่กันแค่ cookie-theft ซึ่ง CSP+HttpOnly+Secure กดความเสี่ยงไปมากแล้ว | D10-2: ผู้ตรวจยืนยัน scope ครอบ browser |
| Cloudflare Worker ซ่อน subscription key | เพิ่ม component โดยไม่เพิ่มความปลอดภัยจริง | ผู้ตรวจห้าม key ปรากฏใน client เท่านั้น |
| Roslyn analyzer แทน grep gates | grep gates ครอบ 80% ของ regression ที่กลัว ด้วย effort 5% | ทีมมี capacity หลัง Phase 2 |
| Redis แยก instance ทันที | DB index + ACL + key prefix ได้ blast-radius ส่วนใหญ่ฟรี | มีงบรอบถัดไป หรือ incident ชี้ว่าจำเป็น |
| DAST อัตโนมัติทุก build | ช้า (นาที-ชั่วโมง) เกินจะอยู่ใน PR loop | ทำเป็น scheduled nightly บน dev/SIT พอ (ตาม S9) |
🎯 ถ้าเป็นผมจะทำอย่างไร (ความเห็น Fable)
- เปิดประชุมด้วย §2 บรรทัดสุดท้าย — “~70% ของแผนไม่มี infra cost ใหม่” เปลี่ยนบรรยากาศจาก “ของบ” เป็น “ขอ approve ลำดับงาน” — งบจริงที่ต้องขอมีก้อนเดียวคือ CI stack (ข้อ 1-3 ใน §2) ซึ่งเลื่อนได้โดยไม่ block Phase 0-1
- Performance ไม่ใช่เหตุผลที่ valid สำหรับเลื่อน hot-path controls — ตัวเลข ~2-4ms ใน §3 คือคำตอบสำเร็จรูปเวลามีคนอ้าง “กลัวช้า” · ตัวเดียวที่ช้าจริงคือ RSA ผ่าน KV ซึ่ง scope เฉพาะ form P0 อยู่แล้ว
- T1-T5 ต้องมีชื่อคน sign-off ใน minutes — trade-off ที่ไม่มีคน accept เป็นลายลักษณ์อักษร จะกลายเป็น “ทำไมระบบ logout เอง” ticket ที่ย้อนกลับมาหาทีม dev ภายหลัง
- จองคำว่า “envelope encryption” ไว้ใน minutes (§3) — วันที่ KYC volume โตจน KV throttle มาถึงแน่ ถ้าจดไว้วันนี้จะไม่มีใคร panic-redesign วันนั้น
- อย่าให้ §5 กลายเป็น “ไม่ทำตลอดไป” — ทุกแถวมีคอลัมน์ re-visit เพราะตั้งใจ — เอาเข้า review รอบ 6 เดือนพร้อม compliance calendar
📚 อ้างอิงมาตรฐาน (สำหรับใช้ในที่ประชุม):
| หลักการ | แหล่งอ้างอิง |
|---|---|
| KV throttling / service limits (เพดานของ RSA ผ่าน KV) | Microsoft Learn — Azure Key Vault service limits |
| APIM capacity & scaling (รองรับ policy เพิ่มไหม) | Microsoft Learn — Capacity of an Azure API Management instance |
| Log Analytics pricing / retention tiers | Azure Monitor pricing |
| Envelope encryption pattern (upgrade path ของ RSA) | Microsoft Learn — Azure data encryption at rest (envelope encryption) |
| Session timeout ที่มาตรฐานบังคับ (ตอบ T1) | NIST SP 800-63B |
| Risk acceptance ต้องมี owner + expiry | NIST SP 800-30 — Guide for Conducting Risk Assessments |