Microsoft Entra ID audit logsの新機能でサービスプリンシパル監視を強化する方法

Microsoft Entra ID audit logs でサービスプリンシパルの作成を監視しているなら、2026年4月時点の更新は見逃せません。結論から言うと、新しい監査ログの詳細項目を使うことで、「Microsoft 365 や Azure 側の正当な自動作成」と「ユーザー・アプリ・外部テナント起点の要調査イベント」を切り分けやすくなります。

これまで「Add service principal」のアラートは、必要な作成なのか、不審なアプリ登録や同意攻撃の兆候なのかを判断するために追加調査が必要でした。今回の更新では、ServicePrincipalProvisioningType、SubscribedSkus、AppOwnerOrganizationId といった情報が監査ログに出るようになり、Identity admins や cloud security teams がアプリガバナンスとアラートトリアージを現実的に改善しやすくなっています。Microsoft の 2026年3月分の Entra 更新情報でも、Service Principal creation audit logs for alerting & monitoring が新機能として紹介されています。(TECHCOMMUNITY.MICROSOFT.COM)

Microsoft Entra ID audit logs で何が変わったのか

Microsoft Entra ID audit logs は、アプリケーション、グループ、ユーザー、ライセンスなど、テナント内で発生した変更を確認するための監査ログです。監査ログでは、誰が、いつ、どのサービスやリソースに対して、どのような変更を行ったかを確認できます。(Microsoft Learn)

今回の注目点は、サービスプリンシパル作成イベントである Add service principal の詳細が増えたことです。Microsoft Learn では、対象イベントは次のように整理されています。(Microsoft Learn)

項目	内容
Service	Core Directory
Category	ApplicationManagement
Activity	Add service principal
確認場所	Microsoft Entra admin center の Monitoring & health > Audit logs
詳細項目の表示場所	イベントを選択後、Additional details を展開

これにより、「サービスプリンシパルが作成された」という事実だけでなく、「なぜ作成されたのか」「どの仕組みが作成を引き起こしたのか」「アプリ登録の所有元テナントはどこか」まで見やすくなりました。

新しく確認すべき3つの監査ログ項目

今回の更新で実務上重要なのは、次の3項目です。

監査ログ項目	何が分かるか	実務での使いどころ
`ServicePrincipalProvisioningType`	サービスプリンシパルがどの経路で作成されたか	Microsoft 起点の自動作成か、テナント内のユーザー・アプリ起点かを一次判定する
`SubscribedSkus`	サービスプリンシパル作成に関係した SKU やサービスプラン	Microsoft 365 E5 など、契約・サービス有効化に伴う作成かを確認する
`AppOwnerOrganizationId`	アプリ登録を所有するホームテナント ID	自社テナント、Microsoft 所有、外部・パートナー所有のアプリを切り分ける

特に ServicePrincipalProvisioningType は、トリアージの最初に見るべき項目です。Microsoft の説明では、defaultMicrosoft、subscription、managerApplications、AzureResourceProvider、ManagedServiceIdentity、Other などの値によって、作成経路を分類できます。Other には、ユーザー操作、委任権限で動くアプリ、アプリケーション権限を持つ自動化処理など、テナント側の操作が含まれ得ます。(Microsoft Learn)

AppOwnerOrganizationId も重要です。この値が自社テナント ID と一致すれば自社登録アプリ、Microsoft services tenant ID と一致すれば Microsoft 所有アプリ、異なる外部テナントであればパートナーや外部アプリの可能性があります。追加の Microsoft Graph 呼び出しを減らしながら、作成直後の初動判断に使える点が大きな利点です。(Microsoft Learn)

なぜサービスプリンシパル作成の監視が重要なのか

サービスプリンシパルは、アプリケーションや自動化処理が Microsoft Entra ID 上で権限を持つための重要なオブジェクトです。正しく管理されていれば、CI/CD、Azure リソース連携、SaaS 連携、バックグラウンド処理を安全に動かす基盤になります。

一方で、悪用されると厄介です。攻撃者が不正なアプリ同意を誘導したり、過剰なアプリケーション権限を持つサービスプリンシパルを作成したりすると、ユーザーのパスワードを直接盗まなくても、メール、ファイル、ディレクトリ情報、クラウドリソースへ継続的にアクセスできる可能性があります。Microsoft のインシデント対応ガイドでも、同意を悪用した攻撃では、攻撃者がアプリに権限を与えさせ、永続化やデータアクセスにつなげるリスクが説明されています。(Microsoft Learn)

つまり、「新しいサービスプリンシパルが作成された」というイベントは、単なる構成変更ではありません。テナント内のアプリ権限、外部連携、データアクセス経路が増えた可能性を示すシグナルです。

アラートトリアージでの判断基準

新しい監査ログ項目を使うと、すべての Add service principal を同じ重大度で扱う必要がなくなります。以下のように、初期分類を決めておくと SOC や ID 管理チームの負荷を減らせます。

状況	初期判断	推奨アクション
`ServicePrincipalProvisioningType` が `subscription`	Microsoft 365 やサービスプランに伴う自動作成の可能性	`SubscribedSkus` を確認し、契約・サービス有効化のタイミングと照合する
`ServicePrincipalProvisioningType` が `ManagedServiceIdentity`	Azure リソースのマネージド ID 作成の可能性	対応する Azure リソース作成、リソースグループ、変更申請を確認する
`ServicePrincipalProvisioningType` が `AzureResourceProvider`	Azure サービスのオンボーディングに伴う作成の可能性	どの Azure サービス導入が引き金かを確認する
`ServicePrincipalProvisioningType` が `Other`	ユーザー、アプリ、自動化処理による直接作成の可能性	作成者、対象アプリ、権限、所有者、資格情報を優先調査する
`AppOwnerOrganizationId` が外部テナント	外部アプリまたはパートナーアプリの可能性	発行元、同意履歴、API 権限、業務上の必要性を確認する
Microsoft 起点に見えるが同時に高権限同意がある	正常とは限らない	アプリ権限、Consent to application、サインインログと相関分析する

ポイントは、Microsoft 起点の値を「安全」と断定しないことです。優先度を下げる材料にはなりますが、組織の変更予定、対象アプリ、権限、利用状況と合わせて判断する必要があります。

app governance での活用方法

Microsoft Defender for Cloud Apps の app governance は、Microsoft Entra ID、Google、Salesforce などに登録された OAuth 対応アプリの可視化、ポリシー管理、検出、修復を支援する機能です。アプリがどのデータへアクセスしているか、どの権限を持つか、異常なアプリ活動がないかを確認できます。(Microsoft Learn)

今回の Microsoft Entra ID audit logs の強化は、app governance を置き換えるものではありません。むしろ、アプリガバナンスの「入口情報」を補強するものです。

たとえば、app governance ではアプリの権限や利用状況を確認できます。一方、監査ログの新項目では、そのサービスプリンシパルが作られた背景を確認できます。

観点	app governance	Microsoft Entra ID audit logs の新項目
目的	アプリの権限、活動、リスクを継続監視する	サービスプリンシパル作成時の背景を把握する
強い領域	OAuth アプリの可視化、ポリシー、アラート、修復	作成経路、SKU、所有元テナントの確認
実務での使い方	リスクのあるアプリを継続的に管理する	新規作成アラートの優先度を決める
組み合わせ例	高権限アプリを検出する	そのアプリが誰・何によって作成されたかを追う

実務では、次のような流れが効果的です。

Add service principal の監査ログで新規作成を検出する
ServicePrincipalProvisioningType で作成経路を分類する
AppOwnerOrganizationId で自社・Microsoft・外部を切り分ける
app governance で権限、データアクセス、アプリ活動を確認する
Microsoft Sentinel や Defender XDR のアラートと相関させる

この流れにすると、「新しいサービスプリンシパルができたから全部調査する」状態から、「不審な経路・外部所有・高権限のものを優先する」運用に変えられます。

Microsoft Sentinel や Log Analytics で確認するサンプル

Microsoft Learn では、これらの新しいプロパティは Log Analytics や Microsoft Sentinel に送信した場合、AuditLogs テーブルの AdditionalDetails JSON で利用できると説明されています。(Microsoft Learn)

まずは、次のようなクエリで Add service principal イベントを抽出し、新しい詳細項目が取得できるか確認します。環境によって列名や格納形式が異なる場合があるため、最初は短い期間で検証してください。

AuditLogs
| where TimeGenerated > ago(30d)
| where ActivityDisplayName == "Add service principal"
| mv-expand detail = AdditionalDetails
| extend detailKey = tostring(detail.key)
| extend detailValue = tostring(detail.value)
| summarize
    ServicePrincipalProvisioningType = take_anyif(detailValue, detailKey == "ServicePrincipalProvisioningType"),
    AppOwnerOrganizationId = take_anyif(detailValue, detailKey == "AppOwnerOrganizationId"),
    SubscribedSkus = take_anyif(detailValue, detailKey == "SubscribedSkus"),
    InitiatedBy = take_any(InitiatedBy),
    TargetResources = take_any(TargetResources)
  by TimeGenerated, CorrelationId, ActivityDisplayName, Result
| order by TimeGenerated desc

次に、要調査イベントを絞り込みます。たとえば、Other や外部テナント所有のアプリを重点的に見る場合は、次のような条件を追加します。

AuditLogs
| where TimeGenerated > ago(30d)
| where ActivityDisplayName == "Add service principal"
| mv-expand detail = AdditionalDetails
| extend detailKey = tostring(detail.key)
| extend detailValue = tostring(detail.value)
| summarize
    ServicePrincipalProvisioningType = take_anyif(detailValue, detailKey == "ServicePrincipalProvisioningType"),
    AppOwnerOrganizationId = take_anyif(detailValue, detailKey == "AppOwnerOrganizationId"),
    InitiatedBy = take_any(InitiatedBy),
    TargetResources = take_any(TargetResources)
  by TimeGenerated, CorrelationId, ActivityDisplayName, Result
| where ServicePrincipalProvisioningType == "Other"
    or AppOwnerOrganizationId !in ("<自社テナントID>", "f8cdef31-a31e-4b4a-93e4-5f571e91255a")
| order by TimeGenerated desc

このクエリは、そのまま完成形の検知ルールにするよりも、まずはベースライン作成に使うのがおすすめです。自社の CI/CD、Azure リソース作成、正規 SaaS 連携、パートナー運用がどのような値で出るかを確認してから、除外条件や重大度を調整してください。

実務でのトリアージ手順

アラートが上がったら、次の順番で確認すると判断が速くなります。

手順	確認内容	判断ポイント
1	`ServicePrincipalProvisioningType` を確認	Microsoft 起点か、テナント内の直接操作か
2	`initiatedBy` を確認	ユーザー、アプリ、自動化アカウントのどれが起点か
3	`AppOwnerOrganizationId` を確認	自社、Microsoft、外部テナントのどれか
4	`SubscribedSkus` を確認	契約・サービスプラン由来の JIT 作成か
5	対象サービスプリンシパルの権限を確認	高権限 API、アプリケーション権限、ディレクトリ書き込み権限がないか
6	所有者と資格情報を確認	不明な owner、長期シークレット、証明書、フェデレーション資格情報がないか
7	関連ログを確認	Consent to application、Add app role assignment、サインイン、Graph API 操作と相関するか
8	app governance で確認	データアクセス、異常なアプリ活動、ポリシー違反がないか

特に Other かつ作成者が一般ユーザー、または想定外のアプリである場合は、早めに権限と同意状況を確認します。高権限のアプリケーション権限、たとえばディレクトリ、メール、ファイル、ロール管理に関わる権限が付与されている場合は、単なる棚卸しではなくインシデント調査として扱うべきです。

Microsoft のアプリ同意攻撃のガイドでは、疑わしいアプリを見つけた場合、単に削除するよりも、戻ってくる可能性を抑えるために無効化を検討する考え方が示されています。復旧や封じ込めの判断は、組織のインシデント対応手順に沿って進めてください。(Microsoft Learn)

アラートルールを改善する具体例

これまでの検知ルールが「Add service principal が発生したら通知する」だけだった場合、ノイズが多くなりがちです。今回の新項目を使うと、次のように分けられます。

情報通知に寄せるイベント

次のようなイベントは、まずは情報通知または低重大度に分類できます。

ServicePrincipalProvisioningType が subscription
SubscribedSkus が既知の Microsoft 365 SKU と一致する
ManagedServiceIdentity で、対応する Azure リソース作成が変更申請に記録されている
defaultMicrosoft で、既知の Microsoft ファーストパーティアプリに該当する

ただし、これらを完全に無視するのは避けます。新しい Microsoft サービスの有効化、ライセンス追加、Azure リソース作成は、攻撃ではなくてもガバナンス上の変更です。月次レビューや棚卸しには残しておくとよいでしょう。

中重大度で確認するイベント

次のようなイベントは、当日中の確認対象にします。

AppOwnerOrganizationId が承認済みパートナーのテナントだが、作成タイミングが不明
Other だが、作成者が開発チームや自動化アプリなど既知の主体
新しい SaaS 導入と一致するが、管理者同意の記録が未確認
owner が設定されていない、または個人アカウントに偏っている

この段階では、いきなり封じ込めるよりも、変更申請、アプリ所有者、必要権限、データアクセス範囲を確認するのが現実的です。

高重大度で調査するイベント

次のようなイベントは、インシデント調査に近い扱いにします。

ServicePrincipalProvisioningType が Other で、起点ユーザーやアプリが不明
AppOwnerOrganizationId が外部テナントで、業務上の説明がない
作成直後に高権限の API 権限や app role assignment が付与されている
管理者アカウントの侵害、同意設定変更、怪しいサインインと時間帯が近い
長期シークレットや不明な証明書が追加されている
作成後すぐにメール、ファイル、ディレクトリ、Azure リソースへアクセスしている

この分類をルール化しておくと、SOC は「何を見ればよいか」で迷いにくくなります。Identity 管理者も、アプリ所有者へ確認すべき内容をテンプレート化できます。

グローバルテナントでの注意点

複数国・複数リージョンで Microsoft Entra ID を運用している場合は、単純な時間帯や作成者だけで不審判定しないことが重要です。

たとえば、日本時間の深夜に Add service principal が発生しても、北米や欧州の開発チームにとっては通常の作業時間かもしれません。逆に、各国の祝日や変更凍結期間に発生した作成は、通常よりも注意して見るべきです。

グローバル運用では、次の情報を台帳化しておくとトリアージが安定します。

管理項目	例
自社テナント ID	本番、検証、買収企業、関連会社のテナント
承認済み外部テナント ID	運用委託先、SaaS ベンダー、共同開発パートナー
Microsoft 所有アプリの扱い	既知の Microsoft ファーストパーティアプリの分類ルール
変更時間帯	地域別の通常作業時間、変更凍結期間
正規の作成経路	CI/CD、IaC、Azure Portal、社内申請システム
連絡先	アプリ所有者、ID 管理者、SOC、クラウド基盤チーム

この台帳がないと、せっかく監査ログが詳しくなっても、「外部テナントだから怪しい」「深夜だから怪しい」といった粗い判断になりがちです。

失敗しやすいポイント

Microsoft 起点のイベントをすべて除外してしまう

defaultMicrosoft や subscription は、多くの場合、正当な Microsoft サービス利用に伴う作成を理解する助けになります。しかし、ガバナンス上は「新しいアプリ ID がテナントに現れた」という事実に変わりはありません。

完全に除外するのではなく、低重大度の記録として残し、月次レビューや構成変更レビューで確認できるようにしておく方が安全です。

`Other` をすべて危険と見なす

Other は要確認ですが、必ずしも悪意を意味するわけではありません。社内の自動化、開発者のポータル操作、Graph API を使ったプロビジョニングなど、正当な業務でも出る可能性があります。

重要なのは、Other を見つけたら「誰が」「何のために」「どの権限で」「どのデータにアクセスするのか」を確認することです。

`SubscribedSkus` だけで判断を終える

SubscribedSkus は、サブスクリプションやサービスプランに由来する JIT 作成を理解するための出発点です。Microsoft Learn でも、単一のサービスプリンシパルが複数のサービスプランや SKU と関連する可能性があり、調査の起点として使うものと説明されています。(Microsoft Learn)

SKU が見えたから安全と決めるのではなく、必要に応じて Microsoft Graph の /subscribedSkus やライセンス管理情報と照合しましょう。

ポータル表示と Log Analytics の列を混同する

Microsoft Entra admin center では Category や Activity で絞り込めますが、Log Analytics の AuditLogs テーブルでは ActivityDisplayName、AdditionalDetails、InitiatedBy、TargetResources などの列を使って確認します。AuditLogs テーブルのスキーマでは、ActivityDisplayName は操作名、AdditionalDetails は追加詳細、TargetResources は変更対象リソースの情報として定義されています。(Microsoft Learn)

検知ルール化する前に、自社ワークスペースで実際のレコードを数件開き、値の入り方を確認してください。

今すぐやるべき設定・運用見直し

今回の更新を活かすには、単に「新しい項目が増えた」と理解するだけでは不十分です。次の順番で運用に反映すると効果が出やすくなります。

優先度	やること	目的
高	直近30日程度の `Add service principal` を抽出する	自社テナントの通常パターンを把握する
高	`ServicePrincipalProvisioningType` 別に件数を集計する	Microsoft 起点とテナント起点の比率を知る
高	自社・Microsoft・承認済み外部テナント ID の allowlist を作る	外部所有アプリの判定精度を上げる
中	Sentinel ルールに新項目を追加する	誤検知を減らし、重大度を分ける
中	app governance のアプリ一覧と突き合わせる	作成背景と現在の権限・活動をつなげる
中	アプリ所有者確認フローを整備する	不明アプリの放置を防ぐ
低	月次レビュー用のレポートを作る	サービスプリンシパルの増加傾向を可視化する

最初から完璧な自動判定を作る必要はありません。まずは Add service principal の一覧に3つの新項目を加え、SOC と ID 管理者が同じ画面を見て会話できる状態を作ることが第一歩です。

まとめ：監査ログの詳細化は「アラート削減」ではなく「判断の高速化」に使う

Microsoft Entra ID audit logs の今回の更新は、サービスプリンシパル作成イベントをより実務的に扱うための改善です。ServicePrincipalProvisioningType で作成経路を見分け、SubscribedSkus でサブスクリプション由来の作成を確認し、AppOwnerOrganizationId でアプリの所有元を判断できます。

この情報を使えば、すべての新規サービスプリンシパルを同じ重さで扱う必要はありません。Microsoft 起点の想定内イベントは低重大度で記録し、Other、外部テナント所有、高権限付与、不審な同意イベントと重なるものに調査リソースを集中できます。

次にやるべきことは明確です。まず直近の Add service principal を抽出し、3つの新項目が自社環境でどう記録されているかを確認してください。そのうえで、Microsoft Sentinel、Log Analytics、app governance、既存の変更管理プロセスに組み込み、サービスプリンシパルの作成を「気づく」だけでなく「すばやく判断できる」状態にしましょう。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。