コンテナ化を進める企業が理解しなければならないのは、コンテナ化によって影響を受けること、コンテナ化がビジネスの運営方法にマイナスの影響を及ぼす恐れがあることだ。だが正しく準備すればこうした摩擦の多くは回避できる。

　セキュリティ企業Aqua Security Softwareがコンテナ展開時の企業の主な懸念について調査した。その調査によると、最も多かった懸念はセキュリティだったという。つまり大半の企業が、直面する問題を完全に認識している。

　マッケイ氏によると、直面する問題には以下のような対策がある。

• アプリケーションをコンテナ化する場合、パッチ管理、アプリケーションのスケーラビリティ、災害復旧計画を確認する
• コンテナの展開によって生じるデータアクセスとログの変化を理解する
• コンテナには必要なバイナリのみを含めるようにする
• コンテナレプリカの存続期間とリソース割り当てを必要な分だけに制限する
• あらゆる形式の対話型ログインをブロックし、権限を昇格させずにコンテナが運用されるようにする

パッチの一括適用

　コンテナのセキュリティにとって特に重要なのはパッチ管理だ。マッケイ氏は次のように話す。「運用環境で実行中のコンテナにログインすると、存在する必要のない攻撃ベクトルが生まれる。コンテナイメージにパッチ管理ソフトウェアをインストールすると攻撃対象領域が増え、アプリケーション管理が複雑になる。実行中のコンテナにパッチを動的に適用すると、パッチ管理システムがオーケストレーションシステムと不和を起こす」

　これらを念頭に置いて、セキュリティ管理者はプロセスを正しい順序で実行して効果を高める必要がある。「正しい解決策は、コンテナイメージにパッチを適用してから、オーケストレーションシステムに既存のレプリカを破棄させ、パッチを適用したバージョンでレプリカを作成することだ」とマッケイ氏は語る。

　だが、コンテナ化に際して認識すべき問題は不適切なパッチ管理だけではない。サイバーリスク対策企業Tenableでインテリジェンス部門のバイスプレジデントを務めるギャビン・ミラード氏によると、コンテナセキュリティの最大の脅威はコンテナ化するアプリケーションに安全性の低いライブラリをバンドルすることだという。

　「コンテナ化したアプリケーションは数百のオープンソースライブラリを含む可能性がある。そうしたライブラリのいずれもが攻撃ベクトル、潜在的なセキュリティの脆弱（ぜいじゃく）性を表す」（ミラード氏）

　同氏によると、DevOpsチームの作業慣行が原因で、こうした脆弱性がさらに有害になる恐れもあるという。「残念なことに、お気に入りのコンテナは何度も使われる可能性がある。その結果、その脆弱性が非常に高い頻度で持ち込まれて展開されることになる」

　「脆弱なライブラリの展開を減らすには、コンテナを常に最新状態に保つことが不可欠だ。そのためには継続的に検証して、古い問題がビルドプロセスを擦り抜けることがないように、そして新たな欠陥が特定・修復されるようにしなければならない」

　多数の企業が直面する大きな変化の一つは言うまでもなく、ワークロード管理の手段としてクラウドが広く採用されるようになったことだ。こうした進化は多くのメリットをもたらす。だがコンテナ化に関しては、クラウドへの移行によってさらなるリスクが生まれる。クラウドを利用すること自体が問題になるのではない。とはいえ正確な監視と厳格なガバナンスが必要になるだろう。

　ミラード氏は次のように指摘する。「クラウド環境におけるコンテナ化はさまざまなサイバーリスクにつながる。そのためクラウドプロバイダーによるID管理ポリシーの実装が不可欠になる。理想的には、コンテナ化したアプリケーションとセキュリティ対策（コンテナイメージのスキャンやソフトウェアコンポジション分析など）をビルドシステムに組み込む必要がある」

　マッケイ氏もこの見解に同意する。「安全性の低いシステムを運用環境に展開する恐れを完全に否定することはできない。単純化したりデフォルト設定を利用したりした結果として、そうしたシステムが生まれることが多い。使用可能なセキュリティ対策を徹底的に確認することが重要なのはそのためだ」

　「『SELinux』か『AppArmor』が有効になっているかどうか。ネットワークファブリックはトラフィックをどのようにホワイトリストにしているかといった問い掛けが構成を確認することになり、その答えによって展開の安全性が分かる」（マッケイ氏）

　だが、最終責任はクラウドサービスを使うユーザーにあるとして、マッケイ氏は次のように強調する。「ユーザーは自身のアプリケーションのセキュリティに常に責任を持つ。つまりコンテナとその中身の攻撃対象領域全体、アプリケーションのデフォルト構成、攻撃対象領域に関連する脅威モデル、コンテナイメージへのパッチ適用作業に責任を持つことになる」

　「クラウドプロバイダーはオーケストレーションシステムを管理し、通常は一連の厳しいセキュリティポリシーを課すことになるだろう。少なくとも最小限のセキュリティポリシーを利用可能にするのはクラウドプロバイダーになる。コンテナシステム運用のリスクをクラウドプロバイダーに委ねれば、ユーザーはアプリケーションのセキュリティに専念できる」

別の可能性

　ここまで取り上げた環境は、コンテナがサーバベースで、ホストコンピュータから配布されることを前提にしてきた。だが、これとは異なるもう一つの可能性がある。

　Droplet Computingは、ホストコンピュータが侵害されるリスクを軽減するためにエンドユーザー環境内でコンテナを使用することの先駆けとなった企業だ。同社のCEOピーター・ボン・オーベン氏は次のように語る。「当社の事業は『Docker』や『Kubernetes』とは大きく異なる。当社が重点を置くのはデスクトップだ。そのためDropletコンテナは必要に応じてオフラインで実行できる」

　例えば、プラットフォームが異なっても人気アプリケーションの正規のオンライン版を呼び出すことができる。「つまりAppleユーザーは、幾つか機能は制限されるが『Microsoft Visio』をオンラインで実行できる。こうすればMacユーザーがWindowsユーザーと全く同じ機能を使うことが可能だ」

　同氏によると、重要なのはDropletが提供する高いセキュリティレベルと採用するアプローチは、従来のコンテナ企業とは異なることだという。

　「重要なのは分離だ。コンテナはアプリケーションとして実行される。しかもOSの基盤となるホストデバイスから抽象化されて実行される。これはOSがハイパーバイザーで仮想マシン環境のハードウェアから抽象化されるのと同じ仕組みだ。つまりコンテナは基盤となるOSとの依存関係がなく、ハードウェアと直接通信する」

　コンテナ化という道を選び、セキュリティを維持することを求める企業に多くの選択肢があるのは確かだ。重要なのは、潜在的な脆弱性を認識して対策することだ。コンテナ化は今後も使われる技術なので、準備しておくにこしたことはない。