careers spotlight

Drive2Cloud: Jak szybko budować bezpieczne aplikacje w chmurze dzięki podejściu DevSecOps?

Metodologia DevSecOps pozwala na włączenie wymogów bezpieczeństwa IT w proces deweloperski w sposób minimalizujący ryzyka bez zwalniania tempa dostarczania nowych produktów.

Ten artykuł jest częścią programu #Drive2Cloud

Jak ewolucja procesów wytwarzania aplikacji doprowadziła do powstania metodyki DevSecOps?

Pierwsze komercyjne aplikacje charakteryzowały się architekturą monolityczną, a ich docelowym środowiskiem uruchomieniowym był przeważnie desktop. Kod tworzono w izolacji, większość kroków integracyjnych i wdrożeniowych wykonywano ręcznie, a zespoły deweloperskie i operacyjne były od siebie odseparowane. W tamtych warunkach nie stanowiło to jednak istotnego problemu – niska częstotliwość wydań nie tworzyła presji w zakresie szybkości wdrożeń, natomiast priorytetem była stabilność oprogramowania. Postępujący rozwój technologiczny oraz rosnące wymogi rynkowe zwiększały jednak nacisk na wprowadzanie częstszych modyfikacji aplikacji. Powyższe warunki wymusiły głębokie zmiany w procesie produkcji oprogramowania, obejmujące organizację, stosowane narzędzia oraz kulturę korporacyjną. W efekcie powstała spójna i przejrzysta metodyka DevOps, której intencją było wykorzystanie najlepszych praktyk, by zmierzyć się z nową rzeczywistością.  

Metodyka DevOps bazuje na bliskiej współpracy wszystkich osób pracujących przy rozwoju aplikacji. Proponowana integracja zespołów deweloperskiego, operacyjnego i testowego ma za zadanie rozbicie organizacyjnych silosów. Analogiczny nacisk kładzie się na kulturę zespołu, zgodnie z którą każdy jest w równym stopniu odpowiedzialny za jakość i bezpieczeństwo finalnego produktu. O ile DevOps nie odnosi się do konkretnych technologii wykorzystywanych w produkcji oprogramowania, o tyle ich zastosowanie ułatwia cały proces. Narzędzia CI/CD, monitoringu, zarządzania konfiguracją i wersją czy automatyzacja testów to elementy, bez których trudno sobie wyobrazić nowoczesny proces rozwoju aplikacji.

Czy w obliczu nowej rewolucji cyfrowej metodyka DevOps jest wystarczająca?

Poważnym wyzwaniem dla DevOps jest integracja procesu rozwoju produktu z wymogami bezpieczeństwa, którego istotność zyskuje na znaczeniu w ostatnich latach. Wzrost adopcji chmury i gwałtowne upowszechnianie się usług web – powiązanych też z technologiami mobilnymi czy IoT – zwiększa potencjalną płaszczyznę cyberataków na aplikacje. Dodatkowo utrzymanie wymaganego tempa wdrożeń przy zachowaniu założonego poziomu bezpieczeństwa często okazuje się problematyczne. Nierzadko może dochodzić do sytuacji, w której, ze względu na wykryte podatności, gotowe wydania zostają wstrzymane przez zespoły bezpieczeństwa tuż przed wdrożeniem. Niestety takie zdarzenia są najczęściej niezwykle kosztowne. Wprowadzenie poprawek w gotowym już kodzie trwa zazwyczaj nieproporcjonalnie długo, co wpływa zarówno na wydłużenie Time-to-Market produktów IT, jak i wzrost kosztów deweloperskich. Co więcej, rosnąca liczba elementów aplikacji i infrastruktury, które są hostowane w chmurze, oraz popularność strategii konteneryzacji aplikacji stwarzają dodatkowe wyzwania w zakresie cyberbezpieczeństwa. 

Czy można pogodzić wymogi bezpieczeństwa IT z elastycznością rozwoju aplikacji i wysoką częstotliwością wdrożeń?

Zintegrowanie obszaru cyberbezpieczeństwa i zwinnego rozwoju aplikacji IT jest głównym celem DevSecOps. Kładzie ona nacisk na budowę bezpiecznych aplikacji już od samego początku procesu deweloperskiego oraz wskazuje na istotę proaktywnego zapobiegania zagrożeniom.


W ramach tzw. paradygmatu shift-left testy bezpieczeństwa są wykonywane na każdym etapie pracy nad aplikacją. Metodologia DevSecOps promuje również przemianę kultury organizacji i budowę świadomości, że każdy członek zespołu jest odpowiedzialny za bezpieczeństwo, a związane z nim zagadnienia zostają włączone do podstawowych wymagań aplikacji. Zaangażowanie zespołów bezpieczeństwa już na etapie projektowania aplikacji pozwala na zlikwidowanie silosów, które oddzielały je od zespołów deweloperskich.



Jak postulowane przez DevSecOps zmiany pomagają w zapewnieniu bezpieczeństwa przy jednoczesnym zachowaniu elastyczności?

Jednym z głównych filarów DevSecOps jest implementacja specyficznej strategii testów. Paradygmat shift-left pozwala w znacznym stopniu zapobiegać powstawaniu podatności w kodzie, zanim zostaną one włączone do kolejnych etapów procesu deweloperskiego, w których ich usunięcie byłoby bardziej pracochłonne i negatywnie wpływało na harmonogram. Jednocześnie metodologia DevSecOps nie ignoruje znaczenia testów shift-right, w których testy bezpieczeństwa prowadzone są nie na statycznym kodzie, ale na już uruchomionej aplikacji. W efekcie powyższe podejście pozwala odpowiedzieć na ryzyka związane z ograniczoną kontrolą nad wersją wykorzystanych bibliotek, sposobem ich użycia, ekspozycją serwisów czy udostępnianiem wrażliwych danych do Internetu. Znaczenie takiego podejścia wzrasta w dobie rosnącej popularności aplikacji skonteneryzowanych, w których kontrola procesów uruchamianych za pomocą statycznej analizy kodu na poszczególnych kontenerach może być problematyczna, a potencjalny atakujący może stosunkowo łatwo wykorzystać je do ekspozycji danych lub zakłócenia prawidłowego działania.  

Metodologia DevSecOps omawia także kilka klas narzędzi, bez których wykonywanie ciągłych testów bezpieczeństwa spowolniłoby tempo wytwarzania aplikacji. Poniżej przedstawiam ich listę, wraz z krótką charakterystyką:

Poza zmianą organizacji zespołów i wdrożeniem narzędzi testowych efektywna implementacja metodyki DevSecOps wymaga również odpowiednich modyfikacji samego procesu produkcji oprogramowania. 


Kluczowe są właściwe śledzenie, kontrola i widoczność wykrytych podatności bezpieczeństwa. Odpowiednia ocena krytyczności incydentów i zaplanowanie adekwatnych zadań naprawczych pozwolą na zamknięcie cyklu DevSecOps, a jednocześnie zapewnią bezpieczeństwo aplikacji i efektywne wykorzystanie czasu zespołu. 




Podsumowanie

Na bardzo konkurencyjnym rynku organizacje znajdują się pod silną presją, która wymusza elastyczność i minimalny Time-to-Market budowanych aplikacji. Architektura bazująca na mikroserwisach, konteneryzacja aplikacji czy przenoszenie procesów do chmury pozwalają na osiągnięcie tych celów. Implementacja wymienionych innowacji wiąże się jednak ze zmianą profilu ryzyka bezpieczeństwa IT. Wdrożenie metodologii DevSecOps pomaga organizacjom połączyć szybkość rozwoju aplikacji z zapewnieniem bezpieczeństwa, a także zapobiec zagrożeniom związanym z adopcją nowych technologii.


Drive2Cloud: How to quickly build secure applications in the cloud with DevSecOps?




 Kontakt

Chcesz dowiedziec sie wiecej? Skontaktuj sie z nami.


Informacje

Related articles

Cloud DR - jak chmura publiczna może pomóc w zabezpieczaniu ciągłości działania firmy?

Disaster Recovery (DR) jest kluczowym elementem planów ciągłości działania (BCP, czyli Business Continuity Plan) zapewniając organizacji sposób postępowania w przypadku awarii lub katastrofy. Organizacje okresowo analizują możliwe zagrożenia i prawdopodobieństwa zmaterializowania się scenariuszy wpływających na ryzyko utrzymania ciągłości działania, w tym uwzględniają m.in. szacowanie ryzyka wystąpienia zdarzeń, ocenę dotkliwości skutków oraz sposoby odpowiedzi na zagrożenia. W efekcie, BCP podlega aktualizacji by odzwierciedlić nowe uwarunkowania w otoczeniu organizacji, które mogą rzutować na ryzyko ciągłości działania.

Transformacja cyfrowa firm w 2022 roku – co się zmieniło?

Obecnie, firmy już nie zastanawiają się czy rozpocząć podróż do chmury, lecz jak to zrobić dobrze? Niestety, jeszcze w wielu przypadkach uczą się budowania strategii chmurowej, a następnie jej realizacji na własnych błędach. Jedynie niewiele z nich potrafi właściwie zdefiniować chmurę oraz wniesione przez nią wartości, co wpływa na nadal niski poziom przyjęcia chmury w Polsce.