Security Adoption — เริ่มที่นี่: service ของคุณต้องทำอะไรบ้าง
สรุปกลไกความปลอดภัย 6 ตัวที่ทำเสร็จและพิสูจน์แล้วบน UserService — อันไหน library ทำให้แล้ว อันไหนต้องต่อเอง ใช้เวลาเท่าไร และลำดับที่ควรทำ พร้อม prompt สำหรับให้ AI ช่วย implement ใน service ของตัวเอง
อัปเดต: 2026-08-23
เอกสารชุดนี้คืออะไร — งาน security uplift รอบแรกทำจริงและพิสูจน์จริงบน UserService ตัวเดียว เอกสารชุดนี้คือการถอดสิ่งที่ทำ ให้ service อื่นเอาไปทำตามได้โดยไม่ต้องย้อนอ่านประวัติการตัดสินใจทั้งหมด
ทุกบรรทัดของโค้ดในเอกสารชุดนี้ คัดมาจากโค้ดที่ merge แล้วจริง ไม่ใช่ pseudo-code
1. อ่าน 60 วินาที
- กลไกส่วนใหญ่ อยู่ใน library กลางแล้ว (
SupApp_util_libฝั่ง backend ·@exim/auth-sdkฝั่ง frontend) — งานของ service คือ ต่อสาย + ใส่ config ไม่ใช่เขียน crypto เอง - ทุกกลไกมี kill switch ปิดอยู่โดย default ⇒ ติดตั้งได้โดยไม่กระทบผู้ใช้ แล้วค่อยเปิดทีหลัง
- ของที่ต้องระวังที่สุดไม่ใช่โค้ด แต่คือ config ไม่ครบทุก env (§4) — เป็นสาเหตุอันดับ 1 ที่ “แก้แล้วไม่มีผลบน cluster”
2. 6 กลไก — อันไหนเกี่ยวกับ service คุณ
| # | กลไก | ป้องกันอะไร | ใครทำให้แล้ว | แรงที่ต้องใช้ | เอกสาร |
|---|---|---|---|---|---|
| 1 | ปิดประตูที่เปิดค้าง ([Authorize] / fail-open) | คนนอกเรียก endpoint ได้โดยไม่ต้อง login | — (งานมือล้วน) | 0.5–2 วัน แล้วแต่จำนวนเส้น | BE — ปิดประตูที่เปิดค้าง |
| 2 | Body Signature (ลายเซ็นต่อผู้ใช้) | ปลอมคำขอ · แก้ body ระหว่างทาง · ยิงซ้ำ (replay) | SupApp_util_lib (filter+verifier) · service ทำ key store เอง | 2–3 วัน | BE — Body Signature |
| 3 | API Key ระหว่าง service | service ปลอมเรียก service | SupApp_util_lib (filter+validator) | 0.5 วัน | BE — API Key |
| 4 | เข้ารหัสข้อมูลอ่อนไหว (DB + Redis) | ข้อมูลหลุดจาก storage/backup | SupApp_util_lib (cipher) | 1–3 วัน แล้วแต่จำนวน field | BE — Encryption |
| 5 | Body Signature ฝั่ง client | เหมือน #2 แต่เป็นฝั่งที่ต้องเซ็น | @exim/auth-sdk/body-signature (interceptor+signer) | 0.5–1 วัน | FE — Body Signature |
| 6 | Frontend hardening (XSS sink) | สคริปต์แปลกปลอมรันในหน้าเว็บผู้ใช้ | @exim/ui-kit (บังคับ sanitize) | 0.5 วัน | FE — Hardening |
ทุก service ควรทำ #1 และ #3 เป็นอย่างน้อย · #2/#5 ทำเป็นคู่เสมอ (ฝั่งเดียวไม่มีความหมาย) · #4 ทำเมื่อ service เก็บข้อมูลส่วนบุคคล
3. ลำดับที่แนะนำ (และเหตุผล)
1) ปิดประตูที่เปิดค้าง ──► ได้ผลทันที ไม่ต้องรอใคร ไม่ต้อง bump library
2) API key ระหว่าง service ──► เล็ก จบเร็ว ทำให้ทีมคุ้นกับ pattern config→IaC→KeyVault
3) Encryption ของ field ที่อ่อนไหว ──► ต้องคิดเรื่อง migration ก่อนลงมือ เริ่มเร็วดีกว่า
4) Body signature BE + FE พร้อมกัน ──► ใหญ่สุด ต้องมี 2 ฝั่งเดินคู่กัน
ห้ามเริ่มที่ #4 ถ้ายังไม่มีคนฝั่ง frontend ที่พร้อมทำคู่ — ฝั่งเดียวจะเปิดใช้จริงไม่ได้ กลายเป็นโค้ดค้าง
4. 🔴 กติกา config ที่ทำให้คนพลาดมากที่สุด
ทุกกลไกในเอกสารชุดนี้มี config ใหม่ ทุกครั้งที่เพิ่ม key ใหม่ใน appsettings.{ENV}.json ต้องไปเพิ่มที่ IaC ด้วยทุก env
| ค่าประเภทไหน | เก็บที่ไหน | ถ้าลืมจะเป็นยังไง |
|---|---|---|
| ค่าธรรมดา (เปิด/ปิด, ชื่อ header, ตัวเลข) | appsettings.json ของ service และ Backend_Iac/config/{service}/{env}/appsettings.json | CI เอาไฟล์จาก IaC ทับทั้งไฟล์ ตอน build ⇒ แก้ในโปรเจกต์อย่างเดียว = ไม่มีผลบน cluster · และ parity check ทำ build fail ถ้า IaC ขาด key ที่ service มี |
| ค่าที่เป็นความลับ (key, secret, connection string) | KeyVault เท่านั้น (mount เป็น env var Section--Key) | env var ชนะ appsettings ทุกชั้น ⇒ แก้ appsettings แล้ว “ไม่มีผล” แบบหาสาเหตุไม่เจอ |
ตอนเขียน PR ให้แนบรายการ key ใหม่ + env ที่ต้องเติมมาด้วยเสมอ ถ้ายังไม่รู้ค่าจริงของ env ไหน ให้บอกออกมาตรง ๆ อย่าปล่อยเงียบ
5. ของที่ ยังไม่ทำ — อย่าเพิ่งสร้าง
| ไม่ทำ | เหตุผล |
|---|---|
| 1 คนใช้ได้หลายอุปกรณ์ (multi-device key) | ออกแบบไว้แล้วแต่ยังไม่อนุมัติให้ build — key store ปัจจุบันคือ 1 subject : 1 key |
| หมุน API key อัตโนมัติ (rotation) | รอผลสำรวจผู้ใช้กุญแจจริงก่อน |
| Rate limit ที่ตัว service | มี policy อยู่แล้วที่ชั้น gateway — บันทึกเป็นข้อสังเกต ไม่ทำซ้ำที่ service |
6. Prompt สำหรับให้ AI ช่วย implement ใน service ของคุณ
คัดลอกทั้งบล็อกนี้ไปวางใน AI coding agent ที่เปิดอยู่บน repo ของ service คุณ แล้วแก้ 2 บรรทัดบนสุด:
service ของฉันคือ {ServiceName} (repo Backend_{ServiceName})
กลไกที่จะทำรอบนี้คือ {เลือกจาก: ปิดเส้น anonymous / body signature / api key / field encryption}
กติกาบังคับ ห้ามข้าม:
1. อ่านเอกสาร adoption ของกลไกนั้นให้จบก่อนเขียนโค้ดบรรทัดแรก แล้วสรุปให้ฉันดูว่าจะแตะไฟล์ไหนบ้าง
2. ห้ามเขียน crypto เอง ทุกอย่างมาจาก SupApp_util_lib แล้ว ถ้าคิดว่าต้องเขียนเอง แปลว่าเข้าใจผิด ให้หยุดถามก่อน
3. ทุก config key ที่เพิ่ม ต้องบอกฉันด้วยว่าต้องไปเติมที่ Backend_Iac/config/{service}/{env}/appsettings.json env ไหนบ้าง และค่าไหนต้องอยู่ KeyVault แทน
4. เปิด kill switch เป็น false เสมอในทุก env ที่ commit ลงไป การเปิดใช้จริงเป็นคนละขั้นตอน
5. โครง Clean Architecture 4 layer ห้าม DTO/business logic อยู่ใน Controller ห้าม repository interface อยู่ใน Infrastructure
6. เขียน unit test ให้ครบตาม acceptance test ที่เอกสารระบุ แล้วรัน dotnet build -c Release และ dotnet test -c Release ให้ผ่านจริงก่อนบอกว่าเสร็จ
7. ห้ามบอกว่า "น่าจะผ่าน" ต้องแปะผลรันจริงมาให้ดู
7. หมายเหตุ
- เอกสาร 101 ชุดเดิม (
/docs/security/body-signature-101ฯลฯ) เขียนไว้ก่อนงานรอบนี้และ มีบางข้อที่ล้าสมัยแล้ว — ถ้าอ่านแล้วขัดกับเอกสารชุดนี้ ให้ยึดชุดนี้ เพราะอ้างอิงโค้ดที่ merge แล้วตรง ๆ - เอกสารชุดนี้ ไม่มีค่าคีย์ ไม่มี secret จริง สักตัว ทุกที่ที่ต้องใช้คีย์จะเป็นคำสั่ง generate ของตัวเอง