NISTがアプリケーションコンテナのセキュリティに関するガイドラインを公開

National Institute of Standards and Technology(NIST)は先頃、アプリケーションコンテナテクノロジと、その最も重要なセキュリティ上の問題に関する報告書を公開した。イメージやレジストリ、オーケストレータ、ホストOS、ハードウェアなどの脆弱性領域とその対策を概説した、公開済の２つの報告書を要約したものだ。

NISTのComputer Security Research Center(CSRC)は、サイバーセキュリティおよび情報セキュリティに関するプロジェクトと公開資料を監督する。今回公開された報告書は、アプリケーションコンテナのセキュリティに関する２つの公開済資料を要約したものだ。アプリケーションコンテナの概要から始まり、セキュリティに影響する要因が続き、最後はアプリケーションコンテナのセキュリティ改善に有効な対策が紹介されている。

コンテナの移植性とその不変性は、セキュリティ上の問題が紛れ込む可能性のある２つの領域に結び付いている。アプリケーションの配布および配置の手段としてのコンテナは、アプリケーションアーカイブよりも高いレベルの抽象性を提供している。同じコンテナイメージを多様な開発、テスト、運用環境で使用可能とするため、コンテナは一般的に、さまざまな環境やマシンアーキテクチャで使用可能なように設計されている。アプリケーションの可搬性と継続的デリバリ環境に寄与するこれらの手法が同時に、セキュリティ上の問題を引き起こす可能性を含んでいる。すなわち、セキュリティツールやプロセスは、コンテナが実行される特定の環境を前提にできないため、環境に固有な数多くのセキュリティ脆弱性を扱う上で、これが抜け穴となる可能性があるのだ。

コンテナは不変(immutable)モデルで動作する – 新たなコンテナのバージョンがイメージとして公開されると、古いコンテナは破棄され、新しく生成されたコンテナが取って代わる。オペレーティングシステムのアップデートなどによってイメージが更新されると、アプリケーション開発者は、アプリケーションをそれに組み込んで、新たなイメージを作成しなければならない。このため、セキュリティ上の脆弱性への対応パッチや公開済みのバグ修正の運用システムへの適用は、運用チームではなく、開発者がその責任を負うことになる。一般的にこのような作業には運用チームに一日の長があるため、これもまた潜在的なセキュリティホールとなる。

NISTガイドラインでは、抜け穴を回避するためにセキュリティ対策を実施すべき領域として、6つの分野が指摘されている。イメージやレジストリ、オーケストレータ、コンテナ、ホストOS、ハードウェアなどがこれに含まれる。イメージの脆弱性としては、未発見のものを含むOSの脆弱性、構成の問題、信頼性の低いイメージ、秘密文書をクリアテキストに保存するようんば悪習慣などが含まれる。イメージはベースイメージ上に構築されるため、基盤となったイメージの問題については意識していないか、あるいは責任を負わないケースが一般的である。レジストリに関連するリスクは安全でない接続や古いイメージ、認証/承認制限が不十分などの場合に発生する可能性がある。実行時にコンテナのライフサイクルを管理するオーケストレータには、ネットワークトラフィックの分離が不十分であったり、無制限な管理アクセスが許可されている場合にバグを持っている可能性がある。後者のポイントとしては、ほとんどのオーケストレータがマルチユーザのシナリオを考慮せずに設計されている点や、デフォルト設定がセキュリティの観点からは最適でないことの多い点などがあげられる。

コンテナには、コンテナを“飛び出して”、同じホスト上の他のコンテナやホスト自体にダメージを与えるような悪意のあるコードが含まれているかも知れない。また、コンテナ内部からの無制限なネットワークアクセスや、特権モードで動作するようなセキュアでないコンテナ実行の設定は、コンテナが他の手段、例えばアプリケーションレベルの脆弱性を通じて棄損された場合に被害を及ぼす可能性がある。ホストOSにはすべて、攻撃者がOSに侵入可能な方法を定義した“アタックサーフェス”がある。ひとつのホストに侵入されれば、実行中のすべてのコンテナが侵入されることになるのだ。コンテナ間でカーネルを共有すれば、アタックサーフェースはさらに拡大することになる。

対抗策はスタックの最下部 – ハードウェアから開始して、コンテナのランタイムまで上昇した後、イメージやレジストリの整合性やオーケストレータ自体に達する。コンテナのセキュリティに関する過去の研究や活動でも、同じようなポイントに触れている。