コンテナが攻撃されたらホストも危ないの？――クラウド利用時の「コンテナセキュリティ」の基礎知識：親子の会話から学ぶクラウドセキュリティ（終）

親子の会話で出てくるような素朴な疑問点から、クラウド環境における情報セキュリティの技術を学習する連載。最終回は、クラウドでコンテナを使用する際のセキュリティの基礎知識について解説します。

[青山桃子，株式会社日立ソリューションズ]

　親子の会話で出てくるような素朴な疑問点から、クラウド環境における情報セキュリティの技術を学習する本連載「親子の会話から学ぶクラウドセキュリティ」。

　初回は、クラウドを始める前に覚えておきたいセキュリティの基礎知識、第2回はネットワーク関連セキュリティ、第3回はセキュリティの運用・監視、第4回は管理アクセスに関する内容、第5回は、クラウド環境での脆弱（ぜいじゃく）性検査や攻撃検知などについて解説しました。第5回では、ついに親子のシステムが完成しました。

　最終回は、クラウドでコンテナを使用する際のセキュリティの基礎知識について解説します。

コンテナって何？

コンテナってのが良いよって友達が言ってたんだけど、コンテナって何？

仮想化技術の一つね。仮想マシンのように、アプリケーション用の独立した環境を作るんだけど、リソースを共有することで、より軽量な仕組みになっているのよ。

うーん。具体的には。どういう仕組みなの？

そうね、大まかには、仮想マシンは仮想環境にOS（オペレーティングシステム）が乗っているけど、コンテナは仮想環境にアプリケーションが乗っているとイメージするといいわよ。

　コンテナとは、アプリケーションの開発、実行、提供などをするために標準的に必要なものを1つにまとめたものです。コードそのものはもちろん、アプリケーションに必要なライブラリや設定などの環境がひとまとまりになっており、さまざまな実行基盤の上で同じアプリケーションを容易に展開することができます。

　コンテナは仮想化技術の一つで、仮想マシンとよく比較されます。仮想マシンの主な構造としては、まず物理的なサーバ上にハイパーバイザー（仮想OS）がインストールされます。その上に仮想的なハードウェアが用意され、ゲストOSをインストールした個々の仮想マシンとなります。実行するアプリケーションは、各ゲストOS上に、物理マシン同様にインストールされます。

　コンテナの場合、物理的なサーバ上にホストOSがインストールされ、その上にコンテナを実行するためのプラットフォームを構築します。各コンテナはそのプラットフォーム上で実行され、それらのコンテナ上でアプリケーションが動作します。

　コンテナや仮想マシンはホストOSやハイパーバイザー、他のコンテナや仮想マシンとはそれぞれ独立した環境になっていますが、CPUやメモリなどのリソースは共有され、全体で最適化されるような仕組みになっています。コンテナの場合は、OSレベルで仮想化しているので、カーネルや共通のライブラリなども全体で共有および最適化されることになり、よりリソースを効率良く使えるような仕組みになっています。

　コンテナ用のプラットフォームとしては「Docker」「LXC」などがあります。

コンテナ（Docker）（左）と仮想マシン（右）

※出典：Docker - What is a Container ?

　複数のコンテナを複数のホスト上で動かせるような大規模な構成の場合、オーケストレーションツールを用いることがあります。それにより、複雑なコンテナ構成を統合的に管理することができるようになります。オーケストレーションツールの例としては「Kubernetes」「Docker Swarm」などがあります。

　コンテナは、自分で一から作ることもできますが、配布されている既存のコンテナを利用して自分用のコンテナを作成することもできます。既存のコンテナは「Docker Hub」などのレジストリで配布されているものを利用できます。これらをカスタマイズするだけで簡単にアプリケーションを作ることができるのもコンテナのメリットです。もちろん、既存のアプリケーションをカスタマイズしないのであれば、配布されているコンテナをそのまま利用することもできます。

クラウド環境でコンテナを使うと、どんな構成になるの？

クラウド環境でコンテナを使うと、どんな構成になるの？

普通に使うだけでも十分便利だけど、クラウド環境ならコンテナを利用してサーバレスにすることもできるのよ。

サーバレスって、サーバがなくても動くの？

サーバの部分はクラウド基盤として管理されるのよ。各アプリケーション向けに専用のサーバが用意されるわけではないから、クラウドのユーザー側から見たら、サーバがないように見えるね。

　クラウド環境において、例えば3層構成のWebシステムの場合は、Webサーバやアプリケーションサーバ部分をコンテナに置き換えると、構築やスケーリングのしやすさといった面でメリットを生かしやすくなります。

　また、クラウド基盤側がコンテナ実行用のプラットフォームを提供している場合、サーバレスの環境でコンテナを実行することもできます。この場合、プラットフォーム側の管理は通常、クラウドベンダーの責任範囲になるので、ユーザーはセキュリティ対策などの管理の手間を軽減できます。Amazon Web Services（AWS）の場合、「AWS Fargate」を用いることで、コンテナをサーバレスで実行できます。また、オーケストレーションサービスとしては「Amazon Elastic Container Service（ECS）」「Amazon Elastic Kubernetes Service（EKS）」を利用することが可能です。

Amazon ECSを用いてコンテナを起動した例

コンテナのセキュリティはどうすればいいの？

コンテナのセキュリティはどうすればいいの？

普通のサーバと同じような、一般的なセキュリティ対策をすることはもちろんだけど、コンテナ特有の注意点もあるわ。

　コンテナのセキュリティ対策として注意すべき例としては下記のようなことが挙げられます。

• コンテナが脆弱である場合
• コンテナに悪意あるコンテンツが含まれている場合
• コンテナ実行環境が脆弱である場合
• コンテナ実行に関する設定に不備がある場合

　まずは、コンテナが脆弱である場合です。コンテナ上で実行されるアプリケーションそのものに脆弱性があったり、コンテナ内で使用されているオープンソースソフトウェア（OSS）に脆弱性が発見されたりする場合があります。このことはコンテナに限らず、一般的にOSSを利用する際などにも当てはまりますが、同様に注意が必要です。特に長い期間メンテナンスされていないような、古いコンテナを実行するような場合は、脆弱なバージョンのOSSが使用されていないかどうかなど、確認するようにしましょう。

　また、インターネットで公開されているような、既存のコンテナを流用する場合、コンテナにマルウェアなどの悪意のあるコンテンツが含まれている場合もあります。既存のコンテナをダウンロードして使用する場合は、作成元や配布元をきちんと確認するようにしましょう。

　このようなコンテナ自体の脆弱性については、コンテナ用の脆弱性スキャナーを用いてチェックすることも可能です。コンテナ用の脆弱性スキャナーの例としては、「Anchore」「Trivy」などがあります。

　他にも、コンテナ実行環境が脆弱である場合や、コンテナ実行に関する設定に不備がある場合など、プラットフォーム側の問題にも注意が必要です。プラットフォームを最新のものにアップデートすることや、適切な管理者権限やアクセス制御を設定することなどに気を付けましょう。

コンテナが攻撃されたらホストも危ないの？

コンテナを実行するホスト側のセキュリティ対策もしっかりね。

コンテナはホストと分離されているって言ってたけど、コンテナが攻撃されたらホストも危ないの？

そうよ。コンテナ側からホストに侵入したり、コンテナ基盤の脆弱性を突いた攻撃を受けたりする可能性もあるから、注意が必要よ。

　コンテナに脆弱性がある場合、ホスト側にサイバー攻撃の影響が及ぶ可能性があります。同じプラットフォーム上の個々のコンテナ同士や、コンテナとホストとは、独立した関係にありますが、完全に分離されているわけではありません。コンテナの独立性は、仮想マシンと比較すると低いともいわれています。コンテナ自体の脆弱性対策や、プラットフォームのセキュリティ対策はもちろんですが、万が一ホストに侵入された場合に備えて、ホストOSやホスト上のソフトウェアなども、最新の状態にアップデートするなど基本的なセキュリティ対策をしておくようにしましょう。

　コンテナ用のプラットフォームがクラウドベンダーの管理になっている場合、ホストのセキュリティ対策はユーザー側ではできませんが、そうではない場合は、ユーザー側での配慮が必要になるので注意が必要です。

便利な機能はどんどん使いたいけど、セキュリティもきちんとしなきゃダメってことが分かったよ。

そうね。最新版へのアップデート、設定不備をなくす、というような基本的なセキュリティ対策は、あらゆるところで気を付けるようにしましょうね。