本記事は、セキュリティイベント「NDC Security 2026」のバーカード氏によるセッション「The dark art of OIDC abuse - A case study in Entra ID」の内容を基に構成している。

　Azure DevOpsには、ビルドや展開のパイプラインから外部のバックエンドに安全に接続するための「サービス接続」（Service Connections）という機能がある。近年、この認証手段として推奨されているのが「ワークロードIDフェデレーション」だ。

　ワークロードIDフェデレーションは、OIDCを利用して外部のIDプロバイダーと信頼関係を確立する仕組みだ。従来のアプローチでは、サービスプリンシパル（アプリケーションやサービスがシステムにアクセスするためのID）のシークレットをAzure DevOpsに保持しておく必要があった。しかし、OIDCを利用すれば、動的に発行されるトークンを用いて認証するため、シークレットの保管や定期的なローテーション作業から解放される。運用負荷の軽減とセキュリティの向上を両立させる合理的な設計思想だと言える。

正常なOIDC認証のフロー

　正常な動作フローでは、まずサービス接続の作成時に「サブジェクト識別子」（Subject identifier）と「発行者」（Issuer）という2つの情報が生成される。これをEntra IDのサービスプリンシパルに登録することで、両者間に信頼関係が構築される。

　パイプラインを実行するビルドエージェントは、最初にAzure DevOpsのOIDC発行者に対して署名付きのOIDCトークンを要求する。次に、取得したトークンを用いてEntra IDに対して認証を試みる。Entra IDは、発行者の公開鍵を用いてトークンの署名を暗号学的に検証し、設定されたサブジェクトと一致するかを確認する。この検証に成功すると、サービスプリンシパルとしての権限を持つアクセストークンが返却され、バックエンドのリソースへのアクセスが可能になる。

「検証して保存」に潜んでいた実装の欠陥

　バーカード氏が着目したのは、サービス接続を設定する画面にある「検証して保存」（Verify and save）という機能の挙動だ。このボタンをクリックすると、Azure DevOpsは入力された資格情報を用いてログインを試み、実際にアクセス可能かをバックエンドのリソースに対して確認する。

　通信の内容を解析した結果、この接続テストの通信を中継する裏側のAPI（検証用プロキシAPI）に対し、開発者のWebブラウザから「サブジェクト」の情報が直接送信されていることが判明した。本来、サブジェクトはサービス接続にひも付く固有のIDであり、サーバで一意に決定されるべき情報だ。Webブラウザから送信させる必要はなく、開発者が制御できてはならない。

　しかし、Azure DevOpsのサーバでは、開発者のWebブラウザから送信されたサブジェクトの妥当性を検証することなく、そのまま最初のOIDCトークンの生成に使用していた。これによって、攻撃者はリクエスト内のサブジェクトを任意の値に書き換える「サブジェクトのなりすまし」（Subject Spoofing）が可能になっていたのだ。

権限昇格とトークン奪取の技術的アプローチ

　この実装の不備は、重大な権限昇格の引き金となる。例えば、権限の低いサービス接続しか持たない攻撃者であっても、リクエスト内のサブジェクトを書き換えることで、高権限を持つ別のサービス接続に成り済ますことができる。結果として、その高権限のサービスプリンシパルとしてEntra IDにログインし、アクセス権を奪うことが可能になる。

　バーカード氏は、アクセストークンを実際に外部へ引き出す手法を確立した。同じ検証用エンドポイントに、サーバに任意の宛先へのリクエストを送信させる脆弱性SSRF（サーバサイドリクエストフォージェリ）が存在することを発見したのだ。

　攻撃者は、成り済ましたいサブジェクトを指定すると同時に、バックエンドのリソースの確認先として自身が管理するサーバのURLを指定する。すると、Azure DevOpsは偽装されたサブジェクトを用いてEntra IDからアクセストークンを取得し、そのトークンを付与した状態で攻撃者のサーバへとリクエストを送信してしまう。これにより、攻撃者はEntra IDの正規のアクセストークンを自らの手元に取得することができた。

今後の展望とセキュリティ上の留意点

　本脆弱性はMicrosoftに報告され、すでに修正が完了している。サブジェクトの成り済ましという根本的な認証フローの欠陥はふさがれたものの、「検証して保存」を実行するAPIには依然としてSSRFにつながる挙動が残されているとバーカード氏は指摘する。

　OIDCのような先進的な認証プロトコル自体は堅牢（けんろう）であっても、それを実装するシステムのインタフェースや機能の境界に想定外の欠陥が存在することは珍しくない。クラウドインフラを運用するIT担当者は、クラウドベンダーが提供する便利な機能の裏側に潜む構造的なリスクを理解し、設定上の分離や最小特権の原則を徹底したアーキテクチャを設計する必要がある。

本稿は、NDC Conferencesが2026年5月12日に公開した動画「The dark art of OIDC abuse - A case study in Entra ID - Cody Burkard - NDC Security 2026」を基に作成しました。