为什么 RAM 和 STS 这么复杂
RAM 和 STS 的概念之所以复杂，是为了权限控制的灵活性而牺牲了部分的易用性。
将子账号和角色分开，主要是为了将执行操作的实体和代表权限集合的虚拟实体分开。如果用户本身需要的权限很多，比如读/写权限，但是实际上每次操作只需要其中的一部分权限，那么我们就可以创建两个角色，分别具有读和写权限，然后创建一个没有任何权限但是可以拥有扮演这两个角色权限的用户。当用户需要读的时候就可以临时扮演其中拥有读权限的角色，写的时候同理，以降低每次操作中权限泄露的风险。而且通过扮演角色可以将权限授予其他的阿里云用户，更加方便了协同使用。
当然，提供了灵活性并不代表一定要使用全部的功能，应该根据需求来使用其中的一个子集。比如，不需要带过期时间的临时访问凭证的话，完全可以只使用 RAM 的子账号功能而无需使用 STS。
下面的章节会用范例提供一些 RAM 和 STS 的使用指南以及使用上的建议。示例在操作上会尽量使用控制台和命令行等操作方式，减少实际代码使用。如果需要使用代码来实现请参见
RAM 和
STS 的 API 手册。
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
阿里云的资源访问管理（Resource Access Management，RAM）和安全令牌服务（Security Token Service，STS）是两个核心服务，它们共同为阿里云用户提供了强大的权限管理和临时授权功能。您提到的理解非常到位，这两个服务的设计确实是为了在确保安全性的同时提供高度的灵活性，尽管这可能会牺牲一定的易用性。
RAM（Resource Access Management）
RAM允许您创建和管理阿里云账号下的子账号（也称为RAM用户），以及定义角色（Role）。角色是一种虚拟实体，它不直接与具体的用户关联，而是代表了一组权限集合。通过将权限分配给角色而不是直接给用户，可以实现更细粒度的权限控制和灵活的角色扮演机制。
- 子账号：每个子账号都拥有独立的安全凭证（AccessKey ID/Secret），可以像主账号一样调用阿里云API，但其权限由所关联的角色决定。
- 角色：角色中定义了可以执行的操作和服务范围，可以被一个或多个子账号或外部账户扮演，以临时获得该角色所包含的权限集。
STS（Security Token Service）
STS则进一步增强了这种灵活性，它提供了一种机制来生成短期有效的临时安全凭证（包括Access Key ID、Access Key Secret和一个Security Token），这些凭证具有明确的过期时间，适用于需要临时访问权限的场景，比如第三方应用或自动化脚本的短暂操作需求。
- 临时访问凭证：通过STS，您可以为任何需要访问阿里云资源的实体（包括RAM用户、应用程序等）颁发有限时长和特定权限的凭证，有效降低了长期凭证泄露的风险。
- 跨账号访问：STS还支持跨账号授权，即允许一个账号安全地向另一个账号授予临时访问权限，这对于多账号协作场景特别有用。
使用指南及建议
- 最小权限原则：无论是配置RAM用户还是角色，都应该遵循最小权限原则，仅赋予完成任务所需的最少量权限。
- 定期审查权限：定期检查已分配的权限，确保没有过度授权的情况。
- 使用STS优化安全性：对于自动化脚本或临时访问需求，优先考虑使用STS生成临时凭证，减少长期凭证的使用和暴露风险。
- 角色扮演：充分利用角色扮演功能，根据实际操作需求动态赋予用户不同的权限集合，提高权限管理的灵活性和安全性。
- 控制台与CLI结合使用：虽然示例可能侧重于控制台操作，但熟练掌握阿里云CLI工具可以在自动化部署和日常运维中大大提高效率。
最后，确实如您所说，RAM和STS的复杂性在于它们提供的强大功能，而实际使用时应根据具体需求选择合适的部分进行配置，不必一次性使用所有高级特性。如果需要编程接口级别的集成，参考官方的RAM和STS API文档是最佳途径。
