セキュリティの専門家にとって、Dockerはあまりなじみがないものかもしれない。多くのセキュリティの専門家はDockerについて認識していない可能性が高いのではないだろうか。知っていたとしても、Dockerのセキュリティについて手はずを整えるのに苦戦しているかもしれない。そして次のように自問自答しているのではないだろうか。「Dockerはセキュリティのプロファイルにどのような変化をもたらすのだろうか」「Dockerが広く普及したときには何を検討したらよいのだろうか」「既存のセキュリティメカニズムはDockerに対応した環境にどう適合するのだろうか」

　本稿では、Dockerについて詳しく解説する。Dockerの概要、Dockerがこれほどまでに普及している理由、セキュリティに関する派生的な問題について取り上げたい。

　セキュリティの専門家にとって、Dockerは認識しておくべきツールである。その最大の理由は、Dockerの人気から、近いうちにDockerを保護する方法について考える必要が生じることだ。また、Dockerへのアプローチ方法にもよるが、Dockerを使用することで、最終的にセキュリティ面でメリットを得られる可能性もある。本稿では、Dockerの概要とエンタープライズセキュリティへの影響を解説する。

Dockerとは

　端的にいうと、Dockerは、Linuxをベースとしたオープンソースのアプリケーションコンテナを抽象化／仮想化するメカニズムだ。「Linuxベースのオープンソース」について説明する必要はないだろう。だが「アプリケーションコンテナの抽象化」については解説が必要かもしれない。最初は複雑に見えるかもしれないが、この概念自体はかなりシンプルなものである。基本的にDockerは自己完結型の仮想環境（コンテナ）を作成する方法だ。この環境では、アプリケーションに完全な自由が与えられる。この仮想コンテナは、基盤となるOSの分離された半プライベートなビューをアプリケーションに提供する。これには、ストレージ、ネットワーク、プロセスなどのリソースも含まれる。

　多くの点において、コンテナはOSの仮想化の概念と似ている。だが、アプリケーションが気に掛けることはなく、厳密には使わない仮想OSイメージのオーバーヘッドについて考えてみてほしい。例えば、LAMPスタックを実行するWebアプリケーションが2つあるとしよう。この2つのアプリケーションの基盤となるスタックは、どの程度異なるのだろうか。OSインストール全体に対する割合で見ると大した違いはない。アプリケーションのみを仮想化することで、1つの仮想／物理OSのインスタンスでアプリケーションを相互に分離することが可能になる。例えば、このタスクには「Docker Engine」を使用することができる。その結果、アプリケーションのパッケージを作成できるようになる。このパッケージは非常に小さく軽量で、アプリケーションの実行に必要なもののみが含まれる。

　この概念により、持ち運びやすくて簡単にカスタマイズできるアプリケーション用のコンテナを作成することが可能になる。OS環境のカスタマイズにかける時間が短くなり、アプリの機能を開発するために時間を使うことができる。そのため、開発者は、この概念を非常に強力だと感じている。データセンターのチームも、この概念を非常に強力だと考えている。その理由は、リソースをより効率的に使用できるからだ。データセンターでは高い割り当て密度を実現できる。例えば、少ないリソースでアプリをサポートできるため、さらに多くのアプリをサポートすることが可能になる。

Dockerのセキュリティについて

　セキュリティの観点では、アプリケーションの仮想化は魅力的な選択肢として映るかもしれない。突き詰めると、「chroot」コマンドを使用してファイルシステムをサンドボックス化するアイデアの発展形と見なすセキュリティの専門家もいるだろう。また、「FreeBSD」の“jail”と類似する機能と見なす専門家もいるだろう（どちらも個々のアプリケーションによる侵害から基盤となるシステムを隔離するための方法だ）。この考え方にいくらかのメリットはあるが、把握しておくべき幾つかの違いがある。また、セキュリティの専門家がDockerのセキュリティを評価して制御を構築する上で把握しておくべき事項もある。

　まず、Dockerの公式イメージの完全性を自動的に検証する方法が誕生したのは、ごく最近であることだ。公式イメージには、アプリケーションの実行に必要と思われる主要なユーティリティとソフトウェアが含まれている。これは、Linuxベースの公式なイメージ、ミドルウェアコンポーネント（米Oracleの「MySQL」や「postgreSQL」など）、フロントエンドコンポーネント（「Apache」や「WordPress」など）の場合もあるだろう。

　2014年に10月にリリースされたバージョン1.3では、デジタル署名の検証が自動化できるようになった。この変更により、公式イメージをダウンロードする前に、イメージが改ざんされていないことをユーザーはある程度保証できる。長期的には公式イメージの改ざんに対する懸念は少なくなるだろう。だが、バージョン1.3以前のバージョンが運用されている可能性はある。そのため、短期的にはバージョン1.3以前の環境に関しては、インストールするイメージに対して追加の精査プロセスを実施する必要がある。

　バージョン1.3以前のDockerに注意するのは言うまでもない。ソフトウェア全般についていえることだが、Dockerエンジン自体にも脆弱性が存在する可能性はある。例えば、最近行われたアップデート1.3.2では、コンテナ間のセグメンテーションの弱体化を招いていた幾つかの重大なセキュリティの問題が修正された。ある脆弱性によって特定のイメージのセキュリティ制限が緩和され、もう1つの脆弱性によって任意のファイルシステムの書き込み（コードの実行）が可能になっていた。これらの問題は、セキュリティウイルス対策を把握すべき理由を示す好例となるだろう。また、ソフトウェアに最新のパッチを適用して最新の状態に保つことが絶対条件であることを示す例にもなるだろう。

　2つ目の考慮すべき事項は、アプリケーションコンテナが、必ずしもハイパーバイザーがスライス間で提供する分離と同じレベルの分離を提供するわけではないことだ。コンテナは、アプリケーションを確実に分離するために少なからぬ処理を行っているが、次のようなアドバイスをしている。「従来の仮想化の技法では、追加のレベルで分離が行われているため、コンテナよりも安全だと見なされている。例えば、Xen、米VMware、KVMなどが実装しているものだ。コンテナはホストのカーネルに対してシステムコールを発行できるが、完全なVMがホストのハイパーバイザーに対して発行できるのはハイパーコールのみだ。後者の場合、攻撃対象の範囲が大幅に狭まる」

　このアドバイスは、あなたの組織の取り組みに影響を与えるものである。短期的には、分離メカニズムを信頼する度合いについて警戒すればよい。例えば、マルチテナントの状況を評価しているとしよう。マルチテナントの状況では、アプリと同時に実行されるものに対する制御が限られる（例えば、パブリッククラウドなどが、これに該当する）。このような環境に配置するアプリケーションは慎重に選ぶのがよいだろう。機密度の低いアプリに適しているが、人事関連のシステムや総勘定元帳システムを移行するのは控えるのが賢明だ。

セキュリティ上のメリットは

　現実主義を掲げるセキュリティの専門家に伝えたいことがある。それは、アプリケーションコンテナは賢く使えばセキュリティ上のメリットを享受できることだ。まず、管理上のメリットは、複雑さの緩和に役立つことだ。複雑さが緩和されるだけで、堅牢なセキュリティウイルス対策の一歩前進につながる。例えば、セキュリティメカニズム、システムアップデート、硬化技術を適用することについて考えてみてほしい。これらを多数の個別の仮想OSインスタンスに適用する作業と比較すると、アプリケーションコンテナを使用する単一のプラットフォームに適用するのは、ずっと簡単な作業になるだろう。

　また、現時点では、アプリケーションコンテナはハイパーバイザーと同じレベルの分離機能を提供していない可能性がある。だが、埋め込みのWebサーバに対する保護を比べてみてほしい。Webサーバでは、1つのアプリケーションが危険にさらされるとほぼ間違いなくシステム全体が危険にさらされる。

　重要なのはメリットもあるということだ。使い方次第で、Dockerはセキュリティツールキットの便利なツールの仲間入りを果たすだろう。今後注目すべきツールであることは間違いない。