极点宏观｜Amarathon 2025 回顾 08：部署 TEAM 并打造最佳工程团队

多账户与 IAM 设计

[ 1 ] 单一账户架构：

● 复杂的权限管理使安全性难以确保

● 难以追踪各工作负载的成本

● 容易发生操作错误与配额问题，导致运营困难

[ 2 ] 多账户架构：

● 通过分离权限提升安全性

● 轻松掌握各工作负载的成本

● 将作业影响降至最低，提升运营效率

跳板账户方法

● 设置跳板账户并集中管理 IAM 用户

● 用户登录跳板账户，再切换角色至各账户

● 各账户的权限会授予目标角色

● 使用跳板账户方法设计 IAM 的要点：

● [ 1 ] 根据实际职责建立组

● [ 2 ] 根据职责为每个账户建立角色

● [ 3 ] 为每个 IAM 组定义要切换的账户与 IAM 角色

使用 TEAM 进行访问控制

● 应如何处理生产环境的访问控制？

● 变更管理：何时由谁访问生产环境以执行变更作业？

● 生产环境访问控制：是否能随时访问生产环境？

---

使用 TEAM 进行访问控制

什么是 TEAM（Temporary Elevated Access Management，临时提升访问权管理）？

● Temporary Elevated Access Management 的缩写

● 用于管理账户访问权的授权式工作流程

● 以应用程序形式提供，可通过 IAM Identity Center 访问入口网站使用

使用 TEAM 控制生产环境访问的工作流程（应用程序）

● [1/3] 目前仅具正式账户的只读权限，从应用程序中选取 TEAM

● [2/3] 建立请求

● [3/3] 因尚未获得批准，状态为待处理 使用

TEAM 控制生产环境访问的工作流程（批准）

● 批准者从「批准请求」中选取相关请求、输入注解并予以批准 使用 TEAM

控制生产环境访问的工作流程（授权）

● 已新增正式账户的访问权限

● 由于已获批准，状态现已设为「已批准」。

整体团队结构

● ① 访问 IAM Identity Center 中的 Amazon Web Services 访问入口网站

● ② 访问 TEAM 应用程序

● ③ 请求提升访问权

● ④ 批准提升访问权

● ⑤ 启用提升访问权

● ⑥ 使用提升访问权

● ⑦ 记录会话活动

● ⑧ 结束提升访问权

● ⑨ 审查请求详细数据与会话活动日志

---

TEAM 的设计与实施

● 整理迁移至 IAM Identity Center 所需的权限：

● ① 整理各账户的角色与政策，建立权限集

● ② 整理跳板账户的组与政策，向 Entra ID 注册组

● ③ 建立指派并使用

CloudFormation 设计人物角色指派与批准工作流程的规则

● TEAM 有四种人物角色（请求访问、批准访问请求、审计日志、管理规则）

● 设计人物角色指派与批准规则

● 人物角色指派设计

● 应提交哪些项目以供批准？

● 应由谁批准／拒绝？

● 授予批准的最长时间

● 通知目的地（电子电子邮件、聊天）

从小规模运营逐步扩大应用范围

● 由小型团队进行测试运营，逐步扩大引入范围

● 个人 → 我的团队 → 整个部门

[ 1 ] 与既有系统并行运作

● 将对业务的影响降至最低

[ 2 ] 根据反馈检讨设置与运营方式

● 人物角色的指派是否足够？

是否授予了任何非预期的权限？IAM Identity Center x TEAM

● 使用从 Entra ID 预置的 SSO 用户

● 通过 IAM Identity Center 访问入口网站切换角色至非生产环境账户

● 在 TEAM 中获得批准后，切换角色至非生产环境账户

---

TEAM 的优点

● IAM Identity Center x TEAM:

[ 1 ] 用户观点：

● 现在跨账户切换角色更加简单

● 请求流程更短，UI 更简洁清楚

● 提升开发效率

[ 2 ] 管理员观点：

● 摆脱 IAM 管理工作

● 人物角色指派与请求规则等设置管理现在更加简单

● 提升运营效率

摘要

● 通过「TEAM」，所有「团队」成员皆提升了运营与安全意识

● 在多账户设置中，应考虑正式账户的访问管理

● 「IAM Identity Center x TEAM」可实现简易管控

● 引入 TEAM 可提升团队生产力、安全性与合规性