Управление конфигурацией информационной системы и безопасность: эталонные конфигурации, контроль изменений и дрейфа

Управление конфигурацией информационной системы держит под контролем всё, что меняется в инфраструктуре: состав компонентов, их настройки, версии пакетов и правила доступа. Работа сводится к четырём действиям: собрать инвентаризацию, зафиксировать эталонные конфигурации (baseline), проводить каждую правку через управляемый процесс и регулярно сверять фактическое состояние с эталоном.

Связь с безопасностью прямая. Незапланированное изменение открывает путь в обход защиты: лишний порт в firewall, добавленное правило в /etc/sudoers, отключённый SELinux, устаревший модуль веб-сервера. Такое расхождение не видно в мониторинге доступности, сервис продолжает отвечать на запросы, а требования к защите уже не выполняются.

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

Что такое управление конфигурацией ИС и почему это критично для безопасности

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

Ценность для безопасности в предсказуемости. Когда состояние серверов описано кодом и версионируется, любое отклонение можно найти и объяснить. Обратная ситуация: настройки живут в головах администраторов, часть правок вносится по SSH в спешке, и восстановить реальную картину получается только перебором файлов на сотне хостов. Стандарт ISO/IEC 27001:2022 относит управление конфигурацией к организационным мерам контроля (приложение A, контроль 8.9), а отраслевые требования к защите КИИ и персональных данных опираются на модель угроз и подтверждённое состояние систем.

Ключевые понятия: эталонная конфигурация, контроль изменений, дрейф

Эталонная конфигурация (baseline) - зафиксированный набор параметров компонента: версии ПО, настройки ОС и сервисов, состав пакетов, учётные записи и права, сетевые правила, параметры шифрования. Baseline хранят как артефакт: Ansible-роль, шаблон конфигурации, файл в Git с тегом версии. Текст в вики для этих целей не подходит, потому что его нельзя применить и проверить автоматически.

Контроль изменений - процесс, при котором правка проходит заявку, оценку риска, согласование, тест на стенде, применение и запись в историю. Итог: изменение либо попадает в baseline, либо отклоняется с обоснованием.

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

Аналогия с чертежом помогает разграничить роли. Baseline - это чертёж детали, допуски - список отклонений, которые считаются приемлемыми (например, диапазон версий ядра или набор разрешённых шифров), дрейф - выход за допуск. Без чертежа проверить деталь нечем.

Связь с управлением уязвимостями и аудитом

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

В русскоязычном контуре к тем же задачам добавляются Банк данных уязвимостей ФСТЭК, опубликованный ФСТЭК совместно с ГНИИИ ПТЗИ, и публичная база уязвимостей НКЦКИ, который координирует субъектов КИИ по обнаружению и ликвидации последствий компьютерных атак. Отдельно стоит держать под рукой раздел «Угрозы» Банка данных угроз: он опубликован в 2015 году и обязателен при моделировании угроз для систем защиты персональных данных, критической информационной инфраструктуры и государственных информационных систем.

Тактики и техники атакующих собраны в MITRE ATT&CK: база создана в 2013 году на основе реальных наблюдений и регулярно обновляется. Её разделы удобно превращать в чек-лист параметров защиты, например при проверке, отключено ли удалённое выполнение и ограничены ли учётные записи сервисов.

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

Инвентаризация компонентов инфраструктуры: первый шаг к управлению конфигурацией

Инвентаризация даёт список конфигурационных единиц и их атрибутов: имя, роль, ОС и версия, IP-адреса, открытые порты, установленные пакеты, ответственный, критичность. Способы сбора отличаются по трудозатратам: ручной обход, сканирование сети (nmap, masscan), агенты (osquery, Zabbix), учётные системы (NetBox, Device42). Разовый опрос оборудования устаревает за месяц, поэтому сбор переводят в расписание, а результат складывают в Git или CMDB.

Инвентаризация серверов и виртуальных машин

Минимальный набор данных по Linux-хосту собирается без установки агентов:

hostnamectl
uname -a
lscpu
ip a
ss -tulpn
systemctl list-units --type=service --state=running
dpkg -l | tail -n 3

Для Windows те же сведения дают встроенные командлеты:

Get-ComputerInfo
Get-Service | Where-Object {$_.Status -eq "Running"}
Get-HotFix

Ansible собирает факты сразу со всего парка и раскладывает их по файлам:

ansible all -m setup --tree facts/

Файлы фактов храните в формате JSON или YAML и версионируйте: тогда видно, когда на хосте появился новый диск, ядро или сетевой интерфейс. Запускайте сбор ежедневно по cron или в CI-пайплайне.

Инвентаризация сетевого оборудования

Коммутаторы и маршрутизаторы опрашивают по SNMP, по SSH или через API. Для устройств Cisco базовый набор команд выглядит так:

show version
show interfaces status
show vlan brief
show ip route
show running-config

Обязательные атрибуты для учёта: модель, версия прошивки, серийный номер, расположение, ответственный, номер порта подключения, список VLAN и ACL. Версию прошивки фиксируйте отдельным полем, иначе отследить устройства с уязвимой версией не получится. Документировать адресацию, префиксы и связи между устройствами удобно в NetBox, который хранит данные в структурированном виде и отдаёт их через API.

Инвентаризация приложений и зависимостей

Состав ПО и версии библиотек нужны, чтобы за минуты отвечать на вопрос, затронул ли новый CVE ваш парк. Список пакетов собирают штатными средствами:

dpkg -l
rpm -qa
pip freeze
npm list --depth=0

Для контейнеров и сборок удобен формат SBOM (Software Bill of Materials). Генерация перечня компонентов через syft выглядит так:

syft dir:/opt/app -o spdx-json > sbom.json

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

Создание эталонных конфигураций (baseline) для серверов, сетевого оборудования и приложений

Baseline отличаются от дефолтных настроек: параметры подбирают под требования безопасности и модель угроз. Источники: CIS Benchmarks, DISA STIG, рекомендации производителя, внутренние политики, требования регулятора. Порядок работы такой: выбрать эталонный экземпляр, привести его к целевому состоянию, протестировать на стенде, описать как код, прогнать сканером соответствия и сохранить в Git с тегом версии. Сканеры нужны для проверки: харденинг Linux-сервера с Lynis и OpenSCAP разобран пошагово.

Эталонная конфигурация серверов на примере Linux

Проверка фактических настроек выполняется тремя командами:

sshd -T
sysctl -a
systemctl list-unit-files --state=enabled

В sshd_config в baseline обычно входят: PermitRootLogin no, PasswordAuthentication no, X11Forwarding no, MaxAuthTries 3, AllowUsers с явным списком, ограниченные наборы Ciphers, KexAlgorithms и MACs. Из параметров ядра фиксируют net.ipv4.ip_forward=0, net.ipv4.conf.all.rp_filter=1, kernel.dmesg_restrict=1, fs.protected_hardlinks=1. Список включённых сервисов пересматривают: каждый лишний демон слушает порт и требует обновлений.

Описание baseline в Ansible сводится к задачам с lineinfile и template, а проверка соответствия запускается так:

oscap xccdf eval --profile cis --report report.html ssg-rhel9-ds.xml
lynis audit system

Отчёт OpenSCAP показывает, сколько правил пройдено, а Lynis даёт быструю оценку hardening index и подсказки по слабым местам.

Эталонная конфигурация сетевого оборудования

Типовой набор требований для коммутатора: отключённые неиспользуемые порты, явные ACL с запретом по умолчанию, парольная политика с enable secret вместо открытого пароля, NTP с внутренним источником, централизованный сбор логов, SNMPv3 с аутентификацией и шифрованием вместо community-строк. Пример команд для Cisco:

no cdp run
no ip http server
service password-encryption
logging host 10.0.0.20
ntp server 10.0.0.21
interface range GigabitEthernet1/0/20 - 24
 shutdown

Конфигурации хранят файлами в Git, а расхождения ищут сравнением:

git diff baseline/switch-core-1.cfg current/switch-core-1.cfg

Перед каждым плановым обновлением прошивки снимайте актуальный running-config и сравнивайте с эталоном: так видно, какие настройки могли остаться от прошлых работ.

Эталонная конфигурация приложений (веб-серверы, СУБД)

Для Nginx в baseline входят: server_tokens off, ssl_protocols TLSv1.2 TLSv1.3, явный список ssl_ciphers, ограничение методов через limit_except, выключенный autoindex, ограничение client_max_body_size. Для PostgreSQL: аутентификация scram-sha-256 в pg_hba.conf, ограничение listen_addresses до нужных интерфейсов, отзыв прав у public на схему public, включённые log_connections и log_disconnections, удаление неиспользуемых расширений.

Любое обновление приложения, закрывающее уязвимость, меняет baseline: сначала правка в репозитории, затем тест, затем раскатка и повторная проверка сканером. Без этого шага эталон быстро расходится с реальностью.

Контроль изменений конфигурации: процессы и инструменты

Классический процесс выглядит так: заявка на изменение с описанием и обоснованием, оценка рисков и влияния, согласование владельцем сервиса, тест на стенде, применение на продуктивной среде, проверка результата, запись в историю и обновление baseline. Ускоренный цикл для низкорисковых правок отличается только сокращённым списком согласующих, но тест и запись в историю остаются обязательными.

Основной инструмент контроля - система версионирования. Git даёт историю, авторство, возможность отката и ревью через merge request. Pre-commit хуки и линтеры ловят синтаксические ошибки до применения: ansible-lint проверяет плейбуки, yamllint - синтаксис YAML, molecule прогоняет роль в контейнере или на виртуальной машине.

Автоматизация контроля изменений с помощью Ansible и Git

Структура репозитория, которая выдерживает рост парка:

inventory/
  production/hosts.yml
group_vars/
  all.yml
roles/
  nginx/
    tasks/main.yml
    templates/nginx.conf.j2
playbooks/
  site.yml

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

ansible-playbook site.yml --check --diff --limit staging
ansible-playbook site.yml --limit production

Флаг --check показывает, что изменилось бы на хостах, а --diff печатает построчные различия файлов. Такой прогон перед раскаткой отвечает на вопрос, не затронет ли правка больше систем, чем планировалось.

Инструменты для аудита изменений: auditd, osquery, SIEM

На уровне ОС изменения в критичных файлах отслеживает auditd. Правила добавляют в /etc/audit/rules.d/ так, чтобы они переживали перезагрузку:

auditctl -w /etc/ssh/sshd_config -p wa -k sshd_cfg
auditctl -w /etc/sudoers -p wa -k sudoers
auditctl -w /etc/passwd -p wa -k accounts
ausearch -k sshd_cfg -ts today

osquery отвечает на вопросы о состоянии системы запросами на SQL-подобном языке, например поиск процессов, слушающих внешние интерфейсы:

SELECT pid, port, address, name FROM listening_ports WHERE address = '0.0.0.0';

События auditd и результаты запросов osquery отправляйте в SIEM и настраивайте оповещения по ключевым тегам: правка sshd_config, sudoers, файлов cron, модулей ядра. Без оповещений журнал остаётся архивом, который читают только после инцидента.

Обнаружение дрейфа конфигурации и реагирование на него

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

Ручное и автоматическое обнаружение дрейфа: команды и скрипты

Сравнение файла конфигурации с эталоном:

diff -u /opt/baseline/sshd_config /etc/ssh/sshd_config

Проверка всего парка без внесения изменений:

ansible-playbook site.yml --check --diff
ansible all -m command -a 'sshd -T' --check

Для сетевого оборудования сохраните running-config в файл и сравните с эталоном тем же diff. Автоматизировать рутину удобно коротким скриптом, который складывает результат в отчёт:

#!/usr/bin/env bash
BASE=/opt/baseline
REPORT=/var/log/drift-report.txt
: > "$REPORT"
for f in sshd_config sudoers nginx.conf; do
  if ! diff -q "$BASE/$f" "/etc/$f" >/dev/null 2>&1; then
    echo "DRIFT: $f" >> "$REPORT"
  fi
done
if [ -s "$REPORT" ]; then
  cat "$REPORT" | mail -s 'Drift detected' security@example.com
fi

Скрипт запускают ежедневно по cron, а отчёт складывают рядом с логами, чтобы отслеживать повторяющиеся расхождения. Для сбора конфигураций с сетевого оборудования по SSH в Python используют библиотеку paramiko: она позволяет выполнить команду show running-config, сохранить вывод в файл и сравнить его с эталоном.

Практические шаги реагирования на дрейф

Порядок действий после срабатывания проверки:

1. Подтвердите расхождение: перечитайте фактический файл или параметр, исключите ложное срабатывание из-за разного форматирования.
2. Оцените риск: что именно изменилось, влияет ли правка на доступ, логирование, шифрование, права.
3. При подозрении на компрометацию изолируйте систему от сети и сохраните копии журналов и файлов до любых правок.
4. Разберите причину по журналам: auditd, syslog, история команд, изменения в системе контроля версий.
5. Примите решение: вернуть систему к эталону или оформить изменение через заявку и обновить baseline.
6. Зафиксируйте инцидент и проведите разбор, если причиной стало нарушение процесса.

Частый случай: проверка показывает новое правило в /etc/sudoers, а журнал auditd и разбор с командой выясняют, что администратор выдал себе права для разовой задачи и не оформил заявку. Техническое исправление здесь только половина работы, вторая половина - договорённость о порядке таких выдач и сроке их действия.

Связь управления конфигурацией с управлением уязвимостями и аудитом

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

Использование данных об уязвимостях (CVE, БДУ ФСТЭК, НКЦКИ, MITRE ATT&CK) для обновления baseline

Порядок работы: мониторить публикации CVE, Банка данных уязвимостей ФСТЭК и базы НКЦКИ, оценивать применимость к своему парку по данным инвентаризации и SBOM, определять, какие изменения нужны (обновление пакета, правка параметра, отключение модуля), проводить их через контроль изменений и обновлять baseline. База MITRE ATT&CK помогает посмотреть на задачу со стороны атакующего и проверить, не оставляет ли конфигурация путей для описанных техник.

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

Аудит конфигурации серверов: подготовка и прохождение

Аудит проверяет соответствие фактических настроек эталону и требованиям регулятора, наличие обновлений, корректность прав доступа и полноту логирования. Подготовка занимает меньше времени, когда инвентаризация, baseline и отчёты сканеров уже ведутся: остаётся выгрузить отчёты OpenSCAP по профилю CIS, свести список отклонений и приложить журналы.

Для организаций, работающих с персональными данными и объектами КИИ, добавляется проверка применяемых средств защиты. Государственный реестр сертифицированных средств защиты информации, опубликованный ФСТЭК, используют для контроля актуальности применяемых СЗИ: наличие сертификата и его срок проверяют по реестру до и во время аудита.

План проверки конфигураций по всей инфраструктуре, включая Docker, Kubernetes и Nginx, описан в материале про комплексный аудит безопасности IT-инфраструктуры.

Типичные ошибки при построении управления конфигурацией и как их избежать

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

Ошибка 1: Ручное вмешательство без фиксации в системе контроля версий

Правка по SSH выглядит быстрее, чем заявка и раскатка, и именно поэтому она ломает процесс. Изменение не проходит тест, не попадает в историю и не отражается в baseline, а при следующей раскатке плейбук вернёт прежнее значение и остановит сервис в неподходящий момент.

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

Ошибка 2: Игнорирование дрейфа конфигурации

Дрейф копится незаметно: администратор добавил тестовый порт в firewall, обновление пакета подтянуло новый конфигурационный файл, демон включился после перезагрузки. Через полгода фактическое состояние отличается от эталона настолько, что baseline перестаёт отражать реальность и теряет смысл.

Что делать: назначить периодичность проверок (ежедневно для критичных хостов, еженедельно для остальных), автоматизировать сравнение, настроить оповещения и разбирать каждое расхождение до решения: откат или легитимное изменение с обновлением эталона. Отдельно проверяйте, что расхождения не появились в результате действий злоумышленника: журналы auditd, изменения в учётных записях и правка sudoers требуют приоритетного разбора.

Инструменты для управления конфигурацией и контроля безопасности: сравнение и выбор

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

Сравнительная таблица инструментов

Границы между классами инструментов и критерии выбора под размер команды разобраны в сравнении CMDB, Git, Ansible, Puppet и Chef.

Рекомендации по выбору для разных сценариев

Парк до 50 серверов: Ansible с ролями, Git как хранилище эталонов, Lynis для быстрых проверок и OpenSCAP для отчётов, auditd на критичных хостах. Этого набора хватает, чтобы закрыть инвентаризацию, контроль изменений и обнаружение дрейфа без отдельной платформы.

Парк от нескольких сотен хостов: Puppet или Chef с центральным сервером, Foreman для управления группами, SIEM для сбора событий, отдельная CMDB для учёта. Здесь важнее скорость применения и единая точка контроля состояния.

Сетевое оборудование: Ansible с модулями для конкретных вендоров (cisco.ios, junipernetworks.junos) плюс Git для версионирования конфигураций. Если устройств немного и они разнородны, на первом этапе допустим сбор конфигураций скриптом по SSH с последующим сравнением с эталоном.

Заключение: как выстроить систему управления конфигурацией с фокусом на безопасность

Практический план на ближайший месяц: собрать инвентаризацию серверов, сетевого оборудования и приложений с версиями пакетов; выбрать один критичный сервис и описать его состояние как код в Git; зафиксировать baseline по CIS или STIG и проверить его сканером; настроить правила auditd на файлы конфигураций и ежедневное сравнение с эталоном; связать новые публикации CVE и БДУ ФСТЭК с изменениями в эталоне.

Дальше цикл повторяется: инвентаризация обновляется, baseline пересматривается при выходе патчей, изменения проходят через репозиторий и тест, дрейф разбирается до причины, а результаты проверок становятся доказательствами при аудите. Держите под рукой первичные источники, CIS Benchmarks, документацию Ansible и OpenSCAP, и возвращайтесь к ним при каждой правке эталона: точность формулировок в конфигурации важнее скорости её появления.