การเปิดใช้ GuardDuty ทั่วทั้งองค์กร

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

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

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

บัญชีการจัดการของ Organizations มีความอ่อนไหวอย่างยิ่ง ดังนั้น AWS จึงแนะนำให้ใช้บัญชีนี้สำหรับการเรียกเก็บเงินและการจัดการบัญชีเท่านั้น การมอบหมายการจัดการด้านความปลอดภัยให้บัญชีแยกต่างหากช่วยจำกัดขอบเขตความเสียหายและแยกหน้าที่รับผิดชอบ ซึ่งเป็นแนวทางปฏิบัติที่ดีของ Well-Architected ที่การสอบให้ความสำคัญ

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

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

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

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

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

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

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

นำการตรวจจับไปใช้ทั่วทั้งองค์กร

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