CMDB: что это такое и как работает

Когда ФСТЭК запрашивает реестр конфигураций для проверки — и выясняется, что никто точно не знает, какой сервис крутится на каком сервере, какая версия ОС, кто ответственный и к какой информационной системе всё это относится. В этот момент становится понятно, чего не хватало: не просто инвентаризации, а CMDB.

Configuration Management Database — не модное слово из ITIL. Это единственный инструмент, который отвечает на вопрос «как устроена инфраструктура» в разрезе связей, а не просто строк в таблице. В этой статье разберём, что такое CMDB, из чего она состоит, чем отличается от ITAM и ITSM, и почему для ИБ-отдела нужна не «просто CMDB», а CMDB с ИБ-контекстом.

Что такое CMDB

CMDB (Configuration Management Database) — база данных конфигурационных единиц (КЕ, или CI — Configuration Items) и связей между ними. Это центральный репозиторий сведений об ИТ-инфраструктуре: не просто список серверов, а модель того, как все элементы инфраструктуры связаны друг с другом и как изменение одного влияет на остальные.

Концепция CMDB появилась в библиотеке ITIL (IT Infrastructure Library) в конце 1980-х годов как часть процесса управления конфигурациями (Configuration Management). Первоначально CMDB создавалась как инструмент ITSM — для управления изменениями, инцидентами и релизами. Со временем её применение расширилось далеко за пределы ИТ-сервис-менеджмента и охватило задачи ИБ, управления рисками и регуляторного соответствия.

Ключевые понятия

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

Связи между КЕ — именно связи превращают набор записей в настоящую CMDB. Типы связей: «зависит от», «является частью», «связан с», «влияет на», «размещён на», «управляется». Связи позволяют моделировать последствия изменений и инцидентов.

Жизненный цикл КЕ — каждая конфигурационная единица проходит стадии: планирование → заказ → получение → эксплуатация → обслуживание → списание. CMDB отражает текущее состояние и историю изменений.

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

Чем CMDB отличается от простого реестра

Реестр активов отвечает на вопрос «что у нас есть». CMDB отвечает на вопросы «как это всё связано», «от чего зависит», «кто отвечает» и «что изменилось». Именно последние вопросы критичны при анализе инцидентов безопасности, проведении аудита и подготовке к проверке регулятора.

Возьмём конкретный сценарий: произошёл сбой в работе корпоративной ERP-системы. Без CMDB ИТ-команда тратит 1–2 часа на выяснение: какие серверы задействованы, кто отвечает за каждый компонент, какие смежные сервисы могут быть затронуты. С CMDB тот же анализ занимает 5 минут — граф зависимостей уже построен, ответственные известны, смежные системы видны. Это принципиально меняет скорость реагирования и, следовательно, время восстановления после инцидентов.

Из чего состоит CMDB

CMDB включает несколько категорий конфигурационных единиц, объединённых сетью связей.

Типы конфигурационных единиц

Атрибуты конфигурационной единицы

Каждая КЕ описывается набором атрибутов. Минимальный стандартный набор:

• Идентификатор — уникальный код КЕ в системе
• Наименование — понятное человеку название
• Тип — категория КЕ (сервер, ПО, сервис и так далее)
• Версия — для ПО и прошивок
• Статус — эксплуатация, резерв, обслуживание, списан
• Владелец — ответственное подразделение или сотрудник
• Местоположение — физическое (стойка, ЦОД, офис) или логическое (подсеть, VLAN)
• Дата ввода в эксплуатацию
• Дата планового списания

Для ИБ-задач атрибуты расширяются: принадлежность к ИСПДн/ГИС/КИИ, перечень установленных СЗИ, сроки сертификатов, уровень критичности.

Связи и зависимости: практический пример

Рассмотрим сервер как КЕ в CMDB:

• Сервер PostgreSQL 14.2 (аппаратная КЕ)
  • → размещает → ОС Astra Linux 1.7 (КЕ ПО)
  • → размещает → СУБД PostgreSQL 14.2 (КЕ ПО)
  • → обеспечивает → Кадровая система HR-Pro (КЕ сервиса)
  • → относится к → ИСПДн «Кадры» (КЕ информационной системы)
  • → защищается → Dallas Lock 8.0-K (КЕ СЗИ, сертификат ФСТЭК до 2026-11)
  • → ответственный → Иванов А.С., системный администратор

Именно такая модель позволяет ответить на вопрос: «Если этот сервер выйдет из строя — какие сервисы пострадают, чьи данные под угрозой, и кто должен реагировать?» — за секунды, а не за часы ручного анализа.

CMDB vs ITAM vs ITSM — в чём разница?

Три понятия часто путают. У каждого — свой фокус, своя аудитория и свои задачи.

Сравнительная таблица

Типичная путаница: инвентаризация ≠ CMDB

Многие организации считают, что провели «инвентаризацию» — значит, у них есть CMDB. Это не так. Инвентаризация — это сбор данных об активах. CMDB — это структурированная база с моделью связей, историей изменений и процессами актуализации.

Пример. В ходе инвентаризации зафиксировали: «На сервере srv-01 установлена Windows Server 2022 и 1С:Предприятие 8.3». Это инвентаризация. CMDB добавляет: srv-01 → входит в кластер prod-cluster → обеспечивает сервис «ERP» → относится к ИСПДн «Бухгалтерия» → защищается Kaspersky Endpoint Security (серт. ФСТЭК №4521, истекает 2026-09) → ответственный Петров В.И. → при сбое срабатывает алерт в SIEM. Инвентаризация — источник данных для CMDB. CMDB — следующий уровень зрелости.

Как ITAM и CMDB дополняют друг друга

ITAM фокусируется на жизненном цикле и финансах: когда купили, сколько заплатили, когда истекает лицензия, когда списать. ITAM-модуль даёт ответы на вопросы финансового директора и закупщика. CMDB даёт ответы на вопросы ИТ-директора и CISO: как инфраструктура устроена, что от чего зависит, какое изменение на что повлияет.

В зрелых организациях ITAM и CMDB работают вместе: ITAM управляет финансовым жизненным циклом, CMDB — конфигурационным. Данные об активах синхронизируются между системами.

CMDB и ITSM: где граница

ITSM (IT Service Management) — это набор процессов управления ИТ-сервисами: управление инцидентами, изменениями, проблемами, релизами. CMDB в ITSM-контексте является справочником конфигурационных данных, к которому обращаются процессы: при заведении инцидента диспетчер видит, к какому активу относится проблема; при плановом изменении менеджер видит, какие сервисы будут затронуты.

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

CMDB для информационной безопасности

CMDB, созданная для ITSM-задач, и CMDB для ИБ — принципиально разные инструменты. Не в архитектуре, а в том, какие связи и атрибуты в ней хранятся.

ITSM-CMDB vs ИБ-CMDB: разные модели связей

В ITSM-CMDB типичная цепочка: КЕ → инцидент → изменение → релиз. Это логика управления сервисами.

В ИБ-CMDB цепочка иная: КЕ → уязвимость → риск → мера защиты → СЗИ → сертификат ФСТЭК → статус выполнения. Это логика управления безопасностью.

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

Что добавляет ИБ-контекст в CMDB

Привязка активов к регуляторному контексту. Каждый актив получает атрибуты: принадлежность к ИСПДн (152-ФЗ), ГИС (Приказ ФСТЭК №17), объекту КИИ (187-ФЗ), значимому объекту КИИ (ПП №127). Это позволяет понять, какие требования применяются к каждому конкретному активу.

Автоматическая сверка ПО с БДУ ФСТЭК. CMDB знает, какое ПО установлено на каждом активе. При автоматическом сопоставлении с Банком данных угроз ФСТЭК сразу видно: на каких активах есть уязвимый компонент, насколько критична уязвимость, к каким информационным системам относятся эти активы. Без CMDB такой анализ — ручная работа на несколько дней.

Реестр СЗИ и СКЗИ с привязкой к КЕ. Каждый актив связан с установленными средствами защиты информации. Для каждого СЗИ хранятся: тип (антивирус, МСЭ, IDS, DLP), производитель, версия, номер сертификата ФСТЭК и срок его действия. Для СКЗИ — дополнительно серийные номера, сертификаты ФСБ, ключевые документы.

Связь: актив → уязвимость → патч → ответственный → срок. Это полный цикл управления уязвимостями, невозможный без CMDB. Сканер находит уязвимость, CMDB даёт контекст — и задача по устранению создаётся автоматически с привязкой к активу и ответственному.

Практический пример: от CVE до закрытия

Представим реальный сценарий. Сканер уязвимостей обнаружил CVE-2024-1234 (критическая, CVSS 9.8) в PostgreSQL версий ниже 14.7. ИБ-CMDB мгновенно отвечает на все нужные вопросы:

1. На каких активах стоит уязвимая версия PostgreSQL? → srv-01, srv-04, srv-09
2. К каким ИС относятся эти серверы? → ИСПДн «Кадры», ИСПДн «Клиенты», ГИС «Учёт»
3. Кто ответственный за каждый сервер? → Иванов, Петров, Сидорова
4. Есть ли компенсирующие меры (МСЭ, IDS, сегментация)? → Да, на srv-04 и srv-09
5. Каков реальный приоритет? → srv-01 (ИСПДн без компенсирующих мер) — P0, срок 72 часа

Без CMDB этот анализ занимает несколько часов ручной работы. С ИБ-CMDB — минуты.

Посмотрите, как работает CMDB-модуль КиберОснова с ИБ-контекстом: сверка с БДУ ФСТЭК, учёт СЗИ/СКЗИ, связи с ИСПДн и КИИ — в едином интерфейсе.

Как строится CMDB — методология

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

Шаг 1. Определить границы CMDB

Ответьте на вопросы: какие типы КЕ включаем (только серверы? все активы? документы?), какие атрибуты обязательны, какие связи критичны для наших задач. Не пытайтесь покрыть всё сразу. Начните с самого ценного: серверы → ключевые сервисы → информационные системы → СЗИ.

Шаг 2. Выбрать источники данных

Хорошая CMDB питается из нескольких источников одновременно:

• Active Directory — компьютеры, пользователи, группы, подразделения
• Агентный сбор — ПО, конфигурации, ресурсы на рабочих станциях и серверах
• Сетевые сканеры — устройства в сети, открытые порты, SNMP-данные от оборудования
• Kaspersky Security Center / Kaspersky Endpoint Security — данные о защищаемых устройствах
• Системы мониторинга (Zabbix, Nagios) — состояние и производительность
• Ручной ввод — для активов, недоступных для автоматического сбора

Шаг 3. Настроить автоматический сбор

Автоматизация — не опция, а обязательное условие. Ручная CMDB теряет актуальность за 2–3 месяца: сотрудники забывают вносить изменения, меняются конфигурации, появляются новые устройства. Исследования показывают: при ручном ведении CMDB через квартал актуальны лишь 30–40% записей.

Выбор подхода:

Шаг 4. Установить процесс обновления (Change Management)

CMDB должна обновляться при каждом изменении инфраструктуры. Выстройте процесс: любое изменение (установка ПО, замена оборудования, ввод нового сервиса) проходит через CMDB. Автоматические обновления покрывают большинство изменений; для плановых работ — ручная фиксация в рамках заявки на изменение.

Шаг 5. Определить владельцев КЕ

Каждая конфигурационная единица должна иметь владельца. Владелец — не тот, кто её создал, а тот, кто несёт ответственность за её корректность и актуальность. Для серверов — системный администратор или руководитель инфраструктуры. Для ИС — бизнес-владелец. Для СЗИ — ответственный за ИБ.

Шаг 6. Настроить связи и зависимости

После наполнения CMDB активами — выстраивайте связи. Начните с наиболее критичных: «сервис → серверы», «информационная система → активы», «СЗИ → защищаемые активы». Связи можно строить автоматически (агент знает, на каком сервере установлен) и вручную (ИС → КИИ — ручная классификация).

Шаг 7. Измерить качество CMDB

Запущенная CMDB нуждается в регулярной проверке. Ключевые метрики качества:

• Покрытие — какой процент известных активов внесён в CMDB (цель: ≥95%)
• Актуальность — как часто данные расходятся с реальностью (цель: ≤5% расхождений)
• Полнота атрибутов — у скольких КЕ заполнены все обязательные поля (цель: ≥90%)
• Покрытие связями — у скольких КЕ определены связи (цель: ≥80%)

Проводите случайные выборки: выбирайте 10–20 активов и сверяйте данные CMDB с реальным состоянием. Если расхождений больше 10% — процесс обновления работает плохо, нужно усиливать автоматизацию.

Главная ошибка при построении CMDB

Попытка сделать CMDB идеальной с первой попытки. На практике оптимально: запустить пилот на критичном сегменте (серверы + СЗИ), получить первый результат за 2–4 недели, затем итеративно расширять. CMDB с 80% актуальностью, работающая сегодня, ценнее «идеальной» CMDB, внедрение которой затянулось на год.

Вторая распространённая ошибка — строить CMDB изолированно от бизнес-процессов. CMDB должна быть интегрирована в реальные рабочие процессы: каждое изменение инфраструктуры должно проходить через CMDB, каждое расследование инцидента должно начинаться с просмотра карточки актива в CMDB. Если сотрудники обходят систему и работают напрямую, CMDB деградирует независимо от качества первоначального наполнения.

Российские CMDB-системы в 2026

Рынок CMDB-систем в России делится на два сегмента: ITSM-ориентированные решения (для ИТ-отделов) и ИБ-ориентированные (для ИБ-подразделений и SGRC-задач).

ITSM-CMDB для ИТ-отделов

Naumen ITAM. Enterprise-решение с сильным модулем управления активами (HAM) и лицензиями (SAM). Хорошо интегрируется с ITSM-платформой Naumen. Фокус — ИТ-управление, финансовый учёт, управление изменениями. Слабые стороны: нет ИБ-специфики (учёт СЗИ, СКЗИ, сертификатов ФСТЭК), нет встроенного сравнения с БДУ ФСТЭК.

SimpleOne ITAM. Российский аналог ServiceNow, включает модуль управления активами и CMDB. Сильная сторона — гибкость настройки и готовые ITIL-процессы. Для ИБ-задач потребует доработки или интеграции со специализированным решением.

ITSM365. SaaS-платформа для управления ИТ-сервисами с базовым модулем CMDB. Быстрый старт, невысокий порог входа, подходит для небольших ИТ-отделов. Для задач ИБ и регуляторного соответствия не предназначена.

ИБ-CMDB для ИБ-отделов

КиберОснова SGRC. SGRC-платформа с полноценным CMDB-модулем, ориентированным на задачи ИБ: агентный сбор данных с поддержкой Astra Linux, автоматическая сверка ПО с БДУ ФСТЭК, реестр СЗИ с контролем сертификатов, учёт СКЗИ по Приказу ФАПСИ №152, привязка активов к ИСПДн и КИИ. Единственное решение на рынке с полноценной поддержкой российских ОС в агентном модуле.

Securitm. Российская SGRC-платформа с модулем «Активы». Базовая инвентаризация есть, ИБ-связки — частично. Сильнее в части управления рисками и соответствием требованиям. Слабее в части агентного сбора и учёта СКЗИ.

R-Vision SGRC. Enterprise-платформа с модулем управления активами КИИ. Глубокая специализация на объектах критической информационной инфраструктуры, интеграция с государственными системами (ГосСОПКА). Высокий порог входа, ориентирована на крупные организации.

Security Vision AM. Модуль управления активами в составе платформы Security Vision. Enterprise-уровень, широкие возможности интеграции. Требует значительных ресурсов на внедрение и настройку.

Open source CMDB

iTop. Полноценная ITIL-CMDB с открытым исходным кодом. Поддерживает настраиваемые типы объектов и связей, имеет веб-интерфейс. Бесплатна, сообщество активно. Минусы: нет российской ИБ-специфики, нет сертификата ФСТЭК, требует самостоятельного развёртывания и поддержки.

NetBox. Специализируется на документировании сетевой инфраструктуры: IP-адреса, VLAN, стойки, оборудование. Отличный инструмент для сетевых инженеров, но не полноценная CMDB для ИБ-задач.

GLPI. ITSM-система с модулем управления активами. Широко используется в европейских госорганизациях. Поддерживает агентное сканирование через FusionInventory. Для задач российского регуляторного соответствия потребует существенной доработки.

Сравнительная таблица решений

Как выбрать

Если основная задача — ИТ-управление, финансовый учёт лицензий и управление изменениями — смотрите на Naumen ITAM или SimpleOne. Если задача — регуляторное соответствие, учёт СЗИ/СКЗИ и управление безопасностью — выбирайте ИБ-CMDB в составе SGRC-платформы. Для госорганизаций с требованием сертифицированного ПО — только решения с действующим сертификатом ФСТЭК.

Чеклист для выбора CMDB:

• Источники данных — поддерживает ли система агентный сбор, безагентное сканирование, импорт из AD?
• Поддержка ОС — работает ли агент на Linux-дистрибутивах, в том числе на Astra Linux, ALT Linux, РЕД ОС?
• ИБ-атрибуты — можно ли хранить данные о сертификатах ФСТЭК, привязке к ИСПДн и КИИ?
• Интеграции — есть ли готовые коннекторы к SIEM, сканерам уязвимостей, БДУ ФСТЭК?
• Учёт СКЗИ — поддерживается ли поэкземплярный учёт по Приказу ФАПСИ №152?
• Сертификация — есть ли сертификат ФСТЭК или решение внесено в реестр Минпромторга?
• Отчётность — формируются ли автоматически отчёты для проверок регуляторов?

Ответы на эти вопросы чётко разграничат ITSM-CMDB и ИБ-CMDB в вашем конкретном контексте. Для большинства организаций с регуляторными требованиями в сфере ИБ выбор очевиден — нужна специализированная ИБ-CMDB, встроенная в SGRC-платформу. Это позволяет не просто вести реестр активов, а управлять безопасностью в едином пространстве: от обнаружения устройства до закрытия уязвимости и отчёта для ФСТЭК.

Хотите сравнить КиберОснова SGRC с другими решениями по конкретным критериям? Запросите демо — покажем CMDB в работе и ответим на технические вопросы.

CMDB и управление изменениями: почему это неразделимо

CMDB без процесса управления изменениями (Change Management) — это фотография инфраструктуры в момент внедрения. Через три месяца она отражает прошлое, а не настоящее.

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

Модель зрелости CMDB

На практике организации проходят несколько уровней зрелости в работе с CMDB:

Уровень 1 — Реестр (инвентаризация). Есть список активов с базовыми атрибутами. Обновляется вручную, периодически. Актуальность 40–60%. Типичный инструмент — Excel или базовый ITAM без интеграций.

Уровень 2 — Автоматизированная CMDB. Данные собираются автоматически через агентов и сканеры. Связи частично выстроены. Актуальность 70–80%. Есть уведомления об изменениях. Типичный инструмент — ITAM-система или базовая CMDB.

Уровень 3 — ИБ-CMDB. Каждый актив связан с ИБ-контекстом: уязвимости, СЗИ, сертификаты, принадлежность к ИСПДн/КИИ. Автоматическая сверка с БДУ ФСТЭК. Актуальность 85–95%. Типичный инструмент — SGRC-платформа с CMDB-модулем.

Уровень 4 — Предиктивная CMDB. CMDB используется для предупреждения проблем: автоматически создаются задачи по истекающим сертификатам, приближающимся датам ТО оборудования, несоответствиям конфигурации политикам ИБ. Актуальность 95%+. Интеграция с SIEM, сканерами уязвимостей, системой управления рисками.

Большинство российских организаций в 2026 году находятся на уровне 1–2. Организации, которые работают с требованиями ФСТЭК, ФСБ и 187-ФЗ всерьёз, целенаправленно движутся к уровню 3. Переход с уровня 2 на уровень 3 — это не замена инструмента, а добавление ИБ-контекста к уже выстроенному процессу инвентаризации.

Почему CMDB критична при проверках регуляторов

Проверка ФСТЭК начинается с одного вопроса: «Предоставьте перечень информационных ресурсов и средств защиты». Организация без CMDB собирает этот перечень вручную 1–3 дня, при этом данные неизбежно содержат ошибки и пробелы. Организация с ИБ-CMDB формирует выгрузку за 10 минут.

Второй типичный вопрос проверки: «Как вы контролируете соответствие конфигураций политикам ИБ?» Без CMDB ответ размытый. С CMDB — конкретный: «Каждый актив имеет эталонную конфигурацию, агент фиксирует отклонения и создаёт задачу ответственному».

Именно поэтому инвентаризация ИТ-активов с выстроенной CMDB — это не просто удобство для ИТ-отдела, а конкурентное преимущество при прохождении проверок и аттестаций.

Часто задаваемые вопросы

Ответы на наиболее частые вопросы о CMDB — что это, чем отличается от Excel и инвентаризации, как работает в контексте российских требований — собраны ниже. Если у вас остались вопросы о том, как CMDB работает в составе КиберОснова SGRC — запросите демо, и мы покажем всё в работе на реальных данных.

Заключение

CMDB — не дорогой проект «для галочки» и не инструмент только для крупных корпораций. Это фундамент, без которого управление ИТ-инфраструктурой и информационной безопасностью остаётся реактивным: ИБ-отдел узнаёт о проблемах постфактум, а не предотвращает их.

Ключевые выводы:

• CMDB — это не инвентаризация. Инвентаризация — источник данных, CMDB — модель связей.
• ITSM-CMDB и ИБ-CMDB решают разные задачи. Для ИБ-отдела нужна система с ИБ-контекстом: привязкой к регуляторным требованиям, учётом СЗИ/СКЗИ, сверкой с БДУ ФСТЭК.
• Автоматический сбор данных — обязательное условие актуальности. Ручная CMDB устаревает за квартал.
• Начинайте с критичного сегмента, а не с полного охвата. Рабочая CMDB на 80% актуальности лучше «идеальной» системы в состоянии вечного внедрения.

КиберОснова SGRC — единственная российская платформа с полноценной ИБ-CMDB: агентный сбор на Astra Linux и других российских ОС, автоматическая сверка с БДУ ФСТЭК, учёт СКЗИ по Приказу ФАПСИ №152 и привязка всех активов к ИСПДн, ГИС и объектам КИИ — в одном интерфейсе. Вы получаете не просто базу данных конфигураций, а рабочий инструмент управления безопасностью, готовый к проверкам ФСТЭК и ФСБ с первого дня.

Запросите демо — за 30 минут покажем CMDB в работе на реальных данных вашей инфраструктуры.