ConnectWise Cloud Backup გაითიშა — აღდგენა და არქივიც მიუწვდომელია

20 ოქტომბრის 19:00 UTC-ის ოფიციალური განახლებით, ConnectWise Cloud Backup კვლავ შეჩერებულია: გეგმური სარეზერვო ასლები არ იქმნება, არსებულ არქივებზე წვდომა და მონაცემების აღდგენა მიუწვდომელია. შეჩერებულია მასთან ინტეგრირებული SaaS Security და Cloud Management-იც. კომპანიამ დაზიანებულ Cloud Backup გარემოში ანგარიშებისა და წვდომის მონაცემების სრული განულება 19 ოქტომბერს დაასრულა, თუმცა სერვისების დაბრუნებამდე უსაფრთხოების შემოწმებას აგრძელებს.

ინციდენტი Cloud Backup-ის, ადრინდელი SkyKick-ის, აპლიკაციის იდენტობებით Microsoft 365-ის მომხმარებელ გარემოებში უნებართვო შესვლას უკავშირდება. Huntress-ის ინციდენტის კვლევაში აღწერილია 15 ოქტომბერს მომწოდებლის წვდომის მონაცემით მიღებული Microsoft Graph-ის ტოკენები; 16 ოქტომბრის 19:00 UTC-ისთვის მკვლევრებს უნებართვო შესვლები 162 tenant-ში ჰქონდათ დადასტურებული. ეს იმ დროისთვის დადასტურებული შესვლების რაოდენობაა და ყველა შესაძლო დაზარალებული გარემოს საბოლოო მაჩვენებელი არ არის.

როგორ განვითარდა შეჭრა და შეჩერება

Cloud Backup-ს მომხმარებლის Microsoft 365 მონაცემების სარეზერვო ასლების შესაქმნელად ფოსტაზე, ფაილებსა და სხვა რესურსებზე წინასწარ მინიჭებული უფლებები სჭირდება. CSO Online-ის ინციდენტის მიმოხილვა აღწერს, როგორ იღებდა აპლიკაცია მომხმარებელ tenant-ებში Microsoft Graph-ის ტოკენებს ConnectWise-ის გარემოსთან დაკავშირებული წვდომის მონაცემით. ასეთი შესვლა აპლიკაციის სახელით სრულდება: მას თანამშრომლის პაროლი ან მისი მრავალფაქტორიანი ავთენტიფიკაციის მოთხოვნა არ სჭირდება.

17 ოქტომბერს, 07:00 UTC-ზე, ConnectWise-მა შვიდი დაკავშირებული აპლიკაციის იდენტობა გათიშა და Cloud Backup-ის დაზიანებული კავშირებისთვის გამოყენებული სერტიფიკატები გააუქმა. SaaS Security და Cloud Management დამატებითი სიფრთხილის მიზნით შეჩერდა, რადგან Cloud Backup-თან არის ინტეგრირებული. მომწოდებლის მხრიდან კავშირის გათიშვა ახალ ავთენტიფიკაციას ზღუდავს, მაგრამ მომხმარებლის tenant-ში უკვე შეცვლილ უფლებებს ან სხვა აპლიკაციაზე დამატებულ წვდომის მონაცემს თავისთავად ვერ აუქმებს.

გამოკვლეულ ორ tenant-ში Cloud Management-ის Microsoft Teams აპლიკაციამ საკუთარ თავს Global Administrator-ის როლი მიანიჭა და სხვა აპლიკაციებს ახალი საიდუმლო გასაღებები დაუმატა. ერთ-ერთი შეცვლილი აპლიკაცია თავად Huntress-ის უსაფრთხოების ინსტრუმენტი იყო. ეს კონკრეტულ გარემოებში დაკვირვებული მოქმედებებია; ისინი ყველა tenant-ზე ვერ განზოგადდება, მაგრამ ხსნის, რატომ უნდა მოიცვას შემოწმებამ თავდაპირველი Cloud Backup კავშირის მიღმაც არსებული აპლიკაციები.

რა შეზღუდვა მოქმედებს სარეზერვო ასლებზე

Cloud Backup-ის გათიშვისას ახალი გეგმური ასლები არ სრულდება და ადმინისტრატორს არსებული არქივიდან მონაცემების დაბრუნება არ შეუძლია. SaaS Security-ში მიუწვდომელია მონიტორინგი და შეტყობინებები, Cloud Management-ში კი მომხმარებლებისა და ლიცენზიების მართვა. რამდენიმე კლიენტის გარემოზე პასუხისმგებელი MSP-ისთვის ეს ნიშნავს, რომ სარეზერვო ასლების შექმნისა და აღდგენის შეზღუდვა თითოეულ შესაბამის კლიენტთან ცალ-ცალკე უნდა აღირიცხოს.

არსებული სარეზერვო არქივები დაშიფრული, იზოლირებული და შენარჩუნებულია; მათზე უნებართვო წვდომის ნიშანი გამოქვეყნებულ ცნობებში მითითებული არ არის. არქივის მდგომარეობა და ცოცხალ Microsoft 365 გარემოში შესაძლო მოქმედებები სხვადასხვა საკითხია. ადმინისტრატორს ბოლო წარმატებული სარეზერვო ასლის დრო შეუძლია დააფიქსიროს, რათა იცოდეს, რომელი პერიოდიდან აღარ ემატება დაცულ მონაცემებს ახალი ასლი.

19 ოქტომბერს დასრულებული ანგარიშებისა და წვდომის მონაცემების განულება მომსახურების დაუყოვნებლივ დაბრუნებას არ ნიშნავს. ჯერ დაზიანებული გარემოს უსაფრთხოება მოწმდება, ხოლო სერვისების ჩართვა ეტაპებად არის დაგეგმილი. თითოეული ეტაპის გავლის შემდეგ კავშირებს დამატებითი შეფასება დასჭირდება, განსაკუთრებით იქ, სადაც მათ ფართო უფლებები აქვთ.

რა კვალი უნდა ნახოს Microsoft 365-ის ადმინისტრატორმა

შემოწმება ეხება MSP-ის საკუთარ tenant-სა და მის მიერ მართულ თითოეულ კლიენტის tenant-ს, მათ შორის გარემოებს, სადაც ძველი SkyKick კავშირი შეიძლება დარჩენილი იყოს. Entra ID-ის Enterprise applications-ში კავშირები Application ID-ით უნდა მოიძებნოს: სახელები ძველ ინსტალაციებში შეიძლება განსხვავდებოდეს. ადგილობრივი სტატუსის დაფიქსირება საჭიროა, რადგან მომწოდებლის მიერ იდენტობის გათიშვა ყველა მომხმარებელ tenant-ში შესაბამისი პარამეტრის შეცვლას არ ადასტურებს.

• აპლიკაციის შესვლები: Service principal sign-ins-ში შეადარეთ აპლიკაციის იდენტიფიკატორები, წარმატებული და წარუმატებელი შესვლები, დრო, წყაროს მისამართები და მოთხოვნილი რესურსები. გამოქვეყნებული საეჭვო მისამართია 144.172.64.128, თუმცა მარტო მისამართის დამთხვევა მონაცემების წაკითხვას არ ამტკიცებს. შეამოწმეთ სხვა უჩვეულო მისამართებიც და ჩანაწერების ხელმისაწვდომი პერიოდი.
• როლები და თანხმობა: Entra ID-ის აუდიტში მოძებნეთ აპლიკაციისთვის დირექტორიის როლის მინიჭება, ახალი მფლობელი, შეცვლილი API უფლებები და ადმინისტრატორის მიერ გაცემული consent. ყურადღება მიაქციეთ შემთხვევებს, როდესაც ConnectWise-ის აპლიკაცია ცვლილების ინიციატორად ჩანს, ხოლო სამიზნე სხვა მართვის ან უსაფრთხოების ინტეგრაციაა.
• ახალი წვდომის მონაცემები: შეამოწმეთ აპლიკაციებსა და service principal-ებზე დამატებული საიდუმლო გასაღებები, სერტიფიკატები და ფედერაციული კავშირები. საწყისი კავშირის გათიშვა სხვა აპლიკაციაზე უკვე დამატებულ გასაღებს არ შლის; ასეთი ცვლილების შეფასებისას შეადარეთ აუდიტის დრო, მფლობელი და ნებადართული სამუშაო.
• ფოსტა და ფაილები: გადაამოწმეთ mailbox forwarding, Inbox-ისა და ტრანსპორტის წესები, დელეგირებული წვდომა და ხელმისაწვდომი SharePoint, OneDrive და Teams აქტივობა. წარმატებული აპლიკაციის შესვლა თავისთავად მონაცემების გადმოტანას არ ნიშნავს. მონაცემებთან მოქმედება ცალკე დასკვნაა და შესაბამის ჩანაწერებს მოითხოვს.

გამოსაკვლევი პერიოდი 13 ოქტომბრიდან იწყება; უფრო ძველი აქტივობაც შეამოწმეთ, თუ ჩანაწერები ხელმისაწვდომია და მასზე მინიშნება გამოჩნდა. Entra ID-ისა და Microsoft Purview-ის ჟურნალები სხვადასხვა მოვლენას აღრიცხავს, ამიტომ მათი დროის მონაკვეთები და ხარვეზები ცალ-ცალკე უნდა ჩაიწეროს. ზოგიერთი Microsoft Graph-ით წაკითხვა აუდიტში დეტალურად არ ჩანს; ცარიელი ჟურნალი ამ პირობებში მონაცემებზე წვდომის გამორიცხვას ვერ შეძლებს.

როდის დაბრუნდება მომსახურება

აღდგენის დაწყების დადასტურებული დრო ჯერ არ გამოქვეყნებულა. გეგმით, ჯერ ძირითადი ინფრასტრუქტურა უნდა დაბრუნდეს, შემდეგ კი უფრო მგრძნობიარე კავშირებმა დამატებითი უსაფრთხოების შეფასება გაიაროს. აღდგენის დაწყების შემდეგ პროცესი რამდენიმე დღეს შეიძლება გაგრძელდეს; უფრო ზუსტ ვადას კომპანია მუშაობის პირველი სრული დღის შემდეგ ელოდება.

მანამდე დაზიანებული აპლიკაციების კავშირები გამორთული უნდა დარჩეს ხელახალი ჩართვის ოფიციალურ ინსტრუქციამდე. პარტნიორებისთვის შემდეგი გადამწყვეტი ცნობა იქნება, როდის დაიწყება ეტაპობრივი აღდგენა და რომელ სერვისს დაუბრუნდება წვდომა. კონკრეტული კლიენტის გარემოში უნებართვო მოქმედების ფარგლებს კი მისი შესვლის, უფლებების ცვლილებისა და მონაცემთა აქტივობის ჩანაწერები განსაზღვრავს.

ასევე წაიკითხეთ:

• Google თუ Microsoft Authenticator: აღდგენას ეკოსისტემა წყვეტს
• Microsoft-ის passkey ჩართეთ, მაგრამ აღდგენის გზა წინასწარ აირჩიეთ
• Atlassian-ის ხარვეზს უკვე იყენებენ — Cloud ვერსია მოქმედებას არ ითხოვს