比较 Azure 和 Google Cloud 中的身份和访问管理

已完成

标识和访问管理(IAM)是权限、流程和系统的框架,用于确保安全主体能够正确访问组织资源。 IAM 涉及管理用户身份,并基于预定义的角色和权限控制他们对系统和数据的访问。

在一家全球自行车零售商工作时,你习惯于在 Google Cloud 上实施 IAM。 你还习惯于使用基于角色的访问控制(RBAC)和策略来创建严格实现的最小特权系统。 现在,你希望了解最近合并的竞争对手在 Azure 中实现的权限,以评估它们是否支持公司的安全策略。

在本单元中,你将了解如何在 Azure 中管理标识和访问,并将其与 Google Cloud 体验中熟悉的方法进行比较。

此图显示了Microsoft Azure 和 Google Cloud 提供的服务类型,其中突出显示了标识和访问管理。

IAM 机制

IAM 包括用户身份验证、授权和帐户预配。 组织使用 IAM 来帮助确保安全主体可以执行操作,并仅访问其角色所需的必要信息。 通过实施 IAM,组织可以增强安全性、简化法规合规性并提高运营效率。

Google Cloud 和 Azure 都提供控制对资源的访问的机制,并且都鼓励最小特权原则。 但是,这两个平台在实现身份验证和访问控制的方式上存在差异。

在介绍访问控制的详细信息之前,让我们先比较平台使用的术语:

Azure Google Cloud 注释
RBAC RBAC Azure 和 Google Cloud 都使用 RBAC 模型,尽管有些细节有所不同。
资源组 资源层次结构 这两个系统都可以对资源进行分组,以更轻松地进行管理。
Microsoft Entra ID 帐户 服务帐户 这两个系统都使用安全帐户来授予用户和服务对资源的访问权限。 在 Azure 中,Microsoft Entra ID 目录提供了灵活的选项。
策略 策略 在 Google Cloud 中,资源可以从层次结构中的较高位置继承策略,以简化管理。 Azure 具有更灵活的策略管理系统,对自定义角色的限制更少。

Microsoft Entra ID

在 Azure 中,用户帐户、服务帐户和其他安全主体存储在 Microsoft Entra ID 中。 Microsoft Entra ID 以前称为 Azure Active Directory (Azure AD)。 它是一种基于云的目录服务,使组织能够管理用户标识,帮助保护对应用程序和资源的访问,并实现多重身份验证。 通过提供用于跨云和本地环境管理标识的统一平台,Microsoft Entra ID 有助于简化用户访问,同时强制实施合规性和安全性。

在 Google Cloud 中,可以创建用户帐户并将其分配给云资源的权限。 但没有与 Microsoft Entra ID 对应的替代品。

资源组和资源层次结构

Google Cloud 具有可用于组织资源和控制访问的对象层次结构:

  • 组织:组织是最大的根级对象。
  • 文件夹:在每个组织中,使用文件夹隔离资源。
  • 项目:在每个文件夹中,可以创建多个项目。 每个项目都包含满足特定目的所需的资源。

Azure 具有以下对象的层次结构:

  • 订阅:订阅是可以包含资源的最大对象。
  • 资源组:在订阅中,使用资源组根据要分配的访问级别组织资源。 组中的所有资源都可以作为单个单元进行管理。

系统组件的安全帐户

在云服务中,用户需要身份以进行身份验证和访问服务。 同样,当一个系统(如虚拟机 [VM])访问另一个系统(如数据库)时,它必须明确地标识自身。 服务帐户是服务用来相互进行身份验证的安全主体。

重要说明

良好的安全做法需要定期替换与服务帐户关联的凭据。 更改服务帐户的密码或其他凭据时,必须使用新的详细信息重新配置服务。 手动进行这些更改可能需要一段时间。

在 Google Cloud 中,可以将角色分配给服务帐户,以确保在启用预期功能时获得最小特权。 每个 Google Cloud 项目都会自动创建一个默认服务帐户,但你可以修改此安排来实现更复杂的安全模型。

在 Azure 中,服务帐户是存储在 Microsoft Entra ID 中的安全主体。 你可以管理安全主体并将其分配给系统组件,以便与他人进行身份验证。

这两个云服务还具有具有自动托管凭据的服务帐户类型。 使用这些帐户可减少管理员的负载,同时维护安全性的最佳做法。 在 Google Cloud 中,使用 服务代理 创建具有自动轮换凭据的服务帐户。 在 Azure 中,等效的服务帐户称为 托管标识

策略

在 Google Cloud 中,可以使用策略将用户帐户和服务帐户与为资源分配权限的角色相关联。 可以在层次结构的各个级别应用策略。 例如,当策略应用于某个文件夹时,下层对象(如该文件夹中的项目)将继承策略。

Azure 策略不用于角色管理。 相反,它们实现了治理。 我们将在下一单元中检查它们。

了解详细信息