เริ่มจัดระเบียบ AWS Access Key ระหว่างเตรียมรับการตรวจ ISMS: บันทึกการเปลี่ยนมาใช้การยืนยันตัวตนแบบอิง Role

บทความนี้สรุปประสบการณ์การตรวจสอบ Access Key ที่สะสมอยู่ในบัญชี AWS ระหว่างกระบวนการเตรียมรับการตรวจติดตามหลังการรับรอง ISMS และการเปลี่ยนมาใช้การยืนยันตัวตนแบบอิง Role

ที่มาของการนำมาใช้

• เมื่อเปิดดู IAM console พบว่า Access Key กระจายอยู่หลายจุด ทั้งใน CI/CD, สคริปต์ดีพลอย, การพัฒนาในเครื่อง ฯลฯ และติดตามได้ยากว่าใช้อยู่ที่ไหนและอย่างไร
• Access Key คงอยู่ได้โดยไม่มีวันหมดอายุ และหากถูกขโมย สิทธิ์ที่ได้รับก็จะถูกเปิดเผยตามนั้น จึงมีความเสี่ยงสูง
• AWS เองก็แนะนำให้ใช้ข้อมูลรับรองชั่วคราว (Role/STS) แทนข้อมูลรับรองระยะยาว (Access Key)

ปัญหา

• เมื่อคีย์ถูกคัดลอกไปใช้ตามที่ต่าง ๆ ก็ยากที่จะตอบได้ว่า “ถ้าคีย์นี้ถูกขโมย จะกระทบไปได้ถึงไหน?”
• หากจะหมุนเวียนคีย์ ต้องแก้การตั้งค่าที่กระจัดกระจายพร้อมกัน และ IAM User หนึ่งคนมักมีสิทธิ์หลายการใช้งานรวมกัน ทำให้บังคับใช้หลักสิทธิ์น้อยที่สุดได้ยาก
• ตอนนั้น IAM User สำหรับ CI/CD ตัวเดียวมีสิทธิ์สำหรับ ECR/S3/SSM/ECS deployment รวมอยู่ด้วยกันทั้งหมด

วิธีที่เปลี่ยนไปใช้ (สรุป)

• Assume Role: วิธีการยืมสิทธิ์ของ Role อื่นมาใช้ชั่วคราวในเวลาที่จำเป็น
• OIDC Web Identity: วิธีการรับ Role ด้วย ID ของระบบภายนอก เช่น GitHub Actions/EKS(=IRSA)
• Instance Profile: วิธีการผูก Role เข้ากับ EC2/Lambda โดยตรง เพื่อให้มีสิทธิ์โดยอัตโนมัติ

ขั้นตอนการเปลี่ยนจริง

• ขั้นที่ 1: แยกสิทธิ์ของ IAM User ที่ผูกกับนโยบายแบบกว้างออกเป็น Role ตามการใช้งาน (ECR push/pull, ECS deployment, S3 cache ฯลฯ)
• ขั้นที่ 2: ใช้ OIDC กับ GitHub Actions (ลงทะเบียน Identity Provider → จำกัดขอบเขต repo ด้วยเงื่อนไขใน Trust Policy → ใช้ configure-aws-credentials ใน workflow)

ผลลัพธ์

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

สิ่งที่ต้องระวัง

• อย่ากำหนดเงื่อนไขใน Trust Policy กว้างเกินไป ให้จำกัดขอบเขตให้น้อยที่สุด (org/repo และถ้าเป็นไปได้ให้ถึงระดับ branch)
• อย่าลบ Access Key เดิมทันที หลังเปลี่ยนแล้วควรปิดใช้งานและมีช่วงตรวจสอบก่อน แล้วค่อยลบ