AWS IAM 入門教學：掌控雲端權限的核心鑰匙

AWS Identity and Access Management (IAM) 是 AWS 安全架構的基石。在雲端世界中，安全性永遠是第一優先，而 IAM 就是控制「誰 (Authentication)」可以對「什麼資源」做「什麼動作 (Authorization)」的守門員。

這篇文章將帶你快速理解 IAM 的核心概念，並分享幾個在實務上必須遵守的最佳實踐。

什麼是 IAM？

IAM 是一個免費的 AWS 全球性服務（Global Service），這意味著你不需要在每個 Region 單獨設定，設定一次即可套用到所有區域。它主要負責兩件事：

認證 (Authentication): 確認你是誰（例如：User ID 和 Password，或 Access Key）。
授權 (Authorization): 確認你能做什麼（例如：能不能讀取 S3 Bucket，能不能開啟 EC2）。

IAM 四大核心元件

要搞懂 IAM，必須先理解這四個名詞：Users, Groups, Roles, Policies。

1. Users (使用者)

代表一個實體的人或應用程式。

Root User (根使用者): 註冊 AWS 帳號時建立的第一個使用者，擁有至高無上的權限（ billing 權限、關閉帳號等）。日常操作絕對不應該使用 Root User。
IAM User: 你為團隊成員或應用程式建立的個別帳號。每個 User 有自己的憑證（密碼或 Access Keys）。

2. Groups (群組)

使用者的集合。將權限賦予 Group，所有在該 Group 內的 User 就會自動繼承這些權限。

Best Practice: 盡量將權限綁定在 Group 上，而不是直接綁定在個別 User 身上。這樣當人員異動時，只需改變 Group 成員即可，管理更輕鬆。

3. Roles (角色)

Role 是一個「臨時」的身份，它沒有固定的密碼或 Access Key。它像是一頂「帽子」，誰戴上這頂帽子，誰就擁有對應的權限。

使用場景:
- AWS 服務: 讓 EC2 機器或 Lambda 函數有權限去讀取 S3 (不再需要把 Key 存在 code 裡)。
- 跨帳號存取: 讓 A 帳號的使用者可以臨時操作 B 帳號的資源。
- 身分聯合 (Federation): 允許使用 Google/Facebook 或公司 AD 登入，登入後扮演某個 Role。

4. Policies (政策)

定義權限的 JSON 文件。你可以把 Policy 貼在 User, Group 或 Role 上。

一個典型的 Policy 包含：

Effect: Allow 或 Deny (AWS 預設為隱式 Deny，除非顯式 Allow)
Action: 允許的操作 (例如 s3:ListBucket)
Resource: 操作的對象 (例如特定 Bucket 的 ARN)

Policy 範例 (唯讀 S3):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:List*", "s3:Get*"],
      "Resource": "*"
    }
  ]
}

IAM 安全最佳實踐 (Best Practices)

鎖定 Root User:
- 不要用 Root User 登入控制台。
- 刪除 Root User 的 Access Keys。
- 務必啟用 MFA (多重驗證)：這是保護帳號的最後一道防線。
最小權限原則 (Least Privilege):
- 只給予使用者「剛好夠用」的權限。如果一個 User 只需要重啟 EC2，就不要給他 AdministratorAccess。
啟用 MFA:
- 為所有人類使用者（特別是管理員）啟用 MFA。即便密碼外洩，駭客沒有你的手機也進不來。
使用 IAM Roles:
- 在 EC2 或 Lambda 上運行程式時，使用 Roles 而不是將 Access Key 硬寫在程式碼或設定檔中。這能避免 Key 外洩的風險。
定期輪替憑證 (Rotate Credentials):
- 定期更換 IAM User 的 Access Key 和密碼，減少憑證被長期濫用的風險。

結語

IAM 是 AWS 中最常被忽視卻最重要的服務。良好的 IAM 設定能為你的雲端架構打下堅實的安全基礎。建議初學者先練習建立一個「僅擁有 ReadOnly 權限」的 User，體驗一下權限控制的威力。

進階觀念：RBAC 與 ABAC 的差異

在 AWS IAM 的世界中，RBAC (Role-Based Access Control) 和 ABAC (Attribute-Based Access Control) 是兩種不同的權限管理策略。

簡單來說：

RBAC 是「根據你的職位/角色決定你能做什麼」。(傳統做法)
ABAC 是「根據你的屬性 (Tags) 與資源的屬性 (Tags) 是否匹配來決定你能做什麼」。(進階做法，適合擴展)

1. RBAC (角色存取控制)

這是 AWS 最傳統且常見的使用方式。 上述提到的 User, Group, Role 主要是為了實現 RBAC。

運作方式：
- 建立一個 IAM Role（例如 Developer）。
- 在這個 Role 上綁定 Policy，明確列出它可以存取的資源（例如 Allow S3 Read on bucket-A）。
- 使用者扮演這個 Role，就獲得了權限。
適用場景：
- 中小型團隊：專案和資源數量還在可控範圍內。
- 權限邊界明確：清楚知道 Developer 群組就只要存取 bucket-A 和 bucket-B。
缺點：
- Policy 變得很長：當新增 bucket-C 時，必須回去修改 Developer 的 Policy 把 bucket-C 加進去。這稱為 "Policy Churn" (策略變動頻繁)。

2. ABAC (屬性存取控制)

這是利用「標籤 (Tags)」來動態決定權限的方式。

運作方式：
- 不需要在 Policy 裡寫死資源 ID (ARN)。
- 寫一條通用的 Policy：「只要使用者的 Department Tag 等於資源的 Department Tag，就允許存取」。
- IAM Policy 寫法範例：
```
"Condition": {
    "StringEquals": {
        "aws:PrincipalTag/Department": "${aws:ResourceTag/Department}"
    }
}
```
適用場景：
- 快速擴張的大型組織：開發團隊一直在開新的 EC2、新的 S3 Bucket。
- 減少管理負擔：當有人開了一個新的 EC2 並打上 Department: Engineering 標籤，所有屬於 Engineering 部門的使用者自動獲得存取權，完全不需要管理員去修改 IAM Policy。
優點：權限會隨著資源增加而自動擴展 (Scale)，無需頻繁修改 Policy。

總結比較

特性	RBAC (基於角色)	ABAC (基於屬性/標籤)
核心邏輯	我是誰 (Role/Group)	我們的屬性 (Tags) 是否匹配
新增資源時	必須修改 Policy，加入新資源 ARN	無需修改 Policy，只需給新資源打對 Tag
管理複雜度	資源少時簡單，資源多時複雜	初始設定較複雜，但極易於擴展
最佳實踐	適合絕大多數基礎場景	適合高度動態、資源眾多的企業環境

什麼是 IAM？​

IAM 四大核心元件​

1. Users (使用者)​

2. Groups (群組)​

3. Roles (角色)​

4. Policies (政策)​

IAM 安全最佳實踐 (Best Practices)​

結語​

進階觀念：RBAC 與 ABAC 的差異​

1. RBAC (角色存取控制)​

2. ABAC (屬性存取控制)​

總結比較​