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.
Ireneusz Wiśniewski, dyrektor zarządzający, F5 Poland
