2019年12月16日 | Azure ARM (21) Azure订阅的两种管理模式

　　熟悉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 Network Resource Group和Private Network Resource Group

　　3.在Public Network Resource Group里面，设置面向公网的，虚拟网络Virtual Network和对应的Subnet。

　　请注意：Public Network Resource Group只对IT Admin可见

　　将来上新的，面向公网的业务。可以单独创建1个以业务名称命名的资源组(比如ProjectA-RG)，把所有Azure资源都放在这个资源组里(比如ProjectA-RG)。但是(ProjectA-RG)里的虚拟机，加入到Public Network Resource Group的虚拟网络里

　　4.在Private Network Resource Group里面，设置面向内网的，虚拟网络的Virtual Network和对应的Subnet

　　请注意：Private Network Resource Group只对IT Admin可见

　　将来上新的，面向内网的业务。可以单独创建1个以业务名称命名的资源组(比如ProjectB-RG)，把所有Azure资源都放在这个资源组里(比如ProjectB-RG)。但是(ProjectB-RG)里的虚拟机，加入到Private Network 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)  普通用户只能看到自己管理的资源，但是无法看到Public Resource Group里面的Virtual Network，还有Private Resource Group里面的Virutal Network

　　(3)  普通用户无法将某个虚拟机资源，从1个Subnet，迁移到另外1个Subnet。因为Virutal Network对用户不可见。

　　3.订阅有限制

　　根据Azure文档：https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits　　

　　我们把所有资源都创建在1个订阅下，会遇到订阅的限制

　　4.如果我们已经采用第一种方案(1个项目1个订阅)，在迁移到第二种方案的时候。需要对现有资源进行整合

　　这样会增加额外的迁移成本

　　总结如下：

　　特别说明，针对上面的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的设计也是相类似的。