พนักงานที่ดูแล API Key ลาออกไปครึ่งปีแล้ว แต่ Key เดิมยังใช้งานอยู่: วางระบบหมุนเวียน Credential ให้ไม่ใช่จุดอ่อนความปลอดภัย

เอเจนซี่ที่ดูแลบัญชีโฆษณาให้ลูกค้าหลายรายแห่งหนึ่งพบเรื่องน่าตกใจตอนตรวจสอบระบบภายใน คือ API key ที่ใช้เชื่อมต่อกับ Meta Conversion API ของลูกค้ารายหนึ่ง ถูกสร้างขึ้นโดยพนักงานที่ลาออกไปแล้วเกือบปี และไม่มีใครในทีมรู้รหัสผ่านของบัญชีที่ใช้สร้าง key นั้นตั้งแต่แรก ถ้า key นี้รั่วไหลหรือถูกใช้ในทางที่ไม่ควร แทบไม่มีใครในทีมปัจจุบันจะรู้วิธีจัดการหรือเพิกถอนสิทธิ์ได้ทันที

เรื่องแบบนี้พบได้บ่อยกว่าที่คิด เพราะการตั้งค่า Conversion API มักทำครั้งเดียวตอนเริ่มโปรเจกต์ แล้วไม่มีใครกลับมาทบทวนอีก credential ที่ควรถูกมองว่าเป็นกุญแจสำคัญของระบบ กลับถูกปฏิบัติเหมือนตั้งค่าแล้วจบ ไม่ต่างจากรหัสผ่าน wifi ที่ตั้งไว้ตอนเปิดร้านแล้วไม่เคยเปลี่ยนอีกเลย

บทความนี้จะอธิบายว่าทำไมการหมุนเวียน credential เป็นเรื่องที่ธุรกิจซึ่งพึ่งพา Conversion API ควรทำเป็นประจำ และจะวางระบบยังไงให้การเปลี่ยน key ไม่ทำให้ข้อมูล Conversion ขาดหายไปช่วงที่กำลังสลับ

ทำไม key เดิมที่ยังใช้งานได้ดี ถึงยังเป็นความเสี่ยง

credential ที่ไม่เคยถูกเปลี่ยนเลย มีความเสี่ยงสะสมตามเวลา ยิ่งอยู่นานเท่าไหร่ ยิ่งมีโอกาสที่มันเคยผ่านมือคนที่ไม่ได้อยู่กับทีมแล้ว ถูกบันทึกไว้ในที่ที่ไม่ปลอดภัย (เช่นแชทกลุ่มหรือไฟล์แชร์ที่ไม่มีการควบคุมสิทธิ์) หรือถูกใช้ในระบบทดสอบที่ความปลอดภัยหย่อนกว่าระบบจริง

อีกประเด็นคือ ถ้า key รั่วไหลจริง โดยไม่มีนโยบายหมุนเวียนเป็นประจำ ทีมมักไม่รู้ตัวจนกว่าจะเห็นความผิดปกติชัดเจน เช่นมี event แปลกปลอมถูกส่งเข้าระบบ หรือได้รับแจ้งเตือนว่าtoken หมดอายุกะทันหัน ซึ่งอาจสายเกินไปแล้วที่จะป้องกันความเสียหาย

หมุนเวียน key ยังไงไม่ให้ข้อมูลขาดช่วง

1. สร้าง key ใหม่ควบคู่กับ key เดิมที่ยังใช้งานอยู่ (แพลตฟอร์มส่วนใหญ่รองรับให้มี key มากกว่าหนึ่งตัวใช้งานพร้อมกันได้ในช่วงเปลี่ยนผ่าน)
2. อัปเดตระบบให้เริ่มใช้ key ใหม่ในการส่งข้อมูล พร้อมเฝ้าดูว่าอัตราส่งสำเร็จยังปกติดีเหมือนตอนใช้ key เดิม
3. เมื่อมั่นใจว่า key ใหม่ทำงานถูกต้องต่อเนื่องอย่างน้อย 24-48 ชั่วโมง ค่อยเพิกถอนสิทธิ์ของ key เดิมอย่างเป็นทางการ
4. บันทึกวันที่หมุนเวียนและใครเป็นผู้ดำเนินการไว้ในระบบ audit เพื่อให้ตรวจสอบย้อนหลังได้ ไม่ต่างจากหลักการที่ใช้ในการเก็บประวัติการเปลี่ยนแปลงข้อมูลสำคัญ

ควบคุมว่าใครเข้าถึง credential ได้บ้าง

• จำกัดจำนวนคนที่เข้าถึง key จริงให้น้อยที่สุดเท่าที่จำเป็น ไม่ใช่แชร์ให้ทุกคนในทีมเพื่อความสะดวก
• ใช้ระบบจัดเก็บ secret โดยเฉพาะ (secret manager) แทนการวาง key ไว้ในไฟล์โค้ดหรือแชทกลุ่มตรง ๆ เพราะไฟล์โค้ดมักถูกแชร์หรือสำรองไว้หลายที่โดยไม่รู้ตัว ควรใช้ร่วมกับหลักการกำหนดสิทธิ์ตามบทบาท เพื่อจำกัดวงคนที่แตะต้อง credential ได้จริง
• ทุกครั้งที่มีคนออกจากทีมหรือเปลี่ยนบทบาทที่เกี่ยวข้องกับระบบ tracking ควรหมุนเวียน key ทันที ไม่ต้องรอถึงรอบทบทวนปกติ

ควรหมุนเวียนบ่อยแค่ไหน

ไม่มีตัวเลขตายตัวที่ใช้ได้กับทุกธุรกิจ แต่แนวทางทั่วไปคือหมุนเวียน credential หลักอย่างน้อยทุก 6-12 เดือนสำหรับธุรกิจทั่วไป และควรถี่กว่านั้นสำหรับธุรกิจที่มีทีมงานเปลี่ยนแปลงบ่อยหรือมีเอเจนซี่ภายนอกเข้าถึงระบบ

สิ่งสำคัญกว่าความถี่คือการมีกระบวนการที่ทำได้จริงโดยไม่กระทบข้อมูล เพราะถ้ากระบวนการยุ่งยากจนทีมกลัวจะทำ สุดท้ายก็จะไม่มีใครหมุนเวียน key จริง ๆ อยู่ดี ไม่ต่างจากรหัสผ่านที่รู้ว่าควรเปลี่ยนแต่ผัดวันเพราะขั้นตอนยุ่งยากเกินไป

สรุป

credential ที่ใช้ส่งข้อมูล Conversion เปรียบเหมือนกุญแจบ้าน ยิ่งใช้กุญแจดอกเดิมนานเท่าไหร่โดยไม่เคยเปลี่ยน ยิ่งมีความเสี่ยงสะสมที่มองไม่เห็นด้วยตาเปล่า

การวางระบบหมุนเวียนที่ทำได้จริงโดยไม่กระทบข้อมูล ไม่ใช่แค่เรื่องความปลอดภัยเชิงทฤษฎี แต่คือการป้องกันความเสียหายที่อาจเกิดขึ้นแบบไม่มีใครคาดคิดในวันที่ทีมงานเปลี่ยนแปลงไปจากวันที่ตั้งค่าครั้งแรก

• credential ที่ไม่เคยถูกเปลี่ยนเลยมีความเสี่ยงสะสมตามเวลา ต่อให้ยังใช้งานได้ปกติ
• หมุนเวียน key แบบมี key ใหม่คู่ขนานกับเก่าก่อน เพื่อไม่ให้ข้อมูลขาดช่วง
• จำกัดจำนวนคนที่เข้าถึง credential และหมุนเวียนทันทีเมื่อมีคนออกจากทีม

คำถามที่พบบ่อย