设计方案1(基于资源池的资源分配)
资源池的数量
在这一设计中,集群中有6台主机,客户在根资源池中创建子资源池。这种层次结构的资源池使得VI管理员可以通过指定每个资源池的保留值,共享值和资源上限等为不同的组织分配资源。
如图6所示,我们设计了三个资源池RP1,RP2和RP3。这些子资源池用于向三个不同的组织(HR,Finance和Sales)提供资源。
将内部区域安全规则映射到资源池
VI管理员基于资源池将资源分配到内部区域,为内部区域定义的安全规则可以被映射到相应的资源池:
1)
Data center → RP 1 : 只允许 TCP port 80流量通过
2)
RP1 → RP2 : 只允许TCP port 2222流量通过
3)
RP1 → RP3 : 所有流量禁止通过
4)
RP2 → RP3 : 只允许TCP port 3333流量通过
vShield App中的安全策略
vShield App是一个集中管理的,层次结构的防火墙。客户可以在数据中心,集群,资源池以及vApp级别创建规则。这些不同的级别也被称为容器,规则应用的优先顺序是:
1)
Data Center High Precedence Rules数据中心高优先级规则
2)
Cluster Level Rules群集级别规则
3)
Data Center Low Precedence Rules数据中心低优先级规则
4)
User defined Security Group Rules用户定义安全组规则
5)
Default Rules缺省规则
vShield App监视进出ESX主机的流量以及同一端口组中各虚拟机之间的流量以强制规则实现,强制策略时基于容器级别的优先级或自定义优先级别。容器级优先指数据中心级别的优先级高于群集级。当在数据中心级别配置规则时,此处的所有群集和 vShield代理都将继承此规则。因为数据中心高级别规则优先于群集级别规则,请确保集群级别规则与数据中心高级别规则不存在冲突。
客户也可以在每个容器级别配置允许或禁止全部流量的缺省规则,如:
缺省允许所有流量:在这种情况下,客户保留缺省的允许所有流量通过的规则,基于流量监视数据来创建禁止规则或手工配置应用防火墙。如果一个会话没有匹配任何禁止规则,vShield App将允许流量通过。
缺省禁止所有流量:这种情况与前一种刚好相反,需要明确指出允许通过的系统和应用。如果一个会话没有匹配任何一条允许规则,vShield App将丢弃会话流量。
前面定义的安全规则可以通过下述配置实现:
数据中心级别策略 (高优先级规则)
-
只允许 TCP port 80流量通过
-
允许来自每个资源池的常用基础架构流量(如DNS/DHCP)通过
-
禁止其它流量
集群级别策略
-
允许用户从数据中心外部访问特定的应用程序(TCP Port 80流量)
-
允许来自每个资源池的常用基础架构流量(如DNS/DHCP)通过
资源池级别策略
-
允许TCP port 2222流量从RP1到RP2通过
-
允许TCP port 3333流量从RP2到RP3通过
-
RP2与RP3之间所有其它流量禁止通过
-
RP1与RP3之间所有流量禁止通过
部署
一旦客户确定了内部区域,安全策略和资源池划分,就应该开始部署了,如图5所示,集群中有6台主机,三个资源池用于运行不同的应用程序。
1)
在每台物理主机上部署一个vShield App
2)
创建资源池
3)
在数据中心,集群和资源池级别定义安全策略,并在群集级别的App Firewall标签上应用策略。
高可用
VMware vSphere平台具有HA和DRS等特性,可以提供弹性和可用性保证。当出现不同类型的故障时,vShield App设备都可以对虚拟基础架构提供持续保护。
·
物理主机失效:如果主机停止工作了,vShield App设备也就无效了,需要它来保护的虚拟机也停止了。如果启用了HA,则虚拟机会在集群中的其它主机上面自动重启,该主机会对虚拟机继续提供保护。
·
虚拟机失效:心跳监视机制帮助检测虚拟机中的操作系统失效,当检测到这种事件时,虚拟机将被重新启动。安全规则无需改变,vShield App设备对虚拟机持续提供保护。
·
vShield App虚拟机失效:如果vShield App设备失效,所有进出该主机的流量都将受到影响,在设备完成重启之前,该主机上的虚拟机将无法进行通讯。
·
vShield Manager失效:如果vShield Manager宕机,vShield App设备将继续提供安全保护,但是新虚拟机将不能被加入到安全组。同时,流量监视数据也可能丢失。
vShield App 设备的一些限制:
1)
vShield App虚拟机与物理主机绑定:vShield App防火墙与安全规则和物理主机上的虚拟机状态密切相关, vShield App虚拟机不能被手工迁移或由DRS自动迁移到其它物理主机。
2)
配置启动顺序:要确保某台物理主机上的所有虚拟机都被正确的保护,要确保先于所有虚拟机开启vShield App设备,当物理主机重新启动时,vShield基础架构可以保证这一点。
3)
对vShield App设备限制权限:VI管理员不应该被允许对vShield App虚拟机执行特权操作(如删除或移动等)。
图
6 基于资源池的设计
设计方案2 (基于vApp的资源分配)
vApp资源池的数量
在这一设计中,根级别的资源池拥有来自6台主机的资源。客户想要通过vApp容器来管理资源分配。不同于前述方案,我们不会根据不同组织的需求来分配资源,而是根据每个应用层来指定保留值,共享值和上限数值等。vApp在多层应用部署的情况下可以提供更好的灵活性与服务质量保证。
如图7所示,我们创建了三个vApp资源池,分别是Web,App和DB层。这三个vApp资源池用于为三个不同的应用层提供资源。
映射内部区域安全规则到vApp资源池
如果VI管理员基于vApp资源池来分配资源到内部区域,那么为内部区域定义的安全规则就应该映射到对应的vApp资源池:
1)
数据中心 → Web : 只允许 TCP port 80流量通过
2)
Web → DB : 所有流量禁止通过
3)
Web → App : 只允许TCP port 2222流量通过
4)
APP → DB : 只允许TCP port 3333流量通过
vShield App安全策略
我们在方案选项1中提到过,要确保集群级别规则与数据中心高优先级规则不存在冲突 。
数据中心级别策略 (高优先级规则)
-
对Web层只允许 TCP port 80流量通过
-
允许来自每个资源池的常用基础架构流量(如DNS/DHCP)通过
-
禁止其它流量
集群级别策略
-
允许用户从数据中心外部访问特定的应用程序(TCP Port 80流量)
-
允许来自每个资源池的常用基础架构流量(如DNS/DHCP)通过
资源池级别策略
-
允许TCP port 2222流量从Web到App通过
-
允许TCP port 3333流量从App到DB通过
-
App与DB之间所有其它流量禁止通过
-
Web与DB之间所有流量禁止通过
部署
一旦客户确定了内部区域,安全策略和资源池划分,就应该开始部署了,如图6所示,集群中有6台主机,三个资源池用于运行不同的应用程序。
1)
在每台物理主机上部署一个vShield App
2)
创建资源池
3)
在数据中心,集群和vApp级别定义安全策略,并在群集级别的App Firewall标签上应用策略。
高可用
与上一方案相同,不再累述。
图
7:vApp设计方案
结论
基于vShield App的安全解决方案可以为用户构建一个非常容易部署和管理的安全虚拟基础架构。vShield App是虚拟网卡级别的防火墙,它可以简化资源分组,对于IT管理员来说,非常容易理解和掌握。