To najbardziej znany diagram w chmurze obliczeniowej. Widziałeś go na każdym kursie certyfikacyjnym AWS, w każdym whitepaperze Azure i w każdym pakiecie onboardingowym Google Cloud. „Model współodpowiedzialności” ma być umową dżentelmeńską, która utrzymuje internet w ruchu: dostawca chmury zabezpiecza chmurę, a ty zabezpieczasz to, co do niej wkładasz.
Proste, prawda?
Dlaczego więc tak wiele naruszeń bezpieczeństwa zdarza się dokładnie na tym styku?
Rzeczywistość jest taka, że choć diagram jest prosty, wykonanie bywa chaotyczne. Granica między „ich obowiązkiem” a „naszym obowiązkiem” jest często bardziej rozmyta, niż sugeruje slajd PowerPoint. Gdy zespoły inżynieryjne źle rozumieją, gdzie zaczyna się ich odpowiedzialność, pozostawiają ogromne, niewidoczne luki w obronie. Zwykle nie wynika to ze złej woli ani niekompetencji, lecz z założeń. A w bezpieczeństwie założenia są matką wszystkich wycieków danych.
Zawartość strony
Mit usług „zarządzanych”
Największą pułapką, w którą wpadają zespoły, jest słowo „zarządzane”.
Gdy dostawca chmury oferuje zarządzaną usługę bazy danych (taką jak RDS czy Cloud SQL), łatwo założyć, że „zarządzane” oznacza „zabezpieczone”. Dostawca zajmuje się łatkami systemu operacyjnego, awariami sprzętu i dostępnością sieci. Nie zajmuje się jednak kontrolą dostępu do danych.
Jeśli uruchomisz zarządzaną bazę danych i pozostawisz grupę zabezpieczeń otwartą na 0.0.0.0/0 (cały internet), nie jest to wina dostawcy. To błąd konfiguracji po twojej stronie granicy.
Nieporozumienie polega na przekonaniu, że przejście na Platform as a Service (PaaS) zwalnia z obowiązków związanych z bezpieczeństwem. W rzeczywistości jedynie przesuwa punkt ciężkości. Być może nie musisz już łatać jądra Linuksa, ale musisz rygorystycznie zarządzać rolami IAM. Jeśli tego zaniedbasz, nie zlecasz bezpieczeństwa na zewnątrz — porzucasz je.
Aby lepiej zrozumieć te niuanse, Cloud Security Alliance (CSA) oferuje doskonałe ramy opisujące, jak odpowiedzialności przesuwają się między modelami SaaS, PaaS i IaaS.
Luka konfiguracyjna
Dostawcy chmury sprzedają w istocie surowce. Dają ci cegły, zaprawę i działkę. Obiecują, że grunt się nie zapadnie, a cegły nie skruszeją. Ale jeśli zbudujesz dom bez drzwi wejściowych, to twoja odpowiedzialność.
To właśnie „luka konfiguracyjna”. Większość współczesnych naruszeń w chmurze nie wynika z tego, że haker złamał algorytmy szyfrowania AWS. Dzieją się dlatego, że koszyk S3 został pozostawiony jako publiczny albo klucz API został na stałe zapisany w repozytorium GitHub.
Gartner słynnie przewidział, że do 2025 roku 99% awarii bezpieczeństwa w chmurze będzie winą klientów. To porażająca statystyka. Pokazuje, że narzędzia dostarczane przez dostawców chmury są solidne, lecz sposób ich wdrażania przez użytkowników bywa wadliwy.
Zespoły często mylą ustawienia domyślne. Usługi chmurowe priorytetowo traktują łatwość użycia. Domyślne opcje są często ustawione na „zezwalaj”, aby zmniejszyć tarcie podczas konfiguracji. Jeśli zespół uznaje konfigurację domyślną za bezpieczną, podatność już istnieje.
Shadow IT i problem „Click-Ops”
Model współodpowiedzialności zakłada scentralizowaną kontrolę. Zakłada, że organizacja wie o każdym posiadanym zasobie. Ale chmura jest elastyczna. Programista może uruchomić nowe środowisko kartą kredytową w pięć minut.
To „Shadow IT” całkowicie omija model współodpowiedzialności, ponieważ zespół bezpieczeństwa nawet nie wie, że istnieje odpowiedzialność do podziału.
Jeśli programista uruchomi serwer testowy w prywatnym regionie, by sprawdzić nową funkcję, i zapomni go wyłączyć, serwer ten technicznie podlega parasolowi odpowiedzialności organizacji. Ponieważ jednak nie został wdrożony przez właściwe kanały bezpieczeństwa chmury, pozostaje niezałatany, niemonitorowany i podatny na przejęcie.
Zespoły muszą odejść od „Click-Ops” (ręcznego klikania w konsolach) na rzecz „Infrastructure as Code” (IaC). Gdy infrastruktura jest definiowana w kodzie (np. Terraform lub CloudFormation), polityki bezpieczeństwa można egzekwować automatycznie przed wdrożeniem. Nie da się zabezpieczyć tego, czego nie widać, a IaC czyni infrastrukturę widoczną.
Tożsamość: nowy perymetr
W starym świecie lokalnych centrów danych bezpieczeństwo opierało się na zaporach. Budowało się zamek i fosę. W chmurze nie ma fosy. Perymetrem jest tożsamość.
Zespoły często nie zdają sobie sprawy, że w modelu współodpowiedzialności zarządzanie tożsamością i dostępem (IAM) w 100% leży po stronie klienta. Dostawcy chmury bez problemu wyegzekwują każdą politykę, jaką napiszesz — nawet jeśli brzmi ona „pozwól wszystkim na wszystko”.
Błąd polega na przenoszeniu starego sposobu myślenia. Zespoły tworzą klucze administratora „God Mode” dla wygody lub współdzielą poświadczenia między usługami. W chmurze liczy się granularność. Zasada najmniejszych uprawnień nie jest tylko dobrą praktyką; to jedyna rzecz, która powstrzymuje przejętą aplikację webową przed skasowaniem całych kopii zapasowych bazy danych.
Jeśli nie audytujesz regularnie ról IAM, nie wywiązujesz się ze swojej części umowy.
Zamykanie luki
Jak więc przestać robić to źle?
- Mapuj teren: nie polegaj na ogólnym schemacie. Stwórz konkretną macierz odpowiedzialności dla swojego stosu. Jeśli używasz Kubernetesa, jasno określ, kto łata węzły, a kto aktualizuje pody.
- Automatyzuj zgodność: ludzie są słabi w sprawdzaniu 500 ustawień konfiguracyjnych. Używaj narzędzi, które automatycznie skanują środowisko chmurowe według benchmarków takich jak CIS Benchmarks.
- Zmień sposób myślenia: przestań traktować dostawcę chmury jak ochroniarza. Traktuj go jak właściciela budynku. Zamykają główne drzwi na noc, ale to ty odpowiadasz za zamknięcie drzwi do swojego mieszkania.
Podsumowanie
Model współodpowiedzialności nie jest tarczą; jest kontraktem. Określa zasady gry. Gdy zespoły traktują chmurę jak magiczne pudełko, które samo zajmuje się bezpieczeństwem, łamią ten kontrakt.
Zrozumienie, że „zarządzane” nie oznacza „zabezpieczone”, uznanie zagrożeń wynikających z błędnej konfiguracji oraz traktowanie tożsamości jako nowego perymetru pozwala zespołom wreszcie wywiązać się ze swojej części umowy. Chmura jest bezpieczna — ale tylko wtedy, gdy ty wykonasz swoją część.
