#aqua security

Aqua Security różni się od narzędzia przeglądającego obraz przed uruchomieniem miejscem, w którym stoi. Przegląd zawartości odpowiada na pytanie, co zostało zapakowane, i kończy pracę w chwili, gdy paczka rusza. Ta platforma zajmuje się drugą stroną startu: czy proces uruchomiony z tej paczki robi to, co wynikało z jej zawartości, i co zrobić, kiedy zacznie robić coś innego.

Warto od razu rozdzielić dwie rzeczy noszące tę samą nazwę. Aqua Security to producent, założony w 2015 roku, sprzedający platformę ochrony aplikacji chmurowych. Obok niej ta sama firma rozwija narzędzia otwarte, z których Trivy jest jednym z najpopularniejszych programów bezpieczeństwa w ogóle, a Tracee stanowi silnik obserwacji stojący pod komercyjnymi funkcjami.

Mechanizm najłatwiej zobaczyć na przykładzie transportu. Przy bramie zakładu ktoś zestawia list przewozowy z tym, co faktycznie stoi na naczepie, i albo wypuszcza pojazd, albo go zatrzymuje. W trasie pracuje natomiast rejestrator wpięty w silnik, a nie w notes kierowcy: zapisuje obroty, postoje i zużycie niezależnie od tego, co kierowca wpisze do papierów. Dwa różne punkty kontroli, dwie zupełnie różne rzeczy do wykrycia.

Odczyt spod kontenera

Rejestratorem wpiętym w silnik jest tutaj mechanizm jądra Linuksa pozwalający ładować do niego małe programy obserwujące, znany pod skrótem eBPF. Kontener jest odgrodzoną częścią jednego systemu, więc każde otwarcie pliku, uruchomienie procesu i nawiązanie połączenia i tak przechodzi przez to samo jądro. Program obserwujący siedzi właśnie tam, poniżej odgrodzenia.

Wynika z tego cecha, której nie da się uzyskać dzienników zbieranych wewnątrz kontenera. Proces, który podmienił własne narzędzia diagnostyczne i wyczyścił po sobie zapisy, nadal zostawia ślad na poziomie jądra, bo nie ma innej drogi do dysku i do sieci. Otwarty Tracee robi dokładnie to i sam w sobie jest narzędziem obserwacyjnym; platforma dokłada do niego reguły, korelację zdarzeń i możliwość zablokowania czynności, a nie tylko jej odnotowania. Ceną jest agent uruchamiany na każdym węźle klastra i zależność od wersji jądra, bo starsze dystrybucje ograniczają, co da się do niego załadować.

Dryf, czyli proces spoza obrazu

Tu leży reguła, której nie da się postawić przy zwykłym serwerze. Obraz kontenera jest niezmienny, a kontener startuje wyłącznie z jego zawartości. Jeżeli więc w działającym kontenerze uruchamia się plik wykonywalny, którego w obrazie nie było, to z definicji nie jest to aktualizacja ani czynność administratora, tylko coś dopisanego po starcie.

Wykrywanie takiej różnicy jest tanie, bo nie wymaga rozpoznawania, czym dopisany plik jest. Wystarczy, że nie ma go na liście. Ta sama logika obejmuje połączenia do adresów spoza wzorca ruchu danej aplikacji i próby sięgnięcia po uprawnienia, których obraz nie potrzebował. Nazywa się to dryfem i jest to jedyny sygnał w tej dziedzinie, który daje się egzekwować twardo, bez strojenia progów, bo opiera się na porównaniu z dokumentem, a nie na ocenie prawdopodobieństwa.

Bramka przed wpuszczeniem na klaster

Drugim punktem jest moment, w którym klaster dostaje polecenie uruchomienia obrazu. Żądanie przechodzi wtedy przez regułę sprawdzającą pochodzenie obrazu z zaufanego rejestru, obecność podpisu, brak podatności powyżej ustalonej wagi i to, czy proces nie chce startować z prawami administratora.

To jest miejsce, w którym wynik wcześniejszego przeglądu obrazu zaczyna cokolwiek znaczyć. Raport leżący w systemie budowania nikogo nie zatrzymuje, bo raport nie ma władzy. Reguła przy wpuszczaniu ma, i dlatego przenoszenie badań w tę stronę zmienia więcej niż dokupienie kolejnego skanera.

Gdzie kończy się część darmowa

Trivy jest samodzielnym programem wydanym jako otwarte oprogramowanie na licencji Apache i bada obrazy, katalogi z kodem, repozytoria, pliki opisujące infrastrukturę, a także działający klaster. Szuka w nich podatności w pakietach, błędnych ustawień, sekretów wpisanych do plików i licencji. Osobny operator uruchamia to cyklicznie wewnątrz klastra i zapisuje wyniki jako obiekty widoczne obok zwykłych zasobów. Wiele firm zna wyłącznie tę część zestawu i jest to użycie kompletne, niewymagające niczego od producenta.

Granica przebiega mniej więcej tam, gdzie kończy się czytanie plików, a zaczyna obserwowanie uruchomionych procesów. Egzekwowanie reguł w czasie działania, historia zdarzeń z wielu węzłów, ocena ustawień samego konta chmurowego i zestawienia pod audyt są częścią produktu płatnego.

Cena stałej obecności w jądrze

Agent ładowany do jądra każdego węzła staje się składnikiem, którego awaria dotyka wszystkiego, co na tym węźle stoi, więc jego aktualizacje planuje się jak aktualizacje systemu, a nie jak podmianę aplikacji. Druga sprawa to reguły blokujące: ustawione zbyt szeroko potrafią zatrzymać wdrożenie w piątek wieczorem, dlatego zwykle wchodzą najpierw w trybie samego zgłaszania, a przełączenie w tryb blokowania jest osobną decyzją i osobną datą.

Trzecia jest znana z każdego systemu wykrywającego. Zdarzenie bez odbiorcy nie chroni niczego, a platforma widząca wszystko produkuje materiał, którego objętość rośnie z każdym węzłem. Bez ustalenia, kto czyta zgłoszenia i co robi po ich przeczytaniu, zostaje bardzo dokładny zapis do przeglądania po fakcie.

Kiedy to za dużo narzędzia

Firma uruchamiająca kilka kontenerów na jednym serwerze nie ma klastra ani węzłów, więc cała warstwa bramek i agentów nie ma się o co zaczepić. Przegląd obrazu przy budowaniu, aktualne obrazy bazowe i porządek w dostępie do serwera dają tam większość możliwego efektu przy ułamku pracy.

Podobnie wygląda to przy aplikacjach stojących na maszynach wirtualnych bez konteneryzacji. Platforma zbudowana wokół niezmienności obrazu traci wtedy swój główny sygnał, bo na zwykłym serwerze pojawienie się nowego pliku wykonywalnego jest codziennością, a nie anomalią. Aqua Security nie zastępuje też kopii zapasowych ani porządku w dostępie do samego klastra, a przejęte konto administratora klastra jest problemem, którego żadna obserwacja procesów nie odwróci.