Azure DevOpsの権限について調べてみた ~1. 組織レベルの権限について~

本記事ではAzure DevOpsの権限について「組織レベルの権限について」「プロジェクトレベル・リポジトリレベルの権限について」、「各サービスレベルの権限について」の3回に分けて書きたいと思います。

Azure DevOpsの権限ですが、とても細かく区分されており、少々複雑になっています。組織レベル、プロジェクトレベル、リポジトリレベル…とそれぞれのレベルで権限が存在し、さらにそれぞれのサービスに対しても権限が存在するためです。

そんな、細分化された権限について、本記事では解説していきたいと思います。

また、Azure DevOpsはサービス自体も多く存在するため、代表的なサービスについての権限についても紹介します。

Azure DevOpsとは、Microsoftが提供する、DevOpsを実行するために必要な環境やツールを備えたサービス群です。

Azure DevOpsを使うことで以下のことが実行できます。

また、Azure DevOpsでは以下のサービスを利用することができます。

それぞれの細かい機能については以下のドキュメントを参照ください。

本記事では、まず組織レベルの権限について紹介します。

Azure DevOpsは階層構造であり、組織は必ず1つのEntra IDを親として持っています。

組織は、Azure DevOpsを管理するためのグループです。

組織の配下で、事業ごと、地域ごと、案件ごと、といったように複数のプロジェクトを作成し、管理することが可能です。

Azure DevOpsでの組織の作成方法は、以下ドキュメントを参照ください。

Azure DevOpsでは、組織を作成した時、以下のグループとユーザーがデフォルトで作成されます。

■グループ

Project Collection Administrators
- すべての特権操作を実行可能なグループ
Project Collection Build Administrators
- ビルドリソースを管理するためのアクセス許可と組織のアクセス許可を持つグループ
Project Collecrion Build Service Accounts
- 組織のビルドサービスを実行許可を持つグループ
Project Collection Proxy Service Accounts
- 組織のプロキシサービスの実行許可を持つグループ
Project Collection Service Accounts
- 組織とAzure DevOps Serviceに対するサービスレベルのアクセス許可を持つグループ
Project Collection Test Service Accounts
- 組織に対するテストサービス許可を持つグループ
Project Collection Valid Users
- すべてのユーザとグループが所属するグループ
Project-Scoped Users
- 組織レベルのデータに対する制限付きの可視性を持つグループ
Security Service Group
- リソースへの明示的なアクセス許可を付与されたIDが自動定に追加されるグループ