Zaniedbania bezpieczeństwa w chmurze, czy firmy świadomie narażają się na ryzyko? – komentuje Ireneusz Wiśniewski, Dyrektor Zarządzający F5 Polska.

Eksperci z F5 Labs od 2017 r. notują przypadki organizacji z całego świata, które utraciły swoje zasoby chmurowe z powodu źle skonfigurowanych baz danych w chmurze lub usłudze pamięci masowej Amazon[1]. Ponieważ w takich przypadkach dostęp dla nieautoryzowanych użytkowników – hakerów – jest możliwy jedynie wtedy, gdy ktoś celowo usunie lub zdegraduje domyślą ochronę, oznacza to świadome działanie i podejmowanie ryzyka po stronie „poszkodowanych”.

Z posiadanych przez F5 danych wynika, że miesięcznie dochodzi średnio do ok. trzech naruszeń z podobnego powodu. Niewiele? Jeśli wskaźnik wzrostu takich zdarzeń, który między 2017 a 2018 r. był na poziomie 200% się utrzyma, to możemy prognozować około 90 włamań do końca br. z powodu celowo zdjętych zabezpieczeń. Zwróćmy uwagę, że dane F5 odnoszą się jedynie do monitorowanych przez firmę przedsiębiorstw, więc szacunki mogą być wierzchołkiem góry lodowej.

Nie oznacza to jednak, że rozwiązania chmurowe same w sobie są źle zabezpieczone i narażają firmy na ryzyko. Chodzi tu wyłącznie o sytuacje, w których organizacje czy użytkownicy wprowadzają zmiany w domyślnej ochronie i tym samym wystawiają na publiczny widok dane, które przechowują. Może mieć to bardzo znaczące konsekwencje dla ich rzeczywistych właścicieli. Ponieważ takie zdarzenia obserwuje się we wszystkich branżach, wycieki mogą dotyczyć np. historii kredytowych, danych osobowych klientów firmy czy innych poufnych informacji, a tym samym narazić prawdziwych ludzi na ogromne ryzyko. Z doświadczenia F5 wynika, że w większości przypadków, za zmiany ustawień w chmurze i tym samym upublicznienie danych, odpowiedzialne były osoby, które nie znajdują się po stronie operacyjnej. Inżynierowie sieci, administratorzy baz danych czy inżynierowie systemów lub bezpieczeństwa – nie popełniliby takich błędów.

Biznes pędzi, presja na IT rośnie

Migracja do chmury umożliwia programistom zrezygnowanie z niektórych tradycyjnych ról w działach IT. Postępująca automatyzacja, a tym samym skrócenie procesów, tworzy potencjalne zagrożenie wdrażania systemów o źle skonfigurowanych funkcjach bezpieczeństwa. W chwili, gdy zadania te przejmują deweloperzy, od których oczekuje się coraz szybszych wdrożeń – takie ryzyko wzrasta. Ponadto mogą oni nie znać potencjalnych konsekwencji lub błędnie założyć, że ataki nie są prawdopodobne.

Domyślne wdrożenia – ograniczona wiedza

W domyślnych wdrożeniach w chmurze dostępne są tylko ograniczone raporty bezpieczeństwa. Niezbędne informacje[2], które wcześniej deweloperzy mogli pozyskać wewnątrz przedsiębiorstwa (u inżynierów sieci i systemów) są dla nich niedostępne. W przypadku większości chmur publicznych organizacje muszą kupować narzędzia kontroli bezpieczeństwa, aby nadal być w stanie generować wystarczająco szczegółowe raporty. Oczywiście powrót do długich opóźnień „z powodu zabezpieczeń” we wdrożeniach (na co skarżą się zespoły Dev) nie jest rozwiązaniem.

Coraz istotniejsza jest współpraca i wymiana informacji pomiędzy deweloperami, odpowiedzialnymi za bezpieczeństwo i działami operacyjnymi: DevSecOps. Takie podejście ma szansę wprowadzić dobre praktyki bezpieczeństwa do dewelopmentu. Celowe zmniejszanie potencjału bezpieczeństwa dla wygody czy prędkości działania, naraża na dotkliwe konsekwencje nie tylko organizacje, ale też ludzi, którzy powierzają im dane.

[1] W folderach S3 bucket

[2] Np. listy podsieci, szczegółowe listy kontroli dostępu, dane dot. uprawnień