はじめに

こんにちは。ACS事業部）土居です。
この記事はエーピーコミュニケーションズ Advent Calendar 2023 の9日目の投稿です。

最近Azure DevOps を仕事で利用していたのですが、Azure DevOps って使い始めると権限管理の設定の複雑さに頭を悩まされることがしばしばあります。今回は自分の備忘録も兼ね、Azure DevOpsの権限管理で注意すべきポイントや、勘違いしやすいポイントを自分なりにまとめてみたいと思います。

Azure DevOps とは？

Azure DevOps とは、Microsoftが提供するクラウドサービスであり、モダンな開発の支援サービスを複数提供しているプラットフォームです。以前は、Team Foundation ServerといったVisual Studioファミリー製品の一つでしたが、2019年よりブランド名が一新されています。

Azure DevOps は主に以下の5つのサービスから構成されています。それぞれのサービスを単体で利用することも可能ですが、各サービスの相互連携がしやすいため、一般的にAzure DevOps を利用する場合は5つのサービスをそれぞれ利用して運用することが多いです。

Azure Boards - かんばんボード、バックログ、チームのダッシュボード、カスタムレポートを使用して作業を追跡できます。
Azure Pipelines - 様々な開発言語、プラットフォーム、クラウドに対応した CI/CD を使用して、ビルド、テスト、デプロイできます。
Azure Repos - クラウドでホストされる無制限のプライベート Git リポジトリを利用できます。pull request と高度なファイル管理を使用して、より優れたコードを構築するために共同作業を行います。
Azure Test Plans - 計画的および探索的なテストソリューションを提供します。
Azure Artifacts - パッケージを作成、ホスト、チームと共有し、 CI/CD パイプラインに成果物を追加できます。

また、Azure DevOps とは別に、オンプレミスのマシンにインストールしてAzure DevOps プラットフォームをプライベートな環境として利用するAzure DevOps Server もあります。

詳細は、公式のAzure DevOps のドキュメントを確認ください。

learn.microsoft.com

ではここからAzure DevOps を利用していく上での権限管理について、ポイントを記載していきます。

Azure DevOps のアクセスレベル（ライセンス）について

Azure DevOps には一般的に以下の3つのアクセスレベルが存在します。アクセスレベルとは、Azure DevOps に招待した各ユーザーに割り当てるライセンスのようなものです。

Stakeholder - 無料で任意のユーザーに無制限に割り当てることができるアクセスレベルです。プライベートプロジェクトへの部分的なアクセスと、主にパブリックプロジェクトへのフルアクセスを提供します。ライセンスとサブスクリプションはないものの、限られた機能セットにアクセスする必要があるユーザーに割り当てます。
Basic - Azure Test Plansの一部機能を除いたほぼ全てのAzure DevOpsサービスの機能が利用できるアクセスレベルです。価格も最初の 5 ユーザーは無料、その後は¥887.28/ユーザー/月と安価で利用できて一番利用されているものとだと思います。
Basic + Testプラン - Basicの機能に、Azure Test Plansにテスト計画とテストスイートの追加、手動テストケースの作成、テスト成果物の削除などの機能を追加した上位アクセスレベルです。ユーザーあたり ¥7,689.76/月が発生します。

他にも既存のVisual Studioライセンスに依存した特殊なアクセスレベルもありますがここでは割愛します。アクセスレベルの詳細については下記の公式ドキュメントに細かな機能差異も記載されています。

learn.microsoft.com

重要なのは、以下の2つです。

アクセスレベルでBasic以上で機能として利用できるようになっていても、後述するProject等への権限が割り当てられていない場合は、ユーザーはAzure DevOps を活用できません。
Project等へ強い権限が割り当てられていたとしても、アクセスレベルがStakeholderで部分的なアクセスしかできない場合、ユーザーはAzure DevOps の機能を活用できません。

Azure DevOps の階層における権限管理

Azure DevOps では組織（Organization）とプロジェクトという2つの概念が存在します。

組織とは、関連プロジェクトのグループを編成して管理するAzure DevOps を利用する際に一番最初に作成を行うものとなります。一般的に、会社単位や事業部門、チーム単位等で作成します。詳細は以下を参照下さい、

learn.microsoft.com

プロジェクトとは、読んでそのままプロジェクトの開発に必要な以下の機能が含まれたものになります。一般的に、開発するシステムに応じてプロジェクトを組織内で複数作成していきます。

Azure DevOps では下記の画像のように組織の中に複数プロジェクトが立ち上がっているという構成になります。

そして、この組織単位と1つ1つのプロジェクトそれぞれで設定できる権限、用意されているセキュリティロールが異なります

https://learn.microsoft.com/en-us/azure/devops/organizations/security/media/about-security/security-groups-permission-management-cloud.png?view=azure-devops

組織は、「Organization Settings」- 「Permissions」から設定を行います。組織単位での設定やアカウントの管理、複数プロジェクトの管理を行うProject Collectionと呼ばれるセキュリティロールが主にここでは設定ができます。

各セキュリティロールの詳細は下記のドキュメントを参照下さい。

アクセス許可、セキュリティグループ、およびサービスアカウントのリファレンス - Azure DevOps | Microsoft Learn

プロジェクトは、特定プロジェクト内での権限設定を行います。例えば、かんばんボードの起票や削除、Azure Pipelinesで作成したCI/CDワークフローへの閲覧・実行の権限、Azure ReposでホストするGitリポジトリへのアクセスやコミット、Pull Requestなどの権限等が挙げられます。こちらは、一旦該当プロジェクトの画面に遷移し、「Project Settings」 - 「Permissions」から設定を行います。

各セキュリティロールの詳細は下記のドキュメントを参照下さい。

アクセス許可、セキュリティグループ、およびサービスアカウントのリファレンス - Azure DevOps | Microsoft Learn

また、この階層による権限管理では継承の仕組みが利用されています。基本的にはグループを作成し用意されたセキュリティロールを利用して権限を管理していけばよいのですが、稀にこのユーザーだけはアクセスを許可したくないといったオーバーライドの設定を行いたい場合があります。その場合、対象ユーザーの「Permissions」の設定で「拒否」をすれば、継承ユーザーが所属しているグループで「許可」のセキュリティロールが割り当てられていたとしても、対象ユーザーのみ権限を制御することができます。時々こういったユースケースは出てくるので覚えておくとよいかもしれません。

Get started with permissions, access levels, and security groups - Azure DevOps | Microsoft Learn

分かりにくいTeamとArea Pathという概念を理解する

既にAzure DevOps を使っていて、このTeamとArea Pathの理解に一度は苦戦された方も多いでしょう。これから使われる方は、TeamsとArea Pathを理解しておけば、Azure DevOps のカスタマイズ範囲が格段に広がるので是非覚えて下さい。

プロジェクトを作成すると、プロジェクトを作成したユーザーがメンバーとなりTeamが自動的に作成されます。

また、このTeamはプロジェクト内のセキュリティグループにも自動的に追加されます。

Azure Boards ではプロジェクトの作業項目を管理するためにかんばんボードを利用しますが、例えば同じプロジェクト内で、複数のチームがそれぞれ別々の単位システムや機能開発を行う場合、1つのかんばんボードで運用してしまうと視認性が悪かったり、互いの見えなくてもよい情報が閲覧できてしまったりと何かと面倒になります。そのため、Azure Boards では複数のかんばんボードを準備することができます。このかんばんボードを準備することをAzure Boards ではArea Pathを呼び、Area Path はどのTeamが利用するか紐づけがされます。

詳細は公式ドキュメントを記載しておきますので、時間がある際は是非一読してみて下さい。

learn.microsoft.com

TeamとArea Pathの前置きはこの程度にし、ここからがこの節で言いたいことです。結局の所、Azure DevOps のプロジェクト内で何か行いたい場合はArea Pathが紐づいているTeamを作成しそこに所属させることが一般的です。なので、「Azure DevOps の階層における権限管理」の節で説明したプロジェクト層での権限管理については、Teamのセキュリティグループに対して基本的な権限設定を行っていきましょう。Teamのセキュリティグループだけで設定が不十分が点が出てくれば、他のグループや継承の仕組みなどを利用することで、より柔軟な権限設定を簡単に行うことができます。

Repos , Pipelines , Artifactsなど個別でのPermissionsの設定

これまでに説明した以外にも、例えばAzure Reposでは特定のRepositoryに対する権限設定、Azure Pipelinesでは各ワークフローに関する権限設定、Artifactsでは格納された各成果物単位での権限設定などを行うことができます。公式ドキュメントを記載しておきますので、こちらも参考下さい。

learn.microsoft.com

https://learn.microsoft.com/ja-jp/azure/devops/organizations/security/set-permissions-access-test?view=azure-devops&tabs=preview-page

learn.microsoft.com