Azure DevOps サービス
アクセス許可チェックは、多くのAzure DevOpsサービス操作の一部です。 大規模な場合、多くの明示的なアクセス許可の割り当て、リソース レベルの例外、およびグループ メンバーシップによって、アクセス許可の評価と更新が遅くなる可能性があります。 大規模なアクセス制御リストでは、より多くのアクセス許可データと ID を取得して解決するサービスも必要です。
Azure DevOps Services で処理されるアクセス許可データの量を減らすには、この記事の推奨事項に従ってください。
Tip
AI を使用して、Azure DevOps タスクに役立てることができます。 作業を開始するには、 Azure DevOps MCP Server で AI サポートを有効にする 方法に関するページを参照してください。
ソフト パフォーマンスの制限
大規模な組織の計画ターゲットとして、次の制限を使用します。 Azure DevOps サービスでは、これらの制限が適用されたり、それを超えるアクセス許可の変更がブロックされたりすることはありません。 ただし、これらを超えると、アクセス許可のクエリ、評価、メンバーシップの更新が遅くなるリスクが高くなります。
| 測る | 推奨される最大値 |
|---|---|
| 1 つのセキュリティ名前空間内の ACE | 1,000,000 |
| 1 つのMicrosoft EntraまたはAzure DevOps グループのメンバー | 10,000 |
アクセス制御エントリ (ACE) には、1 つのユーザーまたはグループに割り当てられたアクセス許可が格納されます。 入れ子になったグループの場合は、グループ サイズのガイドラインを使用する場合は、有効なメンバーシップの合計を考慮してください。
推奨プラクティス
| 演習 | パフォーマンス上の利点 |
|---|---|
| 個々のユーザーではなくグループにアクセス許可を割り当てる | 多数のユーザー アクセス制御エントリ (ACE) を 1 つのグループ ACE に置き換えます。 |
| 最も広範な一致スコープと継承を使用する | 子リソースで同じ ACE を繰り返さないようにします。 |
| 例外に対してのみ 拒否 を使用する | 明示的なオーバーライドとオブジェクト レベルの ACE を制限します。 |
| 適切なサイズの ID グループを使用する | 不要なグループ メンバーシップ処理を減らします。 |
| プロジェクトと組織間でリソースのバランスを取る | 1 つの境界内で評価されるリソースの数を制限します。 |
| アクセス許可の変更を段階的に適用する | 大規模または頻繁なアクセス制御の更新からの負荷を軽減します。 |
グループにアクセス許可を割り当てる
組み込みまたはカスタムのAzure DevOps セキュリティ グループを使用して、ロール、チーム、アクセス コーホートを表します。 グループにアクセス許可を割り当てると、1 つの ACE が作成されます。 多くのユーザーに同じアクセス許可を直接割り当てると、ユーザーごとに ACE が作成されます。
- 閲覧者、共同作成者、Project管理者などの組み込みグループが、必要なアクセス許可と一致する場合に優先します。
- 組み込みグループが必要なアクセスと一致しない場合は、カスタム グループを作成します。
- 1 つのグループを数百または数千の直接ユーザー割り当てに置き換えないでください。
一致する最も広いスコープと継承を使用する
アクセス要件に一致する、サポートされている最も高いスコープでアクセス許可を 1 回設定します。 子リソースにアクセス許可を継承させ、子リソースが異なるアクセスを必要とする場合を除き、継承を有効のままにします。
例えば次が挙げられます。
| アクセス要件 | 優先範囲 |
|---|---|
| 組織レベルのタスクを実行する | 組織レベル (そのレベルでアクセス許可が使用可能な場合) |
| プロジェクトでサポートされている型のすべてのリソースにアクセスする | プロジェクト レベル、またはリソース タイプのプロジェクト レベルの親 |
| プロジェクト内のすべての Git リポジトリにアクセスする | 最上位レベルの Git リポジトリ エントリ |
| リポジトリ内のすべてのブランチにアクセスする | リポジトリ レベル |
| 1 つのリポジトリ、ブランチ、パイプライン、エリア パス、またはその他のリソースにアクセスする | オブジェクト レベル |
リポジトリ、ブランチ、パイプライン、またはその他の子リソースごとに同じアクセス許可を個別に設定しないでください。 Git リポジトリの場合、 個々のリポジトリは最上位レベルの Git リポジトリ エントリからアクセス許可を継承します。
リソースが親とは異なるアクセスを必要とする場合にのみ、継承を無効にします。 多くのリソースで継承を無効にする場合は、通常、より明示的な割り当てが必要です。
例外に対してのみ拒否を使用する
グループを介してアクセス権を付与し、許可を受け取ってはいけない ID に対してアクセス許可を [未設定 ] のままにします。 広範なアクセス権を付与し、多数の 拒否 エントリを追加する代わりに、必要な正確なアクセス許可を持つグループを作成します。
特定の例外に対して継承された許可をオーバーライドする必要がある場合にのみ、Deny を使用します。 1 つの Deny エントリは、本質的にパフォーマンスの問題ではありません。 ただし、多くの例外では ACE が追加され、多くの場合、より多くのオブジェクト レベルのアクセス許可の割り当てが必要になります。
適切なサイズの ID グループを使用する
部署、プロジェクト、製品、ジョブ機能など、アクセス要件に合ったグループを使用します。 Entra グループと Azure DevOps グループのどちらでも、パフォーマンスが向上しません。 両方のグループ タイプに同じサイズとネストに関するガイダンスを適用します。
- すべての従業員グループなど、テナント全体または会社全体のグループを追加しないでください。
- より単純なグループ構造で同等のアクセスを実現できる場合は、深く入れ子になったグループ構造や頻繁に変更されるグループ構造は避けてください。
- メンバー全員が同じアクセスを必要としない場合は、非常に大きなグループを小さなアクセス コーホートに分割します。
- すべてのメンバーが同じアクセスを必要とする場合は、個々の割り当てまたは重複するグループを使用する代わりに、継承された親スコープで 1 つのグループを割り当てます。
メンバー数が 10,000 を超えるグループは、パフォーマンス上のリスクです。 ネスト構造、頻繁なメンバー変更、多数のアクセス制御されたリソースへのアクセスは、影響を大きくする可能性があります。 不要なメンバーシップを減らし、実用的な場合は、グループをより小さなアクセス コーホートに分割します。
プロジェクトと組織間でリソースのバランスを取る
1 つのプロジェクトには何千ものリポジトリとほとんどのアクセス許可で保護されたリソースが集中しないようにしますが、他のプロジェクトには少数しか含めないでください。 アクセス可能なリソースを検出する操作では、セット全体のアクセス許可を評価する必要がある場合があります。
1 つのプロジェクトに多くのリソースが蓄積される前に、多数のリポジトリやその他のリソースをプロジェクト間で分散します。 リポジトリごとに 1 つのプロジェクトを作成しないでください。プロジェクト数には 、実際のパフォーマンス制限もあります。
極端なエンタープライズ規模では、複数の小規模な組織が、ほとんどの会社のリソースとアクセス許可データを含む 1 つの組織よりも優れたパフォーマンスを発揮できます。 安定した製品やビジネスの境界に沿って組織を分割し、リソースとアクセス許可の負荷を分散します。 このアプローチは、スケールのメリットが、別の組織のリソース管理のオーバーヘッドを上回る場合にのみ使用します。
権限の自動化に伴う変動を減らす
スクリプト、REST API、またはコードとしての構成ワークフローを使用してアクセス許可を管理する場合:
- 目的の状態に到達するために必要な変更のみを適用します。 すべての実行で変更されていないアクセス許可の割り当てをクリアして再構築しないでください。
- すべての子リソースに対して同等のエントリを生成するのではなく、親スコープでアクセス許可を設定します。
- サポートされている場所でバッチ変更を行い、REST API のベスト プラクティスAzure DevOps従います。
- 高頻度のアクセス許可調整ループを回避します。
- 多数のプロジェクトやアクセス許可を持つリソースを定期的に作成および削除することは避けてください。
- 古い明示的な割り当てを削除して、アクセス制御リスト (ACL) と ACE ボリュームを減らします。