部署 TEAM 並打造最佳工程團隊

場次筆記

Yuji

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