Реальные инциденты и уроки из практики

Раздел рассматривает реальные примеры киберинцидентов, связанных с операционными (OT) системами в ЦОД. Анализируются технические причины, уязвимости инженерных протоколов и ошибки эксплуатации, которые приводили к длительным простоям и финансовым потерям.

Определение киберинцидента

Согласно определению Национального института стандартов и технологий США (NIST), киберинцидент — это событие, которое фактически или потенциально ставит под угрозу конфиденциальность, целостность или доступность информационной системы, либо нарушает установленные политики безопасности.

Киберинцидент может быть:

непреднамеренным (ошибка конфигурации, сбой системы);
умышленным (целевая атака или эксплуатация уязвимости).

Не каждое нарушение работы — атака. Если невозможно однозначно определить злонамеренность действий, инцидент всё равно классифицируется как киберинцидент.

Пример: авария в ЦОД British Airways (Великобритания, 2017)

27 мая 2017 года в двух британских ЦОД компании British Airways (Boadicea House и Comet House) произошли масштабные отключения электропитания. Инцидент привёл к остановке авиасистем на несколько часов и финансовым потерям в десятки миллионов фунтов.

Хронология и причины:

в ЦОД произошёл кратковременный импульс напряжения, после чего ИБП (UPS) не перешли на батареи, а самостоятельно выключились;
генераторы не запустились, так как UPS находились в линии с общей системой питания;
расследование показало, что сбой не был связан с поставщиком электроэнергии — проблема возникла внутри инфраструктуры ЦОД;
система управления UPS содержала SNMP-карту, на которой были активированы устаревшие функции «graceful shutdown» — автоматического выключения при аномалии;
эти настройки привели к немедленному завершению работы UPS при обнаружении ложного сигнала о сбое.

Суть проблемы заключалась не в хакерской атаке, а в уязвимости конфигурации SNMP-карты: параметры отключения могли быть изменены дистанционно или остались в заводских настройках. Даже при наличии резервирования и дублирования систем, ошибка в настройке одного узла привела к полной потере питания в двух дата-центрах.

Технический разбор уязвимости

Типичные опасные параметры SNMP-карт UPS, оставшиеся со времён 1990-х:

установка таймера в 0 секунд для работы от батареи;
установка порога отключения при 100 % заряде батареи;
активация опции shutdown on transfer to battery (отключение при любом переходе на батарею).

Эти функции изначально предназначались для старых систем, где один UPS обслуживал отдельный сервер, который корректно завершал работу перед выключением ИБП. Современные ЦОД работают по противоположному принципу — сервер нельзя выключать при переходе на батареи, но многие производители не удалили устаревшие опции из прошивок SNMP-карт.

Вывод расследования British Airways: не была реализована политика контроля конфигурации SNMP-устройств, а функции автоматического отключения остались активными по умолчанию.

Уроки для инженерных систем ЦОД

SNMP-карты и аналогичные устройства должны рассматриваться как элементы повышенного риска.
Все функции, связанные с удалённым или автоматическим выключением, подлежат отключению или ограничению доступа.
Требуется централизованный аудит всех конфигураций OT-устройств (UPS, PDU, CRAC, насосные станции и т.д.).
SNMP-доступ следует ограничивать отдельным VLAN, применяя SNMPv3 с authPriv.
Запрещено использовать устаревшие «graceful shutdown» функции и серверное ПО старого поколения.

Даже при наличии резервных вводов и генераторов, ошибочная логика или несанкционированная настройка в одной SNMP-карте может обнулить все уровни отказоустойчивости.

Российская практика

В России инциденты подобного масштаба в ЦОД не публикуются открыто, однако подход к управлению уязвимостями в инженерных системах закреплён нормативно. Приказ ФСТЭК №239 обязывает владельцев значимых объектов КИИ выявлять, устранять и документировать уязвимости технических средств, включая контроллеры и коммуникационные интерфейсы OT.

Меры, принятые в отечественной практике:

аудит конфигураций SNMP/Modbus/BACnet при вводе и в ходе эксплуатации ЦОД;
применение шлюзов с фильтрацией команд управления;
жёсткое разграничение ответственности между подрядчиками (ИТ, инженерка, ИБ);
обязательное журналирование событий в SIEM/OT-SIEM;
отключение всех опций «автоматического выключения» на уровне оборудования.

Основные выводы

Даже тривиальная настройка SNMP может привести к катастрофическим последствиям, если не контролируется политикой ИБ.
Логические уязвимости часто опаснее сетевых атак: они находятся внутри протоколов управления.
Для ЦОД критически важно вести учёт конфигураций всех контроллеров и карт связи.
Управление OT-инцидентами должно быть включено в систему ИБ как часть непрерывного мониторинга.
Российская практика (ФСТЭК №239) требует внедрения процессов управления уязвимостями, что напрямую предотвращает повторение подобных аварий.