IAM 是什麼？

IAM 是 Identity and Access Management 的縮寫，中文通常翻譯為「身分與存取管理」。

之所以叫 IAM，是因為它主要處理兩個問題：

IAM 管理的是：

誰可以對哪些 AWS 資源執行哪些操作。

IAM 底下有四個核心概念：User、Group、Role、Policy，分別代表「身分」、「身分集合」、「可被暫時取得的身分」與「權限規則」。

📌 四個概念快速比較

四個核心名詞

👤 IAM User

IAM User 是在 AWS 帳號中建立的長期身分，通常代表一位特定使用者，或需要長期憑證的應用程式。

IAM User 可以擁有：

• 登入 AWS Management Console 使用的密碼
• 呼叫 AWS API 或 CLI 使用的 Access Key
• 直接附加或透過 Group 繼承的 Policy

⚠️ 安全提醒
IAM User 的密碼及 Access Key 不會自動失效，因此不應共用帳號，也應避免替應用程式建立 IAM User，再把 Access Key 寫死在程式或設定檔中。

👥 IAM Group

IAM Group 是一組 IAM User 的集合，用來統一管理多位使用者的權限。

例如，可以建立一個 Developers Group，將開發人員加入其中，再把需要的 Policy 附加到這個 Group。之後新增或移除成員時，就不必逐一修改每位 User 的 Policy。

📌 Group 的重要限制

• Group 只能包含 IAM User
• Group 不能包含其他 Group
• Group 本身不能登入 AWS
• Group 不能被 EC2、Lambda 等 AWS 服務使用
• Group 不能作為資源型 Policy 中的 Principal

💡 核心用途
Group 不是一種可以登入或操作 AWS 的身分，而是用來集中管理多個 User 權限的工具。

🪪 IAM Role

IAM Role 是一種可以被符合信任條件的使用者、應用程式或 AWS 服務暫時取得的 IAM 身分。

Role 本身沒有密碼，也沒有長期 Access Key。當使用者或服務取得 Role 時，AWS 會提供一組有期限的臨時憑證。

📌 Role 的常見用途

• 讓 EC2、Lambda 等 AWS 服務存取其他 AWS 資源
• 讓使用者暫時取得特定工作所需的權限
• 進行跨 AWS 帳號存取
• 避免在程式或設定檔中保存長期 Access Key

一個 Role 通常需要同時處理兩件事：

🔄 Role 的運作方式

使用者提出 AssumeRole 請求
        ↓
AWS 檢查 Role 的信任政策及使用者權限
        ↓
AWS STS 發出臨時憑證
Access Key ID＋Secret Access Key＋Session Token
        ↓
使用者以 Role 的權限存取資源
        ↓
憑證到期後自動失效

臨時憑證包含：

Access Key ID
Secret Access Key
Session Token

與 IAM User 的長期 Access Key 相比，臨時憑證的風險較低。即使臨時憑證外洩，攻擊者通常也只能在憑證有效期間內使用；長期 Access Key 則會持續有效，直到被停用或刪除。

⚠️ 注意
臨時憑證不代表絕對安全。Role 仍然必須搭配適當的 Trust Policy、最小權限與 CloudTrail 稽核紀錄。

📜 IAM Policy

IAM Policy 是以 JSON 格式撰寫的權限規則，用來定義某個身分或資源可以或不可以執行哪些 AWS 操作。

一條 Policy Statement 通常可能包含：

Policy 的使用方式主要分成兩類：

• Identity-based Policy：附加到 User、Group 或 Role
• Resource-based Policy：附加到 S3 bucket 等 AWS 資源

⚖️ AWS 權限判斷原則

1. 沒有被明確允許的操作，預設拒絕。
2. 至少有一條規則明確允許，才可能執行該操作。
3. 如果同時存在明確允許與明確拒絕，明確拒絕優先。

預設拒絕
   ↓
明確 Allow 才能通過
   ↓
只要出現明確 Deny，仍然拒絕

🧭 遇到情境時，該怎麼選？

比起硬記四個名詞，遇到情境時更重要的是先判斷：

• 這是一個會長期存在的「人」在用嗎？ → User，掛進對應的 Group，方便批次管理。
• 這是給 EC2、Lambda 這類服務用的嗎？ → Role。不需要把金鑰寫進任何檔案裡=沒有金鑰可以外洩。
• 這是「暫時」要借另一個帳號的權限嗎？ → Role，用一種叫 AssumeRole 的方式去借。
• 這份規則要重複套用在很多身份上嗎？ → 寫成一份 Policy，直接掛給多個 User/Group/Role 共用，不用每個地方各寫一次。

🛡️ 最小權限原則

最小權限原則是指：

只授予完成工作所必須的操作、資源範圍與使用期限，不提供額外權限。

情境範例

新進工程師只需要查看某一份報表資料，不需要修改或刪除任何內容。
這時候要決定的不是給不給權限，而是：

• 要讓他操作整個服務嗎？
• 還是只允許他讀取那一份報表？

依照最小權限原則，應該只提供：

• ✅ 特定報表的讀取權限
• ❌ 不允許新增資料
• ❌ 不允許修改資料
• ❌ 不允許刪除資料
• ❌ 不允許變更服務設定

也就是只給完成工作需要的那一小部分權限，其他操作一律不允許。

✅ 小結

設定權限前，先確認四個問題：

1. 誰要使用？
2. 需要執行什麼操作？
3. 可以存取哪些資源？
4. 需要使用多久？

確認這四件事之後，接著再判斷應該使用 User、Group 還是 Role，並設計適當的 Policy。

🧠 AI 出題

問題 1

一間公司要求，所有跨帳號的存取都要能在事後稽核「是誰、在什麼時候，取得了哪些權限」，而且權限不能永久有效。以下哪一種做法最符合這個要求？

• A. 在目標帳號建立一個 IAM User，把 Access Key 提供給需要跨帳號存取的人員
• B. 在目標帳號建立一個 IAM Role，讓來源帳號的使用者透過 AssumeRole 取得有期限的臨時憑證
• C. 在兩個帳號之間共用同一組 root 帳號憑證
• D. 在來源帳號的 IAM User 上，直接附加目標帳號資源的完整存取 Policy

問題 2

一個執行在 EC2 上的應用程式，需要讀取某個 S3 bucket 中的物件，建議的授權方式是什麼？

• A. 建立一個 IAM User，產生 Access Key，再將金鑰寫死在應用程式的設定檔中
• B. 建立一個 IAM Role，附加所需的 S3 權限，再將 Role 掛到這台 EC2 上
• C. 直接在應用程式中使用 AWS 帳號的 root 憑證
• D. 將同事現有的 IAM User 憑證分享給應用程式使用

問題 3

以下哪一個元素不是 IAM Policy 中 Statement 的一部分？

• A. Effect
• B. Action
• C. Resource
• D. Version

問題 4

新進同事只需要瀏覽某個 S3 路徑中的報表。依照最小權限原則，應該如何授權？

• A. 直接給予 AdministratorAccess，避免之後還要再次申請
• B. 只給予特定 S3 路徑的讀取權限
• C. 給予整個 S3 服務的完整存取權，方便他順便整理檔案
• D. 給予和主管相同的權限，方便管理

問題 5

一位新加入的維運人員，每天只需要檢查多個服務的 CloudWatch 告警並回報，不需要修改任何資源設定。團隊為了方便，直接請他共用另一位資深工程師既有的 IAM User 帳號。這個做法主要違反了什麼原則？

• A. 沒有違反任何原則，只要有做好交接即可
• B. 違反最小權限與個別問責原則，因為權限超過實際工作需求，而且無法追蹤實際操作者
• C. 只違反密碼複雜度規則，與共用帳號無關
• D. 只要該帳號已啟用 MFA，共用帳號就沒有問題

💡 解答

1. B

Role 搭配 AssumeRole 會產生有期限的臨時憑證，並能透過 CloudTrail 追蹤 Role 的使用紀錄。

IAM User 的 Access Key 屬於長期憑證，不符合「權限不能永久有效」的要求；共用 root 憑證更是嚴重違反 AWS 安全實務。

2. B

AWS 服務需要存取其他 AWS 資源時，應優先使用 Role。

將 Access Key 寫死在程式或設定檔中，會增加長期憑證外洩的風險。使用 EC2 Role，則可以讓應用程式自動取得及更新臨時憑證。

3. D

Version 是 Policy 文件的頂層欄位，不是 Statement 裡面的元素。

Effect、Action、Resource 都可以出現在 Statement 中；Principal 則主要出現在資源型 Policy 的 Statement 中。

4. B

依照最小權限原則，只能提供完成工作所需的最小權限。

這名同事只需要查看特定 S3 路徑中的報表，因此只需要該範圍的讀取權限，不需要完整的 S3 權限。

5. B

這個做法同時產生兩個問題：

1. 新進人員取得了超過工作需求的權限，違反最小權限原則。
2. 多人共用同一個帳號，無法準確追蹤實際操作者，破壞個別問責與稽核能力。

MFA 解決的是登入驗證問題，不能解決共用帳號造成的操作歸屬及權限過大問題。