Temat cyberbezpieczeństwa środowisk chmurowych w wielu obszarach pokrywa się z zagadnieniami występującymi w środowiskach on-premise. Są też jednak między nimi pewne różnice, których nieznajomość prowadzi do powstawania luk bezpieczeństwa.
Środowisko chmury publicznej może być równie bezpieczne – a nawet w pewnych obszarach bezpieczniejsze – od klasycznych środowisk on-premise, ale wymaga to odpowiedniej konfiguracji.
„Środowisko chmury publicznej ma swoją specyfikę. Część rozwiązań z zakresu bezpieczeństwa jest podobna do systemów on-premise, ale niektóre różnią się. Brak wiedzy o specyfice chmury prowadzi do powstawania luk bezpieczeństwa i przekonania, że środowiska cloud computing są niebezpieczne” – mówi Andrzej Nowodworski, architekt bezpieczeństwa Chmury Krajowej. „W praktyce jest pewien zestaw błędów, które powtarzają się w konfiguracji usług bezpieczeństwa w chmurze publicznej. Wynikają one przeważnie z braku doświadczenia w pracy na platformie chmurowej”.
Oto pięć najpowszechniejszych błędów w obszarze bezpieczeństwa:
1. Brak planu na bezpieczeństwo
Może to brzmieć zaskakująco, ale wiele organizacji, tworząc nowe środowisko, nie uwzględnia kwestii związanych z cybersecurity.
„Wielokrotnie spotykałem się z sytuacją, gdy budowano nowe środowisko IT, a dopiero pod koniec prac pojawiał się pomysł włączenia specjalistów od cyberbezpieczeństwa. Przez to po drodze mogło być pominięte wiele kroków, które trudniej jest naprawić, gdy większość pracy została wykonana. W efekcie cały proces konfiguracji i poprawiania popełnionych wcześniej błędów trwa o wiele dłużej” – mówi Andrzej Nowodworski, architekt bezpieczeństwa z Chmury Krajowej. „Im wcześniej dział bezpieczeństwa zostaje włączony w planowanie i budowanie środowiska IT, tym lepiej będzie ono zabezpieczone, a projekt zrealizowany na czas”.
2. Niedbałe zarządzanie tożsamością
Tożsamość to klucz do bezpieczeństwa – dobrze zarządzana gwarantuje, że użytkownik jest tym, za kogo się podaje i ma takie uprawnienia, jakie powinien mieć. Dobrze zabezpieczona tożsamość użytkownika to fundament każdego systemu IT, ale szczególnie istotne jest to w przypadku środowisk chmurowych.
„Charakterystyczne dla chmury publicznej jest jedno poświadczenie dla całego środowiska chmurowego dla różnych aplikacji. To wygodne rozwiązanie dla użytkownika. Raz zalogowany do środowiska IT może swobodnie przełączać się między aplikacjami, bez potrzeby ponownego logowania. Z drugiej strony, utrata tożsamości przez użytkownika w wyniku np. ataku phishingowego albo ustawienia zbyt prostego hasła powoduje, że przestępca uzyskuje również dostęp do wszystkich elementów środowiska” – mówi Andrzej Nowodworski z Chmury Krajowej. „Dlatego w środowisku chmurowym szczególnie ważne jest zabezpieczenie tożsamości użytkowników”.
„To nie jest kwestia bardzo wyrafinowanych technik, raczej podstawowych, ale konsekwentnie stosowanych. Chociażby w przypadku polityki haseł: powinny być one możliwie jak najdłuższe i nie złożone z prostych czy generycznych zwrotów takich jak „qwerty” czy „12345”. Zbyt skomplikowane hasła złożone z ciągów znaków specjalnych też nie są dobrym rozwiązaniem, ponieważ ich zapamiętanie jest trudne. W rezultacie użytkownicy starają się je zapisać – najchętniej na kartce naklejonej na monitor, co oczywiście pod kątem bezpieczeństwa jest fatalnym pomysłem” – dodaje Andrzej Nowodworski.
O odpowiednie zabezpieczenie tożsamości użytkowników dba też 2FA, czyli dwuskładnikowa weryfikacja użytkownika. Im więcej zabezpieczeń, tym trudniej będzie niepowołanym osobom uzyskać nieautoryzowany dostęp.
„Wykorzystanie 2FA umożliwia np. Google Cloud. W tym środowisku chmurowym funkcja ta nie jest domyślnie włączona, a w dobie coraz częstszych cyberataków tym bardziej warto poświęcić czas na jej uruchomienie. Google Cloud oferuje mechanizmy dwustopniowej weryfikacji wykorzystujące kody SMS, token Google Authenticator oraz sprzętowe klucze typu YubiKey. Takie dodatkowe zabezpieczenie utrudni przestępcom nieautoryzowane przejęcie kont użytkowników” – wyjaśnia Andrzej Nowodworski.
Poza zabezpieczeniem samych kont należy pamiętać o zasadzie minimalnych przywilejów. Powinniśmy ją stosować zarówno do kont uprzywilejowanych, jak i zwykłych użytkowników. W sekcji IAM w Google Cloud jest kolumna „security insights”, w której mechanizmy bezpieczeństwa Google sugerują nam nadmiarowe uprawnienia dla każdego użytkownika, włączając w to konta serwisowe. Dla zapewnienia odpowiedniego poziomu bezpieczeństwa warto je ograniczyć.
3. Nieostrożne korzystanie z aplikacji umieszczonych na marketplace
Zaletą korzystania z chmur publicznych są marketplace’y – sklepy z aplikacjami. Wiele gotowych rozwiązań, które się tam znajdują, pozwala np. integrować ze sobą inne aplikacje albo wzbogaca je o dodatkowe funkcje. Ale uwaga – niezweryfikowane pod kątem bezpieczeństwa aplikacje mogą stanowić duże zagrożenie dla środowiska IT.
„To nie tylko kwestia złośliwych aplikacji, umieszczanych przez hakerów w marketplace’ach. Dostawcy usług chmurowych dosyć sprawnie weryfikują i eliminują aplikacje od niewiarygodnych twórców. Ale nawet te w pełni legalne mogą udostępniać zbyt dużo danych o ich użytkownikach, np. przesyłając je do zewnętrznych serwisów. W ten sposób nieświadomy pracownik może udostępnić na zewnątrz dane, które nie powinny być przesyłane poza firmowe środowisko IT. Rozwiązanie tego problemu jest jedno – przed skorzystaniem z aplikacji umieszczonej w danym marketplace należy skonsultować się z działem bezpieczeństwa odnośnie do takiej możliwości. Może się okazać, że jest to dopuszczalne, ale po dodatkowej konfiguracji, która zapewni poufność danych” – tłumaczy Andrzej Nowodworski.
4. Upublicznienie danych, które powinny być przetwarzane wewnątrz
Powszechnym błędem jest przypadkowe upublicznienie danych z wnętrza firmowego środowiska. Dlaczego dochodzi do tzw. wystawienia na zewnątrz? Powodem są błędy w konfiguracji.
Jeżeli popełniliśmy pierwszy z opisywanych w artykule błędów i nie przygotowaliśmy np. polityk na poziomie organizacji czy projektu, to powołana w Google Cloud maszyna wirtualna domyślnie otrzyma publiczny adres IP i będzie dostępna z poziomu Internetu. Administrator, który nie zna tej zasady, bardzo łatwo może popełnić błąd poważnie naruszający bezpieczeństwo.
„Zupełnie odwrotnie ma się sprawa z ochroną przestrzeni na dane, czyli tzw. bucketami. Domyślnie zaznaczona jest opcja “Enforce public access prevention on this bucket”. Dlatego tak ważna jest odpowiedzialna konfiguracja usług w chmurze i dbanie o nieupublicznianie zasobów, które powinny być prywatne” – wyjaśnia Andrzej Nowodworski z Chmury Krajowej.
5. Brak wiedzy, kto odpowiada za bezpieczeństwo IT w chmurze
Częstym błędem osób z dużym doświadczeniem w środowiskach on-premise jest założenie, że w chmurze publicznej za obszar bezpieczeństwa całkowicie odpowiada dostawca usługi. Owszem, dostawcy chmury publicznej odpowiadają za wiele obszarów bezpieczeństwa, przede wszystkim za bezpieczeństwo fizyczne serwerów, zasilanie w energię elektryczną. Oferują też szereg narzędzi związanych z bezpieczeństwem czy backupem, ale ich skuteczność zależy także od odpowiedniej konfiguracji wewnątrz organizacji. Więcej na ten temat pisaliśmy w artykule „Kto odpowiada za bezpieczeństwo w chmurze”.
Jak widać na podstawie tych kilku powszechnie popełnianych błędów, konfiguracja środowiska chmurowego w sposób bezpieczny jest jak najbardziej możliwa, ale wymaga odpowiedniej wiedzy eksperckiej i planowania. Musimy wiedzieć, z jakich mechanizmów bezpieczeństwa chcemy i powinniśmy skorzystać, jak odseparować dane między sobą, co ma być zasobem publicznym, a co prywatnym.
Podobnie jak w środowiskach on-premise, aby uniknąć błędów, potrzebujemy kompetencji i doświadczenia na odpowiednim poziomie. Jeżeli nie posiadamy wiedzy o mechanizmach bezpieczeństwa danego środowiska chmurowego, warto sięgnąć po materiały (szkolenia, dokumentacja techniczna) albo zwrócić się o pomoc do ekspertów.
Artykuł sponsorowany przez Chmurę Krajową.