Podczas gdy wszyscy spierają się o to, który model najlepiej pisze kod, znacznie starszy i o wiele mniej efektowny problem po cichu narasta wraz z każdym nowym centrum danych AI: kontroler zarządzania płytą główną, czyli BMC. W tym tygodniu badacze bezpieczeństwa przedstawili wyniki wskazujące, że tysiące serwerów największych producentów podłączonych do internetu można zdalnie wyposażyć w tylne furtki za pośrednictwem błędów w tych kontrolerach — niektóre z tych luk mają ponad dekadę. To wcale nie jest historia o AI. To historia o sprzęcie, na którym działa AI, i warto ją zrozumieć, jeśli zastanawiasz się, skąd nadejdzie kolejna fala miejsc pracy związanych z bezpieczeństwem na styku z AI.

Czym właściwie jest BMC i dlaczego budzi obawy

BMC to mały, oddzielny komputer przylutowany do praktycznie każdej płyty głównej serwera klasy enterprise. Działa na własnym systemie operacyjnym, korzysta z własnego stosu sieciowego i ma własny adres IP — całkowicie niezależnie od systemu operacyjnego i aplikacji uruchomionych na głównym serwerze. Administratorzy używają BMC do zarządzania „lights-out” lub „out-of-band”: ponownego uruchamiania maszyny, ponownego zapisywania oprogramowania układowego, reinstalowania systemu operacyjnego — wszystko zdalnie i, co kluczowe, nawet gdy główny serwer jest wyłączony lub zupełnie nie odpowiada.

To właśnie sprawia, że przejęty BMC jest tak niebezpieczny. Atakujący, który uzyska do niego dostęp, nie potrzebuje uruchomionego systemu operacyjnego hosta, nie musi obchodzić zainstalowanych na nim zabezpieczeń punktów końcowych i może utrzymać się w systemie mimo reinstalacji systemu operacyjnego, ponieważ BMC znajduje się poniżej warstwy obserwowanej przez zwykłe narzędzia bezpieczeństwa IT i poza nią. Zgodnie z badaniami omawianymi w tym tygodniu najczęściej wskazywanym protokołem jest IPMI, a badacze bezpieczeństwa zwracają uwagę na tę klasę zagrożeń co najmniej od 2013 roku. Innymi słowy: to nie jest nowy błąd, lecz stara, znana i strukturalnie trudna do naprawienia kategoria błędów, którą branża toleruje od well over a decade.

Dlaczego ma to teraz większe, a nie mniejsze znaczenie

Rozbudowa infrastruktury AI jest fizycznie jedną z największych fal zakupów serwerów w historii — całe rzędy serwerów GPU trafiają do nowych i rozbudowywanych centrów danych tak szybko, jak dostawcy są w stanie je wysyłać. Każdy z tych serwerów jest dostarczany z BMC, ponieważ to właśnie BMC pozwalają operatorom centrów danych zarządzać flotami na dużą skalę; nie można wejść do budynku wielkości magazynu i ręcznie zrestartować dziesięciu tysięcy maszyn. Boom na AI oznacza więc nie tylko zakup mocy obliczeniowej — z konieczności oznacza także zakup porównywalnej liczebnie floty małych, niedostatecznie monitorowanych komputerów działających poza pasmem, z udokumentowaną, sięgającą ponad dekady historią krytycznych podatności.

To właśnie jest dług techniczny: tempo rozbudowy jest zoptymalizowane pod kątem umieszczenia GPU w szafach i rozpoczęcia trenowania, a nie audytowania oprogramowania układowego zarządzania wbudowanego w każdą znajdującą się pod nimi płytę główną. Badacze stojący za ujawnieniem z tego tygodnia mieli podobno określić BMC jako „wszechobecną, niedostatecznie monitorowaną i niedostatecznie aktualizowaną równoległą powierzchnię ataku” — opis, który powstał jeszcze przed boomem na centra danych AI, ale to właśnie ten boom zwielokrotnia obecnie liczbę produkcyjnych BMC.

Nisza, która się dzięki temu otwiera

Jeśli analizujesz kierunki rozwoju karier w obszarze bezpieczeństwa równolegle z infrastrukturą AI, większość oczywistych ścieżek — red teaming modeli, obrona przed prompt injection, zarządzanie agentami — jest już zatłoczona i dobrze opisana gdzie indziej. Audyty bezpieczeństwa sprzętu i działania poza pasmem — nie. To mało efektowny, pozbawiony blasku zakątek bezpieczeństwa infrastruktury, który nie pojawia się w przemówieniach otwierających konferencje o AI, i właśnie na tym polega luka: popyt rośnie wraz z każdym nowym centrum danych, a liczba osób rozumiejących powierzchnie ataku na poziomie oprogramowania układowego i poza pasmem jest niewielka, ponieważ jest to rzeczywiście inny zestaw umiejętności niż bezpieczeństwo aplikacji czy chmury.

Jak ta praca wygląda w praktyce:

  • Znajomość oprogramowania układowego i protokołów. Rozumienie IPMI (i jego znanych słabych punktów — takich jak wycofany już dawno zestaw szyfrów 0, który na niektórych urządzeniach wciąż jest domyślnie włączony) na tyle dobre, by ocenić, czy dana flota serwerów jest narażona, a nie tylko teoretycznie podatna.
  • Audyty segmentacji sieci. Sprawdzanie, czy interfejsy BMC/zarządzania są rzeczywiście odizolowane w dedykowanej sieci zarządzania, czy też można uzyskać do nich dostęp z sieci produkcyjnej albo z ogólnego internetu — jest to podstawowe zabezpieczenie, którego w praktyce wciąż często brakuje.
  • Przeglądy higieny poświadczeń i aktualizacji. BMC często są dostarczane z domyślnymi lub ustawionymi przez producenta danymi uwierzytelniającymi oraz oprogramowaniem układowym, które nie jest objęte zwykłym cyklem aktualizacji systemu operacyjnego w centrum danych, ponieważ nie jest systemem operacyjnym — łatwo więc może wypaść poza zakres odpowiedzialności osoby lub zespołu zajmującego się „aktualizacjami”.
  • Świadomość dostawców i łańcucha dostaw. Oprogramowanie układowe BMC jest zwykle tworzone przez niewielką liczbę wyspecjalizowanych dostawców i licencjonowane producentom serwerów, więc luka w kodzie jednego dostawcy może jednocześnie rozprzestrzenić się na wiele marek sprzętu — dokładnie taki schemat opisano w ujawnieniu z tego tygodnia. Wiedza o tym, jaki stos oprogramowania układowego znajduje się pod daną marką serwera, jest częścią tej pracy.

Jak właściwie przygotować się do tej ścieżki

To rzeczywiście niszowa dziedzina i uzasadnione jest sceptyczne podejście do tego, ile dedykowanych etatów powstanie, zamiast pozostania tej specjalizacji w ramach istniejących zespołów infrastruktury lub bezpieczeństwa — bądź ze sobą szczery: „audytor bezpieczeństwa BMC” może ostatecznie okazać się umiejętnością dodawaną do szerszej roli związanej z bezpieczeństwem sprzętu i centrów danych, a nie samodzielnym stanowiskiem. Niezależnie od tego sens ma kilka konkretnych i weryfikowalnych działań: zdobądź praktyczne doświadczenie z IPMI i narzędziami zarządzania poza pasmem, jeśli masz dostęp do serwerów klasy enterprise albo nawet używanego sprzętu do stworzenia laboratorium; czytaj komunikaty bezpieczeństwa dostawców dotyczące oprogramowania układowego BMC od głównych producentów serwerów i oprogramowania układowego BMC, ponieważ publikują oni rzeczywiste informacje o ujawnionych podatnościach, które możesz analizować; a jeśli już zajmujesz się bezpieczeństwem chmury lub infrastruktury, zacznij zadawać zespołowi swojej organizacji odpowiedzialnemu za centra danych lub zakupy sprzętu proste, weryfikowalne pytanie — czy nasza płaszczyzna zarządzania BMC/IPMI znajduje się w odizolowanej sieci i kto odpowiada za jej aktualizowanie? Jeśli nikt nie ma pewnej odpowiedzi, nie jest to tylko ustalenie, lecz demonstracja dokładnie tej wiedzy specjalistycznej, której potrzebuje ta nisza.