【TechTarget中国原创】

Azure Resource Manager（Azure资源管理器），公有云平台的管理门户，提供了一系列特性，来管理Azure角色，访问控制和安全策略。但是因为Azure用户的多样性，用户包括服务提供商，中央IT基础架构经理，IT运维团队和应用程序开发人员，Azure资源管理器可能有些混乱——特别是在控制服务访问和配置的时候。

本文深入探讨Azure资源管理器（ARM）基于角色的访问控制（RBACs），包括其和底层Azure预配概念，安全和认证管理特性的关系以及常见的用户场景。

在深入RBACs之前，理解Azure服务预配和使用的基本概念很重要，特别是计划、offer、订阅、配额、服务和角色之间的区别。

服务：Azure里最基本的消费单元。服务包括资源，比如虚拟机（VM），对象存储或者关系数据库。

计划：提供给用户的一些服务，比如一系列VM实例，存储和数据库类型，以及任何使用限制，比如域可用性或者资源配额。计划通常针对特定的IT角色，比如开发人员或者数据科学家，或者针对负载需求来量体定制。

Offer：订阅可用的某个或者多个计划的组合。Offer是用户选择订阅的实际产品集。

订阅：某个公司和某个云服务提供商之间的协议，按照订阅计划所定义的，来授予权限，从而消费某个或者多个服务。企业可能有一个或者多个订阅。

配额：作为计划的一部分来定义的服务限制。比如，Azure的免费层，本质上也是一个计划，限制用户可以在一个月内免费使用14个VM，40个SQL数据库和8 TB的存储空间。

角色：分配给某个个人或者组织的一系列访问，管理和使用权限。

使用Azure公有云时，计划和offer之间的差异并不明显，因为Microsoft在后台定义了这些。但是，当使用第三方Azure服务提供商，或者使用Azure Stack来构建私有云的话，这两者之间的差别就变得重要了。这很可能会给不同的组织，企业或者负载需求提供更多的不同粒度的服务包。对于Azure基于角色的访问控制而言，这两者的区别也比较重要，因为订阅和管理用户和组织身份的目录有关系。

管理员从用户目录定义Azure RBACs，并且每个订阅只能信任一个目录。小型开发团队可以使用Azure和Microsoft账号系统里所定义的用户和组；所有Azure角色和控制必须使用Microsoft账号来定义。如果企业之后才引入的Azure，可以将企业的活动目录（AD）和Azure同步，并且使用其设置策略，IT团队必须使用AD身份重新创建开发人员角色。因为个人或者组可能拥有多个订阅，所以务必确保每个订阅使用相同的用户目录来保证一致性。

无论是Azure还是其他系统，所有RBACs的指导性原则都是最小特权原则：终端用户必须仅拥有完成工作所必须的访问权限。Azure通过仅仅允许终端用户在显式定义了权限的资源上执行操作，来强制遵守最小特权原则。没有默认的权限，除非企业为所有资源将全局组应用到某个特定角色上。

在Azure上，RBACs遵循和AD使用类似的先序分层原则——针对用户，组和控制使用全局，父和子域

标准Azure角色

Microsoft定义了三种基础Azure角色：

所有者：拥有完整的管理权限

贡献者：拥有完整的管理权限，除了用户管理权限

只读者：能够查看资源权限

Microsoft还有更加具体的内置Azure角色的列表。比如，自动运维人员（Automation Operator）角色允许其成员启动，停止，暂停并且恢复作业。DevTest Labs用户能够查看所有东西，并且能够连接，启动，重启以及关闭VM。

Azure还支持自定义角色，管理员可以将其分配给整个订阅里的，或者某个特定资源或资源组的用户，组或者应用程序。管理员使用JSON语法定义这些自定义的Azure角色。不管是自定义的还是预定义好的角色，都能够通过ARM web门户来定义该角色的成员。但是，管理员也可以使用PowerShell，Azure命令行接口（CLI）或者REST API来自动化大规模的指派任务。

Microsoft为如下动作提供了PowerShell cmdlet：

Get-AzureRoleAssignment：获得分配给某个用户的角色。

Get-AzureRoleDefinition:列出某个角色的Actions和NotActions

New-AzureRoleAssignment:给某个用户或者组分配角色。

Remove-AzureRoleAssignment:从用户或者组里移除角色指派

一些IT团队抱怨Azure缺乏基于角色的管理，特别是Azure Rights Management（RMS，权限管理），Office 365,、Exchange 和 SharePoint使用的预防数据损失功能。一些人错误地认为Azure要求终端用户必须是全局管理员，才能管理RMS模板。但是，Azure文档上写到，在激活RMS之后，管理员能够“使用两个默认模板，从而可以轻松地给敏感文件应用策略”来限制只有授权用户才能访问。

这两个模板带有权限策略限制，包括受保护内容的只读视图，以及受保护内容的只读或者可更改权限。如上所述，IT团队还能够为权限管理和模板创建定义自定义的角色和权限。

Azure可能并没有为每个服务都提供了企业想要的访问控制粒度。但是不管怎么说，更好地理解RBAC实现，使用并且自定义——在ARM之内并且通过自动化的PowerShell或者CLI脚本——管理员能够为广大用户及其作业需求微调Azure的安全策略。