より良いインフラストラクチャーがセキュリティの被害を未然に防ぐ方法について 第23回 18年10月 / 最終更新：2018.10.16
こんにちはー。野田貴子です。今回はOpenStack関連のコラムで面白いものがあったので意訳版をお届けします。昨今、OpenStackの注目度が高まっており、OpenStack開発者メーリングリストやコラムをチェックしている人も多いと思います。英語が苦手な方にとっては、日本語で要約版があると助かるのではないかと考え、日本語意訳したものをお伝えすることにしました。
さて、クラウドで『タワーリング・インフェルノ（超高層ビル火災を描いたパニック映画）』になるオンプレ草原での火災を防ぐことができるのはみなさんだけです、とOracleのGreg Marsden氏が弁を振るいました。
OracleのLinux開発のバイスプレジデントであるGreg Marsden氏は、セキュリティの被害を止めるために奮闘しています。
Marsden氏は、発足した2000年から40万行以上のコードをLinuxカーネルに提供してきたチームの創設メンバーです。彼はデザインプロセスの観点からOSセキュリティに対する様々なアプローチを行い、独立性のためにコンテナに依存し始めたサービスが増えるにつれて、さまざまな教訓を得てきました。
昨年、幅広いセキュリティの問題によって、古典的な物の見方が見直されました。
例えば稼働時間について見てみましょう。Oracleチームは再起動せずに6年以上経過しています。Marsden氏は先日のOpen Source Summit North Americaでの講演で、「この成果は誇るべきものなのかどうかまだ分かりません」 と話しました。「私はまだ200日や300日間の稼働時間でさえ若干明るい気分になりますが、セキュリティの弱点や脆弱性の知識が増えるにつれ、その期待はやや緩和されています。何かあるたびにアプリケーションをアップグレードしなければならない人たちに同情もします。」
（会場の様子）
https://twitter.com/linuxfoundation/status/1035644989005553665
学術研究者でなくともセキュリティの攻撃が上昇していることに気付くでしょう、と彼は述べています。「最近では大きめのクラウドプロバイダーのパブリックIPブロックでサーバを起動しようとすると、ホスト名が割り当てられていなくてもログファイルが監視され、セキュリティプローブ、SSHログイン試行などの攻撃が開始されるようになります。このようなレガシーOSの問題を取り扱う方法のひとつは、コンテナの導入です。
「コンテナを厳密に使用するとプロセスの分離が可能になり、自然なサンドボックス環境が生まれます」とMarsden氏は説明しています。「攻撃が成功したとしてもそのコンテナで立ち往生しかできないので、これはかなりまともなセキュリティ対策になります。」
被害をなくす
同氏は、ある程度までコンテナがホストOSや他のコンテナと共有し合うことを認めています。「すべてのコンテナの土台に張り巡らされているのは1つのカーネルであり、そのコンテナに影響を与える脆弱性は、そのシステム上で実行されているすべてのコンテナに影響を与えるカーネルの脆弱性だからです。」
「私たちは、Kataコンテナプロジェクトの有望さに高揚しています。」
一方、各コンテナにはそれぞれのユーザースペースとランタイムスタックがあり、それぞれのセキュリティアップデートセットを備えています。ディスク上のライブラリのバージョンが更新された際は、自主的にコンテナを再起動しないとコンテナは更新されません。コンテナが再起動するまではライブラリは古いバージョンのままとなります。マイクロサービスアーキテクチャを使用してコンテナに格納されるように書かれたアプリケーションならば簡単に更新できるので実際に更新されるでしょう。しかしレガシーなアプリケーションの場合は、現実のコンテナワークロードは古典的なデータセンターサービスと同様の稼働時間と可用性の要件が必要になります。というのが彼による指摘です。
「デプロイやパッケージングといった利点があるにもかかわらず、コンテナのセキュリティは古いタイプのアプリケーション開発よりもそれほど優れているわけではありません」とMarsden氏は述べています。コンテナはサイドチャネル攻撃の完璧な開始場所でもあります。この攻撃はハイパースレッドやCグループ上で実行されているプロセスに対して機能し、名前空間は対立する恐れのあるワークロードにて必ずしも共有をブロックして保護するわけではありません、とMarsden氏は付け加えました。
Kataコンテナで予防を少々
Kataコンテナはプロセスや名前空間として動作するのではなく、数秒で起動する最低限のカーネルを使用したプロセス分離のハードウェア仮想化を利用していることを念頭に、「Kataコンテナプロジェクトの有望さに高揚しています」と彼は語りました。「この特別なコンテナはハードウェア仮想化機能を使用して他のコンテナとの相互汚染を防ぎ、サイドチャネル攻撃に対するKVM防御を利用することができます。」
「すべてのコンテナに現れる1つの脆弱性の問題は、クラウドの世界でのみ拡大されています。複数のコンテナがコンピュータ全体で1つのカーネルを共有する環境では、クラウド全体で1つのハイパーバイザーを共有することになります。」クラウドは依然としてゲスト層にさまざまなソフトウェアの多様性を持っていますが、サービスやハイパーバイザー層ではさらに厳しく管理しています、と彼は説明しています。
クラウドはハイパーバイザーと仮想化環境をある程度統一し、その環境全体に一貫性を持たせることができたとのことです。理想的なクラウドとは、すべてのサービスを実行するOSプラットフォームを1つと、それらのサービス（パッチを当てるなどして常に最新のバージョンに保たれる）の中で動くただ一つのバージョンのハイパーバイザーしか持たないものです。なぜなら、セキュリティ上の脆弱性が修正されると、それらは全ての場所に適用されなければならないからだと彼は指摘しています。
彼のチームは、再起動しなくて良いライブパッチ（すべてのものを1つのカゴに収め、それだけを見ていれば済むアプローチ）を当てにしています。ここでは、本番環境のワークロードにライブパッチを適用するソリューションについて考えてみたいということです。
クラウドサービスプロバイダはセキュリティ上の脆弱性について早い段階で情報入手することがよくありますが、エンドユーザーはこれらの情報が一般公開されたときに初めて知ることになります。「ライブパッチを当てることは、リアルタイムで攻撃に反応して対処するための次善策で、おいおい自己修復OSとなることを目指しています」とMarsden氏は述べています。
同氏の講演はこちらで全て閲覧できます。
https://youtu.be/VBv8g2oSsDo
※本コラムは以下の文章を意訳したものです。
※本コラムは原文執筆者が公式に発表しているものでなく、翻訳者が独自に意訳しているものです。
サービス・ソリューション
