Код кибербезопасности ЦОД: подходы, решения, практика. Блок 1. Проектирование безопасности

Вчера в 23:59

Стратегическая сессия

Центры обработки данных входят в контур объектов критической информационной инфраструктуры (КИИ), однако их защита до сих пор страдает от системного разрыва между подходами к физической и кибербезопасности. Редакция журнала RUБЕЖ провела заочную стратегическую сессию с ведущими отраслевыми экспертами в сфере методов и средств технической защиты дата-центров. «Хранители секретов» раскрыли подходы к проектированию систем безопасности, формированию карты угроз и назвали некоторые действенные меры предотвращения инцидентов в ЦОД.

Участники дискуссии: 

• Дмитрий Кузнецов, руководитель департамента системной интеграции Уральского центра систем безопасности (УЦСБ)

• Константин Горбунов, ведущий эксперт по сетевым угрозам компании «Код Безопасности»

• Игорь Каменский, руководитель российского офиса компании ITeaQ

• Антон Паламарчук, основатель агентства ИБ-консалтинга Expice Security

• Дмитрий Малоедов, старший инженер по информационной безопасности компании «Инфосистемы Джет»

• Дмитрий Казмирчук, эксперт по реагированию на инциденты компании «Инфосистемы Джет»

• Никита Бережанский, руководитель направления разработки аппаратного обеспечения компании «Айсорс»

• Вячеслав Селихов, ведущий пресейл-инженер Cloud Networks

БЛОК 1. ПРОЕКТИРОВАНИЕ БЕЗОПАСНОСТИ

Конвергенция систем физической и кибербезопасности: концепция или стратегия? Какие векторы атак возникают на стыке дисциплин и как избежать слепых зон на стадии проекта? Насколько оправдано раздельное проектирование СКУД, видеонаблюдения и ИБ-контуров?

Дмитрий Кузнецов (УЦСБ): Конвергенция перестала быть теоретической концепцией и переросла в производственную необходимость. Инженерные системы пожарной защиты, охлаждения, бесперебойного питания, контроля протечек и климат-контроля уже давно управляются через компьютерные сети и работают на собственном программном обеспечении. Распространение IoT, облачных сервисов и сетевых СКУД окончательно стирает границы между физической и цифровой безопасностью.

Традиционные системы мигрируют на IP-технологии, что позволяет интегрировать их через платформы классов PSIM (Physical Security Information Management) и SIEM (Security Information and Event Management) с унифицированными API (Application Programming Interface — «программный интерфейс приложения») — набором правил, инструментов и протоколов, который позволяет двум разным программам или платформам «общаться» между собой и обмениваться данными. В такой среде злоумышленники активно эксплуатируют конвергенцию, расширяя поверхность атаки, где физические устройства становятся плацдармом для доступа к критическим данным.

Фокус защиты переходит на устойчивость бизнеса, где любой инцидент оценивается через призму юридических и финансовых рисков. Достаточно вспомнить, что взлом контроллера температурного режима может спровоцировать перегрев серверных стоек, а компрометация СКУД откроет двери в серверную. Последствия таких атак по своей критичности не уступают прямому взлому ИТ-оборудования и ПО.

Константин Горбунов («Код Безопасности»): Конвергенция физической и кибербезопасности — это уже реальность, однако раздельное проектирование контуров по-прежнему оправдано не только организационно, но и технически. Современные системы СКУД, видеонаблюдения, BMS (Building Management System), HVAC (отопление, вентиляция и кондиционирование), мониторинга питания, а также интерфейсы IPMI (Intelligent Platform Management Interface) и IP-KVM (обычно часть функционала IPMI, удаленная консоль, передающая видео, клавиатуру и мышь, позволяющая видеть экран и управлять сервером через браузер) — это стандарт для удаленного управления серверами, работающий независимо от ОС, BIOS или процессора. Такие интерфейсы давно оснащены веб-интерфейсами, инструментарием для удаленного администрирования и зачастую интегрированы с корпоративными сервисами. Любая архитектурная ошибка на этапе проектирования мгновенно трансформируется из эксплуатационной проблемы в киберриск.

Главная угроза на стыке дисциплин – появление теневых каналов доступа. Через BMS можно получить карту размещения стоек, через HVAC — дистанционно повлиять на температурный режим, а через некорректно подключенные камеры или внешние ноутбуки – попасть во внутренний контур. Особенно опасны гибридные сценарии, где физический доступ усиливает кибератаку: подключение к сервисному порту, подмена устройства, загрузка с внешнего носителя или использование учетных записей администраторов.

На стадии проекта необходима строгая сегментация сетевого доступа: отдельные изолированные сегменты для ИТ, BMS, видеонаблюдения, подрядчиков и сервисного подключения. Для инженерных систем обязательна запись сессий администрирования, а для критически важных узлов — полный отказ от прямого доступа из интернета или офисной сети. Чтобы исключить «слепые зоны», проектирование должно начинаться с инвентаризации активов, карты доверенных связей и матрицы полномочий. Роли должны быть четко формализованы: инженер получает доступ к функциям поддержания работоспособности, но лишается прав на изменение политик безопасности вне регламента.

Игорь Каменский (ITeaQ): С позиции производителя инженерной инфраструктуры, безопасный ЦОД должен строиться по принципу единой наблюдаемости при строгом разделении контуров управления. Платформы DCIM (Data Center Infrastructure Management — специализированное программное обеспечение для комплексного управления, мониторинга и визуализации физической инфраструктуры центров обработки данных в ЦОД) действительно должны агрегировать мониторинг тревог от ИБП, батарейных модулей, кондиционеров, датчиков протечек, СКУД и видеонаблюдения, но ни в коем случае не превращаться в инструмент неконтролируемого оперативного воздействия.

Изменение установок HVAC должно оставаться за профильными инженерами, управление правами доступа — за службой безопасности, а сервисные интерфейсы серверов должны размещаться в выделенном management/OOB-контуре (Out-of-Band Management — внеполосное управление).
 С учетом экспоненциального развития искусственного интеллекта, который уже сегодня автоматизирует поиск zero-day уязвимостей (скрытых от разработчиков ошибок в программном обеспечении), генерирует полиморфные атаки, обходящие сигнатурные средства защиты, и ведет разведку в режиме 24/7 без участия человека, я с большой осторожностью отношусь к PDU (Power Distribution Unit) — устройствам с функцией удаленного отключения нагрузки. В проектах с повышенными требованиями к отказоустойчивости я бы рекомендовал полностью отказываться от такого функционала.

Для ЦОД критически важно, чтобы удобство дистанционного управления не создавало дополнительный риск случайного или несанкционированного отключения оборудования. Именно поэтому сегодня отказоустойчивость, эксплуатационная надежность и киберзащита должны закладываться как единая архитектурная задача еще на стадии проектирования.

Импортозамещение «железа»: как проектировать ЦОД в условиях недоверия к компонентам?

Дмитрий Кузнецов (УЦСБ): Полная замена импортных чипов отечественными аналогами на текущем этапе технологически невозможна, поэтому разумная стратегия сводится к построению гетерогенной архитектуры, где отказ или компрометация одного элемента не приводит к каскадному обрушению всего ЦОД. Рекомендуется закладывать разнородные вычислительные узлы: наиболее ответственные задачи, такие как шифрование и контроль доступа, следует передавать отечественным процессорам, а для высокопроизводительных расчетов использовать проверенные импортные образцы.

Работа с рисками цепочки поставок и аппаратных закладок сегодня стала обязательным этапом проектирования. По данным отрасли, доля западного оборудования в российских ЦОД уже сократилась с 7,9% до 3,1%, а фокус сместился на вендоров, чья продукция включена в реестр Минпромторга РФ.

Гарантировать полное отсутствие технических рисков, включая аппаратные закладки, не может никто, но минимизировать их позволяет внедрение «доверенного BIOS» — замена стандартных BIOS и BMC на отечественные разработки, такие как Numa BIOS или решения от Fplus, дает полный контроль над исходными кодами на самом низком уровне, что является ключевым критерием доверия для регуляторов.

Активные методы верификации, включая контроль целостности и анализ трафика уже работающего оборудования, а также политика Zero Trust, выступают «последним рубежом» для сегментации и ограничения возможностей потенциально зараженного устройства. Подобная архитектурная избыточность увеличивает капитальные затраты на 20-30%, однако она обеспечивает предсказуемость работы и предотвращает простои, стоимость которых измеряется миллионами рублей за каждый час.

Архитектура защиты: микросегментация и периферийные ЦОД (Edge)

Антон Паламарчук (Expice Security): Классическая периметровая модель защиты, предполагающая четкую границу «свой-чужой», в современных условиях утратила эффективность. Современный ЦОД не имеет жесткой границы: трафик движется горизонтально между рабочими нагрузками, сервисами, виртуальными машинами и контейнерами, зачастую в гибридной среде, где часть вычислений уходит в облако, а часть выносится на периферийные узлы.

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

Реализация возможна на трех уровнях.

На сетевом уровне применяются межсетевые экраны нового поколения, спроектированные под высокие плотности соединений и поддерживающие наложенные сети типа VXLAN для изоляции виртуальных сегментов поверх физической инфраструктуры.

На уровне гипервизора применяется хостовая сегментация, где политики фильтруют трафик между виртуальными машинами до его выхода в физическую сеть.

Наиболее зрелый уровень — идентификационный, где политики привязываются не к IP-адресу, а к идентификатору рабочей нагрузки или пользователя, что формирует основу архитектуры Zero Trust Network Access (ZTNA).

Критически важным дополнением к микросегментации является управление секретами. На практике утечка API-токенов часто наносит больший ущерб, чем отсутствие гранулярного управления VLAN.

Секреты нередко хранятся в переменных среды или конфигурационных файлах, ротация не настроена, а аудит отсутствует. В архитектуре ZTNA эта уязвимость закрывается выделенной системой класса Secrets Manager, которая обеспечивает динамическую выдачу краткосрочных учетных данных, централизованное хранение в покое и автоматическую ротацию. Сервис запрашивает секрет непосредственно в момент необходимости, использует токен с ограниченным сроком жизни и не сохраняет его. Даже при компрометации окно эксплуатации измеряется минутами. Каждое взаимодействие проходит двойную проверку: сетевую (разрешен ли трафик?) и криптографическую (действителен ли секрет?).

Что касается периферийных ЦОД, расположенных на производственных или транспортных узлах, их следует архитектурно трактовать как недоверенные зоны. Весь трафик между Edge (граничным) и центральным ЦОД должен проходить через явную точку контроля с инспекцией, секреты выдаваться централизованно, а телеметрия коррелироваться в единой системе мониторинга.

Производительность не страдает при грамотном проектировании: инспекции подвергается только межзональный трафик, обращения к критичным данным и запросы привилегированных учетных записей, а не каждый пакет внутри одной зоны безопасности.

Ключевая ошибка — начинать внедрение с выбора продукта. Правильный порядок обратный: сначала формируется матрица рисков на основе архитектуры нагрузок, каналов взаимодействия и хранения учетных данных, и только затем выбирается класс решений для закрытия выявленных векторов.

Продолжение: Блок 2 читайте на портале RUБЕЖ