Microsoft Entra ID認証・サービスプリンシパル・Managed Identityの違い
Azureでアプリ認証を設定していると、「アプリの登録」「エンタープライズアプリ」「サービスプリンシパル」「Managed Identity」という似た言葉が登場します。 これらはすべて同じものではありません。 Entra IDは認証とトークン発行の基盤、サービスプリンシパルはアプリがテナント内で活動するためのID、 Managed IdentityはAzureが資格情報を管理してくれるサービスプリンシパルです。 このページでは、それぞれの役割と関係を2枚の図で分かりやすく解説します。
まずは3つの違いを一言で
Entra ID認証は「認証の仕組み」です。 サービスプリンシパルとManaged Identityは、認証される「アプリ側のID」です。 Managed Identityはサービスプリンシパルの一種ですが、クライアントシークレットや証明書などの資格情報をAzureが自動的に管理します。
「Entra ID認証」と「サービスプリンシパル」は、同じ種類の概念ではありません。
- Entra ID認証：認証とトークン発行の仕組み
- サービスプリンシパル：認証される主体
- Managed Identity：Azure管理型の認証主体
アプリの登録・サービスプリンシパル・エンタープライズアプリの関係
「アプリの登録」は設計図、「サービスプリンシパル」はテナント内で動く実体、「エンタープライズアプリ」はその実体を管理する画面です。
設計図アプリの登録
- 認証設定 / リダイレクトURI
- APIアクセス許可
- クライアントシークレット / 証明書
- Application Objectを保持
実体サービスプリンシパル
- テナント内でサインインする実体
- Azure RBACの割り当て対象
- APIアクセス許可の付与対象
- テナントごとに作成される
管理画面エンタープライズアプリ
- ユーザー・グループの割り当て
- シングルサインオン / 条件付きアクセス
- サインインログ / プロビジョニング
- Service Principalを管理する画面
Application ObjectとService Principalは何が違うのか
Application Objectは、アプリケーションそのものの定義です。アプリ名、リダイレクトURI、必要なAPIアクセス許可、認証方式など、アプリに共通する情報を保持します。
Service Principalは、そのアプリケーションが特定のEntra IDテナント内で活動するためのセキュリティIDです。Azure RBACのロール、ユーザーやグループの割り当て、テナント固有のアクセス制御などは、Service Principalに対して設定されます。
Application Object
- アプリの定義
- 「アプリの登録」から管理
- ホームテナントに作成
- Application（Client）IDを持つ
- アプリ共通の設定を保持
Service Principal
- テナント内におけるアプリの実体
- 「エンタープライズアプリ」から管理
- 利用される各テナントに作成
- テナントごとに異なるObject IDを持つ
- RBACやテナント固有の設定を保持
- Client ID：アプリケーションを識別するID
- Object ID：Entra ID内の個別オブジェクトを識別するID
同じアプリでも、Application ObjectとService PrincipalのObject IDは異なります。
Microsoft Entra ID認証とは
Microsoft Entra IDは、ユーザー、アプリケーション、サービス、ワークロードのIDを確認し、アクセストークンを発行するクラウドID基盤です。 ユーザーだけでなく、アプリケーションもEntra IDへサインインできます。
代表的な仕組み：OAuth 2.0 / OpenID Connect / SAML / アクセストークン / IDトークン / SSO / MFA / 条件付きアクセス / サインインログ / ID保護
Entra IDは「社員証を確認し、入館証を発行する受付」のような存在です。 Service PrincipalやManaged Identityは、受付で確認される「アプリの社員証」に相当します。
サービスプリンシパルとは
サービスプリンシパルは、アプリケーション、スクリプト、自動化ツール、CI/CDなどがEntra IDへサインインするためのセキュリティIDです。 ユーザーアカウントを使わず、アプリ自身のIDとして認証できます。
代表的な認証方法：クライアントシークレット / 証明書 / フェデレーション資格情報 / Workload Identity Federation
デプロイ・CI/CD
GitHub ActionsやAzure DevOpsからAzureへデプロイ・リソース操作。
オンプレ・外部連携
オンプレのバッチ処理や外部SaaSからMicrosoft Graphを呼び出す。
IaC・独自アプリ
TerraformからAzureリソースを管理、独自アプリからAzure APIを利用。
クライアントシークレットは便利ですが、漏えい、期限切れ、ローテーション忘れのリスクがあります。 GitHub Actionsなど対応サービスでは、長期間保存するクライアントシークレットよりも、Workload Identity Federationを優先してください。
Managed Identityとは
Managed Identityは、Azureリソースに対してEntra IDのIDを割り当てる機能です。 内部的にはService Principalが作成されますが、アプリケーションコードでクライアントシークレットや証明書を管理する必要がありません。 Azureが資格情報の作成、保管、ローテーションを管理します。
利用できる代表的なサービス：App Service / Functions / Virtual Machines / Container Apps / AKS / Automation / Logic Apps / API Management / Data Factory
アクセス先の例：Key Vault / Storage / Azure SQL Database / Cosmos DB / Service Bus / App Configuration / Azure Resource Manager / Microsoft Graphの一部シナリオ
Managed Identityを有効化しただけでは、対象リソースへアクセスできません。Key Vault、Storage、SQLなどのアクセス先に対して、 必要最小限のRBACロールまたはAPIアクセス許可を割り当てる必要があります。 「シークレットが不要」とは、開発者がシークレットを保持・管理する必要がないという意味で、内部の資格情報はAzureが管理します。
Entra ID認証・サービスプリンシパル・Managed Identityの違い
認証の仕組みと、認証される2種類のアプリ用IDの関係を1枚で整理します。
例1：Azure上のサービスから
Azure上のワークロードはManaged Identityでシークレットレスに接続できます。
例2：Azure外のツールから
Azure外からはService Principal（できればフェデレーション資格情報）で接続します。
Service PrincipalとManaged Identityの比較
| 観点 | Service Principal | Managed Identity |
|---|---|---|
| 正体 | Entra IDテナント内のアプリ用セキュリティID | Azureによって管理されるService Principal |
| 主な利用場所 | Azure外を含むアプリ、CI/CD、外部ツール、自動処理 | Managed Identityに対応したAzureサービス |
| 資格情報 | シークレット、証明書、フェデレーション資格情報など | Azureが管理するため、アプリ側で秘密情報を保持しない |
| 資格情報のローテーション | 方式によって管理が必要 | Azureが管理 |
| Azure RBAC | 利用可能 | 利用可能 |
| APIアクセス許可 | 利用可能 | 対象APIと認証方式に応じて利用可能 |
| 外部環境からの利用 | 可能 | 原則として対応Azureリソース上から利用 |
| 運用負荷 | 認証方式によっては期限管理やローテーションが必要 | 比較的低い |
| 推奨シーン | GitHub Actions、外部システム、マルチクラウド、オンプレミス | App Service、Functions、VMなどAzure上のワークロード |
2種類のManaged Identity
System-assigned
- Azureリソースに直接ひも付く
- リソース作成後に有効化できる
- リソースとライフサイクルが同じ
- リソースを削除するとIDも削除される
- 基本的に1つのリソースで利用する
覚え方：「そのAzureリソース専用の社員証」
User-assigned
- 独立したAzureリソースとして作成する
- 複数のAzureリソースへ割り当てられる
- 利用元リソースを削除してもIDは残る
- 権限やIDを共通化できる
- 複数サービスで同じIDを使う構成に向く
覚え方：「複数のAzureリソースで共有できる社員証」
選び方：1つのApp Serviceだけで利用し、ライフサイクルも同じでよいなら System-assigned。 複数のApp Service、Functions、VMで共通のIDを使いたいなら User-assigned が適しています。
Azureリソースへアクセスするまでの流れ
- ユーザーまたはアプリがEntra IDへ認証を要求する
- Entra IDがユーザー、Service Principal、Managed Identityを確認する
- Entra IDが対象リソース向けのアクセストークンを発行する
- アプリがアクセストークンを付けてAzureリソースへアクセスする
- AzureリソースがトークンとRBACまたはAPI権限を確認する
- 権限があれば処理を許可する
認証に成功しても、権限が付与されていなければアクセスできません。 認証は「あなたは誰か」の確認、認可は「何をしてよいか」の確認です。
どれを使えばよいか
Azure上のワークロード
- Managed Identity
- Workload Identity Federation
- 証明書
- クライアントシークレット
外部CI/CDや外部ワークロード
- Workload Identity Federation
- 証明書
- クライアントシークレット
※ これは絶対的な順位ではなく、システム要件や各サービスの対応状況により異なる場合があります。
具体例で理解する
例1：App ServiceからKey Vault
アプリ設定にKey Vaultのクライアントシークレットを保存する必要がありません。
例2：Azure FunctionsからStorage
接続文字列やストレージアカウントキーをコードに保持せずに接続できます。
例3：GitHub ActionsからAzureへデプロイ
GitHub Secretsへ長期間有効なAzureクライアントシークレットを保存せずに済みます。
例4：オンプレミスバッチからAzure SQL
オンプレミスでは通常のManaged Identityを直接利用できないため、Service Principalなどを利用します。
よくある誤解
誤解：エンタープライズアプリとService Principalは別の製品である
Azure Portalの「エンタープライズアプリ」は、主にテナント内のService Principalを管理する画面です。
誤解：アプリの登録を作れば、それだけでAzureリソースへアクセスできる
認証設定だけでなく、Service Principalに対するRBACまたはAPIアクセス許可が必要です。
誤解：Client IDとObject IDは同じ
Client IDはアプリケーションを識別するIDです。Object IDはEntra ID内の個別オブジェクトを識別するIDです。
誤解：Managed IdentityはService Principalとは無関係
Managed Identityの内部ではService Principalが作成されます。Managed IdentityはAzure管理型のService Principalと考えると理解しやすくなります。
誤解：Managed Identityを有効にすれば、すべてのAzureリソースにアクセスできる
Managed Identityを有効にしただけでは権限はありません。アクセス先で必要最小限のRBACロールやAPI権限を付与します。
誤解：Managed Identityならセキュリティを考えなくてよい
資格情報の管理負荷は下がりますが、過剰なRBAC、不要な権限、ログ監視、ネットワーク制御などは引き続き考慮が必要です。
誤解：サービスプリンシパルでは必ずクライアントシークレットが必要
証明書やWorkload Identity Federationなども利用できます。可能であれば、長期間保存するシークレットを避けてください。
Azure Portalではどこを見るのか
アプリの登録
Microsoft Entra ID → アプリの登録 → 対象アプリ
- Application（Client）ID
- Directory（Tenant）ID
- Object ID
- リダイレクトURI
- APIのアクセス許可
- 証明書とシークレット
- フェデレーション資格情報
エンタープライズアプリ
Microsoft Entra ID → エンタープライズアプリ → 対象アプリ
- Service PrincipalのObject ID
- ユーザーとグループ
- シングルサインオン
- アクセス許可
- サインインログ
- プロビジョニング
- プロパティ
Managed Identity
対象のAzureリソース → ID → システム割り当て済み / ユーザー割り当て済み
- 状態
- プリンシパルID
- テナントID
- User-assigned Managed Identityの割り当て
- Azureロールの割り当て
安全に利用するためのポイント
- Azure上の対応サービスではManaged Identityを優先する
- 外部CI/CDではWorkload Identity Federationを検討する
- クライアントシークレットをソースコードへ書かない
- appsettings.jsonへ平文保存しない
- GitHubへ秘密情報をコミットしない
- 最小権限の原則を適用する
- サブスクリプションOwnerを安易に付けない
- 必要なスコープだけにRBACを付与する
- 証明書やシークレットには有効期限を設定する
- 期限切れの事前通知を設定する
- サインインログと監査ログを確認する
- 不要になったService Principalを削除する
- 所有者・用途・作成日・管理担当者を記録する
- 定期的に棚卸しする
危険な例
- アプリ設定にクライアントシークレットを直接記載
- GitHub Secretsに長期間有効なAzureシークレットを保存
推奨する例
- Managed IdentityからKey Vaultへアクセス
- GitHub Actions OIDCとフェデレーション資格情報を利用
よくある質問
Managed IdentityとService Principalは同じですか？
完全に同じ表現ではありませんが、Managed Identityの内部ではService Principalが作成されます。Managed Identityは、資格情報をAzureが管理するService Principalの一種です。
Managed Identityではシークレットは本当に不要ですか？
アプリケーション開発者がクライアントシークレットや証明書を作成・保存・ローテーションする必要がありません。資格情報はAzure側で管理されます。
Managed Identityを有効化しただけでKey Vaultへアクセスできますか？
できません。Key Vault側で、対象Managed Identityに必要なRBACロールまたはアクセスポリシーを設定する必要があります。
アプリの登録とエンタープライズアプリは同じですか？
アプリの登録はApplication Objectを管理する場所です。エンタープライズアプリは、そのアプリがテナント内で利用される際のService Principalを管理する場所です。
Client IDはアプリの登録とエンタープライズアプリで同じですか？
同じアプリケーションに対応するApplication ObjectとService Principalでは、Application（Client）IDは同じです。一方、Object IDは別です。
GitHub ActionsではManaged Identityを使えますか？
一般的なGitHubホステッドランナーはAzureリソース上のManaged Identityを直接利用しません。通常はService PrincipalとWorkload Identity Federationを組み合わせます。Azure上のセルフホステッドランナーでは構成によってManaged Identityを利用できる場合があります。
System-assignedとUser-assignedはどちらを使うべきですか？
1つのリソース専用でライフサイクルも同じならSystem-assigned、複数のAzureリソースでIDや権限を共有するならUser-assignedが適しています。
Azureの認証・アクセス制御でお困りですか？
Entra ID、サービスプリンシパル、Managed Identityを使った安全な認証・アクセス設計を、Smart Designerがご支援します。