Chmura bez „wyłącznika”
Sławomir Biliński: Google oferuje wersję swojej chmury całkowicie odciętą od Internetu, przeznaczoną m.in. dla wojska i instytucji pracujących na najbardziej wrażliwych danych. Jak to działa w praktyce?
Krzysztofem Kaziów: To rozwiązanie nazywamy Google Distributed Cloud w wersji air-gapped i jest ono w całości odłączone zarówno od publicznego internetu, jak i od samej chmury Google. Zaprojektowaliśmy je tak, by mogło pozostać odłączone bezterminowo. Nasze rozwiązanie air-gapped gwarantuje przetrwanie platformy (platform survivability) – system nie ma wbudowanego „wyłącznika” i nie może zostać zdalnie wyłączony.
SŁOWNICZEK:
Air-gap (środowisko air-gapped) – system fizycznie odcięty od internetu i od sieci dostawcy. Nic do niego nie wpływa i nic z niego nie wypływa online; aktualizacje wgrywa się ręcznie, offline.
Cloud External Key Manager (EKM) – mechanizm, w którym klucze szyfrujące są przechowywane poza infrastrukturą dostawcy. Bez klucza zaszyfrowane dane pozostają nieczytelne dla osób trzecich.
Key Access Justifications – wymóg, by każda próba dostępu do danych miała uzasadnienie zatwierdzane lub odrzucane przez właściciela danych.
Hyperscaler – tu globalny dostawca chmury o ogromnej skali (jak Google, Amazon, Microsoft).
Vendor lock-in – uzależnienie od jednego dostawcy tak silne, że zmiana staje się nieopłacalna lub technicznie niemożliwa.
Serwery stoją fizycznie we własnym centrum danych klienta albo w lokalizacji brzegowej. Instalacją, obsługą i naprawą może zajmować się Google, zaufany partner lokalny albo może odbywać się to w modelu mieszanym. Można również skonfigurować jakie obywatelstwo i poświadczenia bezpieczeństwa mają mieć osoby obsługujące system. Aktualizacje trafiają do środowiska w kontrolowanym procesie offline, bez potrzeby łączności ze światem zewnętrznym. Rozwiązanie zbudowaliśmy pod rygorystyczne standardy, w tym NATO D48, NIST SP 800-53 na poziomie FedRAMP High oraz ISO 27001 i 27017.
Samo środowisko air-gapped razem z usługami AI działającymi w pełni lokalnie, w tym modelami Gemini i Gemma, jest produktem wdrożonym już u naszych sojuszników. Z rozwiązań tych korzystają m.in. NATO, brytyjskie Ministerstwo Obrony (UK MoD) oraz niemieckie BWI działające na rzecz Bundeswehry, które przetwarza otwarte i chronione dane we własnych centrach danych.
Kto trzyma klucze do danych
Nawet jeśli serwery i dane fizycznie znajdują się w Polsce, Google pozostaje firmą amerykańską i podlega prawu USA. Czy istnieją zabezpieczenia. które sprawiają, że Google technicznie nie jest w stanie odczytać danych klienta, nawet gdyby chciał albo musiał? A gdyby amerykański sąd lub służby zażądały wydania danych polskiej instytucji: czy dowiedziałaby się ona o tym i co realnie mógłby przekazać Google?
Tak, takie zabezpieczenia istnieją i mają charakter techniczny. Rozumiemy i wspieramy priorytety europejskich decydentów w zakresie suwerenności danych i ograniczania ryzyk. [1]
W chmurze publicznej fundamentem jest Cloud External Key Manager (EKM): klucze szyfrujące pozostają poza infrastrukturą Google, w wyłącznej dyspozycji lokalnego podmiotu. Tworzy to techniczną barierę uniemożliwiającą dostęp stron trzecich do danych bez zgody i wiedzy klienta. Uzupełnia to mechanizm Key Access Justifications, w którym każda próba dostępu wymaga uzasadnienia, zatwierdzanego lub odrzucanego w czasie rzeczywistym przez właściciela danych.
W modelu z lokalnym operatorem (Google Cloud Dedicated) infrastrukturą i dostępem administracyjnym zarządza podmiot działający pod prawem krajowym, a klient pozostaje w relacji umownej wyłącznie z nim. W środowisku dedykowanym i air-gapped (Google Distributed Cloud) pytanie o jurysdykcję traci znaczenie operacyjne: jest ono odłączone od publicznego internetu i samej chmury Google, a jego eksploatacją zajmuje się klient albo wskazany przez niego podmiot.
W przypadku żądań ze strony sądów czy organów obowiązuje nas jasny protokół [2]Kwestionujemy żądania zbyt szerokie lub sprzeczne z prawem miejscowym, a tam, gdzie prawo na to pozwala, informujemy klienta o tym, że żądanie do nas wpłynęło. Najważniejszy jest jednak fakt, że w żadnym z tych modeli decyzja o dostępie do danych nie należy do nas. Jeżeli środowiskiem zarządza lokalny operator, dostęp administracyjny kontroluje on, a nie Google.
Gdzie kończy się suwerenność
Część ekspertów i polityków mówi wprost: samo powierzenie amerykańskiej korporacji danych związanych z bezpieczeństwem państwa jest naruszeniem polskiej suwerenności cyfrowej. Jak Pan odpowiada na taki zarzut?
Cyfrowa suwerenność zaczyna się od realnego wyboru dostawcy i weryfikowalnej kontroli nad kluczami. O suwerenności decyduje realna zdolność instytucji do zarządzania swoimi danymi i weryfikowania każdego dostępu do nich. Ta kontrola opiera się na konkretnych filarach: wyborze modelu eksploatacji, kluczach pozostających u klienta i obowiązku uzasadnienia każdej próby dostępu, lokalnym operatorze działającym w ramach krajowych przepisów oraz zagwarantowanym prawie do wyjścia.
Granica, której państwo nie powinno przekraczać, przebiega tam, gdzie traci ono techniczną zdolność weryfikacji dostępu do swoich zasobów. Dopóki to polska instytucja trzyma klucze i autoryzuje dostęp, dopóty zachowuje realną kontrolę nad swoimi danymi i każdym dostępem do nich. Właśnie dlatego budujemy ofertę warstwowo: od granicy danych w UE, przez lokalnego operatora, aż po środowiska air-gapped. Instytucja ma możliwość wyboru poziomu kontroli odpowiedniego do wrażliwości konkretnego zadania.
Gdzie „myśli” sztuczna inteligencja
W obronności coraz częściej liczy się nie tylko to, gdzie leżą dane, ale gdzie „myśli” AI. Czy modele AI Google mogą działać w całości na infrastrukturze w Polsce? I co się stanie, jeśli polska instytucja, z powodów politycznych albo prawnych, straci wsparcie producenta: czy system przestanie działać?
Pełną gwarancję, że zapytania, dokumenty i zapisy pracy systemu nie opuszczają kraju daje środowisko, w którym modele działają na infrastrukturze eksploatowanej przez klienta, w wybranej przez niego lokalizacji. Ten wariant rekomendujemy dla danych o najwyższej wrażliwości. W przypadku modeli udostępnianych jako usługa zarządzana obowiązuje granica przetwarzania na poziomie Unii Europejskiej: dane pozostają w UE, ale samo przetwarzanie może odbywać się w jednym z europejskich regionów. Mówimy o tym otwarcie, ponieważ różnica między „w Unii Europejskiej” a „wyłącznie w Polsce” ma znaczenie, a instytucja powinna dobierać odpowiedni model wdrożenia do klasy swoich danych.
Zastrzegam przy tym fundamentalną zasadę: nie wykorzystujemy danych klientów biznesowych do trenowania naszych modeli, więc wprowadzane informacje pozostają wyłącznie własnością instytucji.
Sztuczna inteligencja z powodzeniem pracuje w modelu air-gapped, całkowicie odciętym od internetu. Przykładem dla polskiego rynku jest projekt rozwijany z firmami Deloitte, Dell i NVIDIA, adresujący specyficzne, wysoce wrażliwe potrzeby. Warto dodać ważny kontekst: doświadczenia z Bliskiego Wschodu i wojny w Ukrainie pokazują, że pojedyncze lokalne centra danych są podatne na ataki kinetyczne, dlatego optymalna architektura łączy lokalne środowiska air-gapped dla danych najwyższej wrażliwości z rozproszoną chmurą dla skalowalnych obciążeń AI.
W przypadku utraty wsparcia producenta nasz model opiera się na ciągłości działania. Wdrożone środowisko air-gapped pozostaje pod kontrolą klienta – nie ma w nim zdalnego „wyłącznika” ani zależności od naszej globalnej sieci, więc decyzja biznesowa czy polityczna podjęta po naszej stronie nie zatrzymuje pracy systemu. Cykl życia tej instalacji kontroluje jej właściciel.
Amerykańska firma, europejskie kryteria
W UE trwają prace nad przepisami, które mogą uzależnić dostęp do części zamówień publicznych od tego, jak „suwerenny” jest dostawca chmury – kto jest jego właścicielem, gdzie ma centralę, kto go kontroluje. Czy firma z siedzibą w USA jest w ogóle w stanie spełnić najwyższe z takich wymagań?
Zgodnie z wnioskami z raportu Draghiego [3], postrzeganie suwerenności cyfrowej wyłącznie jako izolacji lub autarkii – chociażby przez wprowadzanie asymetrycznych regulacji i preferencji dla konkretnej struktury właścicielskiej – osłabia europejską konkurencyjność i tworzy ryzyko długu technologicznego. Suwerenność potwierdza się bezpieczną architekturą i weryfikowalnymi mechanizmami kryptograficznymi, czyli kryteriami, które można zbadać i audytować.
Jesteśmy gotowi spełniać rygorystyczne wymogi, które da się zweryfikować technicznie, w tym standardy obowiązujące w NATO. Nasze środowisko air-gapped zbudowaliśmy pod wymogi NATO D48, NIST SP 800-53 na poziomie FedRAMP High oraz ISO 27001 i 27017. Jeśli przepisy zawężą kryteria do adresu centrali, europejskie instytucje stracą dostęp do wiodących rozwiązań chmurowych i modeli sztucznej inteligencji, co bezpośrednio wpłynie na ich zdolność do innowacji i skutecznej obrony przed cyberzagrożeniami. Infrastrukturę budujemy w Europie i razem z Europą: 13 regionów chmurowych, centrum suwerenności w Monachium (Sovereignty Hub) oraz wielomiliardowe inwestycje infrastrukturalne. Jesteśmy przekonani, że suwerenność i konkurencyjność muszą iść w parze.[4]
Czy powstanie „polska chmura Google”
We Francji i w Niemczech Google oferuje chmurę we współpracy z lokalnymi, niezależnymi partnerami, którzy zatrudniają miejscowy personel i sami nią zarządzają. Czy taka „polska chmura Google” mogłaby powstać u nas?
Taki model jest sprawdzony w Europie i w pełni możliwy do wdrożenia w Polsce. Nasza współpraca we Francji zaowocowała powstaniem S3NS, spółki działającej z firmą Thales, która oficjalnie uzyskała najwyższą kwalifikację SecNumCloud 3.2 od francuskiej narodowej agencji cyberbezpieczeństwa (ANSSI). Jest to pierwsza na rynku chmura oparta na technologii globalnego hyperscalera, która uzyskała tę kwalifikację. W Niemczech działamy na podobnych zasadach.[5]
W takim układzie lokalny, niezależny podmiot jest właścicielem infrastruktury, zatrudnia personel z poświadczeniami bezpieczeństwa, zarządza platformą i trzyma klucze do danych. Google dostarcza jedynie technologię, a klient pozostaje w relacji prawnej wyłącznie z firmą działającą pod prawem krajowym. Jeśli chodzi o polski rynek, konsekwentnie trzymamy się zasady niekomentowania rozmów przed oficjalnym sfinalizowaniem porozumień.
Lekcja z Ukrainy
Wojna w Ukrainie pokazała, że centra danych i sieci energetyczne bywają celem rakiet, sabotażu i cyberataków. Jak powinna wyglądać odporna chmura dla polskiego państwa: czy kopie kluczowych danych powinny znajdować się wyłącznie w Polsce, czy także u sojuszników z NATO? I kto w sytuacji kryzysowej podejmowałby decyzję o „ewakuacji” danych do innego kraju?
Odporna chmura opiera się na możliwości przeniesienia danych i geograficznym rozproszeniu oraz unikaniu uzależnienia od jednego dostawcy. W praktyce oznacza to architekturę stworzoną na otwartych standardach i formatach danych, która pozwala szybko przenieść obciążenia poza obszar zagrożony. Nie chodzi przy tym o utrzymywanie kopii u kilku dostawców jednocześnie, ale o to, żeby przeniesienie było technicznie możliwe i przetestowane, zanim będzie to potrzebne. Ukraina po wybuchu wojny udowodniła to w praktyce, przenosząc krytyczne rejestry państwowe do chmury przy współpracy z sojusznikami. Dzięki temu zniszczenie fizycznej serwerowni nie oznaczało utraty danych.
Kopie zapasowe kluczowych danych, przy zachowaniu Polski jako głównego ośrodka przetwarzania, powinny być rozproszone u zaufanych sojuszników w ramach NATO. Geograficzne rozproszenie stanowi fundamentalny element odporności. Decyzję o ewentualnej ewakuacji zawsze podejmuje właściciel danych i kluczy szyfrujących. Polska, posiadając pełnię władztwa nad swoim środowiskiem, może przeprowadzić taką operację całkowicie samodzielnie, bez udziału Google Cloud – decyzja i wykonanie pozostają po stronie właściciela kluczy.
Kryzys w jednym regionie, spokój w innym
Google to firma globalna. Jej centra danych, kable i pracownicy rozsiani są po całym świecie, także w regionach niestabilnych politycznie. Czy atak na infrastrukturę Google, na przykład w którymś z państw Zatoki Perskiej, albo poważny cyberatak na firmę w innej części świata mógłby odbić się na usługach świadczonych np. polskiemu MON?
Architektura Google dzieli się na całkowicie niezależne domeny awarii. Poszczególne regiony i strefy posiadają własne, odseparowane zasilanie, chłodzenie i infrastrukturę sieciową. Problem w jednej części świata nie wpływa kaskadowo na pracę usług świadczonych w innych regionach.
W zastosowaniach obronnych środowisko air-gapped działa całkowicie lokalnie, bez jakiejkolwiek zależności od naszej globalnej sieci. Dane obronne w Polsce są absolutnie odseparowane od zewnętrznego ruchu, a mechanizmy przełączania projektujemy tak, aby usługa funkcjonowała nawet przy fizycznej utracie pojedynczego węzła. Zdarzenia po drugiej stronie świata nie mają technicznej możliwości wpływu na tego typu system.
Prawo do wyjścia
Krytycy chmury publicznej ostrzegają przed uzależnieniem od jednego dostawcy: jego usług, narzędzi i formatów danych. Czy Google byłby gotów dać polskim instytucjom obronnym twarde, kontraktowe gwarancje „wyjścia”: możliwość zabrania danych i przeniesienia systemów do innego?
Prawo do wyjścia jest twardym zobowiązaniem wpisanym w naszą ofertę. Aby zapobiegać zjawisku „vendor lock-in”, promujemy standardy open-source (np. Kubernetes, modele Gemma), które zapewniają swobodę przenoszenia aplikacji i systemów. Nasza platforma pozwala przenieść systemy i dane do innego dostawcy bez konieczności przepisywania ich od podstaw.
Jako pierwsi spośród dużych dostawców chmurowych wyeliminowaliśmy opłaty za transfer danych wychodzących dla klientów migrujących z naszej platformy. Jesteśmy gotowi kontraktowo zagwarantować pełne prawo wyjścia, w tym otwarte formaty danych oraz harmonogram migracji adekwatny do skali danych. Natomiast niezależnie od powyższego chcemy, aby instytucje pozostawały z nami z powodu jakości naszej technologii. Koszt wyjścia nie powinien być argumentem w tej rozmowie.
Boczne drzwi do polityki?
Czy ewentualny duży, strategiczny kontrakt Googla z rządem nie otwiera przypadkiem „bocznych drzwi” do rozmów polityków o zupełnie innych sprawach – na przykład o tym, co widać w wyszukiwarce albo co poleca YouTube? W debacie publicznej regularnie (zwłaszcza przed wyborami) wraca zarzut, że wielkie platformy decydują, które opinie zyskują zasięgi.
Google Cloud stanowi odrębny obszar biznesowy. Nasze umowy z instytucjami państwowymi dotyczą wyłącznie infrastruktury chmurowej, cyberbezpieczeństwa oraz technologii. Nie tworzą one w żaden sposób kanału wpływu na nasze produkty konsumenckie, takie jak wyszukiwarka czy rekomendacje w YouTube.
Zasady działania systemów rekomendacji podlegają ścisłym regulacjom europejskim (m.in. aktowi o usługach cyfrowych – DSA), audytom oraz wymogom sprawozdawczym. Umowa infrastrukturalna z rządem ma charakter ściśle techniczny i rozliczana jest z jakości dostarczanych rozwiązań, nie stwarzając żadnych „bocznych drzwi” do wywierania politycznych nacisków na publiczny przepływ informacji.
Wyścig na szybkość w cyberobronie
Dzięki własnym zespołom analitycznym Google widzi ataki hakerskie na całym świecie, w tym kampanie prowadzone przez grupy powiązane z obcymi państwami. Czy Google dzieli się tą wiedzą z instytucjami państwowymi również wtedy, gdy ich systemy nie korzystają z Google Cloud?
Dzielenie się wiedzą o zagrożeniach to nasza stała praktyka i dotyczy ona krajobrazu cyberbezpieczeństwa jako całości, niezależnie od tego, czy zagrożone systemy korzystają z Google Cloud. Wiedza o wektorach ataku, złośliwym oprogramowaniu czy kampaniach sponsorowanych przez obce państwa ma wymiar uniwersalny. Podstawą jest skala naszej obserwacji: łączymy telemetrię z systemów takich jak Chrome, Android czy Gmail z analizami Google Threat Intelligence Group i ekspertów Mandiant. To daje przewagę czasową nad przeciwnikiem. W walce z cyberatakami rozstrzygającą zmienną jest właśnie szybkość.
Przykładem działania poza granicami naszego ekosystemu jest program Big Sleep, w którym sztuczna inteligencja wyszukuje nieznane wcześniej luki bezpieczeństwa, najpierw w naszych produktach, a następnie w projektach open source, których opiekunom zgłaszamy znalezione problemy. To oprogramowanie, na którym działa znaczna część internetu, także systemy instytucji publicznych. Wymiana informacji z instytucjami państwowymi odbywa się zaufanymi kanałami, z poszanowaniem rygorów poufności. Największym wyzwaniem nie jest dziś wola współpracy, lecz tempo – atakujący skalują działania za pomocą agentów AI, więc obrona musi wymieniać informacje i wdrażać poprawki równie szybko.
Dziękuję za rozmowę i pański czas.
Podsumowanie
Google Cloud przesuwa definicję suwerenności z geografii („gdzie stoi serwer”) na kontrolę („kto trzyma klucze i kto autoryzuje dostęp”). Daje konkretne narzędzia ograniczania ryzyka – klucze poza infrastrukturą dostawcy, środowiska odcięte od sieci, model lokalnego operatora i kontraktowe prawo wyjścia. To realnie zawęża pole sporu o suwerenność cyfrową z ogólnego „amerykańska firma” do sprawdzalnych warunków technicznych i umownych. Pytanie brzmi czy polska władza i służby są na tyle sprawne technicznie by samodzielnie zweryfikować gwarancje techniczne dawane przez ta firmę. Rozmowa o chmurze dla państwa okazuje się w istocie sporem o model cyfrowego państwa: weryfikowalna kontrola wewnątrz technologii globalnego gracza kontra kosztowna budowa europejskiej alternatywy. Zadecyduje tu pewnie ostatecznie cena każdej z tych dróg.
[1]Od redakcji: W 2020 r. Trybunał Sprawiedliwości UE w wyroku Schrems II unieważnił mechanizm Privacy Shield, uznając, że prawo USA nie zapewnia danym Europejczyków ochrony równoważnej unijnej. Wyrok wymusił dodatkowe zabezpieczenia przy transferach danych za Atlantyk. Ta sprawa nie jest definitywnie zakończona.
[2]Od redakcji: źródłem obaw o jurysdykcję USA jest amerykański CLOUD Act z 2018 r., który pozwala organom Stanów Zjednoczonych żądać od firm podlegających prawu amerykańskiemu udostępnienia danych niezależnie od kraju ich przechowywania. To on stoi za tezą, że serwer w Polsce sam w sobie nie wyłącza ryzyka eksterytorialnego.
[3] Od redakcji: Raport o przyszłości konkurencyjności Europy przygotowany pod kierunkiem Maria Draghiego, ostrzega przed technologicznym zapóźnieniem UE i nadmiernym uzależnieniem od zewnętrznych dostawców. Z tego samego raportu wyprowadza się również wnioski o potrzebie budowy własnych europejskich zdolności.
[4] Od redakcji: Komisja Europejska rozwija ramy oceny suwerenności chmury (Cloud Sovereignty Framework, skala SEAL), a w 2026 r. przedstawiła projekt Cloud and AI Development Act (CADA), który może warunkować dostęp do najwrażliwszych zamówień publicznych od poziomu suwerenności dostawcy.
[5] Od redakcji:. S3NS to spółka prawa francuskiego powiązana z Thalesem (udziałowiec większościowy), a jej oferta „chmury zaufanej” (PREMI3NS) uzyskała kwalifikację SecNumCloud 3.2 od ANSSI – ogłoszenie z grudnia 2025 r. SecNumCloud to francuska kwalifikacja bezpieczeństwa chmury nadawana przez agencję ANSSI, obejmująca m.in. odporność na prawo eksterytorialne.
prawnik, autor licznych publikacji z prawa podatkowego