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

  • [アーティクル]

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

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

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

詳細については、「セキュリティのベスト プラクティス」を参照してください。

アクセス レベル

すべての Azure DevOps ユーザーには、特定の Web ポータル機能へのアクセスを許可または制限する アクセス レベルがあります。

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

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

アクセス許可

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

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

詳細については、「 セキュリティのベスト プラクティス、セキュリティとユーザー グループを参照してください。

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

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

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

プロジェクト管理者:

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

アクセス許可の状態

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

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

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

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

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

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

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

警告

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

アクセス許可の継承

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

グループの継承:

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

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

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

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

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

特異 性：

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

例:

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

アクセス許可が継承される理由を理解するには、アクセス許可の設定を一時停止し、Why?Security ページを開くには、「アクセス許可の表示」を参照してください。

Note

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

[アクセス許可] ダイアログ、[プレビュー] ページ、[リンクに注釈が付いている理由] を示すスクリーンショット。

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

[プロジェクトのアクセス許可の設定] ページのプレビュー ユーザー インターフェイスは、Azure DevOps Server 2020 以前のバージョンでは使用できません。

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

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

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

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

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

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

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

次のセキュリティ グループは、プロジェクトと組織ごとに既定で定義されます。 通常、ユーザーまたはグループは、 Readers、 Contributors、または Project Administrators グループに追加します。

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

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

次のセキュリティ グループは、各プロジェクトとプロジェクト コレクションに対して既定で定義されます。 通常、ユーザーまたはグループは、 Readers、 Contributors、または Project Administrators グループに追加します。

Azure DevOps サービス アカウント グループにのみサービス アカウントを追加します。 有効なユーザー グループを理解するには、この記事で後述する Valid ユーザー グループ を参照してください。

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

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

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

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

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

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

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

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

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

ローカル グループまたは Active Directory (AD) グループを作成して、ユーザーを管理できます。

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 を使用して組織のアクセスを管理するには、次の記事を参照してください。

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

Azure DevOps Server で使用する Active Directory を設定するには、次の記事を参照してください。

Azure DevOps Server をインストールする前に Active Directory をインストールします。

有効なユーザー グループ

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

  • プロジェクト コレクションの有効なユーザー:組織レベルのグループに追加されたすべてのメンバー。
  • プロジェクトの有効なユーザー:プロジェクト レベルのグループに追加されたすべてのメンバー。
  • サーバー\Azure DevOps の有効なユーザー: サーバー レベルのグループに追加されたすべてのメンバー。
  • ProjectCollectionName\Project Collection Valid Users: コレクション レベルのグループに追加されたすべてのメンバー。
  • ProjectName\Project Valid Users: プロジェクト レベルのグループに追加されたすべてのメンバー。

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

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

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

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

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

重要

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

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

警告

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

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

Note

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

Note

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

Note

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

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

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

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

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

既定のセキュリティ グループをアクセス許可レベル、クラウドにマッピングする概念イメージ

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

既定のセキュリティ グループをアクセス許可レベル (オンプレミス) にマッピングする概念イメージ

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

プレビュー機能

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

次のステップ

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