Secrets Management: หยุดฝังรหัสผ่านและ API Key ไว้ในโค้ด

รหัสผ่านฐานข้อมูลและ API Key ที่ฝังอยู่ในโค้ด คือระเบิดเวลาที่รั่วได้ทุกเมื่อ เมื่อโค้ดหลุดออกไป บทความนี้อธิบายว่าทำไมความลับไม่ควรอยู่ในโค้ด และจะจัดการอย่างปลอดภัยได้อย่างไร
ความลับของระบบ เช่น รหัสผ่านฐานข้อมูล กุญแจเชื่อมต่อบริการภายนอก และโทเคนต่าง ๆ มักถูกฝังไว้ในโค้ดเพราะสะดวก แต่นั่นหมายความว่าใครก็ตามที่เห็นโค้ด ไม่ว่าจะอดีตพนักงาน ผู้รับเหมา หรือคนที่เจาะ repository ได้ ก็ได้กุญแจของทั้งระบบไปด้วย และความลับที่หลุดในโค้ด มักหลุดถาวรเพราะอยู่ในประวัติการแก้ไขตลอดไป
ทำไมการลบทีหลังไม่พอ
หลายคนคิดว่าถ้าเผลอ commit รหัสผ่านไป ก็แค่ลบออกแล้วจบ แต่ระบบ version control เก็บทุกการเปลี่ยนแปลงไว้ ความลับยังอยู่ในประวัติให้ค้นเจอได้ วิธีที่ถูกคือถือว่าความลับนั้นรั่วแล้ว ต้องเปลี่ยน (rotate) ทันที ไม่ใช่แค่ลบบรรทัดออก
แนวทางจัดการความลับที่ปลอดภัย
- เก็บความลับใน secret manager หรือ environment variable ไม่ใช่ในโค้ด
- ให้สิทธิ์เข้าถึงความลับเท่าที่จำเป็น และบันทึกว่าใครเข้าถึงเมื่อไร
- ตั้งรอบเปลี่ยนความลับเป็นระยะ และเปลี่ยนทันทีเมื่อมีคนออกจากทีม
- ใช้เครื่องมือสแกนหา secret ที่หลุดเข้า repository โดยอัตโนมัติ
การจัดการความลับที่ดีไม่ได้ทำให้ระบบช้าลงหรือยุ่งยากขึ้นอย่างที่กลัว แต่เปลี่ยนความลับจากระเบิดเวลาที่ฝังอยู่ทุกที่ ให้เป็นสิ่งที่ควบคุม เปลี่ยน และตามรอยได้ ซึ่งเป็นพื้นฐานที่องค์กรจริงจังเรื่องความปลอดภัยต้องมี
บริการที่เกี่ยวข้อง
รับพัฒนาระบบและซอฟต์แวร์เฉพาะทาง
ออกแบบและวางระบบตามความต้องการเฉพาะของธุรกิจคุณ ตั้งแต่ต้นจนใช้งานจริง
WhaleScope
ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope
รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล
อ่านต่อ

Containerization: แพ็กแอปให้รันเหมือนกันทุกที่
ปัญหาคลาสสิกคือ บนเครื่องผมมันรันได้ แต่ขึ้นเซิร์ฟเวอร์กลับพัง Containerization แก้ด้วยการแพ็กแอปพร้อมทุกอย่างที่ต้องใช้ ให้รันเหมือนกันทุกที่ ลดปัญหาความต่างของสภาพแวดล้อม

Infrastructure as Code: จัดการโครงสร้างพื้นฐานด้วยโค้ด ไม่ใช่กดมือทีละครั้ง
การตั้งค่าเซิร์ฟเวอร์ด้วยมือทีละครั้ง ทำให้ทำซ้ำยาก ผิดพลาดง่าย และไม่มีใครรู้ว่าใครเปลี่ยนอะไร Infrastructure as Code เปลี่ยนการตั้งค่าให้เป็นโค้ดที่ตรวจสอบ ทำซ้ำ และย้อนกลับได้

Canary Deployment: ปล่อยของใหม่ให้คนกลุ่มเล็กก่อน ลดความเสี่ยงทั้งระบบ
ปล่อยเวอร์ชันใหม่ให้ผู้ใช้ทุกคนพร้อมกัน คือเดิมพันก้อนใหญ่ Canary Deployment ปล่อยให้คนกลุ่มเล็กก่อน เฝ้าดูสัญญาณ แล้วค่อยขยาย ถ้ามีปัญหาจะกระทบแค่กลุ่มเล็กและถอยกลับได้เร็ว

Blue-Green Deployment: เตรียมสนามใหม่ให้พร้อม แล้วสลับทั้งระบบในวินาทีเดียว
การอัปเดตระบบทับของเดิมตรง ๆ คือช่วงเวลาอันตรายที่ถอยกลับยาก Blue-Green รันระบบสองชุดคู่กัน ปล่อยเวอร์ชันใหม่ลงชุดที่ว่าง ทดสอบจนมั่นใจ แล้วค่อยสลับผู้ใช้ไปทั้งหมด ถ้ามีปัญหาก็สลับกลับได้ทันที
