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

このシリーズを初めてご覧になる場合は、最初から始めることをお勧めします。 
コンテナ セキュリティの基礎: 導入

アプリケーション資本の時代において、CI/CD パイプラインは、構築および配信されるアプリケーションの速度とセキュリティを左右する重要なコンポーネントです。

これは、API を介して統合され、コンテナ化されたアプリケーションを構築して最終的に配信するために従うプロセスをデジタルで表現するスクリプトまたはプラグインによって呼び出される、複雑なツール システムです。 つまり、悪意のある人物がシステムを侵害する可能性のあるポイントが複数あるということです。 それは無理があるように聞こえるかもしれませんが、今日ではかなりの数の組織がクラウドを活用しており、必然的にリモート アクセスが実現していることを思い出してください。

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

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

1. 認証は必須です
クラウド内のパイプラインの一部として、またはホストされたサービスとしてツールやサービスを使用している場合、それらは攻撃に対して無防備になります。 内部でホストされているツールやサービスへのリモート開発者や操作のアクセスを有効にすると、攻撃に対して無防備になります。 その懸念を無視する前に、システムを外部アクセスに開放したことによる過去数年間の侵害の件数を忘れないようにしましょう。 パイプラインのセキュリティに関して想定すべき最善の姿勢は、悪意のある人物がパイプラインにアクセスできるという認識を持つことです。

つまり、まず最初にすべきことはアクセスのセキュリティを確保することです。 強力な認証はオプションではありません。 重要なシステムへのアクセスを細かく調整するには、アクセス制御の使用を強くお勧めします。 たとえシステムが内部からしかアクセスできないと思っていても。 ネットワーク上には、悪意のある人物がアクセスできる他のシステムも存在します。

認証に取り組んだら、次は認可です。 承認は、認証されたユーザーがシステム内で何ができるかを指定します。 重要なコンポーネントにアクセスできる資格情報が少ないほど有利になるため、役割に基づいて権限を区別することが重要です。

パイプライン内のすべてのコンポーネントには認証と承認が必要です。 つまり、リポジトリからアプリケーションやコンテナの構築に使用されるツールまですべてが含まれます。

2. パイプラインコンポーネントの保護
残念ながら、攻撃者が公開リポジトリをスキャンして膨大な量の宝物（認証情報やその他の秘密）を発見したという報告を聞くことは珍しくありません。 リポジトリで認証を要求するためのリマインダーについては、1 番を参照してください。

今日のパイプラインの現実は、ツールの統合チェーンであり、それぞれのツールに認証が必要であるということです。 そのため、資格情報とシークレット (キー) は、パイプラインを構成するツールとサービスを呼び出すスクリプトに保存されることがよくあります。 これは非常に悪いことです。特に、これらのスクリプトが保存される可能性のあるリポジトリでの認証方法が不十分な場合は、さらに悪いことです。

資格情報は保護する必要がある重要な資産です。 それらがどこに存在し、どこに保管され、どのように保護されているかを認識してください。 「秘密の拡散」を管理するのに役立つツールは、 HashiCorp Vaultです。 Vault は秘密を中央の場所に安全に保管します。

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

3. 部品表を維持する
システム、またはシステムのコンポーネントを保護するには、まずその存在を知る必要があります。 環境内に何が存在するかを確実に把握するために、包括的な部品表を維持することが重要です。 さらに重要なのは、自分の環境に何が存在するべきか、また逆に何が存在するべきでないかについて確実に把握しておく必要があるということです。

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

DockerHub が侵害を受け、190,000 人のユーザーの認証情報とトークンが公開されたときがまさにそのケースでした。 その情報を使用することで、攻撃者はイメージを侵害し、後で他のシステムにアクセスできるようになる可能性があります。

コンテナ イメージだけで止まらないでください。 外部ソースのアプリケーション コンポーネントは侵害される可能性があることに注意してください。 具体的な例としては、 NodeJS NPM パッケージのイベント ストリームに暗号マイニング ソフトウェアを挿入することが挙げられます。

イメージとコンポーネントの維持されたインベントリを標準化することで、脆弱性が発生した場合でも、脆弱性の修復が効率化されます。 単一の基本 OS レイヤーを更新する方が、異なるコンテナー セットを更新するよりもはるかに簡単に管理できます。

4. スキャンと修復
コンテナ環境が侵害されたり、攻撃に対して脆弱になったりする方法は無数にあります。 最もよく考えられるのは、コンテナ イメージ内のソフトウェアの脆弱性です。 スキャンや更新/パッチなど、注意を払う必要がある一方で、検出され対処されることが少ない構成ベースの問題もあります。 これらの多くは、適切な構成によって防ぐことができます。 パイプラインには、侵害を検出したり、安全でない構成について警告したりできるツールを含める必要があります。

Aqua Security は、コンテナと構成のスキャンと評価を支援するツールを提供します。 Kube-bench と kube-hunter は、Kubernetes 環境における一般的な (しかし重大な) 構成ミスを特定するための優れたリソースです。
 

世界中のあらゆるスキャンを実行しても、行動を起こさなければ、侵害や違反を防ぐことはできません。 Tripwire の 2019 年コンテナ セキュリティの現状調査によると、ほぼ 5 社に 1 社 (17%) の組織がコンテナ イメージの脆弱性を認識していたものの、それをそのまま導入していたことがわかりました。 それを考慮すると、調査で組織の半数以上 (60%) が過去 12 か月間にコンテナ関連のセキュリティ インシデントを経験していたことが判明したのも驚くには当たらないかもしれません。

この点は、何度強調しても足りません。セキュリティ スキャンをパイプラインに統合する場合 (統合する必要があります)、発見事項をフォローアップすることが重要です。 修復を行わない場合、スキャンを実行してもセキュリティは向上しません。

繰り返しますが、修復を行わなければ、スキャンを実行してもセキュリティは向上しません。

パイプラインのセキュリティは、困難な多面的な問題です。 パイプラインは、運用上のものではあっても、最終的には他のアプリケーション セットと同じように扱われるため、他のアプリケーション セットと同様に扱う必要があります。 パイプラインにセキュリティを統合する際には、パイプラインのセキュリティを無視しないでください。

シリーズの次のブログをお読みください: 
コンテナ セキュリティの基礎: オーケストレーション