Ethical Hacking Academy · บทเรียน

พื้นผิวการโจมตีบนคลาวด์

AWS, Azure, GCP

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

พื้นผิวการโจมตีบนคลาวด์คืออะไร

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

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

การตั้งค่าที่ผิดพลาดเพียงจุดเดียวอาจเปิดเผยทั้งบัญชีได้

สามรายใหญ่: AWS, Azure, GCP

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

AWS — ผู้ใช้/บทบาท IAM, S3, EC2, Lambda
Azure — Entra ID (Azure AD), Blob Storage, VM, Functions
GCP — บัญชีบริการ IAM, Cloud Storage, Compute Engine

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

รูปแบบความรับผิดชอบร่วมกัน

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

ผู้ให้บริการ: ศูนย์ข้อมูลทางกายภาพ ไฮเปอร์ไวเซอร์ การแพตช์บริการที่มีการจัดการ
ลูกค้า: นโยบาย IAM ข้อมูล การแพตช์ OS (IaaS) การกำหนดค่าเครือข่าย

ในฐานะผู้ทดสอบเจาะระบบ คุณมุ่งเน้นความรับผิดชอบของลูกค้า เพราะนั่นคือจุดที่ข้อผิดพลาดซึ่งนำไปใช้โจมตีได้เกิดขึ้น

การแจกแจงตัวตนบนคลาวด์

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

หากกุญแจมีสิทธิ์มากเกินไป ตัวตนนี้เพียงตัวเดียวก็สามารถขยายการเข้าถึงไปทั่วทั้งบัญชีได้

# Confirm which AWS identity a credential belongs to
aws sts get-caller-identity

# Example output
# {
#   "UserId": "AIDA...",
#   "Account": "123456789012",
#   "Arn": "arn:aws:iam::123456789012:user/devuser"
# }

พื้นผิวสาธารณะเทียบกับส่วนตัว

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

กลุ่มความปลอดภัย / NSG ที่เปิดให้ 0.0.0.0/0
บัคเก็ตพื้นที่จัดเก็บที่ตั้งค่าให้อ่านได้สาธารณะ
ฐานข้อมูลที่เปิดใช้งานจุดปลายทางสาธารณะ
พอร์ตการจัดการ (22, 3389, 5432) ที่เปิดเผย

การทำแผนที่ว่าทรัพยากรใดเป็นสาธารณะคือพื้นฐานของการสำรวจคลาวด์

การค้นหาทรัพยากรจากภายนอก

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

เครื่องมือจะเดาชื่อบัคเก็ตและพื้นที่จัดเก็บจำนวนมาก โดยอิงจากชื่อบริษัทและรูปแบบทั่วไป

# Resolve a cloud-hosted hostname to map provider/region
nslookup assets.example.com

# Probe a guessed S3 bucket name
curl -s -o /dev/null -w '%{http_code}\n' https://example-backups.s3.amazonaws.com/

ระนาบการจัดการเทียบกับระนาบข้อมูล

ในทุกบัญชีคลาวด์จะมีชั้นการโจมตีที่แยกจากกันสองชั้น:

ระนาบการจัดการ/ควบคุม — API ที่ใช้สร้าง แก้ไข และลบทรัพยากร (เช่น iam:CreateUser, ec2:RunInstances)
ระนาบข้อมูล — การเข้าถึงข้อมูลภายในทรัพยากร (การอ่านออบเจ็กต์ S3 การเรียกข้อมูลจากฐานข้อมูล)

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

พื้นผิวการบันทึกและตรวจจับ

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

AWS CloudTrail — บันทึกการเรียก API ทั้งหมด
Azure Activity Log / Monitor
GCP Cloud Audit Logs

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

# Check whether CloudTrail logging is active
aws cloudtrail describe-trails
aws cloudtrail get-trail-status --name my-trail

จุดเข้าสู่ระบบคลาวด์ที่พบบ่อย

การยึดครองระบบคลาวด์ส่วนใหญ่มักเริ่มจากจุดตั้งต้นไม่กี่รูปแบบดังต่อไปนี้:

คีย์เข้าถึงที่รั่วไหลในคลัง Git บันทึกของ CI หรือแอปมือถือ
บทบาท IAM ที่ให้สิทธิ์กว้างเกินไปและผูกไว้กับเซิร์ฟเวอร์ที่ถูกยึดครอง
SSRF ที่เข้าถึงบริการข้อมูลเมตาของอินสแตนซ์
บักเก็ตพื้นที่จัดเก็บแบบสาธารณะที่เปิดเผยความลับหรือข้อมูลสำรอง

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

การจัดทำแผนผังพื้นผิวอย่างเป็นระบบ

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

เครื่องมืออย่าง ScoutSuite และ Prowler จะตรวจสอบการกำหนดค่าของบริการต่าง ๆ และแจ้งความเสี่ยงโดยอัตโนมัติ

# Audit an AWS account for misconfigurations (read-only)
prowler aws

# Multi-cloud configuration review
scout aws

ขอบเขตและการอนุญาตต้องมาก่อน

การทดสอบคลาวด์ต้องอยู่ภายในขอบเขตการอนุญาตของงาน ผู้ให้บริการเองก็มีข้อกำหนดในการปฏิบัติงานเช่นกัน

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

การทดสอบคลาวด์โดยไม่ได้รับอนุญาตอาจละเมิดข้อกำหนดของผู้ให้บริการและกฎหมายท้องถิ่น

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

ภายใต้รูปแบบความรับผิดชอบร่วมกัน ฝ่ายใดเป็นผู้รับผิดชอบนโยบาย IAM และการกำหนดค่าข้อมูล

สรุป: พื้นผิวการโจมตีบนคลาวด์

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

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

ถัดไป เราจะเจาะลึกการกำหนดค่า IAM ที่ผิดพลาด ซึ่งเป็นหัวใจของการโจมตีระบบคลาวด์

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

บทเรียน “พื้นผิวการโจมตีบนคลาวด์” ฟรีหรือไม่

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

คุณจะเรียนรู้อะไรในบทเรียน “พื้นผิวการโจมตีบนคลาวด์”

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

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

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

บทเรียน “พื้นผิวการโจมตีบนคลาวด์” ใช้เวลานานแค่ไหน

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

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

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

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

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