3、访问控制：基于角色的访问控制(RBAC)、最小权限原则、临时凭证(STS)机制
说到云平台的远程运维，访问控制是绕不开的核心话题。我见过太多团队，一开始图省事，直接给所有人开了管理员权限，结果出事后追责都找不到人。说白了，访问控制就是解决「谁、能对什么资源、做什么操作」这三个问题。
这一节，我重点聊聊三个关键机制：RBAC、最小权限原则、STS临时凭证。这三者配合使用，基本能覆盖90%以上的远程运维安全场景。
3.1 基于角色的访问控制（RBAC）
RBAC不是什么新鲜概念，但在云环境里，它的价值被放大了。你想想看，一个云账号可能有几十个甚至上百个运维人员，如果每个人单独配置权限，那简直是噩梦。
RBAC的核心思想：把权限打包成「角色」，然后把角色分配给用户。用户不再直接跟权限打交道，而是通过角色间接获得权限。
举个例子：在阿里云RAM中，我通常会定义这几个角色：
- 运维工程师：拥有ECS、RDS、SLB的读写权限，但不能删除资源
- 安全审计员：只有只读权限，可以查看所有操作日志
- 超级管理员：拥有所有权限，但仅限2人持有
我在项目中遇到过一件事：一个新来的同事误操作删除了生产环境的数据库。事后排查发现，他居然有「管理员」角色。这就是角色定义不清晰导致的。后来我强制要求：每个角色必须明确其权限边界，不能有「万能角色」。
RBAC的最佳实践
- 角色粒度要适中：太粗了不安全，太细了管理成本高。我个人习惯按「职责域」划分，比如网络管理、计算资源管理、存储管理。
- 避免角色继承过深：有些云平台支持角色嵌套，但嵌套超过3层，权限就变得难以追踪。
- 定期审计角色成员：每季度检查一次，把不再需要的用户从角色中移除。
3.2 最小权限原则
最小权限原则，说白了就是：只给刚刚好的权限，多一点都不给。这个原则听起来简单，但执行起来很难。
为什么会难？因为很多运维人员觉得「先给个大权限，用着方便」。嗯，这里要注意：方便和安全往往是冲突的。我曾经见过一个案例，某公司给所有运维人员都配了「存储管理员」权限，结果有人不小心删除了共享存储上的备份文件，导致数据恢复花了整整两天。
避坑指南：我曾经接手过一个项目，前任运维把所有权限都配成了「*」（通配符）。我花了整整一周才把权限梳理清楚。所以我的建议是：
- 从零开始构建权限，不要复制粘贴已有的策略
- 使用「拒绝优先」原则：先拒绝所有权限，再逐步开放
- 对于临时操作，使用STS临时凭证（下面会讲）
最小权限原则在云环境中的具体落地，我推荐使用策略模拟器。比如AWS的IAM Policy Simulator，可以提前验证你的策略是否满足需求，避免上线后才发现权限不够或过多。
3.3 临时凭证（STS）机制
这是我最喜欢的一个机制。STS（Security Token Service）允许你生成临时、有期限的访问凭证。说白了，就是给运维人员发一张「临时通行证」，用完就失效。
为什么需要STS？ 你想想看，如果运维人员的AK（Access Key）是永久有效的，一旦泄露，攻击者可以一直用。而STS凭证的有效期可以设置为15分钟到36小时，即使泄露，影响范围也有限。
STS的工作流程
- 用户向STS服务发起请求，携带身份信息和权限策略
- STS验证身份后，返回一个临时凭证（包含AccessKeyId、AccessKeySecret、SecurityToken）
- 用户使用临时凭证访问云资源
- 凭证过期后，自动失效
我的个人习惯：对于日常运维操作，我通常设置STS凭证有效期为1小时。对于需要长时间执行的脚本，我会设置4小时，但会配合心跳机制，确保脚本在凭证过期前续期。
STS的典型应用场景
| 场景 | 说明 | 推荐有效期 |
|---|---|---|
| 日常运维操作 | 通过Web控制台或CLI执行操作 | 1小时 |
| 自动化脚本 | CI/CD流水线中的部署脚本 | 2-4小时 |
| 第三方集成 | 外部系统通过API访问云资源 | 15-30分钟 |
| 紧急故障处理 | 需要临时提升权限的场景 | 30分钟 |
STS与RBAC的结合
在实际项目中，我通常这样组合使用：
- 先通过RBAC定义好角色和权限
- 然后通过STS为特定操作生成临时凭证
- 凭证中携带的权限策略，是RBAC角色的子集
举个例子：运维工程师A有「ECS运维」角色，但他今天只需要重启一台服务器。那么我通过STS生成一个临时凭证，只允许他执行「重启」操作，有效期30分钟。这样既满足了需求，又遵循了最小权限原则。
3.4 核心逻辑框架图
下面这张图展示了RBAC、最小权限原则和STS三者之间的关系：
3.5 实战中的避坑指南
我曾经踩过的坑：
- 坑1：STS凭证有效期设置过长。有一次我设置了24小时的有效期，结果凭证泄露后，攻击者有一整天的时间搞破坏。现在我的默认值是1小时。
- 坑2：RBAC角色权限范围过大。比如给「运维工程师」角色配了「ECS:*」权限，结果有人误操作删除了所有ECS实例。现在我会明确区分「读」「写」「管理」三个层级。
- 坑3：忽略最小权限原则的审计。权限配完后就不管了，结果半年后发现很多人的权限已经远远超出实际需求。现在我会每季度做一次权限审计。
我的建议：
- 使用云平台的「权限分析」工具，比如AWS的IAM Access Analyzer，可以自动发现过度授权的角色
- 对于敏感操作（如删除资源、修改网络配置），强制使用STS临时凭证+多因素认证（MFA）
- 建立「权限变更审批流程」，任何权限变更都需要经过审批
好了，关于访问控制的核心内容就这些。RBAC、最小权限原则、STS临时凭证，这三者缺一不可。记住一句话：权限不是越多越好，而是刚刚好最好。
公众号:蓝海资料掘金营，微信deep3321