Wirtualne Media

Kiedyś architektura korporacyjna była fizyczna i jednolita, dogodnie zlokalizowana w jednym miejscu, łatwa w zarządzaniu i zabezpieczaniu. Pęd do cyfryzacji wywarł presję na organizacje zmuszając je do zmian w tym obszarze. Te organizacje, które przyjmują metodyki zwinne i praktyki DevOps, są w stanie zmodernizować swoje środowiska, stosy aplikacji i wdrożenia.

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