一、企业云上身份使用的问题

有些人总以为账号体系或者身份体系是一个账号，它不仅仅是一个账号，而且有这个账号管理的体系和账号的使用体系，做到账号的时候为什会做到安全，在线上的系统或者是云上的系统的时候，会用一个身份来表示使用人员，使用人员使用这个身份的时候，通常用账号来代替，账号有密码、密钥的方式向系统认证的确是一个系统认证的合法用户，如果密钥发生了泄露以后，会有人冒用身份去使用账号下关联的系统数据，以及整个内部的内网结构。

案例一，2022年，某家员工的账号发生了泄露，入侵者利用泄露的账号访问到的内网，篡改系统，导致数据泄露。

案例二，24年某家员工离职员工发现自己的的账号并没有被回收，权限也没被回收，于是登到公司的内网，部署恶意脚本，删除了近百台服务器，对公司造成了止损。

案例三，某家机构的员工密码被泄露，同样被恶意的攻击者利用访问到内部系统里面去扫描内网或者更高权限的账号，从而导致了账号泄露。

无论是这些密码被滥用，被盗取，或者离职员工的账号的密钥被滥用，都会导致线上系统的安全故障或者生产故障，如果导致数据泄露以后，可能会发生安全类的故障，这是每一个企业都不想见到的事实，在这类数据安全故障中，2024年Verizon的报告里面显示，有24%的这种数据泄露行为都是由于密钥的泄露导致的，有77%是因为被盗密钥去攻击外部的系统。

账号的密钥如此重要，在云下系统如此重要，云上不仅仅面临同样的密钥保护的问题，还有更多的身份管理问题，云上的身份和云下的身份如何统一？比如员工入职以后，在员工系统里面创建好员工账号，因为他要访问云上服务，同时也配置了云上的账号，一旦员工发生离职，这个账号有没有被回收，企业内部还有多少账号能够被离职员工去访问，同样多少员工使用云账号还是弱密码，可能已经泄露密码，多少员工没有被设置MFC，同样还有一个场景，员工刚入职的时候，可能遵循最佳实践去设置好复杂的密码，设置MFA分配的最小权限，但随着使用过程中，由于权限申请比较复杂或者比较麻烦，可能产生共用账号情况，产生这种共用账号的情况面临一个问题，云上的操作到底是谁在做，如何去审计它，整个身份的治理或一个云上账号的使用治理，是一个商减的过程，需要持续的投入治理中，如果没有投入，如何知道云上的账号有多少被共用、多少的账号没办法责任到人。

 

二、阿里云单账号身份体系

阿里云上提供怎样的身份的体系来解决上述的问题。云上的身份访问，归根结底分为两类，一类是通过浏览器和APP去访问控制台。通过控制台管理云上的服务，登录控制台的时候，基本上通过用户名密码进行一次的认证，通过MFC多因素认证，比如手机邮箱、虚拟MFA、UTF等设备进行二次认证，也有可能通过SSO进行无密钥的认证。另外一种方式是通过系统集成API，企业使用自己的应用系统去集成云产品的API，也有像使用的IACC工具，例如的telephone form、IOS对云上的资源进行自动化的管控，这个时候它实际上使用了永久密钥和临时密钥，永久AK和临时AK。

接下来将分享主要是集中在身份体系和控制台的访问部分，对于API访问的密钥管理，会由同事给大家分享。正常情况下，企业在上云之前可能会通过well art进行详细的账号规划、网络规划或者一些材质的规划等等，也有可能有些用户是想购买一些资源搭建系统，有可能部分用户只是想买一台无影搭台。真正在规划后、实施上面第一步的时候，第一步是注册云账号，云账号是一个资源的基本跟离单位，云账号下面的资源别的账号不能访问，同样也不能访问别的账号下面的资源，这是一个资源隔离的基本单位，同时购买资源是归属于云账号本身，不属于别的账号，也不属于云账号下面的任意的一个身份。

第三点既然它是这个资源的owner，理所当然的为他的资源的使用付费，它是资源计量计费的主体，第四点是最为重要的一点，主账号对他旗下的资源有完全的管控权限，它是一个root账号，这也是称之云账号为root账号或者跟账号或者主账号的原因，往往高权限的账号伴随高风险，对于高风险的账号，正常情况下，企业的员工可能会共享的账号，使用相同云账号的相同密钥去访问云资源，比如新员工入职，直接把主账号的账号名、密钥交给他，不需要去做任何的额外管理动作，员工持有了账号，他直接可以拿着这个账号的密钥访问到云上服务，因为他是root账号，他不需要任何的权限的申请，他可以一键搞定他想做的事情，看起来管理很方便，不需要做额外的配置，员工使用起来也方便，一键搞定自己想做的工作，但这是正常情况下，访问更多的是像异常情况的蝴蝶效应，异常情况比如现在是一个测试的同学，测完压测以后，只想去释放的一个测试资源，但是不小心释放了线上资源，并不是有意去做，研发只想上台，上机器去看一下的服务，但是发现使用OSS能看到客户的数据，对于这种小秘密总是有分享的欲望，把这种数据分享出去以后，造成客户的数据泄露，会产生更多的安全风险。

同时还有一个问题，因为很多的员工在共享使用这一个账号，在云上产生的这些异常操作，如何去审计它，可能觉得云上提供IT这种服务能够审计到，但并不然，只能审计到的确是这个云账号在什么时间，通过什么UA什么IP来操作的什么动作，但是真正的归因到某一个操作人，可能需要花费大量的时间去对账，谁在什么时间登录进来，做了什么事情，需要花费大量的成本去做，无法审计，无法分权会导致企业不合规，这种不合规是企业每个企业都不可接受的，所以对于这样的账号，不要在日常生活工作中去使用。两条解决路径，一条路径是如何保护它，减少它的高权限账号使用，另一条路径是寻求一种可分权、可被审计的账号体系来替代它。保护分两个方面，第一个方面是密钥的保护，第二个方面是密钥使用的保护。这罗列很多如何保护账号的密钥，但实际上企业用户的治理模型中有更多的定义。重点配置MFA，为什么配置MFA，因为可能按照最佳实际上要求给主账号设置一个强度很高的密码，比如数字大小写字母符号等等，但可能记不住，记不住的时候可能会记在小纸条上，或者记在笔记里面，一旦小纸条和笔记泄露，密钥也会泄露。正常情况下倾向于在不同的网站上使用同账号的时候，会设置相同的密码。

别的网站的密钥丢失了，自己的密钥也丢失了，所以这个时候如果配置了MFA，相当于在密钥的另外一层面上加一层保护，即使密钥丢了、密码丢了，MFA还在，同样登录不了这个账号。下一个关于密钥使用保护，正如平时使用Linux系统，如果登录root用户，都会提醒一句，权利越大责任越大，需要仔细的考虑下一步的动作是什么，主账号能够管理他旗下所有资源，核心的资产，需要把他的密钥分开保护，比如两个团队，一个团队持有登录密码，一个团队持有的MFA，如果一旦要使用账号的时候，需要两个人同意，也尽量减少了这种账号被耐用的风险，同时，可以使用的ActionTrail，企业用云治理成熟度工具定期的审计主账号的使用情况，定期的观测主账号的配置情况，持续的合规是一件很难的事情，云上提供了这样的一个工具去帮助大家，右边的这幅图，上面也提到了个主账号的一些治理工作，更多的一些工作大家可以到云治理平台使用。

第二点是使用的RAM用户的身份来实现的可分权、可审计的管理。RAM用户是主账号下面的一个独立身份，它有独立的名称，意味着他可以被审计，它有独立的密钥，独立的密码，独立的MFA，它也可以被授予信誉度的访问权限，这样的一个账号体系，已经满足可审计和可分权的功能，但是在实际使用中，刚才提到的不使用主账号，使用RAM用户如何使用？首先第一点需要创建一个RAM的admin权限的用户去替代主账号，行使主账号的管理动作，同时要避免人员和程序共用账号，因为人员账号一旦遗失以后，可能能把这个账号登录给禁用掉，账号给删除掉，但一旦共用了以后，发现这把永久AK如何去把它删掉，但删不掉，因为现在的系统在用，一旦删掉可能会导致现场系统故障。

当员工离职的时候，发现这个账号的确删不掉，首先把他的登录给禁用掉，其次可以使用AK的白名单去限制AK访问的范围，尽可能的降低泄露带来的风险。除了刚刚提到的RAM用户有着独立的账号名称，可被信誉度授权的特征以外，还可以在统一的层面上管理这个用户的密钥配置的策略，以及登录的一些策略，比如可以定义它的密钥的长度，比如是否一定要有特殊符号，它的长度是多少、它的登录时间是怎样等，可以在统一的层面上去管理它。

在使用RAM用户过程中，员工入职或者离职的时候，需要手动操作，同样云上还有一把密钥，让RAM用户可以直接登录，有没有办法可以通过自动化的方式去创建RAM用户，删除RAM用户，以及在云上去掉这个用户的密钥，答案是有的，在企业有自己的IDP的前提下，比如本地的AD或者是云上的IDP的服务，可以通过IDP到云上到RAM服务去配置SSO的方式，将认证托管到的企业的IDP，通过scheme的协议将用户的生命周期托管到IDP里面去，当用户入职的时候，或者员工入职的时候，在本地系统里面创建好用户，通过steam协议把用户自动的同步到云上。当员工发生登录的行为的时候，本地登录完，通过的SAML协议SSO到的云上，云上不需要为这个用户保留密钥，这个时候用户自己创建一个密码，在用户SSO前提下，员工创建了密码也不允许他使用密钥登录，他必须使用SSO的登录方式。

RAM的用户已经能够很好的支撑分权管理和可审计的需求，是否能够满足所有的需求。这样的一个场景，如果账号可能是一家代运维的公司，希望能够访问别的账号里面的资源，正常情况下像云账号A，它是一家他持有资源，希望云账号B来访问，云账号A给云账号B颁发一个RAM用户分配好权限，已经满足需求，但实际上当代运营的账号比较多，假设有100个账号的时候，对云账号B同时管理100个用户的密钥。云账号B管理的100个密钥的时候，分享给他的员工也是直接分享他的账号和密钥，如果员工发生了离职，对于云账号A，用户的密钥会被泄露掉，一旦发生轮转需要，同时到云账号B去，每一个人去把密钥给轮转掉，这个时候对于云账号B密钥，这个管理程度是十分的复杂的，对于云账号A，它实际上是存在风险的。

另外一个场景也是真实遇到的场景，企业想使用SSO的时候，但是由于企业本身法规的要求和公司所在地法规的要求，不允许同步员工账号到云上，因为员工账号前面可能是名字的缩写和后面是公司的预邮箱，不允许同步到云上，这个时候可以使用阿里云的RAM角色的身份，RAM角色的身份在阿里云上是一种独立的身份存在，跟RAM用户不一样的地方在于，RAM角色身份是没有访问密钥的，没有密码，没有永久的密码，没有永久的AK等，但它也有自己的独立的角色名，也可以被可以被单独的审计，还可以配置可信实体，可信实体是原本RAM用户是信任主账号，但是在角色的场景下，可以信任别的主账号，别的云服务、别的身份提供商，在使用这个角色的时候，可以通过可信实体拿自己的凭证去获取这个角色的临时密钥。

可信实体到底是什么？RAM角色到底是跟现在理解的通常意义上的角色是什么，有什么区别？通常意义上的角色可能是一个权限的集合，比如现在是一个研发，对服务器有访问的权限，现在是一个运维，可能对服务器的生命周期有管理的权限，对网络设备可能有操作的权限，如果是在develops，可能对所有的都能操作，对于角色，因为它是一个独立的身份存在。假设这样一个场景云账号B想要云账号A访问，这个时候创建一个RAM角色，相当于创建了一份委托。委托书里面定义了云账号A能做什么事情，相当于RAM权限，委托的对象比如委托给云账号A，委托给一个身份提供商，委托一个服务，是可信实体，当云账号A拿着自己的密钥来访问的云账号B的资源的时候，这个时候相当于云账号A扮演云账号的角色，拿到临时的密钥去访问控制台。同时在访问的时候，可以设置员工的身份，可以审计到哪个员工扮演哪一个角色。

在使用SSO的场景，跨账号访问的场景实际上可信实体是另外一个云账号，如果可信实体是身份提供商的时候，也可以使用SAML SSO角色，阿里云的RAM服务，把SAML协议和OIDC协议IDP抽象为一个身份提供商实体，表示外部的身份服务。当配置比如员工本地或者云上的IDP作为外部服务，可以在员工IDP侧的用户关联到角色以及IDP上。在云上定义了N多个角色，每个角色的身份提供商是云服务的IDP、客户自己的IDP。在用户侧为每个用户配置一个属性，属性是可以访问云上哪个账号IDP的身份提供商以及哪个账号角色，在发生SSO的过程中，可以指定使用哪一个属性来进行操作，可以有多个属性，多个属性的时候用户可以自己去选择，选择哪一个属性登到云上，同样在员工入职的时候，要分配权限，可以很简单的分配这一个属性，角色加上IDP都可以实现IDP侧到云上的IDP服务的认证，如果员工离职的时候，无需在云上把账号删除掉，只需要在自己本地的IDP内把属性关联关系删除掉即可。刚刚分享如何保护主账号的服务，主账号如何保护，如何管理RAM用户，管理RAM的角色，以及在RAM和角色上面的SSO行为，似乎已经能够完全满足对账号的管理诉求，但单账号的管理需求已经满足，多账号的管理需求场景下如何满足。

 

三、阿里云多账号身份

企业在使用RD去构建的多账号的身份体系，因为单账号已经很难满足于企业的不同业务的相互隔离的诉求，企业的规模越来越大，员工越来越多，业务越来越多发展，业务和业务之间是希望能够做到资源强隔离、成本分配的强隔离以及自主管理的需求，单个云账号下很难去做这样的事情，使用RD服务、资源管理目录的服务来完成这样多账号的建设，上云的时候，企业持有的企业管理账号RMA，在下面创建了业务资源夹和共享资源夹，业务资源夹下面为每一个业务创建单独资源目录，目录里面定义了两种账号，一种账号是测试的账号，一种账号是生产账号。同时把一些公共的服务，比如安全服务、日志服务，运维的这服务集中在每一个账号里面，假设是一个研发团队，要为业务A去做一些管理动作，或者研发动作，这样的情况下需要访问资源业务A的资源夹下面的生产账号和测试账号，同时要访问共享资源夹下面的日志账号，安全账号、监控账号、运维账号。

这个时候如果按照单账号的配置模式下，很显然要为每一个账号配置SSO，配置RAM用户的同步，配置RAM用户的授权，这意味着每新增一个账号，管理员要去做一遍同样的工作，当员工发生离职的时候，需要到每一个账号里面把权限给去掉，这个管理工作实际上是非常的痛苦，管理工作去掉以后并没有结束了，因为没有一个统一的视角去看到自己的操作是否正确，需要到每一个账号里面去观测，是否正确。

账号治理实际上是一个商检的过程，需要不停的付足努力治理它，时间长了以后，权限是不是跟管理员理解的是一样。很有可能是企业自己开发一套系统，去看权限配置是否正确，每个企业都这做成本是非常高的，阿里云测提供了一个工具去满足多账号场景下员工权限统一配置的问题，云SSO产品，云SSO产品实际上它是一个和资源目录和RAM的服务去集成产品，企业IDP可以通过标准协议，比如SAML协议，SSO服务跟云SSO的目录去集成，把用户同步到云上，把认证托管到的IP测，到云上以后，用户可以通过访问配置和用户同步配置，把权限的配置，把用户同步到指定的账号里面，使用的场景下不仅是在控制台上可以去做访问操作，同时也可以在CLI里面做跨账号的访问，同时又不需要配置永久的密钥。

具体如何做，第一个是关于云SSO访问配置，访问配置是一个定义的模板，它包含了权限、登录的一些配置，比如包含了有20个RAM的系统policy，包含了一个RAM的自定义policy，同时它也定义登录的时长，登录默认的访问页，定义完成以后，下一步做权限访问配置的部署动作，选择要访问哪一个账号，把这样的访问配置定义部署到账号里面，部署的时候首先在账号里面创建好一个角色，角色上授予的权限是访问模板里面定义的RAM的权限，配置的可信实体是云SSO的IDP。配置好后，把云SSO的用户跟这样的部署关联起来，形成一个三元组。

用户组加上访问配置，加上访问的目标账号，授权三元组，使用的时候可以拿到用户名和密码，直接在控制台上使用，用项目SSO的方式登录到每一个账号里面去。这个是访问配置的相关工作，对于一些SaaS的产品，它实际上需要比较强的身份认知，更想用RAM的用户去实现管理和使用的操作，这个时候可以使用用户同步配置，把用户同步到每个账号里面，用户同步配置定义了两条策略，一条策略是同步用户时的冲突策略，一条策略是解除同步时候的删除策略，如果把用户从云SSO同步到每个账号里面去的时候，发现用户名冲突的，可以选择保留原有的用户，新建一个新的用户，也可以选择把现有的用户接管过来，成为cloud SSO管理的用户。

另外一种情况是员工离职以后，要撤销用户的访问授权，这个时候可以选择删除已经同步的用户，以及保留原有的用户，为了防止可能有一些像人员身份和密钥身份共通的情况，配置好访问策略以后，下一步是部署用户同步配置，用户同步配置跟访问策略类似，部署的时候可以选择指定的账号部署，部署的同时在RAM的产品里面创建好同名的RAM用户。

第二步是配置好身份提供商为cloud SSO。用户可以用用户SSO的方式登录到每个账号里面去，下面通过一段DEMO来演示整体的过程，配置的动作是cloud SSO DEMO这个用户现在被插入到两个组里面，一个组是的RamAdminGroup，一个组是GlobalReadOnlyGroup，RamAdminGroup对管理账号具有完全的访问权限。GlobalReadOnlyGroup实际上对资源账号以及管理账号有只读的权限，配置完成权限后，可能要使用控制台CLI来访问到具体的账号里面，首先来看一下配置过程，用RAM SSO Admin管理用户先做配置，先登录输入密码，验证MFA，这是一个U2F的MFC。验证完成以后，登录到控制台，Cloud SSO管控控制台有DEMO用户，这个用户被加入到2组，一组是的RamAdminGroup，一组是GlobalReadOnlyGroup，分别看一下这两个组。这两个组现在没有一个授权，RamAdmin没有被授权，ReadOnlyGroup也没有被授权。下面看一下访问配置，已经创建好两个访问配置，一个是ReadOnly访问配置，它是绑上了RAM的ReadOnlyAccess这样的配置，同时内置一个策略，内置的策略是默认禁止掉对RAM产品的所有的操作点，他没有部署。

再看另外一个它绑上了两个系统策略，一个是ReadOnlyAccess, 一个是RAM的FulAccess，没有内置策略，没有被部署。下面进行多账号的部署。首先选择目标账号，RD管理账号以及监控账号。选择指定的用户组，先选择GlobalReadOnly用户组，选择GlobalReadOnly权限，GlobalReadOnly权限有只读的权限，但没有RAM的操作权限，检查一下。针对于目标的账号，管理账号和监控账号，选择要部署的用户组，选择访问配置，开始配置，会自动在每个账号里面实施刚才提到的创建RAM角色创建身份的动作。

点击完成，进行另外一个账号的配置。对于RD管理账号的配置，要配置RAM admin权限，选择RAM admin用户组，选择RAM admin访问策略。检查一下要配置的内容，开始配置，看到正在配置中，这个时候配置完成以后，再从统一的视角去看刚才配置是否正确，回到用户组，点击RAM admin用户组，查看权限，可以看到对RD的账号有RAM admin访问的权限。再看另外一个用户组，只读的用户组，对两个账号都只有只读的权限。到此为止，已经把账号配置好了，下面是要使用云SSO的用户进行访问，在管控页面把链接、登录的地址复制，输入用户名和密码，点击登录。这时候使用的是虚拟MFA设备进行二次认证。

在这里面可以看到，cloud SSO的DEMO用户被授予了两个账号的访问的权限，每个账号的访问内容，第一个是管理账号，具有RAM admin的权限，有global的访问权限，第二个账号只有GlobalReadOnly的访问权限，尝试了一下，使用GlobalReadOnly访问监控账号，登录到办公控制台，输入RAM的控制台，刚才实际上在GlobalReadOnly权限里面把RAM的操作全部禁掉了，包括只读，这时候提示是没有权限的。换另外一个账号，对管理账号使用RAM admin访问配置去访问指定的账号，登记到RAM控制台。

实际上已经有数据显示，在整个过程中，云SSO的用户被分配好访问每个账号的权限以后，在控制台的访问操作。下面可能是大家比较关心如何在CLI通过无密钥的方式去访问，首先先进行配置，把登录地址配置进去，下一步测试整个使用过程，直接执行登录命令，登录命令会自动的打开登录页面，需要输入刚才配置好的cloudssodemo这个用户的用户名和密码，同样的使用MFA校验。校验完成以后，会提示您即将使用阿里云的CLI，请确认是否登录，点击确认。确认完成以后，到CLI的界面里面看到有两个账号的访问权限，可以任意选择，选择管理账号，选择GlobalOnly的访问配置。

选择完成以后，把密钥展示出来，这个密钥已经过期了，大家随意享用，下一步是配置好CLI，选择external模式，把刚才的登录命令输入进去，选择对应的region，这是一些基本的配置格式，配置成功，配置成功以后使用STS接口，来测试一下当前的账号的身份是什么。能够看到当前账号的身份是访问到有具有GlobalReaOnly的权限的cloudssodemo用户，这里面可以看到cloudssodemo这个用户实际上是最终执行操作的用户，可以通过这个去做用户的操作审计。

 

四、总结

阿里云的身份体系，对于单账号的场景，提到主账号的密钥是如何保护；对于RAM的用户，提供了一个独立的身份，能够被审计、分权的管理；对于RAM的角色，可以使用跨账号的管理模式，同时把信用托管给企业IDP做RAM角色的SSO；对于多账号访问的场景，使用统一的访问配置，以及用户同步的配置，去执行用户同步以及多账号的访问统一管理的动作，对于这些账号体系，使用完成、配置完成后，下一步使用的时候必不可少要使用到密钥。对于密钥管理和密钥使用的基本操作和最佳实践由其他同事为大家带来具体的分享。