Wygląda, że wszystko jest w porządku, systemy są na bieżąco skanowane i patchowane wg wydań producentów, kontrola dostępu do wszystkiego jest, o! nawet MFA jest, programiści nie mają roota ani lokalnego admina.
No.. może czasem mają, ale niewielu i zaraz im się tego zakaże (napiszemy oficjalne pismo!). Na stacjach końcowych liczba agentów od różnego bezpieczeństwa wciąż rośnie. Wszystko jest logowane do dzienników zdarzeń (SIEM!). Komponenty devopsowe są co jakiś czas upgrade-owane, a same aplikacje są potem i skanowane na podatności, a nawet pentestowane. Ponad to, jeżeli aplikacja przetwarza PII to jest cała lista wymagań dla takiej aplikacji, jak internet-facing to jeszcze dłuższa, itd. Oprócz tego, wszystkie zmiany i incydenty (w rozumieniu IT) są w JIRze, włamań nie było. No jest Ok, chyba, nie?
No nie jest, to powyżej - to perspektywa klasycznego bezpiecznika, który zresztą od tego jest.
Czego bezpiecznik nie widzi
Z obserwacji i prac w różnych projektach, na przestrzeni ostatnich paru lat, wyciągnąłem pewne nauki (a nawet nauczki!). Szczegóły techniczne to jedno, ale technologia jest wtórna, wobec pryncypiów, które jeśli nie są odpowiednio wdrożone i wypracowane, to cały ten devops będzie dość bolesnym doświadczeniem. Bowiem, to wdrożone i wypracowane dobre praktyki, zidentyfikowane i wyeliminowane “anty-wzorce” postępowania (ang. antipatterns), ustawiczne doskonalenie tych pryncypiów w praktyce, decydują o sukcesie i bezpieczeństwie całego ekosystemu jak i produktów końcowych - aplikacji.
-
Silosy - Codzienna współpraca wielu ról i współodpowiedzialność. Współodpowiedzialność to trudne słowo i dość trudno-realizowalna koncepcja, szczególnie dla słabo-socjalizujących się programistów, introwertycznych i paranoidalnych bezpieczników, wiecznie niezadowolonych adminów i zespołów wsparcia traktowanych przez wszystkich trochę jak dzieci gorszego boga - a to podstawowy warunek sukcesu devopsowego ekosystemu. Jeśli nawet zaczynamy od zera to w organizacji zazwyczaj obowiązuje tradycyjne podejście IT, gdzie są programiści, gdzie są architekci, gdzie są bezpiecznicy, operacje - admini wszelkich usług, baz danych i OSów, a wszystko to w otoczce departamentów, działów, managerów i dyrektorów. Są też procesy IT.. ooo, co to, to nie! Bez procesów to wiadomo, co by audyt powiedział (albo pewna organizacja na K). Nawet jeśli programiści jadą wg którejś z metodyk Agile, ba! jeśli inne zespoły też sobie wdrożyły i LEANa i Agile i co tam jeszcze, to wiele to nie pomoże. Sukces całego procesu wytwórczego w postaci dobrej jakościowo (odporna architektura, funkcjonalność, bezpieczeństwo, skalowalność, itd.) zależy od bieżącej, intensywnej i codziennej współpracy. Ta codzienna współpraca dopiero generuje właściwy przepływ informacji, wiedzy i doświadczeń z sukcesów i porażek w danym projekcie.
-
Procesy i rutyna - te tradycyjne, nazwijmy je ITILowe i te Agile’owe. Te pierwsze osiadłe w organizacji, rutynowo wykonywane, rutynowo przeglądane i audytowane i te nowe, zwinne. Okazuje się, że to co działa w tych pierwszych poprawnie (bo projekty jadące sobie waterfallem wprost zbierają ludzi z różnych działów, którzy nad tymże projektem potem pracują), niekoniecznie działa w tych zwinnych, w dodatku umocowanych mocno do koncepcji devopsa. Biznes jest od tego by wymagać i robić awantury jeśli dostawy nie są na czas. Albo jak coś nie działa. Oni przynoszą pieniądze firmie, które IT przecież przejada, więc to nie IT ma od biznesu czegoś wymagać, tylko odwrotnie. Dla przykładu, słaba pozycja architektów IT, którzy w popularnym odczuciu, siedzą gdzieś tam i od 17 lat próbują odkodować ukryte przekazy pozaziemskiej cywilizacji z TOGAFa - przyczyn może być wiele, np. nieprecyzyjne uwzględnienie tej roli w projekcie, gdzie siłą przyzwyczajeń biznes przychodzi do analityka biznesowego IT, a ten leci od razu do programistów z tematem CO biznes chce i co więcej - JAK chce. Innym przykładem jest rola zespołów wsparcia. Nie uczestniczą w projekcie rozwoju aplikacji wg devopsa, aplikacja jest wydawana i zespoły tradycyjnie z playbookami w garści obsługują incydenty (ale używając JIRy, żeby nie było!). Jeśli w dodatku, tak się dzieje w każdym z iluś-tam projektów aktywnie realizowanych, a działo się tak w iluś-tam projektach wcześniejszych, gdzie aplikacje nie są aktywnie rozwijane, to ogólny pejzaż funkcjonowania DevOpsa przypomina ćwiczenia w terenie wyższej szkoły pożarnictwa.
O ile nasz “przysłowiowy” bezpiecznik zdaje sobie sprawę, zapewne w jakiej organizacji pracuje, to sądzę, że nie ma najmniejszych szans wpaść na to, gdzie naprawdę tkwią słabości takiego devopsa, który wyrósł bezpiece pod bokiem, a co więcej - jakie właściwe podatności niesie to za sobą dla organizacji i jakie ryzyka biznesowe mogą z tym być związane. Oba te zjawiska powodują, że do praktycznej realizacji manifestów Agile, DevOps i DevSecOps daleka droga.
w następnym wpisie rozwinę oba wątki, jak to dokładnie w DevOpsie może wyglądać i jakich to podatności i ryzyk nie widzi bezpieka.