การแก้ไขอัตโนมัติผ่านกฎ Config

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

การแก้ไขของ Config ขับเคลื่อนด้วยเอกสารการทำงานอัตโนมัติของ AWS Systems Manager (SSM) ซึ่งเรียกอีกอย่างว่าสมุดปฏิบัติการ AWS มีเอกสารที่กำหนดไว้ล่วงหน้าจำนวนมาก เช่น เอกสารสำหรับปิดการเข้าถึงแบบสาธารณะของบักเก็ต S3 หรือเข้ารหัสโวลุ่ม เอกสารจะกำหนดขั้นตอนที่ต้องดำเนินการอย่างชัดเจนเพื่อทำให้ทรัพยากรกลับมาปฏิบัติตามข้อกำหนด

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

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

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

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

รูปแบบคลาสสิกคือจับคู่กฎ s3-bucket-public-read-prohibited กับสมุดปฏิบัติการแก้ไขที่ใช้ Block Public Access กับบักเก็ตใด ๆ ที่ถูกระบุว่าเป็นสาธารณะ ทันทีที่มีผู้เปิดเผยบักเก็ต Config จะตรวจจับและสมุดปฏิบัติการจะทำให้บักเก็ตกลับมาปลอดภัยอีกครั้ง โดยมักใช้เวลาเพียงไม่กี่นาทีและไม่ต้องมีผู้ปฏิบัติงานเข้ามาเกี่ยวข้อง

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

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

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

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

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