Kto odpowiada za bezpieczeństwo danych i aplikacji w chmurze? To zależy od tego jaką usługę wykupimy i co zapewnia jej dostawca. Aby pomóc zrozumieć różne aspekty tego zagadnienia przygotowaliśmy przegląd dostępnych rozwiązań i odpowiadających im zakresów odpowiedzialności.
Wśród osób, które nie miały doświadczenia z rozwiązaniami chmurowymi można spotkać dwa skrajne podejścia do kwestii bezpieczeństwa chmury publicznej. Pierwsze to całkowity brak zaufania i negowanie wszystkich potencjalnych korzyści płynących z migracji do chmury publicznej, właśnie ze względu na brak bezpieczeństwa. Druga postawa to całkowita wiara w dostawców usług cloud computing i przekonanie, że wezmą na siebie pełną odpowiedzialność za ten obszar. Rzeczywistość nie jest tak zerojedynkowa i w praktyce dla zagwarantowania bezpieczeństwa wymaga zaangażowania, w różnych proporcjach 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 kwestii bezpieczeństwa 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. W tym tekście skupimy się na aspektach związanych z bezpieczeństwem przyjmując perspektywę użytkownika.
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 zapewnienia bezpieczeństwa. Od zapewnienia zasilania, zabezpieczenie przed zniszczeniem (pożar, zalanie), poprzez infrastrukturę fizyczną, systemy operacyjne, a na aplikacjach kończąc. Niedostępność systemów, włamanie hakerów, czy wyciek danych - odpowiedzialność jest po naszej stronie.
Migracja do chmury publicznej to stopniowe pozbywanie się tych odpowiedzialności i przenoszenie ich na dostawcę usługi chmurowej. Im bardziej zaawansowana i komplementarna usługa tym więcej odpowiedzialności spoczywa na dostawcy usług chmurowych, a mniej na naszych własnych barkach.
Infrastructure as a Service (IaaS)
Zacznijmy od najprostszej usługi chmurowej - IaaS. Infrastruktura jako usługa, czyli możliwość wynajęcia infrastruktury w modelu subskrypcyjnym. Co to oznacza? W ramach usługi dostawca chmury publicznej zdejmuje z nas 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).
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 danych w różnych lokalizacjach (w przypadku dostawców globalnych: w różnych krajach) są w stanie zapewnić dostępność i bezpieczeństwo, na poziomie zupełnie nieosiągalnym w modelu on-premise.
Platform as a Service (PaaS)
Kolejny model usług chmurowych to PaaS (platforma jako usługa). W kontekście bezpieczeństwa ta usługa stanowi największe wyzwanie, bo różne platformy definiują zakres odpowiedzialności między operatorem chmury publicznej a klientem w niejednolity sposób. Jedno jest pewne: odpowiedzialność za system operacyjny, na którym uruchomiona jest platforma spoczywa na dostawcy usług chmurowych. Przykładowo, jeśli powołamy klaster Kubernetes to nie będziemy ingerować w system operacyjny. Oczywiście jest on zainstalowany na serwerze i w niektórych przypadkach nawet można się do niego zalogować, ale jest to jednak niezalecane, właśnie z uwagi na fakt, że odpowiedzialność za system operacyjny pozostaje po stronie dostawcy usługi chmurowej.
Nad systemem operacyjnym są aplikacje, uprawnienia wraz ze strukturą projektu lub katalogu lub innego kontenera używanego u danego dostawcy usług chmurowych. I tutaj sprawa jest już niejednoznaczna, tzn. zależy od konkretnego dostawcy usług chmurowych. Najlepszym rozwiązaniem jest weryfikacja u dostawcy konkretnej platformy i ustalenie, za które z nich odpowiada dostawca, a o które musimy zadbać sami. Może też się okazać, że w danym aspekcie faktycznie współdzielimy tę odpowiedzialność.
Przykładowo: dostawca chmury może nam automatycznie skonfigurować warstwę sieciową dla domyślnego wykorzystania danej platformy. W trakcie realizacji projektu może się jednak okazać, że 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ę.
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 jak i 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ć jak i bezpieczeństwo samej aplikacji jest po stronie dostawcy chmurowego.
Należy jednak zwrócić uwagę, że chociaż dostawcy usług chmurowych zapewniają backup danych, który gwarantuje nieprzerwaną dostępność danych, to warto jednak wiedzieć, że są sytuacje, w których to rozwiązanie może nie być wystarczające. Mianowicie chodzi o pomyłki użytkowników - przypadkowe skasowanie danych (np. plików tekstowych, e-maili, zdjęć, itp.). W tym przypadku 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 z pomocą innej, zewnętrznej usługi, czy w postaci lokalnie zapisanych plików i folderów. Szczególnie, jeżeli w aplikacji przechowujemy dane krytyczne dla naszej organizacji.
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 i 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.
Tożsamość - klucz do bezpieczeństwa w chmurze
Bardzo istotną kwestią jest zarządzanie tożsamością w chmurze publicznej. To aspekt, który zawsze leży w gestii klienta. Dlatego nie lekceważmy go 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 ważna w każdym systemie IT, ale w środowisku chmurowym jej utrata jest szczególnie istotna. W przeciwieństwie do systemów on-premise aplikacje w chmurze są mocno zintegrowane ze sobą. Przeważnie jedno poświadczenie tożsamości umożliwia dostęp do wielu systemów. Nieautoryzowany dostęp może 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ą do chmury. Podobnie jak model “Zero Trust”, który coraz częściej stosowany jest w chmurach publicznych oraz SDP, czyli Software Defined Perimiter - jednej z form implementacji modelu “Zero Trust”. To ważny i zarazem obszerny wątek, dlatego poświęcimy mu osobny wpis na naszym blogu.
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 np. 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.
