Пока все спорят о том, какая модель лучше всего пишет код, гораздо более старая и куда менее гламурная проблема незаметно масштабируется вместе с каждым новым ИИ-центром обработки данных: контроллер управления базовой платой, или BMC. На этой неделе исследователи безопасности представили результаты, согласно которым тысячи подключённых к интернету серверов крупных производителей можно удалённо превратить в бэкдор через уязвимости в этих контроллерах — некоторым из этих уязвимостей уже больше десяти лет. Это вовсе не история об ИИ. Это история об оборудовании, на котором работает ИИ, и её стоит понять, если вы размышляете о том, откуда появится следующая волна рабочих мест в сфере безопасности, связанной с ИИ.

Что такое BMC на самом деле и почему это опасно

BMC — это небольшой отдельный компьютер, припаянный практически к каждой материнской плате корпоративного сервера. Он работает под управлением собственной операционной системы, использует собственный сетевой стек и имеет собственный IP-адрес — совершенно независимо от ОС и приложений, работающих на основном сервере. Администраторы используют BMC для управления «без участия оператора» или «вне диапазона»: чтобы перезагрузить машину, перепрошить микропрограмму, переустановить ОС — всё удалённо и, что особенно важно, даже когда основной сервер выключен или полностью не отвечает.

Именно это делает скомпрометированный BMC настолько опасным. Атакующему, проникшему в него, не нужно, чтобы гостевая ОС была запущена, не нужно обходить установленную на ней защиту конечных точек, и он может сохраняться после переустановки ОС, поскольку BMC находится ниже и за пределами того уровня, который отслеживают обычные средства ИТ-безопасности. Согласно исследованию, о котором говорили на этой неделе, чаще всего фигурирует протокол IPMI, а исследователи безопасности предупреждают об этом классе рисков как минимум с 2013 года. Иными словами, это не новая ошибка, а старая, известная и структурно трудноустранимая категория уязвимостей, которую отрасль терпит уже значительно больше десяти лет.

Почему сейчас это важнее, а не менее важно

Развёртывание ИИ — это в физическом смысле одна из крупнейших волн закупки серверов в истории: стойки за стойками серверов с GPU отправляются в новые и расширяемые центры обработки данных так быстро, как поставщики успевают их отгружать. Каждый такой сервер поставляется с BMC, потому что именно BMC позволяют операторам центров обработки данных управлять парками устройств в больших масштабах; невозможно войти в здание размером со склад и вручную перезагрузить десять тысяч машин. Поэтому бум ИИ означает не только закупку вычислительных ресурсов — он по необходимости означает закупку сопоставимого по размеру парка небольших, недостаточно контролируемых компьютеров для внеполосного управления, у которых имеется задокументированная история критических уязвимостей длиной более десяти лет.

Вот что представляет собой технический долг: темпы развёртывания оптимизированы под установку GPU в стойки и запуск обучения, а не под аудит встроенной в каждую материнскую плату микропрограммы, которая находится под ними. Исследователи, стоящие за раскрытием информации на этой неделе, по сообщениям, назвали BMC «повсеместной, недостаточно контролируемой и недостаточно пропатченной параллельной поверхностью атаки» — это описание появилось ещё до бума ИИ-центров обработки данных, но именно нынешний бум прямо сейчас многократно увеличивает число BMC в эксплуатации.

Ниша, которая при этом открывается

Если вы пытаетесь понять, куда движется карьера в сфере безопасности параллельно с ИИ-инфраструктурой, большинство очевидных направлений — повторное тестирование моделей, защита от инъекций промптов, управление агентами — уже переполнены и хорошо освещены в других местах. Аудит безопасности оборудования и внеполосного управления — нет. Это неприметный и непрестижный уголок инфраструктурной безопасности, который не появляется в программных докладах об ИИ, и именно в этом заключается возможность: спрос растёт с каждым новым центром обработки данных, а людей, понимающих поверхности атак на уровне микропрограмм и внеполосного управления, мало, потому что это действительно другой набор навыков по сравнению с безопасностью приложений или облака.

Как эта работа выглядит на практике:

  • Грамотность в области микропрограмм и протоколов. Понимать IPMI (и его известные слабые места — например, давно устаревший набор шифров 0, который на некоторых устройствах до сих пор включён) настолько хорошо, чтобы оценить, подвержен ли риску конкретный парк серверов, а не просто уязвим ли он теоретически.
  • Аудит сетевой сегментации. Проверять, действительно ли интерфейсы BMC/управления изолированы в выделенной сети управления или же к ним можно получить доступ из производственной сети либо из общего интернета — это базовый контроль, отсутствие которого снова и снова выявляется на практике.
  • Проверка учётных данных и своевременности установки исправлений. BMC часто поставляются с учётными данными по умолчанию или заданными производителем, а их микропрограмма не входит в обычный цикл установки обновлений ОС в центре обработки данных, поскольку это не ОС — поэтому она легко оказывается вне зоны ответственности того, кто отвечает за «установку исправлений».
  • Знание поставщиков и цепочек поставок. Микропрограммы BMC обычно пишутся небольшим числом специализированных поставщиков и лицензируются производителям серверов, поэтому ошибка в коде одного поставщика может одновременно распространиться на множество брендов оборудования — именно это и произошло в раскрытии информации на этой неделе. Знание того, какой стек микропрограммы используется под каждым брендом серверов, — часть работы.

Как на самом деле подготовить себя к этому направлению

Это действительно нишевая область, и вполне справедливо скептически относиться к тому, сколько отдельных штатных позиций для неё откроется, а сколько она останется специализацией внутри уже существующих команд инфраструктуры или безопасности — честно признайте, что «аудитор безопасности BMC» в итоге может оказаться навыком, который вы добавите к более широкой роли в сфере безопасности оборудования и центров обработки данных, а не самостоятельной должностью. Но в любом случае имеют смысл несколько конкретных шагов, которые можно проверить: получите практический опыт работы с IPMI и инструментами внеполосного управления, если у вас есть доступ к корпоративным серверам или хотя бы к подержанному оборудованию для лаборатории; изучайте рекомендации поставщиков по безопасности микропрограмм BMC от крупных производителей серверов и микропрограмм BMC, поскольку они публикуют реальные сведения об уязвимостях, которые можно анализировать; а если вы уже работаете в сфере безопасности облачной или инфраструктурной среды, начните задавать команде своей организации, отвечающей за центр обработки данных или закупку оборудования, простой проверяемый вопрос: находится ли наша плоскость управления BMC/IPMI в изолированной сети и кто отвечает за установку исправлений? Если никто не может уверенно ответить, это не просто выявленная проблема — это демонстрация именно той экспертизы, в которой нуждается эта ниша.