ลำดับการตัดสินใจประเมินนโยบาย

เมื่อคำขอใด ๆ มาถึง AWS กลไก IAM จะดำเนินลำดับการประเมินที่แม่นยำเพื่อตัดสินใจว่าจะ Allow หรือ Deny การจดจำลำดับนี้เป็นสิ่งที่คุ้มค่ามากสำหรับการสอบ SCS-C02 เพราะคำถามสถานการณ์ที่ซับซ้อนมักขึ้นอยู่กับว่านโยบายประเภทใดมีผลเหนือกว่าเมื่อมีนโยบายหลายรายการเข้ามาเกี่ยวข้อง

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

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

AWS ประเมินตามลำดับเชิงแนวคิดดังนี้: 1) ตรวจสอบการปฏิเสธอย่างชัดเจนในนโยบายใด ๆ (SCP, ขอบเขตสิทธิ์, ข้อมูลระบุตัวตน, ทรัพยากร, เซสชัน) — หากพบ ให้ปฏิเสธ 2) หากมี SCP ที่เกี่ยวข้องและไม่ได้อนุญาตการดำเนินการ ให้ปฏิเสธ 3) ตรวจสอบขอบเขตสิทธิ์ นโยบายเซสชัน และนโยบายข้อมูลระบุตัวตน/ทรัพยากรว่ามี Allow หรือไม่ ช่องว่างใด ๆ จะส่งผลให้เกิดการปฏิเสธโดยปริยาย

Service Control Policies (SCP) ใน AWS Organizations กำหนดสิทธิ์สูงสุดสำหรับบัญชีหนึ่ง ๆ การดำเนินการจะสำเร็จได้ก็ต่อเมื่อ SCP และนโยบาย IAM อนุญาตการดำเนินการนั้น SCP ไม่เคยมอบสิทธิ์การเข้าถึงด้วยตัวเอง แต่จะกำหนดเพดานหรือปฏิเสธเท่านั้น หาก SCP ไม่อนุญาตการดำเนินการใด ก็ไม่มี Allow จาก IAM ใดช่วยกู้คืนสิทธิ์ได้

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

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

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

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

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

จำรายการตรวจสอบนี้ไว้: (1) มีการปฏิเสธอย่างชัดเจนหรือไม่ ปฏิเสธ (2) SCP อนุญาตหรือไม่ หากไม่ใช่ ให้ปฏิเสธ (3) ขอบเขตสิทธิ์/เซสชันอนุญาตหรือไม่ หากไม่ใช่ ให้ปฏิเสธ (4) มี Allow จากข้อมูลระบุตัวตนหรือทรัพยากรหรือไม่ หากมีและไม่มีการปฏิเสธ ให้อนุญาต มิฉะนั้นให้ปฏิเสธโดยปริยาย ใช้ขั้นตอนนี้อย่างเป็นระบบ แล้วแม้แต่คำถามที่มีหลายนโยบายก็จะตรงไปตรงมา

ทดสอบกระบวนการประเมิน

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