Docker Hubのコンテナイメージ、51％以上に脆弱性が混入
よりスケーラブルで柔軟性の高いアプリケーションを構築、提供する手段として注目されるクラウドネイティブ技術。中でもコンテナの活用はここ数年で急激に広がっており、調査会社IDC Japanが発行する調査報告書「2021年 国内クラウドネイティブ技術ユーザー動向調査」では、コンテナを導入検討中や検証中、すでに導入済みと回答した組織が2016年には25％だったのが、2021年には56.6％に上昇したとしている。
コンテナ活用が広がる背景には、モノリシックなアプリケーション開発からマイクロサービスの開発へとシフトが進んでいるからだと、日本シノプシス、ソフトウェア インテグリティ グループ、シニア・プロダクトマーケティング・マネージャの松岡正人氏は指摘する。「コンテナはホストに依存せず、機能の追加や改善も速やかに実施でき、バージョン管理や追跡もしやすく、何よりDevOps環境との親和性が高い」（松岡氏）
その一方で、コンテナには固有のセキュリティリスクが存在する。一例として、コンテナイメージの取り扱いが挙げられる。より効率的にサービスを開発する目的で、Docker Hubにアップロードされているコンテナイメージを活用することは一般的だが、このコンテナイメージに不正なアプリケーションやライブラリなどが埋め込まれていることに気付かず、自社環境へデプロイしてしまった場合、システム侵害や悪用を許してしまう可能性がある。
2020年12月にサイバーセキュリティ企業Prevasioが報告したところによると、Docker Hubにアップロードされた約400万のコンテナイメージを調査した結果、51％以上に悪用可能な脆弱性が発見され、6400以上のコンテナイメージからマルウェアが検出されたという。
コンテナイメージ悪用の可能性については、多くの研究者がすでに指摘している。ある論文では、既知の脆弱性を仕込んだイメージをDocker Hubにアップロードし、ユーザーがそのイメージを自社環境などで起動すると、privilegedオプションでホストへのアクセスを許可する攻撃手法について言及されている。
もちろん、Docker Hubでもこうしたリスクを重視し、脆弱性スキャンオプションを追加。サードパーティのスキャンツールも登場している。「コンテナのセキュリティリスクは、ほかにも色々ある。コンテナの構造や流通の仕組み、運用上の取り扱い方法をきちんと把握し、適切なセキュリティ対策を講じることは重要だ」（松岡氏）
対策のひとつに挙げられるのは、ソフトウェア開発ライフサイクルの各ステップにセキュリティテストを組み込む方法だ。たとえば、コンテナの設計・計画段階ではどのような脅威が存在するのか整理し、リスクを分析。コード開発段階ではコードの静的解析やソフトウェアコンポジション解析で脆弱性を網羅的に洗い出し、イメージをビルドしたあとは脆弱性スキャンやファジング、IAST（インタラクティブアプリケーションセキュリティテスト）やDAST（動的アプリケーションセキュリティテスト）などを実行。コンテナをプッシュしたあとの運用段階でもコンテナの随時スキャンを実施するほか、IAST/DAST、ペネトレーションテスト、ファジングを定期的に実施。不正な変更が行われていないかを確認する。
コンテナ環境をセキュアに運用するためのガイドラインは、米国のNISTが公開している「SP800-190 Application Container Security Guide」を参考にするとよいと松岡氏は言う。
たとえば、同ガイドラインにはセキュアなコンテナ環境を構築、運用するためのポイントを6つ紹介している。
- コンテナの開発、実行、サポートなど運用および技術的プロセスは従来のモノリシックなアプリケーションのそれと異なることを理解した上で、新しい手段を後押しするために調整する
- アタックサーフェスを減らすために、汎用ホストではなくてコンテナ専用ホストを使う
- 単一のホストカーネル上で、同じ目的、機微性、および脅威に対する耐性を持つグループコンテナのみを使用し、さらなる多層防御を可能にする
- コンテナ専用の脆弱性管理ツールとイメージのプロセスを採用し、侵害を防ぐ
- トラステッド・コンピューティングの基板を提供するために、ハードウェアによる対策を検討する
- コンテナに対応したランタイム防御ツールを使用する
詳細は、IPA（情報処理推進機構）の翻訳版で確認できる。
