DevSecOps – bezpieczeństwo na miarę naszych możliwości

Najnowszy raport Deloitte „Trendy Technologiczne 2019” jako jeden z kluczowych obszarów wskazuje rozwój DevSecOps i cyberbezpieczeństwa. O ile to drugie na pewno każdy kojarzy, choćby z głośnych spraw medialnych związanych z wyciekami danych, to pierwszy termin, jako stosunkowo świeży, może nie być zrozumiały. Przyjrzyjmy się więc, czym jest DevSecOps?

IT w wielkim mieście

Projekty IT często porównuje się do tworzenia budowli. Pod pewnymi względami faktycznie są to przedsięwzięcia podobne. W każdym przypadku potrzebny jest projekt, określona grupa specjalistów musi zaakceptować koncepcję, obecne są nawet testy akceptacyjne i dopiero można ruszyć z budową. Istnieje jednak jedna podstawowa różnica – budownictwo miało 7000 lat na dopracowanie podejścia do realizacji projektów. Branża IT miała na to jak dotąd niewiele ponad pół wieku.

Coś, co może wydawać się jedynie ciekawą anegdotą, pozwala zrozumieć fenomen natłoku podejść, koncepcji, ram i metodyk związanych z realizacją projektów IT. Branża musi w jakiś sposób realizować projekty równie skomplikowane, jak budowa wieżowca, nie mając nawet ułamka „odziedziczonego” doświadczenia, jakie mają budowniczy.

Jedną z koncepcji mających usprawnić i przyspieszyć ciągnące się miesiącami projekty jest DevOps – połączenie rozwoju oprogramowania (Development) z jego utrzymaniem (Operations). Jej idea jest jednocześnie zadziwiająco prosta i ogromnie trudna do wdrożenia. Trzymając się porównania budowlanego, polega ona na „budowaniu dla siebie”. W momencie, w którym członek zespołu wie, że będzie musiał system utrzymywać (albo przynajmniej spotykać codziennie kolegę, który będzie to robił), w sposób naturalny będzie dbał o wyższą jakość oprogramowania. Jeśli dodamy do tego podejście tzw. zwinne, zbliżające twórców oprogramowania do końcowych użytkowników, otrzymujemy niemalże samonaprawiający się mechanizm. Oczywiście w rzeczywistości wdrożenie DevOps jest dużo bardziej skomplikowane i wymaga zmiany filozofii działania całej organizacji, niemniej wiele firm zdecydowało się już na ten krok i zaczyna dostrzegać pierwsze zyski.

Zagubiony „Sec”

Jak przystało na oddolną inicjatywę, nie wszyscy zdążyli się w nią zaangażować od samego początku. Z różnych przyczyn, o których za chwilę, wielkim nieobecnym DevOps został dział bezpieczeństwa. O tym, dlaczego bezpieczeństwo w coraz bardziej zinformatyzowanym świecie jest bardzo ważne, wie każdy, kto choć raz na miesiąc zagląda do serwisów internetowych.

Spójrzmy jednak na podwaliny obecnego stanu rzeczy. Tradycyjny projekt kaskadowy opiera się na jednej zasadzie: poszczególne czynności wykonujemy sekwencyjnie – jeśli się pomylimy, oznacza to zmianę zakresu projektu. Przy takiej konstrukcji w pierwszą fazę zaangażowany jest z reguły zespół biznesowy, analityczny, operacji, bezpieczeństwa i wiele innych. W kolejnych fazach miejsce tych osób zastępują programiści, po czym wszyscy spotykają się znowu podczas testów.

Rzeczywistość wygląda z reguły zupełnie inaczej i poszczególne kroki należałoby przedzielić zmianami zakresu, które wiążą się z koniecznością powtórzenia części prac.

Między innymi z tego powodu na scenę wkroczył DevOps. Zaczynając z ogólnym zarysem funkcjonalnym i dostosowując produkt w ramach sprintów, projekt może nie rejestrował mniejszej liczby zmian, natomiast ich zakres był zdecydowanie mniejszy.

Na jedną rzecz należy tu zwrócić szczególną uwagę. Bezpieczeństwo w projektach kaskadowych i zwinnych, niezależnie od tego, czy organizacja zaimplementowała DevOps, czy nie, nadal występuje jedynie w dwóch miejscach: na początku i na końcu projektu.

DevSecOps = DevOps + Sec

W tym miejscu dochodzimy do sedna idei DevSecOps – zaangażowania specjalistów od bezpieczeństwa na przestrzeni całego projektu. Zacznijmy jednak od podsumowania, dlaczego model funkcjonujący dotychczas nie sprawdzał się. Spora część zastojów, to odpowiedniki problemów wdrożeniowych sprzed DevOps. Brak bezpośredniego zaangażowania w projekt wprowadzał model bezpieczeństwa „wieży z kości słoniowej” (ang. ivory tower). Jest to sytuacja zbliżona do tej, która miała (i często nadal ma) miejsce w przypadku architektury korporacyjnej. Zespół bezpieczeństwa definiuje swoje wymagania w sposób jednolity dla wszystkich projektów, nie widząc ich specyfiki. Cała jednostka jest więc postrzegana bardziej jako regulator niż partner i - jak w przypadku każdego regulatora - organizacja robi wszystko, żeby wszelkie wytyczne obejść. Jeżeli obejścia są wykonane nieumiejętnie, poziom bezpieczeństwa rozwiązania może nawet zmaleć.

Takie kategoryczne podejście do bezpieczeństwa powoduje również, że wszelkie luki wykrywane są bardzo późno i są kosztowne w naprawie. I wtedy do gry wkracza zwykły rachunek zysków i strat – czy naprawa luki w zabezpieczeniach będzie tańsza, niż ewentualny wyciek danych? Pod koniec dwuletniego projektu odpowiedź na to pytanie wcale nie jest oczywista.

Takie określenie roli bezpieczeństwa w organizacji determinuje szereg dalszych konsekwencji. W wielu organizacjach oznacza to, że zespół nie jest wystarczająco nagradzany za wprowadzanie innowacji. W efekcie poziom zaangażowania specjalistów od bezpieczeństwa w prace rozwojowe spada, przez co z kolei wzrasta liczba obejść tworzonych w ramach projektów.

Jeśli popatrzymy na powyższą grafikę, to można zauważyć, że przebieg projektu w organizacji DevSecOps nie odbiega od zwykłego projektu zwinnego. Różnica jest tylko (i aż) w zaangażowaniu zespołu bezpieczeństwa w prace projektowe na wszystkich etapach.

DevSecOps to jednak nie tylko zarządzanie projektem. Istnieje cała gałąź związana z wykorzystaniem narzędzi do zwiększenia poziomu bezpieczeństwa oprogramowania. Całość sprowadza się do wzbogacenia wykorzystywanych narzędzi (CI\CD (Continuous Integration \ Continuous Deployment) o aspekty związane z testami bezpieczeństwa. Postawiono tezę, że dużą część powtarzalnych testów bezpieczeństwa można zautomatyzować i wykonywać po każdorazowym opublikowaniu nowej wersji.

Korzyści z takiego podejścia są zbliżone to tych, z wprowadzenia automatycznych testów funkcjonalnych i integracyjnych – dużo szybciej wykrywa się luki bezpieczeństwa , a co za tym idzie koszt ich naprawy znacznie się obniżył.

Jak dodać „Sec” do DevOps

Jak już ustaliliśmy, wdrożenie DevSecOps w znacznej mierze jest kwestią zmiany mentalności organizacji. Co więc powinno się zmienić?

Organizacje, które zdecydowały się na zmiany zauważyły, że zarówno zbliżenie zespołu bezpieczeństwa do projektów, jak i zrozumienie potrzeb i motywacji biznesu, samo w sobie niesie znaczne korzyści. Kolejnym krokiem jest wyrzucenie list kontrolnych akceptowanych na poziomie zarządu i skupienie się na rozwiązywaniu bieżących problemów organizacji i projektów. W krótkim czasie okazało się, że zespoły projektowe potrzebują i cenią sobie pomoc w zagadnieniach bezpieczeństwa aplikacji. W końcu nikt nie chce zobaczyć swojego produktu w nagłówku gazety rozpoczynającego się od „Kolejny wyciek…”. Zbliżenie z biznesem najczęściej powoduje również, że wymagania bezpieczeństwa są bardziej adekwatne do potrzeb firmy i klientów. Popularne powiedzenie mówi, że „najbezpieczniejszy serwer to taki, który jest wyłączony z prądu”, z reguły istnieje jednak złoty środek pomiędzy zamknięciem serwera w sejfie, a publikowaniem danych klientów na portalach społecznościowych.

Ostatni warunek, być może najtrudniejszy dla samych „bezpieczników”, to: przestań straszyć, zacznij edukować. Sam niejednokrotnie brałem udział w dyskusjach, z których wniosek był tylko jeden – „wszyscy zginiemy”. Kiedy po miesiącu okazywało się, że jednak nadal żyjemy, doszedłem do wniosku, że może jednak wyolbrzymiliśmy problem. Temat edukacji organizacji jest bardzo szeroki i zdecydowanie wykracza poza ramy artykułu o DevSecOps, natomiast jest on równie ważny w strukturach projektowych. Czy się to komuś podoba, czy nie, programista podejmuje decyzję dotyczącą bezpieczeństwa kilkanaście razy dziennie i udział w każdej z nich eksperta ds. bezpieczeństwa jest po prostu fizycznie niemożliwy. Należy więc zadbać o to, aby zespoły projektowe miały wystarczającą wiedzę do samodzielnego poruszania się w ramach naszkicowanych przez bezpieczeństwo.

Wdrożenie DecSecOps nie jest proste. To prawda. Na pewno też nie jest odpowiednie dla każdej organizacji. Warto jednak postawić sobie pytanie, czy przy technologii przejmującej w coraz większym zakresie nasze codzienne zadania i obowiązki możemy sobie pozwolić na pozostanie w miejscu?