Client API Key Lite: ออกแบบระบบ Service to Service
แนวทางออกแบบ Client API Key แบบ Light สำหรับระบบ Service to Service ด้วยตารางฐานข้อมูล 6 คอลัมน์และโค้ด 10 บรรทัด ปลอดภัยและรองรับ Key Rotation
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ออกแบบ API Key สำหรับ Service to Service ด้วยตาราง 6 คอลัมน์และฟังก์ชันสิบบรรทัด
- เก็บค่า SHA-256 Hash แทนการเก็บ Plain Text เพื่อป้องกันความเสี่ยงเมื่อฐานข้อมูลรั่วไหล
- ใช้ revoked_at แทนการใช้ UNIQUE บน Consumer เพื่อรองรับ Key Rotation แบบไม่มี Downtime
- แยกส่วน Resolver ออกจาก Framework Middleware เพื่อความยืดหยุ่นในการปรับปรุงโค้ดในอนาคต
การเชื่อมต่อระหว่าง Service ภายในองค์กรเมื่อมีทีมอื่นขอเข้ามาเรียกใช้งาน สิ่งสำคัญคือการระบุตัวตนของผู้ใช้งานให้แน่ชัด ทางเลือกทั่วไปมักหนีไม่พ้นการฝัง Random UUID หรือ Hash ไว้ใน Environment Variable ซึ่งใช้งานได้ดีจนกระทั่งเกิดเหตุการณ์ข้อมูลรั่วไหล หรืออีกทางเลือกคือการดึง OAuth2 เข้ามาใช้งานซึ่งซับซ้อนเกินความจำเป็น บทความนี้นำเสนอแนวทางสายกลางที่เรียกว่า Light Design
ดีไซน์นี้มุ่งเน้นไปที่กรณี Service to Service เท่านั้น ไม่ใช่ Key ที่ผู้ใช้ปลายทางสร้างขึ้นเองจากหน้าเว็บ โดยอาศัยสมิษฐาน 3 ข้อที่ทำให้การออกแบบมีขนาดเล็กได้ หากเป็น Public API ที่เปิดกว้าง สมิษฐานเหล่านี้จะใช้ไม่ได้และต้องอาศัย Rate Limit, หน้าจัดการ Key, วันหมดอายุ รวมถึงระบบสิทธิ์ที่ซับซ้อนยิ่งขึ้น
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
การออกแบบระบบรักษาความปลอดภัยในระยะเริ่มต้นมักเผชิญทางเลือกระหว่างความเรียบง่ายกับความซับซ้อน การเลือกใช้ Light Design ช่วยลดภาระทางวิศวกรรมในวันแรก แต่ต้องอาศัยการวางรากฐานโครงสร้างฐานข้อมูลที่ถูกต้อง เพื่อป้องกันภาระหนี้ทางเทคนิค (Technical Debt) ที่ต้องแก้ไขในอนาคต
โครงสร้างตารางฐานข้อมูล 6 คอลัมน์ประกอบด้วย:
- id INT AUTO_INCREMENT PRIMARY KEY
- consumer VARCHAR(100) NOT NULL (ห้ามตั้งค่า UNIQUE)
- key_hash CHAR(64) NOT NULL UNIQUE (ค่า SHA-256 Hex ของ Key เต็ม)
- revoked_at DATETIME NULL
- description VARCHAR(255) (บันทึกเลขตั๋วและผู้ขอ)
- created_at และ updated_at สำหรับบันทึกเวลา
การตัดสินใจสำคัญจุดแรกคือการไม่เก็บ Key ตรงๆ ในฐานข้อมูล เพราะอาจเสี่ยงต่อการหลุดรั่วผ่านไฟล์ Database Dump บนเครื่องนักพัฒนา การเก็บค่า SHA-256(key) และทำ Hash ค่าวัดผลตอน Authenticate ช่วยตัดความซับซ้อนของการใช้ Bcrypt เนื่องจากค่าที่สุ่มมา 256 บิตมีความปลอดภัยสูงพออยู่แล้ว
จุดสำคัญถัดมาคือการใช้คอลัมน์ revoked_at แบบ Timestamp เพื่อตรวจสอบสถานะและการเพิกถอน พร้อมเงื่อนไข AND revoked_at IS NULL ในตัว SQL Query โดยตรงเสมอ ห้ามกรองในโค้ดฝั่งแอปพลิเคชันเพื่อป้องกันข้อผิดพลาดในอนาคต
"สิ่งที่ UNIQUE ตรงนี้แปลว่า คุณหมุน key (key rotation) ไม่ได้ เพราะ key rotation ที่ปลอดภัยต้องมีช่วงที่ key เก่ากับใหม่ใช้ได้พร้อมกัน"
ผู้เขียนบทความบน Dev.to
การละเว้นการใส่ UNIQUE บนคอลัมน์ consumer เปิดทางให้สามารถทำ Key Rotation ได้อย่างราบรื่นโดยไม่มี Downtime ผ่านกระบวนการแทรก Key ใหม่ ให้ฝั่ง Consumer สลับไปใช้งาน ตรวจสอบว่าไม่มี Traffic เหลือที่ Key เก่า แล้วจึงทำการ Revoke Key เก่าทิ้งในภายหลัง
ในส่วนของการสร้าง Key มีรูปแบบคำสั่งที่ต้องระวังการใช้ printf แทน echo เพื่อป้องกันการขึ้นบรรทัดใหม่ที่ทำให้ค่า Hash เปลี่ยนแปลง และควรส่งมอบค่าผ่าน Secret Manager ของฝั่ง Consumer โดยตรง ไม่ควรส่งผ่านช่องทางแชทหรืออีเมลเพื่อความปลอดภัยสูงสุด
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น