model współdzielonej odpowiedzialności

Model współdzielonej odpowiedzialności (shared responsibility model) to podział obowiązków bezpieczeństwa między dostawcę chmury albo hostingu a klienta. AWS ujmuje go formułą: dostawca odpowiada za bezpieczeństwo „chmury”, a klient za bezpieczeństwo „w chmurze” ^[1]. Dostawca chroni sprzęt, sieć, obiekty i warstwę wirtualizacji; klient chroni to, co w tej infrastrukturze umieszcza i konfiguruje ^[1]. Microsoft zaznacza, że we wszystkich typach wdrożeń klient pozostaje właścicielem swoich danych i tożsamości ^[2].

Jak działa

Linia podziału zależy od rodzaju usługi. NIST w definicji chmury obliczeniowej z września 2011 roku wyróżnia trzy modele usług: SaaS, PaaS i IaaS ^[4]. Im wyżej w stosie sięga usługa, tym więcej warstw przejmuje dostawca. Google opisuje to tak: w IaaS większość obowiązków ma klient, w PaaS dostawca odpowiada za więcej kontroli, a w SaaS przejmuje większość obowiązków ^[3]. Kylos dodaje, że zakres odpowiedzialności klienta wynika z jego wyborów: usług, środowiska i obowiązujących przepisów ^[7].

Microsoft opisuje trzy modele z punktu widzenia klienta. W IaaS klient zarządza maszynami wirtualnymi, systemami operacyjnymi i aplikacjami; w PaaS wdraża aplikacje bez zarządzania maszynami i systemem; w SaaS korzysta z gotowych aplikacji ^[2]. AWS pokazuje tę różnicę na własnych usługach. Klient serwerów wirtualnych EC2 wykonuje całą konfigurację bezpieczeństwa swoich instancji, łącznie z aktualizacjami systemu gościa ^[1]. W usługach zarządzanych, takich jak magazyn S3, dostawca obsługuje infrastrukturę i system operacyjny, a klient zarządza danymi, ich szyfrowaniem, klasyfikacją zasobów i uprawnieniami w narzędziach IAM ^[1]. Kylos opisuje ten sam podział po polsku: przy EC2 klient odpowiada za system operacyjny, oprogramowanie i zapory w instancjach ^[7].

Warstwy stosu, od najniższej do najwyższej, pokazuje schemat poniżej.

RYS. 1Warstwy stosu a podział odpowiedzialności

Microsoft publikuje macierz odpowiedzialności dla swoich usług ^[2]. Wybrane wiersze:

Obowiązki klienta

Niezależnie od modelu Microsoft zostawia klientowi cztery obszary: dane (klasyfikacja, ochrona, decyzje o szyfrowaniu), urządzenia końcowe, konta użytkowników oraz zarządzanie dostępem, w tym RBAC, uwierzytelnianie wieloskładnikowe i dostęp warunkowy ^[2]. Google także wskazuje, że klient zawsze odpowiada za polityki dostępu i dane, które postanowi przechowywać ^[3].

Niektóre obowiązki są naprawdę wspólne. AWS podaje przykład poprawek: dostawca łata infrastrukturę, a klient system gościa i aplikacje ^[1]. W IaaS klient sam konfiguruje zasady zapory grup zabezpieczeń ^[1], czyli swoją zaporę sieciową.

W WordPressie

Ten sam podział obowiązuje na hostingu WordPressa. Podręcznik utwardzania WordPressa mówi wprost: firmy hostingowe często odpowiadają za infrastrukturę, na której działa strona, ale nie za aplikację, którą właściciel postanowi zainstalować ^[5]. Po stronie właściciela zostają więc zwykle:

• aktualizacje rdzenia, wtyczek i motywów; podręcznik przypomina, że starsze wersje WordPressa nie dostają poprawek bezpieczeństwa ^[5];
• konta administratorów, ich hasła i drugi składnik logowania ^[5];
• kopie zapasowe i plan ich odtworzenia, jeśli umowa hostingowa nie mówi inaczej;
• konfiguracja wtyczek i uprawnień użytkowników.

Na hostingu współdzielonym podział ma dodatkową słabość. Podręcznik ostrzega, że gdy zostanie przejęta inna strona na tym samym serwerze, strona właściciela też może paść ofiarą ataku, nawet jeśli przestrzegał wszystkich zaleceń ^[5]. Izolacja kont na serwerze jest tu obowiązkiem dostawcy, a jej brak prowadzi do cross-site contamination.

Współdzielony los

Google rozwija model w kierunku, który nazywa współdzielonym losem (shared fate). Obejmuje on budowanie i utrzymywanie przez dostawcę zaufanej platformy dla obciążeń klienta oraz stałe partnerstwo w podnoszeniu bezpieczeństwa ^[3]. Nie zmienia to podziału podstawowego: klient nadal odpowiada za kontrolę dostępu i dane ^[3]. Microsoft zwraca uwagę na drugą stronę medalu. We własnej serwerowni typowe zaniedbania to opóźnione poprawki, słabe zabezpieczenia fizyczne, niepełne monitorowanie sieci, przestarzały sprzęt i nieprzetestowane kopie zapasowe; część tych obowiązków przejmuje dostawca chmury ^[2].

Zagrożenia i skutki

Najczęstszy błąd to założenie, że skoro usługa jest „w chmurze”, dostawca chroni wszystko. Google zauważa, że wiele naruszeń bezpieczeństwa w chmurze wynika bezpośrednio z błędnej konfiguracji ^[3], czyli z błędnej konfiguracji chmury po stronie klienta. Zaznacza też, że obowiązki przy obsłudze incydentów nie dają się łatwo rozdzielić i wymagają ścisłej współpracy ^[3].

Historia i przykłady

Kampania grupy UNC5537 z 2024 roku pokazuje, gdzie przebiega granica. Mandiant 10 czerwca 2024 roku opisał kradzież danych z instancji klientów Snowflake ^[6]. Śledztwo nie znalazło dowodów, że dostęp wynikał z włamania do środowiska Snowflake; każdy zbadany incydent prowadził do skradzionych danych uwierzytelniających klientów ^[6]. Dane logowania pochodziły głównie z kampanii infostealerów na komputerach spoza Snowflake ^[6]. Przejęte konta nie miały włączonego MFA, hasła nie były zmieniane czasem przez lata, a instancje nie miały list dozwolonych adresów sieciowych ^[6]. Mandiant i Snowflake powiadomiły około 165 organizacji, a co najmniej 79,7% użytych kont miało wcześniej ujawnione dane logowania ^[6]. Wszystkie trzy zabezpieczenia, których zabrakło, leżą po stronie klienta; ocenę takich zależności obejmuje zarządzanie ryzykiem dostawców.