一家國內SaaS企業在AWS上運作了半年後，某天收到了一封來自AWS的異常帳單郵件——單月帳單突然從2000美元飆升到1.8萬美元。
排查後發現：一名離職員工的帳號沒有及時刪除，其AccessKey被洩露，駭客用這個金鑰在多個區域批量啟動了高效能GPU實例挖礦。
這次事故完全可以避免——如果他們當初正確配置了AWS IAM。
IAM（Identity and Access Management）是AWS帳戶安全的第一道防線，也是最容易被忽略的防線。
一、AWS IAM是什麼？它解決什麼問題？
AWS IAM是AWS提供的身分和存取管理服務，核心功能是控制誰能存取你的AWS資源，以及能做什麼。
沒有IAM的世界會發生什麼事：
- 所有人共用Root帳號的使用者名稱和密碼
- 一個實習生有和CTO相同的權限
- 當外部合作商存取你的S3桶時，順便可以看到所有RDS資料庫
有了IAM之後，你可以精確控制：
- 誰（人員/系統）能訪問
- 哪些AWS服務和資源
- 什麼操作（讀/寫/刪除/管理）
- 在什麼條件下（IP限制/時間限制/MFA驗證）
IAM是免費服務，不需要額外付費。
二、IAM的四個核心概念
在實操之前，必須先弄清楚IAM的基本組成：
1. IAM用戶（User）
代表一個具體的人或應用程式。每個IAM使用者有獨立的登入憑證（使用者名稱+密碼，或AccessKey）。
適合場景：
- 給開發團隊每個成員建立獨立帳號
- 為自動化腳本/CI/CD工具建立專屬帳號
2. IAM用戶群組（Group）
將多個使用者歸為一組，統一管理權限。給使用者群組分配策略，群組內所有使用者自動繼承。
適合場景：
- 開發群組、維運組、資料組分別賦予不同權限
- 新員工加入直接加入對應群組，無需單獨配置權限
3. IAM策略（Policy）
策略是權限規則的JSON文檔，定義」允許或拒絕什麼操作」。
AWS提供兩類策略：
- AWS託管策略：AWS預置的常用策略，如AdministratorAccess、ReadOnlyAccess
- 客戶託管策略：你自己創建的自訂策略，更精細
4. IAM角色（Role）
角色是可以被」暫時扮演」的權限身份，沒有固定的使用者名稱和密碼。
適合場景：
- EC2執行個體需要存取S3（給EC2綁定角色，而不是在程式碼裡寫AccessKey）
- 跨帳號存取（A帳號的服務存取B帳號的資源）
- 第三方服務（如GitHub Actions）部署到你的AWS帳戶
| 概念 | 類比 | 核心用途 |
|---|---|---|
| IAM用戶 | 員工工牌 | 具體人員/系統的登入身份 |
| IAM使用者群組 | 部門 | 批量管理同類用戶的權限 |
| IAM策略 | 權限清單 | 定義能做什麼/不能做什麼 |
| IAM角色 | 臨時訪客證 | AWS服務間/跨帳號的臨時權限 |
三、最小權限原則：IAM安全的核心思想
在配置任何IAM權限之前，必須記住一個原則：
最小權限原則（Principle of Least Privilege）
只給每個使用者/角色/服務剛好夠用的權限，不多給一分。
這意味著：
- 開發人員只需要存取開發環境的EC2和RDS，不需要生產環境權限
- 資料分析師只需要S3讀取權限，不需要EC2啟動權限
- Lambda函數只需要寫DynamoDB的權限，不需要讀取S3
很多企業圖省事，給所有人AdministratorAccess 全管理員權限，這是最危險的做法。
四、實操配置：從零建立安全的IAM體系
第一步：保護Root帳號
Root帳號是AWS帳號」的最高權限」帳號，一旦被盜，後果不可控。
Root帳號安全三件事：
- 開啟MFA（多因子認證）：在AWS控制台→ 安全憑證→ 啟動MFA，綁定手機Authenticator App
- 不建立AccessKey：Root帳號不要產生程式存取金鑰
- 只用於帳單管理：日常操作全部切換到IAM用戶完成
第二步：建立管理員IAM用戶
在IAM控制台建立一個管理員用戶，用於日常運維，取代Root帳號登入。
配置要點：
- 使用者名稱建議用真實姓名或工號，如admin-zhangsan
- 存取類型：勾選”AWS管理控制台存取”
- 權限策略：附加AdministratorAccess（僅限真正的管理員）
- 同樣為此用戶開啟MFA
以後登入AWS一律使用這個IAM用戶，Root帳號封存備用。
第三步：建立使用者群組並分配權限
依團隊職能建立使用者群組，並為每組指派對應策略。
建議的基礎使用者群組配置：
| 使用者群組名稱 | 適合人員 | 建議附加策略 |
|---|---|---|
| Developers | 開發工程師 | AmazonEC2FullAccess + AmazonS3FullAccess（限開發環境） |
| DataAnalysts | 資料分析師 | AmazonS3ReadOnlyAccess + AmazonAthenaFullAccess |
| DevOps | 維運工程師 | PowerUserAccess（排除IAM管理權限） |
| Billing | 財務/管理層 | AWSBillingReadOnlyAccess |
| ReadOnly | 審計/合規 | ReadOnlyAccess |
第四步：為EC2/Lambda配置IAM角色
這是最容易被遺漏的步驟，也是安全事故的高發點。
錯誤做法：在EC2實例的程式碼或設定檔裡直接寫入AccessKey ID和SecretKey。這些密鑰一旦被提交到GitHub或洩露，攻擊者可以立即使用。
正確做法：建立IAM角色並綁定到EC2實例。
具體步驟：
- 在IAM控制台→ 角色→ 建立角色
- 選擇”AWS服務” → “EC2″作為信任實體
- 附加需要的策略（如AmazonS3ReadOnlyAccess）
- 為角色取名，如ec2-s3-readonly-role
- 在EC2實例設定中，將此角色附加到實例
EC2執行個體上的程式碼透過執行個體元資料自動取得臨時憑證，無需在程式碼中硬編碼任何金鑰。
第五步：建立自訂精細化策略
當AWS託管策略粒度不夠細時，就需要建立自訂策略。
一個典型場景：允許使用者只讀取特定S3桶，而不是所有S3桶。
自訂策略的核心要素包括四個欄位：
- Effect：Allow（允許）或Deny（拒絕）
- Action：具體的API操作，如s3:GetObject、ec2:DescribeInstances
- Resource：具體資源的ARN（Amazon資源名稱），支援通配符
- Condition（可選）：額外條件，如IP限制、MFA要求
以」只讀特定S3桶」為例，策略邏輯是：允許執行s3:GetObject 和s3:ListBucket 兩個操作，但將資源限定為特定桶的ARN，而不是所有S3資源。
五、IAM安全進階：4個容易忽略的關鍵設置
設定密碼策略
在IAM控制台→ 帳戶設定→ 密碼策略，建議配置：
- 最小密碼長度：12位以上
- 要求包含大寫字母、小寫字母、數字、特殊符號
- 密碼有效期限：90天
- 禁止重複使用最近5次密碼
定期審查和輪換AccessKey
透過IAM的”憑證報告”功能，可以匯出所有使用者的AccessKey使用情況，包括：
- Key是否超過90天未輪換
- Key是否從未被使用（應立即刪除）
- 用戶上次登入時間（長期未登入可能需要停用）
建議每季做一次憑證審計。
啟用AWS CloudTrail記錄所有IAM操作
CloudTrail會記錄帳戶內所有API調用，包括IAM配置變更、使用者登入、資源存取等。
這是安全事故溯源的核心工具。發生異常時，可以精確定位是哪個使用者/角色/服務在什麼時間做了什麼操作。
建議將CloudTrail日誌同步到S3並開啟加密存儲，保留至少一年。
使用權限邊界（Permission Boundary）
當你需要授權給下屬管理員（如DevOps Leader）創建IAM用戶，但又擔心他創建的用戶權限超過自己的權限時，可以使用」權限邊界」功能。
權限邊界定義了某個使用者或角色最多能擁有的權限上限，即使策略裡寫了更高權限，實際執行時也受邊界限制。
六、IAM常見問題排除
問題1：用戶登入時提示”無權訪問”
排查順序：
- 檢查使用者是否被附加了策略（或所在使用者群組有策略）
- 檢查資源ARN是否寫對（很多人ARN寫錯）
- 檢查是否有明確的Deny策略覆蓋了Allow（Deny優先順序更高）
問題2：EC2無法存取S3
最常見原因：EC2實例沒有綁定IAM角色，或綁定的角色策略不包含S3權限。
問題3：跨帳號存取失敗
需要在兩邊都設定：被存取帳號的資源策略中允許另一個帳號的ARN，且存取方帳號的使用者/角色有假設目標角色的權限（sts:AssumeRole）。
寫在最後
AWS IAM配置看似複雜，但核心邏輯其實很簡單：最小權限、角色代替金鑰、定期審計。
做到這三點，80%的雲端安全風險就可以規避。
開頭那家差點損失近2萬美元的企業，如果當時做到了”為每人創建獨立IAM用戶+離職立即刪除帳號”，這次事故完全不會發生。
雲端安全的代價，往往在疏忽的那一刻已經註定。
如果你正在搭建AWS環境，或不確定現有IAM設定是否安全，歡迎聯絡aws-oncloudai.com 的技術團隊，我們提供免費的AWS帳戶安全評估服務。
本文由aws-oncloudai.com 雲端架構團隊原創，轉載請註明來源。
