AWS 作为云计算行业鼻祖，不论是什么功能，都做得非常完备，且一切可编程。它们能全方位的解决客户的各种问题，甚至想他人之未曾想，真的非常值得业内人士及机构尊敬。
但，完备的背后离不开大量的人力支持，又因为它的完备使得各业务都极其复杂。我最近才开始好好看一看 AWS ，才知道居然都有专门的 AWS 咨询师这样的职业。真是厉害了~
目前主要在看的模块是 IAM 以及周边功能，由于本喵的英文水平不太好，云计算行业术语又了解得太少，看得好费劲。不过通过借助谷歌翻译、上手操作以及咨询兽兽等大咖，也算是了解了个大概。
IAM 非官方简介
IAM ，全称 Identity and Access Management ，字面意思就是识别用户身份和接入控制的管理，所以我将其翻译为“用户鉴权”。
整个 IAM 体系主要包括“谁可以使用我的资源”（who）、“如何使用我的资源”（how）和“对资源的使用程度”（Authority）三大方面。
既然都是和“我的资源”相关，所以我在理解时通常将 IAM 与“资源协作”业务场景结合起来看。
账户、用户及角色（Who）
姑且将“我”认为是账户实体，也就是对应 AWS 中的根帐户（Root）。“我”是金主，付钱买了一大堆资源，但是“我”一个人管理不过来，就派人来帮“我”分门别类的管理它们。
而“我”又不可能把自己的账号密码都公开给这些人，因为“我”的账号密码直接代表了整个系统的经济命脉和大佬权限。所以，“我”给他们每个人创建基于“我”的子账号，称之为用户。
既然是分散管理，那么就会对这些用户有不同的类别，就好比 A、B 是开发人员，C、D 是产品经理，各类人群关注点不同，于是给用户创建不同的分组。
然而，可以访问资源的，不仅仅是人，也可能是其他资源、外部应用，或者其他的根。于是，这些被统称为“角色”。
简单的用一个关系图来展示下：
接入方式（How）
用户可以控制台登陆，可以用私有 API 封装到程序连结，亦可以通过 CLI 命令行方式登陆，这个登陆相当于永久性密钥。
而对于各类不同的角色，它们会直接具备某些资源的访问及操作权限。那么每个资源可能需要开通接口，以提供给不同的角色做临时访问鉴权。
于是构成了云平台的接入体系。
权限（Authority）
可以说，权限是整个 IAM 的核心，控制着这个账户下所有的用户及角色对其资源的访问程度。允许还是拒绝？可访问？可管理？增删改查……对象是某个资源 or 某一类资源？
在 AWS 中，所有可能的权限都事先设计好，只需要绑定到用户、组或者角色就可以生效了。这些设计好的权限被称之为策略（Policy）。
AWS IAM 内置了一系列的 Policy ，已足够客户使用。万一不够，还可以创建属于自己的 Policy 。
（该图片系转载，侵删致歉。来源： Alchemist - AWS IAM 学习总结 ）
不同平台用户管理机制对比
目前几乎所有的云平台都有基于资源协作的用户权限管理体系，国内的大厂像阿里云、腾讯云基本就是精简版的 AWS IAM ，而国外的产品倒是各有各的特色。
Google Cloud Platform
GCP 在用户添加时便为其设定具备某种权限的角色，当然后期可编辑和更改。
角色即代表了权限 Map ，一个用户可以有多种角色，而角色策略本身内置不可编辑。
其他资源或应用需要接入时在第一次接入时自动创建基于 IAM 的成员，这样看来，应用获取的可能也是永久接入权限。
配置相对简单，但可扩展性一般。
Azure
Azure 将客户按订阅方式划分不同的套餐，在每个订阅中配置用户角色和用户组。
和 GCP 类似，有一系列的资源控制内置权限。
值得一提的是，Azure 还有 Win Server 中的那套 Active Directory （活动目录）类似机制，使用域控制器将用户分域、分组并针对应用、控件、设备等（而非系统中的云资源）做一些安全权限配置。
但关于 Azure AD 我暂时理解得不够，未来可能还需要多花时间研究一下。
IBM Cloud （BlueMix）
BlueMix 在访问管理上看起来并没有使用统一的认证接口，它为资源创建服务标识以提供给内部其他资源或外部应用接入，同时亦可类似 GCP 那样直接为用户和组授权，也有直接为内部资源之间创建连结权限。
用户是邀请其他账号过来参与本账户的资源协作，没有子账号，不支持权限策略的编辑和制定。
不过，在其用户的管理配置界面，有提到“未来支持 IAM ”字样。
看来 AWS 行业鼻祖的地位影响还是很大的。
BlueMix 给人的感觉，虽然除了子账号，其他各功能也都有，就是比较凌乱，没有统一管控起来。
基于 AWS IAM 的一些思考
用户模型
账户安全问题不容小觑，AWS 在 IAM 控制台首页就提示客户删除根密钥创建 IAM 管理员账户是最佳实践。
在 AWS IAM 用户管理体系中，它似乎与类 UNIX 操作系统的账户体系有着异曲同工之妙：只有 Root 掌握着最高权限，不同的类别服务使用各自的权限用户及用户组。
AWS 这样做，可以很好的防止账单信息被篡改、权限配置的错乱等各种安全和意外问题。
它把整个体系其实上升到了组织的结构，Root 不再是一个人，仅仅是代表了最高权限的集合，只有 IAM 子账号才是实实在在干活儿的人。就类似公司 or 企业，广大员工等价于这里的用户，Root 对应的就是公司。
权限策略
个人认为 AWS IAM 最厉害之处就是将 Policy 封装成了统一的框架，并提供了界面配置和适应专业人士的 json 配置模式，从而直接就形成了 AWS 的自有标准。
同时其内置策略特别多，想必已足够绝大部分用户的使用了。
资源标识符 ARN
前面提到 BlueMix 有让用户为服务创建标识，而 AWS 中默认就是任何资源都有其标识。哪怕是一条服务策略、一个操作、一条配置也有自己的 ARN 。
所以在 AWS ，并不存在 BlueMix 中的那种为了建立连结而再给资源创建标识的需要。底层直接通过 ARN 连接就好。
关于 AWS IAM 的周边功能体验
Organization
Organization ，其实就是一个基于树形结构的组织架构图的管理，里面也有涵盖了账户策略。不同的是，Organization 中的账户都是 Root 账户身份。
一开始，因为看到 IAM 用户组的存在，让人感觉有点晕头转向的，不知道作用如何。
经过一段时间的试用，我想，该功能大约是用于那种集团公司大架构下的管理吧。有很多很多子公司的存在，相互之间要独立又要有关联。
而 Organization 最大的作用大概就在于账单的合并与分离，其实跟接入权限控制关系不大。
有意思的是，在创建了 Organization 之后，IAM 会自动给这个 Organization 创建角色，从而在 Org 内部的用户可以通过 IAM 角色切换登陆。
Cognito
Cognito 是一个应用程序管理器，为你在 AWS 中创建的应用程序管理各种不同接入权限的用户池。
其实它跟 IAM 并没有什么特别的关系，IAM 是基于平台系统层次的，Cognito 基于某个具体的应用程序。假设 AWS 也有类似 ISO 网络模型的话，它们就不是同一层的概念了。
尽管我是偶然发现的这个模块功能，可其实在 Cognito 创建用户池的时候，发现它也会同步的创建一系列 IAM 管理角色。看起来，在应用程序的接入控制上，可能也调用了 IAM 体系中的某模块。
CodeStar
CodeStar 在 AWS 中官方中文版译作“项目”，最先我也以为是以一种资源集合的形式存在（类似 GCP 的 Project ），实际看了之后也并不是。
CodeStar 其实是一个开发者平台，将开发者的项目直接发布到云。可通过连结本地 IDE （比如 VS Code）、代码共享平台（比如 GitHub）一站式管理和发布开发中的项目。当然 AWS 也提供自己的 IDE 和 代码共享平台并在这里推荐用户使用它们。
这样看来， CodeStar 其实类似一个多语言多平台的 GitHub Page 了，因而不仅仅是 Page 。
同样的， CodeStar 的创建也会向 IAM 中添加相应的各种角色。
其实在 AWS 中，真正的资源集合是顶栏标签上的“资源组”，虽然一贯的 AWS 风格，反倒资源组并没有惊艳到我，没有比较深入的体现协作管理关系。这点，我个人还是更喜欢 GCP 的项目风格。
……
其实上面那些严格来说也不算是 IAM 的周边功能吧。 AWS IAM 管理是全局的，很多功能模块使用时可能都会去创建个 IAM 角色接入到管理系统，以辅助完成该模块的身份认证和鉴权。
从这些试用中，可以发现 ARN 中的 “ Resource ” 一词，在整个体系中已不再是狭义的主机、数据库等用户申请创建的虚拟或硬件资源，而是平台中的每一个的功能包括账户管理、应用管理甚至 IAM 管理本身。
一点题外话
在看 IAM 这块内容时，不禁让我想起了多年前我在湖北省电信工作时的 BOSS 三户模型。那个体系因为业务的关系，比这个更复杂，在开发和实施过程中也是研究出了大量的通信标准。
印象中，那种完善的协议制定往往是多个专家经过了长达几个月的封闭式细节推敲和研究才完成，并且有着层层的质量审查。在我国互联网快速迭代的今天，这些真的是太难做到了。
而 AWS 一直坚持的标准和框架结构，想必在形成和迭代的过程中也是非常精密的。
技术复制可能容易，但精神和思想不易。
