内容介绍：
一、云上的凭证
二、凭证的安全风险
三、凭证管理的最佳实践
本次分享的主题是凭证安全管理与治理实践。主要分为三个部分，即云上的凭证、凭证的安全风险以及凭证管理的最佳实践。
一、云上的凭证
1、什么是云上的凭证
简言之，凭证是通过认证证明使用者身份的一种凭据。类比演唱会购买门票，除提供实名购买的门票之外，还需提供身份证证明是购票者本人。同样，在云上访问资源时，我们也需要通过各种手段证明访问者的身份，以获得相应的访问权限。
常见的包括三类认证方式：第一类是“你知道什么”，即用户名、密码、身份证号码、密保等记忆类问题；第二类是“你有什么”，对于人员，包括绑定的手机、邮箱、笔记本电脑等常用设备，在程序访问时，每个程序通过绑定相应的密钥证书以加密的方式进行认证；第三类事“你是什么”，包括最常用的指纹、人脸等生物识别方式，这些识别方式具备相对较高的唯一性。在实现身份识别之后，即可根据操作者的身份分配不同的权限。
2、云上凭证和权限的关系
下图展示的是阿里云身份权限的简单原理结构：
当用户在阿里云创建云账号后，云账号就会成为用户云上资源的容器。同时，云账号默认拥有Root用户的身份，即创建时获得的用户名和密码，Root身份会使得用户拥有所有云资源的最高操作权限，因此，并不推荐用户使用Root身份。Root身份还可以创建出主账号的AccessKey，它是由应用调用API的一种长期的凭证，由于主账号有默认的最高权限，Root身份和主账号AccessKey的权限无法通过任何方式进行限制。我们对两种身份都做了标识，不推荐使用这两种身份访问云资源。
企业中包括各类型的人员，包括高级别高权限的管理员、运维和研发工作人员，应用程序，都可以通过访问控制产品的整套身份权限体系对云资源进行访问。无论是何种身份，都可以获得访问控制的用户或者角色身份。每次登录或访问时，都会通过一定的认证手段来确认身份，而身份可以绑定细粒力度的权限，包括在何种条件下能对哪些资源执行哪些操作等。这样，通过身份认证后，就可以确定访问者的身份，进而对资源、操作等实现云上身份和权限的分配管理。
3、阿里云管控面的凭证
管控面针对的是运维云资源的操作，对一些云产品，如数据库、服务器内部的操作等，都有相应数据面的身份权限，这部分由各个原产品自行管理。
关于管控面的凭证，前面提到，企业当中主要分为人员和程序两种管控访问云资源身份的方式，不同的身份有不同的认证方式。
（1）人员
推荐使用企业IdP的SSO单点登录集成。如果企业有自己的身份系统，员工可以通过个人在企业中的账号密码登录或免登直接访问阿里云控制台，更加安全。且员工就不需要再记忆一套阿里云控制台的身份和密码，进而减少两套密码同时存在时资源管理的难度，降低密码泄露的风险。
如果企业没有自身的身份系统，或不方便做身份单点登录集成，就可以使用访问控制产品的用户名、密码，同时也提供MFA多因素认证，利用双重认证的方式加强用户名、密码登录的安全性，进入控制台访问云资源。
（2）程序
程序访问最常使用两种类型的凭证。一是长期凭证AccessKey访问密钥，这是普通程序使用频率最高的。如果长期凭证一旦泄露，虽然本身可以持续使用，但其有一定的风险。另一种是使用STS Token临时凭证，其有效期相对更短，即使token泄露，也会在短期内失效，不法分子没有更长时间进行违规操作。若有少量运维人员，有调试程序的需要，也要为其分配AccessKey做线上调试。
二、凭证的安全风险
1、凭证泄露事件
这里介绍两个凭证泄露的真实事件。
第一，涉及日本的汽车巨头丰田。2022年，丰田在自有网站上面公开发表声明，公司的一项网站服务导致29万余用户的电子邮件信息的泄露。事件的起因是2017年一家负责业务开发的外包公司不小心将部分源代码上传到了公开的GitHub账户，导致凭证泄露，从而引起用户信息的泄露。该起事件的发生事件发生于代码泄露五年之后。
第二，是一种常见的泄露的场景，涉及到负责通信软件开发的PaaS平台。很多企业都会使用PaaS平台提供的开发套件开发相应的通信软件，由于开发人员的安全意识缺失，导致攻击者可通过获取开发人员在程序中硬密码的凭据，从而攻击应用程序中保存的用户数据，包括大量用户短信、通话记录等隐私信息。
2、凭证的安全风险
前面提到，人员访问控制台是通过账号密码，程序访问云资源是通过直接的API调用使用程序访问的凭证，两类主要的访问身份都有一定的凭证安全风险。
（1）人员
人员访问在密码管理上存在风险。由于使用弱密码，或未做好强密码策略要求，导致密码容易被泄露，若同时未绑定多因素认证，一旦密码泄露，不法分子可以直接通过密码访问资源。更常见的是管理上疏漏的场景，包括人员和程序的混用。一旦密码泄露，或人员恶意对外透露账号密码，同时会影响到线上已经运行的业务，造成更大范围的影响。此外，多人共用身份存在风险。企业中，员工之间信任度高，会存在通用账号的现象。但实际上，一旦发生泄露事件，由于共用账号，很难审计出泄露密码具体的身份，甚至无法审计泄露的源头，加大了管理的难度。
（2）程序
针对程序访问，有几个常见的问题。首先，身份权限管理不严，会对程序访问的AccessKey泄露造成更大的影响。主账号AccessKey的权限最大，且无法用任何方式限制，一旦泄露，基本上可以操作所有的云资源。另外，AccessKey如果长期不做轮转会增加暴露的风险。虽然轮转相对麻烦，需要定期在业务代码中替换旧的AccessKey，如果不做轮转，虽然可以正常使用，但使用时间越长，暴露的风险越大，越有由于人员的疏漏或部分过程中代码的分享等，导致AccessKey的泄露。
对应前面的两个案例，可以看到AccessKey泄露最常见的场景，包括在代码中硬编码AccessKey，研发员将源代码分享到共享的技术平台，源代码中包含了明文的AccessKey，开发的应用程序使用了安全管理存在漏洞的开发工具，都会导致入侵者盗取程序中写入的信息AccessKey。
3、如何发现凭证风险
经过前面的学习，可以发现在访问云资源时存在诸多风险。我们希望可以及时发现这些风险，从而快速修复，做好日常预防和规范管理。
推荐使用RAM访问控制和云治理中心两个产品，它们都提供了治理检测功能。两个产品提供的治理检测的检测项是一致的，都是针对身份凭证安全以及权限管理安全相应的身份检测项，一共23条。这些治理会在经用户授权的条件下，定期扫描账号的配置情况，会扫描得到风险配置、异常使用情况等说明，同时提供治理的方案，对修复现存风险提出合理化的建议，且全部免费。
三、凭证管理的最佳实践
1、凭证管理的基本原则
（1）基本原则
凭证管理的基本原则一共包括两条，即缩短暴露时长和缩小波动面积。
第一，AK（用户名密码凭证）使用时间越短，暴露可能性越低，若能够定期轮换密码和AK，使AK的有效期和生命周期相对更短，预防暴露。第二，缩小暴露面积，可使得凭证对应可访问的云资源、可执行的操作权限相对更小，即便凭证暴露，不法分子可执行的操作范围也较小。
在两条凭证管理的指导原则之下，凭证管理和治理最佳安全实践如下：
（2）最佳实践的内容
首先，不使用主账号AK，并对主账号Root身份的用户名密码开启MFA，做好安全防护。同时，对人员和程序的身份做分离（不将人员和成分放在同一用户身份），相应的人员身份更多通过控制台访问、操作云资源，即要对整个人员身份持有的凭证（用户名、密码）或权限等做相应的安全访控，程序身份通过凭证STS token访问云资源，当然，程序访问凭证也有管理安全事件。此外，还要求对人员和程序的权限都采用最小权限的原则，避免暴露之后因权限过大使得不法分子操作范围扩大。
接下来，在人员身份和程序身份分离后，还要开通操作审计，把日志投递到SLS。由于操作审计产品只默认保存90天，在疑似出现凭证泄露事件时，由于时间已经超过90天，无法再通过审计追溯到之前身份创建或使用的历史。因此，建议用户进行投递，定期进行审计，也可以借助治理检测工具定期查看存在的风险，以及疑似泄露事件，便于及时修补。
2、人员凭证管理的最佳实践
人员凭证管理的最佳实践主要包含四个方面，即SSO单点登录、密码策略、多因素认证和登录IP限制。
（1）SSO单点登录
可以针对单账号和多账号两种使用场景进行单点登录的集成。
①单账号SSO
单账号主要指用户在阿里云的主要核心资源都在一个云账号下，我们可以直接通过访问控制RAM产品做单点登录的集成。员工通过企业IdP完成身份认证后，可直接登录跳转到阿里云控制台，无需要再使用阿里云控制台的用户名和密码。这样，可以为企业管理提供便利，也降低了密码泄露的风险。
②多账号SSO
大型企业在云上可能不仅只有一个云账号，各个云账号都需做身份权限管理，为此，我们提供了多账号的云SSO产品。同样，可以将企业的IdP（身份系统）和云SSO产品做单点登录的集成。云SSO产品也会负责为所有云账号做身份和权限的分配。
（2）密码策略
若未使用SSO单点登陆的集成，且仍需要使用用户名密码，建议使用更强的密码策略防控密码泄露。
包括使用长度在八位以上的密码，密码包含大小写字母、数字和符号至少三种的元素，密码中不允许出现用户名，密码有效期在90天以内，密码过期之后限制登录，密码重置约束在5次以内，以及历史密码检查策略和最少包含的不同字符数等，这些都可以根据企业自身安全要求进行设定。强密码策略能保证密码不易被猜中、破解。同时，定期轮换密码可以缩短暴露时长，降低泄露的风险。
（3）多因素认证
多因素认证通过多重的验证保护，主要针对三种场景。第一种是登录时要求必须做多因素认证，可在密码之外再增加一层验证防护；第二种是异常的登录，如果出现IP或访问设备以及各种登录环境的异常变化，风控平台会作异常登录提示，并且强制要求进行二次身份核实，以确保是操作者本人，而非外部非法调用；第三种是风险操作，在阿里云控制台上进行云资源的操作，尤其是对资源的变更、释放等高风险的操作时，也会触发二级验证的风控要求。当然，阿里云云产品控制台仍未能具备百分之百介入风险操作验证的能力，仍在持续不断地推进，进而实现对一些高危险操作进行验证，确认是否本人操作。
多因素认证的手段主要有4类，包括通过在手机安装APP实现虚拟MFA的动态验证，也可以通过U2F常用硬件设备，还可以通过更方便的手机短信和邮箱验证方式。建议大家为自己的用户绑定一系列的多因素认证方式，以加强登录的安全性。
（4）登录IP限制
在访问控制产品中可以设置登录掩码，员工仅在公司网络环境下才可访问云控制台，从而阻拦非法远程外部调用。若员工经常出差，企业也可以使用自己的VPN能力，即使是远程办公，也同样使用的是公司网络环境的IP访问控制台。
3、程序访问凭证管理的最佳实践
前面介绍了程序访问的临时凭证和长期凭证两种方式，更推荐使用临时凭证替代长期凭证，因为其有效期更短，安全性更高。如果必须使用长期凭证AccessKey，也要做好存储安全、使用安全、审计治理和安全删除等几种管理安全保证。
（1）程序访问如何使用STS token临时凭证
①ECS实例角色获取STS token访问云资源
一个典型的场景是，当业务部署在阿里云ECS实例上，可以直接为实例绑定RAM角色身份，实例中部署的ECS源数据服务就会起到发放STS Token的功能，为实例上部署的应用程序发放临时凭证，应用程序就可以使用临时凭证来访问阿里云的资源，调用相应的API执行操作，而无需要再使用长期凭证写在配置文件中，降低了泄露的风险和维护的难度。
与之类似的方案，在容器服务中也有提供。
②ACK RRSA功能获取STS token访问云资源
若开通了容器服务为ACK RRSA功能，容器服务也会为部署在容器服务当中的应用程序提供STS token的能力。应用程序即可通过临时凭证访问阿里云的资源。以上两种方式详细的实现方式在相应的产品文档中都有提供，且配置过程并不复杂，用户可以详细了解该种方式以避免使用长期的凭证。
（2）AccessKey管理安全最佳实践
若业务并不是部署在ECS服务器或容器上，可能仍需使用AccessKey长期凭证调用阿里云的API操作云资源，可以在三个方面做好AK的管理工作。
第一，AK的存储。该部分最常出现的问题是在各种配置文件和源代码中写入永久AK，增加AK的泄露风险。因此，我们建议定期轮换AK，以缩小AK的暴露时长，同时阿里云也有KMS凭证管家产品，帮助用户更便捷地做AK的管理、存储和轮转工作。
第二，AK的使用。在真正使用AccessKey访问阿里云资源的过程中，都会经过访问控制产品认证和健全的步骤。这个过程中，也可以使用一定的策略做好安全防控，如限制AccessKey只能在企业内网IP范围内访问云资源，或在限定的VPC范围内访问云资源，甚至直接禁止对公网的访问等等，以实现对AK泄露、异常外部调用等情况的及时拦截，降低损失。
第三，AK审计治理。我们在RAM AK的管理中即可以便捷地看到AK的最后使用时间，以判断把AK的调用是否正常，是不是处于活跃状态。同时，操作审计产品也提供了非常详细的AK操作日志，云安全中心也提供了AK公网的扫描。若不小心上传到了GitHub上，会有及时的AK的轮换和删除预警。
（3）AccessKey删除的安全最佳实践
前面提到，建议用户阶段性轮转，以及对终止业务、离职人员及时进行AK的清理。
在AK的删除过程中，也需要提前进行检查，防止因误删除导致线上业务故障的情况。第一步，确认AK是否在活跃状态或是禁用状态，以及根据AK最后使用时间判断其是否仍处于调用中。如果AK已经不再使用，我们可以下探到活跃的调用源，确定AK之前调用的服务和API，哪些源IP有调用记录。通过操作审计和SLS访问数据日志等日志产品查看相应的内容，以判断AK之前的使用情况。
在确定其不再使用后，就可以将其禁用，观察业务是否受到影响。若不受影响，可以直接删除，但目前阿里云提供的是软删除功能，即在AccessKey被删除后，会默认进入回收站。如果发现是误删除，影响了业务运行，可以马上对其进行恢复，减少对业务的影响。如果删除后没有出现异常，在禁用和删除后相对较长的观察期之后，确定AK未正常使用，即可删除，回收站中的AK在30天后会自动永久删除。
以上本次分享的凭证安全的主要内容。
