AWS 權限可以怎麼設？從使用情境看懂 IAM、Cognito、Role、STS 與 SCP

在 AWS 環境裡，權限管理做得好不好，往往會直接影響資安與維運成本，如果身分與權限沒有分清楚，企業不只容易發生誤操作，也可能在稽核時暴露出過度授權的風險。

除了基本的 IAM 權限設定外，AWS 也提供了多種身分與權限治理工具，分別適用於不同的使用者與情境。若能在一開始就依照實際需求來設計權限，不但能提升管理效率，也能降低資安風險，讓雲端環境更符合企業治理與稽核要求。這一篇會從常見的 AWS 權限使用情境出發，帶你看懂 IAM、Cognito、IAM Role、STS 與 SCP 分別適合用在哪裡，以及企業在規劃 AWS 權限時，應該如何選擇最合適的做法。

一、AWS 權限設計對象 

AWS 的權限設計，最重要的第一步不是「先開權限」，而是先搞清楚 誰在使用這個系統，不同對象的身分來源不同，使用方式也不同，因此對應的權限工具也不一樣。 

常見對象與建議做法 

這四種情境看似都和「登入」有關，但實際上設計邏輯完全不同，如果混在一起管理，不只容易出錯，也會讓後續維運變得複雜。 

二、AWS 登入身份認證：Identity Center / SAML  

如果是公司內部員工要登入 AWS，最常見的做法是使用 SAML 或 IAM Identity Center，這類方式適合已經有公司帳號系統的企業，例如 Microsoft Entra ID、Okta、Google Workspace 等，透過整合後，可以讓員工用公司帳號登入 AWS，而不必另外建立一組 AWS 密碼，這種 Federation（身分聯邦） 的機制，讓員工可以用原本的公司帳號「單一登入（SSO）」到 AWS。    

• 帳號統一管理： 
  員工只要用公司原本的帳號登入就好，不用另外記 AWS 帳密，管理也比較方便。 

• 離職後自動失效： 
  如果員工在公司端已經停用帳號，AWS 的登入權限也會一起失效，不需要一個一個手動刪。 

• 安全性更高： 
  公司可以先在自己的登入系統裡設定 MFA（多因素驗證），員工登入 AWS 時就會先通過這一層保護，安全性比較高。 
   

對企業來說，這是最適合內部人員的方式，因為它能讓身分管理與公司既有的 HR 或 SSO 流程接軌。 

三、App 使用者身份證證：Cognito 

如果登入者不是公司內部員工，而是 客戶、會員、玩家或一般 App 使用者，就不適合用 IAM User 或 Identity Center，這類場景通常會使用 Amazon Cognito。 

Cognito 的用途是讓外部使用者可以透過 Email、手機號碼，或第三方帳號（如 Google、Facebook）完成登入，再依照身份取得對應權限，適合用在 App、網站、會員系統、SaaS 產品等需要大量外部使用者登入的情境，且可支援社群登入，如： 

• 會員網站 

• 手機 App 

• 線上平台 

• 遊戲登入系統 
   

簡單來說，Cognito 是給 App 使用者用的，不是給 AWS 內部管理者用的，它的角色是把「外部登入」和「AWS 權限」中間那層做好，避免直接暴露底層 IAM 權限。 

四、AWS 服務身份認證： IAM 

如果是 AWS 服務彼此之間要互相存取資源，例如 EC2 存取 S3、Lambda 讀取 DynamoDB、ECS 呼叫其他 AWS 服務，最正確的方式是使用 IAM Role，Role 的重點在於：它不是固定帳號，也不需要長期密碼或 Access Key，當服務需要權限時，才透過 Assume Role 的方式暫時取得授權。 

 

五、短期權限控管：STS 

一般 IAM User 使用的是長期憑證（如密碼或 Access Key），一旦這些資訊留在開發者的電腦、程式碼、或不小心外洩，風險就會一直存在，直到被發現並刪除為止。為了徹底解決這個資安痛點，AWS 提供了 STS (Security Token Service) 機制，適用於不需要臨時性的任務使用，這些情況比起長期存放帳密，短期 Token 更適合臨時存取與受控操作，例如： 
 

• 顧問臨時協助除錯 

• 跨帳號進行維運 

• 只需要短時間操作某個資源 

• 特定事件處理時才要開權限 

這時候就可以使用 STS（Security Token Service） 發放短期權杖，降低資安風險，也更符合企業治理邏輯。 

六、權限設定： IAM Policy、Permission Boundary 與 SCP 

了解「誰要用什麼方式登入」之後，下一步就是思考：登入後到底可以做什麼，這時候就不能只看登入方式，還要看權限控制的層級。 
 

IAM Policy 

IAM Policy 是最基本的權限規則，它可以掛在 User、Group 或 Role 上，用來定義： 

• 誰可以做什麼 

• 可以對哪些資源做 

• 可以執行哪些動作 

Permission Boundary 

Permission Boundary 是一種「最高權限上限」，它的用途不是直接給權限，而是限制某個 User 或 Role 最多只能擁有多少權限。 

SCP （Service Control Policy）

SCP（Service Control Policy）則是用在 AWS Organizations 層級，針對「整個 AWS 帳號」或「一組帳號（OU）」訂定的最高護欄。它不直接授予使用者權限，而是規定這個帳號「最多只能做到哪、哪些絕對不能動」。 

為什麼它適合多帳號環境？ 對於擁有分支機構或多個開發/測試環境的企業，手動去檢查每個子帳號的 IAM 權限非常困難。這時透過 SCP，管理員可以在總公司帳號（Management Account）一鍵下達指令，讓底下所有子帳號統一遵守安全規範。 

三者的差異可以這樣理解 

• IAM Policy：你可以做什麼 

• Permission Boundary：你最多可以有多大權限 

• SCP：整個帳號或組織可以做什麼 

如果把權限治理想像成一棟建築，IAM Policy 是房間鑰匙，Permission Boundary 是大樓門禁，SCP 則像整個園區的總管理。 

 

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

七、實務應用 FAQ：我該選擇哪種權限管理方式？ 

我們針對了企業 6 項在規劃 AWS 權限時的問題： 

Q1：公司內部開發人員或 IT 帳號要登入 AWS 控制台，建議用什麼方式？ 
A：建議使用 SAML 聯邦認證或 IAM Identity Center，這樣做可以讓員工直接使用公司現有的帳號（如 Google 或 Okta）登入，不需額外管理 AWS 密碼，員工離職時也能一鍵回收所有權限。 
 

Q2：我的手機 App 或手遊需要讓成千上萬個一般使用者登入，該用 IAM 嗎？ 
A：不建議，這種情況請使用 Amazon Cognito， IAM 是設計給員工與內部資源使用的，一般的客戶或玩家應透過 Cognito 進行驗證，這樣既能支撐大量使用者，也能避免將底層 IAM 權限直接暴露給外部。 
 

Q3：我想讓 EC2 伺服器去讀取 S3 裡的檔案，要在程式碼裡放 Access Key 嗎？ 
A：絕對不要。請使用 IAM Role（角色），AWS 會自動幫服務處理身份導換。這樣你的機器不需要存放任何長期金鑰，大幅降低了金鑰外洩被盜用的資安風險。 
 

Q4：公司請了外部顧問來除錯，但我不想給他永久帳號，該怎麼辦？ 
A：建議使用 STS (Security Token Service)，可以發放具有時效性的「短期權杖（Token）」，等顧問處理完任務後，該權限就會自動失效，是處理臨時性、安全性任務的最佳選擇。 
 

Q5：我想委派權限給專案經理，但怕他權限開太大，有什麼預防方式？ 
A：請設定 Permission Boundary（權限邊界），這像是在權限上加了一道「透明天花板」。你可以規定該身分「最高」只能擁有多少權限，就算他給自己掛了 Administrator 政策，只要超出了邊界範圍，依然無法執行。 
 

Q6：公司有多個 AWS 帳號，要如何統一防止底下的人關閉資安日誌？ 
A：請在 AWS Organizations 層級使用 SCP (Service Control Policy)，協助企業能在組織最上層設下「安全護欄」，例如強制禁止所有子帳號刪除 Log 或更改網路設定，以此維持全公司的資安水準。