到底什麼時候才可以開始寫程式...都快把題目寫成 Build on AWS 了...

IAM Identity Center 啟用完成後，接下來就要開始設定開發環境需要的存取權限。

流程大致分成三步：

1. 建立使用者帳號
2. 啟用並綁定 MFA
3. 配置授權（Permission Set）

這些是為了讓本地端能夠順利透過 Toolkit 拿到合理的權限，並與 AWS 互動所必須完成的基礎設定。
少了任何一個步驟，都一定會在 VS Code 連線時遇到錯誤。

合理的權限？
指的是雲端環境的「最小權限原則」或「最低權限原則」。
確保每個使用者、應用程式或實體僅擁有完成其特定任務所需的最低限度的權限和存取權限，以此大幅減少資安風險，降低攻擊範圍，並防止惡意軟體擴散。

建立使用者帳號

• 點選「新增使用者」
  
• 開始樸實無華的填寫資料環節
  
  下一步的「設定群組」可以自行選擇是否啟用，如果需要讓多個使用者擁有完全相同的權限（比如開發團隊、部門、廠商等），就很適合建立群組來統一管理。
• 按下「新增使用者」就可以完成囉！
  

完成建立使用者後，很快就會收到 AWS 發的邀請信，被邀請的使用者需要接受邀請並完成註冊流程，才能進到 AWS Console 中。

不過現在還不急著去收信。

如果對建立「系統管理員」還有印象，單純「有一個使用者」還不代表他能在 AWS 裡執行任何操作。同理，在 Identity Center 的使用者也一樣。
新增的只是擁有一組可以登入的帳號，我們還需要另外為這個使用者設定權限。

建立「系統管理員」詳細操作可參考：Day 4. 沒有人會 24 小時都是員工

為使用者指派帳戶

為什麼要「指派帳戶」?
先前在建立 IAM User 的時候，User 會很明確地屬於某個 AWS 帳戶 (Account) 。
它的「生命範圍」」固定綁在單一帳戶，無法修改，也無法跨到其他帳戶。賦予它定義好的 Policy，就能在該帳戶執行工作。

Identity Center 的 User 則是建在整個 AWS Organization 的最上層，在還沒指派前不屬於任何一個帳戶 (Account)。
簡言之，就是在指派帳戶完成前，這個 User 連一個帳戶都進不去。
就像是這個 User 屬於集團職員，但還沒定義它屬於哪個/些子公司、屬於哪個/些部門，自然到哪裡都會被擋在門外。

因此，「指派 AWS 帳戶」的意義就在於明確告訴 Identity Center：

這個 User 能進哪個 AWS 帳戶，以及要給他什麼權限（Permission Set）。

如果沒有這個動作，這個 User 雖然存在，卻會因為他沒有被允許進入任何帳戶而完全沒有用處。
當然，也沒有辦法綁定任何權限。

• 重新回到 IAM Identity Center 的 使用者功能，點選剛才建立好的使用者：developer
  切換到 AWS 帳戶存取 頁籤
  

• 此時會發現，這個使用者還沒有指派到任何帳戶 (Account)，點下「指派帳戶」
  選擇目前唯一一個帳戶後，按下 建立許可集
  

為使用者設定權限 (Permission Set)

Permission Set 可以理解成「Identity Center 專用的 IAM Policy」。
它定義了這個使用者登入之後，可以進入哪些帳戶 (Account)，以及擁有哪些操作權限。

聽起來很熟悉，和 IAM Role 的 Policy 有什麼差別？

沒錯喔！這兩者的確有點相似。
不同的是，Role 的 Policy 是直接綁在 Role 上；而 Permission Set 則是由 Identity Center 統一管理、指派。
嚴格來說，Permission Set 的定位其實更接近 Role。當在 Identity Center 建立 Permission Set 並指派給某個使用者時，AWS 會自動在指定帳戶裡建立對應的 IAM Role，並把 Policy 掛上去。

• 建立 Permission Set 時會有兩種選擇：
  直接套用 AWS 預設的權限範本（例如 AdministratorAccess、ReadOnlyAccess）。
  自行建立自訂的 Permission Set，內文可以直接寫 JSON Policy。
  
• 這邊選擇自訂
  既然是練習，就不套用現成範本，直接實作一個最小權限的案例。
  按下「下一步」後選擇「內嵌政策」，
  

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "*"
        },
        {
            "Sid": "ListBucket",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::ithome-ironman-2025"
        },
        {
            "Sid": "GetObject",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::ithome-ironman-2025/*"
        }
    ]
}

因為這個專案預計要將所有的資料存放在 AWS S3 (Simple Storage Service)，所以在這個 Policy 裡給予

• 讀取 S3 Bucket 清單
• 讀取 Bucket 內資訊 (限：ithome-ironman-2025 這個 Bucket)
• 取得 Bucket 中物件 (限：ithome-ironman-2025 這個 Bucket 中的物件)

以上幾個權限。

• 下一步需要輸入許可集名稱和 工作階段持續時間
  工作階段持續時間，白話一點就是：使用多久後，這個帳戶會自動登出。
  這個限制由 Identity Center 控管，不需要自己寫 TTL 邏輯，也可以自由設定時間，但最長不可超過 12小時。
  
• 最後檢視一下內容，確認無誤後建立許可集
• 勾選剛建立好的許可集
  
• 完成指派帳戶
  

登入測試！

到目前為止已經完成 Identity Center 的 User 基礎設定，立刻就去收驗證信來測試看看。

• 接受邀請並註冊使用者
  
• 輸入完帳號密碼，系統會要求使用者重新登入
  
• 並要求使用者設定 MFA
  
• 跟著系統引導完成 MFA 設定
  
• 接著就會自動導轉，進入存取入口網站
  就能看到剛才設定好的 Account 和建立好的許可集囉！
  

到今天為止，Identity Center 的使用者基礎設定終於完成了！
專案的存取環境有了明確的基礎，接下來的工作也能在更安全、可控的前提下進行。