Управление изменениями в ИТ: карточка, проверка ИБ и откат

Частая причина сбоев и дыр в защите — не атака, а собственное изменение: открыли порт «на время», обновили пакет без отката, изменили правило firewall и потеряли доступ. Управление изменениями не требует тяжёлых систем: достаточно единой карточки, нескольких вопросов от безопасности и проверенного плана отката. Ниже порядок, который можно ввести в небольшой команде за неделю.

Статья опирается на логику направления «Управление изменениями» из методики зрелости кибербезопасности Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Команды перед применением проверяйте на тестовой машине.

Что должно получиться

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

Типы изменений

Не всё нужно согласовывать долго. Разделите изменения по типам, чтобы быстрые оставались быстрыми:

Шаг 1. Заведите карточку изменения

Карточка — один короткий документ или задача в трекере. Минимальный набор полей:

Изменение: ID-ДАТА-КРАТКОЕ_ИМЯ
Тип: стандартное | обычное | срочное | крупное
Автор: ФИО        Владелец системы: ФИО
Что меняем: одно-два предложения
Зачем: причина (заявка, уязвимость, развитие)
Затронутые системы и данные: список, есть ли персональные данные
Окно работ: ДАТА ВРЕМЯ - ДАТА ВРЕМЯ
Проверка ИБ: см. вопросы ниже, результат и кто проверил
План выполнения: шаги
План отката: шаги и время на откат
Как проверим результат: команды или признаки
Итог: выполнено | откачено | отменено, ДАТА, замечания

Если инфраструктура описана кодом, карточкой служит запрос на слияние (merge request) в репозитории: защитите основную ветку, потребуйте одобрение второго человека и пропускайте код через автоматические проверки: Dependency-Track и SonarQube в GitLab CI, поиск секретов.

Шаг 2. Проверьте изменение с точки зрения ИБ

Ответственный за ИБ отвечает на короткий список вопросов до выполнения. Если ответ «да» на любой из первых шести, изменение идёт по обычному, а не стандартному порядку:

Шаг 3. Подготовьте откат

Откат — условие согласования. Что записать: как вернуть прежнее состояние, сколько это займёт, при каком признаке вы решаете откатываться. Принципы:

• перед изменением конфигурации копируйте файл и проверяйте синтаксис новой версии (nginx -t, sshd -t, nft -c);
• для снимка виртуальной машины или базы данных проверьте, что восстановление реально работает;
• изменение сетевых правил и доступа делайте с автоматическим откатом, чтобы не потерять удалённый доступ.

Пример автоматического отката правил nftables (на проверенной тестовой машине; пути и имена замените своими, а таймер подберите по времени проверки):

sudo cp /etc/nftables.conf /root/nftables.conf.bak
sudo nft -c -f /etc/nftables.conf.new
sudo systemd-run --on-active=2min --unit=fw-rollback /usr/sbin/nft -f /root/nftables.conf.bak
sudo nft -f /etc/nftables.conf.new

Что должно получиться: новая политика применилась, а через две минуты прежние правила вернутся сами. Если вы по-прежнему подключены и всё работает, отмените откат и закрепите изменение:

sudo systemctl stop fw-rollback.timer
sudo cp /etc/nftables.conf.new /etc/nftables.conf

Риск: если запустить второй откат с тем же именем, systemd откажется. Держите открытой вторую сессию SSH на время работ.

Шаг 4. Выполните в окно работ и проверьте результат

1. Предупредите затронутых пользователей и поддержку.
2. Выполните шаги по плану, фиксируя время и вывод ключевых команд.
3. Проверьте результат способом из карточки: сервис отвечает, правила на месте, события в журналах идут.
4. Если проверка не пройдена или время выходит, откатывайтесь по плану, не импровизируйте.
5. Закройте карточку: итог, время, замечания.

Срочные изменения

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

Журнал и сверка с реальностью

Журнал изменений ценен, только если он сходится с фактом. Включите контроль целостности критичных файлов конфигурации и сверяйте срабатывания с журналом: изменение без карточки либо забытая запись, либо несогласованное действие. Для небольшой инфраструктуры подойдёт контроль целостности в Wazuh на каталогах /etc и конфигурации сервисов.

Метрики

Диагностика

Где это в модели зрелости

Материал относится к направлению «Управление изменениями» (карта: карта зрелости). Уровень 1 закрывает запись изменений, уровень 2 добавляет правила согласования, карточку с откатом и проверкой результата. Связанные направления: управление уязвимостями и управление доступом, чьи проверки встроены в вопросы ИБ.

Как проверить

1. Последние пять существенных изменений имеют карточки с планом отката и итогом.
2. Ответственный за ИБ видел хотя бы одно изменение до выполнения и оставил замечание или одобрение.
3. Откат опробован на тестовой системе за последний квартал.
4. Срабатывание контроля целостности на конфигурации сопоставляется с карточкой за один рабочий день.

Источники

• Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
• NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems: csrc.nist.gov. Международная практика, не российский норматив.
• Документация systemd по systemd-run и --on-active для вашей версии: man systemd-run.