Windows UpdateをNSGで許可する方法 – Cloud Steady | パーソルプロセス＆テクノロジー株式会社

この記事は更新から24ヶ月以上経過しているため、最新の情報を別途確認することを推奨いたします。

こんにちわ。

パーソルプロセス＆テクノロジー関西支社の古賀です。

今回はNSGでWindows Updateを制御する方法をご紹介致します。

前提条件

前提条件として

Azure上のVMから直接のインターネット向け通信を、Azureを起点とした送信方向でロックダウンする(送信方向Any Any Deny)
インターネット通信は許可されたProxyサーバ経由とする
Windows Server及びWindows ClientはWSUSサーバ経由、SCCM、3rd Party製のツールを使ってWindows Updateの制御を行うものとする

といった状況を想定しましょう。

要望

Azure上のVMのWindows Server及びWindows Client OSのWindows Updateを行いたい
かかる費用は最低限にしたい

前提条件１．と要望１．が競合しますね。

前提条件２．では大型Windows Update時に通信が輻輳し負荷がかかりますし、前提条件３．は場合によってはライセンス費用がかかり要望２．と競合します。

どのWindows Updateを適用するか、また適用タイミングは前提条件３．で制御したとしても、Windows Update通信そのものはAzure上のマシンはAzureから直接ダウンロードを行って欲しい、というのが情報システム部の本音だと思います。

私も元々ネットワークエンジニアなので、前提条件２．のProxy経由通信の際に起こる輻輳や前提条件３．でのライセンス費用、Windows UpdateのためにオンプレミスとAzure間にあるVPNや専用線で消費される帯域などを考えるとAzure上のマシンはAzureから直接Windows Updateのデータを取得して欲しいと考えます。

これをインターネットブレイクアウトと言いますが、従来のサービスではAzure Firewallを構築し、Application Firewallの機能でWindows Updateに必要なFQDNを許可する、と言った方法しかありませんでしたが、今回これがNSGのサービスタグで実現可能になりました。

Azure FirewallはAzureのマネージドFirewallならではの通信負荷や輻輳による自動スケール機能や、一般的なFirewall機能であるSource IP Address、Destination IP Address、Protocol、Source Port、Destination Portの5つの要素(5タプル)による通信制御や、前述のFQDNによる制御、Destination NATやSource NATなど多機能ですが、デプロイ直後から利用の有無にかかわらず毎月10万円近い利用料金が発生する事から、「費用対効果が出ない」といったお客様の声を多数お聞きしておりました。

対するNSGはどれだけ使っても2021年10月26日時点では無料です。

NSGフローログなどのNetwork Watcher機能を利用すると別途費用はかかりますが、基本的に無料です。

この無料のNSGでWindows Updateが制御できたら・・・と誰もが思ったことはないでしょうか？

特に昨今のコロナ禍でリモートワークが進む中、Azure Virtual DesktopやRDSサービスと組み合わせたVDI環境をAzure上に構築している場合など、Windows UpdateはAzureから直接インターネットブレイクアウトできた方が通信経路的にも良いのではないか、と個人的には考えております。

前置きが長くなりましたが、以降NSGでWindows Updateのみを制御する方法を順を追って説明します。

大まかな流れとして

2つのルールを設定する
2つのルールのうち1つはGUIで設定可能だが、もう1つは現時点(2021年10月26日)ではPowerShellでのみ設定可能
よってWindows Updateを許可するためにはGUIとPowerShellを組み合わせて設定する必要がある

となっています。

前提条件となるNSG設定

まずは前提条件１．を満たすNSGが以下のようになります。

図１．

優先順位やルール名は何でも良いのですが、ポイントは前提条件１．を満たす、「送信方向ロックダウン」のポリシーが存在する事です。

図１．であれば優先順位4096番、ルール名[DenyAllOutBound]が前提条件１．に当たります。

NSGは優先順位の若い番号から順に判定し通信の可否を判定しますので、この4096番より若い番号にWindows Updateを許可するルールを作成します。

Windows Updateを許可するには2つのルールが必要なので、今回は4096番よりも優先順位が高い201番と202番に作成します。

GUI設定

1つ目のルール、GUIで作成可能な[AzureFrontDoor.FirstParty]への通信許可ルールから作成します。

優先順位201番、ルール名は任意ですがここでは[AllowAzureFrontDoorFirstPartyHttpOutBound]とし、サービスを[HTTP]とします。

宛先の指定はService Tagから[AzureFrontDoor.FirstParty]を選択します。

Source IP AddressはWindows Updateを許可したいWindows VMのローカルIPアドレスを指定しますが、ここではAnyを意味する[*]とし、Source Portも同じくAnyを意味する[*]にしてください。

図２．

これで追加をクリックします。

図３．

このルールはWindows Update(HOTFIX本体)をダウンロードするための通信先を許可するルールになります。

PowerShell設定

2つ目のルール、GUIで作成できない、PowerShellでのみ設定可能な[AzureUpdateDelivery]を優先順位202番、ルール名は任意ですがここでは[AllowAzureUpdateDeliveryHttpsOutBound]とし、ProtocolをTCP、Destination Portを443番とします。

Source IP Addressは先のAzureFrontDoor.FirstPartyと同じくWindows Updateを許可したいWindows VMのローカルIPアドレスを指定しますが、ここではAnyを意味する[*]とし、Source Portも同じくAnyを意味する[*]にしてください。

設定のためのPowerShellはこちらになります。

$nsgName="[本設定を追加したいNSG名]"
$rgName="[本設定を追加したいNSGが存在するリソースグループ名]"
$nsg=Get-AzNetworkSecurityGroup -Name $nsgName -ResourceGroupName $rgName
$nsg | Add-AzNetworkSecurityRuleConfig -Name AllowAzureUpdateDeliveryHTTPSOutBound -Access Allow -Protocol TCP -Direction Outbound -Priority 202 -SourceAddressPrefix "*" -SourcePortRange "*" -DestinationAddressPrefix AzureUpdateDelivery -DestinationPortRange "443"
$nsg | Set-AzNetworkSecurityGroup

このPowerShellを実行する前に実際の環境に合わせて、[Connect-AzAccount]コマンドや[Select-AzSubscription]コマンドを実行してください。

エラー無くPowerShellが実行できれば以下の図のようになります。

図４．

これはWindows Updateに必要なメタデータを取得する際に必要な通信先を許可するルールになります。

これにてWindows UpdateのみをNSGにて許可することができました。

実際にWindows Updateを行ったところ、問題なく行えました。

追加検証

Windows VMをデプロイ直後はOSの言語は英語ですが、日本語化を行う際に送信方向をロックダウンしこの2つのルールを設定して検証したところ問題なく日本語化できました。

この検証結果からこの2つのルールは、Windows Updateだけでなく言語パックのダウンロードも許可していることがわかりますので、VMのデプロイ前にこのNSGを設定しておけばVMのローカライズ作業を安全に行えるという事になります。

その他注意事項

ネットワーク関連の設定で、NSGの他に強制トンネリングをはじめルートテーブルを使ってルーティングを変更している場合は別途これらの設定変更も必要になる場合がありますので、これらは各々の環境に合わせて設定してください。

これにてAzure Firewallを使わなくてもWindows UpdateがAzure上でインターネットブレイクアウトできる環境を構築することができました。