身份與存取管理(IAM)

是什麼?

IAM(Identity and Access Management)是管理「誰能存取什麼資源」的系統。涵蓋身份驗證(你是誰)、授權(你能做什麼)、和稽核(你做了什麼)。是雲端安全的第一道防線

ℹ️為什麼 IAM 這麼重要

80% 以上的雲端安全事件源自 IAM 設定錯誤 — 權限過大、密鑰外洩、未啟用 MFA。正確設定 IAM 比任何防火牆都重要。

核心觀念

常見誤區

⚠️常見誤區

  • 所有人都用 Owner 角色:Owner 可以刪除資源和管理權限,日常操作用 Contributor 或更細的角色就夠了。Owner 只給少數管理員
  • Service Principal 的 Secret 寫在程式碼裡:Secret 必須存在 Key Vault 或環境變數中。更好的做法是用 Managed Identity,完全不需要管理 Secret
  • 不做存取 Review:權限會隨時間膨脹。每季做一次 Access Review,清除不再需要的權限

流程/步驟

1

盤點身份

列出所有需要存取雲端資源的人和服務

2

定義角色

基於職責定義角色:Admin、Developer、CI/CD、ReadOnly

3

指派 RBAC

在 Resource Group 或 Resource 層級指派角色

4

設定 Managed Identity

應用程式用 Managed Identity 取代 Service Principal + Secret

5

啟用 MFA + 條件式存取

人類帳號啟用 MFA,設定可疑登入的額外驗證

6

定期 Review

每季檢視和清理不再需要的權限

流程解讀:從盤點身份開始,明確誰需要什麼權限。用 RBAC 按角色批次授權而非逐一設定。應用程式優先用 Managed Identity。人類帳號啟用 MFA。定期 Review 防止權限膨脹。

程式碼範例

C# 版本

csharp
// ASP.NET Core — 用 Managed Identity 存取 Azure 資源(零密鑰管理)
using Azure.Identity;
using Azure.Security.KeyVault.Secrets;
 
// DefaultAzureCredential 自動偵測環境
// 本機開發:用 Azure CLI 登入的身份
// 雲端環境:用 Managed Identity
var credential = new DefaultAzureCredential();
 
// 從 Key Vault 取得密鑰 — 不需要在程式碼中寫任何 Secret
var client = new SecretClient(new Uri("https://myvault.vault.azure.net/"), credential);
var secret = await client.GetSecretAsync("database-connection-string");
var connectionString = secret.Value.Value;
 
// 用 Managed Identity 存取 SQL Database
builder.Services.AddDbContext<AppDbContext>(options =>
{
    options.UseSqlServer(connectionString);
});
 
// RBAC — 在程式碼中檢查使用者角色
[Authorize(Roles = "Admin")]
[HttpDelete("api/users/{id}")]
public async Task<IActionResult> DeleteUser(int id)
{
    // 只有 Admin 角色能刪除使用者
    await _userService.DeleteAsync(id);
    return NoContent();
}
 
[Authorize(Policy = "CanManageOrders")]
[HttpPut("api/orders/{id}")]
public async Task<IActionResult> UpdateOrder(int id, UpdateOrderDto dto)
{
    await _orderService.UpdateAsync(id, dto);
    return NoContent();
}

TypeScript 版本

typescript
// AWS IAM — Terraform 定義角色和策略
hcl
# IAM Role for Lambda Function
resource "aws_iam_role" "lambda_role" {
  name = "order-processor-role"
 
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = { Service = "lambda.amazonaws.com" }
    }]
  })
}
 
# 最小權限策略 — 只允許讀取特定 S3 Bucket 和寫入特定 DynamoDB Table
resource "aws_iam_role_policy" "lambda_policy" {
  role = aws_iam_role.lambda_role.id
 
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = ["s3:GetObject"]
        Resource = "arn:aws:s3:::order-bucket/*"
      },
      {
        Effect   = "Allow"
        Action   = ["dynamodb:PutItem", "dynamodb:UpdateItem"]
        Resource = "arn:aws:dynamodb:*:*:table/Orders"
      }
    ]
  })
}

Python 版本

python
# Azure SDK — 用 Managed Identity 存取資源
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
from azure.mgmt.authorization import AuthorizationManagementClient
 
credential = DefaultAzureCredential()
 
# 從 Key Vault 取密鑰
secret_client = SecretClient(
    vault_url="https://myvault.vault.azure.net/",
    credential=credential
)
db_password = secret_client.get_secret("db-password").value
 
# 列出角色指派(用於 Access Review)
auth_client = AuthorizationManagementClient(credential, subscription_id)
assignments = auth_client.role_assignments.list_for_scope(
    scope=f"/subscriptions/{subscription_id}/resourceGroups/myapp-rg"
)
 
for assignment in assignments:
    print(f"Principal: {assignment.principal_id}, Role: {assignment.role_definition_id}")

架構圖/概念圖

User / Service
authenticate
IAM (Identity Provider)
check role
RBAC (Role Assignment)
allow/deny
Cloud Resource
log access
Audit Log

User 或 Service 先向 IAM 認證身份。IAM 查詢 RBAC 確認該身份有什麼角色。根據角色決定允許或拒絕存取資源。所有存取行為記錄到 Audit Log 供事後稽核。

實戰補充

Q: Managed Identity 和 Service Principal 怎麼選?

A: 優先用 Managed Identity — 不需要管理 Secret,Azure 自動輪替憑證。只有 Managed Identity 不支援的場景(如跨雲、地端應用)才用 Service Principal + Secret/Certificate。

Q: RBAC 的 Scope 要設在哪一層?

A: 遵循最小範圍原則 — 能設在 Resource 層就不設在 Resource Group,能設在 Resource Group 就不設在 Subscription。範圍越小,權限越精確。

Q: 如何防止 IAM 權限膨脹?

A: (1) 用 Just-In-Time(JIT)存取 — 需要時才臨時提升權限,用完自動撤銷。(2) 每季做 Access Review。(3) 設定 Alert 監控異常的權限指派。(4) 用 Azure AD PIM(Privileged Identity Management)管理特權帳號。

理解測驗

🤔 最小權限原則(Least Privilege)的核心精神是什麼?

🤔 Managed Identity 比 Service Principal 好在哪裡?

🤔 RBAC 中的 Scope 設定原則是什麼?

重點整理

💡一句話記住

IAM = 控制誰能對什麼資源做什麼操作。 口訣:「最小權限、Managed Identity、定期 Review」

| 概念 | 說明 | |------|------| | IAM | 管理身份、角色、權限的系統 | | RBAC | 按角色授權,避免逐一設定 | | Service Principal | 應用程式的身份,需要管理 Secret | | Managed Identity | Azure 自動管理的身份,零密鑰 | | Least Privilege | 只給最少需要的權限 |

你可能也想看

雲端網路架構Serverless 架構

按 ← → 鍵切換課程