Shared Responsibility Model: ใครรับผิดชอบอะไรบนคลาวด์

Shared Responsibility Model (แบบจำลองความรับผิดชอบร่วมกัน) คือหลักที่บอกว่า เมื่อองค์กรใช้คลาวด์ ผู้ให้บริการคลาวด์กับองค์กรลูกค้าจะดูแลความปลอดภัยคนละส่วน เส้นแบ่งไม่ตายตัว แต่เลื่อนไปตามแบบบริการที่ใช้ AWS, Microsoft Azure และ Google Cloud ต่างอธิบายหลักนี้ไว้ในเอกสารของตน บทความนี้สรุปว่าใครรับผิดชอบอะไร และองค์กรควรทำอย่างไรกับส่วนที่เป็นของตน

แบ่งเป็นความปลอดภัยของคลาวด์ กับความปลอดภัยในคลาวด์

AWS อธิบายว่าตนปกป้องโครงสร้างพื้นฐานที่ใช้รันบริการทั้งหมด ได้แก่ ฮาร์ดแวร์ ซอฟต์แวร์ เครือข่าย และสถานที่ตั้ง ส่วนฝั่งลูกค้า AWS ระบุว่าขึ้นอยู่กับบริการที่ลูกค้าเลือกใช้ CSA (Cloud Security Alliance หน่วยงานที่เผยแพร่แนวปฏิบัติด้านความปลอดภัยคลาวด์) ใช้คำคู่เดียวกัน คือผู้ให้บริการดูแลความปลอดภัยของคลาวด์ (ตัวระบบคลาวด์เอง) ส่วนลูกค้าดูแลความปลอดภัยในคลาวด์ (สิ่งที่ลูกค้านำไปวางและตั้งค่าบนคลาวด์)

• ผู้ให้บริการคลาวด์: ดูแลฮาร์ดแวร์ เครือข่าย และสถานที่ตั้งที่อยู่เบื้องหลังบริการ
• ลูกค้า: ดูแลสิ่งที่ตนนำไปวางและตั้งค่าบนบริการนั้น เช่น ข้อมูล สิทธิ์การเข้าถึง และซอฟต์แวร์ที่ติดตั้งเอง

บริการสามแบบ: IaaS, PaaS และ SaaS

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

• IaaS (บริการโครงสร้างพื้นฐาน): ลูกค้าดูแลเครื่องเสมือน (virtual machine คือเครื่องคอมพิวเตอร์จำลองที่รันบนเซิร์ฟเวอร์ของผู้ให้บริการ) ระบบปฏิบัติการ และแอปพลิเคชันเอง ตัวอย่างคือ Azure Virtual Machines
• PaaS (บริการแพลตฟอร์ม): ลูกค้านำแอปพลิเคชันขึ้นใช้งานได้เลย โดยไม่ต้องดูแลเครื่องเสมือนหรือระบบปฏิบัติการ ตัวอย่างคือ Azure App Service และ Azure Functions
• SaaS (บริการซอฟต์แวร์สำเร็จรูป): ลูกค้าใช้แอปพลิเคชันที่พร้อมใช้งาน ตัวอย่างคือ Microsoft 365

ลองเทียบกับศูนย์ข้อมูลของตนเอง ซึ่งองค์กรดูแลทุกชั้นเอง Microsoft อธิบายว่าเมื่อย้ายไปใช้คลาวด์ ความรับผิดชอบบางส่วนจะย้ายไปเป็นของผู้ให้บริการ ไล่จาก IaaS ไป PaaS และ SaaS ผู้ให้บริการยิ่งรับงานแทนมากขึ้น งานของลูกค้าจึงลดลง แต่ไม่ลดเหลือศูนย์

สิ่งที่ลูกค้ารับผิดชอบเสมอ

Microsoft ระบุว่า ไม่ว่าจะใช้บริการแบบใด ลูกค้ายังต้องดูแลสี่เรื่องนี้เอง:

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

ส่วนที่เปลี่ยนไปตามแบบบริการ

ตามตารางความรับผิดชอบของ Microsoft ส่วนที่ต่างกันตามแบบบริการมีดังนี้:

• ระบบปฏิบัติการ: IaaS ลูกค้าดูแล ส่วน PaaS และ SaaS Microsoft ดูแล
• การควบคุมเครือข่าย: IaaS ลูกค้าดูแล PaaS ลูกค้ากับ Microsoft ดูแลร่วมกัน SaaS Microsoft ดูแล
• แอปพลิเคชัน: IaaS ลูกค้าดูแล PaaS และ SaaS ลูกค้ากับ Microsoft ดูแลร่วมกัน
• อุปกรณ์ของผู้ใช้: IaaS และ PaaS ลูกค้าดูแล SaaS ลูกค้ากับ Microsoft ดูแลร่วมกัน
• เครื่องโฮสต์จริง เครือข่ายจริง และศูนย์ข้อมูล: Microsoft ดูแลทั้งสามแบบบริการ

AWS และ Google Cloud อธิบายในแนวเดียวกัน AWS ยกตัวอย่าง Amazon EC2 (บริการเครื่องเสมือน) ซึ่งลูกค้าต้องตั้งค่าและดูแลความปลอดภัยเองทั้งหมด รวมถึงอัปเดตและแพตช์ (patch คือชุดแก้ช่องโหว่ของซอฟต์แวร์) ระบบปฏิบัติการของเครื่องเสมือน ส่วนบริการที่ AWS ดูแลชั้นโครงสร้างพื้นฐาน ระบบปฏิบัติการ และแพลตฟอร์มให้ เช่น Amazon S3 (บริการเก็บไฟล์) ลูกค้ายังต้องจัดการข้อมูล การเข้ารหัส และสิทธิ์ใน IAM (ระบบจัดการตัวตนและสิทธิ์ของ AWS) Google Cloud บอกว่า แบบ IaaS ลูกค้าทำงานด้านความปลอดภัยส่วนใหญ่ แบบ PaaS Google ทำมากขึ้น และแบบ SaaS Google ทำส่วนใหญ่ ทั้งสองรายตรงกันว่า ผู้ให้บริการดูแลเครือข่ายและโครงสร้างพื้นฐานเบื้องล่างเสมอ ส่วนลูกค้าดูแลนโยบายการเข้าถึงและข้อมูลเสมอ ดังนั้นให้ดูเส้นแบ่งของแต่ละบริการ อย่าดูแค่ชื่อผู้ให้บริการ

ส่วนที่ใช้ร่วมกัน และใครเป็นเจ้าของมาตรการ

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

• การแพตช์: AWS แพตช์โครงสร้างพื้นฐาน ส่วนลูกค้าแพตช์ระบบปฏิบัติการของเครื่องเสมือนและแอปพลิเคชันของตน
• การตั้งค่า: AWS ตั้งค่าอุปกรณ์โครงสร้างพื้นฐานของตน ส่วนลูกค้าตั้งค่าระบบปฏิบัติการ ฐานข้อมูล และแอปพลิเคชันของตน
• การอบรมสร้างความตระหนัก: AWS อบรมพนักงานของตน ส่วนลูกค้าอบรมพนักงานของตน

CSA แบ่งความเป็นเจ้าของมาตรการใน CCM (Cloud Controls Matrix ชุดมาตรการด้านความปลอดภัยคลาวด์ของ CSA) ออกเป็นสี่แบบ:

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

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

Google Cloud เสนอแนวคิดต่อยอดชื่อ shared fate (ชะตากรรมร่วมกัน) โดยมองว่าแบบจำลองความรับผิดชอบร่วมกันยังไม่พอที่จะช่วยให้ลูกค้าได้ผลลัพธ์ด้านความปลอดภัยที่ดีขึ้น จึงให้แนวทางตั้งต้นที่ปลอดภัยและเครื่องมือกำกับดูแลเพิ่มเติม ส่วน NSA (หน่วยงานความมั่นคงของสหรัฐฯ) เผยแพร่เอกสารสรุปเมื่อเดือนมีนาคม 2024 ว่าด้วยการยึดหลักนี้ เอกสารเตือนว่าลูกค้ามักเข้าใจผิดว่าผู้ให้บริการดูแลบางเรื่อง ทั้งที่เป็นหน้าที่ของลูกค้า (เราอ่านเอกสารฉบับเต็มไม่ได้ ข้อความนี้อิงจากสรุปของแหล่งรอง)

วิธีนำไปใช้ในองค์กร

ขั้นตอนต่อไปนี้ใช้ได้กับทุกผู้ให้บริการ:

• ทำรายการบริการคลาวด์: ระบุว่าองค์กรใช้บริการใดบ้าง และแต่ละบริการเป็น IaaS, PaaS หรือ SaaS
• อ่านเอกสารและสัญญา: ดูว่าผู้ให้บริการแบ่งความรับผิดชอบของบริการนั้นอย่างไร
• ทำตารางเจ้าของมาตรการ: ระบุว่าทุกมาตรการใครรับผิดชอบ รวมถึงส่วนที่ใช้ร่วมกัน (แนวคิดเดียวกับที่ CSA ใช้กับ CCM)
• ตรวจการตั้งค่าฝั่งลูกค้า: ตรวจสิทธิ์ การเข้ารหัส และการเปิดสู่อินเทอร์เน็ตอย่างต่อเนื่อง
• ทบทวนเมื่อเริ่มใช้บริการใหม่: เส้นแบ่งเปลี่ยนไปตามบริการที่เลือก จึงต้องดูใหม่ทุกครั้ง

การตรวจการตั้งค่าอย่างต่อเนื่องเป็นงานของ CSPM (เครื่องมือตรวจการตั้งค่าบนคลาวด์) ดู CSPM คืออะไร ตรวจ Misconfiguration บนคลาวด์ สำหรับบริการ SaaS ดู ความปลอดภัยของ SaaS และ SSPM ส่วนหลักคิดที่ไม่เชื่อใจการเข้าถึงใดโดยอัตโนมัติ ดู Zero Trust คืออะไร และองค์กรควรเริ่มตรงไหน

ข้อผิดพลาดที่พบบ่อย

• คิดว่าย้ายขึ้นคลาวด์แล้วผู้ให้บริการดูแลความปลอดภัยทั้งหมด: ข้อมูล บัญชีผู้ใช้ และสิทธิ์ยังเป็นของลูกค้าเสมอ
• ใช้เส้นแบ่งเดียวกับทุกบริการ: IaaS, PaaS และ SaaS แบ่งงานต่างกัน แม้เป็นบริการของผู้ให้บริการรายเดียวกันก็ตาม
• ไม่อ่านเอกสารและสัญญาของบริการที่ใช้: เส้นแบ่งจริงอยู่ในเอกสารของแต่ละบริการ
• ไม่ตรวจการตั้งค่าฝั่งลูกค้า: เช่น สิทธิ์เข้าถึงพื้นที่เก็บข้อมูลและบัญชีผู้ใช้
• ปล่อยมาตรการที่ใช้ร่วมกันไว้โดยไม่มีเจ้าของ: แต่ละฝ่ายอาจคิดว่าอีกฝ่ายทำอยู่
• มองข้ามอุปกรณ์ปลายทางและบัญชีผู้ใช้: Microsoft ระบุว่าลูกค้าต้องรับผิดชอบส่วนนี้อย่างน้อยบางส่วนเสมอ

ขั้นแรกที่ทำได้ทันที

• เลือกบริการคลาวด์ที่สำคัญที่สุดสามรายการ: ระบุว่าแต่ละรายการเป็น IaaS, PaaS หรือ SaaS
• เปิดหน้าเอกสารความรับผิดชอบร่วมกันของผู้ให้บริการแต่ละราย: จดว่าส่วนไหนเป็นของเรา
• ตั้งเจ้าของ: ให้ทุกบริการมีผู้รับผิดชอบด้านข้อมูล บัญชีผู้ใช้ และการตั้งค่า
• ตรวจ MFA ของบัญชีผู้ดูแลคลาวด์: ส่วนนี้เป็นหน้าที่ของลูกค้าเสมอ
• ตั้งรอบทบทวน: ดูตารางเจ้าของมาตรการทุกครั้งที่เริ่มใช้บริการใหม่

หากต้องการดูว่าองค์กรดูแลส่วนของตนบนคลาวด์ได้ครบเพียงใด ลองใช้ แบบประเมินตนเอง

แหล่งอ้างอิงและข้อมูลเพิ่มเติม

• AWS Shared Responsibility Model: ความปลอดภัยของคลาวด์กับในคลาวด์ มาตรการที่รับมา ใช้ร่วมกัน และเป็นของลูกค้า
• Microsoft: Shared responsibility in the cloud: ตารางความรับผิดชอบของ IaaS, PaaS และ SaaS
• Google Cloud: Shared responsibility and shared fate: การแบ่งงานตามแบบบริการ และแนวคิด shared fate
• CSA: Implementing the Shared Security Responsibility Model in the Cloud: การแบ่งความเป็นเจ้าของมาตรการเป็นสี่แบบ
• CSA Cloud Controls Matrix: ชุดมาตรการที่ระบุบทบาทของผู้ให้บริการและลูกค้า
• NSA: Uphold the Cloud Shared Responsibility Model (PDF, March 2024): เอกสารแนะนำของ NSA