Miközben mindenki azon vitatkozik, melyik modell írja a legjobb kódot, egy sokkal régebbi és jóval kevésbé látványos probléma csendben növekszik minden új AI-adatközponttal együtt: az alaplap-kezelővezérlő, vagyis a BMC. Biztonsági kutatók ezen a héten olyan eredményeket mutattak be, amelyek szerint jelentős gyártók több ezer internethez kapcsolódó szerverét lehet távolról hátsó ajtóval ellátni az ezekben a vezérlőkben található hibákon keresztül — egyes sérülékenységek több mint egy évtizedesek. Ez egyáltalán nem az AI-ról szóló történet. Arról a hardverről szól, amelyen az AI fut, és érdemes megérteni, ha azon gondolkodsz, honnan érkezik majd az AI-hoz kapcsolódó biztonsági állások következő hulláma.

Mi is valójában a BMC, és miért ijesztő

A BMC egy kis, különálló számítógép, amelyet gyakorlatilag minden vállalati szerver alaplapjára ráforrasztanak. Saját operációs rendszert és saját hálózati vermet futtat, valamint saját IP-címe van — teljesen függetlenül attól, hogy milyen operációs rendszer és alkalmazások futnak a fő szerveren. A rendszergazdák a BMC-ket „lights-out” vagy „out-of-band” kezelésre használják: egy gép újraindítására, a firmware újraírására, az operációs rendszer újratelepítésére, mindezt távolról, és ami kritikus, akkor is, amikor a fő szerver ki van kapcsolva vagy teljesen nem reagál.

Pontosan ettől olyan veszélyes egy feltört BMC. A támadónak, aki bejut egy ilyenbe, nincs szüksége arra, hogy a gazdagép operációs rendszere fusson, nem kell megkerülnie az azon telepített végpontbiztonságot, és az operációs rendszer újratelepítése után is fennmaradhat, mivel a BMC az alatt a réteg alatt és azon kívül helyezkedik el, amelyet a szokásos informatikai biztonsági eszközök figyelnek. Az ezen a héten tárgyalt kutatás szerint a leggyakrabban érintett protokoll az IPMI, és a biztonsági kutatók legalább 2013 óta jelzik ezt a kockázati kategóriát. Másképpen fogalmazva: ez nem új hiba, hanem egy régi, ismert, szerkezetéből adódóan nehezen javítható hibakategória, amelyet az iparág jóval több mint egy évtizede eltűr.

Miért fontosabb ez most, és nem kevésbé

Az AI-kiépítés fizikailag a történelem egyik legnagyobb szerverbeszerzési hulláma: GPU-szerverek sorai kerülnek új és kibővített adatközpontokba olyan gyorsan, ahogy a gyártók szállítani tudják őket. Minden egyes ilyen szerver BMC-vel érkezik, mert a BMC-k teszik lehetővé, hogy az adatközpontok üzemeltetői nagy léptékben kezeljék a gépparkokat; nem lehet besétálni egy raktár méretű épületbe, és kézzel újraindítani tízezer gépet. Az AI-boom tehát nem csupán számítási kapacitást vásárol — szükségszerűen ugyanekkora flottát vásárol kis, alulmegfigyelt, out-of-band számítógépekből is, amelyeknél dokumentáltan több mint egy évtizede jelen vannak a kritikus sérülékenységek.

Ez a technikai adósság: a kiépítés sebességét arra optimalizálják, hogy a GPU-k a rackekbe kerüljenek és elinduljanak a tanítási futtatások, nem pedig arra, hogy auditálják az alattuk lévő minden alaplapba beágyazott kezelési firmware-t. A kutatók, akik a heti közzététel mögött állnak, állítólag „mindenütt jelen lévő, alulmegfigyelt, aluljavított párhuzamos támadási felületként” írták le a BMC-ket — ez a leírás megelőzi az AI-adatközpontok boomját, de éppen ez a boom sokszorozza meg most a termelésben lévő BMC-k számát.

A megnyíló szűk szakterület

Ha feltérképezed, merre tartanak a biztonsági karrierek az AI-infrastruktúrával párhuzamosan, a legtöbb kézenfekvő terület — a modellek red teamingje, a promptinjektálás elleni védelem, az ügynökök irányítása — már zsúfolt, és máshol már alaposan lefedik. A hardver- és out-of-band-biztonsági auditálás nem ilyen. Ez az infrastruktúrabiztonság nem túl látványos, nem túl vonzó szeglete, amely nem jelenik meg az AI-ról szóló előadásokon, és pontosan ez benne a rés: a kereslet minden új adatközponttal növekszik, miközben kevés az olyan ember, aki érti a firmware-szintű és out-of-band támadási felületeket, mert ez valóban más készségkészlet, mint az alkalmazás- vagy felhőbiztonság.

Konkrétan ilyen a munka:

  • Firmware- és protokollismeret. Az IPMI (és ismert gyenge pontjainak — például a régóta elavult 0-s titkosítási csomagnak, amelyet egyes eszközök még mindig engedélyezve szállítanak) olyan szintű ismerete, amely elegendő annak felméréséhez, hogy egy adott szerverflotta ténylegesen ki van-e téve a kockázatnak, nem csupán elméletben sérülékeny.
  • Hálózati szegmentálási auditok. Annak ellenőrzése, hogy a BMC-/kezelési interfészek valóban elkülönülnek-e egy dedikált kezelési hálózaton, vagy elérhetők-e a termelési hálózatból, illetve az általános internetről — ez egy alapvető kontroll, amelyről a gyakorlatban újra és újra kiderül, hogy hiányzik.
  • Hitelesítőadat- és javításkezelési felülvizsgálatok. A BMC-ket gyakran alapértelmezett vagy a gyártó által beállított hitelesítő adatokkal, valamint olyan firmware-rel szállítják, amely nem része az adatközpont szokásos operációsrendszer-javítási ciklusának, mert ez nem az operációs rendszer — így könnyen kívül marad azon, hogy ki felel a „javításért”.
  • Gyártói és ellátásilánc-ismeret. A BMC-firmware-t általában néhány specialista gyártó írja, majd licenceli a szervergyártóknak, ezért az egyik gyártó kódjában található hiba egyszerre sok hardvermárkára is kiterjedhet — pontosan ez a minta rajzolódik ki az e heti közzétételben. A munka része annak ismerete, hogy melyik szervermárkában melyik firmware-verem található.

Hogyan pozicionáld magad ténylegesen erre

Ez valóban szűk szakterület, ezért jogos szkeptikusnak lenni azzal kapcsolatban, hány kifejezetten erre létrehozott állás nyílik majd, ahelyett hogy a terület a meglévő infrastruktúra- vagy biztonsági csapatokon belüli specializáció maradna — légy őszinte magaddal: a „BMC-biztonsági auditor” végül inkább olyan készség lehet, amelyet egy szélesebb hardver-/adatközpont-biztonsági szerepkörhöz adsz hozzá, nem pedig önálló munkakör megnevezése. Ettől függetlenül néhány konkrét, ellenőrizhető lépésnek mindenképpen van értelme: szerezz gyakorlati tapasztalatot az IPMI-vel és az out-of-band kezelési eszközökkel, ha hozzáférsz vállalati szerverekhez, vagy akár laborozásra alkalmas használt hardverhez; olvasd a jelentős szerver- és BMC-firmware-gyártók BMC-firmware-rel kapcsolatos biztonsági tájékoztatóit, mivel valós sérülékenységi közzétételeket publikálnak, amelyeket tanulmányozhatsz; és ha már felhő- vagy infrastruktúrabiztonságban dolgozol, kezdd el feltenni a saját szervezeted adatközponti vagy hardverbeszerzési csapatának ezt az egyszerű, ellenőrizhető kérdést: elkülönített hálózaton van-e a BMC-/IPMI-kezelési síkunk, és ki felel a javításáért? Ha senkinek nincs magabiztos válasza, az nem csupán egy megállapítás, hanem annak bemutatása is, hogy pontosan milyen szakértelemre van szüksége ennek a szűk területnek.