Każdy z nas uwielbia śledzić rywalizacje sportowe. Emocje związane z oglądaniem Mundialu, zmagań siatkarzy, skoczków narciarskich czy piłkarzy ręcznych są nie do opisania. Można powiedzieć, że jesteśmy wręcz mistrzami w dziedzinie kibicowania i uważnego obserwowania postępów i sukcesów naszych drużyn. Jednak trochę inaczej sprawa wygląda, kiedy próbujemy się aktywnie w sport angażować.
Pewnego dnia zacząłem się zastanawiać nad podobieństwami między sportem a światem oprogramowania, a w szczególności tymi pojawiającymi się w użytecznym i dość popularnym procesie DevOps. Olśniło mnie! Jeżeli na świecie istnieje jedna rzecz, która ze sportem nie ma nic wspólnego, to na pewno jest to metodyka DevSecOps. Dlaczego? Już spieszę z przykładami i wyjaśnieniem.
1. Nie da się zwalić winy na bramkarza
Wybaczcie, że zacznę od przykładu tak konkretnego, jednak jest on mi bardzo bliski – głównie dlatego, że w latach szkolnych kończyłem zwykle jako bramkarz, a tej funkcji nikt przecież nie lubił. Gdy piłka przelatywała czy wręcz przetaczała się obok mnie – i w konsekwencji lądowała w siatce – za sytuację taką zawsze obwiniano mnie. Nie tylko jest to sytuacja o beznadziejnym wpływie na zespołowe morale, nie powinna być ona bowiem również postrzegana jako odzwierciedlenie funkcjonowania zespołu.
Co mam na myśli? Zawsze jestem ostrożny, kiedy spotykam się ze stwierdzeniem, że „w DevSecOps za bezpieczeństwo odpowiadają wszyscy”. Nie każdy jest ekspertem od bezpieczeństwa, jednak każdy powinien brać choć trochę odpowiedzialności za zrozumienie prawidłowości procesów i za postępowanie zgodnie z jej założeniami. W momencie, gdy coś pójdzie nie po naszej myśli, winy nie należy nigdy zrzucać na ramiona jednej osoby. I nie zapominajmy jeszcze o jednej kwestii: DevSecOps każdorazowo daje szansę na naprawę tego, co poszło nie tak, naprawa ta jest szybka, a następnie ma miejsce wdrożenie testów, które pozwolą na upewnienie się, że ta wrażliwość systemu nie będzie nigdy więcej narażona na atak.
2. Nie wiadomo, kim jest przeciwnik
W sporcie zwykle jasna jest tożsamość adwersarza, jego położenie oraz to, co dany zawodnik w danym momencie robi. Może nie będziecie w stanie zawsze go zatrzymać, ale przynajmniej wiadomo, kim on jest i jaki jest jego cel, czyli co próbuje osiągnąć.
W przypadku DevSecOps powyższe nie ma miejsca, sytuacja taka występuje jeszcze rzadziej niż w świecie normalnych projektów programistycznych. Dzieje się tak, ponieważ jako zespół zajmujecie się opracowywaniem, testowaniem i wykorzystaniem warstw systemu, natomiast Wasi oponenci mogą reprezentować różny poziom umiejętności, mogą też korzystać z różnych zasobów.
Kluczowe jest tu „zespołowe” podejście do sprawy. Jeżeli wdrażacie prawdziwą pracę zespołową, połączona wiedza ekspercka może być używana w wielu warstwach abstrakcji, na sposoby zwykle trudno osiągalne w standardowym modelu programistycznym: „design, develop, test, deploy”. To z kolei daje Wam szerszy i głębszy wgląd w sposoby zwiększenia bezpieczeństwa projektu.
3. Nie gracie na zasadach takich samych jak Wasz przeciwnik
To dość trudna kwestia. W sporcie istnieją zasady, zgodnie z którymi postępować muszą obie strony. W przeciwnym razie strona, która je złamie, musi liczyć się z konsekwencjami nakładanymi przez sędziego, arbitra bądź innego oficjela.
Oczywiście miło byłoby żyć w świecie, gdzie strona atakująca zawsze będzie schwytana i karana (w momencie, gdy podejmie ona kroki zmierzające do ataku infrastruktur lub aplikacji), jednak póki co nic nie wskazuje na to, że taka bajkowa rzeczywistość wkrótce nastąpi. Biorąc pod uwagę mało prawdopodobny scenariusz, w którym adwersarza będziemy „gonić” w czasie rzeczywistym w ramach aktywnego kontrataku, rozważyć trzeba to, jakie możemy wdrożyć środki łagodzące, jak je stosować, i jak szybko można je wprowadzić do działania.
Co istotne, nie może być to obszar pozostawiony do dyspozycji wyłącznie ekspertom zespołu bezpieczeństwa. Mimo iż są oni w stanie przewidzieć prawdopodobne ataki, to kluczowy personel inżynieryjny i operacyjny najlepiej nadaje się do przewidywania potencjalnego wpływu ataku na działanie systemu. To te zespoły powinny projektować odpowiednie środki łagodzące, do przeciwdziałania problemom.
4. W grę zaangażowany jest cały zespół – za każdym razem przez cały czas
W większości gier zespołowych drużyna nigdy nie znajduje się w całości na boisku, korcie czy lodowisku. Jedną z zalet działań DevSecOps jest możliwość zaangażowania wszystkich członków zespołu w cały proces. Trener nie musi przebywać poza boiskiem. W działania można zaangażować psychologa, eksperta od wyników czy specjalistów od techniki, gdy tylko zaistnieje taka potrzeba.
Każdy z członków zespołu wnosi swój wkład w rozwój oprogramowania, w miarę pojawiania się zmian w aplikacji, środowisku wdrożenia czy w krajobrazie bezpieczeństwa. Zespoły DevSecOps nie powinny być izolowane od innych działów firmy: jeżeli trzeba je przez jeden lub dwa dni zaangażować, nie wahajmy się tego zrobić. Nie bójmy się wykonywania szybkich ruchów i przyznawania się do tego, że potrzebujemy pomocy.
5. Porażki są OK – i to w dużych ilościach
Gdy myślimy o zmaganiach sportowych, bardzo wiele emocji poświęcamy zwycięstwu naszych zespołów w każdym spotkaniu. W zasadzie jednak najlepsi sportowcy i najlepsze sportowe drużyny wiedzą również jak przegrywać, a przede wszystkim jak przekuć porażkę na późniejsze sukcesy.
W DevSecOps powinniśmy kibicować naszym zespołom, jednak z intencją odniesienia przez nie porażek – częstych i szybkich. Nasze aplikacje i projekty można usprawnić tylko poprzez doświadczenie i obserwowanie błędów. Nikt nie wierzy w nieśmiertelność systemów lub aplikacji: nie należy zadawać pytania, czy będziemy obiektem ataku lub włamań, tylko kiedy do tego dojdzie. Wasze procesy projektujcie w taki sposób, aby można było szukać zachowań odbiegających od normy. Bądźcie gotowi na łagodzenie ich skutków. Należy także upewnić się, że istnieją procesy, które pozwolą ocenić, co poszło nie tak, a co za tym idzie zbudować nową wersję projektu – lepszego, solidniejszego i odporniejszego.
Kilka słów podsumowania
No dobrze, nie będę udawać, że między DevSecOps i sportem nie ma żadnych podobieństw. Naturalnie istnieje wiele wspólnych cech między nimi. Niektóre z bardziej oczywistych przykładów: jak znaczące zmiany wymagają odgórnego zobowiązania, jak i oddolnego zaangażowania; istota budowania zespołu, którego członkowie będą w stanie się między sobą sprawnie komunikować; zdolność do reakcji na zagrożenia w czasie rzeczywistym.
Skąd zatem pomysł na niniejszy artykuł? Celem ostatecznie nie było ograniczenie się do podania różnic. Czasami dogłębne zrozumienie istoty danego zjawiska czy problemu jest możliwe dzięki porównaniu czegoś do rzeczy, która pozostaje odwrotnością, a nie jest jego odpowiednikiem. Mam nadzieję, że ten artykuł choć w pewnym stopniu pozwolił zrozumieć metodykę DevSecOps.
Autor: Mike Bursell, Chief Security Architect, Red Hat