การประเมินนโยบาย IAM และการปฏิเสธแบบชัดเจน

การใช้ AWS Security สำหรับนักพัฒนา

Rahul Singh

Technical Product Manager

นโยบายคือรายการของกฎ

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

สามฟิลด์ของคำสั่ง IAM หนึ่งรายการเรียงซ้อนกันบนแกนเดียว กำกับหมายเลขหนึ่งถึงสาม ได้แก่ Effect คือ allow หรือ deny, Action คือ API call ใด และ Resource คือสิ่งที่ชี้ไป ซึ่งระบุด้วย ARN

นโยบายคือรายการของกฎ

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "true"
    },
    "IpAddress": {
      "aws:SourceIp": "203.0.113.0/24"
    }
  }
}

สี่ฟิลด์ของคำสั่ง IAM หนึ่งรายการเรียงซ้อนกันบนแกนเดียว กำกับหมายเลขหนึ่งถึงสี่ ได้แก่ Effect คือ allow หรือ deny, Action คือ API call ใด, Resource คือสิ่งที่ชี้ไปซึ่งระบุด้วย ARN และ Condition คือเงื่อนไขที่ต้องตรงกัน บรรทัดปิดท้ายระบุว่า สี่ฟิลด์ หนึ่งกฎ

สามฟิลด์ถาม หนึ่งฟิลด์ตอบ

คำถาม

Action: นี่คือ call ที่ใช่หรือไม่
Resource: นี่คือเป้าหมายที่ใช่หรือไม่
Condition: เงื่อนไขตรงกันหรือไม่

คำตอบ

Effect: allow หรือ deny

สี่ฟิลด์ของคำสั่ง IAM เรียงซ้อนกันในแนวตั้ง: Action, Resource และ Condition ถูกจัดกลุ่มด้วยวงเล็บหนึ่งที่มีป้ายกำกับ "คำถาม" ส่วน Effect ถูกจัดกลุ่มด้วยวงเล็บที่สองที่มีป้ายกำกับ "คำตอบ"

กฎมาจากมากกว่าหนึ่งแหล่ง

เอกสารนโยบายที่แนบกับ role โดยมีลูกศรจาก role ไปยัง bucket

Identity-based

แนบกับ role
role นี้ทำอะไรได้บ้าง

กฎมาจากมากกว่าหนึ่งแหล่ง

เอกสารนโยบายที่แนบกับ role โดยมีลูกศรจาก role ไปยัง bucket

เอกสารนโยบายที่แนบกับ resource โดยมีลูกศรจาก principal ไปยัง bucket

Identity-based

แนบกับ role
role นี้ทำอะไรได้บ้าง

Resource-based

แนบกับสิ่งที่ถูกเข้าถึง
ใครเข้าถึง bucket นี้ได้บ้าง

เมื่อกฎขัดแย้งกัน

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

เมื่อกฎขัดแย้งกัน

{"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
{"Effect": "Deny",  "Action": "s3:DeleteObject", "Resource": "*"}

คำขอ: s3:DeleteObject ส่งผลให้: ถูกปฏิเสธ

การปฏิเสธแบบชัดเจนชนะ allow ใดๆ ไม่ว่าจะกว้างแค่ไหน

คำสั่ง allow และคำสั่ง deny ทั้งสองป้อนเข้าสู่คำขอเดียวกัน โดยเส้นทางของ deny ถูกวาดเน้นหนัก และผลลัพธ์ถูกระบุว่าถูกปฏิเสธ

ลำดับการประเมิน และการปฏิเสธแบบนัย

ผังการประเมินนโยบาย IAM: คำขอ API จะตรวจสอบการปฏิเสธแบบชัดเจนที่เกี่ยวข้องก่อน จากนั้นตรวจสอบ allow ที่เกี่ยวข้อง และจะได้ผลเป็นการปฏิเสธแบบนัย (implicit deny) เมื่อไม่พบทั้งสองอย่าง

การปฏิเสธแบบชัดเจน: มีบางอย่างบอกว่าไม่
Allow: มีบางอย่างบอกว่าใช่ และไม่มีอะไรบอกว่าไม่
การปฏิเสธแบบนัย: ไม่มีอะไรพูดอะไรเลย

สี่คำขอ สามผลลัพธ์

{"Effect": "Allow", "Action": "s3:*",
 "Resource": "*"}

{"Effect": "Deny", "Action": "s3:DeleteObject",
 "Resource": "*"}

s3:GetObject → allow: allow ที่ครอบคลุมกว้างครอบคลุมถึง
s3:DeleteObject → explicit deny: มีคำสั่งบอกว่าไม่
kms:Decrypt, dynamodb:GetItem → implicit deny: นโยบายนี้ไม่เคยกล่าวถึงบริการเหล่านั้น
KMS เก็บกุญแจเข้ารหัส; DynamoDB เป็นฐานข้อมูล key-value แบบจัดการ

ทำไมการเพิ่มสิทธิ์มักไม่ได้ผล

ข้อผิดพลาดเดียวกัน สองสาเหตุ

การปฏิเสธแบบชัดเจน

allow อื่นไม่เปลี่ยนแปลงอะไร
หา deny แล้วจำกัดขอบเขตหรือลบออก

การปฏิเสธแบบนัย

allow แคบเพียงหนึ่งรายการ
บน identity ที่เป็นผู้เรียก call

ข้อผิดพลาด AccessDenied แยกออกเป็นสองสาเหตุ ด้านซ้ายพบ deny ดังนั้น allow เพิ่มเติมจึงไม่เปลี่ยนแปลงอะไร ด้านขวาไม่พบ allow ดังนั้น allow แคบเพียงหนึ่งรายการบน identity ที่เรียก call จะช่วยแก้ปัญหาได้

มาฝึกกันเถอะ!

การใช้ AWS Security สำหรับนักพัฒนา