Azure APIコネクションの継続的な露出スキャナー
Azure Logic AppsのAPIコネクションを継続的に監査し、過剰な権限を持つトークンや既知のテナント間攻撃経路を、第三者に見つけられる前に特定します。
Claude Code や Cursor などのコーディングエージェントにそのまま貼れる概要（英語）です。
総合6.5/10
課題の深刻さ7
支払い意欲6
タイミング8
市場の空白6
参入障壁6
実現性6
賛成
- 誰が払うか
- Logic AppsとPower Platformを利用する、Azure中心の大企業（従業員500名以上）のクラウドセキュリティ責任者やAppSecマネージャー。クラウドセキュリティ態勢管理（CSPM）の予算から月1,000〜3,000ドルを想定します。
- 議論での声 · 4
- 記事では、APIコネクションを通じて被害者のKey Vault、SQLデータベース、Jira、Salesforceにアクセスできる5つの異なるテナント間侵害経路が示されています。著者は、コネクショントークンがほとんど最小権限でスコープされていないと推測しています。 記事から ↗
- Microsoftは報告された脆弱性の修正を誤って適用し、その後の修正で以前の修正が再び壊れ、システムが再び脆弱になりました。 コメントを読む ↗
- Azureは競合他社よりもテナント間の情報漏えいが多いように見えますが、企業の採用は続いています。 コメントを読む ↗
- 問題の根本は基本的なパストラバーサルやIDORであり、この機能が公開された当初から存在していた可能性が高いと見られます。 コメントを読む ↗
議論の内容を要約したものです。元のコメントはリンクからどうぞ。
- 競合と空白
CSPMは一般的な設定ミスを検出しますが、Logic Apps/APIコネクションの攻撃対象領域を深くモデル化しているツールはありません。具体的には、DynamicInvoke型のプロキシエンドポイント、host.api.RuntimeUrlによる上書き、V1とV2のコネクションにおける暗黙のアクセス権、コネクターごとのトークン権限スコープなどが対象外です。Defender for Cloudは、まさにこの領域で不完全な修正を繰り返し出してきたベンダーです。
- なぜ今か
- 1つのコネクターサブシステムに対する5件の実証済みテナント間攻撃が、連載記事として公開されました。修正も何度か退行しています。コメントでは、LLMによる発見がこの種の問題を増やすと予想されており、防御側には一度きりのペンテストではなく継続的なテストが必要になっています。
- 参入障壁 · 6/10
- 数百種類のAzureコネクタータイプと、文書化されていないエンドポイントを網羅した、継続的に更新されるルールと攻撃グラフのライブラリを、独自の研究に基づいて構築します。再現用のハーネスやテナントから得た知見は時間とともに蓄積され、汎用的なCSPMが短期間で模倣するのは困難です。
反対
- レッドチーム
- CSPMがLogic Apps/APIコネクションのこの攻撃対象領域を見落としていることは明らかです。研究によって現実に悪用可能であることも示されています。さらに、Azure中心の大企業は、Wiz規模の予算を既に態勢管理ツールに支払っています。
- 失敗するとしたら
- Microsoftが最終的にAPIコネクションを根本から再設計し、マネージドIDやV2の利用を全面的に義務付けた場合、顧客を獲得する前に攻撃対象領域そのものが消えてしまいます。
始め方
- 最初の3ステップ
- テナントのAPIコネクションを列挙する読み取り専用のAzure監査ツールを作ります。V1コネクション、広範なバックエンドスコープを持つ管理されていないOAuthトークン、到達可能な動的エンドポイントを検出します。
- 公開された攻撃の種類（DynamicInvokeによるパストラバーサル、RuntimeUrlの上書き）について、顧客自身のコネクションに対して安全で非破壊的な確認を再現します。
- 設定変更時やMicrosoftが修正をリリースした後に検査を再実行するダッシュボードとアラートを提供します。各コネクターのトークンのスコープを絞るための是正ガイドも併せて提供します。
- 元の議論
- Azure's Weakest Link – Five Full Cross-Tenant Compromises ↗ 329 ポイントコメント 60 件投稿からリンク先の記事
英語からの翻訳です。 原文を読む