アクセス許可、アクセス、およびセキュリティグループの概要Get started with permissions, access, and security groups

Azure DevOps Services |Azure DevOps Server 2020 |Azure DevOps Server 2019 |TFS 2018-TFS 2013Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2013

Azure DevOps 機能にアクセスする場合は、次の主要な概念を理解することをお勧めします。When it comes to accessing an Azure DevOps feature, it's helpful to understand the following key concepts.

  • Azure DevOps に追加されたすべてのユーザーは、通常、1つまたは複数の セキュリティグループ に追加されます。All users added to Azure DevOps are typically added to one or more security groups.
  • セキュリティグループには、機能へのアクセスを許可または拒否する アクセス許可 が割り当てられます。Security groups are assigned permissions which either allow or deny access to a feature.
  • セキュリティグループのメンバーは、そのグループに割り当てられた アクセス許可を継承 します。Members of the security group inherit the permissions assigned to the group.
  • また、各ユーザーには アクセスレベル が割り当てられ、web ポータルの機能を選択するためのアクセス権が付与または制限されます。Each user is also assigned an access level which grants or restricts access to select web portal features.
  • アクセス許可は、リポジトリ、パイプライン、区分パスなど、ほとんどのオブジェクトに対してさまざまなレベルで設定されます。Permissions are set at various levels for most objects, such as repositories, pipelines, area paths, and so on.
  • その他のアクセス許可は、チーム管理者ロール、拡張管理ロール、さまざまなパイプラインリソースロールなどの ロールベースの割り当て によって管理されます。Other permissions are managed through role-based assignments, such as team administrator role, extension management role, and various pipeline resource roles.
  • 最後に、新機能が導入されると、それらの機能にアクセスするには、 機能フラグ を有効にする必要があります。And finally, as new features are introduced you may need to enable their feature flag to access them.

たとえば、個々の共同作成者は、リポジトリ、作業追跡、パイプラインなどに対する読み取りおよび書き込みアクセスを提供するコントリビューターセキュリティグループに追加されます。For example, individual contributors are added to the Contributors security group which provides read and write access to repositories, work tracking, pipelines, and more. また、共同作成者には主に基本的なアクセス権が付与されます。Also, Contributors are primarily granted Basic access. テストサービスへのアクセスが必要な場合は、Advanced または Basic + Test Plans アクセス権が付与されることがあります。If they need access to test services, then they may be granted Advanced or Basic + Test Plans access. アクセス許可は、Git リポジトリ、ブランチ、パイプライン、区分パスなど、プロジェクト内の特定のプロジェクトまたはオブジェクトに適用できます。Permissions may apply to a specific project or objects within the project, such as Git repositories, branches, pipelines, area paths, and more. または、組織全体またはコレクションに適用することもできます。Or, they can apply to an entire organization or collection. 各機能領域では、セキュリティグループを使用して、展開全体の管理を簡略化します。Each functional area uses security groups to simplify management across the deployment.

管理者は、web ポータルの管理コンテキストからセキュリティグループとアクセス許可を管理します。Administrators manage security groups and permissions from the web portal administration context. 共同作成者は、web ポータルから作成または所有するオブジェクトのアクセス許可も管理します。Contributors manage permissions for objects they create or own from the web portal as well. 権限は、ユーザーを追加するグループ、またはユーザーまたはグループを追加するオブジェクト、プロジェクト、コレクション、またはサーバーレベルに基づいて自動的に設定されます。Permissions are automatically set based on the group that you add users to, or based on the object, project, collection, or server-level to which you add users or groups.

ヒント

複数のセキュリティグループに割り当てられているユーザーアカウントは、 最小限のアクセス 権を付与するアクセス許可に制限されます。User accounts that are assigned to more than one security group are restricted to those permissions granting the least access. たとえば、閲覧者グループとプロジェクト管理者グループにユーザーを追加すると、そのユーザーに対して閲覧者グループの有効なアクセス許可が適用されます。For example, if you add a user to the Readers group and the Project Administrators group, the effective permissions of the Readers group are enforced for the user.

詳細については、この記事と次の記事に記載されている情報を参照してください。To learn more, review the information provided in this article and the following articles:

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

組織、コレクション、またはプロジェクトを作成すると、既定 — のアクセス許可が自動的に割り当てられる既定のセキュリティグループのセットが作成されます。With the creation of an organization, collection, or project—Azure DevOps creates a set of default security groups which are automatically assigned default permissions. 追加のセキュリティグループは、次のアクションを使用して定義されます。Additional security groups are defined with the following actions:

  • カスタムセキュリティグループを追加する場合。When you add a custom security group. カスタムセキュリティグループは、次のレベルで作成できます。You can create custom security groups at the following levels:
    • オブジェクト レベルObject-level
    • プロジェクト レベルProject-level
    • 組織またはコレクションレベルOrganization- or collection-level
    • サーバーレベル (オンプレミスのみ)Server-level (on-premises only)
  • チームを追加すると、チームセキュリティグループが作成されます。When you add a team, a team security group is created

Azure DevOps は、接続されている次の3つの機能領域を介してアクセスを制御します。Azure DevOps controls access through these three inter-connected functional areas:

  • メンバーシップ管理 は、個々のユーザーアカウントとグループを既定のセキュリティグループに追加することをサポートしています。Membership management supports adding individual user accounts and groups to default security groups. 既定の各グループは、一連の既定のアクセス許可に関連付けられています。Each default group is associated with a set of default permissions. 任意のセキュリティグループに追加されたすべてのユーザーが、有効なユーザーグループに追加されます。All users added to any security group are added to the Valid Users group. 有効なユーザーとは、プロジェクト、コレクション、または組織に接続できるユーザーのことです。A valid user is someone who can connect to a project, collection, or organization.

  • アクセス許可の管理 は、システムのさまざまなレベルでの特定の機能タスクへのアクセスを制御します。Permission management controls access to specific functional tasks at different levels of the system. オブジェクトレベルのアクセス許可は、ファイル、フォルダー、ビルドパイプライン、または共有クエリに対するアクセス許可を設定します。Object-level permissions set permissions on a file, folder, build pipeline, or a shared query. アクセス許可の設定は、 許可拒否継承 された許可、継承された 拒否、および 未設定 に対応します。Permission settings correspond to Allow, Deny, Inherited allow, Inherited deny, and Not set. 継承の詳細については、この記事で後述する「 アクセス許可の継承とセキュリティグループ 」を参照してください。To learn more about inheritance, see Permission inheritance and security groups later in this article.

  • アクセスレベル管理 は、web ポータル (Azure DevOps の web アプリケーション) を介して提供される機能へのアクセスを制御します。Access level management controls access to features provided via the web portal, the web application for Azure DevOps. 管理者は、ユーザーに対して購入された内容に基づいて、ユーザーのアクセスレベルを Basic、Basic + Test、VS Enterprise (以前は上級)、または利害関係者に設定します。Based on what has been purchased for a user, administrators set the user's access level to Basic, Basic + Test, VS Enterprise (previously Advanced), or Stakeholder.

各機能領域では、セキュリティグループを使用して、展開全体の管理を簡略化します。Each functional area uses security groups to simplify management across the deployment. Web 管理コンテキストを使用して、ユーザーとグループを追加します。You add users and groups through the web administration context. アクセス許可は、ユーザーを追加するセキュリティグループ、またはグループを追加するオブジェクト、プロジェクト、コレクション、またはサーバーレベルに基づいて自動的に設定されます。Permissions are automatically set based on the security group that you add users to, or based on the object, project, collection, or server level to which you add groups.

セキュリティグループのメンバーは、ユーザー、他のグループ、および Azure Active Directory グループの組み合わせにすることができます。Security group members can be a combination of users, other groups, and Azure Active Directory groups.

セキュリティグループのメンバーは、ユーザー、他のグループ、Active Directory グループ、またはワークグループの組み合わせにすることができます。Security group members can be a combination of users, other groups, and Active Directory groups or a Workgroup.

ローカルグループまたは Active Directory (AD) グループを作成して、ユーザーを管理できます。You can create local groups or Active Directory (AD) groups to manage your users. グループを使用する場合は、それらのグループのメンバーシップが有効なユーザーに制限されていることを確認してください。If you decide to use groups, make sure that membership in those groups is limited to valid users. グループのメンバーシップはいつでも所有者が変更できるので、これらの所有者がグループを作成したときに Azure DevOps Server アクセスを考慮しないと、メンバーシップに対する変更によって、サーバー内で望ましくない副作用が発生する可能性があります。Because group membership can be altered by their owners at any time, if those owners did not consider Azure DevOps Server access when they created those groups, their changes to membership can cause unwanted side effects within the server.

ほとんどのユーザーは、プロジェクトの貢献者グループに割り当てられ、アクセスするために必要な機能へのアクセスを提供します。Most users are assigned to the Contributors group for a project to provide them access to the features they need to access. 管理者は、プロジェクトコレクション管理者またはプロジェクト管理者グループに追加する必要があります。Administrators should be added to the Project Collection Administrators or Project Administrators group.

セキュリティグループの Active Directory と Azure Active DirectoryActive Directory and Azure Active Directory security groups

個々のユーザーを追加することで、セキュリティグループを設定できます。You can populate security groups by adding individual users. ただし、管理を容易にするために、Azure DevOps Server の Azure DevOps Services および Active Directory (AD) または Windows ユーザーグループに Azure Active Directory (Azure AD) を使用してこれらのグループを設定する方が簡単です。However, for ease of management, it's easier if you populate these groups by using Azure Active Directory (Azure AD) for Azure DevOps Services and Active Directory (AD) or Windows user groups for Azure DevOps Server. この方法を使用すると、複数のコンピューターでグループのメンバーシップとアクセス許可をより効率的に管理できます。This method enables you to manage group membership and permissions more efficiently across multiple computers.

少数のユーザーだけを管理する必要がある場合は、この手順を省略できます。If you only have to manage a small set of users, then you can skip this step. ただし、組織が成長する可能性があると予想される場合は、AD または Azure AD を設定することをお勧めします。However, if you foresee that your organization may grow, you may want to set up AD or Azure AD. また、追加のサービスの支払いを計画している場合は、課金をサポートするために Azure DevOps で使用するために Azure AD を設定する必要があります。Also, if you plan on paying for extra services, you'll need to set up Azure AD for use with Azure DevOps to support billing.

注意

Azure AD ない場合は、すべての Azure DevOps ユーザーが Microsoft アカウントを使用してサインインする必要があります。また、個々のユーザーアカウントでアカウントへのアクセスを管理する必要があります。Without Azure AD, all Azure DevOps users must sign in using Microsoft accounts, and you must manage account access by individual user accounts. Microsoft アカウントを使用してアカウントアクセスを管理している場合でも、 課金を管理するために Azure サブスクリプションを設定する必要があります。Even if you manage account access using Microsoft accounts, you need to set up an Azure subscription in order to manage billing.

Azure DevOps Services で使用する Azure Active Directory を設定するには、「 Azure Active Directory に組織を接続する」を参照してください。To set up Azure Active Directory for use with Azure DevOps Services, see Connect your organization to Azure Active Directory.

注意

組織が Azure Active Directory に接続されている場合は、組織をセキュリティで保護するために有効または無効にできる組織ポリシーがいくつかあります。When your organization is connected to Azure Active Directory, there are a number of organization policies which you can enable or disabled to secure your organization. 詳細については、「 セキュリティ、認証、および承認、セキュリティポリシーについて」を参照してください。To learn more, see About security, authentication, and authorization, Security-policies.

Azure AD を使用して組織のアクセスを管理するには、次の記事を参照してください。To manage organizational access with Azure AD, refer to the following articles:

Azure DevOps Server で使用する Active Directory を設定するには、次の記事を参照してください。To set up Active Directory for use with Azure DevOps Server, see the following articles:

通常は、Azure DevOps Server をインストールする前に Active Directory をインストールする必要があります。Typically, you should install Active Directory prior to installing Azure DevOps Server.

有効なユーザーグループValid user groups

ユーザーのアカウントをセキュリティグループに直接追加すると、そのユーザーは有効なユーザーグループの1つに自動的に追加されます。When you add accounts of users directly to a security group, they are automatically added to one of the valid user groups.

  • プロジェクトコレクションの有効なユーザー: 組織レベルのグループに追加されたすべてのメンバー。Project Collection Valid Users: All members added to an organization-level groups.
  • プロジェクトの有効なユーザー: プロジェクトレベルグループに追加されたすべてのメンバー。Project Valid Users: All members added to a project-level group.
  • サーバー \Azure DevOps の有効なユーザー: サーバーレベルグループに追加されたすべてのメンバー。Server\Azure DevOps Valid Users: All members added to server-level groups.
  • ProjectCollectionName \プロジェクトコレクションの有効なユーザー: コレクションレベルグループに追加されたすべてのメンバー。ProjectCollectionName\Project Collection Valid Users: All members added to collection-level groups.
  • ProjectName \プロジェクトの有効なユーザー: プロジェクトレベルのグループに追加されたすべてのメンバー。ProjectName\Project Valid Users: All members added to project-level groups.
  • サーバー \Team Foundation 有効ユーザー: サーバーレベルグループに追加されたすべてのメンバー。Server\Team Foundation Valid Users: All members added to server-level groups.
  • ProjectCollectionName \プロジェクトコレクションの有効なユーザー: コレクションレベルグループに追加されたすべてのメンバー。ProjectCollectionName\Project Collection Valid Users: All members added to collection-level groups.
  • ProjectName \プロジェクトの有効なユーザー: プロジェクトレベルのグループに追加されたすべてのメンバー。ProjectName\Project Valid Users: All members added to project-level groups.

これらのグループに割り当てられた既定のアクセス許可は、主に読み取りアクセスに限定されます。たとえば、 ビルドリソースの表示プロジェクトレベル情報の表示コレクションレベル情報の表示 などです。The default permissions assigned to these groups are primarily limited to read access, such as View build resources, View project-level information, and View collection-level information.

これは、1つのプロジェクトに追加したすべてのユーザーが、コレクション内の他のプロジェクトのオブジェクトを表示できることを意味します。This means that all users that you add to one project can view the objects in other projects within a collection. ビューのアクセスを制限する必要がある場合は、 [区分パス] ノードを使用して制限を設定できます。If you need to restrict view access, then you can set restrictions through the area path node.

有効なユーザーグループの1つに対して [ インスタンスレベル情報の表示 ] アクセス許可を削除または拒否すると、設定したグループに応じて、そのグループのメンバーは、プロジェクト、コレクション、または配置にアクセスできなくなります。If you remove or deny the View instance-level information permission for one of the valid users groups, no members of the group are able to access the project, collection, or deployment, depending on the group you set.

プロジェクトスコープのユーザーグループProject-scoped User group

既定では、組織に追加されたユーザーは、すべての組織とプロジェクトの情報および設定を表示できます。By default, users added to an organization can view all organization and project information and settings. これには、 組織の設定 によってアクセスされるユーザー、プロジェクトの一覧、請求の詳細、使用状況データなどが表示されます。This includes viewing list of users, list of projects, billing details, usage data, and more that is accessed through Organization Settings.

利害関係者、Azure Active Directory ゲストユーザー、特定のセキュリティグループのメンバーなど、選択したユーザーを制限するには、組織の [ プロジェクトのユーザー表示を制限 する] プレビュー機能を有効にします。To restrict select users, such as Stakeholders, Azure Active Directory guest users, or members of a particular security group, you can enable the Limit user visibility for projects preview feature for the organization. このオプションを有効にすると、プロジェクトスコープのユーザー グループに追加されたすべてのユーザーまたはグループは、概要プロジェクト を除き、組織の設定 ページへのアクセスが制限されます。とは、それらが追加されたプロジェクトにのみアクセスできるように制限されています。Once that is enabled, any user or group added to the Project-Scoped Users group, are restricted from accessing the Organization Settings pages, except for Overview and Projects; and are restricted to accessing only those projects to which they've been added to.

この機能を有効にするには、「 機能の管理または有効化」を参照してください。To enable this feature, see Manage or enable features.

注意

すべてのセキュリティグループは、特定のプロジェクトへのアクセス許可のみを持つグループであっても、組織レベルのエンティティです。All security groups are organization-level entities, even those groups that only have permissions to a specific project. Web ポータルでは、プロジェクトにアクセスできないユーザーは、特定のプロジェクトへのアクセス許可のみを持つグループを表示することはできません。From the web portal, users without access to a project can't see those groups which only have permissions to a specific project. ただし、 azure devops CLI ツールまたは REST api を使用して、組織内のすべてのグループの名前を検出することができます。However, you can discover the names of all groups in an organization using the azure devops CLI tool or our REST APIs. 詳細については、「 セキュリティグループの追加と管理」を参照してください。To learn more, see Add and manage security groups.

アクセス レベルAccess levels

アクセスレベルは、web ポータルでユーザーに表示される機能を制御し、ユーザーライセンスに依存します。アクセス許可は、azure DevOps に接続し、Azure DevOps 全体で機能を使用するユーザーの能力を制御します。Access levels control what features are visible to users in the web portal, and are dependent on user licenses; permissions control a user's ability to connect to Azure DevOps and use features across Azure DevOps. アジャイルポートフォリオ管理またはテストケース管理機能へのアクセス権を他のユーザーに付与しようとしている場合は、アクセス許可ではなく アクセスレベルを変更することをお勧めします。If you're trying to give someone access to Agile portfolio management or test case management features, you'll want to change access levels, not permissions.

ユーザーまたはグループのアクセスレベルを設定しても、プロジェクトまたは web ポータルへのアクセス権は付与されません。Setting the access level for users or groups doesn't provide them access to a project or the web portal. チームまたはセキュリティグループに追加されたユーザーまたはグループのみが、プロジェクトと web ポータルに接続できます。Only users or groups added to a team or security group can connect to a project and the web portal. ユーザーが必要なアクセス許可とアクセスレベルの両方を持っていることを確認します。Make sure your users have both the permissions and the access level they need. これを行うには、 プロジェクトまたはチームに追加されていることを確認します。You do this by making sure they're added to the project or a team.

アクセス許可Permissions

次の図に示すように、プロジェクトおよびコレクションレベルで定義されているセキュリティグループは、オブジェクト、プロジェクト、および組織レベルで割り当てられたアクセス許可に割り当てることができます。As shown in the following image, security groups defined at the project and collection-level can be assigned to permissions assigned at the object, project, and organization-level.

概念図既定のセキュリティグループからアクセス許可レベルへのマッピング、クラウド

次の図に示すように、プロジェクトで定義されているセキュリティグループとコレクションレベルは、オブジェクト、プロジェクト、およびコレクションレベルで割り当てられたアクセス許可に割り当てることができます。As shown in the following image, security groups defined at the project and collection-level can be assigned to permissions assigned at the object, project, and collection level. サーバーレベルのセキュリティグループは、サーバーレベルのアクセス許可に対してのみ定義できます。You can only define server-level security groups to server-level permissions.

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

セキュリティグループとアクセス許可レベルの概念図 (TFS-2018 およびそれ以前のバージョン)

各既定のセキュリティグループの説明については、「 セキュリティグループ、サービスアカウント、およびアクセス許可」を参照してください。For a description of each default security group, see Security groups, service accounts, and permissions.

権限状態Permission states

アクセス許可に対して割り当てられる5つの割り当てがあります。There are five possible assignments made to a permission. これらのユーザーは、指示に従ってアクセスを許可または制限します。They grant or restrict access as indicated.

  • ユーザーまたはグループには、タスクを実行する権限があります。User or group has permissions to perform a task:
    • 許可Allow
    • 継承された許可Inherited allow
  • ユーザーまたはグループにタスクを実行するためのアクセス許可がありません:User or group doesn't have permission to perform a task:
    • DenyDeny
    • 継承された拒否Inherited deny
    • 未設定Not set

アクセス許可の設定について理解しておく必要があるものは次のとおりです。Here's what you need to know about permission settings:

  • Allow または Deny は、ユーザーに特定のタスクの実行を明示的に許可または制限します。通常、グループのメンバーシップから継承されます。Allow or Deny explicitly grants or restricts users from performing specific tasks, and are usually inherited from group membership.

  • [設定なし] に設定すると、ユーザーはそのアクセス許可を必要とするタスクを実行できなくなります。ただし、アクセス許可セットが優先されるグループのメンバーシップ (許可 (継承) または継承された 許可拒否 ( 継承) または継承された 拒否) が許可されます。Not set implicitly denies users the ability to perform tasks that require that permission, but allows membership in a group that does have that permission set to take precedence, also known as Allow (inherited) or Inherited allow and Deny (inherited) or Inherited deny.

  • ほとんどのグループおよびほとんどのアクセス許可では、 拒否 のオーバーライドが 許可 されます。For most groups and almost all permissions, Deny overrides Allow. ユーザーが2つのグループに属していて、そのうちの1人が特定のアクセス許可を [ 拒否] に設定している場合、そのユーザーは、そのアクセス許可が [ 許可] に設定されているグループに属している場合でも、そのアクセス許可を必要とするタスクを実行できません。If a user belongs to two groups, and one of them has a specific permission set to Deny, that user is not able to perform tasks that require that permission even if they belong to a group that has that permission set to Allow.

    場合によっては、 プロジェクトコレクション管理者 または Team Foundation 管理者 グループのメンバーは、別のグループのアクセス許可が拒否されていても、常にアクセス許可を取得することがあります。In some cases, members of the Project Collection Administrators or Team Foundation Administrators groups may always get the permission even if they are denied that permission in a different group. 作業項目の削除やパイプラインなどの他のケースでは、プロジェクトコレクション管理者のメンバーである場合、他の場所で設定された 拒否 アクセス許可は無視されません。In other cases such as work item deletion or pipelines, being a member of project collection administrators does not bypass Deny permissions set elsewhere.

  • グループのアクセス許可を変更すると、そのグループのメンバーであるすべてのユーザーに対して、そのアクセス許可が変更されます。Changing a permission for a group changes that permission for all users who are members of that group. つまり、グループのサイズによっては、1 つのアクセス許可を変更するだけで、数百人のユーザーのジョブに影響を与える可能性があります。In other words, depending on the size of the group, you might affect the ability of hundreds of users to do their jobs by changing just one permission. 変更を加える前に影響について理解しておく必要があります。So make sure you understand the impact before you make a change.

アクセス許可の継承とセキュリティグループPermission inheritance and security groups

一部の権限は、階層を介して管理されます。Some permissions are managed through a hierarchy. この階層内では、アクセス許可を親から継承することも、オーバーライドすることもできます。Within this hierarchy, permissions can be inherited from the parent or overridden. セキュリティグループは、グループのメンバーにアクセス許可のセットを割り当てます。Security groups assign a set of permissions to those members of the group. たとえば、 貢献 者グループまたは プロジェクト管理者 グループのメンバーには、[ 許可 ] に設定されているアクセス許可がそのグループに割り当てられます。For example, members of the Contributors group or Project Administrators group are assigned the permissions that are set as Allowed to those groups.

アクセス許可がユーザーに対して直接許可または拒否されていない場合は、2つの方法で継承される可能性があります。If a permission isn't directly allowed or denied for a user, then it may be inherited in two ways.

  • ユーザーは、所属するグループからアクセス許可を継承します。Users inherit permissions from the groups to which they belong. ユーザーが直接、またはそのアクセス許可を持つグループのメンバーシップを介してアクセス許可を付与され、直接またはグループメンバーシップによって拒否された場合、アクセス許可は拒否されます。When a permission is allowed for a user directly or through membership in a group that has that permission, and it is denied, either directly or through group membership, the permission is denied.

    プロジェクトコレクション管理者 または Team Foundation 管理者 のメンバーは、アクセス許可を拒否した他のグループに属している場合でも、ほとんどのアクセス許可を保持します。Members of Project Collection Administrators or Team Foundation Administrators retain most allowed permissions, even if they belong to other groups that deny those permissions. 作業項目の操作のアクセス許可は、この規則の例外です。Work item operation permissions are the exception to this rule.

  • 階層のノードに割り当てられたオブジェクトレベルの権限 (区分、イテレーション、バージョンコントロールフォルダー、作業項目クエリフォルダー) は、階層の下位に継承されます。Object-level permissions that are assigned for nodes of a hierarchy - areas, iterations, version control folders, work item query folders - are inherited down the hierarchy. つまり、 area-1 area-1/sub-area-1 同じ権限がに対して明示的に許可または拒否されていない場合、に設定されているユーザーの権限はによって継承され area-1/sub-area-1 ます。That is, a user's permissions that are set at area-1 are inherited by area-1/sub-area-1, if the same permission is not explicitly allowed or denied for area-1/sub-area-1. などのオブジェクトに対して権限が明示的に設定されている場合、拒否されているか許可されて area-1/sub-area-1 いるかにかかわらず、親ノードは継承されません。If a permission is set explicitly for an object, like area-1/sub-area-1, then the parent node is not inherited, regardless of whether it is denied or allowed. 設定されていない場合、そのノードのアクセス許可は、アクセス許可が明示的に設定されている最も近い先祖から継承されます。If it's not set, then the permissions for that node are inherited from the closest ancestor that has the permission explicitly set. 最後に、オブジェクト階層では、特異性勝る継承です。Lastly, in the object hierarchy, specificity trumps inheritance. たとえば、アクセス許可が明示的に "area-1 " に設定 されていても、"area-1/サブ区分-1" に対して明示的に allow に設定されているユーザーは、最終的に ' area-1/サブ区分-1 ' で 許可 を受け取ります。For example, a user whose permissions are explicitly set to Deny on 'area-1' but are also explicitly set to Allow for 'area-1/sub-area-1' will ultimately receive an Allow on 'area-1/sub-area-1'.

アクセス許可が継承される理由を理解するには、アクセス許可の設定を一時停止し、その理由を選択し ます。To understand why a permission is inherited, you can pause over a permission setting, and then choose Why? [ セキュリティ ] ページを開くには、「 アクセス許可を表示する」を参照してください。To open a Security page, see View permissions.

注意

[プロジェクトのアクセス許可] 設定ページで新しいユーザーインターフェイスを有効にするには、「 プレビュー機能を有効にする」を参照してください。To enable the new user interface for the Project Permissions Settings Page, see Enable preview features.

[プレビュー] ページPreview page

[アクセス許可] ダイアログ、プレビューページ、リンクが注釈付きの理由Permissions dialog, preview page, Why link annotated.

新しいダイアログが開き、そのアクセス許可の継承情報が表示されます。A new dialog opens that shows the inheritance information for that permission.

プロジェクトのアクセス許可の設定ページのプレビューユーザーインターフェイスは、Azure DevOps Server 2020 以前のバージョンでは使用できません。The preview user interface for the Project Permissions Settings Page isn't available for Azure DevOps Server 2020 and earlier versions.

[アクセス許可] ダイアログ、[現在のページ]、リンクが注釈付きである理由。Permissions dialog, current page, Why link annotated.

新しいウィンドウが開き、そのアクセス許可の継承情報が表示されます。A new window opens that shows the inheritance information for that permission.

アクセス許可のトレースダイアログ。

[アクセス許可] ダイアログ。これより前のバージョンでは、リンクが注釈付きになります。

一部のオブジェクトレベルのセキュリティダイアログボックスには、継承のオン/オフオプションが用意されています。Some object level Security dialog boxes provide an Inheritance on/off option. このオプションを使用すると、フォルダー、共有クエリ、および他のオブジェクトに関する継承を無効にすることができます。Use this option to disable inheritance for folders, shared queries, and other objects.

アクセス許可のトレースダイアログ。以前のバージョン。

アクセス許可を割り当てるときWhen assigning permissions

くださいDo:

  • 多くのユーザーを管理する場合は、Windows グループを使用します。Use Windows groups when managing lots of users.
  • 作業項目クエリフォルダー に対して、プロジェクトの作業項目クエリを作成および共有する機能を必要とするユーザーまたはグループに対する投稿権限を付与することを検討してください。Consider granting the work item query folders Contribute permission to users or groups that require the ability to create and share work item queries for the project.
  • 多くのチームを追加する場合は、プロジェクト管理者 が使用できるアクセス許可のサブセットを割り当てる、チーム管理者 のカスタムグループを作成することを検討してください。When adding many teams, consider creating a Team Administrators custom group where you allocate a subset of the permissions available to Project Administrators.
  • チームを追加する場合は、チーム リーダー、スクラム マスター、さらに区分パス、イテレーション パス、クエリを作成および修正する必要のあるチームの他のメンバーに、どのアクセス権限を割り当てるかを検討します。When adding teams, consider what permissions you want to assign to team leads, scrum masters, and other team members who may need to create and modify area paths, iteration paths, and queries.

できません:Don't:

  • プロジェクト管理者 グループに追加したプロジェクト 閲覧 者グループにユーザーを追加しないでください。Don't add users to the project Readers group that you've added to the Project Administrators group. リーダーグループでは、プロジェクト管理者グループが許可するいくつかのアクセス許可が拒否されるため、拒否が優先されます。Because the Readers group denies several permissions that the Project Administrators group allows, and deny takes precedence.
  • 有効なユーザーグループに対して行われた既定の割り当てを変更しないでください。Don't change the default assignments made to the valid users groups. 有効なユーザーグループの1つに対して [ インスタンスレベル情報の表示 ] 権限を [拒否] に設定した場合は、設定したグループに応じて、そのグループ内のユーザーがプロジェクト、コレクション、または配置にアクセスできなくなります。If you remove or set the View instance-level information permission to Deny for one of the Valid Users groups, no users in the group are able to access the project, collection, or deployment, depending on the group you set.
  • "サービスアカウントにのみ割り当てる" と表示されているアクセス許可をユーザーアカウントに割り当てないでください。Don't assign permissions that are noted as 'Assign only to service accounts' to user accounts.

ロール ベース アクセス許可Role-based permissions

ロールベースの権限では、ユーザーアカウントがロールに割り当てられ、各ロールに1つ以上のアクセス許可が割り当てられます。With Role-based permissions, user accounts are assigned to a role, with each role assigned one or more permissions. ここでは、主要な役割とリンクを紹介します。Here are the primary roles and links to learn more.

  • 成果物またはパッケージフィードのセキュリティロール: ロールでは、パッケージフィードを編集および管理するためのさまざまなアクセス許可レベルがサポートされています。Artifact or package feed security roles: Roles support various permission levels to edit and manage package feeds.

  • Marketplace 拡張機能マネージャーロール: マネージャーロールのメンバーは、拡張機能をインストールして、拡張機能のインストール要求に応答できます。Marketplace extension Manager role: Members of the Manager role can install extensions and respond to requests for extensions to be installed.

  • パイプラインのセキュリティロール: ライブラリリソース、プロジェクトレベル、およびコレクションレベルのパイプラインリソースを管理するために、いくつかのロールが使用されます。Pipeline security roles: Several role are used to manage library resources, project-level and collection-level pipeline resources.

  • チーム管理者ロール チーム管理者は、すべてのチームツールを管理できます。Team administrator role Team administrators are able to manage all team tools.

    注意

    プロジェクト管理者グループまたはプロジェクトコレクション管理者グループのメンバーは、すべてのチームのすべてのチームツールを管理できます。Members of the Project Administrators or Project Collection Administrators groups can manage all team tools for all teams.

機能フラグFeature flags

選択へのアクセス、新機能は機能フラグによって制御されます。Access to select, new features are controlled by feature flags. Azure DevOps Services は、定期的に機能フラグの背後に配置することで新機能を紹介します。Periodically, Azure DevOps Services introduces new features by placing them behind a feature flag. プライベートプレビューの機能を使用するには、組織所有者が機能を有効にするように要求する必要があります。Features under a private preview require the organization owner to request that the feature be turned on. その他の機能は、一般的なユーザーが有効または無効にできるプレビュー機能として導入されることがあります。Other features may be introduced as a preview feature which general users can enable or disable.

詳細については、「 機能の管理または有効化」を参照してください。To learn more, see Manage or enable features.

次のステップNext steps