Amerykanie obiecali Europie, że będą ją chronić. Mówię: sprawdzam
Twój biznes może się znajdować pod całkowitą ochroną europejskiego prawa. Zapewnili to Amerykanie. Suwerenna chmura Amazona może przestawić europejski rynek danych na nowe tory.
W styczniu pisałem o oficjalnym uruchomieniu AWS European Sovereign Cloud – pierwszej w historii chmury AWS zaprojektowanej od podstaw z myślą o europejskich regulacjach i europejskiej kontroli nad danymi. Tamten tekst skupiał się na tym co ogłosił Amazon. Teraz czas na jak i dlaczego - bo gdy rozmawia się z człowiekiem, który pracował nad tym projektem od samego początku, obraz staje się znacznie ciekawszy.
Mustafa Isik jest głównym technologiem ds. suwerenności cyfrowej w Amazon Web Services. Z wykształcenia informatyk ze stopniem magistra, przez lata contributor projektów open source, dziś jeden z głównych architektów odpowiedzi AWS na jedno z poważniejszych wyzwań geopolitycznych ostatnich lat. Kiedy rozmawialiśmy, zanim zdążyliśmy jako Spider’s Web zadać pierwsze pytanie, sam się przedstawił: "Wiesz co? Jestem geek'iem."
To dużo mówi o stylu rozmowy, jaka potem nastąpiła.
Czytaj też:
7,8 miliarda euro i trzy filary
Zacznijmy od pieniędzy, bo skala inwestycji robi wrażenie. AWS European Sovereign Cloud to 7,8 miliarda euro - i nie jest to kolejny datacenter przyklejony do istniejącej infrastruktury. Isik tłumaczy to w sposób, który dobrze porządkuje temat: "Chmura europejska ma trzy filary. Pierwszy to zregionalizowana infrastruktura i usługi. Drugi - zregionalizowany personel operacyjny i wsparcia. Trzeci - bardzo konkretna struktura zarządcza."
Filar personalny jest w kontekście suwerenności może najbardziej intrygujący. Wszyscy pracownicy operujący ESC muszą być rezydentami UE - i, co kluczowe, mogą pełnić swoje role wyłącznie wtedy, gdy fizycznie przebywają na terenie państwa członkowskiego Unii. Isik podał przykład z własnej perspektywy: "Gdybym miał rolę operacyjną w European Sovereign Cloud, nie mógłbym jej pełnić będąc tutaj" – czyli rozmawiając ze mną przez Atlantyk, z biura w Stanach.
To mechanizm, który ma odpowiadać na jeden z fundamentalnych lęków europejskich regulatorów: że nawet jeśli dane fizycznie siedzą we Frankfurcie, to ktoś w Seattle może po nie sięgnąć.
Spółka z ograniczoną odpowiedzialnością jako narzędzie suwerenności
Filar zarządczy wygląda może niepozornie, ale jest prawnie bardzo przemyślany. ESC jest zarządzany przez AWS European Sovereign Cloud GmbH - niemiecką spółkę z o.o. Na jej czele stoi Stefan Israel, Francuz, były prezes Arianespace. Isik tłumaczy, dlaczego to nie jest kwestia PR-owa: "Pod niemieckim prawem korporacyjnym Geschäftsführer - zarządca spółki - jest zobowiązany prawnie do działania w najlepszym interesie GmbH, której jest odpowiedzialny, zgodnie ze wszystkimi przepisami prawa".
Sam Isik jest obywatelem Niemiec. GmbH kontroluje trzy spółki córki: jedną odpowiedzialną za infrastrukturę, drugą za cały personel operacyjny, i trzecią – centrum zaufania, które zarządza m.in. infrastrukturą kryptograficzną klucza publicznego. Certyfikaty root, hierarchia certyfikatów – wszystko to pozostaje regionalnie w rękach ESC.
"Rebuild cloud" – Amazon zrobił to samo dwa razy
Jeden cytat z rozmowy z Isikiem wyjątkowo dobrze opisuje skalę przedsięwzięcia: "Musieliśmy odbudować chmurę. Wziąć to, co już działa dla milionów klientów globalnie, i zinstancjonować to ponownie - tym razem zregionalizowane do UE."
To brzmi banalnie, dopóki się nie pomyśli, co to oznacza w praktyce. ESC oferuje ponad 90 usług od pierwszego dnia - te same API, te same poziomy SLA, co globalne regiony AWS. Klient migrujący z Frankfurt region na ESC nie musi przepisywać kodu. Isik podkreśla, że to był warunek konieczny dla klientów: "Każda rozmowa z klientami sprowadzała się do tego samego: nie chcemy niczego gorszego. Chcemy tych samych usług, tych samych API, tego samego bezpieczeństwa, tych samych umów."
Mało kto mówi wprost, że ta operacja technicznie to nie jest „zbuduj region w Europie". To zbudowanie całego stosu od nowa, z izolacją nawet na poziomie metadanych klientów - do czego zaraz wrócimy.
Nitro: jak AWS ogranicza dostęp do własnej infrastruktury
Jeśli jest jeden aspekt techniczny, który Isik opowiadał z widocznym entuzjazmem informatyka, to właśnie system Nitro. I jest się czym ekscytować, bo to rzeczywiście ciekawa architektura.
Problem, który Nitro rozwiązuje, jest następujący: nawet jeśli chronimy dane przed dostępem z zewnątrz, co z administratorami samego AWS? Standardowe hypervisory (jak KVM czy Xen) mają uprzywilejowany dostęp do uruchomionych na nich maszyn wirtualnych – coś, co w żargonie technicznym nazywa się DOM0. To komponent z większymi prawami niż workloady klientów.
AWS poszedł inną drogą. "Hypervisor Nitro jest zbudowany tak, że wzięliśmy wszystko, co możemy zdjąć z procesora i przenieśliśmy przez magistralę PCI Express - która jest zasadniczo fosą - na dedykowane karty PCI Express" - tłumaczy Isik. Efekt? Operatorzy AWS nie mają uprzywilejowanego dostępu do danych klientów w trakcie przetwarzania. To nie jest oświadczenie marketingowe – jest poparte warunkami umowy (punkt 96 user agreement AWS) oraz niezależną weryfikacją przez NCC Group, globalną firmę zajmującą się bezpieczeństwem IT.
To samo NCC Group zweryfikowało zresztą niedawno mechanizmy bezpieczeństwa Amazon EKS - usługi Kubernetes AWS - pod kątem właśnie ograniczeń dostępu operatorskiego.
Metadane: subtelny, ale istotny szczegół
Jest jeden techniczny aspekt ESC, który w poprzednim artykule zaledwie musnąłem, a który w rozmowie z Isikiem okazał się kluczowy dla zrozumienia różnicy między "zwykłym" regionem AWS a European Sovereign Cloud.
Chodzi o metadane tworzone przez klientów. W globalnej infrastrukturze AWS dane rozliczeniowe, dane IAM (zarządzania tożsamością i dostępem) czy metryki użycia są agregowane globalnie – ma to sens, gdy klient korzysta jednocześnie z regionów we Frankfurcie, Mediolanie i Tokio i chce jedną skonsolidowaną fakturę.
W ESC to się zmienia. "Metadane tworzone przez klientów pozostają w granicach European Sovereign Cloud" - mówi Isik. Chodzi o dane takie jak: kto korzystał z jakich usług w jakim zakresie, dane uwierzytelniania i autoryzacji, historię użycia. Te informacje nie opuszczają europejskiego ekosystemu. Żeby to osiągnąć AWS musiał regionalnie odtworzyć całą globalną warstwę zarządzania - billing, IAM, operacyjne metadane. To kolejny powód, dla którego "rebuild cloud" nie jest przesadą.
DDoS i 9 milionów kilometrów kabli
Podczas rozmowy Isik powołał się na ogłoszenie Matt Garmana (CEO AWS) dotyczące skali infrastruktury sieciowej Amazona. Liczba, którą podał, jest absurdalna: 9 mln kilometrów własnych kabli podmorskich i lądowych.
Dlaczego to istotne w kontekście suwerenności i bezpieczeństwa? Bo jedyna skuteczna ochrona przed atakami DDoS to skala. Nie ma eleganckiego algorytmu, który zastąpi po prostu ogromną infrastrukturę. "Przed tym, zanim ataki w ogóle dotrą do endpointów API klientów, 99 proc. z nich niszczymy. Klienci nawet nie wiedzą o 99 proc. tych ataków" - wyjaśnia Isik.
Polska i publiczne wątpliwości
W naszej rozmowie poruszyliśmy kwestię, która w Polsce pojawiała się w mediach: publiczne instytucje korzystające z AWS (w tym podmioty powiązane z krajowymi funduszami), i powtarzające się w debacie publicznej pytanie - czy dane obywateli powinny być w ogóle w rękach prywatnej firmy?
Isik nie był wtajemniczony w konkretne polskie sprawy, ale odpowiedź, którą dał, trafia w sedno: "Gdy zaczyna się wnikać w temat razem z regulatorami, politykami, klientami - niezależnie od kraju - rozmowa zawsze sprowadza się do tego samego. Czy wiem, gdzie są moje dane? Czy kontroluję, kto ma do nich dostęp? Czy mam kontrolę nad szyfrowaniem? Czy mam kontrolę nad odpornością systemu? To są rzeczy, na których ludziom zależy."
To uczciwa odpowiedź. Nie "ufajcie nam, bo Amazon", lecz wskazanie konkretnych mechanizmów kontroli - i zaproszenie do ich weryfikacji. Isik wspomniał też o rozwiązaniu, które może być interesujące dla polskich instytucji publicznych szukających większej kontroli nad fizyczną infrastrukturą.
Dedykowane strefy lokalne i Outposts, czyli chmura w twoim budynku
Kiedy zapytaliśmy o możliwość posiadania przez instytucję publiczną własnych ludzi "wewnątrz" infrastruktury, to Isik opisał kilka modeli - realnych, nie hipotetycznych.
Pierwszym przykładem był Singapur. Tamtejszy rząd (przez podmiot Smart Nation) zażądał, żeby część regulowanych danych znajdowała się fizycznie w rządowych budynkach, ale jednocześnie pozostawała podłączona do regionalnej infrastruktury AWS. Efektem było stworzenie Dedicated Local Zones - rozszerzeń regionalnych umieszczonych w infrastrukturze klienta, ale wciąż własnością i pod operatywną kontrolą AWS. W tym modelu możliwe jest nadanie personelowi AWS stosownych poświadczeń bezpieczeństwa wymaganych przez rządowego klienta.
Jeszcze dalej idzie model Outposts - rack AWS dosłownie umieszczony w centrum danych klienta, obsługiwany zdalnie, bez konieczności stałej obecności operatorów AWS na miejscu. To rozwiązanie dla organizacji, które potrzebują fizycznej lokalizacji u siebie, ale chcą zachować spójność z chmurową platformą
Szyfrowanie i klucze, których AWS nie widzi
Na koniec warto wspomnieć o warstwie, która często umyka w dyskusjach o suwerenności: szyfrowaniu i zarządzaniu kluczami. AWS Key Management Service (KMS) pozwala klientom przynosić własne klucze szyfrujące albo korzystać z kluczy generowanych przez AWS. W obu przypadkach szczyt hierarchii kluczy rezyduje w sprzętowych modułach bezpieczeństwa certyfikowanych na poziomie FIPS 140-2 Level 3 - co oznacza urządzenia odporne na manipulację fizyczną.
"Nie możemy uzyskać do tego dostępu" - mówi Isik wprost o kluczach zarządzanych przez KMS. Bez wyraźnej instrukcji od klienta, klucze pozostają nieosiągalne nawet dla samego AWS.
Czy to wystarczy?
ESC nie jest odpowiedzią na wszystkie pytania o suwerenność cyfrową w Europie. Jest odpowiedzią na konkretne pytanie: jak zbudować hyperscalerową chmurę z gwarancjami operacyjnej niezależności od jurysdykcji USA? I technicznie, ta odpowiedź jest przemyślana - co więcej, zweryfikowana przez niezależne strony trzecie, a nie oparta wyłącznie na słowie Amazona.
Dla polskiego kontekstu oznacza to przede wszystkim tyle, że instytucje i firmy operujące na wrażliwych danych – ochrona zdrowia, finanse, administracja publiczna - mają dziś do dyspozycji coś, czego kilka lat temu po prostu nie było: chmurę hyperscalerową z pełnym portfolio usług, zarządzaną przez Europejczyków, z prawnie egzekwowalnymi gwarancjami, że dane nie opuszczają UE. Obowiązek skorzystania z tego nie spoczywa na nikim. Ale argument "nie ma technicznie dobrego rozwiązania" przestał obowiązywać.
