Az - Basic Information
组织层级
管理组
如果您的组织有 多个 Azure 订阅，您可能需要一种有效的方式来 管理访问、政策和合规性。管理组提供了一个 高于订阅的治理范围。
请注意，单个目录中可以支持 10,000 个管理组，并且管理组树可以支持 最多六个层级的深度。
来自文档：每个目录都有一个 顶级管理组，称为根管理组。根管理组内置于层级中，以便 所有管理组和订阅都归入其中。此根管理组允许在目录级别应用 全局政策和 Azure 角色分配。 Azure AD 全局管理员需要提升自己 为此根组的 用户访问管理员角色。提升访问后，管理员可以 将任何 Azure 角色分配给其他目录用户或组以管理层级。作为管理员，您可以将 自己的帐户分配为根管理组的所有者。
根管理组 不能被移动或删除，与其他管理组不同。
管理组为您提供企业级的规模管理，无论您可能拥有何种类型的订阅。然而，单个管理组内的所有订阅必须信任 相同的 Azure Active Directory (Azure AD) 租户。
Azure 订阅
在 Azure 中，订阅作为 逻辑容器 用于 配置 业务或技术 资源。此容器维护 资源的详细信息，例如虚拟机 (VM)、数据库等。在创建 Azure 资源（如 VM）时，指定与之 关联的订阅。此结构便于访问的委派，利用基于角色的访问控制机制。
资源组
来自文档： 资源组是一个 容器，用于保存 Azure 解决方案的 相关资源。资源组可以包括解决方案的所有资源，或仅包括您希望作为一组管理的 资源。通常，将 共享相同生命周期 的 资源 添加到同一资源组，以便您可以轻松地作为一组进行部署、更新和删除。
所有的 资源 必须 在资源组内，并且只能属于一个组，如果删除资源组，则其中的所有资源也会被删除。
管理单位
来自文档： 管理单位允许您 细分 组织为 任何单位，然后 分配特定管理员，使其 仅管理该单位的成员。例如，您可以使用管理单位将权限委派给大型大学每个学院的管理员，以便他们可以控制访问、管理用户并仅在工程学院设置政策。
只有 用户、组 和 设备 可以成为 管理单位 的 成员。
因此，一个 管理单位 将 包含 一些 成员，其他 主体 将被 分配权限 以管理该管理 单位 的成员。
Azure 与 Azure AD 与 Azure AD 域服务
重要的是要注意 Azure AD 是 Azure 内部的一个服务。Azure 是微软的 云平台，而 Azure AD 是 Azure 中的企业 身份 服务。 此外，Azure AD 与 Windows Active Directory 不同，它是一种以完全不同方式工作的身份服务。如果您想在 Azure 中为 Windows Active Directory 环境运行 域控制器，则需要使用 Azure AD 域服务。
主体
Azure 支持不同类型的主体：
用户：具有访问凭据的普通 人。
组：一起管理的 主体组。授予组的 权限 会被 成员继承。
服务主体/企业应用：为 应用、托管服务和自动化工具访问 Azure 资源而创建的 身份。此访问受 分配给服务主体的角色 限制，使您能够控制 可以访问哪些资源 以及访问级别。出于安全原因，始终建议 使用服务主体与自动化工具，而不是允许它们使用用户身份登录。
创建 服务主体 时，您可以选择 密码身份验证 或 证书身份验证。
如果选择 密码 身份验证（默认），请 保存生成的密码，因为您将无法再次访问它。
如果选择证书身份验证，请确保 应用程序将能够访问私钥。
托管身份 (元数据凭据)：Azure Active Directory 中的托管身份提供了一种 自动管理应用程序身份 的解决方案。这些身份由应用程序用于 连接 到与 Azure Active Directory (Azure AD) 身份验证兼容的 资源。通过利用托管身份，应用程序可以 安全地获取 Azure AD 令牌，同时消除直接处理凭据的需要。托管身份有两种类型：
系统分配。某些 Azure 服务允许您 直接在服务实例上启用托管身份。启用系统分配的托管身份时，会在 Azure AD 中创建一个身份。该身份与 该服务实例的生命周期 相关联。当 资源 被 删除 时，Azure 会自动为您 删除 该 身份。按设计，只有该 Azure 资源可以使用此身份请求 Azure AD 的令牌。
用户分配。您还可以将托管身份作为独立的 Azure 资源创建。您可以 创建用户分配的托管身份 并将其分配给一个或 多个实例 的 Azure 服务（多个资源）。对于用户分配的托管身份，身份与使用它的资源分开管理。
角色与权限
角色 在 范围 上分配给 主体： principal -[HAS ROLE]->(scope)
分配给 组 的 角色 会被组内所有 成员继承。
根据角色分配的范围，角色 可能会被 继承 到范围容器内的 其他资源。例如，如果用户 A 在订阅上有一个 角色，他将在该订阅内的所有资源组和 所有资源 上拥有该 角色。
经典角色
内置角色
来自文档：Azure 基于角色的访问控制 (Azure RBAC) 有几个 Azure 内置角色，您可以 分配 给 用户、组、服务主体和托管身份。角色分配是您控制 对 Azure 资源的访问 的方式。如果内置角色不满足您组织的特定需求，您可以创建自己的 Azure 自定义角色.
内置 角色仅适用于 它们所针对的资源，例如检查这两个 内置角色 在计算资源上的示例：
这些角色也可以 分配给逻辑容器（例如管理组、订阅和资源组），受影响的主体将在 这些容器内的资源上 拥有它们。
在这里找到 所有 Azure 内置角色 的列表。
在这里找到 所有 Azure AD 内置角色 的列表。
自定义角色
Azure 还允许创建 自定义角色，以满足用户的权限需求。
权限被拒绝
为了使 主体对资源具有某些访问权限，他需要被明确授予一个角色（以任何方式） 授予他该权限。
明确的 拒绝角色分配优先于 授予权限的角色。
全局管理员
具有全局管理员角色的用户能够 提升为用户访问管理员 Azure 角色到根管理组。这意味着全局管理员将能够管理 所有 Azure 订阅和管理组。 此提升可以在页面底部完成：https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Azure 政策
Azure 政策是一组 在 Microsoft Azure 中的规则和规定，帮助管理和执行组织标准，并评估合规性。这些政策在您的 Azure 资源 上强制执行不同的规则，确保这些资源符合公司标准和服务水平协议。
Azure 政策对于云治理和安全至关重要，帮助确保资源得到适当和高效的使用，并符合外部法规和内部政策。 一些示例：
确保符合特定 Azure 区域：此政策确保所有资源在特定 Azure 区域中部署。例如，一家公司可能希望确保其所有数据存储在欧洲以符合 GDPR。
强制命名标准：政策可以强制 Azure 资源的命名约定。这有助于根据名称组织和轻松识别资源，这在大型环境中非常有用。
限制某些资源类型：此政策可以限制某些类型资源的创建。例如，可以设置政策以防止创建某些 VM 大小等昂贵的资源类型，以控制成本。
强制标记政策：标记是与 Azure 资源关联的键值对，用于资源管理。政策可以强制要求某些标记必须存在，或对所有资源具有特定值。这对于成本跟踪、所有权或资源分类非常有用。
限制对资源的公共访问：政策可以强制某些资源（如存储帐户或数据库）没有公共端点，确保它们仅在组织的网络内可访问。
自动应用安全设置：政策可以用于自动将安全设置应用于资源，例如将特定网络安全组应用于所有 VM 或确保所有存储帐户使用加密。
请注意，Azure 政策可以附加到 Azure 层级的任何级别，但它们 通常用于根管理组 或其他管理组。
权限范围
在 Azure 中，权限可以分配给层级的任何部分。这包括管理组、订阅、资源组和单个资源。权限由分配它们的实体的 包含资源 继承。
这种层级结构允许高效和可扩展的访问权限管理。
Azure RBAC 与 ABAC
RBAC（基于角色的访问控制）是我们在前面的部分中看到的内容：将角色分配给主体以授予他对资源的访问。 然而，在某些情况下，您可能希望提供 更细粒度的访问管理 或 简化 数百个角色 分配 的管理。
Azure ABAC（基于属性的访问控制）在 Azure RBAC 的基础上，通过在特定操作的上下文中添加 基于属性的角色分配条件 来构建。角色分配条件 是您可以选择性地添加到角色分配中的 额外检查，以提供更细粒度的访问控制。条件过滤掉作为角色定义和角色分配一部分授予的权限。例如，您可以 添加一个条件，要求对象具有特定标记才能读取该对象。 您 不能 明确 拒绝 使用条件对特定资源的 访问。
默认用户权限
基本用户将拥有一些 默认权限 以枚举 AzureAD 的某些部分：
读取所有用户、组、应用程序、设备、角色、订阅及其公共属性
邀请访客（可以关闭）
创建安全组
读取非隐藏的组成员资格
将访客添加到拥有的组
创建新应用程序（可以关闭）
将最多 50 个设备添加到 Azure（可以关闭）
您可以在文档中查看完整的 用户默认权限列表。此外，请注意，在该列表中，您还可以看到 访客默认权限列表。
请记住，要枚举 Azure 资源，用户需要明确授予该权限。
特权身份管理 (PIM)
Azure 中的特权身份管理 (PIM) 是一个工具，用于 管理、控制和监视特权访问 在 Azure Active Directory 和 Azure 中。它通过提供 及时和时间限制的特权访问、强制审批工作流 和 要求额外身份验证 来增强安全性。这种方法通过确保仅在必要时和特定时间段内授予提升的权限，最小化未经授权访问的风险。
身份验证令牌
在 OIDC 中使用 三种类型的令牌：
访问令牌**：客户端将此令牌呈现给资源服务器以 访问资源。它只能用于特定的用户、客户端和资源组合，并且 在到期之前无法撤销 - 默认情况下为 1 小时。使用此令牌的检测率较低。
ID 令牌：客户端从 授权服务器 接收此 令牌。它包含有关用户的基本信息。它与特定的用户和客户端组合 绑定。
刷新令牌：与访问令牌一起提供给客户端。用于 获取新的访问和 ID 令牌。它与特定的用户和客户端组合 绑定，并且可以被撤销。默认过期时间为 90 天（对于不活动的刷新令牌）和 活动令牌没有过期。
有关 条件访问 的信息 存储 在 JWT 中。因此，如果您从允许的 IP 地址请求 令牌，该 IP 将被 存储 在令牌中，然后您可以使用该令牌从 不允许的 IP 访问资源。
查看以下页面以了解不同的方式 请求访问令牌 并使用它们登录：
最常见的 API 端点是：
Azure 资源管理器 (ARM)：management.azure.com
Microsoft Graph：graph.microsoft.com（已弃用的 Azure AD Graph 是 graph.windows.net）
参考文献
Last updated
