เหนือกว่า CSPM: ปิดช่องว่างด้านความปลอดภัยของข้อมูลบนคลาวด์
- CSPM ตรวจพบการตั้งค่าผิดพลาดในโครงสร้างพื้นฐานคลาวด์ แต่ไม่สามารถมองเห็นข้อมูลที่ละเอียดอ่อนภายในได้
- CSPM เป็นพื้นฐานของโครงสร้างพื้นฐาน ไม่ใช่กลยุทธ์ความปลอดภัยข้อมูลบนคลาวด์แบบครบวงจร ส่วน DSPM ช่วยเติมเต็มช่องว่างในการมองเห็นข้อมูล
- องค์กรสมัยใหม่ต้องการวิธีการแบบบูรณาการที่ผสมผสานการมองเห็นโครงสร้างพื้นฐานกับการปกป้องข้อมูลเป็นศูนย์กลาง
ระบบการจัดการสถานะความปลอดภัยบนคลาวด์ (CSPM) ได้กลายเป็นมาตรการควบคุมพื้นฐานสำหรับการระบุการตั้งค่าคลาวด์ที่ผิดพลาด การเบี่ยงเบนจากนโยบาย และการตั้งค่าในชั้นควบคุมที่ไม่ปลอดภัย แต่ระบบนี้ยังไม่สามารถตอบคำถามทั้งหมดที่เกี่ยวข้องกับข้อมูล ซึ่งทีมความปลอดภัยต้องการคำตอบ
CSPM ได้รับการออกแบบมาเพื่อทำให้การประเมินสถานะความปลอดภัยเป็นอัตโนมัติ และตรวจจับความเบี่ยงเบนในสภาพแวดล้อมคลาวด์ มันสามารถระบุบริการที่ถูกเปิดเผย บทบาท IAM ที่มีสิทธิ์มากเกินไป พื้นที่จัดเก็บข้อมูลที่ไม่ได้รับการเข้ารหัส สแนปช็อตสาธารณะ และการละเมิดนโยบายบน AWS, Azure, Google Cloud และแพลตฟอร์ม IaaS อื่น ๆ ความสามารถนี้มีความสำคัญอย่างยิ่ง รายงาน DBIR ของ Verizon ยังคงแสดงให้เห็นว่าข้อผิดพลาดและการตั้งค่าผิดยังคงเป็นปัจจัยสำคัญที่ก่อให้เกิดการละเมิดข้อมูล; อินโฟกราฟิก DBIR ปี 2024 รายงานว่าข้อผิดพลาดคิดเป็น 28% ของการละเมิดข้อมูล โดยการตั้งค่าผิดเป็นรูปแบบข้อผิดพลาดที่พบบ่อย
แต่เครื่องมือ CSPM แบบดั้งเดิมเน้นไปที่การกำหนดค่าโครงสร้างพื้นฐานและความปลอดภัยของระบบควบคุม (control plane) ไม่ใช่เนื้อหาหรือระดับความไวของข้อมูล เครื่องมือเหล่านี้ไม่ตรวจสอบอย่างลึกซึ้งว่าทรัพยากรข้อมูลมีเนื้อหาอะไร ความไวของข้อมูลนั้นเป็นอย่างไร หรือใครสามารถเข้าถึงข้อมูลนั้นได้จริงผ่านช่องทางต่าง ๆ ได้จริง ๆ ตัวอย่างเช่น บักเก็ตเก็บข้อมูลอาจสอดคล้องกับข้อกำหนดด้านการกำหนดค่า แต่ยังคงเปิดเผยข้อมูลลูกค้าผ่านสิทธิ์การเข้าถึงที่แบ่งปันมากเกินไปหรือลิงก์จากภายนอก
ช่องว่างนี้มีความสำคัญ เพราะความเสี่ยงด้านข้อมูลบนคลาวด์ไม่ได้จำกัดอยู่เพียงการตั้งค่าผิดพลาดที่เห็นได้ชัดเท่านั้น เส้นทางการโจมตีบนคลาวด์หลายทางเกี่ยวข้องกับการใช้ข้อมูลรับรองที่ถูกขโมยและการใช้บัญชีที่ถูกต้องอย่างผิดวัตถุประสงค์ ไม่ใช่เพียงข้อผิดพลาดในการตั้งค่าทางเทคนิคเท่านั้น เอกสาร MITRE ATT&CK บันทึกเทคนิคที่ผู้โจมตีใช้บัญชีคลาวด์ที่ถูกต้องเพื่อเข้าถึงทรัพยากรและนำข้อมูลออกไปเก็บไว้ในพื้นที่จัดเก็บข้อมูลบนคลาวด์ ในสถานการณ์ดังกล่าว โครงสร้างพื้นฐานอาจดูเหมือนได้รับการตั้งค่าอย่างถูกต้อง แต่ข้อมูลยังคงถูกเปิดเผยอยู่ แหล่งที่มา: https://attack.mitre.org/
การจัดการความปลอดภัยข้อมูลบนคลาวด์จำเป็นต้องมีความชัดเจนเกี่ยวกับสถานที่จัดเก็บข้อมูลที่ละเอียดอ่อน วิธีการเคลื่อนย้ายข้อมูล ผู้ที่มีสิทธิ์เข้าถึงข้อมูล และระดับความเสี่ยงที่เปลี่ยนแปลงไปตามเวลา ซึ่งหมายความว่าต้องมองไปไกลกว่าการตรวจสอบสถานะความปลอดภัย และต้องครอบคลุมถึงการค้นพบข้อมูล การจัดประเภทข้อมูล การวิเคราะห์ความเสี่ยง และการติดตามตรวจสอบอย่างต่อเนื่องในสภาพแวดล้อมคลาวด์และ SaaS – ซึ่งเป็นความสามารถที่กำหนดแนวทางจัดการความปลอดภัยข้อมูลอย่างครบถ้วน (DSPM)
จุดแข็งของ CSPM
CSPM มีความสามารถสูงในการตรวจพบปัญหาในโครงสร้างพื้นฐานคลาวด์ที่ก่อให้เกิดความเสี่ยงในระดับ control-plane ระบบนี้ติดตามตรวจสอบการตั้งค่าคลาวด์อย่างต่อเนื่องเพื่อเปรียบเทียบกับค่ามาตรฐานและกรอบการปฏิบัติตามข้อกำหนด และสามารถตรวจพบปัญหาต่าง ๆ เช่น:
• พื้นที่เก็บข้อมูลที่เปิดให้สาธารณชนเข้าถึงได้
• บทบาทที่มีสิทธิพิเศษมากเกินไปและสิทธิ์ที่เกินความจำเป็น
• ทรัพยากรที่ไม่ได้รับการเข้ารหัส / การเข้ารหัสถูกปิดใช้งาน
• กลุ่มความปลอดภัยที่เปิดอยู่ และบริการ/ฐานข้อมูลที่ถูกเปิดเผย
• การละเมิดนโยบายภายในหรือข้อกำหนดทางกฎหมาย
สำหรับทีมคลาวด์ ความสามารถในการมองเห็นนี้มีความสำคัญอย่างยิ่ง เพราะช่วยระบุจุดอ่อนในการเสริมความปลอดภัย บังคับใช้นโยบาย และลดความเสี่ยงทั่วไปที่เกิดจากความคลาดเคลื่อนในการตั้งค่า นอกจากนี้ ยังช่วยให้สามารถดำเนินการตรวจสอบแบบซ้ำได้กับผู้ให้บริการคลาวด์หลายราย ซึ่งเป็นเรื่องที่ยากจะทำได้ด้วยมือในขนาดใหญ่
จุดอ่อนของ CSPM
ข้อจำกัดอยู่ที่ขอบเขต CSPM ตรวจสอบความถูกต้องของสภาพแวดล้อม แต่ไม่บอกคุณว่าสภาพแวดล้อมนั้นมีอะไรอยู่

ถังเก็บข้อมูลอาจผ่านการตรวจสอบการควบคุมการกำหนดค่าทุกขั้นตอน แต่ยังคงเก็บข้อมูลที่อยู่ภายใต้การกำกับดูแลได้ พื้นที่ทำงานร่วมกันอาจปฏิบัติตามการตั้งค่าที่ได้รับการอนุมัติ แต่ไฟล์ที่มีความอ่อนไหวกลับถูกแชร์อย่างกว้างขวางเกินไป ฐานข้อมูลบนคลาวด์อาจถูกจำกัดการเข้าถึงที่ชั้นเครือข่าย แต่ผู้ใช้แอปพลิเคชัน บัญชีบริการ หรือสิทธิ์ที่สืบทอดมา อาจก่อให้เกิดความเสี่ยงที่ไม่คาดคิด
นั่นคือเหตุผลที่ CSPM เพียงอย่างเดียวไม่สามารถตอบคำถามที่ทีมความปลอดภัยให้ความสำคัญมากที่สุดได้:
• ข้อมูลที่ละเอียดอ่อนถูกเก็บไว้ที่ไหน?
• ข้อมูลประเภทใด?
• ใครสามารถเข้าถึงได้?
• มันถูกแชร์อย่างไร?
• ปัจจัยเสี่ยงใดที่ก่อให้เกิดความเสี่ยงทางธุรกิจสูงที่สุด?
CSPM แบบดั้งเดิมยังมีความสามารถในการมองเห็นการไหลของข้อมูลระหว่างแพลตฟอร์มที่จำกัด เครื่องมือที่ช่วยรักษาความปลอดภัยให้กับสภาพแวดล้อม AWS ของคุณอาจไม่สามารถมองเห็นได้ว่าข้อมูลเคลื่อนย้ายระหว่าง AWS กับ Microsoft 365, Salesforce หรือบริการคลาวด์อื่น ๆ อย่างไร นอกจากนี้ ยังอาจไม่สามารถตรวจจับคลังข้อมูลเงา (shadow repositories) ที่ถูกสร้างขึ้นผ่านพื้นที่จัดเก็บข้อมูลคลาวด์ส่วนตัว การใช้ SaaS ที่ไม่ได้รับอนุญาต หรือการส่งออกข้อมูลไปยังเครื่องมือการทำงานร่วมกันภายนอก
ทำไมบริบทของข้อมูลจึงส่งผลต่อการจัดลำดับความสำคัญ
ทีมความปลอดภัยอาจต้องเผชิญกับปริมาณข้อมูลผลการตรวจสอบสถานะระบบที่มาก แต่หากขาดบริบทของข้อมูล พวกเขาอาจประสบปัญหาในการจัดลำดับความสำคัญของความเสี่ยงที่มีผลกระทบสูงสุด สภาพแวดล้อมการทดสอบที่มีความเสี่ยงต่ำซึ่งใช้ข้อมูลสังเคราะห์ ไม่ควรได้รับการจัดลำดับความเร่งด่วนในระดับเดียวกับระบบผลิตที่เก็บข้อมูลทางการเงินของลูกค้า

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

การบริหารจัดการความปลอดภัยข้อมูลที่แข็งแกร่งเริ่มต้นจากการสำรวจข้อมูลในระบบคลาวด์และระบบ SaaS โดยต้องระบุให้ชัดเจนว่าข้อมูลนั้นถูกเก็บไว้ที่ใด ไม่ว่าจะเป็นในระบบจัดเก็บข้อมูลบนคลาวด์ เครื่องมือการทำงานร่วมกัน หรือแอปพลิเคชันที่ได้รับการอนุมัติและไม่ได้รับการอนุมัติ
จากจุดนั้น การจัดประเภทจะเพิ่มบริบททางธุรกิจเข้ามา การตรวจสอบเนื้อหาเพียงอย่างเดียวไม่เพียงพอ; ต้องเข้าใจข้อมูลในแง่ของความละเอียดอ่อนและผลกระทบ ซึ่งหมายความว่าต้องแยกแยะระหว่างไฟล์ทั่วไปกับข้อมูลที่อยู่ภายใต้การกำกับดูแล เช่น ข้อมูลส่วนบุคคล (PII), ข้อมูล PCI, เอกสารทางการเงิน หรือทรัพย์สินทางปัญญา
การวิเคราะห์ความเสี่ยงในการเปิดเผยข้อมูลจะระบุวิธีการที่ข้อมูลอาจถูกเข้าถึงได้ ซึ่งรวมถึงสิทธิ์การเข้าถึง การตั้งค่าการแบ่งปัน ลิงก์ภายนอก สิทธิ์การเข้าถึงกลุ่มที่สืบทอดมา การเปิดเผย API การบูรณาการระบบ และพฤติกรรมของผู้ใช้ นอกจากนี้ยังพิจารณาด้วยว่าผู้โจมตีอาจเข้าถึงข้อมูลได้อย่างไรผ่านการบุกรุกบัญชีหรือการเพิ่มระดับสิทธิ์
สุดท้าย การติดตามอย่างต่อเนื่องช่วยให้มั่นใจได้ว่าการเปลี่ยนแปลงในด้านการถ่ายโอนข้อมูล การแบ่งปันข้อมูล และการเข้าถึงข้อมูล จะถูกตรวจพบทันทีที่เกิดขึ้น ในสภาพแวดล้อมคลาวด์ ความเสี่ยงอาจเปลี่ยนแปลงได้อย่างรวดเร็วเมื่อทีมทำงานร่วมกัน ดำเนินการอัตโนมัติ และเชื่อมต่อบริการใหม่
CSPM และ DSPM เป็นระบบที่เสริมกัน
CSPM และ DSPM ไม่ใช่สิ่งทดแทนกัน ทั้งสองช่วยแก้ปัญหาที่แตกต่างกัน และทำงานได้ดีที่สุดเมื่อใช้ร่วมกัน
CSPM ช่วยรักษาความปลอดภัยให้กับชั้นโครงสร้างพื้นฐาน โดยแจ้งให้ทราบว่าทรัพยากรคลาวด์ได้รับการกำหนดค่าอย่างถูกต้องหรือไม่ และมาตรการควบคุมพื้นฐานได้ถูกนำไปใช้แล้วหรือไม่ ส่วน DSPM ช่วยขยายขอบเขตการมองเห็นไปยังชั้นข้อมูล โดยแจ้งให้ทราบว่ามีข้อมูลที่ละเอียดอ่อนใดบ้าง ที่เก็บไว้ที่ไหน ใครสามารถเข้าถึงได้ และข้อมูลดังกล่าวอาจถูกเปิดเผยได้อย่างไร
มุมมองแบบบูรณาการนี้ช่วยให้ทีมความปลอดภัยได้รับคำตอบที่ครบถ้วนยิ่งขึ้นสำหรับทั้งปัญหาด้านโครงสร้างพื้นฐานและข้อมูล นอกจากนี้ยังช่วยในการจัดลำดับความสำคัญของความเสี่ยงได้อย่างมีประสิทธิภาพมากขึ้น เนื่องจากทีมสามารถเชื่อมโยงการตั้งค่าผิดพลาดกับสินทรัพย์และข้อมูลที่ได้รับผลกระทบจริงได้
องค์กรที่ใช้แพลตฟอร์มแบบรวมศูนย์ เช่น โซลูชันSecurity Service Edge SSE) ที่ครบวงจรSkyhigh Security สามารถผสานรวมการมองเห็นทั้งด้านโครงสร้างพื้นฐานและด้านข้อมูล เพื่อจัดการกับการบริหารจัดการข้อมูลบนคลาวด์และความเสี่ยงที่เกี่ยวข้องกับข้อมูลอย่างครบถ้วน
ตัวอย่างในทางปฏิบัติ
ลองพิจารณาทีมพัฒนาที่ส่งโค้ดต้นไปยังพื้นที่จัดเก็บข้อมูลบนคลาวด์เพื่อทำงานร่วมกัน CSPM อาจแสดงว่าบัญชีพื้นที่จัดเก็บข้อมูลดังกล่าวได้รับการเข้ารหัส เป็นแบบส่วนตัว และสอดคล้องกับนโยบายพื้นฐาน ซึ่งดูเป็นที่ยอมรับได้จากมุมมองด้านโครงสร้างพื้นฐาน
แต่การมองเห็นข้อมูลแบบเรียลไทม์อาจเผยให้เห็นภาพที่แตกต่างออกไป ที่เก็บข้อมูลอาจมีอัลกอริทึมที่เป็นกรรมสิทธิ์ สิทธิ์การเข้าถึงของผู้รับจ้างที่หมดอายุแล้ว หรือลิงก์ที่แชร์ซึ่งยังไม่ถูกเพิกถอน ในกรณีนี้ ความเสี่ยงไม่ได้เกิดจากตั้งค่าคลาวด์เพียงอย่างเดียว แต่เป็นผลรวมของการตั้งค่า เนื้อหา และเส้นทางการเข้าถึง
หลักการเดียวกันนี้ใช้กับเครื่องมือการทำงานร่วมกันแบบ SaaS ด้วยเช่นกัน ไฟล์อาจถูกเก็บไว้ในแอปพลิเคชันที่ได้รับการอนุมัติ แต่สามารถถูกแบ่งปันกับฝ่ายภายนอก ถูกส่งต่อผ่านการเป็นสมาชิกกลุ่ม หรือเข้าถึงได้ผ่านแอปพลิเคชันที่เชื่อมต่อกันและการผสานรวม API CSPM ไม่ได้ถูกออกแบบมาเพื่อระบุความสัมพันธ์ในการแบ่งปันข้อมูลเหล่านั้นอย่างละเอียด
ทำไมโปรแกรมคลาวด์สมัยใหม่จึงจำเป็นต้องมีทั้งสองมุมมอง
เมื่อการใช้งานระบบคลาวด์ขยายตัว ข้อมูลที่ละเอียดอ่อนก็กระจายไปทั่วบริการ ตัวตน และช่องทางการทำงานร่วมกันมากขึ้น การควบคุมโครงสร้างพื้นฐานยังคงเป็นสิ่งจำเป็น แต่เพียงการควบคุมโครงสร้างพื้นฐานเพียงอย่างเดียวนั้นไม่เพียงพออีกต่อไป
ระบบความปลอดภัยบนคลาวด์ที่พัฒนาอย่างครบถ้วนจำเป็นต้องมีความสามารถในการมองเห็นข้อมูลอย่างรวมศูนย์ ทั้งในส่วนควบคุม (control planes) และส่วนข้อมูล (data planes) ซึ่งหมายความว่าต้องผสาน CSPM กับความสามารถที่เน้นข้อมูลเป็นศูนย์กลาง ซึ่งสามารถตรวจพบเนื้อหาที่ละเอียดอ่อน ระบุระดับความเสี่ยง และสนับสนุนการตอบสนองตามระดับความเสี่ยง
องค์กรที่นำวิธีการเหล่านี้มาใช้ร่วมกันจะสามารถตอบคำถามต่าง ๆ ได้ดีขึ้น เช่น:
• ทรัพยากรคลาวด์ได้รับการตั้งค่าให้ปลอดภัยแล้วหรือไม่?
• มีข้อมูลที่ละเอียดอ่อนอยู่หรือไม่?
• คนที่เหมาะสมสามารถเข้าถึงข้อมูลนี้ได้หรือไม่?
• ข้อมูลนี้ถูกเปิดเผยผ่านการแชร์ การเชื่อมต่อกับระบบอื่น หรือลิงก์ภายนอกหรือไม่?
• ปัญหาใดควรได้รับการแก้ไขก่อน?
คำถามเหล่านั้นช่วยชี้ให้เห็นความแตกต่างระหว่างการตั้งค่าความปลอดภัยกับสภาพความปลอดภัยของข้อมูล