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

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

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

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

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

アクセス レベル

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

アクセス許可

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

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

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

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

• 組織内またはプロジェクト コレクション内で最高の権限を保持します。
• コレクション全体のすべての操作を実行します。
• 組織の設定、ポリシー、およびプロセスを管理します。
• すべてのプロジェクトと拡張機能を作成して管理します。

プロジェクト管理者:

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

アクセス許可の状態

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

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

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

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

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

Project コレクション管理者または Team Foundation Administrators グループのメンバーは、別のグループで拒否された場合でも、常にアクセス許可を受け取ることがあります。 次の例では、このシナリオについてさらに説明します。

• ユーザーは引き続きプロジェクト設定にアクセスしたり、ユーザーを管理したりできます。 ただし、作業項目の削除やパイプライン管理などのタスクの場合、Project Collection Administrators グループのメンバーである場合、他の場所で設定 Deny アクセス許可はオーバーライドされません。
• ユーザーが特定のプロジェクトの作業項目を削除する権限を拒否された場合、プロジェクト コレクション管理者グループに含まれている場合でも、作業項目を削除することはできません。 同様に、パイプラインのアクセス許可が拒否された場合、管理ロールにもかかわらずパイプラインを管理または実行することはできません。

アクセス許可の継承

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

グループの継承:

• ユーザーは、所属するグループからアクセス許可を継承します。
• Allow 権限をユーザーが直接持っている場合や、グループ メンバーシップを通じて持っている場合でも、別のグループを通じて Deny 権限を持っている場合には、Deny 権限が優先されます。
• プロジェクト コレクション管理者または Team Foundation 管理者のメンバーは、それらのアクセス許可を拒否する他のグループ (作業項目の操作を除く) に属している場合でも、許可されているほとんどのアクセス許可を保持します。

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

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

アクセス許可の継承と特定性の規則:

• 明示的なアクセス許可は、常に継承されたアクセス許可よりも優先されます。
• 上位レベルのノードで設定されたアクセス許可は、明示的にオーバーライドされない限り、すべてのサブノードによって継承されます。
• サブノードに対して権限が明示的に許可または拒否されていない場合、その権限は親から継承されます。
• サブノードに対してアクセス許可が明示的に設定されている場合、親のアクセス許可は、許可されているか拒否されているかに関係なく継承されません。

特異 性：

オブジェクト階層では、特定性によって継承が切り捨てられます。 競合するアクセス許可が存在する場合は、最も具体的なアクセス許可が優先されます。

例:

• (親ノード) で明示的に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 Plans または Advanced アクセスが 必要です。

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

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

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

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

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

各機能領域では、デプロイの管理をシンプルにするためにセキュリティ グループを使用します。 ユーザーとグループを追加するには、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 つのプロジェクトに追加するすべてのユーザーは、コレクション内の他のプロジェクトのオブジェクトを表示できます。 ビューのアクセスを制限するには、エリア パス ノードを使用して制限を設定。 いずれかの有効なユーザー グループの インスタンス レベルの情報の表示 権限を削除または拒否した場合、グループのメンバーは、設定したグループに応じてプロジェクト、コレクション、または配置にアクセスできません。

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

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

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

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

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

プレビュー機能

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

次のステップ

関連コンテンツ