Руслан Рахметов, Security Vision
CMDB (Configuration Management Database) – это централизованная база данных управления конфигурациями, которая хранит информацию обо всех ИТ-активах, их атрибутах и сложных многоуровневых взаимосвязях. Исторически возникнув как ключевой элемент методологии ITIL
(IT Infrastructure Library) для обеспечения стабильности предоставления ИТ-сервисов, в современном мире CMDB трансформировалась: сейчас она выступает безальтернативным фундаментом для инвентаризации средств защиты, непрерывного контроля расширяющейся поверхности атаки и риск-ориентированной приоритизации уязвимостей. В текущей статье мы поговорим о всех основных составляющих такой системы:
Оглавление
Стратегическое отличие CMDB от ITAM
Зачем CMDB нужна специалисту по ИБ
Интеграция CMDB в стек технологий кибербезопасности
Главные вызовы и ошибки при внедрении CMDB
Экосистемный подход и автоматизация: Платформа Security Vision
Возникновение и эволюция CMDB
Термин CMDB часто ошибочно трактуется как простой реестр серверов и программного обеспечения, но истинная ценность CMDB кроется не в самом факте инвентаризационного хранения данных, а в построении сложной топологии графовых связей между разрозненными элементами системы. Строительным блоком CMDB является понятие конфигурационных единиц (Configuration Item, CI) или активов (assets). Если в классических подходах десятилетней давности под активом понимался исключительно физический сервер или рабочая станция, то современная парадигма информационной безопасности и ИТ-управления трактует CI максимально широко, покрывая практически любые логические и физические сущности, влияющие на бизнес-процессы.
Представьте себе сложную инфраструктуру современного умного дома: «Умная лампа – 20 шт., Датчик движения – 5 шт., Главный роутер — 1 шт., Реле напряжения — 5 шт.» и т.д. и, если внезапно сгорает роутер или одно реле, по этому плоскому списку абсолютно невозможно спрогнозировать, какие именно комнаты останутся без света, отключится ли отопление и сработает ли сигнализация. Так выглядит базовая ведомость или ITAM (IT Asset Management) система, но CMDB – это не список, а трехмерная, динамическая архитектурная схема дома. В ней зафиксировано: «Датчик движения №5 (находится в коридоре) подключен к Роутеру №1 (находится в центральном щитке) и управляет группой Лампочек №10-15 (освещение пути к выходу)». Если ломается Роутер №1, схема в доли секунды показывает (коррелирует), что коридор погрузится во тьму, и жильцы (аналог бизнес-процесса) не смогут безопасно эвакуироваться. CMDB дает понимание зависимостей.
Именно благодаря фиксации связей система позволяет проводить анализ первопричин (Root Cause Analysis) при сбоях и оценивать потенциальное влияние (Impact Analysis) при планировании изменений в ИТ-инфраструктуре.
Стратегическое отличие CMDB от ITAM
ИТ-актив в парадигме ITAM – это, прежде всего, объект, обладающий финансовой стоимостью, амортизацией и контрактными обязательствами. ITAM сфокусирована на контроле капитальных (CAPEX) и операционных (OPEX) затрат, а жизненный цикл актива в ней начинается задолго до его появления в сети (на этапе формирования заявки на закупку, тендера и заключения договора с поставщиком) и заканчивается финансовым списанием с баланса организации (и физической утилизацией).
Напротив, конфигурационная единица (CI) в парадигме CMDB может вообще не иметь прямой финансовой стоимости. Например, открытый порт 443 на сервере, виртуальная подсеть или самоподписанный SSL-сертификат не покупаются через тендер, они не имеют инвентарного номера бухгалтерии, но их неверная конфигурация может привести к колоссальным бизнес-убыткам из-за взлома. Фокус CMDB – операционный статус, конфигурация, производительность и доступность. Жизненный цикл CI в CMDB начинается только в момент его фактического развертывания в сетевой инфраструктуре и заканчивается выводом из эксплуатации.
Зачем CMDB нужна специалисту по ИБ
За последнее десятилетие CMDB совершила концептуальный переход из разряда исключительно ИТ-инструментов, применяемых для процессов ITIL, в категорию критически важных, фундаментальных платформ кибербезопасности. Невозможно эффективно защитить то, о существовании чего служба безопасности даже не подозревает, поэтому внедрение и зрелое управление активами ИБ становится так называемым «нулевым шагом» для развертывания любых других защитных практик. Будь то мониторинг инцидентов, управление уязвимостями, внедрение архитектуры Zero Trust или обеспечение соответствия требованиям регуляторов – все эти процессы опираются на полноту и достоверность данных об инфраструктуре.
1) С массовой популяризацией SaaS-решений, децентрализацией облачных вычислений и развитием гибкой культуры разработки (DevOps/DevSecOps) в организациях экспоненциально растет объем неучтенных активов – так называемых Shadow IT. Без централизованной ИБ-CMDB, оснащенной функциями непрерывного, автономного сетевого сканирования и безагентского обнаружения, служба информационной безопасности остается абсолютно слепой к этим изменениям. В случае компрометации такого неучтенного, теневого актива ИБ-специалисты узнают об инциденте слишком поздно – на этапе, когда злоумышленники уже успешно провели разведку, скомпрометировали тестовый сервер и начали горизонтальное продвижение вглубь защищенного корпоративного периметра, используя похищенные токены.
2) Карта поверхности атаки организации напрямую, математически зависит от полноты, охвата и актуальности базы данных управления конфигурацией: она представляет собой совокупность всех без исключения точек входа (векторов), через которые неавторизованный пользователь или вредоносный код может попытаться проникнуть в среду, ввести данные, выполнить команды или извлечь конфиденциальную информацию. CMDB превращает абстрактное понятие «поверхность атаки» в конкретный список конфигурационных единиц, подлежащих немедленному харденингу (усилению защиты, например, с применением SPC функций).
3) Слияние сырых данных сканера уязвимостей (VS) и архитектурного контекста из CMDB порождает современный процесс Risk-Based Vulnerability Management (RBVM), в котором приоритизация патчинга происходит не на основе «голой» технической оценки (CVSS), а на базе сложной формулы риска, где риск является функцией вероятности эксплуатации, критичности актива для непрерывности бизнеса (которую дает CMDB), его сетевых связей и наличия компенсирующих мер защиты (например, наличия WAF, который уже фильтрует эксплойты к этой уязвимости).
Интеграция CMDB в стек технологий кибербезопасности
В условиях современных комплексных целевых атак (Advanced Persistent Threats, APT), когда реагирование на киберинциденты должно исчисляться не часами, а минутами, аналитики SOC физически не имеют права тратить драгоценное время на выяснение принадлежности взломанного сервера. При традиционном подходе аналитику приходится обзванивать коллег («чья это машина с IP 10.10.x.x?»), листать устаревшие таблицы или запрашивать доступы к системам виртуализации. Пока системный администратор ушел на обед, хакерский инструмент типа Mimikatz уже собирает хэши паролей из оперативной памяти и стадия Initial Access (Первоначальный доступ) стремительно перерастает в масштабный Lateral Movement (Горизонтальное перемещение) по всей сети.
Чтобы исключить человеческий фактор и задержки, CMDB должна выступать центральной нервной системой SOC, тесно интегрируясь со всем пулом решений кибербезопасности:
- Обнаружение активов и инвентаризация AM;
- Обогащение алертов в системах SIEM;
- Оркестрация и автоматизация реагирования с помощью SOAR;
- Взаимодействие с процессами управление уязвимостями VM;
- Оценка связей для уменьшения поверхности атак SPC;
- Риск-ориентированный подход к кибербезопасности RM/ORM;
- Проведение аудитов для анализа соответствия CM;
- Моделирование угроз и непрерывность бизнеса BCM.
Главные вызовы и ошибки при внедрении CMDB
Несмотря на очевидную, неоспоримую бизнес-ценность, мировые аналитические агентства отмечают, что значительный процент проектов по внедрению CMDB в крупных корпорациях заканчиваются провалом. Базы превращаются в дорогостоящие, громоздкие «кладбища данных», которым никто не доверяет, а анализ рынка выявляет три фундаментальные архитектурные и процессные ошибки:
а) Автоматизация ручного заполнения
Попытка вести базу конфигураций путем ручного ввода данных ИТ-специалистами (или через импорт статических таблиц) обречена на сокрушительную неудачу: инфраструктура XXI века чрезмерно динамична: виртуальные машины создаются и удаляются автоматически скриптами, сотрудники меняют отделы и локации, IP-адреса постоянно переназначаются серверами DHCP, а контейнеры Kubernetes живут от нескольких минут до нескольких часов. Поэтому ручное заполнение приводит к тому, что база безнадежно устаревает еще до того, как администратор нажмет кнопку «Сохранить». Единственный масштабируемый подход – это тотальный отказ от ручного ввода в пользу автоматических механизмов обнаружения (Discovery), сетевого сканирования и использования агентов инвентаризации. Человек в CMDB должен утверждать связи и бизнес-атрибуты, а не вбивать MAC-адреса.
б) Устранение дубликатов и ненужных объектов
Проблема «Мусор на входе / мусор на выходе» является фатальной для систем управления активами: поскольку современная CMDB наполняется данными из десятков различных, независимых источников (системы виртуализации, сканеры уязвимостей, Active Directory, EDR-агенты, антивирусы), неизбежно возникает хаос дублирования данных. Если база допускает создание дубликатов, процесс RBVM будет сломан, а расследование инцидентов превратится в путаницу. Поэтому современные решения управления конфигурациями обязаны иметь мощные встроенные механизмы нормализации и дедупликации, чтобы «склеивать» эти разрозненные записи, обогащать их и формировать единый, доверенный «золотой» профиль актива. Отсутствие процессов постоянной дедупликации и актуализации превращает базу данных в набор вредных советов.
в) Построение связей с реальными бизнес-сервисами
Многие инженеры и архитекторы фокусируются на нижнем технологическом слое (учесть каждый сервер, каждый кабель, каждый коммутатор), забывая о верхнем бизнес-слое (учесть сервис «Электронная коммерция», систему «Бухгалтерия», сервис «Доставка»). Такой разрыв между абстрактным ИТ-железом и реальной бизнес-ценностью делает абсолютно невозможным управление операционными рисками на уровне компании, поэтому процесс картирования сервисов, связывающий железные серверы с логическими бизнес-процессами, должен быть неотъемлемой частью внедрения.
Экосистемный подход и автоматизация: Платформа Security Vision
Преодолеть эти и другие проблемы путем применения отдельных, не связанных между собой точечных продуктов (один вендор поставляет сканер уязвимостей, второй продает систему CMDB, третий внедряет SOAR и т.д.) в современных реалиях становится всё сложнее и неэффективнее. Интеграция («склеивание» по API) разрозненных реляционных таблиц, разработка кастомных коннекторов и попытки привести данные разных производителей к единой модели данных отнимают колоссальное количество времени у ИТ- и ИБ-специалистов. Когда счет во время кибератаки идет на минуты, владельцы систем не имеют физического времени на ручную консолидацию аналитики из десятка разных, независимых источников.
Именно поэтому современный рынок информационной безопасности неуклонно смещается в сторону тотальной платформизации: экосистемный подход радикально исключает необходимость постоянно синхронизировать разрозненные инструменты, предоставляя единую монолитную среду, где управление активами является не просто модулем, а основополагающим ядром (онтологией) для всех остальных процессов безопасности.
Решения Security Vision в свою очередь предоставляют не только экосистему на базе единой Платформы, но и инструменты по интегрированию всех источников в единую зонтичную систему вне зависимости от выбранных вендоров и решений (за счет low code инструментов это возможно и без участия производителей). В наступившую эпоху сверхсложных, многовекторных целевых угроз, непрерывно меняющихся облачных архитектур и предельно строгих регуляторных требований на государственном уровне (таких как взаимодействие с ГосСОПКА и FinCERT), актуальная, автоматизированная и контекстно-богатая база данных управления конфигурацией выступает абсолютно единственным технологическим и логическим фундаментом. На нём можно построить по-настоящему эффективный, роботизированный и устойчивый к современным вызовам Security Operations Center.
