DevSecOps dla aplikacji chmurowych
Zmiana w podejściu do wytwarzania oprogramowania i przejście z kaskadowej metodologii (ang. waterfall model) do trybu zwinnego (ang. agile) spowodowały, że kwestia bezpieczeństwa tworzonych aplikacji stała się jeszcze ważniejsza niż dotychczas. Zamiast pojawiać się na samym końcu liniowego modelu waterfall, bezpieczeństwo jest obecne na każdym etapie rozwoju w metodologii zwinnej. W międzyczasie, żeby jeszcze bardziej usprawnić prace nad oprogramowaniem, pojawił się DevOps, czyli kultura stanowiąca połączenie Development and Operations – rozwoju i utrzymania. Dzięki DevOps zespół przyspiesza tworzenie i zwiększa jakość aplikacji, jednak tradycyjne podejście do kwestii bezpieczeństwa – czyli prace realizowane przez odrębny dział – często nie jest w stanie nadążyć za tempem całego procesu. W ten sposób, odpowiadając na pilne potrzeby oraz w zgodzie z Cloud Culture, pojawił się termin DevSecOps.
Czym tak właściwie jest DevSecOps?
Połączenie ze sobą działów dotychczas odpowiedzialnych za różne rzeczy w projekcie – rozwój oraz utrzymanie – działa świetnie, jeśli chodzi o zwiększenie wydajności i prędkości, z jaką wytwarza się oprogramowanie. Jak wspomnieliśmy we wstępie, w mieszance DevOps zabrakło jednak odpowiedzi na pytanie: co z bezpieczeństwem tak szybko tworzonego kodu? Jak łatwo można się domyślić, do DevOps (Development and Operations) dodano kolejny człon – „Sec”, czyli Security (pl. bezpieczeństwo). Dzięki podejściu DevSecOps bezpieczeństwo jest wpisane w samo centrum od pierwszych etapów istnienia danego rozwiązania – dosłownie i w przenośni. Jest to ewolucja dobrze działającego modelu. Dzięki niej wyniki zespołu projektowego są jeszcze lepsze i bardziej efektywne, zwłaszcza w przypadku rozwiązań chmurowych, gdzie integracja procesów jest najłatwiejsza.
DevSecOps vs DevOps
Stosunkowo nowy DevSecOps jest coraz lepiej znanym w środowisku IT terminem, ale jak bardzo różni się od funkcjonującego od kilkunastu lat DevOps? W paragrafach poniżej dokładniej odpowiadamy na to pytanie, porównując obie metodyki.
Samo wykorzystywanie DevOps w projektach znacznie przyspieszyło i usprawniło rozwój oprogramowania, ponieważ połączyło ze sobą dwa do tej pory odrębne działy, które pracują w zupełnie inny sposób – Development, czyli rozwój, oraz Operations, czyli dział operacji IT. Z zasady osoby odpowiedzialne za wytwarzanie oprogramowania działają szybko, powinny móc sprawnie i w krótkim czasie odpowiedzieć na zadania i zmiany, które czasem pojawiają się niespodziewanie, na przykład na prośbę klienta. Z kolei operacje IT utrzymują istniejące aplikacje i programy, oczekuje się od nich stabilności, dużej wydajności i unikania błędów – a ryzyko wystąpienia bugów pojawia się przy każdej kolejnej szybkiej zmianie, którą implementuje dział Development. Te dwa sprzeczne podejścia powodują, że w projektach często powstaje dług technologiczny, który bardzo ciężko w późniejszym czasie zniwelować (więcej szczegółów w artykule: “Historia metodyki DevOps”).
Ten problem rozwiązuje wdrożenie metodyki DevOps. Dwa działy pracujące w inny sposób bardzo blisko współpracują i są w stałym kontakcie, mają wspólne procedury i są w stanie o wiele szybciej identyfikować i usuwać pojawiające się problemy; warto dodać, że najczęściej odpowiedzialni za ten proces są inżynierowie posiadający stanowisko o nazwie DevOps Engineer, lub po prostu DevOps. Automatyzacja przebiega znacznie sprawniej, ponieważ zespół używa wspólnych narzędzi i razem działa tam, gdzie do tej pory prace przebiegały całkiem osobno.
Wiele iteracji oraz wypuszczanie kolejnych porcji kodu w krótkim czasie jest wydajne i efektywne, jednak jest jeszcze jeden dział, bez którego oprogramowanie tak naprawdę nie może istnieć – dział bezpieczeństwa. W modelu DevOps nadal działa on w pewnym oderwaniu od reszty zespołu, zwykle na początku i na końcu projektu, i nawet jeśli przedstawiciel działu Security pojawia się na spotkaniach i bezpośrednio współpracuje z programistami, to zabezpieczenia nie są projektowane i wdrażane na bieżąco, tylko po zakończeniu kolejnych etapów prac – to powoduje, że odkryte luki czy bugi są naprawiane wolniej (w późniejszym czasie) i jest to bardziej kosztowny proces. Biorąc pod uwagę świetne wyniki po połączeniu dwóch działów – dlaczego nie zrobić tego z jeszcze jednym? W ten sposób, po powstaniu DevSecOps, bezpieczeństwo zostało wpisane na stałe we wszystkie etapy życia projektu – od samego pomysłu do dostarczenia gotowego produktu. Dzięki temu w każdym momencie security jest obecne i jest odpowiedzialnością wspólną, a nie tylko dedykowanego zespołu – problemy są rozwiązywane zaraz po tym, jak się pojawiają, co zmniejsza koszty i przyspiesza ogólne prace. Kod jest analizowany pod względem bezpieczeństwa przez cały czas i może być poprawiony od razu, na wczesnym etapie powstania ewentualnej luki.
Jakie są dobre praktyki DevSecOps?
Należy pamiętać, że człon „Sec” zostaje dodane do istniejącego pipeline’u DevOps, dlatego zasady zapewnienia bezpieczeństwa nie mogą być takie same, jak do tej pory – zmiana jest konieczna, bo przecież stąd powstała metodyka DevSecOps, że działy Security nie nadążały za pracami nad oprogramowaniem w starym modelu, zwłaszcza w chmurze. Wdrażanie i trening DevSecOps powinny odbywać się w zgodzie z istniejącymi już procesami i pipeline CI/CD (ang. Continuous Improvement/Continuous Deployment) oraz wykorzystywanymi narzędziami programistów, a nie na odwrót. Przynosi to świetne rezultaty, zwłaszcza jeśli postawimy na automatyzację – testy bezpieczeństwa są wykonywane jeszcze sprawniej, ponieważ duża ich część jest powtarzalna i można je ubrać w proces, także z wykorzystaniem inteligentnej automatyzacji.
Bardzo bliska współpraca pomiędzy działami niesie za sobą wielkie korzyści także w temacie edukacji. Teza, że w modelu DevSeOps bezpieczeństwo to odpowiedzialność wspólna, pozwala na trening wszystkich zaangażowanych, aby posiadali wiedzę wystarczającą do podejmowania decyzji zgodnie z wcześniej ustalonymi zasadami Security i tymi samymi standardami. Testy i ich wyniki powinny być przeprowadzane w istniejącym środowisku DevOps – być z nim zintegrowane i, tak jak wspomnieliśmy, zautomatyzowane w jak największym stopniu oraz przeprowadzane na bieżąco. Wymaga to zmiany nie tylko w sposobach użycia narzędzi, ale także w podejściu programistów i ekspertów do spraw bezpieczeństwa do ich własnej pracy. Jest to wyzwanie same w sobie dla organizacji wdrażającej DevSecOps, jednak jest bardzo wartościowe.
Narzędzia DevSecOps
Idąc za tropem zestawienia SANS Institute, instytutu wydającego certyfikaty bezpieczeństwa i oferującego kursy Cloud cybersecurity w USA, narzędzia DevSecOps powinny być jak najprostsze w integracji z istniejącymi narzędziami CI/CD oraz mieć opcję jak największej możliwości automatyzacji. Aby zapewnić najwyższy poziom bezpieczeństwa tworzonych aplikacji, w trakcie rozwoju oprogramowania dobrze zwrócić się do znanych rodzajów narzędzi testowania poziomu bezpieczeństwa i wiedzieć, kiedy ich używać: SAST (statyczne skanery aplikacji, ang. Static Application Security Testing), SCA (skanery analizy składu oprogramowania, ang. Software Composition Analysis) i DAST (dynamiczne skanery aplikacji, ang. Dynamic Application Security Testing). Prócz tego, istnieją narzędzia do śledzenia i zarządzania zgłoszeniami i konfiguracją, do komunikacji, weryfikacji środowiska oraz narzędzia używane już po wdrożeniu aplikacji, takie jak RASP (ochrona własna aplikacji w czasie pracy, ang. Runtime Application Self-Protection), które chronią aplikacje w czasie rzeczywistym ich działania. Wdrożenie rozwiązań DevSecOps zdecydowanie ułatwi także przetwarzanie bezserwerowe, czyli Serverless.
Jak zostać DevSecOps?
Przede wszystkim trzeba zdać sobie sprawę, że bycie DevSecOps Engineer wiąże się z dużą wszechstronnością oraz nieustannym rozwojem, żeby być w stanie nadążyć za zmianami we wszystkich obszarach – programowania, utrzymania oraz bezpieczeństwa. Praca w tym charakterze jest zwykle związana z częstymi zmianami projektów, więc zdarza się, że pomiędzy jednym a drugim konieczna jest nauka innych narzędzi czy języków i wykorzystywanych technologii. Znajomość kodowania pozwoli DevSecOpsowi na łatwiejsze komunikowanie się z zespołem oraz wykonywanie niektórych czynności samodzielnie, tak samo obycie w środowiskach chmurowych, np. AWS, oraz wiedza o praktykach ciągłej integracji i ciągłego dostarczania (CI/CD). DevSecOps jest łącznikiem pomiędzy deweloperami, ekspertami bezpieczeństwa oraz zespołem operacyjnym, powinien więc poruszać się swobodnie i być w stanie monitorować, komunikować oraz koordynować działania między nimi.
Gdzie uczyć się na DevSecOps?
Pierwszym, najbardziej oczywistym krokiem są studia – DevSecOps wiąże się z pracą w obszarach cyberbezpieczeństwa, a to wymaga kwalifikacji i sporej wiedzy technicznej, dlatego pracodawcy zwykle skupiają się na kandydatach z taką historią edukacji, jak informatyka czy cyberbezpieczeństwo. Samej osobie zainteresowanej takie kierunki na pewno pomogą w dalszej nauce potrzebnej do zostania DevSecOps, dostarczając już podstawy i najważniejszą wiedzę. Kursy także są w cenie – najbardziej pożądane i efektywne będą oficjalne certyfikaty.
Trzeba pamiętać, że znaczna większość DevSecOpsów nie zaczyna pracy od razu w tej roli. Zwykle potrzebne jest doświadczenie na różnych stanowiskach, zwłaszcza że sama rola DevSecOps wymaga znajomości innych obszarów, niż tylko samo cyberbezpiecześntwo – wspomnieliśmy już programowanie, pisanie kodu, ale także mocne kompetencje miękkie (komunikacja, praca z zespołem na różnych płaszczyznach) czy umiejętności oceny ryzyka i modelowania zagrożeń. Te wszystkie wymagania określają dojrzałego i doświadczonego pracownika, gotowego do przejęcia roli DevSecOps.
Kiedy firma potrzebuje DevSecOps?
Rozwiązania chmurowe i przyspieszenie prac deweloperskich przez DevOps stworzyły już lukę pomiędzy świetnymi wynikami zespołów a pracami ekspertów bezpieczeństwa, które są przeprowadzane późno i generują większe koszty. Tak naprawdę, jeśli chcemy nadążyć za obecnym tempem rozwoju i zniwelować wspomniane problemy oraz ograniczyć cyberzagrożenia, powinniśmy zacząć przejście do modelu DevSecOps jak najszybciej. Dzięki niemu firma jest zdecydowanie bardziej chroniona a oprogramowanie szybciej dostarczane i bezpieczne – koniec końców jest również tańsze, ponieważ Security działa na każdym etapie jego rozwoju, a nie z opóźnieniem. Możemy śmiało stwierdzić, że w dzisiejszych czasach DevSecOps jest potrzebne każdemu, kto chce nadążyć za szybko zmieniającymi się realiami i wykorzystywać w pełni potencjał swojej organizacji.
Porozmawiajmy!
a my pomożemy Ci wdrożyć najnowsze rozwiązania!
Podobne wpisy:
Zarządzanie projektem wdrożenia w warunkach pandemii cz.2
DMS (Document Management Software) – czym jest system zarządzania dokumentami oraz kiedy twoja firma będzie go potrzebowała?
Zarządzanie Big Data, czyli jakie wyzwania stawiają przed nami obszerne zbiory danych?
Business Process a Workflow, czyli procesy biznesowe kontra przepływy pracy – czym tak naprawdę są i jakie są główne różnice?