コンテナセキュリティの基礎：パイプラインセキュリティ

このシリーズを初めてお読みになる場合は、最初からご覧になることをおすすめします：
コンテナセキュリティの基礎：はじめに

アプリケーションが資産となる時代において、CI/CDパイプラインは、そこで構築・提供されるアプリケーションのスピードとセキュリティを支える重要な要素です。

これは、APIを介して統合され、スクリプトやプラグインによって呼び出される複雑なツールシステムであり、コンテナ化されたアプリケーションを構築し、最終的に提供するための一連のプロセスをデジタルで表現したものです。つまり、悪意のある攻撃者がシステムを侵害できるポイントが複数存在します。現実味がないように思えるかもしれませんが、現在、多くの組織がクラウドを活用しており、それには必然的にリモートアクセスが伴うことを忘れてはなりません。

つまり、パイプラインセキュリティには2つの側面があります。1つ目は、パイプライン自体のセキュリティです。2つ目は、パイプライン内のセキュリティです。

パイプライン自体のセキュリティ

1. 認証は必須
クラウド上またはホステッドサービスとして、パイプラインの一部にツールやサービスを使用している場合、それらは攻撃にさらされます。社内でホストしているツールやサービスに、リモートの開発者や運用担当者がアクセスできるようにした場合も同様です。この懸念を軽視する前に、システムを外部からアクセス可能にしたことで、過去数年間に数多くの侵害が発生していることを忘れてはなりません。パイプラインのセキュリティについては、悪意のある攻撃者がアクセスできるという前提に立つことが最善です。

したがって、最初に取り組むべきことは、アクセスの保護です。強力な認証は必須です。重要なシステムへのアクセスをきめ細かく制御するため、アクセス制御の使用を強く推奨します。システムには社内からしかアクセスできないと考えている場合でも、ネットワーク上の別のシステムを経由して、悪意のある攻撃者がアクセスする可能性があります。

認証に対処したら、次は認可です。認可では、認証済みユーザーがシステム内で実行できる操作を規定します。重要なコンポーネントにアクセスできる認証情報は少ないほど望ましいため、ロールに基づいて権限を区別することが重要です。

パイプライン内のすべてのコンポーネントで、認証と認可を必須にする必要があります。これには、リポジトリからアプリケーションやコンテナのビルドに使用するツールまで、あらゆるものが含まれます。

2. パイプラインコンポーネントの保護
残念ながら、攻撃者が公開リポジトリをスキャンし、大量の貴重な情報（認証情報やその他のシークレット）を発見したという報告は珍しくありません。リポジトリで認証を必須にする必要性については、1をご確認ください。

今日のパイプラインは、複数のツールが統合された一連の仕組みであり、各ツールで認証を必須とする必要があります。そのため、パイプラインを構成するツールやサービスを呼び出すスクリプトに、認証情報やシークレット（キー）が保存されてしまうことが少なくありません。これは「非常に好ましくないこと™」です。特に、そのようなスクリプトが保存される可能性のあるリポジトリで、認証が適切に行われていない場合は深刻です。

認証情報は、保護が必要な重要資産です。認証情報がどこに存在し、どこに保存され、どのように保護されているかを把握してください。「シークレットの拡散」を管理するうえで役立つツールが、HashiCorp Vaultです。Vaultは、シークレットを一元的かつ安全に保存します。

パイプラインのセキュリティ

3. 部品表を維持する
システムまたはそのコンポーネントのセキュリティを確保するには、まずその存在を把握する必要があります。環境内に何が存在するかを確実に把握できるよう、包括的な部品表を維持することが重要です。さらに重要なのは、環境内に何が存在すべきか、逆に何が存在すべきでないかを確実に把握することです。

適切に管理されたインベントリは、汚染されたコンポーネントや侵害されたコンポーネントをパイプラインに挿入しようとする試みへの対策に役立ちます。単一のベースコンテナ、または少なくとも管理可能な数のコンテナに標準化することで、潜在的な問題を検出する能力を大幅に向上できます。そのため、標準からの逸脱を検出した場合は、調査可能なアラートを発する必要があります。たとえば、ハッシュを比較し、可能であればコンテナイメージのデジタル署名を検証することが重要です。リモートリポジトリから取得する場合、そのリポジトリが侵害されている可能性があります。

実際に、DockerHubで侵害が発生し、ユーザー19万人分の認証情報とトークンが漏えいした事例があります。攻撃者はその情報を利用してイメージを侵害し、後に他のシステムへアクセスできた可能性があります。

コンテナイメージだけにとどまらず、外部から調達したアプリケーションコンポーネントも侵害される可能性があることに留意してください。具体例として、NodeJSのNPMパッケージであるevent-streamへの暗号資産マイニングソフトウェアの挿入が挙げられます。

イメージとコンポーネントを保守管理されたインベントリに標準化することで、いずれ発生する脆弱性への対処も効率化できます。個別に異なるコンテナ群を更新するよりも、単一のベースOSレイヤーを更新する方がはるかに容易に管理できます。

4. スキャンと修復
コンテナ環境が侵害されたり、攻撃を受けやすい状態になったりする原因は多岐にわたります。一般にまず思い浮かぶのは、コンテナイメージ内のソフトウェアに存在する脆弱性です。こうした脆弱性に注意し、スキャンや更新、パッチ適用を行う必要がありますが、検出や対処が見過ごされがちな設定上の問題もあります。その多くは、適切に設定することで防止できます。パイプラインには、侵害を検出したり、安全でない設定について警告したりできるツールを組み込む必要があります。

Aqua Securityは、コンテナと構成の両方のスキャンおよび評価に役立つツールを提供しています。Kube-benchとkube-hunterは、Kubernetes環境でよく見られる（ただし重大な）構成ミスを特定するうえで有用なリソースです。

o FOSS
https://github.com/aquasecurity/kube-bench
https://github.com/aquasecurity/kube-hunter

o 商用
https://www.aquasec.com/

どれほど多くのスキャンを実施しても、その結果に対処しなければ、侵害や情報漏えいの防止には役立ちません。Tripwireの「2019 State of Container Security」によると、約5組織に1組織（17%）がコンテナイメージの脆弱性を認識しながら、そのままデプロイしていました。こうした状況を踏まえると、過去12か月間にコンテナ関連のセキュリティインシデントを経験した組織が半数を超える（60%）という調査結果も、驚くには当たらないでしょう。

この点は、何度強調してもしすぎることはありません。パイプラインにセキュリティスキャンを組み込む場合（組み込むことを推奨します）、検出結果に対処することが重要です。修復を行わなければ、スキャンを実行してもセキュリティの向上にはつながりません。

繰り返します。スキャンを実行しても、検出された問題を修正しなければ、セキュリティの向上にはつながりません。

パイプラインのセキュリティは多面的で、対処が難しい問題です。パイプラインは運用を担うものではありますが、実質的には一連のアプリケーションであるため、ほかのアプリケーション群と同様に扱う必要があります。パイプライン自体のセキュリティを軽視したまま、パイプラインにセキュリティを組み込まないでください。

シリーズの次の記事はこちら：
コンテナセキュリティの基礎：オーケストレーション