ผู้ให้บริการกลายเป็นพื้นที่เสี่ยงภัย
ตลอดทศวรรษที่ผ่านมา ทีมรักษาความปลอดภัยขององค์กรต่างมุ่งเน้นการป้องกันแบบ perimeter: รักษาความปลอดภัยเครือข่าย ปกป้อง endpoint และควบคุมการเข้าถึงระบบภายใน โมเดลภัยคุกคามสันนิษฐานว่าผู้โจมตีจะพยายามเจาะเข้าองค์กรโดยตรง
ข้อมูลการละเมิด SaaS ปี 2024 แสดงให้เห็นว่าโมเดลนี้ล้าสมัยแล้ว การละเมิด SaaS พุ่งสูงขึ้น 300% ในปี 2024 ตามรายงาน SaaS Security Threat Report 2025 ของ Obsidian Security ผู้โจมตีไม่ได้มุ่งเป้าไปที่องค์กรโดยตรงอีกต่อไป แต่มุ่งเป้าไปที่ผู้ให้บริการ SaaS ที่องค์กรเหล่านั้นไว้วางใจในการจัดเก็บข้อมูล
เมื่อผู้ให้บริการของคุณคือพื้นที่เสี่ยงภัย ความปลอดภัยของเครือข่ายภายในไม่มีความหมายใดๆ ข้อมูลลูกค้า บันทึกพนักงาน และข้อมูลทางธุรกิจที่ละเอียดอ่อนอยู่บนโครงสร้างพื้นฐานของผู้ให้บริการ เข้าถึงได้ด้วยกุญแจของผู้ให้บริการ และถูกเปิดเผยเมื่อระบบของพวกเขาถูกโจมตี
ตัวเลขการละเมิด SaaS ปี 2024
ขนาดของการละเมิด SaaS ปี 2024 แสดงให้เห็นถึงความเสี่ยง:
Conduent ประสบการละเมิดที่เปิดเผย บันทึก 25.9 ล้านรายการ Conduent ให้บริการ outsourcing กระบวนการทางธุรกิจแก่หน่วยงานรัฐบาลและองค์กรขนาดใหญ่ รวมถึงการจัดการสวัสดิการ การประมวลผลการชำระเงิน และพอร์ทัลบริการประชาชน บุคคล 25.9 ล้านรายที่ได้รับผลกระทบไม่ทราบด้วยซ้ำว่าข้อมูลของตนถูกเก็บไว้โดยผู้ให้บริการบุคคลที่สาม
NHS Digital ประสบการละเมิดที่ส่งผลกระทบต่อ ผู้ป่วย 9 ล้านคน การละเมิด NHS เปิดเผยข้อมูลผู้ป่วยที่ผ่านโครงสร้างพื้นฐานของผู้ให้บริการ SaaS ซึ่งเป็นข้อมูลทางคลินิกที่ผู้ป่วยมอบให้แก่ผู้ให้บริการด้านสุขภาพ โดยไม่มีเหตุผลให้เชื่อว่าข้อมูลถูกส่งต่อไปยังแพลตฟอร์มบุคคลที่สาม
นี่ไม่ใช่เหตุการณ์ผิดปกติ แต่เป็นบรรทัดฐานใหม่ของการรั่วไหลข้อมูล: การละเมิดขนาดใหญ่ที่ส่งผลกระทบต่อบุคคลนับล้านที่มอบข้อมูลให้แก่องค์กรที่ตนไว้วางใจ ซึ่งส่งต่อข้อมูลนั้นไปยังผู้ให้บริการที่บุคคลเหล่านั้นไม่รู้จักด้วยซ้ำ
เหตุใดการละเมิด SaaS จึงแตกต่างในเชิงโครงสร้าง
การละเมิดเครือข่ายแบบดั้งเดิมต้องการให้ผู้โจมตีเจาะผ่าน perimeter ขององค์กร นำทางผ่านระบบภายใน และขโมยข้อมูลออกไป ซึ่งเป็นกระบวนการหลายขั้นตอนที่มีโอกาสตรวจจับหลายครั้ง
การละเมิด SaaS ทำงานแตกต่างออกไป ผู้โจมตีที่เจาะระบบผู้ให้บริการ SaaS ได้จะสามารถเข้าถึงข้อมูลของลูกค้าทุกรายที่ประมวลผลข้อมูลผ่านผู้ให้บริการนั้น การโจมตีครั้งเดียวได้ข้อมูลบันทึกลูกค้าจากองค์กรหลายสิบหรือหลายร้อยแห่งพร้อมกัน
ช่วงเวลาการละเมิด 9 นาที ซึ่งเป็นเวลาตั้งแต่เข้าถึงครั้งแรกจนถึงการขโมยข้อมูลในสภาพแวดล้อม SaaS ตามข้อมูลการตอบสนองต่อเหตุการณ์ของ Obsidian Security สะท้อนถึงความแตกต่างเชิงโครงสร้างนี้ เมื่ออยู่ในโครงสร้างพื้นฐานของผู้ให้บริการ ผู้โจมตีพบข้อมูลจากหลายองค์กรที่จัดเก็บในสภาพแวดล้อมร่วมกัน พื้นที่เสี่ยงภัยรวมศูนย์มูลค่าไว้
สำหรับองค์กรที่ลงนาม Data Processing Agreement ที่สอดคล้อง GDPR กับผู้ให้บริการ SaaS การละเมิดไม่ได้ขจัดความรับผิดด้านการปฏิบัติตามกฎระเบียบ GDPR มาตรา 82 กำหนดความรับผิดร่วมกันต่อผู้ประมวลผลข้อมูลสำหรับการละเมิดที่เกิดจากการไม่ปฏิบัติตามข้อผูกพัน GDPR แต่ความรับผิดร่วมกันต้องพิสูจน์ว่าผู้ให้บริการไม่ปฏิบัติตาม ซึ่งเป็นการสืบสวนที่ซับซ้อนใช้เวลาหลายเดือนในขณะที่ข้อมูลอยู่ในมือของผู้ก่อภัยคุกคามแล้ว
DPA ไม่ได้ปกป้องข้อมูล
GDPR มาตรา 28 กำหนดให้องค์กรใช้เฉพาะผู้ประมวลผลที่ให้ "การรับประกันที่เพียงพอ" ในการดำเนินมาตรการทางเทคนิคและองค์กรที่เหมาะสม Data Processing Agreement คือหลักฐานตามสัญญาของการรับประกันเหล่านั้น
เช่นเดียวกับ BAA ของ HIPAA, DPA ครอบคลุมความสัมพันธ์ตามสัญญา ไม่ได้ครอบคลุมความเป็นจริงทางเทคนิคของสิ่งที่เกิดขึ้นกับข้อมูลของคุณในโครงสร้างพื้นฐานของผู้ให้บริการ
ผู้ให้บริการ SaaS ที่ดำเนินการภายใต้ DPA ที่สอดคล้อง GDPR ยังคงอาจ:
- จัดเก็บข้อมูลลูกค้าของคุณโดยใช้การเข้ารหัสฝั่งเซิร์ฟเวอร์ด้วยกุญแจที่ผู้ให้บริการควบคุม
- ประมวลผลข้อมูลพนักงานของคุณในสภาพแวดล้อม multi-tenant ที่ใช้ร่วมกับลูกค้าอื่น
- เก็บบันทึกข้อมูล บันทึกการประมวลผล และเนื้อหาที่แคชไว้เกินกว่าวัตถุประสงค์ที่ระบุในสัญญา
- ถูกโจมตีในลักษณะที่เปิดเผยข้อมูลทั้งหมดข้างต้น
DPA สร้างข้อผูกพัน แต่ไม่ได้สร้างอุปสรรคทางเทคนิคต่อการเปิดเผยข้อมูล เมื่อผู้โจมตีเจาะระบบผู้ให้บริการภายใน 9 นาที DPA ไม่ได้ชะลอพวกเขา
การพุ่งสูง 300% คือผลของการเปลี่ยนแปลงโครงสร้าง
การพุ่งสูง 300% ของการละเมิด SaaS สะท้อนถึงสองแนวโน้มที่ดำเนินการพร้อมกัน
ประการแรก ปริมาณข้อมูลในแพลตฟอร์ม SaaS เพิ่มขึ้นอย่างมากในปี 2024 เมื่อองค์กรมากขึ้นย้ายกระบวนการมากขึ้นไปยังผู้ให้บริการบนคลาวด์ ข้อมูลที่มีอยู่ในสภาพแวดล้อมของผู้ให้บริการก็เพิ่มขึ้นตามสัดส่วน ข้อมูลมากขึ้นในโครงสร้างพื้นฐานของผู้ให้บริการสร้างแรงจูงใจมากขึ้นสำหรับผู้โจมตีในการมุ่งเป้าไปที่โครงสร้างพื้นฐานของผู้ให้บริการ
ประการที่สอง ผู้โจมตีได้ปรับวิธีการของตนให้สอดคล้องกับการรวมศูนย์มูลค่า ปัจจุบันองค์กรประมวลผลข้อมูลที่ละเอียดอ่อนมากขึ้นผ่านผู้ให้บริการ SaaS มากขึ้นกว่าที่เคย ได้แก่ บันทึกลูกค้า ธุรกรรมทางการเงิน ข้อมูล HR เอกสารทางกฎหมาย ข้อมูลด้านสุขภาพ ผู้ให้บริการ SaaS กลายเป็นเป้าหมายที่มีมูลค่าสูงเพราะการเจาะระบบผู้ให้บริการรายเดียวได้ข้อมูลจากหลายองค์กร
ตัวเลข 300% อธิบายถึงการเปลี่ยนแปลงเชิงโครงสร้างในทิศทางการโจมตี ไม่ใช่แค่การเพิ่มขึ้นของกิจกรรมอาชญากรรมทั่วไป
สถาปัตยกรรม Zero-Knowledge ในฐานะมาตรการบรรเทาความเสี่ยงจากผู้ให้บริการ
การเปลี่ยนแนวคิดที่สถาปัตยกรรม zero-knowledge ต้องการนั้นตรงไปตรงมา: หากผู้ให้บริการของคุณไม่สามารถไว้ใจให้จัดเก็บข้อมูลของคุณอย่างปลอดภัย ไม่ใช่เพราะความล้มเหลวเฉพาะเจาะจง แต่เพราะผู้ให้บริการใดก็ตามอาจถูกเจาะระบบ ข้อมูลของคุณก็ไม่ควรถึงมือผู้ให้บริการในรูปแบบที่ระบุตัวตนได้
การทำให้ไม่ระบุตัวตนแบบ zero-knowledge ก่อนส่งต่อไปยังผู้ให้บริการ SaaS เปลี่ยนแปลงความเสี่ยงจากการละเมิดอย่างพื้นฐาน เมื่อผู้ให้บริการที่ใช้ข้อมูลที่ผ่านกระบวนการ zero-knowledge ถูกเจาะระบบ:
- ผู้โจมตีเข้าถึงบันทึกที่ไม่ระบุตัวตนโดยไม่มีตัวระบุลูกค้าที่กู้คืนได้
- ไม่จำเป็นต้องแจ้งเตือนเจ้าของข้อมูลเนื่องจากไม่มีการเปิดเผยข้อมูลส่วนบุคคล
- ไม่จำเป็นต้องสืบสวนความรับผิดร่วมกันตาม GDPR มาตรา 82
- ไม่มีผลการบังคับใช้ด้านกฎระเบียบจากการละเมิด
การละเมิดส่งผลกระทบต่อผู้ให้บริการ แต่ไม่ส่งผลกระทบต่อข้อมูลลูกค้าของคุณ เพราะข้อมูลลูกค้าไม่เคยอยู่บนเซิร์ฟเวอร์ของผู้ให้บริการในรูปแบบที่กู้คืนได้
การพุ่งสูง 300% ของการละเมิด SaaS เปลี่ยนการคำนวณความเสี่ยงจากผู้ให้บริการ องค์กรที่ประเมินผู้ให้บริการเฉพาะจากท่าทีด้านความปลอดภัยและข้อผูกพันตามสัญญากำลังไว้วางใจว่าผู้ให้บริการของตนจะไม่ปรากฏในสถิติการละเมิดครั้งต่อไป สถาปัตยกรรม zero-knowledge ขจัดการพึ่งพานั้น
แหล่งที่มา: