IAM 政策評估與角色：一個請求為什麼被允許、又為什麼被拒絕

💡 先搞懂問題

虛構公司「青松物流」把月報表放在 S3 儲存貯體 qingsong-reports，訂單程式跑在 EC2 上。上線第一週就出了兩件事：工程師美玲的 IAM 使用者明明掛了「S3 讀寫」的政策，刪除舊報表時卻收到 AccessDenied；另一邊，資安同仁發現外部稽核廠商的帳戶居然讀得到報表，可是沒有人記得在哪裡開放過。兩件事的根源一樣：一個請求同時受到好幾份政策影響，大家只看了其中一份。

新手最常卡在三個地方。第一，以為「沒寫 Deny 就是允許」，其實 AWS 預設全部拒絕，只有被明確允許的才會過。第二，以為 Allow 寫得越多權限越大，忽略了組織層級的 SCP、角色上的權限界限這類「天花板」，它們不給權限，只把上限壓低。第三，以為權限只看自己身上的政策，忘了 S3 儲存貯體政策這種掛在資源上的政策，同樣能放行或擋下請求，跨帳戶時更是兩邊都要同意。

處理這件事的是 AWS Identity and Access Management（IAM）。每一次 API 呼叫都是一個請求（request），裡面有主體（principal），也就是誰在呼叫；動作（action），例如 s3:GetObject；資源（resource），例如某個物件的 ARN；以及來源 IP、時間、MFA 等條件內容（context）。AWS 收集所有適用的政策（policy），依照固定的政策評估邏輯（policy evaluation logic）算出最後是允許（Allow）還是拒絕（Deny）。

生活比喻：公司門禁

青松物流的辦公大樓用門禁刷卡。每位員工的識別證上登記了可以進哪些區域，這份權限跟著人走，換樓層也有效。每層樓的管理處也會在門口貼一張名單，寫明「這些人可以進來」，名單上有你，就算識別證沒登記，管理處也會放你進去。總部另外規定了幾個禁區，例如機房只准資訊部進入，就算樓層名單寫了你、識別證也登記了，總部的禁令照樣擋下。外包廠商來施工，不發正式識別證，而是由櫃台核發臨時訪客證，只開指定的門，下班時間一到自動失效。

大樓的保全只做一件事：每次有人刷卡，就把識別證、門口名單、總部規定一起拿出來比對。有人寫了「禁止」，直接擋下；都沒提到你，也不放行；至少有一份明確寫了「可以」，而且沒有任何上限規定把你排除，門才會開。

比喻有三個地方和 AWS 不一樣，偏偏都是最常考錯的地方。第一，大樓保全可能看你面熟就放行，AWS 沒有「通融」：沒有任何政策明確允許，就是拒絕，這叫隱含拒絕（implicit deny）；任何一份適用的政策寫了 Deny，就是明確拒絕（explicit deny），壓過所有允許。第二，門禁名單在 AWS 裡要分清楚是同帳戶還是跨帳戶：同一個帳戶內，資源型政策或身分型政策任一個允許通常就夠；跨帳戶時，請求方帳戶的身分型政策和資源擁有者的資源型政策兩邊都要允許。第三，臨時訪客證在 AWS 裡不只給外人用，EC2、Lambda 上的程式也應該用角色取得臨時憑證，而不是把長期的存取金鑰寫進設定檔。

🎮 互動實驗室一：政策評估模擬器

左邊先決定請求：誰（主體）、做什麼（動作）。資源會跟著動作自動帶出：S3 動作打在儲存貯體 qingsong-reports 的物件上，EC2 動作打在一台執行個體上。再從下拉選單組合六種政策。右邊會照 AWS 官方的評估順序一步一步檢查：明確拒絕 → RCP → SCP → 資源型政策 → 身分型政策 → 權限界限 → 工作階段政策，並標出在哪一步做出最後決定。可以先按「我猜 Allow」或「我猜 Deny」再看結果；上方 8 個情境會自動載入一組設定，適合從頭練一次。

🎮 互動實驗室二：身分做法分診台

每張卡是一個虛構公司的需求：某個人、某支程式或某個外部單位要存取 AWS。從七種做法中選出最適合的一種：IAM 使用者＋存取金鑰、EC2 執行個體設定檔、Lambda 執行角色、IAM Identity Center 權限集、跨帳戶角色、OIDC 聯合角色，或是只有根使用者能做的工作。判斷的順序是先看「誰」要存取，再看「從哪裡」來，最後才想權限內容。答完會說明原因；選錯時也會說明你選的那一種適合什麼情況。

🛠️ 操作教學：替 EC2 建立 IAM 角色並檢查權限

情境：青松物流的訂單程式跑在 EC2 上，要讀取儲存貯體 qingsong-reports 裡的報表。過去有人把存取金鑰寫在設定檔裡，這次改用 IAM 角色。左邊是簡化的主控台，照步驟選信任的實體、挑許可政策、取名、建立角色，再把角色掛到執行個體上，最後用政策模擬器確認「能讀、不能刪」。右邊的 AWS CLI 與 CloudFormation 會跟著你選的服務、政策、名稱即時更新，目前步驟對應的那幾行會用底色標出來。可以故意把角色名稱打成中文或加空白，看看驗證訊息。

範例中的客戶受管政策

步驟 2 可以選的「qingsong-reports-read」是青松物流自己寫的客戶受管政策（customer managed policy），只允許列出這個儲存貯體與讀取裡面的物件。和 AWS 受管的 AmazonS3ReadOnlyAccess 相比，它把 Resource 縮到單一儲存貯體，是比較貼近最小權限的寫法。這份政策要先存在帳戶裡，角色才掛得上去；建立方式是 aws iam create-policy --policy-name qingsong-reports-read --policy-document file://reports-read.json。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListReportsBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::qingsong-reports"
    },
    {
      "Sid": "ReadReportObjects",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::qingsong-reports/*"
    }
  ]
}

注意兩個 Resource 的差別：s3:ListBucket 作用在儲存貯體本身，s3:GetObject 作用在物件，所以後面要加 /*。這是寫 S3 政策最常見的錯誤之一，寫反了就會出現「列得出檔名卻讀不到內容」或反過來的情況。

自己動手時要注意

權限：操作的人至少需要 iam:CreateRole、iam:AttachRolePolicy、iam:CreateInstanceProfile、iam:AddRoleToInstanceProfile；把角色掛到執行個體上還需要 iam:PassRole（把角色交給 AWS 服務使用的權限）與 ec2:AssociateIamInstanceProfile；用模擬器檢查要 iam:SimulatePrincipalPolicy。iam:PassRole 值得特別留意：能把任何角色交給 EC2 的人，等於能讓自己啟動的機器擁有那個角色的權限，所以實務上會把它的 Resource 限縮到特定角色。

費用：IAM 本身不另收費，建立角色、政策、執行個體設定檔都不花錢；費用來自你接著啟動的 EC2 執行個體與 S3 的儲存與請求。2025-07-15 以後建立的新帳戶適用抵用金制的 Free Tier，選「免費方案」的帳戶不會被收費，但到期或抵用金用完會關閉帳戶；選「付費方案」的帳戶抵用金用完後就依用量計費，練習完記得把執行個體終止。

清理：用 CLI 建立的，要照「先拆後刪」的順序：把角色從執行個體設定檔移除、刪除執行個體設定檔、卸離受管政策、刪除內嵌政策，最後才能刪除角色（角色上還掛著政策或還在設定檔裡時，刪除會失敗）。用 CloudFormation 建立的，刪除堆疊就會一併刪除它建立的角色與執行個體設定檔。

# 用 CLI 建立的：照順序拆掉再刪除
aws iam remove-role-from-instance-profile --instance-profile-name qingsong-order-ec2-role --role-name qingsong-order-ec2-role
aws iam delete-instance-profile --instance-profile-name qingsong-order-ec2-role
aws iam detach-role-policy --role-name qingsong-order-ec2-role --policy-arn arn:aws:iam::111122223333:policy/qingsong-reports-read
aws iam delete-role-policy --role-name qingsong-order-ec2-role --policy-name uploads-write
aws iam delete-role --role-name qingsong-order-ec2-role

# 用 CloudFormation 建立的：刪除堆疊，角色與執行個體設定檔一起刪除
aws cloudformation delete-stack --stack-name qingsong-order-role

不要寫進範例的東西：本頁的帳戶 ID 一律用官方文件慣用的 111122223333，外部帳戶用 444455556666。真實的帳戶 ID、存取金鑰、秘密存取金鑰不要貼進程式碼儲存庫、聊天群組或教學文件；這一頁的重點正是讓程式透過角色自動取得臨時憑證，從此不需要保存任何金鑰。

📘 原理補完

官方評估順序：七個關卡，任一關說「不」就停

AWS 文件把單一帳戶內的評估寫成固定順序。第一步先在所有適用政策中找明確拒絕，找到一條就結束。接著看 AWS Organizations 的 RCP 與 SCP：它們是「允許清單」，如果 RCP 或 SCP 沒有任何陳述式允許這個動作，結果就是拒絕；所以預設會掛 RCPFullAWSAccess 與 FullAWSAccess 這兩個全部允許的受管政策，拿掉之前要先換上別的允許政策。然後才輪到會授予權限的資源型政策與身分型政策，最後是權限界限與工作階段政策這兩道天花板。順序本身只影響「在哪一步做出決定」，不影響結果：任何一處明確拒絕都會贏，每一道天花板都要允許。

第 ④ 步的細節最常被問到。官方的說法是：在同一個帳戶內，「只要身分型政策或資源型政策其中一個明確允許」通常就足以放行，但會依主體類型不同而有差異。以 IAM 使用者 ARN 授權的資源型政策，不受身分型政策或權限界限的隱含拒絕限制；以角色 ARN 授權的，仍受權限界限與工作階段政策的隱含拒絕限制；直接以角色工作階段 ARN 授權的，則不受這三者的隱含拒絕限制。另外有兩個例外：IAM 角色的信任政策與 KMS 金鑰政策，一定要在這份資源型政策裡明確允許主體，身分型政策單獨給不了。

誰會給權限、誰只會收權限

把這些政策分成兩群最好記。會授予權限的只有身分型政策與資源型政策；只設上限的有 SCP、RCP、權限界限、工作階段政策。上限政策寫了 Allow 也不會讓任何人多一點權限，它只是告訴評估引擎「這個範圍之外的一律不行」。所以最後的有效權限可以寫成：（身分型政策 ∪ 資源型政策）∩ SCP ∩ RCP ∩ 權限界限 ∩ 工作階段政策，再扣掉所有明確拒絕。

同帳戶與跨帳戶：要幾個人同意

同一個帳戶內，身分型政策與資源型政策是「聯集」，任一邊允許就有機會成功，這也是為什麼實驗室情境 ⑤ 裡，美玲身上什麼政策都沒有，靠儲存貯體政策也能刪檔。跨帳戶時規則變成「兩邊都要」：請求方帳戶要用身分型政策允許自己的主體發出請求，資源擁有者帳戶的資源型政策也要允許這個外部主體，兩次評估都是 Allow 才會成功。資源不支援資源型政策的服務（例如 EC2 執行個體），跨帳戶的標準做法是在資源所在的帳戶建立角色，讓對方用 sts:AssumeRole 擔任，進到帳戶裡面以後就變成同帳戶的請求。

IAM 角色：信任政策決定誰能拿，權限政策決定拿了能做什麼

角色沒有密碼也沒有長期存取金鑰。它有兩份政策：信任政策（trust policy）是一種資源型政策，Principal 寫的是誰可以擔任這個角色，例如 ec2.amazonaws.com、另一個帳戶、或某個 OIDC 身分提供者；權限政策是身分型政策，決定擔任之後能做什麼。擔任角色時由 AWS STS 發出臨時憑證，AssumeRole 的工作階段預設 1 小時，最長可到角色設定的最大工作階段時間（上限 12 小時），角色串接時最長 1 小時（查證於 2026 年 10 月）。

EC2 不能直接「拿」角色，中間隔了一個執行個體設定檔（instance profile）：它是裝角色的容器，一個設定檔只能裝一個角色。用主控台建立 EC2 用途的角色時，會自動建立同名的設定檔；用 CLI 或 API 則要自己建立並把角色放進去，這也是操作教學第 5 步的由來。執行個體上的程式透過執行個體中繼資料服務取得臨時憑證，SDK 會在到期前自動更新，所以程式碼裡完全不需要金鑰。Lambda 則直接使用執行角色，不需要設定檔。

判斷步驟：先問誰、再問從哪裡來

1. 如果是只有根使用者能做的工作（關閉帳戶、變更根使用者 Email、設定 S3 MFA delete 等），用根使用者，做完立刻鎖回去；其他任何工作都不要用它。
2. 如果是「人」，而且是自家員工：用 IAM Identity Center，接公司既有的身分提供者，用權限集指派到各帳戶。自家 App 的終端使用者則是 Amazon Cognito 的範圍。
3. 如果是程式，而且跑在 AWS 裡：EC2 用執行個體設定檔、Lambda 用執行角色、ECS 用任務角色，一律是角色。
4. 如果是程式，但跑在 AWS 外面、能提供 OIDC 或 SAML 權杖（例如 CI 平台）：用聯合身分換取臨時憑證。
5. 如果是另一個 AWS 帳戶：在資源所在的帳戶建立跨帳戶角色；如果是第三方，加上外部 ID。
6. 只有以上都不適用（只支援存取金鑰的第三方工具、緊急存取帳號）時，才建立 IAM 使用者與長期金鑰，並限縮權限、定期輪替、監控使用。

容易考錯的地方

Allow 不等於成功：題目描述「已經給了 Allow 卻仍被拒絕」時，依序檢查有沒有明確拒絕（儲存貯體政策、SCP）、SCP 是否只允許部分服務、權限界限、工作階段政策。干擾選項常是「再加一條 Allow」，但天花板政策不會因為多一條 Allow 就放寬。

SCP 的三個例外：SCP 對管理帳戶的使用者與角色無效、不限制服務連結角色，但會限制成員帳戶的根使用者。題目若問「如何限制管理帳戶的管理員」，SCP 不是答案；若問「如何防止成員帳戶的任何人（包括根使用者）停用 CloudTrail」，SCP 正是答案。

SCP 和 RCP 怎麼分：要限制「我們自己的身分能做什麼」用 SCP；要限制「我們的資源能被誰存取」，尤其是擋組織外部的身分，用 RCP。SCP 管不到外部帳戶的身分。

SCP 和權限界限怎麼分：兩者都是上限，SCP 套在 OU 或帳戶上影響所有人，權限界限套在單一使用者或角色上。「讓開發者能建立角色，但不能建出比自己權限更大的角色」是權限界限的經典情境。

跨帳戶要兩邊：只改一邊的選項幾乎都是錯的。用角色做跨帳戶時，「目標帳戶的角色信任來源帳戶」加上「來源帳戶的身分有 sts:AssumeRole 權限」才完整；第三方再加外部 ID。

工具怎麼查：想知道某個角色能不能做某件事，用 IAM 政策模擬器或 aws iam simulate-principal-policy，它會評估身分型政策與 SCP，但不支援 RCP，結果也可能和實際環境有出入；想找出被分享到組織外的資源、或沒在用的權限，用 IAM Access Analyzer。

以上概念在 CLF-C02（IAM、根使用者保護、IAM Identity Center）、SAA-C03（IAM 使用者、角色、政策、聯合身分與多帳戶安全策略）、DVA-C02（assume role、AWS STS）、SOA-C03（SCP、IAM Access Analyzer、IAM Identity Center）與 SCS-C03（Organizations 政策、根憑證管理、Identity Center）的考試指南中都有列出。

✅ 自我檢測

以下 6 題都是原創題，選完會立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6