Scentralizowane centra danych jako cel: czego polskie firmy mogą nauczyć się z rosyjskich ataków dronów

Rosyjskie firmy technologiczne i państwowe spółki zaczęły publicznie rozważać przenoszenie centrów danych pod ziemię – do wyrobisk po kopalniach odkrywkowych i obiektów podziemnych – po tym, jak ataki dronów uszkodziły infrastrukturę mieszczącą superkomputery i zakłóciły działanie usług chmurowych dla milionów użytkowników. Według Ars Technica, powołującej się na rosyjskie i niezależne media, chodzi m.in. o obiekty należące do Yandexu, Sbierbanku, VKontakte i Ministerstwa Finansów Rosji. Temat dotyczy więc nie tylko rosyjskiego rynku: pokazuje, jak szybko scentralizowana infrastruktura cyfrowa staje się celem i jak kruche okazują się założenia o „chmurze gdzieś tam”, gdy fizyczna lokalizacja serwerowni przestaje być neutralna.

Dla polskich firm IT i administratorów to przede wszystkim studium przypadku o odporności. Nie chodzi o kopiowanie rosyjskich rozwiązań, lecz o pytanie, które każda organizacja powinna sobie zadać: ile krytycznych usług działa w jednym regionie, u jednego dostawcy i na jednym nośniku zależności? W materiale dowodowym mamy zarówno deklaracje rosyjskich mediów i władz, jak i obserwacje niezależnych redakcji. Część informacji pochodzi z doniesień, których nie da się zweryfikować niezależnie, i tak należy je traktować – jako sygnał, nie jako potwierdzony opis architektury.

Co dokładnie wiadomo, a czego nie wiadomo

Najpierw fakty z materiału dowodowego, oddzielone od interpretacji.

• Według Ars Technica rosyjskie firmy technologiczne „gorączkowo” szukają sposobów na wzmocnienie i ukrycie centrów danych pod ziemią po atakach dronów, które uszkodziły obiekty z superkomputerami i zakłóciły usługi chmurowe.
• Według Vedomosti państwowy Rostelecom rozmawiał z Norilskiem o możliwości przeniesienia części centrów danych pod ziemię.
• Data Center Dynamics wskazał propozycję gubernatora jednego z regionów, by budować centra danych w odkrywkowych kopalniach węgla, a nad nimi urządzać parki jako kamuflaż.
• Według Meduzy Putin podpisał 2 listopada dekret nakazujący operatorom centrów danych rezerwację 10 proc. dostępnej przestrzeni i mocy na potrzeby państwa.
• Ten sam dekret ma pozwalać specjalnej komisji rządowej na autoryzację korzystania z zagranicznych centrów danych w konsultacji z FSB.
• Wcześniej Rosja wprowadziła prawo o „suwerennym internecie”, które blokowało firmom korzystanie z infrastruktury chmurowej poza granicami kraju.
• Według Meduzy Yandex musiał przenieść wszystkie trzy główne superkomputery po atakach na centra danych AI.
• Ars Technica podaje, że ataki dronów uszkodziły lub wyłączyły centra danych m.in. Yandexu, Sbierbanku, VKontakte i Ministerstwa Finansów.
• Według Ars Technica Ukraina rozproszyła kluczowe węzły energetyczne i telekomunikacyjne oraz przeniosła część zasobów rządowych do chmur w Europie przy wsparciu Amazona i Microsoftu po lutym 2022 r.
• Ars Technica podaje, że Ukraina używa terminali Starlink jako zapasowego systemu łączności, finansowanych m.in. przez USA, Polskę i Niemcy.

Czego materiał nie potwierdza: nie ma w nim danych o skali zniszczeń, czasie niedostępności usług, liczbie dotkniętych użytkowników ani o tym, czy podziemne lokalizacje zostały faktycznie uruchomione. Propozycje gubernatora i rozmowy Rostelecomu z Norilskiem to na tym etapie plany i doniesienia medialne, a nie działająca infrastruktura. Dekret o rezerwie 10 proc. znamy z relacji Meduzy – nie z treści samego dokumentu. To rozróżnienie jest istotne, bo w dyskusji o odporności łatwo pomylić zapowiedź z wdrożeniem.

Tło techniczne: dlaczego fizyczne centrum danych jest pojedynczym punktem awarii

Chmura w codziennym języku brzmi jak coś bez lokalizacji. Technicznie jest odwrotnie: każda usługa działa na konkretnym serwerze, w konkretnej hali, zasilanym z konkretnej sieci energetycznej i podłączonym do konkretnego węzła sieciowego. Kiedy mówimy o „regionie chmury”, mówimy o fizycznym miejscu, które ma własne ograniczenia: moc przyłączeniową, chłodzenie, łącza i ludzi, którzy mogą wejść na teren obiektu.

Z tego wynikają trzy klasy ryzyka, które warto rozdzielić.

1. Awaria pojedynczego obiektu

Jeśli wszystkie repliki bazy danych działają w jednej hali, to pożar, zalanie, awaria zasilania czy uszkodzenie mechaniczne dotykają wszystkich kopii naraz. Replikacja w obrębie jednego budynku nie chroni przed utratą budynku. To najbardziej podstawowy błąd architektoniczny i najczęstsza przyczyna „niespodziewanych” przestojów.

2. Zależność od jednego dostawcy i jednego regionu

Korzystanie z usług jednego dostawcy w jednym regionie jest wygodne i tanie, ale oznacza, że polityka, awarie i decyzje tego dostawcy stają się twoim ryzykiem. Regiony w chmurze publicznej są projektowane jako niezależne, ale niezależność ma granice: wspólne kanały tranzycji sieciowej, wspólni poddostawcy energii, wspólne systemy zarządzania tożsamością.

3. Ekspozycja fizyczna i geopolityczna

Tradycyjnie centra danych projektowano z myślą o awariach technicznych, nie o celowym ataku na obiekt. Rosyjski przypadek pokazuje, że lokalizacja może stać się elementem ryzyka, jeśli infrastruktura jest postrzegana jako krytyczna dla państwa lub dużej części gospodarki. To ryzyko trudne do wycenienia, ale nie można go ignorować przy planowaniu ciągłości działania.

Wniosek techniczny jest prosty: odporność nie wynika z liczby serwerów, lecz z liczby niezależnych od siebie ścieżek – zasilania, sieci, lokalizacji i dostawców.

Realne konsekwencje dla użytkowników i firm

W rosyjskim przypadku skutki opisane w materiale dotyczyły usług codziennych: płatności, bankowości cyfrowej, e-commerce, streamingu wideo, aplikacji do przewozów i dostaw jedzenia. To pokazuje, że „chmurowa” infrastruktura jest widoczna dla klienta dopiero wtedy, gdy przestaje działać. Dla firmy oznacza to kilka konkretnych konsekwencji.

• Przestój przekłada się na przychód i zaufanie. Nawet krótka niedostępność płatności lub logowania generuje koszty obsługi i utratę konwersji.
• Odtworzenie bywa dłuższe niż awaria. Jeśli kopie zapasowe leżą w tym samym regionie, odtworzenie może być niemożliwe do czasu przywrócenia infrastruktury.
• Zależności ukryte wychodzą na jaw. Wiele firm odkrywa, że ich dostawca SaaS sam korzysta z jednego regionu albo jednego poddostawcy.
• Presja regulacyjna rośnie. Rosyjski dekret o rezerwie mocy to skrajny przykład, ale w UE również pojawia się dyskusja o suwerenności cyfrowej i lokalizacji danych.

Scenariusze ryzyka: co może pójść nie tak

Poniższa tabela porządkuje scenariusze według prawdopodobieństwa i wpływu. Oceny są interpretacją redakcyjną opartą na typowych wzorcach awarii, nie na danych z rosyjskich zdarzeń.

Scenariusz	Prawdopodobieństwo	Wpływ	Główne zabezpieczenie
Awaria zasilania lub chłodzenia w jednej hali	Średnie	Wysoki dla usług w tym regionie	Replikacja między strefami dostępności
Awaria regionu chmury u jednego dostawcy	Niskie–średnie	Bardzo wysoki	Drugi region lub drugi dostawca
Błąd konfiguracji lub wdrożenia	Wysokie	Średni–wysoki	Testy odtwarzania, kontrola zmian
Utrata dostępu do konta lub panelu zarządzania	Niskie	Wysoki	Niezależne konta awaryjne, MFA sprzętowe
Zniszczenie lub zajęcie obiektu	Bardzo niskie w Polsce	Katastrofalny	Kopie poza regionem, plan ciągłości

Ostatni wiersz wymaga komentarza. W polskich warunkach ryzyko fizycznego zniszczenia centrum danych przez działania zbrojne jest niskie, ale nie zerowe – i nie trzeba go traktować jako scenariusza dominującego. Wystarczy, że traktujemy go jako przypomnienie: każda architektura powinna mieć odpowiedź na pytanie „co, jeśli ten obiekt zniknie z mapy na tydzień”.

Jak sprawdzić, czy problem dotyczy twojej firmy

To nie jest lista pytań do dostawcy chmury, lecz do własnego zespołu. Odpowiedzi powinny być udokumentowane, nie deklaratywne.

1. Wypisz krytyczne usługi i dla każdej wskaż region, dostawcę oraz liczbę niezależnych kopii danych.
2. Sprawdź, czy kopie zapasowe leżą w innym regionie niż dane produkcyjne. Jeśli nie – to jest pierwszy problem do rozwiązania.
3. Ustal, czy replikacja obejmuje dane, konfigurację i sekrety, czy tylko bazę danych.
4. Zapytaj dostawcę SaaS, w jakich regionach działa i czy ma plan awaryjny na utratę regionu. Odpowiedź powinna być na piśmie.
5. Sprawdź, czy zespół potrafi odtworzyć usługę bez dostępu do głównego panelu zarządzania.
6. Zweryfikuj, czy dokumentacja zawiera aktualne adresy, kontakty i procedury na wypadek niedostępności regionu.

Plan reakcji krok po kroku

Poniższy plan dotyczy sytuacji, w której region lub dostawca staje się niedostępny. Kolejność jest istotna, bo część kroków trzeba wykonać, zanim pojawi się awaria.

Przed awarią

1. Zdefiniuj poziomy krytyczności usług i dopuszczalny czas niedostępności dla każdego z nich.
2. Ustal architekturę kopii zapasowych: inny region, inny dostawca lub nośnik offline dla danych najważniejszych.
3. Przeprowadź test odtworzenia co najmniej raz na kwartał, z mierzalnym czasem przywrócenia.
4. Zabezpiecz dostępy awaryjne: konta niezależne od głównego dostawcy, klucze sprzętowe, procedura „break glass”.
5. Uzgodnij z dostawcami zapisy o powiadamianiu o incydentach i o lokalizacji danych.

W trakcie awarii

1. Potwierdź zakres: czy problem dotyczy jednej usługi, regionu czy całego dostawcy.
2. Uruchom komunikację do klientów i wewnętrzną – jedna osoba odpowiedzialna za status.
3. Przełącz ruch na środowisko zapasowe, jeśli jest gotowe i przetestowane.
4. Nie podejmuj decyzji o odtworzeniu z kopii, dopóki nie wiesz, czy kopia jest spójna.
5. Zapisuj decyzje i czasy – to materiał do analizy po zdarzeniu.

Po awarii

1. Przeprowadź analizę przyczyn i skutków, oddzielając błąd techniczny od błędu procesu.
2. Zaktualizuj dokumentację i plan ciągłości.
3. Zaplanuj kolejny test odtworzenia z uwzględnieniem wniosków.

Typowe błędy

• „Mamy kopie zapasowe” bez testu odtworzenia. Kopia, której nigdy nie odtworzono, jest hipotezą, nie zabezpieczeniem.
• Replikacja w jednej strefie. Chroni przed awarią serwera, nie przed awarią hali.
• Pomylenie dostępności z odpornością. Wysoki SLA dostawcy nie oznacza, że twoja aplikacja przetrwa utratę regionu.
• Brak dokumentacji poza systemem. Jeśli procedury są tylko w usłudze, która padła, nie masz procedur.
• Optymizm w ocenie zależności. Założenie, że poddostawca dostawcy jest równie niezawodny, bywa kosztowne.

Działania krótkoterminowe

W perspektywie dni i tygodni priorytetem jest zmniejszenie pojedynczych punktów awarii bez przebudowy całej architektury.

• Przenieś kopie zapasowych danych krytycznych do innego regionu lub na nośnik offline.
• Włącz wersjonowanie i niezmienność kopii, aby chronić je przed przypadkowym usunięciem.
• Ustal i przetestuj procedurę dostępu awaryjnego do kont i paneli.
• Zbierz od dostawców pisemne potwierdzenie lokalizacji danych i planu ciągłości.
• Przeprowadź próbne odtworzenie jednej, najlepiej najmniej krytycznej usługi.

Działania długoterminowe

W perspektywie kwartałów i lat chodzi o zmianę architektury i sposobu myślenia o lokalizacji.

• Zaprojektuj usługi tak, aby działały w co najmniej dwóch niezależnych regionach, z jasno określonym trybem degradacji.
• Rozważ architekturę multi-cloud lub hybrid tam, gdzie ryzyko uzasadnia koszt – nie wszędzie.
• Wpisz lokalizację i odporność do kryteriów wyboru dostawców obok ceny i funkcji.
• Utrzymuj plan ciągłości jako żywy dokument z właścicielem i harmonogramem testów.
• Śledź regulacje dotyczące lokalizacji danych w UE, bo mogą zmienić dostępne opcje.

Checklista praktyczna

• Czy wiem, w jakich regionach działają moje krytyczne usługi?
• Czy kopie zapasowe są w innym regionie niż dane produkcyjne?
• Czy test odtworzenia odbył się w ciągu ostatnich 90 dni?
• Czy mam dostęp awaryjny niezależny od głównego dostawcy?
• Czy dostawca potwierdził na piśmie plan na wypadek utraty regionu?
• Czy zespół zna procedurę na wypadek niedostępności panelu zarządzania?
• Czy wiem, które usługi mogą działać w trybie ograniczonym, a które muszą być dostępne zawsze?

Co powinien zrobić właściciel firmy / administrator

Właściciel firmy odpowiada za decyzję o poziomie ryzyka, administrator za jej wykonanie. Podział obowiązków warto zapisać.

Właściciel firmy

• Ustal, które usługi są krytyczne dla przychodu i reputacji, i zaakceptuj koszt ich odporności.
• Zadbaj, aby plan ciągłości miał właściciela i budżet, nie tylko dokument.
• Podejmuj decyzje o lokalizacji danych świadomie, z uwzględnieniem regulacji i ryzyka.

Administrator

• Utrzymuj aktualną mapę zależności: regiony, dostawcy, poddostawcy.
• Testuj odtwarzanie i raportuj wyniki wraz z czasem przywrócenia.
• Zabezpiecz dostępy awaryjne i dokumentację poza systemami, które mogą paść.
• Weryfikuj deklaracje dostawców i zgłaszaj rozbieżności.

Rosyjski przypadek jako lekcja, nie wzór

Rosyjskie plany przenoszenia centrów danych pod ziemię i rezerwa 10 proc. mocy na potrzeby państwa to odpowiedź na konkretną sytuację wojenną i specyficzny model zarządzania. Nie należy ich traktować jako rekomendacji dla polskich firm. Warto natomiast zauważyć dwie rzeczy.

Po pierwsze, scentralizowany system pod presją szybko ujawnia słabości – w materiale widać, że usługi codzienne, płatności i bankowość cyfrowa odczuły skutki ataków na obiekty kilku dużych operatorów. Po drugie, ukraińskie podejście – rozproszenie węzłów, przeniesienie części zasobów do chmur w Europie i zapasowa łączność satelitarna – pokazuje, że odporność buduje się przez redundancję i planowanie, a nie przez ukrywanie pojedynczego obiektu.

Dla polskich firm najważniejszy wniosek jest praktyczny: warto regularnie zadawać pytanie, co się stanie, jeśli jeden region, jeden dostawca lub jeden obiekt przestanie działać. Odpowiedź powinna być przetestowana, nie tylko zapisana.

Praktyczna weryfikacja deklaracji dostawców

Deklaracje dostawców chmury i SaaS warto traktować jako punkt wyjścia do weryfikacji, nie jako fakt. Materiał źródłowy pokazuje, że rosyjskie firmy technologiczne musiały w trybie pilnym przenosić superkomputery i szukać nowych lokalizacji po atakach na obiekty, w których wcześniej działały. Wniosek dla polskich organizacji jest prosty: to, co dostawca zapisze w umowie lub dokumentacji, trzeba sprawdzić własnymi działaniami, zanim pojawi się realny incydent.

Weryfikacja lokalizacji i regionów

• Poproś dostawcę o wskazanie regionów, w których faktycznie przechowywane są dane produkcyjne i kopie zapasowe – nie tylko regionów „dostępnych w ofercie”.
• Sprawdź, czy region zapasowy jest niezależny infrastrukturalnie, czy tylko administracyjnie wydzielony. Dwa regiony w tej samej hali nie dają odporności na utratę obiektu.
• Zweryfikuj, czy replikacja obejmuje dane, konfigurację, sekrety i polityki dostępu – sama replikacja bazy danych nie wystarczy do odtworzenia usługi.
• Uzyskaj na piśmie informację o poddostawcach, którzy uczestniczą w świadczeniu usługi, i o ich lokalizacji.

Weryfikacja planu ciągłości dostawcy

• Zapytaj, czy dostawca ma udokumentowany plan na wypadek utraty regionu i czy został on kiedykolwiek przetestowany.
• Poproś o opis procedury powiadamiania o incydentach: kto informuje, w jakim czasie, jakim kanałem.
• Sprawdź, czy plan ciągłości dostawcy zakłada scenariusz dłuższej niedostępności, czy tylko krótkotrwałej awarii.
• Porównaj deklarowany SLA z realnym czasem przywrócenia usługi po awarii – historia incydentów bywa bardziej miarodajna niż zapisy umowy.

Weryfikacja własnej zdolności do odtworzenia

• Przeprowadź odtworzenie usługi w środowisku izolowanym, bez dostępu do głównego panelu zarządzania.
• Sprawdź, czy dokumentacja procedur jest dostępna poza systemami, które mogą paść – jeśli leży tylko w usłudze, która jest niedostępna, nie masz procedur.
• Zmierz czas przywrócenia i porównaj go z założonym dopuszczalnym czasem niedostępności dla danej usługi.
• Zapisz wynik testu wraz z datą, zakresem i napotkanymi problemami – to materiał do kolejnych iteracji.

Monitoring po wdrożeniu

Wdrożenie architektury odpornej na utratę regionu nie kończy pracy – rozpoczyna ją. Materiał źródłowy pokazuje, że scentralizowany system pod presją szybko ujawnia słabości, a skutki ataków na kluczowe obiekty odczuły usługi codzienne, płatności i bankowość cyfrowa. Monitoring powinien więc obejmować nie tylko dostępność usług, ale też stan zabezpieczeń i gotowość do reakcji.

Co monitorować na bieżąco

• Dostępność usług krytycznych z perspektywy zewnętrznej, niezależnej od monitoringu dostawcy.
• Stan replikacji i opóźnienie między danymi produkcyjnymi a kopiami zapasowymi.
• Ważność certyfikatów, kluczy i poświadczeń awaryjnych – wygasły klucz w momencie awarii jest równie problematyczny jak jego brak.
• Zmiany w konfiguracji regionów i polityk dostępu – niekontrolowana zmiana może znieść wcześniej wypracowaną odporność.
• Komunikaty dostawców o planowanych pracach i incydentach, z przypisaniem osoby odpowiedzialnej za ich odbiór.

Rytm przeglądów

1. Przegląd tygodniowy: status replikacji, alerty dostępności, otwarte incydenty u dostawców.
2. Przegląd miesięczny: aktualność mapy zależności, zmiany w regionach i poddostawcach.
3. Przegląd kwartalny: test odtworzenia z mierzalnym czasem przywrócenia i aktualizacja planu ciągłości.
4. Przegląd roczny: ponowna ocena ryzyka, weryfikacja deklaracji dostawców i przegląd regulacji dotyczących lokalizacji danych w UE.

Wskaźniki, które warto śledzić

• Czas od wykrycia incydentu do potwierdzenia jego zakresu.
• Czas przywrócenia usługi w ostatnim teście odtworzenia w porównaniu z poprzednim.
• Liczba usług krytycznych, dla których kopie zapasowe leżą w innym regionie niż dane produkcyjne.
• Liczba dni od ostatniego testu dostępu awaryjnego.
• Liczba rozbieżności między deklaracjami dostawców a stanem faktycznym, wykrytych w danym okresie.

Checklista wdrożeniowa przed uruchomieniem

Poniższa lista porządkuje czynności, które należy wykonać, zanim uznamy nową usługę lub nową architekturę za gotową do pracy. Kolejność ma znaczenie, bo część punktów trzeba domknąć przed przekazaniem usługi do eksploatacji.

1. Usługa ma zdefiniowany poziom krytyczności i dopuszczalny czas niedostępności.
2. Wskazano region produkcyjny i region zapasowy, a ich niezależność została potwierdzona.
3. Kopie zapasowe danych, konfiguracji i sekretów leżą poza regionem produkcyjnym.
4. Włączono wersjonowanie i niezmienność kopii, aby chronić je przed przypadkowym usunięciem.
5. Istnieją konta awaryjne niezależne od głównego dostawcy, z uwierzytelnianiem sprzętowym.
6. Procedura „break glass” jest opisana i znana zespołowi.
7. Dokumentacja procedur jest dostępna poza systemami, które mogą paść.
8. Dostawca potwierdził na piśmie lokalizację danych i plan na wypadek utraty regionu.
9. Uzgodniono zapisy o powiadamianiu o incydentach.
10. Zaplanowano pierwszy test odtworzenia z datą i osobą odpowiedzialną.

Checklista po każdym incydencie i teście

Każde zdarzenie – zarówno realna awaria, jak i test – powinno kończyć się uporządkowanym domknięciem. Materiał źródłowy pokazuje, że reakcja pod presją bywa chaotyczna, dlatego warto mieć gotową listę czynności, które wykonuje się po uspokojeniu sytuacji.

• Czy zapisano decyzje i czasy podejmowanych działań?
• Czy oddzielono błąd techniczny od błędu procesu?
• Czy zaktualizowano dokumentację i plan ciągłości na podstawie wniosków?
• Czy sprawdzono, czy deklaracje dostawcy pokrywają się z przebiegiem zdarzenia?
• Czy zaplanowano kolejny test odtworzenia z uwzględnieniem wniosków?
• Czy poinformowano właściciela firmy o wyniku i rekomendacjach?
• Czy zweryfikowano, czy dostępy awaryjne zadziałały zgodnie z procedurą?

Podział odpowiedzialności w monitoringu

Monitoring bez przypisanych osób staje się zbiorem alertów, które nikt nie analizuje. Warto rozdzielić role tak, aby każdy element miał właściciela.

• Administrator: utrzymuje mapę zależności, konfiguruje monitoring, raportuje wyniki testów i zgłasza rozbieżności w deklaracjach dostawców.
• Właściciel firmy: akceptuje poziom ryzyka, zatwierdza budżet na odporność i podejmuje decyzje o lokalizacji danych z uwzględnieniem regulacji.
• Osoba odpowiedzialna za komunikację: prowadzi komunikację do klientów i wewnętrzną podczas incydentu, jedna na zdarzenie.
• Właściciel planu ciągłości: dba o aktualność dokumentu i harmonogram testów.

Jak wykorzystać przypadek rosyjski w praktyce

Rosyjskie plany przenoszenia centrów danych pod ziemię i rezerwa 10 proc. mocy na potrzeby państwa to odpowiedź na konkretną sytuację wojenną i specyficzny model zarządzania – nie rekomendacja dla polskich firm. Praktyczny wniosek z materiału jest inny: scentralizowany system pod presją szybko ujawnia słabości, a rozproszenie węzłów, przeniesienie części zasobów do chmur w Europie i zapasowa łączność satelitarna pokazują, że odporność buduje się przez redundancję i planowanie.

Dla zespołu oznacza to konkretne zadania w monitoringu: regularne sprawdzanie, czy żadna krytyczna usługa nie opiera się na pojedynczym regionie, pojedynczym dostawcy lub pojedynczym obiekcie, oraz testowanie odpowiedzi na pytanie „co się stanie, jeśli ten element przestanie działać”. Odpowiedź powinna być przetestowana, nie tylko zapisana.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

1. Ukraine’s drone strikes spur hasty Russian plans for underground data centers (arstechnica.com)

Zdjęcie wyróżniające: panumas nikhomkhai / Pexels.