Константин Струлев: «Самая распространенная ошибка - попытка собрать систему из разрозненных инструментов» 

2 часа назад

© Фото: ЦОДУМ.

Константин Струлев
Директор компании «ЦОДУМ»

Требования к безопасности центров обработки данных растут, а инфраструктура становится только сложнее. Как перестать гасить пожары в ручном режиме и выстроить систему, которая работает на опережение? Вместе с директором компании «ЦОДУМ» Константином Струлевым разбираемся, почему попытка склеить мониторинг из разрозненных кусков ведет в тупик, чем опасен информационный «шум» в системах безопасности и как единая платформа Smart DCIM помогает видеть полную картину - от серверной стойки до распределенной сети. А также - почему подключать экспертов к проекту нужно еще на стадии проектирования, как сократить время реакции на инциденты и что на самом деле означает «доверие к системе».

Какие специфические требования к мониторингу и управлению инфраструктурой предъявляет законодательство к ЦОДам, отнесённым к объектам КИИ, и как платформа Smart DCIM помогает выполнить эти требования без избыточных затрат?

Константин Струлев: Если упростить, требования 187-ФЗ сводятся к вполне практичным вещам: вы должны постоянно понимать, что происходит с объектом, быстро реагировать на отклонения и иметь прозрачную историю событий. На практике это означает необходимость видеть не только ИТ, но и всю инженерную инфраструктуру как единую систему. Именно здесь у заказчиков чаще всего возникают сложности - данные разрознены, системы не связаны между собой. Smart DCIM изначально проектировался как единая платформа для таких задач. Мы собираем данные со всех ключевых подсистем - от серверов до электропитания, охлаждения и физической безопасности - и сводим их в единую картину. За счет этого можно не просто фиксировать инциденты, а видеть их предпосылки и реагировать заранее. Отдельно важно, что вся событийная модель централизована и легко интегрируется с SIEM заказчика. Это сильно упрощает как внутренние процессы, так и прохождение проверок. При этом мы всегда стараемся найти баланс между функциональностью и затратами. Для заказчика это, как правило, означает отказ от набора разрозненных решений в пользу одной платформы с предсказуемой стоимостью владения.

В условиях ужесточения контроля со стороны ФСТЭК и ФСБ как вы выстраиваете взаимодействие с заказчиками на этапе подготовки к аттестации? Есть ли у ЦОДУМ типовые решения или методические рекомендации для ускорения этого процесса?

К. Струлев: Подготовка к аттестации - один из самых чувствительных этапов для заказчика, и здесь важно не усложнять процесс, а наоборот, сделать его максимально управляемым. Мы стараемся подключаться как можно раньше, еще на стадии проектирования. Это позволяет сразу заложить архитектуру, которая не потребует доработок перед аттестацией - а такие переделки обычно самые дорогие. Дальше мы даем заказчику не просто продукт, а набор практических инструментов: документацию, примеры настроек, типовые сценарии. Это не формальные материалы, а вещи, которые реально используются в проектах и помогают ускорить подготовку. При этом мы всегда работаем в логике конкретного объекта. У каждого заказчика свои требования, свои регуляторы, своя внутренняя политика безопасности - и наша задача аккуратно встроиться в эту модель, а не навязывать универсальное решение.

Технологическая экспертиза: мониторинг как основа безопасности

Платформа Smart DCIM позиционируется как решение для комплексного мониторинга. Какие компоненты физической и информационной безопасности (СКУД, видеонаблюдение, пожарная сигнализация, защита периметра) уже интегрированы в систему, и по каким протоколам происходит обмен данными?

К. Струлев: Мы изначально делали ставку на открытость платформы, потому что в реальных ЦОДах почти никогда не бывает «идеальной» инфраструктуры из одного вендора.

Поэтому Smart DCIM спокойно интегрируется с тем, что уже есть у заказчика: СКУД, видеонаблюдение, пожарные системы, датчики, инженерка. Для нас это не отдельная задача, а базовый сценарий.

Используем стандартные протоколы - SNMP, Modbus, MQTT, API - чтобы не создавать лишних ограничений. Это позволяет быстро подключать как новое оборудование, так и унаследованные системы.

Но ключевая ценность даже не в самой интеграции, а в том, что все эти данные начинают «разговаривать» друг с другом. Когда событие доступа, видео и инженерные параметры складываются в единый контекст, у службы безопасности появляется гораздо более точное понимание ситуации.

Продукты Smart Site и Smart Rack, включённые в реестр отечественного ПО Минцифры, ориентированы на разные уровни инфраструктуры. Как они обеспечивают сквозной контроль безопасности - от отдельной серверной стойки до распределённой сети дата-центров?

К. Струлев:  Здесь мы обычно объясняем это через два уровня. Smart DCIM дает максимальную детализацию на уровне конкретного объекта - стойки, зала, инженерной системы. Это тот уровень, где принимаются оперативные решения. Smart Site, в свою очередь, собирает эту информацию на уровне всей распределенной инфраструктуры. В результате заказчик получает не набор разрозненных площадок, а единую систему с централизованным управлением. Для безопасности это критично: можно задать единые политики доступа, единые правила реагирования, единые подходы к аудиту. При этом вся детализация «внизу» никуда не теряется. Мы видим, что такой подход особенно востребован у заказчиков с распределенной инфраструктурой - там, где важно держать под контролем десятки и сотни объектов без потери управляемости.

Предиктивная аналитика и автоматизация реакций на инциденты - один из трендов в управлении ЦОД. Какие сценарии автоматического реагирования на угрозы физической или кибербезопасности уже реализованы в Smart DCIM, и как система минимизирует ложные срабатывания?

К. Струлев: Сегодня автоматическое реагирование - это уже не просто уведомления, а полноценные сценарии действий. Smart DCIM постоянно анализирует состояние инфраструктуры и при отклонениях запускает заранее настроенные реакции. Это может быть как информирование, так и конкретные действия - например, переключение на резерв или запуск внешних процедур. Из практики: при перегреве система может инициировать корректировку охлаждения, при событиях доступа - сразу связать их с видеопотоком и уведомить службу безопасности. При этом мы уделяем большое внимание тому, чтобы система не «шумела». Ложные срабатывания - одна из главных проблем в эксплуатации. Поэтому используем не только пороговые значения, а комбинации параметров и контекст. Плюс учитывается история работы конкретного объекта, что со временем делает систему более точной.

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

Новые инструменты визуализации, включая 3D-моделирование и чат-боты для мониторинга повышают оперативность принятия решений. Как эти функции помогают службам безопасности быстрее выявлять и локализовать инциденты в реальном времени?

К. Струлев: 3D и чат-боты мы рассматриваем не как отдельные функции, а как инструменты ускорения реакции.

3D-модель позволяет сразу увидеть, где именно произошел инцидент. Оператору не нужно сопоставлять данные с планами - он получает визуально понятную картину и быстрее принимает решение.

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

Мы видим, что такие инструменты особенно ценны для распределенных команд и дежурных служб. В итоге сокращается время от события до реакции, а это напрямую влияет на последствия инцидента.

Импортозамещение и доверие к отечественным решениям

Включение Smart DCIM и Smart Site в реестр российского ПО важный шаг для импортозамещения. Какие архитектурные и функциональные преимущества отечественной разработки вы выделяете при сравнении с зарубежными DCIM-платформами, ушедшими с рынка?

К. Струлев: Включение в реестр отечественного ПО для нас - это не просто формальный статус, а отражение того, как изначально строилась архитектура решений. Если сравнивать с зарубежными платформами, которые ушли с рынка, то главное отличие - в гибкости и адаптивности под реальные задачи заказчика. Smart DCIM и Smart Site не «жестко зашиты» под определённые сценарии, их можно достаточно быстро подстроить под конкретную инфраструктуру, требования безопасности и внутренние процессы. Отдельный момент - работа с оборудованием. Мы изначально ориентируемся на гетерогенную среду, включая российские решения, поэтому интеграция, как правило, проходит без лишних сложностей. Плюс важен вопрос масштаба. Smart Site позволяет централизованно работать с распределенной инфраструктурой без искусственных ограничений - это то, с чем многие заказчики сталкивались в зарубежных продуктах. Ну и, конечно, поддержка. Для заказчиков из КИИ это принципиально - возможность быстро получить помощь, доработать функциональность, учесть требования регуляторов. Здесь локальная разработка даёт ощутимое преимущество.

Планирует ли ЦОДУМ проходить сертификацию ФСТЭК для отдельных модулей платформы, особенно тех, что работают с персональными данными или критическими процессами управления инфраструктурой? Какие шаги уже предприняты в этом направлении?

К. Струлев: Вопрос сертификации для нас абсолютно практический, потому что мы понимаем, что для части заказчиков без этого дальше двигаться невозможно. При этом мы не рассматриваем сертификацию как «галочку». Сначала выстраиваем саму платформу с точки зрения безопасности: архитектура, разграничение доступа, процессы разработки. Уже на этой базе логично проходить сертификацию, а не наоборот. Сейчас мы системно готовимся к этому процессу - формируем документацию, выстраиваем процедуры, взаимодействуем с профильными экспертами. При этом держим фокус на реальных задачах заказчиков: если появляется проект, где сертификация критична, мы готовы достаточно быстро перейти в практическую плоскость. В целом наша позиция здесь простая - мы должны быть готовы к требованиям рынка, а не догонять их.

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

К. Струлев: Защита самой платформы - это базовая вещь, особенно если она используется на объектах КИИ. Мы стараемся встроиться в существующую модель безопасности заказчика, а не создавать параллельную. Поэтому активно используем интеграцию с корпоративными системами аутентификации - через SSO, IAM. Заказчик сохраняет централизованный контроль над доступами, и это, как правило, наиболее правильная модель. Дальше - стандартные, но обязательные вещи: шифрование каналов, разграничение прав, аудит действий. Многофакторная аутентификация для критичных операций - уже де-факто стандарт. Важно, что вся эта логика не навязывается, а настраивается под требования конкретного объекта. В КИИ редко бывают универсальные решения, и мы это учитываем.

Практика внедрения и стратегические перспективы

Можете ли вы поделиться кейсом внедрения решений ЦОДУМ на объекте, отнесенным к КИИ? Какие задачи по безопасности решались в первую очередь, и как измерялась эффективность после запуска системы?

К. Струлев: Кейсы в этой области почти всегда под NDA, и мы аккуратно к этому относимся - для заказчиков это принципиально. Но если говорить в целом по проектам, то задачи, как правило, повторяются. В первую очередь заказчики закрывают базовые риски: контроль инженерной инфраструктуры, доступ, целостность картины происходящего. Дальше уже идет развитие - интеграция с системами безопасности, автоматизация реагирования, аналитика. Эффективность при этом оценивается вполне прагматично. Смотрят, насколько сократилось время реакции, стало ли меньше «ложных» событий, насколько стабильно работает инфраструктура. Часто отдельно отмечают снижение нагрузки на персонал - за счет того, что система берет на себя рутину. Для нас это важный момент: мы всегда стараемся, чтобы эффект от внедрения был измеримым, а не оставался на уровне «стало удобнее».

Как меняется запрос от заказчиков из госсектора и критических отраслей (транспорт, энергетика, финансы) в части интеграции систем мониторинга инфраструктуры с СОПКА и другими государственными платформами обмена информацией об инцидентах?

К. Струлев: За последние годы запрос со стороны КИИ заметно повзрослел. Если раньше задача была просто зафиксировать инцидент, то сейчас речь идет о полноценном обмене данными с государственными системами, в том числе с ГосСОПКА. Причём в автоматическом режиме и в стандартизированном формате. Мы это видим и закладываем в архитектуру: открытые API, возможность формировать события в нужных форматах, интеграция с внешними системами. При этом для заказчика важно не просто «уметь отправить событие», а сделать это без лишней нагрузки на персонал. Поэтому ключевой запрос сейчас - максимальная автоматизация: система сама выявляет инцидент, классифицирует его и передает дальше. Именно в этом направлении сейчас развивается большинство проектов.

Какие технологические тренды - цифровые двойники, ИИ-аналитика, edge-мониторинг - вы считаете наиболее перспективными для развития решений в области безопасности ЦОДов на горизонте 2–3 лет?

К. Струлев: Если говорить про горизонт ближайших лет, то основные тренды уже понятны, и мы их видим в реальных проектах. Цифровые двойники постепенно переходят из «демо-функции» в рабочий инструмент. Они позволяют не только визуализировать объект, но и моделировать сценарии, что важно для безопасности. ИИ-аналитика - это в первую очередь про снижение шума и выявление нетипичных ситуаций. При большом количестве данных без этого уже сложно обойтись. Edge-подход тоже набирает обороты, особенно на распределенных объектах. Возможность принимать решения локально, без задержек - это критично для ряда сценариев. Мы стараемся не просто добавлять эти технологии, а интегрировать их в общую логику платформы, чтобы они давали практическую пользу, а не оставались «витринными» возможностями.

С учётом роста кибератак на транспортную и энергетическую инфраструктуру видит ли ЦОДУМ возможность адаптации платформы для мониторинга распределённых объектов КИИ вне классических дата-центров - например, на узлах связи или промышленных площадках?

К. Струлев: Да, такой запрос сейчас есть, и он довольно активно растёт. Изначально Smart DCIM и Smart Site проектировались с расчетом на распределенные объекты, поэтому адаптация под узлы связи, энергетику или промышленность - это не кардинальная переделка, а скорее настройка под конкретную предметную область. Для заказчиков здесь важно, что можно контролировать не только ИТ, но и всю сопутствующую инфраструктуру - питание, климат, безопасность, каналы связи - в рамках одной системы. Плюс остаётся вся логика централизованного управления, которая особенно ценна для территориально распределенных объектов. Мы уже видим такие внедрения и понимаем, что это направление будет только усиливаться.

Что бы вы порекомендовали руководителям служб безопасности ЦОДов, которые только начинают выстраивать систему мониторинга в соответствии с требованиями 187-ФЗ: с чего начать, на какие риски обратить внимание в первую очередь и как избежать типичных ошибок при выборе инструментов?

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

Читайте также: Данила Любомирский: «Стоимость простоев — главный индикатор риска».