部署 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 可提升团队生产力、安全性与合规性