Shared responsibility model & compliance

Dziś chciałbym opowiedzieć o współodpowiedzialności, która dość często nie jest rozumiana właściwie. No, bo jak to? Dostawca chmurowy przecież “powinien” odpowiadać za wszystko! Otóż - nie do końca.

Wyobraźmy sobie pewną sytuację…

Prowadzimy pojazd, nasze auto posiada wszystkie możliwe testy bezpieczeństwa, maksymalną ilość gwiazdek w testach zderzeniowych Euro NCAP, a mimo wszystko uderzyliśmy w inny pojazd i coś nam i naszym pasażerom się stało. Ktoś z boku zapyta od razu (pomijam mentalność narodową): jaka była prędkość pojazdu podczas zderzenia, jaka była pogoda i warunki na drodze, jaka była widoczność, co robił kierowca tuż przed zderzeniem, czy zareagował w czas. Wiele innych pytań, a ilość czynników rośnie. Można założyć, że jak zwykle była to nadmierna prędkość, bo przecież, gdyby pojazd się nie poruszał, do wypadku by nie doszło, prawda? Czy w takim razie za zaistniałą sytuację odpowiada producent auta? A może należałoby być mu wdzięcznym, że “tylko tyle” obrażeń mają pasażerowie?

Współodpowiedzialność w chmurze

Dostawca chmurowy daje nam podstawę, odpowiedni budynek, szybkie łącza, niezawodny sprzęt, gwarancję (*) naprawy w przypadku awarii. My jednak odpowiadamy za to, w jaki sposób wykorzystamy to, co od dostawcy chmurowego kupimy.

(*) gwarantuje nam uruchomienie rozwiązania, w przypadku awarii jego sprzętu. Nie należy tego mylić z wysoką dostępnością czy odpornością na awarię - to zupełnie inny temat.

Podstawowa odpowiedzialność

Wspomniałem już o sprzęcie, budynku etc. Do tego dochodzi oprogramowanie, które pozwala nam na budowanie różnych rozwiązań. Odnoszę się w tym momencie do Amazon Web Services (AWS), gdzie możemy na przykład zbudować wirtualną maszynę, będącą serwerem z preinstalowanym (zainstalowanym) systemem operacyjnym (Linux, Windows) - czyli usługa Elastic Compute Cloud tj. EC2. W praktyce ten zwrot: “wirtualna maszyna”, oznacza że została zbudowana na czymś “niewirtualnym”, czyli fizycznym sprzęcie. Właśnie za ten fizyczny sprzęt i możliwość uruchomienia Twojej wirtualnej maszyny odpowiada AWS. Żeby takie EC2 mogło działać, potrzebuje też oprogramowania, umieszczonego na tym fizycznym sprzęcie/serwerze (host) - za nie również odpowiada AWS. Ty jednak odpowiadasz za to, czy system operacyjny (Linux, Windows) będzie aktualizowany, czy będzie miał najnowsze poprawki; czy oprogramowanie, zainstalowane na tym systemie, będzie aktualne i wolne od błędów.

Skoro ten serwer działa, to pewnie działa w jakiejś sieci? Nie inaczej! Skoro tak, to jest chroniony przez dostępem osób niepowołanych? I tak, i nie; AWS odpowiada za to, żeby nikt nie dostał się fizycznie do serwera hosta. Również za to, by komunikacja pomiędzy Twoim serwerem a światem była możliwa zgodnie z Twoimi ustawieniami. Te ustawienia, to np. ustawienia zapory (firewall), która w przypadku AWS nazywa się Security Group, lub, nie wchodząc w szczegóły, Access Control List. To Ty odpowiadasz za to, czy dopuścisz ruch do swojego serwera, czy klient/użytkownik będzie w stanie się do niego dostać.

Dlatego też w podstawowym modelu, AWS odpowiada za część fizyczną i oprogramowanie do zarządzania Twoim wirtualnym serwerem. Ty natomiast odpowiadasz za to, jak jest on skonfigurowany, jakie oprogramowanie ma na sobie i kto ma do niego dostęp, jakie dane są na nim przechowywane, czy i jak są szyfrowane.

“Odpowiedzialność zmienną jest”

Skoro podstawową odpowiedzialność dostawcy mamy już za sobą, to jak się ona zmienia, skoro jest zmienna?

Patrząc z poziomu różnych usług jak np. IaaS, PaaS, SaaS, znając różnice pomiędzy nimi (jeśli nie wiesz, o czym piszę, zerknij tutaj), możemy się domyślić, że odpowiedzialność AWS rośnie wprost proporcjonalnie do serwisów, którymi zarządza.

IaaS

Ten przypadek został opisany powyżej, to właśnie podstawowa odpowiedzialność, do której zakwalifikować możemy IaaS.

PaaS

AWS dostarcza dla nas zarówno podstawę, jak i środowisko (system operacyjny) wykonujące nasz kod. My zaś dostarczamy aplikację i dane, dlatego też za nie, jak i dostęp do nich, odpowiadamy.

SaaS

W tym przypadku, AWS odpowiada również za dostarczoną aplikację. Dobrym przykładem jest tutaj usługa S3 (Simple Storage Service), w ramach której Amazon Web Services odpowiada za serwery, przestrzeń dyskową, wysoką dostępność (tutaj jest ona ogromna - 99,99%) czy też wytrzymałość/trwałość (ang. durability) na poziomie 99,999999999%. My jednak odpowiadamy za umieszczone tam dane (jako, że jest to serwis do składowania plików) oraz za to, kto i z jakimi uprawnieniami będzie miał do nich dostęp.

Ten serwis zbudowany jest na S3 - jako statyczna strona web.

Innym przykładem takiej usługi jest produkt firmy Microsoft - O365.

Jak widzisz, potrzebna jest wiedza na temat produktu/serwisu i połączonych z nim elementów, by móc we właściwy sposób zaprojektować usługę, którą będziesz świadczyć w chmurze w taki sposób, by była bezpieczna. By odpowiedzialność była w właściwy sposób rozłożona pomiędzy Tobą a dostawcą.

Gdybym zatrzymał się w tym momencie, pokazałbym tylko część prawdy.

Compliance - zgodność z…

Często jest tak, że musimy być zgodni z jakimiś normami, przepisami prawa itd. By to osiągnąć, wymaga się od nas (lub sami narzucamy sobie), że spełniamy jakieś wymagania i jesteśmy z nimi zgodni. Spróbujmy zobrazować to przykładem z życia wziętym.

Sytuacja liryczna

Budujemy sklep internetowy, który ma być stale dostępny. Niestraszny mu Black Friday, a płatności realizowane są elektronicznie za pomocą kart płatniczych.

W tym scenariuszu zauważamy co najmniej jeden aspekt, który musi być zgodny z konkretną regulacją ustaloną przez zewnętrzną instytucję. Tak, to płatności realizowane za pomocą kart płatniczych.

Wprawdzie to nie my jesteśmy odpowiedzialni za obsługę tych kart, jedynie wykorzystujemy mechanizmy (API) dostarczane przez operatora płatności kartami, jednakże dostawca musi być zgodny ze standardem PCI DSS. Standard ten reguluje aspekty związane z dostarczaniem takich rozwiązań, zarówno od strony formalnej, jak i budowy infrastruktury teleinformatycznej.

Mamy zatem pierwszy standard, w przypadku którego, jeśli dostawca płatności zdecyduje się na umieszczenie swojego rozwiązania w chmurze, będzie musiał wybrać dostawcę, który wspiera założenia tego standardu (AWS oczywiście posiada certyfikację, gwarantującą zgodność z tym, a także innymi standardami).

Wróćmy do naszego sklepu.

Skoro jesteśmy firmą z zasadami, mamy również własne obostrzenia, w których nasi dostawcy muszą spełniać pewne założenia. Powiedzmy, że każdy dostawca musi posiadać certyfikację ISO 27001 (znów: AWS takową posiada) itd.

Podsumowanie

Bezpieczeństwo chmury ma wiele warstw i stwierdzenie, że chmura jest bezpieczna, będzie tak samo błędne, jak i poprawne. Bowiem to, czy nasze rozwiązanie będzie bezpieczne w chmurze, zależy przede wszystkim od naszej świadomości, od tego, czy rozumiemy mechanizm działania współodpowiedzialności ( shared responsibility model). Czy potrafimy zbudować nasze rozwiązania w sposób wykorzystujący mechanizmy dostarczane przez dostawcę chmurowego w sposób bezpieczny, zgodny z najlepszymi praktykami?

Myślę, że warto sobie odpowiedzieć na pytanie, szczególnie w kontekście infrastruktury:

Dlaczego uważam, że zabezpieczę swoją serwerownię lepiej, niż firma, która utrzymuje się z dostarczania takich rozwiązań, a także buduje je na całym świecie?

AWS jest weryfikowany przez certyfikowane firmy audytorskie niemalże bez ustanku. Amazon Web Services jest zgodny z największą liczbą standardów bezpieczeństwa jak i certyfikacjami takimi jak: PCI-DSS, HIPAA/HITECH, FedRAMP, GDPR, FIPS 140-2, czy NIST 800-171.

Dajcie znać, co myślicie?

Źródła:

• Amazon Web Services,
• Microsoft Azure,

Obrazy: Unsplash, AWS, Trend Micro