簡介

在前幾天的文章裡，我們已經介紹了 Data Lakehouse 的基礎、資料來源以及 Amazon S3 與資料格式的重要性。

但如果要真正開始在 AWS 上進行實作，僅有架構、資料、儲存空間還不夠，我們還需要一套「門禁系統」，來確保誰能使用、誰能修改，誰不應該看到什麼資源。

這個「門禁系統」就是 AWS 的 IAM (Identity and Access Management)。

為什麼需要 IAM？

當你建立 AWS 帳號時，會得到一個 Root 帳號。

Root 帳號擁有所有權限，可以建立或刪除任何資源，但也因為權限過大，一旦外洩將帶來巨大風險。

👉 因此，AWS 的最佳實務是：

• Root 只用於初始化設定（例如啟用帳單警示、建立第一個 IAM 使用者）。
• 日常操作一律透過 IAM 使用者與角色 來進行。

IAM 的四大核心元素

1. User（使用者）

   • 代表「一個人」或「應用程式」。
   • 有登入 AWS Console 的憑證，或使用 Access Key 存取 API/CLI。

2. Group（群組）

   • user 的集合，可以一次套用 Policy。
   • 範例：Admin group、Developer group。

3. Role（角色）

   • 臨時授權身份，沒有長期憑證，必須被「Assume」才會生效。
   • 常見用途：
     • Lambda、EC2、Glue 等 AWS 服務臨時存取 S3 或其他服務。
     • 跨帳號授權（公司 A 的 User 臨時扮演公司 B 的 Role）。
     • 取代長期 Access Key，提升安全性。

4. Policy（政策）

   • 權限規則使用「JSON 文件」來作設定。
   • 定義誰能對哪些資源執行什麼操作。
   • 可以附加到 User、Group、Role。
   • 範例：只允許讀取某個 S3 Bucket 的檔案。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::anime-lake/*"]
    }
  ]
}

IAM 四大元素的關係圖

👉 簡易解讀：

• User 可以屬於 Group，繼承群組 Policy。
• User 也能直接綁定 Policy（但不建議）。
• Role 必須被 Assume（扮演） 才能使用，通常由 User 或 AWS 服務扮演。

Role 的運作方式

1. 建立 Role → 定義 Policy（例：讀取某個 S3 Bucket）。
2. 設定信任策略 (Trust Policy) → 誰可以 Assume 這個 Role。
3. AssumeRole → User 或 Service 扮演 Role，取得臨時憑證。
4. 執行操作 → 使用 Role 的權限存取資源，例如針對 S3 Bucket 內的資料檔案做異動。

範例：Developer 群組透過 Role 存取 S3

Step 1. 建立 Role (給開發人員用)

• Role Policy (允許讀取 S3 Bucket)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::anime-lake/*"]
    }
  ]
}

• Role 的信任策略 (允許特定帳號的 IAM User/Group 扮演這個角色)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

👉 這代表：只要是帳號 123456789012 底下的 IAM User/Group，都能 Assume 這個 Role。

Step 2. 建立 Group 並允許成員 Assume Role

• Group Policy (允許成員扮演 DeveloperRole)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::123456789012:role/DeveloperRole"
    }
  ]
}

👉 這代表：這個 Policy 不直接給 S3 權限，而是允許群組內的使用者去 Assume DeveloperRole。

Step 3. 使用者繼承群組權限

• 將 user1 與 user2 加入 DeveloperGroup，他們不直接擁有 S3 權限，而是 先 Assume DeveloperRole，再透過該 Role 的 Policy 存取 S3。

關係示意圖

範例總結：

• Group 的 Policy：只允許成員 AssumeRole。
• Role 的 Policy：定義可以存取的資源 (S3)。
• User：透過加入 Group → 繼承 AssumeRole 權限 → 使用 Role 的 Policy 存取 S3。

👉 這就是 AWS 推崇的「間接授權模式」：
User/Group 不直接擁有資源存取權限，而是透過 Role 來取得。

IAM 的治理原則

• 最小權限原則 (Principle of Least Privilege)：僅授與完成任務所需的最小權限。
• 分層管理：依群組、角色區分不同層級（例如只讀 vs. 管理員）。
• 定期檢視：避免長期累積過度授權。

結論與建議

IAM 是 AWS 世界的第一道防線，也是治理的起點。

理解 IAM 的 User、Group、Role、Policy，不僅能確保資料安全，也能避免日後管理混亂。

下篇預告

本篇我們初步理解了 IAM 的觀念與核心元素，並學會了它們之間的關係。

下篇我們將進入 「DAY8 雲端基礎章-建立帳號與 IAM 實作」，實際操作 AWS 帳號初始化、設定 MFA、建立 IAM 使用者與群組，完成第一個安全環境的基礎建設。

參考資料

[1] What is IAM?
[2] Security Pillar - AWS Well-Architected Framework