Российские центры обработки данных всё чаще рискуют стать жертвами киберфизической атаки через системы жизнеобеспечения: охлаждения, электропитания, диспетчеризацию здания и промышленные контроллеры. НВБС предупреждает, что злоумышленники могут искать вход не через хорошо защищенный ИТ-периметр, а через инженерные контуры, которые исторически проектировались для надёжности, а не для защиты от атак. Для современных ЦОДов это особенно опасно: высокая плотность оборудования и ИИ-кластеры не прощают сбои климат-систем и питания.
Системный интегратор и производитель технологических решений НВБС сообщил о смене вектора угроз для российских ЦОДов. Если серверный контур защищён межсетевыми экранами, сегментацией, мониторингом и отработанными процедурами реагирования, атакующий может искать менее очевидный маршрут — через инженерную инфраструктуру объекта.
В зоне риска оказываются системы промышленного охлаждения, электропитания, систему диспетчеризации здания BMS (Building Management System) и автоматизированную систему управления (АСУ). BMS управляет вентиляцией, температурой, энергопотреблением, датчиками, аварийными режимами и другим инженерным оборудованием. АСУ отвечает за контроллеры, датчики, исполнительные механизмы, SCADA и т.д. В ЦОДе такая система — часть критической инфраструктуры: от неё зависит, будут ли серверы вообще работать.
Проблема часто в архитектуре. Многие инженерные устройства и протоколы появились в эпоху, когда их отделяли от внешних сетей, а главным требованием была отказоустойчивость. Киберзащита, строгая аутентификация, журналы безопасности и сценарии расследования часто добавлялись позже — если добавлялись вообще. NIST в руководстве по безопасности промышленной инфраструктуры (OT — Operational Technology) относит к операционным технологиям не только промышленные системы, но и автоматизацию зданий, контроль физического доступа и мониторинг параметров среды.
Классический ИТ-периметр у крупных компаний за последние годы заметно окреп. Сегментация сети, EDR, SIEM, контроль привилегий, резервное копирование и реагирование на инциденты стали базой для зрелых организаций. Инженерные сети развивались иначе: их обслуживают другие команды, у них другой жизненный цикл оборудования и поставщики.
Для атакующего это удобная зона, слабое звено системы. В ИТ-сети он сталкивается с SOC, корреляцией событий и понятными правилами детекта. В OT-сегменте может оказаться устаревший контроллер, слабая аутентификация, открытый протокол, общий сервисный аккаунт или удалённый доступ для подрядчиков. НВБС отмечает, что слабая изоляция контроллера кондиционирования уже на пентестах подтверждает сценарий неочевидной точки входа в критически важные корпоративные системы.
Международные регуляторы описывают тот же класс проблем шире. CISA и партнёры в 2025 году выпустили руководство по инвентаризации OT-активов: без понимания, какие контроллеры, шлюзы, станции операторов и инженерные сервисы реально подключены к сети, организация не может нормально снижать риск и поддерживать непрерывность работы.
Опасный вариант — изменение параметров украдкой, незаметно. Например, злоумышленник получает доступ к инженерной диспетчеризации и меняет температурные пороги, режимы охлаждения или логику оповещений. Операторы видят инженерную аномалию, пытаются разобраться с кондиционированием, и в этот момент, «под шумок» как раз и происходит атака на серверный или прикладной контур.
НВБС считает киберфизическую атаку на ЦОД управляемым сценарием. Скрытый доступ может использоваться для изменения температурных порогов, ускоренного износа оборудования и отвлечения служб реагирования. Обычно это сочетание нескольких мелких действий: чуть поднять температуру, создать ложные срабатывания, перегрузить дежурную смену, скрыть сетевую активность за реальной инженерной проблемой.
Для дата-центра это болезненно, потому что инженерный сбой быстро становится ИТ-сбоем. Серверу всё равно, почему нарушился тепловой режим — из-за ошибки в проекте, отказа оборудования, неверной команды контроллеру или кибератаки. Итог один: деградация, аварийное выключение, потеря доступности сервиса, риск повреждения оборудования и данных.
Есть и ещё одна проблема — рост ИИ-нагрузок тоже меняет физику дата-центров. Плотность стоек растёт, а с ней и тепловыделение, запас по охлаждению сокращается. CNews в апреле уже публиковал оценку НВБС о риске массовых перегревов российских ЦОДов из-за ИИ-нагрузок: компания рекомендовала заранее закладывать жидкостное охлаждение и модернизированные схемы электропитания при строительстве и реконструкции таких площадок.
В новом сообщении НВБС отдельно указывает уровень 50–60 кВт на стойку как норму для высокоплотных ИИ-кластеров. Но при такой плотности небольшой сбой климатических условий может привести к аварийному отключению серверов или физическому повреждению оборудования.
Глобальная статистика тоже показывает, что доступность ЦОДов остаётся живой проблемой, даже когда общая частота серьёзных аварий снижается. Uptime Institute в отчёте 2025 года пишет, что предотвращение простоев остаётся стратегическим приоритетом для операторов, а сложность современных архитектур и внешние угрозы создают новые риски.
НВБС предлагает в качестве одного из решений кросс-системную аналитику: рост температуры, странная команда в контроллере и всплеск сетевой активности нужно анализировать как части одного сценария, а не как три независимых инцидента.
Одна из рекомендаций НВБС — жёсткая аппаратная OT-изоляция с применением «диодной логики». Смысл подхода: телеметрия свободно передаётся из инженерного контура наружу в мониторинг, но обратное дистанционное управление контроллерами извне физически блокируется.
Проще говоря, система мониторинга отслеживает температуру, состояние питания, аварийные сигналы и параметры оборудования. Но команда «измени режим», «переключи порог», «отключи узел» не должна прилетать обратно из ИТ-сети в контроллер без жесткого контроля.
Такой подход меняет модель доверия. Инженерный контур перестаёт быть обычным сетевым сегментом, куда можно зайти удаленно просто при наличии учетной записи. Он становится зоной, где право видеть и управлять разделены аппаратно и организационно.
Типовые слабые места ЦОДов:
-
Устаревшие протоколы без нормальной аутентификации,
-
Доступ подрядчиков через постоянные VPN,
-
Общие пароли,
-
Отсутствие инвентаризации контроллеров,
-
Слабая сегментация между ИТ и OT,
-
Недокументированные шлюзы,
-
Старые Windows-станции операторов,
-
Редкие обновления,
-
Отсутствие понятной процедуры реагирования.
Все это может стать тем самым уязвимым местом, через которое в систему проникнут злоумышленники и навредят ей.
CISA в материалах по OT делает акцент на базовых вещах: знать свои активы, понимать связи между ними, снижать доступность критических контроллеров из внешних сетей и выстраивать защиту вокруг реальных операционных процессов.
NIST в руководстве SP 800-82 также описывает OT как отдельный класс систем с собственными угрозами, типовыми топологиями и мерами защиты. Туда входят промышленные контроллеры, системы автоматизации зданий, физический доступ и мониторинг окружающей среды — ровно те контуры, которые в ЦОДе отвечают за жизнь объекта.
Общие рекомендации по обеспечению безопасности систем в ЦОДах:
-
Инвентаризация. Нужно понимать, какие контроллеры, BMS-серверы, инженерные станции, шлюзы, датчики и сервисные каналы реально работают на объекте. Не примерно, а фактически: с адресами, версиями ПО, связями, учётными записями и владельцами.
-
Разделение ИТ и OT. Инженерные системы не должны быть «ещё одной VLAN» в общей корпоративной сети. Доступ к ним должен быть минимальным, журналируемым и объяснимым. Удалённое обслуживание подрядчиков — только через контролируемые каналы, с временными правами и записью действий.
-
Общая аналитика. SIEM должен видеть не только серверные события, но и инженерные признаки: команды контроллерам, изменения порогов, аварии климатики, питание, события BMS, входы операторов и сетевую активность между зонами. Без этого атака через инженерку будет выглядеть как набор странных, но разрозненных событий.
-
Проектирование «с нуля». Для новых ЦОДов OT-безопасность надо закладывать на этапе архитектуры, а не после ввода объекта. НВБС формулирует это как обязательную часть проектирования безопасного дата-центра, а не как дополнительную опцию.
