Tak jak kiedyś programiści i operacje przerzucali między sobą odpowiedzialność, tak do niedawna było z DevOps i bezpieczeństwem. Historia pokazuje, że można się porozumieć i współdziałać, a pierwsze sygnały zmian w tym obszarze są już widoczne. DevSecOps jest już blisko.
Rozmowa z Michałem Ciemięgą, Regional Sales Managerem Poland, Ukraine, Adriatics and Baltics oraz Bartoszem Kryńskim, pracującym jako Solutions Engineering Team Leader w Polsce, Ukrainie, krajach Bałtyckich oraz Adriatyckich w CyberArk, CISSP.

 

Choć coraz częściej słychać o DevSecOps, to jednak czyste DevOps nadal dobrze funkcjonuje. Czy security stało się dziś nieodłącznym elementem DevOps?

Michał Ciemięga: Powinno się stać. Jeszcze jakiś czas temu te dwa światy były od siebie zupełnie oderwane. Bezpieczeństwo nie rozumiało DevOps, a programiści i administratorzy wykorzystywali to trochę i przekonywali, żeby za bardzo nie ingerować w ich pracę, bo przestanie to dobrze działać. Zespoły DevOps nie były zainteresowane bezpieczeństwem, ponieważ obawiały się nadmiernej kontroli i ograniczenia swobody działania. Sytuacja systematycznie się jednak zmienia na lepsze.

Bartosz Kryński: Faktycznie do tej pory Zespoły Bezpieczeństwa nie ingerowały bezpośrednio w DevOps, bo ani nie miały odpowiednich ku temu narzędzi ani procesów. Nie funkcjonowała rozliczalność. Programiści i administratorzy obawiali się, że security będzie im nieustannie patrzyło na ręce.
Trzeba jednak powiedzieć, że to się zmieniło. Można to dostrzec między innymi na tegorocznym DevOps@Enterprise Forum. Nasze rozmowy z Zespołami DevOps potwierdzają, że potrzeba budowania wspólnego świata DevSecOps jest znacznie większa niż jeszcze dwa czy nawet rok temu. Kiedyś niejeden raz słyszeliśmy opinię „nie potrzebujemy centralizacji” czy też „nie widzimy dla niej uzasadnienia”. Dzisiaj dużo częściej słyszymy „bezpieczeństwo to wspólna odpowiedzialność”. Zwłaszcza, że tak łatwo przeprowadzać dzisiaj skuteczne ataki.

Rozumiem, że świadomość jest większa, ale czy praktyka nadąża. Jak wygląda codzienna praktyka w tym zakresie?

Bartosz Kryński: Według mnie jesteśmy jeszcze na początku tej drogi. Dostrzegamy dobre chęci i zmianę nastawienia. DevOps zaczyna dyskutować o bezpieczeństwie, nie tylko wąsko, w kontekście kontrolowania zewnętrznych deweloperów, ale w szerokim spektrum spojrzenia na środowisko. Wszyscy zaczęli bowiem dostrzegać, że do bezpieczeństwa trzeba podchodzić kompleksowo. Wszystkie klocki muszą być poukładane i pasować do siebie. Nie może być luk.
Myślę, że częściowo ta zmiana to efekt migracji do chmury, która wymusiła zmianę sposobu myślenia o bezpieczeństwie. Nie mamy już tylko własnych lokalnych centrów danych, na których wszyscy się skupiali. Ich zabezpieczenie było stosunkowo łatwe – zarówno technicznie jak i procesowo. Dzisiaj dane i aplikacje są praktycznie wszędzie a użytkownicy łączą się z różnych lokalizacji, nie koniecznie tak bezpiecznych jak sieć wewnętrzna organizacji. Zabezpieczenie takiego środowiska to poważne wyzwanie. Widać, że wszyscy zaczęli o tym myśleć. Uruchamiają nowe inicjatywy, poszukuje się specjalistów od zabezpieczania DevOps oraz środowisk chmurowych.

Michał Ciemięga: Trzeba jednak powiedzieć, że w niewielu firmach udało się dotychczas wdrożyć pełen wspólny program DevSecOps. Zespoły deweloperskie nadal budują własne strategie ochrony aplikacji oraz środowisk, za które odpowiadają.
Tym bardziej zachęcamy organizacje do skorzystania z naszej zupełnie darmowej usługi, która polega na wsparciu w przygotowaniu długofalowego programu cyberbezpieczeństwa. Powstająca w jej wyniku roadmapa nie jest oparta na żadnych konkretnych produktach. Dotychczas pomogliśmy przygotować takie programy kilkuset klientom w regionie i żaden z nich nie powiedział, że był to stracony czas. Podobnie menedżerowie odpowiedzialni za bezpieczeństwo i DevOps wspólnie z nami mogą wypracować program, który pozwoli im współdziałać. Można oczywiście powiedzieć, że to bezpieczeństwo ostatecznie za to odpowiada. Prawda jest jednak taka, że bez udziału DevOps to się nie uda.
Wracając do praktyki, to kluczowe jest, żeby zacząć wspólnie rozmawiać. Nie o produktach, ale zasadach, politykach, długofalowym programie. Bez tego nie ma sensu nawet zaczynać dyskusji o narzędziach.

Czy brak współpracy to główna trudność w związku z bezpieczeństwem w kontekście DevOps?

Michał Ciemięga: Nie powiedziałbym, że to jest problem. Trudnością byłby brak świadomości, a powiedzieliśmy, że ona się pojawiła. Wyzwaniem jest natomiast brak wiedzy na temat kolejnego kroku, jaki trzeba wykonać. Mało kto wie co trzeba zrobić, żeby osiągnąć kompletne bezpieczeństwo w nowoczesnej organizacji.

Bartosz Kryński: Z pewnością trzeba współpracować i rozmawiać, żeby określić kto jest za co odpowiedzialny. Jednym z przykładów może być zarządzanie sekretami. Nie jest to jedyny obszar do zabezpieczenia, ale dosyć ważny. W narzędziach, kodzie oprogramowania, w pamięci współdzielonej między różnymi serwisami mamy porozrzucane i często niezarządzane centralnie różne sekrety zarówno ludzi jak i maszyn. Kto powinien być za to odpowiedzialny, na przykład za nadawanie uprawnień dostępowych oraz za rotację sekretów? Naturalnym pierwszym kierunkiem jest bezpieczeństwo, jednak praktyka jest taka, że specjaliści od cyberbezpieczeństwa nie do końca wiedzą jak działają systemu i co powinno korzystać z danego sekretu. Gdy zadajemy bardziej dociekliwe pytania, na przykład: jak chronimy poszczególne systemy, jak Jenkins czy Kubernetes, często security nic o tym nie wie. Z drugiej strony, jeśli powierzymy odpowiedzialność wyłącznie DevOps, to każdy będzie implementował zabezpieczenia zgodnie z własnym pomysłem – lepszym lub gorszym. Dlatego potrzebna jest współpraca oraz wypracowany kompromis. DevOps jest bezpośrednio odpowiedzialne za bezpieczeństwo, bo wie jak to działa, z drugiej strony Sec musi wiedzieć i widzieć kto i jak zmienia politykę w konkretnym zakresie. Coraz więcej klientów zmierza w tym kierunku.

Czy wszystko o czym mówimy to raczej kwestia narzędzi i metodyki czy bardziej kultury organizacyjnej?

Michał Ciemięga: Zdecydowanie bardziej kultury organizacyjnej. DevOps to nowy obszar i ta kultura cały czas się rozwija. W tradycyjnych organizacjach, infrastrukturach było inaczej. Nowe podejście do tworzenia i dostarczania usług wymaga przedefiniowania całego podejścia.

Bartosz Kryński: Podobnie było z utrzymaniem aplikacji i baz danych dekadę temu. Kiedy nie było DevOps programiści i administratorzy przerzucali między sobą odpowiedzialność. Dzisiaj widać, że udało się to zmienić. Podobnie będzie z bezpieczeństwem.

Michał Ciemięga: Z pewnością problemem nie jest technologia. My jako dostawcy rozwiązań cyberbezpieczeństwa jesteśmy gotowi, żeby te dwa światy ze sobą połączyć.

Jak zatem włączyć DevOps do strategii ochrony przedsiębiorstwa? Od czego zacząć?

Bartosz Kryński: Jak zwykle trzeba zacząć od planowania. Nie zaczynamy budowy domu od wbijania łopaty, ale do projektu architektonicznego. Im więcej zaplanujemy na początku, tym lepiej, tym mniej niespodzianek będziemy mieli później.
My specjalizujemy się w ochronie tożsamości. To niezwykle istoty obszar cyberbezpieczeństwa. Każda tożsamość musi być chroniona w sposób spójny i równie skuteczny. Co z tego, że będziemy chronić bardzo dobrze jeden obszar, na przykład zapewnimy doskonałą ochronę w zakresie jednego zespołu deweloperskiego? Intruzom wystarczy jedna gorzej zabezpieczona tożsamość (czy to pracownika, partnera biznesowego, zewnętrznego dewelopera), żeby wejść do środowiska i zacząć się w nim skutecznie przemieszczać. Dlatego trzeba zacząć od zaplanowania wspólnej strategii bezpieczeństwa nie tylko na miesiące, ale lata. Po potwierdzeniu takiego planu na wyższym poziomie, trzeba go zacząć wdrażać.
Jeśli tego nie będzie, to skończymy z punktowymi rozwiązaniami. Możemy mieć wiele nowoczesnych technologii zabezpieczeń w środowisku, ale bez odpowiedniej unifikacji i centralnego podejścia nie przyniesie to oczekiwanych efektów.

Michał Ciemięga: Współpracujemy z wieloma firmami w regionie i na świecie. Mamy doświadczenie w budowaniu długofalowych planów cyberbezpieczeństwa. Od czego zacząć? Proponujemy spotkanie z nami, w gronie DevOps i Security. Nie narzucamy konkretnych rozwiązań, nie sprzedajemy, o produktach w ogóle nie rozmawiamy podczas tworzenia planu. Analizujemy i staramy się pomóc w budowie programu, który zadziała w danym przypadku i środowisku. Każdy element tego programu konsultujemy ze wszystkim stronami. Jest to darmowa usługa. Czy po opracowaniu tego planu klient chce dalej z nami współpracować, czy ma własną wizje na narzędzia – to już zupełnie inna historia. Dajcie więc nam szansę, spotkajmy się, aby zaplanować strategię i wykonać pierwszy krok.