Model współodpowiedzialności: IaaS, PaaS, SaaS

Usługi chmurowe są dostarczane w trzech podstawowych modelach, z których każdy oferuje inny poziom abstrakcji. Infrastructure as a Service (IaaS) zapewnia surowe zasoby obliczeniowe, pamięć masową i sieć. Platform as a Service (PaaS) dodaje system operacyjny, oprogramowanie pośredniczące i środowiska uruchomieniowe. Software as a Service (SaaS) udostępnia w pełni funkcjonalne aplikacje przez internet. Zrozumienie tych modeli jest kluczowe, ponieważ zakres odpowiedzialności za bezpieczeństwo znacznie się między nimi różni.

Model współdzielonej odpowiedzialności określa, które zadania związane z bezpieczeństwem należą do dostawcy chmury, a które do klienta. Model ten często podsumowuje się następująco: dostawca odpowiada za bezpieczeństwo chmury (fizyczne centra danych, hypervisory, infrastrukturę sieciową), natomiast klient odpowiada za bezpieczeństwo w chmurze (dane, zarządzanie dostępem, bezpieczeństwo aplikacji i konfigurację). Niezrozumienie tej granicy jest jedną z głównych przyczyn incydentów bezpieczeństwa w chmurze.

W modelu IaaS klient przejmuje największą część odpowiedzialności za bezpieczeństwo. Dostawca chmury zabezpiecza infrastrukturę fizyczną, hypervisor i szkielet sieci. Klient odpowiada za: instalację, aktualizowanie i wzmacnianie zabezpieczeń systemu operacyjnego; konfigurację środowiska uruchomieniowego i oprogramowania pośredniczącego; bezpieczeństwo aplikacji; reguły grup zabezpieczeń sieciowych; zasady IAM i zarządzanie użytkownikami; szyfrowanie danych w spoczynku i podczas przesyłania; oraz konfigurację zgodności. IaaS zapewnia maksymalną kontrolę, ale wymaga również największego nakładu pracy na rzecz bezpieczeństwa.

W modelu PaaS dostawca przejmuje zarządzanie systemem operacyjnym i środowiskiem uruchomieniowym. Klient nie aktualizuje już systemu operacyjnego ani nie zarządza oprogramowaniem pośredniczącym — zajmuje się tym dostawca. Klient nadal odpowiada jednak za: bezpieczeństwo kodu aplikacji (brak SQLi, XSS itp.), klasyfikację i szyfrowanie danych, zarządzanie tożsamością i dostępem, konfigurację aplikacji (zmienne środowiskowe, zarządzanie sekretami) oraz bezpieczeństwo interfejsów API. PaaS przenosi część obciążeń na dostawcę, pozwalając klientom skupić się na logice aplikacji.

W modelu SaaS dostawca zarządza niemal wszystkim. Główne obowiązki klienta w zakresie bezpieczeństwa to: zarządzanie dostępem (kto ma konta, egzekwowanie MFA, przegląd uprawnień), zarządzanie danymi (jakie dane są przesyłane i jak długo są przechowywane), bezpieczeństwo konfiguracji (ustawienia prywatności, uprawnienia udostępniania, integracje z usługami innych firm) oraz zgodność z zasadami dopuszczalnego użycia. Wiele przypadków naruszenia bezpieczeństwa SaaS wynika z nieprawidłowo skonfigurowanych ustawień udostępniania lub nadmiernych uprawnień aplikacji innych firm, a nie z awarii po stronie dostawcy.

Niektóre mechanizmy kontroli są współdzielone przez dostawcę i klienta. Przykładem jest szyfrowanie: dostawca chmury może oferować usługi szyfrowania (KMS, szyfrowanie domyślne), ale klient musi je włączyć, skonfigurować zarządzanie kluczami i wybrać odpowiednie algorytmy. Podobnie jest z tożsamością: dostawca udostępnia narzędzia IAM, ale klient musi skonfigurować zasady minimalnych uprawnień i wymusić MFA. Założenie, że dostawca obsługuje współdzielony mechanizm kontroli, i pominięcie jego konfiguracji to częsty i niebezpieczny błąd.

Model współodpowiedzialności najczęściej zawodzi z powodu błędnej konfiguracji po stronie klienta, a nie awarii dostawcy. Klasyczne przykłady to: zasobniki S3 pozostawione jako publicznie dostępne (wyciek Capital One z 2019 r., ujawniono 100 mln rekordów), nadmiernie liberalne role IAM umożliwiające eskalację uprawnień, grupy zabezpieczeń z regułami przychodzącymi 0.0.0.0/0 na wrażliwych portach oraz niezmienione dane uwierzytelniające w bazach danych wdrożonych w chmurze. Infrastruktura bazowa dostawcy była bezpieczna, ale konfiguracja klienta już nie.

Kluczowym wyzwaniem w modelu współodpowiedzialności jest widoczność. W środowiskach lokalnych zespoły ds. bezpieczeństwa kontrolują wszystkie dzienniki. W chmurze dzienniki infrastruktury dostawcy mogą być niedostępne. Klienci muszą włączyć natywne dla chmury usługi rejestrowania: AWS CloudTrail, Azure Monitor i GCP Cloud Audit Logs rejestrują wywołania API oraz zmiany konfiguracji. Bez włączenia tych usług organizacja nie ma śladu audytowego pokazującego, kto i co zrobił w jej środowisku chmurowym — powstaje poważna luka w zakresie zgodności i informatyki śledczej.

Gdy organizacje korzystają z dostawców zarządzanych usług (MSP) do obsługi środowisk chmurowych, odpowiedzialność dzieli się na trzy strony. Klient musi dopilnować, aby umowy (SLA i DPA) jasno określały obowiązki w zakresie bezpieczeństwa. Aplikacje chmurowe stron trzecich używane za pośrednictwem SaaS wprowadzają dodatkową złożoność: zgoda OAuth udzielona aplikacji o nadmiernych uprawnieniach daje jej dostęp do danych. Przeglądanie i regularne audytowanie zgód OAuth udzielonych stronom trzecim jest elementem higieny bezpieczeństwa SaaS.

Wymagania dotyczące zgodności z przepisami nie znikają tylko dlatego, że obciążenia przeniesiono do chmury. HIPAA wymaga zawarcia umowy Business Associate Agreement (BAA) z dostawcami chmury przetwarzającymi PHI — AWS, Azure i GCP oferują umowy BAA. PCI-DSS wymaga, aby środowisko chmurowe było objęte zakresem oceny; macierze współodpowiedzialności dostawców dokumentują, które mechanizmy kontroli PCI są spełnione. Organizacje muszą rozumieć, za co odpowiada dostawca, a co muszą wdrożyć samodzielnie, aby pomyślnie przejść audyty.

Model współodpowiedzialności ma znaczenie prawne. Warunki świadczenia usług dostawcy chmury oraz umowy SLA (Service Level Agreements) określają gwarancje dostępności i wyłączenia. Umowy powierzenia przetwarzania danych (DPA) zawierane na podstawie RODO definiują obowiązki podmiotu przetwarzającego. Jeśli dojdzie do naruszenia w wyniku awarii po stronie dostawcy, klient może dochodzić środków naprawczych na podstawie SLA. Jeśli naruszenie wynika z błędnej konfiguracji klienta, dostawca nie ponosi odpowiedzialności. Zrozumienie umów jest równie ważne jak zrozumienie technicznych mechanizmów kontroli.

W tej lekcji poznano: model współodpowiedzialności definiuje obowiązki dostawcy i klienta w zakresie bezpieczeństwa dla IaaS, PaaS i SaaS, klienci ponoszą największą odpowiedzialność za bezpieczeństwo w IaaS, a najmniejszą w SaaS, ale zawsze odpowiadają za zarządzanie dostępem i nadzór nad danymi oraz błędna konfiguracja po stronie klienta — a nie awaria dostawcy — jest główną przyczyną naruszeń bezpieczeństwa w chmurze. Następnie omówione zostaną bezpieczeństwo pamięci masowej w chmurze i zagrożenia związane z ujawnieniem danych.