アクセス許可、アクセスおよびセキュリティ グループの概要

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

Azure DevOps 機能へのアクセスに関しては、次の主要な概念を理解しておくと役立ちます。

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

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

    • Azure DevOps に追加されたすべてのユーザーは 、アクセス レベルに割り当てられます。これにより、Web ポータル機能を選択するためのアクセスが許可または制限されます。
    • 主なアクセス レベルは、利害関係者BasicBasic + Test Plansの 3 つあります。
    • 利害関係者アクセスでは、制限された機能セットに対して無制限の数のユーザーに無料でアクセスできます。 詳細については、「 利害関係者アクセスクイック リファレンス」を参照してください
  • プレビュー機能について:
    • 新機能が導入されると、ユーザーは プレビュー機能 を使用してそれらを有効または無効にして、それらにアクセスできます。
    • 新機能の小さなサブセットは、組織レベルで管理され、組織の所有者によって有効または無効になります。

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

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

既定のアクセス許可の概要については、「 既定のアクセス許可のクイック リファレンス」を参照してください。

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

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

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

ヒント

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

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

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

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

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

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

注意

次の一覧は、TFS 2017 以降のバージョンで定義されている最新のグループを示しています。 以前のバージョンの Azure DevOps では、一覧が異なる場合があります。 Azure DevOps サービス アカウント グループにのみサービス アカウントを追加します。 有効なユーザー グループについては、この記事で後述 する「有効なユーザー グループ 」を参照してください。

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

ヒント

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

各グループと各アクセス許可の説明については、「 Permissions and groups reference, Groups」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

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

注意

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

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

注意

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

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

Azure DevOps は、Azure AD で発生した変更から 1 時間以内に Azure AD グループに加えられた変更を登録し、そのグループへのメンバーシップを介して継承されたすべてのアクセス許可を更新します。 さらに、Azure DevOps ユーザーは、Azure AD メンバーシップの更新と、Azure DevOps の継承されたアクセス許可をトリガーできます。この場合は、サインアウトしてもう一度サインインするか、更新をトリガー してアクセス許可を再評価できます

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

通常は、Azure DevOps Serverをインストールする前に Active Directory をインストールする必要があります。

有効なユーザー グループ

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

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

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

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

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

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

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

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

この機能を有効にするには、「 機能の管理または有効化」を参照してください。

注意

すべてのセキュリティ グループは、特定のプロジェクトに対するアクセス許可のみを持つグループであっても、組織レベルのエンティティです。 Web ポータルから、一部のセキュリティ グループの可視性は、ユーザーのアクセス許可に基づいて制限される場合があります。 ただし、 Azure devops CLI ツールまたは REST API を使用して、組織内のすべてのグループの名前を検出できます。 詳細については、「 セキュリティ グループの追加と管理」を参照してください。

注意

すべてのセキュリティ グループはコレクション レベルのエンティティであり、特定のプロジェクトに対するアクセス許可のみを持つグループも含まれます。 Web ポータルから、一部のセキュリティ グループの可視性は、ユーザーのアクセス許可に基づいて制限される場合があります。 ただし、 Azure devops CLI ツールまたは REST API を使用して、組織内のすべてのグループの名前を検出できます。 詳細については、「 セキュリティ グループの追加と管理」を参照してください。

注意

すべてのセキュリティ グループはコレクション レベルのエンティティであり、特定のプロジェクトに対するアクセス許可のみを持つグループも含まれます。 Web ポータルから、一部のセキュリティ グループの可視性は、ユーザーのアクセス許可に基づいて制限される場合があります。 ただし、REST API を使用して、組織内のすべてのグループの名前を検出できます。 詳細については、「 セキュリティ グループの追加と管理」を参照してください。

アクセス レベル

アクセス レベルは、Web ポータルでユーザーに表示される機能を制御し、ユーザー ライセンスに依存します。アクセス許可は、Azure DevOps に接続し、Azure DevOps 全体で機能を使用するユーザーの機能を制御します。 アジャイル ポートフォリオ管理またはテスト ケース管理機能へのアクセス権を他のユーザーに付与しようとしている場合は、アクセス許可ではなく アクセス レベルを変更する必要があります。

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

アクセス許可

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

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

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

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

セキュリティ グループとアクセス許可レベル、TFS-2018 以前のバージョンの概念図

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

権限状態

1 つのアクセス許可に対して 5 つの割り当てが可能です。 指定されたとおりにアクセスを許可または制限します。

  • ユーザーまたはグループには、タスクを実行するためのアクセス許可があります。
    • 許可
    • 継承された許可
  • ユーザーまたはグループには、タスクを実行するためのアクセス許可がありません。
    • Deny
    • 継承された拒否
    • 未設定

アクセス許可の設定について知る必要がある内容を次に示します。

  • 許可 または 拒否 は、ユーザーが特定のタスクを実行することを明示的に許可または制限し、通常はグループ メンバーシップから継承されます。

  • [設定しない ] では、そのアクセス許可を必要とするタスクをユーザーが実行する機能が暗黙的に拒否されますが、そのアクセス許可が設定されているグループのメンバーシップが優先されます (許可 (継承) または 継承された許可拒否 (継承) または 継承拒否とも呼ばれます)。

  • ほとんどのグループとほぼすべてのアクセス許可の場合、 拒否許可をオーバーライドします。 ユーザーが 2 つのグループに属し、そのうちの 1 つに特定のアクセス許可が Deny に設定されている場合、そのユーザーは、そのアクセス許可が [許可] に設定されているグループに属している場合でも、そのアクセス許可を必要とするタスクを実行できません。

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

  • グループのアクセス許可を変更すると、そのグループのメンバーであるすべてのユーザーに対する権限が変更されます。 つまり、グループのサイズによっては、1 つのアクセス許可を変更するだけで、数百人のユーザーのジョブに影響を与える可能性があります。 変更を加える前に影響について理解しておく必要があります。

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

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

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

  • ユーザーは、所属するグループからアクセス許可を継承します。 そのアクセス許可を持つグループ内のメンバーシップを通じてユーザーに対してアクセス許可が許可され、直接またはグループ メンバーシップを通じて拒否されると、アクセス許可は拒否されます。

    プロジェクト コレクション管理者または Team Foundation 管理者のメンバーは、それらのアクセス許可を拒否する他のグループに属している場合でも、許可されているアクセス許可が最も多く保持されます。 作業項目操作のアクセス許可は、この規則の例外です。

  • 階層のノード (領域、イテレーション、バージョン管理フォルダー、作業項目クエリ フォルダー) に割り当てられるオブジェクト レベルのアクセス許可は、階層に継承されます。 つまり、 に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' で 許可 を受け取ります。

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

注意

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

[アクセス許可] ダイアログ、プレビュー ページ、注釈が付いたリンクの理由。

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

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

アクセス許可を割り当てるときに

推奨事項:

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

禁止事項:

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

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

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

プレビュー機能

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

次のステップ