Azure Managed Identity vs Service Principal 完全比較｜認証パターンの選定と実装ベストプラクティス

Service Principal は『アプリケーション登録 (App Registration) によって作成される Microsoft Entra ID の認証エンティティ』で、Client ID + Client Secret (または証明書) で認証する。Managed Identity は『Azure リソース (VM・App Service・Functions など) に自動付与される特別な Service Principal』で、Client Secret 不要 (Azure が裏側で自動的に管理)。Managed Identity は Service Principal の一種だが、シークレット管理が不要というセキュリティ上の優位性があり、Azure リソース間認証ではほぼ常に Managed Identity が推奨。Service Principal は『Azure 外のシステム (オンプレ・他クラウド・GitHub Actions) から Azure 認証する場合』『複数 Azure リソースで認証を共有する場合』『3rd party SaaS 連携』で使用します。

System-assigned: Azure リソース (VM・App Service など) のライフサイクルに紐付く Managed Identity、1 リソースに 1 つ。リソース削除時に自動削除。シンプル・最小権限原則に従いやすい。User-assigned: 独立した Azure リソースとして作成、複数 Azure リソースに割り当て可能 (1 つの User-assigned Identity を 100 VM で共有など)。リソース削除時も残る、ライフサイクルが分離。複数リソースで同じ権限を共有したい場合・テンプレート化された権限管理をしたい場合に使用。新規プロジェクトでは User-assigned が柔軟性で優位、シンプルな単発リソースなら System-assigned で十分。両者は混在可能で、1 リソースに System-assigned + 複数 User-assigned を併用可能です。

2026 年現在、Azure のほぼすべてのコンピュート系サービスで Managed Identity がサポート。代表例: Azure VM・VMSS・App Service・Functions・Logic Apps・Container Apps・AKS Pod (Workload Identity)・Azure Container Instances・Azure Batch・Azure Data Factory・Synapse Analytics・Fabric・Azure Automation・Service Bus Namespace・Event Hub Namespace・API Management・Cognitive Services / Azure OpenAI・Static Web Apps。逆に Managed Identity 非対応 (2026-05 時点) のサービスは Azure Functions for SAP・一部レガシーサービスのみ。Azure リソースから他 Azure リソースへの認証は Managed Identity を使うのがベストプラクティスで、Client Secret や Connection String の管理から完全解放されます。

Service Principal の作成手順: 1) Azure Portal『Microsoft Entra ID』→『App registrations』→『New registration』で App Registration を作成 (Display Name・Supported account types・Redirect URI 指定)。これにより App Registration オブジェクトと、それに紐付く Service Principal オブジェクトが自動作成される。2) 認証情報を設定: Certificates & secrets で Client Secret 生成 (1-2 年で期限切れに注意) または Certificate アップロード (推奨)。3) API permissions で必要な権限付与 (Microsoft Graph / Azure Service Management 等)、Admin consent が必要なら実施。4) Service Principal に RBAC ロール割り当て (Subscription / RG / Resource レベルで)。5) アプリケーションで Client ID + Client Secret (or Certificate) を使って Azure AD トークン取得し、API 呼び出し。

Certificate (証明書) が推奨です。Client Secret は文字列ベースのシークレットで、漏洩リスクが高い (Git コミット・ログ・メール添付など)。Certificate は秘密鍵がマシン内に保管され、外部漏洩しにくい。さらに Workload Identity Federation (2022 年 GA、2026 年現在は主力推奨) では Certificate も不要で、GitHub Actions / Azure DevOps / Kubernetes 外部 IdP からの OIDC トークンで Azure 認証可能。新規プロジェクトでは: 1) Azure 内サービス → Managed Identity (シークレット完全不要)、2) GitHub Actions / Azure DevOps → Workload Identity Federation (OIDC)、3) その他オンプレ・3rd party → Certificate、4) どうしても Client Secret → 90 日以内ローテーション + Key Vault 保管必須、というセキュリティ階層が標準。

Workload Identity Federation (WIF) は、Azure 外の認証システム (GitHub Actions・Azure DevOps・Google Cloud・AWS・Kubernetes クラスタ・任意の OIDC プロバイダ) から Azure リソースへ認証する仕組み。Service Principal に Federated Credential を構成し、外部 IdP の OIDC トークンを Azure AD トークンに交換することで、Client Secret や Certificate の管理が完全不要に。GitHub Actions の azure/login@v2 アクションで標準サポートされ、CI/CD パイプラインでのシークレット漏洩リスクをゼロ化。Microsoft が強く推奨する 2026 年現在の主力認証パターンで、新規 CI/CD 構成では WIF 一択というのが業界標準。AKS の Workload Identity も同じ思想で、Pod から Azure リソースへの認証に Kubernetes Service Account の OIDC トークンを使います。

AKS Pod Identity (旧方式、2024-09 廃止予定): AAD Pod Identity プロジェクトベースで、aad-pod-identity Add-on をクラスタにインストール、Pod の IP に基づいて Azure Identity を割り当てる仕組み。実装複雑・パフォーマンス課題・既に廃止予定。AKS Workload Identity (新方式、推奨): Kubernetes 標準の Service Account をベースに、Azure AD と OIDC で連携。Pod は Service Account の OIDC トークンを Azure AD に提示してアクセストークン取得。シンプル・スケーラブル・パフォーマンス改善。2026 年現在の AKS では Workload Identity 一択で、既存 AKS Pod Identity ユーザーは Workload Identity への移行が必須です。

SC-300 (Identity and Access Administrator Associate) で Service Principal・Managed Identity・Workload Identity が深く問われ、OAuth 2.0 / OIDC フローと組み合わせて出題。AZ-204 (Developer Associate、2026-07 リタイア注意) で アプリ開発者視点での Managed Identity 活用、AZ-104 (Administrator) で RBAC 連携、AZ-400 (DevOps Engineer Expert) で Workload Identity Federation の CI/CD 適用、AI-103 (2026-06 GA) で Azure OpenAI / AI Search への認証パターン。Azure アプリケーション開発者にとって Managed Identity の使い方は事実上必須スキルです。