Bezpieczeństwo w chmurze: odejście od modelu wspólnej odpowiedzialności jest groźne

ORACLEWybierając usługę chmury lub oceniając jej dostawcę, firmy poświęcają mnóstwo czasu i zasobów na sprawdzenie funkcji, możliwości, infrastruktury i umów SLA. Ostatecznie przejście do modelu cloud computing jest poważną decyzją, oznaczającą rezygnację ze stosowanych od dawna praktyk i zaangażowanie w nowe modele biznesowe.

 REKLAMA 
 ERP-VIEW.PL- STREAMSOFT 
 
Więc dlaczego tak wiele firm przeocza jeden istotny element jeśli chodzi o bezpieczeństwo - wspólny model odpowiedzialności? Prosimy dobrze nas zrozumieć. Nie twierdzimy, że firmy lekceważą kwestię bezpieczeństwa jako takiego. Uważamy jednak, że wiele z nich wpada w pułapkę podejścia „uruchom i zapomnij”. To oznacza, że po skonfigurowaniu usługi zgodnie z rozsądnymi wytycznymi dotyczącymi bezpieczeństwa, ustawieniu praw dostępu i uprawnień administratora oraz wyszkoleniu personelu pod kątem wymogów bezpieczeństwa (np. ochrona poświadczeń tożsamości), niektóre firmy już niezbyt dbają o ich aktualność.

Jednak te same firmy podpisują umowy o usługi z klauzulami bezpieczeństwa zgodnymi z modelem wspólnej odpowiedzialności, według którego usługodawca odpowiada za utrzymywanie bezpiecznej i stale dostępnej usługi, a operator musi dbać o bezpieczeństwo jej użytkowania. Nie sugerujemy, że firmy rozmyślnie lekceważą postanowienia umowy, jednak w rzeczywistości (w świecie, w którym błądzić jest rzeczą ludzką) firmy z czasem oddalają się od początkowo dobrze zdefiniowanych ustawień i parametrów, ponieważ zarówno one, jak i ich pracownicy z biegiem czasu ulegają zmianom — albo dlatego, że po prostu nie mają odpowiednich zasobów. Szukanie powodów zmian w konfiguracji wprowadzonych 6 miesięcy wcześniej przez administratora, który już nie pracuje w firmie, wymaga czasu i nakładu pracy. Dlatego wielu administratorów IT po prostu działa zgodnie z zasadą „lepiej nie naprawiać czegoś, co nie jest zepsute” i tylko reaguje na ewentualne problemy. Do reakcji może skłonić na przykład nocny telefon od dyrektora, który właśnie zauważył, że nie ma już dostępu do ważnych danych potrzebnych na poranne zebranie zarządu.



Ale w takiej sytuacji złość zarządu może być najmniejszym problemem. Takie odejścia od konfiguracji mogą zwiększać podatność firmy na atak. I narażać ją na poważne straty finansowe. Załóżmy, że niezadowolony pracownik fabryki przed odejściem z pracy zarejestrował firmę w dziesiątkach usług chmurowych, co odkryto dopiero wtedy, gdy do księgowości dotarły faktury na wysoką kwotę. Albo że dostawca hostingu danych padł ofiarą phishingu, co poskutkowało uzyskaniem przez hakera uprzywilejowanego dostępu do systemów dostawcy, żądaniem okupu, atakiem DDoS i ostatecznie upadkiem firmy. Katastrofa!

Jak temu zaradzić? Rozwijające się firmy często nie mają zasobów, aby sprostać wymogom wspólnej odpowiedzialności. No i czyż nie po to m.in. przechodzi się do chmury, aby firma nie musiała dopełniać tego rodzaju obowiązków? Rozwiązaniem może być automatyzacja zabezpieczeń w chmurze. Te funkcje pozwalają eliminować luki w stosowanych dotąd środkach bezpieczeństwa. Mogą ostrzegać o krytycznych zmianach w konfiguracji, ujawnionych poświadczeniach lub ryzykownych bądź odbiegających od normy zachowaniach, które są oznaką ataku.

Gdyby we wspomnianej fabryce lub u dostawcy hostingu były wdrożone jakiegoś typu zautomatyzowane zabezpieczenia chmury, to opisanych katastrofalnych skutków zapewne można by uniknąć. Rozwijające się firmy mają już dość stawiania czoła wyzwaniom, które nadmiernie obciążają ich ograniczone zasoby. Bezpieczeństwo w chmurze nie powinno do nich należeć.

Źródło: www.oracle.com

PRZECZYTAJ RÓWNIEŻ:


Back to top