Azure Application Gateway（WAF）をV1からV2へ移行するタイミングで、TLS 1.0/1.1廃止（8/31のTLS 1.2強制）に備えると、通信断や切替手順の迷いが起きがちです。本記事では期限後の挙動、後追い対応の可否、移行時の落とし穴、実務で使える確認手順をまとめます。
前提：WAF移行とTLS強制は「別レイヤー」の話
Azure Application Gateway の WAF は、HTTP/HTTPS リクエストを受け取った後にルール評価（OWASP ルールやカスタムルール）を行ってブロック/許可を判断します。一方で、TLS（SSL）ハンドシェイクはリクエストより前に成立している必要があります。つまり、Microsoft 側で「TLS 1.2 以上を必須」にすると、TLS 1.0/1.1 のクライアントは WAF 以前の段階で接続できなくなるため、WAF のバージョン（V1/V2）やルール設定だけで救済することはできません。
この2つを同時に進めるときに重要なのは、影響が出る箇所を「クライアント→WAF（フロント）」と「WAF→バックエンド（アプリ）」に分けて設計・検証することです。特に「TLS 1.2 対応済みだと思っていたが、暗号スイートや証明書チェーンで失敗していた」というケースが移行直前に発覚しやすいので、先に可視化しておくと事故が減ります。
8/31以降にTLS 1.0/1.1接続が残っていたら何が起きる？
期限（8/31）以降、対象のAzureプラットフォーム側で TLS 1.2 以上が強制される場合、TLS 1.0/1.1 の通信はハンドシェイク段階で拒否されます。アプリケーションまで到達しないため、アプリ側ログに何も残らないこともあります（クライアント側でエラーとして見える）。
| 残っていた接続 | 起きること（典型） | 現場での見え方 | まず確認する場所 |
|---|---|---|---|
| TLS 1.0 / 1.1 のブラウザ | 接続不可（ハンドシェイク失敗） | ブラウザで「安全な接続ができない」「証明書の問題」等の表示 | 端末のOS/ブラウザバージョン、社内プロキシ/SSLインスペクション |
| 古いAPIクライアント（古いJava/.NET/ライブラリ） | API呼び出しが失敗 | handshake_failure、protocol_version、共通暗号が無い等の例外 | クライアントの実行環境、利用TLS設定、ライブラリ/ランタイム |
| 古い機器（IoT/複合機/監視ツール） | 通信断（再接続できない） | 監視が赤くなるが原因が追いにくい | 機器のファーム、HTTPS実装、メーカーのTLS対応表 |
| 社内の中継（プロキシ、ゲートウェイ） | 中継が古いTLSで終端→外向きが失敗 | 「クライアントは新しいのに失敗する」 | 中継機器のTLS最小バージョン、暗号スイート設定 |
ポイントは、「自分がAzure側でTLS 1.0/1.1を許可する設定のままでも止まる」ことです。プラットフォーム側が最低バージョンを引き上げると、設定上は許可に見えても、実効としては通らなくなります。逆に言えば、期限後に突然発覚する問題の多くは「Azure設定」ではなく「クライアント/中継/バックエンドの古さ」に起因します。
期限を過ぎても対応できる？できない？（WAF V2移行・SSLポリシー）
結論として、期限後でも WAF V1→V2 移行や SSL ポリシー（TLS 1.2+）の設定変更は実施可能です。ただし、期限後は TLS 1.0/1.1 が物理的に通らないため、移行作業そのものができるかどうかではなく、「残っている古いクライアントがその瞬間から使えなくなる」ことがリスクになります。
| 作業 | 期限後に実施できるか | 期限後に起きうる影響 | 実務の着眼点 |
|---|---|---|---|
| WAF（Application Gateway）V1→V2 への移行 | 可能（ただし新規V2作成→切替が基本） | TLS 1.0/1.1 のクライアントは既に接続不可。切替で顕在化しやすいのは別要因（証明書、SNI、ルール差分） | 並行稼働で検証→段階的切替。切戻し経路も確保 |
| フロントのSSLポリシーで TLS 1.2+ を明示 | 可能 | 期限後は実質的に同等になることが多いが、暗号スイートを絞るとTLS 1.2でも失敗するクライアントが出る | 互換性優先なら「TLS 1.2+かつ幅広い暗号」→段階的に強化 |
| バックエンドHTTPS（エンドツーエンドTLS）の見直し | 可能 | バックエンドが古いTLS/証明書だと 502 等で障害化 | バックエンド最小TLS、証明書チェーン、SNI、ヘルスプローブを重点確認 |
期限後にTLS 1.2を有効化したら「追加の復旧作業」は必要？
多くのケースでは、期限後に TLS 1.2 を有効化（= クライアント/中継/バックエンドをTLS 1.2対応へ更新）しても、特別な「復旧儀式」のような作業は不要です。通信が成立する条件（TLS 1.2+ と証明書/暗号の整合）が満たされれば、その時点で自然に復旧します。
ただし現場では、単に「TLS 1.2に対応している」だけでは復旧しないことがあり、次の3点で詰まることが多いです。
- 暗号スイートの不一致：TLS 1.2対応でも、クライアントが古い暗号（例：弱いRSAや古いCBC系）しか持たないと握手できません。
- 証明書チェーン：中間証明書が欠けている、古いルート証明書しか信頼していない端末が残っている。
- 中継の存在：社内プロキシやSSLインスペクション機器がTLS 1.2未満で終端している（クライアント更新だけでは解決しない）。
復旧を早めるための「実務チェックリスト」は次のとおりです。
| チェック項目 | 具体例 | 確認手段 | 対処の方向性 |
|---|---|---|---|
| クライアントのTLS最小バージョン | 古いOS/ブラウザ、古いJRE、古いOpenSSL | 端末棚卸し、ランタイム/パッケージのバージョン確認 | OS/ランタイム更新、TLS設定の有効化 |
| 暗号スイート互換 | ECDHE未対応、特定暗号のみ対応 | テスト端末で実接続、TLS診断ツール | SSLポリシーの段階的強化、クライアント更新 |
| 証明書とチェーン | 中間証明書不足、期限切れ、SNIと証明書の不一致 | 証明書チェッカー、実ブラウザでの確認 | 証明書の更新/統一、正しいチェーン配布 |
| 中継経路 | プロキシ、FWのHTTPS検査、APIゲートウェイ | ネットワーク経路図、プロキシログ | 中継側のTLS 1.2+化、例外ルールの見直し |
WAF V1→V2移行の実務パターン（落とし穴つき）
Azure WAF（Application Gateway）の V1 と V2 は思想が異なり、いわゆる「ボタン一発のインプレースアップグレード」よりも、新しい WAF_v2 を並行作成して切り替える方式が現実的です。とくに本番で安全に進めるなら、次のように段階を踏むのがおすすめです。
移行の王道フロー
- 現状の構成を棚卸し：リスナー、証明書、ルーティングルール、バックエンドプール、プローブ、WAF設定（除外、カスタムルール）、ログ/監視。
- V2の新規作成：同一VNet内の専用サブネットに配置し、必要に応じてゾーン冗長やオートスケールを有効化。
- 設定の移植：HTTP設定/プローブ/証明書/ルール/リダイレクト/ヘッダー書換などをV2側へ再現。
- 検証環境で事前テスト：ステージング用DNSやホストファイルでV2へ向け、機能テストとWAF誤検知を確認。
- 本番切替：DNS切替、Traffic Manager/Front Doorで段階的ルーティング、または一時的な並列公開。
- 切替後監視：アクセスログ、WAFログ、ヘルス、バックエンド応答、TLSエラーを集中監視。
切替方法はシステム特性で変わります。APIだけならDNS TTLを短くして切替しやすい一方、B2B/固定クライアントが多い場合は段階的（カナリア）に流量を寄せた方が安全です。
V1→V2で特にハマりやすいポイント
| ハマりどころ | なぜ起きる | 事前の回避策 |
|---|---|---|
| Public IPのSKU差 | V2では標準SKUのIPが求められるケースが多く、既存のIPをそのまま使えないことがある | 切替方式（IP固定が必要か、DNSで逃がせるか）を先に決め、IP/DNS計画を作る |
| サブネット枯渇 | Application Gateway用サブネットは余裕が必要。V2の機能（スケール/ゾーン）でIP消費が増えることがある | サブネットサイズを再確認し、必要なら拡張/専用化してから移行 |
| 証明書とSNI | マルチサイト/複数証明書でSNI依存の構成だと、リスナー設定差分で握手失敗になる | ホスト名ごとの証明書対応を整理し、リスナー単位でテストする |
| WAF誤検知（False Positive） | ルールセットの更新、除外の漏れ、カスタムルール優先度の違いでブロックが変わる | 移行前に「学習用期間」を作り、ブロックログをもとに除外/調整を済ませる |
TLS 1.2移行を「期限前に」片付けるための現場テクニック
TLS 1.2 強制の本当の敵は、設定作業の難しさではなく「古いクライアントがどこに残っているか分からない」ことです。WAF移行と並行するなら、次の2段階で洗い出すとスムーズです。
段階1：ログで“怪しい”通信を見つける
- アクセスログで、クライアント種別（User-Agent）、送信元IP、時間帯、特定パスへの集中などを洗い出す
- TLSバージョン/暗号がログに出る構成なら、TLS 1.0/1.1 を明確に抽出する
Log Analytics に送っている場合は、まずは「どのクライアントがいるか」を可視化するだけでも十分効果があります。フィールド名は環境で異なるため、実データに合わせて調整してください。
// 例：アクセスログから送信元やUser-Agentを集計（フィールド名は環境により要調整）
AzureDiagnostics
| where Category == "ApplicationGatewayAccessLog"
| summarize Count=count() by clientIP_s, userAgent_s
| top 50 by Count desc段階2：意図的にTLS 1.2+へ寄せて影響を表に出す
可能なら、期限より前にフロントのSSLポリシーをTLS 1.2+にして、影響を先に顕在化させます。こうすると、期限当日に「突然止まった」ではなく、いつ、誰が、どの端末が困るかを事前に把握できます。
ただし、互換性を一気に絞りすぎると本番影響が大きくなります。最初は「TLS 1.2以上のみ」にして暗号スイートは広めに残し、段階的に強化するのが現実的です。
TLS強制とWAF移行が絡むときのリスク整理
「WAFをV2にしたからTLS問題が起きた」というより、同時期にやることで原因切り分けが難しくなります。トラブルを早く終わらせるために、リスクを最初から分類しておきましょう。
| 分類 | 障害の典型症状 | 原因の当たり | 切り分けのコツ |
|---|---|---|---|
| TLS（クライアント→WAF） | 接続できない、ブラウザのSSLエラー、APIのハンドシェイク例外 | TLS 1.0/1.1、暗号スイート、証明書チェーン、SNI | まずはWAFログではなくクライアント側エラーとTLSテストで確認 |
| WAFルール | 403（WAFでブロック）、特定リクエストだけ失敗 | 誤検知、除外不足、カスタムルール優先度 | WAFログのメッセージ/ルールIDで特定し、検知モード→防御モード移行を検討 |
| バックエンド（WAF→アプリ） | 502/504、ヘルス不良、特定バックエンドだけ落ちる | プローブ不整合、バックエンド証明書、SNI、DNS、ルーティング設定 | プローブとHTTP設定を最優先で確認。直アクセスでバックエンドが生きているかも確認 |
現場で使える「切替当日」の運用手順
切替当日は、作業の成否だけでなく「障害が起きたときに誰がどこを見るか」が重要です。おすすめの運用手順をテンプレとして残しておくと、チームで動きやすくなります。
- 監視ダッシュボード：HTTPステータス（200/3xx/4xx/5xx）、バックエンドヘルス、WAFブロック数、主要エンドポイントの応答時間。
- アラート設計：5xx急増、ヘルス不良、WAFブロック急増、DNS切替後のエラー率上昇。
- 切戻し判断：戻す閾値（例：5xxがX分でY%超、主要取引先から通信断報告など）を事前に合意。
- 連絡導線：アプリ担当/ネットワーク担当/取引先窓口の連絡先と、一次切り分け手順を一枚にまとめる。
よくある質問
TLS 1.0/1.1 の端末をどうしても残したい場合は？
Azure側でTLS 1.2+ が必須になると、フロントで旧TLSを受けること自体が難しくなります。業務上どうしても必要なら、旧TLS端末が到達できる場所に別の終端（例：社内ゲートウェイでTLS終端→内側はTLS 1.2+）を用意するなど、アーキテクチャで分離するのが現実的です。既存システムに無理やり例外を作るより、入口を分けた方が運用も安全です。
WAF移行とTLS対応、どちらを先にやるべき？
基本はTLS 1.2対応（洗い出しとクライアント更新）を先に進め、影響を可視化した上で WAF V2 へ移行する順が安全です。理由は、TLS問題は「接続できない」ため切り分けが難しく、WAF移行と同時だと原因が混ざりやすいからです。とはいえ期限が迫っている場合は、並行でも構いません。その場合は、検証環境でV2を先に立てておき、切替当日は“変数”を増やさない（証明書やルールを同時に大きく変えない）方針が効きます。
期限後に設定変更したら、サービス側で何か再起動や再デプロイが必要？
多くの場合、設定変更そのものに特別な再デプロイは不要です。ただし、クライアント側や中継側の更新をした場合は、プロセス再起動や証明書ストア更新の反映が必要になることがあります。復旧作業としては「Azureを触る」より「クライアント/中継の更新を確実に反映する」方が支配的です。
まとめ：期限後に困らないための最短ルート
- 8/31以降、TLS 1.0/1.1 が残っていれば原則として接続できず、WAF設定で救済できない。
- 期限後でもWAF V1→V2移行やSSLポリシー変更は可能だが、古いクライアントはその時点で切り捨てになる。
- 「TLS 1.2対応」と言っても、暗号スイート・証明書チェーン・中継機器で詰まる。ログと段階的強制で早期に洗い出す。
- WAF V2移行は新規作成→切替が基本。並行稼働と切戻し設計で安全に進める。
コメント