アクセス許可とセキュリティ グループについて

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

この記事では、Azure DevOps の継承、セキュリティ グループ、ロールなどを使用したアクセス レベルとアクセス許可について説明します。

既定のアクセス許可の概要については、既定のアクセス許可のクイック リファレンスに関する記事をご覧ください。 各既定のセキュリティ グループの説明については、「セキュリティ グループ、サービス アカウント、およびアクセス許可のリファレンス」を参照してください。

アクセス レベル

Azure DevOps に追加されたすべてのユーザーにはアクセス レベルが割り当てられ、特定の Web ポータル機能へのアクセスが許可または制限されます。

主なアクセス レベルは、利害関係者、基本、基本 + テスト プランの 3 つです。 利害関係者アクセスでは、制限された機能セットに対して無制限の数のユーザーに無料でアクセスできます。 詳細については、「利害関係者アクセスクイック リファレンス」を参照してください。

アジャイル ポートフォリオ管理またはテスト ケース管理機能へのアクセス権をユーザーに付与するには、 アクセス許可ではなくアクセス レベルを変更します。 詳細については、「アクセス レベルについて」を参照してください。

アクセス許可

Azure DevOps に追加されたすべてのユーザーは、1 つ以上の既定 のセキュリティ グループに追加されます。 セキュリティ グループには、機能またはタスクへのアクセスを許可または拒否するアクセス許可が割り当てられます。

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

Azure DevOps でのアクセス許可の管理に関しては、プロジェクト コレクション管理者とプロジェクト管理者の 2 つの主要なグループが関係します。 いくつかに分けてみましょう。

プロジェクト コレクション管理者:

• これらの個人は、組織内またはプロジェクト コレクション内で最高レベルの権限を持っています。
• コレクション全体のすべての操作を実行できます。
• その責任には、組織の設定、ポリシー、およびプロセスの管理が含まれます。
• さらに、組織内のすべてのプロジェクトと拡張機能を作成および管理できます。

プロジェクト管理者:

• プロジェクト管理者は、プロジェクト レベルで動作します。
• セキュリティ グループとアクセス許可は、主に Web ポータルのプロジェクト設定から管理します。
• 一方、共同作成者は、プロジェクト内で作成した特定のオブジェクトに対するアクセス許可を処理します。

アクセス許可の状態

次の方法でアクセス許可を割り当て、指示に従ってアクセスを許可または制限できます。

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

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

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

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

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

場合によっては、プロジェクト コレクション管理者または Team Foundation Administrators グループのメンバーは、別のグループでそのアクセス許可が拒否された場合でも、常にアクセス許可を取得することがあります。 作業項目の削除やパイプラインなど、プロジェクト コレクション管理者グループのメンバーである場合は、他の場所で設定された拒否アクセス許可はバイパスされません。

警告

グループのアクセス許可を変更すると、そのグループ内のすべてのユーザーに影響します。 1 つのアクセス許可の変更であっても、数百人のユーザーに影響を与える可能性があるため、調整を行う前に潜在的な影響を考慮することが重要です。

アクセス許可の継承

権限は階層に従い、親からの継承またはオーバーライドを許可します。

• グループの継承: ユーザーは、所属するグループからアクセス許可を継承します。 ユーザーが直接またはグループ メンバーシップを通じて許可アクセス許可を持っていても、別のグループを通じて拒否アクセス許可を持っている場合は、拒否アクセス許可が優先されます。 ただし、プロジェクト コレクション管理者または Team Foundation 管理者のメンバーは、それらのアクセス許可を拒否する他のグループ (作業項目の操作を除く) に属している場合でも、許可されているほとんどのアクセス許可を保持します。
• オブジェクト レベルの継承: オブジェクト レベルのアクセス許可 (領域、イテレーション、バージョン 管理フォルダー、作業項目クエリ フォルダーなどのノードに割り当てられる) は、階層に継承されます。

たとえば、アクセス許可の継承と特定性の規則を分解し、明示的なアクセス許可は常に継承されたアクセス許可よりも優先されます。

• ユーザーのアクセス許可が上位ノード (領域 1) で設定されている場合、明示的にオーバーライドされない限り、それらのアクセス許可はすべてのサブノード (領域 1/サブ領域-1) によって継承されます。
• サブノードに対して権限が 明示的に許可または拒否されていない 場合、その権限は親から継承されます。
• ただし、サブノード (area-1/sub-area-1) に対して権限が明示的に設定されている場合、親のアクセス許可は 、許可されているか拒否されているかに関係なく継承されません 。 特異 性：
• オブジェクト階層では、特定性によって継承が切り捨てられます。 つまり、競合するアクセス許可が存在する場合は、最も具体的なアクセス許可が優先されます。
• たとえば、次のようなユーザーを考えてみましょう。
  • 'area-1' (親ノード) で明示的に 拒否 します。
  • 'area-1/sub-area-1' を明示的に 許可 します (子ノード)。
• この場合、ユーザーは 'area-1/sub-area-1' で許可を受け取り、親ノードから継承された Deny をオーバーライドします。

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

Note

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

[プレビュー] ページ

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

現在のページ

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

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

セキュリティ グループは、メンバーに特定のアクセス許可を割り当てます。

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

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

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

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

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

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

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

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

チーム、エリア、イテレーション パス、リポジトリ、サービス フック、サービス エンドポイントなどのプロジェクト レベルの機能の管理を行うユーザーの場合は、プロジェクト管理者グループに追加します。

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

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

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 つのプロジェクトに追加するすべてのユーザーは、コレクション内の他のプロジェクトのオブジェクトを表示できます。 ビューのアクセスを制限するには、エリア パス ノードを使用して制限を設定します。

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

プロジェクト スコープのユーザー グループ

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

重要

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

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

警告

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

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

Note

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

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

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

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

詳細については、「セキュリティ ロールについて」を参照してください。

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

プロジェクト管理者グループまたはプロジェクト コレクション管理者グループのメンバーは、すべてのチームのすべてのチーム ツールを管理できます。

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

推奨事項:

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

禁止事項:

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

プレビュー機能

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

次のステップ

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

関連記事

• アクセスとアクセス許可に関する問題のトラブルシューティング
• セキュリティ、認証、許可について
• アクセス許可とグループのリファレンス
• セキュリティとアクセス許可の管理ツール
• セキュリティグループの追加と管理