ตัวตน ทรัพยากร และขอบเขต

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

Rahul Singh

Technical Product Manager

นโยบายไหนที่มีอำนาจตัดสิน

การแก้ไขที่ไม่เปลี่ยนอะไรเลย

  • บทที่หนึ่ง: deny ชัดเจน หรือไม่มี allow
  • ที่นี่: สาเหตุที่สาม

คำขอที่มาเจอกับชุดการตรวจสอบนโยบายสามชั้น โดยมีเครื่องหมายคำถามตรงจุดที่ควรเป็นผลการตัดสินใจ

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

นโยบายไหนที่มีอำนาจตัดสิน

สูงสุดสามชั้น

  1. Identity policy บนผู้เรียก
  2. Resource policy บนทรัพยากร
  3. Boundary ด้านบน ลดสิทธิ์ได้อย่างเดียว

ในบัญชีของตัวเอง แค่มีนโยบายใดนโยบายหนึ่ง allow ก็พอ

ถูก deny หากพบที่ชั้นใดชั้นหนึ่ง

คำขอไหลจากบนลงล่างผ่านการตรวจสอบสามขั้นตามลำดับ ได้แก่ identity policy, resource policy และ permissions boundary ก่อนจะได้ผลลัพธ์ที่อนุญาต

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

สองที่ที่นโยบายแนบอยู่ได้

Identity-based policy

  • แนบไว้ที่ผู้เรียก
  • สิ่งที่ตัวตนนั้นทำได้
  • เปรียบเหมือนบัตรผ่านที่สวมติดตัว

บทบาทด้านบนมี identity-based policy แนบอยู่ พร้อมพื้นที่ด้านล่างสำหรับฝั่งทรัพยากรของคำขอเดียวกัน

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

สองที่ที่นโยบายแนบอยู่ได้

Identity-based policy

  • แนบไว้ที่ผู้เรียก
  • สิ่งที่ตัวตนนั้นทำได้
  • เปรียบเหมือนบัตรผ่านที่สวมติดตัว

Resource-based policy

  • แนบไว้ที่ทรัพยากร
  • ใครแตะต้องมันได้บ้าง
  • จำเป็นสำหรับผู้เรียกข้ามบัญชี

บทบาทด้านบนมี identity-based policy แนบอยู่ ขณะที่ S3 bucket ด้านล่างมี resource-based policy แนบอยู่ และคำขอเดินทางลงมาระหว่างทั้งสอง

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

จัดการโดย AWS หรือโดยคุณ

identity-based policy สองประเภท

  • AWS managed: เป็นของ AWS
  • Customer managed: เป็นของคุณ

การ์ดสองใบเปรียบเทียบ AWS managed policy ซึ่งเป็นของ AWS และกว้างโดยค่าเริ่มต้น กับ customer managed policy ซึ่งเป็นของคุณและจำกัดเฉพาะงาน

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

จัดการโดย AWS หรือโดยคุณ

identity-based policy สองประเภท

  • AWS managed: เป็นของ AWS
  • Customer managed: เป็นของคุณ

 

ความสะดวกหรือความแม่นยำ

  • AWS managed: เริ่มใช้งานได้เร็ว
  • Customer managed: สิทธิ์ขั้นต่ำสุด

การ์ดสองใบเปรียบเทียบ AWS managed policy ซึ่งเป็นของ AWS และกว้างโดยค่าเริ่มต้น กับ customer managed policy ซึ่งเป็นของคุณและจำกัดเฉพาะงาน

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

Boundary จำกัดสิ่งที่นโยบายให้สิทธิ์

ทำไมบัญชีถึงแนบนโยบายนี้

  • นักพัฒนาสร้าง role ได้ แต่ไม่มีใครยกระดับสิทธิ์

Permissions boundary

  • เพดานจำกัดสิ่งที่นโยบายให้สิทธิ์
  • สิทธิ์จริง: ต้องได้รับอนุญาตจากทั้งสองฝั่ง

สิทธิ์สามรายการที่ identity policy ให้ไว้ไหลลงสู่ permissions boundary ที่อนุญาตเฉพาะการกระทำบน S3 โดยสิทธิ์ iam:CreateUser ถูกหยุด ส่วนอีกสองรายการผ่านต่อไปยังสิทธิ์จริงด้านล่าง

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

Boundary จำกัดสิ่งที่นโยบายให้สิทธิ์

ทำไมบัญชีถึงแนบนโยบายนี้

  • นักพัฒนาสร้าง role ได้ แต่ไม่มีใครยกระดับสิทธิ์

Permissions boundary

  • เพดานจำกัดสิ่งที่นโยบายให้สิทธิ์
  • สิทธิ์จริง: ต้องได้รับอนุญาตจากทั้งสองฝั่ง

ทำไม iam:CreateUser ถึงไม่เกิดผล

  • ลดสิทธิ์ได้อย่างเดียว ไม่เคยให้สิทธิ์

สิทธิ์สามรายการที่ identity policy ให้ไว้ไหลลงสู่ permissions boundary ที่อนุญาตเฉพาะการกระทำบน S3 โดยสิทธิ์ iam:CreateUser ถูกหยุด ส่วนอีกสองรายการผ่านต่อไปยังสิทธิ์จริงด้านล่าง

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

Boundary จำกัดสิ่งที่นโยบายให้สิทธิ์

ทำไมบัญชีถึงแนบนโยบายนี้

  • นักพัฒนาสร้าง role ได้ แต่ไม่มีใครยกระดับสิทธิ์

Permissions boundary

  • เพดานจำกัดสิ่งที่นโยบายให้สิทธิ์
  • สิทธิ์จริง: ต้องได้รับอนุญาตจากทั้งสองฝั่ง

ทำไม iam:CreateUser ถึงไม่เกิดผล

  • ลดสิทธิ์ได้อย่างเดียว ไม่เคยให้สิทธิ์

Session policy: สำหรับหนึ่งเซสชัน AssumeRole

สิทธิ์สามรายการที่ identity policy ให้ไว้ไหลลงสู่ permissions boundary ที่อนุญาตเฉพาะการกระทำบน S3 โดยสิทธิ์ iam:CreateUser ถูกหยุด ส่วนอีกสองรายการผ่านต่อไปยังสิทธิ์จริงด้านล่าง

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

เงื่อนไขทำให้ allow แคบลง

Condition key

  • จำกัดขอบเขตของ allow ให้แคบลงตามบริบทของคำขอ

  • aws:SourceIp: เครือข่ายต้นทางของคำขอ

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

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

เงื่อนไขทำให้ allow แคบลง

Condition key

  • จำกัดขอบเขตของ allow ให้แคบลงตามบริบทของคำขอ

  • aws:SourceIp: เครือข่ายต้นทางของคำขอ

  • aws:PrincipalTag: แท็กบนผู้เรียก

ABAC: attribute-based access control

  • นโยบายเดียว ใช้ได้กับผู้เรียกหลายราย

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

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

ตารางเดียว ทีละ tenant

ตารางเดียวที่ใช้ร่วมกัน

  • DynamoDB หนึ่ง partition key ต่อหนึ่ง tenant
  • ไม่ได้แยกการเข้าถึงด้วยตัวเอง

ผู้เรียก tenant A ผ่านเงื่อนไข leading keys เข้าสู่ตาราง DynamoDB ที่ใช้ร่วมกัน โดยแถวของ tenant A ถูกส่งคืน ส่วนแถวของ tenant B และ tenant C ถูกบล็อก

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

ตารางเดียว ทีละ tenant

"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

ตารางเดียวที่ใช้ร่วมกัน

  • DynamoDB หนึ่ง partition key ต่อหนึ่ง tenant
  • ไม่ได้แยกการเข้าถึงด้วยตัวเอง

เงื่อนไขหนึ่งข้อจำกัดให้แคบลง

  • ForAllValues: ทุกคีย์ที่ระบุต้องตรงกัน
การใช้ AWS Security สำหรับนักพัฒนา

ตารางเดียว ทีละ tenant

"Action": ["dynamodb:Query", "dynamodb:GetItem", "dynamodb:Scan"],
"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${aws:PrincipalTag/tenant}"]
  }
}

ตารางเดียวที่ใช้ร่วมกัน

  • DynamoDB หนึ่ง partition key ต่อหนึ่ง tenant
  • ไม่ได้แยกการเข้าถึงด้วยตัวเอง

เงื่อนไขหนึ่งข้อจำกัดให้แคบลง

  • ForAllValues: ทุกคีย์ที่ระบุต้องตรงกัน
ช่องว่างที่ยังเหลืออยู่: ไม่ใช่ทุกคำขอที่ระบุ partition
  • dynamodb:Scan ไม่ระบุคีย์ใดเลย จึงไม่มีอะไรที่จะล้มเหลวได้
การใช้ AWS Security สำหรับนักพัฒนา

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

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

Preparing Video For Download...