Azure DevOpsサービス |Azure DevOps Server |Azure DevOps Server 2022
この記事を使用して、組織レベルでAzure DevOpsの認証方法を選択します。 一般的な方法のセキュリティ体制、ガバナンス、保守容易性について説明し、実装に重点を置いたガイダンスへのリンクを示します。
アプリ レベルの実装の詳細については、Azure DevOpsの認証方法に関するページを参照してください。
サービスとサーバーの違い
認証オプションは、Azure DevOps サービスとAzure DevOps Serverによって異なります。
| プラットフォーム | 推奨される既定値 | Notes |
|---|---|---|
| Azure DevOps Services | Microsoft Entra ベースの認証 | ユーザー Microsoft Entraサインインを使用し、自動化のためにアプリケーション ID をMicrosoft Entraします。 |
| Azure DevOps Server | サポートされている場合は、Windows 認証、.NETクライアント ライブラリ、または AT | Azure DevOps認証のサービス プリンシパルとマネージド ID パターンは、Azure DevOps Serverではなく、Azure DevOps サービスに適用されます。 |
一般的な認証の選択肢を比較する
次の表を使用して、ユーザー、アプリ、スクリプト、およびパイプラインの一般的な選択肢を比較します。
| Method | 最適な用途 | セキュリティ態勢 | 資格情報の管理 | で動作します。 | 次の場合は避けてください |
|---|---|---|---|---|---|
| ユーザー サインインMicrosoft Entraする | Azure DevOps組織への対話型ユーザー アクセス | 一元化された ID ガバナンス、条件付きアクセス、多要素認証を使用した強力なオプション | Microsoft Entraライフサイクルとテナント ポリシーによって管理される | Azure DevOps Services | アプリ間の無人自動化を実装している |
| マネージド ID | Azure Functionsや App Service など、Azureホスト型の自動化 | トークンは有効期間が短く、ID ライフサイクルを管理Azureため、Azureホスト型自動化の最も強力なオプション | 保存またはローテーションするクライアント シークレットがない | Azure DevOps Services | ワークロードがAzureで実行されないか、環境間で移植可能な ID が必要です |
| サービス プリンシパル | Azure外、または複数の環境および CI/CD システムにまたがる自動化 | 最小限の特権と最新の資格情報パターンを使用する場合の強力なオプション | フェデレーション フローでシークレットが削除されない限り、アプリ ID と資格情報を管理します | Azure DevOps Services | マネージド ID は、Azureホストされるワークロードで同じ要件を満たすことができます |
| Azure DevOps サービス接続 | Azure DevOps リソースへのアクセスをAzure Pipelinesする | ワークロード ID フェデレーションを使用し、パイプラインでの PAT のスプロールを回避するため、パイプライン自動化の強力なオプション | Azure DevOps サービス接続設定を使用して管理する | Azure DevOps サービス パイプライン | このシナリオは、Azure Pipelines |
| 個人用アクセス トークン (PAT) | 有効期間の短い個人用スクリプト、1 回限りのテスト、または従来の互換性シナリオ | PAT はユーザー アカウントに関連付けられている有効期間の長いベアラー シークレットであるため、最も高いリスク | 手動での作成、ストレージ、ローテーション、失効 | Azure DevOps Services と Azure DevOps Server | サービス プリンシパル、マネージド ID、またはサービス接続を使用できる運用自動化 |
Important
より安全なMicrosoft Entraトークンを、リスクの高い個人アクセス トークンよりも使用することを検討してください。 詳細については、「 PAT 使用量の削減」を参照してください。 認証ガイダンスを確認して、ニーズに適した認証メカニズムを選択します。
シナリオ別の推奨される既定値
- Azure DevOps サービス組織へのユーザー アクセスには、Microsoft Entraユーザー サインインを使用します。
- 最初にマネージド ID を使用して、Azureホスト型の自動化を行います。
- 非Azureまたは環境間の自動化には、サービス プリンシパルを使用します。
- Azure Pipelines Azure DevOpsリソース アクセスが必要な場合は、サービス接続Azure DevOps使用します。
- PAT は、より安全なオプションが適用されない一時的、個人的、レガシ、またはAzure DevOps Serverのシナリオにのみ使用します。
PAT を使用する場合
次のような限られたシナリオで PAT を使用します。
- 個人用アドホック スクリプト
- 1 回限りの API のトラブルシューティング
- Microsoft Entra ベースの認証を使用できないレガシ ツール
- 最新のクラウド ID フローが使用できないAzure DevOps Serverシナリオ
AT を使用する場合:
- 必要最小限のアクセス許可にスコープを設定します。
- 最短の実用的な有効期間を使用します。
- シークレットとして保存してローテーションします。
- 可能な場合は、Microsoft Entraベースのオプションに置き換えます。
PAT ライフサイクル のガイダンスについては、「 個人用アクセス トークンの使用 」および 「PAT ポリシーの管理」を参照してください。
ポリシーとガバナンスの制御
組織とテナントのコントロールを使用して、認証体制を適用します。
意思決定チェックリスト
認証方法を選択する前に、次の内容を確認します。
- このユーザー対話型アクセスまたは無人オートメーションですか?
- ワークロードはAzureまたは外部のAzureでホストされていますか?
- ターゲット プラットフォームはサービスまたはAzure DevOps Server Azure DevOpsですか?
- このシナリオでは、有効期間が長い資格情報を回避できますか?
- 組織のポリシーと監査の要件は満たされていますか?