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

プロトコルの脆弱（ぜいじゃく）性の問題から、レガシーなSSL 3.0やTLS 1.0／1.1を無効化し、より安全なTLS 1.2以降を使用することが推奨されています。常時SSL化され、TLS 1.2以降での接続を要求するWebサイトやサービスも増えてきました。SSL／TLSはMicrosoft Azureのサービスへの接続やデータ転送の保護に重要なプロトコルですが、業界の流れと同様に、各サービスでレガシーなプロトコルの廃止が進んでいます。

[山市良，テクニカルライター]

Microsoft Azure最新機能フォローアップ

Cloud App Securityは2019年9月にTLS 1.0／1.1のサポートを終了

　2019年7月末、Microsoft Cloud App Securityチームが公式ブログにおいて、「Microsoft Cloud App Security」におけるTLS 1.0／1.1のサポートを2019年9月8日（米国時間）に終了することを発表しました。

• End of support for TLS 1.0 and 1.1 in Microsoft Cloud App Security［英語］（Enterprise Mobility＋Security Blog）

　Cloud App Securityは、企業や組織でエンドユーザーが利用しているクラウドアプリの検出とそのリスク評価（シャドーITの検出）、アプリの条件付きアクセス制御、リアルタイム監視、異常なアクティビティーの検出などを行えるクラウドベースのサービスです。

　Cloud App SecurityのTLS 1.0／1.1サポート終了とは、TLS 1.2以降を利用できない場合にエージェントやログコレクターがサービスに接続できなくなる、サービスのAPIを利用するカスタムアプリケーションやコードがAPIのエンドポイントに接続できなくなるという影響があります。また、条件付きアクセス制御の対象となるクラウドアプリもTLS 1.2以降に対応していることが必須になります。

　Windows OSや.NET FrameworkアプリのTLS 1.2対応状況と、有効化の方法については、以下のJapan IE Support Team Blogの投稿や公式ドキュメント（Microsoft Docs）にまとめられているので参考にしてください。

• .NET FrameworkでTLS 1.1および1.2を有効化する方法 -まとめ-（Japan IE Support Team Blog）
• トランスポート層セキュリティ（TLS）レジストリ設定（Microsoft Docs）

　TLS 1.1の有効化についても説明されていますが、OSや.NET Frameworkのさまざまなバージョンの組み合わせにおけるTLS 1.2の有効化の部分に注目してください。特に、レガシーなWindows 7、Windows Server 2008 R2、Windows Server 2008 Service Pack 2（SP2）は、OSとしてはTLS 1.2に対応していますが、レジストリを作成して有効化しないとアプリケーションでTLS 1.2を利用できない場合があるので注意が必要です。

Update Managementは既にTLS 1.2対応が必須要件に

　Cloud App Securityのように、事前にアナウンスがある場合もありますが、Microsoft Azureの他のサービスでも今後、TLS 1.2以降が必須化される流れにあることは間違いありません。既にTLS 1.2以降の使用の強制が開始されているものもあります。

　Azure仮想マシンとオンプレミスのWindows／Linuxの更新管理が可能な「Azure Update Management」（更新プログラムの管理）では、筆者が確認した限り、2019年7月末時点でエージェントからサービスエンドポイントへの接続にTLS 1.2が要求されるようになったようです（正式なアナウンスはありません）。

　Windows Server 2008 R2およびSQL Server 2008 R2を実行するAzure仮想マシンにおいて、7月末にUpdate Managementのエージェントが「切断」された状態になっているのを見て気が付きました（画面1）。7月上旬のセキュリティ更新の際は確かに正常な状態でした。

画面1　2019年7月末時点でUpdate Managementのエージェントが「切断」状態に

　「トラブルシューティング」リンクから「エージェントの更新のトラブルシューティング」のチェックを実行すると、前提条件の「TLS 1.2」が失敗し、エンドポイントに接続できない状態にあることが分かります（画面2）。

画面2　「エージェントの更新のトラブルシューティング」を実行すると、TLS 1.2の前提条件のチェックとエンドポイントとの接続性の確認に失敗

　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スクリプトセンター）

筆者紹介

山市 良（やまいち りょう）

岩手県花巻市在住。Microsoft MVP：Cloud and Datacenter Management（2019-2020）SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『ITプロフェッショナル向けWindowsトラブル解決 コマンド＆テクニック集』（日経BP社）。