はじめに
インシデント対応中、「このサービスプリンシパルの認証を今すぐ止めたい」と思ったことはないでしょうか。パスワードをリセットしても、アカウントを無効化しても、すでに発行されたアクセストークンは有効期限が切れるまで機能し続けます。通常の設定では 60〜90 分。この時間が攻撃者に与える猶予です。
2026年8月25日、Microsoft が「CAE(Continuous Access Evaluation)を使ったサービスプリンシパルベアラートークンの即時失効」に関する技術ブログを公開しました。この機能を使えば、発行済みトークンを有効期限前に無効化できます。本記事では、情シス担当者が実際に設定・検証できるレベルで手順を解説します。
1. ベアラートークンが抱えるリスク
サービスプリンシパルの認証には「クライアントクレデンシャルフロー」が使われ、結果としてベアラートークン(アクセストークン)が発行されます。
ベアラートークンの性質として、持っている者が誰でも使えます。署名検証は行われますが、発行済みトークンを「途中でキャンセルする」仕組みは、CAE なしでは存在しません。
通常のトークンでできないこと:
- パスワード変更後のトークン即時失効
- サービスプリンシパル無効化後のトークン即時失効
- リスク検知後のトークン即時失効
これが、クレデンシャル流出インシデントで「対処したはずなのに 1 時間近く悪用が続いた」という状況を生む原因です。

2. CAE とは何か
CAE(Continuous Access Evaluation)は、認証済みセッションをリアルタイムで再評価する仕組みです。クライアントとリソースサーバー(Microsoft Graph など)の両方が CAE に対応することで、ポリシー変更やリスクイベントを即座に反映できます。
これまでユーザー向けに提供されていた機能が、ワークロード ID(サービスプリンシパル)にも対応しました。
CAE を有効にすると起きること:
| 変化 | 内容 |
|---|---|
| トークン有効期限の延長 | 60〜90 分 → 約 24 時間 |
| 即時失効の有効化 | 特定イベント発生時に リアルタイムで失効 |
有効期限が延びることに不安を感じるかもしれませんが、動的な失効制御と組み合わせることで、静的な短期トークンより堅牢な運用が可能になります。

3. CAE 対応トークンを取得する方法
CAE を有効にするには、認証リクエストに xms_cc クレーム(値: cp1) を含める必要があります。これはクライアント側の実装変更が必要です。既存のサービスプリンシパルに「後から有効化する」設定はなく、認証コードを修正して再発行したトークンから CAE が適用されます。
PowerShell での実装例:
function Connect-And-GetToken {
param(
[string]$TenantId,
[string]$ClientId,
[string]$ClientSecret
)
$body = @{
grant_type = "client_credentials"
client_id = $ClientId
client_secret = $ClientSecret
scope = "https://graph.microsoft.com/.default"
claims = '{"access_token":{"xms_cc":{"values":["cp1"]}}}'
}
$response = Invoke-RestMethod -Method POST `
-Uri "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token" `
-Body $body
return $response.access_token
}
取得したトークンを jwt.ms でデコードすると、2点確認できます:
xms_ccクレームにcp1が含まれているexp(有効期限)が発行から約 24 時間後になっている
4. 失効イベントの種類
CAE 対応トークンが即時失効するタイミングは、現時点で 3 種類です:
| 失効イベント | 内容 | 必要なライセンス |
|---|---|---|
| サービスプリンシパルが高リスク判定 | Identity Protection が high risk と判断 | Workload Identity Premium |
| サービスプリンシパルの直接無効化 | 管理者が SP を直接 disabled に設定 | 不要 |
| サービスプリンシパルの削除 | SP を削除する | 不要 |
注意: 登録済みアプリ(App Registration)を無効化しても、この失効イベントはトリガーされません。サービスプリンシパル自体を直接操作する必要があります。
5. 実際にテストしてみる
テスト 1: 高リスクシミュレーション
別のサービスプリンシパルに IdentityRiskyServicePrincipal.ReadWrite.All 権限を付与した上で実行します:
Connect-MgGraph
Confirm-MgRiskyServicePrincipalCompromised -ServicePrincipalIds @("{対象SPのオブジェクトID}")
数分後、Entra ポータルの「Identity Protection > リスクのあるワークロード ID」に high risk として表示されます。この状態で既存のアクセストークンを使うと 401 Unauthorized が返ります。
リスクを解除する場合:
Invoke-MgDismissRiskyServicePrincipal -ServicePrincipalIds @("{対象SPのオブジェクトID}")
リスクを解除しても、失効したトークンは戻りません。再認証が必要です。

テスト 2: サービスプリンシパルの直接無効化(推奨キルスイッチ)
Graph Explorer または PowerShell でサービスプリンシパルを直接無効化します:
Update-MgServicePrincipal -ServicePrincipalId "{オブジェクトID}" -AccountEnabled:$false
こちらは Workload Identity Premium ライセンス不要で実行でき、即座に 401 Unauthorized が返ります。インシデント対応時の現実的なキルスイッチです。
6. Entra サインインログで CAE を確認する
CAE 対応トークンが発行されたかどうかは、Entra ポータルのサービスプリンシパルサインインログで確認できます。
確認手順:
- Entra ポータル > 「サインイン ログ」> 「サービス プリンシパルのサインイン」
- 対象のサインインイベントを開く
- 「基本情報」タブで「継続的アクセス評価: Yes」が表示されていれば CAE 有効
「追加の詳細」タブには、セッションのライフタイム情報も含まれています。

7. 高リスク失効には Conditional Access が必須
高リスクによる失効を使う場合、必ず Workload Identities の条件付きアクセスポリシーで「高リスク時に認証をブロック」する設定を追加してください。
理由は単純です。高リスクでトークンが失効しても、攻撃者がクライアント ID とシークレットを持っている場合、再認証して新しいトークンを取得できてしまいます。失効と再取得のイタチごっこになります。
Conditional Access ポリシーで認証自体をブロックすることで、初めて「高リスク = 完全遮断」が成立します。
ライセンス要件: Conditional Access for Workload Identities には Workload Identity Premium ライセンスが必要です。
一方、サービスプリンシパルの直接無効化はライセンス不要で再認証もブロックできるため、まずはこちらをインシデント対応フローに組み込むのが現実的です。
8. まとめ
CAE のワークロード ID 対応により、サービスプリンシパルのアクセストークンをインシデント発生直後に失効させることができます。
設定・運用のポイント:
xms_cc: cp1クレームを認証リクエストに含める — クライアントコードの変更が必要。このクレームがなければ CAE は機能しない- キルスイッチとして最も確実なのはサービスプリンシパルの直接無効化 — ライセンス不要、即時効果あり
- 高リスク自動失効を使うなら Conditional Access と組み合わせる — 再認証もブロックしないと意味がない
- Entra サインインログで CAE が有効かどうか確認できる — 「継続的アクセス評価: Yes」が目印
ワークロード ID は特権を持つことが多く、攻撃者にとって魅力的なターゲットです。CAE の対応を機に、自社のサービスプリンシパルの認証コードを見直してみてください。
ワークロード ID(サービスプリンシパル)はユーザーアカウントと比べて見落とされがちですが、特権アクセスを持つケースが多く、侵害された際の影響は深刻です。CAE の設定やワークロード ID の棚卸し・リスク評価は、YJK がサポートできます。「どのサービスプリンシパルに何の権限があるか把握できていない」という状況から一緒に整理しましょう。