
ที่มาภาพ: The Register
Microsoft ไม่ได้สัญญาว่าจะสำรองข้อมูลให้คุณ
⚡ สรุป 30 วิ
การสำรองข้อมูลในบริการคลาวด์ของ Microsoft ไม่ได้เป็นความรับผิดชอบของผู้ให้บริการโดยอัตโนมัติ ลูกค้าต้องดูแลแบ็คอัพและเตรียมพร้อมต่อ ransomware เอง.
การกู้คืนข้อมูลหลังการโจมตีแบบ ransomware ไม่ได้หมายความว่า Microsoft จะรับผิดชอบในการสำรองข้อมูลของคุณโดยอัตโนมัติ ความเชื่อที่ว่าบริการ SaaS ของ Microsoft มีระบบแบ็คอัพ “ครบวงจร” นั้นต้องได้รับการตรวจสอบใหม่เพื่อหลีกเลี่ยงความเข้าใจผิดและความเสี่ยงต่อธุรกิจ
Overview
Microsoft ให้บริการแพลตฟอร์มคลาวด์ เช่น M365, Entra ID และโครงสร้างพื้นฐาน Azure ที่ช่วยให้ธุรกิจทำงานได้อย่างรวดเร็วและยืดหยุ่น อย่างไรก็ตาม โมเดลความรับผิดชอบร่วม (shared responsibility) ของ Microsoft ยังคงต้องการให้ลูกค้าเป็นผู้ดูแลข้อมูลของตนเอง ทั้งในเรื่องของการสำรอง การกู้คืน และการป้องกันจากภัยคุกคาม
ตามที่ Brent Torre, GM of cyber resilience ที่ Kaseya ระบุไว้ Microsoft มีเครื่องมือพื้นฐานสำหรับการเก็บรักษาขั้นสั้นและการจัดการข้อมูล (governance) แต่ไม่ได้ออกแบบมาเป็นโซลูชันสำรองข้อมูลหรือป้องกัน ransomware การเข้าใจความแตกต่างนี้จึงเป็นกุญแจสำคัญในการวางแผนการฟื้นตัวขององค์กร
Shared Responsibility Model
โมเดล “shared responsibility” ของ Microsoft แบ่งภาระระหว่างผู้ให้บริการคลาวด์กับลูกค้าอย่างชัดเจน ลูกค้าต้องรับผิดชอบข้อมูล (information), อุปกรณ์ (devices), บัญชีผู้ใช้และตัวตน (identities) ทั้งหมดที่อยู่ในบริการ ไม่ว่าจะเป็น SaaS อย่าง Microsoft 365, แพลตฟอร์มเช่น SQL Server หรือ VM ที่รันบน Azure
เมื่อเกิดการโจมตีและแฮกเกอร์เริ่มลบข้อมูล ลูกค้าเป็นฝ่ายรับความเสี่ยงต่อการสูญเสียโดยตรง Microsoft ไม่ได้มีข้อผูกพันในการคืนข้อมูลไปยังจุดที่ “ดี” ก่อนเหตุการณ์ การตั้งค่า SLAs ที่เข้มงวดสำหรับ MSPs (Managed Service Providers) จึงต้องคำนึงถึงขอบเขตความรับผิดชอบเหล่านี้ด้วย
Evolving Threat Landscape
ภัยคุกคามไซเบอร์ได้เปลี่ยนแปลงอย่างรวดเร็วจากการโจมตีโครงสร้างพื้นฐานไปสู่การทำลายตัวบุคคลโดยใช้ identity เป็นจุดเริ่มต้น การขโมยข้อมูลประจำตัวและการใช้งาน AI เพื่อสร้างฟิชชิงหรืออีเมลหลอกลวง ทำให้แฮกเกอร์สามารถเข้าถึง Entra ID ได้ง่ายขึ้น
เมื่อผู้โจมตีควบคุม Entra ID พวกเขาจะมีสิทธิ์ดึงข้อมูลจาก Mailbox, OneDrive, SharePoint, Teams และแหล่ง SaaS อื่น ๆ ได้โดยไม่ต้องกระตุ้นระบบเตือนภัย การใช้ ransomware หลังจากนั้นจึงเป็นเพียงขั้นตอนต่อเนื่องที่ทำได้อย่างรวดเร็ว
Hybrid Cloud & Backup Gaps
องค์กรหลายแห่งยังคงผสมการใช้งานระหว่าง on‑premise, IaaS/PaaS และ SaaS ทำให้ระดับความปลอดภัยและแผนสำรองข้อมูลแตกต่างกันไป การกระจายข้อมูลเหล่านี้อาจทำให้เกิด “chink in the armor” เมื่อมีการละเมิด
- บางระบบอาจได้รับการแบ็คอัพเป็นประจำในโซลูชันของผู้ให้บริการ
- ระบบอื่น ๆ ที่อยู่บน SaaS อาจพึ่งพาเครื่องมือพื้นฐานของ Microsoft เท่านั้น
ผลที่ตามมาคือไม่มีการรับประกันว่าข้อมูลทั้งหมดจะสามารถกู้คืนได้ในรูปแบบเดียวกันเมื่อเผชิญกับ ransomware
Compliance Pressures
มาตรฐานและข้อกำหนดด้านความปลอดภัยไซเบอร์หลายฉบับกำหนดให้ต้องมีแผนสำรองข้อมูลและการฟื้นตัวอย่างเป็นระบบ แต่หลายองค์กรยังไม่มีความพร้อมเพียงพอ การละเลยเรื่องนี้ไม่เพียงเพิ่มความเสี่ยงต่อการสูญเสียข้อมูลเท่านั้น ยังส่งผลกระทบต่อสถานะการปฏิบัติตามกฎระเบียบ (compliance) อีกด้วย
ตามที่บทวิเคราะห์ของ Kaseya ชี้ให้เห็น องค์กรควรทำ “immutable backup” ที่สามารถเรียกคืนได้แม้ในกรณีที่ผู้ให้บริการคลาวด์หลักหรือแอปพลิเคชัน SaaS ถูกโจมตี
Recommendations
Brent Torre แนะนำให้ใช้โซลูชัน cloud‑to‑cloud backup ที่จัดเก็บข้อมูลสำคัญไว้ภายนอก tenant ของ Microsoft เพื่อสร้าง “immutable copy”
- เลือกผู้ให้บริการที่มีศูนย์ข้อมูลแยกจากคลาวด์ของ Microsoft
- ทำการสำรองอย่างต่อเนื่องและตรวจสอบความสมบูรณ์ของข้อมูลเป็นประจำ
- ปรับกระบวนการเรียกคืนให้สอดคล้องกับข้อกำหนดของ cyber‑insurance และ compliance
วิธีนี้ช่วยให้องค์กรสามารถฟื้นตัวได้เร็วขึ้นโดยไม่ต้องพึ่งพาการสร้าง “shell” ใหม่หรือพยายามเจาะกลับเข้าไปใน tenant ที่ถูกทำลาย
Summary
Microsoft ให้บริการโครงสร้างคลาวด์ที่แข็งแกร่ง แต่ไม่ได้รับประกันการสำรองข้อมูลแบบครบวงจร การเข้าใจโมเดลความรับผิดชอบร่วมและเตรียมสำรองข้อมูลด้วยโซลูชันอิสระเป็นขั้นตอนสำคัญเพื่อให้ธุรกิจสามารถฟื้นตัวจาก ransomware ได้อย่างมีประสิทธิภาพ.
แชร์บทความนี้:
ชอบบทความแบบนี้?
สมัคร AI Automate Weekly Newsletter — รับเคล็ดลับ AI + how-to ใหม่
ทุกสัปดาห์ตรงถึง inbox ฟรี ไม่มีสแปม
แหล่งข่าวต้นฉบับ
- ชื่อต้นฉบับ
- The backup Microsoft never promised you
- ผู้เขียน
- Unknown
- แหล่ง
- The Register
- วันที่เผยแพร่
- 13 สิงหาคม 2569 เวลา 22:00



