7 zasad bezpieczeństwa chmury

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.