Patch Tuesday февраль 2014: как мы тестируем патчи прежде чем катить на всё

Во вторник Microsoft выкатила февральский Patch Tuesday. Среди семи бюллетеней - четыре с рейтингом Critical, и три из них касаются Internet Explorer и компонентов ядра Windows. Для тех, кто ещё не мигрировал с XP (а таких всё ещё немало), это дополнительный повод для тревоги: патчи для XP ещё выходят, но до апреля осталось меньше двух месяцев.

Разговор сегодня не о самих уязвимостях, а о другом: как мы вообще катим патчи на клиентские инфраструктуры. Потому что «нажать Approve в WSUS» - это не процесс, это лотерея.

Почему нельзя просто одобрить и катить

Патч - это изменение системного кода. Любое изменение системного кода может что-то сломать. Microsoft тестирует свои обновления на широкой матрице конфигураций, но ваша конкретная инфраструктура в эту матрицу не входит: у вас своё прикладное ПО, свои версии драйверов, свои кастомные настройки IE в GPO.

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

Поэтому у нас есть процесс. Небыстрый - но управляемый.

Три слоя перед массовым выкатом

Тестовая OU. Первое - небольшая группа машин, выделенная специально под тесты. Не «лишние компьютеры в углу», а рабочие станции с реальным типовым набором ПО: офисный пакет, корпоративный браузер, антивирус, типичная учётная запись без прав администратора. WSUS-группа для тестовой OU получает Approved немедленно после выхода патчей. Машины применяют обновления, мы смотрим на результат через день.

Это не полноценное тестирование, но базовые проблемы - вылет приложений при старте, сломанный IE, проблемы с логином - всплывают именно здесь. За день-два.

Пилотная группа. Если тестовая OU отработала без происшествий, патчи уходят в пилот - двадцать-тридцать процентов парка. Сюда попадают машины из разных отделов, с разными ролями и разным ПО. Пилот живёт три-пять рабочих дней. В это время мы мониторим обращения в хелпдеск, смотрим на WSUS-статусы и Event Log с основных машин.

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

Массовый выкат в окно обслуживания. Если пилот прошёл - всё остальное уходит в согласованное окно обслуживания. Обычно ночь с воскресенья на понедельник или ранее утро. Машины применяют патчи, перезагружаются если нужно, пользователи к началу рабочего дня уже работают на обновлённых системах.

Окно обслуживания - не просто «чтобы не мешать», это ещё и страховка: если что-то пошло не так, есть время отреагировать до того, как люди начнут работать.

Несколько нюансов по WSUS

Approvals в WSUS мы выставляем по компьютерным группам, а не глобально. Три группы как минимум: Test, Pilot, Production. Машины в Active Directory попадают в WSUS-группы через GPO - ничего не нужно назначать руками.

Deadline на Production-группу мы ставим всегда - иначе часть машин просто не установит обновления, потому что пользователь каждый раз откладывает перезагрузку. С Deadline WSUS принудительно применяет обновления и перезагружает машину в нужное время, даже если пользователь нажимал «напомнить позже» всю неделю.

Серверы - отдельная история. Там нет автоматического Deadline, всё согласуется с клиентом: какой сервер, когда, с каким резервным временем на откат. Критические патчи для серверов мы стараемся катить в течение недели-двух, некритические - в плановый цикл раз в месяц.

Про февральские патчи конкретно

IE-патч (MS14-010 и MS14-011) - критический, RCE через специально сформированную веб-страницу. Это не история «пользователь должен постараться», это вполне реальный вектор через почту или заражённый ресурс. Для инфраструктур, где IE используется для внутренних порталов или банк-клиентов, откладывать не стоит.

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

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