编辑: star薰衣草 | 2016-07-08 |
登录验证 为根账户和 RAM 用户启用 MFA 建议您 为根账户绑定 MFA(Multi-factor authentication,多因素认证),每次使用根账户时都强 制使用多因素认证. 如果您创建了 RAM 用户,并且给用户授予了高风险操作权限(比如,停止虚拟机,删除存储桶 ),那么建议您 给RAM 用户绑定 MFA. 为用户登录配置强密码策略 如果您 允许子用户更改登录密码,那么应该要求他们创建强密码并且定期轮换. 您可以通过 RAM 控制台 设置密码策略,如最短长度、是否需要非字母字符、必须进行轮换的频率等 等. 定期轮转用户登录密码和访问密钥 建议您或 RAM 用户要定期轮换登录密码或访问密钥. 在您不知情的时候,如果出现凭证泄露,那么 凭证的使用期限也是受限制的. 您可以通过 设置密码策略 来强制 RAM 用户轮换登录密码或访问密钥的周期. 账号授权 遵循最小授权原则 最小授权原则是安全设计的基本原则.当您需要 给RAM 用户授权 时,请授予刚好满足他工作所需的权限,而 访问控制 最佳实践
1 不要过度授权. 比如,在您的组织中,如果 Developers 组员(或者一个应用系统)的工作职责只需要读取 OSS 存储桶里的数 据,那么就只给这个组(或应用系统)授予 OSS 资源的只读权限,而不要授权 OSS 资源的所有权限,更不要 授予对所有产品资源的访问权限. 使用策略限制条件来增强安全性 建议您给用户授权时 设置策略限制条件,这样可以增强安全性. 比如,授权用户 Alice 可以关停 ECS 实例,限制条件是 Alice 必须在指定时间、并且您公司网络中执行该操作 . 及时撤销用户不再需要的权限 当一个用户由于工作职责变更而不再使用权限时,您应该及时 将用户的权限撤销.撤销方法请参考 给RAM 用 户授权 中的 后续操作. 这样,如果在不知情的时候,当用户的访问凭证泄露时对您带来的安全风险最小. 权限分配 不要为根账户创建访问密钥 由于根账户对名下资源有完全控制权限,所以为了避免因访问密钥泄露所带来的灾难性损失,不建议您创建根 账号访问密钥并使用该密钥进行日常工作. 使用群组给 RAM 用户分配权限 在给RAM 用户授权 时,除了对 RAM 用户直接绑定授权策略,更方便的做法是创建与人员工作职责相关的 群组(如admins、developers、accounting等),为每个群组绑定合适的授权策略,然后把用户加入这些群 组.群组内的所有用户共享相同的权限. 这样,如果您需要修改群组内所有人的权限,只需在一处修改即可.当您的组织人员发生调动时,您只需更改 用户所属的群组即可. 将用户管理、权限管理与资源管理分离 在使用 RAM 时,您应该考虑创建不同的 RAM 用户,其职责分别是 RAM 用户管理、RAM 权限分配,以及各 产品的资源操作管理.一个好的分权体系应该支持权力制衡,尽可能地降低安全风险. 将控制台用户与 API 用户分离 不建议给一个 RAM 用户同时创建用于控制台操作的登录密码和用于 API 操作的访问密钥.通常只给员工创建 访问控制 最佳实践
2 - - - - - 登录密码,给系统或应用程序只创建访问密钥. 主账号安全实践 阿里云主账号相当于您的所有云资源管控的 root 账号.一旦主账号的登录密码或 API 访问密钥丢失或泄露 ,将会对您的企业造成不可估量的损失. 那么,在使用阿里云服务时,如何保护您的主账号安全呢?请参考本文提供的主账号安全实践若干原则. 原则 1:给主账号开启多因素认证 给主账号开启多因素认证(MFA),不要与他人共享 MFA 设备. 给授予特权操作的 RAM 用户也开启多因素认证.特权操作通常指管理用户、授权、停止/释放实例、 修改实例配置、删除数据等. 原则 2:不要使用主账号进行日常运维管理操作 给员工 创建 RAM 用户账号 进行日常的运维管理操作. 为财务人员创建独立的 RAM 用户账号. 创建独立的 RAM 用户账号来作为 RAM 管理员. 原则 3:不要为主账号创建 AccessKey AccessKey 与登录密码具有同样的特权,AccessKey 用于程序访问,登录密码用于控制台登录.由于 AccessKey 通常以明文形式保存在配置文件中,泄露的风险更高. 给所有的应用系统 配置 RAM 用户身份,并在 给RAM 用户授权 时遵循最小授权原则. 原则 4:使用带 IP 限制条件的授权策略进行授权 授予所有的特权操作 必须受 IP 条件限制(acs:SourceIp). 那么,即使 RAM 用户的登录密码或 AccessKey 泄露,只有攻击者没有渗透进入您的可信网络,那么攻击者也 无能为力. 原则 5:使用带 MFA 限制条件的授权策略进行授权 授予所有的特权操作 必须受 MFA 条件限制(acs:MFAPresent). 那么,即使 RAM 用户的登录密码或 AccessKey 泄露,只要 MFA 设备没有丢失,攻击者也无能为力. 更多限制条件,请参考 Policy 语法结构. 访问控制 最佳实践