サービスプリンシパルとマネージドIDの使い分け｜Azure認証設計の実務ガイド

「データベースの接続文字列、コードの中に直書きしてます」——クラウド移行直後の現場でこれを聞くと、背筋が凍ります。

アプリケーションがAzureのリソースにアクセスするとき、「誰として」アクセスするかを明確にしなければなりません。人間であればユーザーアカウントで認証しますが、アプリやスクリプトはどうするか——ここで登場するのがサービスプリンシパルとマネージドIDです。

この記事では、2つの仕組みの違いと使い分けの判断基準を整理します。

「アプリにパスワードを持たせる」——それ、今すぐやめてください
サービスプリンシパルとマネージドIDの違いを整理する
どちらを使うべきか——使い分けの判断基準
1. マネージドIDを使うべきケース
2. サービスプリンシパルを使うべきケース
マネージドIDの種類——システム割り当てとユーザー割り当て
1. システム割り当てマネージドID——リソースと一体で管理する
2. ユーザー割り当てマネージドID——複数リソースで共有する
よくある失敗パターン——認証情報の管理ミスが招くリスク
実務チェックリスト——設計・運用の確認ポイント
1. 設計時の確認
2. 運用時の確認
まとめ——今日確認すべきことは1つです

「アプリにパスワードを持たせる」——それ、今すぐやめてください

アプリケーションがAzureリソースにアクセスする方法として、よく見かける危険な実装があります。

# よくある危険な実装例
connection_string = "DefaultEndpointsProtocol=https;AccountName=mystorage;AccountKey=xxxxxxxxxxxxxxxx"

接続文字列やクライアントシークレットをコードやファイルに直書きすると、以下のリスクが生じます。

リスク	内容
漏えい	GitHubなどのリポジトリに誤ってコミットされる
有効期限切れ	シークレットの期限が切れてサービスが停止する
管理コスト	ローテーションのたびに手動更新が必要
追跡困難	どのアプリが何のキーを使っているか把握できなくなる

これを解決するのがサービスプリンシパルとマネージドIDです。アプリに「人間と同じようにIDを持たせ、適切な権限だけを付与する」設計に切り替えることで、認証情報のハードコードを排除できます。

最小権限の考え方の基本については「最小権限の原則とは？」で解説しています。

サービスプリンシパルとマネージドIDの違いを整理する

サービスプリンシパルとは——アプリやスクリプトのための「IDカード」

サービスプリンシパル（Service Principal） Microsoft Entra IDにおけるアプリケーション・スクリプト専用のID。クライアントIDとシークレット（またはX.509証明書）で認証し、Azureリソースへのアクセス権を付与できる。

サービスプリンシパルは「アプリのためのユーザーアカウント」と考えるとわかりやすいです。Entra IDにアプリ登録を行うことで発行され、クライアントID・テナントID・シークレット（またはX.509証明書）の3点セットで認証します。

AzureだけでなくオンプレミスのアプリやGitHub Actionsなど、Azure外部からAzureリソースにアクセスする場合に使います。

マネージドIDとは——Azureが自動管理する「パスワード不要のID」

マネージドID（Managed Identity） AzureのリソースにEntra IDのIDを自動発行・自動管理する機能。認証情報（パスワード・シークレット）の管理が不要になり、Azureが裏側でローテーションを行う。

マネージドIDはAzureが認証情報を完全に管理します。開発者はクライアントシークレットを扱う必要がなく、コードへの認証情報の埋め込みをゼロにできます。Azure VM・App Service・FunctionsなどのAzureリソース上で動くアプリに付与できます。

参考：マネージドIDとは（Microsoft Learn）

2つの違いを一目で比較する

比較項目	サービスプリンシパル	マネージドID
認証情報の管理	自分で管理（シークレット・証明書）	Azureが自動管理
利用できる場所	Azure内外どこでも	Azureリソース上のみ
シークレットの漏えいリスク	あり	なし
有効期限の管理	必要	不要
セットアップの手間	やや多い	少ない
コスト	無料	無料

どちらを使うべきか——使い分けの判断基準

判断の基本は**「Azure上で動くか、Azure外で動くか」** の1点です。

マネージドIDを使うべきケース

Azure上で動くリソースからAzureサービスにアクセスする場合は、原則としてマネージドIDを選択してください。

ケース	例
Azure VMからBlob Storageにアクセス	VM→Storage Account
App ServiceからKey Vaultのシークレットを取得	App Service→Key Vault
Azure FunctionsからSQL Databaseに接続	Functions→SQL Database
ACI（コンテナインスタンス）からACRにアクセス	ACI→Azure Container Registry

サービスプリンシパルを使うべきケース

Azure外のシステムや、マネージドIDが利用できない環境ではサービスプリンシパルを使います。

ケース	例
GitHub ActionsからAzureにデプロイ	CI/CDパイプライン
オンプレミスサーバーからAzure APIを呼び出す	オンプレ→Azure
Terraformなどのインフラ管理ツール	IaCツール全般
マネージドIDに対応していないAzureサービス	一部のレガシーサービス

サービスプリンシパルを使う場合でも、シークレットはAzure Key Vaultに格納し、コードには直書きしない設計を徹底してください。

サービスアカウント全般の権限設計については「サービスアカウントの権限設計」を参照してください。

マネージドIDの種類——システム割り当てとユーザー割り当て

マネージドIDには2種類あり、用途によって使い分けが必要です。

システム割り当てマネージドID——リソースと一体で管理する

システム割り当てマネージドID（System-assigned Managed Identity） 特定のAzureリソースに直接紐づくマネージドID。リソースを削除すると自動的に削除される。1つのリソースに1つのIDが対応する。

VMやApp Serviceなど、1つのリソースが独立して動く場合に適しています。リソースのライフサイクルとIDが一致するため管理がシンプルです。

# システム割り当てマネージドIDの有効化例（Azure CLI）
az vm identity assign \
  --resource-group myRG \
  --name myVM

ユーザー割り当てマネージドID——複数リソースで共有する

ユーザー割り当てマネージドID（User-assigned Managed Identity） 独立したリソースとして作成するマネージドID。複数のAzureリソースに同じIDを割り当てられる。リソースを削除してもIDは残る。

複数のVMやApp Serviceが同じストレージやKey Vaultにアクセスする場合に有効です。IDを1つ作成して複数リソースに割り当てるため、権限管理が一元化できます。

比較項目	システム割り当て	ユーザー割り当て
IDの作成	リソースと同時に自動作成	独立して作成
複数リソースへの割り当て	不可（1対1）	可能（1対多）
リソース削除時のID	自動削除	残る
向いているケース	単独リソース・シンプルな構成	複数リソースで共有・再利用

よくある失敗パターン——認証情報の管理ミスが招くリスク

① シークレットをコードにハードコードしていた

最も多い失敗です。GitHubのパブリックリポジトリにシークレットを含むコードをコミットしてしまうと、数分以内にスキャンツールに検出されます。Azureポータルでそのシークレットが使われていないか確認し、即座にローテーションしてください。マネージドIDが使える環境ならシークレット自体を排除できます。

② シークレットの有効期限切れでサービスが停止した

サービスプリンシパルのクライアントシークレットはデフォルトで最大2年の有効期限が設定されます。期限切れに気づかずサービスが停止するケースは頻繁に起きます。Key Vaultのシークレット有効期限アラートを設定し、ローテーションを計画的に行う運用フローを作ってください。

③ サービスプリンシパルに過剰な権限を付与していた

「とりあえずOwner権限を付与した」サービスプリンシパルが放置されているケースは非常に危険です。侵害された場合にサブスクリプション全体が攻撃者の手に渡ります。Azure RBACで必要最小限のスコープ・ロールに絞った設計を徹底してください。

Azure RBAC設計の落とし穴については「Azure RBAC設計でよくある失敗6選」を参照してください。

④ どのアプリがどのサービスプリンシパルを使っているか把握できていない

サービスプリンシパルが増えるにつれ「このIDは何のためのものか」が不明になるケースです。命名規則（例：sp-appname-env-purpose）を決め、台帳で一元管理する運用を最初から設計してください。定期的な棚卸しも必要です。