Azure DevOpsの権限まわりをざっくり理解する（前半）

# はじめに
Azure DevOpsの権限まわりの話題ですが、まぁまぁややこしいという印象があります。
そこで、権限まわりの公式ドキュメントが読みやすくなるような記事をまとめたいと思います。

※Publicなプロジェクトをご利用になる場合はちょっと例外な部分もあります、ご了承ください。

# 結論
・認証、認可、ライセンスの３段構えが存在する
・Azure ADが使える
・個々のサービス単位での権限が存在する
ここらへんがフンワリわかっていれば、以降は読まなくて大丈夫です。

# 公式ドキュメント
Azure DevOpsの公式ドキュメントはこちらから始まります。

https://docs.microsoft.com/ja-jp/azure/devops/organizations/?view=azure-devops

特に今回は、こちらのドキュメントにフォーカスして理解を進めたいと思います。

https://docs.microsoft.com/ja-jp/azure/devops/organizations/security/about-permissions?view=azure-devops&tabs=preview-page

ここがわかれば、残りのドキュメントは読めるようになります。

# ドキュメントの冒頭を理解する
ドキュメントの冒頭に、以下のような記載があります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/672e52b1-200a-3161-44bf-c862ae40c3db.png)
**次の主要な概念を理解することをお勧めします**とのことです。
１つ１つ確認していきます。

・Azure DevOps に追加されたすべての**ユーザー**は、通常、1つまたは複数の**セキュリティグループ**に追加されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/cf25cd2e-f37b-f138-724f-0512c245bf3f.png)

・セキュリティグループには、機能へのアクセスを許可または拒否する**アクセス許可**が割り当てられます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/fe9b4cb8-386d-b2fe-9269-29c47c458adf.png)

・セキュリティグループのメンバーは、そのグループに割り当てられた**アクセス許可を継承**します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/0525dba5-0d72-2377-e405-63fc392db300.png)

・また、各ユーザーには**アクセスレベル**が割り当てられ、webポータルの機能を選択するためのアクセス権が付与または制限されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/4dc87707-a85d-217c-fa1d-748c6ba5b0e1.png)

あと３つは後述。まずはここまでを理解します。

AzureAD、マイクロソフトアカウント、GitHubなどユーザーの定義方法は様々ありますが、ユーザーは登録されると、どこかのセキュリティグループに所属します。
この時点で、何らかの認証手段を得た人が入ってくることを前提としていることがわかります。
また、野良なユーザーは存在せず、必ずどこかのグループに入るのだと書かれています。

ご自身の所属グループの確認はこちらになります。
"Organization Settings"　→　"Security - Permissions"　→　"Users"　→　"ご自身"　→　"Member of"タブ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/5226a463-dbf0-c1e3-8ae9-68af4c3d1a21.png)

「ログインできるけど、〇〇さんと同じ機能が使えない」といった時は、まずここからご確認ください。
細かいことがわからなくても、同じことができているユーザーとの差を確認していけば、何が起きているのかはわかると思います。

**セキュリティグループ**には、各種機能の許可or拒否の設定(**アクセス許可**)が施されています。
"各種機能"に関しては先ほどの続き
**・アクセス許可は、リポジトリ、パイプライン、区分パスなど、ほとんどのオブジェクトに対してさまざまなレベルで設定されます。**
との記載があります。
"リポジトリ"は**Repos**機能、"パイプライン"は**Pipelines**機能、"区分パス(Area Path)"は**Boards**機能の話題です。
これらは各々属性の異なる利用者が登場しますので、個々のグループに対して良い感じに設定してくださいね、ということです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/439826/59a48195-0718-7288-168a-74867eec20de.png)
絵が雑ですが２社に開発を委託したときのイメージです。パートナー各社と契約元では許可すべき機能が異なります。パートナー２社も開発範囲が異なれば、各々が独立した形で機能を利用したくなります。
そもそもこの絵が指している開発の全体像につきましては、こちらを参照ください。
[Azure と Azure DevOps を使った開発の流れをふんわりと](https://qiita.com/mstakaha1113/items/1fa52135a7a61dfc30e4)

認証されたユーザーが所属するグループごとに"どんなことを許可もしくは拒否するのか"を設定するので、これは認可機能であるとわかります。
（ディレクトリやファイルのアクセス権限の話題をグループ単位で付与するみたいなのと同じことを機能単位でやっているだけです。）

基本的には上記のように権限付与が行われますが、例外が存在します。
それが先ほどの続きにあります
**・その他のアクセス許可は、チーム管理者ロール、拡張管理ロール、さまざまなパイプラインリソースロールなどの ロールベースの割り当て によって管理されます。**
という記述です。
具体的には同ドキュメント後半、"[ロール ベース アクセス許可](https://docs.microsoft.com/ja-jp/azure/devops/organizations/security/about-permissions?view=azure-devops&tabs=preview-page#role-based-permissions)"に記載があります。


ここまでは主にセキュリティグループと機能の関係を中心に、"使える""使えない"の話題をしてきました。

今度は個々のユーザーについてです。認証されたユーザーは、簡単に言えば使える範囲ごとに料金が異なっています。
これを"アクセスレベル"と呼びます。
アクセスレベルは"Basic"、"利害関係者(ステークホルダー)"、"Test"の３種類に分類されます。
各々で料金が異なっています。
ここらへんの分類につきましては、こちらを参照いただけますと幸いです。
[Azure DevOps 利用料の考え方](https://qiita.com/mstakaha1113/items/81ddab698c1d4d01a10b)

主だった内容は以上となります。
最後に、AzureDevOpsは、良くも悪くも（？）新機能がどんどんリリースされていきます。
これらを使えるようにするか否かを選択できるようにできています。
それが最後に記載されている
**・最後に、新機能が導入されると、それらの機能にアクセスするには、 機能フラグ を有効にする必要があります。**
という記述です。
こちらも具体的にはドキュメント後半、"[機能フラグ](https://docs.microsoft.com/ja-jp/azure/devops/organizations/security/about-permissions?view=azure-devops&tabs=preview-page#feature-flags)"に記載があります。

# 続きは別途
まだドキュメントの前半しか触れていませんが、長いので一旦切りたいと思います。