当企业将工作迁移至云上后,企业还需要考虑如何保护资源,识别授权用户,以确保用户的访问和操作都在许可的范围内。Azure AD便是Microsoft提供的基于云上的集中控制用户对公司数据的访问权限,提供明确标识, 员工离职或供应商合同结束时,确保删除他们的访问权限的权限管理服务。

Azure Ad并非Windows server AD的云版本,且不能完全取代本地AD。但是,正在使用的Windows AD服务器可以连接到Azure AD来扩展到Azure,使用此方法可以让用户使用相同的凭据来访问本地资源和云上资源。同样,用户也可以独立使用Azure AD,将其作为唯一目录服务,以便用于控制应用程序和SaaS产品的访问。

请记住,此方法不提供完全集中的管理模型。例如,本地 Windows 计算机使用本地凭据进行身份验证。 用户可以编写应用程序以使用 Azure AD 并提供身份验证和授权,以便用户在单个位置进行管理。

目录、订阅与用户

显示 Azure 中的用户、目录和订阅的概念图。

当购买某个产品或服务时,会为其分配默认目录,即Azure AD 实例。这个目录会包含有权访问公司所购买服务的用户合租。

Azure中的订阅指一个计费实体,即虚拟机、网站、数据库等资源与每一个订阅关联,每一个订阅也包含一个账户的所有者,这个所有者需要为资源所产生的费用负责。订阅还与单个 Azure AD 目录关联。多个订阅可以信任同一个目录,但一个订阅只能信任一个目录。

可以将用户和组添加到多个订阅。这样,用户就可以创建、访问、控制订阅中的资源。将用户添加到订阅时,关联的目录必须已知晓该用户。

用户

每个访问Azure资源的用户都需要一个Azure用户账户。用户账户包含登录过程中所需的全部信息。身份验证通过后,Azure AD会生成访问令牌,以便授权对资源进行访问和操作。

Azure AD通常按照以下三种方式定义用户:

  • 云标识:这些用户仅存在于Azure AD中。例如:管理员账户和你自行管理的用户
  • 目录同步标识:这些用户存在于本地AD中。通过Azure AD connect 及逆行的同步活动会将这些用户移动到Azure中
  • 来宾用户:这些用户存在于Azure之外。例如:来自其他云供应商的账户和Mircosoft账户。即“受邀用户”

创建用户

如果添加很多用户,最好使用命令行工具,可以运行 New-AzureADUser Azure PowerShell 命令添加基于云的用户

# Create a password object
$PasswordProfile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile

# Assign the password
$PasswordProfile.Password = "<Password>"

# Create the new user
New-AzureADUser -AccountEnabled $True -DisplayName "Abby Brown" -PasswordProfile $PasswordProfile -MailNickName "AbbyB" -UserPrincipalName "AbbyB@contoso.com"

传统的命令行,可以使用Azure CLI:

az ad user create --display-name "Abby Brown" \
                  --password "<password>" \
                  --user-principal-name "AbbyB@contoso.com" \
                  --force-change-password-next-login true \
                  --mail-nickname "AbbyB"

使用命令行工具,可以通过脚本批量添加用户。最常见的使用方法是使用逗号分隔值文件(CSV)。可以手动创建,也可以从现有数据源导出。

使用CSV,需考虑一下事件:

  • 命名约定:建立或实现用于用户名、显示名称和别名的命名约定。 例如,用户名可能的形式为姓氏后跟句点 (.),然后是名字(例如,Smith.John@contoso.com)。
  • 密码:为新创建用户的初始密码实现约定。 确定新用户如何以安全性增强的方式接收密码。 常用方法是生成随机密码,然后通过电子邮件将其发送给新用户或其管理员。

配合使用 CSV与Azure PowerShell:

  1. 运行 Connect-AzureAD 命令创建与目录的 Azure PowerShell 连接。 使用对目录具有权限的管理员帐户进行连接。
  2. 为新用户创建新的密码配置文件。 新用户的密码需要符合为目录设置的密码复杂性规则。
  3. 使用 Import-CSV 导入 CSV。 需要指定 CSV 的路径和文件名。
  4. 循环浏览文件中的用户,并构造每个用户所需的用户参数。 例如,参数包括用户主体名称、显示名称、名字、部门和职务。
  5. 运行 New-AzureADUser 命令创建每个用户。 确保启用每个帐户。

Azure AD 组可以帮助组织用户,简化权限管理。资源所有者可以以组的形式分发权限。Azure AD 提供根据规则定义成员身份的功能(例如,用户就职部门或其所处职位)。

Azure AD 允许定义一下两种组:

  • 安全组:安全组是最常见的组,用于管理成员和一组用户对共享资源的计算机访问权限。使用此选项需要管理员的身份
  • Mircosoft 365 组:Office 365 组通过为成员分配对共享邮箱、日历、文件、SharePoint站点等的访问权限来提供写作机会,也可以通过此选项向组织外的人员分配对组的访问权限。用户和管理员均可使用此选项。

通过脚本创建组

可使用Azure PowerShell 通过 New-AzureADGroup命令添加组:

New-AzureADGroup -Description "Marketing" -DisplayName "Marketing" -MailEnabled $false -SecurityEnabled $true -MailNickName "Marketing"

使用角色控制资源访问

Azure AD 提供了若干内置角色,以涵盖最常见的安全性解决方案。

适用于所有资源类型的三种角色:

  • 所有者:拥有对所有资源的完全访问权限,包括将访问权限委派给其他用户的权限。
  • 参与者:可以创建和管理所有类型的Azure资源,但无法将访问权限授予其他用户。
  • 读者:可以查看现有的Azure资源

角色定义

每个角色通过JSON定义一组数据,包含可用权限(Actions)、拒绝权限(NotActions)以及范围(例如,读取访问)。

对于所有者角色,即标识所有操作(用*表示);没有拒绝的操作;以及所有范围(用/表示)

可以通过PowerShell Get-AzroleDefinition Owner cmdlet获取此信息

Get-AzRoleDefinition Owner

会生成一下输出:

Name             : Owner
Id               : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom         : False
Description      : Lets you manage everything, including access to resources.
Actions          : {*}
NotActions       : {}
DataActions      : {}
NotDataActions   : {}
AssignableScopes : {/}

角色定义

角色定义是权限的集合。角色定义列出了可以执行的操作,例如“读取”、“写入”和“删除”。它可以列出不能执行的操作或与基础数据相关的操作

如前所述,角色定义具有以下结构。

名称 说明
Id 角色的唯一标识符,由 Azure 分配。
IsCustom 如果这是一个自定义角色,则为 True;如果这是一个内置角色,则为 False。
Description 角色的可读说明。
Actions [] 允许的权限,* 表示所有权限。
NotActions [] 拒绝的权限。
DataActions [] 应用于数据的特定允许权限,例如 Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
NotDataActions [] 应用于数据的特定拒绝权限。
AssignableScopes [] 此角色适用的范围。 / 表示全局,但可以进入分层树。

在基于角色的访问控制(RBAC)或基础API中使用,此结构表示为JSON,例如下方是JSON格式的参与者角色定义。

{
  "Name": "Contributor",
  "Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
  "IsCustom": false,
  "Description": "Lets you manage everything except access to resources.",
  "Actions": [
    "*"
  ],
  "NotActions": [
    "Microsoft.Authorization/*/Delete",
    "Microsoft.Authorization/*/Write",
    "Microsoft.Authorization/elevateAccess/Action"
  ],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
    "/"
  ]
}

Action和NotActions

可以定制 ActionsNotActions 属性,以授予和拒绝所需的确切权限。 这些属性的格式始终为 {Company}.{ProviderName}/{resourceType}/{action}

例如,下面是前面介绍的三个角色的操作。

内置角色 Actions NotActions
所有者(允许执行所有操作) * -
参与者(允许执行除编写或删除角色分配之外的所有操作) * Microsoft.Authorization/*/Delete, Microsoft.Authorization/*/Write, Microsoft.Authorization/*/elevateAccess/Action
读者(允许执行所有读取操作) */read -

Actions 下的通配符 (*) 操作表示分配给此角色的主体可以执行所有操作,换句话说,此角色可以管理所有内容,其中包括将来定义的操作,因为 Azure 会添加新的资源类型。 使用“读者”角色,仅允许 read 操作。

NotActions 下的操作会从 Actions 中去除。 使用“参与者”角色,NotActions 可删除此角色管理资源访问权限以及分配资源访问权限的功能。

DataActions和NotDataActions

数据操作在 DataActionsNotDataActions 属性中指定。 可以将数据操作与管理操作分开指定。 这可防止包含通配符 (*) 的当前角色分配突然访问数据。 下面是可在 DataActionsNotDataActions 中指定的一些数据操作:

  • 读取容器中的 Blob 列表
  • 在容器中写入存储 Blob
  • 删除队列中的消息

只能将数据操作添加到 DataActionsNotDataActions 属性。 资源提供程序通过将 isDataAction 属性设置为 true 来识别哪些操作是数据操作。 没有数据操作的角色可以在角色定义中忽略这些属性。

这些操作的处理方式与其管理方式完全相同。 指定要允许的操作(* 表示全部操作),然后提供要从 NotDataActions 集合中删除的特定操作的列表。 下面是一些示例,可以在资源提供程序文档中找到操作和数据操作的完整列表

数据操作 说明
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete 删除 blob数据
Microsoft.Compute/virtualMachines/login/action 以普通用户身份登录 VM
Microsoft.EventHub/namespaces/messages/send/action 在事件中心发送消息
Microsoft.Storage/storageAccounts/fileServices/fileshares/files/read 返回文件/文件夹或文件/文件夹列表
Microsoft.Storage/storageAccounts/queueServices/queues/messages/read 从队列中读取消息

可分配范围

定义 Actions 和 NotActions 属性不足以完全实现角色。 还需要适当地确定角色的范围。

角色的 AssignableScopes 属性指定角色可供分配的范围(订阅、资源组或资源)。 可以使自定义角色仅在需要它的订阅或资源组中可供分配,从而避免影响其他订阅或资源组的用户体验。

以下是一些示例。

目标 使用范围
限制为订阅。 "/subscriptions/{sub-id}"
限制为特定订阅中的特定资源组。 "/subscriptions/{sub-id}/resourceGroups/{rg-name}"
限制为特定资源。 "/subscriptions/{sub-id}/resourceGroups/{rg-name}/{resource-name}"
使角色在两个订阅中可供分配。 "/subscriptions/{sub-id}", "/subscriptions/{sub-id}"

创建角色

Azure AD 存在内置角色,可能涵盖了想要执行的99%的操作。推荐首先使用内置角色,如有必要再创建自定义角色。

创建自定义角色需要 Azure AD Premium P1 或 P2,且无法在免费层中完成。

创建新角色可以通过以下三种机制完成:

  • Azure 门户:可以使用 Azure 门户,通过“Azure Active Directory”>“角色和管理员”>“新建自定义角色”创建自定义角色。
  • Azure PowerShell:可以使用 New-AzADMSRoleDefinition cmdlet 定义新角色。
  • Azure 图形 API: 可以使用对图形 API 的 REST 调用以编程方式创建新角色。

Azure AD Connect

用于将本地AD与Azure目录同步的免费工具

Azure AD Connect 提供了几个可供安装的组件,用于创建混合标识系统。

  • 同步服务。 此组件用于创建用户、组和其他对象。 它还可以确保本地用户和组的标识信息与云中的标识信息匹配。
  • 运行状况监视。 Azure AD Connect Health 提供强大的监视功能,可用于在 Azure 门户的中心位置查看此活动。
  • AD FS。 联合身份验证是 Azure AD Connect 的一个可选部分,可用于通过本地 AD FS 基础结构配置混合环境。 组织可以使用其来解决复杂的部署,例如域加入 SSO、强制实施 Active Directory 登录策略,以及智能卡或第三方多重身份验证。
  • 密码哈希同步。 此功能是一种登录方法,可将用户的本地 Active Directory 密码哈希与 Azure AD 同步。
  • 传递身份验证。 利用此功能,用户可以使用相同的密码登录本地应用程序和基于云的应用程序。 这可降低 IT 支持人员成本,因为用户不太可能忘记登录方式。 此功能提供了“密码哈希同步”的替代方法,可让组织强制实施其安全性和密码复杂性策略。

Azure AD 集成战略

战略 优势 劣势
云身份(纯云) 1. 对于小型组织而言,更易管理
2. 无需在本地部署和管理
3. 无需其他硬件
4. 如果用户离开公司,则更容易禁用
1. 需要额外创建云用户
2. 访问云中的工作负载时,用户将需要登陆
3. 云和本地身份的密码可能相同也可能不同
4.需要付出额外努力才能将云身份迁移至同步身份
身份同步(AAD Connect) 1. 本地密码可对本地和云进行身份验证
2. 对于小型、中型或大型组织而言,更易管理
3. 用户可以对某些资源进行单点登录(SSO)
4. Microsoft首选的同步方法
1. 由于特定的公司政策,某些客户可能不愿意将目录与云同步
联合身份(AAD Connect + ADFS) 1. 用户可以具有单点登录(SSO)
2. 如果用户被终止或离开,则可以立即禁用该账户并撤销访问权限
3. 支持无法通过同步完成的高级方案(AD和三方集成)
1. 设置和配置的更多步骤
2. 更高的维护
3. 需要其他硬件
4. 需要针对SSO进行广泛的设置
5. 如果联合服务器宕机,则将是关键的故障点,用户将无法进行身份验证