AWS IAM 入門教學：什麼是 IAM？為何每個 AWS 使用者都該懂？

更新日期： 2025 年 6 月 4 日

當你開始使用 AWS（Amazon Web Services）建立雲端資源時，你就會接觸到一個不可或缺的服務：IAM（Identity and Access Management）。

IAM 是 AWS 的安全基礎，它決定了誰能存取你的資源、能執行什麼動作、在哪些條件下操作等。

無論你是單人開發者、初創團隊，還是企業級架構師，只要使用 AWS，就一定需要正確理解與設定 IAM。

這篇文章將一步步帶你了解 IAM 的核心功能、使用方式與實務建議，幫助你打造安全又可控的雲端環境。

IAM 是什麼？

在 AWS 上建構系統的過程中，你可能會建立 EC2 虛擬機、儲存資料到 S3、建立資料庫 RDS 或發佈 Lambda 函式。

這些資源都非常強大，也可能非常敏感。

因此，「誰能存取這些資源、可以做什麼事情」，就變成了至關重要的議題。

這時候，IAM（Identity and Access Management）就登場了。

IAM 的定義

IAM 是 AWS 提供的一套存取控制機制，讓你可以精確地管理「誰」可以對「哪些資源」執行「哪些操作」。

換句話說，它是：

🎫 一套精密的「權限管理系統」，控制你的 AWS 環境中每一份資源的「使用權限」。

IAM 的角色就像是 AWS 的保全系統，你可以用它設定：

• 誰可以登入 AWS（例如你的工程師或管理者）
• 誰可以操作 EC2、S3、RDS 等服務
• 哪些系統服務可以與彼此互動（例如讓 Lambda 存取 DynamoDB）
• 如何加強安全性（例如開啟多因子認證、限制 IP 來源）

這一切，都是透過 IAM 來設定與管理的。

從 Policy 認識 IAM 的運作核心

什麼是 IAM Policy？

在 AWS 中，Policy（政策）是一份權限聲明書，用來明確定義一個身份（如使用者、角色、服務）可以對哪些資源執行哪些操作。

它就像是 AWS 的「門禁清單」，你可以透過這份清單精準地設定：

• 誰（例如某個 IAM 使用者）
• 可以對什麼（例如某個 S3 Bucket）
• 做什麼事情（例如讀取檔案、上傳資料）

這份清單的內容是用 JSON 格式 編寫的，每一份 Policy 通常包含一或多個「Statement（敘述）」區塊，每個區塊代表一條具體的權限規則。

一份 IAM Policy 的基本結構

以下是一個典型的 IAM Policy：

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

這份政策的意思是：

✅ 允許（Allow）這個身份對 my-bucket 裡的所有物件執行 s3:GetObject 操作（也就是讀取檔案）。

我們逐一來看每個欄位的意思：

Version

這個欄位不是代表你自己的 Policy 版本，而是固定填寫 AWS 使用的語法版本。

目前統一使用 "2012-10-17"。

✅ 寫法固定為：

"Version": "2012-10-17"

Statement

Statement 是整份 Policy 的重點部分，可以是一個物件，也可以是一個陣列。

每個 Statement 都代表一條獨立的權限規則。

通常會包含以下欄位：

小範例解釋（再深入一點）：

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

這代表「只允許」這個身份：

• 執行 s3:GetObject：也就是從 S3 Bucket 中讀取物件
• 資源是 arn:aws:s3:::my-bucket/*：這是指定某個 Bucket 底下的所有物件（而不是整個 Bucket 本身）

❗ 注意：「Bucket 本身」與「Bucket 內的物件」是不同的資源，兩者 ARN 寫法也不同：

🔐 Effect：允許或拒絕

你可以明確寫出：

• "Effect": "Allow"：表示「我允許這件事發生」
• "Effect": "Deny"：表示「即使其他地方允許，我還是要拒絕這件事」

📌 小提醒：Deny 的權限優先於 Allow。如果一個身份同時被 Allow 和 Deny 相同動作，最終會被拒絕。

⚙️ Action：你想執行什麼操作？

這裡會指定 AWS 上的某項操作。例如：

• s3:PutObject → 上傳物件
• s3:GetObject → 讀取物件
• ec2:StartInstances → 啟動 EC2 執行個體
• dynamodb:Query → 查詢資料

你也可以使用萬用字元：

"Action": "s3:*"

這代表允許「所有 S3 的操作」，但這麼做風險較高，實務上建議精確指定必要的行為（稱為「最小權限原則」）。

📦 Resource：對哪個資源做這些事？

這裡是最重要的權限範圍設定，你要清楚列出哪些資源是被授權的。

例如：

• arn:aws:s3:::my-bucket/*：某個 bucket 裡的所有物件
• arn:aws:ec2:us-east-1:123456789012:instance/i-12345678：特定 EC2 實例

若你想允許操作「所有資源」，可以寫成：

"Resource": "*"

但這樣非常危險，千萬不要用在正式環境中！

📌 總結一句話：

Policy 就像 AWS 的「進出許可證」，用 JSON 說明誰可以怎麼樣操作哪些資源。

它是 IAM 權限機制的核心，所有的授權都是透過這些文字規則來完成的。

延伸補充：Condition 與 Principal 是什麼？

• Condition：讓你加入一些附加條件（例如只允許從某個 IP 存取、只允許平日登入）
• Principal：只在 Resource-based policy 才會用，代表「被授權的人是誰」

這兩個屬性不是每次都會出現，但在需要進階控制時非常有用。之後可以獨立介紹。

Policy 有兩種類型：Identity-based 與 Resource-based

在 IAM 中，Policy 並不只是單純給某個人用的權限清單，而是有兩種用途，取決於你是「從身份的角度授權」還是「從資源的角度控管」。

我們可以將這兩種 Policy 類型理解為：

接下來我們分別說明：

Identity-based Policy（身份型政策）

這種 Policy 是最常見、最基本的授權方式。

你可以把它想成「我是一個人／一個服務，我要設定我自己能做哪些事」。這種政策會綁定在某個身份上，身份的種類包括：

🔹 使用者（User）

代表一個實體的人，例如開發者、管理員。通常會登入 AWS 控制台或使用 CLI 操作。

🔹 群組（Group）

代表一群使用者的集合，你可以把一套 Policy 指派給整個群組，讓所有成員都擁有相同權限。

🔹 角色（Role）

代表一種可被「扮演」的身份，通常由 EC2、Lambda 等 AWS 服務、或其他帳號來使用。

使用情境舉例：

🧠 特點與優點：

• 是 IAM 中最基礎的授權機制
• 適用於「自己想要去做事」的情境
• 搭配 Action 和 Resource 定義行為範圍
• 管理簡單、邏輯直觀

Resource-based Policy（資源型政策）

這種 Policy 是「寫在資源本身」的，也就是由資源來決定：「誰可以來用我」。

例如：某個 S3 Bucket，可以設定成：

允許某個 IAM 使用者、角色、甚至外部帳號來存取我這個 Bucket。

你可以把它理解為：「資源自己訂門禁」。

🔧 常見資源支援 Resource-based Policy：

這類型的 Policy 多了一個很重要的欄位：Principal，用來指定「被授權的人是誰」。

🧠 語法差異示例：

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:user/Alice"
  },
  "Resource": "arn:aws:s3:::my-bucket/*"
}

這段寫在某個 S3 Bucket 的 Resource-based Policy 裡，意思是：

允許帳號 123456789012 下的 Alice 使用者，來讀取我這個 Bucket 裡的物件。

✅ 使用情境舉例：

🧠 Resource-based Policy 的特點：

• 必須資源本身支援，並非所有服務都可以用
• 適用於跨帳號授權、開放存取的情境
• 權限來自資源本身，而非操作者的身份
• 多用於資料分享與服務整合

初學者常見誤解整理：

✅ 小結：如何選擇用哪一種 Policy？

三種 IAM 身份：User、Group、Role

IAM 的設計邏輯是這樣的：

先建立「身份」，再授與「權限」。

而這三種身份（User、Group、Role）就是你用來操作 AWS 資源時的「主體」，你必須先知道這三種角色有什麼差別，才能正確分配權限與管理使用者。

User（使用者）

🧾 定義：

IAM User 代表的是一個「具名的實體人員」，像是你、你的同事或組織裡的工程師、財務人員等。

每個使用者都是 AWS 上的一個個體，會有自己的登入方式與個人金鑰。

🧰 特性：

📘 適用情境：

• 工程師需要登入 AWS 控制台管理資源
• 財務部門查看帳單與成本報表
• 系統管理員需要維護 IAM 設定與安全政策

✅ 實作建議：

• 每個人都應該擁有獨立的 IAM User，避免共用帳號（這是最常見的新手錯誤之一）
• 啟用 MFA（多因子認證）提升安全性
• 搭配 Group 使用，提高維護效率

Group（群組）

🧾 定義：

IAM Group 是一種「使用者的集合」，你可以將一組 IAM User 加入同一個 Group，然後對這個 Group 授與 Policy，所有成員都會自動繼承該權限。

Group 並不是一種可以登入或操作的身份，它只是為了「統一管理權限」而存在的邏輯分組工具。

🧰 特性：

📘 適用情境：

• 給「所有工程師」一樣的權限，例如：操作 EC2、讀寫 S3
• 管理者需要快速移除或變更一整群人權限時，只要調整 Group 即可
• 節省人力成本，不用為每個人逐一設定權限

✅ 實作建議：

• 將 User 加入不同部門 Group，例如：Developers、QA、Finance
• Group 的命名應清楚反映職責（如 S3-ReadOnly-Team）
• 變更權限時優先修改 Group，而非每位使用者

Role（角色）

🧾 定義：

IAM Role 是一種 「可以被扮演的臨時身份」，不像 User 是人，Role 通常給AWS 服務、應用程式、或外部帳號來使用。

Role 沒有帳密，也不能直接登入 AWS 控制台，必須透過assume（扮演）的動作，才能獲得它的權限。

🧰 特性：

📘 適用情境：

• EC2 實例要存取 S3：你可以建立一個具有寫入權限的 Role 並掛載給 EC2
• Lambda 要寫入 DynamoDB，不需手動設定 Access Key
• 第三方帳號（如合作夥伴）要暫時存取你的資源，可透過 Cross-account Role 授權

✅ 實作建議：

• 儘量使用 Role，而非把 Access Key 寫死在程式中（這是重大安全風險）
• Role 名稱應說明用途，例如：EC2-UploadToS3-Role
• 需要跨帳號時，搭配 Resource-based Policy 一起設計

小結：三種身份的對比整理

Resource-based Policy 怎麼運作？

在 IAM 的世界裡，我們前面提到了一種常見的授權方式叫做 Identity-based Policy，意思是「我這個人／服務，能做什麼事」。

但 AWS 中也有一種相反邏輯的授權方式，叫做 Resource-based Policy（資源型政策），意思是：

「我是某個資源，我要決定誰可以來使用我。」

也就是說，這種授權邏輯是從資源本身出發來設定的，它會寫在資源內部，例如某個 S3 Bucket、Lambda Function、SNS Topic、SQS Queue 等。

資源透過這份政策來對外開放或限制存取行為。

Resource-based Policy 的使用場景

這種 Policy 通常用在以下幾種情境：

Resource-based Policy 的語法結構

一份 Resource-based Policy 的 JSON 通常會包含以下欄位：

進一步解析 Principal

Resource-based Policy 跟 Identity-based Policy 最大的語法差異就是多了一個欄位：

"Principal": {
  "AWS": "arn:aws:iam::123456789012:user/partner"
}

這行代表的是：「我這個資源允許帳號 123456789012 下的 partner 使用者來存取我。」

Principal 的值可以是：

📘 實際範例：S3 公開讀取設定

假設你想要讓「全世界」都可以讀取某個圖片資料夾：

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/public/*"
}

這段代表：

• 任何人（"*"）都可以對 my-bucket/public/ 資料夾下的物件執行 s3:GetObject（讀取）行為
• 常用於放置公開圖片、影片或前端靜態檔案（如網站 HTML、JS）

⚠️ 注意：這會讓任何人都可以不登入就存取該路徑，因此要謹慎使用！

語法小技巧：允許跨帳號使用你的資源

假設你擁有一個帳號 A，要讓帳號 B 下的 Lambda 可以觸發你帳號 A 的 SNS Topic，就需要寫一份 Resource-based Policy 在 SNS 上：

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::987654321000:role/LambdaInvoker"
  },
  "Action": "sns:Publish",
  "Resource": "arn:aws:sns:ap-northeast-1:123456789012:MyTopic"
}

這樣帳號 B 的 LambdaInvoker 角色就可以「發訊息」到你的 SNS Topic。

🔒 安全建議與注意事項

如果把 IAM Identity-based Policy 想像成「主動請求的能力」，那麼 Resource-based Policy 就像是「資源開門的許可」。

兩者常常需要同時搭配使用，才能完成一個完整的跨帳號或跨服務授權流程。

IAM 權限評估是如何進行的？

當你透過 AWS CLI、SDK 或控制台發出一個操作請求（例如上傳檔案到 S3），AWS 背後會經過一套嚴謹的「權限判斷流程」來決定是否允許這個行為。

這套流程會根據 IAM 中的各種政策（Policy）來進行評估，遵守一個核心原則：

✅ 預設拒絕（Implicit Deny），明確允許（Explicit Allow），明確拒絕優先（Explicit Deny）。

以下是完整的判斷流程，讓我們一步步來看：

先檢查 Identity-based Policy（身份型政策）

AWS 首先會檢查這個執行操作的身份（User、Group、Role）本身有沒有被賦予相應的權限。

如果該身份的 IAM Policy 中有明確允許這個動作，就進入下一步；

如果找不到任何允許的規則，則預設是「不允許」。

接著檢查 Resource-based Policy（資源型政策）

如果你操作的資源支援 Resource-based Policy（如 S3、Lambda、SNS…），AWS 會同時檢查這個資源有沒有開放權限給你這個「Principal」。

如果資源本身也允許你做這件事，才算完整授權。

📌 補充：兩邊都可以授權，只要有一方允許，就有可能成功。

若有任何一個明確的 Deny，就直接拒絕

這是 IAM 的安全原則之一：Explicit Deny（明確拒絕）優先級最高。

只要在任一條 Policy（無論是身份型還是資源型）中有寫明 Effect: "Deny"，AWS 就會無條件拒絕這次請求，即使其他地方寫了 Allow。

🧠 這可以用來蓋掉某些不應該開放的權限，例如：

{
  "Effect": "Deny",
  "Action": "s3:DeleteObject",
  "Resource": "*"
}

這條會讓你無法刪除任何 S3 物件，即使別的 Policy 說可以。

如果找不到任何 Allow，則預設為拒絕

IAM 採取的是「白名單」原則，意思是：

❌「如果沒有明確說你可以做這件事，那你就是不能做。」

這種「預設禁止」的策略，雖然限制比較嚴格，但可以大幅降低錯誤授權的風險，是大型雲端平台的標準做法。

實際評估流程小例子

假設你是一個 IAM 使用者 Alice，你發出一個動作：想從 my-bucket/public/file.txt 讀取資料（s3:GetObject）：

若反過來，如果 Bucket Policy 有明確 Deny：

{
  "Effect": "Deny",
  "Action": "s3:GetObject",
  "Principal": "*",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

即使你有被 Allow，結果仍然是 ❌ 拒絕。

IAM 整體架構邏輯總覽

以下是 IAM 相關元件的角色說明與定位整理表：