Azure ARM (21) Azure订阅的两种管理模式
2018-01-31 17:05
281 查看
《Windows Azure Platform 系列文章目录》
熟悉Azure平台的读者都知道,Microsoft Azure服务管理,分为三个层次:
1.企业服务合同 (Enterprise Agreement)
2.订阅(Subscription),在1个企业服务合同下,可以创建无数多个订阅,订阅之间的资源是互相隔离的。
3.资源组(Resource Group),在1个订阅下,可以创建无数个资源组。
通过资源组,我们可以设置RBAC(Role Base Access Control)。设置对资源的访问权限,比如只读,可读写等。
有关RBAC的内容,可以参考我的blog:
Azure ARM (16) 基于角色的访问控制 (Role Based Access Control, RBAC) - 使用默认的Role
Azure ARM (17) 基于角色的访问控制 (Role Based Access Control, RBAC) - 自定义Role
这里多提一句,我们可以针对每个一个资源(Resource)设置标签(TAG),也就是增加备注。
比如创建的时间,项目所属部门,负责人,成本中心,操作人,审核人,版本号等等,一个资源可以设置15个标签(TAG)
从我的客户使用Azure来说,对于订阅的管理分为两种:
一.以项目来区分订阅的,比如1个项目创建一个订阅。如下图所示:
简单说明一下上图的设计:
1.我们的设计思路是1个项目1个订阅
2.在不同的订阅里面,分别创建不同的Virtual Network,且保证IP Range不能重叠
3.设置公用的Express Route Gateway,这个Express Route Gateway通过专线链接到IDC
4.如果不同的订阅项目,需要通过内网互相访问,则设置不同订阅之间的VNet Peering
5.如果不同的订阅项目,需要链接到内网IDC的资源,则设置不同订阅,到Shared ER Gateway之间的VNet Peering
这样管理的优点是:
1.管理简单。
当我们新上一个项目的时候,只要EA账户的管理员创建1个新的订阅和对应的账户即可。
而且Azure EA Portal (http://ea.windowsazure.cn),是可以按照订阅进行成本拆分的。
但是这样的管理方式,还是有缺点的:
1.需要在每个不同的订阅,设置Virtual Network的Private IP Range
如上图所示,我们需要IT Admin预先设置Virtual Network的Private IP Range。比如A项目的Virtual Network IP Range为172.0.0.0/24,B项目的VNet IP Range为172.0.1.0/24
因为部署在云端的项目在一开始可能不需要通过内网进行互通互联,但是后期需要进行内网互通。
比如在A订阅里面是CRM系统,在B订阅里面是订单系统。就要通过A订阅的内网链接(VNet Peering) 到B订阅的内网。
如果我们使用Azure Virtual Network默认的IP Range 10.0.0.0/24就完蛋了,因为两个相同IP Range的Virtual Network无法设置VNet Peering
2.VNet Peering会增加额外的成本
根据Azure China官网价格,VNet Peering的成本为:入站数据传输为每GB 0.065元,出站数据传输为每GB 0.065元
3.项目越多,VNet Peering的连接线会越多
大家想象一下,如果我有50个订阅,每个订阅有1个VNet。如果这50个订阅的VNet都要设置VNet Peering,代价是非常大的。
4.有潜在的安全风险
因为订阅是直接由项目负责人来进行维护的,如果这些项目负责人不具备相应的IT技能(比如把端口22, 3389, 1433等直接暴露在Internet上),则会产生潜在的安全风险。
每个项目都需要进行架构设计(Architect Review)和安全审查(Security Review)。
总结如下:
另外一种订阅的设计方式是:我只创建2个订阅,1个生产订阅,1个测试订阅。如下图:
简单说明一下上图的设计:
1.我们只创建2个订阅:Production生产订阅,和Non-Production测试订阅
2.在Production订阅和Non-Production订阅下,分为创建2个资源组Public Resource Group和Private Resource Group
3.在Public Resource Group里面,设置面向公网的,虚拟网络Virtual Network和对应的Subnet。
将来所有面向公网的资源,都部署在Public Resource Group里面
4.在Private Resource Group里面,设置面向内网的,虚拟网络的Virtual Network和对应的Subnet
将来所有面向内网的资源,都部署在Private Resource Group里面
这样管理的优点是:
1.相比第一种设计思路,安全更高
IT Admin对整体项目负责,所以不存在某个资源开启了不安全的端口。
这里有个非常重要的概念是:我们把NSG设置到VNet的Subnet上,IT Admin对所有的Subnet负责
2.IT Admin还可以设置WAF设备和IPS设备
3.IT Admin负责整体的安全性
因为IT Admin只管理2个订阅,每个订阅的Virtual Network的安全组(Network Security Group, NSG)都是由IT Admin进行管理的
但是这样的管理方式,还是有缺点的:
1.区分成本不如第一种方式简单
因为不同项目的Azure资源,都部署在同一个订阅里。所以我们在进行成本拆分的时候,需要对每个资源都增加标签TAG,通过不同的TAG进行筛选和成本拆分。
2.IT Admin必须提用户创建资源
这里有1个知识点:
IT Admin可以管理的资源是:
(1)Public Resource Group里面的Virtual Network
(2) Private Resource Group里面的Virutal Network
(3) 不同项目需要的资源组,比如A项目的资源组(里面有虚拟机,SQL数据,Azure Storage等等),B项目的资源组,C项目的资源组等等。
普通用户可以管理的资源是:
(1)不同项目需要的资源组,比如A用户管理A资源组,B用户管理B资源组,C用户管理C资源组
这样管理的好处是:
(1) IT Admin可以看到所有的资源。
(2) 普通用户只能看到自己管理的资源,但是无法看到[b]Public Resource Group里面的Virtual Network,还有[b]Private Resource Group里面的Virutal Network[/b][/b]
(3) 普通用户无法将某个虚拟机资源,从1个Subnet,迁移到另外1个Subnet。因为[b][b][b]Virutal Network对用户不可见。[/b][/b][/b]
3.订阅有限制
根据Azure文档:https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits
我们把所有资源都创建在1个订阅下,会遇到订阅的限制,比如1个订阅最多可以使用1万个CPU Core
4.如果我们已经采用第一种方案([b]1个项目1个订阅),在迁移到第二种方案的时候。需要对现有资源进行整合[/b]
这样会增加额外的迁移成本
总结如下:
特别说明,针对上面的Azure订阅设计,从网络安全性角度来说,我们可以通过用户自定义路由(User Define Route, UDR)
来设置在Virtual Network内的VM之间的数据流走向。如下图:
上图中,我们可以在Public Virtual Network里面设置4个3个Subnet
1. Web Subnet,用来保存面向公网应用的Web Server
2. DB Subnet,用来保存面向公网应用的DB Servers
3. DMZ Subnet,用来保存IPS入侵监测VM
4. 当Web Server需要访问DB Server的时候,所有流量都需要经过DMZ Subnet的IPS设备,进行流量清洗和入侵检测
面向内网的Private Virtual Network的设计也是相类似的。
熟悉Azure平台的读者都知道,Microsoft Azure服务管理,分为三个层次:
1.企业服务合同 (Enterprise Agreement)
2.订阅(Subscription),在1个企业服务合同下,可以创建无数多个订阅,订阅之间的资源是互相隔离的。
3.资源组(Resource Group),在1个订阅下,可以创建无数个资源组。
通过资源组,我们可以设置RBAC(Role Base Access Control)。设置对资源的访问权限,比如只读,可读写等。
有关RBAC的内容,可以参考我的blog:
Azure ARM (16) 基于角色的访问控制 (Role Based Access Control, RBAC) - 使用默认的Role
Azure ARM (17) 基于角色的访问控制 (Role Based Access Control, RBAC) - 自定义Role
这里多提一句,我们可以针对每个一个资源(Resource)设置标签(TAG),也就是增加备注。
比如创建的时间,项目所属部门,负责人,成本中心,操作人,审核人,版本号等等,一个资源可以设置15个标签(TAG)
从我的客户使用Azure来说,对于订阅的管理分为两种:
一.以项目来区分订阅的,比如1个项目创建一个订阅。如下图所示:
简单说明一下上图的设计:
1.我们的设计思路是1个项目1个订阅
2.在不同的订阅里面,分别创建不同的Virtual Network,且保证IP Range不能重叠
3.设置公用的Express Route Gateway,这个Express Route Gateway通过专线链接到IDC
4.如果不同的订阅项目,需要通过内网互相访问,则设置不同订阅之间的VNet Peering
5.如果不同的订阅项目,需要链接到内网IDC的资源,则设置不同订阅,到Shared ER Gateway之间的VNet Peering
这样管理的优点是:
1.管理简单。
当我们新上一个项目的时候,只要EA账户的管理员创建1个新的订阅和对应的账户即可。
而且Azure EA Portal (http://ea.windowsazure.cn),是可以按照订阅进行成本拆分的。
但是这样的管理方式,还是有缺点的:
1.需要在每个不同的订阅,设置Virtual Network的Private IP Range
如上图所示,我们需要IT Admin预先设置Virtual Network的Private IP Range。比如A项目的Virtual Network IP Range为172.0.0.0/24,B项目的VNet IP Range为172.0.1.0/24
因为部署在云端的项目在一开始可能不需要通过内网进行互通互联,但是后期需要进行内网互通。
比如在A订阅里面是CRM系统,在B订阅里面是订单系统。就要通过A订阅的内网链接(VNet Peering) 到B订阅的内网。
如果我们使用Azure Virtual Network默认的IP Range 10.0.0.0/24就完蛋了,因为两个相同IP Range的Virtual Network无法设置VNet Peering
2.VNet Peering会增加额外的成本
根据Azure China官网价格,VNet Peering的成本为:入站数据传输为每GB 0.065元,出站数据传输为每GB 0.065元
3.项目越多,VNet Peering的连接线会越多
大家想象一下,如果我有50个订阅,每个订阅有1个VNet。如果这50个订阅的VNet都要设置VNet Peering,代价是非常大的。
4.有潜在的安全风险
因为订阅是直接由项目负责人来进行维护的,如果这些项目负责人不具备相应的IT技能(比如把端口22, 3389, 1433等直接暴露在Internet上),则会产生潜在的安全风险。
每个项目都需要进行架构设计(Architect Review)和安全审查(Security Review)。
总结如下:
另外一种订阅的设计方式是:我只创建2个订阅,1个生产订阅,1个测试订阅。如下图:
简单说明一下上图的设计:
1.我们只创建2个订阅:Production生产订阅,和Non-Production测试订阅
2.在Production订阅和Non-Production订阅下,分为创建2个资源组Public Resource Group和Private Resource Group
3.在Public Resource Group里面,设置面向公网的,虚拟网络Virtual Network和对应的Subnet。
将来所有面向公网的资源,都部署在Public Resource Group里面
4.在Private Resource Group里面,设置面向内网的,虚拟网络的Virtual Network和对应的Subnet
将来所有面向内网的资源,都部署在Private Resource Group里面
这样管理的优点是:
1.相比第一种设计思路,安全更高
IT Admin对整体项目负责,所以不存在某个资源开启了不安全的端口。
这里有个非常重要的概念是:我们把NSG设置到VNet的Subnet上,IT Admin对所有的Subnet负责
2.IT Admin还可以设置WAF设备和IPS设备
3.IT Admin负责整体的安全性
因为IT Admin只管理2个订阅,每个订阅的Virtual Network的安全组(Network Security Group, NSG)都是由IT Admin进行管理的
但是这样的管理方式,还是有缺点的:
1.区分成本不如第一种方式简单
因为不同项目的Azure资源,都部署在同一个订阅里。所以我们在进行成本拆分的时候,需要对每个资源都增加标签TAG,通过不同的TAG进行筛选和成本拆分。
2.IT Admin必须提用户创建资源
这里有1个知识点:
IT Admin可以管理的资源是:
(1)Public Resource Group里面的Virtual Network
(2) Private Resource Group里面的Virutal Network
(3) 不同项目需要的资源组,比如A项目的资源组(里面有虚拟机,SQL数据,Azure Storage等等),B项目的资源组,C项目的资源组等等。
普通用户可以管理的资源是:
(1)不同项目需要的资源组,比如A用户管理A资源组,B用户管理B资源组,C用户管理C资源组
这样管理的好处是:
(1) IT Admin可以看到所有的资源。
(2) 普通用户只能看到自己管理的资源,但是无法看到[b]Public Resource Group里面的Virtual Network,还有[b]Private Resource Group里面的Virutal Network[/b][/b]
(3) 普通用户无法将某个虚拟机资源,从1个Subnet,迁移到另外1个Subnet。因为[b][b][b]Virutal Network对用户不可见。[/b][/b][/b]
3.订阅有限制
根据Azure文档:https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits
我们把所有资源都创建在1个订阅下,会遇到订阅的限制,比如1个订阅最多可以使用1万个CPU Core
4.如果我们已经采用第一种方案([b]1个项目1个订阅),在迁移到第二种方案的时候。需要对现有资源进行整合[/b]
这样会增加额外的迁移成本
总结如下:
特别说明,针对上面的Azure订阅设计,从网络安全性角度来说,我们可以通过用户自定义路由(User Define Route, UDR)
来设置在Virtual Network内的VM之间的数据流走向。如下图:
上图中,我们可以在Public Virtual Network里面设置4个3个Subnet
1. Web Subnet,用来保存面向公网应用的Web Server
2. DB Subnet,用来保存面向公网应用的DB Servers
3. DMZ Subnet,用来保存IPS入侵监测VM
4. 当Web Server需要访问DB Server的时候,所有流量都需要经过DMZ Subnet的IPS设备,进行流量清洗和入侵检测
面向内网的Private Virtual Network的设计也是相类似的。
相关文章推荐
- 深入php-fpm的两种进程管理模式详解
- 深入php-fpm的两种进程管理模式详解
- [Azure] 使用 Visual Studio 2013 管理中国版 Azure 订阅
- [Azure]使用Azure Powershell输出ARM模式下某个账号中所有订阅下的虚拟网络拓扑
- DDD:管理“工作单元实例”的两种模式
- [Azure] 使用 Visual Studio 2013 管理中国版 Azure 订阅
- [Azure]ARM模式下使用Powershell找出订阅中没有被使用的vhd
- SVN版本管理:两种开发模式
- RTI1.3时间管理支持的两种模式
- 深入php-fpm的两种进程管理模式详解
- 掌握 Azure 的注册、帐户和订阅管理 Azure 上云须知
- 关于DDD:管理"工作单元实例"的两种模式的使用方法
- 软件公司两种不同的管理模式
- 域和工作组的区别(1) 局域网上的资源需要管理,“域”和“工作组”就是两种不同的网络资源管理模式。那么二者有何区别呢?看了这篇文章,您就会明白了。
- SVN 版本管理:两种开发模式
- [Azure]使用Powershell获取Azure ARM模式订阅下的一些常用信息
- 深入php-fpm的两种进程管理模式详解
- Azure Powershell管理多订阅及证书
- Azure PowerShell (4) 使用PowerShell管理多个订阅
- MapXtreme的两种状态管理模式