ConnectWise ปิดระบบสำรองข้อมูล—ผู้ดูแล Microsoft 365 ต้องตรวจ 7 แอป

ณ วันที่ 19 ตุลาคม 2026 ConnectWise ยังคงระงับ Cloud Backup, SaaS Security และ Cloud Management หลังพบการเข้าถึงตัวตนแอปที่เกี่ยวข้องโดยไม่ได้รับอนุญาต โดยประกาศของ ConnectWise ระบุว่าบริษัทปิดการเชื่อมต่อของตัวตนแอป 7 รายการแล้ว แต่งานสำรองตามกำหนด การเข้าถึงคลังสำรอง และการกู้คืนผ่าน Cloud Backup ยังไม่พร้อมใช้งาน ผู้ดูแล Microsoft 365 จึงต้องตรวจสถานะของแอปเหล่านั้นใน tenant ของตนเองควบคู่กับการหาทางกู้คืนข้อมูลระหว่างบริการหยุด

รายงานของ Security.io วันที่ 19 ตุลาคม 2026 อธิบายเหตุนี้ว่าเป็นทั้งปัญหาตัวตนแอปใน Microsoft 365 และปัญหาความต่อเนื่องของการสำรองข้อมูล การปิดการเชื่อมต่อฝั่งผู้ขายช่วยหยุดการยืนยันตัวตนใหม่ผ่านช่องทางที่ถูกปิด แต่ไม่ย้อนการเปลี่ยนสิทธิ์หรือ credential ที่อาจเกิดขึ้นภายใน tenant ลูกค้าแล้ว สำหรับองค์กรไทยที่ใช้ผู้ให้บริการภายนอก คำถามจึงมีทั้งว่าแอปเคยทำอะไรใน tenant และมีสำเนาข้อมูลชุดใดที่กู้ได้จริงในเวลานี้

บริการที่หยุดและขอบเขตของข้อมูลสำรอง

ConnectWise ระงับ Cloud Backup หลังพบตัวบ่งชี้ของกิจกรรมที่ไม่ได้รับอนุญาต ส่วน SaaS Security และ Cloud Management ถูกระงับเพื่อป้องกันไว้ก่อนเพราะทำงานเชื่อมโยงกับบริการสำรองข้อมูล ผลที่เกิดกับลูกค้าแตกต่างกันตามบริการ: Cloud Backup ไม่ทำงานสำรองตามกำหนดและยังเปิดคลังหรือกู้คืนผ่านระบบไม่ได้; SaaS Security หยุดการเฝ้าระวังและแจ้งเตือน; Cloud Management หยุดงานจัดการผู้ใช้และไลเซนส์ผ่านบริการดังกล่าว

ในการอัปเดตวันที่ 20 ตุลาคม บริษัทระบุว่าคลังสำรองเดิมยังถูกเข้ารหัส แยกเก็บ และรักษาไว้ โดยยังไม่มีข้อบ่งชี้ว่าคลังเหล่านั้นถูกเข้าถึง ข้อค้นพบนี้ว่าด้วยข้อมูลสำรองที่จัดเก็บอยู่เท่านั้น สถานะของข้อมูลและการตั้งค่าใน Microsoft 365 tenant แต่ละแห่งต้องตรวจจากหลักฐานของ tenant นั้นเอง เพราะระบบสำรองข้อมูลของผู้ขายไม่ได้ให้ภาพกิจกรรมทั้งหมดที่เกิดภายในสภาพแวดล้อมลูกค้า

การปิดตัวตนแอปฝั่ง ConnectWise และการเพิกถอน certificate ของการเชื่อมต่อที่เกี่ยวข้องทำให้ credential ร่วมของ Cloud Backup ใช้ผ่านช่องทางนั้นไม่ได้แล้ว อย่างไรก็ดี access token ที่ออกก่อนมาตรการกักกันอาจใช้ได้จนกว่าจะหมดอายุหรือถูกทำให้ใช้ไม่ได้ และ credential ที่ถูกเพิ่มให้ตัวตนอื่นภายใน tenant ต้องจัดการแยกต่างหาก ความต่างนี้เป็นเหตุผลที่การแจ้งว่าผู้ขายปิดระบบแล้วไม่อาจใช้แทนผลตรวจ tenant ของลูกค้า

สำหรับลูกค้าที่ซื้อบริการผ่านตัวแทนจำหน่ายหรือผู้ให้บริการจัดการระบบ ควรระบุผู้รับผิดชอบให้ตรงกับสิทธิ์ที่มีจริง: ใครเข้าถึง Entra ของแต่ละ tenant ได้ ใครเก็บบันทึกเหตุการณ์ ใครอนุมัติการแก้สิทธิ์ และใครตัดสินใจเรื่องการกู้คืน ผู้ดูแลฝั่งลูกค้าอาจต้องทำงานร่วมกับผู้ให้บริการหลายราย หากแอปสำรองข้อมูลและแอปรักษาความปลอดภัยมีเจ้าของหรือสิทธิ์ดูแลต่างกัน การส่งต่อชื่อผู้รับผิดชอบและช่วงเวลาที่ตรวจแล้วช่วยป้องกันช่องว่างระหว่างการกักกันเหตุฝั่งผู้ขายกับการตรวจฝั่งลูกค้า

จับคู่ตัวตนแอปทั้ง 7 รายการใน tenant

จุดเริ่มต้นคือค้นหา Enterprise applications ใน Microsoft Entra ด้วย Application ID ไม่ใช่อาศัยชื่อที่แสดงเพียงอย่างเดียว การติดตั้งเก่าบางแห่งยังใช้ชื่อ SkyKick และแอปที่ชื่อคล้ายกันอาจมีตัวตนคนละรายการ แอปที่ ConnectWise ปิดการเชื่อมต่อและให้ผู้ดูแลตรวจสถานะใน tenant มีดังนี้:

• ConnectWise Cloud Backup — 506e08f9-6e9a-4da4-942b-a099a03644ae
• ConnectWise Cloud Management — 2399d300-6fca-4e6a-a686-399fefe75b83
• Cloud Management - MS Teams — 24205314-2b89-4e07-a2a4-579e898a5640
• Cloud Management - Exchange Online — b78f6a77-d4e5-46fb-87e5-d1648bd02519
• Cloud Management - MS Graph — 0de14c77-b9b0-4137-9360-34878a929827
• Cloud Management - Partner Center — 412dcf96-176d-4b3a-a1b0-4981ad66971e
• Cloud Management - SharePoint Online — b2b55f5b-7758-4719-8d8f-88ae172e6bdb

รายการนี้เป็นขอบเขตสำหรับตรวจและกักกัน ไม่ได้หมายความว่าพบการใช้ทุกแอปเพื่อเข้าถึงทุก tenant ผู้ดูแลควรบันทึก tenant ID, Application ID, Object ID ที่เป็นของ tenant นั้น และสถานะการอนุญาตให้ลงชื่อเข้าใช้สำหรับรายการที่พบ Object ID ช่วยผูกบันทึกเหตุการณ์เข้ากับตัวตนภายใน tenant ได้แม้ชื่อแอปจะถูกเปลี่ยน หรือมีชื่อเก่าปรากฏอยู่ในบันทึก

หากแอปที่เกี่ยวข้องยังเปิดให้ลงชื่อเข้าใช้ ผู้มีสิทธิ์ควรตั้งค่าปิดใน Enterprise applications แล้วตรวจว่าระบบบันทึกสถานะใหม่จริง จดผู้ดำเนินการและเวลา UTC ไว้พร้อมรายการที่เปลี่ยน การปิดใช้งานรักษาการตั้งค่าเดิมไว้ให้ตรวจสอบต่อได้ ส่วนการลบแอปทันทีอาจทำให้เทียบสิทธิ์เดิมกับบันทึกเหตุการณ์ยากขึ้น ผู้ดูแลจึงควรเก็บหลักฐานก่อนตัดสินใจลบสิ่งใดออกจาก tenant

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

เก็บหลักฐาน Entra และไล่สิทธิ์ที่อาจคงอยู่

เหตุที่ต้องตรวจต่อหลังปิดแอปเห็นได้จากการสอบสวนของ Huntress: ใน tenant ลูกค้ารายหนึ่งเมื่อวันที่ 15 ตุลาคม 2026 ตัวตน Cloud Management สำหรับ MS Teams ได้รับบทบาท Global Administrator แล้วมีการเพิ่ม client secret ให้แอปอื่น 2 รายการ ซึ่งรวมแอปของ Huntress เอง การปิดแอป ConnectWise จึงไม่ลบ secret ที่ถูกเพิ่มให้แอปปลายทาง และ secret นั้นอาจใช้สิทธิ์เดิมของแอปปลายทางเพื่อลงชื่อเข้าใช้ต่อได้จนกว่าจะถูกเพิกถอน

หลักฐานชุดแรกควรมาจาก Service principal sign-ins และ Entra Audit logs ของทั้ง tenant ผู้ให้บริการและ tenant ลูกค้าที่ดูแลอยู่ จากนั้นเก็บบันทึกกิจกรรม Microsoft 365 ใน Purview เท่าที่องค์กรมีสิทธิ์และมีการบันทึกไว้ ระบุช่วงเวลาที่ส่งออก เขตเวลา ประเภทบันทึก และช่องว่างของข้อมูลให้ชัด การเก็บหลักฐานไม่ควรทำให้การปิดการเข้าถึงที่ยังเปิดอยู่ล่าช้า แต่ควรทำเร็วพอที่จะไม่สูญเสียบันทึกตามระยะเวลาเก็บของระบบ

ในการค้นหาการลงชื่อเข้าใช้ ให้ใช้ Application ID ของแอปแต่ละรายการเป็นแกน แล้วดูผลสำเร็จหรือความล้มเหลว เวลา แหล่งที่มา ทรัพยากรที่ขอเข้าถึง และ correlation ID หากระบบรวมหลายเหตุการณ์ไว้ในแถวเดียวต้องเปิดดูรายการย่อยด้วย ที่อยู่ IP 144.172.64.128 เป็นตัวบ่งชี้สำคัญสำหรับการค้นหา แต่ไม่ควรใช้เป็นตัวกรองเดียว เพราะกิจกรรมที่นำไปสู่การเพิ่ม credential ในกรณีที่ Huntress ตรวจพบมาจากช่วงที่อยู่ IPv6 ภายใน Azure

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

ลำดับถัดไปคือดู Audit logs ของการเพิ่มหรือแก้ client secret, certificate และ federated credential รวมถึงการเปลี่ยน owner, consent, API permission และบทบาทไดเรกทอรี ต้องค้นหาแอปที่เกี่ยวข้องทั้งในฐานะผู้เริ่มการเปลี่ยนและเป้าหมายของการเปลี่ยน หากแอปหนึ่งแก้ credential ของแอปจัดการระบบหรือแอปรักษาความปลอดภัยอีกตัว ให้ตามต่อที่แอปปลายทาง แม้แอปนั้นไม่ได้อยู่ในรายชื่อที่ผู้ขายปิดการเชื่อมต่อ

สำหรับแอปที่องค์กรลงทะเบียนเอง ผู้ดูแลสามารถเทียบข้อมูลใน App registrations กับประวัติการเปลี่ยนที่ได้รับอนุมัติ ส่วนแอปหลาย tenant ของผู้ขายอาจไม่ปรากฏเป็น app registration ใน tenant ลูกค้า จึงต้องตรวจ service principal ใน Enterprise applications และใช้สิทธิ์ที่เหมาะสมเข้าถึงข้อมูล credential ที่เกี่ยวข้อง บันทึกรหัสอ้างอิง credential และช่วงเวลาที่มีผล แต่ไม่เก็บค่า secret จริงลงในรายงานเหตุการณ์ วันที่หมดอายุของ secret บอกอายุการใช้งานที่ตั้งไว้ ไม่ได้พิสูจน์วันที่มันถูกเพิ่ม

การตรวจบทบาทควรให้ความสำคัญกับ Global Administrator และบทบาทที่แก้แอป สิทธิ์ หรือกล่องจดหมายของผู้อื่นได้ ตรวจทั้งการมอบบทบาทให้ service principal และการเพิ่มเจ้าของหรือความยินยอมให้แอป เมื่อพบรายการที่ไม่คุ้นเคย ให้เทียบผู้เริ่มเหตุการณ์ เวลา เป้าหมาย และคุณสมบัติที่เปลี่ยนกับงานที่ได้รับอนุมัติก่อนจัดว่าเป็นการกระทำที่ไม่ชอบด้วยสิทธิ์ จากนั้นเก็บหลักฐานและให้ผู้รับผิดชอบเพิกถอน credential หรือสิทธิ์ที่ยืนยันแล้วว่าไม่ถูกต้อง พร้อมตรวจว่าช่องทางเข้าถึงนั้นใช้ต่อไม่ได้

อีกด้านหนึ่งของการตรวจคือผลที่อาจคงอยู่ในงานประจำวัน ตรวจการสร้างหรือแก้กฎกล่องจดหมาย การส่งต่ออีเมลออกนอกองค์กร สิทธิ์อ่านหรือส่งแทนผู้อื่น และกฎการขนส่งอีเมลใน Exchange ควบคู่กับการเปลี่ยนนโยบาย Conditional Access และกิจกรรมใน SharePoint, OneDrive หรือ Teams ตามบันทึกที่มี สิ่งเหล่านี้ต้องผูกกับเวลาและตัวตนที่ลงมือจริง ไม่ควรตีความการมีสิทธิ์กว้างหรือ IP ที่ตรงกับตัวบ่งชี้ว่าเป็นหลักฐานการคัดลอกข้อมูลโดยลำพัง

กู้คืนอย่างไรระหว่าง Cloud Backup ยังหยุด

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

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

องค์กรที่ใช้ผู้ให้บริการภายนอกควรตกลงจุดตัดสินใจร่วมกันก่อนเชื่อมต่อแอปกลับ: tenant ใดตรวจสิทธิ์และ credential แล้ว รายการใดยังอธิบายไม่ได้ หลักฐานช่วงใดขาดหาย และใครยอมรับความเสี่ยงของการเริ่มงานสำรองใหม่ ConnectWise ระบุว่าจะคืนบริการเป็นระยะหลังตรวจมาตรการแก้ไขและความปลอดภัย พร้อมออกคำแนะนำเรื่องการเชื่อมต่ออีกครั้ง เมื่อถึงขั้นนั้นผู้ดูแลยังต้องตรวจการเชื่อมต่อของแต่ละ workload และผลสำเร็จของงานสำรองชุดใหม่ใน tenant ของตนเอง