Entra ID でサービスプリンシパルを効果的に管理する方法

By Mirko Peters · 2026-03-22 · Updated 2026-03-24

Microsoft Entra ID でサービスプリンシパルを保護し、ID管理を強化します。テナント内のアプリケーションオブジェクトとサービスプリンシパルについて解説します。

Automatically translated with AI from the original post. Read the English original

Entra ID におけるサービスプリンシパルとアプリの登録の管理は、セキュリティとアクセス制御を維持するうえで極めて重要です。適切なガバナンスは、権限昇格やテナントの侵害などの重大なセキュリティインシデントの防止に役立ちます。たとえば、管理が不十分なサービスプリンシパルは、攻撃者に悪用されて管理者のパスワードをリセットされ、重要なシステムへの不正アクセスを許す可能性があります。適切な管理手法を実践することで、これらのリスクを軽減し、環境の安全性を保つことができます。主な手順は、サービスプリンシパルの理解、適切なアクセス許可の割り当て、アクセスポリシーの定期的な見直しです。

Entra ID でサービスプリンシパルを効果的に管理する方法を学んでいるなら、これから紹介する知られていない事実が、自動化された ID の保護と運用の方法を変えるかもしれません。

1. サービスプリンシパルはアプリオブジェクトとは別物です: アプリケーションオブジェクトはグローバルなアプリケーションの定義であり、サービスプリンシパルはテナント内のローカルな ID です。1つのアプリオブジェクトに対して、複数のテナントにまたがる複数のサービスプリンシパルを持つことができます。
2. 有効期限のない資格情報を持つことがあります: Entra ID では、設計上または設定ミスにより、有効期限のないクライアントシークレットや証明書を作成できます。手動でローテーションしないと、長期的なリスクが高まります。
3. マネージド ID は内部でサービスプリンシパルを使用します: システム割り当てとユーザー割り当てのどちらのマネージド ID も、ディレクトリ内ではサービスプリンシパルとして表現されます。そのため、RBAC や条件付きアクセスポリシーをこれらに適用できます。
4. サービスプリンシパルは条件付きアクセスで利用できます: 条件付きアクセスは主にユーザーを対象としていますが、アプリケーションのコンテキストを評価でき、特にアプリケーション認証コンテキストと組み合わせた場合、一部のポリシーはサービスプリンシパルに影響を与えることがあります。
5. 委任されたアクセス許可とアプリケーションのアクセス許可を同時にサポートします: 1つのサービスプリンシパルが、委任されたアクセス許可(ユーザーに代わって実行)とアプリケーションのアクセス許可(アプリのみで実行)の両方を保持できます。そのため、最小権限の適用は複雑になります。
6. サインインログには非対話型のアプリ認証が含まれます: Entra ID はサービスプリンシパルのサインインを記録するため、異常なアプリの動作を検出できます。しかし、ユーザーのサインインと比べて見落とされがちです。
7. 同意と権利の管理により、見えないアクセス経路が生じることがあります: 管理者の同意や権利の管理によって付与されたエンタープライズアプリケーションやサービスプリンシパルは、間接的なアクセス経路を生み出す可能性があります。これらは、権限と権利の徹底的な見直しを行わないと発見が困難です。

重要なポイント

• Entra ID におけるアプリケーションの登録とサービスプリンシパルの違いを理解します。
• サービスプリンシパルの管理を始める前に、適切なアクセス許可があることを確認し、作業の妨げにならないようにします。
• Entra ID でアプリケーションを登録するための明確な手順に従い、必要な詳細情報を入力します。
• アプリケーションのセキュリティを強化するために、複数の認証方法を使用します。
• サービスプリンシパルに適切なアクセス許可を割り当てるため、ロールベースのアクセス制御(RBAC)を実装します。
• アクセスポリシーを定期的に見直し、セキュリティのベストプラクティスに沿っていることを確認します。
• 監査を実施して変更を監視し、不正アクセスや不審な操作を検出します。
• 最小権限の原則に従い、サービスプリンシパルには必要なアクセス許可のみを付与します。

Entra ID 管理の前提条件

サービスプリンシパルの理解

Entra ID でサービスプリンシパルを管理する前に、いくつかの基本的な概念を理解しておく必要があります。以下に、押さえておくべき主要なポイントを示します。

• アプリケーションの登録(App)は、Entra ID においてアプリケーションを表す、グローバルに一意なオブジェクトです。
• サービスプリンシパル(SP)は、単一のテナント内における、そのアプリケーションオブジェクトの特定のインスタンスです。
• アプリの登録を行うと、同じテナント内にサービス プリンシパルが自動的に作成されます。
• サービス プリンシパルには、アプリケーション オブジェクトとは別に、独自の資格情報とアクセス許可があります。
• ユーザーの作成など、テナント内で行われる操作は、サービス プリンシパルによって実行されます。

Entra ID ポータルは分かりにくい場合があります。サービス プリンシパルは「エンタープライズ アプリケーション」に表示され、「サービス プリンシパル」という用語が使われることはほとんどありません。そのため、アプリの登録とサービス プリンシパルの関係について誤解が生じやすくなります。

必要なアクセス許可

サービス プリンシパルを効果的に管理するには、適切なアクセス許可が必要です。主な前提条件は次のとおりです。

これらのアクセス許可があれば、支障なく必要な操作を実行できます。アプリの登録やロールの割り当てを行う前に、必ずアカウントに必要なアクセス許可があることを確認してください。

これらの前提条件を理解しておくと、Entra ID でサービス プリンシパルを管理するための確かな土台になります。この知識は、アクセス管理の複雑さに対処し、組織のセキュリティ態勢を高めるのに役立ちます。

Entra ID でのアプリケーションの登録

アプリケーションを登録する手順

Entra ID でのアプリケーションの登録は簡単な作業です。以下の手順に従って始めてください。

1. Entra ID ポータルにサインインする: Microsoft Entra アカウントを使用してポータルにアクセスします。
2. アプリの登録に移動する: 左側のメニューで「アプリの登録」を選択します。
3. 「新規登録」をクリックする: このオプションで新しいアプリケーションを作成できます。
4. アプリケーションの詳細を入力する:
   • 名前: アプリケーションの一意の名前を指定します。
   • サポートされるアカウントの種類: アプリケーションを使用できるユーザーを選択します(例: この組織のディレクトリのみのアカウント)。
   • リダイレクト URI: 認証後にユーザーをリダイレクトする URI を指定します。Web アプリケーションでは特に重要です。
5. 確認して登録する: 必要な情報を入力したら、「登録」をクリックしてアプリケーションを作成します。

登録後、Free エディションでは 1 つのテナントに最大 50,000 件の Microsoft Entra リソースを作成できます。ドメインを検証すると、この上限は 300,000 件まで増やせます。また、パスワード ベースのシングル サインオンを使用するアプリは、最大 48 個まで資格情報を構成できます。

アプリケーション設定の構成

アプリケーションを登録したら、セキュリティと機能を最適化するために設定を構成する必要があります。以下は従うべきベスト プラクティスです。

1. 複数の Entra ID 認証方法を構成する: 多要素認証(MFA)やパスワードレス認証などのさまざまな認証方法を使用して、セキュリティを強化します。
2. Entra ID グループを使用してアクセス許可を割り当てる: ユーザー グループを作成して、アクセス制御を効果的に管理します。これにより、ユーザーには必要なアクセス許可のみが付与されます。
3. 条件付きアクセス ポリシー (CAP) を使用する: CAP を実装して、リソースへのアクセス条件を定義します。細かな制御によって、セキュリティがさらに一段強化されます。

さらに、アプリの棚卸しも検討してください。Entra に接続されているすべてのアプリを特定し、一覧化して効果的に管理します。各アプリに割り当てられたアクセス許可を定期的に評価し、セキュリティ戦略の判断材料にしてください。未使用のアプリは削除し、攻撃対象領域を減らします。

これらの手順とベスト プラクティスに従うことで、アプリケーションが Entra ID 内で適切に構成され、安全に保たれていることを確認できます。

サービス プリンシパルへのロールの割り当て

RBAC の概要

ロールベースのアクセス制御 (RBAC) は、Entra ID における重要な機能です。組織内のどのユーザーがどのリソースにアクセスできるかを管理するのに役立ちます。RBAC を使うと、サービス プリンシパルにロールを割り当てられるため、セキュリティを損なうことなく、タスクの実行に必要な適切なアクセス許可を与えられます。

Entra ID には、2 種類のロール定義があります。

• 組み込みロール: 固定のアクセス許可セットを持っています。変更はできませんが、一般的なシナリオを網羅しています。
• カスタム ロール: 特定の要件に合わせてアクセス許可を調整できます。カスタム ロールの作成は、ロールの定義と割り当ての 2 段階の手順で行います。

これら 2 種類のロールを理解すると、アプリケーションに適したアプローチを選択しやすくなります。RBAC の詳細については、ロールベースのアクセス制御の概要をご覧ください。

ロールの割り当て

サービス プリンシパルへのロールの割り当ては、効果的な管理に欠かせません。ロールを正しく割り当てるには、次の手順に従ってください。

1. ロールの割り当てを作成する: Microsoft Entra 管理センター、Microsoft Graph PowerShell、または Microsoft Graph API を使用します。この作業には Azure CLI はサポートされていない点にご注意ください。
2. アプリケーションを登録する: Microsoft Entra アプリを登録し、Azure portal でサービス プリンシパルを作成済みであることを確認します。
3. 適切なロールを選択する: 利用可能なロールを確認し、アプリケーションに必要なアクセス許可を提供するロールを特定します。

ロールの割り当てプロセスを簡単にまとめた参照表は次のとおりです。

これらの手順に従うことで、サービス プリンシパルが機能を果たすために適切なアクセス権を、安全に持つことを確認できます。適切なロールの割り当ては、セキュリティを高めるだけでなく、組織内の運用の効率化にもつながります。

Entra ID の認証方法

認証の概要

Entra ID でサービス プリンシパルを管理する場合、主に 2 つの認証方法から選択できます。クライアント シークレット認証と証明書ベースの認証です。それぞれの方法には、長所と適した用途があります。

クライアント シークレット認証

クライアント シークレット認証では、クライアント シークレットと呼ばれるパスワードに似た文字列を使用します。この方法は簡単で、すぐにセットアップする必要があるアプリケーションによく使われます。ただし、クライアント シークレットはパスワードと同様に扱うことが重要です。安全に保管し、セキュリティを維持するために定期的にローテーションしてください。

• 長所:

  • 実装が容易です。
  • テストや開発環境に適しています。

• 短所:

  • 証明書ベースの認証と比べてセキュリティが低くなります。
  • 適切に管理しないと、漏えいのリスクがあります。

証明書ベースの認証

証明書ベースの認証では、デジタル証明書を使ってサービス プリンシパルを認証します。この方法はクライアント シークレットよりも安全で、運用環境での利用が推奨されます。最適なセキュリティを確保するには、認証局 (CA) が発行した信頼できる証明書を使用してください。自己署名証明書はテストには使用できますが、運用環境での使用は推奨されません。

• 長所:

  • セキュリティ レベルが高くなります。
  • 資格情報の盗難リスクを軽減します。

• 短所:

  • 設定がより複雑になります。
  • 証明書の管理が必要になります。

認証の構成

Entra ID でサービス プリンシパルの認証を構成するには、次の手順に従います。

1. Microsoft Entra 管理センターの「ホーム」ページを開きます。
2. Entra ID > アプリの登録 に移動し、対象のアプリケーションを選択します。
3. アプリの「概要」ページで「ディレクトリ (テナント) ID」の値をコピーし、アプリケーションのコードに保存します。
4. 「アプリケーション (クライアント) ID」の値をコピーし、アプリケーションのコードに保存します。
5. 証明書ベースの認証またはクライアント シークレットの認証のいずれかを選択します。認証機関が発行した信頼された証明書をアップロードすることをお勧めします。
6. 証明書を使用する場合は、Entra ID > アプリの登録 > 証明書とシークレット > 証明書のアップロード の順に移動して証明書をアップロードします。
7. クライアント シークレットを使用する場合は、Entra ID > アプリの登録 > 証明書とシークレット > クライアント シークレット > 新しいクライアント シークレット の順に移動して作成します。

これらの手順に従うことで、サービス プリンシパルが安全に認証されるようになり、必要なリソースへのアクセスを許可しつつ、セキュリティ リスクを最小限に抑えられます。

Entra ID のアクセス ポリシー

アクセス ポリシーの理解

Entra ID のアクセス ポリシーは、アプリケーションとデータを保護するうえで重要な役割を果たします。これらのポリシーは、誰が、どのリソースに、どの条件でアクセスできるかを定義します。知っておくべき主なアクセス ポリシーの種類は次のとおりです。

• リスクのあるサインインに対する MFA の要求: 疑わしいサインインが検出された場合に、ユーザーに多要素認証の完了を求めるポリシーです。
• 侵害されたアカウントのブロックまたは修復: 侵害の兆候が見られるアカウントへのアクセスを、自動的に制限するポリシーです。

これらのアクセス ポリシーを実装すると、セキュリティ体制が強化されます。潜在的な脅威への対応を自動化することで、リスクを効果的に管理できます。たとえば、条件付きアクセス ポリシーは、アクセスを許可する前に、ユーザー ID、デバイスのコンプライアンス状態、リアルタイムのリスク シグナルなどの要素を評価します。この予防的なアプローチは、セキュリティを向上させるだけでなく、組織の標準への準拠の確保にもつながります。

アクセス ポリシーの構成

Entra ID でサービス プリンシパルのアクセス ポリシーを構成するのは簡単です。次の手順に従って、ポリシーを効果的に設定してください。

1. Microsoft Entra 管理センターにサインインし、Entra ID » エンタープライズ アプリケーション に移動します。
2. 制限するサービス プリンシパルをクリックし、[管理] タブの プロパティ に移動します。
3. ユーザーがサインインできるように有効にしますか? を いいえ に設定し、[保存] をクリックして、このアプリケーションへのユーザーのサインインを無効にします。
4. 条件付きアクセス ポリシーを作成するには、Microsoft Entra 管理センターにサインインし、Entra ID » 条件付きアクセス に移動します。
5. + 新しいポリシーの作成 をクリックし、ポリシーの名前を入力します。
6. [割り当て] の下で、ユーザーまたはワークロード ID に移動します。
7. [このポリシーの対象] で ワークロード ID を選択します。[含める] の下で サービス プリンシパルの選択 をクリックし、一覧から適切なサービス プリンシパルを選択します。
8. [ターゲット リソース] セクションの [含める] で、すべてのリソース (以前の 'すべてのクラウド アプリ') を選択します。
9. [条件] セクションで、ポリシーをトリガーするタイミングを決める特定の要件を構成します。
10. [アクセス制御] の下で '許可' に移動し、アクセスをブロック を選択して、'選択' をクリックします。
11. ポリシーを有効にする を オン に設定し、'作成' をクリックして、Microsoft Entra ワークロード ID 用の条件付きアクセス ポリシーを作成します。

これらの手順に従うことで、サービス プリンシパルを厳格なアクセス制御の下で運用できます。これはリソースの保護につながるだけでなく、セキュリティとコンプライアンスのベスト プラクティスにも沿ったものです。

サービス プリンシパルのベスト プラクティス

セキュリティに関する推奨事項

Entra ID でサービス プリンシパルを保護するために、次のセキュリティに関する推奨事項に従ってください。

• セキュリティを強化するには、クライアント シークレットの代わりにクライアント証明書を使用してください。
• 証明書とシークレットを安全に管理するために、Azure Key Vault を活用してください。
• サービス プリンシパルには最小特権のアクセス制御を実装してください。つまり、タスクの実行に必要なアクセス許可のみを付与します。
• Microsoft Entra のサインイン ログを使用して、サービス プリンシパルのサインインを監視します。これにより、通常と異なるアクティビティを検出できます。
• 信頼されていない場所からのアクセスを制限するために、Conditional Access を使用してください。これにより、セキュリティの層が一つ追加されます。
• 特権レベルが適切であることを確認するために、Tier 0 ロールのメンバーシップを定期的に見直してください。これにより、重要なリソースへの不正アクセスを防げます。

これらの方法を取り入れることで、サービス プリンシパルのセキュリティを大幅に高め、不正アクセスのリスクを低減できます。

定期的な監査

サービス プリンシパルのセキュリティと整合性を維持するには、定期的な監査が欠かせません。実施すべき一般的な監査項目は次のとおりです。

定期的な監査により、サービス プリンシパルの状態を把握し続けられます。不正な変更や不審なアクティビティを早期に発見できるため、環境の安全性を維持できます。

これらのベスト プラクティスに従うことで、Entra ID におけるサービス プリンシパルを効果的に管理でき、セキュリティとコンプライアンスの両方を高められます。

まとめると、Entra ID でサービス プリンシパルを効果的に管理するには、いくつかの重要な手順とベスト プラクティスが必要です。次のことを行ってください。

• アプリケーションを適切に登録し、その設定を構成します。
• 最小特権の原則に基づいてロールを割り当てます。
• 堅牢な認証方法を実装します。
• アクセス ポリシーとアクセス許可を定期的に見直します。

継続的な管理が重要です。セルフサービスの利便性が高まるほど、アクセス管理の改善の必要性も高まります。定期的な見直しにより、アクセス権の管理を維持できます。各ゲスト アカウントには、アクセスの妥当性を継続的に確認する社内の責任者を置くべきです。これらの戦略を取り入れることで、セキュリティを強化し、サービス プリンシパルを効果的に統制できます。

このチェックリストは、Entra ID でサービス プリンシパルを効果的に管理するためのベスト プラクティスの実装に役立ちます。

• インベントリと検出: テナントおよびサブスクリプション全体のすべてのサービス プリンシパルを特定します(定期的なスキャンやレポートを作成してください)。
• アプリケーションと所有者の対応付け: 各サービス プリンシパルを、対応するアプリケーション、ビジネス オーナー、サポート担当者と関連付けます。
• アクセスの分類と用途の明確化: 各サービス プリンシパルの用途、環境(本番/開発/テスト)、必要なアクセス許可を文書化します。
• 最小特権の原則: 割り当てられたロールとアクセス許可を監査し、必要最小限まで削除または縮小します。
• マネージド ID の優先: Azure リソースについては、可能な限りアプリの登録やサービス プリンシパルをマネージド ID に置き換えます。
• 資格情報の衛生管理: 長期間有効な資格情報は避け、クライアント シークレットよりも証明書を優先し、資格情報を定期的にローテーションします。
• 資格情報ポリシーを適用する: 該当する場合は、アプリケーションの資格情報に対して条件付きアクセスと Azure AD のパスワード/シークレット ポリシーを実装します。
• 対話型利用には MFA/条件付きアクセスを要求する: 必要かつ保護されている場合を除き、対話型サインインを許可する資格情報をブロックまたは制限します。
• ジャストインタイム (JIT) または期間限定のアクセスを有効にする: 可能な限り、高い権限のロールを期間を限定してサービス プリンシパルに付与します。
• 命名規則とメタデータ: 明確な命名標準を適用し、サービス プリンシパルに環境、所有者、有効期限のメタデータをタグ付けします。
• 有効期限とライフサイクル ポリシー: シークレットと証明書に有効期限を設定し、ライフサイクル (プロビジョニング、更新、取り消し、プロビジョニング解除) を自動化します。
• 未使用のサービス プリンシパルを無効化する: 所有者による確認を経て、定義された期間内に使用されていないサービス プリンシパルを無効化または削除します。
• サインインとリスクの高い利用を監視する: 異常なサインイン、リスクの高いアクティビティ、権限昇格に対して、ログの記録とアラートを有効にします。
• ログの一元化と SIEM 連携: 監査ログ、サインイン イベント、プロビジョニングの変更を SIEM に転送し、相関分析と保持を行います。
• アクセス レビューと定期監査: 各サービス プリンシパルの必要性と所有者の承認を検証するため、定期的にアクセス レビューを実施します。
• API とアクセス許可を強化する: 範囲を限定した委任アクセス許可、または厳密に定義されたアプリ専用のスコープを使用します。
• シークレットを安全に保管する: クライアント シークレットと証明書は Azure Key Vault または同等の保管庫に保存し、保管庫へのアクセスは必要なプリンシパルのみに制限します。
• 自動修復: 侵害された、または期限切れのサービス プリンシパルを無効化し、資格情報をローテーションするための自動化プレイブックを実装します。
• ポリシーの適用: Azure AD / Entra ID の条件付きアクセス、Microsoft Entra のアクセス許可管理、Azure Policy を使用して標準を適用します。
• ドキュメントとランブック: プロビジョニング、緊急時の資格情報ローテーション、プロビジョニング解除の手順に関するランブックを整備します。
• アクセスのテストとフェイルオーバー: 資格情報のローテーションや構成変更の後、非本番環境でアプリケーションの認証ワークフローを検証します。
• 安全なオンボーディング/オフボーディング: サービス プリンシパルのプロビジョニングとプロビジョニング解除を CI/CD と変更管理のプロセスに組み込みます。
• 自動化向けの最小特権サービス アカウント: 自動化タスクには専用のサービス プリンシパルを使用し、権限の範囲を厳密に限定して、所有者を明確に定めます。
• 外部/ゲスト アクセスの確認: 外部アプリが作成したサービス プリンシパルを監査し、セキュリティ レビューの後にのみアクセスを許可します。
• コンプライアンスの証跡を保持する: 社内外の要件への準拠を示すため、承認、レビュー、ローテーションの記録を残します。
• チームと所有者への教育: アプリケーションの所有者と開発者に対し、Entra ID でサービス プリンシパルを効果的に管理する方法と、安全な資格情報の扱い方を教育します。

よくある質問: Microsoft Entra ID サービス プリンシパルの参考資料

Microsoft Entra ID のサービス プリンシパルとは何ですか。アプリケーション オブジェクトとどう違いますか。

Microsoft Entra ID のサービス プリンシパルは、テナントまたはディレクトリ内におけるアプリケーション インスタンスのローカルな表現です。アプリケーションが使用される各テナントに作成され、グローバルに一意のアプリケーション オブジェクトを参照します (アプリケーション オブジェクトはホーム テナントに存在します)。アプリケーション オブジェクトはアプリケーションをグローバルに定義し、サービス プリンシパルは特定のテナントにおけるアクセス ポリシーと、そのアプリケーションに許可される操作を定義します。

サービス プリンシパルはどのように作成され、いつ作成されますか。

通常、Microsoft Entra アプリケーションを登録し、そのアプリケーション インスタンスがテナントで使用されると、サービス プリンシパルは自動的に作成されます。マルチテナント アプリの場合は、ユーザーがアクセス許可に同意したときに作成されることもあります。また、保護されたリソースへのアクセスが必要なアプリケーションをテナントにデプロイする際に、Azure ポータル、Microsoft Graph、または自動化によって手動で作成することもできます。

Microsoft Entra でサービス プリンシパルを保護するためのベスト プラクティスは何ですか。

サービス プリンシパルは、最小特権のアクセス許可を割り当て、資格情報 (パスワードと証明書) をローテーションして保護し、可能な場合はマネージド ID を使用し、条件付きアクセス ポリシーを適用し、サインインと監査ログを監視し、フィルターベースのアクセス制御によりリスクの高いプリンシパルを除外することで保護します。機密性の高いリソースへのアクセスには、条件付きアクセスを使用して準拠デバイスまたは MFA を要求してください。

サービス プリンシパルのパスワードや証明書などの資格情報は、どのように管理すればよいですか。

パスワードと証明書は、安全な保管場所（Key Vault）に保存し、有効期限ポリシーを設定してください。可能な場合は証明書ベースの認証を使用し、Microsoft Graph または CI/CD パイプラインで更新を自動化します。有効期限の長い資格情報については、期限切れが近づいたときにアラートを設定し、ポリシーとスキーマを適用して、古い、または安全でないシークレットが残らないようにします。

Microsoft Graph を使用して、自動化によりサービス プリンシパルを照会および管理するにはどうすればよいですか？

Microsoft Graph API を使用すると、Microsoft Entra ID のサービス プリンシパル オブジェクトの一覧表示、フィルター、作成、更新、削除ができます。フィルターを使用して appId、displayName、所有者でサービス プリンシパルを検索できるほか、付与されたアクセス許可の管理、所有者の割り当てもできます。グローバル一意識別子を参照するスクリプトやコネクタを使用すれば、環境間でのサービス プリンシパルの同期も自動化できます。

所有者を割り当てる役割は何ですか、また所有者はどのように管理すればよいですか？

所有者を割り当てると、サービス プリンシパルに対する委任された管理権限が与えられ、所有者は資格情報とアクセス許可を管理できるようになります。事業継続性のために、ロールベースのアクセス制御と複数の所有者を使用し、所有者の変更は監査してください。長期的な ID に紐付いていないユーザー アカウントに所有者の権限を割り当てるのは避け、ポリシーで制約されたチームまたはサービス アカウントを優先してください。

同期やテナント、ディレクトリに関する考慮事項は、サービス プリンシパルにどのように影響しますか？

エンタープライズ アプリや ID をテナント間で同期するような同期シナリオでは、ターゲット テナントにサービス プリンシパルが作成されることがあります。アプリがシングル テナントかマルチ テナントか、アプリケーションが登録されたホーム テナントはどこか、そしてそのテナントのユーザーによる同意が必要かどうかを確認してください。同期を計画する際は、サービス プリンシパルが重複しないようにし、不要なオブジェクトはフィルターで除外してください。

サービス プリンシパルを作成する代わりに、マネージド ID を使用すべきなのはどのような場合ですか？

ワークロードが Azure 上で実行され、埋め込みの資格情報を使わずにプラットフォームが管理するマネージド ID を利用してトークンを取得できる場合は、マネージド ID を使用してください。マネージド ID を使うとパスワードの管理が不要になり、セキュリティ更新も簡素化されます。対応しているシナリオでは、サービス プリンシパルを保護する方法として推奨されます。

サービス プリンシパルで保護されたリソースへのアクセスを監査し、トラブルシューティングするにはどうすればよいですか？

Microsoft Entra ID と Azure AD のサインイン ログと監査ログを有効にして確認し、Microsoft Graph を使用してイベントを取得してください。フィルターを適用して結果を絞り込み、ログは SIEM と統合します。技術サポートが必要な場合や複雑な問題の場合は、サポートに問い合わせる前に、サービス プリンシパルの objectId、appId、タイムスタンプ、エラー メッセージを収集してください。Microsoft Learn やその他のリソースを参照して調査を進めることもできます。