コンテナセキュリティの基礎知識【後編】

「コンテナ」「オーケストレーター」のセキュリティを脅かす4大脆弱性

コンテナとオーケストレーターを安全に運用する上で、対処すべき代表的な4種類の脆弱性がある。それらの概要と、脅威を軽減する手段を紹介する。

公開 2019年06月28日 05時03分

更新 2019年07月06日 18時35分

著者

Johna Till Johnson

[TechTarget]

印刷する連載新着通知を受け取る

　前編「いまさら聞けない『コンテナ』『オーケストレーター』の仕組みと役割」では、アプリケーションの稼働環境を仮想化する「コンテナ」と、その管理やデプロイ（配備）を効率化する「コンテナオーケストレーター」（「コンテナオーケストレーションツール」とも。以下、オーケストレーター）の基礎知識を紹介した。後編では、コンテナやオーケストレーターに関わるセキュリティリスクと、その対策について説明する。

併せて読みたいお薦め記事

コンテナ導入前の基礎知識

Kubernetes活用のヒント

コンテナやオーケストレーターの代表的な脆弱性

　コンテナとオーケストレーターの脆弱（ぜいじゃく）性の大半は、サイバーセキュリティ専門家にとってなじみがあるだろう。というのも、これらの脆弱性はOSとアプリケーションが持つ典型的な脆弱性だからだ。具体的には、次の4種類がある。

アクセスと承認の脆弱性
APIサーバへのアクセスの脆弱性
コンテナイメージの脆弱性
コンテナ間のトラフィックの脆弱性

　これら4つの脆弱性について紹介しよう。

脆弱性1．アクセスと承認の脆弱性

　前編で紹介したTesla Motorsと電子商取引構築サービスを手掛けるShopifyの事例では、どちらもアクセスと承認に原因があることは注目に値する。Teslaのケースでは、システム構成に不備があり、オーケストレーター「Kubernetes」のセキュリティを確保できていなかった。その結果、Kubernetesを経由してシステムが侵害を受けた。Shopifyのケースでは、攻撃者はAPI（アプリケーションプログラミングインタフェース）サーバに不正アクセスし、コンテナクラスタを操作できる脆弱性が見つかった。

　どのアプリケーションとOSについてもいえることだが、開発者は全てのアクセス・承認の構成とセキュリティ確保に細心の注意を払わなければならない。そのためには、アクセスをロックダウン（制限）し、修正プログラムを適用してシステムを最新状態に保つ必要がある。

脆弱性2．APIサーバへのアクセスの脆弱性

　APIサーバはオーケストレーターを操作するためのフロントエンドだ。APIサーバを「正しい資格情報を持つアプリケーションのみに通行を許可した正面玄関」だと考えてみてほしい。偽の資格情報やなりすましによって攻撃者がこの正面玄関を突破すると、コンテナが不正アクセスにさらされることになる。APIサーバを保護するためには、全てのアクセスと承認を扱う領域を用意することが不可欠だ。

脆弱性3．コンテナイメージの脆弱性

　コンテナイメージはオーケストレーターの“DNA”、コンテナを作成するための処方箋のようなものだ。巧妙なハッカーは、コンテナイメージにマルウェアを仕込んで、危害を及ぼし得る“毒入りコンテナ”を生成する。さらに巧妙なハッカーであれば、オーケストレーターの状態監視コンポーネントを制御し、毒入りコンテナが検出されないようにすることも可能だろう。保有する全コンテナイメージを蓄積した「イメージレジストリ」も侵害の対象になり得る。その目的は、マルウェアを仕込んだコンテナイメージの存在を隠すことだ。従ってコンテナイメージの変更を検出できることや、変更あるいはコンテナ自体を管理できることも同様に重要になる。

脆弱性4．コンテナ間のトラフィックの脆弱性

　コンテナは基本的に自己完結型である一方、コンテナ同士は相互に通信する。通信には暗号化した経路を使用する。ただし暗号化は、もろ刃の剣になり得る。暗号化によって、正当なデータフローだけでなく、マルウェアの転送も隠れてしまうためだ。あるコンテナが侵害されると、他のコンテナがマルウェアに感染する恐れがある。

　コンテナにまつわるその他の脆弱性を理解する資料としては、米国立標準技術研究所（NIST）のガイドライン「NIST Special Publication 800-190」（SP 800-190）がお薦めだ。ただし前述の通り、ここで挙げた脆弱性は、多くの専門家が学んだ標準的な脆弱性のバリエーションにすぎない。目新しいのは「コンテナとオーケストレーターという新しい概念に関係している」点だけだ。