コンテナイメージのセキュリティ戦略を強化するためのヒント

このブログシリーズの第1回では、使用する可能性のあるベースイメージのセキュリティに関するベストプラクティスを紹介しました。では、ほかのものを追加すると、コンテナイメージのセキュリティはどうなるでしょうか。上流から追加のソフトウェアをインストールしたり、独自のアプリケーションを追加したりすることがあるでしょう。それらには、さらに独自の依存関係がインストールされる可能性もあります。追加したものは自分たちで管理できるため、そこから持ち込んだ脆弱性の修正にも責任を持つ必要があります。

ベースラインを作成する

コンテナイメージをビルドする際は、変更を加える前にベースイメージだけをスキャンすることをおすすめします。これによりコンテナイメージのセキュリティベースラインを確立でき、ベースイメージに含まれていた脆弱性と、その後のレイヤーで追加された脆弱性を簡単に見分けられます。カスタムのミドルウェアレイヤーとアプリケーションなど、複数のレイヤーを追加してイメージをビルドする場合は、それぞれの段階でベースラインを作成し、各イメージを個別に管理するのも有効です。脆弱性の発生元を明確に把握できます。

優先順位を決める

ごくシンプルなアプリケーションを除き、脆弱性がまったくない完全なコンテナイメージのセキュリティを実現するのは、現実的ではないでしょう。修正に使えるリソースには限りがあるため、何を修正し、何を許容するかを判断し、優先順位を付ける必要があります。

しかし、スキャナーが多数の脆弱性を報告するイメージを扱う場合、こうした判断は非常に難しくなります。セキュリティスキャンでは、提示される情報が多すぎて確認する人が圧倒され、結果としてスキャンを無視したり、無効にしたりするおそれがあります。

また、脆弱性のリスクは単純にゼロか百かで判断できるものではありません。特定の脆弱性が問題になるのは、非常に限られた状況や特定のアーキテクチャ、プラットフォームに限られる場合があります。すべての脆弱性の詳細を読まずに、自分たちの環境で問題となるかどうかをどう判断すればよいのでしょうか。

優先順位付けは厳密な科学ではなく、さまざまな要素に基づいて行われます。深刻度だけでは、潜在的な影響以外の情報はあまり得られません。悪用可能性や影響などを考慮するCVSSスコアを見れば、より多くの背景情報が得られます。さらに、公開されているエクスプロイトコードの成熟度や、何より修正プログラムがあるかどうかも参考にできます。深刻度が高く、エクスプロイトと修正プログラムの両方がある脆弱性は、まず修正すべきものと言えるでしょう。Snykの優先順位スコアは、こうした要素をすべて考慮して脆弱性を提示するため、開発者は明確な情報に基づいて判断できます。

コンテナイメージのセキュリティ戦略を決める

セキュリティ対策では、特に労力とリスクの間で、ほぼ常に何らかのトレードオフが発生します。特定の問題を修正するために必要な労力と、自分たちの環境で実際に問題となるリスクを比較する必要があります。セキュリティ脆弱性の修正に優先順位を付ける場合、まず戦略を定めるのが一般的です。たとえば、非常にシンプルな戦略として、次のようなものが考えられます。

• 本番環境に深刻度の高いCVEを残さない

• 成熟したエクスプロイトがある脆弱性を残さない

• パッチがあれば適用する

この方針に従えば、多くの場合、脆弱性の総数を大幅に減らせるでしょう。

リスクの軽減：環境ごとに異なる対策

スコアから深刻度の目安はわかりますが、主観的な判断が必要な要素もあります。たとえば、深刻度の高い脆弱性であっても、悪用にローカルシェルへのアクセスが必要であり、そのアクセスを防ぐほかの制御策がある場合、自分たちの環境ではリスクが低いと判断するかもしれません。シェルを含まないdistrolessコンテナを使用すれば、こうした制御策によってリスクを軽減できます。

セキュリティ境界を理解する

環境によっては、ネットワークを信頼できるものとみなし、そのネットワークに接続する脆弱な要素はそれほど問題ではないと判断するかもしれません。しかし、接続が非常に複雑な現代のコンピューティング環境では、完全にエアギャップ化された環境を除き、境界を明確にするのは難しいため、この考え方には問題があります。クラウド環境では特に問題になります。また、内部の悪意ある攻撃者からも保護できません。これは、特に大規模な組織にとって重大なリスクです。通常は、すべてのネットワークを信頼できないものとして扱うほうが安全です。

ツールを理解する

ここで重要になるのが、こうした問題の検出に使うツールへの理解です。多くのイメージスキャンツールでは、出力をフィルタリングして、特に確認したい情報を設定できます。ソフトウェアのデリバリーパイプラインにセキュリティスキャンを組み込む場合は、特に重要です。関連性のない情報や、ほかの方法でリスクを軽減すると判断した問題を理由に、ビルドやデプロイが繰り返し失敗するのは避けたいものです。Snykでは、CLIスキャンの終了ステータスを制御する--fail-on flagを用意しています。特定の条件を満たす場合にのみ、CLIが失敗を返すように設定できます。たとえば、次のように指定します。

1snyk container test purpledobie/mattj-goof --fail-on upgradable

この設定では、イメージ内にアップグレード可能な脆弱性が1つ以上見つかった場合にのみ失敗として終了します。修正不可能な脆弱性やパッチを適用できる脆弱性が見つかっても、失敗にはなりません。

Snyk CLIでは、後からフィルタリングできるJSON形式での出力も可能です。JSON出力を使えば、jqなどのツールで複雑なフィルターを作成できます。

1snyk container test purpledobie/mattj-goof --json | jq '.vulnerabilities[] | select(.CVSSv3 | test("AV:N"))'

この非常にシンプルな例では、CVSSスコアの攻撃ベクターがNetworkに設定されているかどうかに基づいて脆弱性リストを絞り込み、ネットワーク経由で悪用可能な脆弱性だけを返します。このようなフィルターを作成することで、複雑なポリシーに基づく判断をスキャンに組み込めます。

修正を自動化する

戦略を定めてツールを設定したら、修正を自動化しましょう。開発者が下す判断を減らして認知負荷を軽減し、必要なリソースも削減できます。全体的な戦略に明確に当てはまり、修正プログラムが用意されている問題に対するプルリクエストを自動作成すれば、開発チームは継続的に修正を進めやすくなります。その分、手作業のリソースをより複雑な例外対応に充てられます。

コンテナイメージのセキュリティを詳しく解説

コンテナスキャンでは、ビルド時に追加されたパッケージに含まれないバイナリなどを検出できない場合があります。そのため、コンテナイメージのスキャンだけに頼るべきではありません。コードベースやDockerfileのスキャンも重要です。本番ワークロードでは、多層防御の原則を採用し、実行時の異常検知やエンドポイントスキャンなど、ほかのセキュリティチェックも取り入れるべきです。

コンテナを安全に保つ

コンテナイメージのセキュリティ対策を考える際には、さまざまな検討事項があります。この記事が、取り組みを始めるためのポイントを明確にする一助となれば幸いです。現在のコンテナイメージの安全性を確認するには、Snykの無料アカウントを作成してスキャンを実行してください。