„Dostawca” – mówią użytkownicy. „Użytkownicy” – mówi dostawca. Tymczasem sprawa zakresów odpowiedzialności za bezpieczeństwo jest bardziej skomplikowana, a prawda leży… po środku.
Odpowiednie zabezpieczenie środowiska przed niepowołanym dostępem to nie tylko kwestia ambicji działu IT, ale prawdziwe wyzwanie biznesowe. Włamania do firmowych zasobów przez nieupoważnione osoby i skutki takich sytuacji (na przykład utrata danych) oznaczają poważne straty finansowe. Według Cybersecurity Ventures globalne koszty związane z cyberprzestępczością będą rosnąć co roku o 15 procent przez najbliższe pięć lat, aż osiągną poziom 10,5 bln USD w 2025 roku.
Na wczesnym etapie rozwoju rynku cloud computing klienci obawiali się o bezpieczeństwo swoich danych. w tej chwili coraz więcej menedżerów IT decyduje się na przejście do chmury właśnie ze względu na jej wysoki poziom bezpieczeństwa. W ten sposób chcą zdjąć ze swojej agendy kwestię ochrony środowiska IT przed zagrożeniami. Kto w takim razie tak naprawdę odpowiada za bezpieczeństwo środowiska chmurowego?
„W praktyce zagwarantowanie bezpieczeństwa wymaga zaangażowania obu stron tego procesu, czyli zarówno dostawcy, jak i użytkownika rozwiązań chmurowych. Stopień zaangażowania poszczególnych stron wynika bezpośrednio z wybranego rodzaju usług cloud computing. W usługach chmurowych mamy bowiem do czynienia z modelem współdzielonej odpowiedzialności pomiędzy dostawcą i odbiorcą usług chmury publicznej. Model ten opisuje nie tylko zakres odpowiedzialności w kwestiach bezpieczeństwa danych i aplikacji, ale także bieżącego utrzymania systemów” – wyjaśnia Andrzej Nowodworski, senior security architect w Chmurze Krajowej.
Jak wyglądają zakresy odpowiedzialności w różnych modelach IT?
On-premise
Jeżeli wszystkie systemy w organizacji są używane w modelu on-premise, to sprawa jest bardzo prosta. Użytkownik odpowiada za każdy aspekt utrzymania, monitorowania i gwarancji bezpieczeństwa. Od zapewnienia zasilania, zabezpieczenia przed zniszczeniem (pożar, zalanie), poprzez infrastrukturę fizyczną, systemy operacyjne, na aplikacjach kończąc.
„To najbardziej pracochłonny dla klienta model, w którym cokolwiek się stanie (organizacja utraci dostęp do systemów, dane wyciekną lub zostaną zaszyfrowane), za wszystko odpowiada użytkownik” – tłumaczy Andrzej Nowodworski z Chmury Krajowej.
Migracja do chmury publicznej to stopniowe pozbywanie się tej odpowiedzialności przez użytkownika i przenoszenie jej na dostawcę usługi chmurowej. Im bardziej zaawansowana i komplementarna usługa, tym więcej odpowiedzialności spoczywa na dostawcy.
Infrastructure as a Service (IaaS)
Infrastruktura jako usługa oznacza możliwość wynajęcia infrastruktury w modelu subskrypcyjnym. W ramach usługi dostawca chmury publicznej zdejmuje z użytkownika odpowiedzialność za fizyczną część utrzymania środowiska IT. Nie trzeba martwić się o zasilanie, sprzęt, okablowanie, kontrolę dostępu, systemy monitoringu wizyjnego, firmę ochroniarską i inne aspekty związane z posiadaniem własnego data center.
„Wszystkie wspomniane aspekty są w obszarze odpowiedzialności dostawcy usługi chmurowej. Po stronie użytkownika pozostaje system operacyjny i wszystko to, co jest powyżej (bazy danych, aplikacje)” – wyjaśnia Andrzej Nowodworski.
Operatorzy chmur publicznych, w tym Chmura Krajowa, zapewniają najwyższe standardy zabezpieczenia centrów danych, w których zlokalizowany jest sprzęt. Co więcej, dzięki posiadaniu większej liczby centrów w różnych lokalizacjach (w przypadku dostawców globalnych – w różnych krajach) są oni w stanie zapewnić dostępność i bezpieczeństwo na poziomie zupełnie nieosiągalnym w modelu on-premise.
Platform as a Service (PaaS)
Inny model usług chmurowych to PaaS (platforma jako usługa). W kontekście bezpieczeństwa stanowi największe wyzwanie, ponieważ zakres odpowiedzialności między operatorem chmury publicznej a klientem jest tu definiowany w niejednolity sposób. Z pewnością jednak odpowiedzialność za system operacyjny, na którym uruchomiona jest platforma, spoczywa na dostawcy usług chmurowych.
„Przykładowo, jeżeli powołamy klaster Kubernetes, to nie będziemy ingerować w system operacyjny. Oczywiście jest on zainstalowany na serwerze i w niektórych przypadkach choćby można się do niego zalogować, ale jest to jednak niezalecane, właśnie z uwagi na fakt, iż odpowiedzialność za system operacyjny pozostaje po stronie dostawcy usługi chmurowej” – mówi Nowodworski.
Nad systemem operacyjnym są aplikacje, uprawnienia wraz ze strukturą projektu czy katalogu lub innego kontenera używanego u danego dostawcy usług chmurowych. I tutaj sprawa jest już niejednoznaczna, tzn. zależy od konkretnego dostawcy. Najlepszym rozwiązaniem jest weryfikacja u dostawcy danej platformy i ustalenie, za które z nich odpowiada on sam, a o które musimy zadbać my. Może też się okazać, iż w danym aspekcie faktycznie współdzielimy tę odpowiedzialność.
Na przykład dostawca chmury może nam automatycznie skonfigurować warstwę sieciową dla domyślnego wykorzystania danej platformy. W trakcie realizacji projektu może się jednak okazać, iż potrzebujemy bardziej zaawansowanej funkcjonalności, dla której częściowo sami zmieniamy konfigurację sieci. Wtedy faktycznie współdzielimy tę odpowiedzialność i musimy sobie z tego zdawać sprawę.
Dla przykładu – w usłudze Google Kubernetes Engine (GKE) to użytkownik decyduje o konfiguracji sieci. I to zarówno na styku pomiędzy klastrem GKE a innymi usługami czy Internetem, jak i wewnątrz klastra GKE. Użytkownik odpowiada także za odpowiednią alokację puli adresów IP na potrzeby wewnętrzne klastra (pody) i definiuje polityki sieciowe, które ograniczają ruch na przykład między podami. Ewentualny błąd może skutkować niedostępnością niektórych usług. Z drugiej strony nie trzeba martwić się o warstwę systemu operacyjnego czy samą konfigurację klastra. To wszystko dostarcza Google wraz z usługą GKE.
Software as a Service (SaaS)
Na koniec mamy usługę SaaS, czyli oprogramowanie jako usługę. Z punktu widzenia przenoszenia odpowiedzialności za utrzymanie i bezpieczeństwo jest to model najbardziej korzystny dla użytkownika. Odpowiedzialność zaczyna się dopiero od warstwy aplikacji, czyli dbamy o tożsamości i uprawnienia, dane, które przetwarzamy w aplikacji, oraz urządzenia klienckie (najczęściej stacje robocze pracowników), na których korzystają oni z danej usługi. Cała reszta, czyli serwery, system operacyjny, sieć, a także bezpieczeństwo samej aplikacji są po stronie dostawcy chmurowego.
„W modelu Software as a Service faktycznie dostawca usługi ma największą odpowiedzialność za obszar bezpieczeństwa, ale należy też zwrócić uwagę na pewne kwestie. Przykładowo: chociaż dostawcy usług chmurowych zapewniają backup danych, który gwarantuje nieprzerwaną dostępność danych, to warto jednak wiedzieć, iż są sytuacje, w których to rozwiązanie może nie być wystarczające” – tłumaczy Andrzej Nowodworski.
Chodzi o pomyłki użytkowników – przypadkowe skasowanie danych (plików tekstowych, e-maili, zdjęć itp.). W tym wypadku dostawca aplikacji w chmurze nie ponosi odpowiedzialności i nie będzie w stanie przywrócić skasowanych plików. Dlatego warto sprawdzić, czy aplikacja umożliwia stworzenie dodatkowego backupu – czy to dzięki innej, zewnętrznej usługi, czy w postaci lokalnie zapisanych plików i folderów. Szczególnie o ile w aplikacji przechowujemy dane krytyczne dla naszej organizacji.
W przypadku małych organizacji do usługi backupu w chmurze może wystarczyć choćby Dysk Google. Dla większych ilości danych bardziej opłacalne będzie wykorzystanie storage’u typu archive z Google Cloud. W usłudze Dysk Google można wykorzystać oficjalną aplikację Dysk Google, która ma wbudowaną opcję robienia backupu. jeżeli wykorzystujemy storage z Google, potrzebne są mechanizmy potrafiące wykonać backup na zdalnym nośniku danych. Co ciekawe, większość urządzeń typu NAS czy systemu tworzącego backup wspiera wykorzystanie storage’ów chmurowych.
Zakresy odpowiedzialności łatwiej zrozumieć, patrząc na poniższy schemat. Jak widać, są takie obszary, o które zawsze dba dostawca usług chmurowych i takie, o które zawsze dba użytkownik. Są też obszary, które w zależności od tego, w jakim modelu korzystamy z danej usługi, przechodzą płynnie pomiędzy klienta a dostawcę. Pamiętajmy więc o tym, aby w każdym przypadku określić, gdzie kończy się nasza odpowiedzialność i zadbać o to, co należy do nas.
Model współdzielonej odpowiedzialności w chmurach publicznychKlucz do bezpieczeństwa w chmurze: tożsamość
Zarządzanie tożsamością jest fundamentem bezpieczeństwa w chmurze publicznej. Ta kwestia zawsze leży w gestii klienta, dlatego nie lekceważmy jej i weryfikujmy, jakie mamy do dyspozycji opcje związane z bezpieczeństwem, bo dostawcy usług oferują różne modele autoryzacji. Tworząc środowisko IT wybierzmy te, które pogodzą wygodę użytkowania z zapewnieniem odpowiedniego poziomu bezpieczeństwa.
Tożsamość jest istotna w każdym systemie IT, ale w środowisku chmurowym jej utrata może być szczególnie dotkliwa. W przeciwieństwie do systemów on-premise, aplikacje w chmurze są ze sobą mocno zintegrowane – przeważnie jedno poświadczenie tożsamości umożliwia dojście do wielu systemów. Nieautoryzowany dostęp może zatem oznaczać utratę wielu cennych danych.
Oprócz modeli weryfikacji tożsamości i autoryzacji w chmurach publicznych mamy także dostępne inne narzędzia, choćby typu PIM (Privileged Identity Management) czy PAM (Privileged Access Management). Warto je poznać jeszcze przed migracją danych do chmury. Podobnie model „Zero Trust”, który coraz częściej stosowany jest w chmurach publicznych, oraz SDP, czyli Software Defined Perimiter – jedna z form implementacji modelu „Zero Trust”.
W Google Cloud oprócz tożsamości wykorzystywanej przez administratorów/devopsów istnieją tzw. konta serwisowe. Konta te wykorzystywane są głównie do automatyzacji i uwierzytelniania pomiędzy serwisami wewnątrz chmury. Dobrą praktyką jest niewykorzystywanie domyślnych kont serwisowych. Należy tworzyć takie konta z bardzo ograniczonymi uprawnieniami zgodnie z funkcją, którą dane konto ma pełnić. I tak w przypadku konta serwisowego wykorzystywanego w IaC na przykład na potrzeby powołania organizacji trzeba ograniczyć uprawnienia do niezbędnego minimum, czyli potencjalnie tylko do ustawiania polityki na poziomie organizacji, tworzenie folderów i projektów. Osobne konto z odrębnymi uprawnieniami będzie potrzebne do powoływania zasobów w konkretnym projekcie.
Zebraliśmy w tym artykule podstawowe informacje dotyczące odpowiedzialności za bezpieczeństwo danych i aplikacji w chmurze publicznej. Jednak przy złożonych projektach, na przykład związanych z zarządzaniem tożsamością w modelu multicloud, każdy przypadek jest nieco inny, wymaga indywidualnej analizy i rozwiązań. Dlatego warto skorzystać z wiedzy i doświadczenia ekspertów Chmury Krajowej, by dobrze przygotować się do migracji i skutecznie zadbać o bezpieczeństwo. Zapraszamy do współpracy.
Artykuł sponsorowany przez Chmurę Krajową.
