Azure DevOps でサービスプリンシパルとマネージド ID を使用する

Azure DevOps Services

サービスプリンシパルとマネージド ID は、Azure DevOps 自動化ワークフローに対してセキュリティで保護されたスケーラブルな認証を提供します。これらの Microsoft Entra ID の種類は、従来の個人用アクセストークン (AT) よりもセキュリティが強化されています。資格情報の自動管理、トークンの有効期間の短縮、エンタープライズレベルのアクセス制御を使用します。

サービスプリンシパルとマネージド ID の利点

セキュリティの強化

有効期間の短いトークン: Microsoft Entra トークンは 1 時間ごとに期限切れになります。これにより、PAT (最長 1 年間) と比較して露出リスクが軽減されます。
自動ローテーション: マネージド ID は資格情報のローテーションを自動的に処理します。
保存されたシークレットなし: コードまたは構成に有効期間の長い資格情報を格納する必要がなくなります。

オペレーショナルエクセレンス

一元管理: Microsoft Entra ID ポリシーと Azure DevOps アクセス許可を使用してアクセスを制御します。
監査機能: 包括的なログ記録を使用して認証とアクセスパターンを追跡します。
効率的にスケーリング: 個々のユーザー依存関係なしでエンタープライズ自動化シナリオをサポートします。

先進認証

標準ベース: OAuth 2.0 および OpenID Connect プロトコルを使用します。
多要素認証のサポート: 組織のセキュリティポリシーを継承します。
条件付きアクセス: コンテキストに基づいて高度なセキュリティポリシーを適用します。

サービスプリンシパルとマネージド ID について

サービスプリンシパル

サービスプリンシパルは、テナント内のアプリケーションを表す Microsoft Entra オブジェクトです。アプリケーションでできること、アクセスできるリソース、およびアプリケーションを使用できるユーザーを定義します。 Microsoft Entra ID でアプリケーションを登録すると、サービスプリンシパルが自動的に作成され、アプリケーションがリソースを認証してアクセスするための安全な方法が提供されます。

主な特性

Microsoft Entra ID でのアプリケーション登録によって作成されます。
マルチテナントシナリオをサポートします。
明示的な資格情報管理 (証明書またはクライアントシークレット) が必要です。
さまざまな環境で認証する必要があるアプリケーションに最適です。

管理されたアイデンティティー

マネージド ID は、Azure が自動的に管理する特殊な種類のサービスプリンシパルです。 Azure リソースの Microsoft Entra ID に自動的にマネージド ID を提供することで、開発者が資格情報を管理する必要がなくなります。

マネージド ID の種類

システム割り当てマネージド ID:

自動的に作成され、特定の Azure リソースに関連付けられます。
Azure によって管理されるライフサイクル (リソースが削除されたときに削除されます)。
Azure リソースとの一対一のリレーションシップ。
1 つの Azure リソースにデプロイされたアプリケーションに最適です。

ユーザー割り当てマネージド ID:

スタンドアロンの Azure リソースとして作成されます。
複数の Azure リソースに割り当てることができます。
関連付けられているリソースとは別に管理されるライフサイクル。
複数のリソースで実行されるアプリケーションや、共有 ID が必要なアプリケーションに最適です。

各型を使用する場合:

サービスプリンシパル: クラウド間デプロイ、継続的インテグレーションと継続的デリバリー (CI/CD) パイプライン、Azure 外部のアプリケーション。
システム割り当てマネージド ID: 単一の Azure リソースアプリケーション (Azure Functions、Azure App Service)。
ユーザー割り当てマネージド ID: マルチリソースアプリケーション、共有 ID シナリオ。

実装ガイド

Azure DevOps 認証のサービスプリンシパルまたはマネージド ID を実装するには、次の手順に従います。完全なコード例については、サンプルアプリケーションを参照してください。

手順 1: ID を作成する

デプロイシナリオに基づいて適切な ID の種類を選択します。

オプション A: サービスプリンシパルを作成する (アプリケーションの登録)

サービスプリンシパルは、柔軟なデプロイオプションを必要とする CI/CD パイプライン、クロスクラウドシナリオ、アプリケーションに適しています。

Microsoft Entra 管理センターでアプリケーションを登録します。
[ アプリの登録>新しい登録] に移動します。
アプリケーションを構成します。
- 名前: アプリケーションのわかりやすい名前を使用します。
- アカウントの種類: 適切なテナントサポートを選択します。
- リダイレクト URI: サービス間のシナリオでは空白のままにします。
認証資格情報を作成します。
- 推奨: セキュリティを強化するために証明書をアップロードします。
- 別の方法: クライアントシークレットを作成する (定期的なローテーションが必要)。

Von Bedeutung

アプリケーションを登録すると、Azure によってアプリケーションオブジェクトとサービスプリンシパルオブジェクトの両方が作成されます。 サービスプリンシパルのオブジェクト ID ([エンタープライズアプリケーション] ウィンドウにあります) は、アプリケーションのオブジェクト ID ではなく、Azure DevOps に追加するときに使用します。

詳細については、次の記事を参照してください。

オプション B: マネージド ID を作成する

マネージド ID は、Azure でホストされるアプリケーションにとって最も簡単な認証エクスペリエンスを提供します。

システム割り当てマネージド ID の場合:

App Service や Azure Functions アプリなどの Azure リソースに移動します。
Identity>System assigned に移動します。
状態を [オン] に切り替えます。
[ 保存] を 選択して構成を保存します。

ユーザー割り当てマネージド ID の場合:

Azure portal でマネージド ID を作成します。
リソースの作成>管理 ID に移動します。
基本設定を構成し、リソースを作成します。
必要に応じてリソースに割り当てます。

詳細については、次の記事を参照してください。

手順 2: Id を Azure DevOps に追加する

Microsoft Entra ID で ID を作成したら、それを Azure DevOps 組織に追加してリソースへのアクセスを許可します。

[前提条件]

プロジェクトコレクション管理者ロール。
招待ポリシーでチーム管理者がユーザーを追加できる場合のプロジェクト管理者またはチーム管理者ロール。

ID を追加する

Azure DevOps ポータルを使用して ID を追加するには:

組織の設定>ユーザーに移動します。
[ ユーザーの追加] を選択します。
サービスプリンシパルまたはマネージド ID の表示名を入力します。
適切なアクセスレベルとプロジェクトアクセスを選択します。
招待を送信します。

プログラムによって ID を追加します。

ServicePrincipalEntitlements REST API を使用してプロセスを自動化します。

その他の考慮事項:

正しい ID を見つけます。 アプリケーション登録のオブジェクト ID ではなく、Microsoft Entra 管理センターの [エンタープライズアプリケーション ] ウィンドウでサービスプリンシパルのオブジェクト ID を使用します。
テナントの制限: ID は、Azure DevOps 組織が接続されているのと同じテナントからのみ追加できます。テナント間でのシナリオに関しては、FAQの回避策をご覧ください。

手順 3: アクセス許可を構成する

Azure DevOps 内でサービスプリンシパルまたはマネージド ID の詳細なアクセス許可を構成します。他の Azure サービスとは異なり、Azure DevOps は Microsoft Entra アプリケーションのアクセス許可ではなく、独自のアクセス許可モデルを使用します。

アクセス許可オプション:

直接割り当て: アクセス許可を ID に直接割り当てます。
グループメンバーシップ: Azure DevOps または Microsoft Entra セキュリティグループに追加します。
アクセスレベル: 適切なライセンスレベル (Basic、Basic + Test Plans、または Visual Studio サブスクライバー) を割り当てます。

ベストプラクティス:

最小限の特権を適用する: 必要な最小限のアクセス許可のみを付与します。
グループを使用する: メンテナンスを容易にするために、グループを使用してアクセス許可を管理します。
定期的なレビュー: アクセス許可を定期的に監査します。

アクセス許可管理オプション:

Azure DevOps ポータル: 組織の設定>Permissions を選択します。
REST API: プログラムによる管理には、サービスプリンシパル Graph API を使用します。

Von Bedeutung

Azure DevOps と Microsoft Entra のアクセス許可: Azure DevOps では、Microsoft Entra ID アプリケーションのアクセス許可は使用されません。すべてのアクセス制御は、Azure DevOps アクセス許可システムを介して管理されます。これにより、プロジェクトレベルとリソースレベルの詳細なアクセス許可が可能になります。

手順 4: Microsoft Entra ID トークンを取得する

Azure DevOps API とサービスを使用してアプリケーションを認証するためのアクセストークンを取得します。

サービスプリンシパルの場合

クライアント資格情報フローを使用する:

POST https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

client_id={client-id}
&scope=https://app.vssps.visualstudio.com/.default
&client_secret={client-secret}
&grant_type=client_credentials

証明書認証を使用する (推奨):

using Microsoft.Identity.Client;

var app = ConfidentialClientApplicationBuilder
    .Create(clientId)
    .WithCertificate(certificate)
    .WithAuthority(new Uri($"https://login.microsoftonline.com/{tenantId}"))
    .Build();

var result = await app
    .AcquireTokenForClient(new[] { "https://app.vssps.visualstudio.com/.default" })
    .ExecuteAsync();

string accessToken = result.AccessToken;

マネージド ID の場合

Azure リソースから:

using Azure.Identity;
using Azure.Core;

var credential = new ManagedIdentityCredential();
var tokenRequest = new TokenRequestContext(new[] { "https://app.vssps.visualstudio.com/.default" });
var token = await credential.GetTokenAsync(tokenRequest);

string accessToken = token.Token;

Azure Instance Metadata Service を使用する:

GET http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://app.vssps.visualstudio.com/
Metadata: true

アドホック操作用の Azure CLI

1 回限りの操作またはテストでは、Azure CLI を使用します。

# For service principal
az login --service-principal --username {client-id} --password {client-secret} --tenant {tenant-id}
az account get-access-token --resource https://app.vssps.visualstudio.com/

# For managed identity (from Azure resource)
az login --identity
az account get-access-token --resource https://app.vssps.visualstudio.com/

詳細については、「 Microsoft Entra トークンの取得」を参照してください。

手順 5: Azure DevOps でトークンを使用する

取得したトークンを使用して、REST API 呼び出しやその他の Azure DevOps 操作を認証します。

認証された API 呼び出しを行います。

using System.Net.Http;
using System.Net.Http.Headers;

var client = new HttpClient();
client.DefaultRequestHeaders.Authorization = 
    new AuthenticationHeaderValue("Bearer", accessToken);

var response = await client.GetAsync(
    "https://dev.azure.com/{organization}/_apis/projects?api-version=7.1");

ビデオの例

一般的な統合シナリオ

NuGet フィード: NuGet.exe または dotnet CLI を使用して接続します。
Marketplace の発行: コマンドラインを使用して拡張機能を発行します。
Azure Pipelines: マネージド ID によってサポートされるサービス接続を作成します。
Git 操作: Git Credential Manager を使用してリポジトリを複製します。

完全なコード例については、サンプルアプリケーションを参照してください。

管理に関する考慮事項

サービスプリンシパルとマネージド ID には、ユーザーアカウントと比較して異なる管理特性があります。

ライセンス

各 ID には、参加するすべての組織のライセンスが必要です。
複数組織の課金は、サービスプリンシパルには適用されません。
グループベースのライセンス規則は自動的には適用されません。ライセンスを直接割り当てる必要があります。

ID 管理

メールアドレスは使用されないため、メールによる招待はありません。
表示名またはアバターは、Azure DevOps では変更されません。
表示名は Microsoft Entra ID から継承されます。

グループメンバーシップ

Microsoft Entra グループと Azure DevOps グループに追加できます。
Microsoft Entra グループメンバーリストに表示されない技術的な制限があります (UI の制限のみ)。
引き続き、そのグループが属する Microsoft Entra グループからアクセス許可を継承できます。

具体化

組織に明示的に追加する必要があります (ユーザーのような自動具体化は行われません)。
サービスプリンシパルは対話形式でサインインできないため、必須です。

ユーザーアカウントとの主な違い

サービスプリンシパルとマネージド ID には、通常のユーザーと比べて特定の制限があります。

能力

✅ API アクセス用の Microsoft Entra トークンを生成します。
✅ 適切なアクセス許可を持つ Azure DevOps リソースにアクセスします。
✅ セキュリティグループとチームに参加します。
❌ AT または Secure Shell キーを作成します。
❌ 対話形式でサインインするか、Web UI 経由でアクセスします。
❌ 組織を作成または所有する。
❌ Azure DevOps OAuth フローをサポートします。

Billing

各組織で個別のライセンスとしてカウントされます。 (複数組織の割引はありません)。)
アクセスレベルを直接割り当てる必要があります。 (グループルールは自動的には適用されません)。

よく寄せられる質問

質問 PAT の代わりにサービスプリンシパルまたはマネージド ID を使用する必要がある理由

Ａ。サービスプリンシパルとマネージド ID は、AT よりも大きなセキュリティ上の利点を提供します。

セキュリティ上の利点:

有効期間が短い: Microsoft Entra トークンの有効期限は、1 年まで続く場合がある AT と比較して 1 時間ごとに切れます。
自動ローテーション: マネージド ID は資格情報を自動的にローテーションします。
共有シークレットなし: 有効期間の長いトークンを格納または誤って公開するリスクは排除されます。
一元管理: エンタープライズセキュリティポリシーを使用して Microsoft Entra ID を使用して管理されます。

運用上の利点:

監査証跡: 認証とアクセスパターンを完全にログに記録します。
条件付きアクセス: 場所、デバイス、リスク要因に基づいてポリシーを適用します。
サービスアカウントなし: 自動化のための個々のユーザーアカウントへの依存関係を排除します。

移行の例については、「 APP を Microsoft Entra トークンに置き換える」を参照してください。

質問サービスプリンシパルとマネージド ID のレート制限は何ですか?

Ａ。サービスプリンシパルとマネージド ID には、ユーザーと同じレート制限があります。

質問この機能を使用すると、コストが高くなりますか?

Ａ。サービスプリンシパルとマネージド ID は、アクセスレベルに基づいてユーザーと同じように価格が設定されます。主な違いは次のとおりです。

複数組織の課金割引なし: 各 ID は、すべての組織で個別のライセンスとしてカウントされます。
ライセンスの割り当て: アクセスレベルを直接割り当てる必要があります。 (グループルールは自動的には適用されません)。
同じ価格レベル: Basic、Basic + Test Plans、Visual Studio サブスクライバー料金が適用されます。

質問別のテナントのマネージド ID を組織に追加できますか?

Ａ。 ID は、組織の接続されているテナントからのみ直接追加できます。テナント間のシナリオでは、この回避策を使用します。

テナント間マネージド ID を設定するには:

リソーステナントにユーザー割り当てマネージド ID を作成します。
仮想マシンや Functions アプリなど、Azure リソースに割り当てます)。
キーコンテナーを作成し、証明書 (PEM 以外の形式) を生成します。
シークレット の取得 と 一覧表示 のアクセス許可を使用して、マネージド ID にキーコンテナーへのアクセス権を付与します。
証明書を CER 形式でダウンロードします (公開キーのみ)。
ターゲットテナントにアプリケーションを登録します。
証明書をアプリケーション登録にアップロードします。
Azure DevOps 組織にサービスプリンシパルを追加します。
キーコンテナーの証明書を使用して認証を構成します。

// Example: Acquire token using managed identity certificate
public static async Task<string> GetSecret(string keyVaultName, string secretName)
{
    var keyVaultUri = new Uri($"https://{keyVaultName}.vault.azure.net");
    var client = new SecretClient(keyVaultUri, new ManagedIdentityCredential());
    var keyVaultSecret = await client.GetSecretAsync(secretName);
    return keyVaultSecret.Value.Value;
}

private static async Task<AuthenticationResult> GetAppRegistrationAADAccessToken(
    string applicationClientID, string appTenantId)
{
    byte[] privateKeyBytes = Convert.FromBase64String(await GetSecret(keyVaultName, secretName));
    var certificate = new X509Certificate2(privateKeyBytes, (string)null, X509KeyStorageFlags.MachineKeySet);

    var app = ConfidentialClientApplicationBuilder.Create(applicationClientID)
        .WithCertificate(certificate)
        .WithAuthority(new Uri($"https://login.microsoftonline.com/{appTenantId}"))
        .Build();

    var result = await app.AcquireTokenForClient(
        new[] { "499b84ac-1321-427f-aa17-267ca6975798/.default" })
        .ExecuteAsync();

    return result;
}

Von Bedeutung

セキュリティのベストプラクティスのために証明書を定期的にローテーションします。

一般的なエラーと解決

名前または識別子を持つ Git リポジトリが存在しないか、アクセス許可がありません

解決： サービスプリンシパルに少なくとも Basic ライセンスがあることを確認します。利害関係者ライセンスでは、リポジトリへのアクセスは提供されません。

オブジェクト ID を持つサービスプリンシパルを作成できませんでした

解決： アプリケーション登録のオブジェクト ID ではなく、 エンタープライズアプリケーション ウィンドウからサービスプリンシパルのオブジェクト ID を使用していることを確認します。

正しい ID を見つけるには:

Microsoft Entra 管理センター>Enterprise アプリケーションに移動します。
アプリケーション名を検索します。
[エンタープライズアプリケーション] ウィンドウでオブジェクト ID を使用します。

アクセスが拒否されました: ユーザーを追加するためのアクセス許可が必要です

考えられる原因と解決策:

ロールが不十分: 招待アクセス許可が有効になっているプロジェクトコレクション管理者 (PCA) またはプロジェクトまたはチーム管理者である必要があります。
ポリシーの制限: [チーム管理者とプロジェクト管理者に新しいユーザーの招待を許可する ] ポリシーが有効になっているかどうかを確認します。
ライセンスの割り当て: プロジェクト管理者は、招待中にライセンスを割り当てることはできません。ライセンスの変更については、PCA にお問い合わせください。

Azure DevOps Graphs List API が空のリストを返す

解決：continuationTokenを使用して、すべてのページを反復処理します。 API の改ページ動作により、サービスプリンシパルが後のページに表示されることがあります。

解決： 必要なアクセス許可を持つ組織にサービスプリンシパルが正しく追加されていることを確認します。このエラーは、組織内で ID が認識されていないことを示します。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-08-28

次の方法で共有

Azure DevOps でサービス プリンシパルとマネージド ID を使用する

サービス プリンシパルとマネージド ID の利点

セキュリティの強化

オペレーショナルエクセレンス

先進認証

サービス プリンシパルとマネージド ID について

サービス プリンシパル

主な特性

管理されたアイデンティティー

マネージド ID の種類

実装ガイド

手順 1: ID を作成する

オプション A: サービス プリンシパルを作成する (アプリケーションの登録)

オプション B: マネージド ID を作成する

手順 2: Id を Azure DevOps に追加する

[前提条件]

ID を追加する

手順 3: アクセス許可を構成する

手順 4: Microsoft Entra ID トークンを取得する

サービス プリンシパルの場合

マネージド ID の場合

アドホック操作用の Azure CLI

手順 5: Azure DevOps でトークンを使用する

ビデオの例

一般的な統合シナリオ

管理に関する考慮事項

ライセンス

ID 管理

グループ メンバーシップ

具体化

ユーザー アカウントとの主な違い

能力

Billing

よく寄せられる質問

質問 PAT の代わりにサービス プリンシパルまたはマネージド ID を使用する必要がある理由

質問 サービス プリンシパルとマネージド ID のレート制限は何ですか?

質問 この機能を使用すると、コストが高くなりますか?

質問 別のテナントのマネージド ID を組織に追加できますか?

一般的なエラーと解決

名前または識別子を持つ Git リポジトリが存在しないか、アクセス許可がありません

オブジェクト ID を持つサービス プリンシパルを作成できませんでした

アクセスが拒否されました: ユーザーを追加するためのアクセス許可が必要です

Azure DevOps Graphs List API が空のリストを返す

TF401444: サインインが必要なエラー

関連コンテンツ

フィードバック

その他のリソース

Azure DevOps でサービスプリンシパルとマネージド ID を使用する

サービスプリンシパルとマネージド ID の利点

サービスプリンシパルとマネージド ID について

サービスプリンシパル

オプション A: サービスプリンシパルを作成する (アプリケーションの登録)

サービスプリンシパルの場合

グループメンバーシップ

ユーザーアカウントとの主な違い

質問 PAT の代わりにサービスプリンシパルまたはマネージド ID を使用する必要がある理由

質問サービスプリンシパルとマネージド ID のレート制限は何ですか?

質問この機能を使用すると、コストが高くなりますか?

質問別のテナントのマネージド ID を組織に追加できますか?

オブジェクト ID を持つサービスプリンシパルを作成できませんでした