Amazon Inspector สแกนช่องโหว่ EC2 AMI ได้ก่อนเปิด Instance

AWS ประกาศวันที่ 2 พฤศจิกายน 2026 ว่า Amazon Inspector ตรวจหาช่องโหว่ใน EC2 Amazon Machine Image หรือ AMI ได้โดยตรงแล้ว ทีมดูแลระบบจึงประเมิน image ก่อนนำไปเปิด instance ได้ โดยไม่ต้องเปิดเครื่องชั่วคราวหรือติดตั้ง agent เพียงเพื่อสแกน ฟีเจอร์นี้สำคัญกับองค์กรที่ใช้ golden image เป็นฐานของ Auto Scaling, งานประมวลผลเป็นชุด หรือเซิร์ฟเวอร์หลายบัญชี เพราะแพ็กเกจที่มีช่องโหว่ใน image ต้นแบบอาจถูกคัดลอกไปยังเครื่องจำนวนมากก่อนทีมรักษาความปลอดภัยจะเห็นปัญหา

ตรวจที่ต้นทางของเครื่องเสมือน

ที่ผ่านมา Inspector สแกน EC2 instance ที่กำลังทำงานได้ แต่การรอให้เปิด instance จาก AMI ก่อนจึงค่อยพบช่องโหว่ทำให้การแก้ไขช้า รอบนี้ AWS เพิ่มการสแกน AMI ที่บัญชีเป็นเจ้าของโดยอ่าน inventory ของซอฟต์แวร์จาก EBS snapshot ที่รองรับ จึงไม่ต้องติดตั้ง SSM Agent หรือสร้าง instance จาก image เพื่อเริ่มตรวจ อย่างไรก็ตาม ผลสแกน AMI และผลสแกน runtime มีขอบเขตต่างกัน การสแกน image มองเห็นแพ็กเกจที่อยู่ใน snapshot ไม่ได้แทนการตรวจ configuration, process หรือความเสี่ยงที่เกิดหลังเครื่องบูต

ผู้ดูแลระบบเลือกเปิดการประเมินแบบต่อเนื่องสำหรับคลัง AMI เพื่อให้ Inspector ตรวจซ้ำเมื่อมี CVE ที่เกี่ยวข้องใหม่ หรือสั่งสแกนเฉพาะ AMI แบบครั้งเดียวจาก EC2 Console ได้ AWS ระบุว่าสามารถเปิดระดับบัญชีหรือทั่วทั้ง AWS Organizations และส่ง findings ไป AWS Security Hub ได้ การนำผลไปใช้ควรผูกกับทะเบียน image ที่องค์กรแจกจ่ายจริง ไม่ใช่ดูเฉพาะ image ล่าสุด เพราะ AMI รุ่นเก่าอาจยังถูกอ้างถึงใน launch template ของระบบสำคัญ

ผูกผลตรวจเข้ากับขั้นตอนอนุมัติ image

ข่าวของ AWS แนะนำให้ใช้ Allowed AMIs กำหนดเกณฑ์ความปลอดภัยที่ image ต้องผ่านก่อนบัญชีจะมองเห็นและนำไปใช้ และสามารถบังคับนโยบายทั่วองค์กรด้วย Declarative Policies ทีมที่สร้าง AMI ผ่าน EC2 Image Builder สามารถผสานการสแกนใน pipeline แล้วจำกัดการแจกจ่าย image ที่ไม่ผ่านเกณฑ์ได้ คู่มือ CLI ของ Image Builder ระบุโหมด ON_DEMAND_AMI_CVE สำหรับสแกน AMI ผลลัพธ์ในช่วงทดสอบ หากตั้ง scanResultCondition ขั้นทดสอบจะรอผลและให้ build ไม่ผ่านเมื่อ finding เกินระดับที่กำหนด แต่ถ้าไม่ตั้งเงื่อนไขนั้น ระบบเริ่มสแกนโดยไม่รอผลหรือใช้ผลตัดสิน build ประเด็นนี้มีผลต่อความหมายของคำว่า pipeline ผ่านอย่างมาก

ทีมควรเริ่มจากกำหนดเจ้าของของแต่ละ AMI, อายุการใช้งาน, แอปพลิเคชันที่ใช้ image และเกณฑ์ finding ที่ยอมรับได้ จากนั้นทดสอบกับ image รุ่นหนึ่งก่อนบังคับใช้ทั่วองค์กร เพื่อดูว่ามีแพ็กเกจใดต้องอัปเดตใน recipe และมี false positive ที่ต้องประเมินด้วยคนหรือไม่ การแก้ที่ recipe และสร้าง image ใหม่ช่วยลดการแก้เครื่องรายตัวภายหลัง แต่ยังต้องวางแผนเปลี่ยน instance ที่ใช้ AMI เดิม เพราะการสแกนไม่แก้ช่องโหว่ให้เครื่องที่เปิดอยู่โดยอัตโนมัติ

ตรวจขอบเขตการรองรับและค่าใช้จ่าย

AWS ระบุว่าฟีเจอร์มีใน commercial Regions ที่ Amazon Inspector เปิดให้ใช้ แต่ระบบปฏิบัติการและรูปแบบ snapshot ต้องอยู่ในรายการที่ Inspector รองรับ คู่มือ AWS ระบุว่า image บางชนิด เช่น snapshot ที่ใช้ Logical Volume Manager ซึ่งบริการอ่านไม่ได้ อาจขึ้นสถานะ UNSUPPORTED_OS และการตรวจแพ็กเกจ Linux มีข้อจำกัดสำหรับ repository ภายนอก ผู้ดูแลจึงควรตรวจ coverage ของ AMI ทุกตระกูลก่อนถือว่าคลัง image ปลอดภัยทั้งหมด รวมทั้งตรวจราคา Inspector และปริมาณ image ที่จะสแกนต่อเนื่อง

ตัวอย่างการใช้งานจริงคือ pipeline สร้าง AMI รายสัปดาห์สำหรับเว็บเซิร์ฟเวอร์ เมื่อ build เสร็จให้สแกน AMI ใหม่ เทียบ finding กับเกณฑ์ที่ทีมตกลง อนุมัติให้แจกจ่ายเฉพาะรุ่นที่ผ่าน และค่อยอัปเดต launch template พร้อมทดสอบ rollback หาก CVE ใหม่ถูกประกาศระหว่างสัปดาห์ การสแกนแบบต่อเนื่องจะช่วยบอกว่า image ที่เคยผ่านต้องกลับมาสร้างใหม่เมื่อใด วิธีนี้ลดช่วงเวลาที่ image ต้นแบบมีช่องโหว่โดยไม่รู้ตัว และทำให้การปล่อยเครื่องใหม่อาศัยหลักฐานที่ตรวจสอบย้อนหลังได้

แหล่งข่าว: ประกาศ AWS วันที่ 2 พฤศจิกายน 2026, คู่มือระบบและแพ็กเกจที่ Inspector รองรับ และ คำสั่ง Image Builder สำหรับเงื่อนไขผลสแกน