Przejdź do treści

Szukaj w Security Magazine

NewsletterNewsletter
CybernewsyChmura i usługi SaaS

Czy chmura to już zaplanowany przestój?

Airbus właśnie wrzuca na rynek przetarg za ponad 50 mln euro na migrację mission‑critical systemów (ERP, MES, PLM, CRM) na „suwerenną europejską chmurę” na 10 lat, bo przestali wierzyć w papierową „rezydencję danych” w USA‑cloudzie z etykietką „EU region”.

W tym tekście (7)

Jeśli oni uważają, że CLOUD Act jest realnym zagrożeniem dla ich linii produkcyjnych, to twój polski e‑commerce/szpital/producent części samochodowych naprawdę wierzy, że jest mniej interesujący dla polityków z Waszyngtonu niż Airbus?


O co realnie chodzi w „wywalaniu USA-cloudów”

Europejczycy nie dostali nagle alergii na Amazona i Microsoft, tylko policzyli, że 90‑procentowa zależność od amerykańskiej infrastruktury cloud to pojedynczy punkt awarii sterowany polityką obcego państwa. CLOUD Act zmusza dostawcę z siedzibą w USA do wydania danych, niezależnie gdzie leży dysk – Frankfurt nie ratuje cię przed amerykańskim sądem. Microsoft sam przyznał, że nie jest w stanie zagwarantować pełnej niezależności europejskich danych od amerykańskich organów. To nie jest paranoja regulatorów, tylko problem ciągłości biznesu – jeśli jutro jakiś polityk stwierdzi, że „trzeba przykręcić śrubę Europie”, to czyj przycisk „off” trzyma w ręku.

Dla polskiego CISO oznacza to proste pytanie: które systemy mogą przestać działać, bo ktoś w Seattle, Redmond albo Waszyngton zmienił interpretację prawa. Dla CEO: ile dni downtime’u i ile milionów złotych wypłynie, zanim przeniesiesz się awaryjnie na lokalnego operatora, którego nawet nie masz dziś na liście dostawców.


Case Airbus – przepis na to, co czeka polskie firmy za 12–24 miesiące

Airbus nie bawi się w „przetestujemy jakiegoś niszowego providera”. Wrzucają przetarg na ponad 50 mln euro, do 10 lat, z naciskiem na przewidywalne ceny i suwerenną infrastrukturę utrzymywaną przez podmioty z UE. W zakres wchodzą ERP, MES, CRM i PLM z danymi konstrukcyjnymi samolotów – rzeczy, których nie chcesz mieć w systemie, na który wpływ może mieć obce państwo.

Ten ruch jest bezpośrednio powiązany z powrotem Trumpa i geopolityczną huśtawką – europejskie firmy przestały wierzyć, że relacje transatlantyckie są „stabilne politycznie” na tyle, by oprzeć na nich swoje RTO i RPO. Do tego dochodzi fakt, że Komisja Europejska sama przyznaje, że próbuje budować europejski stack: European Alliance for Industrial Data, Edge and Cloud, roadmapy, fundusze, całe to nudne tło, które nagle umożliwia firmom z UE kupowanie „suwerennych” rozwiązań bez łamania prawa zamówień publicznych.

Czyli: duży przemysł już ucieka. Administracje w Austrii, Niemczech, Francji przepinają kolaborację na Nextclouda i lokalne chmury, żeby odciąć Teams, Zooma, M365 z krytycznych procesów państwowych. To samo wejdzie do sektora prywatnego w Polsce, tylko z opóźnieniem i przy większym bólu, bo wszyscy będą robili to naraz.


„Czy Region UE u hiperskalera wystarczy?” – nie, nie wystarczy

Narracja vendorów jest przewidywalna: masz „Region EU”, czasem nawet „European Sovereign Cloud” z piękną broszurą, w której piszą, że region jest „fizycznie i logicznie odseparowany”, a operacje prowadzą podmioty z UE. Problem w tym, że CLOUD Act nie pyta o to, kto obsługuje data center, tylko kto kontroluje spółkę-matkę. Tu nie chodzi o „gdzie leży dysk”, tylko „kto odbiera telefon, gdy dzwoni amerykański sąd”.

Drugi dogmat do rozstrzelania: „jak będzie problem, to i tak dogadamy się z vendorami, przecież jesteśmy dla nich klientem”. Airbus pokazuje, że duży klient potrafi policzyć inaczej – zakładają, że muszą mieć stack, który prawniczo i technicznie jest poza zasięgiem obcego państwa dla krytycznych systemów, bo inaczej ich linia produkcyjna zależy od geopolityki. Jeśli serwis wnętrz samochodów czy logistyka e‑commerce dalej wierzy, że ich system WMS czy TMS jest mniej „geopolityczny”, to znaczy, że nikt nie policzył efektu domina, gdy dostawcy OEM przestają pracować.


Techniczna brudna robota: gdzie naprawdę boli CISO

Prawdziwy ból nie jest w hasłach typu „suwerenność”, tylko w konkretnych miejscach konfiguracji i integracji.

Pierwszy punkt: identyfikacja „wjazdu” regulacyjno‑geopolitycznego. Systemy do natychmiastowego oznaczenia:

  • IdP / IAM: Azure AD / Entra ID jako single point of failure dla logowania do wszystkiego, w tym VPN, M365, CRM, czasem nawet paneli administracyjnych firewalli.
  • Collaboration: M365/Google Workspace, Teams/Zoom – dokumenty z IP, pliki ofertowe, wewnętrzne raporty ryzyka.
  • ERP / CRM / PLM / MES: SAP S/4HANA w modelu SaaS w US‑cloudzie, Salesforce, Dynamics 365, PLM w SAAS na hyperskalerze.

Drugi punkt: techniczny szczegół, który od razu zdradza, czy ktoś myśli o suwerenności, czy tylko o ładnej prezentacji – kontrola egressu. W 90% polskich wdrożeń widać w VPC/VNet reguły typu „0.0.0.0/0 allow outbound na AzureFirewallOutbound lub Internet”, a Security Groups dopuszczają ruch wychodzący „Any → Any na 443”. To idealny przepis na niekontrolowany exfil przez managed service’y providerów, które trzymają logi i metadane poza twoją świadomością.

Jeśli twój „suwerenny” model zakłada, że:

  • logi z SIEM lecą do US‑based log analytics,
  • backupy idą na S3 w regionie „eu‑central‑1” z opcją „Cross-Region Replication” włączoną z rozpędu,
  • a w polityce „Default outbound access for VMs” nic nie zostało wyłączone,

to nie masz suwerenności, tylko ładnego slajdu.

Trzeci punkt: identity federation. Często jest tak, że „lokalny” dostawca chmury używa IdP w modelu „Connect with Azure AD / Google”. Wtedy suwerenność pada na pierwszym 302 z redirectem do login.microsoftonline.com, który jest pod pełną jurysdykcją USA – nawet jeśli twoja aplikacja pracuje na serwerze w Krakowie.


Koszty: ile to naprawdę będzie boleć

CFO nie interesuje „suwerenność”, tylko rachunek.

Airbus pakuje w ten ruch ponad 50 mln euro na 10 lat, w zamian za przewidywalność cen i kontrolę. Przeliczając brutalnie: dla polskiej firmy z przychodem 1–5 mld zł analogiczny program nie będzie kosztował 50 mln euro, ale parę procent rocznego IT CAPEX/OPEX rozłożonych na kilka lat. Dochodzą trzy główne kubły wydatków:

  1. Koszt podwójnego stacku przez 2–3 lata.Przez migrację będziesz płacił jednocześnie za USA‑cloud i lokalnego operatora. To znaczy, że budżet na infrastrukturę i licencje w tych latach rośnie typowo o 30–60%, a nie o 10%.
  2. Koszt re‑platformingu.ERP typu SAP S/4HANA w modelu „RISE with SAP” sprowadzony do lokalnej chmury lub hostingu oznacza: nowe licencje / maintenance, przebudowę integracji, testy regresyjne, czasem przepisanie customowych rozszerzeń. To kilkanaście do kilkudziesięciu mln zł w średniej firmie, zanim zobaczysz jakikolwiek „oszczędności”.
  3. Koszt ludzi.W Polsce brakuje inżynierów, którzy naprawdę rozumieją jednocześnie AWS/Azure i lokalnych providerów, do tego prawo (RODO, NIS2) i modele BCP. Tych ludzi trzeba kupić konsultingiem, co przy dużym programie oznacza spokojnie 20–40 tys. euro miesięcznie przez kilkanaście miesięcy.

Z drugiej strony: realny koszt „nie‑zrobienia nic” to nie tylko kary RODO. Jeśli faktycznie dojdzie do ograniczenia usług przez amerykańskich providerów wobec wybranych sektorów / krajów, to downtime krytycznych systemów ERP/MES w produkcji czy WMS w logistyce liczy się w milionach złotych na dzień. Airbus wrzuca 50+ mln euro właśnie po to, żeby nie liczyć potem „ile kosztuje zatrzymana fabryka przez polityczną decyzję w innym państwie”.


Plan na polskie realia – co robisz w poniedziałek rano

Krok pierwszy: brutalna inwentaryzacja zależności od US‑cloudów. Lista systemów, ich RTO/RPO, vendor, jurysdykcja spółki‑matki. Osobno wypisujesz: IdP/IAM, ERP/CRM, collaboration, PLM/MES, logi/SIEM, backup. Jeśli nie wiesz, gdzie jest IdP, to już masz problem.

Krok drugi: klasyfikacja „musimy wyrzucić z USA‑jurysdykcji w 3 lata” vs „może zostać, jeśli zredukujemy impact”. Do pierwszej grupy zwykle trafią: systemy produkcyjne (MES, SCADA integracje, ERP finansowy), systemy z IP (PLM, repozytoria kodu), systemy z danymi wrażliwymi (zdrowie, dane obywateli).

Krok trzeci: projektowanie podwójnego IdP, żeby mieć drogę ucieczki. Minimum: lokalny, europejski IdP (Keycloak / WSO2 / lokalne IdP‑as‑a‑Service) na infrastrukturze podmiotów z UE, spięty w federację z obecnym Entra ID, ale gotowy do przejęcia roli źródła tożsamości.

Krok czwarty: wymuszenie kontroli egressu i logów – zamknięcie „any/any outbound”, centralne proxy egressowe z pełnym audytem, zapis logów na storage kontrolowanym kontraktowo i jurysdykcyjnie przez UE. To brzmi nudno, ale to jest ten poziom, po którym inżynierowie widzą, że ktoś naprawdę myśli o suwerenności, a nie o slajdzie dla zarządu.

Krok piąty: negocjacje z CFO. Pokazujesz trzyliniowy rachunek:

  • koszty utrzymania podwójnego stacku 2–3 lata,
  • koszty re‑platformingu krytycznych systemów,
  • szacunkowy koszt dnia przestoju + ryzyko geopolityczne (w oparciu o przykład Airbusa i regulacje CLOUD Act).

Nie sprzedajesz „bezpieczeństwa”, sprzedajesz redukcję prawdopodobieństwa, że twoja firma zostanie zakładnikiem cudzej polityki.


Bibliografia

  • The Register – „Euro firms must ditch Uncle Sam's clouds and go EU-native”.
  • The Register – „Airbus to migrate critical apps to a sovereign Euro cloud”.
  • CloudComputing-News – „Airbus prepares tender for European sovereign cloud”.​
  • Techzine – „Airbus wants to migrate critical apps to sovereign European cloud”.
  • European Commission – European Alliance for Industrial Data, Edge and Cloud.​
  • EU/CISPE – krytyka EU Cloud Sovereignty Framework.
  • Nextcloud – „Digital sovereignty in Europe: what still lies ahead”, „Nextcloud 2025 Wrap-Up”.
  • Artykuły o migracji austriackiego ministerstwa na Nextcloud.​

Powiązane materiały