Klikając „Akceptuj wszystkie pliki cookie”, zgadzasz się na przechowywanie plików cookie na swoim urządzeniu w celu ułatwienia nawigacji po stronie, analizy korzystania ze strony oraz wspierania naszych działań marketingowych. Zobacz naszą Politykę prywatności, aby uzyskać więcej informacji.
Artykuł

Rosja wykorzystuje zachodnie chmury obliczeniowe do napędzania swojej machiny wojennej

Renata Davidson

Ekspertka zarządzania ryzykiem i ciągłością działania

Najnowsze badania ujawniają, jak aplikacje wojskowe Kremla korzystają z infrastruktury Amazon, Google i innych gigantów technologicznych do prowadzenia działań w Ukrainie.

Zachodnie rządy dwoją się i troją w nakładaniu kolejnych sankcji na Rosję, próbując ograniczyć jej zdolności wojskowe, tymczasem nowe badania ujawniają niepokojącą prawdę: rosyjskie aplikacje wojskowe wykorzystują amerykańską i europejską infrastrukturę chmury obliczeniowej do kierowania artylerią i dronami na ukraińskim polu bitwy.

Analiza (w całości dostępna w materiałach 17. Międzynarodowej Konferencji na temat Konfliktów Cybernetycznych: Następny Krok) przeprowadzona przez Volodymra Styrana, eksperta ds. cyberbezpieczeństwa z ukraińskiego Państwowego Centrum Ochrony Cybernetycznej, dla prestiżowego Królewskiego Instytutu Służb Zbrojnych (RUSI) w Londynie pokazuje, jak 62 rosyjskie aplikacje wojskowe polegają na serwisach Amazon Web Services, Google Cloud i Cloudflare – firmach z krajów, które oficjalnie sankcjonują Rosję za jej agresję na Ukrainę.

Ukryty paradoks wojny technologicznej

Odkrycie to ujawnia paradoks obecnego konfliktu. Te same zachodnie firmy technologiczne, które są chwalone za zapewnienie kluczowego wsparcia dla cyfrowej odporności Ukrainy, nieświadomie wspierają także infrastrukturę używaną przez rosyjskie aplikacje kierujące artylerią i dronami.

Analiza przeprowadzona przez Volodymra Styrana objęła aplikacje mobilne na system Android używane przez rosyjskie siły zbrojne i ich sojuszników. Wszystkie były rozprowadzane poza oficjalnymi sklepami z aplikacjami – zazwyczaj przez kanały Telegram związane z wojną – wykorzystując model "sideloadingu" Androida, który umożliwia zdecentralizowaną i w dużej mierze niewidoczną sieć dystrybucji aplikacji, która omija nadzór Google'a lub innych regulatorów.

Amerykańskie serwery dla rosyjskich rakiet

Skala zależności od zachodniej infrastruktury jest oszałamiająca. Volodymyr Styran zidentyfikował 323 nazwy domen i 387 adresów IP wbudowanych w te aplikacje, z których ponad 70% było hostowanych w Stanach Zjednoczonych. Rosyjskie aplikacje wojskowe używają tych serwisów do przechowywania danych, renderowania map, telemetrii i komunikacji.

Szczególnie krytyczne są dane meteorologiczne i mapowe, których Rosja nie jest w stanie samodzielnie wyprodukować. Wiele analizowanych aplikacji korzysta z otwartych źródeł danych mapowych, takich jak OpenStreetMap, Mapbox czy OpenTopoMap – platform projektowanych dla użytku publicznego, ale przekształconych na potrzeby wojenne.

Konkretne przykłady wykorzystania open source

Volodymyr Styran przeanalizował 62 aplikacje wojskowe, ujawniając szokujące przykłady wykorzystania zachodnich rozwiązań open source:

  • ZeVs—METEO ALPHA - aplikacja meteorologiczna dla artylerii wykorzystuje OpenStreetMap (110 wystąpień w kodzie), Google Maps oraz CloudMade do dostarczania danych o pogodzie kluczowych dla precyzji ostrzału artyleryjskiego.
  • Karlson3 - aplikacja do zarządzania dronami wykorzystuje platformy Mapbox (103 wystąpienia), Amazon Web Services oraz GitHub do obsługi dronów DJI w misjach rozpoznawczych i korekty ognia artyleryjskiego.
  • Veterok - część kompleksu taktycznego dla jednostek rozpoznawczych i artyleryjskich wykorzystuje OpenStreetMap, ArcGIS Online oraz platformę HERE API do automatyzacji kompleksu rozpoznawczo-uderzeniowego.

Aplikacje te wykorzystują także Github dla hostowania kodu, Firebase Google'a do baz danych w czasie rzeczywistym oraz Telegram jako platformę komunikacyjną - wszystkie są dostępne za darmo lub w ramach darmowych pakietów startowych

Symbolika nazw i propaganda

Nazwy aplikacji noszą wyraźne znamiona rosyjskiej propagandy wojennej. Prefiks "ZeVs" w aplikacjach meteorologicznych nawiązuje do liter Z i V - symboli malowanych na rosyjskim sprzęcie wojskowym, które stały się symbolami poparcia dla inwazji na Ukrainę. "Z" prawdopodobnie oznacza "Zapad" (Zachód) lub "Za pobedu" (Za zwycięstwo), podczas gdy "V" może oznaczać "Vostok" (Wschód) lub "Victory" (Zwycięstwo).

Nazwa "Karlson3" to z kolei nawiązanie do postaci "Karlssona z dachu" ze szwedzkiej książki dla dzieci - mężczyzny ze śmigłem na plecach, co symbolicznie odnosi się do funkcji aplikacji związanej z operacjami dronów. Czy dostawcy usług chmurowych powinni być uważani podczas wojny za neutralnych dostawców infrastruktury? Czy firma może jednocześnie wspierać zaatakowany kraj, jednocześnie pomagając agresorowi w rozwoju technologii bojowych?

Koszty ignorowania tej cyfrowej luki są wysokie. Po pierwsze, podkopuje to wiarygodność i możliwość egzekwowania sankcji – szczególnie tych skierowanych do sektora technologicznego. Po drugie, pozwala Rosji ukrywać infrastrukturę wojskową na zachodnich platformach, utrudniając jej wykrycie i neutralizowanie.

Dalsze kroki

Eksperci RUSI proponują konkretne działania, które należy podjąć:

  • Monitorowanie wzorców użytkowania na platformach chmurowych, w celu wykrycia aktywności wojskowej przez podmioty prowadzące nielegalne wojny.
  • Wprowadzenie geofencingu i ograniczeń na poziomie API, w celu zablokowania rosyjskim programistom (wojskowym i powiązanym z armią) wykorzystywania zachodniej infrastruktury chmurowej.
  • Zwiększenie kontroli ekosystemu aplikacji, poprzez wezwanie sklepów z aplikacjami i analityków malware do identyfikacji i oznaczania narzędzi wojskowych instalowanych "z boku" (sideloading).
  • Przewartościowanie polityk neutralności technologicznej dla platform chmurowych i open-source podczas wojny.

Wnioski z raportu

Machina wojenna Rosji to nie tylko elementy fizyczne. Machina ta jest cyfrowa, rozproszona i – jak na ironię – demokratyczna w swoim wykorzystaniu otwartych technologii. Te same platformy, które służą wolności wypowiedzi i innowacjom obywatelskim na Zachodzie, są wykorzystywane przez Rosję jako broń do kierowania artylerią i koordynowania ataków dronów.

Jak konkluduje Volodymyr Styran w swoim raporcie:

"Otwartość bez odpowiedzialności zaprasza do nadużyć. Dopóki nie zostaną podjęte konkretne kroki, zachodnia infrastruktura pozostanie niewidzialnym pomocnikiem wojny. A my musimy przestać podtrzymywać wojnę, którą chcemy zakończyć".

Odkrycie autora podkreśla, jak bardzo współczesne konflikty wykraczają poza tradycyjne pola bitew, wkraczając w sferę cyfrową, gdzie linie między sojusznikami a przeciwnikami stają się nieoczekiwanie rozmyte.

Skutki prawne dla przedsiębiorców - gdy open source staje się bronią

Nowa rzeczywistość regulacyjna

Analiza V. Styrana ujawnia niepokojące implikacje prawne dla dostawców usług chmurowych i twórców oprogramowania open source. Firmy technologiczne, które nieświadomie wspierają rosyjską machinę wojenną, mogą narazić się na zarzuty łamania międzynarodowych sankcji.

Od września 2024 roku przepisy amerykańskiego Biura ds. Kontroli Aktywów Zagranicznych (OFAC) zakazują świadczenia usług IT i wsparcia dla oprogramowania przedsiębiorstw oraz projektowania i produkcji software'u dla rosyjskich podmiotów. Unia Europejska nałożyła podobne ograniczenia w swoim 12. pakiecie sankcji z grudnia 2023 roku.

Odpowiedzialność prawna przedsiębiorców

Dla firm oferujących rozwiązania open source, sytuacja ta oznacza nową kategorię ryzyka prawnego. Licencje open source to prawnie wiążące umowy, a ich naruszenie może (i prowadzi) do konsekwencji prawnych i konieczności wypłaty odszkodowań.

Przedsiębiorcy muszą teraz uwzględnić w swoich analizach prawnych:

  • Ryzyko sankcji wtórnych - OFAC ostrzega zagraniczne instytucje finansowe, że ryzykują sankcjami za prowadzenie znaczących transakcji z podmiotami objętymi sankcjami na podstawie rozporządzenia wykonawczego 14024.
  • Problemy z geoblokowaniem - Choć standardowe licencje open source nie pozwalają na ograniczenia geograficzne, eksperci prawni wskazują, że nic nie zmusza dostawców oprogramowania lub usług zbudowanych wokół niego do obsługi klientów z danego regionu świata. Innymi słowy, licencja open source mówi, że możesz używać oprogramowania gdziekolwiek jesteś, ale nie zmusza nikogo, żeby Ci to oprogramowanie specjalnie "dostarczył" w formie płatnej usługi, jeśli nie chce (lub nie może - np. z powodu sankcji) tego robić w Twoim regionie.
  • Koszty nieprzestrzegania - kary z tytułu nieprzestrzegania sankcji, szczególnie w przypadku dużych korporacji, często sięgają miliardów dolarów.

Wyzwania dla dostawców open source

Sytuacja ta stawia pytania o przyszłość modelu open source. Sankcje są uznawane za legalne przez państwo, które je nałożyło, ale są zazwyczaj uważane za nielegalne przez państwa, które są im przeciwne. To oznacza, że twórcy oprogramowania open source znaleźli się w centrum konfliktu geopolitycznego.

Rekomendacje dla firm technologicznych

Eksperci prawni zalecają firmom technologicznym:

  • Wdrożenie systemów monitorowania użycia ich platform w celu wykrycia aktywności wojskowej
  • Przegląd umów licencyjnych pod kątem możliwości wprowadzenia ograniczeń geograficznych
  • Konsultacje prawne dotyczące interpretacji najnowszych sankcji
  • Audyt łańcucha dostaw w celu identyfikacji potencjalnych naruszeń

Aby złagodzić te obawy dotyczące odpowiedzialności, organizacje powinny przyjąć strategie zarządzania ryzykiem licencji open source, takie jak zapewnienie zgodności, edukacja zespołów programistycznych i wykorzystanie narzędzi do śledzenia licencji.

Precedens dla przyszłości

Przypadek rosyjskich aplikacji wojskowych może stać się precedensem dla przyszłych konfliktów. Eksperci ostrzegają, że inne autorytarne państwa mogą próbować wykorzystać otwartość demokratycznych platform technologicznych przeciwko nim samym, co wymaga przemyślenia zasad neutralności technologicznej w czasach wojny.

Artykuł został napisany w oparciu o rzetelne źródła akademickie, prawne i branżowe, z głównym naciskiem na badania RUSI - jednej z najbardziej renomowanych instytucji badawczych w dziedzinie bezpieczeństwa międzynarodowego.

Zapisz się już teraz! 

Subskrybując newsletter Davidson Consulting, otrzymujesz merytoryczne analizy z zakresu zarządzania ryzykiem, ciągłości działania, cyberbezpieczeństwa i compliance (m.in. DORA, NIS2), a także informacje o naszych usługach i produktach, które pomogą Ci skutecznie wdrożyć prezentowane strategie.  

Pamiętaj, Twoja subskrypcja jest w pełni dobrowolna i możesz ją anulować w każdej chwili jednym kliknięciem.
* - Pole obowiązkowe
Dziękujemy za zapisanie się do Forum Ekspertów Odporności Operacyjnej.
Ups! Coś poszło nie tak podczas uzupełnienia formy. Spróbuj ponownie lub skontaktuj się bezpośrednio.

Najnowsze artykuły

ENISA 2025: wyzwania i zalecenia dla UE

Europejska Agencja ds. Cyberbezpieczeństwa (ENISA) opublikowała raport Threat Landscape 2025, przedstawiający przegląd ekosystemu cyberzagrożeń w Europie wokresie od lipca 2024 do czerwca 2025 roku.
Czytaj dalej
Raport

ENISA 2025: wyzwania i zalecenia dla UE

Cyberbezpieczeństwo
Geopolityka a biznes
Bezpieczeństwo łańcucha dostaw
ENISA, raport, cyberbezpieczeństwo, threats
Administracja publiczna
IT i technologia

Globalna awaria Azure Front Door

Analiza incydentu i wnioski dla sektora finansowego (i nie tylko)
Czytaj dalej
Case Study

Globalna awaria Azure Front Door

Cyberbezpieczeństwo
Zarządzanie kryzysowe
Bezpieczeństwo łańcucha dostaw
Incydenty
awaria Microsoft Azure, awaria Azure Front Door, globalna awaria Microsoft, Azure Front Door outage, Microsoft Azure outage, awaria usług Microsoft, niedostępność usług Microsoft, Azure AD, Entra ID, App Service, Azure SQL Database, Azure Portal, Xbox, Minecraft, chmura Microsoft, awaria chmury, błąd konfiguracji Azure, konfiguracja tenant, software defect, wada oprogramowania, błąd ludzki Microsoft, human error Azure, efekt kaskadowy, przeciążenie węzłów Azure, awaria DNS, Azure DNS outage, rollback Azure, last known good configuration, LKGC, Site Reliability Engineering, SRE, defense in depth, automatyzacja wdrożeń, błąd walidacji konfiguracji, błędna konfiguracja, kontrola konfiguracji Azure, edge case Azure, control plane, data plane, failure in validation, awaria globalna, Microsoft incident report, Post Incident Report, PIR Microsoft, YKYN-BWZ, resilience Azure, cloud resilience, odporność operacyjna, operational resilience, DORA, Digital Operational Resilience Act, regulacje DORA, zgodność z DORA, compliance DORA, KNF, Komisja Nadzoru Finansowego, nadzór finansowy, ryzyko koncentracji, third party risk, ryzyko dostawcy chmury, cloud risk management, vendor lock-in, multicloud, multi-cloud, multi-region, geodywersyfikacja, architektura odporna, cloud architecture, disaster recovery, DRP, business continuity, BCP, cloud outage analysis, audyt chmurowy, cloud audit, SOC 2, cloud governance, SLA, RTO, RPO, czas odtworzenia Azure, Microsoft downtime, outage recovery, chaos engineering, testy negatywne, automatyczny rollback, Canary Deployment, phased deployment, failover Azure, critical third party provider, CCP, ESAs, EBA, EIOPA, ESMA, nadzór nad dostawcami chmury, resilience banking, odporność banków, ryzyko chmurowe w sektorze finansowym, ryzyko technologiczne, ciągłość działania, cloud compliance, architektura wielochmurowa, cloud diversification, multivendor strategy, strategia multicloud, optymalizacja kosztów chmury, cloud cost optimization, cloud latency, Azure performance, globalna infrastruktura Microsoft, awarie AWS, porównanie Azure AWS, cloud dependency, single point of failure, SPOF, cloud reliability, cloud security, błędy operacyjne Microsoft, analiza incydentu Azure, raport Microsoft Azure, zarządzanie ryzykiem ICT, cloud risk, infrastruktura krytyczna, cloud incident response, audyt poawaryjny, analiza PIR, Microsoft transparency report, cloud service disruption, krytyczne usługi ICT, chmura publiczna, odporność regulacyjna, zgodność z regulacjami UE, dyrektywa DORA, bezpieczeństwo chmury, cloud compliance EU, KNF DORA wytyczne, architektura bankowa, infrastruktura finansowa, cloud resilience strategy, zarządzanie ciągłością działania, ryzyko operacyjne, ryzyko ICT, cyberbezpieczeństwo sektora finansowego.
IT i technologia
Bankowość i rynki finansowe
Firmy w Polsce

Ataki na bankomaty Santander w Poznaniu

Analiza odpowiedzialności, zwrotu środków i wyzwań bezpieczeństwa.
Czytaj dalej
Case Study

Ataki na bankomaty Santander w Poznaniu

Incydenty
Zgodność
atak Santander, Santander bankomaty, zwrot środków po nieautoryzowanej transakcji, odpowiedzialność banku za straty klientów, skimming bankomatowy, zabezpieczenia bankomatów Santander, skradzione pieniądze Santander bank, umowy między bankiem a operatorem bankomatów, dyrektywa PSD2 w ochronie konsumentów, silne uwierzytelnianie klienta (SCA), monitoring bankomatów i wykrywanie oszustw, postępowanie prokuratorskie w sprawie skimmingu, odzyskiwanie pieniędzy przez bank, procedury bezpieczeństwa banku Santander, edukacja klientów w zakresie cyberbezpieczeństwa, System Bezpieczeństwa Danych Przemysłu Kart Płatniczych (PCI DSS), skimmery i kamery na bankomatach, operatorzy bankomatów Euronet i ITCARD, ryzyko prawne banku przy atakach na bankomaty, audyty i testy penetracyjne w sektorze bankowym, współpraca banku z organami ścigania w sprawach cyberprzestępczości.
Bankowość i rynki finansowe

Jak przygotowywać testy planów lub procedur awaryjnych

Incydent w Erding wyraźnie nas uczy: nie możemy sobie pozwolić na „uczenie się na błędach" w obszarach, gdzie stawką jest życie ludzkie.
Czytaj dalej
Case Study

Jak przygotowywać testy planów lub procedur awaryjnych

Komunikacja kryzysowa
Ochrona ludności
Zarządzanie kryzysowe
testy planów awaryjnych, testowanie procedur awaryjnych, zarządzanie ciągłością działania, plan reagowania kryzysowego, zarządzanie kryzysowe, analiza incydentu bezpieczeństwa, analiza incydentu Erding, incydent w Erding, Bundeswehra, ćwiczenia wojskowe Erding, strzelanina podczas ćwiczeń, błędy komunikacji między wojskiem a policją, zarządzanie ryzykiem operacyjnym, ćwiczenia międzyresortowe, komunikacja kryzysowa, błędy w komunikacji między służbami, unified command, testowanie odporności organizacji, analiza FMEA, zarządzanie incydentami, bezpieczeństwo infrastruktury krytycznej, planowanie testów bezpieczeństwa, kultura bezpieczeństwa, lessons learned, testowanie systemów łączności, dobre praktyki testowania procedur, kryzys w Bawarii, systemowe błędy bezpieczeństwa, koordynacja służb, komunikacja międzyresortowa, zarządzanie incydentami w czasie rzeczywistym
Administracja publiczna
Podmioty ważne i kluczowe