Цикл patch management: что должно происходить каждый месяц
- Актуализировать инвентаризацию активов: состав серверов, их версии Windows Server, роли, владельцев и зависимости.
- Проверить, поддерживается ли конкретный выпуск ОС и есть ли у него право получать обновления.
- Получить список ожидаемых обновлений, сопоставить его с бюллетенями Microsoft и оценить риск для конкретных хостов.
- Подготовить тестовую группу, план развёртывания, окно обслуживания, критерии успеха и действия при сбое.
- Установить обновления по волнам, контролировать статус установки и необходимость перезапуска.
- После reboot проверить ОС, службы, доступность приложения и бизнес-функции.
- Зафиксировать результат, ошибки и исключения; назначить срок пересмотра для каждого не обновлённого сервера.
У такого процесса должны быть владельцы: технический владелец сервера подтверждает работоспособность роли, владелец сервиса согласует простой, команда эксплуатации выполняет изменение, а владелец риска принимает решение об отсрочке. Это предотвращает ситуацию, когда патч установлен формально, но зависимый сервис не проверен.
Инвентаризация перед запуском обновлений
Для каждого хоста создайте или актуализируйте карточку. Минимальный набор нужен и дл я регулярных обновлений безопасности Windows Server, и для внеочередного патча.
Карточка сервера для patch management
| Сведения | Что фиксировать | Зачем это нужно |
|---|---|---|
| Идентификация | Имя хоста, FQDN, IP-адреса, среда: production, test, development | Исключает обновление не того узла и помогает группировать волны. |
| ОС | Выпуск, редакция, тип установки Server Core или Desktop Experience, версия, номер сборки, архитектура | Определяет применимость обновлений и статус жизненного цикла. |
| Роль и сервис | Например, веб-сервер, файловый сервер, AD DS, сервер БД, сервер приложений; критичные службы и порты | Определяет тесты после установки и последствия простоя. |
| Владельцы | Технический владелец, владелец сервиса, согласующий изменение, контакты для эскалации | Позволяет согласовать окно и быстро проверить результат. |
| Критичность | Критичность актива, допустимый простой, требования RTO/RPO, внешняя доступность | Помогает выбрать порядок развёртывания и срок устранения риска. |
| Зависимости | Клиенты, базы данных, контроллеры домена, балансировщики, очереди, внешние API, порядок запуска | Нужны для плана reboot и проверки цепочки сервиса. |
| Управление обновлениями | Выбранный инструмент, группа развёртывания, источник обновлений, назначенное окно, политика перезапуска | Делает состояние управляемым, а не зависящим от ручных действий. |
| Восстановление | Согласованный способ восстановления, ответственный и критерий, когда переходить к не му | Позволяет действовать при неудачной установке без импровизации. |
Get-ComputerInfo | Select-Object WindowsProductName, WindowsDisplayVersion, WindowsVersion, OsBuildNumberОжидаемый результат — значения WindowsProductName, WindowsDisplayVersion, WindowsVersion и OsBuildNumber. Состав и заполненность полей зависят от выпуска ОС. Если команда недоступна или выдаёт неполные сведения, используйте `systeminfo` и данные средства управления конфигурацией.Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20 HotFixID, Description, InstalledOnОжидаемый результат — список KB и дат установки. Отсутствие нужного KB может означать, что оно заменено более новым накопительным обновлением; сверяйте заменяемость в сведениях Microsoft.Версия, сборка и история установки
winver, параметрах Windows Update, разделе истории обновлений и в журнале Microsoft-Windows-WindowsUpdateClient/Operational. Доступность интерфейсов и состав полей различаются между Server Core, Desktop Experience и версиями Windows Server. Для контроля развёртывания предпочтительнее отчёт выбранного централизованного средства вместе с номером сборки ОС.Поддерживаемая Windows Server и окончание жизненного цикла
Работающая система не обязательно поддерживается. Поддерживаемость определяется точным выпуском Windows Server, редакцией, каналом обслуживания и условиями лицензирования, а не только названием «Windows Server». Сверяйте каждый выпуск с актуальной страницей Microsoft Lifecycle перед планированием обновлений и миграции.
Даты для выпусков LTSC по Microsoft Lifecycle; их следует повторно сверять перед принятием решения
| Выпуск Windows Server LTSC | Окончание основной поддержки | Окончание расширенной поддержки | Статус после этой даты |
|---|---|---|---|
| Windows Server 2016 | 11 января 2022 года | 12 января 2027 года | Регулярные обновления прекращаются; возможность ESU зависит от доступной программы и условий. |
| Windows Server 2019 | 9 января 2024 года | 9 января 2029 года | Регулярные обновления прекращаются; возможность ESU зависит от доступной программы и условий. |
| Windows Server 2022 | 13 октября 2026 года | 14 октября 2031 года | Регулярные обновления прекращаются; возможность ESU зависит от доступной программы и условий. |
| Windows Server 2025 | 13 ноября 2029 года | 14 ноября 2034 года | Регулярные обновления прекращаются; возможность ESU зависит от доступной программы и условий. |
Окончание основной поддержки не равно немедленному окончанию исправлений безопасности: в период расширенной поддержки Microsoft продолжает выпускать предусмотренные политикой обновления безопасности для поддерживаемого выпуска. Для Windows Server 2016 Microsoft документирует возможность получать ESU в течение не более трёх ежегодных периодов после 12 января 2027 года. Это не продление полной поддержки: программа предоставляет предусмотренные её условиями обновления безопасности, но не возвращает выпуску новые функции и обычные исправления. Право на ESU, способ активации и доставки зависят от действующих условий лицензирования и размещения — например, от традиционной схемы лицензирования, подключения через Azure Arc или подходящего размещения в Azure. Условия необходимо повторно проверять перед каждым периодом ESU. Для Windows Server 2019, 2022 и 2025 нельзя автоматически переносить условия программы Windows Server 2016: доступность, сроки и способы получения ESU следует проверять на актуальных страницах Microsoft Lifecycle и ESU для конкретного выпуска и сценария.
EOL нельзя исправить одной настройкой
Какие обновления учитывать
Для поддерживаемых Windows Server обычной единицей обслуживания являются ежемесячные накопительные обновления качества. Они обычно включают исправления безопасности и надёжности, поэтому процедура не должна строиться на предположении, что на любом сервере доступен отдельный «только security» патч. Состав пакетов и модель обслуживания зависят от выпуска Windows Server и периода его поддержки.
- Накопительное обновление качества — основной ежемесячный пакет ОС; более новое накопительное обновление обычно включает предыдущие исправления для той же ветви.
- Security update — классификация или обновление, устраняющее уязвимость. Оно может поставляться в составе накопительного обновления качества.
- Servicing stack update (SSU) — обновление компонента обслуживания Windows Update. Для некоторых выпусков и периодов оно могло поставляться отдельно либо быть объединено с накопительным пакетом; устанавливайте его в составе и порядке, указанном Microsoft для конкретного обновления.
- Обновления .NET — обновления среды .NET и связанных компонентов. Их применим ость зависит от установленных версий .NET и роли приложений, поэтому они требуют той же оценки и тестирования.
Перед установкой откройте бюллетень безопасности в Microsoft Security Update Guide и проверьте затронутые продукты, CVE, KB, заменяемость, известные проблемы и сведения об эксплуатации. Поля о затронутом продукте, CVE и признаке Exploited помогают связать обновление с риском, но решение нельзя выводить только из CVSS. Полный процесс проверки применимости CVE и данных сканирования описан в статье «Управление уязвимостями сервера: CVE, сканирование и приоритизация».
Как часто обновлять сервер и когда менять график
Базовый вариант patch management policy для Windows Server — регулярный ежемесячный цикл с установленными сроками для разных групп критичности. Его удобно привязать к публикации е жемесячных обновлений Microsoft и к постоянному окну обновлений сервера. Конкретные сроки организация устанавливает по риску и допустимому простою, а не по единому числу дней для всех хостов.
Регулярные и внеочередные изменения
| Ситуация | Решение | Обязательные контроли |
|---|---|---|
| Обычные ежемесячные обновления | Тестирование и развёртывание в регулярное окно по утверждённым волнам | Проверка поддержки ОС, тест, план reboot, проверка сервиса, фиксация результата |
| Хост доступен из интернета или имеет высокую критичность | Назначить более раннюю волну и более короткий внутренний срок после теста | Подтвердить влияние на сервис и доступность отката |
| Есть известно эксплуатируемая уязвимость или сведения об активной эксплуатации | Провести внеочередное изменение, если уязвимость применима к хосту | Экстренная оценка воздействия, согласованное окно, проверка после установки и документирование |
| Патч нельзя установить в срок | Оформить временное исключение с компенсирующими мерами и сроком пересмотра | Владелец риска, причина, затронутые CVE/KB, дата следующего решения, план устранения |
Для срочной оценки используйте Security Update Guide, каталог KEV, сведения производителя приложения и контекст хоста: опубликован ли сервис, включён ли уязвимый компонент, есть ли работающий компенсирующий контроль. Даже внеочередная установка не должна пропускать оценку воздействия, план восстановления и проверку результата.
Тестовая группа и поэтапное развёртывание
Подготовка волны обновлений
Повторяйте этот порядок для ежемесячного и внеочередного изменения. Состав групп определяют роли и зависимости, а не случайная выборка серверов.
- 1Соберите ожидаемый набор обновленийЗафиксируйте дату, KB, затронутые продукты, CVE, известные проблемы и предполагаемую необходимость reboot. Проверьте, что пакет применим к версии и сборке ОС. Результат — утверждённый перечень обновлений для конкретной волны; при сомнении исключите хост из автоматического назначения до уточнения.
- 2Сформируйте представительную тестовую группуВключите не только наименее важный сервер, но и экземпляры тех же ролей, версий ОС, агентов, .NET-компонентов и прикладных зависимостей, что есть в production. Результат — тест покрывает значимые варианты конфигурации; если точного аналога нет, назначьте пилот из ограниченной production-волны с отдельным согласованием.
- 3Определите проверки до установкиЗафиксируйте исходную сборку ОС, состояние ключевых служб, доступность URL или портов, очередь заданий, ошибки приложения и допустимую длительность недоступности. Результат — измеримые критерии «работало до изменения»; если исходное состояние уже неисправно, отделите эту проблему от результата патча.
- 4Проведите тест с перезагрузкойУстановите тот же набор обновлений и выполните restart, если он требуется или запланирован для подтверждения состояния. Проверьте загрузку ОС, службы, приложение, аутентификацию и интеграции. Результат — подтверждение, что тестовая роль работает; при ошибке остановите следующую волну, сохраните логи и оцените восстановление.
- 5Разверните обновления волнамиТипичный порядок: тестовая группа, пилотная production-группа, некритичные серверы, затем критичные роли по согласованной последовательности. Не обновляйте одновременно все экземпляры отказоустойчивой роли, если это нарушает её модель доступности. Специфические процедуры обслуживания кластеров, гипервизоров и миграции ВМ находятся вне рамок этой статьи.
- 6Остановите волну по критериямЗаранее определите стоп-условия: неудачная установка, повторная загрузка, не стартовавшая служба, ухудшение ключевой метрики, потеря административного доступа или ошибка бизнес-проверки. Результат — оператор знает, когда не продолжать развёртывание и кого уведомить.
Перезагрузка как отдельный этап изменения
Установка пакета и его фактическое применение — разные события. Обновление может завершить загрузку и установку, но требовать restart для замены компонентов. План должен заранее задавать допустимый простой, порядок обслуживания зависимых серверов, проверку доступности после загрузки и действия при неуспешном запуске.
- Согласуйте, кто подтверждает начало и окончание простоя.
- Определите последовательность: например, сначала зависимые экземпляры приложения по одному, затем общая инфраструктурная роль только по её утверждённой процедуре.
- Проверьте доступ через консоль или BMC и наличие аварийного административного пути до перезагрузки.
- Зафиксируйте ожидаемое время загрузки и тайм-аут, после которого начинается диагностика и эскалация.
- Подготовьте проверки: доступность хоста, статус служб, журналы, сетевой путь, прикладной health check и подтверждение владельца сервиса.
- Согласуйте способ восстановления и условия его запуска. Удаление обновления не всегда возможно, не всегда устраняет проблему и само может потребовать reboot.
Не существует единого универсального статуса pending restart
Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, MessageОжидаемый результат — события поиска, загрузки, установки или ошибок. Если канал отсутствует либо данных недостаточно, проверьте журналы Setup и System, а также отчёт инструмента развёртывания.Проверка после установки и действия при проблеме
Закрытие изменения после обновления
- 1Подтвердите успешную загрузкуПроверьте, что сервер отвечает по согласованному каналу управления, ОС загрузилась, а номер сборки соответствует ожидаемому обновлению. Сравните с исходным состоянием. При невозможности подключения используйте предусмотренный консольный путь и не продолжайте волну.
- 2Проверьте статус обновленийСвер ьте отчёт WSUS, Configuration Manager, Azure Update Manager либо другого выбранного механизма с локальными данными: KB, дата установки, код результата и статус restart. Результат — у каждого хоста есть статус success, failed, pending restart или исключение; неопределённый статус требует разбора, а не отметки «успешно».
- 3Проверьте службу и её зависимостиВыполните заранее определённые проверки: состояние служб, открытие прикладного URL, подключение клиента, выполнение безопасной тестовой операции, обработку очереди или репликацию — в зависимости от роли. Проверка «сервер отвечает на ping» недостаточна для подтверждения сервиса.
- 4Просмотрите ошибки периода измененияПроверьте System, Setup, Windows Update и журналы приложения за время установки и загрузки. Сопоставьте новые ошибки со временем изменения. При ошибке сохраните идентификатор KB, код, события и фактические симптомы для эскалации.
- 5Примите решение об откате или восстановленииЕсли достигнут заранее согласованный стоп-критерий, остановите следующую волну. Дальше действуйте по утверждённому плану: диагностируйте известную проблему, при применимости удалите обновление или перейдите к согласованному восстановлению. Восстановление выполняйте по заранее утверждённой процедуре; настройка резервного копирования и полного аварийного восстановления находится вне рамок этой статьи.
Средства обнаружения и развёртывания Windows Server updates
Выбирайте средство по размещению серверов, масштабу, требуемому утверждению обновлений, отчётности, интеграции с группами устройств и управлению окнами. Интерфейсы, названия статусов, политики автоматической установки, параметры reboot и доступные команды зависят от версии Windows Server и конкретного продукта. Для точных настроек сверяйтесь с официальным руководством Microsoft для используемой версии ОС и средства.
Инструменты не являются полностью взаимозаменяемыми
| Средство | Когда подходит | Что проверить до выбора |
|---|---|---|
| Windows Update на самом сервере | Небольшое число отдельно управляемых или вручную сопровождаемых серверов с доступом к настроенному источнику обновлений | Кто утверждает установку, как исключить одновременный reboot, где хранится история и как подтвердить результат |
| Windows Server Update Services (WSUS) | Нужен локальный механизм синхронизации, одобрения и распространения обновлений Windows | Поддержку вашей версии Windows Server, классификации и продукты, место на хранилище, порядок одобрения и отчётность |
| Microsoft Configuration Manager | Есть действующая инфраструктура Configuration Manager и нужны коллекции, развёртывания, окна обслуживания и отчётность | Поддержку клиента и ОС, гр аницы, коллекции, точки обновлений, maintenance windows и политику restart |
| Azure Update Manager | Azure ВМ и гибридные/локальные серверы, подключённые через поддерживаемую схему Azure Arc | Поддержку региона, ОС и Arc, права Azure, сеть, расписания, maintenance configurations и отчёт о результате |
WSUS остаётся поддерживаемым механизмом для существующих сценариев, однако Microsoft помечает его как deprecated: новых возможностей не планируется, при этом текущие возможности сохраняются и обновления продолжают публиковаться. Это не означает немедленной необходимости отключить WSUS, но при новом проектировании стоит отдельно оценить его жизненный цикл и альтернативы. Configuration Manager и Azure Update Manager решают другие задачи и имеют собственные требования к инфраструктуре, лицензированию, агентам и поддерживаемым средам.
Автоматизация не отменяет контроля
Что фиксировать после патча и как оформлять исключение
Минимальные записи для аудита и последующего разбора
| После успешной установки | При временном исключении |
|---|---|
| Идентификатор изменения, дата и волна | Идентификатор изменения и причина отсрочки |
| Хосты, выпуск ОС, сборка до и после обновления | Затронутые хосты, роли, версия ОС и применимые KB/CVE |
| Установленные KB, источник и результат установки | Почему обновление нельзя поставить сейчас: техническое ограничение, зависимость, отсутствие окна или иной факт |
| Факт и время reboot, если он выполнялся | Оценка риска, включа я внешнюю доступность и сведения об эксплуатации |
| Результаты технической и прикладной проверки | Компенсирующие меры и их владелец |
| Ошибки, отклонения и принятые действия | Владелец риска, согласование, дата истечения исключения и следующая дата пересмотра |
Сравнивайте фактическое состояние с утверждённым состоянием: отсутствие патча, незапланированный reboot или неучтённая версия ОС — признаки конфигурационного дрейфа. Отчёт о покрытии обновлениями должен показывать не только процент успешных установок, но и хосты без данных, ожидающие reboot, неудачные установки, EOL-системы и активные исключения. Это позволяет измерять конфигурационное соответствие, а не только количество запущенных задач.
Границы процедуры
Термины в статье
- Бюллетень безопасности
- Бюллетень безопасности — официальное уведомление о риске или уязвимости, содержащее сведения о затронутых версиях, последствиях и мерах защиты.
- Известно эксплуатируемая уязвимость
- Известно эксплуатируемая уязвимость — уязвимость с подтверждёнными данными об использовании в атаках, тре бующая приоритетной оценки и устранения.
- Инвентаризация активов
- Инвентаризация активов — процесс выявления и ведения учёта ИТ-активов, их владельцев, характеристик, состояния и значимости для организации.
- Каталог KEV
- Каталог KEV — поддерживаемый CISA перечень CVE-уязвимостей с подтверждённой эксплуатацией, используемый для приоритизации устранения рисков.
- Конфигурационное соответствие
- Конфигурационное соответствие — сте пень, в которой фактические параметры ИТ-объекта отвечают утверждённой политике, шаблону или базовой линии.
- Конфигурационный дрейф
- Конфигурационный дрейф — накопившееся отклонение фактической конфигурации системы от утверждённого эталона вследствие несогласованных или незафиксированных изменений.
- Критичность актива
- Критичность актива — оценка важности ИТ-актива для бизнеса по последствиям его отказа, компрометации или недоступности, определяющая приоритет защиты и восстановления.
- Окно обслуживания
- Окно обслуживания — согласованный интервал времени для плановых работ с ИТ-системой, когда допустимы ограничение функциональности, перезапуск или недоступность сервиса.
- Остаточный риск
- Остаточный риск — уровень риска, сохраняющийся после внедрения и применения мер защиты, включая технические, организационные и компенсирующие контроли.
- Патч безопасности
- Патч безопасности — обновление ПО, ОС или прошивки, устраняющее конкретную уязвимость либо снижающее риск её эксплуатации без обязательного изменения функциональности.
- Принятие риска
- Принятие риска — формальное решение владельца риска допустить остаточный риск без дополнительных мер либо после внедрения выбранных мер контроля.
- Управление патчами
- Управление патчами — процесс учёта, оценки, тестирования, развёртывания и контроля обновлений ПО и прошивок для снижения риска уязвимостей и сбоев.
- Управление уязвимостями
- Управление уязвимостями — непрерывный процесс выявления, оценки, приоритизации и устранения слабых мест ИТ-активов с контролем результата и остаточного риска.