WEBVTT

00:00.150 --> 00:05.790
- ：在我们的网络中越来越流行的最新类型的虚拟化被称为基于容器的虚拟化,

00:05.790 --> 00:07.980
也被称为容器化｡

00:07.980 --> 00:12.780
不过, 这种类型的虚拟化更关注服务器而不是最终用户｡

00:12.780 --> 00:14.460
通过这种类型的虚拟化,

00:14.460 --> 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:33.390
容器化被认为是相当安全的,

00:33.390 --> 00:38.280
因为它在操作系统级别强制执行资源分段和分离｡

00:38.280 --> 00:40.290
现在容器化通常用于Linux服务器,

00:40.290 --> 00:43.950
这种基于容器的虚拟化的一些例子包括Docker,

00:43.950 --> 00:48.960
Parallels Virtuozzo和OpenVZ项目｡

00:48.960 --> 00:51.870
那么, 集装箱化到底是什么样子的呢？

00:51.870 --> 00:53.610
好吧, 你有一个硬件, 然后在这个硬件之上,

00:53.610 --> 00:56.460
你有一个主机操作系统, 通常是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
在这种情况下, 我有三个集装箱｡ 

01:10.290 --> 01:12.000
我有第一个环境, 它基于主机操作系统的内核,

01:12.000 --> 01:16.170
在这个例子中, 使用的是Linux系统｡

01:16.170 --> 01:18.720
所以我们有一个运行Linnux的容器,

01:18.720 --> 01:20.700
它包含一些应用程序｡

01:20.700 --> 01:25.290
现在容器2可以做同样的事情容器3也可以做同样的事情｡

01:25.290 --> 01:28.980
因为所有三个容器共享相同的主机操作系统文件｡

01:28.980 --> 01:33.690
这比使用虚拟机进行纯虚拟化需要少得多的资源｡

01:33.690 --> 01:35.730
就像我们谈到的虚拟化一样｡ 

01:35.730 --> 01:40.860
如果我们使用单独的虚拟机, 那么每个虚拟机都需要自己的操作系统副本｡

01:40.860 --> 01:43.740
每个可能有8到10千兆字节｡ 

01:43.740 --> 01:47.280
但是有了容器, 我们可以共享同一个操作系统｡

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
如果我想让两个容器对话, 我实际上必须通过虚拟网络连接它们,

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
如果攻击者破坏了下面的主机操作系统,

02:22.890 --> 02:24.990
例如, 我刚才讨论的Linux操作系统,

02:24.990 --> 02:27.960
猜猜会发生什么？

02:27.960 --> 02:30.810
好吧, 这个攻击现在可以访问所有容器的数据,

02:30.810 --> 02:35.790
因为一个操作系统被托管的所有容器使用｡

02:35.790 --> 02:38.820
这是使用容器时最大的漏洞之一｡

02:38.820 --> 02:42.240
我可以有一个运行50个不同服务器的容器系统｡

02:42.240 --> 02:46.230
每一个都使用容器化运行不同的服务器和服务｡

02:46.230 --> 02:49.050
但是, 如果有人能够访问Linux操作系统下的一台服务器,

02:49.050 --> 02:55.290
他们现在就可以访问所有50台托管服务器及其所有数据｡

02:55.290 --> 03:00.390
另一个需要考虑的风险是容器和其他虚拟机实际上将如何托管｡

03:00.390 --> 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:26.760
同样, 如果一个组织没有维护其虚拟环境的安全性,

03:26.760 --> 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:50.820
正确配置､ 管理和审核用户对托管在这些服务器上的虚拟机的访问对我们来说非常重要｡

03:50.820 --> 03:53.850
此外, 我们要确保我们的虚拟机有最新的补丁,

03:53.850 --> 03:58.410
防病毒, animwire和访问控制到位｡

03:58.410 --> 04:02.490
为了最大限度地降低物理服务器资源不堪重负的风险,

04:02.490 --> 04:08.280
设置具有适当故障转移､ 冗余和弹性的虚拟机始终是一个好主意｡

04:08.280 --> 04:09.810
通过监控网络性能和物理服务器资源,

04:09.810 --> 04:17.370
我们应该能够在多个物理机器上平衡负载, 而不是仅仅依赖于一个｡

04:17.370 --> 04:19.290
另一个可能被攻击者利用的漏洞是,

04:19.290 --> 04:24.420
当我们在所有虚拟机上使用相同类型的虚拟机管理程序时｡

04:24.420 --> 04:29.700
因此, 例如, 如果我们的组织仅依赖于VMware的VMware虚拟机监控程序,

04:29.700 --> 04:32.280
并且为该虚拟机监控程序创建了新的漏洞,

04:32.280 --> 04:35.790
那么攻击者可以使用该漏洞来攻击我们的所有系统｡

04:35.790 --> 04:40.830
所以, 如果它在我们的一台服务器上成功, 他们可能会在我们的其他服务器上尝试｡

04:40.830 --> 04:43.260
如果我们所有的服务器都使用同一个平台,

04:43.260 --> 04:49.350
在这种情况下, VMware的VMware, 这个漏洞可能会在我们整个组织中被利用｡

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
并决定为您的组织及其特定用例选择最佳方案｡
