Shared Responsibility Model คืออะไร เราต้องดูแลอะไรบนคลาวด์

เวลาย้ายงานขึ้นคลาวด์ครั้งแรก มักมีความเชื่อเงียบ ๆ ติดมาด้วยว่า "ตอนนี้อยู่บน AWS (หรือ Azure หรือ Google Cloud) แล้ว ก็ปลอดภัยแล้ว" ประโยคนี้ถูกอยู่ครึ่งเดียว ผู้ให้บริการดูแลให้เยอะจริง แต่อีกครึ่งเป็นหน้าที่ของเรา และผู้ให้บริการเองก็เขียนไว้ชัดเจนในเอกสารของตัวเองครับ

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

เริ่มจากสามคำ: IaaS, PaaS, SaaS

นิยามมาตรฐานมาจาก NIST Special Publication 800-145 เอกสารสั้น ๆ ที่ออกเมื่อกันยายน พ.ศ. 2554 ซึ่งอธิบาย cloud computing ว่าประกอบด้วย essential characteristics ห้าข้อ, service model สามแบบ และ deployment model สี่แบบ ส่วนที่เกี่ยวกับเรื่องนี้คือ service model ทั้งสาม สรุปเป็นภาษาของผมเองจากเนื้อหาฉบับเต็ม ได้ดังนี้

• Infrastructure as a Service (IaaS): เราได้ processing, storage และ network มา แล้วจะรันซอฟต์แวร์อะไรบนนั้นก็ได้ รวมถึงระบบปฏิบัติการของเราเอง เราไม่ได้ควบคุม cloud infrastructure ข้างใต้ แต่ ควบคุม operating system, storage และแอปที่ deploy เอง และอาจควบคุมอุปกรณ์เครือข่ายบางส่วนได้ เช่น host firewall
• Platform as a Service (PaaS): เรา deploy แอปของเราเอง (หรือแอปที่ซื้อมา) ขึ้นไปบนแพลตฟอร์มของผู้ให้บริการ ด้วยภาษาและเครื่องมือที่แพลตฟอร์มรองรับ เราไม่ต้องจัดการ server หรือ OS แต่ควบคุมตัวแอปที่ deploy และอาจตั้งค่าบางอย่างของ hosting environment ได้
• Software as a Service (SaaS): เราใช้แอปของผู้ให้บริการ ส่วนใหญ่ผ่าน browser เราไม่ได้จัดการ infrastructure และแทบไม่ได้จัดการตัวแอปด้วยซ้ำ ยกเว้นการตั้งค่าเฉพาะผู้ใช้บางอย่างที่มีจำกัด

สังเกตรูปแบบนี้ไว้ ยิ่งไล่จาก IaaS ไปหา SaaS รายการสิ่งที่เราควบคุมก็ยิ่งสั้นลง แต่ไม่เคยเหลือศูนย์

ห้องเช่าสามแบบ

ลองนึกถึงการเช่าที่พักสามแบบดูครับ

1. ห้องเปล่า (IaaS) เจ้าของตึกให้อาคารที่แข็งแรง ทั้งฐานราก ผนัง ทางเข้าหลัก และสายไฟจนถึงมิเตอร์ของเรา แต่ข้างในโล่ง เราต้องหาเฟอร์นิเจอร์เอง ติดกลอนประตูเอง เลือกเองว่าใครได้กุญแจ และตัดสินใจเองว่าจะปิดหน้าต่างหรือไม่
2. ห้องพร้อมเฟอร์นิเจอร์ (PaaS) เจ้าของตึกให้เฟอร์นิเจอร์และเครื่องใช้ไฟฟ้า และคอยดูแลให้ใช้งานได้ แต่เรายังเป็นคนเลือกว่าใครได้กุญแจ จะเก็บอะไรไว้ในห้อง และจะเปิดประตูระเบียงทิ้งไว้หรือไม่
3. เซอร์วิสอพาร์ตเมนต์ (SaaS) ทำความสะอาด ซ่อมแซม และแทบทุกอย่างมีคนจัดการให้ แต่เรายังเป็นคนเลือกว่าจะให้คีย์การ์ดกับใคร และเรายังเป็นคนที่วางแล็ปท็อปไว้บนโต๊ะข้างหน้าต่างที่เปิดอยู่

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

                IaaS     PaaS     SaaS              .--.        
                ▀▀▀▀                              .(    ).      
        you  ██▒▒▒▒▒▒▒▒▒ data ▒▒▒▒▒▒▒▒▒██ ┐                     
                                          │                     
        you  ██▒▒ identities & access ▒██ │ always yours        
                                          │                     
        you  ██▒▒▒▒▒ configuration ▒▒▒▒██ ┘                     
                                                                
        you  ██▒▒▒▒▒▒ application ▒▒▒▒▒██                       
                                                                
        you  ██▒▒▒▒▒ OS / runtime ▒▒▒▒▒██                       
             ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ ◄ the line            
   provider  ██░░░░ virtualization ░░░░██                       
                                                                
   provider  ██░░░░░░░ hardware ░░░░░░░██  · · ▪ ·  racks       
                                                                
   provider  ██░░░░░░░ facility ░░░░░░░██  ▁▂▁▂▁                
                                                                

ผู้ให้บริการพูดไว้ว่าอย่างไร

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

AWS: "of the cloud" กับ "in the cloud"

หน้า shared responsibility ของ AWS ใช้คำคู่ที่จำง่าย AWS รับผิดชอบ security of the cloud คือ hardware, software, networking และ facility ที่ใช้รันบริการทั้งหมด ส่วนลูกค้ารับผิดชอบ security in the cloud ซึ่งขอบเขตขึ้นอยู่กับบริการที่เลือกใช้

สำหรับ Amazon EC2 ซึ่ง AWS จัดเป็น IaaS ลูกค้าต้องดูแล guest operating system (รวมถึงการอัปเดตและ security patch) ซอฟต์แวร์ที่ติดตั้งเอง และการตั้งค่า firewall ที่ AWS ให้มา ซึ่งเรียกว่า security group ส่วนบริการที่ถูก abstract มากกว่า อย่าง Amazon S3 และ DynamoDB นั้น AWS ดูแล infrastructure, OS และ platform ให้ ลูกค้าดูแลข้อมูล ตัวเลือกการเข้ารหัส และ permission ของตัวเอง

หน้าเดียวกันยังแบ่ง control เป็นสามกลุ่มที่มีประโยชน์

• Inherited controls คือ control ที่ได้จาก AWS ทั้งหมด เช่น physical และ environmental control
• Shared controls คือแต่ละฝ่ายทำส่วนของตัวเอง ตัวอย่างคลาสสิกคือการ patch: AWS patch infrastructure ของตัวเอง เรา patch guest OS และแอปของเรา
• Customer-specific controls คือ control ที่เป็นของเราทั้งหมด ขึ้นอยู่กับสิ่งที่เราสร้าง

Microsoft: ตาราง และสี่เรื่องที่เป็นของเราเสมอ

หน้า shared responsibility ของ Microsoft มีตารางที่แบ่งแถวตาม layer และแบ่งคอลัมน์ตาม model (on-premises, IaaS, PaaS, SaaS) physical host, physical network และ physical datacenter ย้ายไปเป็นของ Microsoft ทันทีที่อยู่ใน cloud model ใดก็ตาม operating system ย้ายไปเป็นของ Microsoft ตั้งแต่ PaaS ส่วน application ถูกระบุว่า "shared" ใน PaaS และ SaaS, network control เป็น "shared" ใน PaaS (และเป็นของ Microsoft ใน SaaS) และ client device กลายเป็น "shared" ใน SaaS

มีสามแถวที่เขียนว่า "Customer" ใน ทุก คอลัมน์ คือ customer data, configurations and settings และ identities and users จากนั้นหน้านี้ก็ระบุสิ่งที่ลูกค้ารับผิดชอบเสมอไม่ว่าจะ deploy แบบไหน ได้แก่ data, endpoint (แล็ปท็อปและมือถือที่ใช้เข้าบริการ), account และ access management ซึ่งอธิบายว่าหมายถึง role-based access control, multifactor authentication และ conditional access policy

Microsoft ยังมีหมายเหตุที่ควรอ่านซ้ำสองรอบ คือคำว่า "responsibility" ในบทความนี้ใช้ในความหมายเชิง governance (ใครควรเป็นคนตั้งค่า ดูแล และเฝ้าดู control นั้น) และบทความเป็นแนวทางเชิงอธิบาย ไม่ได้เปลี่ยนเงื่อนไขในสัญญาที่เรามีกับ Microsoft ครับ

Google Cloud: shared responsibility แล้วต่อด้วย "shared fate"

หน้า Architecture Framework ของ Google อธิบายการแบ่งแบบเดียวกัน สำหรับ IaaS หน้าที่ด้าน security ส่วนใหญ่อยู่กับลูกค้า โดย Google ดูแล infrastructure และ physical security สำหรับ PaaS Google รับไปมากขึ้น IAM และ control ระดับแอปเป็นแบบ shared และลูกค้ายังรับผิดชอบ data security และการป้องกันฝั่ง client สำหรับ SaaS Google ดูแลเกือบทั้งหมด แต่ลูกค้ายังต้องจัดการ access control และข้อมูลที่ตัวเองเก็บ

สรุปหนึ่งประโยคของ Google ตรงกับภาพห้องเช่าพอดี: ผู้ให้บริการรับผิดชอบ network และ infrastructure ข้างใต้เสมอ และลูกค้ารับผิดชอบ access policy และข้อมูลของตัวเองเสมอ

จากนั้น Google ไปอีกขั้นด้วยแนวคิดที่เรียกว่า shared fate คือผู้ให้บริการเข้ามามีส่วนช่วยให้ลูกค้าทำครึ่งของตัวเองให้ถูก แทนที่จะขีดเส้นแล้วถอยออกไป ในทางปฏิบัติคือสิ่งอย่าง blueprint ที่ปลอดภัยตั้งแต่ต้น (enterprise foundations blueprint และ landing zone guide) เครื่องมืออย่าง Assured Workloads และ Security Command Center และ Risk Protection Program ที่ทำร่วมกับบริษัทประกันภัยไซเบอร์ ถ้าเปรียบกับห้องเช่า ก็คือเจ้าของตึกที่ไม่ได้แค่ซ่อมหลังคา แต่ยังให้กลอนดี ๆ ให้ checklist และช่วยดูหน้าต่างของเราอย่างตรงไปตรงมาครับ

สิ่งที่เป็นของเราเสมอ

พอเอาสามหน้านี้มาวางเทียบกัน จะได้รายการสั้น ๆ ที่ตรงกัน

layer ตรงกลาง (application, OS, network control) ย้ายไปมาระหว่างเรากับผู้ให้บริการตาม model ส่วน layer ล่างสุด (hardware, facility) เป็นของผู้ให้บริการในทุก cloud model

ช่องโหว่มักอยู่ตรงไหน

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

1. Storage ที่เปิดให้สาธารณะเข้าได้

กรณีคลาสสิกคือ storage bucket ที่ใครบนอินเทอร์เน็ตก็อ่านได้ ผู้ให้บริการเองก็ปรับค่า default ไปทางปลอดภัยมากขึ้น ตั้งแต่เมษายน พ.ศ. 2566 bucket ใหม่ของ Amazon S3 จะเปิด Block Public Access และปิด ACL เป็นค่าเริ่มต้น และสำหรับ storage account แบบ Azure Resource Manager anonymous access ต่อ blob data ถูกห้ามเป็นค่าเริ่มต้น

แต่ค่า default เป็นแค่จุดเริ่มต้นของสวิตช์ เอกสาร S3 บอกชัดว่าผู้ใช้ยังแก้ bucket policy หรือ object permission ให้เปิดสาธารณะได้ และถ้าเอา Block Public Access ออก bucket ที่มี public policy อยู่ก็จะกลับเป็นสาธารณะอีกครั้ง AWS แนะนำให้เปิด Block Public Access ทั้งสี่ setting ที่ระดับ account เพื่อให้ครอบคลุมทั้ง bucket ที่มีอยู่และที่จะสร้างในอนาคตครับ

 INTERNET                /              ╎                       
                        /               ┆                       
            ┊          /                ┆                       
            ┊         /                 ┆   ┌─────┐  ┌─────┐    
            ┊        /                  ┆   │ · · │  │ ▪ ▪ │    
            ┊       ┌──────────┐        ┆   │     │  │     │    
            ┊       │ ▤  ▤  ▤  │        ┆   │ ▪ · │  │ · ▪ │    
            ┊       │ ▤  ▤  ▤  │        ┆   │     │  │     │    
            ┊       └──────────┘   o─┬  ╎   └─────┘  └─────┘    
            ┊         bucket      key   ╎                       
            ┊      public: yes          ╎    locked  ✓          
            ┊                           ╎                       
                                        ╎                       
               YOUR HALF                ╎    PROVIDER'S HALF    

2. Role ที่ทำได้มากเกินไป

ช่องโหว่ที่สองคือ identity ที่มีสิทธิ์มากกว่าที่จำเป็น IAM best practices ของ AWS เริ่มจากให้คนและ workload ใช้ temporary credential, บังคับใช้ MFA ในกรณีที่ยังต้องใช้ IAM user หรือ root user แล้วมาถึงหัวใจของเรื่อง คือให้เฉพาะ permission ที่จำเป็นต่อการทำงานนั้น และค่อย ๆ ขยับเข้าหา least privilege เมื่อ workload โตขึ้น หน้าเดียวกันยังเตือนว่า AWS managed policy เขียนมาสำหรับลูกค้าทุกราย จึงอาจไม่ใช่ least privilege สำหรับงานของเรา และแนะนำให้ใช้ IAM Access Analyzer สร้าง policy จาก activity จริง และหา access แบบสาธารณะหรือข้าม account

ถ้าเปรียบกับห้องเช่า ก็คืออย่าให้กุญแจผีกับคนที่แค่มารดน้ำต้นไม้ครับ

3. Log ที่นึกว่ามีอยู่แล้ว

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

• บน AWS CloudTrail event history เปิดอยู่เป็นค่าเริ่มต้น แต่เก็บ management event ย้อนหลัง 90 วัน ต่อ Region และไม่แสดง data event ถ้าต้องการบันทึกต่อเนื่อง ต้องสร้าง trail หรือ event data store เอง
• บน Google Cloud Admin Activity audit log เปิดอยู่เสมอ แต่ Data Access audit log ปิดเป็นค่าเริ่มต้น สำหรับทุกบริการ ยกเว้นบริการ BigQuery บางตัว ถ้าอยากรู้ว่าใคร อ่าน ข้อมูลของเรา ต้องเปิดเอง

ผู้ให้บริการเป็นคนรันระบบ logging แต่การตัดสินใจว่าจะเก็บอะไร เก็บนานแค่ไหน และใครเป็นคนดู เป็นครึ่งของเราครับ

แล้ว SaaS ล่ะ?

SaaS ให้ความรู้สึกว่าผู้ให้บริการทำให้ทุกอย่าง แต่ identity, data และ setting ยังเป็นของเรา นี่จึงเป็นเหตุผลที่ โครงการ Secure Cloud Business Applications (SCuBA) ของ CISA เผยแพร่ secure configuration baseline สำหรับ Microsoft 365 และ Google Workspace พร้อมเครื่องมือฟรี (ScubaGear และ ScubaGoggles) ที่ใช้ตรวจ tenant เทียบกับ baseline นั้น แม้จะอยู่เซอร์วิสอพาร์ตเมนต์ ก็ยังต้องมีคนคอยเช็กหน้าต่างครับ

ตารางความรับผิดชอบที่นำไปปรับใช้ได้

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

วิธีใช้แบบได้ผลจริง: เพิ่มคอลัมน์ชื่อ "ฝั่งเราใครดูแล?" แล้วเขียนชื่อคนหรือชื่อทีมไว้ข้างทุกแถวที่เป็น "เรา" หรือ "Shared" แถวไหนที่ไม่มีใครตอบได้ คือแถวที่ควรไปดูภายในสัปดาห์นี้ครับ

สรุปสั้น ๆ

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

แหล่งอ้างอิง

• NIST SP 800-145, The NIST Definition of Cloud Computing (หน้าเอกสาร)
• NIST SP 800-145, ฉบับเต็ม (DOI)
• AWS, Shared Responsibility Model
• Microsoft Learn, Shared responsibility in the cloud
• Google Cloud Architecture Framework, Shared responsibilities and shared fate on Google Cloud
• AWS News Blog, Heads-Up: Amazon S3 Security Changes Are Coming in April of 2023
• Amazon S3 User Guide, Blocking public access to your Amazon S3 storage
• Microsoft Learn, Remediate anonymous read access to blob data
• AWS IAM User Guide, Security best practices in IAM
• AWS CloudTrail User Guide, Working with CloudTrail event history
• Google Cloud Logging, Enable Data Access audit logs
• CISA, Secure Cloud Business Applications (SCuBA) Project