Az - 基本信息

Tip

学习和实践 AWS 黑客技术：HackTricks Training AWS Red Team Expert (ARTE)
学习和实践 GCP 黑客技术：HackTricks Training GCP Red Team Expert (GRTE) 学习和实践 Azure 黑客技术：HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

查看 订阅计划!

加入 💬 Discord 群组 或 Telegram 群组 或在 Twitter 🐦 上关注我们 @hacktricks_live.

通过向 HackTricks 和 HackTricks Cloud GitHub 仓库提交 PR 来分享黑客技巧。

组织层级

https://www.tunecom.be/stg_ba12f/wp-content/uploads/2020/01/VDC-Governance-ManagementGroups-1536x716.png

管理组

它可以包含其他管理组或订阅。
这允许在管理组级别应用治理控制，如RBAC和Azure Policy，并使其继承到组内的所有订阅。
单个目录最多可以支持10,000个管理组。
管理组树可以支持最多六个层级的深度。此限制不包括根级别或订阅级别。
每个管理组和订阅只能支持一个父级。
即使可以创建多个管理组，根管理组只有一个。
根管理组包含所有其他管理组和订阅，并且无法移动或删除**。
单个管理组内的所有订阅必须信任相同的Entra ID租户。

https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png

Azure 订阅

这是另一个逻辑容器，资源（虚拟机、数据库等）可以在其中运行并计费。
它的父级始终是管理组（可以是根管理组），因为订阅不能包含其他订阅。
它仅信任一个Entra ID目录。
在订阅级别（或其任何父级）应用的权限会继承到订阅内的所有资源。

资源组

来自文档：资源组是一个容器，用于保存Azure解决方案的相关资源。资源组可以包括解决方案的所有资源，或仅包括您希望作为一组管理的资源。通常，将共享相同生命周期的资源添加到同一资源组，以便您可以轻松地作为一组进行部署、更新和删除。

所有的资源必须在资源组内，并且只能属于一个组，如果资源组被删除，组内的所有资源也会被删除。

https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&ssl=1

Azure 资源 ID

Azure 中的每个资源都有一个 Azure 资源 ID 来标识它。

Azure 资源 ID 的格式如下：

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}

对于在订阅 ID 12345678-1234-1234-1234-123456789012 下的资源组 myResourceGroup 中名为 myVM 的虚拟机，Azure 资源 ID 看起来像这样：

/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM

Azure vs Entra ID vs Azure AD 域服务

Azure

Azure 是微软的综合云计算平台，提供广泛的服务，包括虚拟机、数据库、人工智能和存储。它作为托管和管理应用程序、构建可扩展基础设施以及在云中运行现代工作负载的基础。Azure 为开发人员和 IT 专业人员提供工具，以无缝创建、部署和管理应用程序和服务，满足从初创企业到大型企业的各种需求。

Entra ID（前称 Azure Active Directory）

Entra ID 是一个基于云的身份和访问管理服务，旨在处理身份验证、授权和用户访问控制。它为 Microsoft 服务（如 Office 365、Azure 和许多第三方 SaaS 应用程序）提供安全访问。具有单点登录（SSO）、多因素身份验证（MFA）和条件访问策略等功能。

Entra 域服务（前称 Azure AD DS）

Entra 域服务通过提供与传统 Windows Active Directory 环境兼容的托管域服务扩展了 Entra ID 的功能。它支持 LDAP、Kerberos 和 NTLM 等遗留协议，允许组织在云中迁移或运行旧应用程序，而无需部署本地域控制器。此服务还支持组策略以进行集中管理，使其适合需要与现代云环境共存的遗留或基于 AD 的工作负载场景。

Entra ID 主体

用户

新用户
指定所选租户的电子邮件名称和域
指定显示名称
指定密码
指定属性（名字、职位、联系信息等）
默认用户类型为“成员”
外部用户
指定邀请的电子邮件和显示名称（可以是非微软电子邮件）
指定属性
默认用户类型为“访客”

成员和访客默认权限

您可以在 https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions 中查看它们，但成员可以执行的其他操作包括：

读取所有用户、组、应用程序、设备、角色、订阅及其公共属性
邀请访客（可以关闭）
创建安全组
读取非隐藏的组成员资格
将访客添加到拥有的组
创建新应用程序（可以关闭）
将最多 50 个设备添加到 Azure（可以关闭）

Note

请记住，要枚举 Azure 资源，用户需要明确授予权限。

用户默认可配置权限

成员（文档）
注册应用程序：默认是
限制非管理员用户创建租户：默认否
创建安全组：默认是
限制访问 Microsoft Entra 管理门户：默认否
这不会限制对门户的 API 访问（仅限网页）
允许用户将工作或学校帐户与 LinkedIn 连接：默认是
显示保持用户登录：默认是
限制用户恢复其拥有设备的 BitLocker 密钥：默认否（请在设备设置中检查）
读取其他用户：默认是（通过 Microsoft Graph）
访客
访客用户访问限制选项：
访客用户与成员具有相同的访问权限。
访客用户对目录对象的属性和成员资格的访问有限（默认）。这限制了访客访问仅限于他们自己的用户资料。对其他用户和组信息的访问不再允许。
访客用户访问限制为仅限于其自己目录对象的属性和成员资格是最严格的。
访客可以邀请选项：
组织中的任何人都可以邀请访客用户，包括访客和非管理员（最具包容性） - 默认
成员用户和分配给特定管理员角色的用户可以邀请访客用户，包括具有成员权限的访客
只有分配给特定管理员角色的用户可以邀请访客用户
组织中的任何人都不能邀请访客用户，包括管理员（最严格）
外部用户离开：默认为真
允许外部用户离开组织

Tip

即使默认受到限制，具有授予权限的用户（成员和访客）仍可以执行上述操作。

组

有2种类型的组：

安全组：此类型的组用于授予成员对应用程序、资源的访问权限并分配许可证。用户、设备、服务主体和其他组可以是成员。
Microsoft 365 组：此类型的组用于协作，给予成员对共享邮箱、日历、文件、SharePoint 站点等的访问权限。组成员只能是用户。
这将具有 EntraID 租户的电子邮件地址。

有2种类型的成员资格：

分配：允许手动将特定成员添加到组。
动态成员资格：使用规则自动管理成员资格，当成员属性更改时更新组的包含。

服务主体

服务主体是为应用程序、托管服务和自动化工具访问 Azure 资源而创建的身份。此访问权限由分配给服务主体的角色限制，使您能够控制可以访问哪些资源以及访问的级别。出于安全原因，始终建议使用服务主体与自动化工具，而不是允许它们使用用户身份登录。

可以通过生成密钥（密码）、证书或授予对第三方平台（例如 GitHub Actions）的联合访问来直接以服务主体身份登录。

如果选择密码身份验证（默认），请保存生成的密码，因为您将无法再次访问它。
如果选择证书身份验证，请确保应用程序将能够访问私钥。

应用注册

应用注册是一个配置，允许应用程序与 Entra ID 集成并执行操作。

关键组件：

应用程序 ID（客户端 ID）： 您的应用在 Azure AD 中的唯一标识符。
重定向 URI： Azure AD 发送身份验证响应的 URL。
证书、密钥和联合凭据： 可以生成密钥或证书以作为应用程序的服务主体登录，或授予对其的联合访问（例如 GitHub Actions）。
如果生成了证书或密钥，则可以通过知道应用程序 ID、密钥或证书以及租户（域或 ID）来以服务主体身份登录。
API 权限： 指定应用可以访问的资源或 API。
身份验证设置： 定义应用支持的身份验证流程（例如，OAuth2、OpenID Connect）。
服务主体：创建应用时会创建服务主体（如果是从 Web 控制台创建）或在新租户中安装时创建。
服务主体将获得其配置的所有请求权限。

默认同意权限

用户对应用程序的同意

不允许用户同意
所有应用程序都需要管理员批准。
允许用户对来自经过验证的发布者、内部应用程序和仅请求选定权限的应用程序进行同意（推荐）
所有用户可以同意仅请求被分类为“低影响”的权限、来自经过验证的发布者的应用程序和在租户中注册的应用程序。
默认低影响权限（尽管您需要接受将其添加为低影响）：
User.Read - 登录并读取用户资料
offline_access - 保持对用户已授予访问权限的数据的访问
openid - 登录用户
profile - 查看用户的基本资料
email - 查看用户的电子邮件地址
允许用户对应用程序进行同意（默认）
所有用户可以同意任何应用程序访问组织的数据。

管理员同意请求：默认否

用户可以请求管理员同意他们无法同意的应用程序
如果是：可以指示可以同意请求的用户、组和角色
还可以配置用户是否会收到电子邮件通知和到期提醒

托管身份（元数据）

Azure Active Directory 中的托管身份提供了一种自动管理应用程序身份的解决方案。这些身份由应用程序用于连接到与 Azure Active Directory（Azure AD）身份验证兼容的资源。这允许消除在代码中硬编码云凭据的需要，因为应用程序将能够联系元数据服务以获取有效令牌，以作为指定的托管身份执行操作。

有两种类型的托管身份：

系统分配。某些 Azure 服务允许您直接在服务实例上启用托管身份。当您启用系统分配的托管身份时，会在资源所在的订阅中创建一个服务主体，该订阅信任 Entra ID 租户。当资源被删除时，Azure 会自动为您删除该身份。
用户分配。用户也可以生成托管身份。这些身份是在订阅内的资源组中创建的，并且将在 EntraID 中创建一个服务主体，该主体由订阅信任。然后，您可以将托管身份分配给一个或多个实例的 Azure 服务（多个资源）。对于用户分配的托管身份，身份与使用它的资源是分开管理的。

托管身份不会生成永久凭据（如密码或证书）以访问与其关联的服务主体。

企业应用程序

这只是一个在 Azure 中过滤服务主体并检查已分配给的应用程序的表。

这不是另一种“应用程序”，在 Azure 中没有任何对象是“企业应用程序”，这只是检查服务主体、应用注册和托管身份的抽象。

管理单位

管理单位允许从角色中授予对组织特定部分的权限。

示例：

场景：一家公司希望区域 IT 管理员仅管理自己区域的用户。
实施：
为每个区域创建管理单位（例如，“北美 AU”、“欧洲 AU”）。
用来自各自区域的用户填充 AU。
AU 可以包含用户、组或设备
AU 支持动态成员资格
AU 不能包含 AU
分配管理员角色：
将“用户管理员”角色授予区域 IT 员工，范围限制在其区域的 AU。
结果：区域 IT 管理员可以管理其区域内的用户帐户，而不会影响其他区域。

Entra ID 角色和权限

为了管理 Entra ID，有一些内置角色可以分配给 Entra ID 主体以管理 Entra ID
在 https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference 中查看角色
EntraID 标记为**PRIVILEGED**的角色应谨慎分配，因为正如微软在文档中所解释的那样：https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference：特权角色分配如果未以安全和预期的方式使用，可能会导致权限提升。
权限最高的角色是全局管理员
角色组细化权限，可以在其描述中找到。
可以创建自定义角色，以获得所需的权限。尽管由于某种原因，并非所有细化权限都可供管理员创建自定义角色。
Entra ID 中的角色与 Azure 中的角色完全独立。唯一的关系是，具有 Entra ID 中全局管理员角色的主体可以提升为 Azure 中的用户访问管理员角色。
在 Entra ID 角色中不可能使用通配符。

Azure 角色和权限

角色被分配给主体，并具有范围：principal -[HAS ROLE]->(scope)
分配给组的角色会被组内的所有成员继承。
根据角色分配的范围，角色可能会继承到范围容器内的其他资源。例如，如果用户 A 在订阅上具有角色，他将在该订阅内的所有资源组和资源组内的所有资源上拥有该角色。

内置角色

来自文档：Azure 基于角色的访问控制（Azure RBAC）有几个 Azure 内置角色，您可以将其分配给用户、组、服务主体和托管身份。角色分配是您控制对 Azure 资源的访问的方式。如果内置角色无法满足您组织的特定需求，您可以创建自己的 Azure 自定义角色。

内置角色仅适用于它们所针对的资源，例如检查这两个内置角色在计算资源上的示例：

磁盘备份读取器	提供备份库执行磁盘备份的权限。	3e5e47e6-65f7-47ef-90b5-e5dd4d455f24
虚拟机用户登录	在门户中查看虚拟机并以常规用户身份登录。	fb879df8-f326-4884-b1cf-06f3ad86be52

这些角色也可以分配给逻辑容器（如管理组、订阅和资源组），受影响的主体将在这些容器内的资源上拥有它们。

在这里找到 所有 Azure 内置角色 的列表。
在这里找到 所有 Entra ID 内置角色 的列表。

自定义角色

也可以创建 自定义角色
它们是在一个范围内创建的，尽管一个角色可以在多个范围内（管理组、订阅和资源组）
可以配置自定义角色将具有的所有细化权限
可以排除权限
拥有排除权限的主体即使在其他地方授予权限也无法使用该权限
可以使用通配符
使用的格式是 JSON
actions 指的是对资源进行管理操作的权限，例如创建、更新或删除资源定义和设置。
dataActions 是对资源内数据操作的权限，允许您读取、写入或删除资源中包含的实际数据。
notActions 和 notDataActions 用于从角色中排除特定权限。但是，它们不会拒绝这些权限，如果其他角色授予它们，主体将拥有这些权限。
assignableScopes 是可以分配角色的范围数组（如管理组、订阅或资源组）。

自定义角色的权限 JSON 示例：

{
"properties": {
"roleName": "",
"description": "",
"assignableScopes": ["/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f"],
"permissions": [
{
"actions": [
"Microsoft.DigitalTwins/register/action",
"Microsoft.DigitalTwins/unregister/action",
"Microsoft.DigitalTwins/operations/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/read",
"Microsoft.DigitalTwins/digitalTwinsInstances/write",
"Microsoft.CostManagement/exports/*"
],
"notActions": [
"Astronomer.Astro/register/action",
"Astronomer.Astro/unregister/action",
"Astronomer.Astro/operations/read",
"Astronomer.Astro/organizations/read"
],
"dataActions": [],
"notDataActions": []
}
]
}
}

权限顺序

为了让一个 主体对资源有某种访问权限，他需要被授予一个明确的角色（以任何方式）授予他该权限。
明确的 拒绝分配优先于 授予权限的角色。

https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10

全局管理员

全局管理员是 Entra ID 的一个角色，授予 对 Entra ID 租户的完全控制。然而，它默认不授予对 Azure 资源的任何权限。

拥有全局管理员角色的用户可以在根管理组中 ‘提升’ 为用户访问管理员 Azure 角色。因此，全局管理员可以管理 所有 Azure 订阅和管理组的访问。
此提升可以在页面底部完成：https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties

分配条件与 MFA

根据文档：目前，可以将条件添加到具有 Blob 存储数据操作或队列存储数据操作 的内置或自定义角色分配中。

拒绝分配

与角色分配一样，拒绝分配 用于 控制对 Azure 资源的访问。然而，拒绝分配 用于 明确拒绝对资源的访问，即使用户通过角色分配获得了访问权限。拒绝分配 优先于 角色分配，这意味着如果用户通过角色分配获得了访问权限，但也通过拒绝分配被明确拒绝访问，则拒绝分配将优先。

与角色分配一样，拒绝分配 应用于某个范围，指示受影响的主体和被拒绝的权限。此外，在拒绝分配的情况下，可以 防止拒绝被子资源继承。

Azure 策略

Azure 策略 是帮助组织确保其资源符合特定标准和合规要求的规则。它们允许您 强制执行或审核 Azure 中资源的设置。例如，您可以防止在未经授权的区域创建虚拟机，或确保所有资源都有特定的标签以便跟踪。

Azure 策略是 主动的：它们可以阻止不合规资源的创建或更改。它们也是 反应性的，允许您查找并修复现有的不合规资源。

关键概念

策略定义：以 JSON 编写的规则，指定允许或要求的内容。
策略分配：将策略应用于特定范围（例如，订阅、资源组）。
倡议：一组政策的集合，用于更广泛的执行。
效果：指定当策略被触发时发生的事情（例如，“拒绝”、“审核”或“附加”）。

一些示例：

确保符合特定 Azure 区域的合规性：此策略确保所有资源在特定 Azure 区域部署。例如，一家公司可能希望确保其所有数据存储在欧洲以符合 GDPR。
强制命名标准：策略可以强制 Azure 资源的命名约定。这有助于根据名称组织和轻松识别资源，这在大型环境中非常有用。
限制某些资源类型：此策略可以限制某些类型资源的创建。例如，可以设置策略以防止创建某些虚拟机大小等昂贵资源类型，以控制成本。
强制标签策略：标签是与 Azure 资源关联的键值对，用于资源管理。策略可以强制要求所有资源必须存在某些标签，或具有特定值。这对于成本跟踪、所有权或资源分类非常有用。
限制对资源的公共访问：策略可以强制某些资源（如存储帐户或数据库）没有公共端点，确保它们仅在组织的网络内可访问。
自动应用安全设置：策略可以用于自动将安全设置应用于资源，例如将特定的网络安全组应用于所有虚拟机或确保所有存储帐户使用加密。

请注意，Azure 策略可以附加到 Azure 层次结构的任何级别，但它们 通常用于根管理组 或其他管理组。

Azure 策略 JSON 示例：

{
"policyRule": {
"if": {
"field": "location",
"notIn": ["eastus", "westus"]
},
"then": {
"effect": "Deny"
}
},
"parameters": {},
"displayName": "Allow resources only in East US and West US",
"description": "This policy ensures that resources can only be created in East US or West US.",
"mode": "All"
}