Azure Application Gateway（WAF）を古いSSLポリシーAppGwSslPolicy20150501のまま運用すると、TLS 1.0/1.1の廃止に伴い接続障害や監査指摘につながります。本記事では影響点を整理し、TLS 1.2以上へ安全に移行する具体的手順をまとめます。
結論：AppGwSslPolicy20150501（TLS 1.0 有効）を放置すると起きること
先に結論から言うと、インターネット公開のWebエンドポイントでTLS 1.0を許容し続ける運用は「リスクが高い」だけでなく、Azure側のサポート終了によって技術的に維持できなくなる局面があります。特にAzure Application Gatewayは、2025年8月31日を境にTLS 1.0/1.1のサポートが終了（データプレーン/コントロールプレーン段階的適用）し、古いポリシーの扱いも変わります。
- TLS 1.0/1.1で接続してくるクライアントは通信できなくなる（ハンドシェイク失敗）
- 古い事前定義ポリシー（20150501/20170401）は廃止され、紐付けできなくなる
- 移行せずに残すと、構成更新（PUT）時にGatewayがFailed状態になる可能性がある（運用上かなり痛い）
- PCI DSSや社内セキュリティ基準の監査で「弱い暗号/古いプロトコルを許容」として是正要求が出やすい
推奨は、TLS 1.2以上（可能ならTLS 1.3も）を許可するポリシーへ変更です。V2（Standard_v2/WAF_v2）なら、AppGwSslPolicy20220101またはAppGwSslPolicy20220101Sが現実的な第一候補になります。
前提整理：Application Gatewayの「TLSポリシー（SSLポリシー）」で何が決まるのか
Azure Application Gatewayは、HTTPSリスナーで受けた通信をゲートウェイで終端（復号）し、ルールに従ってバックエンドへ転送します。このときフロントエンド（クライアント→Application Gateway）のTLSハンドシェイクで使われるTLSバージョンと暗号スイートを、ゲートウェイ側でまとめて制御できるのが「TLSポリシー（SSLポリシー）」です。
設定方法は大きく2つあります。
- 事前定義（Predefined）：Microsoftが用意したプリセット（
AppGwSslPolicyYYYYMMDD）を選ぶ - カスタム（Custom / CustomV2）：最小TLSバージョンや暗号スイートを自分で定義する（V2ではTLS 1.3対応のCustomV2あり）
またV2 SKU（Standard_v2/WAF_v2）では、リスナーごとにポリシーを変えたいときにSSLプロファイル（SSL Profile）を使えます。ただし、2022系（20220101/20220101S）やCustomV2など「新しいポリシー」を使う場合、ゲートウェイ全体の安全性/性能の都合で旧来ポリシーと新ポリシーを同一ゲートウェイで混在できない制約がある点は要注意です。
AppGwSslPolicy20150501を使い続けた場合の影響（サポート/セキュリティ/互換性）
サポート面：2025年8月31日以降、TLS 1.0/1.1はApplication Gatewayで非サポート
Azure Application Gatewayは2025年8月31日にTLS 1.0/1.1をサポートしなくなります。これはApplication Gateway単体の話というより「Azure全体でTLS 1.2以上を必須化する流れ」に沿ったものです。
特に重要なのは次の2点です。
- V2 SKUでは、TLS 1.0/1.1を含む事前定義ポリシー（
20150501・20170401）は廃止され、以後は紐付けできない - 古い（廃止予定）ポリシーを選んだまま移行しないと、構成更新を行ったタイミングでGatewayがFailedになる可能性がある（「放置しても動いているからOK」が通りにくい）
つまり、「TLS 1.0を許可したままでも、当面は問題なく運用できる」ではなく、運用のどこかのタイミング（構成更新/拡張/証明書更新/ルール変更など）で一気に破綻するリスクが現実的に存在します。
セキュリティ/コンプライアンス面：TLS 1.0/1.1は“使わない”が基本線
TLS 1.0/1.1は、現在の推奨暗号（AEADなど）や現代的な運用要件に合わず、標準化コミュニティでも正式に「非推奨」とされています。IETFのRFC 8996ではTLS 1.0/1.1を正式にdeprecated（Historic扱い）とし、各種プロファイルで回避が義務化されている背景も説明されています。
監査・ガバナンス観点でも、TLS 1.0/1.1を許容していると次のような“言い訳しにくい指摘”につながりやすいです。
| 観点 | 要求/傾向 | TLS 1.0を許可した場合の典型的な扱い |
|---|---|---|
| PCI DSS | SSL/early TLSを強い暗号として扱わない（例外は限定的） | クレジットカード情報等を扱う経路で指摘・是正対象になりやすい |
| NIST（政府系ガイドライン） | TLS 1.2を必須、TLS 1.3の移行を要求/推奨 | TLS 1.0は原則許容しない方向（例外は相互運用性に限定） |
| 社内規程/第三者監査 | 「最新の安全な暗号スイートとプロトコル」を求める傾向 | “古いプロトコルが開いている”だけで是正要求が出ることがある |
上の表は要点を噛み砕いたものですが、実務的には「TLS 1.0を許可している」＝「いつでも弱点として指摘される状態」と捉えるのが安全です。特にWAFを置くほど外部公開の重要な入口なら、なおさら説明責任が重くなります。
互換性面：主要ブラウザーはTLS 1.0/1.1をすでに無効化済み
「TLS 1.0を許可していると“古いクライアントにも優しい”」と思われがちですが、逆に現代では主要ブラウザー側がTLS 1.0/1.1を無効化しています。結果として、TLS 1.0しか話せない（または企業プロキシ等でTLS 1.0しか通せない）環境は、すでにWeb利用そのものが成立しにくいのが実情です。
| クライアント側の動き | 起きること | 運用への影響 |
|---|---|---|
| Chrome / FirefoxなどでTLS 1.0/1.1の廃止・無効化 | TLS 1.0/1.1しか提示できないサーバーは警告/ブロック対象 | “古い端末だけ”ではなく、社内のセキュリティ設定次第で一般端末も影響 |
| Microsoft Edge/IE系でも既定無効化の流れ | 既定設定ではTLS 1.0/1.1が使われない | 「一部ユーザーだけ繋がらない」現象が発生しやすい |
| OS側でTLS 1.0/1.1を既定無効化する動き | アプリ/ミドルウェアがOSの設定に追従して通信できなくなる | “いつの間にか通信不可”を招きやすく、事前把握が重要 |
Webの入口（Application Gateway）だけTLS 1.0を許可していても、クライアント側がTLS 1.0を話さない/話せないなら互換性メリットは小さく、むしろ“例外的に古い暗号を開けていること”自体が負債になります。
症状で理解する：放置したときに現場で起きるエラーと影響
「結局、ユーザーにはどう見えるのか」を把握しておくと、問い合わせ対応や切り戻し判断が速くなります。
| 現象 | 原因の当たり | 確認ポイント | まずやること |
|---|---|---|---|
| ブラウザーで「安全な接続を確立できません」系のエラー | クライアントがTLS 1.2+必須、サーバー/経路が合わない | 該当端末/ネットワークだけ発生していないか | 影響範囲の切り分け（端末・NW・プロキシ） |
curlでハンドシェイク失敗（例：sslv3 alert handshake failure） | TLSバージョン不一致、または暗号スイート不一致 | Application GatewayのTLSポリシーとクライアント設定 | TLS 1.2/1.3での接続テストを先に実施 |
| 構成変更後にApplication GatewayがFailed状態 | 廃止ポリシーのままPUT更新が走った | 直前に何を更新したか（証明書/ルール/設定） | サポートされるTLSポリシーへ更新して再PUT |
curlの具体例（ハンドシェイク失敗メッセージ）はMicrosoftの案内にも掲載があります。運用上は「障害対応のために、TLS版数が原因かどうかを最短で切り分ける」目的で、curl/openssl等の“観測用コマンド”を手元に置いておくと役立ちます。
最優先の棚卸し：誰がTLS 1.0/1.1を使っているかを把握する
移行計画でいちばん揉めるのは「古いクライアントがいるかもしれない」という不確実性です。ここを曖昧にしたまま変更すると、障害時に“想定外でした”しか言えなくなります。
V2（Standard_v2 / WAF_v2）の場合：メトリックでTLSバージョンを可視化できる
V2 SKUなら、Application GatewayのメトリックとしてClient TLS protocolが提供されており、TLS 1.0/1.1を使っているクライアントがいるかを集計できます。Portal上での手順は次のとおりです。
- Azure Portalで対象のApplication Gatewayを開く
- 左メニューの「監視」→「メトリック」を開く
- メトリックに
Client TLS protocolを選ぶ - 「分割の適用（Apply splitting）」で「TLS protocol」別に分解して確認する
ここでTLS 1.0/1.1が0に近い（あるいは観測されない）ことを確認できれば、移行時の接続断リスクは大きく下がります。一方、TLS 1.0/1.1が少しでも出るなら、“どの利用者（どの拠点・どの端末・どのアプリ）か”まで落とし込み、先にクライアント側を更新する計画が必要です。
V1（Standard / WAF）の場合：メトリック/ログでTLS版数が取れない前提で動く
V1 SKUでは、メトリックやログからクライアントのTLSプロトコル情報を取得できない旨が明記されています。つまり、V1でTLS移行をやるなら「外形監視」「クライアント台帳」「ネットワーク機器ログ」など、別の観測手段が重要になります。
実務では、以下のように“複数の弱い証拠”を重ねて判断するのが現実的です。
- 社内の端末/ブラウザー/OSの標準構成（TLS 1.2以上が既定か）
- 業務アプリ（古いJava/古いSSLライブラリ/組込み機器）が残っていないか
- 外形監視でTLS 1.0/1.1を要求する接続テストを実行し、すでに失敗することを確認（＝依存が薄い可能性）
どのポリシーにすべきか：2022系ポリシーの選び方（20220101 vs 20220101S）
V2 SKUで「事前定義ポリシーを選ぶ」場合、現実的な移行先は次の2択になりやすいです。
| ポリシー | 最小TLS | TLS 1.3 | 特徴 | おすすめ |
|---|---|---|---|---|
AppGwSslPolicy20220101 | 1.2 | 対応（V2のみ） | 2022系。互換性寄りの暗号スイートが残る（例：一部CBC系） | まずは安全側に寄せつつ、古いクライアントが混在する可能性がある環境 |
AppGwSslPolicy20220101S | 1.2 | 対応（V2のみ） | 2022系の“より厳格”版。CBC系など一部を落として強い構成になりやすい | 外部公開のWeb、B2C/B2B、監査が厳しい環境（まずこちらを検討） |
上の判断軸のポイントは「TLS 1.2以上」という最低ラインを守りつつ、暗号スイートまで含めてどこまで厳格にするかです。多くの環境では、まず20220101Sを第一候補にし、もし互換性問題が出るなら20220101へ寄せる（またはCustomV2で調整）という順序が現実的です。
なお、V1 SKUは2022系ポリシーが利用できず、将来的には20170401Sのみをサポートする前提になります。V1を継続するなら「今後は選択肢が狭くなる」ことを織り込んでおくべきです。
具体的な対応手順：TLS 1.2以上へ切り替える（Portal / CLI / PowerShell）
手順A：Azure Portalで事前定義ポリシーに切り替える（基本）
PortalのUIは更新されることがありますが、基本の導線は「Application Gateway → SSL settings（SSL設定）」周りに集約されています。V2でリスナー別に変える場合も、まずSSLプロファイル作成から始めます。
- Azure Portalで対象のApplication Gatewayを開く
- 左メニューから「SSL settings（SSL設定）」を開く
- （ゲートウェイ全体のポリシー変更の場合）「SSL policy」で「Predefined」を選び、
AppGwSslPolicy20220101S（または20220101）を選択して保存 - （リスナー別に変える場合）「SSL profiles」を作成し、「Enable listener-specific SSL policy」を有効化してポリシーを選択 → そのSSLプロファイルを該当リスナーに割り当て
V2で2022系ポリシーを採用する場合、旧ポリシーと混在できない制約があるため、切替は“部分的”ではなくゲートウェイ全体に効く変更として扱うのが安全です。変更ウィンドウや関係者周知は、通常のWAFルール変更よりも一段丁寧に設計してください。
手順B：Azure CLIで変更する（自動化/手順書に強い）
CLIは「現状確認→変更→再確認」がやりやすく、運用手順書やIaC移行の第一歩に向いています。
1) 現在のSSLポリシーを確認
az network application-gateway ssl-policy show \
-g <リソースグループ名> \
--gateway-name <Application Gateway名>2) 事前定義ポリシーへ更新（推奨）
az network application-gateway ssl-policy set \
-g <リソースグループ名> \
--gateway-name <Application Gateway名> \
--policy-type Predefined \
-n AppGwSslPolicy20220101S3) 利用可能な事前定義ポリシーを確認（環境差分の吸収）
az network application-gateway ssl-policy predefined listCLIコマンドのパラメータは、--policy-typeと-n（--name）の組み合わせがポイントです。手元のスクリプトに“古い書き方（例：–policy-name）”が残っていると更新に失敗するため、運用チーム内でテンプレを統一しておくのがおすすめです。
手順C：Azure PowerShellで変更する（Windows運用・スクリプト資産がある場合）
PowerShellでは、利用可能なTLSオプションの列挙と、ポリシーの適用が比較的わかりやすい形で提供されています。
1) 利用可能なTLSオプション確認（棚卸しに便利）
$sslOptions = Get-AzApplicationGatewayAvailableSslOptions
$sslOptions.PredefinedPolicies
$sslOptions.AvailableProtocols2) 既存ゲートウェイに事前定義ポリシーを適用
$gw = Get-AzApplicationGateway -Name "<Application Gateway名>" -ResourceGroupName "<リソースグループ名>"
Set-AzApplicationGatewaySslPolicy ` -ApplicationGateway $gw`
-PolicyType Predefined `
-PolicyName "AppGwSslPolicy20220101S"
# 実際の更新反映
Set-AzApplicationGateway -ApplicationGateway $gwPowerShellは「ローカルで設定→最後にSet-AzApplicationGatewayで反映」という流れがあるため、手順書では“最後の反映コマンドを忘れると変わっていないように見える”落とし穴もセットで注意書きしておくと事故が減ります。
移行でつまずきやすいポイントと実務的な回避策
落とし穴1：古いクライアントが“少数だけ”残っていて炎上する
TLS移行は、全体の99%が問題なくても「残り1%が業務の要」に当たると大きな障害になります。対策はシンプルで、事前に可視化するしかありません。V2ならClient TLS protocolで把握し、V1なら周辺ログや端末棚卸しで“当たり”を潰します。
加えて、対外サービスなら「切替当日に問い合わせが増える」前提で、FAQテンプレを用意しておくと運用が安定します（例：推奨ブラウザー/OS、社内プロキシ利用時の連絡先など）。
落とし穴2：バックエンド側のTLS最小バージョンと噛み合わず、ヘルスプローブが落ちる
TLSポリシーの変更は主にフロントエンドの話ですが、Azureの方針変更により、バックエンド接続もTLS 1.2以上が前提になっていきます。Microsoftの案内では、退役後のバックエンド接続はV2でTLS 1.3優先（最低TLS 1.2）、V1でTLS 1.2となり、バックエンド側が対応していないと接続に支障が出る可能性があります。
エンドツーエンドTLS（再暗号化）構成の場合は、バックエンド（IIS/Nginx/アプリ基盤/PaaS）側も「TLS 1.2以上で受けられるか」「証明書チェーンが正しいか」「暗号スイートが過度に制限されていないか」を合わせて点検してください。
落とし穴3：“Defaultだから大丈夫”と思っていたら古い既定が残っていた
Application Gatewayの既定TLSポリシーは、作成時のAPIバージョンに依存します。API 2023-02-01未満で作成されたものは既定がAppGwSslPolicy20150501、2023-02-01以上では既定がAppGwSslPolicy20220101という整理です。
さらにややこしいのは、Azure側が「既定の自動更新」をしてくれるのは明示的にTLS設定がされていない場合に限る点です。つまり、過去に運用者がAppGwSslPolicy20150501を明示設定していた場合は、放置しても自動的に安全なポリシーへ変わりません。
運用に落とし込むためのチェックリスト（そのまま手順書にできる形）
| フェーズ | チェック項目 | 合格条件 |
|---|---|---|
| 現状把握 | SKU（V1/V2）・現在のTLSポリシー・リスナー構成を確認 | 「どのポリシーがどこに効いているか」を図で説明できる |
| 影響調査 | V2ならClient TLS protocolでTLS 1.0/1.1利用有無を確認 | TLS 1.0/1.1が0、または利用者が特定済み |
| 移行設計 | 移行先ポリシー（原則20220101S）と切替手順を確定 | 切替後に必要な受入テスト項目が揃っている |
| 事前検証 | ステージングで切替→主要クライアントで疎通確認 | ログイン/決済/ファイルDLなど重要導線が正常 |
| 本番切替 | 変更実施、監視（HTTP 4xx/5xx、WAF検知、ヘルス）強化 | エラー率がベースライン内、問い合わせが許容範囲 |
| 事後対応 | 古いクライアントの是正計画（残件）をクローズ | “例外運用”が残っていない |
よくある質問
TLS 1.0を「一応残しておく」という選択肢はありますか？
2025年8月31日以降、Azure Application GatewayはTLS 1.0/1.1をサポートしません。したがって「残したまま運用する」は、セキュリティ以前にサービス仕様として成立しなくなります。
Application GatewayでTLS 1.3を使えますか？
V2 SKU（Standard_v2/WAF_v2）では、2022系の事前定義ポリシーやCustomV2でTLS 1.3をサポートします。一方、V1 SKUでは2022系ポリシーは利用できません。
移行で最も安全な進め方は？
“安全”の定義を「通信断を最小化」と「監査/攻撃面を最小化」に分けると、両方を満たす現実解は次です。
- まずV2なら
Client TLS protocolでTLS 1.0/1.1利用状況を可視化 AppGwSslPolicy20220101Sでステージング検証→本番へ- もし問題が出たら、原因が「TLS版数」か「暗号スイート」かを切り分け、必要なら
20220101やCustomV2へ調整
まとめ：WAFを使うなら“入口のTLS”は今すぐ現代化すべき
AppGwSslPolicy20150501（TLS 1.0有効）のままにしておくと、セキュリティ監査・互換性低下だけでなく、AzureのTLS 1.0/1.1サポート終了により運用継続が難しくなります。
最短で効果が高い対応は、V2ならAppGwSslPolicy20220101S（または20220101）へ移行し、最小TLSを1.2以上に固定することです。あわせて、メトリック/ログで利用状況を可視化し、バックエンドもTLS 1.2以上を前提に整備しておくと、将来の変更にも強い構成になります。
コメント