0Pricing
Cloud & IT Cert Prep · บทเรียน

อัตลักษณ์บนคลาวด์: บทบาท IAM และบัญชีบริการ

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

อัตลักษณ์บนคลาวด์: บทบาท IAM และบัญชีบริการ เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

พื้นฐานอัตลักษณ์บนคลาวด์

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

ผู้ใช้ กลุ่ม และบทบาทใน AWS IAM

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

# IAM role trust policy — allows EC2 to assume this role
{
  'Version': '2012-10-17',
  'Statement': [{
    'Effect': 'Allow',
    'Principal': { 'Service': 'ec2.amazonaws.com' },
    'Action': 'sts:AssumeRole'
  }]
}

# EC2 instance with this role attached can call AWS APIs
# using temporary credentials from the instance metadata service

สิทธิ์เท่าที่จำเป็นใน policy ของ IAM

policy ของ IAM กำหนดว่าอัตลักษณ์หนึ่งสามารถดำเนินการใดกับทรัพยากรใดได้บ้าง หลักการให้สิทธิ์เท่าที่จำเป็นกำหนดให้ policy อนุญาตเฉพาะ Action ที่จำเป็นต่อภารกิจเท่านั้น การละเมิดที่พบบ่อย ได้แก่ การใช้ไวลด์การ์ด * กับ Action (ทำให้ใช้ Action ทั้งหมดในบริการได้) การใช้ * กับ Resource (ทำให้เข้าถึง Resource ทั้งหมดได้) และการแนบ policy ที่มีขอบเขตกว้างเกินไป เช่น AdministratorAccess ให้กับบัญชีบริการ ควรมีเหตุผลรองรับการใช้ไวลด์การ์ดทุกจุดและทบทวนเป็นประจำ

# Overly permissive policy (AVOID)
{
  'Effect': 'Allow',
  'Action': 's3:*',      # all S3 actions
  'Resource': '*'         # all buckets
}

# Least-privilege policy (PREFERRED)
{
  'Effect': 'Allow',
  'Action': ['s3:GetObject', 's3:ListBucket'],
  'Resource': [
    'arn:aws:s3:::my-specific-bucket',
    'arn:aws:s3:::my-specific-bucket/*'
  ]
}

บัญชีบริการใน GCP

ใน แพลตฟอร์ม Google Cloud (GCP) เวิร์กโหลดที่ไม่ใช่มนุษย์จะยืนยันตัวตนโดยใช้ บัญชีบริการ ซึ่งเป็นเอนทิตีข้อมูลระบุตัวตนที่มีการจัดการ พร้อมไฟล์คีย์ JSON หรือ Workload Identity Federation บัญชีบริการแต่ละบัญชีควรปฏิบัติตามหลักสิทธิ์เท่าที่จำเป็น โดยผูกบัญชีไว้เฉพาะกับบริการ GCP ที่ต้องเรียกใช้เท่านั้น คีย์ของบัญชีบริการ (ไฟล์ JSON ที่ดาวน์โหลดจากคอนโซล) เป็นข้อมูลรับรองอายุยาวที่ต้องปฏิบัติเสมือนรหัสผ่าน โดยต้องหมุนเวียนคีย์เป็นประจำ และห้ามนำไปเก็บในซอร์สโค้ดหรืออัปโหลดไปยังคลังสาธารณะโดยเด็ดขาด

# Check service account permissions (gcloud)
gcloud projects get-iam-policy my-project \
  --flatten='bindings[].members' \
  --format='table(bindings.role, bindings.members)' \
  --filter='bindings.members:serviceAccount'

# Prefer Workload Identity over service account keys
# (no downloadable key files — uses workload federation tokens)

ข้อมูลระบุตัวตนที่มีการจัดการของ Azure

ข้อมูลระบุตัวตนที่มีการจัดการของ Azure (เดิมเรียกว่า MSI) เป็นสิ่งเทียบเท่ากับบทบาท AWS สำหรับบริการต่าง ๆ ใน Azure โดยช่วยให้ทรัพยากร Azure (VM, App Services และ Functions) ยืนยันตัวตนกับ API ของ Azure ได้โดยไม่ต้องจัดเก็บข้อมูลรับรอง มีอยู่สองประเภท ได้แก่ ข้อมูลระบุตัวตนที่มีการจัดการแบบ กำหนดโดยระบบ ซึ่งผูกกับทรัพยากรเฉพาะและจะถูกลบเมื่อทรัพยากรถูกลบ และข้อมูลระบุตัวตนที่มีการจัดการแบบ กำหนดโดยผู้ใช้ ซึ่งเป็นออบเจ็กต์อิสระที่สามารถใช้ร่วมกันระหว่างทรัพยากรหลายรายการได้ ข้อมูลระบุตัวตนที่มีการจัดการช่วยขจัดความจำเป็นในการจัดเก็บคีย์หรือข้อมูลลับใด ๆ

# Azure CLI — assign managed identity to a VM
az vm identity assign \
  --name myVM \
  --resource-group myRG \
  --identities /subscriptions/.../userAssignedIdentities/myIdentity

# The VM can now call Azure Key Vault without any stored credentials:
# Token is fetched automatically from the Instance Metadata Service

ข้อมูลรับรองอายุยาว: ความเสี่ยง

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

# Find IAM access keys older than 90 days (AWS)
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | \
  base64 -d | grep -v 'N/A' | \
  awk -F',' '$10 > 90 {print $1, $10}'

# Keys older than 90 days should be rotated or deleted

การเชื่อมโยงบทบาทและการยกระดับสิทธิ์

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

# Dangerous permission combination (enables privilege escalation):
# iam:CreatePolicyVersion + iam:SetDefaultPolicyVersion
# Attacker can create a new policy version with AdministratorAccess

# Or: iam:PassRole + lambda:CreateFunction + lambda:InvokeFunction
# Attacker creates Lambda with a privileged role, invokes it

# Defense: permission boundaries limit maximum grantable permissions

การรับบทบาทข้ามบัญชี

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

# Trust policy with External ID (confused deputy protection)
{
  'Effect': 'Allow',
  'Principal': { 'AWS': 'arn:aws:iam::PARTNER-ACCOUNT-ID:root' },
  'Action': 'sts:AssumeRole',
  'Condition': {
    'StringEquals': {
      'sts:ExternalId': 'unique-shared-secret-12345'
    }
  }
}

ความปลอดภัยของ IMDS และบริการข้อมูลเมทาดาทา

อินสแตนซ์ AWS EC2 สามารถเรียกข้อมูลรับรองบทบาท IAM ของตนเองจาก บริการข้อมูลเมทาดาทาของอินสแตนซ์ (IMDS) ที่ http://169.254.169.254 ช่องโหว่ประเภท SSRF มีอันตรายเป็นพิเศษในกรณีนี้ หากแอปพลิเคชันมีช่องโหว่ SSRF ผู้โจมตีอาจขโมยข้อมูลรับรองบทบาท IAM ของอินสแตนซ์ได้ โดยสั่งให้เซิร์ฟเวอร์เรียกข้อมูลจาก URL ของ IMDS IMDSv2 (ซึ่งกำหนดให้ใช้โทเค็นเซสชัน) ช่วยลดการขโมยข้อมูลรับรองผ่าน SSRF และควรบังคับใช้กับอินสแตนซ์ EC2 ทั้งหมด

# Enforce IMDSv2 on a new EC2 instance (requires token for IMDS)
aws ec2 run-instances \
  --metadata-options 'HttpTokens=required,HttpEndpoint=enabled' \
  ...

# IMDSv1 (insecure) just needs a GET request:
# curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# IMDSv2 requires a PUT to get a session token first

IAM Access Analyzer และการทบทวนนโยบาย

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

การรวมศูนย์ข้อมูลระบุตัวตนของเวิร์กโหลด

การรวมศูนย์ข้อมูลระบุตัวตนของเวิร์กโหลดช่วยให้เวิร์กโหลดภายนอก (GitHub Actions, ระบบภายในองค์กร และผู้ให้บริการคลาวด์รายอื่น) ยืนยันตัวตนกับ IAM ของคลาวด์โดยใช้โทเค็น OIDC อายุสั้นแทนคีย์บัญชีบริการอายุยาว เวิร์กโฟลว์ GitHub Actions สามารถรับบทบาท IAM ของ AWS โดยใช้โทเค็น OIDC ตลอดระยะเวลาของงาน จากนั้นโทเค็นจะหมดอายุ แนวทางนี้ช่วยขจัดการรั่วไหลของข้อมูลรับรองอายุยาวจากไปป์ไลน์ CI/CD ได้ทั้งหมด

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้

สรุปบทเรียน

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

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

บทเรียน “อัตลักษณ์บนคลาวด์: บทบาท IAM และบัญชีบริการ” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “อัตลักษณ์บนคลาวด์: บทบาท IAM และบัญชีบริการ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “อัตลักษณ์บนคลาวด์: บทบาท IAM และบัญชีบริการ”

กำหนดค่าบทบาท IAM และบัญชีบริการตามหลักสิทธิ์เท่าที่จำเป็นบนแพลตฟอร์มคลาวด์ พร้อมหลีกเลี่ยงข้อผิดพลาดทั่วไป เช่น สิทธิ์แบบไวลด์การ์ดและกุญแจที่มีอายุการใช้งานยาวนาน คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่

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

บทเรียน “อัตลักษณ์บนคลาวด์: บทบาท IAM และบัญชีบริการ” ใช้เวลานานแค่ไหน

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

ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม

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

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

  1. รูปแบบความรับผิดชอบร่วมกัน: IaaS, PaaS, SaaS
  2. ความปลอดภัยของพื้นที่จัดเก็บบนคลาวด์และความเสี่ยงจากการเปิดเผยข้อมูล
  3. อัตลักษณ์บนคลาวด์: บทบาท IAM และบัญชีบริการ
  4. การจัดการสถานะความปลอดภัยบนคลาวด์ (CSPM)
← กลับไปที่ Cloud & IT Cert Prep