前情提要

經過了成功的雲端搬遷，小李的餐廳帝國已經完全運行在 AWS 上。系統穩定、監控完善、成本也得到了很好的控制。但是，隨著業務的擴張和團隊的成長，一個新的挑戰浮現了：如何管理越來越多的員工對 AWS 資源的存取權限？

這天早上，小李接到了一通讓他冷汗直流的電話。

「老闆，我們的 AWS 帳單這個月暴增了 300%！」財務主管小王焦急地說，「而且我發現有人在我們不知道的區域啟動了很多大型 EC2 實例！」

小李立刻衝到辦公室，召集了小張和技術團隊。經過調查，他們發現是一位新進的實習生誤用了生產環境的 AWS 帳號，不小心在錯誤的區域啟動了大量資源。

「這個問題很嚴重，」小張嚴肅地說，「我們需要立即建立一套完整的權限管理制度。在 AWS 中，這叫做 Identity and Access Management，簡稱 IAM。」

小李擦著額頭上的汗：「我以為把密碼設得複雜一點就夠了，沒想到權限管理這麼重要。」

「權限管理就像餐廳的門禁系統，」小張比喻道，「不是每個人都能進入廚房，不是每個人都能開收銀機，不是每個人都能進入倉庫。AWS 也是一樣，我們需要給每個人適當的權限，既能完成工作，又不會造成安全風險。」

第一章：IAM 基礎概念 - 「建立數位身分證系統」

什麼是 IAM？

小張在白板上畫了一個餐廳的平面圖：

「想像我們的餐廳有不同的區域：前台、廚房、倉庫、辦公室、金庫。每個員工根據職責不同，需要進入不同的區域。」

她指著圖說：「IAM 就是 AWS 的門禁系統，它決定：」

• 誰可以存取 AWS 資源（身分認證）
• 什麼時候可以存取（時間限制）
• 存取什麼資源（資源範圍）
• 能做什麼操作（權限範圍）

IAM 的四大核心元件

小張繼續解釋 IAM 的組成：

1. Users（使用者）- 「員工身分證」
「每個需要使用 AWS 的人都需要一個 User 帳號，就像每個員工都有一張身分證。」

2. Groups（群組）- 「部門分類」
「把有相同職責的使用者歸類在一起，比如『廚師群組』、『服務生群組』、『管理層群組』。」

3. Roles（角色）- 「臨時工作證」
「給應用程式或服務臨時的權限，就像給外包廠商發放臨時工作證。」

4. Policies（政策）- 「規章制度」
「定義具體的權限規則，就像員工手冊裡的各種規定。」

實際案例：餐廳員工權限設計

小李開始理解了：「那我們餐廳的員工應該怎麼分配權限？」

小張設計了一個實際的權限架構：

餐廳組織架構 → AWS IAM 對應

總經理（小李）
├── 開發團隊主管
│   ├── 資深工程師
│   ├── 初級工程師
│   └── 實習生
├── 運維團隊主管
│   ├── 系統管理員
│   └── 監控專員
└── 財務主管
    ├── 會計
    └── 出納

對應的 IAM 設計：

總經理群組（AdminGroup）

• 完整的 AWS 管理權限
• 可以建立和刪除任何資源
• 可以管理帳單和成本

開發團隊群組（DeveloperGroup）

• 可以管理開發和測試環境
• 不能存取生產環境
• 不能查看帳單資訊

運維團隊群組（OpsGroup）

• 可以管理生產環境
• 可以查看監控和日誌
• 可以執行備份和恢復

財務群組（FinanceGroup）

• 只能查看帳單和成本報告
• 不能存取技術資源
• 可以設定預算告警

第二章：建立安全的使用者管理 - 「發放數位身分證」

建立第一個 IAM 使用者

小張開始實際操作，教小李如何建立 IAM 使用者：

「我們先為你的技術主管小陳建立一個帳號。」

步驟一：進入 IAM Console

1. 登入 AWS Console
2. 搜尋並點擊「IAM」服務
3. 在左側選單點擊「Users」

步驟二：建立新使用者

1. 點擊「Create user」
2. 輸入使用者名稱：chen-tech-lead
3. 選擇存取類型：
   • Programmatic access：用於 API、CLI、SDK
   • AWS Management Console access：用於網頁介面

小張解釋：「小陳需要兩種存取方式，所以我們都勾選。」

步驟三：設定密碼政策

密碼要求：
- 最少 12 個字元
- 包含大小寫字母
- 包含數字和特殊符號
- 不能包含使用者名稱
- 90 天後必須更換

「這就像餐廳的門禁卡，」小張說，「密碼越複雜，安全性越高。」

步驟四：設定權限
「現在我們需要決定小陳能做什麼。我們有三種方式：」

1. 直接附加政策：直接給使用者特定權限
2. 加入群組：把使用者加入預設的群組
3. 複製現有使用者：複製其他使用者的權限

小張建議：「最好的做法是建立群組，然後把使用者加入群組。這樣管理起來比較容易。」

建立群組和政策

建立開發團隊群組：

1. 進入 Groups 頁面
2. 點擊 Create group
3. 群組名稱：DeveloperGroup
4. 附加政策：
   • AmazonEC2FullAccess（管理 EC2）
   • AmazonS3ReadOnlyAccess（讀取 S3）
   • AmazonRDSReadOnlyAccess（讀取 RDS）

小李問：「為什麼不給他們完整權限？」

「這叫做『最小權限原則』，」小張解釋，「只給員工完成工作所需的最小權限。就像廚師不需要金庫的鑰匙一樣。」

多因素認證（MFA）

「除了密碼，我們還需要加上第二層保護，」小張說，「這叫做多因素認證，簡稱 MFA。」

設定 MFA 的步驟：

1. 選擇 MFA 設備類型：

   • 虛擬 MFA 設備（手機 App）
   • 硬體 MFA 設備
   • SMS 簡訊（不建議）

2. 安裝認證 App：

   • Google Authenticator
   • Microsoft Authenticator
   • Authy

3. 掃描 QR Code

4. 輸入兩組連續的驗證碼

5. 完成設定

小張示範了登入過程：「現在小陳登入時，除了輸入密碼，還需要輸入手機 App 產生的 6 位數驗證碼。」

小李點頭：「這樣就算密碼被偷，沒有手機也進不來。」

第三章：群組管理策略 - 「部門權限分工」

設計合理的群組架構

小張開始設計更完整的群組架構：

「我們需要根據職責和風險等級來設計群組。」

高權限群組（需要嚴格控制）：

1. AdminGroup（系統管理員）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

• 成員：只有小李和小張
• 權限：完整的 AWS 管理權限
• 要求：必須啟用 MFA

2. PowerUserGroup（高級使用者）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*",
        "account:*"
      ],
      "Resource": "*"
    }
  ]
}

• 成員：技術主管
• 權限：除了 IAM 管理外的所有權限
• 限制：不能修改權限設定

中等權限群組：

3. DeveloperGroup（開發人員）

• 可以管理開發和測試環境
• 不能存取生產環境
• 不能查看帳單

4. OpsGroup（運維人員）

• 可以管理生產環境
• 可以查看監控和日誌
• 可以執行備份操作

低權限群組：

5. ReadOnlyGroup（唯讀使用者）

• 只能查看資源狀態
• 不能修改任何設定
• 適合實習生和外部顧問

環境隔離策略

小張特別強調環境隔離的重要性：

「我們需要確保開發環境和生產環境完全分離。」

方法一：使用不同的 AWS 帳號

生產帳號（Production Account）
├── 生產環境資源
├── 嚴格的權限控制
└── 完整的監控和備份

開發帳號（Development Account）
├── 開發和測試環境
├── 較寬鬆的權限
└── 可以自由實驗

方法二：使用標籤和條件政策

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Environment": "Development"
        }
      }
    }
  ]
}

這個政策只允許操作標籤為「Environment: Development」的資源。

實際案例：實習生權限設計

小李想起那個造成問題的實習生：「我們應該給實習生什麼權限？」

小張設計了一個「實習生沙盒」：

InternGroup 權限設計：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:DescribeImages",
        "ec2:RunInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-1"
        },
        "ForAllValues:StringEquals": {
          "ec2:InstanceType": [
            "t2.micro",
            "t2.small"
          ]
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Environment": "Production"
        }
      }
    }
  ]
}

這個政策的限制：

• 只能在 us-east-1 區域操作
• 只能啟動小型實例（t2.micro, t2.small）
• 不能存取生產環境資源
• 不能查看帳單資訊

小李滿意地點頭：「這樣實習生就不會再誤操作了。」

第四章：角色（Roles）的妙用 - 「臨時工作證系統」

什麼是 IAM 角色？

「角色和使用者不同，」小張解釋，「使用者是給人用的，角色是給應用程式或服務用的。」

她用餐廳的例子說明：「假設我們有一個自動點餐系統，它需要存取客戶資料庫。我們不會給這個系統一個『使用者帳號』，而是給它一個『角色』。」

角色的特點：

• 沒有永久的密碼或存取金鑰
• 使用臨時的安全憑證
• 可以被多個實體使用
• 權限可以動態調整

EC2 實例角色

**場景：**小李的訂單處理系統需要存取 S3 儲存客戶照片。

傳統做法（不安全）：

# 在 EC2 實例中硬編碼 AWS 憑證
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

小張搖頭：「這樣做很危險，憑證可能被洩露。」

正確做法（使用角色）：

1. 建立角色：

   • 角色名稱：OrderProcessingRole
   • 信任實體：EC2 服務
   • 權限政策：S3 讀寫權限

2. 附加角色到 EC2：

   • 在啟動 EC2 時指定角色
   • 或者為現有實例附加角色

3. 應用程式自動取得憑證：

import boto3

# 不需要指定憑證，自動從角色取得
s3 = boto3.client('s3')
s3.upload_file('order.jpg', 'customer-photos', 'order-123.jpg')

跨帳號角色

隨著業務成長，小李決定將開發和生產環境分離到不同的 AWS 帳號。

**挑戰：**開發人員需要偶爾存取生產環境進行問題排查。

**解決方案：**跨帳號角色

在生產帳號中建立角色：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::DEV-ACCOUNT-ID:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

開發人員使用方式：

# 切換到生產環境角色
aws sts assume-role \
  --role-arn arn:aws:iam::PROD-ACCOUNT-ID:role/ProductionReadOnlyRole \
  --role-session-name dev-troubleshooting \
  --external-id unique-external-id

小張強調：「注意這裡要求 MFA，確保只有經過雙重認證的使用者才能存取生產環境。」

服務連結角色

「有些 AWS 服務需要特殊的權限來代表你執行操作，」小張說，「比如 EKS 需要管理 EC2 實例，Lambda 需要寫入 CloudWatch 日誌。」

EKS 服務角色範例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateNetworkInterface",
        "ec2:DescribeNetworkInterfaces",
        "ec2:DeleteNetworkInterface"
      ],
      "Resource": "*"
    }
  ]
}

這些角色通常由 AWS 自動建立和管理，我們只需要確保它們存在即可。

第五章：政策（Policies）深度解析 - 「規章制度設計」

政策的結構

小張拿出一份政策文件：「政策就像法律條文，需要非常精確。」

基本結構：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3Access",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "s3:ExistingObjectTag/Department": "Marketing"
        }
      }
    }
  ]
}

各部分說明：

• Version：政策語言版本
• Statement：權限聲明陣列
• Sid：聲明 ID（可選）
• Effect：Allow 或 Deny
• Action：允許或拒絕的操作
• Resource：操作的目標資源
• Condition：額外的條件限制

實用政策範例

1. 時間限制政策

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "DateGreaterThan": {
          "aws:CurrentTime": "08:00:00Z"
        },
        "DateLessThan": {
          "aws:CurrentTime": "18:00:00Z"
        }
      }
    }
  ]
}

「這個政策只允許在工作時間（8:00-18:00 UTC）存取 AWS。」

2. IP 位址限制政策

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "203.0.113.0/24",
            "198.51.100.0/24"
          ]
        }
      }
    }
  ]
}

「只允許從公司 IP 位址存取 AWS。」

3. MFA 強制政策

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

「沒有 MFA 認證就拒絕所有操作。」

政策測試和驗證

小張展示了 IAM 政策模擬器：

「在實際套用政策之前，我們可以先測試它的效果。」

使用政策模擬器：

1. 進入 IAM Console
2. 點擊「Policy Simulator」
3. 選擇使用者或角色
4. 選擇要測試的服務和操作
5. 查看模擬結果

測試案例：

• 使用者：chen-tech-lead
• 服務：EC2
• 操作：RunInstances
• 資源：arn:aws:ec2:us-east-1:*:instance/*

結果會顯示：「Allowed」或「Denied」，以及具體的原因。

第六章：安全最佳實踐 - 「建立堅固的防線」

最小權限原則

「這是 IAM 最重要的原則，」小張強調，「給每個人剛好夠用的權限，不多也不少。」

實施步驟：

1. 從最小權限開始

   • 新員工先給最基本的權限
   • 根據工作需要逐步增加

2. 定期權限審查

   • 每季度檢查使用者權限
   • 移除不再需要的權限

3. 使用存取分析器

   • AWS Access Analyzer 可以分析實際使用情況
   • 識別過度授權的權限

權限審查清單：

□ 檢查長期未使用的使用者
□ 檢查過度授權的權限
□ 檢查未使用的存取金鑰
□ 檢查 MFA 啟用狀況
□ 檢查密碼政策合規性

第七章：進階 IAM 功能 - 「高級安全技巧」

權限邊界（Permission Boundaries）

「權限邊界就像給員工設定一個『不能超越的界線』，」小張解釋。

使用場景：
小李想讓部門主管能夠為自己的團隊建立 IAM 使用者，但不希望他們給出超過自己權限的權限。

解決方案：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "rds:Describe*"
      ],
      "Resource": "*"
    }
  ]
}

這個權限邊界確保即使部門主管給團隊成員附加了 AdministratorAccess 政策，該成員也只能在 EC2、S3 和 RDS 讀取權限範圍內操作。

條件式存取

基於標籤的存取控制：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Owner": "${aws:username}"
        }
      }
    }
  ]
}

這個政策只允許使用者操作標籤 Owner 值等於自己使用者名稱的 EC2 資源。

基於請求屬性的存取控制：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": ["us-east-1", "us-west-2"]
        },
        "ForAllValues:StringEquals": {
          "ec2:InstanceType": ["t2.micro", "t2.small", "t2.medium"]
        }
      }
    }
  ]
}

外部身分提供者整合

隨著公司成長，小李發現管理越來越多的 IAM 使用者變得困難。

「我們可以整合公司現有的 Active Directory，」小張建議，「這樣員工就可以用同一組帳號密碼存取 AWS。」

SAML 2.0 整合：

1. 在 IAM 中建立身分提供者
2. 建立 SAML 角色
3. 配置信任關係

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:saml-provider/CompanyAD"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }
  ]
}

好處：

• 員工使用現有帳號密碼
• 集中管理使用者生命週期
• 支援單一登入（SSO）
• 減少密碼管理負擔

結語：安全是一個持續的過程

小李的安全覺醒

經過這次深入的 IAM 學習，小李對安全管理有了全新的認識。

「我以前以為安全就是設個複雜密碼，」小李感慨地說，「現在才知道安全管理是一個系統工程，需要從組織架構、流程制度、技術實現等多個層面來考慮。」

小張點頭：「安全不是一次性的工作，而是一個持續改進的過程。隨著業務的發展和威脅的變化，我們的安全策略也需要不斷調整。」

建立安全文化

「技術只是基礎，更重要的是建立安全文化，」小張說，「讓每個員工都有安全意識。」

安全文化的要素：

1. 安全培訓

   • 定期進行 IAM 培訓
   • 分享安全最佳實踐
   • 模擬安全事件演練

2. 責任分工

   • 明確每個人的安全責任
   • 建立安全檢查清單
   • 定期進行安全審查

3. 持續改進

   • 收集安全事件回饋
   • 分析安全漏洞原因
   • 更新安全政策和程序

未來的安全挑戰

「隨著我們業務的全球化，安全挑戰會越來越複雜，」小李說。

小張同意：「我們需要考慮：」

• 多雲環境管理：如何在多個雲端平台間統一身分管理
• 零信任架構：假設網路已被入侵，如何設計安全架構
• AI 和機器學習：如何利用 AI 提升安全防護能力
• 合規性要求：如何滿足不同國家和地區的法規要求

給讀者的建議

如果你也在管理 AWS 環境的安全，記住這些要點：

1. 從基礎做起

• 啟用 MFA
• 實施最小權限原則
• 定期輪換存取金鑰
• 監控異常活動

2. 建立流程

• 制定 IAM 管理流程
• 建立權限審查機制
• 準備事件回應計劃
• 定期進行安全培訓

3. 使用工具

• 善用 AWS 安全服務
• 自動化安全檢查
• 整合第三方安全工具
• 建立安全儀表板

4. 持續學習

• 關注安全威脅趨勢
• 學習新的安全技術
• 參與安全社群
• 分享經驗和教訓

「安全是每個人的責任，」小張最後說，「不是只有安全團隊的事。每個使用 AWS 的人都應該了解基本的安全原則，這樣我們才能建立一個真正安全的雲端環境。」

小李深有感觸地點頭：「這次的學習讓我明白，投資在安全上的每一分錢都是值得的。因為一旦出現安全問題，損失可能是無法估量的。」

這個故事展示了 AWS IAM 的重要性和複雜性。記住，安全不是一次性的設定，而是需要持續關注和改進的過程。建立良好的 IAM 架構和安全文化，是保護雲端資源的基石。