План развертывания обновления виртуальных машин Windows в Azure

Если вы заблокировали доступ из Интернет к виртуальной сети Azure, вы по-прежнему сможете получать обновления Windows, не жертвуя безопасностью и не открывая доступ ко всему Интернету. Эта статья содержит рекомендации по настройке сети периметра, также называемой промежуточной подсетью, для размещения экземпляра Windows Server Update Service (WSUS), позволяющего безопасно обновлять виртуальные сети без подключения к Интернету.

Если вы используете брандмауэр Azure, вы используете WindowsUpdate тег FQDN в правилах приложения, чтобы разрешить необходимый исходящий сетевой трафик через брандмауэр. Дополнительные сведения см. в разделе "Общие сведения о тегах FQDN " и "Планирование обновлений программного обеспечения" — настройка брандмауэров.

Для реализации рекомендаций, описанных в этой статье, необходимо ознакомиться со службами Azure. В следующих разделах описывается рекомендуемая схема развертывания, которая использует конфигурацию концентратора в одном регионе или многорегионной конфигурации.

Топология сети концентратора виртуальной сети Azure

Рекомендуется настроить топологию сети с радиальной моделью, создав периферийную сеть. Разместите сервер WSUS на виртуальной машине Azure, которая находится в Центре между Интернетом и виртуальными сетями. Центр должен иметь открытые порты. Для получения обновлений от Майкрософт на этом сервере WSUS используются порт 80 для протокола HTTP и порт 443 для протокола HTTPS. Периферийные сети - это все остальные виртуальные сети, которые будут обмениваться данными с концентратором, но не с интернетом. Это можно сделать, создав подсеть, группы безопасности сети (НСГ) и пиринг между виртуальными сетями Azure, которые позволяют прохождение трафика WSUS, блокируя другой интернет-трафик. На этом изображении показан пример топологии с концентраторами:

Скачайте файл Visio для этой архитектуры.

На этом рисунке:

• snet-wsus — это подсеть в центре концентратора и периферийной топологии, содержащей сервер WSUS.
• nsg-ds — это правило группы безопасности сети, которое разрешает трафик для WSUS, блокируя другой интернет-трафик.
• Виртуальная машина службы обновления Windows Server — это виртуальная машина Azure, настроенная для запуска WSUS.
• Snet-workload — это пример подсети в пиринговой виртуальной сети, содержащей виртуальные машины Windows.
• nsg-ms — это групповая политика безопасности сети, которая разрешает трафик на виртуальную машину WSUS, но запрещает другой интернет-трафик.

Вы можете повторно использовать существующий сервер или развернуть новый сервер, который становится сервером WSUS. Виртуальная машина WSUS должна соответствовать документированных системным требованиям. Поскольку это возможность, связанная с чувствительной безопасностью, вы должны запланировать доступ к этой виртуальной машине с помощью JIT. См. Управление доступом к виртуальным машинам с помощью Just-in-Time.

В вашей сети будет несколько виртуальных сетей Azure, которые могут размещаться в том же или в разных регионах. Необходимо оценить все виртуальные машины Windows Server, чтобы узнать, можно ли использовать его в качестве сервера WSUS. Если вы будете обновлять несколько тысяч виртуальных машин, мы рекомендуем выделить для роли WSUS отдельную ВМ Windows Server. Мы также рекомендуем, чтобы виртуальные машины не использовали сервер WSUS в другом регионе в качестве основного источника.

Если все виртуальные сети находятся в одном регионе, мы предлагаем выделить отдельный сервер WSUS на каждые 18 000 виртуальных машин. Это предложение основано на сочетании требований к виртуальной машине, количеству обновляемых клиентских виртуальных машин и стоимости связи между виртуальными сетями. Дополнительные сведения о требованиях к емкости WSUS см. в разделе Planing a WSUS Deployment (Планирование развертывания WSUS).

Для расчета затрат на применение этих конфигураций воспользуйтесь калькулятором цен Azure. Необходимо указать спецификации виртуальных машин WSUS и ваших сетевых ожиданий; один и тот же регион в разных регионах. Для передачи данных начните с 3 ГБ. Цены зависят от региона.

Ручное развертывание

После идентификации виртуальной сети Azure или определения необходимости создания нового экземпляра Windows Server необходимо создать правило NSG. Это правило позволит интернет-трафику, который позволяет метаданным и содержимому Центра обновления Windows синхронизироваться с создаваемым сервером WSUS. Ниже приведены правила, которые необходимо добавить.

• Правило NSG для входящего и исходящего интернет-трафика через порт 80 (для передачи содержимого).
• Правило NSG для входящего и исходящего интернет-трафика через порт 443 (для передачи метаданных).
• Правило NSG для разрешения входящего и исходящего трафика к клиентским виртуальным машинам через порт 8530 (по умолчанию, если не изменено).

Настройка WSUS

Для настройки сервера WSUS можно использовать один из двух подходов:

• Если вы управляете множеством серверов или хотите выполнять воспроизводимые развертывания без ручного вмешательства, автоматизируйте настройку, написав собственный скрипт PowerShell. Этот подход настраивает сервер для обработки типичной рабочей нагрузки с минимальными требованиями администрирования.
• Если вам нужно обрабатывать тысячи клиентов, работающих с различными операционными системами и языками, или если вы хотите настроить WSUS таким образом, чтобы скрипт не смог обрабатывать, настройте WSUS вручную. Оба подхода описаны в этой статье далее.

Вы также можете объединить два подхода с помощью скрипта, чтобы выполнить большую часть работы, а затем с помощью консоли администрирования WSUS для точной настройки параметров сервера.

Настройка WSUS с помощью скрипта автоматизации

Чтобы автоматизировать этот сценарий, создайте скрипт PowerShell. WSUS предоставляет поверхность PowerShell, которую можно использовать для установки роли и настройки синхронизации, продуктов, классификаций, языков и обновлений утверждений без использования административной консоли. Сведения о командлетах, используемых скриптом, см. в справочнике по WSUS PowerShell (модуль UpdateServices).

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

• Установите роль сервера WSUS и средства управления, а затем выполните необходимый шаг после установки, чтобы задать каталог содержимого.
• Настройте вышестоящий источник, из который сервер синхронизируется, например Microsoft Update или другой сервер WSUS.
• Укажите, должны ли пакеты обновлений храниться локально (и где именно) или оставаться на серверах Microsoft.
• Выберите продукты, классификации обновлений и языки, доступные на сервере.
• Задайте, будет ли сервер автоматически утверждать обновления для установки или оставлять их неутвержденными, если администратор не утверждает их.
• Задайте, будет ли сервер автоматически получать новые обновления из Microsoft и, если да, как часто.
• Задайте, используются ли пакеты обновления Express. Пакеты экспресс-обновлений снижают пропускную способность сервера к клиенту за счет использования ЦП и дисков клиента и пропускной способности сервера к серверу.
• Защитите от непреднамеренной перенастройки. Например, зафиксируйте, что скрипт уже был выполнен, и пропускайте последующие запуски, если не задано значение переопределения, чтобы избежать непреднамеренных изменений, которые могут нарушить работу сервера.

Скрипт можно запустить одним из двух способов:

• Запустите скрипт вручную из виртуальной машины WSUS. Запустите его из командной строки с повышенными привилегиями, чтобы установить и настроить WSUS.

• Вы можете использовать Расширение пользовательского сценария для Windows.

  Скопируйте скрипт и его файл конфигурации в свой контейнер хранилища, имеющий сетевую видимость по частной сети к виртуальной машине WSUS.

  Для правильной работы сценария в типичных конфигурациях виртуальной машины и виртуальной сети Azure Расширению пользовательского сценария требуются только два следующих параметра. Замените значения, отображаемые здесь, URL-адресами для расположений хранения и именами файлов.

  settings: {
    fileUris: [
      'https://yourstorageaccount.blob.core.windows.net/wsus/Configure-WSUSServer.ps1'
      'https://yourstorageaccount.blob.core.windows.net/container/WSUS-Config.json'
    ]
    commandToExecute: 'powershell.exe -ExecutionPolicy Unrestricted -File .\Configure-WSUSServer.ps1 -WSUSConfigJson .\WSUS-Config.json'
  }
  

Запустите скрипт начальную синхронизацию, которая делает обновления доступными для клиентских компьютеров, но не требует, чтобы он ждал завершения этой синхронизации. В зависимости от продуктов, классификаций и языков, которые вы выбрали, начальная синхронизация может занять несколько часов. Все последующие синхронизации будут выполняться быстрее.

Настройка WSUS вручную

На виртуальной машине WSUS следуйте инструкциям, приведенным в разделе "Установка роли сервера WSUS"

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

Настройка виртуальных сетей для обмена данными с WSUS

Затем настройте пиринг между виртуальными сетями Azure или пиринг между глобальными виртуальными сетями для взаимодействия с центром. Мы рекомендуем создать отдельный сервер WSUS в каждом регионе развертывания, чтобы добиться минимальной задержки.

В каждой виртуальной сети Azure, являющейся спицей, необходимо создать политику NSG с этими правилами:

• Входящее/исходящее правило NSG для разрешения трафика к виртуальной машине WSUS через порт 8530 (по умолчанию, если не настроен иначе).
• Правило NSG для входящего и исходящего трафика, запрещающее доступ в Интернет.

Теперь создайте пиринг между виртуальными сетями Azure от периферийной сети до сети концентратора.

Настройка клиентских виртуальных машин

Службы WSUS можно использовать для обновления любой виртуальной машины под управлением Windows. Сведения о настройке клиентов с помощью групповой политики см. в статье "Настройка клиентских компьютеров для получения обновлений с сервера WSUS".

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

Диспетчер обновлений Azure

С помощью Диспетчера обновлений Azure можно управлять обновлениями операционной системы и планировать их синхронизацию с WSUS. Состояние обновления для виртуальной машины (т. е. сведения о недостающих обновлениях) вычисляется на основе того источника, с которым синхронизируется эта виртуальная машина. Если виртуальная машина Windows настроена на отчётность в WSUS, результаты могут отличаться от отображаемых Центром обновления Microsoft, в зависимости от того, когда WSUS в последний раз синхронизировался с Центром обновления Microsoft. После настройки среды WSUS можно включить управление обновлениями. Для получения дополнительных сведений см. обзор Диспетчера обновлений Azure.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Основной автор

• Пол Рид | Старший менеджер по программе соответствия требованиям Azure

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

• Дополнительные сведения о планировании развертывания см. в статье Планирование развертывания WSUS.
• См. сведения об управлении WSUS, настройке графика синхронизации WSUS и других возможностях.

Связанный ресурс

• Запуск виртуальной машины Windows в Azure