阿里云 RAM：身份与访问管理完全指南

资源访问管理（RAM）是阿里云安全核心的身份和访问控制服务。它管理谁可以访问哪些云资源以及可以执行哪些操作。在企业云环境中，数十或数百个用户与多个账号下的数千个资源进行交互，RAM 提供了细粒度的访问控制、联合认证能力和安全护栏，防止未授权访问并限制凭证泄露的影响范围。本指南涵盖 RAM 的完整功能集——从用户和用户组到角色、策略、单点登录和多因素认证——并提供经过生产验证的最佳实践。

RAM 安全模型

RAM 在所有阿里云服务上以一致的模型运行：一个主体（用户、角色或服务）尝试对资源执行操作，RAM 评估适用的策略以确定该操作是允许还是拒绝。这一模型在概念上很简单，但结合策略条件、资源级权限和委托管理后，可以支持复杂的访问控制模式。

RAM 中的默认立场是隐式拒绝：除非策略显式允许，否则不授予任何访问权限。任何适用策略中的显式拒绝会覆盖任何允许，确保安全边界无论如何都会被强制执行。这种默认拒绝模型符合零信任安全原则，迫使组织有意识地授予访问权限，而非默认假设访问权限存在。

RAM 用户 vs. RAM 角色

理解 RAM 用户和 RAM 角色之间的区别是设计有效访问控制架构的基础。RAM 用户是一个持久身份，代表需要长期访问权限的个人或服务。RAM 用户可以拥有访问密钥（用于 API 和 CLI 访问）、控制台密码（用于 Web 控制台访问），并可通过直接策略附加或用户组成员身份被分配策略。

RAM 角色是一个附带权限的身份，不永久关联到特定用户。相反，角色由受信任的实体——RAM 用户、阿里云服务或外部身份提供商——临时扮演。当主体扮演角色时，他们会收到具有有限生命周期的临时安全凭证。角色是几乎所有场景下授予访问权限的首选机制，因为临时凭证消除了长期访问密钥被泄露或被遗忘的风险。

根账号安全

每个阿里云账号都有一个根用户——初始账号持有者，拥有对所有资源和账单信息的不受限访问权限。根账号应仅用于只有根账号才能执行的任务，例如更改账号设置或启用注销保护。对于所有日常运维，管理工作应通过具有管理员权限的 RAM 用户进行。

使用强密码和 MFA 保护根账号。除非对于无法委托的编程操作绝对必要，否则切勿为根账号创建访问密钥。定期审计根账号活动，并设置对任何根账号登录或 API 调用的告警。

RAM 用户与用户组

RAM 用户是与阿里云交互的个人和服务的身份。每个 RAM 用户存在于单个阿里云账号中，可以通过直接策略附加或组身份成员被分配权限。

创建和管理用户

为每个需要访问阿里云资源的人创建 RAM 用户。避免在团队成员之间共享凭证，即使在开发期间也不应共享——共享凭证会破坏个体审计追踪，并使得在团队成员更换角色或离开组织时难以撤销访问权限。

为访问 Web 控制台的用户配置登录配置文件，设置一个要求在首次登录时更改的强初始密码。对于编程访问，谨慎创建访问密钥，仅为其正需要 API 或 CLI 访问的用户创建。尽可能优先使用角色而非访问密钥；如果用户已通过 SSO 在外部系统中拥有身份，他们可以扮演角色而无需在 RAM 中拥有长期凭证。

通过用户组实现可扩展管理

用户组简化了大规模权限管理。不要将策略附加到每个单独用户——这在有数十个用户时会变得难以管理——而是将策略附加到组，再将用户添加到适当的组中。典型的组织结构包括诸如 Developers、Operations、SecurityAdmins、BillingManagers 和 ReadOnly 等组，每个组具有与其职责相适应的策略。

当团队成员更换角色时，将他们移动到不同的组即可即时调整权限。当新团队成员加入时，将他们添加到适当的组即可授予所有必要的访问权限，无需复刻策略配置。用户组还作为 SSO 角色扮演的基础，其中外部身份提供商的组映射到具有相关权限的 RAM 角色。

访问密钥管理

访问密钥（AccessKey ID 和 AccessKey Secret）支持对阿里云 API 和 CLI 的编程访问。它们是等同于密码的敏感凭证，必须同样谨慎管理。切勿将访问密钥嵌入源代码、配置文件或容器镜像中——应使用环境变量、Secrets Manager 或实例 RAM 角色替代。

作为安全卫生实践，定期轮换访问密钥。RAM 支持每个用户拥有两个活跃访问密钥，从而实现无服务中断的轮换：创建新密钥，更新应用使用新密钥，验证功能正常，然后停用并删除旧密钥。通过 RAM 报告监控访问密钥的存在时间和最后使用情况，并自动禁用在规定期限内未使用的密钥。

RAM 角色与委托

RAM 角色是临时访问和跨服务授权的基石。理解角色模式对于构建安全、可维护的架构至关重要。

服务角色

阿里云服务通常需要代表您访问其他服务。例如，ECS 实例可能需要从 OSS 存储空间读取数据或写入日志服务 LogStore。与其在实例上运行的应用中嵌入访问密钥，您可以将服务角色附加到 ECS 实例上。实例元数据服务提供该角色的临时凭证，阿里云 SDK 会自动检索并使用这些凭证。

服务角色适用于大多数阿里云服务，包括 ECS、函数计算、容器服务 Kubernetes 版和 Serverless 应用引擎。当应用在附加了角色的这些服务上运行时，会自动继承该角色的权限。这完全消除了为云托管应用管理凭证的需要——相比静态访问密钥，这是一项重大的安全和运维改进。

跨账号角色

许多组织运营多个阿里云账号，用于账单分离、环境隔离或业务单元自治。跨账号角色允许一个账号（受信任账号）中的主体访问另一个账号（信任账号）中的资源，而无需创建重复的身份。

信任账号创建一个带有信任策略的角色，该策略指定受信任账号 ID，并可选择限制该账号中哪些主体可以扮演该角色。受信任账号中的用户使用 sts:AssumeRole API 扮演该角色，获取信任账号的临时凭证。此模式对于集中式安全运维、共享服务架构以及第三方供应商需要有限访问您资源的场景至关重要。

身份提供商角色与联合认证

对于拥有现有身份系统的组织——如 Active Directory、Azure AD、Okta 或任何兼容 SAML 2.0 的身份提供商——RAM 通过 SAML 和 OIDC 支持身份联合认证。无需为每位员工创建单独的 RAM 用户，您可以创建一个带有指定外部身份提供商信任策略的 RAM 角色。用户向其企业身份提供商进行身份认证，身份提供商签发 RAM 信任的 SAML 断言，RAM 返回该角色的临时凭证。

这种联合认证模型将您现有的身份基础设施保留为权威来源。员工的入职、离职和权限变更在企业目录中管理，RAM 通过角色扮演反映这些变化。用户无需管理额外的凭证，当企业账号被禁用时，访问权限自动撤销。

RAM 策略

策略是定义 RAM 中权限的授权文档。它们是 JSON 文档，指定在哪些条件下对哪些资源允许或拒绝哪些操作。掌握策略编写是实现最小权限访问的关键技能。

策略结构与语法

一个策略由一个或多个 Statement 组成，每个 Statement 包含一个 Effect（Allow 或 Deny）、一个 Action（一个或多个 API 操作）、一个 Resource（一个或多个资源 ARN），并可选择包含一个 Condition，限制 Statement 何时适用。策略中的多个 Statement 被综合评估，显式 Deny 覆盖任何 Allow。

操作使用 service:Operation 格式，例如 oss:GetObject 或 ecs:RunInstances。支持通配符：oss: 授予所有 OSS 操作权限，ecs:Describe 授予所有以 "Describe" 开头的只读 ECS 操作权限。资源以阿里云资源名称（ARN）格式指定，使用通配符进行灵活匹配：acs:oss:::my-bucket/* 匹配跨所有区域的 my-bucket 存储空间中所有对象。

策略类型

RAM 支持多种策略类型以适应不同场景。系统策略由阿里云预定义，涵盖常见场景，如只读访问、完全管理员访问或特定服务访问。系统策略由阿里云维护，当新服务功能需要策略变更时自动更新。

自定义策略由您的组织编写，用于实施特定的访问控制需求。自定义策略提供了灵活性，可精确授予架构和合规所需的权限。在存在系统策略的地方从系统策略开始，用自定义策略扩展组织特定需求。

会话策略在扮演角色时传递，进一步限制该会话期间可用的权限，甚至超角色策略所允许的范围。会话策略对于委托管理场景非常有用，您希望授予对角色权限子集的临时、限定范围的访问。

策略条件

条件为策略 Statement 添加基于上下文的限制，实现超越简单操作-资源映射的细粒度访问控制。常见条件键包括 acs:SourceIp（限制访问到特定 IP 范围）、acs:CurrentTime（限制访问到工作时间）、acs:MFAPresent（要求多因素认证）和 acs:SecureTransport（要求 HTTPS）。

条件支持诸如 IpAddress（匹配 IP 地址或 CIDR 范围）、StringEquals（精确字符串匹配）、StringLike（通配符匹配）和 DateLessThan（时间比较）等运算符。一个 Statement 中的多个条件是 AND 关系；不同的 Statement 是 OR 关系。这种条件逻辑使复杂策略成为可能："允许对 SLS 日志的读取访问，但仅限来自企业 VPN IP 范围且 MFA 存在的情况。"

最小权限设计

实施最小权限要求仅授予任务所需的权限，不授予更多。从显式拒绝一切开始，然后为每个必需操作在必需资源上添加 Allow Statement。使用 RAM Access Analyzer 和 ActionTrail 日志识别未使用的权限并将其移除。

对于开发团队，避免授予笼统的 ecs: 或 rds: 权限。相反，识别您的部署脚本和应用实际需要的特定 API 调用——通常是 ecs:RunInstances、ecs:DescribeInstances、ecs:StartInstances、ecs:StopInstances 等针对性操作。资源级权限可通过标签或实例 ID 上的条件进一步限制可影响的实例范围。

RAM 单点登录（SSO）

阿里云 Cloud SSO 是一项云原生身份联合认证服务，提供跨多个阿里云账号的集中式访问管理。它作为一个身份中枢，通过单一配置点将您的企业目录连接到阿里云账号。

SSO 架构

Cloud SSO 使用一个目录，该目录可以通过从外部身份源（Active Directory、Azure AD、Okta 等）同步来填充，也可以直接在 Cloud SSO 中管理。Cloud SSO 目录中的用户和组被分配到访问配置——特定阿里云账号的 RAM 角色和权限策略的组合。

当用户通过 Cloud SSO 门户登录时，他们会看到可用的账号和权限集。选择一个账号即会让他们登录到该账号的控制台，或提供临时 API 凭证，权限由访问配置定义。此架构允许单个企业身份访问多个阿里云账号，在每个账号中可能具有不同的权限级别——在开发账号中拥有完全管理员权限，在生产账号中仅拥有只读权限。

访问配置管理

访问配置定义用户在目标账号中获得的权限。每个访问配置在目标账号中创建具有指定附加策略的 RAM 角色。可以为不同账号的同一用户或同一账号的不同用户分配多个访问配置，从而精细控制谁在哪里可以做什么。

对访问配置的更新会传播到所有已分配的账号，简化大规模权限管理。当用户职责发生变化时，更新其 Cloud SSO 组成员身份或访问配置会立即影响其跨所有账号的权限，无需逐账号更改策略。

会话管理

Cloud SSO 会话具有可配置的持续时间，范围从一小时到十二小时。较短的会话减少了会话劫持的机会窗口，但需要更频繁的重新认证。对于敏感操作，使用单独的、会话持续时间较短的角色，仅在需要时由用户扮演。

会话活动被集中记录，提供哪个用户在什么时间以什么权限访问哪个账号的审计追踪。这一审计追踪对于遵守 SOC 2、ISO 27001 和 PCI DSS 等需要追踪特权访问的标准至关重要。

多因素认证（MFA）

MFA 在密码之外增加了第二重认证因素，显著降低了凭证泄露的风险。RAM 支持虚拟 MFA 设备（软件认证应用，如 Google Authenticator 或 Microsoft Authenticator）以及用于硬件支持的 U2F 安全密钥。

强制 MFA

MFA 应强制要求所有拥有控制台访问权限的 RAM 用户使用，尤其是那些拥有管理员权限或敏感数据访问权限的用户。RAM 策略可通过 acs:MFAPresent 条件键要求 MFA。典型的强制策略拒绝所有操作，除非 MFA 存在，从而形成对第二重因素的硬性要求。

对于无法使用交互式 MFA 的 API 调用编程访问，应使用服务角色和临时凭证而非访问密钥。如果访问密钥不可避免，实施补偿性控制措施，如 IP 限制、短生命周期凭证和加强的 API 活动监控。

特权操作的 MFA

除全面 MFA 要求外，考虑对特定敏感操作要求 MFA，如删除 OSS 存储空间、终止 ECS 实例、修改安全组或更改 IAM 配置。这种针对性方法允许常规只读或低风险操作无需 MFA（减少摩擦），同时保护高影响操作。

MFA 设备管理

如果策略要求，用户可以在首次登录时通过 RAM 控制台自助注册 MFA 设备。提供关于 MFA 设置和恢复流程的清晰文档，包括用户丢失 MFA 设备时该怎么办。丢失的 MFA 设备需要管理员介入才能停用，因此需维护一个带有适当身份验证步骤的文档化流程，以安全地处理 MFA 恢复请求。

监控与审计

有效的访问管理需要持续监控，以检测配置错误和未授权活动。

ActionTrail 集成

在所有区域启用阿里云 ActionTrail，捕获账号中进行的每次 API 调用。ActionTrail 日志包括主体（用户或角色）、执行的操作、影响的资源、源 IP 和结果（允许或拒绝）。这些日志对于安全调查、合规审计和异常检测至关重要。

将 ActionTrail 日志投递至日志服务（SLS）进行实时分析和告警，并投递至 OSS 进行长期归档。为重要安全事件创建告警：根账号使用、IAM 策略变更、安全组修改、访问密钥创建或删除，以及任何可能表明未授权访问尝试的被拒绝 API 调用。

Access Analyzer

RAM Access Analyzer 识别账号中与外部实体共享的资源，包括跨账号角色、授予外部账号访问权限的 OSS 存储空间策略，以及带有外部主体的 KMS 密钥策略。Access Analyzer 的发现结果帮助您了解外部暴露面，并识别意外公开或跨账号的资源。

定期运行 Access Analyzer 并审查发现结果。任何无法被合理化的发现结果都应通过收紧资源策略来修复。将 Access Analyzer 视为持续合规工具，而非一次性审计。

凭证报告

RAM 提供凭证报告，列出所有用户、其访问密钥状态、密码存在时间及最后使用情况、以及 MFA 注册状态。使用这些报告进行定期访问审查，并识别应被移除的过期凭证。自动化凭证报告的生成和分析，标记未启用 MFA 的用户、超过 90 天的访问密钥或应被禁用凭证的非活跃用户。

企业最佳实践

账号结构

设计阿里云账号结构以与组织和安全边界保持一致。常见模式包括专用的根管理账号（不承载生产工作负载）、独立的开发、预发和生产环境账号，以及可能为不同业务单元或合规范围设立的独立账号。使用 Cloud SSO 实现集中访问，使用 ROS Stack Group 实现跨账号的一致基础设施。

紧急访问

定义"破窗"程序，用于正常认证路径不可用时的紧急访问。这通常涉及一个专用的紧急管理员角色，具有高度限制的信任策略和积极的告警机制——该角色的任何扮演都会立即触发安全团队通知。定期测试破窗程序，确保在需要时能正常工作。

定期访问审查

对所有 RAM 用户、角色和策略进行定期访问审查。验证每个用户是否仍需要其拥有的访问权限，每个角色的信任策略是否仍然适当，以及没有策略授予过多权限。尽可能自动化审查流程：生成用户-角色-策略映射报告，分发给团队负责人进行验证，并追踪发现的任何问题的修复。

最小权限原则自动化

使用策略生成工具，分析 ActionTrail 日志以确定用户或角色实际使用的最小权限，并生成仅授予这些权限的策略。这种数据驱动的策略设计方法比手动编写策略更准确、更可维护，尤其适用于复杂的服务交互。

总结

RAM 身份与访问管理是阿里云安全的基础，控制着与云资源的每次交互。通过实施最小权限策略、优先使用角色而非访问密钥、通过 SSO 与企业身份系统集成以及强制执行多因素认证，组织可以显著降低未授权访问和凭证泄露的风险。结合通过 ActionTrail 和 Access Analyzer 的持续监控，RAM 提供了在复杂的多账号云环境中维持强大安全态势所需的工具。

本文由 7.chengzicloud.cloud 提供，点击访问首页了解更多