http://158.108.32.49/wiki/index.php?action=history&feed=atom&title=01204223%2Fsecrets_overview
01204223/secrets overview - ประวัติรุ่นแก้ไข
2026-04-15T00:17:02Z
ประวัติรุ่นแก้ไขของหน้านี้ในวิกิ
MediaWiki 1.33.1
http://158.108.32.49/wiki/index.php?title=01204223/secrets_overview&diff=60040&oldid=prev
Jittat: สร้างหน้าด้วย "== แนวปฏิบัติทั่วไปในการจัดการ ''secrets'' (รหัสผ่าน / API keys) สำหรับ..."
2026-02-26T16:08:14Z
<p>สร้างหน้าด้วย "== แนวปฏิบัติทั่วไปในการจัดการ ''secrets'' (รหัสผ่าน / API keys) สำหรับ..."</p>
<p><b>หน้าใหม่</b></p><div>== แนวปฏิบัติทั่วไปในการจัดการ ''secrets'' (รหัสผ่าน / API keys) สำหรับเว็บแอป Flask + React ==<br />
<br />
: ''เขียนโดย chatgpt''<br />
<br />
=== หลักคิดพื้นฐาน ===<br />
<br />
* '''ห้ามฝัง secret ลงในโค้ด''' (รวมถึง commit เข้า git, paste ลง issue, หรือส่งในแชต)<br />
* '''ให้สิทธิ์เท่าที่จำเป็น (least privilege)''' เช่น key ที่ใช้เรียก API แค่ read ก็อย่าให้ write<br />
* '''แยกสภาพแวดล้อม (dev / staging / prod)''' และใช้ secret คนละชุดเสมอ<br />
* '''หมุนคีย์ได้ (rotation)''' ออกแบบให้เปลี่ยน key/รหัสผ่านแล้วระบบรันต่อได้ ไม่ต้อง deploy แบบเสี่ยง ๆ<br />
* '''ทุกอย่างที่อยู่ฝั่ง client ถือว่า “เปิดเผยได้”''' เพราะ React build แล้วผู้ใช้สามารถดูไฟล์ JS ได้<br />
<br />
=== ทำความเข้าใจ “อะไรเป็น secret” ในสถาปัตยกรรม Flask + React ===<br />
==== อะไรที่ควรอยู่ฝั่ง Backend (Flask) เท่านั้น ====<br />
<br />
* รหัสผ่าน DB, connection string<br />
* API key ของบริการภายนอกที่มีสิทธิ์ “ทำอะไรได้จริง” (เช่น จ่ายเงิน, ส่งอีเมล, อ่านข้อมูลส่วนตัว)<br />
* JWT signing key / session secret / Flask SECRET_KEY<br />
* Private keys (เช่น OAuth client secret, service account key)<br />
<br />
==== อะไรที่ “ไม่ใช่ secret” และอยู่ฝั่ง Frontend ได้ ====<br />
<br />
* ค่า config ที่เป็น public เช่น base URL, feature flag บางชนิด, public analytics key (ที่ผู้ให้บริการออกแบบให้เปิดเผยได้)<br />
* OAuth '''client id''' มักไม่ถือเป็น secret (แต่ '''client secret''' เป็น secret)<br />
<br />
=== Git และการป้องกันการหลุดเข้าระบบควบคุมเวอร์ชัน ===<br />
<br />
ใส่ไฟล์ secret ใน ''.gitignore'' เช่น<br />
<br />
* ''.env''<br />
* ''config.local.json''<br />
* ''.pem'', ''.key''<br />
<br />
ใช้ ''pre-commit hook'' หรือเครื่องมือสแกน secret เพื่อกันพลาด (เช่นตรวจพบ pattern ของ key ก่อน commit)<br />
<br />
ถ้าเผลอ commit ไปแล้ว:<br />
<br />
* ถือว่า secret “รั่ว” แล้ว (แม้จะ revert ก็ยังอยู่ใน history)<br />
* รีบ '''revoke/rotate''' key<br />
* พิจารณา rewrite history (แต่ต้องเข้าใจผลกระทบกับทีม)<br />
<br />
=== การเก็บ secret ระหว่าง Development ===<br />
==== ใช้ Environment Variables ====<br />
แนวทางที่พบบ่อยสุดคือเก็บ secret ใน environment variables แล้วให้ Flask อ่านจาก env<br />
<br />
ข้อดี: ไม่ต้องใส่ลงโค้ด, แยก env ได้ง่าย<br />
<br />
ข้อควรระวัง: อย่า log ค่า env ออกมา, และอย่าให้ dump env ใน error page<br />
<br />
==== ใช้ไฟล์ .env ในเครื่องตัวเอง (dev only) ====<br />
<br />
ใช้ ''.env'' สำหรับ dev และใส่ลง ''.gitignore''<br />
<br />
ทำไฟล์ตัวอย่าง ''(.env.example)'' ที่ไม่มี secret จริง เช่น<br />
<br />
''DATABASE_URL=postgresql://USER:PASSWORD@HOST/DB'' (ใส่ placeholder)<br />
''STRIPE_SECRET_KEY=...'' (placeholder)<br />
<br />
=== การเก็บ secret ใน Production ===<br />
==== ใช้ Secret Manager ของแพลตฟอร์ม ====<br />
แนวปฏิบัติทั่วไป:<br />
<br />
* Docker/Kubernetes: ใช้ ''Kubernetes Secrets'' + mount เป็น env หรือไฟล์<br />
* Cloud: ใช้ secret manager (เช่น AWS/GCP/Azure) แล้วดึงตอนรัน<br />
* PaaS: ตั้งค่า secret ผ่าน dashboard/CLI (เช่น environment config ของ platform)<br />
<br />
หลักสำคัญ:<br />
<br />
* จำกัดสิทธิ์การเข้าถึง secret manager ให้เฉพาะ service account ของแอป<br />
* audit log ได้ว่าใคร/อะไรเข้าถึง secret<br />
<br />
==== หลีกเลี่ยงการวาง secret ไว้ใน image/build artifact ====<br />
<br />
อย่า bake secret เข้า Docker image<br />
<br />
อย่าให้ขั้นตอน build ของ React รับ secret จริง (เพราะจะถูก bundle ลงไฟล์ JS)<br />
<br />
=== Flask: จุดที่เกี่ยวกับ secret โดยตรง ===<br />
==== Flask SECRET_KEY และ session security ====<br />
<br />
ตั้งค่า ''SECRET_KEY'' จาก env<br />
<br />
ห้ามใช้ค่าเดิมระหว่างหลาย environment<br />
<br />
หมุนคีย์แล้วกระทบ session (ผู้ใช้อาจถูก logout) — ถือเป็นเรื่องปกติ<br />
<br />
==== Database credentials / connection string ====<br />
<br />
อ่านจาก env เช่น ''DATABASE_URL''<br />
<br />
ให้ DB user มีสิทธิ์เท่าที่ต้องใช้ (แยก read/write ถ้าทำได้)<br />
<br />
==== JWT / OAuth / API signing keys ====<br />
<br />
เก็บ private/signing key ฝั่ง backend เท่านั้น<br />
<br />
แยก key ต่อ environment<br />
<br />
พิจารณาใช้ key id (kid) เพื่อรองรับ rotation หลายคีย์พร้อมกัน<br />
<br />
=== React: สิ่งที่ต้องระวังเป็นพิเศษ ===<br />
==== ทุกอย่างที่อยู่ใน React build “ไม่ลับ” ====<br />
<br />
ค่าใน ''process.env'' ที่ถูก inject ตอน build จะไปอยู่ใน bundle<br />
<br />
ต่อให้ obfuscate ก็ยังดึงได้<br />
<br />
==== ถ้าต้องเรียกบริการภายนอก ให้ทำผ่าน Backend เป็น proxy ====<br />
ตัวอย่างสถานการณ์:<br />
<br />
React ต้องเรียก API ที่ต้องใช้ secret → ให้ React เรียก Flask ก่อน แล้ว Flask ใส่ secret เรียกต่อ <br />
<br />
จะได้ควบคุม:<br />
* rate limit<br />
* validation<br />
* logging/audit<br />
* permission ตาม user<br />
<br />
==== การตั้งค่าฝั่ง frontend แบบปลอดภัย ====<br />
<br />
เก็บเฉพาะ public config เช่น ''REACT_APP_API_BASE_URL''<br />
<br />
ถ้าต้องการ runtime config ให้เสิร์ฟไฟล์ config จาก backend (ที่ไม่มี secret) แทนการ bake ตอน build<br />
<br />
=== การส่ง secret ระหว่างบริการ (backend ↔ external services) ===<br />
<br />
* ใช้ HTTPS เสมอ<br />
* ตั้ง timeout และ retry policy (ลดโอกาสหลุด log แปลก ๆ)<br />
* อย่าใส่ secret ใน query string (URL) เพราะอาจหลุดใน:<br />
** server access logs<br />
** browser history<br />
** referrer headers<br />
<br />
=== Logging / Monitoring / Error handling ===<br />
<br />
* '''อย่า log secret''' (รวมถึง request headers เช่น ''Authorization'')<br />
<br />
* ทำ ''redaction'' ใน logger:<br />
** mask token เหลือท้าย 4 ตัว<br />
** remove fields เช่น ''password'', ''api_key'', ''secret''<br />
<br />
* ระวัง error page / stack trace ใน production:<br />
** ปิด debug mode<br />
** จัดการ exception แล้วตอบ error แบบไม่เผยข้อมูลภายใน<br />
<br />
=== การจัดการสิทธิ์และการหมุนคีย์ (Rotation) ===<br />
<br />
* มีนโยบาย rotation เช่น ทุก 60–90 วัน (แล้วแต่ความเสี่ยง)<br />
* รองรับ rollout แบบไม่ downtime:<br />
** backend ยอมรับทั้ง “คีย์เก่าและคีย์ใหม่” ช่วงหนึ่ง (dual keys)<br />
** แล้วค่อย revoke คีย์เก่า<br />
<br />
เก็บประวัติการออกคีย์ / revoke / ผู้รับผิดชอบ<br />
<br />
=== การทดสอบและ CI/CD ===<br />
<br />
* ใน CI ให้ใช้ secret store ของระบบ CI (เช่น GitHub Actions Secrets / GitLab CI Variables)<br />
* แยก secret สำหรับ test/staging โดยเฉพาะ<br />
* ใน unit test หลีกเลี่ยงการใช้ secret จริง:<br />
** mock external API<br />
** ใช้ dummy key ที่ไม่มีสิทธิ์<br />
<br />
=== Checklist แบบสั้น ===<br />
<br />
* ไม่มี secret ใน repo (รวม history)<br />
* ใช้ env vars / secret manager แทน hardcode<br />
* React ไม่มี secret ใด ๆ ใน bundle<br />
* Flask ปิด debug ใน production<br />
* logger มีการ redaction (Authorization/password/api_key)<br />
* แยก secret ต่อ environment + least privilege<br />
* มีแผน rotation/revoke และทำได้จริง<br />
<br />
=== ตัวอย่างโครงสร้างไฟล์ที่พบบ่อย ===<br />
<br />
* ''backend/''<br />
** ''.env'' (ignored)<br />
** ''.env.example'' (commit ได้)<br />
** ''app/config.py'' (อ่านค่าจาก env)<br />
<br />
* ''frontend/''<br />
** ''.env'' (มักไม่ใส่ secret; ถ้ามีให้เป็นแค่ public config)<br />
** ''.env.production'' (ระวัง: ยังถือว่า public หลัง build)<br />
** ''src/config.ts'' (อ่าน public config)<br />
<br />
ถ้าคุณอยากได้ “ตัวอย่าง template” สำหรับ Flask config + วิธีเสิร์ฟ runtime config ให้ React (แบบไม่ bake ตอน build) บอกสแต็กที่ใช้ deploy (เช่น Docker/K8s/Render/Fly/EC2) เดี๋ยวผมเขียนให้เป็นแพตเทิร์นครบชุดได้เลย.</div>
Jittat