谈身份管理之进阶篇 - 快速了解从管理到治理的最佳方案-LMLPHP

引言

云上身份安全是当今企业管理者和云上运维团队所面临的挑战之一。例如员工离职后发现权限未收回,恶意删除了大规模应用造成企业损失惨重;又比如员工密钥泄露导致被恶意攻击,造成数据泄漏,服务中断等影响。这些真实且震撼的案例还有许多,针对云上身份管理不全面所产生的风险究竟又哪些?又应当如何应对?本文将结合案例和最佳实践与您分享。

从员工入职到离职,进行账号的全生命周期管理

典型场景一

员工离职是一个典型的身份管理场景, 员工离职后,企业没有回收或清理员工对于账号的访问,离职的员工依然可以持续访问和管控企业在云上的资源和数据。将直接导致企业的数据泄漏;如果离职员工蓄意破坏,将直接导致企业的服务中断,造成企业形象、经济损失。

如何回收离职员工的访问权限?遵循「先禁用,后删除」原则

1. 禁用离职员工账号的控制台登录。

禁用控制台登录会较快的将共用账号的问题暴露出来。如果存在共用的情况,首先重置密码止血,再为共用的员工分配新账号。

2. 查看离职员工账号下是否持有永久AK。

如果有,则先冻结AK的访问。员工的账号中的AK是不能用在生产系统中。如果不确定员工账号下的AK是否有在生产系统中使用,可以在用户的AK列表中查看最近使用时间。如果某把AK最近访问时间至今已经有一段时间,则可以放心禁用。如果上一次访问之间至今时间较短。则可以配合ActionTrail的能力,排查访问的服务,以确认是否有使用在生产系统中。如果有使用,则尽快做轮转。

3. 先禁用再删除。

在禁用完离职员工账号访问控制台以及API的访问能力后,通过ActionTrail服务的能力,持续监控一段时间是否有活跃,如果在一段时间内没有活跃动作(登录或API调用),则可将用户及其密钥删除。

典型场景二

企业员工在使用阿里云RAM用户的时候,会设置用户的密码作为登录控制台的凭证。可能由于密码保存不当,共享密码、被钓鱼等方式造成泄漏。通过审计的方式发现有异常登录的情况,或者发现有不熟悉的IAM账号,非自己创建的资源等。均有可能是密码泄漏导致。密码泄漏的问题可导致攻击者冒充员工身份进行资源创建和删除操作,数据读取等操作。造成数据泄漏,服务中断等影响。

如何处置员工密码泄漏?两步快速止血

1. 通过重置用户的密码进行登录阻断,防止攻击者使用已经泄漏的密码进一步登录。

2. 通过审计日志检查是否有新创建的账号或AK。如果有,则对新生成的账号禁用登录,并禁用AK。

如何防止密码泄漏?三招降低风险

1. 加强密码本身保护是重中之重,从创建用户那刻开始:

  • 设置足够的密码强度,设置密码复用的限制。减少弱密码或旧密码的时候
  • 设置密码的过期时间,定期更换密码。
  • 对于登录密码错误设置严格的阻断策略。一段时间内密码错误次数过多将冻结登录。

2. 登录保护,启用MFA:

MFA为除密码以外的新的认证因素。当用户密码严重通过后,还需要输入正确的MFA Code才可以验证通过。阿里云的MFA是基于TOTP协议的动态口令,每30秒生成一个新的6位数口令。当密码泄漏被攻击者使用,攻击者无法获取MFA动态口令也将导致登录失败。

3. 审计异常的登录行为:

通过ActionTrail中的登录成功和失败的日志,通过UA,IP等方式定位疑似异常登录行为的用户。并通过重置密码,启用MFA等方式进行保护。

在阿里云,进行员工入职,离职场景身份管理的最佳实践

一家企业的员工入职和离职,涉及到分配云平台的账号的时候。云上的账号身份的生命周期管理需要和本地的员工的身份管理统一处理。

用户入职

  • 分配新账号:通过阿里云控制台或集成IMS OpenAPI同步创建用户,不要与其他用户共用,否则将导致不可审计,无法回收权限的问题。
  • 为账号分配密码:在目录级别配置密码强度及合适的密码生命周期,为用户创建合适的密码,开启MFA,配置合适的登录策略
  • 为账号分配密钥:区分员工使用的账号和服务使用的账号,员工使用的账号开启永久AK,使用CloudShell替代。服务使用的账号保护好AK Secret,有条件定期做轮转。

员工离职

  • 遵循先禁用,后删除的原则,禁用用户的控制台登录,禁用用户的AK,有问题可及时回滚配置。
  • 通过OpenAPI的方式集成在本地IDP,或通过控制台的方式进行关联操作。
  • 离职员工删除:人员离职一段时间后,通过CredentialReport和ActionTrail的审计日志确认不活跃后,删除不活跃的账号和AK。

生命周期内定期审计

使用ActionTrail和CredentialReport,对员工的账号活跃度以及操作记录做持续审计,发现不活跃的账号并及时整改。

一劳永逸的解决身份管理和认证的统一问题

通常在企业内,分配和回收员工的工作由HR的系统触发,(或企业自己的云管平台触发),上云账号的管理员/系统接受到了这个事件后,人肉/系统自动分配或回收用户的登录权限。但是这里可能要依赖人肉管理,或依赖企业开发系统去实现。因此也给企业的管理带来了额外的管理和研发审计的成本。一旦忘记操作或系统存在bug,将给企业的数据安全和生产稳定性带来风险。

那么,有没有更好的办法,不额外给员工颁发阿里云RAM用户的登录密码,将登录认证集中在企业本地的员工系统?答案是有的,企业可以通过使用以下两种方式将身份管理和身份认证统一到本地IDP进行集中管理:

方案一:使用SSO将身份认证统一到本地IDP。

阿里云作为SP(Service provider),支持SAML协议。企业本地身份系统可以使用SAML 协议,打通本地到云上的控制台访问。无需在云上额外的为用户配置访问控制台的认证方式。

企业的管理员首先配置好企业本地IDP和阿里云账号的信任关系,用户在企业本地IDP认证完成后,企业IDP向阿里云发起SAML SSO。基于配置好的信任关系,阿里云侧按照SAML SSO中描述的身份信息和session信息生成登录态。完成了指定身份的登录。目前登录行为包含两种方式:

1)基于RAM用户的SAML SSO

企业用户通过OpenAPI或SCIM将企业员工的信息同步到云上,通过SAML Response中指定的用户确定阿里云RAM的用户,以指定用户的身份登录到阿里云上。好处是以RAM用户的身份登录到阿里云的控制台,权限可以根据用户做定制。

2)基于RAM角色的SAML SSO

企业通过OpenAPI或控制台创建角色并授予权限,通过SAML Response中指定的角色确定阿里云的RAM的角色,以指定角色的身份登录到阿里云上。好处是以RAM角色的身份登录到阿里云的控制台,无需配置额外的身份,企业员工可以共用角色。

企业基于这两种方式SSO到阿里云控制台,只需在本地的IDP维护认证信息,无需为员工在阿里云的RAM账号上创建密码。员工只需要保管好自己在企业IDP中的密码即可。同时当员工发生离职后,企业只需要回收本地员工的账号,员工无法直接访问云端的账号。

方案二:使用IMS OpenAPI/SCIM将员工身份管理统一到本地IDP

  • IMS 提供OpenAPI供企业管理系统集成,当本地员工发生入职,离职或调岗的时候,可以通过IMS 的OpenAPI在云端进行异步的管理动作。
  • 企业服务如果支持SCIM,可以通过RAM提供的SCIM接口,自动的管理用户的新增和删除操作。(员工对应的账号的AK不要用于生产系统,如果企业员工发生离职或者调岗,触发了云端账号的删除动作,将直接删除账号。对应的AK一并删除。如果员工账号的AK用于生产系统,可能直接导致故障)。

总结

阿里云企业IT治理身份管理高级技术专家冬山结合产品研发和客户服务的经验总结了核心原则:“对于身份管理的最佳实践,核心是『统一管理身份和认证』,并『进行定期的用户认证审计』。”

原文链接

本文为阿里云原创内容,未经允许不得转载。

03-14 01:52