コンテンツに移動
Google Cloud

セキュリティ比較 : コンテナと VM の違いとは

2017年8月22日
Google Cloud Japan Team

ここ数年、大企業やスタートアップの間でコンテナが大きな人気を集めています。コンテナは、開発ペースを大幅に引き上げ、リソースの効率的な利用によってコストを減らし、本番環境の一貫性を高めます。とはいえ、従来の VM ベースのアプリケーションに比べると、コンテナにはセキュリティに関して独特の意味合いがあるにもかかわらず、そのことがあまり理解されていないようです。

Google には、10 年以上にわたってコンテナ ベースの本番インフラストラクチャを運用してきた実績があります。この投稿では、従来の VM ベースのアプリケーションとコンテナにおけるセキュリティの違いについて、私たちの見方を皆さんとシェアしたいと思います。

コンテナ化されたワークロードは、いくつかの点で従来のアプリケーションとは大きく異なります。コンテナには次のような利点もあります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/7583878.max-700x700.png

  • アプリケーションがモジュール化される(モノリスからマイクロサービスへ)
  • リリースのオーバーヘッドが軽減される(便利なパッケージング形式と、明確に定義された CI/CD)
  • 寿命が短いため、陳腐化したパッケージの残存リスクが低減される(数か月~数年が数時間~数日へ)
  • 稼働後に、最初の状態からの逸脱が発生しにくい(ワークロードが短命で、簡単に再構築や再プッシュが行えるため、メンテナンスのための直接アクセスが減る)
では、こうした違いがセキュリティにどのような影響を及ぼすのかを見てみましょう。

コンテナのセキュリティ境界にまつわる誤解

コンテナのセキュリティに関するよくある誤解の 1 つは、コンテナは VM と同じようにセキュリティ境界となるべきなのに、そのような保障がないので VM よりもセキュアでないデプロイ方法だという見方です。しかし本当は、コンテナはミニ VM ではなく、アプリケーションをパッケージングして送り届けるための便利なメカニズムだと考えるべきなのです。

従来のアプリケーションが VM 内で完全に隔離されているわけではないのと同様に、攻撃者や悪意のプログラムが実行中のコンテナの外に飛び出し、同じ VM で実行されている他のコンテナを支配することもありえます。しかし、適切に保護されたクラスタのコンテナであれば、カーネル、共通のコンテナ インフラストラクチャ(Docker など)、VM サービスのいずれかに未パッチの脆弱性が残っていないかぎり、プログラムがコンテナの外に出ることはできません。

VM への攻撃のリスクを軽減するため、Google Container Engineフルマネージド ノードを提供するとともに、VM 内の脆弱性や陳腐化したパッケージ(サードパーティによるアドオンを含む)を積極的に監視し、必要に応じて自動更新や自動修復を行っています。したがって、新しい脆弱性が見つかったとしても、コンテナの外に出るための攻撃手段は限られます。

適切に保護され、更新されている VM であれば、通常のアプリケーションとコンテナ ワークロードの両方に対してプロセス レベルの分離機能を提供します。また、Linux のセキュリティ モジュールを使用すれば、コンテナの攻撃対象領域はさらに狭まります。たとえば、オープンソースのコンテナ オーケストレーション システムである Kubernetes は、コンテナからアクセスできるシステム コールに制限を加えるために、AppArmor、Seccomp、および SELinux とのネイティブな統合をサポートしています。

コンテナの分離をサポートするために Kubernetes が提供しているツールは他にもあります。PodSecurityPolicy を使えば、ワークロードがノード レベルで実行できることやアクセスできることに制限を加えることが可能です。また、特に機密性が高く、VM レベルでの分離が必要なワークロードの場合は、taint and toleration を使用することで、互いに信頼できるワークロードでなければ同じ VM でスケジューリングされないようにすることができます。

VM 内のアプリケーションでもコンテナ ワークロードでも、セキュリティ確保のための最終的な防壁は VM が提供します。セキュリティ レベルがまちまちなプログラムを同じ VM の上で実行したりしないのと同じように、セキュリティ レベルがまちまちなポッドを同じノードで実行することは避けるべきです。ポッドの間に確実なセキュリティ境界はないのです。

陳腐化したパッケージの排除

VM で実行されているアプリケーションに対する最も一般的な攻撃対象は、陳腐化したパッケージです。実際、既知の脆弱性の 99.9 % は、共通脆弱性識別子(CVE)が公開されてから 1 年以上もの間、悪用され続けています(Verizon Data Breach Investigation Report, 2015)。モノリシック アプリケーションでは保守担当者が OS やアプリケーションに手動でパッチを適用することが多く、VM ベースのワークロードはしばしば長期にわたって更新されずに実行され続けます。

コンテナの世界では、マイクロサービスと明確に定義された CI/CD パイプラインのおかげで、従来よりも簡単にリリース頻度を高めることができます。コンテナ化されたワークロードは一般に短命で(数日、場合によっては数時間)、パッケージの陳腐化によって生まれる攻撃対象領域は大幅に狭まっています。

Container Engine のホスト OS はハードニングされており、自動更新されます。さらに、フルマネージド ノードを採用すればゲスト OS とシステム コンテナでも自動パッチおよび自動更新が行われるため、既知の脆弱性によるリスクはさらに低くなります。

要約すると、コンテナは、高いリリース頻度を可能にする CI/CD パイプラインとの連携により、できるかぎり頻繁に最新のパッチで更新される体制を確立しているのです。

一元的なガバナンスのために

VM で従来のアプリケーションを実行していると、本番環境でどのソフトウェアが実行されているのかを正確に把握することはほぼ不可能であり、ましてどのソフトウェアがデプロイされようとしているのかを管理することはできません。これは重大な欠点であり、その根本原因は 3 つあります。

  1. VM は不透明なアプリケーション パッケージング形式であり、デプロイ前に内容を検査して一覧化するためのワークフローを効率的な形で確立することが難しい。
  2. VM イメージ管理は標準化されておらず、広く採用されてもいないため、プロジェクトにデプロイされたことのあるすべてのイメージを追跡することは難しい。
  3. VM ワークロードは寿命が長く、しかもアプリケーションおよび OS の更新やメンテナンスの際に管理者によって頻繁に操作されるため、それが原因でデプロイ時のもともとの状態から大きく逸脱してしまうことがある。
また、大規模な形でアプリケーションの状態を正確に把握することは難しく、それゆえ一般的なセキュリティ管理では、アプリケーションや OS の挙動、設定の異常を見つけることに重点を置くことで妥協してしまうのです。

それに対してコンテナは、より透明で検証しやすく変更不能なアプリケーション パッケージ形式のため、デプロイ前にコンテナの内容を検査して一覧化するためのワークフローを簡単に確立できます。さらにコンテナには、標準化されたイメージ管理メカニズム(特定コンテナのすべてのバージョンを追跡している一元的なイメージ リポジトリ)もあります。コンテナは一般に短命で、簡単に再構築や再プッシュが可能であり、実行中のコンテナがデプロイ時の状態から逸脱することも減ります。

これらの特徴は、コンテナの開発やデプロイのワークフローをセキュリティの管理下に置くうえで役に立ちます。適切なプロセスとコンテンツによって構築された適切なコンテナだけがデプロイされるようになれば、企業は本番環境で実行されているものを正確に知り、管理することができます。

セキュリティに対する責任の共有

VM ベースの従来のアプリケーションは、ある意味でコンテナ化アプリケーションよりも単純なセキュリティ モデルを提供しています。その実行環境は、一般に 1 人のオーナーによって作成、管理され、本番デプロイされるコードは IT によって全面的に管理されています。頻度の低い長期的なリリースには、一元化されたセキュリティ チームがすべての本番プッシュを詳細にチェックできるという意味もあります。

それに対してコンテナは、アジャイルなリリース プラクティスを実現し、スピーディで頻繁な本番プッシュを可能にする一方で、一元的なセキュリティ評価のための時間は VM アプリケーションよりも短く、セキュリティの責任をデベロッパーに委ねています。

コンテナを採用する企業は、開発のペースが上がり、セキュリティの責任が一元化されないことによるリスクを緩和するために、上述したベスト プラクティスも採用すべきでしょう。本番環境にデプロイされる外部依存コード(たとえばオープンソースのベース イメージ)を一元管理するプライベート レジストリの導入、脆弱性や問題のある依存コードを検出するイメージ スキャニングの CI/CD プロセスへの統合、既知の良質なソフトウェアだけが本番デプロイされるようにするためのデプロイ時間管理の確立などがそうです。

要するに、由緒正しく品質の高いセキュアなソフトウェアの自動的で効率的なサプライチェーンを確保すれば、セキュリティ面で大きなメリットが得られ、しかも手動のレビューを定期的に組み込むこともできるのです。

まとめ

VM ベースのアプリケーションが持つセキュリティ上の制約の多くは(現状では)コンテナにも当てはまりますが、アプリケーションのパッケージングとデプロイのためにコンテナを使用すると、より正確で効率的なセキュリティ管理への道が開けます。

このブログでは、コンテナ、セキュリティ、効果的なソフトウェア開発チームについて深く掘り下げる記事をこれからも掲載していきます。ご期待ください。

Google Cloud Platform(GCP)のセキュリティ モデルの詳細を学びたい方は、こちらのウェブ ページを参照してください。

* この投稿は米国時間 8 月 9 日、Product Manager である Jianing Guo によって投稿されたもの(投稿はこちら)の抄訳です。

- By Jianing Guo, Product Manager

投稿先