Обновления откладываются: как выстроить безопасность без вечного потом

Фраза «работает — не трогай» звучит как здравый консерватизм, пока на сервере не всплывает публичный эксплойт годичной давности. CMS, ОС, панели управления и библиотеки без патчей — любимая цель массовых сканеров. Обновления откладывают не из вредности: боятся сломать 1С, сайт или «тот самый» плагин. Но цена промедления — простой, утечка и разговор с регулятором.

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

Почему «потом» становится «уже поздно»

Типичная картина в МСБ: WordPress или 1С Битрикс на нескольких мажорных версий ниже актуальной, Ubuntu без security-апдейтов полгода, панель управления с известным CVE в шапке новостей. Админ знает. Директор не знает. Подрядчик «по часам» не заложен на регрессию. Пока трафик идёт — все спокойны. Когда ботнет или ransomware заходит по дыре из бюллетеня — начинается срочный проект за двойную цену.

• известные CVE эксплуатируются автоматически, без «целевой атаки»;
• страховки и корпоративные клиенты спрашивают patch policy на тендерах;
• после инцидента расследование всегда начинается с вопроса «почему не обновили»;
• накопленный долг обновлений делает следующее окно всё страшнее — замкнутый круг.

Что именно обычно копят

Страх поломки — валидный, но решаемый

Откладывают обновления не глупые люди. Ломаются кастомные модули Битрикс, сертифицированные связки 1С, «хрупкие» интеграции. Ответ — не героизм в пятницу в боевой контур, а конвейер: тестовый контур → регрессия критичных сценариев → окно изменений → откат. Без тестовый контур любое обновление действительно лотерея; с ним — управляемый риск.

Регламент, который выдерживает реальность

1. Инвентарь. Список хостов, ролей, версий ОС/CMS, владельцев, критичности.
2. Классификация патчей. Critical security — дни; важные — недели; функциональные — по релизу продукта.
3. Окна. Согласованные слоты с бизнесом (не «когда админ свободен»).
4. Тестовый контур. Копия или близкий контур для быстрая проверка тестов: логин, оплата, обмен с 1С, отчёты.
5. Откат. Снимок диска / бэкап до работ + проверенный откат.
6. Отчёт. Что обновили, что отложили с датой и риском — для директора и ИБ.

Как не убить 1С и сайт одним апдейтом

• разделяйте OS security updates и мажорные апгрейды CMS;
• для 1С сверяйтесь с рекомендациями партнёра и ITS до смены платформы ОС;
• плагины WordPress/Битрикс обновляйте пакетами с регрессией витрины и админки;
• не смешивайте «починим заодно» десять хотелок в одном окне патчей;
• после работ — мониторинг ошибок и ключевых бизнес метрик первые 24 часа.

Инструменты без культа

Где то хватает unattended-upgrades + WSUS/аналог и чеклиста CMS. Где то нужен vulnerability scanner и тикеты на каждое critical. Главное — владелец метрики «срок закрытия critical CVE». Сканер без процесса только генерирует PDF, которым пугают раз в квартал.

Ошибки, которые дорого стоят

• патчить боевой контур без бэкапа «потому что места мало»;
• отключать автообновления и забывать ручной график;
• держать phpMyAdmin и тестовые панели в интернете «на всякий случай»;
• считать WAF заменой патчей — WAF снижает, но не закрывает долг;
• прятать отсрочки от руководства: директор узнаёт из письма «вас взломали»;
• копить год, а потом пытаться закрыть всё одним ночным окном.

Пилотный контур на 30 дней

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

Связь с облаком и миграциями

Иногда долг патчей настолько велик, что дешевле поднять чистый контур в Yandex Cloud и перенести сервисы, чем «лечить» легаси на месте. Это решение принимают после аудита, а не из паники. Патч менеджмент на новом контуре закладывают сразу — иначе через год история повторится уже на красивых виртуалках.

FAQ

Можно ли обновляться раз в полгода пакетом? Для critical security — нет. Для минорных фич CMS — иногда да, но security-поток отдельно.

Что делать, если подрядчик «не гарантирует» после патча? Значит, нет тестовый контур и DoD. Меняйте процесс или подрядчика, а не копите CVE.

Нужен ли SOC? Сначала инвентарь, патчи, бэкапы и базовый мониторинг. SOC без гигиены — дорогой телескоп на болото.

Как убедить директора выделить окно? Покажите публичный CVE на вашей версии и стоимость часа простоя — обычно этого достаточно.

Чеклист руководителю

• есть ли список серверов и дата последнего security-обновления;
• кто отвечает числом за закрытие critical за N дней;
• есть ли тестовый контур для сайта и учётной системы;
• когда следующее согласованное окно — в календаре, а не «в уме»;
• есть ли отчёт «что отложено и до когда».

Метрики, которые видит руководитель

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

«Работает — не трогай» уместно для экспериментального стенда. Для витрины, почты и учётной системы это ставка против публичных эксплойтов. Управляемые обновления сценируют риск; бесконечные отсрочки его только накапливают.

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

Следующий шаг

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

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