WEBVTT 00:00.300 --> 00:04.110 ナレーター：最近､ クラウド・コンピューティングがこの業界の大きなトレンドになっているようだ｡ 00:04.110 --> 00:06.090 可用性の向上､ より高い回復力､ 無制限の弾力性が約束されているクラウドは､ 00:06.090 --> 00:14.340 従来のネットワーク・アーキテクチャと比較して､ 間違いなく多くの利点を私たちの組織に提供することができる｡ 00:14.340 --> 00:18.390 しかし､ クラウド・コンピューティングは､ 私たちの環境に多くのユニークなセキュリティ上の課題をもたらす可能性もあり､ 00:18.390 --> 00:20.910 私たちはそれを認識しておく必要がある｡ 00:20.910 --> 00:22.200 これらをよりよく理解するためには､ 00:22.200 --> 00:28.050 まず､ 現在利用可能なさまざまなタイプのクラウド・ソリューションとアーキテクチャを見てみる必要がある｡ 00:28.050 --> 00:30.900 クラウドの導入モデルには､ パブリック､ プライベート､ 00:30.900 --> 00:31.733 ハイブリッド､ 00:31.733 --> 00:36.450 コミュニティ､ マルチテナント､ シングル傾向の6種類がある｡ 00:36.450 --> 00:39.840 最も一般的なクラウドアーキテクチャはパブリッククラウドである｡ 00:39.840 --> 00:44.730 このモデルでは､ サービス・プロバイダーがインターネット経由でエンドユーザーにリソースを提供する｡ 00:44.730 --> 00:47.310 現在､ グーグル､ マイクロソフト､ アマゾンをはじめ､ 00:47.310 --> 00:50.460 数多くのパブリッククラウド・ソリューションが提供されている｡ 00:50.460 --> 00:56.880 例えば､ グーグル・ドライブは､ 無料と有料モデルの両方で提供されているパブリック・クラウド・サービスだ｡ 00:56.880 --> 01:03.870 現在､ パブリック・クラウドは､ 組織が必要とするサービスを迅速かつ効率的に得るための安価な方法となることが多い｡ 01:03.870 --> 01:05.880 つ目の選択肢は､ プライベート・クラウドだ｡ 01:05.880 --> 01:06.840 このサービスでは､ 01:06.840 --> 01:12.300 企業内リソースとして企業だけが利用できる独自のクラウド環境を構築する必要がある｡ 01:12.300 --> 01:13.380 プライベート・クラウドでは､ 01:13.380 --> 01:15.720 クラウド・リソースとそれをホストするサーバーの設計､ 01:15.720 --> 01:19.890 実装､ 運用は組織の責任となる｡ 01:19.890 --> 01:24.600 例えば､ 米国政府はGovCloudと呼ばれる独自のプライベートクラウドを運用している｡ 01:24.600 --> 01:27.510 そして､ これは政府内のさまざまな組織で使われている｡ 01:27.510 --> 01:30.990 しかし､ あなたの会社や私の会社は､ グーグル・ドライブやAWSやAzureのように､ 01:30.990 --> 01:34.830 そこにアクセスして使うことはできない｡ 01:34.830 --> 01:36.960 一般的に､ プライベート・クラウドは､ 01:36.960 --> 01:41.460 低コストであることよりもセキュリティを重視する場合に選択される｡ 01:41.460 --> 01:46.290 ハイブリッドクラウドソリューションは､ パブリッククラウドとプライベートクラウドの両方のメリットを組み合わせることができる｡ 01:46.290 --> 01:47.670 このアーキテクチャーでは､ 01:47.670 --> 01:51.510 プライベート・クラウドのように組織自身が開発・運用するリソースもあるが､ 01:51.510 --> 01:55.650 パブリック・クラウドのように､ 一般に公開されているリソースを利用したり､ 01:55.650 --> 02:01.680 他のサービス・プロバイダーにサービスをアウトソースしたりすることもできる｡ 02:01.680 --> 02:04.500 パブリック・クラウドとプライベート・クラウドのリソースが混在しているため､ 02:04.500 --> 02:09.900 ハイブリッド・クラウドの各部分でホストされるデータの種類にかかわらず､ 厳格なルールを適用する必要がある｡ 02:09.900 --> 02:15.480 例えば､ 機密情報は組織のプライベート・クラウド部分にホスティングされるべきである｡ 02:15.480 --> 02:17.910 第4の選択肢は､ コミュニティクラウドだ｡ 02:17.910 --> 02:20.070 このモデルでは､ 共通のサービスを必要とする複数の組織が､ 02:20.070 --> 02:24.360 リソースとコストを共有する｡ 02:24.360 --> 02:29.340 これは､ 複数のプライベート・クラウドをつなぎ合わせてコストを下げるのと似ている｡ 02:29.340 --> 02:30.810 ここでのセキュリティ上の課題は､ 02:30.810 --> 02:32.580 各組織がそれぞれ独自のセキュリティ管理をしている可能性があり､ 02:32.580 --> 02:37.710 これらを組み合わせる際にそれを緩和しなければならないということだ｡ 02:37.710 --> 02:43.230 自分のネットワークを他のネットワークに接続すれば､ そのネットワークのセキュリティ・リスクも引き継ぐことになることを忘れないでほしい｡ 02:43.230 --> 02:46.350 これはクラウド環境に移行したからといって変わるものではない｡ 02:46.350 --> 02:48.810 さて､ 4つのクラウド展開モデルに加えて､ 02:48.810 --> 02:52.080 注意すべき他の2つのモデルも見ておく必要がある｡ 02:52.080 --> 02:54.690 これはマルチテナントであり､ 単一傾向である｡ 02:54.690 --> 02:57.180 最初のものはマルチテナンシーモデルだ｡ 02:57.180 --> 03:01.170 このモデルでは､ 同じリソースを複数の組織が使用する｡ 03:01.170 --> 03:03.330 ほとんどの組織では､ 1台のサーバーやサーバー群の全容量を使用することはないため､ 03:03.330 --> 03:08.340 これによって効率を大幅に向上させることができる｡ 03:08.340 --> 03:12.030 しかし､ 2つ以上の組織が同じ物理リソースを共有する場合､ 03:12.030 --> 03:14.250 セキュリティ上の懸念が生じる｡ 03:14.250 --> 03:18.750 たとえば､ あなたのウェブサイトが他の20人の顧客と共有サーバーでホストされている場合､ 03:18.750 --> 03:24.840 そのうちの1人がサービス拒否攻撃の犠牲者になると､ そのサーバー全体が同じ攻撃を受けることになります｡ 03:24.840 --> 03:27.120 そしてこれは､ 他のサーバーに対するサービス拒否の際に､ 03:27.120 --> 03:31.260 あなたのものを巻き添えにしてオフラインにすることもできる｡ 03:31.260 --> 03:35.580 さて､ これはマルチテナンシー・モデルで想定される危険とリスクのひとつに過ぎない｡ 03:35.580 --> 03:38.190 マルチテナンシー・モデルで想定されるリスクと戦うために､ 03:38.190 --> 03:41.640 シングル・テナンシーと呼ばれるシングル・ユーザー・モデルもある｡ 03:41.640 --> 03:46.410 このモデルでは､ 1つの組織が特定のリソースに割り当てられる｡ 03:46.410 --> 03:51.150 このため､ シングル・テナンシー・ソリューションはマルチテナンシー・ソリューションよりも効率が悪くなる傾向がある｡ 03:51.150 --> 03:53.040 また､ 適切に動作させるためにはより多くのハードウェアを必要とするため､ 03:53.040 --> 03:55.440 価格も高くなる｡ 03:55.440 --> 03:58.530 では､ この6つのモデルのうち､ あるいはこれらのモデルの組み合わせのうち､ 03:58.530 --> 04:00.750 どれがあなたの組織に適しているのだろうか？ 04:00.750 --> 04:03.240 まあ､ それはあなたのセキュリティー・ニーズ､ 04:03.240 --> 04:05.940 コスト制限､ リスク許容度による｡ 04:05.940 --> 04:11.520 パブリック・クラウド・モデルを組み合わせたマルチテナンシー・モデルを使用するのが最も安上がりだろう｡ 04:11.520 --> 04:16.560 しかし､ これは情報の機密性と可用性に対するリスクを高めることにもなる｡ 04:16.560 --> 04:19.140 セキュリティ実務者として検討する多くの事柄と同様､ 04:19.140 --> 04:21.090 ここに唯一の正解はありません｡ その代わりに､ 04:21.090 --> 04:23.490 これらのモデルの利点と欠点を比較検討し､ 04:23.490 --> 04:30.453 組織固有のニーズと懸念事項に基づいてどれが正しいかを決定するのが私たちの仕事です｡