Shared responsibility model – za co odpowiada dostawca, a za co użytkownik chmury?

Bezpieczeństwo firmowych danych, systemów oraz aplikacji w chmurze publicznej to praca wspólna. Wymaga zaangażowania, zarówno po stronie dostawcy usług, jak i klienta. A kto za co w tym duecie odpowiada definiuje tzw. model współodpowiedzialności.

Dane korporacyjne w chmurze mogą stanowić łakomy kąsek dla cyberprzestępców. Pojedynczy wyciek danych może kosztować firmę nie tylko utratę reputacji. Tego typu zakłócenia w działalności dużych przedsiębiorstw powodują szkody liczone w setkach milionów, a nawet miliardach dolarów.

Najlepiej zabezpieczone środowisko chmurowe nie może zagwarantować w 100% bezpieczeństwa korporacyjnych danych, jeśli nie zrobi tego przedsiębiorca. Parafrazując, domu nie zabezpieczą nawet najlepsze drzwi i okna antywłamaniowe, jeśli sam właściciel pozostawi je uchylone.

Jak prognozują analitycy Gartnera, do 2025 roku nawet 99 proc. wszystkich incydentów bezpieczeństwa w chmurze będzie wynikać z błędów po stronie użytkownika. Na szczęście takim incydentom da się skutecznie zapobiegać. 

Biznes korzystający z usług chmury publicznej musi dobrze zrozumieć rolę, jaką ma do odegrania w zakresie bezpieczeństwa swoich danych przechowywanych w chmurze. Pomaga w tym model współodpowiedzialności.

Co to jest model współodpowiedzialności?

Każdy dostawca chmury publicznej ma swój własny model współodpowiedzialności (ang. shared responsibility model, w skrócie SRM). Wyznacza on sfery działalności, za które  bezpośrednio odpowiada usługodawca. Wskazuje ponadto zakres odpowiedzialności dla klienta korzystającego z danej usługi.

W telegraficznym skrócie: dostawca usług chmurowych jest odpowiedzialny za bezpieczeństwo samej chmury (OF THE CLOUD) i wszystkich oferowanych przez siebie rozwiązań. Odpowiedzialność za bezpieczeństwo swoich danych oraz aplikacji w chmurze (IN THE CLOUD) ponosi jej użytkownik. Sam może je sukcesywnie zwiększać, stosując się m.in. do dobrych praktyk w zakresie cyberbezpieczeństwa.

Warto od razu wspomnieć, że granica tej odpowiedzialności nie jest wyznaczona na stałe. Zależy m.in. od rodzaju usługi wybranej przez użytkownika chmury.

Pamiętaj, że o ile migracja do chmury stopniowo przenosi odpowiedzialność z firmy na dostawcę rozwiązania, o tyle biznes nigdy nie pozbywa się jej do końca. W zrozumieniu podziału obowiązków pomoże poniższy schemat.

Prześledźmy zatem granice odpowiedzialności dostawcy chmury i biznesu dla każdego rodzaju rozwiązań chmurowych (IaaS, PaaS i SaaS). Celowo pomijamy model on premise, kiedy firma w zasadzie nie korzysta z żadnych rozwiązań chmurowych. Ponosi wtedy pełną odpowiedzialność za zapewnienie bezpieczeństwa i monitoring własnej infrastruktury oraz przechowywanych aplikacji i danych.

Shared responsibility model w usłudze SaaS

W usłudze chmurowej bazującej na modelu SaaS (software as a service – oprogramowanie jako usługa) klient bierze odpowiedzialność wyłącznie za zawartość, udostępnianie jej innym użytkownikom oraz samo używanie danej aplikacji zgodnie z dobrymi praktykami. 

Przykładem aplikacji udostępnianej w modelu SaaS może być edytor tekstu online – Google Docs (Dokumenty Google). Odpowiedzialność za poprawne działanie wszystkich narzędzi i dostępność samego edytora spada na dostawcę usług chmurowych, czyli w tym wypadku Google.

Shared responsibility model w usłudze PaaS

Usługa chmurowa bazująca na modelu PaaS (platform as a service – platforma jako usługa) nakłada na użytkownika dodatkowe obowiązki. Według schematu dla usług Google Cloud dorzuca przykładowo odpowiedzialność za wdrożenie oraz bezpieczeństwo aplikacji webowej. 

Za przykład usługi dostępnej w Google Cloud Platform oferowanej w modelu PaaS może posłużyć App Engine. To środowisko developerskie i hostingowe do uruchamiania własnych aplikacji w chmurze publicznej Google. Widać wyraźnie, że to w gestii samego developera aplikacji pozostaje takie jej zabezpieczenie, aby skutecznie chronić użytkowników przed cyberatakami.

Shared responsibility model w usłudze IaaS

Najbardziej wymagającym uwagi klienta rozwiązaniem chmurowym jest usługa typu IaaS, przy której użytkownik przyjmuje na siebie m.in. zadanie opieki nad systemem operacyjnym i jego poprawnym działaniem, tożsamością, przechowywanymi danymi, autoryzacją dostępu oraz konfiguracją sieci.    

W Google Cloud Platform przykładem usługi oferowanej w modelu IaaS (infrastructure as a service – infrastruktura jako usługa) jest Compute Engine. To rozwiązanie umożliwiające tworzenie i uruchamianie maszyn wirtualnych bazujących na infrastrukturze Google.

Za co odpowiada dostawca chmury, a za co użytkownik?

W każdym z powyższych scenariuszy widać wyraźnie, że to zawsze użytkownik ponosi odpowiedzialność za bezpieczeństwo danych, które przechowuje w środowisku chmurowym. Do niego należy wypracowanie skutecznego mechanizmu ich zabezpieczenia, w tym kontroli dostępu do tych danych, na bazie udostępnianych przez dostawcę chmury rozwiązań.

W przypadku korzystania z usług o wyższym stopniu odpowiedzialności po stronie klienta (PaaS i IaaS), biznes musi też wziąć na siebie właściwą konfigurację wykorzystywanych rozwiązań chmurowych. Do niego należy m.in. kontrola autoryzacji dostępu dla innych użytkowników w firmie. 

Odpowiedzialność za kondycję i bezpieczeństwo samej infrastruktury w każdym przypadku spoczywa po stronie dostawcy usług chmurowych. O wielopoziomowej ochronie centrów danych Google dowiesz się więcej z poniższego klipu.

Jak zadbać o bezpieczeństwo firmowych danych w chmurze?

Skoro już wiemy, że dbałość o bezpieczeństwo danych w chmurze to praca zespołowa, jak możemy jako klienci/użytkownicy eliminować ryzyko cyberataków i utraty cennych informacji na skutek nieprzewidzianych zdarzeń losowych? Jeden z filarów stanowi tzw. disaster recovery plan, czyli plan odzyskiwania sprawności po awarii.

W ramach takiego planu definiuje się między innymi odpowiedzialność działów i osób w firmie, w zakresie kontroli dostępu do kluczowych danych oraz mechanizmów autoryzacji. Przewiduje się również dodatkowe poziomy zabezpieczeń w postaci kopii zapasowych i alternatywnych centrów danych (tzw. Disaster Recovery Center), w których dane będą przechowywane i regularnie aktualizowane.

Pamiętajmy też, że rozwiązania w zakresie bezpieczeństwa oferowane przez dostawców chmury publicznej są zwykle nieosiągalne dla modelu on premise. Rozproszona po całym świecie i dobrze skomunikowana sieć centrów danych jest dużo lepiej przygotowana na nieoczekiwane zdarzenia. Pomaga w tym również podział na strefy i regiony, w ramach których mogą działać wspomniane RDC.

Dowiedz się, czym jest i z czego powinien składać się Disaster Recovery Plan, czytając artykuł: Disaster Recovery Plan, czyli jak zachować dostępność aplikacji w obliczu awarii