ตั้ง MFA ให้ AWS root: อุปกรณ์เดียวไม่พอเมื่อถึงวันกู้บัญชี

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

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

ตรวจบัญชีและช่องทางกู้คืนก่อนเริ่ม

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

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

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

ลงทะเบียนตัวหลักและตัวสำรองให้เป็นคนละทาง

ลงชื่อเข้าใช้ AWS Management Console ด้วย Root user เปิดชื่อบัญชีบนแถบนำทาง แล้วเข้า Security credentials ในส่วน Multi-factor authentication (MFA) เลือก Assign MFA device ตั้งชื่ออุปกรณ์ให้แยกกันได้ และเลือกประเภทที่ทีมดูแลได้จริง การตั้งค่า MFA ให้ root ทำในคอนโซล; สิทธิ์ผู้ดูแลระบบทั่วไปไม่ใช่สิทธิ์สำหรับลงทะเบียนอุปกรณ์แทน root

1. เลือกตัวหลักจาก passkey หรือ security key, แอปยืนยันตัวตนที่สร้างรหัส TOTP หรืออุปกรณ์ TOTP แบบฮาร์ดแวร์ หากใช้ passkey หรือ security key ให้ทำตามขั้นตอนของเบราว์เซอร์จนการลงทะเบียนเสร็จ หากใช้แอป ให้สแกน QR หรือกรอกคีย์ตั้งค่าตามตัวช่วย แล้วป้อนรหัสที่ระบบร้องขอตามลำดับ
2. กลับมาที่ส่วน MFA และเลือก Assign MFA device อีกครั้งเพื่อลงทะเบียนตัวสำรอง ตั้งชื่อที่ช่วยระบุผู้ดูแลหรือสถานที่เก็บในทะเบียนภายในของทีม โดยไม่ใส่รหัสลับหรือภาพ QR ในทะเบียนนั้น
3. เลือกตัวสำรองที่ยังใช้ได้เมื่อจุดที่เก็บตัวหลักเสียหรือเข้าถึงไม่ได้ หากตัวหลักอยู่ในโทรศัพท์ ตัวสำรองอาจเป็น security key ที่เก็บอีกแห่ง หรือวิธีอื่นที่ผู้รับผิดชอบอีกคนหยิบใช้ได้ การมี passkey หลายรายการในคลังเดียวกันควรพิจารณาตามการเข้าถึงคลังนั้นจริง ไม่ใช่นับจำนวนรายการอย่างเดียว
4. ตรวจว่าอุปกรณ์ทั้งสองปรากฏในส่วน MFA ของ root แล้วออกจากเซสชันเพื่อทดสอบการลงชื่อเข้าใช้ด้วยตัวสำรอง อย่าลบอุปกรณ์เดิมที่ยังใช้ได้ก่อนยืนยันว่าตัวใหม่ลงทะเบียนและใช้งานสำเร็จ

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

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

แยกผู้ถือปัจจัยโดยยังมีคนรับช่วง

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

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

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

ทดสอบตัวสำรองและเตรียมทางกู้คืน

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

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

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

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

หยุดใช้ root ประจำและตรวจร่องรอย

เมื่อ MFA พร้อม ให้ใช้อัตลักษณ์ผู้ดูแลใน IAM Identity Center หรือบทบาทที่ได้รับสิทธิ์เหมาะสมกับงานประจำ สงวน root สำหรับงานที่ต้องใช้ข้อมูลรับรอง root จริง และกำหนดผู้อนุมัติก่อนลงชื่อเข้าใช้ การเปิด MFA ไม่ได้ลดสิทธิ์ของ root; การลดจำนวนครั้งที่ต้องใช้จึงช่วยจำกัดโอกาสนำข้อมูลรับรองที่มีอำนาจสูงสุดออกมาใช้งาน

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

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

หลังการทดสอบหรือการใช้ root ที่ได้รับอนุมัติ ให้เทียบเวลาและบัญชีกับเหตุการณ์ใน CloudTrail ตามตัวอย่างเหตุการณ์ลงชื่อเข้าใช้ของ AWS การเข้าคอนโซลของ root ปรากฏเป็น ConsoleLogin พร้อม userIdentity.type เป็น Root และผลใน responseElements โดยเหตุการณ์อาจบันทึกใน us-east-1, us-east-2 หรือ us-west-2 จึงต้องค้นใน Region ที่เกี่ยวข้อง ไม่ใช่เฉพาะ Region ที่ทีมใช้ทรัพยากรเป็นประจำ

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

อ่านเพิ่มเติม:

• ต่อ GitHub Actions เข้า AWS ด้วย OIDC: จำกัดสิทธิ์ถึง repo และ branch
• AWS Activate หรือ Google for Startups: เครดิตสูงสุดแพ้ได้ถ้าใช้ไม่ทัน