コンテナの静的・動的スキャン

コンテナの静的・動的スキャン

前回は、コンテナおよびKubernetesの作成／運用におけるセキュリティ上の課題について説明しました。今回はコンテナセキュリティにおける基本である、コンテナスキャンについて説明します。

コンテナスキャンには、コンテナイメージをスキャンする静的スキャンと、動作中のコンテナへの攻撃を検知する動的スキャンがあります。

コンテナの静的スキャン

コンテナの静的スキャンには以下のものがあります。

• セキュリティ基準に則っているか
• コンテナホストに対する脆弱性スキャン
  • コンテナホストで実行されるカーネル／コンテナを実行するデーモンにバグがあると、いくらコンテナがセキュアでも外部から攻撃を受ける場合がある
• コンテナイメージに対する脆弱性スキャン
  • コンテナに含まれるアプリケーション／ライブラリなどの脆弱性を検知

-

コンテナホスト／コンテナの脆弱性スキャンでは、マシン内で使用しているアプリケーション／ライブラリを始めとした実行形式に脆弱性がないかを確かめます。

これらのスキャンは、今までベアメタル／仮想マシンで行っていたのと同様に行う必要があります。

セキュリティ基準

コンテナの使用には、以下のようなセキュリティ基準があります。

• CISベンチマーク
  • CIS（Center for Internet Security）は、セキュリティに関する基準を容易に実行可能なベンチマークとして提供している。その中には、DockerやKubernetesに関するベンチマークも含まれる
  • CIS docker benchmark
  • CIS kubernetes benchmark
• NIST（National Institute of Standards and Technology）
  • NIST（米国標準技術研究所）は、コンテナセキュリティに関する基準も出している
  • NIST Application Container Security Guide
• PCI DSS（Payment Card Industry Data Security Standard）
  • PCI DSSは、クレジットカード情報の取引情報を保護するために制定された、クレジットカードセキュリティの業界標準。SSC（Security Standard Council）によって制定された。以下のガイドも参考に
  • PCI SSC Cloud Computing Guidelines（PDF）

CISベンチマークは比較的容易なコマンドの実行で監査可能です。一方NISTとPCI DSSはガイドラインのみ提供されており、それを守るには専用ツールや、システム自体の精査が必要になります。

コンテナ脆弱性スキャンの仕組み

コンテナの脆弱性スキャンでは、CVE/JVN^※情報をもとにOSのパッケージ単位で行うことが多いです。これはアプリケーション／ライブラリ／実行形式などにバグや脆弱性が発見されても、OSベンダーが独自にパッチを当てたパッケージを作成し、対処している場合もあるためです。

CVE: Common Vulnerabilities and Exposures
JVN: Japan Vulnerability Notes

ライブラリの脆弱性や静的リンクでライブラリを使用している場合、ファイルレベルでライブラリのバージョン情報を検知することはほぼできません。ファイル内に関数シンボルやバージョン名が入っている場合は別ですが、多くの場合Shared Objectファイルからはそのような情報が削除されているためです。またユーザが独自に作成した実行形式を使用する／静的リンクを使用する場合は、使用しているライブラリに脆弱性のないことを、自分自身で確認する必要があります。

連載の第1回で、「コンテナのイメージはレイヤ状になっていること」「レイヤがsha256 checksumで確認できること」を説明しました。コンテナの静的スキャンの特徴として、レイヤごとに脆弱性スキャンを行うことが挙げられます。同じタイミングで複数コンテナをスキャンした場合、sha256sumで同じと見なされたレイヤのスキャンを省くことが可能です。

レイヤ状になっているDockerコンテナイメージ

このことから、使用する複数コンテナイメージのベースは、できるだけ合わせておくことの優位性がわかります。

コンテナ静的スキャンを継続して続ける意味

コンテナの静的スキャンは、コンテナ作成時のみでなく、コンテナサービスを継続している期間中も実施する必要があります。なぜなら使用しているアプリケーションやライブラリの脆弱性が新たに発見される可能性があるからです。昨日は脆弱性が見つからなくても、今日になったら脆弱性が見つかる可能性もあります。

これに対応するためには、脆弱性情報を日々更新し、サービス中のコンテナイメージの脆弱性スキャンを実施するしかありません。

コンテナ静的スキャンツール

コンテナ静的スキャンを行うツールは、オープンソース／商用を含め複数存在します。以下に、いくつかの静的スキャンツールを挙げていきます。

スキャンツール概要：

スキャンツールのディストリビューション対応：

Anchore Engine

• Anchore社が提供する、オープンソースの静的コンテナスキャンツール
• 指定OSのパッケージチェックに対応
• NVD v2／GitHubアドバイザリから脆弱性情報を取得
• GEM／JAR／NPMなどの言語パッケージの脆弱性チェック可能
• 脆弱性を含んだコンテナ作成や、コンテナデプロイをポリシーで制御
• JenkinsなどCI/CDツールとの連携可能
• Kubernetesへの対応

Aqua MicroScanner

• Aqua社が提供する、無償で使用可能なオンプレミスのコンテナ静的スキャンツール
• Dockerfileへ組み込むことで、コンテナ作成時に脆弱性をスキャン可能
• CVE／NVD／Heartbleedから取得した脆弱性データを取得して生成した、Aqua社の脆弱性データベースを使用
• 使用するにあたり、Aqua社へのアカウント登録が必要
• Trivy（下記参照）の買収により、Trivyに統合される予定

Clair

• CoreOS社（現在はRed Hat社により買収）が開発した、オープンソースの静的コンテナスキャンツール
• NVDから脆弱性情報を取得
• APIでスキャン可能で、CI/CDツールとの連携が可能

Trivy

• Teppei Fukuda氏により、オープンソースで開発された静的コンテナスキャンツール
• 現在Aqua社により買収され、オープンソースのまま開発継続中。開発者のFukuda氏もAqua社に雇用された
• スタンドアローンもしくはクライアント／サーバー方式で、指定コンテナの脆弱性をスキャン可能
• NVEやOSのパッケージ情報、Ruby（Gem）／Python（pip／Poetry）／PHP（Composer）／Node.js（npm／yarn）／Rust（Cargo）の言語パッケージから、依存関係をたどった脆弱性を検知
• Travis CI/CircleCI/GitLabなどのCI/CDツールとの連携可能
• Docker Hub／Amazon ECR（Elastic Container Registry）／GCR（Google Container Registry）のDockerイメージをスキャン可能

Vuls

• オープンソースで開発された脆弱性スキャンツール
• NVD/JVN/JPCERT/US-CERTなどから脆弱性情報を取得
• コンテナに限らず、ベアメタルやIaaS環境でも動作し、コンテナホストに対する脆弱性スキャンに使用可能
• 指定OSのパッケージチェックに対応
• コンテナのスキャンには、Aqua社のfanal/Trivyを使用する^※
• Docker Hub／プライベートDocker Hub／Amazon ECR／GCR上のDockerイメージをスキャン可能

※ 2020/5/8より、Trivyによるイメージの静的スキャンはサポート対象外となり、言語ライブラリのスキャンのみに使用

Dockle

Dockleは、CIS（Center for Internet Security）が提供しているセキュリティ基準CIS Docker benchmarkに基づき、コンテナイメージのセキュリティを確認します。

• Tomoya Amachi氏により、オープンソースとして開発された静的コンテナスキャンツール
• DockerfileのベストプラクティスをもとにDockerイメージをスキャン
• CIS Docker benchmarkをもとにDockerイメージ内のDockerfileをスキャン
• Travis CI/CircleCI/GitLabなどのCI/CDツールとの連携可能
• Docker Hub／Amazon ECR（Elastic Container Registry）／GCR（Google Container Registry）上のDockerイメージをスキャン可能

Dockleはイメージベースの脆弱性スキャンツールではありません。イメージベースの脆弱性スキャンと組み合わせて使用することで、コンテナセキュリティを高めることができます。