AWS 身分與權限治理（IAM）完整指南：從帳號架構到稽核落地

在雲端時代，企業的資安不再只是防火牆與網路隔離，而是回到一個更根本的問題：「誰可以做什麼？」 

AWS 作為全球主流的雲端平台，提供了高度彈性的資源與服務，但同時也意味著——如果權限控管沒有設計好，風險也會被同步放大。 

AWS IAM（Identity and Access Management）正是解決這個問題的核心工具。透過正確的帳號架構設計、角色分工與權限控管，不僅可以提升操作效率，更能在一開始就建立安全與合規的基礎。本篇文章將從 IAM 的基本架構出發，逐步帶你理解 User、Group、Role、Policy 的實務用法，並進一步透過常見的 Policy 範本，說明如何在「系統可用」與「權限不過度開放」之間取得平衡，協助企業建立一套可長期維運、也能通過稽核的雲端權限治理機制。 

一、為什麼身分與權限治理（IAM）在現今特別重要？ 

隨著企業全面上雲，系統邊界早已不再只是公司內網，而是延伸到各種雲端服務與遠端工作環境，在這樣的架構下，「誰可以存取什麼資源」就成為資安的第一道防線，而這正是 IAM（Identity and Access Management）存在的核心價值。 

近年來多數資安事件，其實並不是因為駭客突破了高強度防護，而是來自於帳號被盜用或權限控管不當。例如員工帳密外洩、權限設定過大（過度授權）、或離職帳號未即時停用，這些都可能讓攻擊者在不被察覺的情況下直接進入系統內部。 

從國際資安報告也可以看到明顯趨勢： 

• 多數資料外洩事件與「身分驗證」或「存取控制」有直接關聯 

• 權限過大（Over-permission）已成為雲端環境最常見的風險之一 

• 零信任（Zero Trust）架構逐漸成為主流，而 IAM 正是其核心基礎 

對企業來說，IAM 不只是「帳號管理工具」，而是整體雲端治理與稽核的基石。透過良好的身分與權限設計，可以有效做到： 

• 避免人為誤操作（如誤刪資料、誤關服務） 

• 降低帳號外洩帶來的影響範圍 

• 滿足 ISO 27001、SOC 2 等資安與合規要求 

也因此，企業在導入 AWS 或進行雲端轉型時，若沒有一套清楚的 IAM 架構與治理機制，後續不僅會面臨資安風險，也會在稽核與管理上付出更高成本。 

二、什麼是AWS IAM (Identity and Access Management) 

AWS IAM 是管理 AWS 服務存取權限的核心工具，其架構主要由以下四項重要元件構成，確保企業能落實「身分識別」與「權限控管」： 
 

AWS IAM 中幾項重要元件:  

• User  

• Group  

• Role  

• Policy 

IAM User (使用者身分管理)  

這是 AWS 中用來代表「誰在操作系統」的身分，可以是工程師、管理員，或是系統程式。當建立 AWS 帳號時，系統會提供一個 Root 使用者（根帳號），這個帳號擁有所有資源的完整控制權，但權限最高同時也代表風險最大。 

因此在實務上，企業通常不會用 Root 帳號進行日常操作，常見做法是：先替 Root 啟用 MFA（多因素驗證）並妥善保管，之後就不再使用它登入，接著會建立一個具有管理權限的 IAM User（例如 Administrator），作為日常操作的主要帳號，再由這個帳號去建立其他使用者並分配適當權限。 一個 AWS 帳號最多可以建立 5,000 個 IAM User，足以支援多數企業的使用需求。 

IAM Group (使用者組) 

這是一組 IAM 使用者的集合，簡單來說，Group 就是將「職位相似」的人打包在一起，並統一核發權限。 
 

相比逐一管理每個使用者，使用 Group 能讓管理變得更直覺且安全，常見的做法是根據職務功能來分類，例如建立： 

• 開發組 (Developers)：只給予修改程式碼的權限。 

• 測試組 (Testers)：僅提供查看測試環境的權限。 

• 維運組 (Ops)：擁有重啟伺服器或調整網路的權限。 
   

當有新員工入職時，管理員只需要將他「加入特定 Group」，就能立刻獲得所需的權限；當員工離職或調職時，也只需從 Group 中移除，不需要去檢查他身上掛了哪些零散的 Policy。 在 AWS 中，一個 User 可以同時屬於多個 Group，而單一帳號下最多可以建立 300 個 Group，足以應對企業內各種精準的角色分工。 

IAM Role (角色) 

這是一項特殊的「虛擬身分」，它與 User 不同並沒有固定的登入密碼或存取金鑰（Access Key），而是供「需要權限的人或服務」暫時切換（Assume）使用。 

可以把 Role 想像成一頂「帶有特定權限的帽子」，誰戴上了它，誰就能在時效內執行對應的任務。常見的實務場景包括： 

• 賦予服務權限：例如讓 EC2 伺服器能讀取 S3 儲存桶的資料，不需要在機器內寫死金鑰，安全性更高。  

• 跨帳號存取：允許公司 A 的管理員暫時登入公司 B 的環境進行除錯。 

• 第三方顧問接入：讓雲端代理商在受控的情況下，安全地檢視您的架構。  

使用 Role 的核心目的是「消除長期金鑰（Long-term Credential）」，這是目前 AWS 安全架構中最推薦的實務標準。 
 

IAM Policy (政策) 

這是定義「誰（Who）能對什麼資源（What）做什麼動作（Action）」的文件，通常以 JSON 格式編寫，是 IAM 權限控管的核心內容。 

Policy 就像是一張「通行證規定」，具體記載了權限的細節。它可以掛載在 User、Group 或 Role 身上。在企業管理中，Policy 的運用掌握了兩大關鍵： 

• 最小權限原則 (Least Privilege)：只給予工作所需的最低限度權限，降低人為失誤導致資料刪除的風險。 

• 分類管理：Policy 有兩種選擇，一種是 AWS 內建的「套餐（受管政策）」，適合通用的場景，例如直接給予開發者完整的 S3 權限；另一種是企業可以針對特定需求「客製化（自定義政策）」，例如精確設定某人只能在週一至週五存取特定的資料夾。 

好的 Policy 設計能讓權限管理變得很靈活，但也需要定期稽核，確保沒有過度授權導致的安全漏洞，很多資安漏洞，都是因為管理員為了省事，直接給了員工「AWS 內建的套餐（全開）」，導致權限太大。身為專業的代理商，我們會建議客戶在關鍵權限上使用「客製化政策」，這才是最安全的作法。 

立即免費檢測您的雲端 IAM 權限 

三、 IAM Policy 怎麼？3 種常見需求的 policy 範本 

理解了 IAM 4 個主要元件，真正影響資安與管理成本的關鍵，最重要的是 Policy 。很多企業一開始為了「先讓系統能跑」，容易直接套用權限較大的受管政策（Managed Policy），短期省事、長期卻會讓權限失控，增加誤刪、外洩與稽核風險。 

比較安全、也更符合實務的做法是：先從最小權限開始，把「能做什麼」與「能動到哪些資源」寫清楚，真的不夠再逐步補上；並在上線前用工具把政策做檢查/驗證，避免語法或邏輯錯誤造成「該擋沒擋、該放沒放」。接下來我們用 3 種最常見的需求情境，提供可直接改用的 Policy 範本，幫你在「可用」與「不過度授權」之間取得平衡。 

情境一：只允許讀取 S3（避免誤刪資料） 

常見錯誤寫法： 

直接套用 AmazonS3FullAccess，等於開放讀、寫、刪全部權限。 

• Sid 欄位可以放公司名稱或用途說明，方便日後稽核時快速辨識這份 Policy 是誰寫的、用途是什麼 

• 只開 ListBucket（列出）與 GetObject（讀取），沒有 DeleteObject 就不可能誤刪 

• Resource 明確指定 bucket 名稱，不影響帳號內其他 bucket 

情境二：只允許操作特定 EC2（避免影響整個環境） 

• 等於整個帳號 EC2 全開 

建議寫法：只允許啟動 / 停止指定實例 

• 不用 ec2:*，只開必要動作 

• Resource 指定到「單一 instance」 

• 避免誤關整批機器（常見事故） 

情境三：限制只能在特定條件下存取（進階安全控管） 

例如：只允許在公司 IP 範圍內操作 

• 使用 Condition 增加限制條件 

• 就算帳密外洩，非公司 IP 也無法使用 

• 是企業資安與稽核常見要求（ISO / SOC2） 

IAM 從來不只是「設定權限」這麼單純，而是企業在雲端環境中的治理能力體現。一套設計良好的 IAM 架構，可以讓權限清楚、責任分明，降低人為錯誤的風險，同時也讓企業在面對資安稽核時更有依據。 

我們建議企業在雲端導入的早期，就將 IAM 納入整體架構規劃的一部分，並定期進行權限檢視與優化。從「最小權限」出發，搭配 Role 與條件控管，逐步建立一套可控、可視、可稽核的權限體系。如果您不確定目前的 AWS 權限是否存在過度授權或潛在風險，也可以透過 CKmates 的專業顧問進行檢視與優化，協助您在不影響既有系統運作的前提下，建立更安全且符合企業成長需求的雲端治理架構。