Bezpieczeństwo rozproszone

 

Procesy polegające na dekompozycji monolitycznych aplikacji na architektury mikrousług, automatyzacji rutynowych zadań, adaptowaniu Kubernetes (k8s) do zarządzania kontenerami i przenoszeniu się do chmury publicznej mają na celu sprawne dostarczanie usług. Chociaż znacznie zwiększa to wygodę dla organizacji i ich użytkowników końcowych, może wiązać się z problemami bezpieczeństwa.

Dzieje się tak, ponieważ w wielu przypadkach metodologie DevOps zostały wdrożone i rozpowszechnione bez niezbędnych zabezpieczeń. Powoduje to późniejszą konieczność łatania i reagowania w chwili, gdy pojawiają się problemy, a w niektórych przypadkach dopiero po ich wystąpieniu.

Odchodzenie od tradycyjnego modelu ochrony

W scentralizowanych środowiskach - dobrze znanych i określonych ilościowo – stosunkowo łatwo było osiągnąć jednolitość kontroli bezpieczeństwa, operacji, raportowania i ostrzegania. Zmiany w przyjętych technologiach zdarzały się rzadko ponieważ wymagały dużych inwestycji we własność intelektualną i wysokich nakładów finansowych.

Obsługa wielu nowych środowisk wiąże się z takimi czynnikami, jak brak gotowości - dojrzałości i możliwości, odmienne środowiska chmurowe, miszmasz technologii, nieczytelne operacje, słaba widoczność, czy trudne raportowanie.

W odpowiedzi na te wyzwania dostawcy chmury publicznej udostępnili bramy tranzytowe, centralne punkty kontroli, przez które przechodzi cały ruch do i od klientów.

W nowoczesnych środowiskach z aplikacjami rozproszonymi w chmurach, posiadanie zabezpieczeń w poszczególnych aplikacjach ma sens. Bezpieczeństwo jest w nich stałym elementem, stosowanym wtedy i tam, gdzie zabezpieczenia są potrzebne. Nie można o nim zapomnieć, ominąć go, a usunięcie jest możliwe dopiero na etapie likwidacji aplikacji.

Model ten stwarza również możliwość wczesnego testowania (shift left) dla bezpieczeństwa w rozumieniu obecności na wszystkich etapach cyklu życia aplikacji i we wszystkich środowiskach. Oznacza to, że kontrole bezpieczeństwa napotykamy w cyklu wcześniej niż na etapie wdrażania i uruchamiania, czy w fazie przedprodukcyjnej i produkcyjnej.

Bezpieczeństwo wpisane w organizację

Najlepszym sposobem na osiągnięcie bezpieczeństwa w nowoczesnych środowiskach jest umożliwienie zespołom DevOps korzystania z zabezpieczeń w sposób, który odpowiada ich potrzebom. Wiąże się to z wdrożeniem kontroli bezpieczeństwa na wcześniejszych etapach cyklu rozwoju, jak modelowanie zagrożeń, statyczne testowanie bezpieczeństwa aplikacji, analiza składu oprogramowania.

Ponadto, może to oznaczać też udostępnienie kontroli bezpieczeństwa późniejszych etapów w środowiskach wcześniejszych etapów, np.: Web Application Firewall, Dynamic Application Security Testing itp. w środowiskach Dev i Test.

Tradycyjne podejście do osiągnięcia bezpieczeństwa rozproszonego cechuje się posiadaniem różnych technologii, stosów i kontroli dla różnych środowisk. Nie przynosi ono jednak efektu skali i zwrotu z inwestycji. Różnorodność środowisk wzrasta, a wspieranie każdego nowego, odmiennego środowiska i zestawu kontroli staje się wykładniczo trudniejsze.

Przy takim podejściu uzyskuje się niewielką spójność zabezpieczeń w różnych środowiskach, dla których dostępne są różne alerty, raportowanie i rejestrowanie, co utrudnia zarządzanie czy przewidywalność środowiska.

Droga przed nami – jednolity stos dla bezpieczeństwa rozproszonego

W idealnym świecie, odpowiedzią na powyższe wyzwania będzie jednolity stos, który można wdrożyć w dowolnym miejscu, w którym jest potrzebny.

Taki stos jest niewielki, odpowiedni dla nowoczesnych środowisk i wspiera szybkie wdrażanie oraz likwidację. Dostarcza scentralizowaną i zuniformizowaną widoczność, logowanie i raportowanie. Zawiera również rozwinięte, kompleksowe kontrole bezpieczeństwa klasy korporacyjnej z centralnym punktem kontroli – do jednorazowego, scentralizowanego zdefiniowania i wdrożenia polityki. Polityka byłaby w takim przypadku elastyczna i zdefiniowana poprzez sieć, tożsamość, zabezpieczenia i aplikacje.

Całe rozwiązanie jest w 100% oparte na interfejsach API, aby prawdziwie umożliwić zespołom programistycznym, pomocniczym i operacyjnym współpracę w zwiększeniu tempa rozwoju firmy.

Autor: Ireneusz Wiśniewski, dyrektor zarządzający, F5 Poland