Security Supplemental Recommendations

วันที่: 07/07/2026
สถานะ: Draft สำหรับ review เพิ่มเติม
บริบท: เอกสารนี้เป็นส่วนเสริมจากชุด IMPL_PLAN_00 ถึง IMPL_PLAN_09 และ SECURITY_UPLIFT_DISCUSSION_TOPICS.md ไม่ได้แทนที่แผนหลัก แต่เติมช่องว่างด้าน governance, assurance และ use case เฉพาะที่ควรหารือเพิ่ม

สรุป

แผนหลักครอบคลุม technical control สำคัญแล้ว โดยเฉพาะการปิด credential รั่ว, auth bypass, default-deny, APIM hardening, secrets, Redis, PII inventory และ observability

ส่วนที่ควรเติมคือ security governance และ assurance ที่ทำให้ control เหล่านี้ไม่ถอยหลัง รวมถึง use case ใหม่ 2 เรื่อง:

1. การเก็บ sensitive data ใน DB เช่น PDPA, เลขบัตรประจำตัวประชาชน, KYC document
2. การส่งข้อมูลออกไปให้ client render report ซึ่งเป็น data egress surface ที่เสี่ยงต่อ excessive data exposure, cache leak, unauthorized export และ report tampering

S1 - Threat Model กลางของระบบ

เหตุผล

เอกสารหลักมี trust boundary และ mitigation กระจายอยู่หลายหมวดแล้ว แต่ยังไม่มี threat model กลางที่ใช้เป็นแหล่งอ้างอิงเดียวสำหรับ flow สำคัญ

ข้อเสนอ

สร้างไฟล์ THREAT_MODEL.md หรือเพิ่มเป็น section ในเอกสาร architecture/security กลาง โดยครอบคลุม flow ต่อไปนี้:

Definition of Done

• มี diagram ระบุ trust boundary
• มี abuse case ต่อ flow
• mitigation แต่ละรายการ link กลับไปยัง implementation plan
• review ทุกครั้งที่เพิ่ม flow ใหม่หรือ external integration ใหม่

S2 - Authorization Matrix + Object-Level Authorization

เหตุผล

แผนหลักพูดถึง IDOR/BOLA แล้ว แต่ควรแปลงเป็น artifact ที่ตรวจสอบได้ ไม่ใช่ขึ้นกับการ review code รายครั้ง

ข้อเสนอ

ทำ AUTHORIZATION_MATRIX.md ต่อ service หรือรวมกลาง โดยระบุ:

งานที่ควรเพิ่ม

• เพิ่ม integration test สำหรับ 401/403 ต่อ endpoint ที่สำคัญ
• เพิ่ม negative test สำหรับ cross-user และ cross-tenant access
• เพิ่ม CI gate ว่า endpoint ใหม่ที่ access resource ต้องมี test อย่างน้อยหนึ่ง case สำหรับ unauthorized access

S3 - CSRF / CORS / Cookie Security Plan

เหตุผล

ระบบมี browser cookie และ Sentinel/APIM façade ดังนั้น state-changing request ต้องมีแผน CSRF/CORS ที่ชัดเจน แยกจาก JWT validation

ข้อเสนอ

เพิ่มเอกสารสั้น CSRF_CORS_COOKIE_POLICY.md หรือเพิ่มใน IMPL_PLAN_04:

• กำหนด SameSite ต่อ environment และ use case
• ระบุว่า endpoint ที่รับ cookie และเปลี่ยน state ต้องใช้ CSRF token หรือ double-submit token หรือ header ที่ตรวจ Origin/Referer อย่างเข้ม
• CORS allowlist ต้องมาจาก config ต่อ env ห้าม wildcard กับ credentialed request
• ทดสอบ Origin ที่ไม่ได้ allow ต้องถูก reject
• ทดสอบ request ไม่มี CSRF token ต่อ write endpoint ต้อง 403

จุดที่ควรระวัง

ถ้าใช้ SameSite=None เพื่อรองรับ WebView/LIFF/cross-site flow ต้อง compensate ด้วย CSRF token และ Origin validation ที่จริงจัง

S4 - Vulnerability Management Process

เหตุผล

IMPL_PLAN_01 วาง scanner ครบดี แต่ต้องมี process หลัง scan พบช่องโหว่ ไม่อย่างนั้น dashboard จะกลายเป็น backlog ที่ไม่มีเจ้าของ

ข้อเสนอ

เพิ่ม process:

ต้องมี exception process:

• ระบุ owner
• ระบุเหตุผลที่ accept risk
• มี expiry date
• มี compensating control
• review ซ้ำก่อนหมดอายุ

S5 - Supply Chain Hardening

เหตุผล

SAST/SCA/container scan ช่วยจับปัญหา แต่ยังไม่ได้ยืนยันว่า artifact ที่ deploy คือ artifact ที่ผ่าน pipeline จริง

ข้อเสนอ

เพิ่มหัวข้อระยะ Phase 2/3:

• สร้าง SBOM ทุก build และเก็บกับ artifact
• pin dependency ผ่าน lockfile และห้าม restore แบบ floating version ใน production build
• sign container image เช่น Cosign หรือ Azure-native equivalent
• enforce deploy เฉพาะ signed image จาก trusted pipeline
• จำกัดสิทธิ์ ADO service connection ให้ push/deploy ได้เฉพาะ scope ที่จำเป็น
• branch protection: require PR, required checks, no direct push to protected branch

S6 - Incident Response Runbooks

เหตุผล

IMPL_PLAN_09 มี alerting แล้ว แต่ยังต้องระบุว่าเมื่อ alert ดังแล้วใครทำอะไรตามลำดับ

Runbook ที่ควรมี

Definition of Done

• แต่ละ alert rule มี runbook link
• มี contact/owner ต่อ severity
• มี tabletop exercise อย่างน้อยรายไตรมาส

S7 - Backup / Restore / DR Security

เหตุผล

Sensitive data ไม่ได้อยู่แค่ DB production แต่รวมถึง backup, export, Redis persistence, Log Analytics export และ generated report files

ข้อเสนอ

• ระบุ backup inventory: PostgreSQL, Redis persistence, blob/report storage, audit log export, Key Vault backup
• ตรวจว่า backup encrypted at rest และ access จำกัดด้วย RBAC
• ทดสอบ restore อย่างน้อยรายไตรมาส
• restore environment ต้องไม่ expose PII ให้ทีมที่ไม่จำเป็น
• backup retention ต้องสอดคล้องกับ PDPA retention policy
• มี procedure ลบหรือทำลาย backup เมื่อครบ retention ตามข้อกำหนด

S8 - Admin / Ops Access Governance

เหตุผล

ถ้า admin access กว้างเกินไป control ฝั่ง app จะถูก bypass ได้จาก infra layer

ข้อเสนอ

• ใช้ PIM/JIT สำหรับ Azure privileged role
• MFA และ Conditional Access สำหรับ Azure, ADO, Cloudflare, APIM, Key Vault
• มี break-glass account พร้อม monitoring และ review
• review role assignment รายเดือน โดยเฉพาะ Key Vault, AKS, ACR, APIM, Log Analytics, Storage immutable
• audit admin action ต้อง query ได้และอยู่ใน WORM retention

S9 - DAST / API Fuzzing / Negative Security Regression

เหตุผล

CI scanner แบบ static จับได้ไม่ครบ โดยเฉพาะ auth flow, APIM policy, runtime header behavior, CSRF, replay และ report export

ข้อเสนอ

เพิ่ม smoke security test หลัง deploy dev/SIT:

• malformed JWT -> 401
• expired JWT -> 401
• missing subscription key -> 401 ที่ APIM
• missing HMAC signature บน endpoint ที่ require -> 401
• timestamp เก่า/replay -> 401
• payload เกิน limit -> 413
• request เกิน rate -> 429
• user A access resource user B -> 403
• Origin ไม่อยู่ใน allowlist -> reject
• report export โดย user ไม่มีสิทธิ์ -> 403

เครื่องมือที่ใช้ได้:

• OWASP ZAP baseline scan
• Postman/Newman negative collection
• k6 สำหรับ rate/security smoke
• custom integration tests ใน pipeline

S10 - Security PR Acceptance Criteria

เหตุผล

เพื่อให้ security ไม่ขึ้นกับ reviewer คนใดคนหนึ่ง ควรฝัง checklist ลงใน PR template

Checklist เสนอ

• Endpoint ใหม่มี [Authorize], [AllowAnonymous] หรือ policy ที่ชัดเจน
• ถ้า endpoint เข้าถึง resource เฉพาะ user/tenant มี object-level authorization แล้ว
• ไม่มี PII/secret/token ใน URL/query string
• ไม่มี PII/secret/token ใน log หรือ error response
• ถ้ามี PII response มีเหตุผลและใช้ DTO เฉพาะ use case
• ถ้าเป็น write/high-risk operation มี idempotency/replay consideration
• ถ้าเพิ่ม secret/config ใหม่ มี KV + fail-fast validation + IaC parity
• ถ้าเพิ่ม report/export มี authorization, audit, cache policy และ minimization

S11 - Use Case: DB Sensitive Data Storage

Scope

ครอบคลุม sensitive data ที่ถูกเก็บใน database เช่น:

• เลขบัตรประจำตัวประชาชน
• passport
• ที่อยู่
• เบอร์โทรศัพท์
• email
• KYC document metadata
• consent record
• ข้อมูลตาม PDPA หรือข้อมูลที่ระบุตัวบุคคลได้

ความเสี่ยงหลัก

Control ที่ควรเพิ่ม

1. Data Classification ต้องลงถึงระดับ field

ใช้ class จาก IMPL_PLAN_08:

Output ควรอยู่ใน PII_INVENTORY_{SERVICE}.md และเพิ่ม column:

• DB table
• DB column
• encryption required
• searchable required
• retention period
• masking rule
• report/export allowed
• owner/data steward

2. เลือก encryption pattern ตามการใช้งานของ field

ข้อควรระวัง: ถ้าใช้ encryption แบบ deterministic เพื่อ search จะ leak pattern ได้ ควรใช้ blind index ด้วย key แยกจาก encryption key

3. Key management สำหรับ DB encryption

• key อยู่ใน Key Vault เท่านั้น
• payload ควรมี key id/version เช่น enc:v2:<kid>:<ciphertext>
• มี dual-read หรือ migration strategy ก่อน rotate key
• key สำหรับ encryption แยกจาก key สำหรับ HMAC/blind index
• กำหนด emergency rotation procedure ถ้าสงสัย key รั่ว

4. Access control ที่ DB และ application layer

• app ใช้ least-privilege DB account ต่อ service
• ห้าม service A อ่าน schema/table ของ service B ถ้าไม่จำเป็น
• admin read PII เต็มต้องผ่าน approved path และถูก audit
• endpoint ที่แสดง PII เต็มต้องมี policy แยก เช่น RequirePIIReveal
• read P0 แบบเต็มต้องมี audit event ระบุ user, purpose, resource id, correlation id

5. Retention และ deletion

• ระบุ retention ต่อ data type จาก PII inventory
• มี scheduled purge/anonymization job
• deletion ต้องครอบคลุม DB, Redis cache, generated report, backup policy เท่าที่ข้อกฎหมายกำหนด
• data subject request ต้อง trace ได้ว่าข้อมูลอยู่ table/report/export ใดบ้าง

DB Sensitive Data Definition of Done

• มี inventory field-level ครบ service pilot
• P0 field ไม่มี plaintext ใน DB, log, Redis, report export โดยไม่จำเป็น
• encryption payload มี key version
• มี blind index เฉพาะ field ที่ต้อง search
• admin/full reveal ถูก audit
• retention job หรือ documented retention owner พร้อม SLA

S12 - Use Case: ส่งข้อมูลให้ Client Render Report

Scope

ครอบคลุมกรณีที่ backend ส่ง dataset ไปให้ frontend/client render report เช่น:

• รายงานผู้ใช้
• รายงานธุรกรรม
• รายงาน consent
• PDF/Excel ที่ render ฝั่ง browser
• report preview
• export file ที่ download ผ่าน URL

ความเสี่ยงหลัก

หลักการ

1. Backend ต้องเป็นตัว enforce authorization และ dataset scope เสมอ
2. Client ไม่ควรได้รับ field ที่ไม่ได้ใช้ใน report
3. Report ที่มี PII ต้องมี audit trail
4. Report output ต้องมี cache policy ชัดเจน
5. Export/download link ต้อง short-lived และผูกกับ user/session/permission
6. ถ้า report เป็นหลักฐานทางธุรกิจ ต้องมี server-side generated canonical copy หรือ digital signature/hash

Control ที่ควรเพิ่ม

1. Report Authorization Matrix

เพิ่ม report ลงใน authorization matrix:

2. Dataset minimization

ห้าม pattern นี้:

Backend returns full entity -> Frontend hides columns -> User exports visible columns

ให้ใช้ pattern นี้:

Frontend requests report type + filters
Backend checks permission + tenant/user scope
Backend builds report-specific DTO
Backend masks/removes fields by permission
Client renders only approved dataset

3. Cache and transport policy

สำหรับ report ที่มี PII:

Cache-Control: no-store, no-cache, must-revalidate, private
Pragma: no-cache
X-Content-Type-Options: nosniff
Content-Disposition: attachment; filename="report-<id>.pdf"

Frontend:

• ห้ามเก็บ report P0/P1 ใน localStorage/sessionStorage/IndexedDB
• ห้าม log report dataset ลง console
• clear in-memory state เมื่อออกจากหน้า report ถ้าเป็น P0
• route query string ห้ามมี citizen ID/email/phone

4. Export/download link

ถ้ามี generated report file:

• ใช้ opaque report id ห้ามใช้ sequential id
• download URL ต้อง short-lived
• URL ต้องผูกกับ user/session หรือใช้ backend re-check permission ทุกครั้ง
• report file storage ต้อง private container เท่านั้น
• report file ที่มี PII ต้องมี retention สั้นและ purge job
• ไม่แนบ PII ใน filename

5. Audit log

ทุก report ที่มี P0/P1 หรือ export ได้ ควร log:

• user id / service identity
• tenant
• report type
• filters ที่ใช้ แต่ต้อง mask PII
• row count / record count
• export format
• timestamp
• correlation id
• reason/purpose ถ้าเป็น P0/full reveal

ห้าม log:

• report dataset เต็ม
• citizen ID เต็ม
• token/session id
• generated file URL แบบมี signed token

6. Watermark และ tamper evidence

สำหรับ report ที่ออกนอกระบบหรือใช้เป็นหลักฐาน:

• ใส่ watermark เช่น generated by, user, timestamp, report id
• สร้าง hash ของ canonical report payload
• เก็บ hash และ metadata ฝั่ง server
• ถ้าเป็นเอกสารสำคัญมาก พิจารณา server-side PDF generation แทน client-only render

7. Report-specific security tests

• user ไม่มี permission เรียก report -> 403
• user tenant A ขอ report tenant B -> 403
• report request ใส่ filter เกิน scope -> backend override/reject
• response ไม่มี field P0 ที่ไม่จำเป็น
• response header เป็น Cache-Control: no-store
• generated link หมดอายุแล้ว download ไม่ได้
• export action มี audit log

Report Rendering Definition of Done

• report ทุกตัวมี owner และ authorization matrix
• dataset เป็น report-specific DTO ไม่ใช่ entity เต็ม
• P0/P1 ถูก mask/minimize ก่อนถึง client
• response มี no-store cache policy
• export/download ถูก audit
• generated file มี retention/purge policy
• negative test ครบ unauthorized, cross-tenant, expired link

ลำดับที่แนะนำให้เพิ่มเข้า roadmap

Decision Checklist เพิ่มเติม

• D10 - ข้อมูล P0/P1 ใน DB field ไหนต้อง encrypt ตั้งแต่ phase แรก
• D11 - field ไหนต้อง search exact match และจะใช้ blind index หรือไม่
• D12 - report ใดถือเป็น sensitive report และต้อง audit/export control
• D13 - report rendering ตัวไหนต้อง server-side canonical PDF แทน client-only render
• D14 - retention ของ generated report file คือกี่วัน
• D15 - ใครเป็น data owner/DPO สำหรับการ approve full PII reveal
• D16 - vulnerability SLA และ risk acceptance process ใช้เกณฑ์ใด
• D17 - incident owner/on-call สำหรับ security alert คือใคร

🎯 ถ้าเป็นผมจะทำอย่างไร (ความเห็น Fable)

1. เอกสารนี้ดีแต่กว้าง — อย่าทำทั้ง 12 ข้อพร้อมกัน ถ้าต้องเลือก 3 ข้อแรกของผมคือ: S2 (authorization matrix) — กัน BOLA/IDOR ซึ่งเป็น OWASP API #1 และได้ของแถมจาก FallbackPolicy rollout · S3 (CSRF/CORS/cookie) — เป็นช่องโหว่จริงของระบบ cookie-based ที่แผนหลักยังไม่ครอบ · S10 (PR checklist) — ถูกที่สุด (แค่แก้ PR template) ผลกว้างสุด
2. S1 (threat model) ทำเป็น living doc หลัง Phase 1 เสร็จ — ทำก่อน = เสียเวลา model สิ่งที่กำลังเปลี่ยน · ใช้ตาราง flow ที่เขียนไว้ใน S1 เป็น skeleton ได้เลย
3. S4 (vulnerability SLA) ต้องมาพร้อม CI scanner เป็น package เดียว — scanner โดยไม่มี SLA = dashboard ที่ทุกคน mute · เสนอเอา SLA table ของ S4 เข้าที่ประชุมเดียวกับ D6 ของ gate policy
4. S12 (report) สำคัญขึ้นเพราะมี use case จริงแล้ว (report client + fx.reportAccessToken ใน localStorage — F1 ของ IMPL_PLAN_10 §9) — ยกระดับจาก “supplemental” เป็นงาน Phase 2 จริง
5. S5-S8 (supply chain, IR runbook, DR, admin governance) คือ Phase 3 ทั้งหมด — ถูกต้องแต่อย่าเอามาแย่ง bandwidth กับการปิดประตูที่เปิดอยู่ตอนนี้ — ยกเว้น S6 เฉพาะ “credential leak runbook” ตัวเดียวที่ควรมีก่อน (เพราะ Phase 0 กำลังจะ rotate ของจริง — มี playbook ดีกว่า improvise)

📚 อ้างอิงมาตรฐาน (สำหรับใช้ในที่ประชุม):