โปรไฟล์อินสแตนซ์สำหรับเวิร์กโหลด EC2

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

โปรไฟล์อินสแตนซ์คือภาชนะสำหรับบทบาท IAM ที่คุณแนบเข้ากับอินสแตนซ์ EC2 แม้ในเชิงแนวคิดคุณจะกำหนดบทบาท แต่ในทางปฏิบัติ EC2 จะแนบโปรไฟล์อินสแตนซ์ที่ครอบบทบาทนั้นไว้ เมื่อคุณสร้างบทบาทสำหรับ EC2 ในคอนโซล ระบบจะสร้างโปรไฟล์อินสแตนซ์ที่มีชื่อเดียวกันโดยอัตโนมัติ แต่เมื่อใช้ CLI หรือ API คุณอาจต้องสร้างโปรไฟล์นี้อย่างชัดเจน

เมื่อแนบโปรไฟล์อินสแตนซ์แล้ว อินสแตนซ์จะดึงข้อมูลรับรองชั่วคราวจาก Instance Metadata Service (IMDS) ซึ่งเป็นปลายทางแบบลิงก์ภายในเครื่องพิเศษที่ 169.254.169.254 AWS SDK และ CLI จะดึงและต่ออายุข้อมูลรับรองเหล่านี้อย่างโปร่งใส ดังนั้นโค้ดของแอปพลิเคชันจึงไม่ต้องจัดการคีย์เลย

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

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

บริการข้อมูลเมตารุ่นเดิม (IMDSv1) อาจถูกใช้ในทางที่ผิดผ่านการโจมตีแบบ SSRF (การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์) เพื่อขโมยข้อมูลรับรองของบทบาท IMDSv2 กำหนดให้ต้องขอโทเค็นเซสชันผ่านคำขอแบบ PUT ก่อน ซึ่งช่วยป้องกันการโจมตี SSRF ส่วนใหญ่ การสอบคาดหวังให้คุณบังคับใช้ IMDSv2 และควรตั้งขีดจำกัดการกระโดดเป็น 1 เพื่อป้องกันไม่ให้คอนเทนเนอร์เข้าถึงบริการนี้

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

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

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

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

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

ตรวจสอบความรู้เกี่ยวกับโปรไฟล์อินสแตนซ์ของคุณ

โปรไฟล์อินสแตนซ์ครอบบทบาท IAM และแนบบทบาทนั้นเข้ากับ EC2 พร้อมส่งมอบข้อมูลรับรองชั่วคราวที่หมุนเวียนโดยอัตโนมัติผ่านบริการข้อมูลเมตาของอินสแตนซ์ วิธีนี้จะลบคีย์แบบคงที่ออกไปทั้งหมด ให้บังคับใช้ IMDSv2 และขีดจำกัดการกระโดดเป็น 1 เพื่อป้องกันการขโมยข้อมูลรับรองผ่าน SSRF จำกัดขอบเขตบทบาทตามหลักสิทธิ์น้อยที่สุด และตรวจสอบเซสชันของบทบาทนั้นใน CloudTrail