รูปแบบความรับผิดชอบร่วมกัน: IaaS, PaaS, SaaS
แจกแจงให้ชัดเจนว่าผู้ให้บริการคลาวด์รับผิดชอบมาตรการควบคุมความปลอดภัยใด และลูกค้ารับผิดชอบส่วนใดในบริการทั้งสามรูปแบบหลัก
รูปแบบความรับผิดชอบร่วมกัน: IaaS, PaaS, SaaS เป็นบทเรียน Security+ Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Security+ Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน
ภาพรวมแบบจำลองบริการ Cloud
บริการ Cloud ให้บริการผ่านแบบจำลองหลักสามรูปแบบ โดยแต่ละรูปแบบมีระดับการแยกความซับซ้อนที่แตกต่างกัน Infrastructure as a Service (IaaS) ให้บริการ Compute พื้นฐาน พื้นที่จัดเก็บข้อมูล และเครือข่าย Platform as a Service (PaaS) เพิ่ม OS มิดเดิลแวร์ และสภาพแวดล้อมขณะทำงาน Software as a Service (SaaS) ให้บริการแอปพลิเคชันที่พร้อมใช้งานอย่างสมบูรณ์ผ่านอินเทอร์เน็ต การทำความเข้าใจแบบจำลองเหล่านี้เป็นสิ่งสำคัญ เพราะความรับผิดชอบด้านความปลอดภัยแตกต่างกันอย่างมากในแต่ละแบบจำลอง
# Cloud service model examples
# IaaS: AWS EC2, Azure VMs, Google Compute Engine
# You manage: OS, runtime, applications, data
# Provider manages: hypervisor, physical hardware, datacenter
# PaaS: AWS Elastic Beanstalk, Azure App Service, Heroku
# You manage: applications, data, configurations
# Provider manages: OS patches, runtime, scaling
# SaaS: Microsoft 365, Salesforce, Google Workspace
# You manage: user access, data content, configuration
# Provider manages: everything elseแบบจำลองความรับผิดชอบร่วมกัน
แบบจำลองความรับผิดชอบร่วมกัน กำหนดว่างานด้านความปลอดภัยใดเป็นหน้าที่ของ Provider Cloud และงานใดเป็นหน้าที่ของลูกค้า โดยมักสรุปว่า Provider รับผิดชอบความปลอดภัย ของ Cloud (ศูนย์ข้อมูลจริง ไฮเปอร์ไวเซอร์ และโครงสร้างพื้นฐานเครือข่าย) ขณะที่ลูกค้ารับผิดชอบความปลอดภัย ภายใน Cloud (ข้อมูล การจัดการการเข้าถึง ความปลอดภัยของแอปพลิเคชัน และการกำหนดค่า) การเข้าใจขอบเขตนี้ผิดเป็นสาเหตุสำคัญประการหนึ่งของเหตุการณ์ด้านความปลอดภัยบน Cloud
ความรับผิดชอบใน IaaS
ใน IaaS ลูกค้ารับผิดชอบด้านความปลอดภัยมากที่สุด Provider Cloud รักษาความปลอดภัยให้โครงสร้างพื้นฐานจริง ไฮเปอร์ไวเซอร์ และโครงสร้างเครือข่าย ส่วน ลูกค้า รับผิดชอบ: การติดตั้ง OS การติดตั้ง Patch และการเสริมความแข็งแกร่งด้านความปลอดภัย การกำหนดค่าสภาพแวดล้อมขณะทำงานและมิดเดิลแวร์ ความปลอดภัยของแอปพลิเคชัน กฎของกลุ่มความปลอดภัยเครือข่าย นโยบาย IAM และการจัดการผู้ใช้ การเข้ารหัสข้อมูลขณะจัดเก็บและระหว่างส่ง และการกำหนดค่าเพื่อการปฏิบัติตามข้อกำหนด IaaS ให้การควบคุมสูงสุด แต่ต้องใช้ความพยายามด้านความปลอดภัยสูงสุดด้วย
# IaaS security checklist (customer responsibilities)
# AWS EC2 example:
# [ ] Patch OS and installed packages regularly
# [ ] Harden security group rules (least-privilege inbound/outbound)
# [ ] Enable CloudTrail for API logging
# [ ] Encrypt EBS volumes with KMS
# [ ] Rotate IAM access keys regularly
# [ ] Enable VPC Flow Logs for network monitoringความรับผิดชอบใน PaaS
ใน PaaS Provider เข้ามารับผิดชอบการจัดการ OS และสภาพแวดล้อมขณะทำงาน ลูกค้าไม่ต้องติดตั้ง Patch ให้ระบบปฏิบัติการหรือจัดการมิดเดิลแวร์อีกต่อไป เพราะ Provider เป็นผู้ดำเนินการให้ อย่างไรก็ตาม ลูกค้ายังคงรับผิดชอบ: ความปลอดภัยของโค้ดแอปพลิเคชัน (ไม่มี SQLi, XSS และอื่น ๆ) การจัดประเภทและการเข้ารหัสข้อมูล การจัดการข้อมูลระบุตัวตนและการเข้าถึง การกำหนดค่าแอปพลิเคชัน (ตัวแปรสภาพแวดล้อมและการจัดการข้อมูลลับ) และความปลอดภัยของ API PaaS ช่วยถ่ายโอนภาระบางส่วนไปยัง Provider ขณะที่ลูกค้ามุ่งเน้นที่ตรรกะของแอปพลิเคชัน
ความรับผิดชอบใน SaaS
ใน SaaS Provider จะจัดการเกือบทุกอย่าง ความรับผิดชอบหลักด้านความปลอดภัยของลูกค้า ได้แก่: การจัดการการเข้าถึง (ใครมีบัญชี การบังคับใช้ MFA และการทบทวนสิทธิ์) การกำกับดูแลข้อมูล (อัปโหลดข้อมูลใด และเก็บรักษาไว้นานเท่าใด) ความปลอดภัยของการกำหนดค่า (การตั้งค่าความเป็นส่วนตัว สิทธิ์การแชร์ และการผสานรวมกับบริการของบุคคลที่สาม) และ การปฏิบัติตามข้อกำหนดด้านการใช้งานที่ยอมรับได้ การรั่วไหลของข้อมูลใน SaaS จำนวนมากเกิดจากการตั้งค่าการแชร์ที่ไม่ถูกต้องหรือสิทธิ์ของแอปบุคคลที่สามที่มากเกินไป มากกว่าจะเกิดจากความล้มเหลวของ Provider
โซนแห่งความสับสน: การควบคุมร่วมกัน
การควบคุมบางส่วนเป็นความรับผิดชอบ ร่วมกัน ระหว่างผู้ให้บริการกับลูกค้า ตัวอย่างเช่น การเข้ารหัส ผู้ให้บริการคลาวด์อาจมีบริการเข้ารหัส (KMS การเข้ารหัสเริ่มต้น) แต่ลูกค้าต้องเปิดใช้งาน กำหนดค่าการจัดการคีย์ และเลือกอัลกอริทึมที่เหมาะสม เช่นเดียวกับการจัดการข้อมูลประจำตัว ผู้ให้บริการมีเครื่องมือ IAM ให้ แต่ลูกค้าต้องกำหนดค่า policy ตามหลักสิทธิ์เท่าที่จำเป็น และบังคับใช้ MFA การเข้าใจผิดว่าผู้ให้บริการจะจัดการการควบคุมร่วมกันให้ แล้วไม่กำหนดค่าด้วยตนเอง เป็นข้อผิดพลาดที่พบได้บ่อยและอันตราย
ความล้มเหลวในโลกจริง: การกำหนดค่าผิดพลาด
โมเดลความรับผิดชอบร่วมกันมักล้มเหลวจาก การกำหนดค่าผิดพลาดของลูกค้า ไม่ใช่จากความล้มเหลวของผู้ให้บริการ ตัวอย่างที่พบได้บ่อย ได้แก่ bucket ของ S3 ที่ปล่อยให้เข้าถึงได้แบบสาธารณะ (เหตุการณ์ข้อมูลรั่วไหลของ Capital One ในปี 2019 ซึ่งทำให้ข้อมูล 100 ล้านรายการถูกเปิดเผย) บทบาท IAM ที่อนุญาตกว้างเกินไปจนทำให้ยกระดับสิทธิ์ได้ กลุ่มความปลอดภัยที่มีกฎขาเข้าสำหรับพอร์ตสำคัญจาก 0.0.0.0/0 และข้อมูลประจำตัวเริ่มต้นของฐานข้อมูลที่นำไปใช้งานบนคลาวด์แล้วไม่ได้เปลี่ยนแปลง โครงสร้างพื้นฐานเบื้องหลังของผู้ให้บริการมีความปลอดภัย แต่การกำหนดค่าของลูกค้าไม่ปลอดภัย
# S3 public access — dangerous misconfiguration
aws s3api get-bucket-acl --bucket my-sensitive-bucket
# Check for 'AllUsers' grants — means world-readable!
# Fix: block all public access
aws s3api put-public-access-block \
--bucket my-sensitive-bucket \
--public-access-block-configuration \
'BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true'การมองเห็นและการบันทึกกิจกรรมบนคลาวด์
ความท้าทายสำคัญของโมเดลร่วมกันคือ การมองเห็น ในสภาพแวดล้อมภายในองค์กร ทีมรักษาความปลอดภัยควบคุมการบันทึกกิจกรรมทั้งหมด แต่บนคลาวด์ บันทึกจากโครงสร้างพื้นฐานของผู้ให้บริการอาจไม่สามารถเข้าถึงได้ ลูกค้าต้องเปิดใช้บริการบันทึกกิจกรรมแบบเนทีฟของคลาวด์ ได้แก่ AWS CloudTrail, Azure Monitor และบันทึก Cloud Audit Logs ของ GCP ซึ่งจะบันทึกการเรียกใช้ API และการเปลี่ยนแปลงการกำหนดค่า หากไม่เปิดใช้บริการเหล่านี้ องค์กรจะไม่มีบันทึกตรวจสอบว่าใครทำอะไรในสภาพแวดล้อมคลาวด์ของตน ซึ่งเป็นช่องว่างสำคัญด้านการปฏิบัติตามข้อกำหนดและการพิสูจน์หลักฐาน
# Enable CloudTrail for all regions (AWS)
aws cloudtrail create-trail \
--name org-trail \
--s3-bucket-name my-cloudtrail-bucket \
--is-multi-region-trail \
--include-global-service-events
aws cloudtrail start-logging --name org-trailความรับผิดชอบของบุคคลที่สาม: MSP และ CSP
เมื่อองค์กรใช้ผู้ให้บริการจัดการระบบ (MSP) เพื่อดำเนินงานสภาพแวดล้อมคลาวด์ ความรับผิดชอบจะถูกแบ่งออกเป็นสามฝ่าย ลูกค้าต้องตรวจสอบให้แน่ใจว่าสัญญา (SLA และ DPA) ระบุภาระหน้าที่ด้านความปลอดภัยไว้อย่างชัดเจน แอปคลาวด์ของบุคคลที่สามที่เข้าถึงผ่าน SaaS เพิ่มความซับซ้อนอีกระดับหนึ่ง การให้ความยินยอม OAuth แก่แอปที่อนุญาตกว้างเกินไป ทำให้แอปนั้นเข้าถึงข้อมูลของคุณได้ การตรวจสอบและทบทวนความยินยอม OAuth ของบุคคลที่สามเป็นประจำเป็นส่วนหนึ่งของแนวปฏิบัติด้านความปลอดภัยของ SaaS
การปฏิบัติตามข้อกำหนดในโมเดลความรับผิดชอบร่วมกัน
ข้อกำหนดด้านการปฏิบัติตามข้อกำหนดไม่ได้หายไปเพียงเพราะย้ายเวิร์กโหลดขึ้นคลาวด์ HIPAA กำหนดให้ต้องมีข้อตกลงผู้ช่วยทางธุรกิจ (BAA) กับผู้ให้บริการคลาวด์ที่จัดการ PHI โดย AWS, Azure และ GCP ต่างก็มี BAA ให้บริการ PCI-DSS กำหนดว่าสภาพแวดล้อมคลาวด์ต้องอยู่ภายในขอบเขตการประเมิน เมทริกซ์ความรับผิดชอบร่วมกันจากผู้ให้บริการจะระบุว่าการควบคุม PCI ใดได้รับการปฏิบัติตามแล้ว องค์กรต้องเข้าใจว่าส่วนใดอยู่ภายใต้ความรับผิดชอบของผู้ให้บริการ และส่วนใดที่องค์กรต้องดำเนินการเองเพื่อให้ผ่านการตรวจสอบ
ข้อพิจารณาด้านสัญญาและกฎหมาย
โมเดลความรับผิดชอบร่วมกันมีผลทางกฎหมาย ข้อกำหนดการให้บริการของผู้ให้บริการคลาวด์และ ข้อตกลงระดับการให้บริการ (SLA) จะระบุการรับประกันความพร้อมใช้งานและข้อยกเว้น ข้อตกลงการประมวลผลข้อมูล (DPA) ภายใต้ GDPR จะกำหนดภาระหน้าที่ของผู้ประมวลผล หากเกิดการรั่วไหลเนื่องจากความล้มเหลวฝั่งผู้ให้บริการ ลูกค้ามีสิทธิ์เรียกร้องการเยียวยาตาม SLA แต่หากการรั่วไหลเกิดจากการกำหนดค่าผิดพลาดของลูกค้า ผู้ให้บริการจะไม่ต้องรับผิด การทำความเข้าใจสัญญาสำคัญไม่แพ้การทำความเข้าใจการควบคุมทางเทคนิค
ตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิดของ CompTIA Security+ (SY0-701) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า โมเดลความรับผิดชอบร่วมกันกำหนดภาระหน้าที่ด้านความปลอดภัยของผู้ให้บริการและลูกค้าใน IaaS, PaaS และ SaaS ลูกค้ามีความรับผิดชอบด้านความปลอดภัยมากที่สุดใน IaaS และน้อยที่สุดใน SaaS แต่ยังคงเป็นผู้รับผิดชอบการจัดการการเข้าถึงและการกำกับดูแลข้อมูลเสมอ และ การกำหนดค่าผิดพลาดของลูกค้า ไม่ใช่ความล้มเหลวของผู้ให้บริการ เป็นสาเหตุหลักของการรั่วไหลบนคลาวด์ บทถัดไปเราจะศึกษาเรื่องความปลอดภัยของพื้นที่จัดเก็บบนคลาวด์และความเสี่ยงจากการเปิดเผยข้อมูล
คำถามที่พบบ่อย
บทเรียน “รูปแบบความรับผิดชอบร่วมกัน: IaaS, PaaS, SaaS” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “รูปแบบความรับผิดชอบร่วมกัน: IaaS, PaaS, SaaS” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Security+ Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Security+ Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “รูปแบบความรับผิดชอบร่วมกัน: IaaS, PaaS, SaaS”
แจกแจงให้ชัดเจนว่าผู้ให้บริการคลาวด์รับผิดชอบมาตรการควบคุมความปลอดภัยใด และลูกค้ารับผิดชอบส่วนใดในบริการทั้งสามรูปแบบหลัก คุณปฏิบัติ Security+ Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Security+ Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Security+ Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน
บทเรียน “รูปแบบความรับผิดชอบร่วมกัน: IaaS, PaaS, SaaS” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Security+ Academy นี้ได้ไหม
ได้ บทเรียน Security+ Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- รูปแบบความรับผิดชอบร่วมกัน: IaaS, PaaS, SaaS
- ความปลอดภัยของพื้นที่จัดเก็บบนคลาวด์และความเสี่ยงจากการเปิดเผยข้อมูล
- อัตลักษณ์บนคลาวด์: บทบาท IAM และบัญชีบริการ
- การจัดการสถานะความปลอดภัยบนคลาวด์ (CSPM)