Dlaczego Blokowanie Homebrew Pogarsza Stan Bezpieczeństwa

W pewnym momencie życia większości korporacyjnych organizacji IT ktoś podejmuje decyzję o zablokowaniu Homebrew. Powód jest różny — nieudany audyt, incydent związany z bezpieczeństwem, raport o podatnościach. Obawa jest uzasadniona: niezarządzane oprogramowanie na komputerach programistów to realne ryzyko, a instynkt, by coś z tym zrobić, jest jak najbardziej słuszny.

Problem nie polega na celu. Chodzi o narzędzie. Całkowita blokada Homebrew nie zapewnia nadzoru, jaki obiecuje. W praktyce przekształca widoczne, potencjalnie możliwe do zarządzania ryzyko w niewidoczne, zdecydowanie niezarządzane ryzyko — tworząc jednocześnie koszty i martwe punkty, których pierwotna decyzja rzadko bierze pod uwagę.

Drogi Ucieczki, Które Wybierają Programiści — W Ciągu Kilku Dni

Gdy Homebrew zostaje zablokowany, programiści nie przestają instalować oprogramowania. Przestają instalować oprogramowanie przez kanał, który widzi dział IT.

Alternatywy są liczne i łatwo dostępne. Alternatywne menedżery pakietów, które działają wyłącznie w przestrzeni użytkownika, bez uprawnień administratora i bez żadnego śladu widocznego dla narzędzi MDM. Menedżery wersji specyficzne dla języka, które pobierają pliki binarne środowiska uruchomieniowego bezpośrednio z publicznych repozytoriów — brak centralnego menedżera pakietów, punktu kontroli zasad i wpisów w logach. Budowanie ze źródła: sklonowanie publicznego repozytorium, uruchomienie skryptu budującego, przeniesienie pliku binarnego do lokalnego katalogu. Wynik jest funkcjonalnie identyczny z instalacją zarządzaną przez pakiety, ale nie pozostawia żadnego zapisu o jej wystąpieniu. Konteneryzowane środowiska programistyczne, w których rzeczywisty łańcuch narzędzi pracy programisty działa wewnątrz kontenera, do którego dział IT nie ma żadnego wglądu. W skrajnym przypadku: osobisty laptop działający obok firmowego komputera, całkowicie odizolowany od zarządzania przez dział IT.

Każda z tych dróg ucieczki jest racjonalną reakcją na tępe ograniczenie. Programiści nie mają złych intencji; mają pracę do wykonania i znajdą na to sposób. Konsekwencją dla bezpieczeństwa jest to, że IT ma teraz mniejszy wgląd w to, co działa na komputerach programistów, niż miało przed zablokowaniem Homebrew. Zarządzany, audytowalny kanał został zastąpiony asortymentem niezarządzanych i nieaudytowanych.

To nie są hipotezy. To się dzieje w organizacjach, które blokują Homebrew, rutynowo i przewidywalnie, zazwyczaj w ciągu pierwszych dwóch tygodni od wdrożenia blokady.

Iluzja Bezpieczeństwa

Blokada Homebrew tworzy pozory kontroli. Zespoły ds. bezpieczeństwa mogą powołać się na zasady podczas następnego audytu. Logi MDM pokazują, że blokada jest aktywna. Sprawa zostaje zamknięta.

Ale pytanie, na które ma odpowiedzieć polityka bezpieczeństwa, nie brzmi „czy polityka istnieje?” Brzmi „czy ryzyko zostało zmniejszone?” To są różne pytania, a w tym przypadku odpowiedź na to drugie jest często przecząca — lub co gorsza, odwrotna.

Istotne pytanie dotyczące bezpieczeństwa nie brzmi „czy zablokowaliśmy ten wektor?”, ale „czy mamy wgląd w ten wektor?”. Wgląd jest tym, co sprawia, że ryzyko można zarządzać. Bez tego organizacje nie mogą wykryć, kiedy zainstalowano coś niebezpiecznego, nie mogą zareagować na nowo opublikowane luki CVE wpływające na pakiety w ich flocie, nie mogą sporządzić spisu oprogramowania, o który ostatecznie poprosi audytor.

Flota deweloperów korzystająca z Homebrew za pośrednictwem zarządzanego, audytowanego kanału jest środowiskiem mniej ryzykownym niż flota deweloperów korzystająca z zestawu niezarządzanych alternatyw. W pierwszym przypadku organizacja wie, co zostało zainstalowane. W drugim nie wie. Świadomość ryzyka to warunek wstępny do zajęcia się nim.

Podobna analogia dotyczy innych dziedzin. Blokowanie firmowej poczty e-mail, aby zapobiec phishingowi, nie sprawia, że organizacja staje się bezpieczniejsza — pracownicy obchodzą to, korzystając z osobistych kont, a dział IT traci wgląd w to, co się dzieje. Powierzchnia ataku nie uległa zmniejszeniu. Po prostu się przeniosła.

Koszt Produktywności

Koszty zablokowania Homebrew nie są abstrakcyjne, ale łatwo je źle obliczyć.

Po skonfigurowaniu przez programistę obejścia blokady codzienne nakłady są niskie. Prawdziwym kosztem nie jest cotygodniowe utrudnienie — to nagromadzenie jednorazowych kosztów konfiguracji, które powtarzają się częściej, niż się wydaje. Nowy programista dołącza: od dwóch do trzech dni z czasu onboardingu zajmuje konfiguracja łańcucha narzędzi, która powinna zająć jedno popołudnie. Inżynier podejmuje nowy projekt, który wymaga narzędzia, którego wcześniej nie potrzebował: kolejne kilka godzin konfiguracji obejścia, biletów do działu pomocy technicznej lub czekania na IT. Aktualizacja systemu macOS przerywa konfigurację obejścia: kolejna godzina na debugowanie, która nie ma nic wspólnego z faktyczną pracą.

Te zdarzenia zdarzają się rzadko w przypadku jednego inżyniera, ale w 50-osobowym zespole jakaś ich wersja zdarza się w każdym tygodniu. Całość się sumuje i nic z tego nie pojawia się w żadnej linii budżetowej związanej z decyzją dotyczącącą bezpieczeństwa, która je spowodowała.

Niektóre stanowiska płacą wyższą, ciągłą cenę. Badacze bezpieczeństwa, inżynierowie danych i inżynierowie uczenia maszynowego regularnie sięgają po nowe narzędzia jako element ich normalnego trybu pracy — nowy framework analityczny, dekompilator protokołu, narzędzie CLI, które dobrze wykonuje jedną rzecz. W przypadku tych stanowisk każde nowe zapotrzebowanie na narzędzie staje się wydarzeniem zakupowym. To tarcie nie jest katastrofalne, ale jest uporczywe i zniechęcające w sposób, w jaki rzadko bywa rutynowe utrudnienie pracy.

Wymiar Talentów

Inżynierowie wymieniają się opiniami. Recenzje w Glassdoor, prywatne społeczności na Slacku, rozmowy na korytarzach konferencji — środowiska narzędzi dla deweloperów są dyskutowane, a organizacje z restrykcyjnymi zyskują sobie opinię. „Ich dział IT blokuje wszystko” nie jest obojętną daną podczas podejmowania decyzji przez kandydata. Jest to sygnał na temat kultury organizacyjnej i filozofii zarządzania, który ma wpływ na akceptację bądź odrzucenie oferty pracy.

Koszt zastąpienia odchodzącego starszego inżyniera to zazwyczaj równowartość jego wynagrodzenia za od sześciu do dwunastu miesięcy — opłaty za rekrutację, czas przeznaczony na rozmowy kwalifikacyjne, proces wdrażania, przepaść w produktywności między jego odejściem a pełnym powrotem do optymalnej wydajności. Organizacja, która traci dwóch starszych inżynierów rocznie częściowo z powodu frustracji narzędziami — ostrożne szacunki dla 50-osobowego zespołu inżynierów w restrykcyjnym środowisku — płaci 300 000 do 600 000 USD rocznie za te odejścia, oprócz powyższych strat wydajności.

Nie jest to argument za tym, że polityka bezpieczeństwa powinna być zakładnikiem preferencji programistów. Ma to na celu wykazanie, że decyzja o zablokowaniu Homebrew nie jest darmowa. Ma ona koszty, które należy rozważyć w stosunku do korzyści z punktu widzenia bezpieczeństwa — a w większości przypadków, kiedy te koszty są uczciwie zliczane i porównywane z faktycznie osiągniętą redukcją ryzyka (co, jak opisano powyżej, często jest ujemne), analiza nie wspiera tej decyzji.

Co Oznacza "Zarządzane" — i Dlaczego to Różni Się od "Zablokowane"

Alternatywą dla blokowania Homebrew nie jest pozwolenie na nieograniczoną instalację bez nadzoru. Jest to status quo, który blokada ma na celu poprawić i jest autentycznie niewystarczający. Alternatywą jest zarządzany Homebrew: instalacja za pośrednictwem kanału, który zapewnia widoczność w czasie rzeczywistym, ocenę CVE, egzekwowanie polityk i logowanie audytów.

W środowisku zarządzanym każde zdarzenie brew install jest przechwytywane w momencie, gdy ma miejsce za pośrednictwem lekkiej architektury proxy: jaki pakiet, jaka wersja, jaka maszyna, jaki użytkownik i o jakiej porze. Status CVE jest oceniany względem żądanej wersji przed zakończeniem instalacji. Pakiety o znanych krytycznych lukach bezpieczeństwa mogą być blokowane w momencie podejmowania działań — nie samo narzędzie, ale konkretne pakiety stanowiące rzeczywiste ryzyko. Polityka może być zróżnicowana ze względu na zespół lub stanowisko: bardziej surowe kontrole dla wykonawców, luźniejszy dostęp dla badaczy bezpieczeństwa, którzy w sposób uzasadniony potrzebują określonych narzędzi. Zgłoszenia wyjątków są obsługiwane za pośrednictwem szybkiego, udokumentowanego przepływu pracy ze ścieżką audytu, a nie za pomocą nieoficjalnych negocjacji czy zgłoszeń do działu pomocy technicznej, których rozwiązanie zajmuje dni.

Doświadczenie deweloperów w tym środowisku jest niemal identyczne, jak w przypadku niezarządzanego Homebrew. Polecenia są te same; obieg pracy jest ten sam; zdecydowana większość instalacji przebiega bez tarć. Deweloperzy nie mają powodu, by to obchodzić, ponieważ ograniczenia, które napotykają — jeśli w ogóle je spotykają — są ukierunkowane, wytłumaczalne i towarzyszy im wyraźna, bezproblemowa ścieżka do uzyskania wyjątku, jeśli ograniczenie jest błędne.

Przemianie ulega środowisko IT i bezpieczeństwa. Organizacja wie, co jest zainstalowane w całej flocie, w czasie rzeczywistym. Powiadomienia CVE generują informacje przydatne do podjęcia działań na temat maszyn, których to dotyczy, a także o użytkownikach, którzy zainstalowali pakiet podatny na ataki. Żądania audytu opierają się na danych z eksportu zamiast konieczności ręcznego śledztwa.

Argument Audytowy, Odwrócony

Najczęstszym uzasadnieniem blokowania Homebrew jest audyt. Audytor pyta o sposób kontrolowania instalacji oprogramowania na komputerach deweloperów; rozwiązaniem ma być zablokowanie instalacji. Ta odpowiedź ma jednak słabsze uzasadnienie niż można to sobie wyobrazić.

Audytorzy — w szczególności ci pracujący w ramach takich struktur jak SOC 2, ISO 27001 czy PCI DSS — są coraz lepiej zorientowani w narzędziach dla deweloperów. Całkowita blokada, która spycha instalację do podziemia, nie jest mechanizmem kontrolnym, który spełnia podstawowe wymagania; to mechanizm, który ukrywa problem. Audytorzy, którzy rozumieją sytuację, zadadzą pytania uzupełniające: skąd wiesz, co faktycznie zostało zainstalowane? Co się dzieje, gdy deweloper stosuje metodę alternatywną? Gdzie są dowody na usunięcie luk CVE?

Mocniejsza odpowiedź wygląda inaczej: mamy log wszystkich instalacji pakietów w całej flocie z ostatnich 90 dni, na bieżąco uzupełniany o wskazanie użytkownika i status CVE w momencie instalacji. Poniżej znajduje się raport przefiltrowany ze względu na obecność podatności o statusie krytycznym. A to dokument polityki opisujący zablokowane pakiety z opisem sposobu przeprowadzania ewentualnych wyjątków, oraz historią ich akceptacji. Audytorzy, którzy otrzymają takie zestawienie danych, rozumieją, że organizacja dysponuje rzetelną wiedzą na temat istniejącego ryzyka. Nie stwarza po prostu pozorów posiadania kontroli.

Podsumowanie

Organizacje dobrze radzące sobie z kwestiami bezpieczeństwa narzędzi stosowanych przez programistów reorientują się w określony sposób. Zaprzestają stawiania pytań w rodzaju „w jaki sposób zniechęcić programistów od posługiwania się Homebrew?”, a zamiast tego pytają: „co zrobić, żeby w toku posługiwania się tym narzędziem podlegało ono kontroli, umożliwiało audytowanie instalacji oprogramowania, jego testowanie oraz wdrażanie wewnętrznej polityki zarządzania narzędziami programistycznymi?”.

To nie są te same pytania i nie przyniosą takich samych odpowiedzi. Odpowiedź na to pierwsze zapytanie polega w istocie na prostej propozycji odcięcia danego menadżera zasobów, a tego rodzaju pomysł bywa przyczyną jeszcze szerszego zbioru problematycznych konsekwencji. Konieczne inwestycje ze strony zarządzającego sferą IT to konieczność powiązania z drugim ze stanowisk. Pociągnie ona jednak za sobą szereg rezultatów wprost niedostępnych po uruchomieniu pierwszego kroku, to znaczy rzeczywisty wgląd w funkcjonowanie środowisk roboczych poszczególnych deweloperów oraz zdolność do reagowania na pojawiające się niepokojące lub niesprawdzone zdarzenia.

Blokada Homebrew jest tylko złudzeniem kontroli. Z kolei udostępnienie administrowanego Homebrew gwarantuje realizację celów stawianych wyżej wspomnianej decyzji o wykluczeniu.