アクセス許可とアクセスの概要

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

この記事では、Azure DevOps で継承、セキュリティ グループ、ロールなどを使用してアクセス レベルとアクセス許可を管理する方法について説明します。 まず、次の主要な概念を理解します。

• アクセス許可について:

  • Azure DevOps に追加されたすべてのユーザーは、1 つ以上の既定 のセキュリティ グループに追加されます。
  • セキュリティ グループには、機能またはタスクへのアクセスを許可または拒否するアクセス許可が割り当てられます。
  • セキュリティ グループのメンバーは、グループ に割り当てられたアクセス許可 を継承します。
  • 権限は、組織/コレクション、プロジェクト、オブジェクトなど、さまざまなレベルで定義されます。
  • その他のアクセス許可は、チーム管理者、拡張機能の管理、さまざまなパイプライン リソース ロールなど、ロールベースの割り当てによって管理されます。
  • 管理istrator は、さまざまな機能領域のアクセス許可を管理するカスタム セキュリティ グループを定義できます。

• アクセス レベルについて:

  • Azure DevOps に追加されたすべてのユーザーがアクセス レベルに割り当てられ、選択した Web ポータル機能へのアクセスが許可または制限されます。
  • アクセス レベルには、利害関係者、基本、基本 + テストプランの 3 つのメインがあります。
  • 利害関係者アクセスでは、制限された機能セットに対して無制限の数のユーザーに無料でアクセスできます。 詳細については、「利害関係者アクセスクイック リファレンス」を参照してください。

• プレビュー機能について:
  • 新しい機能が導入されると、ユーザーはプレビュー機能を使用してそれらを有効または無効にしてアクセスできます。
  • 新機能の小さなサブセットは、組織レベルで管理され、組織の所有者によって有効または無効になります。

たとえば、ほとんどの Azure DevOps ユーザーは共同作成者セキュリティ グループに追加され、Basic アクセス レベルが付与されます。 共同作成者グループは 、 リポジトリ、作業追跡、パイプラインなどの読み取りと書き込みアクセスを提供します。 Basic アクセスを使用すると、Azure Boards、Azure Repos、Azure Pipelines、Azure Artifacts を使用するためのすべての機能とタスクにアクセスできます。 Azure Test Plans の管理にアクセスする必要があるユーザーには、Basic + Test Plans または Advanced アクセス権が付与されている必要があります。

管理者は、プロジェクト コレクション管理者またはプロジェクト管理者グループに追加する必要があります。 管理リストは、主に Web ポータルからセキュリティ グループとアクセス許可を管理します。プロジェクトの設定。 共同作成者は、Web ポータルから作成したオブジェクトのアクセス許可も管理します。

既定のアクセス許可の概要については、既定のアクセス許可のクイック リファレンスに関する記事をご覧ください。

セキュリティ グループとメンバーシップ

組織、コレクション、またはプロジェクトを作成すると、Azure DevOps によって既定のセキュリティ グループのセットが作成され、それらに既定のアクセス許可が自動的に割り当てられます。 その他のセキュリティ グループは、次のアクションで定義されます。

• 次のレベルでカスタム セキュリティ グループを作成する場合:
  • プロジェクト レベル
  • 組織またはコレクション レベル
  • サーバー レベル (オンプレミスのみ)
• チームを追加すると、チーム セキュリティ グループが作成されます

オブジェクト レベルのセキュリティ グループを作成することはできませんが、カスタム グループをオブジェクト レベルに割り当てて、そのレベルにアクセス許可を割り当てることができます。 詳細については、「オブジェクト レベルのアクセス許可を設定する」を参照してください。

既定のセキュリティ グループ

次のセキュリティ グループは、プロジェクトと組織ごとに既定で定義されます。 通常は、閲覧者、共同作成者、または Project 管理istrators グループにユーザーまたはグループを追加します。

プロジェクト	組織またはコレクション
- 管理istrator をビルドする -貢献 - Project 管理istrators - プロジェクトの有効なユーザー -読者 - 管理リストをリリースする - TeamName Team	- Project Collection 管理istrators - Project Collection Build 管理istrators - プロジェクト コレクション ビルド サービス アカウント - プロジェクト コレクション プロキシ サービス アカウント - Project Collection Service アカウント - Project Collection テスト サービス アカウント - プロジェクト コレクションの有効なユーザー - プロジェクト スコープ ユーザー - セキュリティ サービス グループ

これらの各グループの説明については、「セキュリティ グループ、サービス アカウント、およびアクセス許可」を参照してください。 最も一般的な既定のセキュリティ グループに対する既定のアクセス許可の割り当てについては、「既定のアクセス許可とアクセス」を参照してください。

チーム、エリア、反復パス、リポジトリ、サービス フック、サービス エンドポイントなどのプロジェクト レベルの機能の管理を任されているユーザーは、プロジェクト 管理istrators グループに追加します。 組織レベルまたはコレクション レベルの機能 (プロジェクト、ポリシー、プロセス、アイテム保持ポリシー、エージェントと展開プール、拡張機能など) の管理を行うユーザーの場合は、それらを Project Collection 管理istrators グループに追加します。 詳細については、「ユーザー、チーム、プロジェクト、および組織レベルの設定について」を参照してください。

各グループと各アクセス許可の説明については、「アクセス許可とグループのリファレンス」の「グループ」を参照してください。

メンバーシップ、アクセス許可、アクセス レベルの管理

Azure DevOps は、次の 3 つの接続間機能領域を介してアクセスを制御します。

• メンバーシップ管理では、個々のユーザー アカウントおよびグループを既定のセキュリティ グループに追加する操作がサポートされています。 各既定グループは、既定のアクセス許可のセットに関連付けられています。 セキュリティ グループに追加されたすべてのユーザーは、有効なユーザー グループに追加されます。 有効なユーザーとは、プロジェクト、コレクション、または組織に接続できるユーザーのことです。

• アクセス許可の管理では、システムのさまざまなレベルで特定の機能タスクへのアクセスを制御します。 オブジェクト レベルのアクセス許可は、ファイル、フォルダー、ビルド パイプライン、または共有クエリに対するアクセス許可を設定します。 アクセス許可の設定は、[許可]、[拒否]、[継承された許可]、[継承された拒否]、[システム許可]、[システム拒否]、[未設定] に対応しています。 詳細については、この記事で後述する「アクセス許可の継承とセキュリティ グループ」を参照してください。

• アクセス レベル管理 は、Web ポータル機能へのアクセスを制御します。 管理者は、ユーザーの購入内容に基づいて、ユーザーのアクセス レベルを利害関係者、Basic、Basic + Test、または Visual Studio Enterprise (以前の詳細) に設定します。

各機能領域では、デプロイの管理をシンプルにするためにセキュリティ グループを使用します。 ユーザーとグループを追加するには、Web 管理コンテキストを使用します。 アクセス許可は、ユーザーを追加するセキュリティ グループに基づいて自動的に設定されます。 または、グループを追加するオブジェクト、プロジェクト、コレクション、またはサーバー レベルに基づいてアクセス許可を取得します。

セキュリティ グループ メンバーシップは、ユーザー、他のグループ、Microsoft Entra グループの組み合わせにすることができます。

Active Directory および Microsoft Entra セキュリティ グループ

個々のユーザーを追加することで、セキュリティ グループを設定できます。 ただし、管理を容易にするために、Azure DevOps Services 用の Microsoft Entra ID と Azure DevOps Server 用の Active Directory (AD) または Windows ユーザー グループを使用してこれらのグループを設定する方が簡単です。 この方法を使用すると、複数のコンピューターでグループ メンバーシップとアクセス許可をより効率的に管理できます。

少数のユーザーのみを管理する必要がある場合は、この手順をスキップできます。 ただし、組織が成長する可能性があることを予測した場合は、Active Directory または Microsoft Entra ID を設定できます。 また、追加のサービスの支払いを計画している場合は、課金をサポートするために、Azure DevOps で使用する Microsoft Entra ID を設定する必要があります。

Note

Microsoft Entra ID を使用しない場合、すべての Azure DevOps ユーザーは Microsoft アカウントを使用してサインインする必要があり、個々のユーザー アカウントによるアカウント アクセスを管理する必要があります。 Microsoft アカウントを使用してアカウント アクセスを管理する場合でも、課金を管理するには Azure サブスクリプションを設定する必要があります。

Azure DevOps Services で使用する Microsoft Entra ID を設定するには、「組織を Microsoft Entra ID に接続する」を参照してください。

組織が Microsoft Entra ID に接続されている場合、組織をセキュリティで保護するために有効または無効にできる多くの組織ポリシーがあります。 詳細については、「セキュリティ、認証、承認、セキュリティ ポリシーについて」を参照してください。

Microsoft Entra ID を使用して組織のアクセスを管理するには、次の記事を参照してください。

• Microsoft Entra IDを使用してユーザーを追加または削除します
• Microsoft Entra ID を使用したアクセスのトラブルシューティング

Azure DevOps は、その変更から 1 時間以内に Microsoft Entra グループに加えられた変更を Microsoft Entra ID に登録します。 グループ メンバーシップを介して継承されたすべてのアクセス許可が更新されます。 Azure DevOps で Microsoft Entra メンバーシップと継承されたアクセス許可を更新する場合は、サインアウトしてからサインインするか、更新を トリガーしてアクセス許可を再評価します。

有効なユーザー グループ

ユーザーのアカウントをセキュリティ グループに直接追加すると、有効なユーザー グループのいずれかに自動的に追加されます。

• プロジェクト コレクションの有効なユーザー: 組織レベルのグループに追加されたすべてのメンバー。
• プロジェクトの有効なユーザー: プロジェクト レベルのグループに追加されたすべてのメンバー。

これらのグループに割り当てられる既定のアクセス許可は、主に、ビルド リソースの表示、プロジェクト レベルの情報の表示、コレクション レベルの情報の表示など、読み取りアクセスに制限されます。

1 つのプロジェクトに追加するすべてのユーザーは、コレクション内の他のプロジェクトのオブジェクトを表示できます。 ビュー アクセスを制限する必要がある場合は、エリア パス ノードを使用して制限を設定できます。

いずれかの有効なユーザー グループの インスタンス レベルの情報 の表示権限を削除または拒否した場合、設定したグループに応じて、グループのメンバーはプロジェクト、コレクション、または配置にアクセスできません。

Project-Scoped Users グループ

既定では、organizationに追加されたユーザーは、すべてのorganizationとプロジェクトの情報と設定を表示できます。 これらの設定には、ユーザーの一覧、プロジェクトの一覧、課金の詳細、使用状況データなど、組織の設定からアクセスできます。

重要

• このセクションで説明する制限付き可視性機能は、Web ポータルを介した操作にのみ適用されます。 REST API または azure devops CLI コマンドを使用すると、プロジェクト メンバーは制限付きデータにアクセスできます。
• Microsoft Entra ID で既定のアクセス権を持つ制限付きグループのメンバーであるゲスト ユーザーは、ユーザー 選択ウィンドウでユーザーを検索できません。 組織のプレビュー機能がオフになっている場合、またはゲスト ユーザーが制限付きグループのメンバーでない場合、ゲスト ユーザーは、想定どおりにすべての Microsoft Entra ユーザーを検索できます。

選択したユーザー (利害関係者、Microsoft Entra ゲスト ユーザー、特定のセキュリティ グループのメンバーなど) を制限するには、[ユーザーの可視性とコラボレーションを組織の特定のプロジェクトプレビュー機能に制限する] 機能を有効にします。 これを有効にすると、プロジェクト スコープ ユーザー グループに追加されたユーザーまたはグループは、[概要] と [プロジェクト] を除き、組織の設定ページへのアクセスが制限され、追加先のプロジェクトにのみアクセスできるようになります。

警告

組織で [ユーザーの 可視性とコラボレーションを特定のプロジェクト に限定する] プレビュー機能が有効になっている場合、プロジェクト スコープのユーザーは、明示的なユーザー招待ではなく、Microsoft Entra グループ メンバーシップを通じて組織に追加されたユーザーを検索できません。 これは予期しない動作であり、解決が行われています。 この問題を自己解決するには、組織の特定のプロジェクトプレビュー機能 にユーザーの可視性とコラボレーションを制限 する機能を無効にします。

詳細については、「 プレビュー機能の管理」を参照してください。

Note

セキュリティ グループは、特定のプロジェクトにのみアクセスする場合でも、組織レベルに属します。 ユーザーのアクセス許可によっては、一部のグループが Web ポータルで非表示になる場合があります。 Azure devops CLI ツールまたは REST API を使用して、組織内のすべてのグループ名を見つけることができます。 詳細については、「セキュリティ グループの追加と管理」を参照してください。

アクセス レベル

アクセス レベルは、Web ポータルでユーザーに表示される機能を制御します。 アクセスはユーザー ライセンスによって異なります。

アジャイル ポートフォリオ管理またはテスト ケース管理機能へのアクセス権をユーザーに付与する場合は、 アクセス許可ではなくアクセス レベルを変更します。

ユーザーまたはグループのアクセス レベルを設定しても、プロジェクトや Web ポータルへのアクセスは提供されません。 プロジェクトと Web ポータルに接続できるのは、チームまたはセキュリティ グループに追加されたユーザーまたはグループだけです。 ユーザーが必要なアクセス許可とアクセス レベルの両方を持っていることを確認します。 これを行うには、プロジェクトまたはチームに追加されていることを確認します。

アクセス許可

次の図に示すように、プロジェクトおよびコレクション レベルで定義されているセキュリティ グループは、オブジェクト、プロジェクト、および組織レベルで割り当てられたアクセス許可に割り当てることができます。

各既定のセキュリティ グループの説明については、「セキュリティ グループ、サービス アカウント、およびアクセス許可」を参照してください。

アクセス許可の状態

アクセス許可には、次の割り当てを割り当てることができます。 指定されたとおりにアクセスを許可または制限します。

ユーザーまたはグループ には、 タスクを実行するためのアクセス許可があります。

• 許可
• 許可 (継承)
• 許可 (システム)

ユーザーまたはグループ に タスクを実行するアクセス許可がありません。

• Deny
• 拒否 (継承)
• 拒否 (システム)
• 設定なし

アクセス許可の状態	説明
許可	特定のタスクの実行をユーザーに明示的に許可し、グループ メンバーシップから継承されることはありません。
許可 (継承)	特定のタスクを実行するグループ メンバーを許可します。
許可 (システム)	ユーザーのアクセス許可より前に優先されるアクセス許可を付与します。 編集不可で、構成データベースに格納されます。ユーザーには表示されません。
Deny	ユーザーが特定のタスクを実行できないように明示的に制限し、グループ メンバーシップから継承されることはありません。 ほとんどのグループおよびほとんどすべてのアクセス許可では、拒否の方が許可よりも優先されます。 ユーザーが 2 つのグループに属していて、そのうちの 1 つに特定のアクセス許可が [拒否] に設定されている場合、そのアクセス許可が [許可] に設定されているグループに属している場合でも、そのユーザーはそのアクセス許可を必要とするタスクを実行できません。
拒否 (継承)	グループ メンバーが特定のタスクを実行できないように制限します。 明示的 な許可をオーバーライドします。
拒否 (システム)	ユーザーのアクセス許可より前に優先されるアクセス許可を制限します。 編集不可で、構成データベースに格納されます。ユーザーには表示されません。
設定なし	そのアクセス許可を必要とするタスクを実行する権限をユーザーに暗黙的に拒否しますが、そのアクセス許可を持つグループのメンバーシップが優先されるようにします (許可 (継承) または拒否 (継承) とも呼ばれます)。

場合によっては、Project Collection 管理istrators または Team Foundation 管理istrators グループのメンバーは、別のグループでそのアクセス許可が拒否された場合でも、常にアクセス許可を取得できます。 作業項目の削除やパイプラインなど、Project Collection 管理istrators グループのメンバーである場合、他の場所で設定された拒否アクセス許可はバイパスされません。

警告

グループのアクセス許可を変更すると、そのグループのメンバーであるすべてのユーザーのアクセス許可が変更されます。 グループのサイズによっては、1 つのアクセス許可のみを変更することで、何百人ものユーザーが自分のジョブを実行する機能に影響を与える可能性があります。 そのため、変更を加える前に、潜在的な影響を理解していることを確認してください。

アクセス許可の継承とセキュリティ グループ

一部のアクセス許可は階層を通じて管理されます。 この階層内では、権限は親から継承することも、オーバーライドすることもできます。 セキュリティ グループは、グループのメンバーにアクセス許可のセットを割り当てます。 たとえば、共同作成者グループまたは Project 管理istrators グループのメンバーには、それらのグループに許可として設定されているアクセス許可が割り当てられます。

アクセス許可がユーザーに対して直接許可または拒否されていない場合は、次の方法で継承される可能性があります。

• ユーザーは、所属するグループからアクセス許可を継承します。 ユーザーが直接またはグループ メンバーシップ の許可 アクセス許可を持っている場合、直接またはグループ メンバーシップ の拒否 アクセス許可によってオーバーライドされます。

  Project Collection 管理istrators または Team Foundation 管理istrators のメンバーは、それらのアクセス許可を拒否する他のグループに属している場合でも、最も許可されているアクセス許可を保持します。 作業項目操作のアクセス許可は、この規則の例外です。

• 階層のノード (領域、イテレーション、バージョン 管理フォルダー、作業項目クエリ フォルダー) に割り当てられるオブジェクト レベルのアクセス許可は、階層の下位に継承されます。 つまり、同じアクセス許可が明示的に許可または拒否されていない場合、継承時に設定area-1されたユーザーのアクセス許可が継承されますarea-1/sub-area-1。area-1/sub-area-1 オブジェクトに対して権限が明示的に設定されている場合 (たとえば area-1/sub-area-1、親ノードが拒否または許可されているかどうかに関係なく)、親ノードは継承されません。 設定されていない場合、そのノードのアクセス許可は、アクセス許可が明示的に設定されている最も近い先祖から継承されます。 最後に、オブジェクト階層では、特定性が継承を切り捨てます。 たとえば、アクセス許可が明示的に 'area-1' で拒否に設定されているが、'area-1/sub-area-1' に対して明示的に許可に設定されているユーザーは、'area-1/sub-area-1' で許可を受け取ります。

アクセス許可が継承される理由を理解するには、アクセス許可の設定を一時停止し、[理由] を選択します。[セキュリティ] ページを開くには、「アクセス許可の表示」を参照してください。

Note

[プロジェクトの権限設定] ページのプレビュー ページを有効にするには、「プレビュー機能を有効にする」を参照してください。

[プレビュー] ページ

新しいダイアログが開き、そのアクセス許可の継承情報が表示されます。

現在のページ

新しいウィンドウが開き、そのアクセス許可の継承情報が表示されます。

アクセス許可のベスト プラクティス

推奨事項:

• 多数のユーザーを管理する場合は、Microsoft Entra ID、Active Directory、または Windows セキュリティ グループを使用します。
• チームを追加するときは、チーム リード、スクラム マスター、およびその他のチーム メンバーに割り当てるアクセス許可を検討します。 エリア パス、反復パス、クエリを作成および変更するユーザーを検討します。
• 多数のチームを追加する場合は、Project 管理istrators で使用できるアクセス許可のサブセットを割り当てることができる Team 管理istrators カスタム グループを作成することを検討してください。
• 作業項目クエリ フォルダーに、プロジェクトの作業項目クエリを作成および共有する機能を必要とするユーザーまたはグループに投稿権限を付与することを検討してください。

禁止事項:

• アクセス許可レベルが異なる複数のセキュリティ グループにユーザーを追加しないでください。 場合によっては、拒否アクセス許可レベルによって許可アクセス許可レベルがオーバーライドされることがあります。
• [有効なユーザー] グループに対する既定の割り当てを変更しないでください。 いずれかの有効なユーザー グループに対してインスタンスレベル情報の表示アクセス許可を削除するか、または 拒否に設定した場合は、設定したグループに応じて、そのグループ内のどのユーザーも、プロジェクト、コレクション、またはデプロイにアクセスできません。
• 'サービス アカウントにのみ割り当てます' と注記されているアクセス許可をユーザー アカウントに割り当てないでください。

ロール ベース アクセス許可

ロールベースのアクセス許可では、ロールにユーザー アカウントまたはセキュリティ グループを割り当て、各ロールには 1 つ以上のアクセス許可が割り当てられます。 主な役割と詳細情報へのリンクを次に示します。

• 成果物またはパッケージ フィードのセキュリティ ロール: ロールは、パッケージ フィードを編集および管理するためのさまざまなアクセス許可レベルをサポートします。
• Marketplace 拡張機能マネージャー ロール: マネージャー ロールのメンバーは、拡張機能をインストールし、拡張機能をインストールするための要求に応答できます。
• パイプライン セキュリティ ロール: ライブラリ リソース、プロジェクト レベル、およびコレクション レベルのパイプライン リソースを管理するために、いくつかのロールが使用されます。
• チーム管理者ロール チーム管理者は、すべてのチーム ツールを管理できます。

Project 管理istrators または Project Collection 管理istrators グループのメンバーは、すべてのチームのすべてのチーム ツールを管理できます。

プレビュー機能

機能フラグは、選択する新しい機能へのアクセスを制御します。 Azure DevOps では、機能フラグの後ろに配置することで、新機能が定期的に導入されています。 プロジェクト メンバーと組織の所有者は、プレビュー機能を有効または無効にすることができます。 詳細については、「機能の管理または有効化」を参照してください。

次のステップ

既定のアクセス許可とアクセス

関連記事

• アクセスとアクセス許可に関する問題のトラブルシューティング
• セキュリティ、認証、許可について
• Microsoft Entra Connect とは
• Microsoft Entra ID で開始する
• アクセス許可とグループのリファレンス
• セキュリティとアクセス許可の管理ツール
• 組織にユーザーを追加する
• セキュリティグループの追加と管理
• トークン、名前空間、アクセス許可を管理する
• 課金のしくみ
• Azure DevOps でのユーザー、パイプライン、クラウドベースのロード テストに対する課金を設定する