AWS去堡垒机化运维:基于IAM进行运维登录

在传统运维体系中，“登录服务器”通常意味着三件事：

• 一个固定账号
• 一组长期凭证
• 一个集中跳转点（堡垒机）

而在 AWS 的设计中，这套模型被系统性重构。 本文讨论的不是“如何配置某个功能”，而是一个更基础的问题：

在没有 SSH 密码、没有固定账号、没有堡垒机的前提下， 运维登录是如何成立的？

一、去堡垒机的前提：身份必须统一收敛到 IAM

去堡垒机并不是“取消管控”，而是改变管控的位置。

在 AWS 中有一个明确前提：

• 人的身份只存在于 IAM
• 授权只能通过 IAM Policy 表达
• 所有访问能力都通过 STS 临时会话下发

这意味着：

• 不再需要在资源侧维护“运维账号”
• 不需要分发长期有效的登录凭证
• 登录行为本身成为一次被授权的会话

二、统一的运维登录抽象：身份 → 会话 → 资源

无论登录的是计算资源还是数据库，AWS 的运维登录都可以抽象为：

1
2
3
4
5
6
7

运维人员
  ↓
IAM 身份（User / Role / IdP）
  ↓
STS 临时会话
  ↓
受 IAM Policy 约束的登录操作

差异不在身份侧，而在于资源如何接受这个会话。

三、EC2 运维登录：两种 IAM 原生路径

Session Manager：完全去凭证的登录方式

Session Manager 是最符合 AWS 设计理念的运维方式：

• 不暴露 SSH 端口
• 不依赖公网 IP
• 不需要分发系统账号或密钥

运维人员只需要被授予相应的 IAM 权限，即可建立受控会话。

关键点在于：

实例本身不感知“是谁登录了它”， 只接受来自 AWS 控制面的会话指令。

EC2 Instance Connect：受 IAM 控制的 SSH

Instance Connect 的存在，主要是为了兼容传统 SSH 运维方式。

但它与传统 SSH 有本质区别：

• 公钥不长期存储在实例上
• 公钥由 IAM 授权临时推送
• 有效期极短，用完即失效

本质上，这是把 SSH 纳入 IAM 与 STS 的控制体系，而不是保留原有的运维账号模型。

四、RDS 运维登录：IAM DB Authentication

数据库运维往往是去堡垒机体系中被忽略的一环。

传统问题

• 数据库账号长期存在
• 密码分发与轮转复杂
• 运维操作难以精细审计

IAM DB Auth 的思路

• 数据库用户不再依赖静态密码
• 登录 Token 由 IAM 临时生成
• 授权逻辑集中在 IAM Policy

简化后的登录链路是：

1
2
3
4
5
6
7

运维人员
  ↓
AssumeRole
  ↓
STS 临时凭证
  ↓
生成短期数据库登录 Token

Token 生命周期极短，不需要存储数据库密码，也可以精确绑定到具体资源。

1
2
3
4
5
6
7

mysql --host=database-1.ctg20gsqsqbx.ap-northeast-1.rds.amazonaws.com \
      --port=3306 \
      --ssl-ca=global-bundle.pem \
      --ssl-mode=VERIFY_IDENTITY \
      --user=your_iam_user \
      --password="$(aws rds generate-db-auth-token --hostname database-xxxxx.rds.amazonaws.com --port 3306 --region ap-northeast-1 --username your_iam_user)" \
      --enable-cleartext-plugin

五、从 EC2 到 RDS：统一的“去堡垒机”运维模型

从计算资源到数据库，可以看到一个一致的变化方向：

去掉的不是“堡垒机组件”，而是资源侧对“长期运维身份”的依赖。

结语：去堡垒机，本质是抽象升级

在 IAM 模型下，运维的本质发生了变化：

• 身份集中在控制面
• 授权前置且显式
• 会话短暂、可撤销
• 操作天然可审计