前言：雲端安全真的是別人的責任嗎？

許多企業在擁抱數位轉型、將業務搬上雲端時，常抱持著一種極具風險的誤解：認為既然付費給了頂尖的雲端服務供應商（CSP），資訊安全就理所當然變成了對方的職責。這種想把麻煩事往外推的心態，在業界被戲稱為「資安甩鍋」。

然而，作為一名資深雲端架構師，我必須嚴肅地告訴你：這種想法是給自己的環境埋下定時炸彈。安全性絕非隨著「搬家」就自動達成，本文將帶你深入剖析 AWS 身份與存取管理（IAM）的核心邏輯，揭開那些對安全策略有深遠影響的 5 個關鍵真相。

真相一：搬家不等於甩鍋——共同責任模型的冷知識

在 AWS 的架構設計中，一切安全討論的起點都是「共同責任模型（Shared Responsibility Model）」。這不僅是技術準則，更是法律與責任的邊界。

「搬到雲端不是把整個資訊安全甩鍋給雲端平台(以下簡稱CSP)。」

這句話道出了雲端安全的本質。AWS 負責「雲端環境本身」的安全（底層硬體、資料中心實體安全），而企業則必須負責「雲端內部」的安全。簡單來說，AWS 保護雲端，而你保護你在雲端裡放的東西。IAM 正是落實這一責任的核心工具，它定義了誰（Who）在什麼條件下（Under which conditions）可以對哪些資源（Which resources）執行什麼操作（Which actions）。

真相二：為什麼你該放棄長期憑證？「角色 (Roles)」的動態魅力

在 IAM 中，使用者（Users）與角色（Roles）的差異不只是名稱而已，更關乎憑證的生命週期。

• 使用者 (Users)： 依賴的是「長期不變」的憑證（Access Keys）。這些憑證就像傳統鑰匙，一旦遺失或外洩，就是永久性的安全缺口，除非你手動更換。
• 角色 (Roles)： 則是透過安全性權杖服務（STS）取得「短期憑證」。這些憑證具備自動過期的特性，大幅縮短了憑證被盜用的風險窗口。

真正的架構師會利用 EC2 Instance Role，讓應用程式透過 EC2 Metadata Service 自動取得短期憑證，IT人員完全不需要手動管理或儲存憑證。此外，在**跨帳戶角色（Cross Account roles）**的場景中，我們使用的是「切換（Assume）」的概念，永遠不需要跨帳戶共享使用者憑證。這種「短期」且「動態」的授權方式，是現代防禦架構的核心趨勢。

真相三：權限邏輯的權威——當「拒絕 (Deny)」遇上「允許 (Allow)」

理解 IAM Policy 的評估優先順序，是避免權限漏洞的基礎。AWS 遵循一條鋼鐵律法：明確的 DENY 始終具有最高優先級。無論你在其他政策中給予了多大的 ALLOW，只要存在一條明確的 DENY，該操作就會被瞬間封殺。

為了實踐「最小權限原則 (Least Privilege)」，我們必須從「預設拒絕」開始，並利用 AWS 提供的專家級工具進行動態清理：

• IAM Access Advisor： 它能顯示各項權限最後被存取的時間。如果某項權限一年都沒被觸發過，那就是多餘的風險，應該立即刪除。
• Access Analyzer： 專門分析與外部帳戶或公眾共享的資源（如 S3 Bucket），確保你的敏感資料沒有被不經意地暴露給全世界。

真相四：身份的徹底轉變——「切換角色」時你失去了什麼？

這是許多資深IT也會踩進去的陷阱：當你執行 AssumeRole（切換角色）時，你並不只是「增加」了權限，而是經歷了一次身份的轉變。

關鍵真相是：當你擔任一個角色時，你會「放棄所有原始權限」，轉而僅獲得該角色分配的權限。

這在跨帳戶作業中會產生嚴重的邏輯衝突。假設你需要從帳戶 A 掃描 DynamoDB 並轉存到帳戶 B 的 S3 Bucket：

• 如果你選擇「切換」到帳戶 B 的角色，你確實獲得了寫入 S3 的權力，但你同時也「失去」了在帳戶 A 掃描 DynamoDB 的權限，導致作業中斷。
• 解決方案： 改用「基於資源的政策 (Resource-based Policies)」。在帳戶 B 的 S3 Bucket 上設定政策，直接允許帳戶 A 的主體存取。這樣主體（Principal）就不必切換身份，能同時保留原本的 DynamoDB 權限並存取遠端的 S3。

真相五：權限邊界 (Permissions Boundary)——給予自由但不失控

權限邊界（Permissions Boundary）是一項進階功能，它設定了實體能獲得的「權限最大上限」。這項功能不支援使用者群組（Group），僅能套用於個別使用者或角色。

權限邊界的邏輯在於**「交集 (Intersection)」**。你的 有效權限 (Effective Permissions) 是「身份政策」與「權限邊界」重疊的部分。

• 舉例： 即使你的身份政策允許了 iam:CreateUser，但如果權限邊界僅定義了 S3、CloudWatch 與 EC2，那麼 iam:CreateUser 的操作最終會因為不在邊界內而被判定為 No Permissions。

這在大型組織中極其強大。管理者可以將「建立角色」的權力委派給開發人員，讓他們在開發環境中獲得自由，但透過預設的權限邊界，開發者永遠無法透過「權限提升 (Privilege Escalation)」來讓自己變成超級管理員。

結論：從「能跑就好」到「絕對安全」

IAM 絕非只是設定帳號密碼的簡單工具，它是實現雲端治理戰略的高度控管手段。透過靈活運用政策變數，例如 ${aws:username}，你可以只寫一條政策，就讓成千上萬個使用者各自擁有專屬的 S3 個人資料夾目錄（如 arn:aws:s3:::mybucket/${aws:username}/*），這就是自動化管理的藝術。

在雲端環境中，「能跑」只是最低要求，「安全」才是永續經營的基石。最後，請反思：在你的環境中，還有多少「長期憑證」正悄悄成為潛在的安全破口？ 從現在開始，轉向動態、短期的授權策略，才是架構師應有的思維。