WSUS и группа Emergency: как три волны патчей изменили нашу конфигурацию

Когда в сентябре разбирали процесс patch-менеджмента после Shellshock, основное внимание было на Linux. WSUS для Windows упоминался вскользь: мол, там-то всё понятно, Patch Tuesday, плановые окна, группы, всё расписано. Два месяца и три волны экстренных обновлений спустя - понятно уже не так однозначно.

Поводом для пересмотра стало следующее: когда вышел MS14-060 по Sandworm, мы переводили все Windows-хосты в форсированную группу WSUS вручную. Это работает, но выглядит как костыль: создаём ситуацию, когда инженер в режиме аврала руками двигает машины между группами. Это и медленно, и рискованно - кто-нибудь обязательно окажется забытым.

Что было до

Стандартная конфигурация WSUS на Windows Server 2012 R2 у большинства клиентов выглядела примерно одинаково: несколько групп по типам серверов, автоматическое одобрение отключено (чтобы не прилетело обновление в неподходящий момент), плановая синхронизация раз в сутки, установка - в ночное окно обслуживания.

Для спокойного режима это разумная схема. Проблема возникла, когда «спокойный режим» закончился. Shellshock в конце сентября, POODLE и Sandworm 14 октября - всё это потребовало действий в течение нескольких часов, а не в ближайшее ночное окно. Windows-машин у клиентов достаточно, чтобы ручное управление группами при каждом таком случае превращалось в отдельную задачу.

Группа Emergency

Решение, к которому пришли: отдельная группа WSUS под названием Emergency - с автоматическим одобрением для категорий Critical Updates и Security Updates.

Логика такая: Critical и Security от Microsoft - это уже прошедшая фильтрацию категория. Microsoft сами помечают обновление Critical, когда там эксплуатируемая уязвимость или высокая вероятность эксплуатации. Мы не теряем на этом контроль над тем, что именно ставится - мы теряем задержку между «обновление появилось» и «обновление одобрено».

Настройка в консоли WSUS:

• Automatic Approvals - создаём правило: если Classification = «Critical Updates» или «Security Updates», и Group = «Emergency», то Action = «Approve».
• В группу Emergency добавляем все активные Windows-хосты клиентов. Не «все серверы» - именно все хосты, включая рабочие станции, где это применимо.
• Deadline на установку - 24 часа с момента одобрения. Это заставляет агентов не ждать следующего опроса, а получать задание в течение ближайшего цикла.

Синхронизацию с Microsoft Update выставили на каждые 3 часа - раньше была раз в сутки. Когда выходит экстренный out-of-band патч, 24-часовая задержка до появления в каталоге уже неприемлема.

Что осталось от старой схемы

Группа Emergency не заменила старые группы, а встала рядом. Плановые обновления - Definition Updates для Defender, Feature Packs, обычные накопительные пакеты - по-прежнему идут через стандартные группы с ночными окнами и ручным одобрением. Emergency закрывает только критический и безопасный трек.

Это принципиально: автоматическое одобрение всего подряд - это другая история с другими рисками. Feature Packs или крупные накопительные обновления могут ломать совместимость, требуют проверки перед применением. Критические патчи безопасности - другая категория, там скорость важнее.

Что проверяем дополнительно

После пересмотра конфигурации добавили несколько контрольных точек в мониторинг:

• Статус WSUS-агентов. Агент на хосте может зависнуть или остановиться - мы это обнаружили при работе с MS14-060. Теперь хосты, от которых нет отчёта в WSUS дольше 48 часов, попадают в алерт.
• Pending Restart. WSUS-консоль показывает «Installed/Pending Restart» - технически патч установлен, но не применён. Для рабочих станций это часто нормально: перезагрузятся через сутки. Для серверов - отдельный контроль с уведомлением клиенту.
• Синхронизация каталога. Если синхронизация не завершилась за отведённое время - алерт, потому что при экстренном патче задержка в получении каталога критична.

Что не идеально

Честно: автоодобрение Critical/Security - это доверие к классификации Microsoft, а не к нашей оценке конкретного обновления. Были случаи, когда патч с меткой Critical оказывался некритическим для конкретной конфигурации - например, закрывал компонент, которого просто нет на хосте. В обычном режиме мы бы посмотрели, оценили, возможно отложили бы. С автоодобрением - он ставится.

Мы пришли к выводу, что это приемлемый компромисс. Ложноположительное срабатывание - лишнее обновление на сервере, перезагрузка не в самое удобное время. Ложноотрицательное - открытая уязвимость, пока инженер не дойдёт до ручного одобрения. Для критического трека второй риск перевешивает.

Более сложный вопрос - что будет, если Microsoft выпустит что-то с меткой Critical, что реально сломает работающую систему. Пока таких случаев не было в этом году, но расслабляться не стоит. Ответом на этот риск должен быть нормальный тестовый контур перед боевым - это отдельная задача, которую пока решаем частично.

В рамках managed-сопровождения эта конфигурация стала стандартной для всех клиентов с Windows-инфраструктурой. Осень 2014-го показала, что «плановый Patch Tuesday раз в месяц» - это не режим реагирования на текущий год.