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

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022

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

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

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

アクセス レベル

すべての Azure DevOps ユーザーには、特定の Web ポータル機能へのアクセスを許可または制限する アクセス レベルがあります。 主に、 利害関係者、 基本、および 基本 + テスト計画の 3 つの主要なアクセス レベルが存在します。 アジャイル ポートフォリオ管理またはテスト ケース管理機能へのアクセス権をユーザーに付与するには、アクセス許可ではなくアクセス レベル変更します。 詳細については、「アクセス レベルについて」を参照してください。

アクセス許可

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

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

Azure DevOps でのアクセス許可の管理には、プロジェクト コレクション管理者とプロジェクト管理者の 2 つの主要なグループが含まれます。

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

• 組織内またはプロジェクト コレクション内で広範な管理アクセス許可を持つ。
• 組織の設定、ポリシー、およびプロセスを管理します。
• プロジェクトを作成および管理します。

プロジェクト管理者:

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

アクセス許可の状態

アクセスを許可または制限するアクセス許可を割り当てます。

ユーザーまたはグループにアクセス許可があります。

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

ユーザーまたはグループにアクセス許可がありません。

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

Azure DevOpsは、直接割り当て、グループ メンバーシップ、継承された割り当てから有効なアクセス許可を計算します。 同じスコープで割り当てを結合する場合、通常、 拒否 が 許可よりも優先されます。 オブジェクト階層では、子オブジェクトに対する明示的な割り当てによって、親から継承された値を同じ ID に置き換えることができます。

アクセス許可の継承

権限は階層に従うので、親ノードから権限を継承したり、オーバーライドしたりできます。

グループの継承:

• ユーザーは、所属するグループの結合されたアクセス許可を受け取ります。
• 同じスコープでは、通常、あるグループからの 拒否 が別のグループからの 許可 よりも優先されます。
• [設定しない ] はアクセス許可を付与または拒否せず、別のグループからの割り当てをオーバーライドしません。

オブジェクト レベルの継承:

領域、イテレーション、バージョン 管理フォルダー、作業項目クエリ フォルダーなどのノードにオブジェクト レベルのアクセス許可を割り当てます。 これらのアクセス許可は階層の下に継承されます。

オブジェクト階層ルール:

• 上位レベルのノードで設定されたアクセス許可は、明示的にオーバーライドされない限り、すべてのサブノードによって継承されます。
• サブノードに対して権限が明示的に許可または拒否されていない場合、その権限は親から継承されます。
• サブノード上の ID に対して権限が明示的に設定されている場合、その ID の親から継承された値はサブノードには適用されません。
• オブジェクト階層を解決した後、Azure DevOpsは、該当する直接割り当てとグループ割り当てを結合します。 結果のスコープの別のグループからの 拒否 は、引き続き 許可よりも優先されます。

例:

• (親ノード) で明示的にarea-1します。
• を明示的にarea-1/sub-area-1する (子ノード)。
• この場合、ユーザーは でarea-1/sub-area-1を受け取り、親ノードから継承された拒否をオーバーライドします。

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

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

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

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

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

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

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

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

プロジェクト レベルの機能を管理するユーザーを プロジェクト管理者 グループに追加します。 これらの機能には、チーム、領域、反復パス、リポジトリ、サービス フック、およびサービス エンドポイントが含まれます。

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

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

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

• メンバーシップ管理では、個々のユーザー アカウントおよびグループを既定のセキュリティ グループに追加する操作がサポートされています。 各既定グループは、既定のアクセス許可のセットに関連付けられています。 セキュリティ グループに追加されたすべてのユーザーは、有効なユーザー グループに追加されます。 有効なユーザーとは、プロジェクト、コレクション、または組織に接続できるユーザーのことです。
• アクセス許可の管理では、システムのさまざまなレベルで特定の機能タスクへのアクセスを制御します。 オブジェクト レベルのアクセス許可は、ファイル、フォルダー、ビルド パイプライン、または共有クエリに対するアクセス許可を設定します。 アクセス許可の設定は、 Allow、 Deny、 Inherited allow、 Inherited deny、 System allow、 System deny、および Not set に対応。
• アクセス レベルの管理 Web ポータル機能へのアクセスを制御します。 管理者は、ライセンスとユーザーのロールに基づいて、利害関係者、Basic、Basic + Test Plans、または適用可能なVisual Studioサブスクリプション アクセス レベルを割り当てます。

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

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 を構成することが不可欠です。

有効なユーザー グループ

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

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

プロジェクト リソースにアクセスするには、ユーザーは プロジェクト レベルの情報 と、特定のリソースに必要なアクセス許可を表示する必要があります。 領域パスのアクセス許可 は、プロジェクト内の作業項目とテスト成果物へのアクセスを制御します。ユーザーがプロジェクトにアクセスできるかどうかを制御しません。 有効なユーザー グループの既定のアクセス許可は変更しないでください。 プロジェクト レベルの情報の表示、コレクション レベルの情報の表示、またはこれらのグループのいずれかに対するインスタンス レベルの情報の表示を拒否すると、対応するスコープからすべてのメンバーをブロックできます。

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

ロールベースのアクセス許可では、ユーザー アカウントまたはセキュリティ グループをロールに割り当て、各ロールには 1 つ以上のアクセス許可があります。 次のリソースは、ロールベースのアクセス許可をサポートしています。

• アーティファクトまたはパッケージ フィードのセキュリティ ロール
• Marketplace 拡張機能マネージャーロール
• パイプライン セキュリティ ロール
• チーム管理者ロール

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

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

プレビュー機能

プレビュー機能は、一般公開される前に機能に早期にアクセスできるようにします。 ユーザーは、ユーザー レベルで提供されるプレビュー機能を管理できます。 Project コレクション管理者グループのメンバーは、Azure DevOps Services の組織レベルのプレビュー機能と、Azure DevOps Serverのコレクション レベルのプレビュー機能を管理できます。 詳細については、「 機能の管理または有効化を参照してください。

次のステップ

関連コンテンツ