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

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 アクセス レベルが付与されます。 共同作成者グループは、リポジトリ、作業追跡、パイプラインなどへの読み取りおよび書き込みアクセスを提供します。 Basic アクセスを使用すると、Azure Boards、Azure Repos、Azure Pipelines、Azure Artifacts を使用するためのすべての機能とタスクにアクセスできます。 Azure Test Plansの管理にアクセスする必要があるユーザーには、Basic + Test Plans または Advanced アクセスを付与する必要があります。

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

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

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

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

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

ヒント

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

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

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

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

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

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

Note

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

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

ヒント

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

各グループと各アクセス許可の説明については、「 アクセス許可とグループのリファレンス」の「グループ」を参照してください。

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

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 を設定する必要があります。

Note

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

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

Note

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

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

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 グループに追加されたユーザーまたはグループは、[概要] ページと [プロジェクト] を除き、[組織の設定] ページへのアクセスが制限されます。は、追加先のプロジェクトにのみアクセスするように制限されます。

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

Note

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

Note

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

Note

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

アクセス レベル

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

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

アクセス許可

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

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

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

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

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

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

権限状態

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

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

アクセス許可の設定について知っておくべきことを次に示します。

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

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

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

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

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

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

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

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

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

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

  • 階層のノード (領域、イテレーション、バージョン管理フォルダー、作業項目クエリ フォルダー) に割り当てられるオブジェクト レベルのアクセス許可は、階層の下に継承されます。 つまり、同じアクセス許可が明示的に許可または拒否されていない場合、設定area-1されているユーザーのアクセス許可は継承されますarea-1/sub-area-1area-1/sub-area-1。 オブジェクトに対して権限が明示的に設定されている場合 (たとえば area-1/sub-area-1、親ノードが拒否または許可されているかどうかに関係なく)、親ノードは継承されません。 設定されていない場合、そのノードのアクセス許可は、アクセス許可が明示的に設定されている最も近い先祖から継承されます。 最後に、オブジェクト階層では、特定性が継承を切り捨てます。 たとえば、アクセス許可が明示的に 'area-1' で 拒否 に設定されているが、明示的に 'area-1/sub-area-1' に 対して許可 に設定されているユーザーは、最終的に 'area-1/sub-area-1' で 許可 を受け取ります。

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

Note

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

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

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

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

アクセス許可を割り当てる場合

推奨事項:

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

禁止事項:

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

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

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

プレビュー機能

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

次のステップ