華為雲國際企業帳號 AWS亞馬遜雲帳戶權限說明

華為雲國際企業帳號 前言：權限這件事，看起來很玄但其實有規律

如果把AWS比喻成一棟超大的摩天大樓，那麼「雲帳戶權限」就是大樓裡每扇門的門禁系統。你可能有鑰匙，也可能只能站在門外看別人操作；你可能能開S3的櫃子，但不能碰EC2的機房；你可能在自己的樓層自由走動，卻不能跨到別人的樓層。

而AWS的厲害之處在於：它讓你用很細的粒度控制誰能做什麼、在哪裡做、在什麼條件下做。厲害到什麼程度？厲害到你一不小心就會遇到「怎麼我明明有權限卻還是被拒絕？」的經典人生課題。別怕，這篇文章會用清楚、好讀、帶點幽默的方式，幫你把AWS亞馬遜雲帳戶權限摸順。

AWS權限的核心觀念：你不是在授權“人”，而是在授權“行為”

在AWS裡，權限通常不是一句「你可以」就結束。它會包含三件重要的事：

• 誰（Principal）：使用者、群組、角色，或是跨帳戶的實體。
• 能做什麼（Action）：例如 s3:ListBucket、ec2:StartInstances、cloudwatch:GetMetricData。
• 對哪個資源（Resource）：例如某個Bucket、某個Instance、某個Log Group。

再加上一點運氣（不是啦，是條件條款，Condition），例如限定時間、來源IP、是否使用特定的MFA、或要求使用TLS等。

IAM是權限的主引擎：帳戶權限不是單一開關

AWS的權限主要透過IAM（Identity and Access Management）來管理。IAM讓你能：

• 建立使用者（User）、群組（Group）、角色（Role）。
• 用政策（Policy）定義授權規則。
• 把政策套到使用者、群組或角色上。

很多人第一次接觸會問：「那雲帳戶的權限是不是就只有AWS帳戶的root？」不完全是。root帳戶當然擁有完全權限，但實務上通常不建議日常工作都靠root，因為那會像把所有門的鑰匙都交給自己還不加鎖：安全性會哭。

政策（Policy）是權限的文字劇本：Allow與Deny的差別很重要

AWS政策通常是JSON格式，裡面最常見的效果（Effect）有兩種：

• Allow：允許某些行為。
• Deny：明確拒絕某些行為。

重點來了：在AWS的權限評估中，顯式Deny會蓋過一切Allow。你可以想像成「保安部貼了一張公告：就算你有其他門禁卡，這扇門你也不准進」。所以如果你遇到權限被拒，先去找Deny。

權限評估的邏輯：最後看的是“結果”，不是看你以為會怎樣

當你發送請求給AWS服務時，AWS會根據所有相關政策做評估。整體概念通常是：

• 尋找所有允許你執行該Action的政策。
• 同時尋找是否存在任何明確拒絕（Explicit Deny）。
• 若有Explicit Deny，直接拒絕。
• 若沒有Deny且存在Allow，則允許。
• 若沒有任何Allow，就預設拒絕（Implicit Deny）。

所以你會得到一個很現實的結論：AWS預設是不讓你做，你要用政策明確允許。

權限的落點：政策可以掛在哪些地方？

AWS的政策不會只出現在一個地方。常見的掛載位置包括：

• Identity-based policies（身分型政策）：掛在IAM使用者、群組或角色。
• Resource-based policies（資源型政策）：掛在資源本身，例如S3 Bucket Policy、SQS Queue Policy。

這兩種政策的存在方式不同，但最終效果都會納入權限判斷。換句話說：有些服務比較吃「資源型政策」，有些比較吃「身分型政策」。你要做的不是死背，而是看到需求就對應。

常見角色（Role）與使用者（User）：為什麼AWS偏愛Role？

使用者（User）是長期憑證（例如登入IAM使用者）。角色（Role）則是給「被允許去扮演某件事」的機制，常用於：

• 跨帳戶存取（Account A 讓 Account B 的人或服務操作）。
• EC2或Lambda等服務需要以某個權限執行。
• 使用Federation（例如企業身分系統登入AWS）。

角色常被採用，是因為它能更好地控制臨時憑證、降低暴露風險，也能更容易套用條件。簡單說：你可以把User想成「永久員工證」，Role想成「當天通行證」。不過員工證也要管理好，角色也不是萬能。

最小權限原則（Least Privilege）：別讓權限變成萬用鑰匙

最小權限原則的核心是：只給你完成工作所需的權限。它不是一句口號，而是能實際減少風險。

舉個常見例子：你可能只是要讓某個人讀取S3的特定資料夾，結果你卻給了該帳戶對整個S3的完全管理（s3:*）。等到某天誤操作、或憑證外洩，損失會比你想像的大很多。

最小權限不是讓你痛苦到每次都手動磨政策，而是讓你能以流程管理方式做到「剛剛好」。例如先從受限版本開始、再逐步擴展；或使用AWS Access Analyzer、IAM Access Advisor等工具協助判斷。

AWS常見資源的授權示例概念：用“能做的事”來想

雖然每個服務都有細節，但你可以用通用策略思考：先確認Action，再鎖定Resource，最後補上Condition。

S3（儲存桶）權限：Bucket Policy常常是關鍵

S3權限常見會用到兩層：身分型政策給使用者/角色要做什麼，另外可能還需要資源型政策（Bucket Policy）決定哪些主體能存取該Bucket。

華為雲國際企業帳號 例子思路：

• 要列出Bucket物件：通常包含 s3:ListBucket，資源鎖定到Bucket本身。
• 要讀取物件：通常包含 s3:GetObject，資源鎖定到物件路徑（例如 arn:aws:s3:::bucket-name/prefix/*）。

如果你發現「角色已經有GetObject，但仍然AccessDenied」，那就很可能是Bucket Policy或其他條件沒有符合。

EC2（虛擬機）權限：Start/Stop與Describe是常見分工

EC2權限通常分成幾類行為：

• 查看資訊：例如 ec2:DescribeInstances（很多團隊需要只讀）。
• 啟停資源：例如 ec2:StartInstances、ec2:StopInstances。
• 更改設定：例如 ec2:ModifyInstanceAttribute、ec2:TerminateInstances（這通常是高風險操作）。

常見實務是：管理員有啟停與終止權限；一般人只要Describe即可，免得你某位同事一時手滑把測試機終止，然後大家一起進行“尋找昨天備份在哪”的偵探劇。

CloudWatch（監控）權限：讀取與查詢通常需要不同Action

CloudWatch權限常用在查詢指標、查看Log事件等。你會看到類似 cloudwatch:GetMetricData、logs:DescribeLogGroups、logs:GetLogEvents 等Action。

若你只想讓人看儀表板但不能改設定，通常不需要任何put類型的權限。這也是最小權限原則最常被忽略的地方：很多人一股腦給了太多寫入權限，結果監控資料被改、告警被關，然後你才發現「原來不是系統壞，是權限被改了」。

跨帳戶授權：你以為是同一個世界，其實是不同宇宙

跨帳戶時，你會遇到兩個重點：

• Account A 的角色/使用者要能假定（AssumeRole）到 Account B 的角色。
• Account B 的角色必須信任Account A的主體（Trust Policy）。

這裡的直覺是：Trust Policy管“誰能扮演這個角色”，而該角色的權限政策管“扮演後能做什麼”。

若跨帳戶失敗，常見狀況是：

• Trust Policy不包含Account A的主體或ARN條件不符合。
• AssumeRole成功了，但角色本身沒有對目標資源的Allow。

所以排錯要有順序：先查AssumeRole是否成功，再查資源存取是否允許。

條件（Condition）：讓權限從“有或沒有”變成“在某些情況才行”

Condition可以像是一個更精細的門禁邏輯。例如：

• 只允許特定來源IP：IpAddress / NotIpAddress。
• 要求使用特定MFA：Bool條件（例如 aws:MultiFactorAuthPresent）。
• 只允許透過TLS：Bool aws:SecureTransport。
• 限制資源標籤（Tag-based access）：例如要求資源具備特定Tag。

條件不是裝飾品，它是把風險往下壓的工具。當你想避免「任何地方、任何時間都能操作」時，就用Condition。

政策變更與版本控管：權限也是程式，別只靠腦記

當權限逐漸擴張、逐漸堆疊，最常見的災難是：你忘了某條政策是何時加的、為什麼加、現在是否還需要。

建議你做幾件很實務的事：

• 用版本控管（Git）管理IAM政策檔案。
• 用Infrastructure as Code（如CloudFormation、Terraform、AWS CDK）管理資源與政策。
• 華為雲國際企業帳號 變更後記得審查（Review）與建立審計（Audit）。

權限管理如果只靠口頭傳承，那最後通常會變成「你以為我以前有寫，但其實我只口頭說過」。這不是你錯，是流程需要一點工程化。

排錯指南：為什麼你會被拒絕（AccessDenied）的常見原因

當你遇到AccessDenied，不要先慌。AWS的錯誤雖然不一定像真人客服那樣溫柔，但它通常能引導你定位。

華為雲國際企業帳號 1）你忘了Allow，或Allow不覆蓋到資源

最常見的原因之一是Resource沒鎖到正確ARN，或Action拼錯（例如把 GetObject 寫成 GetObjs）。

2）隱式拒絕：沒有任何政策允許

AWS預設拒絕，所以沒有顯式Allow就會被拒。

3）顯式Deny在某處踩了你

只要某個政策存在Deny，就會蓋掉所有Allow。你需要檢查是否有SCP（在組織層級）、或其他策略中有Deny。

4）信任關係（Trust Policy）不符合

跨帳戶或角色假定失敗時，常見就是Trust Policy沒放對Principal，或條件條件沒有符合。

5）條件（Condition）沒過

例如限制了來源IP或MFA，你以為有，結果其實沒有。或者你測試的環境來源IP不同，導致條件不成立。

組織層級的控制：AWS Organizations 與SCP（服務控制政策）

如果你在使用AWS Organizations，那權限會多一層：SCP。SCP可以在組織/OU層級限制成員帳戶能做的事。這有點像公司規定：就算部門給你一張門禁卡，你也不能進入“全公司禁止區”。

SCP特別要注意：它可能讓你即使在帳戶內寫了Allow，仍然會被拒絕。排錯時別只盯著IAM帳戶設定，也要檢查Organizations。

實務建議：讓權限管理更省力、更安全

下面這些建議不會讓你立刻成為AWS權限大師，但會讓你少踩坑、速度快很多。

建立權限模板與責任分工

例如：

• 只讀角色模板（ReadOnly）
• 監控查看角色模板（MonitoringViewer）
• 部署角色模板（DeploymentRole）
• 高風險操作角色模板（BreakGlass，通常加上MFA）

把常見需求標準化，比每次都手寫政策快，也更容易審核。

用標籤（Tags）做資源授權時的邏輯

當你的資源規模變大，按資源ARN逐一指定會很麻煩。透過Tag-based access，可以讓你按業務屬性授權，例如project、team、environment（dev/stage/prod）。

注意：Tag-based access很強，但要確保Tag治理做得好，否則你會遇到「資源沒有Tag，所以誰也用不了」的狀況。

定期回顧權限（Access Review）

人會變、專案會停、責任會移轉。權限也要跟著整理。定期檢查不僅能減少風險，也能省下你未來大量的排錯時間。

啟用權限分析與事件追蹤

你可以善用AWS工具來做權限可視化與分析，並對CloudTrail事件保留審計紀錄。簡單說：權限出了事，你至少要知道是誰做了什麼、何時做、從哪裡做。

小抄：用一句話快速記住AWS權限

如果你只想記一段最精簡的重點，可以把AWS權限理解成：

AWS允許你做某件事，必須符合Allow且沒有Deny；再加上Trust Policy（角色假定）與Condition（條件）都得過。

剩下的差異就是各服務的Action/Resource規則，以及政策要放在身分或資源的哪裡。

結語：權限不是障礙，是你在雲端的護城河

AWS亞馬遜雲帳戶權限的世界看起來可能像一疊疊表格、像一串串ARN、像一段段JSON，但當你把它拆成「誰」「能做什麼」「對哪個資源」「在什麼條件」後，它就會開始變得有規律、有章法。

當你能用最小權限、用角色管理、用政策與條件精準控制存取，你就不是在“設定權限”，你是在打造一套可靠的安全與治理機制。雲端越做越大時，權限管理就是那道護城河；而這道護城河修得好，你未來就少很多“為什麼我不能做”的人生內耗。

最後送你一句很現實的話：權限不是寫完就結束，而是要持續審查與調整。畢竟世界會變，需求會變，你的權限也應該跟得上。