SCP ทำงานร่วมกับสิทธิ์ IAM อย่างไร

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

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

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

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

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

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

ลองนึกภาพว่านโยบาย IAM มอบสิทธิ์ s3:* และ ec2:* ขอบเขตสิทธิ์อนุญาตเฉพาะ s3:* และ SCP อนุญาตเฉพาะ s3:GetObject สิทธิ์ที่มีผลจริงจึงมีเพียง s3:GetObject ซึ่งเป็นส่วนตัดกันของทั้งสามชั้น แต่ละเพดานจะลดขอบเขตสิทธิ์ลงไปอีก

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

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

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

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

ทดสอบตรรกะการทำงานร่วมกัน

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