Azure Pipelines セキュリティで最初に確認すべき結論は、サービス接続、Environment、Library、Agent pool、Pipeline本体の権限が「必要なパイプラインだけ」に絞られているかです。2026年5月9日時点で確認すべきポイントは、緊急の移行作業というより、既存のAzure DevOps環境に残りやすい「Open access」「継承された強すぎる権限」「共有されたサービス接続」を棚卸しすることにあります。Microsoft Learnの対象ドキュメントは、Azure Pipelinesのビルド、リリース、タスクグループ、エージェントプール、サービス接続などへのアクセスを、ユーザーとセキュリティグループの階層で管理する内容として整理しています。(Microsoft Learn)
Microsoft Azureのセキュリティ更新、管理者が確認すべき影響範囲と対応ポイント
今回の「Manage security in Azure Pipelines」は、Azure Pipelinesの権限管理を一つの機能だけで見るのではなく、パイプラインが触るリソース全体のアクセス制御として見直すための情報です。
公式ドキュメントの履歴では、2026年5月7日と5月8日に対象ファイルの更新が確認できます。ただし、コミット内容は「ms.assetidメタデータの削除」や「Related articlesをRelated contentへ置き換える」といったドキュメント整備が中心で、Azure Pipelinesの権限仕様そのものが大きく変わったことを示す更新ではありません。(GitHub)
そのため、管理者が取るべき対応は「急いで何かを移行する」ではなく、既存のパイプライン権限が現在のセキュリティ方針に合っているかを点検することです。特に、過去に作成されたプロジェクトでは、開発効率を優先して広い権限を残したままになっているケースがあります。
変更点として押さえるべきこと
今回の更新で実務上重要なのは、ドキュメントの更新日そのものよりも、Azure Pipelinesのセキュリティ管理で見落としやすい範囲が明確に整理されている点です。対象はパイプライン単体ではなく、サービス接続、Environment、Library、Release、Task group、Agent poolまで広がります。
| 確認項目 | 変更・整理された見方 | 管理者への影響 |
|---|---|---|
| パイプライン権限 | プロジェクトレベルとオブジェクトレベルの階層で管理する | 全パイプラインに効く設定と個別パイプラインの例外を分けて確認する |
| 継承 | 多くのリソースはプロジェクトレベルの権限を継承する | 例外設定が増えると、誰に何が許可されているか追いにくくなる |
| Open access | Environment、サービス接続、Agent poolなどで全パイプライン利用を許可できる | 本番環境や機密情報に接続するリソースでは危険度が高い |
| Library | Variable groupやSecure filesを一括・個別に管理する | シークレットや証明書ファイルの利用範囲を絞る必要がある |
| Agent pool | 組織、コレクション、プロジェクト、個別プールで権限管理する | 自己ホストエージェントの横展開リスクを抑える必要がある |
Azure Pipelinesの権限は、プロジェクトレベルの設定がオブジェクトレベルへ継承される階層モデルです。プロジェクト全体の既定権限は変更できますが、システムによって設定された権限は変更できません。(Microsoft Learn)
影響範囲は「パイプラインを実行できる人」だけではない
Azure Pipelines セキュリティの見直しでよくある誤解は、「誰がパイプラインを編集・実行できるか」だけを確認して終わることです。実際には、パイプラインが利用する接続先、変数、ファイル、エージェント、デプロイ先まで確認しなければ、権限の抜け道が残ります。
たとえば、ある開発者がパイプラインの編集権限を持っていなくても、広く共有されたサービス接続やAgent poolを別のパイプラインから利用できる場合があります。逆に、パイプライン自体の権限を厳しくしていても、Variable groupやSecure filesの利用範囲が広いと、意図しないジョブから機密値を参照できる可能性があります。
特に確認すべき影響範囲は次のとおりです。
| リソース | 何が問題になりやすいか | 優先度 |
|---|---|---|
| Service connections | Azure、GitHub、外部サービスへの接続権限が広すぎる | 高 |
| Environments | 本番環境へのデプロイを多くのパイプラインが利用できる | 高 |
| Library | 変数グループ、Secure files、証明書、キーの参照範囲が広い | 高 |
| Agent pools | 自己ホストエージェントが複数プロジェクトから使われる | 高 |
| Release pipelines | Classic releaseのステージ権限が古いまま残る | 中 |
| Task groups | Classic系の再利用部品に過剰な編集権限が残る | 中 |
管理者が最初に確認すべき設定
パイプライン本体のプロジェクトレベル権限を確認する
まず、プロジェクト全体で「誰がパイプラインを作成、編集、削除、キュー投入できるか」を確認します。Azure Pipelinesでは、Readers、Contributors、Build Administrators、Project Administratorsなどの既定グループに権限が割り当てられます。Contributorsはパイプラインやビルドを管理できますが、ビルドキューの管理は含まれないなど、グループごとに許可範囲が異なります。(Microsoft Learn)
実務では、次の判断基準が使いやすいです。
| 権限 | 許可してよい対象 | 見直しが必要な例 |
|---|---|---|
| View builds / View build pipeline | 開発チーム、監査担当、運用担当 | 機密プロジェクトを全社ユーザーが閲覧できる |
| Create build pipeline | CI/CDを設計する担当者 | 全Contributorsが自由に作成できる |
| Delete or edit build pipeline | パイプライン管理者、リード開発者 | 一般開発者が本番用パイプラインを編集できる |
| Queue builds | 開発者、QA、運用担当 | 本番デプロイを含むパイプラインを誰でも実行できる |
| Administer build permissions | プロジェクト管理者、限定されたDevOps管理者 | 一時対応用に付けた管理権限が残っている |
注意したいのは、Azure DevOpsの権限にはAllow、Deny、Not setなどの状態があり、多くの場合DenyはAllowより強く働くことです。安易にDenyを多用すると、別グループで必要な権限を与えても操作できない原因になります。まずはNot setとグループ設計で整理し、明確に禁止したい操作だけDenyを使うのが安全です。(Microsoft Learn)
オブジェクトレベル権限で例外が増えすぎていないか見る
個別パイプラインでは、プロジェクトレベルの権限をオーバーライドできます。これは本番デプロイ用パイプラインや、特定チームだけが扱うパイプラインでは有効です。一方で、個別設定が増えすぎると、退職者、異動者、外部委託メンバーの権限が残りやすくなります。
確認する際は、次の順番で見ると効率的です。
| 手順 | 確認内容 |
|---|---|
| 1 | 本番環境、顧客データ、重要なAzureリソースに関係するパイプラインを洗い出す |
| 2 | 各パイプラインのManage securityを開く |
| 3 | 個人アカウントに直接付与された権限を確認する |
| 4 | 不要な個別権限を削除し、Microsoft Entra IDグループやAzure DevOpsグループへ寄せる |
| 5 | 継承を無効化している場合、その理由を記録する |
継承されたユーザーやグループは、継承を無効にしない限り削除できないケースがあります。公式ドキュメントでも、継承されたユーザーやグループを削除するには継承の無効化が必要であることが示されています。(Microsoft Learn)
Service connectionsは最優先で棚卸しする
Service connectionsは、Azure、GitHub、コンテナレジストリ、外部クラウド、SaaSなどへ接続するための入口です。ここが広く開いていると、パイプライン権限の弱点がそのままクラウドリソースへの操作権限につながります。
公式ドキュメントでは、サービス接続に対してユーザー・グループのロール、パイプラインアクセス、プロジェクトアクセスを設定できると説明されています。また、ロールにはReader、User、Creator、Administratorがあり、Administratorはサービス接続の利用だけでなく他ユーザーのロール管理もできます。(Microsoft Learn)
特に確認すべき項目は次の3つです。
| 確認項目 | 推奨される考え方 |
|---|---|
| Pipeline permissions | 本番・準本番向けサービス接続はOpen accessではなく、利用するパイプラインを明示的に追加する |
| User permissions | Administratorを最小限にし、利用だけならUserにする |
| Project permissions | 他プロジェクトへの共有は必要な場合だけ行い、共有理由を記録する |
サービス接続のパイプライン権限は、すべてのパイプラインに利用を許可するOpen accessと、特定パイプラインのみに制限する設定を選べます。さらに、サービス接続は既定では他プロジェクトに共有されません。共有する場合は、組織レベルの管理者権限や対象プロジェクトでの作成権限が関係します。(Microsoft Learn)
実務での判断例
本番Azureサブスクリプションへデプロイするサービス接続は、次のように分けると事故を減らせます。
| 用途 | 設定例 |
|---|---|
| 開発環境デプロイ | 開発用パイプラインのみ許可。権限は対象リソースグループに限定 |
| 検証環境デプロイ | QA用パイプラインのみ許可。手動承認を追加 |
| 本番環境デプロイ | 本番用YAMLパイプラインだけ許可。Open accessは避ける |
| 共通読み取り用途 | Reader権限中心。書き込みや削除権限を持たせない |
Microsoftのセキュリティ推奨でも、サービス接続のスコープは必要最小限にし、Azure Resource Managerサービス接続では必要なリソースグループだけを選ぶこと、可能であればWorkload identity federationを使うことが推奨されています。(Microsoft Learn)
Environmentsは「誰がデプロイできるか」と「どのパイプラインが使えるか」を分けて見る
YAMLパイプラインでデプロイ先を管理する場合、Environmentsの権限は重要です。EnvironmentはYAMLパイプライン向けのデプロイターゲットをまとめる機能で、Classic pipelineとは互換性がありません。ロールにはCreator、Reader、User、Administratorがあり、Environment作成者にはそのEnvironmentのAdministratorロールが自動付与されます。(Microsoft Learn)
ここで見るべきポイントは2つあります。
| 観点 | 確認内容 |
|---|---|
| ユーザー・グループのロール | 誰がEnvironmentを閲覧、利用、管理できるか |
| パイプラインアクセス | すべてのパイプラインに開放しているか、特定パイプラインだけに制限しているか |
Environmentのパイプライン権限は、プロジェクト内のすべてのパイプラインに許可するOpen accessと、特定のパイプラインだけを許可する制限アクセスを選べます。Open accessを設定できるのはProject administratorsです。(Microsoft Learn)
本番Environmentでは、Open accessを避け、次のように管理すると安全です。
| 環境 | 推奨設定 |
|---|---|
| dev | 開発チームの主要パイプラインを許可 |
| staging | 検証・リリース候補パイプラインだけ許可 |
| production | 本番リリース用パイプラインだけ許可し、承認プロセスを追加 |
| shared-test | 一時利用を許可する場合も、定期的に利用パイプラインを棚卸しする |
Library、Variable group、Secure filesはシークレット管理の要
Libraryは、Variable groupやSecure filesをビルド・リリースパイプライン間で共有するための領域です。ロールにはAdministrator、Creator、Reader、Userがあり、Libraryレベルで設定したロールは配下のアセットへ適用されますが、個別アセットで調整することもできます。(Microsoft Learn)
Secure filesとVariable groupは、既定ではプロジェクトレベルのLibraryロールを継承します。個別ファイルや個別変数グループで権限を上書きできますが、継承されたユーザーやグループを削除したり、権限を下げたりするには継承を無効にする必要があります。(Microsoft Learn)
失敗しやすいのは、次のような設定です。
| ありがちな設定 | リスク | 対応 |
|---|---|---|
| Project Valid Usersに広くReaderを残す | 変数名や構成情報の露出につながる | 機密グループは閲覧者も限定する |
| ContributorsにCreatorを広く許可 | 誰でも変数グループを作れて管理が分散する | 作成権限をチームリードやDevOps担当に絞る |
| Secure filesを複数パイプラインで使い回す | 証明書や秘密鍵の利用経路が追いにくい | 用途別にファイルを分け、利用パイプラインを限定する |
| 個人にAdministratorを直接付与 | 異動・退職時に権限が残りやすい | グループ付与へ変更する |
シークレットは、可能であればYAML内に書かず、UI、Variable group、Azure Key Vaultなどから参照します。Microsoftのセキュリティ推奨でも、シークレットをYAMLに平文で置かないこと、ログやコマンドラインに出力しないこと、必要に応じてローテーションすることが示されています。(Microsoft Learn)
Agent poolは横展開リスクを意識して分ける
Agent poolは、ビルドやリリースジョブを実行するエージェントの集合です。Azure Pipelinesでは、組織スコープまたはプロジェクトスコープのAgent poolを作成できます。組織スコープのAgent poolは既存または新規プロジェクトから利用でき、プロジェクトスコープのAgent poolは対象プロジェクトだけで利用されます。(Microsoft Learn)
自己ホストエージェントを使っている場合は、特に慎重に確認してください。エージェントは社内ネットワーク、ビルド成果物、キャッシュ、ツールチェーン、クラウド認証に近い場所で動くため、パイプラインの悪用時に影響が広がりやすいからです。
公式ドキュメントでは、Agent poolのセキュリティロールを組織、コレクション、プロジェクト、個別プールの単位で管理できること、個別Agent poolではパイプライン権限を特定パイプラインに制限できることが示されています。(Microsoft Learn)
実務では、次の分離が有効です。
| Agent pool | 用途 | 注意点 |
|---|---|---|
| dev-build-pool | 開発ビルド、単体テスト | 機密情報を置かない |
| staging-deploy-pool | 検証環境デプロイ | 利用パイプラインを制限する |
| prod-deploy-pool | 本番デプロイ | 最小権限、承認、監査ログ確認を徹底する |
| external-pr-pool | 外部PRやforkビルド | Microsoft-hosted agentの利用を優先する |
Microsoftのセキュリティ推奨でも、Microsoft-hosted agentsの利用、プロジェクトごとのエージェント分離、自己ホストエージェントの低権限アカウント運用、機密プールの分離、定期的な更新が推奨されています。(Microsoft Learn)
Classic pipelineからYAMLへの移行で注意すべき点
Azure Pipelinesでは、Classic pipelineよりもYAML pipelineを使うことがセキュリティ面で推奨されています。YAMLはパイプライン定義をコードとして扱えるため、Pull Request、ブランチポリシー、レビュー、テンプレートによる統制と相性がよいからです。Microsoftの推奨でも、Classic pipelineを使っている場合はYAMLへの移行が案内されています。(Microsoft Learn)
ただし、移行は単純な置き換えではありません。特に次の点に注意してください。
| 移行時の確認点 | 理由 |
|---|---|
| Classic releaseのステージ権限 | YAMLへ移行すると管理単位が変わるため、承認やEnvironment権限で再設計する必要がある |
| Task group | Task groupはYAML pipelineではサポートされず、代わりにテンプレートを使う |
| Service connection | 旧パイプライン用にOpen accessになっている可能性がある |
| Variable group | 移行後のYAMLから参照できる範囲を確認する |
| Agent pool | Classic時代の共有プールをそのまま使うと分離が不十分になりやすい |
Task groupについては、公式ドキュメントでYAML pipelineではサポートされず、テンプレートが利用できると説明されています。ClassicからYAMLへ移行する際は、Task groupの処理をYAMLテンプレートへ置き換え、テンプレートリポジトリの権限もあわせて管理してください。(Microsoft Learn)
開発者が確認すべきポイント
管理者だけでなく、パイプラインを作成・修正する開発者もAzure Pipelines セキュリティの一部を担います。特に、YAMLに書く内容はレビュー対象にし、実行時に任意のコマンドや変数を受け付けすぎないようにする必要があります。
開発者が確認すべきポイントは次のとおりです。
| 項目 | 確認すること |
|---|---|
| YAML内のシークレット | パスワード、キー、トークンを平文で書いていないか |
| Queue-time variables | 実行時に任意の変数を追加できる状態になっていないか |
| Parameters | 選択肢や型を制限し、任意文字列をそのままシェルへ渡していないか |
| Scripts | PATHに依存せず、必要に応じてフルパスや入力検証を使っているか |
| Templates | 共通テンプレートを安全なリポジトリで管理しているか |
| Fork builds | 外部forkにシークレットを渡していないか |
Microsoftの推奨では、シェルタスク引数の検証、キュー時に設定できる変数の制限、変数よりパラメーターの利用、settableVariablesによる変数設定の制限などが紹介されています。(Microsoft Learn)
展開時の実践手順
Azure Pipelines セキュリティの見直しは、一度に全設定を変えるとビルド停止やデプロイ失敗を招きます。次の順番で進めると、影響を抑えながら安全性を上げられます。
| フェーズ | 作業内容 | 成果物 |
|---|---|---|
| 棚卸し | パイプライン、サービス接続、Environment、Library、Agent poolを一覧化する | リソース一覧 |
| リスク分類 | 本番接続、シークレット利用、自己ホストエージェント利用を高リスクに分類する | 優先度リスト |
| 権限確認 | Open access、個人付与、継承無効、Administrator付与を確認する | 権限レビュー表 |
| 制限設定 | 高リスクなリソースから特定パイプラインのみに制限する | 変更履歴 |
| テスト | 開発、検証、本番前の順にパイプライン実行を確認する | テスト結果 |
| 定着 | 月次または四半期で権限レビューを行う | 運用ルール |
最初の対象は、本番Azureリソースへ接続するサービス接続、production Environment、本番デプロイ用Agent pool、Secure filesです。この4つを先に確認するだけでも、実害につながる設定ミスを減らしやすくなります。
失敗しやすいポイント
Open accessを「便利だから」で残す
Open accessは、すべてのパイプラインから対象リソースを使えるため便利です。しかし、本番サービス接続や本番Environmentで使うと、別チームのパイプラインや検証用パイプラインから重要リソースへ到達できる可能性が高まります。
個人アカウントにAdministratorを直接付ける
一時対応のために個人へAdministratorを付与し、そのまま残るケースはよくあります。権限はできるだけグループへ付与し、個人付与が必要な場合は期限と理由を記録します。
継承を無効にした理由が残っていない
継承の無効化は有効な手段ですが、理由が残っていないと後から戻せません。例外設定には「なぜ必要か」「誰が承認したか」「いつ見直すか」を残してください。
Classic時代の設定をYAML移行後も放置する
YAMLへ移行しても、古いRelease pipeline、Task group、Deployment group、共有Agent poolが残っていることがあります。使っていないリソースでも、権限が残っていれば管理対象です。
シークレットをログで漏らす
Azure Pipelinesはシークレットのマスクを試みますが、すべての漏えいパターンを防げるわけではありません。JSONのような構造化データを1つのシークレットにする、コマンドライン引数に直接渡す、ログにechoする、といった運用は避けるべきです。(Microsoft Learn)
まず今日やるべきチェックリスト
最後に、管理者がすぐ実行できるチェックリストをまとめます。
| チェック | 完了 |
|---|---|
| 本番向けService connectionがOpen accessになっていないか確認する | □ |
| production Environmentを利用できるパイプラインを確認する | □ |
| Secure filesとVariable groupのAdministratorを確認する | □ |
| 自己ホストAgent poolを使えるパイプラインを確認する | □ |
| 個人アカウントに直接付与された管理権限を洗い出す | □ |
| 継承を無効にしているリソースと理由を記録する | □ |
| Classic pipeline、Task group、Deployment groupの残存を確認する | □ |
| YAML内にシークレットや過度に自由な変数入力がないか確認する | □ |
| forkビルドにシークレットを渡していないか確認する | □ |
| 変更後に主要パイプラインの実行テストを行う | □ |
Azure Pipelines セキュリティは、単に「パイプラインを実行できる人」を制限するだけでは不十分です。サービス接続、Environment、Library、Agent poolまで含めて、どのパイプラインが何にアクセスできるかを整理することが重要です。まずは本番環境に関わるリソースからOpen accessとAdministrator付与を確認し、必要なパイプラインだけに絞るところから始めてください。
コメント