# 防御思路

默认情况下如果没有创建RAM用户则是使用阿里云创建的用户生成的Access Key则是拥有所有管理权限的。

配置RAM用户，使用RAM用户连接OSS，就算AK泄漏造成的影响也是有限。

* &#x20;RAM (Resource Access Management) 是阿里云为客户提供的用户身份管理与访问控制服务。
  * &#x20;使用RAM，您可以创建、管理用户账号（比如员工、系统或应用程序），并可以控制这些用户账号对您名下资源具有的操作权限。
  * &#x20;当您的企业存在多用户协同操作资源时，使用RAM可以让您避免与其他用户共享云账号密钥，按需为用户分配最小权限，从而降低您的企业信息安全风险。
  * &#x20;一个云账号下可以创建多个RAM用户，对应企业内的员工、系统或应用程序。
  * &#x20;RAM用户归属于云账号，只能在所属云账号的空间下可见，而不是独立的云账号。
  * &#x20;RAM用户必须在获得云账号的授权后才能登录控制台或使用API操作云账号下的资源。

&#x20;

目前在Github上能找到阿里云的AK/SK已经很困难了，阿里云和Github合作引入了Token scan机制，用户不慎泄漏AccessKey会被检测出来并且通知用户进行更改。

<figure><img src="https://2774253028-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LxZ3g61O4Qp4qY2guHB%2Fuploads%2FyY8sKYxFJq9LcsPlX3Lv%2Fimage.png?alt=media&#x26;token=cd8fb826-7a52-4ca6-a69e-69db59766988" alt=""><figcaption></figcaption></figure>

其它安全建议：

* &#x20;不要将AccessKey嵌入代码中
  * &#x20;嵌入代码中的AK凭证容易被人忽视，经验丰富的开发者会将其写入数据库或者独立的文件中，使得其管理起来更方便。
* &#x20;定期更新AccessKey
  * &#x20;定期更新代码中存在的AccessKey，可保证一些旧的代码泄漏后不会影响当前线上业务。
* &#x20;定期吊销不需要的AccessKey
  * &#x20;在阿里云AccessKey控制台可查看最后一次AccessKey的访问时间，建议禁用所有不用的AccessKey。
* &#x20;遵循最小权限原则使用RAM账户
  * &#x20;根据不同业务需要授予不同子账户的读写权限，为不同业务分配不同子账户的AccessKey。
* &#x20;开启操作日志审计，并将其投递至OSS和SLS保存和审计
  * &#x20;将操作日志存储至OSS，异常情况时可以起到固证的作用；操作日志投递至SLS，帮助您在日志数量大的时候也能实现高效检索。

&#x20;
