From 87afe229b5e3b3698b42e1014e2656fe776912cd Mon Sep 17 00:00:00 2001 From: Translator Date: Sat, 8 Feb 2025 18:51:34 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE --- .../az-basic-information/README.md | 109 ++++++++++-------- 1 file changed, 64 insertions(+), 45 deletions(-) diff --git a/src/pentesting-cloud/azure-security/az-basic-information/README.md b/src/pentesting-cloud/azure-security/az-basic-information/README.md index ae36431a9..895a08a82 100644 --- a/src/pentesting-cloud/azure-security/az-basic-information/README.md +++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md @@ -9,7 +9,7 @@ ### 管理组 - 它可以包含**其他管理组或订阅**。 -- 这允许在管理组级别**应用治理控制**，如RBAC和Azure Policy，并使其**被所有订阅继承**。 +- 这允许在管理组级别**应用治理控制**，如RBAC和Azure Policy，并让所有组内的订阅**继承**这些控制。 - **单个目录**最多可以支持**10,000个管理组**。 - 管理组树可以支持**最多六个层级的深度**。此限制不包括根级别或订阅级别。 - 每个管理组和订阅只能支持**一个父级**。 @@ -24,7 +24,7 @@ - 这是另一个**逻辑容器，资源**（虚拟机、数据库等）可以在其中运行并计费。 - 它的**父级**始终是**管理组**（可以是根管理组），因为订阅不能包含其他订阅。 - 它**只信任一个Entra ID**目录。 -- 在订阅级别（或其任何父级）应用的**权限**会**被所有资源继承**。 +- 在订阅级别（或其任何父级）应用的**权限**会**继承**到订阅内的所有资源。 ### 资源组 @@ -42,7 +42,7 @@ Azure 资源 ID 的格式如下： - `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}` -对于在订阅 ID `12345678-1234-1234-1234-123456789012` 下的资源组 `myResourceGroup` 中名为 myVM 的虚拟机，Azure 资源 ID 看起来像这样： +对于在资源组`myResourceGroup`下，订阅 ID 为`12345678-1234-1234-1234-123456789012`的名为 myVM 的虚拟机，Azure 资源 ID 如下所示： - `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM` @@ -124,16 +124,16 @@ Entra 域服务通过提供**与传统 Windows Active Directory 环境兼容的 - **安全组**：此类型的组用于授予成员对应用程序、资源的访问权限并分配许可证。用户、设备、服务主体和其他组可以是成员。 - **Microsoft 365 组**：此类型的组用于协作，给予成员对共享邮箱、日历、文件、SharePoint 站点等的访问权限。组成员只能是用户。 -- 这将具有一个**电子邮件地址**，其域为 EntraID 租户的域。 +- 这将具有 EntraID 租户的**电子邮件地址**。 有**2种类型的成员资格**： -- **分配的**：允许手动将特定成员添加到组。 +- **分配**：允许手动将特定成员添加到组。 - **动态成员资格**：使用规则自动管理成员资格，当成员属性更改时更新组的包含。 ### **服务主体** -**服务主体**是为**与应用程序**、托管服务和自动化工具一起使用而创建的**身份**，以访问 Azure 资源。此访问**受限于分配给服务主体的角色**，使您能够控制**可以访问哪些资源**以及访问的级别。出于安全原因，始终建议**使用服务主体与自动化工具**，而不是允许它们使用用户身份登录。 +**服务主体**是为**应用程序**、托管服务和自动化工具创建的**身份**，用于访问 Azure 资源。此访问权限由分配给服务主体的角色**限制**，使您能够控制**可以访问哪些资源**以及访问的级别。出于安全原因，始终建议**使用服务主体与自动化工具**，而不是允许它们使用用户身份登录。 可以通过生成**密钥**（密码）、**证书**或授予对第三方平台（例如 GitHub Actions）的**联合**访问来**直接以服务主体身份登录**。 @@ -149,19 +149,19 @@ Entra 域服务通过提供**与传统 Windows Active Directory 环境兼容的 1. **应用程序 ID（客户端 ID）：** 您的应用在 Azure AD 中的唯一标识符。 2. **重定向 URI：** Azure AD 发送身份验证响应的 URL。 3. **证书、密钥和联合凭据：** 可以生成密钥或证书以作为应用程序的服务主体登录，或授予对其的联合访问（例如 GitHub Actions）。 -1. 如果生成了**证书**或**密钥**，则可以通过知道**应用程序 ID**、**密钥**或**证书**以及**租户**（域或 ID）来**以服务主体身份登录**。 -4. **API 权限：** 指定应用可以访问的资源或 API。 -5. **身份验证设置：** 定义应用支持的身份验证流程（例如，OAuth2、OpenID Connect）。 -6. **服务主体**：创建应用时会创建服务主体（如果是从网络控制台创建）或在新租户中安装时。 -1. **服务主体**将获得其配置的所有请求权限。 +4. 如果生成了**证书**或**密钥**，则可以通过知道**应用程序 ID**、**密钥**或**证书**以及**租户**（域或 ID）来**以服务主体身份登录**。 +5. **API 权限：** 指定应用可以访问的资源或 API。 +6. **身份验证设置：** 定义应用支持的身份验证流程（例如，OAuth2、OpenID Connect）。 +7. **服务主体**：创建应用时会创建服务主体（如果是从网络控制台创建）或在新租户中安装时。 +8. **服务主体**将获得其配置的所有请求权限。 ### 默认同意权限 **用户对应用程序的同意** - **不允许用户同意** -- 所有应用程序都需要管理员。 -- **允许用户对来自经过验证的发布者的应用程序进行选择性权限的同意（推荐）** +- 所有应用程序都需要管理员批准。 +- **允许用户对来自经过验证的发布者的应用程序进行同意，针对选定的权限（推荐）** - 所有用户可以对被分类为“低影响”的权限进行同意，适用于来自经过验证的发布者或在此组织中注册的应用程序。 - **默认**低影响权限（尽管您需要接受将其添加为低影响）： - User.Read - 登录并读取用户资料 @@ -184,8 +184,8 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程 托管身份有两种类型： -- **系统分配**。某些 Azure 服务允许您**直接在服务实例上启用托管身份**。当您启用系统分配的托管身份时，会在资源所在的订阅中创建一个**服务主体**。当**资源**被**删除**时，Azure 会自动为您**删除**该**身份**。 -- **用户分配**。用户也可以生成托管身份。这些身份是在订阅中的资源组内创建的，并且将在 EntraID 中创建一个服务主体。然后，您可以将托管身份分配给一个或**多个 Azure 服务实例**（多个资源）。对于用户分配的托管身份，**身份与使用它的资源是分开管理的**。 +- **系统分配**。某些 Azure 服务允许您**直接在服务实例上启用托管身份**。当您启用系统分配的托管身份时，会在资源所在的订阅中创建一个**服务主体**，该订阅信任 Entra ID 租户。当**资源**被**删除**时，Azure 会自动为您**删除**该**身份**。 +- **用户分配**。用户也可以生成托管身份。这些身份是在订阅内的资源组中创建的，并且将在 EntraID 中创建一个服务主体，该主体由订阅信任。然后，您可以将托管身份分配给一个或**多个 Azure 服务实例**（多个资源）。对于用户分配的托管身份，**身份与使用它的资源是分开管理的**。 托管身份**不会生成永久凭据**（如密码或证书）以访问与其附加的服务主体。 @@ -193,7 +193,7 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程 这只是一个**在 Azure 中过滤服务主体**并检查已分配应用程序的表。 -**这不是另一种“应用程序”类型，** Azure 中没有任何对象是“企业应用程序”，这只是检查服务主体、应用注册和托管身份的抽象。 +**这不是另一种“应用程序”**，在 Azure 中没有任何对象是“企业应用程序”，这只是检查服务主体、应用注册和托管身份的抽象。 ### 管理单位 @@ -223,11 +223,11 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程 **角色**是**分配**给**主体**的**范围**：`principal -[HAS ROLE]->(scope)` -**分配给组的角色**会**被组内所有成员继承**。 +**分配给组的角色**会被**组内所有成员继承**。 -根据角色分配的范围，**角色**可能会**被继承**到范围容器内的**其他资源**。例如，如果用户 A 在订阅上有一个**角色**，他将在订阅内的所有资源组和资源组内的**所有资源**上拥有该**角色**。 +根据角色分配的范围，**角色**可能会**继承**到**范围容器内的其他资源**。例如，如果用户 A 在订阅上有一个**角色**，他将在订阅内的所有资源组和资源组内的**所有资源**上拥有该**角色**。 -### **经典角色** +### 经典角色 | **所有者** | | 所有资源类型 | | ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ | @@ -237,13 +237,13 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程 ### 内置角色 -[来自文档： ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure 基于角色的访问控制（Azure RBAC）](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) 有几个 Azure **内置角色**，您可以将其**分配**给**用户、组、服务主体和托管身份**。角色分配是您控制**对 Azure 资源的访问**的方式。如果内置角色不满足您组织的特定需求，您可以创建自己的 [**Azure 自定义角色**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**。** +[来自文档： ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure 基于角色的访问控制（Azure RBAC）](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview)有多个 Azure **内置角色**，您可以将其**分配**给**用户、组、服务主体和托管身份**。角色分配是您控制**对 Azure 资源的访问**的方式。如果内置角色不满足您组织的特定需求，您可以创建自己的 [**Azure 自定义角色**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**。** **内置**角色仅适用于**它们所针对的资源**，例如检查这两个**内置角色**在计算资源上的示例： | [磁盘备份读取者](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader) | 提供备份库执行磁盘备份的权限。 | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ | -| [虚拟机用户登录](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | 在门户中查看虚拟机并以常规用户身份登录。 | fb879df8-f326-4884-b1cf-06f3ad86be52 | +| [虚拟机用户登录](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | 在门户中查看虚拟机并以普通用户身份登录。 | fb879df8-f326-4884-b1cf-06f3ad86be52 | 这些角色也可以**分配给逻辑容器**（如管理组、订阅和资源组），受影响的主体将在**这些容器内的资源上**拥有它们。 @@ -254,13 +254,15 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程 - 也可以创建 [**自定义角色**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) - 它们是在一个范围内创建的，尽管一个角色可以在多个范围内（管理组、订阅和资源组） -- 可以配置自定义角色的所有细粒度权限 +- 可以配置自定义角色将具有的所有细粒度权限 - 可以排除权限 - 拥有被排除权限的主体即使在其他地方授予权限也无法使用该权限 - 可以使用通配符 - 使用的格式是 JSON -- `actions` 用于控制对资源的操作 -- `dataActions` 是对对象内数据的权限 +- `actions` 指的是对资源进行管理操作的权限，例如创建、更新或删除资源定义和设置。 +- `dataActions` 是对资源内数据操作的权限，允许您读取、写入或删除资源中包含的实际数据。 +- `notActions` 和 `notDataActions` 用于从角色中排除特定权限。但是，**它们并不拒绝这些权限**，如果其他角色授予它们，主体将拥有这些权限。 +- `assignableScopes` 是可以分配角色的范围数组（如管理组、订阅或资源组）。 自定义角色的权限 JSON 示例： ```json @@ -295,44 +297,61 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程 ### 权限顺序 - 为了让一个 **主体对资源有某些访问权限**，他需要被授予一个明确的角色（以任何方式）**授予他该权限**。 -- 明确的 **拒绝角色分配优先于** 授予权限的角色。 +- 明确的 **拒绝分配优先于** 授予权限的角色。

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

### 全局管理员 -全局管理员是 Entra ID 的一个角色，授予 **对 Entra ID 租户的完全控制**。然而，它默认不授予对 Azure 资源的任何权限。 +全局管理员是 Entra ID 的一个角色，授予 **对 Entra ID 租户的完全控制**。然而，默认情况下，它并不授予对 Azure 资源的任何权限。 拥有全局管理员角色的用户可以在根管理组中 '**提升' 为用户访问管理员 Azure 角色**。因此，全局管理员可以管理 **所有 Azure 订阅和管理组的访问**。\ 此提升可以在页面底部完成：[https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
-### Azure 策略 +### 分配条件与 MFA -**Azure 策略** 是帮助组织确保其资源符合特定标准和合规要求的规则。它们允许您 **强制执行或审核 Azure 中资源的设置**。例如，您可以防止在未经授权的区域创建虚拟机，或确保所有资源都有特定的标签以便跟踪。 +可以 **在将角色分配给主体时建立一些条件**。一个常见的条件是要求 MFA 以访问某些角色权限： +```bash +az role assignment create \ +--assignee \ +--role \ +--scope "/subscriptions/9291ff6e-6afb-430e-82a4-6f04b2d05c7f" \ +--condition "PrincipalClaims['amr'] contains 'mfa'" \ +--condition-version 2.0 +``` +### Deny Assignments -Azure 策略是 **主动的**：它们可以阻止不合规资源的创建或更改。它们也是 **反应性的**，允许您查找并修复现有的不合规资源。 +就像角色分配一样，**deny assignments** 用于 **控制对 Azure 资源的访问**。然而，**deny assignments** 用于 **明确拒绝对资源的访问**，即使用户通过角色分配获得了访问权限。**Deny assignments** 优先于 **role assignments**，这意味着如果用户通过角色分配获得了访问权限，但也通过 deny assignment 明确拒绝了访问，则 deny assignment 将优先。 -#### **关键概念** +就像角色分配一样，**deny assignments** 应用于某个范围，指示受影响的主体和被拒绝的权限。此外，在 deny assignments 的情况下，可以 **防止拒绝被子资源继承**。 -1. **策略定义**：以 JSON 编写的规则，指定允许或要求的内容。 -2. **策略分配**：将策略应用于特定范围（例如，订阅、资源组）。 -3. **倡议**：一组政策的集合，用于更广泛的执行。 -4. **效果**：指定当策略被触发时会发生什么（例如，“拒绝”、“审核”或“附加”）。 +### Azure Policies + +**Azure Policies** 是帮助组织确保其资源符合特定标准和合规要求的规则。它们允许您 **强制执行或审核 Azure 中资源的设置**。例如，您可以防止在未经授权的区域创建虚拟机，或确保所有资源都有特定的标签以便跟踪。 + +Azure Policies 是 **主动的**：它们可以阻止不合规资源的创建或更改。它们也是 **反应性的**，允许您查找并修复现有的不合规资源。 + +#### **Key Concepts** + +1. **Policy Definition**: 一条规则，采用 JSON 编写，指定允许或要求的内容。 +2. **Policy Assignment**: 将政策应用于特定范围（例如，订阅、资源组）。 +3. **Initiatives**: 一组政策的集合，用于更广泛的执行。 +4. **Effect**: 指定当政策被触发时会发生什么（例如，“Deny”，“Audit”或“Append”）。 **一些示例：** -1. **确保符合特定 Azure 区域的合规性**：此策略确保所有资源在特定 Azure 区域部署。例如，一家公司可能希望确保其所有数据存储在欧洲以符合 GDPR。 -2. **强制命名标准**：策略可以强制 Azure 资源的命名约定。这有助于根据名称组织和轻松识别资源，这在大型环境中非常有用。 -3. **限制某些资源类型**：此策略可以限制某些类型资源的创建。例如，可以设置策略以防止创建某些 VM 大小等昂贵资源类型，以控制成本。 -4. **强制标签策略**：标签是与 Azure 资源关联的键值对，用于资源管理。策略可以强制要求所有资源必须存在某些标签，或具有特定值。这对于成本跟踪、所有权或资源分类非常有用。 -5. **限制对资源的公共访问**：策略可以强制某些资源（如存储帐户或数据库）没有公共端点，确保它们仅在组织的网络内可访问。 -6. **自动应用安全设置**：策略可以用于自动将安全设置应用于资源，例如将特定网络安全组应用于所有 VM，或确保所有存储帐户使用加密。 +1. **确保符合特定 Azure 区域的合规性**：此政策确保所有资源在特定 Azure 区域中部署。例如，一家公司可能希望确保其所有数据存储在欧洲以符合 GDPR 合规性。 +2. **强制命名标准**：政策可以强制 Azure 资源的命名约定。这有助于根据名称组织和轻松识别资源，这在大型环境中非常有用。 +3. **限制某些资源类型**：此政策可以限制某些类型资源的创建。例如，可以设置政策以防止创建昂贵的资源类型，如某些 VM 大小，以控制成本。 +4. **强制标签政策**：标签是与 Azure 资源关联的键值对，用于资源管理。政策可以强制要求所有资源必须存在某些标签，或具有特定值。这对于成本跟踪、所有权或资源分类非常有用。 +5. **限制对资源的公共访问**：政策可以强制某些资源（如存储帐户或数据库）没有公共端点，确保它们仅在组织的网络内可访问。 +6. **自动应用安全设置**：政策可以用于自动将安全设置应用于资源，例如将特定的网络安全组应用于所有 VM，或确保所有存储帐户使用加密。 -请注意，Azure 策略可以附加到 Azure 层次结构的任何级别，但它们 **通常用于根管理组** 或其他管理组。 +请注意，Azure Policies 可以附加到 Azure 层次结构的任何级别，但它们 **通常用于根管理组** 或其他管理组。 -Azure 策略 JSON 示例： +Azure policy json example: ```json { "policyRule": { @@ -352,9 +371,9 @@ Azure 策略 JSON 示例： ``` ### 权限继承 -在 Azure **权限可以分配给层级的任何部分**。这包括管理组、订阅、资源组和单个资源。权限由分配它们的实体的包含 **资源** 继承。 +在 Azure **权限可以分配给层次结构的任何部分**。这包括管理组、订阅、资源组和单个资源。权限由分配它们的实体的包含 **资源** 继承。 -这种层级结构允许高效且可扩展的访问权限管理。 +这种层次结构允许高效且可扩展的访问权限管理。
@@ -364,7 +383,7 @@ Azure 策略 JSON 示例： 然而，在某些情况下，您可能希望提供 **更细粒度的访问管理** 或 **简化** 数百个角色 **分配** 的管理。 Azure **ABAC**（基于属性的访问控制）在 Azure RBAC 的基础上，通过在特定操作的上下文中添加 **基于属性的角色分配条件** 来构建。_角色分配条件_ 是您可以选择性地添加到角色分配中的 **额外检查**，以提供更细粒度的访问控制。条件过滤掉作为角色定义和角色分配一部分授予的权限。例如，您可以 **添加一个条件，要求对象具有特定标签才能读取该对象**。\ -您 **不能** 明确 **拒绝** **使用条件** 对特定资源的 **访问**。 +您 **不能** 明确 **拒绝** **对特定资源的访问** **使用条件**。 ## 参考文献