「Microsoft Edge documentation update: fix(confidential-ledger): harden redirect handling against credential…」を見て、EdgeブラウザーやCopilot機能の更新だと思った方は、まず対象を切り分ける必要があります。結論から言うと、今回確認すべき中心は Microsoft Edge本体の設定ではなく、Azure SDK for JavaScriptの @azure-rest/confidential-ledger を使うアプリケーション です。
この更新は、Azure Confidential Ledgerクライアントがリダイレクトを処理する際に、資格情報やリクエスト本文を信頼できない宛先へ送らないようにするセキュリティ強化です。Edgeのグループポリシー、Copilot、ブラウザー拡張機能、閲覧設定を変更するタイプの更新ではありません。公式PRでは、対象パッケージが @azure-rest/confidential-ledger で、1.1.2-beta.5 から 1.1.2-beta.6 へ更新される内容として説明されています。(GitHub)
Microsoft Edge documentation updateとして見たときの位置づけ
今回の「Microsoft Edge documentation update」という表現は、Edge利用者向けの機能追加というより、Microsoft関連ドキュメントやGitHub上の更新情報を追っている管理者が見かけやすい更新名として捉えるのが適切です。
実際の変更対象は、Microsoft Edgeブラウザーではなく、Azure Confidential Ledger向けのJavaScript RESTクライアントです。Azure Confidential Ledgerは、機密データのレコードを管理するための不変データストアで、RESTインターフェイスやJavaScriptなどのSDKが提供されています。(Microsoft Learn)
| 確認項目 | 内容 |
|---|---|
| 対象サービスとして誤解しやすいもの | Microsoft Edge本体、EdgeのAI/Copilot機能、Edgeポリシー |
| 実際の主な対象 | Azure SDK for JavaScriptの @azure-rest/confidential-ledger |
| 更新の核心 | リダイレクト先が信頼境界内かを検証し、資格情報と本文の送信先を制限する |
| 管理者が見るべき場所 | npm依存関係、ロックファイル、Azure Confidential Ledger連携アプリ、プロキシ設定 |
| 直接影響しない可能性が高い利用者 | EdgeでWeb閲覧やMicrosoft Learn参照だけを行っている一般利用者 |
つまり、Edge管理者が最初に行うべきことは、Edgeの設定変更ではありません。社内にAzure Confidential Ledgerを利用するJavaScript/TypeScriptアプリがあるか、そこに @azure-rest/confidential-ledger が含まれているかを確認することです。
何が変わったのか
今回の修正では、Confidential Ledgerクライアント独自のリダイレクト処理が強化されています。従来は、Confidential Ledgerのロードバランサーからプライマリノードへリダイレクトされる際に、Authorization ヘッダーを保持する必要がありました。これは正当なリダイレクトで認証エラーを避けるための挙動です。
一方で、リダイレクト先が本当に台帳サービスの信頼できる範囲内かを十分に確認しないと、Bearerトークンや書き込みリクエストの本文が意図しない宛先へ送信されるリスクがあります。PRでは、この問題に対して「HTTPSであること」「ポートが一致すること」「ホスト名が設定済みの台帳ホスト名またはそのサブドメインであること」を満たす場合のみリダイレクトを許可する設計が採用されています。(GitHub)
信頼できるリダイレクトだけを許可する
今回の修正で重要なのは、「リダイレクトを全面的に禁止する」のではなく、「Azure Confidential Ledgerの正当な動作に必要なリダイレクトは許可し、それ以外は拒否する」という点です。
| リダイレクト先の例 | 扱い | 理由 |
|---|---|---|
https://node-primary.example-ledger.confidential-ledger.azure.com | 許可される可能性がある | 元の台帳ホスト名のサブドメインで、HTTPSかつ同一ポートであれば信頼境界内と判断できる |
http://... から始まるURL | 拒否 | HTTPSではないため |
| 別ドメインのURL | 拒否 | 台帳の信頼境界外に資格情報が送られる可能性があるため |
| 同じように見えるが別ホストのURL | 拒否 | プレフィックス衝突のような紛らわしいホスト名をサブドメインとして扱わないため |
| 異なるポートへのリダイレクト | 拒否 | 設定済みの台帳エンドポイントとポートが一致しないため |
この挙動は、単に Authorization ヘッダーを削除してリダイレクトを続行するより安全です。ヘッダーを削除しても、リクエスト本文が信頼できない宛先へ送られる可能性が残るためです。PRでは、この案は採用されず、信頼できないリダイレクトは拒否する方針が選ばれています。(GitHub)
書き込みリクエストのリダイレクトキャッシュも安全側に変更
Confidential Ledgerでは、書き込み操作がロードバランサーからプライマリノードへリダイレクトされることがあります。今回の更新では、307/308リダイレクト後のURLキャッシュについても安全性が見直されています。
変更後は、リダイレクトチェーンの途中でキャッシュを即時確定せず、信頼できるリダイレクトが完了し、最終的に非リダイレクトの応答に到達した場合にだけキャッシュを確定します。サーバーエラー、通信エラー、信頼できないリダイレクト、途中で不正なLocationヘッダーが発生した場合は、キャッシュを破棄する設計です。(GitHub)
これにより、悪意あるリダイレクト先が一度キャッシュされ、その後の書き込み処理が継続的に誤った宛先へ送られるような「キャッシュ汚染」を防ぎやすくなります。
影響範囲：Edge利用者より、Azure SDK利用アプリを優先して確認
今回の更新で影響を受ける可能性があるのは、Microsoft Edgeを使っているすべての利用者ではありません。影響範囲は、Azure Confidential LedgerとJavaScript SDKの利用有無で判断します。
| 利用状況 | 影響 | 対応の優先度 |
|---|---|---|
| Microsoft Edgeで通常のWeb閲覧をしている | 基本的に直接影響なし | 低 |
| EdgeでMicrosoft LearnやGitHubのドキュメントを閲覧している | 閲覧行為自体には直接影響なし | 低 |
| Azure Confidential LedgerをJavaScript/TypeScriptアプリで利用している | 依存パッケージの確認が必要 | 高 |
@azure-rest/confidential-ledger のベータ版を利用している | バージョン確認と検証が必要 | 高 |
| 独自プロキシやゲートウェイで台帳エンドポイントを中継している | リダイレクト先のホスト名・ポート・HTTPS要件の確認が必要 | 高 |
| REST APIを自前実装している | SDK修正は自動適用されないため、自前のリダイレクト処理確認が必要 | 中〜高 |
PR上では、1.1.2-beta.5 は未公開で、その内容は 1.1.2-beta.6 に含まれると記載されています。実際に利用できるパッケージバージョンは、npmや社内レジストリで確認してから更新してください。(GitHub)
Microsoft Edge管理者が確認すべきこと
Edge管理者の立場では、「Edgeポリシーを変えるべきか」よりも、「社内でEdgeを通じて利用している管理画面や業務アプリがAzure Confidential Ledgerを使っていないか」を確認するほうが実務的です。
Edge側でやってはいけない対応
今回の内容を誤ってEdgeのリダイレクト設定やセキュリティ設定の問題と捉えると、不要な変更をしてしまう可能性があります。
| 避けたい対応 | 理由 |
|---|---|
| Edgeのセキュリティ機能を弱める | SDK側のリダイレクト検証の問題であり、ブラウザー保護機能を弱めても根本対策にならない |
| CopilotやAI関連のポリシーを変更する | 今回のPRはCopilot機能更新ではない |
| 社内ポータルのリダイレクトを無条件許可する | 資格情報や本文の送信先を広げるリスクがある |
| 「Edgeでアクセスできるから安全」と判断する | SDKやサーバー側アプリの通信経路はブラウザー設定とは別に確認が必要 |
Edge管理者が関与するべきなのは、社内の開発・クラウド運用チームと連携し、Azure Confidential Ledgerを使うアプリの棚卸しを進める場面です。
管理者・開発者向けの確認チェックリスト
Azure Confidential Ledgerを利用している可能性がある場合は、次の順番で確認すると抜け漏れを減らせます。
| 確認項目 | 見る場所 | 判断基準 |
|---|---|---|
| パッケージ利用有無 | package.json、package-lock.json、pnpm-lock.yaml、yarn.lock | @azure-rest/confidential-ledger が含まれているか |
| 利用バージョン | ロックファイル、CIログ、npmレジストリ | ベータ版、特に 1.1.2-beta.4 以降を使っているか |
| 台帳エンドポイント | 環境変数、アプリ設定、Key Vault、CI/CD変数 | HTTPSの正規Azure Confidential Ledgerエンドポイントか |
| プロキシ・中継設定 | API Gateway、リバースプロキシ、WAF、社内プロキシ | Locationヘッダーを書き換えていないか、別ポートへ誘導していないか |
| 書き込み処理 | POST、PUT、PATCH、DELETEを行うコード | リダイレクト後も正常に書き込めるか |
| ログ | App Insights、Azure Monitor、アプリログ | 信頼できないリダイレクト拒否、5xx、リトライ増加がないか |
| 認証方式 | Microsoft Entra ID、証明書認証 | 最小権限で運用されているか |
Azure Confidential Ledgerのセキュアな運用では、台帳ノードの信頼性確認、Microsoft Entra IDによる認証、最小権限の適用が重要です。Microsoftのセキュリティガイダンスでも、台帳ノードの正当性確認、Microsoft Entra IDの利用、Reader・Contributor・Administratorといった役割に基づく最小権限管理が推奨されています。(Microsoft Learn)
開発者が行う移行・展開手順
依存関係を確認する
まず、対象パッケージを本当に使っているか確認します。
npm ls @azure-rest/confidential-ledgerpnpmを使っている場合は、次のように確認できます。
pnpm why @azure-rest/confidential-ledgerYarnの場合は、次のコマンドが使えます。
yarn why @azure-rest/confidential-ledgerロックファイルだけでなく、CI/CDで実際に解決されているバージョンも確認してください。開発端末では新しいバージョンでも、本番ビルドでは古いロックファイルが使われているケースがあります。
利用可能なバージョンを確認する
PRやCHANGELOG上のバージョンが、すぐにnpmで利用できるとは限りません。特に今回のように Unreleased と記載されている場合は、公開レジストリまたは社内レジストリで利用可能か確認してから更新します。
npm view @azure-rest/confidential-ledger versions --json1.1.2-beta.6 が利用可能で、組織としてベータ版利用を許可している場合は、検証環境で更新します。
npm install @azure-rest/[email protected]ただし、ベータ版は本番利用方針が組織によって異なります。すでに安定版のみを許可している環境では、無理にベータ版へ上げるのではなく、Microsoftの正式リリース状況、セキュリティアドバイザリ、社内リスク評価に基づいて判断してください。
リダイレクト処理をテストする
更新後は、単にビルドが通るだけでは不十分です。今回の変更はリダイレクト時の挙動に関わるため、通常の読み取り処理だけでなく、書き込み処理を含めて確認します。
| テスト観点 | 確認内容 |
|---|---|
| 正常な書き込み | Confidential LedgerへのPOST/PUT/PATCH/DELETEが成功するか |
| 正当なリダイレクト | ロードバランサーから台帳サブドメインへのリダイレクトが失敗しないか |
| 不正なリダイレクト拒否 | 外部ドメインやHTTPへのリダイレクトを拒否できるか |
| 資格情報の保護 | ログやモックで、Bearerトークンが信頼できない宛先へ送られていないか |
| キャッシュの安全性 | エラー後に誤ったリダイレクト先を再利用していないか |
| リトライ挙動 | 5xxや通信エラー後に、元のロードバランサーURLから再試行できるか |
PRでは、クロスオリジン、HTTPへのダウングレード、兄弟ドメイン、異なるポート、プレフィックス衝突、途中の信頼できないホップなどを含むセキュリティ回帰テストが追加されたと説明されています。自社のテストでも、実際の攻撃手順を再現するのではなく、モックやテスト用HTTPクライアントで「拒否すべき宛先に資格情報が送られない」ことを確認するのが安全です。(GitHub)
展開時の注意点
カナリア展開でログを確認する
本番環境へ一括展開する前に、検証環境または一部トラフィックでカナリア展開します。特に、以下のログを確認してください。
Confidential Ledger refused to follow redirect...のような拒否ログ- 307/308リダイレクト後の書き込み成功率
- 401、403、5xxの増加
- リトライ回数の急増
- 書き込み遅延の変化
- プロキシやWAFでのLocationヘッダー書き換え
拒否ログが出た場合、すぐにSDKを戻すのではなく、リダイレクト先が本当に正規の台帳サブドメインか、プロキシがホスト名やポートを書き換えていないかを先に確認してください。信頼境界外へのリダイレクトを許可する方向で回避すると、今回のセキュリティ強化を無効化してしまいます。
独自プロキシを使う環境は特に注意する
社内ネットワークでは、Azureサービスへの通信をリバースプロキシ、API Gateway、WAF、透過プロキシ経由にしていることがあります。この場合、リダイレクト先のURLがAzure Confidential Ledgerの正規サブドメインではなく、社内ドメインや別ポートに変換されることがあります。
今回の修正では、リダイレクト先がHTTPS、同一ポート、台帳ホスト名またはそのサブドメインであることが重要です。プロキシがLocationヘッダーを独自ドメインに書き換える構成では、更新後にリダイレクトが拒否される可能性があります。これはSDKの不具合とは限らず、信頼境界の設計とプロキシ構成が合っていない可能性があります。
ほかの言語SDKに同じ修正が入っているとは限らない
今回のPRはJavaScript SDKの @azure-rest/confidential-ledger に関するものです。PR内では、Python側の関連PRにも触れられていますが、同じタイミングで同じ修正がすべての言語SDKへ反映されるとは限りません。JavaScript以外でConfidential Ledgerを使っている場合は、各SDKのリリースノート、CHANGELOG、GitHub PRを個別に確認してください。(GitHub)
よくある誤解と正しい判断
Microsoft EdgeのAI/Copilot機能が変わるのか
今回の確認対象は、EdgeのAI機能やCopilot機能ではありません。EdgeのUI、サイドバー、Copilotポリシー、検索設定を変更する必要は基本的にありません。
「Microsoft Edge documentation update」という見え方だけで、Edgeブラウザー更新と判断しないことが重要です。実際には、Azure SDK for JavaScriptのConfidential Ledgerクライアントに関するセキュリティ修正として読むべき内容です。
Edgeでアクセスする社内アプリは影響を受けるのか
Edgeで利用している社内アプリが、バックエンドでAzure Confidential Ledgerと通信している場合は、間接的に関係する可能性があります。たとえば、監査ログ、契約データ、重要イベント記録をConfidential Ledgerへ書き込むアプリでは、サーバー側のSDK更新が必要になることがあります。
一方、Edgeで通常のWebサイトを閲覧しているだけ、またはMicrosoft Learnを参照しているだけであれば、今回のSDK修正による直接対応は基本的に不要です。
リダイレクトをすべて禁止すればよいのか
すべてのリダイレクトを禁止すると、Confidential Ledgerの正当な動作まで壊れる可能性があります。Confidential Ledgerでは、ロードバランサーからプライマリノードのサブドメインへリダイレクトされることがあるためです。
今回の修正は、正当なサブドメインへのリダイレクトを残しながら、信頼できない宛先への資格情報送信を防ぐ設計です。管理者が独自に制御を追加する場合も、「全面禁止」ではなく「信頼境界内だけ許可」という考え方に合わせるべきです。
次に取るべき行動
今回のMicrosoft Edge documentation updateを見た管理者や開発者は、Edgeの設定画面を探すのではなく、まず依存関係を確認してください。
最初に、社内アプリの package.json とロックファイルから @azure-rest/confidential-ledger の利用有無を調べます。次に、利用しているバージョンと、1.1.2-beta.6 がnpmまたは社内レジストリで利用可能かを確認します。そのうえで、検証環境で書き込み処理、正当なリダイレクト、不正なリダイレクト拒否、キャッシュ無効化、ログ監視をテストします。
Edge管理者は、ブラウザー設定を変更するよりも、Azure運用担当者や開発チームと連携し、Confidential Ledgerを使う業務アプリを棚卸しすることが重要です。開発者は、更新後にリダイレクト拒否が発生した場合でも安易に制限を緩めず、エンドポイント、プロキシ、Locationヘッダー、ポート、HTTPS構成を順に確認してください。
今回の更新の本質は、Edgeの機能追加ではなく、資格情報を信頼できる宛先にだけ送るための防御強化です。Azure Confidential Ledgerを使うアプリがある場合は、依存関係の確認、検証環境での更新、段階的な本番展開までをセットで進めるのが安全です。
コメント