กุญแจ AWS ที่รั่วสู่สาธารณะกว่า 9,300 ดอกยังใช้งานได้หลายปีต่อมา

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

768 คีย์เปิดทางควบคุมบัญชีองค์กรได้เต็มรูปแบบ

ในบรรดาคีย์ที่ยังใช้งานได้และเชื่อมโยงกับบัญชีองค์กร มี 817 ดอกที่ระบุว่าเป็นของบริษัท โดยประกอบด้วย

• คีย์บัญชี root ของ AWS 526 ดอก
• คีย์ของผู้ใช้ IAM 242 ดอก ที่ผูกกับนโยบาย AdministratorAccess
• รวม 768 คีย์ ที่ให้สิทธิ์ควบคุมบัญชี AWS ของบริษัทได้อย่างเต็มรูปแบบ

บัญชี root เป็นระดับสิทธิ์สูงสุดสำหรับลูกค้า AWS ส่วนตัวตน IAM ที่มี AdministratorAccess สามารถดำเนินการกับบริการต่าง ๆ ของ AWS ได้อย่างกว้างขวาง คีย์ที่ยังใช้ได้ในระดับนี้จึงอาจเปิดทางให้ยึดบัญชี สร้างทรัพยากรโดยไม่ได้รับอนุญาต เข้าถึงข้อมูล หรือใช้ทรัพยากรคลาวด์ไปทำกิจกรรมที่สร้างค่าใช้จ่ายสูง เช่น การขุดคริปโต

ประเด็นนี้จึงไม่ใช่แค่เรื่องการลบความลับออกจากซอร์สโค้ด แต่เป็นปัญหาการจัดการสิทธิ์และวงจรชีวิตของข้อมูลรับรองด้วย การลบคีย์ออกจากไฟล์หรือเขียนประวัติ Git ใหม่ไม่ได้ทำให้สำเนาที่มีคนคัดลอกไปแล้วใช้ไม่ได้ คีย์ต้องถูกเพิกถอนหรือหมุนเวียนใหม่

Hugging Face เป็นแหล่งที่พบการเปิดเผยมากที่สุด

Hugging Face เป็นแหล่งเดี่ยวที่พบการเปิดเผยข้อมูลรับรอง AWS มากที่สุด จำนวน 8,482 รายการ และ Truffle Security รายงานว่า 17.9% ของข้อมูลรับรอง AWS เหล่านี้เป็นข้อมูลรับรองระดับ root

ผลดังกล่าวสอดคล้องกับการสแกนข้อมูลสาธารณะบน Hugging Face ในวงกว้าง ซึ่งครอบคลุมข้อมูล 7.6 เพตะไบต์ และพบข้อมูลรับรองที่ยังใช้งานได้ในชุดข้อมูลหลายพันชุด แสดงให้เห็นว่าความลับอาจคงอยู่ภายนอกรีโพสซิทอรีซอฟต์แวร์แบบดั้งเดิม และถูกเผยแพร่ไปพร้อมกับชุดข้อมูลสาธารณะ

สำหรับทีมความปลอดภัย การสแกนเฉพาะซอร์สโค้ดปัจจุบันจึงไม่เพียงพอ ประวัติ Git อาร์ติแฟกต์จากการ build อิมเมจคอนเทนเนอร์ รีจิสทรี ชุดข้อมูลที่เผยแพร่ และเอาต์พุตจาก CI ล้วนเก็บคีย์ไว้ได้ แม้นักพัฒนาจะคิดว่าลบออกแล้วก็ตาม

คีย์จำนวนมากมีอายุหลายปีและแทบไม่เคยถูกหมุนเวียน

อายุคีย์ที่รายงานมีค่ามัธยฐานประมาณ 1,831 วัน หรือเกือบ 5 ปี ส่วนคีย์ที่เก่าที่สุดมีอายุ 17.4 ปี ขณะที่มีเพียง 13.7% ของรายการที่พบคีย์ใหม่กว่าซึ่งเชื่อมโยงกับผู้ใช้รายเดียวกัน สะท้อนว่าคีย์ส่วนใหญ่ไม่เคยผ่านกระบวนการหมุนเวียนตามปกติ

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

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

มีเพียงส่วนน้อยที่เปิดการแจ้งเตือนงบประมาณ

Truffle Security สามารถอ่านข้อมูลบัญชีได้ 2,754 บัญชี แต่มีเพียง 262 บัญชี ที่เปิดใช้การแจ้งเตือนงบประมาณของ AWS

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

การแจ้งเตือนของ AWS ช่วยได้แค่ไหน

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

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

Truffle Security ระบุว่าการทดสอบของตนเป็นแบบ อ่านอย่างเดียว (read-only) โดยตรวจสอบการยืนยันตัวตนและข้อมูลเมตาดาต้าด้านสิทธิ์หรือบัญชี ไม่ได้แก้ไขทรัพยากรของลูกค้า รายละเอียดวิธีการดังกล่าวเป็นคำอธิบายจาก Truffle Security และแหล่งข้อมูลที่มีอยู่ไม่ได้ยืนยันรายละเอียดเชิงปฏิบัติการทุกส่วนอย่างเป็นอิสระ

องค์กรควรทำอย่างไรเมื่อคีย์ AWS รั่ว

1. เพิกถอนหรือหมุนเวียนคีย์ทันที

ลบหรือปิดใช้งานข้อมูลรับรองที่ถูกเปิดเผยต่อสาธารณะ แล้วออกคีย์ใหม่เฉพาะเมื่อยังจำเป็นต้องใช้งาน การลบความลับออกจากรีโพสซิทอรี ลบไฟล์ หรือเขียนประวัติ Git ใหม่ ไม่ได้ทำให้สำเนาที่ถูกคัดลอกไปแล้วใช้ไม่ได้

2. ยกเลิกการใช้ root access key

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

3. ตรวจสอบสิทธิ์และเจ้าของคีย์

ระบุว่าคีย์เป็นของบัญชี ผู้ใช้ บริการ และทรัพยากรใด จากนั้นจัดลำดับความสำคัญให้คีย์ที่มีสิทธิ์ root, AdministratorAccess, สิทธิ์เข้าถึงข้อมูลวงกว้าง หรือสิทธิ์สร้างโครงสร้างพื้นฐาน

4. สืบสวนทั้งก่อนและหลังการเพิกถอน

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

5. เปลี่ยนไปใช้ตัวตนอายุสั้น

หากเป็นไปได้ ให้ใช้ IAM role และ workload identity ที่มีอายุสั้น แทน access key แบบถาวร พร้อมใช้หลักสิทธิ์เท่าที่จำเป็น (least privilege) เพื่อลดความเสียหายหากข้อมูลรับรองรั่ว

6. ตั้งการแจ้งเตือนงบประมาณและช่องทางตอบสนอง

เปิดใช้ AWS Budgets และการตรวจจับความผิดปกติของค่าใช้จ่าย พร้อมส่งการแจ้งเตือนไปยังผู้ที่สามารถลงมือแก้ไขได้อย่างรวดเร็ว การติดตามค่าใช้จ่ายเป็นเพียงแนวป้องกันชั้นเสริม ไม่ใช่สิ่งทดแทนการสแกนความลับ การหมุนเวียนคีย์ และการทบทวนสิทธิ์เข้าถึง

บทเรียนที่ใหญ่กว่าจำนวนคีย์ที่รั่ว

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

แนวทางที่ปลอดภัยกว่าคือให้ถือว่าข้อมูลรับรอง AWS ทุกดอกที่รั่วไหลถูกเจาะแล้ว ตรวจสอบว่าคีย์เข้าถึงอะไรได้บ้าง เพิกถอนหรือหมุนเวียนทันที และแทนที่คีย์ถาวรด้วยตัวตนอายุสั้นที่มีสิทธิ์น้อยที่สุดเท่าที่งานจำเป็น