นโยบายอิงอัตลักษณ์เทียบกับนโยบายอิงทรัพยากร

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

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

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

นโยบายบักเก็ต S3 นี้ให้บัญชีอื่นมีสิทธิ์อ่าน Principal จะระบุบัญชีที่เชื่อถือได้ ซึ่งมีเพียงนโยบายตามทรัพยากรเท่านั้นที่ทำได้

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

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

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

ไม่ใช่ทุกบริการที่รองรับนโยบายตามทรัพยากร บริการสำคัญที่รองรับ ได้แก่ S3, KMS, SQS, SNS, Lambda, Secrets Manager และ ECR เมื่อบริการไม่มีนโยบายทรัพยากร จะต้องให้สิทธิ์การเข้าถึงข้ามบัญชีผ่านการรับบทบาทแทน การสอบอาจทดสอบว่าวิธีที่เลือกนั้นเป็นไปได้จริงสำหรับบริการหนึ่ง ๆ หรือไม่

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

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

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

ทดสอบความเข้าใจเรื่องการให้เหตุผลเกี่ยวกับประเภทนโยบายของคุณ

นโยบายตามตัวตนจะแนบกับ Principal และไม่มีองค์ประกอบ Principal ส่วนนโยบายตามทรัพยากรจะแนบกับทรัพยากรและระบุ Principal การเข้าถึงภายในบัญชีเดียวกันเป็นผลรวมของทั้งสองประเภท ส่วนการเข้าถึงข้ามบัญชีต้องให้ทั้งสองประเภทอนุญาต มีเพียงบางบริการเท่านั้น (S3, KMS, SQS, SNS, Lambda, Secrets Manager, ECR) ที่รองรับนโยบายทรัพยากร มิฉะนั้นให้ใช้การรับบทบาท