Azure Lei Zhang的博客

weibo: LeiZhang的微博/QQ: 185165016/QQ群:319036205/邮箱:leizhang1984@outlook.com/TeL:139-161-22926

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  390 随笔 :: 0 文章 :: 394 评论 :: 0 引用

  《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 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的设计也是相类似的。

  

posted on 2018-01-31 17:05 Lei Zhang的博客 阅读(...) 评论(...) 编辑 收藏