Невидимые серверы и неконтролируемые изменения: как DCIM закрывает слепые зоны безопасности

Вы уверены, что точно знаете, какие серверы сейчас работают в вашем ЦОДе? Не по документам, не по CMDB и не по отчетам, а в реальности — что именно установлено, подключено и обрабатывает нагрузку прямо сейчас. Этот вопрос особенно актуален для тех, кто отвечает за безопасность, эксплуатацию и архитектуру инфраструктуры. Потому что любая защита начинается с понимания границ: что именно входит в контур, а что — нет.

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

В результате возникает знакомая ситуация: на бумаге всё выглядит аккуратно, а в стойках — чуть более разнообразно. И именно в этой разнице часто скрываются риски безопасности.

Почему классические средства ИБ видят не всё

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

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

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

Физика как источник правды

DCIM в этой картине работает на другом уровне. Он опирается не на записи в базе, а на фактическое состояние инфраструктуры.

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

В продвинутых DCIM к этому добавляется еще один важный источник — автодискаверинг. Он позволяет «увидеть» оборудование со стороны сети: какие устройства реально присутствуют, какие у них характеристики, как они меняются.

И в этот момент возникает особенно интересный эффект. Физическая картина и “сетевая” начинают дополнять друг друга. И любое расхождение между ними — это уже не просто техническая деталь, а повод для проверки с точки зрения безопасности.

Кейc: сервер, которого «не было»

В одной из инфраструктур всё выглядело корректно: учет велся, CMDB считалась актуальной, лишнего оборудования «не наблюдалось».

Но при анализе DCIM обратили внимание на странность — в одной из стоек фиксировалось стабильное энергопотребление, которое не объяснялось ни одним из известных серверов.

Проверили измерения — всё корректно. Посмотрели тепловую картину — подтверждает наличие работающего узла. В учетных системах — тишина.

В итоге выяснилось, что в стойке действительно находился сервер, установленный «временно» и так и оставшийся вне всех процессов.

С точки зрения безопасности это не просто «забытый актив». Это:

• узел без понятного владельца
• вне контроля обновлений и политик
• потенциальная точка входа или закрепления

И обнаружить его удалось только потому, что физику сложно игнорировать.

Изменения, которые никто не фиксировал

Но даже если с составом инфраструктуры всё более-менее понятно, остается вторая зона риска — изменения.

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

Как правило, без злого умысла. Но последствия могут быть вполне ощутимыми.

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

Кейc: «невинная» оптимизация, изменившая уровень риска

В одной инфраструктуре обратили внимание на постепенное изменение профиля энергопотребления в группе стоек. Без резких скачков — просто медленный рост там, где по плану всё должно было быть стабильно.

Официальных изменений не было.

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

Проблема в том, что вместе с этим изменилась схема резервирования. Часть нагрузки оказалась сосредоточена иначе, чем предполагалось, и в случае отказа последствия могли быть заметно серьезнее.

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

Без DCIM это осталось бы незамеченным.

Почему это важно для безопасности

Если обобщить, получается довольно простая мысль.

Безопасность опирается на контроль. А контроль — это не только списки и регламенты, но и понимание того, что происходит в реальности, даже если это не прошло через официальные процессы.

DCIM добавляет к привычным инструментам ИБ именно этот слой. Он не заменяет их, а делает картину полной. И в этой полной картине довольно быстро начинают находиться вещи, которые раньше просто не было видно.

В следующей статье посмотрим на эту же историю с другой стороны. Потому что всё то, что сегодня выглядит как «небольшое отклонение», очень часто оказывается вполне ощутимыми потерями денег.