摘要：越来越多的企业客户开始迁云，然而客户上云后所反馈最多的一类问题就是云资源的管理问题。究其原因，我们发现本质问题是企业上云的云账号规划问题。于是产出本文，首先介绍阿里云账号的基本概念及其功能，然后全面解释阿里云所提供的四种云资源管理基础模型，最后再提供一个案例分析，以帮助上云客户有效解决云资源的安全管理问题。
认识云账号
云账号又称租户账号，它是阿里云客户的身份标识。要正确理解一个云账号，我们需要从四个方面来看：
- 云账号是多租户资源隔离的基本主体。在云平台上，不同客户所购买的云资源是默认隔离的，比如，账号A在ECS上购买的虚拟机在默认时不会被其它云账号看见。
- 云账号是云资源的属主(ResourceOwner)。任何云资源都有唯一的属主，该属主就是云账号，属主将要确保对所租用资源的合规、合法使用。
- 云账号是云资源使用计量及财务结算主体。云账号具有独立的财务管理能力，比如申请信用额度、充值续费、账单结算、开具发票等。
- 云账号是云资源的权限管理员(root)。云账号是资源的属主，对资源拥有完全控制权限，而且可以将这些权限授予给其他用户。
多个云账号的财务关联
对于多个完全独立的云账号而言，每个云账号进行独立的财务结算可能会导致较高的管理成本。为此，阿里云提供了云财务管理功能，它支持将多个独立的云账号进行财务关联，可以对多个云账号进行合并计费、合并账单、以及共享资金和信用额度。对此有需求的客户可以访问 云财务管理控制台 。
注意：尽管云财务管理提供对多个账号的财务合并管理功能，但不同账号之家的资源仍然是完全隔离的。多账号的财务合并管理并不会打破多租户资源隔离这一基本原则。
云资源管理模型
Type-I：单账号模型
这是企业上云的原始模型。该模型仅仅依赖云账号所提供的基础功能，如下图所示：
适用场景：
- 单个项目上云
- 单用户使用与管理
- 仅适合于个人学习或测试场景
__注意：__由于该模型没有遵循最佳安全实践，我们不推荐任何企业客户使用，而强烈建议客户使用Type-III（单账号+RAM）模型来取代该模型。
Type-II：“多账号+合并财务管理”模型
该模型支持多个云账号以及多账号的合并财务管理，比较适合于多个独立项目或子公司上云的场景，不同项目或子公司的机器/网络资源无需互通，并且希望在财务方面能提供统一结算、合并账单、统一开票、共享资金和信用额度等功能。
模型描述如下图所示：
适用场景：
- 集团型企业，多个子公司上云
- 不同子公司资源隔离，网络或机器不需要互通
- 需要合并不同子公司的账单、支付和开票管理
- 每个子公司有独立的运维管理员
Type-III：“单账号+RAM”模型
该模型是对Type-I模型的安全增强。Type-I模型的主要缺点是多用户场景下不得不共享“主账号”或“大AK”而导致极大的安全风险。通常对一个企业客户来说，云资源的使用和运维管理都存在多用户场景，需要能支持多用户管理、细粒度授权管理与风险控制管理。RAM服务是阿里云提供的多用户管理与访问控制服务，它能很好的满足云计算业界最佳安全实践标准。模型描述如下图所示：
适用场景：
- 普通企业单项目上云
- 多用户运维管理，实现不同职责的权限分离
- 最佳安全实践，满足最小权限原则
Type-IV: “单账号+RAM+资源组管理”模型
由于我们越来越多的企业业务开始迁云，一个云账号下拥有上千个ECS实例、RDS实例以及PB级存储已成为普遍场景。由于缺少资源分组以及基于分组的自治权限管理，上文描述的Type-III模型将无法应对此类场景。Type-IV模型正是以解决此类大规模资源管理场景为目标，基于Type-III模型能力进行扩展，增加了资源管理服务，提供云资源的分组管理、分级授权管理、以及面向资源组的账单管理。模型描述如下图所示：
适用场景：
- 普通企业多项目上云
- 资源按项目进行分组管理
- 每个项目分组可以实现独立的分级权限管理
- 多用户运维，实现不同职责的权限分离
- 最佳安全实践，满足最小权限原则
- 按照项目分组维度查看账单
选择单账号，还是多账号？
有了上述四种基础模型，很大程度上能直接满足大部分的客户场景。然而有的企业客户场景和需求比较复杂，而且业务模型也可能不断演变，所以有时候并不能给出一个绝对正确的方案。
比如，很多客户可能都会问到 —— “我的企业到底应该使用单个账号还是多个账号呢？” 但这个问题并没有一个千篇一律的标准答案。很多企业可能已经创建了多个账号，那么也许只能沿着多账号结构继续走下去（因为跨账号资源过户及数据迁移是一件更加挑战的事情）。如果你的企业正在规划上云的账号结构，那么如下建议可供参考。
__如果你的企业在财务管理或安全管理方面有如下诉求，那么建议使用多账号结构__:
- 不同BU (business unit) 或 CC (cost center) 之间的成本预算和账单消费要求100%的隔离，比如部门A的花费不能记在部门B的账上。
- 不同项目之间或运行环境之间需要做到*别的资源和安全隔离，比如要求“开发环境”与“生产环境”有严格的资源隔离和清晰的安全边界。
客户案例分析
我们提供的上述四种基本模型，很大程度上就能直接满足大部分的客户场景。然而有的企业客户场景和需求比较复杂，需要足够理解这四种模型的优劣之后才能得到有效的解决方案。
如下是一个真实的客户案例：
企业A有超过1万员工，有企业本地数据中心，信息安全系统健全，企业内部正在使用Windows AD进行员工域账号管理。企业有10个新项目要上云，平均每个项目大约需要50台ECS虚拟机及其它相关云资源，目前各个项目的资源不需要互通，但希望后续也能支持互通的可能性。希望每个项目能有独立的管理员，项目管理员能独立管理项目资源、项目成员及其权限管理。所有云资源操作人员要求使用企业本地域账号认证，禁止绕过企业本地身份认证系统而直接操作云资源。所有项目希望能合并记账，统一支付和账单管理。
针对这个客户场景，简单方案是采用Type-II模型（多账号+合并财务管理）。比如，一共申请11个云账号，每个项目对应一个云账号，最后一个云账号用于合并财务管理。然而，这一做法存在的问题有两个：(1) 如果企业未来需要实现不同项目的资源互通，尽管技术上存在可行性，但会导致相当高的管理成本；(2) 由于要实现与企业本地AD系统的身份联盟，那么就要在11个云账号下都开通RAM，域账号数据同步到每个RAM，并且还要为每个RAM都配置外部账号SSO，这也会导致相当高的技术管理成本。
因此我们会推荐采用Type-IV模型（单账号+RAM+资源组管理）来解决该客户场景问题：客户一共只需要申请1个云账号，开启RAM服务，企业域账号同步到RAM，并在RAM中开启使用外部账号SSO。在这个云账号下创建10个项目，为不同项目设置独立的管理员，那么管理员可以自治管理项目的资源和权限。云财务管理系统也将为客户提供基于资源组维度的账单管理和财务功能，因此可以更好地满足客户需要，真正有效地降低客户上云的安全管理成本。
结语
基于多租户的云资源管理与传统的企业资源管理有着本质的差别。上云之前，客户只有充分理解了云平台所提供的云资源管理模型和能力时，迁云才可能是一件充满无限魅力的事情。