Czy da się korzystać z chmury publicznej, nie tracąc kontroli nad danymi? Tak, pod warunkiem, że wybierzesz dostawcę, który rozumie, czym naprawdę jest cyfrowa suwerenność. W rozmowie z ekspertem Google Cloud sprawdzamy, jak w praktyce wygląda bezpieczeństwo, zgodność z regulacjami i realna kontrola nad lokalizacją danych również w Polsce. — Nie ma realnych powodów, by rezygnować z rozwiązań chmurowych z obawy o kwestie związane z suwerennością cyfrową – te zagadnienia można skutecznie zaadresować — mówi Artur Kuliński, ekspert ds. cyberbezpieczeństwa w Google Cloud w rozmowie z Business Growth Review.
- Suwerenność danych oznacza pełną kontrolę użytkownika nad tym, gdzie i jak jego dane są przechowywane i przetwarzane
- Google Cloud umożliwia klientom wybór lokalizacji danych, gwarantując ich przetwarzanie wyłącznie w wyznaczonym regionie, np. w Warszawie
- Bezpieczeństwo w chmurze Google Cloud jest realizowane w sposób kompleksowy — od projektowania usług, przez infrastrukturę, aż po kulturę organizacyjną
- Nowoczesne firmy coraz częściej wybierają chmurę jako podstawę infrastruktury IT, także ze względu na zgodność z regulacjami i możliwość elastycznego rozwoju
Grzegorz Kubera, Business Growth Review: W Europie, ale też w Polsce duże znaczenie zyskuje suwerenność w kontekście danych czy szerzej – cyfryzacji. Jak należy ją rozumieć?
Artur Kuliński, ekspert ds. cyberbezpieczeństwa w Google Cloud: Suwerenność cyfrowa to pojęcie znacznie szersze niż sama suwerenność danych. Gdy jednak mówimy o suwerenności w kontekście cyfrowym, najczęściej mamy właśnie na myśli kwestie związane z danymi. Dzieje się tak dlatego, że temat ten najczęściej pojawia się w dyskusjach dotyczących zgodności z przepisami i wzbudza wiele różnych wątpliwości. 
W uproszczeniu można powiedzieć, że chodzi o sytuację, w której użytkownik usług cyfrowych ma realną kontrolę nad tym, w jaki sposób jego dane są przechowywane, przetwarzane i przesyłane w ramach danej usługi. To byłaby chyba najprostsza i najbardziej podstawowa definicja suwerenności danych.
Załóżmy, że firma chce zapewnić swoich klientów, że oferuje im suwerenność danych, mimo że te dane są przesyłane do chmury. Jak w takim przypadku wygląda to w praktyce, gdy korzystamy z usług Google Cloud?
Jako dostawca usług chmurowych pełnimy bardzo określoną rolę, która ogranicza się jedynie do przechowywania i przetwarzania danych. Nie jesteśmy właścicielami danych i nie wykorzystujemy ich w żaden inny sposób niż ten, który został określony w instrukcjach od klienta. Użytkownik korzystający z usług Google Cloud samodzielnie konfiguruje środowisko i decyduje, w jaki sposób dane mają być przechowywane i przetwarzane.
Jednym z kluczowych elementów tej konfiguracji jest fizyczna lokalizacja danych. Większość naszych usług objęta jest tzw. rezydencją danych, co oznacza, że gwarantujemy – zarówno kontraktowo, jak i technicznie – że jeśli klient wskaże konkretną lokalizację, dane nie opuszczą wskazanego obszaru.
Czyli możemy wskazać, aby dane np. nie opuściły Polski i były przetwarzane tylko w Polsce?
W praktyce wygląda to tak, że chmura opiera się na regionach, czyli kilku centrach danych zlokalizowanych w jednej konkretnej lokalizacji geograficznej, na przykład w Warszawie. W tym przypadku mówimy o regionie o nazwie „europe-central2”. Google Cloud ma obecnie 13 tego typu regionów w Europie. Poza regionami istnieją także szersze lokalizacje, takie jak obszar całej Unii Europejskiej, a także lokalizacje globalne.
Jeśli klient wybierze w konfiguracji, że jego dane mają pozostawać w regionie “europe-central2”, to dla usług objętych rezydencją danych zapewniamy, że dane rzeczywiście będą przetwarzane wyłącznie w tej lokalizacji. Istnieje również możliwość wyboru tzw. multiregionu, np. Unii Europejskiej – co oznacza, że dane będą przechowywane i przetwarzane tylko w centrach danych zlokalizowanych w UE. Tak właśnie rozumiemy i realizujemy suwerenność danych.
Doprecyzujmy jeszcze: jeśli dane mają być przechowywane w Warszawie, to czy to oznacza, że będą one przetwarzane wyłącznie na serwerach fizycznie zlokalizowanych właśnie w Warszawie?
Trzeba pamiętać, że chmura to ponad 150 różnych usług, które pełnią różne funkcje – od przechowywania danych po ich przetwarzanie. W przypadku większości kluczowych usług klient ma możliwość takiej konfiguracji, by zarówno dane w spoczynku, czyli zapisane na nośnikach, jak i dane przetwarzane aktywnie, były obsługiwane w określonym regionie geograficznym.
Dla lepszego zobrazowania podam przykład. Mamy usługę Kubernetes, która opiera się na klastrach maszyn wirtualnych wykorzystywanych do przetwarzania danych. Klient może uruchomić taki klaster w konkretnym regionie, na przykład w Warszawie i jednocześnie wskazać lokalizację danych, z których klaster ma korzystać – na przykład w usłudze cloud storage. Te dwie usługi wspierają rezydencję danych, zatem z technicznego punktu widzenia jesteśmy w stanie zagwarantować, że dane pozostaną wyłącznie w regionie warszawskim i nie zostaną przesłane poza jego granice.
Jak dobrać chmurę dla siebie
Czy firma decydująca się na współpracę z Google Cloud, która ma siedzibę w Polsce, ale myśli o rozszerzeniu działalności na całą Unię Europejską, powinna wybrać od razu region europejski, czy na początek lepiej postawić na region warszawski, bo będzie taniej?
Chmura Google Cloud to jeden spójny ekosystem, dostępny w różnych lokalizacjach na całym świecie. Kluczowe usługi są dostępne globalnie, więc to, jaką lokalizację wybierze klient, zależy przede wszystkim od jego indywidualnych potrzeb. Jeśli firma obsługuje klientów głównie w Polsce lub w regionie Europy Środkowo-Wschodniej, naturalnym wyborem będzie region chmurowy położony najbliżej tych użytkowników – na przykład ten warszawski – ze względu na niższe opóźnienia i większą wydajność.
Z drugiej strony, jeśli klient ma szczególne wymagania związane z wysoką dostępnością usług i chce zabezpieczyć się na wypadek bardzo rzadkiej awarii całego regionu, może zaprojektować rozwiązanie tak, aby działało równolegle w Warszawie i w innych regionach Unii Europejskiej.
W przypadku firm, które rozwijają działalność na rynki globalne, możliwa jest konfiguracja środowiska w taki sposób, by dane i aplikacje były dostępne w wielu lokalizacjach na świecie – bez konieczności zmiany technologii czy narzędzi. Na tym właśnie polega elastyczność i siła rozwiązań chmurowych.
Jakie dane firma powinna przetwarzać w chmurze, a które pozostawić lokalnie, czyli on-premise? I czy nadal wiele firm uznaje, że chce przechowywać część danych na własnych urządzeniach i nie przenosi całego środowiska do chmury?
Etap takiego ostrożnego podejścia do chmury mamy już za sobą. Gdybym spojrzał na sytuację sprzed trzech, a może nawet czterech lat, rzeczywiście widać było wśród niektórych firm tendencję do ostrożnego testowania rozwiązań chmurowych, najczęściej zaczynając od systemów niewymagających przetwarzania danych wrażliwych. Dziś wygląda to inaczej, choć oczywiście wiele zależy od rodzaju firmy.
Mamy startupy, dla których chmura jest naturalnym środowiskiem. Dla takich firm własna serwerownia czy fizyczna infrastruktura to coś zupełnie obcego – od początku działają w pełni w chmurze i tam też przetwarzają wszystkie dane, niezależnie od ich charakteru. Sam, przechodząc do Google z firmy bardziej tradycyjnej, zauważyłem, jak ogromna jest różnica między podejściem firm „urodzonych” w internecie a tych, które dopiero przestawiają się na model chmurowy. To zupełnie inny sposób działania i zestaw narzędzi.
Z drugiej strony mamy firmy o bardziej klasycznym profilu, w tym również te działające w sektorach podlegających ścisłym regulacjom. Tu podejście do chmury bywa zróżnicowane. W trakcie mojej współpracy z jedną z największych firm na polskim rynku, która przetwarza ogromne wolumeny danych, w tym danych wrażliwych, zauważłem, że nawet w tak wymagającym środowisku chmura znajduje swoje miejsce – choć sposób wdrożenia bywa bardziej złożony i dostosowany do specyfiki działalności.
Podejście polegało na tym, by rozpocząć migrację do chmury od środowiska hurtowni danych. Dlaczego właśnie od tego miejsca? Bo to tam znajdują się wszystkie możliwe typy danych – od najprostszych po najbardziej wrażliwe. Budując chmurową architekturę pod kątem hurtowni danych, tworzy się kompletne środowisko: od konfiguracji bezpieczeństwa, przez tzw. landing zone, aż po pełną zgodność z wymaganiami regulacyjnymi. Jeśli uda się przenieść hurtownię danych, oznacza to, że najtrudniejsze elementy są już wdrożone, a cała reszta – inne systemy i aplikacje – może być stopniowo przenoszona, bo każda kategoria danych jest już właściwie obsługiwana w chmurze.
Było to podejście odważne, ale skuteczne. W rozmowie z szefem tej organizacji padło bardzo trafne podsumowanie. Porównał to do zbudowania autostrady do chmury. I ta autostrada rzeczywiście się sprawdziła.
Czyli można powiedzieć, że dzisiaj wiele firm od razu decyduje, że dane w całości będą przetwarzane w chmurze i ma już zaufanie do takiego środowiska?
W przeszłości wiele firm podchodziło do chmury ostrożnie, zaczynając od systemów niekrytycznych. Chodziło nie tylko o kwestie związane z danymi, ale także o sprawdzenie kompetencji zespołu i upewnienie się, że można zapewnić w chmurze takie same parametry niefunkcjonalne jak w znanym i kontrolowanym środowisku lokalnym – na przykład odpowiednią wydajność i dostępność aplikacji.
Dziś sytuacja wygląda już inaczej. Firmy, zwłaszcza duże, mają doświadczenie, wypracowane standardy i konkretne zasady projektowania oraz wdrażania rozwiązań w środowiskach chmurowych. Chmura nie jest już czymś nowym czy nieznanym. Ten etap mamy zdecydowanie za sobą.
Często w przypadku chmury pojawia się jednak obawa o to, co stanie się, jeśli firma zdecyduje się z niej zrezygnować. Czy w takiej sytuacji pojawiają się problemy z przeniesieniem danych do innego dostawcy?
W tej kwestii warto spojrzeć z trzech perspektyw: technicznej, kontraktowej i regulacyjnej. Najważniejsza zasada jest taka, że korzystając z usług Google Cloud, klient pozostaje właścicielem swoich danych. My nie wykonujemy żadnych operacji na danych, które nie zostały nam wyraźnie zlecone przez klienta.
Kontraktowo gwarantujemy również, że dane można w każdej chwili pobrać z chmury i że po zakończeniu współpracy, w określonym czasie, zostaną one całkowicie usunięte z naszej infrastruktury. Proces ten jest nie tylko uregulowany w umowie, ale także wsparty odpowiednimi certyfikacjami. Oznacza to, że pełna kontrola nad danymi pozostaje po stronie klienta.
Pojawia się też pytanie, co w sytuacji, gdy klient chce zrezygnować z usługi – na przykład dlatego, że zmieniły się warunki albo oferta przestała odpowiadać jego potrzebom. Tego rodzaju obawy, związane z tzw. vendor lock-in, znamy przede wszystkim ze środowisk on-premise, a nie z chmury, choć oczywiście poważni klienci zawsze biorą takie ryzyko pod uwagę. W naszym przypadku kluczowe znaczenie mają wspomniane już gwarancje kontraktowe, ale również fakt, że opieramy się na otwartych technologiach – takich jak Kubernetes – które umożliwiają klientowi elastyczne przenoszenie środowisk, jeśli tylko pojawi się taka potrzeba.
Opracowanie prostego i realistycznego planu wyjścia z chmury jest jak najbardziej możliwe, a w przypadku niektórych branż, na przykład instytucji finansowych, wręcz wymagane przez regulacje. Klient, decydując się na korzystanie z technologii chmurowych, zobowiązany jest do przygotowania takiego planu i w praktyce często wspieraliśmy instytucje regulowane w jego tworzeniu. Taki plan uwzględnia zarówno kwestie technologiczne, jak i kontraktowe.
Można więc powiedzieć, że Google Cloud nie tylko nie utrudnia przejścia do innego dostawcy, ale nawet w tym pomaga?
W przypadku planu wyjścia istotne są zapisy umowy i gwarancje, które pozwalają przygotować scenariusz odejścia od danego dostawcy w sposób uporządkowany i wykonalny. Warto podkreślić, że choć plany tego typu istnieją, są przetestowane i możliwe do wdrożenia, to w praktyce jeszcze nie spotkałem się z sytuacją, w której klient rzeczywiście musiałby taki plan uruchomić z powodu problemów ze współpracą czy niezadowolenia z technologii Google Cloud.
Bezpieczeństwo a dane w chmurze
Chmura musi być bezpieczna. Obecnie firmy borykają się z dużą ilością przeróżnych cyberataków, a skala ta tylko rośnie. Czy są jakieś trzy-cztery najważniejsze zabezpieczenia, która musi oferować chmura?
Trudno mi jednoznacznie wskazać trzy czy cztery najważniejsze zabezpieczenia. W praktyce nie da się tego tak łatwo sklasyfikować, bo bezpieczeństwo w chmurze to nie jest zbiór pojedynczych narzędzi, tylko całościowe podejście. Jeśli spojrzy Pan na dostępne dane — polecam chociażby Cloud Vulnerability Database — to zauważy Pan, że nasza chmura, w zależności od tego, z kim ją porównujemy, mado 60 proc. mniej krytycznych podatności niż konkurencja. To nie jest przypadek.
Bezpieczeństwo w Google to element naszej kultury i filozofii działania. Chmura to tylko jeden z naszych obszarów biznesowych, ale równocześnie odpowiadamy za bezpieczeństwo ogromnej części globalnego internetu. Obsługujemy miliardy użytkowników w naszych usługach, więc kwestie bezpieczeństwa są fundamentalne. Nie tworzymy produktów, a dopiero potem zastanawiamy się, jak je zabezpieczyć. Bezpieczeństwo jest u nas uwzględniane od samego początku, na każdym etapie projektowania i działania.
Bezpieczeństwo to w Google fundament, bez którego nie zaczynamy pracy nad żadnym rozwiązaniem. Już na wczesnym etapie przeprowadzamy modelowanie zagrożeń, a każda usługa powstaje w oparciu o zaawansowaną analizę bezpieczeństwa i prywatności danych. To standard, który stosujemy od wielu lat – zanim stał się popularny w innych firmach, nawet tych zaawansowanych technologicznie.
Czy może Pan podać jakiś przykład?
Przykładem może być proces tworzenia oprogramowania. Zanim cokolwiek trafi na produkcję, przechodzi dokładnie zdefiniowane ścieżki testów i kontroli, w środowiskach, które są w pełni kontrolowane przez nas. Wykorzystujemy tzw. autoryzację binarną, czyli mechanizm, który pozwala dokładnie sprawdzić, czy dany kod pochodzi z zaufanego źródła i przeszedł wymagane etapy weryfikacji. To część naszej dbałości o łańcuch dostaw – obszar, który od lat traktujemy z najwyższą uwagą.
W naszych centrach danych nie używamy też seryjnego sprzętu od zewnętrznych dostawców. Każdy element infrastruktury powstaje na bazie naszych własnych projektów. Po wyprodukowaniu sprzęt jest dodatkowo sprawdzany, a my wprowadzamy dodatkowe mechanizmy kontrolne – na przykład kontrolę poprawności procesu uruchomienia serwera już na poziomie firmware’u, czyli najniższego poziomu oprogramowania uruchamianego zaraz po włączeniu zasilania.
Jeśli na naszym sprzęcie w centrum danych wykryjemy, że firmware został zmieniony, nie jest zgodny z oczekiwaną wersją albo nie został „podpisany” przez nas, serwer po prostu się nie uruchomi. Dzieje się tak dlatego, że stosujemy specjalne układy, które weryfikują integralność zarówno elementów sprzętowych, jak i podstawowego oprogramowania.
Proszę jeszcze powiedzieć, co ma najważniejsze znaczenie z perspektywy nie dostawcy, ale użytkownika chmury. Jak firma, która korzysta z chmury, powinna dbać o bezpieczeństwo po swojej stronie?
To, co mogę powiedzieć na dziś, to fakt, że w przypadku naszej chmury nie obserwujemy wyrafinowanych metod ataków. Zdecydowana większość incydentów bezpieczeństwa w środowiskach chmurowych dotyczy dwóch głównych obszarów. Pierwszym z nich jest tożsamość – chodzi o słabe hasła, ich całkowity brak, brak uwierzytelnienia dwuskładnikowego albo wykorzystanie danych uwierzytelniających przejętych przez atakujących. To pozwala cyberprzestępcom uzyskać dostęp do zasobów w chmurze.
Warto jednak zaznaczyć, że w przypadku dużych organizacji, które mają wysoką świadomość w zakresie bezpieczeństwa, tego typu sytuacje zdarzają się rzadko.
Drugim obszarem są podatności, ale nie w samej infrastrukturze chmurowej, tylko w aplikacjach i systemach, które klienci uruchamiają w chmurze. Chodzi na przykład o oprogramowanie zawierające luki bezpieczeństwa – mówiąc potocznie: „z dziurami”, które mogą zostać wykorzystane przez atakujących do przejęcia zasobów.
Wygląda na to, że obecnie trudno o argumenty, by nie działać w chmurze.
Jeśli ktoś jeszcze nie zdecydował się na przejście do chmury i ma obawy związane z przetwarzaniem danych, zwłaszcza danych wrażliwych, lub z wymogami regulacyjnymi, powinien mieć świadomość, że dostawcy chmurowi – w szczególności Google Cloud – zainwestowali ogromne środki, by umożliwić firmom z całej Unii Europejskiej bezpieczne i zgodne z przepisami korzystanie z chmury publicznej. Jesteśmy w stanie spełnić większość wymagań dotyczących przechowywania i przetwarzania danych, również tych najbardziej wrażliwych.
To nie są tylko deklaracje. Zapewniamy wysoki poziom transparentności – nasi klienci mają możliwość weryfikowania zgodności poprzez dostęp do certyfikacji, a w przypadku dużych firm także poprzez przeprowadzanie audytów. Dlatego nie ma realnych powodów, by rezygnować z rozwiązań chmurowych z obawy o kwestie związane z suwerennością cyfrową – te zagadnienia można skutecznie zaadresować.
Z praktycznego punktu widzenia warto pamiętać, że podstawą bezpieczeństwa w chmurze jest odpowiednie zarządzanie tożsamością. Kluczowe jest stosowanie silnego uwierzytelniania, w tym drugiego składnika uwierzytelniającego oraz pełna świadomość, kto i na jakich zasadach ma dostęp do środowiska chmurowego. To fundament skutecznej ochrony.
Artur Kuliński jest członkiem zespołu specjalistów cyberbezpieczeństwa EMEA w Google. Poza pracą w obszarze produktów Google Cloud Security zaangażowany jest także jako ekspert merytoryczny w realizowane przez Google programy związane z edukacją i poprawą świadomości w zakresie cyberbezpieczeństwa. Z branżą IT jest związany zawodowo od ponad 20 lat, podczas których pracował jako programista, projektant, architekt i manager. Ukończył Wydział Elektroniki i Technik Informacyjnych PW oraz uzyskał dyplom MBA w Szkole Biznesu Politechniki Warszawskiej.
