Microsoft Entra Workload IDのフェデレーション資格情報で、リポジトリ名やプロジェクトパス、ユーザー名などから作られた可変OIDC subjectを信頼条件にしている場合は、設定を見直す必要があります。
元のリポジトリやプロジェクトが削除、改名、移管された後、同じ名前が別の主体へ再割り当てされると、新しい主体が発行したOIDCトークンのsub claimが既存のフェデレーション資格情報に一致する可能性があります。その結果、本来は以前のワークロードだけに許可していたMicrosoft Entraのアクセス権が、別のワークロードから利用されるおそれがあります。これは「subject recycling」と呼ばれるリスクです。
Microsoftは2026年7月30日更新の公式情報で、可能な限り再利用されない不変claimを信頼条件に使い、不要になったフェデレーション資格情報を削除するよう推奨しています。(Microsoft Learn)
Entraフェデレーションで可変OIDC subjectを避けるべき理由
Microsoft Entraのフェデレーション資格情報は、外部IDプロバイダーが発行したOIDCトークンについて、主に次の値を照合します。
iss：トークンを発行した外部IDプロバイダーsub：外部ワークロードを識別するsubjectaud：トークンの利用先
通常のフェデレーション資格情報では、登録したissuer、subject、audienceと、受信したトークン内の値が大文字・小文字を区別して一致した場合に、トークン交換が許可されます。Microsoft Entraは、同じsub文字列が以前どのリポジトリやプロジェクトに割り当てられていたかまでは判断しません。(Microsoft Learn)
したがって、次のような名前ベースのsubjectを設定していると注意が必要です。
repo:contoso/payment-api:ref:refs/heads/mainこの文字列に含まれるcontosoやpayment-apiが変更、移管、削除後の再作成によって別の主体に割り当てられると、外部IDプロバイダーが同じsubを持つ正規のOIDCトークンを発行する可能性があります。
ここで起きるのは、フェデレーション資格情報ファイルやシークレットの盗難ではありません。古い信頼設定を、新しい主体が正規のトークンによって満たしてしまう問題です。
シークレットレス認証に移行しても、信頼条件のライフサイクル管理が不要になるわけではありません。シークレット漏えいのリスクが減る一方で、subjectの再割り当てや不要な信頼設定の放置が新たな管理ポイントになります。
可変subjectと不変subjectの違い
可変か不変かは、文字列の見た目ではなく、外部IDプロバイダーがその値をどのように管理しているかで判断します。
| 判断項目 | 可変subject | 不変subject |
|---|---|---|
| 主な生成元 | リポジトリ名、プロジェクトパス、組織名、ユーザー名 | リポジトリID、プロジェクトID、所有者IDなど |
| 改名による影響 | 値が変わる可能性がある | 通常は変わらない |
| 削除後の再利用 | 同じ名前を別主体が取得できる場合がある | 一度割り当てたIDを再利用しない設計 |
| 移管時の扱い | 所有者名やパスが変化することがある | 元のリソースに紐づき続ける |
| Entraの信頼条件 | 原則として避ける | 優先して使用する |
| 例 | project_path:group/project | project_id:57382910 |
Microsoftが可変subjectの例として挙げているのは、改名や再作成が可能なリポジトリ、プロジェクト、グループ、名前空間、組織ハンドル、ユーザー名などです。一方、不変識別子は、元のリソースに一度だけ割り当てられ、後から別主体へ再利用されない値です。(Microsoft Learn)
注意したいのは、数字やGUID形式だからといって自動的に不変とは限らない点です。次の条件を外部IDプロバイダーの仕様で確認する必要があります。
- リソースの改名後も同じ値が維持されるか
- 別組織への移管後も同じリソースを表すか
- リソース削除後に同じ値が再利用されないか
- バックアップからの復元や再作成で別IDになるか
- subject以外のclaimでも同じIDを検証できるか
「変更できない」だけでなく、「将来も別主体へ再割り当てされない」ことが重要です。
subject recyclingが起きる流れ
可変OIDC subjectによるsubject recyclingは、次のように発生します。
- 管理者が名前ベースの
subを信頼するフェデレーション資格情報を作成する - 元のリポジトリやプロジェクトが削除、改名、移管される
- 古い名前やパスが再利用可能になる
- 別のユーザーや組織がその名前を取得する
- 新しい主体のOIDCトークンに、古い設定と一致する
subが含まれる - Microsoft Entraがフェデレーション資格情報との一致を確認する
- 新しい主体に、アプリ登録またはユーザー割り当てマネージドIDのアクセストークンが発行される
Microsoftは、これを可変subjectにおける主要なセキュリティリスクとして説明しています。(Microsoft Learn)
ただし、名前を取得しただけで無条件にアクセスできるわけではありません。一般に、次の条件がそろう必要があります。
| 成立条件 | 内容 |
|---|---|
| 同じissuer | 古い資格情報が信頼する外部IDプロバイダーからトークンが発行される |
| subjectが一致 | 通常の資格情報では完全一致、柔軟な資格情報では条件式に一致する |
| audienceが一致 | Entra向けの想定されたaudが設定されている |
| 古い資格情報が残っている | 元ワークロード廃止後も信頼設定が削除されていない |
| Entra側に権限がある | アプリまたはマネージドIDにAzure RBACやAPI権限が付与されている |
そのため、実際の影響範囲はフェデレーション資格情報に紐づくMicrosoft Entra ID上の権限によって変わります。サブスクリプション全体に広い権限を持つIDと、特定のストレージコンテナーだけに権限を持つIDでは、同じsubject recyclingでも影響が大きく異なります。
dangling federated identity credentialがリスクを高める
元のワークロードが存在しないのに、Microsoft Entra側のフェデレーション資格情報だけが残っている状態を、Microsoftは「dangling federated identity credential」と呼んでいます。
日本語では、宙ぶらりんになった資格情報、孤立した資格情報、不要になった信頼設定などと考えると分かりやすいでしょう。
発生しやすいのは、次のような場面です。
- GitHubやGitLabのリポジトリを削除した
- リポジトリ名やプロジェクト名を変更した
- プロジェクトを別の組織へ移管した
- CI/CDパイプラインを別サービスへ移行した
- 検証環境や一時プロジェクトだけを削除した
- 担当者の異動後、アプリ登録の管理者が不在になった
- 新しい資格情報へ移行した後、古い設定を削除し忘れた
ワークロードを削除すると、通常は古いパイプラインからの認証も行われなくなります。そのため、フェデレーション資格情報が残っていても日常運用ではエラーが発生せず、設定の残存に気づきにくいのが問題です。
その後、古い名前が別主体に使われた時点で、放置されていた信頼設定が再び有効な経路になる可能性があります。Microsoftは、不変subjectの利用に加え、不要な資格情報の削除、定期監査、最小権限化を推奨しています。(Microsoft Learn)
通常の資格情報と柔軟なフェデレーション資格情報の違い
Microsoft Entra Workload IDには、通常のフェデレーション資格情報に加え、条件式でclaimを評価できるFlexible federated identity credentialsがあります。
| 項目 | 通常のフェデレーション資格情報 | Flexible federated identity credentials |
|---|---|---|
| subjectの評価 | 登録値との完全一致 | 条件式による一致 |
| ワイルドカード | 使用不可 | matchesで使用可能 |
| 複数claimの照合 | 基本的にissuer、subject、audience | 許可された追加claimをandで組み合わせ可能 |
| 向いている用途 | 特定ブランチや特定環境を厳密に信頼 | 複数ブランチやタグをまとめて管理 |
| 注意点 | 資格情報数が増えやすい | 条件を広げすぎると信頼範囲も広がる |
Flexible federated identity credentialsは、ワイルドカードを使って複数ブランチやタグを1つの設定で扱える便利な機能です。ただし、ワイルドカードを使えばsubject recyclingを防げるわけではありません。
例えば、次のように名前ベースのリポジトリ全体を信頼している場合、リポジトリ名自体が再利用されれば、条件式にも一致する可能性があります。
claims['sub'] matches 'repo:contoso/payment-api:*'安全性を高めるには、ワイルドカードでブランチ部分を柔軟にしつつ、リポジトリIDやプロジェクトIDなどの不変claimで主体を固定します。
Flexible federated identity credentialsは、2026年7月時点ではプレビュー機能として案内されており、対応issuerや設定対象、管理方法に制約があります。通常のsubjectプロパティとclaimsMatchingExpressionは同時に指定できません。導入時には最新の対応状況を確認する必要があります。(Microsoft Learn)
可変OIDC subjectを監査する手順
フェデレーション資格情報を一覧化する
アプリ登録に設定されたフェデレーション資格情報は、Azure CLIで確認できます。
az ad app federated-credential list \
--id <application-object-id> \
--output jsonユーザー割り当てマネージドIDの場合は、次のコマンドを使用します。
az identity federated-credential list \
--identity-name <identity-name> \
--resource-group <resource-group> \
--output jsonこれらのコマンドは対象を1件ずつ確認する方法です。多数のアプリ登録を運用している組織では、Microsoft Graphなどを使ってテナント全体の情報を収集し、台帳化すると管理しやすくなります。(Microsoft Learn)
最低限、次の情報を記録します。
| 記録項目 | 確認内容 |
|---|---|
| 親オブジェクト | アプリ登録またはユーザー割り当てマネージドID |
| 資格情報名 | フェデレーション資格情報の管理名 |
| issuer | GitHub、GitLab、Kubernetesなどの発行元 |
| subject | 登録されているsubの値 |
| 条件式 | claimsMatchingExpressionの内容 |
| audience | 通常はEntraのトークン交換用audience |
| 対応ワークロード | リポジトリ、プロジェクト、クラスターなど |
| ワークロード所有者 | 管理チームや担当者 |
| Entra側権限 | Azure RBAC、Microsoft Graph権限、アプリケーション権限 |
| 存在確認 | 元のワークロードが現在も存在するか |
| 不変性 | subjectの構成値が再利用されないか |
実際のOIDCトークンを確認する
ポータルに登録されたsubjectだけで判断せず、外部IDプロバイダーが実際に発行するOIDCトークンも確認します。
主に見るべきclaimは次のとおりです。
isssubaud- リポジトリID
- リポジトリ所有者ID
- プロジェクトID
- 名前空間ID
- ジョブを実行するユーザーID
- ブランチ、タグ、環境を示すclaim
本番トークンを外部のJWT解析サイトへ貼り付けるのは避け、ローカル環境、CI/CDプラットフォームのプレビュー機能、管理APIなどを利用します。
subjectにパスや名前が含まれているだけで直ちに脆弱と断定するのではなく、その値が外部IDプロバイダー上で再利用されるかを確認することが重要です。仕様が分からない場合は、安全側に倒して可変subjectとして扱います。
対応優先度を決める
すべての資格情報を同時に変更できない場合は、次の順で対応します。
| 優先度 | 状況 |
|---|---|
| 最優先 | 元ワークロードが削除済みで、名前ベースの資格情報だけが残っている |
| 高 | リポジトリやプロジェクトを改名・移管した後、古い資格情報が残っている |
| 高 | 可変subjectに紐づくEntra IDが広いAzure RBACやAPI権限を持つ |
| 中 | 現在稼働中だが、将来再利用され得る名前ベースのsubjectを使っている |
| 中 | Flexible資格情報で可変名に広いワイルドカードを設定している |
| 低 | 不変IDを使い、元ワークロードの存在確認と最小権限化ができている |
停止時間を抑えて不変subjectへ移行する方法
既存のパイプラインを止めずに移行する場合は、次の順序で進めます。
- 外部IDプロバイダーから不変IDを取得する
- 不変subjectを信頼する新しいフェデレーション資格情報を追加する
- 外部IDプロバイダー側で、不変subjectを含むOIDCトークンを発行するよう設定する
- CI/CDワークフローを実行し、認証とデプロイが成功することを確認する
- 古い名前ベースのフェデレーション資格情報を削除する
- 不要なRBACやAPI権限がないか再確認する
先に古い資格情報を削除すると、外部IDプロバイダー側の切り替えが完了するまで認証できなくなる可能性があります。反対に、新旧両方を長期間残すと、可変subjectの信頼経路が残り続けます。
新しい資格情報を追加して動作確認した後、古い資格情報を速やかに削除することが重要です。Microsoftが公開しているGitHub Actionsの移行手順でも、この並行追加、検証、旧資格情報削除の順序が採用されています。(Microsoft Learn)
GitHub Actionsで不変subjectを使う例
GitHub Actionsで従来使われてきた名前ベースのsubjectは、次のような形式です。
repo:contoso/payments-api:ref:refs/heads/main不変形式では、所有者名とリポジトリ名に、それぞれの数値IDが追加されます。
repo:contoso@5544123/payments-api@821093847:ref:refs/heads/main所有者IDとリポジトリIDは一度割り当てられた後に再利用されないため、リポジトリの改名、移管、同名での再作成が行われても、元のリポジトリに対する信頼を維持しやすくなります。(Microsoft Learn)
通常のフェデレーション資格情報では、この不変subject全体を完全一致で登録します。
{
"name": "payments-main-immutable",
"issuer": "https://token.actions.githubusercontent.com",
"subject": "repo:contoso@5544123/payments-api@821093847:ref:refs/heads/main",
"audiences": [
"api://AzureADTokenExchange"
]
}Flexible federated identity credentialsを使う場合は、subだけでなく、repository_idやrepository_owner_idも条件に含めます。
claims['sub'] matches 'repo:contoso@5544123/payments-api@821093847:*'
and claims['repository_id'] eq '821093847'
and claims['repository_owner_id'] eq '5544123'リポジトリを別の所有者へ移管した後も利用できるようにするならrepository_idを中心に信頼し、特定の所有者に属する場合だけ許可したいならrepository_owner_idも照合します。どちらが適切かは、組織の信頼境界によって異なります。(Microsoft Learn)
Microsoftの2026年7月30日更新情報では、GitHubの不変subjectはGitHub.com向けであり、GitHub Enterprise Serverでは利用できないとされています。また、2026年7月15日以降、新規作成、改名、移管されたリポジトリには不変形式が自動適用される一方、それ以前から存在するリポジトリは明示的に切り替えるまで名前ベースの形式を維持します。既存環境は自動的に安全な形式へ変わったとは限らないため、個別確認が必要です。(Microsoft Learn)
GitLabでproject_pathからproject_idへ移行する例
GitLabでは、従来のsubjectがプロジェクトパスを基に作られる場合があります。
{
"iss": "https://gitlab.com",
"sub": "project_path:acme-group/billing-service:ref_type:branch:ref:main"
}acme-groupやbilling-serviceは改名、移管、再取得の対象になり得るため、この形式は可変subjectとして扱う必要があります。
GitLabでは、subjectの先頭を不変のproject_idに変更できます。
{
"iss": "https://gitlab.com",
"sub": "project_id:57382910:ref_type:branch:ref:main"
}Microsoftの公式例では、Flexible federated identity credentialsを使って複数ブランチやタグをまとめる場合、次のように不変IDを組み合わせます。
claims['sub'] matches 'project_id:57382910:*'
and claims['project_id'] eq '57382910'
and claims['namespace_id'] eq '<namespace-id>'GitLab向けのFlexible federated identity credentialsでは、subに加えて、project_id、namespace_id、user_idのうち、信頼境界を表すclaimを照合します。特定ユーザーが実行したジョブだけを許可する場合は、user_idも条件へ追加します。(Microsoft Learn)
可変subject対策で失敗しやすいポイント
issuerを固定しているから安全だと考える
issuerを固定すれば、別のOIDCプロバイダーから発行されたトークンは拒否できます。しかし、subject recyclingは同じissuer内で名前が別主体へ再割り当てされる問題です。
そのため、issuerの完全一致だけでは防げません。
audienceを限定すれば主体を識別できると考える
audienceは、そのトークンがMicrosoft Entraとの交換用に発行されたことを確認するために重要です。しかし、同じ外部IDプロバイダーで新しい主体が同じaudienceのトークンを取得できる場合、古い主体との区別にはなりません。
主体の識別には、不変subjectや追加の不変claimが必要です。
ワイルドカードへ移行すれば安全になると考える
Flexible federated identity credentialsのワイルドカードは、資格情報数を減らすための機能です。subjectを不変にする機能ではありません。
claims['sub'] matches 'repo:contoso/*'このような条件は運用を簡単にする一方、組織名やリポジトリ名が可変であれば、信頼範囲を必要以上に広げる可能性があります。
ワイルドカードを使う場合も、リポジトリID、所有者ID、プロジェクトID、名前空間IDなどを組み合わせます。
新しい資格情報の追加後に古い設定を残す
移行中に新旧両方の資格情報を登録すること自体は、停止時間を避けるための合理的な方法です。しかし、テスト終了後も古い名前ベースの資格情報を残すと、subject recyclingへの露出は解消されません。
移行作業には「旧資格情報の削除」までを含めます。
subjectだけを見てEntra側の権限を確認しない
同じ可変subjectでも、紐づくIDが持つ権限によってリスクは変わります。
確認対象には次のものを含めます。
- AzureサブスクリプションやリソースグループのRBAC
- Key VaultやStorageなどのデータプレーン権限
- Microsoft Graphのアプリケーション権限
- Azure DevOpsや各種SaaSへのアクセス権
- 別のマネージドIDやシークレットを取得できる権限
subjectの移行と同時に、不要なロール割り当てやAPI権限も削除します。
subject recyclingが疑われる場合の対応
別主体による利用が疑われる場合は、単に新しいフェデレーション資格情報を追加するだけでは不十分です。
まず、影響が疑われる名前ベースの資格情報を削除します。影響範囲が大きい場合は、関連するAzure RBACやアプリケーション権限を一時的に外し、不正なトークンが発行されてもリソースへ到達できない状態にします。
続いて、次の期間を対象に調査します。
- 元のワークロードを削除、改名、移管した日時
- 古い名前が再利用可能になった日時
- 別主体が名前を取得した日時
- 古いフェデレーション資格情報を削除した日時
Microsoft Entraのサービスプリンシパルサインイン、Azure Activity Log、対象リソースの監査ログ、外部IDプロバイダーの操作履歴、CI/CDの実行履歴を突き合わせます。
フェデレーションでは共有シークレットを使わないため、シークレットのローテーションだけでは解決しません。必要なのは、古い信頼条件の削除、不変subjectへの再構成、権限の見直しです。
可変OIDC subjectへの対応を今日から始める
可変OIDC subjectの問題は、認証設定を作成した時点では表面化しないことがあります。リポジトリやプロジェクトの削除、改名、移管から時間が経過し、同じ名前が別主体へ割り当てられた時に初めてリスクが顕在化します。
まず実施すべきなのは、次の3点です。
- Microsoft Entra上のフェデレーション資格情報を一覧化する
- パス、名前、ユーザー名を含むsubjectを抽出し、不変性を確認する
- 不変IDを使う新しい資格情報へ移行し、古い資格情報を削除する
あわせて、ワークロードの削除や移管とフェデレーション資格情報の削除を同じ運用手順に組み込みます。CI/CD環境だけを削除し、Microsoft Entra側の信頼設定を残す運用をなくすことが、dangling federated identity credentialの防止につながります。
Microsoft Entra Workload IDを安全に運用するうえでは、シークレットをなくすことだけでなく、「そのsubjectが将来も同じ主体を表し続けるか」まで確認することが重要です。
コメント