Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
運用を実行するコードを保護するには、組織はソース コード リポジトリへのアクセスを慎重に制御する必要があります。 この記事では、Azure Pipelines のビルドおよびリリース パイプラインがリポジトリに安全にアクセスして、承認されていないアクセスのリスクを最小限に抑える方法について説明します。
この記事は、Azure Pipelines のセキュリティ対策を実装するのに役立つシリーズの一部です。 詳細については、「 Azure Pipelines のセキュリティ保護」を参照してください。
[前提条件]
| カテゴリ | 必要条件 |
|---|---|
| Azure DevOps | - Azure DevOps をセキュリティで保護し、Azure Pipelines を セキュリティで保護する方法に関するページの推奨事項を実装します。 - YAML と Azure Pipelines に関する基本的な知識。 詳細については、「最初の パイプラインを作成する」を参照してください。 |
| 権限 | - パイプラインのアクセス許可を変更するには: プロジェクト管理者グループのメンバー。 - 組織のアクセス許可を変更するには: プロジェクト コレクション管理者グループのメンバー。 |
プロジェクトベースのパイプラインID
パイプラインでは、実行中に ID を使用して、リポジトリ、サービス接続、変数グループなどのリソースにアクセスします。 パイプラインでは、コレクション レベルまたはプロジェクト レベルの 2 種類の ID を利用できます。
コレクション レベルの ID は簡単に設定して使用できますが、プロジェクト レベルの ID はセキュリティに優先順位を付けます。 セキュリティを強化するには、プロジェクト レベルの ID を使用してパイプラインを実行します。 プロジェクト レベルの ID は、そのプロジェクト内でのみリソースにアクセスでき、悪意のあるアクターによる不正アクセスの影響を最小限に抑えます。 詳細については、「 スコープ付きビルド ID と ジョブ承認スコープ」を参照してください。
プロジェクト レベルの ID を使用するようにパイプラインを構成するには、非リリース パイプラインの場合はジョブ承認スコープを現在のプロジェクトに制限するか、パイプライン プロジェクトの [プロジェクト設定] の [Pipelines>] で、リリース パイプラインのジョブ承認スコープを現在のプロジェクトに制限します。
リポジトリ のアクセス セキュリティを強化する手順
プロジェクト管理者またはプロジェクト コレクション管理者は、パイプラインから Git リポジトリにアクセスするためのセキュリティを強化するために、次の手順を実行できます。
パイプラインを調べて、他のプロジェクトにある必要なリポジトリを特定します。 リリース以外のパイプラインでジョブ承認スコープを現在のプロジェクトに制限するを有効にした場合、パイプラインは現在のプロジェクトのリポジトリからのみコードをチェックアウトできます。
パイプライン プロジェクトに、必要な他のプロジェクトへのアクセス権を付与します。 詳細については、「 同じプロジェクト コレクション内の別のプロジェクトにアクセスするためのプロジェクトのアクセス許可を構成する」を参照してください。
パイプライン ビルド ID に、チェックアウトした各リポジトリへの 読み取り アクセス権を付与します。また、パイプライン ID に、必要なリポジトリによってサブモジュールとして使用されるすべてのリポジトリへの 読み取り アクセス権を付与します。 詳細については、「 同じプロジェクト コレクション内の別のリポジトリにアクセスするためのアクセス許可を構成する」を参照してください。
パイプライン プロジェクトの次の組織またはプロジェクト設定を有効にします。
- リリース以外のパイプラインのジョブ承認スコープを現在のプロジェクトに制限します。
- プロジェクトにリリース パイプラインがある場合は、リリース パイプラインのジョブ承認スコープを現在 のプロジェクトに制限します。
- プロジェクトに Azure Repos YAML パイプラインがある場合は、YAML パイプライン内のリポジトリへのアクセスを保護します。
これらの設定を有効にするには、組織の設定またはプロジェクトの設定>>> でトグルをオンに設定します。
[組織の設定] で設定が有効になっている場合は、[プロジェクトの設定] で上書きすることはできません。 [組織の設定] で設定が有効になっていない場合は、プロジェクト レベルで有効にすることができます。
サブモジュールとしてリポジトリを使用する
リポジトリがプロジェクト内の別のリポジトリをサブモジュールとして使用している場合、パイプラインに両方のリポジトリへの 読み取り アクセス権を付与した場合でも、サブモジュールをチェックアウトするときにチェックアウトが失敗する可能性があります。 この問題を解決するには、まずサブモジュール リポジトリをチェックアウトし、その後にサブモジュールを使用するリポジトリをチェックアウトしてください。 詳細については、 サブモジュールのチェックアウトを参照してください。
GitHub リポジトリ
GitHub リポジトリへのパイプライン アクセスには、次のセキュリティに関する考慮事項が適用されます。 詳細については、「Github リポジトリへのアクセス」を参照してください。
GitHub サービス接続
GitHub リポジトリを使用するには、Azure Pipelines に GitHub サービス接続が必要です。 サービス接続のセキュリティを強化するには:
- パイプラインの実行が必要なリポジトリへのアクセスのみを許可します。
- [サービス接続 のすべてのパイプラインにアクセス許可を付与 する] を選択しないでください。 使用する各パイプラインのために、サービス接続を明示的に承認します。
GitHub リポジトリへの認証
ビルドをトリガーし、ビルド中にコードをフェッチするには、Azure Pipelines に GitHub リポジトリへのアクセス権を付与する必要があります。 このアクセスでは、GitHub 個人用アクセス トークン (PAT)、OAuth、または GitHub Azure Pipelines アプリ認証を使用できます。 詳細については、「Github リポジトリへのアクセス」を参照してください。
GitHub Azure Pipelines アプリは、継続的インテグレーション (CI) パイプラインに推奨される認証の種類です。 ビルドと GitHub の状態の更新では、個人の GitHub ID を使用するのではなく、Azure Pipelines ID を使用します。 アプリをインストールするときに、セキュリティを強化するためにアプリがアクセスできるリポジトリを制限できます。
OAuth および PAT 認証では、個人の GitHub ID が使用され、パイプライン アクセスが承認されている必要があります。 セキュリティ上の問題のため、PAT を使用することはお勧めしません。 PAT 認証を使用する必要がある場合は、きめ細かい PAT を選択し、特定のユーザー、リポジトリ、およびアクセス許可にスコープを制限します。 詳細については、「 個人用アクセス トークンの管理」を参照してください。
注
GitHub 組織内のすべてのリポジトリに GitHub アプリをインストールすると、アプリが使用するトークンは、組織内のすべてのプライベート リポジトリとパブリック リポジトリにアクセスできます。 セキュリティを強化するには、プライベート リポジトリを別の組織に分離するか、アプリがアクセスできるリポジトリを明示的に選択します。
フォークされた GitHub リポジトリ
フォークされたリポジトリは、パイプラインでの悪意のあるコード実行や機密情報のリリースのリスクを高めます。 組織外から発生したフォークは、特定のリスクを引き起こす可能性があります。
フォークされたリポジトリからのリスクを最小限に抑えるには、 フォークされた GitHub リポジトリからのプル要求のビルドを制限 し、 フォークされたリポジトリからのプル要求のビルドを無効にします 。既定では、 プロジェクト設定 または 組織の設定>Pipelines>Settings>Triggers で有効になっています。
フォークされた GitHub リポジトリからのビルドを許可し、リスクを軽減するには、[ フォークされたリポジトリからプル要求を安全にビルドする] を選択します。 この設定では、シークレットを使用できるようにするか、通常のビルドと同じアクセス許可を使用することを禁止します。パイプラインをトリガーするには、チーム メンバーからの PR コメントが必要です。
または、 フォークされたリポジトリからプル要求を作成するためのルールのカスタマイズ を選択して、これらの設定をさらにカスタマイズすることもできます。
フォーク セキュリティを強化するその他の方法は次のとおりです。
pull request 検証を使用してビルドをトリガーする場合は、パイプライン定義のトリガーセクションでこのリポジトリのフォークからのプルリクエストをビルドするの選択を解除するか、フォークのビルドでシークレットを利用可能にするおよびフォークビルドの権限を通常のビルドと同じにするの選択を解除することを確認します。 pull request を作成する前に、[チーム メンバーのコメントを要求する] を選択することもできます。
Microsoft でホストされるエージェントを使用して、フォークからビルドします。 その後、ビルド後すぐにエージェントからリソースが削除されます。 セルフホステッド エージェントを使用する場合は、エージェントを定期的にクリーンアップして更新するか、異なるフォークまたはブランチに個別のエージェントを使用します。
Azure Repos リポジトリ
YAML パイプライン内のリポジトリへのアクセスを保護する
[YAML パイプラインプロジェクトまたは組織のリポジトリへのアクセスを保護する] 設定では、YAML パイプラインに対するきめ細かいアクセス許可が提供されます。 この設定により、YAML パイプラインは、プロジェクトに関係なく、リポジトリにアクセスするためのアクセス許可を明示的に要求します。 詳細については、「 YAML パイプラインのリポジトリへのアクセスを保護する」を参照してください。
注
[YAML パイプライン内のリポジトリへのアクセスを保護する] 設定は、GitHub リポジトリには適用されません。
この設定を有効にすると、Azure Repos YAML パイプラインは常に、初めて実行するときにリポジトリにアクセスするためのアクセス許可を要求します。 次のスクリーンショットのようなアクセス許可要求が表示されます。
パイプライン リポジトリまたはリソースにアクセス許可を付与するには、[ 許可] を選択します。 パイプラインは成功しました。
git コマンド ラインを使用して他のリポジトリをチェックアウトする
git clone https://github/fabrikam-tailspin/FabrikamFiber/_git/OtherRepo/するが有効になっていると、のようなコマンド ライン スクリプトが失敗する可能性があります。 この問題を解決するには、OtherRepoなどの checkout コマンドを使用して、checkout: git://FabrikamFiber/OtherRepo リポジトリを明示的にチェックアウトします。
Azure Repos の例
次の例は、パイプライン内の Azure Repos アクセスのセキュリティを強化するプロセスを示しています。
https://dev.azure.com/fabrikam-tailspin組織には、SpaceGameWeb プロジェクトと FabrikamFiber プロジェクトが含まれています。
SpaceGameWeb プロジェクトには、SpaceGameWeb リポジトリと SpaceGameWebReact リポジトリが含まれています。
FabrikamFiber プロジェクトには、FabrikamFiber、FabrikamChat、および FabrikamFiberLib リポジトリが含まれています。 FabrikamFiber リポジトリは、FabrikamFiberLib リポジトリをサブモジュールとして使用します。
SpaceGameWeb プロジェクトの SpaceGameWeb パイプラインは、SpaceGameWeb プロジェクトの SpaceGameWebReact リポジトリ、FabrikamFiber プロジェクトの FabrikamFiber リポジトリと FabrikamChat リポジトリをチェックアウトします。
プロジェクトベースのビルド ID を使用するか、YAML パイプライン内のリポジトリへのアクセスを保護するようにプロジェクトが設定されていない場合、 SpaceGameWeb パイプラインは組織内のすべてのプロジェクトのすべてのリポジトリにアクセスして正常に実行できます。
プロジェクト レベルの ID を使用する
セキュリティを強化するには、プロジェクト レベルの ID を使用してパイプラインを実行します。 [プロジェクトの設定] または [組織の設定] で、[リリース以外のパイプラインのジョブ承認スコープを現在のプロジェクトに制限する] トグルを有効にします。
この設定が有効になっている場合、パイプラインは SpaceGameWeb プロジェクト内のリソースにのみアクセスできます。このプロジェクトには、 SpaceGameWeb リポジトリと SpaceGameWebReact リポジトリのみが含まれます。 FabrikamFiber プロジェクトのリポジトリをチェックアウトできないため、パイプラインは失敗します。
エラーの remote: TF401019: The Git repository with name or identifier FabrikamChat does not exist or you do not have permissions for the operation you are attempting と remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attemptingが表示されます。
問題を解決するには、パイプライン プロジェクトに FabrikamFiber プロジェクトへのアクセス権を付与し、パイプライン ID に FabrikamFiber、FabrikamChat、FabrikamFiberLib リポジトリへの読み取りアクセス権を付与します。
サブモジュールを明示的にチェックアウトする
FabrikamFiber リポジトリは、FabrikamFiberLib リポジトリをサブモジュールとして使用します。 両方のリポジトリへのアクセス権をパイプラインに付与した場合でも、 FabrikamFiberLib サブモジュールをチェックアウトするときに FabrikamFiber リポジトリのチェックアウトは失敗します。
この問題を解決するには、 FabrikamFiberLib リポジトリをチェックアウトする前に、 FabrikamFiberLib リポジトリを明示的にチェックアウトしてください。
checkout: git://FabrikamFiber/FabrikamFiberLibステップの前にcheckout: FabrikamFiberステップを追加します。 パイプラインの例が成功しました。
YAML パイプラインへのアクセスを保護する
例の SpaceGameWeb パイプラインが YAML パイプラインで、YAML パイプライン内のリポジトリへのアクセスを保護するが有効になっている場合、パイプラインには、最初に実行されるときに SpaceGameWebReact、FabrikamFiber、および FabrikamChat リポジトリにアクセスするためのアクセス許可が必要です。
次のコードは、完全な YAML パイプラインを示しています。
trigger:
- main
pool:
vmImage: ubuntu-latest
resources:
repositories:
- repository: SpaceGameWebReact
name: SpaceGameWeb/SpaceGameWebReact
type: git
- repository: FabrikamFiber
name: FabrikamFiber/FabrikamFiber
type: git
- repository: FabrikamChat
name: FabrikamFiber/FabrikamChat
type: git
steps:
- script: echo "Building SpaceGameWeb"
- checkout: SpaceGameWebReact
- checkout: FabrikamChat
condition: always()
- checkout: git://FabrikamFiber/FabrikamFiberLib
- checkout: FabrikamFiber
submodules: true
condition: always()
- script: |
cd FabrikamFiber
git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
- script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md
リポジトリのその他のセキュリティ対策
リソースを共有する YAML およびクラシック パイプラインからのセキュリティ リスクを軽減するには、[プロジェクトの設定] または [組織の設定] で [クラシック ビルド パイプラインの作成を無効にする] と [クラシック リリース パイプラインの作成を無効にする] トグルをオンにして、クラシック パイプラインの作成を無効にします。 クラシック ビルドおよびリリース パイプラインの作成は、新しい組織では既定で無効になっています。
パイプライン テンプレートを使用して パイプライン構造を定義し、悪意のあるコード侵入を防ぎます。 テンプレートでは、資格情報のスキャンや保護されたリソースに対するチェックの適用などのタスクを自動的に実行することもできます。
承認されていない ブランチ でパイプラインが自動的に実行されないようにするには、保護されたブランチ チェックを使用します。
指定した YAML パイプラインでのみ使用するリポジトリを設定します。 詳細については、「 パイプラインのアクセス許可をリポジトリ リソースに追加する」を参照してください。
Azure Pipelines アクセス トークンのスコープを制限します。このトークンは、パイプラインの
resourcesセクションに記載されているリポジトリに対してのみ指定します。 詳細については、「 リポジトリの保護」を参照してください。