-私たちのネットワークで普及している最新の仮想化は､
コンテナ・ベース仮想化（コンテナ化とも呼ばれる）です｡
しかし､ このタイプの仮想化は､ エンドユーザーではなくサーバーに重点を置いている｡
このタイプの仮想化では､ オペレーティング・システムのカーネルは複数の仮想マシンで共有されるが､
各仮想マシンのユーザー空間は独自に作成・管理される｡
コンテナ化は仮想化の一種で､ ホスト・オペレーティング・システムによって適用され､
アプリケーションのための分離された実行環境を提供する｡
コンテナ化は､ オペレーティング・システム・レベルでリソースのセグメンテーションと分離を強制するため､
かなりセキュアだと考えられている｡
現在､ コンテナ化はLinuxサーバーで一般的に使用されており､
このコンテナベースの仮想化の例としては､ Docker､ Parallels
Virtuozzo､ OpenVZプロジェクトなどがある｡
さて､ コンテナ化とは実際にはどのようなものだろうか？
ハードウェアがあり､ その上にホストOS（通常はLinux）があり､
さらにコンテナ・マネージャーがある｡
KubernetesとかDockerとか､ そういうものだ｡
さて､ このコンテナ・マネージャーを使って､ さまざまなアプリケーションを格納するコンテナを作成する｡
この場合､ 私は3つのコンテナを持っている｡
最初の環境は､ ホストOS（この例ではLinuxシステム）のカーネルに基づいている｡
コンテナではLinnuxが動いていて､ いくつかのアプリケーションが入っている｡
コンテナ2も同じことができるし､ コンテナ3も同じことができる｡
3つのコンテナはすべて同じホストOSファイルを共有している｡
これは､ 仮想マシンを使って純粋な仮想化を行うよりも､
はるかに少ないリソースで済む｡
仮想化について話したようにね｡
その代わりに個々の仮想マシンを使うとすれば､ それぞれにオペレーティング・システムのコピーが必要になる｡
そしてそれは､ 1つにつき8ギガバイトから10ギガバイトになるかもしれない｡
しかしコンテナを使えば､
全員が同じOSを共有できる｡
そのため､ コンテナ化によって使用されるストレージ・ベースは大幅に削減され､
処理能力も大幅に削減される｡
これこそが､ 運用の観点からコンテナのようなものを使うことの本当の利点なのだ｡
さて､ これらのコンテナは論理的に分離されている｡
実際に互いにインターフェースすることはできない｡
もし2つのコンテナを会話させたければ､
実際には仮想ネットワークで接続し､ 適切なルーティングとスイッチングを行って会話させなければならない｡
セグメンテーションがあるため､
セキュリティの観点からは素晴らしいことだ｡
さて､ コンテナを扱う際の大きな注意点だ｡
攻撃者がホストOSを侵害した場合､ 例えば､
先ほど説明したLinuxオペレーティング・システムがそうだ｡
その1つのオペレーティング・システムは､
ホストされているすべてのコンテナで使用されているからだ｡
これは､ コンテナを使用する際の最大の脆弱性の1つである｡
コンテナシステムで50台のサーバーを動かすこともできる｡
そして､ それぞれがコンテナ化を使って異なるサーバーやサービスを動かしている｡
しかし､ もし誰かがそのLinuxオペレーティング・システムの下にある1台のサーバーにアクセスすることができれば､
そのサーバーは50台すべてのホスティング・サーバーとすべてのデータにアクセスできるようになる｡
考慮すべきもう1つのリスクは､ コンテナやその他の仮想マシンを実際にどのようにホスティングするかだ｡
仮想化やクラウド・コンピューティングに依存し始めると､
自分たちのデータが他の組織のデータと同じ物理サーバーにホストされているかもしれないことを認識することが非常に重要になる｡
そうすることで､ システムのセキュリティに脆弱性が生じる｡
第一に､ 他の組織が何かしていることが原因で物理サーバーがクラッシュした場合､
同じサーバー上のすべての組織に影響を及ぼす可能性がある｡
同様に､ ある組織が仮想環境のセキュリティを維持せず､
物理サーバー上でホストしている場合､ 攻撃者がそれを利用して､
同じサーバー上でホストしている他の組織すべてに不利益をもたらす可能性がある｡
私たちのネットワークを他の誰かのネットワークと相互接続する際に懸念があるように､
複数の組織のデータを同じ物理サーバーでホスティングする際にも懸念があります｡
これらのサーバーでホストされている仮想マシンへのユーザーアクセスを適切に設定､
管理､ 監査することが重要です｡
また､ 仮想マシンに最新のパッチ､ アンチウイルス､
アンチウイルス､ アクセス制御を確実に適用したい｡
物理サーバーのリソースが圧迫されるリスクを最小限に抑えるには､
適切なフェイルオーバー､ 冗長性､ 弾力性を備えた仮想マシンをセットアップするのが常に良い考えです｡
ネットワークのパフォーマンスと物理サーバーのリソースを監視することで､
1台の物理マシンだけに頼るのではなく､
複数の物理マシンに負荷分散できるはずだ｡
攻撃者に悪用される可能性のあるもう1つの脆弱性は､
すべての仮想マシンで同じ種類のハイパーバイザーを使用している場合です｡
例えば､ 私たちの組織がVMwareのESXiハイパーバイザーのみに依存しており､
そのハイパーバイザーに対して新しいエクスプロイトが作成された場合､
攻撃者は私たちのすべてのシステムに対してそのエクスプロイトを使用することができます｡
だから､ 我々のサーバーのひとつで成功すれば､
他のサーバーでも試してくれるだろう｡
そして､ すべてのサーバーが同じプラットフォーム（この場合はVMwareのESXi）を使っている場合､
この脆弱性は組織全体に悪用される可能性がある｡
しかし､ この場合の課題は､ 複数のハイパーバイザー・プラットフォームを利用する場合､
サポート・コストとトレーニングの必要性が増大することだ｡
このような理由から､ ほとんどの組織は単一のプラットフォームを使用することを選択するが､
少なくともその際には､ リスクを考慮した上で決断を下すことになる｡
そのリスクを軽減するために､ 組織は適切なコンフィギュレーションを利用し､
ハイパーバイザーが常にパッチを適用して最新の状態に保たれ､ 安全な管理インターフェイスからのみアクセスできるようにし､ さらにアクセス制御を厳重に行う必要がある｡
システムを仮想化し､ オンプレミスまたはクラウドベースのソリューションに移行するかどうかを検討する際には､
これらの点を考慮する必要がある｡
まず､ 仮想化するのか？
その場合､ 従来の仮想マシンを使うのか､ それともコンテナ化を使うのか｡
ここでのリスクとリターンは？
バランスを取ることが必要なんだ｡
これはビジネス上の決断であり､
サイバーセキュリティ上の決断でもある｡
そして､ これらのことを測定し､ あなたの組織とその特定のユースケースにとって､
何を選択するのがベストかを決定しなければならない｡