Shared responsibility: dlaczego dostawca chmury nie zabezpiecza wszystkiego
Dostawca może chronić fizyczną infrastrukturę i platformę, a klient nadal odpowiadać za konta, dane, konfigurację i część monitoringu.
Jednym z najbardziej niebezpiecznych skrótów myślowych jest założenie, że skoro system działa u dużego dostawcy, bezpieczeństwo zostało całkowicie przeniesione na jego zespół. W chmurze odpowiedzialność jest dzielona.
Granica zależy od usługi
W IaaS klient zwykle kontroluje więcej warstw, więc ma też więcej obowiązków konfiguracyjnych. W SaaS dostawca zarządza większą częścią stosu, ale użytkownik nadal odpowiada za decyzje dotyczące tożsamości, ról, danych i integracji.
CISA opisuje shared responsibility jako konieczność jasnego zrozumienia zarówno obowiązków dostawcy, jak i klienta. W nowszych materiałach dotyczących systemów chmurowych podkreśla również znaczenie konfiguracji oraz widoczności potrzebnej do monitorowania zagrożeń.
Najczęstsze błędy pojawiają się na granicy
Jeżeli dostawca zakłada, że klient ograniczy dostęp do zasobu, a klient uważa, że zrobi to dostawca, powstaje luka. Podobnie jest z logowaniem zdarzeń, retencją danych czy kopiami. Technicznie obie strony mogą wykonywać swoje zadania poprawnie, a cały system nadal będzie źle zabezpieczony przez błędne założenia.
Umowa i dokumentacja są częścią architektury
Shared responsibility nie jest jedną uniwersalną tabelą. Konkretna usługa może inaczej dzielić odpowiedzialność za szyfrowanie, klucze, system operacyjny, kopie czy monitoring. Dlatego model trzeba czytać razem z dokumentacją i zakresem wykupionej usługi.
Najbardziej praktyczne pytanie brzmi nie „czy dostawca jest bezpieczny?”, lecz „za które ryzyka odpowiada dostawca, za które klient i gdzie odpowiedzialność jest wspólna?”. Dopiero taka mapa pozwala zobaczyć brakujące zabezpieczenia.
Tożsamość i konfiguracja są często po stronie klienta
Nawet dobrze zabezpieczona platforma nie poprawi automatycznie błędnej polityki uprawnień. Konto z nadmiarem praw, publicznie wystawiony zasób, sekret zapisany w kodzie albo brak wieloskładnikowego logowania mogą powstać po stronie użytkownika usługi.
Dlatego mapa odpowiedzialności powinna obejmować nie tylko serwery i sieć. Trzeba uwzględnić konta, klucze, role, logi, kopie, ustawienia retencji oraz proces odbierania dostępu osobom, które go już nie potrzebują. W praktyce bezpieczeństwo chmury często zależy od jakości konfiguracji tak samo jak od jakości infrastruktury dostawcy.