WEBVTT 00:00.150 --> 00:03.540 -私たちのネットワークで普及している最新の仮想化は､ 00:03.540 --> 00:07.980 コンテナ・ベース仮想化（コンテナ化とも呼ばれる）です｡ 00:07.980 --> 00:12.780 しかし､ このタイプの仮想化は､ エンドユーザーではなくサーバーに重点を置いている｡ 00:12.780 --> 00:16.440 このタイプの仮想化では､ オペレーティング・システムのカーネルは複数の仮想マシンで共有されるが､ 00:16.440 --> 00:22.740 各仮想マシンのユーザー空間は独自に作成・管理される｡ 00:22.740 --> 00:25.020 コンテナ化は仮想化の一種で､ ホスト・オペレーティング・システムによって適用され､ 00:25.020 --> 00:31.230 アプリケーションのための分離された実行環境を提供する｡ 00:31.230 --> 00:35.370 コンテナ化は､ オペレーティング・システム・レベルでリソースのセグメンテーションと分離を強制するため､ 00:35.370 --> 00:38.280 かなりセキュアだと考えられている｡ 00:38.280 --> 00:40.290 現在､ コンテナ化はLinuxサーバーで一般的に使用されており､ 00:40.290 --> 00:43.950 このコンテナベースの仮想化の例としては､ Docker､ Parallels 00:43.950 --> 00:48.960 Virtuozzo､ OpenVZプロジェクトなどがある｡ 00:48.960 --> 00:51.870 さて､ コンテナ化とは実際にはどのようなものだろうか？ 00:51.870 --> 00:56.460 ハードウェアがあり､ その上にホストOS（通常はLinux）があり､ 00:56.460 --> 00:59.430 さらにコンテナ・マネージャーがある｡ 00:59.430 --> 01:02.820 KubernetesとかDockerとか､ そういうものだ｡ 01:02.820 --> 01:08.070 さて､ このコンテナ・マネージャーを使って､ さまざまなアプリケーションを格納するコンテナを作成する｡ 01:08.070 --> 01:10.290 この場合､ 私は3つのコンテナを持っている｡ 01:10.290 --> 01:16.170 最初の環境は､ ホストOS（この例ではLinuxシステム）のカーネルに基づいている｡ 01:16.170 --> 01:20.700 コンテナではLinnuxが動いていて､ いくつかのアプリケーションが入っている｡ 01:20.700 --> 01:25.290 コンテナ2も同じことができるし､ コンテナ3も同じことができる｡ 01:25.290 --> 01:28.980 3つのコンテナはすべて同じホストOSファイルを共有している｡ 01:28.980 --> 01:30.750 これは､ 仮想マシンを使って純粋な仮想化を行うよりも､ 01:30.750 --> 01:33.690 はるかに少ないリソースで済む｡ 01:33.690 --> 01:35.730 仮想化について話したようにね｡ 01:35.730 --> 01:40.860 その代わりに個々の仮想マシンを使うとすれば､ それぞれにオペレーティング・システムのコピーが必要になる｡ 01:40.860 --> 01:43.740 そしてそれは､ 1つにつき8ギガバイトから10ギガバイトになるかもしれない｡ 01:43.740 --> 01:45.000 しかしコンテナを使えば､ 01:45.000 --> 01:47.280 全員が同じOSを共有できる｡ 01:47.280 --> 01:50.250 そのため､ コンテナ化によって使用されるストレージ・ベースは大幅に削減され､ 01:50.250 --> 01:52.260 処理能力も大幅に削減される｡ 01:52.260 --> 01:56.970 これこそが､ 運用の観点からコンテナのようなものを使うことの本当の利点なのだ｡ 01:56.970 --> 01:59.970 さて､ これらのコンテナは論理的に分離されている｡ 01:59.970 --> 02:02.100 実際に互いにインターフェースすることはできない｡ 02:02.100 --> 02:04.080 もし2つのコンテナを会話させたければ､ 02:04.080 --> 02:09.330 実際には仮想ネットワークで接続し､ 適切なルーティングとスイッチングを行って会話させなければならない｡ 02:09.330 --> 02:11.970 セグメンテーションがあるため､ 02:11.970 --> 02:16.410 セキュリティの観点からは素晴らしいことだ｡ 02:16.410 --> 02:20.010 さて､ コンテナを扱う際の大きな注意点だ｡ 02:20.010 --> 02:22.890 攻撃者がホストOSを侵害した場合､ 例えば､ 02:22.890 --> 02:27.960 先ほど説明したLinuxオペレーティング・システムがそうだ｡ 02:27.960 --> 02:30.810 その1つのオペレーティング・システムは､ 02:30.810 --> 02:35.790 ホストされているすべてのコンテナで使用されているからだ｡ 02:35.790 --> 02:38.820 これは､ コンテナを使用する際の最大の脆弱性の1つである｡ 02:38.820 --> 02:42.240 コンテナシステムで50台のサーバーを動かすこともできる｡ 02:42.240 --> 02:46.230 そして､ それぞれがコンテナ化を使って異なるサーバーやサービスを動かしている｡ 02:46.230 --> 02:49.050 しかし､ もし誰かがそのLinuxオペレーティング・システムの下にある1台のサーバーにアクセスすることができれば､ 02:49.050 --> 02:55.290 そのサーバーは50台すべてのホスティング・サーバーとすべてのデータにアクセスできるようになる｡ 02:55.290 --> 03:00.390 考慮すべきもう1つのリスクは､ コンテナやその他の仮想マシンを実際にどのようにホスティングするかだ｡ 03:00.390 --> 03:03.210 仮想化やクラウド・コンピューティングに依存し始めると､ 03:03.210 --> 03:09.660 自分たちのデータが他の組織のデータと同じ物理サーバーにホストされているかもしれないことを認識することが非常に重要になる｡ 03:09.660 --> 03:13.920 そうすることで､ システムのセキュリティに脆弱性が生じる｡ 03:13.920 --> 03:16.950 第一に､ 他の組織が何かしていることが原因で物理サーバーがクラッシュした場合､ 03:16.950 --> 03:22.500 同じサーバー上のすべての組織に影響を及ぼす可能性がある｡ 03:22.500 --> 03:24.960 同様に､ ある組織が仮想環境のセキュリティを維持せず､ 03:24.960 --> 03:28.740 物理サーバー上でホストしている場合､ 攻撃者がそれを利用して､ 03:28.740 --> 03:35.880 同じサーバー上でホストしている他の組織すべてに不利益をもたらす可能性がある｡ 03:35.880 --> 03:38.220 私たちのネットワークを他の誰かのネットワークと相互接続する際に懸念があるように､ 03:38.220 --> 03:44.010 複数の組織のデータを同じ物理サーバーでホスティングする際にも懸念があります｡ 03:44.010 --> 03:48.780 これらのサーバーでホストされている仮想マシンへのユーザーアクセスを適切に設定､ 03:48.780 --> 03:50.820 管理､ 監査することが重要です｡ 03:50.820 --> 03:53.850 また､ 仮想マシンに最新のパッチ､ アンチウイルス､ 03:53.850 --> 03:58.410 アンチウイルス､ アクセス制御を確実に適用したい｡ 03:58.410 --> 03:59.760 物理サーバーのリソースが圧迫されるリスクを最小限に抑えるには､ 03:59.760 --> 04:08.280 適切なフェイルオーバー､ 冗長性､ 弾力性を備えた仮想マシンをセットアップするのが常に良い考えです｡ 04:08.280 --> 04:11.610 ネットワークのパフォーマンスと物理サーバーのリソースを監視することで､ 04:11.610 --> 04:13.500 1台の物理マシンだけに頼るのではなく､ 04:13.500 --> 04:17.370 複数の物理マシンに負荷分散できるはずだ｡ 04:17.370 --> 04:19.290 攻撃者に悪用される可能性のあるもう1つの脆弱性は､ 04:19.290 --> 04:24.420 すべての仮想マシンで同じ種類のハイパーバイザーを使用している場合です｡ 04:24.420 --> 04:27.180 例えば､ 私たちの組織がVMwareのESXiハイパーバイザーのみに依存しており､ 04:27.180 --> 04:29.700 そのハイパーバイザーに対して新しいエクスプロイトが作成された場合､ 04:29.700 --> 04:35.790 攻撃者は私たちのすべてのシステムに対してそのエクスプロイトを使用することができます｡ 04:35.790 --> 04:38.400 だから､ 我々のサーバーのひとつで成功すれば､ 04:38.400 --> 04:40.830 他のサーバーでも試してくれるだろう｡ 04:40.830 --> 04:46.410 そして､ すべてのサーバーが同じプラットフォーム（この場合はVMwareのESXi）を使っている場合､ 04:46.410 --> 04:49.350 この脆弱性は組織全体に悪用される可能性がある｡ 04:49.350 --> 04:53.700 しかし､ この場合の課題は､ 複数のハイパーバイザー・プラットフォームを利用する場合､ 04:53.700 --> 04:57.360 サポート・コストとトレーニングの必要性が増大することだ｡ 04:57.360 --> 05:00.090 このような理由から､ ほとんどの組織は単一のプラットフォームを使用することを選択するが､ 05:00.090 --> 05:04.800 少なくともその際には､ リスクを考慮した上で決断を下すことになる｡ 05:04.800 --> 05:07.290 そのリスクを軽減するために､ 組織は適切なコンフィギュレーションを利用し､ 05:07.290 --> 05:16.830 ハイパーバイザーが常にパッチを適用して最新の状態に保たれ､ 安全な管理インターフェイスからのみアクセスできるようにし､ さらにアクセス制御を厳重に行う必要がある｡ 05:16.830 --> 05:21.570 システムを仮想化し､ オンプレミスまたはクラウドベースのソリューションに移行するかどうかを検討する際には､ 05:21.570 --> 05:25.410 これらの点を考慮する必要がある｡ 05:25.410 --> 05:27.540 まず､ 仮想化するのか？ 05:27.540 --> 05:32.430 その場合､ 従来の仮想マシンを使うのか､ それともコンテナ化を使うのか｡ 05:32.430 --> 05:34.410 ここでのリスクとリターンは？ 05:34.410 --> 05:35.970 バランスを取ることが必要なんだ｡ 05:35.970 --> 05:37.230 これはビジネス上の決断であり､ 05:37.230 --> 05:39.780 サイバーセキュリティ上の決断でもある｡ 05:39.780 --> 05:41.460 そして､ これらのことを測定し､ あなたの組織とその特定のユースケースにとって､ 05:41.460 --> 05:45.723 何を選択するのがベストかを決定しなければならない｡