極點宏觀｜Amarathon 2025 回顧 08：部署 TEAM 並打造最佳工程團隊

Oshima 多帳戶與 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 可提升團隊生產力、安全性與合規性