Azure Part 1

发表于 2026-03-22 分类于 Red-Team

Azure

根据维基和微软描述，Azure 是一个云计算平台，提供包括计算、分析、存储、网络、AI、身份识别与访问管理等一系列云服务。客户可以从这些服务中进行选择，以在云端开发和扩展新应用程序或运行现有应用程序。Azure 帮助企业轻松灵活地在全球范围内管理和部署应用程序。

微软云（microsoft-cloud）是所有微软云服务的统称，包括 Azure、Microsoft 365 和 Dynamics 365。Azure 特指微软云计算平台，并且整个微软云都运行在 Azure 上。

Azure 服务概述

关于Azure服务常见如下：

计算服务：虚拟机、云服务、RemoteApp、Service Fabric、容器服务和函数服务
应用服务：应用服务、API管理服务、服务总线、Mobile Engagement和IoT应用集
存储服务：关系数据库、DocumentDB、存储体、搜索服务、Redis缓存服务和Cosmos DB
分析服务：HDInsights、资料流分析、资料工厂、事件汇集器、资料湖和机器学习
网络服务：虚拟网络、高速路由专线、流量管理员和名称托管服务
身份识别与访问管理服务：Microsoft Entra ID
开发人员服务：Application Insights、Azure DevOps、Azure App Center
管理服务：调度器、自动化、营运洞察、密钥收纳库、安全中心、备份服务和站台撤销服务

服务总览如图：

RBAC

基于角色的访问控制 (RBAC) 是一种广泛使用的访问控制模型，旨在通过将主体 (Subject) 分配到预定义的角色 (Role) 来管理用户访问权限，每个角色都指定了一组权限 (Permissions)，用于控制主体在资源 (Resources) 中可以执行的操作。该模型提供了一种结构化的访问管理方法，使组织能够实施符合业务目标和安全要求的策略。

组成部分大概如下：

主体 (Subject)：用户、实体、标识、应用程序等
角色 (Role)：一组主体的集合，例如工程师、销售员、售后员
权限 (Permissions)：一组权限定义了可以对资源执行的特定操作，例如读取、删除、添加、开机等
资源 (Resources)：被操作的对象，例如容器、计算机、订阅等
角色分配 (Role Assignment)：将角色与资源关联起来的过程

Azure 使用RBAC模型实现对Azure资源进行细粒度访问管理。

我将微软云中RBAC分为三种：

Azure RBAC：控制 云资源
Microsoft Entra ID RBAC：控制 身份 & SaaS 服务
Microsoft 365下各服务 RBAC：Saas服务各自的RBAC实现

Azure RBAC

Azure RBAC管理谁有权访问 Azure 资源、他们可以对这些资源执行哪些操作以及他们可以访问哪些区域。有以下要素：

安全主体（security principal）

用户(user)、组(group)、服务主体(service principal)、托管标识(managed identity)

角色定义（role definition）

通常简称为角色，列出了可以执行的操作，例如读取、写入和删除。Azure角色分为内置（Built-in）和自定义（custom）

作用范围（scope）

范围是指访问权限所适用的资源集合，Azure 中可指定四个级别的范围：管理组（management-groups）、订阅（subscription）、资源组（resource-groups）、资源（resource）

角色分配（Role Assignment）

可以通过 Azure portal、Azure CLI、Azure PowerShell、Azure SDKs、REST APIs 进行角色分配

关于Azure RBAC的角色分配还有以下特性

角色分配对组具有传递性

重叠角色为权限的并集

Built in Role

https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles

常见Role	Description
Contributor	授予管理所有资源的完全访问权限，但不允许您在 Azure RBAC 中分配角色、在 Azure 蓝图中管理分配或共享图像库
Owner	授予管理所有资源的完全权限，包括在 Azure RBAC 中分配角色的能力
Reservations Administrator	允许用户读取和管理租户中的所有预订信息
Role Based Access Control Administrator	使用 Azure RBAC 分配角色来管理对 Azure 资源的访问。此角色不允许您使用其他方式（例如 Azure Policy）来管理访问
User Access Administrator	允许您管理用户对 Azure 资源的访问权限
Reader	查看所有资源，但不允许您进行任何更改

Entra ID RBAC

与Azure RBAC类似，但Microsoft Entra ID 中的主体/范围/定义是不同于Azure

安全主体（security principal）

用户(user)：用户是指在 Microsoft Entra ID 中拥有用户配置文件的个人

组(group)：被设可分配角色组的 Microsoft 365 组或安全组

服务主体(service principal)：为应用程序、托管服务、自动化工具访问 Microsoft Entra 资源而创建的身份

角色定义（role definition）

角色是一组权限的集合，分为内置（Built-in）和自定义（custom）

作用范围（scope）

Entra 中指定了三种类型的作用范围

Tenant
Administrative unit
Microsoft Entra resource
- Microsoft Entra groups
- Enterprise applications
- Application registrations

角色分配（Role Assignment）

可以通过 Microsoft Entra 管理中心、Microsoft Graph PowerShell 、Microsoft Graph API 进行角色分配

运行流程

用户/组/服务主体获取 Microsoft Graph endpoint的Token
用户通过 Microsoft Graph 使用token向 Microsoft Entra ID 发出 API请求
根据具体情况，Microsoft Entra ID 会执行以下操作之一：
- 根据用户access token中的 wids 声明评估用户的角色成员身份
- 检索适用于用户的所有角色分配，无论是直接分配还是通过组成员身份分配，这些角色分配都适用于正在执行操作的资源
Microsoft Entra ID 确定 API 调用中的操作是否包含在用户对此资源拥有的角色中
如果用户没有在请求的权限范围内执行该操作的角色，则不授予访问权限。否则，授予访问权限

Built in Role

常见Role	Description
Global Administrator	全局管理员，管理所有
Privileged Role Administrator	特权角色管理员，分配所有高权限角色
Global Reader	几乎读所有信息
User Administrator	用户管理员
Groups Administrator	组管理员
Application Administrator	应用管理员
Cloud Application Administrator	云应用管理员
Exchange Administrator	Exchange Online 管理员
SharePoint Administrator	SharePoint Online 管理员
Teams Administrator	Teams 管理员

365 RBAC

Microsoft 365 拥有多个基于角色的访问控制系统，即多个服务都有一套自己的RBAC

Exchange Online：https://learn.microsoft.com/en-us/exchange/permissions-exo/permissions-exo

Microsoft Intune：https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/role-based-access-control

Microsoft Purview：https://learn.microsoft.com/en-us/purview/purview-permissions

这里有常见服务的RBAC Map可以方便的查看Role和权限：Microsoft 365 Admin Center RBAC

Azure VS Entra

	Entra ID RBAC	Azure RBAC
描述	一种身份和访问管理服务，可帮助您访问内部和外部资源	一个管理用户对 Azure 资源访问权限的授权系统
重点	使用 Microsoft Graph API 控制对 Microsoft Entra 资源（例如用户、组和应用程序）的访问	使用 Azure 资源管理来控制对 Azure 资源（例如虚拟机或存储）的访问
范围	租户级别（组织范围）、管理单元、单个对象（例如，特定应用程序）指定	指定在多个级别（管理组、订阅、资源组、资源）
角色	Global Administrator、User Administrator、Billing Administrator	Owner、Contributor、Reader、User Access Administrator
角色信息	通过 Azure 门户、Microsoft Entra 管理中心、Microsoft 365 管理中心、Microsoft Graph 和 Microsoft Graph PowerShell 访问角色信息	通过 Azure 门户、CLI、PowerShell、资源管理器模板和 REST API 访问角色信息

默认情况下，Azure 角色和 Microsoft Entra 角色不能互相跨越 Azure 和 Microsoft Entra ID，但是 Global Administrator 可以开启 Access management for Azure resources 实现跨越

Entra VS 365

Microsoft 365 中包含许多不同的服务，其中一些服务拥有自己的RBAC如下：

Microsoft Entra ID
Microsoft Exchange
Microsoft Intune
Microsoft Defender for Cloud Apps
Microsoft 365 Defender portal
Compliance portal
Cost Management + Billing

一些服务没有自己的RBAC，所以它们使用 Microsoft Entra ID的角色进行管理访问，如下：

Teams
SharePoint
Managed Desktop

为了方便在 Microsoft Entra 管理中心统一管理 Microsoft 365 中身份，微软添加了一些特定于服务的内置角色，每个角色都授予对 Microsoft 365 服务的管理权限，例如Entra ID中的 Exchange Administrator，就是专门用来管理Exchange Online的，同理还有Intune Administrator, Teams Administrator, SharePoint Administrator。

针对这种情况，Microsoft Entra roles就可以分为三类：

Microsoft Entra ID-specific roles：Microsoft Entra ID特有角色
Service-specific roles in Microsoft Entra ID：Microsoft Entra ID管理服务的角色
Cross-service roles in Microsoft Entra ID：跨服务使用的角色，比如所有 Microsoft 365 服务都支持的两个角色 Global Administrator 和 Global Reader，还有关于跨安全服务的Security Administrator 和 Security Reader

Microsoft Entra ID

Microsoft Entra

Microsoft Entra 是一系列标识和网络访问产品。它允许组织实施零信任安全策略，并创建一个信任结构用于验证标识、验证访问条件、检查权限、加密连接通道以及监视泄露

Microsoft Entra admin center，是一个基于 Web 的 Microsoft Entra 产品身份门户。它为组织提供统一的管理体验，以便在一个集中位置配置和管理其 Microsoft Entra 解决方案

Entra ID

Entra ID是 Microsoft Entra 的基础产品。它是一种基于云的身份和访问管理服务，提供必要的身份、身份验证、策略和保护，以保障用户、设备、应用和资源的安全。简单说Entra ID是一个用来进行身份验证的身份管理平台，通过RBAC来控制可访问的资源

AD vs Entra ID

在2023年Azure AD，更名为 Microsoft Entra ID，以前Azure AD与Windows Server Active Directory会存在一些命名混淆，至少我在初步认识时误以为Azure AD就是云上的域，实则不然。以下是一些对比：

特性	Windows AD（Active Directory）	Entra ID
部署类型	本地部署，需要在组织的服务器上安装和维护	云部署，由 Microsoft 托管和维护
主要用途	管理本地 Windows 环境中的用户、计算机和资源，例如文件服务器、打印机和应用程序	管理云应用程序和资源的访问，例如 Microsoft 365、Azure 服务和 SaaS 应用程序
身份验证协议	Kerberos、NTLM	SAML、WS-Federation、OAuth 2.0、OpenID Connect
目录结构	基于树状结构的组织单位 (OU)	基于扁平结构的组
组策略	支持组策略对象 (GPO)，用于集中管理 Windows 设置和配置	不直接支持组策略，但可以使用 Intune 等工具实现类似功能
访问控制	基于访问控制列表 (ACL)	基于角色的访问控制 (RBAC) 和条件访问策略
单点登录 (SSO)	支持本地应用程序的 SSO，但需要额外的配置	支持云应用程序的 SSO，通常开箱即用
多重身份验证 (MFA)	支持 MFA，但需要额外的配置	支持 MFA，并且易于配置
自助服务	支持自助服务密码重置和解锁帐户，但需要额外的配置	支持自助服务密码重置、解锁帐户和注册设备，通常开箱即用
许可模式	通常作为 Windows Server 操作系统的一部分提供，需要购买 Windows Server 许可证	提供免费版和付费版，付费版P1、P2
适用场景	适用于主要使用本地 Windows 应用程序和资源的组织，或者需要严格控制本地环境的组织	适用于主要使用云应用程序和资源的组织，或者需要灵活、可扩展的身份和访问管理解决方案的组织
集成	可以与 Azure AD 集成，实现混合身份管理	可以与 Windows AD 集成，实现混合身份管理
其他功能	提供其他功能，如 DNS、DHCP 和证书服务	提供其他功能，如设备管理、应用程序代理、自助服务组管理和动态组

Entra ID Role

在Entra ID RBAC中已初步介绍

Application

在RBAC节提到了Entra ID的服务主体(Service Principal) 和scope之一的Microsoft Entra resource：

Microsoft Entra groups
Enterprise applications
Application registrations

还提及到了Entra ID认证的流程，这里简单回顾，安全主体（包括user/group/Service Principal）通过Graph获取Token，携带Token向Entra ID发起对scope的操作请求。

那么安全主体中的服务主体 (Service Principal) 是什么？以及scope中企业应用 (Enterprise applications)、应用注册 (Application registrations)是什么？以及他们之间是什么关系？

这篇文章介绍的非常详细：Understanding Microsoft Entra ID App Registrations, Enterprise Apps and Service Principals

我总结以下几点

应用初步认识

企业应用 = 服务主体，每个企业应用都是一个服务主体
服务主体始终与应用注册关联
应用注册是将一个应用注册到 Entra ID 系统中，创建新的应用注册信息，实际上只是告诉 Entra ID 这个应用模板存在，可以理解为一个声明
Entra 应用可以注册并添加到单个租户（您注册该应用的租户）、多租户（任何Entra ID租户）、多租户 + 个人帐户
应用注册的 Application(client) ID 在所有 Entra ID 租户中都是唯一的。因此一个应用注册只能存在于一个租户中
某些应用程序注册信息你将看不到，因为该程序不是你注册的，例如Graph应用就是微软注册的多租户应用程序
当在Azure门户创建应用注册时，会自动创建一个对应的企业应用程序(服务主体)
当通过powershell创建应用注册时，不会自动创建一个对应的企业应用程序(服务主体)，只会创建（注册）应用程序本身
可以通过服务主体登录 Graph PowerShell

应用的权限

注册应用程序和企业应用程序中都存在权限，分为两大类

委托权限：以 用户身份 操作，委托权限需要已登录用户，请求是以已登录用户的身份发出的，而且用于连接到Graph的应用程序必须配置并同意相应的委托权限
应用程序权限：以 应用自身身份 操作，无需用户登录即可执行操作，您需要client secret（客户端密钥）或 cert（证书）
应用注册中配置的所有权限都将是企业应用需要请求的权限

混合模式

如今，企业和公司越来越多地采用本地部署和云应用相结合的方式。用户需要同时访问本地和云端的应用，我称此场景为混合模式，本地环境 + 云环境同时存在并协同工作

混合模式
    ├── 混合身份（Entra + AD）
    ├── 混合邮件
    ├── 混合应用
    └── 混合网络

跨目录配置是指在两个不同的目录服务系统之间配置身份。跨目录配置最常见的场景是将本地 Active Directory 中的用户配置到 Microsoft Entra ID 中，实现混合身份环境。这里进行简单介绍

同步方法

Entra ID提供了三种实现目录间配置的方法：

Microsoft Entra Connect：AD 到 Entra 的主流同步方案
Microsoft Entra Cloud Sync：提供了一种轻量级的基于代理的方法，它将取代 Microsoft Entra Connect
Microsoft Identity Manager (MIM) ：提供高级目录间配置功能

认证方式

Microsoft Entra Connect 提供了如下核心功能实现身份认证

密码哈希同步 (Password Hash Synchronization, PHS)：将本地 AD 用户密码的哈希同步到 Microsoft Entra ID
传递身份验证 (Pass-through Authentication, PTA)：允许用户在本地和云端使用相同密码，无需额外的联合环境基础设施
联合身份验证集成 (Federation integration)：可用于配置使用本地 ADFS 基础架构的混合环境

交互

MSOnline Powershell：偏向Office 365

AzureAD Powershell：常规AzureAD模块

Microsoft 365

Office 365 和 Microsoft 365 区别

Office 365 是基于云的商业一系列应用程序，包含了Word、Excel、Outlook、PowerPoint、OneDrive、Teams、Exchange Online、SharePoint Online、Entra ID等

Microsoft 365 是一项订阅服务，提供一套 Microsoft 的生产力工具和基于云的服务，包含了 Office 365 加 Windows 10/11 操作系统和企业移动套件等，不同订阅解锁的服务工具各不同

Exchange Online

Microsoft Exchange Online是一个基于云的消息平台，提供电子邮件、日历、联系人和任务管理功能。本地域环境中的Exchange Server是在本地机器搭建的服务，而Online是微软提供的云服务，也称邮箱上云。

当公司/组织注册了商业版、企业版订阅时，即可使用Exchange Online，也可以购买独立的 Exchange Online 计划。用户可以使用 Outlook、Outlook 网页版或 Outlook 移动应用等应用程序连接到 Exchange Online。

组织管理员管理Exchange Online时可通过两种方式

Microsoft 365 管理中心：使用管理员权限登录Microsoft 365 管理中心 https://admin.microsoft.com/ ，在导航中选择Exchange
Exchange 管理中心 (EAC) ：https://admin.exchange.microsoft.com

Outlook

Outlook既是客户端应用程序的名称，也是微软基础邮件托管服务的名称。

作为基础邮件托管服务来说，它提供了一个类似Gmail的邮箱服务，可以让用户注册一个@outlook.com的邮箱
作为客户端应用程序来说，它有桌面版、web页面、移动端。通过客户端登录，可以连接到Exchange Online、Exchange Server、微软邮箱托管服务，简而言之，Outlook是一个前端入口用来连接邮箱后端服务

Microsoft Graph

是通往 Microsoft 云服务（如 Microsoft Entra 和 Microsoft 365）中的数据和智能的门户，通过Microsoft Graph 公开的 REST API 和客户端库，可以访问众多Microsoft 云服务上的数据。简单来说，就是拿着你的Token通过API去获取、操作服务数据等