SaaS security คือการดูแลความปลอดภัยของแอปที่เช่าใช้ผ่านอินเทอร์เน็ต เช่น อีเมลองค์กร ระบบจัดการเอกสาร หรือ CRM (ระบบจัดการข้อมูลลูกค้า) ผู้ให้บริการดูแลเครื่องและโปรแกรมให้ แต่องค์กรยังต้องดูแลความเสี่ยงหลักเอง เริ่มจาก ใครล็อกอินเข้าใช้ได้ ตั้งค่าแต่ละแอปอย่างไร และแชร์ข้อมูลให้ใครบ้าง SSPM (เครื่องมือประเภทหนึ่งที่ตรวจการตั้งค่าแอป SaaS ซ้ำตามรอบ และแจ้งเมื่อมีค่าไหนเบี่ยงจากมาตรฐานที่องค์กรเลือก) ช่วยให้ทำงานนี้ได้ต่อเนื่อง บทความนี้อธิบายความเสี่ยงหลัก วิธีเลือกค่ามาตรฐานจากแหล่งที่เป็นกลาง และขั้นตอนดูแลแอป SaaS ทีละขั้น
SaaS ใครดูแลอะไร
ผู้ให้บริการ SaaS ดูแลระบบเบื้องหลังทั้งหมด องค์กรจึงไม่ต้องติดตั้งหรืออัปเดตเซิร์ฟเวอร์เอง แต่ผู้ให้บริการมักไม่ได้ตั้งค่าแอปให้เหมาะกับองค์กร สิ่งที่ยังอยู่ในมือองค์กรคือ บัญชีผู้ใช้ สิทธิ์ การตั้งค่าการแชร์ การเชื่อมต่อกับแอปอื่น และการเก็บ log (บันทึกเหตุการณ์ของระบบ) CSA (Cloud Security Alliance องค์กรไม่แสวงกำไรที่จัดทำแนวทางความปลอดภัยคลาวด์) มีเอกสารแนวปฏิบัติด้านธรรมาภิบาล SaaS (การกำกับดูแลการใช้ SaaS) เอกสารนี้พูดถึงความเสี่ยงและมาตรการฝั่งลูกค้าตลอดวงจร ตั้งแต่การประเมินผู้ให้บริการไปจนถึงการเลิกใช้บริการ
ความเสี่ยงหลักของแอป SaaS
ความเสี่ยงส่วนใหญ่ไม่ได้มาจากช่องโหว่ในตัวโปรแกรม แต่มาจากการตั้งค่าและการใช้งานที่องค์กรควบคุมเองได้ รายการด้านล่างเป็นการจัดกลุ่มของเราเอง ไม่ได้ยกมาจากมาตรฐานใดโดยตรง
- การตั้งค่าไม่ปลอดภัยหรือเปลี่ยนไปจากเดิม: เช่น เปิดแชร์ไฟล์ให้คนนอกองค์กร หรือไม่บังคับ MFA (การยืนยันตัวตนหลายปัจจัย คือต้องใช้อย่างอื่นนอกจากรหัสผ่านด้วย) ค่าที่เคยตั้งไว้ดีอาจถูกแก้ภายหลังโดยไม่มีใครรู้ เรียกว่า configuration drift (การตั้งค่าค่อย ๆ เบี่ยงไปจากเดิม)
- บัญชีและสิทธิ์เกินจำเป็น: มีผู้ดูแลระบบมากเกินไป บัญชีของคนที่ลาออกแล้วยังใช้ได้ และมีบัญชีแขกที่ไม่มีเจ้าของ
- แอปที่เชื่อมต่อผ่าน OAuth: OAuth คือกลไกที่ให้แอปหนึ่งเข้าถึงข้อมูลในอีกแอปแทนผู้ใช้ โดยไม่ต้องบอกรหัสผ่านให้แอปนั้น ผู้ใช้กดอนุญาตครั้งเดียว แอปนั้นก็อ่านอีเมลหรือไฟล์ต่อไปได้จนกว่าจะมีคนเพิกถอนสิทธิ์ MITRE ATT&CK (ฐานความรู้เรื่องเทคนิคของผู้โจมตี) มีเทคนิคชื่อ Steal Application Access Token ที่เกี่ยวข้องกับเรื่องนี้
- แอปที่ไม่มีใครอนุมัติ (shadow SaaS): พนักงานสมัครใช้เองโดยฝ่ายไอทีไม่รู้ ข้อมูลองค์กรจึงไปอยู่ในที่ที่ไม่มีใครดูแล ดู Shadow AI: ความเสี่ยงและวิธีรับมือ
- บัญชีเครื่องและ API key ที่ไม่มีใครดูแล: บัญชีเครื่องคือบัญชีที่โปรแกรมใช้ ไม่ใช่คน ส่วน API key คือรหัสที่โปรแกรมใช้เรียกบริการ ระบบอัตโนมัติที่เชื่อมกับ SaaS ใช้ token (รหัสที่แอปใช้แทนรหัสผ่าน) ซึ่งมักไม่หมดอายุและไม่มีเจ้าของ ดู Service Account และ Non-human Identity: ความเสี่ยงที่ถูกมองข้าม
SSPM คืออะไร และช่วยอะไรได้
SSPM เป็นเครื่องมือประเภทหนึ่ง ไม่ใช่มาตรฐาน หลักการคือเชื่อมต่อกับแอป SaaS ด้วยสิทธิ์อ่านการตั้งค่า แล้วเทียบกับค่ามาตรฐานที่องค์กรเลือก และรายงานจุดที่ไม่ตรง ความสามารถจริงต่างกันไปตามผลิตภัณฑ์ และตามแอปที่รองรับ ดังนั้นควรทดลองกับแอปที่องค์กรใช้อยู่จริงก่อนตัดสินใจ งานที่เครื่องมือประเภทนี้ทำโดยทั่วไปมีดังนี้
- ตรวจการตั้งค่าเทียบ baseline: baseline คือค่ามาตรฐานขั้นต่ำที่ควรตั้ง เช่น บังคับ MFA หรือจำกัดการแชร์ให้คนนอก
- ตรวจจับการเปลี่ยนแปลง: แจ้งเตือนเมื่อมีคนแก้ค่าที่เคยตั้งไว้ถูกต้อง
- ดูสิทธิ์และบัญชี: ชี้ให้เห็นบัญชีผู้ดูแลระบบ บัญชีแขก และบัญชีที่ไม่ได้ใช้งาน
- ดูแอปที่เชื่อมต่อ: แสดงรายการแอปที่ได้รับสิทธิ์เข้าถึงข้อมูล ผู้ขายบางรายทำส่วนนี้ได้ลึกกว่ารายอื่น
SSPM ไม่ได้แทนมาตรการอื่น เครื่องมือบอกได้ว่าการตั้งค่าผิดตรงไหน แต่ไม่ได้เฝ้าดูทุกอย่างที่ผู้ใช้ทำในแอป และไม่ได้แก้ปัญหาเรื่องตัวตนให้เอง องค์กรยังต้องมี MFA การเฝ้าระวัง log และเจ้าของที่รับผิดชอบแต่ละแอป เรื่อง log ของ SaaS ดู Cloud Logging และ Detection: ต้องเก็บ log อะไร
เลือก baseline จากแหล่งที่เป็นกลาง
องค์กรไม่ต้องคิดค่ามาตรฐานเองทั้งหมด CISA (หน่วยงานด้านความมั่นคงปลอดภัยไซเบอร์ของสหรัฐฯ) มีโครงการ SCuBA (Secure Cloud Business Applications) ซึ่งเริ่มในปี 2022 โครงการนี้เผยแพร่ secure configuration baseline คือเอกสารที่ระบุค่าที่ควรตั้ง สำหรับ Microsoft 365 และ Google Workspace นอกจากนี้ยังมีเครื่องมือฟรีสองตัว คือ ScubaGear สำหรับ Microsoft 365 และ ScubaGoggles สำหรับ Google Workspace เครื่องมือเหล่านี้อ่านการตั้งค่าของคุณแล้วเทียบกับ baseline ให้ ผลออกมาเป็นรายงานแบบเว็บเพจ (HTML) และไฟล์ข้อมูล JSON (รูปแบบข้อมูลที่โปรแกรมอ่านต่อได้ง่าย)
SCuBA เขียนขึ้นสำหรับหน่วยงานรัฐบาลกลางสหรัฐฯ เป็นหลัก ในเดือนธันวาคม 2024 CISA ออกคำสั่ง BOD 25-01 บังคับให้หน่วยงานเหล่านั้นใช้ baseline นี้ องค์กรอื่นนำไปใช้อ้างอิงได้ แต่ไม่ได้ถูกบังคับ และ SCuBA ครอบคลุมเฉพาะสองผลิตภัณฑ์ข้างต้น สำหรับแอปอื่นต้องใช้ baseline ของผู้ให้บริการเอง หรือใช้กรอบของ CSA ชื่อ SaaS Security Capability Framework (SSCF) ซึ่งเผยแพร่เวอร์ชัน 1.0 ในปี 2025 กรอบนี้ไม่ใช่รายการค่าที่ต้องตั้งในแอปใดแอปหนึ่ง แต่เป็นรายการมาตรการที่ผู้ให้บริการควรมีให้ลูกค้าตั้งค่าได้ องค์กรใช้กรอบนี้ประเมินผู้ให้บริการก่อนซื้อ และใช้เทียบกับคำตอบที่ผู้ให้บริการให้มา
ขั้นตอนดูแลแอป SaaS
ขั้นตอนนี้เป็นแนวปฏิบัติที่เราเรียบเรียงเองจากแหล่งข้างต้น ให้ทำซ้ำเป็นรอบ ไม่ใช่ทำครั้งเดียว
- ทำบัญชีรายการแอป: รวบรวมแอป SaaS ทั้งหมดที่องค์กรใช้ รวมถึงแอปที่พนักงานสมัครเอง โดยดูจากใบแจ้งหนี้ ระบบ login กลาง และรายการแอปที่ได้รับสิทธิ์ OAuth
- กำหนดเจ้าของและจัดลำดับ: ให้แต่ละแอปมีเจ้าของที่ระบุชื่อได้ แล้วจัดลำดับตามข้อมูลที่แอปเก็บ โดยเริ่มจากแอปที่ถือข้อมูลสำคัญ หรือมีสิทธิ์ผู้ดูแลระบบกว้าง
- ตั้งค่าตาม baseline: ใช้ baseline ที่เลือกไว้ และบันทึกข้อยกเว้นที่ยอมรับได้พร้อมเหตุผล
- รวมตัวตนไว้ที่ศูนย์กลาง: ให้แอปล็อกอินผ่านระบบกลาง (SSO คือการล็อกอินครั้งเดียวแล้วใช้ได้หลายแอป) และบังคับ MFA เมื่อพนักงานลาออก จะปิดบัญชีที่ศูนย์กลางจุดเดียวได้
- เฝ้าระวังและตรวจซ้ำ: ส่ง log ของแอปเข้าระบบเฝ้าระวัง ตรวจการตั้งค่าซ้ำตามรอบ ด้วยมือหรือด้วย SSPM และทบทวนแอปที่เชื่อมต่อทุกรอบ
ข้อผิดพลาดที่พบบ่อย
- เชื่อว่าผู้ให้บริการดูแลความปลอดภัยให้ทั้งหมด: ผู้ให้บริการดูแลระบบเบื้องหลัง แต่การตั้งค่า สิทธิ์ และการแชร์ข้อมูลยังเป็นหน้าที่ขององค์กร
- ตั้งค่าครั้งเดียวแล้วไม่กลับมาตรวจ: การตั้งค่าเปลี่ยนได้ทุกเมื่อ ทั้งจากผู้ดูแลระบบและจากการอัปเดตของผู้ให้บริการ
- ไม่มีใครเป็นเจ้าของแอป: เมื่อเกิดปัญหา ไม่มีใครรู้ว่าต้องถามใคร หรือใครต้องแก้
- ปล่อยให้ผู้ใช้อนุญาตแอปภายนอกได้อิสระ: ผู้ใช้กดอนุญาตให้แอปอ่านอีเมลหรือไฟล์ได้เอง โดยไม่มีการตรวจสอบก่อน
- ซื้อ SSPM ก่อนมีบัญชีรายการแอป: เครื่องมือเห็นได้เฉพาะแอปที่เชื่อมต่อไว้ ดังนั้นต้องรู้ก่อนว่ามีแอปอะไรบ้าง
ข้อผิดพลาด
- คิดว่าผู้ให้บริการดูแลหมดแล้ว
- ตั้งค่าครั้งเดียวแล้วไม่ตรวจซ้ำ
- ปล่อยให้ผู้ใช้อนุญาตแอปภายนอกเอง
แนวปฏิบัติ
- รู้ว่าส่วนไหนเป็นหน้าที่ของเรา
- ตรวจการตั้งค่าตามรอบ
- ทบทวนแอปที่เชื่อมต่อทุกรอบ
ขั้นแรกที่ทำได้ทันที
- เลือก 5 แอปแรก: เลือกจากข้อมูลที่แอปเก็บ เช่น อีเมล ไฟล์ HR และระบบการเงิน
- ถ้าใช้ Microsoft 365 หรือ Google Workspace: อ่าน baseline ของ SCuBA แล้วลองรัน ScubaGear หรือ ScubaGoggles กับบัญชีองค์กรสำหรับทดสอบ (test tenant) ก่อน
- ตรวจรายการแอปที่ได้รับสิทธิ์ OAuth: ถอนสิทธิ์แอปที่ไม่มีใครรู้จักหรือไม่ได้ใช้แล้ว
- ตรวจผู้ดูแลระบบและบัญชีแขก: ลดจำนวนผู้ดูแลระบบให้เหลือเท่าที่จำเป็น และปิดบัญชีที่ไม่มีเจ้าของ
หากต้องการทราบว่าการควบคุมแอป SaaS ขององค์กรอยู่ในระดับใด ลองใช้ แบบประเมินตนเอง
แหล่งอ้างอิงและข้อมูลเพิ่มเติม
- CISA: SCuBA Project: ภาพรวมของโครงการ baseline และเครื่องมือ
- ScubaGear: เครื่องมือตรวจ Microsoft 365 เทียบกับ baseline
- ScubaGoggles: เครื่องมือตรวจ Google Workspace เทียบกับ baseline
- CISA BOD 25-01: Implementing Secure Practices for Cloud Services: คำสั่งสำหรับหน่วยงานรัฐบาลกลางสหรัฐฯ
- CSA: SaaS Security Capability Framework (SSCF): กรอบมาตรการที่ผู้ให้บริการ SaaS ควรมีให้ลูกค้า
- CSA: SaaS Governance Best Practices for Cloud Customers: ความเสี่ยงและมาตรการฝั่งลูกค้าตลอดวงจรการใช้ SaaS
- MITRE ATT&CK: Cloud Matrix: เทคนิคของผู้โจมตีที่ครอบคลุม SaaS, IaaS (บริการเช่าเครื่องและเครือข่าย) และระบบตัวตน
- MITRE ATT&CK T1528: Steal Application Access Token: เทคนิคที่เกี่ยวกับ token ของแอปที่เชื่อมต่อ