Application GatewayのKeyless TLS：秘密鍵保護と引き換えに増える署名経路の依存を検証する

結論：鍵の保護要件と署名経路の可用性をセットで判定する

編集上の判断：採用候補は、秘密鍵をゲートウェイへ渡さないことが設計要件となる環境です。その要件がない場合も含め、既存方式の継続とKeyless TLSへの移行を比較してください。鍵の保護を強化しても、業務の可用性や証明書更新の確実性が自動的に改善するとは評価できません。

編集上の反論：HSMを採用すれば常に安全で運用も簡単になる、という説明は不十分です。ID、HSM権限、署名操作、証明書公開部分、リスナーを別々に管理すると、鍵は存在していても接続を成立させられない構成になり得ます。導入の判断資料には、通常時と障害時の依存関係を同じ図で示します。

背景と技術的要因：TLSハンドシェイクにHSM署名が入る

確認済み事実：公式概要では、証明書の公開部分をゲートウェイへ渡し、秘密鍵をManaged HSM内に保持します。クライアントからのHTTPS接続時、ゲートウェイがHSMへ署名を要求し、返された署名を用いてTLSハンドシェイクを完了する流れです。

編集上の分析：公開Webリスナー、バックエンド、HSM署名経路は別の障害点として扱います。バックエンドのヘルスプローブ成功だけでは、利用者が新しいTLS接続を確立できることの証明になりません。鍵管理をデータ経路から独立した設定作業とみなさず、接続成立を支える依存サービスとして扱います。

日付・対象・制約：資料更新日を提供開始日へ読み替えない

日付の区別：公表日＝null。概要・チュートリアルの最終更新日＝2026-10-19。提供開始の適用日＝null。強制移行日＝null。非推奨化期日＝null。確認日＝2026-10-29。今回取得できた一次資料だけでは、GAの公表日や全リージョンでの提供開始日は確認できません。更新日を適用期限として案内しません。

確認済み事実：概要はApplication Gateway v2、Managed HSM、ユーザー割り当てマネージドIDとHSMキーへの権限を挙げています。チュートリアルの制約はTLS 1.2以降、SSLポリシーはAppGwSslPolicy20220101、AppGwSslPolicy20220101S、CustomV2です。

確認済み事実：Keyless TLSの非対応項目としてAGIC、WebSockets、L4 TCP/TLSプロキシ、FIPSモード、ECキーが列挙されています。これはApplication Gateway全体の機能廃止を意味しません。APIバージョン、必要なCLIの最小版、Terraformプロバイダーの最小版は今回確定できないためnullです。

確認済み事実：証明書操作に用いるライブラリについて、チュートリアルはOpenSSL 3.0.13との組合せを指定しています。編集上の提案：証明書作成環境の互換条件として確認し、稼働サーバー全体をこの版へ戻す指示には転用しないでください。

アーキテクチャ・実装・IaC：鍵参照と証明書を一組で管理する

確認済み事実：構成例はsslCertificatesにHSM参照を追加し、Azure CLIのssl-cert createで--hsmにkeyIdとpublicCertDataを渡します。ゲートウェイのユーザー割り当てIDにHSM側の権限を付与し、必要なら対象キー単位のスコープへ限定できます。

編集上の提案：Terraform/Bicepでは、利用中のAPI・プロバイダーが当該設定を扱えるかを先に検証します。未確認の属性名を補って実装せず、対応状況、取得された構成、planまたはwhat-ifの差分を記録してください。CLIで追加した設定が次回のIaC適用で消える状態は受け入れません。

編集上の提案：依存順は、HSMと鍵、実行ID、HSM権限、ゲートウェイのID関連付け、公開証明書と鍵参照、リスナー、ルールとして整理します。既存リスナー・証明書・IDをまとめて上書きしないよう、変更前構成を保存し、限定した試験リスナーから検証します。

編集上の提案：公開証明書、対応する鍵、ホスト名、有効期限、更新担当者を同じ台帳で追跡します。公開証明書だけの更新と、HSM鍵を含む更新を区別し、両者が一致しない状態を受入試験で検出してください。

運用・監視・フェイルオーバー：更新成功の表示だけでは判定しない

確認済み事実：公式手順はManaged HSMのAuditEvent診断とKeySign操作の確認を示します。また、証明書の置換が最初の更新で反映されない場合があるとし、追加変更または参照の削除・再追加を案内しています。

編集上の提案：設定更新後は、新規TLS接続で実際に提示される証明書のシリアル番号・有効期限・チェーン・ホスト名を確認します。接続再利用だけの試験にせず、署名ログ、ゲートウェイ側の状態、利用者視点の成功率・接続時間を時刻と対象IDで照合してください。KeySignログ件数と全HTTP要求数が一致するとは仮定しません。

編集上の提案：更新が反映されない場合、直ちに本番の鍵参照を削除する運用にはしません。公式の回避手順を検証環境で再現し、影響リスナー、実施順、停止許容時間、切戻し条件を決めます。証明書切替の確認をせずに追加変更だけを実施しても、完了証跡にはなりません。

編集上の提案：障害試験では、検証環境の専用IDに限った権限不備や通信不可を再現し、新規接続への影響、検知時間、復旧後の再接続を測定します。キャッシュ、セッション再開、再試行の詳細動作は今回確認できず、継続接続と新規接続への影響を同一と断定しません。DR先のID・権限・鍵参照・通信・公開証明書を実測し、DNS切替だけで復旧完了としないでください。

責任分界と費用：鍵の保管・利用・復旧を別々に引き継ぐ

編集上の分担案：基盤担当はリスナーと接続監視、鍵管理担当は鍵・証明書の対応とHSM権限、セキュリティ担当は監査ログ、業務責任者は停止・再開条件を管理します。サービス側の障害対応と、自社設定の修復・証明書更新を分け、契約と運用手順の担当範囲を一致させます。

編集上の提案：費用評価にはHSMの利用、署名負荷、ゲートウェイ、診断ログの取込・保持、復旧試験を含めてください。固定の月額や従来方式からの節約額は確認できません。通信の負荷試験結果と契約・リージョン別の最新公式価格を使って判断します。鍵の非エクスポート性を理由に無条件採用せず、継続運用できる費用と担当者を確保します。

移行手順：互換性確認から限定切替、更新・復旧試験へ進める

編集上の手順案：最初に非対応機能の利用有無と現行構成を確認し、次に検証用ID・鍵・リスナーで構成します。正常系、証明書更新、署名経路障害、復旧、IaC再適用を通した後、限定範囲で本番切替を行います。失敗時の戻し先が鍵保管要件に反しないかも、事前に判断してください。

適用上の前提：本記事は個別環境の設計保証や法的助言ではありません。実装適用には検証環境での事前テストと業務範囲の確認が必要です。以下のチェックリストは編集上の提案であり、公式仕様として追加の要件を課すものではありません。