CI/CD パイプラインの保護: 自己の危険性を探る

ホーム » セキュリティ ブロガー ネットワーク » CI/CD パイプラインの保護: セルフホスト型エージェントの危険性を探る

継続的インテグレーション/継続的デプロイメント (CI/CD) パイプラインは、最新のソフトウェア開発実践にとって重要になっています。 CI/CD パイプラインは、コードの構築、テスト、デプロイのプロセスを自動化することで、開発効率とソフトウェアの品質を大幅に向上させることができます。 最新の CI/CD プラットフォーム (GitHub アクション、Circle CI など) では、セルフホスト ランナー (CI/CD プラットフォームではなくユーザーがホストするエージェント) 上でパイプライン プロセスを実行し、ジョブを実行するオプションが提供されています。独自のインフラストラクチャ。

自己ホスト型ランナーを使用すると、大規模なジョブを実行するための処理能力やメモリを備えたニーズを満たすカスタム ハードウェア構成を作成できます。 さらに、ローカル ネットワークで利用可能なソフトウェアをインストールし、プラットフォームで提供されていないオペレーティング システムを選択することもできます。 自己ホスト型ランナーは、物理的、仮想的、コンテナー内、オンプレミス、またはクラウド環境内にあります。 別の方法は、ユーザーが環境を制御できない SaaS CI/CD プラットフォームによって提供される、Build-as-a-Service ランナーを使用することです。

自己ホスト型ランナーを使用する理由はいくつかあります。

コンプライアンスとプライバシー: 多くの組織は、機密データを構築して SaaS 構築サービスに送信することを妨げる厳しい規制に縛られています。 たとえば、金融部門や政府部門の組織は、内部サーバーでビルドを実行することを好むことがよくあります。

特別な仕様: 一般的ではないオペレーティング システムや異なるアーキテクチャ用のソフトウェアを構築する場合、構築プロセスには要件に一致する仕様のマシンが必要です。 これは、多くの組み込みアプリケーション、IoT アプリケーション、またはクライアント側アプリケーションにも当てはまります。

コストの節約: 既存のクラウド インフラ/プライベート クラウドを備えている組織は、セルフホスト ランナーを使用し、リソース プールを自分で管理することを選択すると、コストを節約できます。

上記の理由から、自主主催ランナーは多くの組織で人気を集めています。 ただし、自己ホスト型ランナーは、特に信頼できないワークフローが実行されている場合、重大なセキュリティ リスクを引き起こす可能性があります。 悪意のあるプログラムはビルド マシンを侵害し、ランナーのサンドボックスから脱出し、マシンのネットワークへのアクセスや機密情報などを公開する可能性があります。

自己ホスト型ランナーを使用すると、パフォーマンスの向上や環境制御の強化などの利点が得られます。 ただし、これにはセキュリティ上のリスクも伴います。

セルフホスト型ランナーの動作には、専用のサーバーまたは仮想マシン (VM) が必要です。 これらのサーバーのセキュリティは非常に重要です。 ランナーをホストするサーバーが適切に保護されていない場合、攻撃者の潜在的な侵入ポイントとなる可能性があります。

通常、セルフホスト ランナーには、リポジトリおよびランナーがインストールされているシステムへの特権アクセスが必要です。 アクセス制御を慎重に管理し、ランナーに付与される権限を制限することが重要です。 ランナーへの不正アクセスは、潜在的なデータ侵害や悪意のあるコードの実行につながる可能性があります。

自己ホスト型ランナーを重要なシステムや機密データから隔離しないと、侵害されたランナーが不正アクセスや潜在的なデータ侵害につながるリスクが高まります。 適切に分離しないと、ランナーの制御を取得した攻撃者がネットワーク内を横方向に移動し、他のシステムやデータを侵害する可能性があります。

自己ホスト型ランナー ソフトウェアの定期的な更新と監視を怠ると、システムが既知の脆弱性にさらされ、攻撃を受けやすくなります。 タイムリーなセキュリティ パッチとアップデートがなければ、攻撃者はランナー ソフトウェアの既知の弱点を悪用する可能性があります。 監視が不十分な場合、悪意のあるアクティビティが検出されない可能性が高まり、セキュリティ インシデントへの対応が遅れ、不正アクセスや損害が長期間にわたって発生する可能性があります。

許可されたユーザーへのアクセスを制限せずにセルフホスト ランナーを使用すると、誰でも仮想通貨マイニングやその他の金銭的損害を与える可能性のあるアクティビティにコンピューティング リソースを悪用できます。

GitHub Actions は、ソフトウェア開発用の強力な CI/CD 自動化ツールとして近年大幅に採用されています。 GitHub Actions を使用すると、開発者はソフトウェアの構築、テスト、デプロイなどのタスクを自動化し、より重要なタスクに集中できるようになります。 GitHub Actions は、事前に構築されたアクション、コミュニティによって構築されたアクション、独自のアクションを作成する機能など、幅広いカスタマイズ オプションを提供します。 GitHub Actions を採用する組織が増えるにつれて、GitHub Actions は最新のソフトウェア開発にとってますます重要なツールになってきています。

GitHub には、自己ホスト型ランナーを使用するオプションも提供されています。 単一のリポジトリ専用のリポジトリ レベルのランナー、組織内の複数のリポジトリのジョブを処理できる組織レベルのランナー、割り当て可能なエンタープライズ レベルのランナーなど、管理階層のさまざまなレベルでセルフホスト ランナーを追加できます。エンタープライズアカウント内の複数の組織に。

研究中に、私たちは徹底的に調べました300 万のパブリックリポジトリ。リポジトリごとに、さまざまな GitHub Actions ファイルを検査し、各ジョブで使用されるランナーを抽出しました。 チェックした 3,106,445 個のパブリック リポジトリのうち、43,803 個が自己ホスト ランナーを使用していることがわかりました。 パブリック リポジトリでセルフホスト ランナーを使用すると、世界中の GitHub ユーザーが攻撃を開始する可能性があるため、想定されるリスクが大幅に増加します。

GitHub は、セルフホスト ランナーを構成するためのいくつかのオプションを組織に提供します。 ユーザーは、潜在的なリスクを防ぐために、組織が構成のベスト プラクティスに従っていることを確認する必要があります。

ランナー グループ: 自己ホスト型ランナーが組織レベルまたはエンタープライズ レベルで定義されている場合、GitHub は複数のリポジトリから同じランナーへのワークフローをスケジュールできます。 したがって、これらの環境でセキュリティが侵害されると、広範囲に影響が及ぶ可能性があります。 妥協の範囲を減らすために、自己ホスト ランナーを別のグループに編成することで境界を作成できます。

パブリック リポジトリの禁止:パブリック リポジトリでセルフホスト ランナーを使用し、アクセス制御を適切に構成していない場合、攻撃者が悪意のあるワークフローを実行するプル リクエストを作成することにより、セルフホスト ランナー マシンにアクセスできる可能性があります。 これにより、自己ホスト型ランナー マシンのアクセス レベルに応じて、攻撃者がマシン上で任意のコードを実行したり、機密データにアクセスしたり、その他の悪意のあるアクションを実行したりする可能性があります。

たとえば、攻撃者はプル リクエスト内のコードを変更して、自己ホスト型ランナー マシンにマルウェアをインストールしたり、組織から機密データを盗んだりするコマンドを実行する可能性があります。 これは、データ侵害、知的財産の損失、組織の評判の低下などの深刻な結果につながる可能性があります。

リスクを回避するには、プライベート リポジトリでのみセルフホスト ランナーを使用することをお勧めします。 攻撃対象領域を制限し、セルフホスト型ランナー マシンへの不正アクセスのリスクを軽減できます。

アクセス制御:ランナー グループにアクセスできる組織とリポジトリを制限できます。 さらに、ランナーを特定のワークフローに制限できます。 詳細については、「グループを使用した自己ホスト ランナーへのアクセスの管理」を参照してください。

@ryotkak が投稿したブログ投稿では、自己ホスト型ランナーがどのようにリスクをもたらし、誤って使用すると機密情報の盗難につながる可能性があるかの例を見ることができます。 ryotkak は、GitHub によって作成されたワークフローの例を示しています。 脆弱なワークフローはアクション フレームワーク自体の一部です。 特定の条件下では、自己ホスト型ランナーはあらゆる攻撃者に到達可能でした。 この例で盗まれたトークンは、GitHub 自体の開発者が所有するトークンであり、攻撃者はこれを利用して広範囲に影響を与えるソフトウェア サプライ チェーン攻撃を実行できる可能性がありました。

このデモでは、自己ホスト型ランナーを使用してパブリック GitHub リポジトリを作成する方法を示します。 この例は、外部の悪意のある協力者がいくつかの攻撃を実行することを示しています。

最初の画像では、ランナー pwn_me がランナー グループ プールに追加されていることがわかります。

次のステップは、自己ホスト型ランナーで実行され、pull_request トリガーによってトリガーされるワークフローを構成することでした。

攻撃者が行う必要があるのは、ランナーの秘密と機密情報を取得する変更されたワークフロー ファイルを含むフォークを作成することだけです。 悪意のある投稿者によって作成されたジョブの例:

このビデオでは、例としてフォークからプル リクエストを作成し、/etc/passwd ファイルへのアクセスを取得する方法を示しています。

次のベスト プラクティスは、すべての CI/CD セルフホスト プラットフォームに当てはまります。 GitHub Actions Jenkins、GitLab、またはその他のプラットフォームを使用するかどうかに関係なく、次のガイドラインは、セルフホスト ランナーの安全とソフトウェア サプライ チェーンの安全を保つのに役立ちます。

機密情報がランナー上に保存されていないことを確認してください。 たとえば、プライベート SSH キーや API アクセス トークンなどです。

ランナーが他の内部資産に最小限のネットワーク アクセスを持っていることを確認してください。 たとえば、Azure や AWS の管理コンソールやメタデータ サービスなどです。 管理コンソールとメタデータ サービスは、クラウド環境管理を取得したり、情報を実行したりするためにクラウド ベンダーが提供するパネルです。 これらのリソースにアクセスできる攻撃者は、被害者のクラウド構成を変更したり、攻撃対象領域を拡大したりする可能性があります。 この環境における機密情報の量は最小限にする必要があります。 ワークフローを呼び出すことができるすべてのユーザーがこの環境にアクセスできることに常に留意する必要があります。

ランナー内のすべてのサービスが最新であり、既知の脆弱性がないことを確認します。

永続性を回避 – 各ジョブがクリーンで新しいエージェント コンテナ/VM 上で実行されるようにします。

コンテナを使用する場合は、最小限の権限で実行してください。

コンテナーを特権モードで実行しないでください。

コンテナーが専用デバイスにマウントされており、ホストとリソースを共有していないことを確認してください。

ホストごとに 1 つのコンテナのみを実行します。

通信に HTTPS を使用する: HTTPS を使用してセルフホスト ランナーと GitHub 間の通信を暗号化し、暗号化されていない HTTP の使用を避けます。

全体として、セルフホスティング CI/CD パイプラインは、適切に管理されないとリスクを伴う可能性があります。 潜在的な危険を最小限に抑えるには、セルフホスト エージェントの定期的な更新、アクセス制御の実装、不審なアクティビティの監視など、セキュリティのベスト プラクティスに従うことが重要です。 さらに、組織は、セルフホスト型ソリューションよりも優れたセキュリティと信頼性を提供できるクラウドベースの CI/CD サービスの使用を検討する必要があります。

Legit Security プラットフォームはビルド環境に接続して、パイプライン内の攻撃の試みなどを検出します。 自己ホスト型ランナーを使用するパブリック リポジトリなど、さまざまな構成ミスを特定します。 これらのセキュリティ リスクやソフトウェア サプライ チェーン全体のその他のリスクについて懸念がある場合は、当社までご連絡いただき、当社の Web サイトでデモをリクエストしてください。

*** これは、Nadav Noy によって作成された Legit Security Blog の Security Bloggers Network シンジケート ブログです。 元の投稿を読む: https://www.legitsecurity.com/blog/securing-your-ci/cd-pipeline-exploring-the-dangers-of-self-hosted-agents