Yandex po atakach dronów. Trzy centra danych w cztery dni

blackweb.pl Stan na dzień 4 min
yandex chmura infrastruktura backup

Między 8 a 11 października drony zaatakowały trzy centra danych Yandexu: w Sasowie, Kałudze i Włodzimierzu. Operator potwierdził uszkodzenia. 12 października nadal informował o ograniczonym działaniu chmury i zalecał klientom korzystanie z innych platform do uruchamiania usług oraz przechowywania kopii.

Wśród relacji o pożarach jest szczegół, który dobrze pokazuje problem klienta takiej chmury: aplikacja przestała działać, kopia bazy istniała, ale próba przywrócenia kończyła się błędem. Na tym etapie nie trzeba nawet utracić danych, żeby stracić możliwość prowadzenia usługi.

Biuro Yandexu w Moskwie, 2019. Fot. WikiFido / Wikimedia Commons, CC BY-SA 4.0. Wersja pomniejszona; kadr na stronie dopasowany do ramki. Zdjęcie nie przedstawia zaatakowanych centrów danych.

Co potwierdził operator

W komunikacie z 9 października Yandex opisał dwa zdarzenia. Nocą z 7 na 8 października poważnie uszkodzone zostało centrum w Sasowie, którego pracę całkowicie wstrzymano. Rankiem 9 października zaatakowano obiekt w Kałudze. Tam firma mówiła o wyłączeniu części infrastruktury, nie całej serwerowni. Według operatora pracownicy obu obiektów nie ucierpieli. Nie podano terminu przywrócenia działania.

11 października do tej listy doszedł Włodzimierz. Yandex Cloud Alerts potwierdził uszkodzenia po ataku dronów i całkowite zatrzymanie obiektu. Również w tym komunikacie firma informowała o braku poszkodowanych. To informacje operatora o jego obiektach i personelu, nie bilans wszystkich ataków w tych regionach.

Reuters opisał, że 9 października Wołodymyr Zełenski potwierdził ukraińskie uderzenie na centrum w Kałudze. Przedstawił je jako odpowiedź na rosyjskie ataki na ukraińską infrastrukturę telekomunikacyjną i centra danych. To deklaracja strony konfliktu dotycząca motywacji. Nie zastępuje ustaleń o przeznaczeniu konkretnych serwerów.

Kopia była, odtworzenie zwracało błąd

Reuters rozmawiał z Alexandrem Savitskym, prowadzącym aplikację randkową Pulse. Według jego relacji około 8 tysięcy użytkowników nie mogło korzystać z aplikacji od czwartku 8 października. Nie miał też dostępu do kopii bazy w Yandex Cloud, a próba odtworzenia jej w innym miejscu kończyła się błędem wewnętrznym.

Ta relacja pochodzi z 9 października. Nie potwierdza trwałej utraty bazy ani tego, że aplikacja pozostaje niedostępna w chwili publikacji tego tekstu.

Pokazuje za to różnicę między posiadaniem kopii a możliwością skorzystania z niej podczas awarii dostawcy. Jeśli odtworzenie wymaga działającego panelu tej samej chmury, jej API lub dostępnego miejsca na nowe maszyny, sam zapis „backup wykonany” niewiele mówi o czasie powrotu usługi. W planie awaryjnym trzeba sprawdzić także te zależności.

Gdzie przenieść usługę, kiedy brakuje zasobów

10 października operator informował o ręcznym zarządzaniu limitami zasobów, ograniczonej dodatkowej pojemności i priorytecie dla usług krytycznych. Po ataku we Włodzimierzu określił pozostałą konfigurację infrastruktury jako niestabilną i zalecił uruchomienie alternatywnych planów odtwarzania.

W aktualizacji z 12 października platforma nadal pracowała w ograniczonym trybie. Trwało przywracanie usług, wsparcie miało opóźnienia, a operator ponownie wskazywał inne platformy jako miejsce dla obciążeń i kopii. Nie oznacza to, że każda usługa Yandexu była wyłączona. Nie oznacza też powrotu całej chmury do normalnej pracy.

Dokumentacja Yandex Cloud opisuje strefę dostępności jako infrastrukturę umieszczoną w centrum danych. Rozdzielenie zasobów między strefy ma ograniczać skutki awarii sprzętu lub oprogramowania w jednej z nich. Kolejne fizyczne uderzenia w różne obiekty stawiają przed takim układem inne wymagania niż pojedyncza awaria.

Bez technicznego raportu z incydentu nie ocenię, które zabezpieczenia zadziałały, a które zawiodły. Sama liczba stref nie odpowiada jednak na pytanie klienta: czy po utracie części infrastruktury pozostała pojemność wystarczy również dla mojej aplikacji?

Czy zniknęły rosyjskie boty propagandowe?

Wokół ataków pojawiły się również doniesienia łączące spadek ruchu botów z ograniczeniem propagandy. Tak dalekiego wniosku nie da się wyprowadzić z samego wykresu ruchu sieciowego Yandexu.

Cloudflare klasyfikuje automatyczny ruch, ale taka klasyfikacja nie ustala politycznego celu żądania. Yandex prowadzi wyszukiwarkę, a jej roboty pobierają strony do indeksowania. One również są botami.

Żeby przypisać spadek aktywności kontom propagandowym, potrzebne byłyby dane o tych kontach oraz podstawa do powiązania ich infrastruktury z zaatakowanymi obiektami. Nie traktuję wykresu automatycznych żądań jako takiego dowodu. To ten sam podział na ustalenie i interpretację, który opisuję w zasadach pracy ze źródłami.

Z perspektywy osoby utrzymującej usługę bardziej użyteczne pytanie dotyczy własnej kopii: czy można ją pobrać i odtworzyć bez działającego konta u podstawowego dostawcy? Druga chmura wpisana w dokumentację nie rozwiązuje tego sama. Potrzebne są dostępne dane, uprawnienia i środowisko, w którym rzeczywiście przeprowadzono próbę odtworzenia. W relacji klienta Pulse zabrakło już dostępu do kopii.

Źródła

Jak pracuję ze źródłami i poprawiam błędy. Znalazłeś błąd? Podaj fragment i źródło.

Powiązane

← Archiwum