7 zasad bezpieczeństwa chmury

Główną przyczyną większości przypadków wycieków danych z chmury nie są błędy w oprogramowaniu czy działania hakerów – wina najczęściej leży po stronie administratorów, którzy zapominają skonfigurować zabezpieczenia lub po prostu robią to źle (czym ułatwiają zadanie włamywaczom). Stosowanie się do kilku zasad pozwoli zminimalizować ryzyko takich incydentów, niezależnie od tego, czy korzystacie z Amazon Web Services, Microsoft Azure czy Google Cloud Platform.

Przykładów zasygnalizowanych powyżej sytuacji nie trzeba daleko szukać – osławiony wyciek danych z chmury firmy Capital One Finance był, jak wykazały późniejsze analizy, spowodowany przez błąd w konfiguracji zapory sieciowej typu Web Application Firewall, z której firma korzystała w swojej infrastrukturze hostowanej w chmurze Amazon Web Services. Okazało się, że WAF skonfigurowany był tak, by listować i sprawdzać zawartość wszystkich plików przechowywanych w tzw. data buckets w ramach AWS – co z kolei pozwoliło nieautoryzowanemu użytkownikowi na wysłanie żądania przesłania tych danych do niego.

Efekty tego błędu i bazującego na nim włamania były opłakane – przestępcy zdołali przejąć dane blisko 100 mln obywateli USA – w tym ok. 140 tys. numerów ubezpieczenia społecznego i dane 80 tys. kont bankowych. Skutki będą fatalne również dla Capital One, bo wedle ostrożnych szacunków, firmie może grozić kara finansowa sięgająca 150 mln USD za nienależyte zabezpieczenie danych klientów.

Zobacz również:

Liczba takich incydentów będzie się zwiększać – Gartner prognozuje, że do 2022 r. co najmniej 95% wszystkich problemów z bezpieczeństwem systemów chmurowych będzie konsekwencją błędów użytkowników, związanych z konfiguracją lub zarządzaniem usługami chmurowymi. Wyzwaniem okazuje się nie bezpieczeństwo chmury jako takiej, lecz zasad i narzędzi wykorzystywanych do jej zabezpieczania i kontrolowania. W zdecydowanej większości przypadków winnym zaniedbania okazuje się użytkownik, a nie dostawca usługi chmurowej.

Dlatego CIO powinni przestać zastanawiać się czy chmura jest bezpieczna, a ocenić, czy sami używają chmury w bezpieczny sposób

– wyjaśniają eksperci Gartnera.

Bezpieczeństwo chmury. Jeden problem, wiele przyczyn

Powodów tej sytuacji jest co najmniej kilka. Jednym z podstawowych jest błędne przeświadczenie o tym, kto właściwie odpowiedzialny jest za zabezpieczenie chmury – zbyt wielu użytkowników zakłada, że jest to obowiązek wyłącznie dostawcy usługi. Oczywiście, on również ma wiele do zrobienia w tym zakresie, jednak myślenie, że powinien zrobić wszystko, jest błędem.

Microsoft, Amazon i Google muszą oczywiście zagwarantować bezpieczeństwo swojej fizycznej infrastruktury IaaS w centrach danych, sprzętu, na którym działają wirtualne maszyny oraz pilnować aktualizacji oprogramowania. Ale dbanie o bezpieczeństwo własnych wirtualnych maszyn i działających w nich aplikacji jest już po stronie klienta lub użytkownika. Nie ma znaczenia, jak dobre zabezpieczenia zastosuje dostawca usługi – jeśli klient sam nie zabezpieczy własnej infrastruktury (nawet tej działającej w systemie dostawcy), to nie będzie mógł liczyć na odpowiednio wysoki poziom bezpieczeństwa. Co istotne, operator usługi chmurowej zwykle dostarcza klientowi narzędzia pozwalające mu na zabezpieczenie swoich zasobów – ale ich wdrożenie i zarządzanie pozostaje zadaniem użytkownika.

Kolejnym powodem problemów z bezpieczeństwem jest swoisty dysonans pomiędzy tym, jak użytkownik postrzega swoje zasoby oraz kwestie bezpieczeństwa a rzeczywistością. Użytkownicy biznesowi wciąż funkcjonują w przeświadczeniu, że gdzieś tam w sieci czyhają przestępcy, którzy mogą pewnego dnia podjąć spontaniczną próbę sforsowania systemów zabezpieczających ich firm i wykradzenia ich danych. Ich zdaniem, szanse na wystąpienie takiego incydentu są znikome, bo „dlaczego właściwie ktoś miałby atakować moją firmę?”.

W istocie sytuacja wygląda zupełnie inaczej – z opublikowanego niedawno raportu firmy McAfee wynika, że większość przestępców wcale nie poluje na konkretne firmy.

Dzisiejsi hakerzy są oportunistycznymi drapieżnikami, którzy przeszukują internet w poszukiwaniu systemów podatnych na ataki, źle skonfigurowanych – i dopiero po wykryciu takich słabości biorą na cel konkretną firmę.

Kolejnym problemem jest coraz wyższy poziom skomplikowania firmowych systemów IT. Wiele firm chętnie wdraża u siebie rozwiązania typu multi-cloud, czyli usługi chmurowe różnych dostawców, co sprawia, że ich systemy stają się coraz mniej przejrzyste i trudniejsze do zarządzania. To z kolei stwarza więcej okazji do popełnienia poważnego błędu w konfiguracji, z czego sami klienci nie całkiem zdają sobie sprawę. Według McAfee ok. 76% użytkowników biznesowych deklaruje, że korzysta w firmie z systemów multi-cloud – podczas gdy analizy firmy wykazały, że takie środowiska wdrożyło ok. 92%. Oznacza to, że administratorzy 17% ankietowanych firm tak naprawdę nie wiedzieli, czym zarządzają. Przy takim podejściu łatwo o błędy i zaniedbania.

Bezpieczeństwo chmury. Klęska urodzaju

Sytuacji nie poprawia również ostra konkurencja na rynku usług Infrastructure as a Service. Główni gracze tego segmentu – Amazon, Microsoft oraz Google – właściwie non stop prezentują nowe funkcje, narzędzia, aplikacje i oferty. „W pierwszym roku działania platformy AWS Amazon udostępnił dla niej 28 różnych funkcji i narzędzi. W tym roku wprowadzono ich już ponad 1800. Stanowi to ogromne wyzwanie dla pracowników odpowiedzialnych za bezpieczeństwo, którzy muszą nadążać z zabezpieczaniem wszystkich wdrażanych przez ich organizacje nowości. Tak naprawdę w złożonym środowisku multi-cloud powinno się mieć po jednym ekspercie ds. bezpieczeństwa na każdą używaną platformę i usługę – tylko takie podejście zagwarantuje odpowiednio wysoki poziom bezpieczeństwa” – komentuje John Yeoh, wiceprezes ds. badań organizacji Cloud Security Alliance.

Dodajmy jeszcze do tego istny wysyp nowych typów aplikacji i innowacyjnych rozwiązań chmurowych, takich hak choćby Kubernetes, Jenkins, architektura serverless, nowe interfejsy API i narzędzia pozwalające na praktycznie dowolne łączenie różnych funkcji, narzędzi i platform chmurowych. Wszystko to jeszcze zwiększa liczbę usług, funkcji czy punktów styku, które mogą być potencjalnie źle wdrożone lub skonfigurowane.

Bezpieczeństwo chmury. Zasady ochrony

Aby zapanować nad zabezpieczeniem tego skomplikowanego, stale ewoluującego środowiska, należy stosować się do kilku podstawowych zasad.

1. Wiedza i odpowiedzialność

Usługi chmurowe różnią się między sobą zarówno zestawem funkcji, jak i tym, kto dokładnie ponosi odpowiedzialność za zabezpieczenie poszczególnych elementów. W przypadku usług Software as a Service to operator zwykle dba o bezpieczeństwo aplikacji czy przesyłanych danych. W środowiskach IaaS może to już wyglądać zupełnie inaczej. Weźmy choćby AWS – w przypadku instancji AWS Elastic Compute Cloud (EC2), Amazon EBS i Amazon Virtual Private Cloud (VPC) to klient ma pełną kontrolę nad infrastrukturą – oprogramowaniem, konfiguracją danych i aplikacji, kontrolą dostępu czy uwierzytelnieniem – i to on jest wyłącznie odpowiedzialny za ich zabezpieczenie.

Z w kolei w S3 to Amazon dba o bezpieczeństwo systemu i aplikacji a po stronie klienta jest tylko zapewnienie odpowiednio wysokiego poziomu zabezpieczenia danych (Amazon dostarcza niezbędne narzędzia, jednak to klient musi zadbać o ich wdrożenie i stosowanie).

2. Kontrola dostępu

Bałagan w „polityce dostępowej” jest jednym z większych problemów użytkowników usług chmurowych. Z raportu opublikowanego w ubiegłym roku przez RedLock Cloud Security Intelligence dowiadujemy się, że w 51% organizacji zdarzyło się co najmniej raz, że jakieś zasoby chmurowe zostały przypadkowo udostępnione publicznie. I to w sytuacji, gdy dostawcy większości usług chmurowych zwykle ostrzegają użytkowników przed „wystawianiem” zasobów w internecie i odradzają takie działania, jeśli nie jest to absolutnie niezbędne. Co więcej – zwykle dostarczają oni również narzędzia pozwalające na przeprowadzenie szybkiego audytu i sprawdzenie co dokładnie (i komu) zostało udostępnione.

Innym popularnym (niestety) błędem jest umożliwianie nawiązywania połączeń SSH bezpośrednio z internetu – co teoretycznie otwiera nieautoryzowanym użytkownikom drogę do szukania i wykorzystywania luk i błędów w konfiguracji usługi chmurowej.

3. Szyfrowanie danych

Poważnym zaniedbaniem administratorów jest przechowywanie w chmurze nieszyfrowanych danych – taki błąd popełnili swego czasu nawet pracownicy amerykańskiego Pentagonu czy tamtejszej komisji wyborczej. Tymczasem o takim niedopatrzeniu właściwie nie powinno być mowy – wszyscy liczący się dostawcy chmury rekomendują szyfrowanie danych i dostarczają niezbędne do tego narzędzia oraz usługi. Problem polega na tym, że klienci z nich nie korzystają. A szkoda, bo to dodatkowa, bardzo skuteczna warstwa zabezpieczeń, która chroni dane przed odczytaniem nawet gdy dojdzie do wycieku lub kradzieży.

Jeśli to możliwe, należy też starać się zachować pełną kontrolę nad kluczami szyfrującymi, aczkolwiek nie zawsze jest to możliwe, niekiedy niezbędne jest przecież udostępnienie ich np. partnerom.

4. Ochrona danych logowania

O tym, że użytkownicy, a często również specjaliści IT, nie dbają o zapewnienie odpowiednio wysokiego poziomy bezpieczeństwa danych logowania, wiadomo od dawna – nie raz i nie dwa zdarzyło się, że analiza włamań wykazywała, iż „ofiary” korzystały ze słabych czy domyślnych haseł, otwierając tym samym włamywaczom drogę dostępu do cennych zasobów.

Hasła i klucze dostępu do usług chmurowych powinny być traktowane – i chronione – jak rodowe srebra. Dla każdej aplikacji, zasobu, czy usługi należy tworzyć oddzielne, unikalne i odpowiednio silne hasła, a także pamiętać o ich regularnym zmienianiu. Dzięki temu nawet jeśli dojdzie do wycieku czy kradzieży danych, to jest duża szansa, że włamywacze przejmą nieaktualne hasło. Ważne jest również, by precyzyjnie przydzielać uprawnienia i dawać użytkownikom dostęp tylko do tych zasobów, do których powinni go mieć.

W miarę możliwości należy zrezygnować z używania na co dzień konta root, nawet do zadań administracyjnych. Do tego celu lepiej będzie wykorzystać konto użytkownika z odpowiednio wysokim do wykonania danego zadania poziomem uprawnień. Należy też regularnie sprawdzać, czy w systemie istnieją nieaktywne konta użytkowników – a jeśli tak, usuwać je.

5. Informatyczna higiena

Zabezpieczanie środowisk chmurowych powinno być procesem wieloetapowym, w którym stosujemy wiele różnych, nakładających się technologii z dziedziny bezpieczeństwa – dzięki temu nawet jeśli któraś z „warstw” zostanie spenetrowana lub dojdzie do błędu użytkownika, wciąż jest duża szansa, że nasze zasoby pozostaną nienaruszone.

Dlatego tak ważne jest np. korzystanie z uwierzytelniania wieloetapowego, znacznie wzmacniającego standardowe zabezpieczenie z wykorzystaniem loginu i hasła.

6. Przejrzystość

Dostawcy najpopularniejszych platform chmurowych oferują narzędzia, pozwalające na aktywowanie bezpiecznego logowania, a także monitorowanie wszelkich nieudanych/podejrzanych prób logowania – dobrym przykładem jest na przykład AWS CloudTrail. Niestety, praktyka pokazuje, że znaczna część użytkowników nie aktywuje tych rozwiązań – a szkoda, bo to doskonałe narzędzia do identyfikowania potencjalnych prób ataku, podejrzanych zachowań, błędów i innych anomalii.

7. „Shift-left” w bezpieczeństwie

Warto do polityki bezpieczeństwa zastosować znane z tworzenia aplikacji podejście „shift-left” – innymi słowy, planować wdrażanie funkcji związanych z bezpieczeństwem już na bardzo wczesnym etapie tworzenia czy implementowania danego rozwiązania. Teraz często odbywa się to zupełnie inaczej – najpierw wdrażamy jakieś rozwiązanie, a dopiero później dodajemy do niego funkcje i narzędzia zabezpieczające. Stosowanie podejścia „shift-left” w bezpieczeństwie jest dziś prostsze – coraz więcej wiele firm oferuje bowiem narzędzia z zakresu bezpieczeństwa integrujące się np. z Kubernetes czy Jenkinsem.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200