在 AWS 多账号架构中，Break-Glass（破窗/应急）账号是安全体系最后一道防线。当 SSO 挂了、SCP 改坏了、权限全锁了的时候，这是唯一能进去的路。
设计原则
Break-Glass 账号的核心原则：不依赖任何可能出问题的组件。
| 原则 | 说明 |
|---|---|
| 独立于 SSO | SSO 可能配置错误、管理员离职、IAM Identity Center 故障 |
| 独立于日常权限体系 | 日常 SCP 可能误封所有操作 |
| Root 凭据安全存储 | 邮箱 + 密码 + MFA 存放在密码管理器 |
| 平时不用 | 仅应急时启用，避免暴露面 |
使用方式
Emergency 账号平时不用，仅在紧急情况下介入。两种入口都可以：
- SSO 登录：如果 SSO 还能用，直接通过 IAM Identity Center 进去
- Root 登录：如果 SSO 挂了，用安全存储的 Root 凭据（邮箱+密码+MFA）登录
进去之后的流程取决于登录方式：
SSO 登录→ 直接通过 Switch Role 进入目标账号操作。SSO 颁发的临时凭证本身可审计。
Root 登录→ 先创建临时 IAM 用户，再用 IAM 用户登录后 Switch Role。原因是 AWS Root 用户不能执行 sts:AssumeRole，无法直接 Switch Role 到其他账号：
1
2
3
4
5
6
7
8
9
Root 登录
↓
创建临时 IAM 用户（AdministratorAccess）
↓
用 IAM 用户的凭证登录
↓
Switch Role 到目标账号恢复操作
↓
操作完成后删除临时 IAM 用户及凭证
Cross-Account AssumeRole 机制
Emergency 账号通过临时 IAM 用户登录后，使用 AWS 控制台的 Switch Role 功能进入其他账号：
1
2
3
4
5
6
7
临时 IAM 用户登录 Emergency 账号
↓ Switch Role
Management（修复 CT / SSO）
Log-Archive（检查日志）
Audit（修复安全服务）
Billing（检查账单）
Prod（修复生产环境）
前提是目标账号的 OrganizationAccountAccessRole（AWS Organizations 在每个账号中自动创建）信任 Emergency 账号。需要在目标账号中修改信任策略：
1
2
3
4
5
6
7
8
9
{
"Action": "sts:AssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::${EMERGENCY_ACCOUNT_ID}:root"
]
}
}
注意信任的是 Emergency 账号的 Root（arn:aws:iam::${EMERGENCY_ACCOUNT_ID}:root），不是某个 IAM 用户。临时 IAM 用户在 Emergency 账号内继承账号权限，可以通过 Switch Role 进入任何信任该账号的目标角色。
SCP 豁免策略
Emergency 账号的 SCP 比普通账号宽松，确保在极端情况下不封锁自己。
Security OU 下只有一个层级，Audit、Log-Archive、Emergency 都在同一 OU。通过 SCP 条件按账号豁免：
1
2
3
4
5
6
7
{
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": "${EMERGENCY_ACCOUNT_ID}"
}
}
}
严格规则附加到 Security OU，但 Emergency 账号通过 aws:PrincipalAccount 条件跳过。
总结
Break-Glass 账号的核心价值在于独立性和可用性——不依赖 SSO、不依赖日常权限体系、凭据独立存储。配置好跨账号 AssumeRole 链路和 SCP 豁免策略，就能在极端情况下保住一条通往所有账号的修复路径。