Polityka bezpieczeństwa jako dokument Word
Typowa organizacja technologiczna ma politykę bezpieczeństwa. Opisuje co wolno, a czego nie. Wymagania dotyczące konfiguracji kontenerów — brak uprawnień root, zdefiniowane limity zasobów, brak obrazów z tagiem latest. Wymagania dotyczące sieci — brak otwartych portów bez uzasadnienia, szyfrowanie w tranzycie. Wymagania dotyczące deploymentu — zatwierdzenie przez uprawnioną osobę, automatyczne testy, logi zmian.
Problem z dokumentem: nikt go nie weryfikuje przy każdym deployment. Developer który w pośpiechu konfiguruje kontener nie zawsze sięga po 40-stronicowy dokument polityki. Reviewer code review skupia się na logice biznesowej, nie na parametrach bezpieczeństwa konfiguracji. Audytor zobaczy naruszenie — ale dopiero przy następnym audycie, który może być za rok.
Przestrzeń między polityką a jej egzekwowaniem
Ta przestrzeń — między tym co polityka mówi a tym co faktycznie trafia na produkcję — jest miejscem gdzie narodzą się incydenty bezpieczeństwa. Nie dlatego że ktoś ma złe intencje. Dlatego że ludzkie procesy weryfikacji nie skalują się z prędkością wytwarzania oprogramowania.
Organizacja która deployuje kilkanaście razy dziennie nie jest w stanie manualnie weryfikować zgodności każdego deploymentu z polityką bezpieczeństwa. Albo weryfikacja jest automatyczna — albo jej nie ma.
Policy-as-Code jako zmiana modelu
Policy-as-Code to podejście polegające na zakodowaniu polityk bezpieczeństwa w formie wykonywalnego kodu i automatycznym ich weryfikowaniu przy każdym deployu, każdej zmianie konfiguracji, każdym zasobie tworzonym w infrastrukturze.
Open Policy Agent (OPA, projekt CNCF) jest jednym z najpowszechniej używanych silników do tego celu. Pozwala zdefiniować politykę (“żaden kontener nie może być uruchamiany jako root”) i automatycznie weryfikować każdy zasób Kubernetes przed jego uruchomieniem. Naruszenie polityki skutkuje odmową uruchomienia — z komunikatem opisującym co należy zmienić.
Wynik: polityka przestaje być dokumentem. Staje się właściwością systemu — egzekwowaną automatycznie, przy każdej operacji, bez wyjątków i bez możliwości pominięcia przez zapomnienie lub pośpiech.
Gdzie policy-as-code ma największy sens
Największa wartość pojawia się przy kontrolach które są obiektywnie weryfikowalne i wysokiego ryzyka: konfiguracja security context kontenerów, dostęp do sekretów, polityki sieciowe, wymagania dotyczące obrazów bazowych. To kontrole gdzie automatyczna weryfikacja jest zarówno możliwa jak i krytyczna.
Polityki które wymagają kontekstu i oceny — np. czy dana architektura decyzja jest odpowiednia — pozostają domeną code review przez człowieka. Policy-as-Code nie zastępuje myślenia inżynierskiego. Zastępuje te weryfikacje które są mechaniczne, powtarzalne i zbyt ważne żeby zależeć od czyjejś uwagi w danym momencie.
Czytaj również: