后续随着业务的飞速扩张，云上的账号体系也必将越来越复杂。且业务上云后，传统IT中的中心化托管不再适用，中心运维团队需要下放运维身份和权限给业务团队，以支持更灵活的运维模式。

在上云最初制定并实施治理基线，可避免在规模壮大后可能出现的人员冗杂、权限难以梳理、账号无法清退的困境。避免因低效混乱的账号管理遭受恶意访问和攻击。

例如：某知名证券企业在上云之初时，仅在云上部署测试单元，共注册了3个主账号分别用作测试账号、生产账号和审计账号。在没有具体业务上云的情况下，事先在云上实施了身份权限的风险治理。

具体要求如下：

  • 仅允许白名单内的子账号和角色可以在云上进行管控操作。那么，即便子账号和角色被创建出来，也可以利用白名单约束其活动。
  • 根账号和具备较高权限的子账号必须开启多因素认证（MFA）认证，强制高权限账号必须开启多因素认证。
  • 必须采用强密码策略。
  • 当认证协议和密码策略发生变更时需收到告警，这是对身份权限管理策略的强监管。
  • 将所有账号的操作事件统一归集到权限隔离的审计账号，并做安全分析。

该企业在后续长期的运营中，主账号增长到15个，活跃的子账号超过70个。中心运维团队下放管控权限给业务团队和第三方服务商。在企业内部建立了一套账号变更管理流程，当发生人员离职、人员组织架构变动、人员变更归属项目时，分别对云上活跃账号白名单及子账号归属的用户组进行变更，实现云上身份权限的缜密管理。

应对的风险

不同的企业管理模式可能导致身份权限管理中面对不同的风险，常见的风险如下：

  • 高权限风险。活跃的管控账号直接为主账号或具备管理员权限的子账号，可能给运维人员的误操作提供了更大的空间，对资源错误的变更、释放、主机升级都可能造成业务中断。
  • 较弱的认证机制和密码策略。这可能增加账号被盗用的可能性，进而遭到恶意破坏和数据窃取。
  • 闲置的有效账号。长期闲置的具备一定权限的账号可能是离职员工的曾用账号，闲置账号不及时回收可能成为安全管理的盲区，被恶意利用。
  • 缺乏操作审计监管。企业不监控和收集云上的访问事件，将无法及时发现访问事件背后的恶意意图，如高频的登录失败、无权限访问、异常访问等。在真正发生恶意操作后也难以复盘和追责。

随着业务的发展壮大，云上的IT管理人员、IT规模、业务复杂度都在成倍增长，企业应周期性审视身份权限管理的风险辨识，及时更新风险的定义并推进风险治理策略的升级实施。

风险评估

企业的权限管理人员在日常工作中可能需要解答下面几个问题：

  • 为什么需要进行身份权限风险治理？收益是什么？
  • 应该什么时候采取风险治理措施？

在实际工作中这两个问题需要结合起来看。身份权限治理的收益是靠风险可能造成的损失来衡量的，而风险可能造成多大的损失又取决于企业实际的身份权限管理复杂度。所以，当企业的身份权限管理复杂度达到一定程度时，企业业务的规模和复杂度也一定较高。此时权限过大、认证较弱的风险可能带来的业务损失也更大，那么“达到一定程度”时就是必须采取风险治理措施的时候，而这个“一定程度”每个企业会有所不同。

这里提供一些衡量指标的维度，企业可根据自身实际情况设定阈值：

  • 云上活跃的子账号数达到N个。
  • 云上活跃的子账号中具备较高权限的达到N个。
  • 云上需要管理的资源对象达到N个。
  • 云上需要管理的项目达到N个。
  • 曾发生账号盗用事件N次。
  • 出现身份认证失败超过N次。
  • 出现尝试越权访问而访问失败N次。
  • 需要将云上管控的身份权限委托给第三方服务商。

治理基线

企业应根据云上运维人员数量、运维人员的工作边界、需托管的业务数量、需托管的云上IT规模、具体托管的业务内容等实际情况来制定自己的身份权限治理基线，以下提供较通用的基线策略，可以作为参考：

  • 账号基本安全
    • 为云账号开启多因素认证（MFA）。
    • 避免使用主账号访问密钥（AK）。
  • 使用访问控制
    • 使用云平台的访问控制产品。避免直接使用主账号，通过创建子账号并授予最小必要权限来进行云上管控。
    • 为所有子账号开启多因素认证（MFA）。
    • 限定云上活跃的子账号和角色白名单。
    • 必须采用强密码策略。
      • 密码有效期不超过90天。
      • 密码最小长度不小于8。
      • 密码中必须包含大小写字母、数字、特殊符号。
      • 禁止使用前3次使用过的密码。
      • 一小时内最多允许输入5次错误密码进行登录。
    • 避免同一个子账号同时具备控制台登录权限和AK访问权限。
    • 避免存在空的用户组和未放入用户组的子账号，对用户组授权避免直接对子账号授权。
    • 避免长期存在未授权的子账号，或未绑定到子账号的权限策略。
    • 仅为有限的人员设置管理员权限，并严格禁止账号共享使用。
    • 预定义固定的用户名、角色名和相应权限，变更时收到告警并自动修复。
    • 使用Policy Conditions精确权限的生效条件，例如：
      • 使用IP条件，限制仅能在公司或通过VPN来管控阿里云资源。
      • 使用时间条件，限制仅允许在工作时间进行资源变更。
  • 充分审计
    • 将所有账号的操作事件统一归集到权限隔离的审计账号，并做安全分析。
    • 当认证协议和密码策略发现变更时需收到告警。
    • 当根账号活跃时收到告警。
    • 定期对比子账号实际操作行为和授权策略，避免冗余授权。
  • 持续治理
    • 使用云上具备监控和持续检测能力的治理工具。
    • 开启云平台推荐的治理基线，结合企业自身实际需求实现自定义策略。

治理基线的迭代与实施

企业需要在内部构建较强的监管流程保证身份权限治理策略被正确完整的实施。流程的可监管能力、可强制能力决定了身份权限治理策略实施的结果。在长期的身份权限治理工作中，企业需要根据业务的发展不断更新迭代身份权限治理基线，并通过流程从上而下地实施落地。同时还需要定期审视当前实施的治理策略，根据审视结果及时优化治理策略。