entra-workload-identity

Microsoft Entra ワークロード ID

ワークロード ID は、アプリ、サービス、スクリプト、パイプラインが Microsoft Entra で保護されたリソースにアクセスするために使用する人間以外の IDです。近年のインシデント後の報告では、クラウド侵害の最大の原因となっています。多くの場合、クライアント シークレットの漏えい、過剰な権限を持つサービス プリンシパル、または管理されていない証明書の有効期限切れが原因です。

このスキルでは、適切な ID の種類の選択、フェデレーションによるシークレットの排除、サービス プリンシパルの強化、Workload Identities Premium の制御の適用について説明します。

使用する場面

Azure リソース、GitHub Action、Azure DevOps パイプライン、AKS ポッド、または外部ワークロードが、Entra で保護された API（Azure Resource Manager、 Microsoft Graph、Key Vault、Storage など）に対して認証する方法を設計するときに使用します。

このスキルは、人間の ID（entra-id）、マルチクラウドのエンタイトルメント分析（entra-permissions-management）、または AI エージェントの ID ガバナンスに特化した用途（agent-identity-governance）には使用しないでください。

適切な ID を選ぶ

ワークロード	最適な ID
Azure でホストされるリソース（App Service、Function、VM、AKS ポッド、Container Apps）	マネージド ID（1 対 1 の場合はシステム割り当て、共有またはライフサイクルを分離する場合はユーザー割り当て）
GitHub Actions / GitLab CI / Azure DevOps / Jenkins	ユーザー割り当て MI またはアプリ登録へのワークロード ID フェデレーション
OIDC 発行者を持つ Azure 外部のワークロード（Kubernetes、AWS、GCP）	ワークロード ID フェデレーション
OIDC を使用できないレガシーなオンプレミス サービス	証明書を使用したアプリ登録（シークレットは決して使用しないでください）
Microsoft Graph のみを認証先とするもの	アプリ登録 + フェデレーション／証明書

**経験則：**設計書にクライアント シークレットが含まれている場合、フェデレーションの機会を見逃しています。まずフェデレーションを試し、次に証明書を検討してください。新規構築ではクライアント シークレットを決して使用しないでください。

アプローチ

1. 既存のサービスプリンシパルと資格情報を棚卸しします。 Microsoft Graph （servicePrincipals、applications）を使用して、すべてのアプリ登録、そのキー／シークレット 資格情報、有効期限、割り当てられたロールを一覧表示します。多くのテナントでは、有効期限切れのシークレット、 10年前に作成されたテスト用アプリ、所有者不在の管理者による同意済みアプリが見つかります。

2. フェデレーションが使える場合は、シークレットをなくします。

   • GitHub Actions → Azure：ユーザー割り当て MI （またはアプリ登録）に、サブジェクト repo:org/repo:environment:prod を指定したフェデレーション資格情報を設定します。GitHub にシークレットは不要です。
   • AKS ワークロード ID：クラスターで有効にし、サービスアカウントにアノテーションを付けてトークンを 投影します。ポッドは、紐付けられたユーザー割り当て MI として認証されます。
   • Azure DevOps：ワークロード ID フェデレーション サービス接続を使用します。
   • 外部 OIDC 発行者（GCP、AWS、Okta）：発行者 URL とサブジェクトクレームを指定して、フェデレーション資格情報を追加します。

3. 資格情報を保持する必要がある場合は、クライアントシークレットではなく、Key Vault でローテーションする証明書を使用します。 有効期限を短く（≤180日）設定し、ローテーションを自動化します。

4. 最小権限の RBAC を適用します。 既定では、リソースまたは RG レベルでスコープを限定したロール割り当てを使用します。正当な理由がない限り、サブスクリプションの所有者ロールは割り当てません。スコープ付き、またはアプリコレクション単位のアクセス許可（Sites.Selected、アプリのアクセス ポリシーによる特定のメールボックスへの Mail.Send）がある場合は、Microsoft Graph の .All アクセス許可（例：Files.ReadWrite.All）を避けます。

5. Workload Identities Premium（別個の SKU）を利用します。以下が可能になります。

   • ワークロード向け条件付きアクセス — 想定外の IP 範囲からのサービスプリンシパルのサインインをブロックし、名前付きの場所を要求し、クライアントアプリで制限します。
   • ワークロード ID のリスク検出 — 資格情報の漏えい、異常なサインイン、不審な管理者アクティビティを検出します。
   • ワークロード ID のアクセスレビュー — SP ロールの所有者による定期的なレビューを行います。 外部公開または高い特権を持つワークロード ID に適用します。テナント内のすべての SP に適用する必要はありません。

6. ライフサイクル： すべてのアプリ登録に所有者を設定します（退職した人ではなく、空のリストにもなっていないこと）。所有者不在および未使用のアプリを四半期ごとにレビューし、無効化してから削除します。

7. 監視します。 ServicePrincipalSignInLogs を Sentinel にストリーミングします。以下をアラートします。

   • 想定されるベースライン外の国または IP からのサインイン。
   • 新しい資格情報の追加（特に、所有者とは別の ID による追加）。
   • 高い特権を持つロールのトークンが営業時間外に発行された場合。

ガードレール

• 新しい設計ではクライアントシークレットを使用しません。 フェデレーション ＞ 証明書 ＞ シークレット。
• システム割り当て MI はリソースのライフサイクルに紐付いています。 リソースを削除すると、ID（およびそのロール割り当て）も消えます。通常は望ましい動作ですが、予想外の結果になる場合もあります。
• 複数のリソースで共有するユーザー割り当て MI は便利ですが、影響範囲の分離を損ないます。ライフサイクルと信頼境界が本当に一致する場合にのみ共有します。
• フェデレーション資格情報は具体的に指定する必要があります。 サブジェクト repo:org/repo:* は、攻撃者のフォークを含む、すべてのブランチと PR を受け入れます。環境または保護されたブランチに固定します。
• 明確な正当性がない限り、.All Graph アクセス許可を使用しません。 Sites.Selected、メールアプリのアクセス ポリシー、またはアプリ専用 RBAC のスコープ設定を使用します。
• 環境ごとにアプリ登録を作成しません。 ワークロードごとにアプリを 1 つ用意し、複数のフェデレーション資格情報（環境ごとに 1 つ）を設定します。これによりロールの一覧を整理できます。
• 所有者は個人とグループにします。 単独所有者のアプリは、所有者の退職後に孤立します。
• ワークロード向け CA は、別個のプレミアムポリシータイプです。 コンプライアンス対策として利用する場合は、有効になっていることを確認します。

よくあるアンチパターン

• 「GitHub Action が AZURE_CREDENTIALS を JSON シークレットとして保存している」 — シークレット漏えいのリスクがあります。 OIDC フェデレーションに切り替えてください。
• 「DevOps プラットフォーム全体で 1 つの巨大なサービス プリンシパルを使い、すべてのサブスクリプションで Owner を付与している」 — 侵害されると、テナント全体が危険にさらされます。パイプラインごとに ID を割り当て、スコープを限定してください。
• 「クライアント シークレットの有効期限が 2099 年」 — 有効期間の長いベアラー シークレットでは、ローテーションの仕組みが機能しません。有効期間を 180 日以内に制限し、自動化してください。
• 「AKS ポッドがノードプールの MSI を使ってアプリのデータにアクセスしている」 — ノード上のすべてのポッドが同じ ID を使用します。サービス アカウントごとに AKS ワークロード ID を使用してください。
• 「フェデレーション資格情報の subject が repo:org/repo:」** — PR を含むすべてのブランチを受け入れてしまいます。environment:prod に固定してください。
• 「レポート スクリプトを実行するために、サービス プリンシパルに Global Administrator を付与している」 — 読み取り専用の Graph 権限をスコープ限定で付与すれば十分でした。
• 「アプリ登録の所有者リストが空」 — レビューやローテーションを行う人がいません。孤立したアプリは監査で指摘されます。

プロンプトの例

• GitHub Actions の Azure デプロイで使っているクライアント シークレットを、ワークロード ID フェデレーションに置き換えてください。
• 12 個の AKS ワークロードを kiam/pod-identity から AKS ワークロード ID に移行してください。
• 30 日以内に有効期限が切れるシークレットを持つすべてのアプリ登録を棚卸しし、証明書のローテーションに優先順位を付けてください。
• 給与計算統合用のサービス プリンシパルに条件付きアクセスを適用し、IP をパートナーの CIDR に制限してください。
• prod と dev で環境スコープの subject クレームを使う Azure DevOps のフェデレーション資格情報を設計してください。
• Microsoft Graph の .All 権限を持つサービス プリンシパルを監査し、スコープを限定した代替案を提案してください。
• Workload Identities Premium を使って、特権の高いワークロード ID の四半期ごとのアクセスレビューを展開してください。
• Sentinel で異常なサービス プリンシパルのサインインをハントしてください — KQL による検出。

Microsoft Learn

• ワークロード ID の概要：https://learn.microsoft.com/entra/workload-id/workload-identities-overview
• マネージド ID：https://learn.microsoft.com/entra/identity/managed-identities-azure-resources/overview
• ワークロード ID フェデレーション：https://learn.microsoft.com/entra/workload-id/workload-identity-federation
• GitHub Actions の OIDC：https://learn.microsoft.com/entra/workload-id/workload-identity-federation-create-trust?pivots=identity-wif-apps-methods-azp
• AKS ワークロード ID：https://learn.microsoft.com/azure/aks/workload-identity-overview
• Azure DevOps のワークロード ID：https://learn.microsoft.com/azure/devops/pipelines/library/connect-to-azure?view=azure-devops#create-an-azure-resource-manager-service-connection-that-uses-workload-identity-federation
• ワークロード ID の条件付きアクセス：https://learn.microsoft.com/entra/identity/conditional-access/workload-identity
• ワークロード ID のリスク：https://learn.microsoft.com/entra/id-protection/concept-workload-identity-risk
• Microsoft Graph のアプリケーション権限リファレンス：https://learn.microsoft.com/graph/permissions-reference