MS_AzureServicePrincipal

Azure サービス プリンシパル

• 戻る（SPN、Role Based Access Control (RBAC)）
  • Azure サービス プリンシパル
  • Azure Managed ID

概要

• ≒ SPN の Azure 版
• Active Directory ではなく、
  Azure AD に管理される。
• RBAC のアクセス権を付与するために使用される。

詳細

• Azure のリソース操作用の ID
• この ID（appId）は、Azure AD によって管理される。
• 基本は、アプリケーション用として利用する。

補足（用語）: 「アプリケーション登録」と「サービス プリンシパル」は別物である。

	内容
アプリケーション（App Registration）	アプリの定義。ホーム テナントに 1 つ
サービス プリンシパル	そのアプリのテナントごとの実体。権限はこちらに付く

マルチテナント アプリでは、 定義は 1 つでも、利用する各テナントにサービス プリンシパルが作られる。 RBAC のロールを割り当てる相手は サービス プリンシパルのオブジェクト ID である。

認証の種類

サービス・プリンシパルでは 2 種類の認証を使用可能。

• パスワード（シークレット）ベースの認証
• 証明書ベースの認証

また、Azure Managed ID は
ラッパとして機能し、パスワードを使用しないで利用できる。

補足: 選択の優先順位は明確である。

1. マネージド ID（Azure リソースから使う場合）— シークレット不要
2. ワークロード ID フェデレーション（GitHub Actions 等、Azure 外から）— シークレット不要
3. 証明書
4. クライアント シークレット — 最終手段

WebAPIの認証 の補足と同じ結論で、 シークレットを持ち回らない構成を優先する。

パスワードの失効とリフレッシュ

• 失効
  • 既定では一年でパスワード（シークレット）が失効する。
  • 無期限に設定することも出来る模様。
• リフレッシュ
  • 必要に応じリフレッシュが必要になる。
  • リフレッシュはパスワード（シークレット）を再作成し、
    アプリケーションにパスワード（シークレット）を再設定する。

補足（正誤・最新化）: 「無期限に設定することも出来る」は、 現在は実質的にできない。 ポータルでは最長 24 か月しか選べず、 Microsoft Graph 経由でそれ以上を設定することも テナント ポリシー（アプリケーション管理ポリシー）で禁止できる。

そして実務上、シークレットの期限切れは障害の常連である。 対策は次のとおり。

• 期限切れを監視・通知する（Graph でクエリして棚卸しする）
• そもそもシークレットを使わない（マネージド ID / フェデレーション）
• シークレットは Key Vault（MS_AzureKeyVault.md）に置き、 コードや構成ファイルに直接書かない

用例

オートメーション・アカウント

• Azure オートメーションを利用すると、Azure リソースへの操作を自動化できる。
  • 主にインフラ系操作の自動化に利用する仕組み
  • オートメーション・アカウントを作成し、複数のアカウントを束ねて管理
  • Runbook と呼ばれる仕組みで、実際に行う自動化の作業を記述・管理
• Azure インフラ操作だけでなく、オンプレミス側へのリソース操作指示なども可能。

補足（最新化）: Azure Automation の 実行アカウント（Run As アカウント）は 2023 年 9 月に廃止された。 現在は マネージド ID を使用する （Azure Managed ID 参照）。 これも「サービス プリンシパル＋証明書」から シークレットレスへ移行した例である。

参考

• SPN
• Role Based Access Control (RBAC)
• Azure Managed ID
• Azureのアクセス制御と権限
• Microsoft Azure Active Directory
• アプリケーション オブジェクトとサービス プリンシパル オブジェクト - Microsoft Learn

---

Tags: セキュリティ, アカウント, クラウド, 認証基盤, Azure