Azureの各種サービスでTLS 1.2対応が必須要件に：Microsoft Azure最新機能フォローアップ（87）

　Update Managementサービスが依存する「Log Analytics」のドキュメントの「TLS 1.2を使用して安全にデータを送信する」には、次のように記載されています。

• Log Analyticsデータのセキュリティ（Microsoft Azure）

Log Analytics へのデータの転送時のセキュリティを保証するため、少なくとも Transport Layer Security（TLS）1.2を使用するようにエージェントを構成することを強くお勧めします。以前のバージョンの TLS／SSL（Secure Sockets Layer）は脆弱であることが確認されています。現在、これらは下位互換性を維持するために使用可能ですが、推奨されていません。さらに、業界はこれらの以前のプロトコルのサポートを中止する方向へ急速に動いています。（中略）……Azureがレガシーサポートを廃止した場合、エージェント／クライアントがTLS 1.2以上で通信できないとLog Analyticsにデータを送信できなくなります

　「エージェントの更新のトラブルシューティング」の結果は、ここに書かれている「レガシーサポートを廃止」が実施されたことを示しているように見えます。

　また、「プラットフォーム固有のガイダンス」として、Windows 7 SP1とWindows Server 2008 R2 SP1ではTLS 1.2がサポートされているが、既定では有効になっていないことが説明されています。有効にする方法としては、「トランスポート層セキュリティ（TLS）レジストリ設定」への参照リンクがあります。

　しかし、リンク先にあるのは関連する多数のレジストリ設定であり、どの設定を行えばよいのか明確になっていません。前出の「.NET FrameworkでTLS 1.1および1.2を有効化する方法 -まとめ-」には必要十分な設定が含まれますが、問題となっているWindows Server 2008 R2上のエージェントにとって必要な設定がどれなのかを判断するのは難しいかもしれません。

　Update Managementの現在の状況は一時的なことかもしれませんが、将来的にTLS 1.1以前が完全に廃止されることは間違いありません。筆者が確認できていないだけで、他のサービスでも既に影響が出ている可能性もあります。

　TLS 1.2対応のために手動で設定が必要なWindows 7とWindows Server 2008／2008 R2をAzure仮想マシンやその他のAzureサービスのクライアントとして利用している場合は、TLS 1.2への対応を済ませておくことをお勧めします。

　Azureに限らず、レガシーな環境におけるTLS 1.2対応の方法は、OSやアプリケーションによってさまざまです。Update Management（Log Analytics）の場合は、「Azure Monitor」と共通のエージェント（Microsoft Monitoring Agent、MMA）を使用しています。

　現在、MMAを使用する全てのサービスがTLS 1.2を必須要件にしているわけではありませんが、必要な設定は以下のドキュメントの「TLS 1.2を使用するようエージェントを構成する」に見つかりました。

• WindowsコンピューターをAzure Monitorに接続する（Microsoft Docs）

　Windows Server 2008 R2上のエージェントをTLS 1.2に対応させるには、4つのレジストリ設定を作成して、サーバを再起動します。コマンドプロンプトから実施するには、次の5行のコマンドラインを実行してください。

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v "DisabledByDefault" /t REG_DWORD /d 0 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" /v "Enabled" /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" /v "SchUseStrongCrypto" /t REG_DWORD /d 1 /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" /v "SchUseStrongCrypto" /t REG_DWORD /d 1 /f
shutdown /r /t 0

　このコマンドラインは、OSとしてTLS 1.2クライアントを有効化し、.NET Framework 4.5.2向けにTLS 1.2の使用を有効化しています。このサーバには.NET Framework 4.7.2がインストール済みですが、Update Managementの前提条件が.NET Framework 4.5以降であるため、.NET Framework 4.5.2向けの設定が必要なようです（画面3、画面4）。

画面3　Update Managementのエージェントのために、Windows Server 2008 R2 SP1のOS設定と.NET Framework 4.5.2向け設定でTLS 1.2を有効化する

画面4　サーバの再起動後、「更新プログラムの管理」を開くと、エージェントが「準備完了」の正常な状態に復帰した

　本連載第85回でも取り上げましたが、製品サポート終了後も最大3年間、更新サポートを提供する「拡張セキュリティ更新プログラム（Extended Security Updates：ESU）」を利用するために、Windows Server 2008／2008 R2やSQL Server 2008／2008 R2サーバをAzure IaaSに移行することを検討している企業は多いと思います。既に移行したところもあるでしょう。

　今回のUpdate Managementのケースのように、レガシープロトコルの廃止がサービスの利用に影響することがあることには注意が必要です。

• SQL Server 2008／2008 R2のサポートが終了、オンプレミス向けESUの提供方法が明らかに（本連載 第85回）

【参考】.NET Frameworkのバージョンを確認するスクリプト

　Microsoftの「TechNetスクリプトセンター」に、筆者が『ITプロフェッショナル向けWindowsトラブル解決コマンド＆テクニック集』（日経BP社刊、2018年10月）向けに作成したWindows PowerShellスクリプト「get-dotnetver.ps1」の最新版を公開しています。

　.NET Frameworkの正確なバージョン情報を調べるには、レジストリを参照する必要がありますが、このスクリプトを実行することで、.NET Framework 2.0から最新の.NET Framework 4.8まで（.NET Coreは想定していません）を識別できます（画面3のPowerShellウィンドウを参照）。

• Determine which .NET Framework versions are installed by PowerShell（TechNetスクリプトセンター）