Ethical Hacking Academy · บทเรียน

การกำหนดค่า IAM ผิดพลาด

บทบาทที่ให้สิทธิ์กว้างเกินไป

การกำหนดค่า IAM ผิดพลาด เป็นบทเรียน Ethical Hacking Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Ethical Hacking Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Ethical Hacking Academy มีบทเรียนทั้งหมด 4 บทเรียน

เหตุใด IAM จึงเป็นขอบเขตป้องกันที่แท้จริง

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

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

การยกระดับสิทธิ์บนคลาวด์ส่วนใหญ่เป็นปัญหาของ IAM

ผู้ใช้ บทบาท และนโยบาย

AWS IAM มีองค์ประกอบพื้นฐานสามส่วนที่คุณต้องทำความเข้าใจ:

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

การผูกนโยบายไว้กว้างเกินไปเป็นสาเหตุของการให้สิทธิ์มากเกินจำเป็น

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::reports-bucket/*"
}

อันตรายของไวลด์การ์ด

รูปแบบ IAM ที่อันตรายที่สุดคือ นโยบายไวลด์การ์ด ซึ่งอนุญาตให้ดำเนินการได้ทุกอย่างกับทรัพยากรทุกประเภท

หากผู้โจมตียึดครองข้อมูลประจำตัวที่ใช้นโยบายนี้ได้ ผู้โจมตีก็จะควบคุมทั้งบัญชี

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

# Action:* Resource:* = full administrative control.
# Flag this everywhere it appears outside a break-glass admin role.

สำรวจสิทธิ์ของตนเอง

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

บางบัญชียังอนุญาตให้ผู้ใช้ทั่วไปใช้ iam:Get* และ iam:List* ได้ ทำให้คุณได้แผนผังพร้อมใช้โดยไม่ต้องออกแรง

# List policies attached to a user
aws iam list-attached-user-policies --user-name devuser

# Get the JSON of a managed policy version
aws iam get-policy-version \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess \
  --version-id v1

การยกระดับสิทธิ์ผ่าน iam:PassRole

ตัวอย่างการยกระดับสิทธิ์แบบคลาสสิก: ผู้ใช้มี iam:PassRole พร้อมสิทธิ์ในการสร้างบริการ ผู้ใช้จึงเปิดใช้ทรัพยากรที่สวมบทบาทซึ่งมีสิทธิ์สูง และรับช่วงสิทธิ์ของบทบาทนั้นมาได้

ผู้ใช้มี ec2:RunInstances + iam:PassRole
ผู้ใช้เปิดใช้อินสแตนซ์ EC2 ที่ผูกบทบาทผู้ดูแลระบบไว้
อินสแตนซ์มีข้อมูลรับรองผู้ดูแลระบบอยู่ จากนั้นผู้ใช้จึงดึงข้อมูลดังกล่าวออกมา

ผู้ใช้ไม่เคยมีสิทธิ์ผู้ดูแลระบบโดยตรง แต่สามารถยกระดับเข้าไปสู่สิทธิ์นั้นได้

การผสมผสานสิทธิ์ที่เป็นอันตราย

สิทธิ์แต่ละรายการอาจไม่เป็นอันตราย แต่เมื่อรวมกันอาจกลายเป็นช่องทางยกระดับสิทธิ์ได้ ตัวอย่างการผสมผสานที่มีความเสี่ยง ได้แก่:

iam:CreatePolicyVersion — แก้ไขนโยบายเดิมให้มอบสิทธิ์ผู้ดูแลระบบ
iam:AttachUserPolicy — ผูก AdministratorAccess ให้กับตนเอง
iam:CreateAccessKey กับผู้ใช้รายอื่น — ขโมยข้อมูลประจำตัวของผู้ใช้นั้น
sts:AssumeRole กับบทบาทที่ไว้วางใจมากเกินไป

เครื่องมือจะสำรวจสิ่งเหล่านี้โดยอัตโนมัติ

นโยบายความไว้วางใจและ AssumeRole

บทบาทต่าง ๆ มี นโยบายความไว้วางใจที่กำหนดว่าใครสามารถสวมบทบาทได้ นโยบายความไว้วางใจที่กว้างเกินไปเปรียบเสมือนประตูหลัง

หากบทบาทไว้วางใจทั้งบัญชี หรือแม้แต่บัญชีภายนอกโดยไม่ได้ตั้งใจ ผู้โจมตีก็สามารถสวมบทบาทนั้นได้

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
  "Action": "sts:AssumeRole"
}

# Trusting the entire account root means ANY identity in it can assume the role.

ทำให้การค้นหาเส้นทางยกระดับสิทธิ์เป็นอัตโนมัติ

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

Pacu — กรอบการทำงานสำหรับโจมตี AWS พร้อมโมดูลยกระดับสิทธิ์
PMapper — สร้างกราฟความสัมพันธ์ของ IAM และค้นหาเส้นทางยกระดับสิทธิ์
enumerate-iam — ทดลองแบบไล่ครบทุกกรณีเพื่อดูว่าคีย์หนึ่งสามารถเรียก API ใดได้บ้าง

# Run Pacu's IAM privilege escalation enumeration
pacu
# > run iam__privesc_scan

# Build an IAM access graph and query it
pmapper graph create
pmapper query 'preset privesc *'

นโยบายแบบฝังในตัวเทียบกับนโยบายที่จัดการ

สามารถมอบสิทธิ์ได้สองวิธี และผู้โจมตีจะตรวจสอบทั้งสองวิธี:

นโยบายที่จัดการ — นำกลับมาใช้ซ้ำได้และผูกกับข้อมูลประจำตัวหลายรายการ
นโยบายแบบฝังในตัว — ฝังไว้โดยตรงในผู้ใช้หรือบทบาทเดียว

นโยบายแบบฝังในตัวมักถูกมองข้ามในการตรวจสอบ จึงมักซ่อนสิทธิ์ที่มากเกินจำเป็นไว้ ให้สำรวจทั้งสองแบบเสมอเมื่อประเมินข้อมูลประจำตัว

# Inline policies are listed separately from attached ones
aws iam list-user-policies --user-name devuser
aws iam get-user-policy --user-name devuser --policy-name custom-inline

การเสริมความปลอดภัย: สิทธิ์เท่าที่จำเป็น

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

แทนที่ไวลด์การ์ดด้วยการดำเนินการและ ARN ของทรัพยากรที่ระบุไว้อย่างชัดเจน
ใช้บทบาทที่มีข้อมูลรับรองอายุสั้นแทนคีย์ที่มีอายุยาวนาน
ตรวจสอบสิทธิ์ที่ไม่ได้ใช้งานด้วย Access Analyzer
บังคับใช้ MFA กับข้อมูลประจำตัวที่มีสิทธิ์สูง

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

อยู่ภายในการอนุญาต

การทดสอบการยกระดับสิทธิ์จะเปลี่ยนแปลงสถานะของบัญชีโดยตรง จึงต้องระมัดระวัง:

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

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

ตรวจสอบอย่างรวดเร็ว

การผสมผสานสิทธิ์ใดเป็นเส้นทางยกระดับสิทธิ์บน AWS แบบคลาสสิก

สรุป: การกำหนดค่า IAM ที่ผิดพลาด

คุณได้เรียนรู้ว่าเหตุใด IAM จึงเป็นขอบเขตป้องกันที่แท้จริงของระบบคลาวด์ และผู้โจมตีใช้ประโยชน์จากมันอย่างไร

นโยบายไวลด์การ์ด Action:* Resource:* เป็นภัยร้ายแรง
iam:PassRole + การสร้างบริการ ทำให้ยกระดับสิทธิ์ได้
นโยบายความไว้วางใจที่กว้างเกินไปเปิดโอกาสให้ผู้โจมตีสวมบทบาท
เครื่องมืออย่าง Pacu และ PMapper ทำให้การค้นหาเส้นทางเป็นอัตโนมัติ
แนวทางแก้ไขคือใช้หลัก สิทธิ์เท่าที่จำเป็น เสมอ

ถัดไป เราจะดู S3 และการเปิดเผยข้อมูลจากพื้นที่จัดเก็บ

คำถามที่พบบ่อย

บทเรียน “การกำหนดค่า IAM ผิดพลาด” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การกำหนดค่า IAM ผิดพลาด” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Ethical Hacking Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Ethical Hacking Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การกำหนดค่า IAM ผิดพลาด”

บทบาทที่ให้สิทธิ์กว้างเกินไป คุณปฏิบัติ Ethical Hacking Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Ethical Hacking Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Ethical Hacking Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 2 จากทั้งหมด 4 บทเรียน

บทเรียน “การกำหนดค่า IAM ผิดพลาด” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Ethical Hacking Academy นี้ได้ไหม

ได้ บทเรียน Ethical Hacking Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ Ethical Hacking Academy