これはAzure DevOpsアドベントカレンダー3日目の記事です。
Azure DevOpsで複雑だと言われる点の一つがセキュリティ周りの設定です。東京と大阪で来年このネタでしゃべるつもりですが、チラ見せみたいな形でご紹介します。
大前提
会社組織であればAzure DevOpsはAzure ADベースで動かしましょう。特にOffice 365を使っていればグループ管理が格段に楽です。
ただ、グループの反映はオンプレミスADと違って、1時間くらいかかるようなので、リアルタイム反映は期待しないほうがいいようです。
Organization
ユーザー追加設定です。まずはここに登録しないと始まりません。Azure ADベースで運用しているのであれば、Azure ADのグループごとに追加していったほうが楽です。数人であれば、ちまちま手作業でもいいでしょう。
会社であれば、REST APIを使って管理するのもいいと思います。
Azure DevOps のOrganization(dev.azure.com/Organization)全体の設定です。全プロジェクトに関わるので慎重にしてください。一名では何かの時に不安なので、複数登録しておくことをお勧めします。
アプリケーションからの接続方法を許可する設定です。Alternative AuthenticationはSSHやAzure AD認証がなかった頃、MSアカウントでの認証ができないような環境向けに用意されていた脆弱な方法です。現在はSSHやAzure AD認証(デバイスなど)ができるようになっているので、オフにすることを推奨します。
パブリックプロジェクトはプロジェクト単位で外部に公開できる機能です。組織では使うことはないかもしれないので、最初はオフにしておくといいでしょう。
仮に公開する場合でも、公開は「プロジェクト」単位です。Gitのリポジトリごとに公開できないので、注意してください。
Gitブランチ
Gitのブランチごとにセキュリティの設定ができます。特徴的なのはbypass policies〜ですね。特定の条件に一致した場合、ポリシーをスルーできます。
ブランチポリシー
セキュリティとは少し違いますが、類似なので解説します。
Azure DevOpsではGitブランチごとにレビュワー設定、ビルドを通すという設定ができます。全部のブランチに設定すると大変なので、master, dev, releaseなどの重要なブランチにのみ設定してください。
最小限のレビュワー、作業項目のリンクを必須にする、マージ戦略を強制するといった設定です。
コミット前にビルドが通るかどうかのチェックするビルド定義を指定します。Require approval from external servicesでは例えば、マージ前にセキュリティやコンプライアンスチェックを行うようなサービスを呼び出す、未解決のworkitemがあるかどうかを判定する独自サービスとの連携行います。
こういうのはAzure FunctionsやAWS Lambdaを使うといいですね。
プロジェクトセキュリティ
Project Settingsのページから実施します。
プロジェクトの基本的なセキュリティ設定です。以前作られたプロジェクトではBuild Administratorに入っていないとビルド定義が作れなかった(外部サービスからも同様)のですが、最近の変更で変わりました。古いプロジェクトは明示的に変更する必要があります。
Azure Pipelines
ビルドとリリースにもセキュリティ設定があります。どちらもだいたい同じです。それぞれの定義の三点リーダ(…)をクリックすると出てくるSecurityから呼び出せます。
内容はどちらもだいたい同じで、セットするかどうかだけですね。
ブログでは簡単にまとめましたが、セッションではもうちょっとシナリオベースでお話しようかなと思っています。
