LinuxコンテナとVM:セキュリティの比較

開発者はコンテナが大好きです。それらは使いやすく、起動が速いです。単純なハードウェアでもそれらの多くを実行できます。起動時のオーバーヘッドは常に開発とテストの悩みの種であり、このオーバーヘッドはマイクロサービスアーキテクチャでのみ増加します。開発者が半ダースのサービスを必要とする場合、ハードウェアの構成、インストーラーの実行、非互換性との戦いなど、セットアップで1日か2日を簡単に浪費する可能性があります。

コンテナーを使用すると、数分または数秒に折りたたまれ、1つの開発ワークステーションで実行できます。すぐに利用できる便利なコンテナイメージのリポジトリは、オープンソースと同じように開発者の生産性を向上させますが、ビルドを行う手間がかかりません。運用チームはコンテナの採用に時間がかかっています。 1つの理由は、サポートする必要のある多くのアプリケーションがまだコンテナ化されていないことです。もう1つの理由は、VMから離れることに消極的であるということです。

運用では、ベアメタルからVMへの移行は自然なことでした。個々のVMは、同じツールとプロセスを使用して、個々のシステムのように見え、管理できます。 VMのセキュリティに関する初期の懸念は、メインフレームの世界でのVMの長い生産履歴、ベアメタルシステムに使用されるのと同じ制御を適用する機能、ハードウェア仮想化のサポート、およびVM管理ツールの進化する成熟度によって緩和されました。

初期のセキュリティに関する多くの懸念は、1つの質問に帰着しました。VMはベアメタルと同じくらい安全でしたか?現在、コンテナについて同様の質問が提起されています。コンテナはどの程度安全で、VMと比較してどうですか?確かに、コンテナーで実行されているサービスを、同じシステムで別々のプロセスとして実行されている同じサービスと比較すると、コンテナーのバージョンの方が安全です。 Linux名前空間とcgroupによって提供される分離は、プレーンプロセス間には存在しない障壁を提供します。 VMとの比較はあまり明確ではありません。セキュリティの観点からVMとコンテナを見てみましょう。

この記事では、VMとコンテナのセキュリティを比較するために2つの異なるアプローチを取ります。最初のアプローチは、セキュリティの観点からそれぞれの特性を検討する、より構造的または理論的なものになります。次に、一般的な違反で何が発生し、コンテナとVMアーキテクチャによってどのように影響を受ける可能性があるかを調べて、より実用的な分析を適用します。

構造図

構造的アプローチについては、両方のシステムの攻撃対象領域を比較します。攻撃対象領域は、システムが攻撃される可能性のあるポイントの数を表します。正確に定義されているわけではありませんが(たとえば、数値として)、比較には役立ちます。泥棒にとって、ドアが10個ある家は、ドアが同じであっても、ドアが1個ある家よりも攻撃対象領域が大きくなります。 1つのドアのロックが解除されたままになる可能性があります。 1つのロックに欠陥がある可能性があります。さまざまな場所にあるドアは、侵入者により多くのプライバシーを提供する可能性があります。

コンピュータシステムでは、攻撃対象領域には、攻撃者(または攻撃者に代わって行動するソフトウェア)が標的システムに「触れる」ことができるあらゆるものが含まれます。ネットワークインターフェイス、ハードウェア接続、および共有リソースはすべて、考えられる攻撃ポイントです。攻撃対象領域は、実際の脆弱性が存在することを意味するものではないことに注意してください。 10個のドアはすべて完全に安全かもしれません。ただし、攻撃対象領域が大きいほど、保護する場所が多くなり、攻撃者が少なくとも1つに弱点を見つける可能性が高くなります。

攻撃対象領域の合計は、さまざまなタッチポイントの数とそれぞれの複雑さに依存します。簡単な例を見てみましょう。株式市場の相場を提供する昔ながらのシステムを想像してみてください。それは単一のインターフェース、単純なシリアルラインを持っています。その行のプロトコルも単純です。固定長の銘柄記号、たとえば5文字がサーバーに送信され、サーバーは固定長の価格見積もり(たとえば、10文字)で応答します。イーサネット、TCP / IP、HTTPなどはありません。(私は実際、はるか昔に、はるか遠くの銀河でそのようなシステムに取り組んでいました。)

このシステムの攻撃対象領域は非常に小さいです。攻撃者は、シリアルラインの電気的特性を操作したり、誤ったシンボルを送信したり、大量のデータを送信したり、その他の方法でプロトコルを変更したりする可能性があります。システムを保護するには、これらの攻撃に対する適切な制御を実装する必要があります。

同じサービスを想像してみてください。ただし、最新のアーキテクチャです。このサービスはインターネット上で利用可能であり、RESTfulAPIを公開しています。攻撃の電気的な側面はなくなりました。攻撃者自身のルーターまたはスイッチを揚げるだけです。しかし、プロトコルは非常に複雑です。IP、TCP、場合によってはTLS、HTTPのレイヤーがあり、それぞれが悪用可能な脆弱性の可能性を提供します。最新のシステムの攻撃対象領域ははるかに大きくなっていますが、攻撃者には単一のインターフェイスポイントのように見えます。

ベアメタル攻撃対象領域

データセンターに物理的に存在しない攻撃者にとって、最初の攻撃対象領域はサーバーへのネットワークです。これにより、セキュリティの「境界ビュー」が生まれました。データセンターへのエントリポイントを保護し、何も侵入しないようにします。攻撃者が侵入できない場合は、内部のシステム間で何が起こっても問題ありません。境界インターフェイスが単純な場合(ダイヤルアップを考えてください)はうまく機能しましたが、内部インターフェイスの弱点を助長しました。境界に穴を見つけた攻撃者は、サーバーファームの内部の攻撃対象領域が外部の攻撃対象領域よりもはるかに大きいことに気付くことが多く、内部に入るとかなりの損害を与える可能性があります。

この内部攻撃対象領域には、サーバー間のネットワーク接続だけでなく、単一サーバー内のプロセス間の相互作用も含まれていました。さらに悪いことに、多くのサービスは昇格された特権(「root」ユーザー)で実行されるため、1つにうまく侵入すると、追加の脆弱性を探すことなく、そのシステム上の他のものに自由にアクセスできるようになります。業界全体は、ファイアウォール、マルウェア対策、侵入検知などのサーバーの保護を中心に成長しましたが、完璧とは言えませんでした。

サーバーに対する興味深い「サイドチャネル」攻撃もあります。研究者は、コンピューターからの電力消費、ノイズ、または電磁放射を使用して情報、場合によっては暗号化キーなどの非常に機密性の高いデータを抽出する例を示しています。他の攻撃では、ワイヤレスキーボードプロトコルなどの公開されたインターフェイスが利用されています。ただし、一般的に、これらの攻撃はより困難であり、たとえばサーバーへの近接性が必要になる場合があるため、「ネットワークを介して」到達する主な経路がより一般的です。

VM攻撃対象領域

VMがベアメタルと同じように使用され、アプリケーションのアーキテクチャに違いがない場合(よくあることですが)、VMはほとんど同じ攻撃ポイントを共有します。追加の攻撃対象領域の1つは、ハイパーバイザー、OS、またはハードウェアでVM間でリソースを適切に分離できず、VMが別のVMのメモリを何らかの方法で読み取れる可能性があることです。 VMとハイパーバイザー間のインターフェイスも攻撃ポイントを表します。 VMが突破してハイパーバイザーで任意のコードを実行できる場合、VMは同じシステム上の他のVMにアクセスできます。ハイパーバイザー自体は、管理インターフェイスを公開するため、攻撃のポイントを表します。

VMシステムのタイプに応じて、追加の攻撃ポイントがあります。タイプ2VMシステムは、基盤となるホストOS上でプロセスとして実行されるハイパーバイザーを使用します。これらのシステムは、ホストOSを攻撃することによって攻撃される可能性があります。攻撃者がホストシステムでコードを実行できる場合、特に特権ユーザーとしてアクセスできる場合は、ハイパーバイザーとVMに影響を与える可能性があります。ユーティリティ、管理ツール、場合によっては他のサービスやエントリポイント(SSHなど)を含むOS全体の存在は、考えられる攻撃ポイントの数を提供します。ハイパーバイザーが基盤となるハードウェア上で直接実行されるタイプ1VMシステムは、これらのエントリポイントを排除するため、攻撃対象領域が小さくなります。

コンテナの攻撃対象領域

VMと同様に、コンテナはベアメタルシステムの基本的なネットワークエントリ攻撃ポイントを共有します。さらに、タイプ2仮想マシンと同様に、「完全にロードされた」ホストOSを使用するコンテナシステムは、そのホストOSのユーティリティとサービスに対して利用可能な同じ攻撃のすべての影響を受けます。攻撃者がそのホストにアクセスできる場合は、実行中のコンテナにアクセスするか、影響を与えることができます。特権(「ルート」)アクセスを取得すると、攻撃者は任意のコンテナにアクセスまたは制御できるようになります。 「ミニマリスト」OS(ApceraのKurmaOSなど)は、この攻撃対象領域を減らすのに役立ちますが、コンテナー管理にはホストOSへのアクセスが必要なため、完全に排除することはできません。

基本的なコンテナ分離メカニズム(名前空間)も潜在的な攻撃ポイントを提供します。さらに、Linuxシステムのプロセスのすべての側面に名前空間が付けられているわけではないため、一部の項目はコンテナー間で共有されます。これらは、攻撃者が調査する自然な領域です。最後に、カーネルインターフェイス(システムコール用)へのプロセスは大きく、VMとハイパーバイザー間のはるかに小さいインターフェイスとは対照的に、すべてのコンテナーで公開されます。システムコールの脆弱性は、カーネルへの潜在的なアクセスを提供する可能性があります。この一例は、最近報告されたLinuxキーリングの脆弱性です。

アーキテクチャ上の考慮事項

VMとコンテナの両方で、攻撃対象領域のサイズは、アプリケーションアーキテクチャとテクノロジの使用方法によって影響を受ける可能性があります。

多くのレガシーVMアプリケーションは、VMをベアメタルのように扱います。言い換えれば、VMや境界セキュリティに基づかないセキュリティモデルに特化したアーキテクチャを採用していません。同じVMに多くのサービスをインストールし、root権限でサービスを実行し、サービス間のセキュリティ制御がほとんどまたはまったくない場合があります。これらのアプリケーションを再設計する(または新しいアプリケーションに置き換える)と、VMを使用して、単に多数のマシンを管理する手段としてではなく、機能ユニット間のセキュリティを分離することができます。

コンテナは、標準化されたAPIを使用して多数の(通常は)小さなサービスを「つなぎ合わせる」マイクロサービスアーキテクチャに最適です。このようなサービスの有効期間は非常に短いことが多く、コンテナ化されたサービスがオンデマンドで開始され、要求に応答して破棄されたり、サービスが需要に基づいて急速に増減したりします。その使用パターンは、コンテナーがサポートする高速インスタンス化に依存しています。セキュリティの観点からは、メリットとデメリットの両方があります。

サービスの数が多いほど、ネットワークインターフェイスの数が多くなり、攻撃対象領域が大きくなります。ただし、ネットワーク層でより多くの制御を行うこともできます。たとえば、Apceraプラットフォームでは、すべてのコンテナからコンテナへのトラフィックを明示的に許可する必要があります。不正なコンテナは、ネットワークエンドポイントに任意に到達することはできません。

コンテナの存続期間が短いということは、攻撃者が侵入した場合、長時間実行されるサービスによって提供される機会のウィンドウとは対照的に、攻撃者が何かをしなければならない時間が制限されることを意味します。欠点は、フォレンジックが難しいことです。コンテナがなくなると、マルウェアを見つけるために調査および調査することはできません。これらのアーキテクチャはまた、攻撃者がブート時にロードするドライバーをインストールすることでベアメタルに侵入する可能性があるため、コンテナーの破壊後も存続するマルウェアをインストールすることをより困難にします。コンテナは通常、信頼できる読み取り専用リポジトリからロードされ、暗号化チェックによってさらに保護できます。

次に、違反中に何が起こっているかを考えてみましょう。

違反に対する保護

攻撃者は通常、サーバーシステムに侵入する際に1つまたは2つの目標を持っています。彼らはデータを取得したり、損害を与えたいと思っています。

彼らがデータを求めている場合、彼らは可能な限り最高の特権で可能な限り多くのシステムに侵入し、そのアクセスを可能な限り長く維持したいと考えています。これを達成すると、データを見つける時間が与えられます。データはすでに存在している可能性があります(たとえば、セキュリティが不十分なデータベース)。または、ユーザーからのトランザクションの収集など、時間の経過とともに収集が遅くなる可能性があります。長期間アクセスを維持するには、ステルスが必要です。攻撃には、データを取り出す方法も必要です。

攻撃者が単にダメージを与えようとしている場合、再び目標は、できるだけ多くのシステムと特権にアクセスすることです。しかし、バランスをとる行為があります。損傷が始まると、おそらく気付かれますが、攻撃者が開始を待つ時間が長くなるほど(マルウェアがシステムからシステムへとフィルタリングする間)、検出される可能性が高くなります。データを取り出すことは、マルウェアを協調的に制御することほど重要ではありません。アイデアは、できるだけ多くのシステムに感染し、事前に準備された、またはコマンドで、同期されたポイントでそれらを損傷することです。

違反には多くの要素が関係しています。それぞれを見て、VMとコンテナ化されたアーキテクチャがそれぞれの攻撃対象領域に影響を与える可能性があるかどうかを確認しましょう。