Azure Pipelines のその他のセキュリティに関する考慮事項

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Azure Pipelines のセキュリティ保護に関しては、 共有インフラストラクチャの保護、 repositories、、 projects、 など、覚えておく必要がある考慮事項がいくつかあります。

共有インフラストラクチャを保護する

Azure Pipelines の保護されたリソースは、実際のインフラストラクチャを抽象化したものです。 基になるインフラストラクチャを保護するには、次の推奨事項に従ってください。

Microsoft によってホストされているプールを使用する

Microsoft によってホストされているプールは、パイプラインの実行ごとに分離とクリーンな仮想マシンを提供します。 できるだけ、セルフホステッド プールではなく、Microsoft によってホストされているプールを使用してください。

プロジェクトごとにエージェントを分離する

エージェントは、1 つのプールにのみ関連付けることができます。 プールを複数のプロジェクトに関連付けることで、複数のプロジェクト間でエージェントを共有できます。 実際には、複数のプロジェクトで同じエージェントが連続して使用される場合があります。 コスト効率に優れていますが、このアプローチでは横移動リスクが発生する可能性があります。

横方向の移動を軽減し、プロジェクト間のクロスコンタミネーションを防ぐには、それぞれ特定のプロジェクト専用の個別のエージェント プールを維持します。

低い権限のアカウントを使用してエージェントを実行する

誘惑を受けるかもしれませんが、Azure DevOps リソースに直接アクセスできる ID でエージェントを実行すると、リスクが高くなる可能性があります。 このセットアップは、Microsoft Entra ID を使用する組織で広く使用されていますが、リスクが伴います。 Microsoft Entra ID によってサポートされる ID でエージェントを実行すると、ジョブのアクセス トークンに依存することなく、Azure DevOps API に直接アクセスできます。 セキュリティを強化するために、ネットワーク サービスなどの特権のないローカル アカウントを使用してエージェントを実行することを検討してください。

重要

Azure DevOps には、 Project Collection Service Accounts というグループがあり、誤解を招く可能性があります。 継承により、Project Collection Service アカウントのメンバーは、 Project コレクション管理者のメンバーとも見なされます。 一部のお客様は、Microsoft Entra ID に基づく ID を使用してビルド エージェントを実行します。これらの ID は Project Collection Service アカウントの一部である可能性があります。 しかし、敵対者がこれらのビルド エージェントのいずれかでパイプラインを実行すると、Azure DevOps 組織全体を制御できる可能性があります。

セルフホステッド エージェントが高い特権を持つアカウントで動作する場合があります。 これらのエージェントは、多くの場合、これらの特権アカウントを使用してシークレットまたは運用環境にアクセスします。 しかし、敵対者がこれらのビルド エージェントのいずれかで侵害されたパイプラインを実行すると、それらのシークレットにアクセスできます。 その後、敵対者は、これらのアカウントを介してアクセス可能な他のシステムを横方向に移動できます。

システム セキュリティを強化するには、セルフホステッド エージェントを実行するために、最も低い特権のアカウントを使用することをお勧めします。 たとえば、お使いのマシンのアカウントやマネージド サービス ID を使用してください。 また、シークレットと環境へのアクセスの管理を Azure Pipelines に委託します。

サービス接続のスコープを最小限に抑える

サービス接続が必要なリソースにのみアクセスできることを確認します。 可能な場合は常に、Azure サービス接続のサービス プリンシパルの代わりに id フェデレーションworkload を使用することを検討してください。 ワークロード ID フェデレーションでは、業界標準テクノロジである Open ID Connect (OIDC) を使用して、シークレットに依存せずに Azure と Azure DevOps の間の認証を容易にします。

Azure サービス接続が、必要なリソースのみにアクセスするようにスコープ設定されていることを確認します。 Azure サブスクリプション全体に対して広範な共同作成者権限をユーザーに付与することは避けてください。

新しい Azure Resource Manager サービス接続を作成するときは、常に特定のリソース グループを選択します。 リソース グループに、ビルドに必要な VM またはリソースのみが含まれていることを確認します。 同様に、GitHub アプリを構成する場合は、Azure Pipelines を使用してビルドするリポジトリにのみアクセス権を付与します。

プロジェクトを保護する

個々のリソースだけでなく、Azure DevOps のリソース グループを検討することが重要です。 リソースはチーム プロジェクトごとに編成され、プロジェクトの設定と包含に基づいてパイプラインがアクセスできる内容を理解することが不可欠です。

パイプライン内の各ジョブは、開いているリソースを読み取るアクセス許可を持つアクセス トークンを受け取ります。 場合によっては、パイプラインによってこれらのリソースが更新される場合もあります。 つまり、ユーザー アカウントが特定のリソース、スクリプト、およびパイプラインで実行されているタスクに直接アクセスできない場合でも、それにアクセスできる可能性があります。 さらに、Azure DevOps のセキュリティ モデルを使用すると、組織内の他のプロジェクトからこれらのリソースにアクセスできます。 特定のリソースへのパイプライン アクセスを制限する場合、この決定はプロジェクト内のすべてのパイプラインに適用されます。特定のパイプラインに、開いているリソースへのアクセス権を選択的に付与することはできません。

個別のプロジェクト

オープン リソースの性質上、各製品とチームを個別のプロジェクトで管理することを検討してください。 これにより、ある製品からパイプラインが誤って別の製品から開いているリソースにアクセスするのを防ぎ、横方向の露出を最小限に抑えることができます。 しかし、複数のチームまたは製品がプロジェクトを共有する場合、リソースの細かい分離が困難になります。

Azure DevOps 組織が 2019 年 8 月より前に作成された場合でも、すべての組織のプロジェクトで開いているリソースに対して実行がアクセスできる可能性があります。 組織の管理者は、パイプラインのプロジェクト分離を有効にする Azure Pipelines の重要なセキュリティ設定を確認する必要があります。

この設定は、 Organization 設定>Pipelines>Settings、または直接: https://dev.azure.com/Organization_Name/_settings/pipelinessettingsにあります。

リポジトリを保護する

バージョン管理リポジトリには、ソース コード、パイプラインの YAML ファイル、および必要なスクリプトとツールを格納できます。 コードとパイプラインに安全に変更を加えるためには、アクセス許可とブランチ ポリシーを適用することが重要です。 さらに、パイプラインのアクセス許可 追加し、リポジトリに確認することを検討してください。

さらに、リポジトリの 既定のアクセス制御設定 を確認します。

Git の設計は、ブランチ レベルの保護に制限があることを意味します。 リポジトリへのプッシュ アクセスを持つユーザーは、通常、新しいブランチを作成できます。 GitHub オープンソース プロジェクトを使用している場合は、GitHub アカウントを持つすべてのユーザーがリポジトリをフォークし、投稿を提案できます。 パイプラインは (特定のブランチではなく) リポジトリに関連付けられているため、コードファイルと YAML ファイルを信頼できない可能性があるものとして扱う必要があります。

フォーク

GitHub からパブリック リポジトリを使用する場合は、ビルドをフォークするアプローチを慎重に検討することが不可欠です。 フォークは組織外から発生し、特定のリスクを引き起こす。 信頼されていない可能性のあるコードから製品を保護するには、次の推奨事項を考慮してください

Note

これらの推奨事項は、主に GitHub からパブリック リポジトリを構築する場合に適用されます。

フォーク ビルドにシークレットを提供しない

既定では、パイプラインはフォークを構築するように構成されていますが、シークレットと保護されたリソースは、それらのパイプライン内のジョブに自動的には公開されません。 セキュリティを維持するために、この保護を無効にしないことが不可欠です。

Note

フォーク ビルドを有効にしてシークレットにアクセスすると、Azure Pipelines によって既定で使用されるアクセス トークンが制限されます。 このトークンは、通常のアクセス トークンと比較して、開いているリソースへのアクセスが制限されています。 フォーク ビルドに通常のビルドと同じアクセス許可を付与するには、 Make フォーク ビルドに通常のビルドと同じアクセス許可 設定を有効にします。

フォーク ビルドを手動でトリガーすることを検討する

自動フォーク ビルドをオフにし、これらの投稿を手動でビルドする方法として、代わりに pull request のコメントを使用できます。 この設定により、ビルドをトリガーする前にコードを確認できます。

フォーク ビルドには Microsoft ホステッド エージェントを使用する

セルフホステッド エージェントでフォークからビルドを実行しないようにします。 これを行うと、外部組織が企業ネットワーク内のコンピューターで外部コードを実行できるようになります。 可能な限り、Microsoft でホストされるエージェントを使用します。 セルフホステッド エージェントの場合は、ネットワーク分離を実装し、エージェントがジョブ間で状態を保持しないようにします。

コードの変更を確認する

フォークされた pull request でパイプラインを実行する前に、提案された変更を慎重に検討し、実行しても問題がないことを確認します。

実行する YAML パイプラインのバージョンは、プル要求のバージョンです。 したがって、YAML コードと、パイプラインの実行時に実行されるコード (コマンド ライン スクリプトや単体テストなど) に対する変更に特に注意してください。

GitHub のトークン スコープの制限

GitHub でフォークされた pull request をビルドすると、Azure Pipelines は、パイプラインで GitHub リポジトリの内容を変更できないようにします。 この制限は、GitHub との統合に Azure Pipelines GitHub アプリを使用する場合に "のみ" 適用されます。 OAuth アプリなど、他の形式の GitHub 統合を使用する場合、制限は適用されません。

ユーザー ブランチ

適切なアクセス許可を持っている組織のユーザーは、新しいコードまたは更新されたコードを含む新しいブランチを作成できます。 このコードは、保護されたブランチと同じパイプラインを介して実行できます。 新しいブランチの YAML ファイルが変更されると、更新された YAML がパイプラインの実行に使用されます。 この設計により、柔軟性に優れ、セルフサービスが可能になりますが、すべての変更が (悪意を持って行われたかどうかに関係なく) 安全であるわけではありません。

パイプラインが、ソース コードを使用する場合や、Azure Repos で定義されている場合は、Azure Repos のアクセス許可モデルを完全に理解している必要があります。 特に、リポジトリ レベルでブランチの作成アクセス許可を持つユーザーは、コントリビューション アクセス許可がなくても、リポジトリにコードを取り込むことができます。

その他のセキュリティの考慮事項

パイプラインをセキュリティで保護する際に考慮する必要があるその他の事項は次のとおりです。

PATH に依存する

エージェントの PATH 設定に依存することは危険です。 以前のスクリプトやツールによって変更された可能性があるため、それがどこにあると思うかは意味をなさないかもしれません。 セキュリティ クリティカルなスクリプトやバイナリの場合は、常にプログラムへの完全修飾パスを使用します。

シークレットをログに記録する

Azure Pipelines は、可能な限りログからシークレットをスクラブしようとします。 このフィルター処理はベストエフォート ベースであり、シークレットが漏洩するおそれがあるすべての方法をキャッチすることはできません。 シークレットをコンソールにエコーしたり、コマンド ライン パラメーターで使用したり、ファイルにログしたりしないでください。

コンテナーのロックダウン

コンテナーには、ホスト エージェントとの通信に必要な、システムによって提供されるボリューム マウント マッピングが、タスク、ワークスペース、および外部コンポーネントにいくつか用意されています。 これらのボリュームの一部またはすべてを、読み取り専用に設定してください。

resources:
  containers:
  - container: example
    image: ubuntu:22.04
    mountReadOnly:
      externals: true
      tasks: true
      tools: true
      work: false  # the default; shown here for completeness

通常、ほとんどのユーザーは、最初の 3 つのディレクトリを読み取り専用として設定し、 work を読み取り/書き込みのままにする必要があります。 特定のジョブまたはステップで work ディレクトリに書き込まない場合は、 work 読み取り専用にすることもできます。 ただし、パイプライン タスクに自己修正が含まれる場合は、 tasks を読み取り/書き込みとして保持する必要があります。

使用可能なタスクを制御する

Marketplace からタスクをインストールして実行する機能を無効にできます。これにより、パイプラインで実行されるコードをより詳細に制御できます。 また、すべてのインザボックス タスクを無効にすることもできます (チェックアウトを除きます。これはエージェントに対する特別なアクションです)。 インザボックス タスクは、ほとんどの状況では無効にしないことをお勧めします。

tfx で直接インストールしたタスクは常に使用できます。 これらの機能両方を有効にすると、それらのタスクのみ使用できます。

監査サービスを使用する

監査サービスには、多くのパイプライン イベントが記録されます。 監査ログを定期的に確認して、悪意のある変更が過去に滑り落ちないようにします。 https://dev.azure.com/ORG-NAME/_settings/audit にアクセスして始めましょう。

次のステップ

セキュリティの概要を確認する