スケーラブルなWindows仮想マシンのパッチ管理

この記事では、ワークロード内の仮想マシン (VM) Windowsオペレーティング システムの更新プログラムを運用化するための推奨される方法について説明します。 推奨されるプロセスでは、ワークロード内のWindows VM に対して、一貫性のあるスケーラブルで管理されたパッチ管理ソリューションが提供されます。 運用環境に昇格する前に、運用前環境で更新プログラムを検証できます。

効果的なパッチ管理は、更新プログラムのインストール以外にも拡張されます。 パッチ管理戦略では、VM がパッチ管理ソリューションにオンボードされ、ワークロード標準に従って構成され、コンプライアンスを継続的に監視されるように、一貫したガバナンスも必要です。

Azure Update Manager

Azure Windows VM で OS 更新プログラムWindows管理するための推奨される方法は、Update Manager を使用することです。 このサービスは、一元的なスケジュール設定とコンプライアンス レポートを提供し、VM に対して段階的な OS 更新プログラムのデプロイを実行する機能を提供します。 Update Manager は、ワークロード内の各 VM にインストールされているサイドカー Azure VM 拡張機能を介して動作します。 Update Manager は、パッチ自体をホストまたは配布しません。 各 VM 上のネイティブ Windows Update エージェント (WUA) を制御してアクティブ化します。

Update Manager を使用すると、ワークロード チームは環境内の VM の修正プログラムの状態を一元的に確認できます。 パッチ適用のターゲットと周期を設定し、オンデマンドパッチロールアウトを有効にすることができます。

Azure リソース組織

Update Manager はAzureリソースではありません。 それをワークロードが属するサブスクリプションにデプロイすることはありません。 Azure ポータルで使用でき、ポータルでのエクスペリエンスは RBAC ベースであり、サブスクリプションに依存しません。 メンテナンス構成、適用される OS パッチ、修正プログラムの適用日時、ワークロードの VM への構成の関連付けをAzureリソースとして保持します。

各メンテナンス構成には 1 つのスケジュールを設定でき、関連付けを介して任意の数のリソースを対象にすることができます。 メンテナンス構成はリージョン リソースです。 1 つのメンテナンス構成と一連の関連付けを使用して、同じリージョンとサブスクリプション内の VM のみを含めます。 この方法を使用すると、すべての環境に個別のメンテナンス構成リソースがあり、ワークロードがマルチリージョンであるか、ワークロードの各部分に異なる更新スケジュールがある場合は、環境ごとに複数のリソースが存在する可能性があります。

その環境のワークロードの IaC の一部として、メンテナンス構成リソースを維持します。 この方法を使用すると、変更制御プロセスと安全なデプロイプラクティスを実行でき、ディザスター リカバリー オプションを利用できます。

VM の要件

Windows VM では、サポートされているカスタムイメージまたはAzure Marketplaceイメージを使用する必要があります。 ソースに関係なく、更新プログラムをサポートするように OS を構成する必要があります。 推奨される方法は、必要な OS 設定を構成する VM の IaC を使用することです。 具体的には、VM に少なくとも次の設定があることを確認します。

windowsConfiguration: {
  provisionVMAgent: true
  enableAutomaticUpdates: true

  patchSettings: {
    patchMode: 'AutomaticByPlatform'  // Turns off automatic updates in the OS; now platform triggers updates
    assessmentMode: 'AutomaticByPlatform' // Scans for missing updates every 24 hours

    automaticByPlatformSettings: {
      bypassPlatformSafetyChecksOnUserSchedule: true  // Allows Azure Update Management to honor defined schedules
      rebootSetting: 'IfRequired'  // Or 'Never' if required in your workload
    }
  }
}

Windows ゲスト エージェントは、Microsoft.CPlat.Core.WindowsPatchExtensionと呼ばれるサイドカー拡張機能をインストールします。 この特権拡張機能は、VM 上で実行され、スケジュールと更新の構成を取得します。 また、ネイティブ Windows OS 更新 API を呼び出して更新プログラムを実行します。 この拡張機能は、VM IaC の一部として定義しません。 Update Manager によって自動的にインストールされ、ライフサイクルが維持されます。

WindowsPatchExtension拡張機能は、コンピューターの更新ソース設定をオーバーライドしません。 VM の更新ソースを構成する必要があります。

• Windows Update リポジトリ (Windows OS と特定のドライバー)
• Microsoft更新リポジトリ (Windows OS、特定のドライバー、および特定のMicrosoft製品)
• 組織でワークロードを使用する必要がある場合は、Windows Server Update Services (WSUS) サーバー (現在は非推奨)

サポートされているソースの詳細については、「サポートされている更新プログラムのソース、種類、Microsoftアプリケーションの更新プログラム、およびMicrosoft以外の更新プログラム」を参照してください。

コンプライアンス レポートに現在のデータが反映されるように、自動評価を有効にします。 この機能は、パッチ ベースラインに関する各 VM の状態を示し、次回のスケジュールされた実行前に新しく公開された露出を強調表示します。 評価では、実行中の VM のみが対象となります。 停止または割り当て解除された VM はスキャンされません。

ポリシーの適用

また、ワークロードでは、Azure Policyを使用して、VM が Update Manager 用に適切に構成されたままであることを強制する必要があります。 組み込みのAzure Update Manager ポリシーを適用して、構成のずれを防ぎます。 組み込みのポリシーは、DINE (deployIfNotExists) をサポートし、準拠していない VM を自動的に修復するように適用を変更します。

パッチ管理に対するポリシー主導のアプローチについては、「ポリシーを使用して、Azure VM で定期的な評価とスケジュールされた修正プログラムの適用を有効にする」を参照してください。 ワークロードで VM のデプロイと構成に IaC を使用していない場合は、このアプローチを使用します。

ネットワークの要件

直接送信インターネット アクセスを使用する Azure VM の場合、ゲスト OS の更新ソース、DNS、プロキシ、TLS 検査、およびローカル ポリシー設定でWindows Update/Microsoft更新トラフィックが許可されている場合、通常、Windows Updateは追加のネットワーク許可リストなしで動作します。 ただし、ほとんどのワークロードは、送信アクセスが制限されたロックダウンされた仮想ネットワークで動作します。 このような場合は、送信するすべてのネットワーク セキュリティ グループとファイアウォール全体で、Microsoft更新エンドポイントへのトラフィックを許可する必要があります。

ネットワーク セキュリティ グループ

Windows Updateを含む既定の更新ソースは DNS ベースであり、安定した静的 IP リストは発行されません。 そのため、インターネットでホストされる更新ソースの場合、VM の NIC またはそのサブネットに接続されているネットワーク セキュリティ グループは、TCP:443 および TCP:80 へのインターネット エグレス トラフィックをサポートする必要があります。 エグレス ファイアウォール内からのアクセスをさらに制限する必要があります。 更新プログラムが静的 IP アドレス範囲 (オンプレミスのソースなど) から取得される場合は、ネットワーク セキュリティ グループでその送信先を明示的に定義する必要があります。

エグレス ファイアウォール

エグレス ファイアウォールでは、更新ソースで使用される FQDN へのトラフィックを許可する必要があります。 Azure FirewallとMicrosoft提供の更新ソースを使用する場合は、WindowsUpdate FQDN タグを使用して、Windows Update エンドポイントへの送信アクセスを許可します。 ネットワーク パス内の他のエグレス ファイアウォールの構成については、「 ファイアウォールの構成」を参照してください。 このトラフィックは、ワークロード内の関連のないサブネットからではなく、Windows VM から送信された場合にのみ許可する必要があります。

VM をメンテナンス構成に関連付ける

メンテナンス構成と VM の間に静的な関連付けを作成できますが、代わりに動的スコープを使用します。 動的スコープは、リソース グループ、場所、タグなどの属性に基づいて、メンテナンス構成に関連付けられている VM を決定します。 動的スコープではなく、メンテナンス構成によって、インストールされる更新プログラムとインストールされるタイミングが定義されます。 動的スコープでは、VM ごとの構成関連付けリソースを管理することなく、条件に一致する新しい VM をオンボードできます。

動的スコープ規則を使用する場合は、次の推奨事項に従います。

• ワークロードの一部として IaC の動的スコープ規則を管理します。
• 環境間の依存関係を回避するには、環境の VM のみを含め、必要に応じて環境間で構成と動的スコープルールを複製します。
• 関連付けの主要なメカニズムとしてタグを使用し、Azure Policyを使用して使用を強制します。

段階的なパッチ適用スケジュールを設計する

ワークロードの一般的な修正プログラム適用スケジュールでは、段階的なデプロイ スケジュールが使用されます。 毎月のMicrosoft更新プログラムのリリース後、最初に開発 VM とテスト VM に更新プログラムを適用します。 これらの更新プログラムを検証したら、同じ分類の更新プログラムを運用前に昇格し、別のメンテナンス期間で運用します。

メンテナンス構成を作成して、繰り返し、メンテナンス期間、更新プログラムの分類、再起動の動作を定義します。 次に、ワークロード内の VM を対象とする動的スコープ関連付けを作成して、定期的な修正プログラムの適用スケジュールを実行します。

火曜日に調整された パッチスケジュールでは、通常、運用環境のデプロイ前に検証に数日を割り当てられます。 毎月Microsoftセキュリティ更新プログラムは通常、毎月第 2 火曜日にリリースされるため、推奨されるアプローチは次のようになります。 この例では、ターゲット VM はタグを使用する動的スコープルールを使用して管理されます。

更新の同時実行に対処する

メンテナンス構成では、関連付けられているすべての VM の更新が同時に開始されます。 Azureは、共通の可用性セット内の VM に対してのみ、更新ドメインごとに再起動をシリアル化します。 この例の バックエンド ウェーブと フロントエンド ウェーブは、冗長な容量ではなく階層ごとにスケジュールを分離するため、レベル内のすべてのインスタンスが一緒に再起動され、そのレベルが必要な容量を下回る可能性があります。

各運用レベル内で、可用性ゾーン、更新ドメイン、またはワークロード定義インスタンス グループに合わせた容量保持ウェーブにパッチ適用を分割します。 ウェーブごとに個別のタグ値とメンテナンス構成を使用します。

ロールアウトの整合性を検討する

Update Manager は、実行ごとに新しい評価を実行します。 したがって、分類ベースのスケジュールでは、後のウェーブで別のナレッジ ベース (KB) 記事に関連付けられている更新プログラム パッケージを選択できます。 各ウェーブで正確に検証された更新セットをインストール する必要がある 場合は、分類のみに依存するのではなく、明示的な KB 包含を構成します。

この構成を自動化するには、Update Manager REST API を使用して、最初のウェーブからの評価結果を照会してから、後続のウェーブのメンテナンス構成を更新します。

ウェーブの完全な一貫性を実現するために行うトレードオフは、オーケストレーションの複雑さです。 ワークロードで、後のウェーブが最初のウェーブとは異なる更新パッケージをインストールするリスクを許容できる場合は、分類ベースのスケジュールを使用します。

ホットパッチを使用して再起動を減らす

多くの場合、再起動はパッチ適用スケジュールの最も破壊的な部分です。 前の表のメンテナンス期間のサイズと再起動の動作を決定します。 サポートされているイメージでは、ホットパッチを適用すると、実行中のプロセスのメモリ内コードに修正プログラムを適用することでセキュリティ更新プログラムWindowsインストールされるため、ほとんどの月の更新プログラムは再起動なしで適用されます。 ホットパッチはWindows Updateの拡張機能であるため、Update Manager は、他の VM に使用するのと同じメンテナンス構成と動的スコープを使用してホットパッチをインストールします。

ワークロードが再起動の影響を受けやすい場合は、ホットパッチをサポートする OS SKU と設計を採用します。

• ホットパッチは、特定のWindowsイメージでのみ使用できます。 任意のカスタム イメージでホットパッチを有効にすることはできません。
• ホットパッチが適用されるのは、Windowsセキュリティ更新プログラムのみです。 セキュリティ以外の更新プログラム、.NET更新プログラム、およびドライバーまたはファームウェアの更新プログラムは、リリースされた月に再起動する必要があります。 四半期ごとのホットパッチ ベースラインと、Microsoft がゼロデイ修正のためにリリースする計画外のベースラインでは、いずれも再起動が必要です。 再起動を吸収できるメンテナンス期間を維持します。

"before" と "after" の懸念事項を処理する

Update Manager はオペレーティング システムの更新プログラムを評価してインストールしますが、パッチ適用プロセスが成功すると、メンテナンス期間の前後のアクティビティが含まれる場合があり、必要な再起動やアプリケーション固有の問題を適切に処理できます。 Update Manager には、ワークロードの自動化で使用できる 事前イベントと事後イベント が用意されています。 Azure関数などのイベント ハンドラーをワークロードのアーキテクチャに追加します。 イベント ハンドラーは、スケジュールされた修正プログラムの実行の前後にAzure Event Grid通知に応答します。

Update Manager のパッチ適用前アクティビティを使用して、次のようなタスクを実行します。

• 停止または割り当て解除された VM を開始します。 停止または割り当て解除された VM に修正プログラムを適用することはできないため、スキップされます。
• バックアップ復旧ポイントが使用可能であることを確認します。
• VM とアプリケーションの正常性を検証します。
• メンテナンス期間中に誤検知を防ぐために、監視アラートを一時的に抑制します。

更新プログラムがインストールされたら、修正プログラムの適用後のアクティビティを使用して、次のようなタスクを実行します。

• 監視を復元。
• アプリケーションとサービスの正常性チェックを実行します。
• Microsoft Teams チャネルに通知を投稿します。

Event Grid とイベント ハンドラーコンピューティングをワークロード リソースとして扱います。 IaC を使用してデプロイし、環境間で分離します。

オンデマンド更新の準備

Update Manager では、スケジュールされたメンテナンス期間外のオンデマンド修正プログラムのインストールがサポートされます。 この機能は、緊急パッチまたは重大なサイクル外修正プログラムを適用する場合や、より広範なスケジュールされたロールアウトの前に単一の VM でパッチの動作を検証する場合に役立ちます。 オンデマンド更新は、Azure ポータルまたは Update Manager REST API から 1 つ以上の VM に対して同時に直接トリガーできます。 ワークロード チームは、帯域外更新を実行するタイミングと、そのプロセスがワークロード全体でどのように調整されるかに関するガイドラインを確立する必要があります。

更新プログラムをロールバックする

Update Manager では、OS パッチのロールバックは提供されません。 パッチを適用した後、Update Manager を使用して直接アンインストールする組み込みメカニズムはありません。

ワークロードで "前回の正常な状態" をサポートする必要がある場合は、メンテナンスを実行する前にスナップショットまたは復旧ポイントを作成します。 各修正プログラム適用ウィンドウの前に実行するスナップショットの作成を自動化して、パッチが適用される前に復旧ポイントが常に存在することを確認します。 または、修正プログラムなしで VM を再デプロイし、問題のある KB パッチをデプロイから除外して、更新プログラムを再適用します。

コンプライアンス レポート

Update Manager は、評価と修正プログラムのインストール結果の両方をAzure Resource Graphにプッシュし、保留中の更新プログラムを 7 日間保存し、インストール結果を 30 日間保存します。 Update Manager には、環境全体の更新状態を可視化する組み込みのコンプライアンス レポートと管理ビューが含まれています。 これらのダッシュボードを使用すると、管理者はパッチコンプライアンスを監視し、注意が必要なマシンを特定し、中央の場所から更新プログラムの展開の進行状況を追跡できます。

事前定義されたワークブックでは、ワークロード全体にわたる重要な情報を確認できます。

• マシンの状態と構成の全体的な概要
• 重大度と分類別の保留中の更新プログラムの内訳
• スケジュール、メンテナンス構成、および各スケジュールにアタッチされているマシンの概要
• 成功率やエラーなど、過去のインストール実行の履歴ビュー

多くの組織では、アプリケーション チームがコンプライアンス レポートを提供する必要があります。 Update Manager ポータルのエクスペリエンスとブックはサブスクリプションの境界を越えて動作でき、ワークロードでカスタムパッチステータスレポートを提供する必要がないため、組織では既にその追跡に Update Manager を使用するのが理想的です。

定義済みのビュー以外のカスタム レポートが必要な場合は、ブックをカスタマイズできます。 ワークロードの IaC ファイルにカスタマイズしたワークブックを含めることで、変更管理プロセスを適用し、障害復旧オプションを提供できます。 代わりに、 Resource Graph クエリを使用して必要なコンプライアンス レポート データを提供することもできます。

ワークロードで、Resource Graph が保持するよりも長い期間、パッチ履歴を保持する必要がある場合は、制御するストアにデータをエクスポートするプロセスを構築します。

代替アプローチ

スケジュールされた段階的な Update Manager アプローチをワークロードに採用しない場合は、カスタム ソリューションを設計する前に 、VM ゲストの自動修正プログラムを 評価します。 このオプションを使用すると、Azure修正プログラムの適用が調整されます。 ただし、この方法を使用する場合は、次の利点を放棄します。

• 段階的なロールアウト。 更新プログラムは開発、テスト、本番の各段階へと順次進められないため、検証ゲートがなくなります。
• メンテナンスウィンドウの制御。 Azureは、各 VM のタイム ゾーンでピーク時以外の時間帯にパッチ適用を実行するタイミングを決定します。
• 分類コントロールを更新します。 重大更新プログラムとセキュリティ更新プログラムのみが適用されます。 その他の更新プログラムは自動的にインストールされません。

貢献者達

Microsoft では、この記事を保持しています。 この記事を書いたのは、以下の寄稿者です。

主要著者:

• テドマン・リー |シニア ソリューション エンジニア

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ

• Update Manager のしくみについて説明します。
• メンテナンス構成サービスの制限: スケジュール、リソースの関連付け、動的スコープの制限を確認します。
• 事前イベントと事後イベントを使用して実行順序をスケジュールする: 各メンテナンス期間に十分なリード タイムを確保できるように、事前イベントと事後イベントのタイミング ウィンドウとキャンセル動作について理解します。