Az - Basic Information
Last updated
Last updated
学习和实践 AWS 黑客技术：HackTricks 培训 AWS 红队专家 (ARTE) 学习和实践 GCP 黑客技术：HackTricks 培训 GCP 红队专家 (GRTE)
它可以包含 其他管理组或订阅。
这允许在管理组级别 应用治理控制，如 RBAC 和 Azure 策略，并让所有组内的订阅 继承。
单个目录中可以支持 10,000 个管理组。
管理组树可以支持 最多六个层级的深度。此限制不包括根级别或订阅级别。
每个管理组和订阅只能支持 一个父级。
即使可以创建多个管理组，也只有一个根管理组。
根管理组 包含 所有 其他管理组和订阅，并且 无法移动或删除。
单个管理组内的所有订阅必须信任 相同的 Entra ID 租户。
这是另一个 逻辑容器，资源（虚拟机、数据库等）可以在其中运行并计费。
它的 父级 始终是 管理组（可以是根管理组），因为订阅不能包含其他订阅。
它 仅信任一个 Entra ID 目录。
在订阅级别（或其任何父级）应用的 权限 会 继承 到订阅内的所有资源。
来自文档： 资源组是一个 容器，用于保存 Azure 解决方案的 相关资源。资源组可以包括解决方案的所有资源，或仅包括您希望作为一组管理的 资源。通常，将 共享相同生命周期 的 资源 添加到同一资源组，以便您可以轻松地作为一组进行部署、更新和删除。
所有 资源 必须 在资源组内，并且只能属于一个组，如果资源组被删除，组内的所有资源也会被删除。
Azure 中的每个资源都有一个 Azure 资源 ID 来标识它。
Azure 资源 ID 的格式如下：
/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}
对于名为 myVM 的虚拟机，在订阅 ID 为 12345678-1234-1234-1234-123456789012 的资源组 myResourceGroup 下，Azure 资源 ID 看起来像这样：
/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM
Azure 是微软的综合 云计算平台，提供广泛的服务，包括虚拟机、数据库、人工智能和存储。它作为托管和管理应用程序、构建可扩展基础设施以及在云中运行现代工作负载的基础。Azure 为开发人员和 IT 专业人员提供工具，以无缝创建、部署和管理应用程序和服务，满足从初创企业到大型企业的各种需求。
Entra ID 是一个基于云的 身份和访问管理服务，旨在处理身份验证、授权和用户访问控制。它为 Microsoft 服务（如 Office 365、Azure 和许多第三方 SaaS 应用程序）提供安全访问。具有单点登录（SSO）、多因素身份验证（MFA）和条件访问策略等功能。
Entra 域服务通过提供 与传统 Windows Active Directory 环境兼容的托管域服务 扩展了 Entra ID 的功能。它支持 LDAP、Kerberos 和 NTLM 等遗留协议，允许组织在云中迁移或运行旧应用程序，而无需部署本地域控制器。此服务还支持组策略以进行集中管理，使其适合需要与现代云环境共存的遗留或基于 AD 的工作负载场景。
新用户
指定所选租户的电子邮件名称和域
指定显示名称
指定密码
指定属性（名字、职位、联系信息等）
默认用户类型为“成员”
外部用户
指定邀请的电子邮件和显示名称（可以是非微软电子邮件）
指定属性
默认用户类型为“访客”
您可以在 https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions 中查看它们，但成员可以执行的其他操作包括：
读取所有用户、组、应用程序、设备、角色、订阅及其公共属性
邀请访客（可以关闭）
创建安全组
读取非隐藏的组成员资格
将访客添加到拥有的组
创建新应用程序（可以关闭）
将最多 50 个设备添加到 Azure（可以关闭）
请记住，要枚举 Azure 资源，用户需要明确授予权限。
成员（文档）
注册应用程序：默认 是
限制非管理员用户创建租户：默认 否
创建安全组：默认 是
限制访问 Microsoft Entra 管理门户：默认 否
这不会限制对门户的 API 访问（仅限网页）
允许用户将工作或学校帐户与 LinkedIn 连接：默认 是
显示保持用户登录：默认 是
限制用户恢复其拥有设备的 BitLocker 密钥：默认否（请在设备设置中检查）
读取其他用户：默认 是（通过 Microsoft Graph）
访客
访客用户访问限制
访客用户与成员 的访问权限相同，默认情况下将所有成员用户权限授予访客用户。
访客用户对目录对象的属性和成员资格的访问有限（默认） 默认情况下限制访客访问仅限于他们自己的用户配置文件。 不再允许访问其他用户和组信息。
访客用户访问限制在其自己的目录对象的属性和成员资格 是最严格的。
访客可以邀请
组织中的任何人都可以邀请访客用户，包括访客和非管理员（最包容） - 默认
成员用户和分配给特定管理员角色的用户可以邀请访客用户，包括具有成员权限的访客
只有分配给特定管理员角色的用户可以邀请访客用户
组织中的任何人都不能邀请访客用户，包括管理员（最严格）
外部用户离开：默认 是
允许外部用户离开组织
即使默认受到限制，具有授予权限的用户（成员和访客）仍可以执行上述操作。
有 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 服务允许您 直接在服务实例上启用托管身份。当您启用系统分配的托管身份时，会在资源所在的订阅中创建一个 服务主体，该订阅受信任。 当 资源 被 删除 时，Azure 会自动为您 删除 该 身份。
用户分配。用户也可以生成托管身份。这些是在订阅内的资源组中创建的，并且将在 EntraID 中创建一个受信任的服务主体。然后，您可以将托管身份分配给一个或 多个 Azure 服务实例（多个资源）。对于用户分配的托管身份，身份与使用它的资源是分开管理的。
托管身份 不会生成永久凭据（如密码或证书）以访问与其关联的服务主体。
这只是一个 Azure 中的表，用于过滤服务主体 并检查已分配给的应用程序。
这不是另一种“应用程序”类型， Azure 中没有任何对象是“企业应用程序”，这只是检查服务主体、应用注册和托管身份的抽象。
管理单位允许 从角色中授予对组织特定部分的权限。
示例：
场景：一家公司希望区域 IT 管理员仅管理自己区域的用户。
实施：
为每个区域创建管理单位（例如，“北美 AU”、“欧洲 AU”）。
用来自各自区域的用户填充 AU。
AU 可以 包含用户、组或设备
AU 支持 动态成员资格
AU 不能包含 AU
分配管理员角色：
将“用户管理员”角色授予区域 IT 员工，范围限制在其区域的 AU。
结果：区域 IT 管理员可以管理其区域内的用户帐户，而不会影响其他区域。
为了管理 Entra ID，有一些 内置角色 可以分配给 Entra ID 主体以管理 Entra ID
权限最高的角色是 全局管理员
在角色描述中可以看到其 细粒度权限
角色 是 分配 给 主体 的 范围： 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 是对对象内数据的权限
自定义角色的权限 JSON 示例：
为了让一个 主体对资源有某些访问权限，他需要被明确授予一个角色（以任何方式）授予他该权限。
明确的 拒绝角色分配优先于 授予权限的角色。
全局管理员是 Entra ID 的一个角色，授予 对 Entra ID 租户的完全控制。然而，它默认不授予对 Azure 资源的任何权限。
拥有全局管理员角色的用户可以在根管理组中 '提升' 为用户访问管理员 Azure 角色。因此，全局管理员可以管理 所有 Azure 订阅和管理组的访问。 此提升可以在页面底部完成：https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Azure 策略 是帮助组织确保其资源符合特定标准和合规要求的规则。它们允许您 强制执行或审核 Azure 中资源的设置。例如，您可以防止在未经授权的区域创建虚拟机，或确保所有资源都有特定标签以便跟踪。
Azure 策略是 主动的：它们可以阻止不合规资源的创建或更改。它们也是 反应性的，允许您查找并修复现有的不合规资源。
策略定义：以 JSON 编写的规则，指定允许或要求的内容。
策略分配：将策略应用于特定范围（例如，订阅、资源组）。
倡议：一组政策的集合，用于更广泛的执行。
效果：指定当策略被触发时发生的事情（例如，“拒绝”、“审核”或“附加”）。
一些示例：
确保符合特定 Azure 区域的合规性：此策略确保所有资源在特定 Azure 区域部署。例如，一家公司可能希望确保其所有数据存储在欧洲以符合 GDPR 合规性。
强制命名标准：策略可以强制 Azure 资源的命名约定。这有助于根据名称组织和轻松识别资源，这在大型环境中非常有用。
限制某些资源类型：此策略可以限制某些类型资源的创建。例如，可以设置策略以防止创建某些 VM 大小等昂贵资源类型，以控制成本。
强制标签策略：标签是与 Azure 资源关联的键值对，用于资源管理。策略可以强制要求所有资源必须存在某些标签，或具有特定值。这对于成本跟踪、所有权或资源分类非常有用。
限制对资源的公共访问：策略可以强制某些资源（如存储帐户或数据库）没有公共端点，确保它们仅在组织的网络内可访问。
自动应用安全设置：策略可以用于自动将安全设置应用于资源，例如将特定网络安全组应用于所有 VM，或确保所有存储帐户使用加密。
请注意，Azure 策略可以附加到 Azure 层次结构的任何级别，但它们 通常用于根管理组 或其他管理组。
Azure 策略 JSON 示例：
在 Azure 权限可以分配给层级的任何部分。这包括管理组、订阅、资源组和单个资源。权限由分配它们的实体的包含 资源 继承。
这种层级结构允许高效和可扩展的访问权限管理。
RBAC（基于角色的访问控制）是我们在前面的部分中已经看到的内容：将角色分配给主体以授予其对资源的访问权限。 然而，在某些情况下，您可能希望提供 更细粒度的访问管理 或 简化 数百个 角色 分配 的管理。
Azure ABAC（基于属性的访问控制）在 Azure RBAC 的基础上，通过在特定操作的上下文中添加 基于属性的角色分配条件 来构建。角色分配条件 是您可以选择性地添加到角色分配中的 额外检查，以提供更细粒度的访问控制。条件过滤作为角色定义和角色分配一部分授予的权限。例如，您可以 添加一个条件，要求对象具有特定标签才能读取该对象。 您 不能 明确 拒绝 对特定资源的访问 使用条件。
学习与实践 AWS 黑客技术：HackTricks 培训 AWS 红队专家 (ARTE) 学习与实践 GCP 黑客技术： HackTricks 培训 GCP 红队专家 (GRTE)
