Cloud Native Security 完整指南：4C 模型與 OWASP Top 10 安全風險【2025】

Cloud Native 架構帶來彈性和效率，但也帶來新的安全挑戰。傳統的邊界防護（防火牆、WAF）不再足夠，因為攻擊面已經從網路邊界擴展到每一個容器、每一個 API、每一行程式碼。

這篇文章會介紹 Cloud Native 安全的核心框架：4C 安全模型和 OWASP Cloud Native Top 10。讀完後，你會知道在雲原生環境中應該關注哪些安全議題，以及如何用正確的工具來防護。

---

Cloud Native 安全挑戰

為什麼雲原生安全更複雜？

Cloud Native 架構的幾個特性讓安全變得更具挑戰：

1. 攻擊面擴大

微服務架構把一個單體應用拆成幾十個甚至幾百個服務。每個服務都是潛在的攻擊入口。

2. 動態環境

容器和 Pod 會不斷創建和銷毀。傳統基於 IP 的安全規則不再適用。

3. 分散式通訊

服務間透過網路通訊，比本地函式呼叫暴露更多風險。

4. 供應鏈風險

一個容器映像可能包含數十個依賴項，每個都可能有漏洞。

5. 共享責任

使用雲端服務時，安全責任由雲端商和使用者共同承擔，邊界有時不清楚。

傳統安全 vs Cloud Native 安全

面向	傳統安全	Cloud Native 安全
防護邊界	網路邊界（防火牆）	每個服務都是邊界
信任模型	內網信任	零信任
身份驗證	基於 IP	基於身份（mTLS）
政策管理	手動設定	程式碼化（Policy as Code）
漏洞修補	定期更新	持續掃描、自動修補
稽核追蹤	集中式日誌	分散式追蹤

Cloud Native 安全責任模型

使用雲端服務時，安全責任的分配：

層級	IaaS (EC2)	CaaS (EKS)	PaaS (App Engine)
應用程式	使用者	使用者	使用者
資料	使用者	使用者	使用者
容器/執行環境	使用者	使用者	雲端商
K8s Control Plane	N/A	雲端商	N/A
作業系統	使用者	雲端商*	雲端商
虛擬化	雲端商	雲端商	雲端商
實體設施	雲端商	雲端商	雲端商

*EKS/GKE 的 Worker Node 作業系統由雲端商管理，但使用者可以選擇自訂。

想了解 Cloud Native 完整概念？請參考 Cloud Native 完整指南。

---

4C 安全模型詳解

Kubernetes 官方文件提出的 4C 安全模型，把 Cloud Native 安全分成四個層級，由外而內：

┌─────────────────────────────────────────┐
│              Cloud                       │
│  ┌─────────────────────────────────┐    │
│  │           Cluster                │    │
│  │  ┌─────────────────────────┐    │    │
│  │  │       Container          │    │    │
│  │  │  ┌─────────────────┐    │    │    │
│  │  │  │      Code       │    │    │    │
│  │  │  └─────────────────┘    │    │    │
│  │  └─────────────────────────┘    │    │
│  └─────────────────────────────────┘    │
└─────────────────────────────────────────┘

每一層的安全都依賴外層。如果 Cloud 層有漏洞，內層再怎麼防護也沒用。

Cloud（雲端層）

雲端層是最外層，包含雲端基礎設施的安全。

主要關注點：

• IAM 配置：最小權限原則，避免過度授權
• 網路安全：VPC 設計、安全群組、私有子網
• 加密：傳輸加密（TLS）、儲存加密（at-rest）
• 稽核日誌：CloudTrail、VPC Flow Logs

常見錯誤：

• S3 Bucket 公開存取
• IAM 使用 Admin 權限
• 資料庫開放到公網
• 沒有啟用 MFA

最佳實踐：

# AWS IAM Policy 範例 - 最小權限
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

Cluster（叢集層）

Cluster 層涵蓋 Kubernetes 叢集的安全配置。

主要關注點：

• API Server 安全：認證、授權、Admission Control
• RBAC 設定：角色和權限管理
• Network Policy：Pod 間的網路隔離
• Secrets 管理：機密資訊的儲存和存取

RBAC 範例：

# 建立只能讀取 Pod 的 Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
# 綁定 Role 到 ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: ServiceAccount
  name: my-app
  namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Network Policy 範例：

# 只允許特定 Pod 存取資料庫
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-access
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: database
    ports:
    - protocol: TCP
      port: 5432

了解更多 K8s 配置？請參考 Cloud Native 技術棧入門。

Container（容器層）

Container 層關注容器映像和執行時期的安全。

主要關注點：

• 映像安全：基礎映像選擇、漏洞掃描
• 執行時期防護：限制容器權限
• 映像簽章：確保映像未被竄改

安全的 Pod 配置：

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true       # 不以 root 執行
    runAsUser: 1000          # 指定 UID
    fsGroup: 1000
  containers:
  - name: app
    image: my-app:v1.0.0
    securityContext:
      allowPrivilegeEscalation: false  # 禁止提權
      readOnlyRootFilesystem: true     # 唯讀檔案系統
      capabilities:
        drop:
          - ALL                         # 移除所有能力
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"

常見錯誤：

• 以 root 執行容器
• 使用過時的基礎映像
• 沒有掃描映像漏洞
• 沒有設定資源限制

擔心雲端安全？資安事件的代價遠超過預防成本。預約資安評估，讓專家幫你檢視安全配置。

Code（程式碼層）

Code 層是最內層，關注應用程式本身的安全。

主要關注點：

• 安全編碼：避免 SQL Injection、XSS 等漏洞
• 依賴項安全：掃描第三方套件漏洞
• 機密管理：不在程式碼中硬編碼密碼
• 輸入驗證：驗證所有外部輸入

依賴項掃描範例：

# 使用 npm audit 掃描 Node.js 依賴
npm audit

# 使用 Snyk 掃描
snyk test

# 使用 OWASP Dependency-Check
dependency-check --project myapp --scan .

這也符合 12 Factor 的 Config 原則：機密資訊不應該寫在程式碼裡。

---

OWASP Cloud Native Top 10

OWASP 發布的 Cloud Native Application Security Top 10 列出了雲原生環境最常見的安全風險。

CNS01: 不安全的雲端/容器配置

風險： 雲端服務或容器的預設配置往往不安全，開發者沒有調整就直接使用。

範例：

• Kubernetes API Server 開放到公網
• 容器以 root 權限執行
• S3 Bucket 公開存取

對策：

• 使用 CIS Benchmark 檢查配置
• 使用 Policy as Code 強制安全配置
• 定期稽核雲端配置

CNS02: 供應鏈漏洞

風險： 容器映像或第三方依賴項包含已知漏洞。

範例：

• 使用過時的基礎映像（如 Alpine 3.10）
• npm/pip 套件有已知 CVE
• 使用未經驗證的第三方映像

對策：

• 持續掃描映像和依賴項
• 使用私有 Registry，限制可用映像
• 使用 SBOM（Software Bill of Materials）追蹤元件

CNS03: 過度授權的身份和存取

風險： 服務帳號或使用者被授予過多權限。

範例：

• Pod 使用 cluster-admin 權限
• IAM Role 有 * 權限
• 沒有區分不同環境的權限

對策：

• 最小權限原則
• 定期審查權限
• 使用 Just-in-Time（JIT）存取

CNS04: 不安全的機密管理

風險： 敏感資訊（密碼、API Key）暴露或管理不當。

範例：

• 密碼寫在程式碼或環境變數明文
• Kubernetes Secret 沒有加密
• 機密資訊提交到 Git

對策：

• 使用專門的機密管理工具（Vault、Sealed Secrets）
• 啟用 K8s Secret 的加密
• 使用 git-secrets 防止提交機密

CNS05: 網路分隔不足

風險： 服務之間沒有適當的網路隔離，一個服務被入侵可以橫向移動。

對策：

• 使用 Network Policy 限制 Pod 間通訊
• 微服務之間使用 mTLS
• 實施零信任架構

CNS06: 執行時期防護不足

風險： 缺乏對執行中容器的監控和防護。

對策：

• 使用 Falco 偵測異常行為
• 限制容器系統呼叫（seccomp）
• 使用唯讀檔案系統

CNS07: 日誌和監控不足

風險： 沒有足夠的日誌記錄，發生事件時無法追蹤。

對策：

• 集中式日誌收集
• 稽核日誌長期保存
• 建立告警規則

CNS08: 不安全的工作負載

風險： 容器或函式的配置不安全。

對策：

• 使用 Pod Security Standards
• 限制容器能力（capabilities）
• 不以 root 執行

CNS09: 不安全的 API

風險： API 端點缺乏適當的認證、授權、限流。

對策：

• 所有 API 都要認證
• 實施速率限制
• 驗證輸入參數

CNS10: 不當的資源分配

風險： 沒有設定資源限制，可能導致 DoS 或資源耗盡。

對策：

• 設定 CPU/記憶體限制
• 使用 LimitRange 和 ResourceQuota
• 監控資源使用量

你的 Cloud Native 環境有這些風險嗎？免費資安快篩，15 分鐘找出關鍵漏洞。

---

Cloud Native 安全最佳實踐

安全左移（Shift Left）

「安全左移」是指把安全檢查移到軟體開發生命週期的早期階段。

實踐方式：

1. 開發階段

   • IDE 安全插件
   • Pre-commit 掃描

2. CI/CD 階段

   • 映像掃描
   • SAST/DAST 測試
   • Policy 檢查

3. 部署階段

   • Admission Control
   • 配置驗證

# GitHub Actions 安全掃描範例
name: Security Scan
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          security-checks: 'vuln,secret,config'
          severity: 'HIGH,CRITICAL'

零信任架構

零信任的核心原則：「永不信任，持續驗證」

實施重點：

• 身份驗證：所有服務都要驗證身份
• 最小權限：只給必要的權限
• 加密通訊：服務間使用 mTLS
• 持續監控：記錄和分析所有存取

Service Mesh mTLS 設定（Istio）：

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT  # 強制 mTLS

持續安全監控

監控重點：

• 容器異常行為（新程序、網路連線）
• K8s API 異常呼叫
• 資源異常使用
• 網路異常流量

Falco 規則範例：

- rule: Terminal shell in container
  desc: 偵測容器內的互動式 shell
  condition: >
    spawned_process and container
    and shell_procs and proc.tty != 0
  output: >
    Shell spawned in container
    (user=%user.name container=%container.name
    shell=%proc.name)
  priority: WARNING

安全即程式碼（Security as Code）

把安全政策用程式碼管理，納入版本控制。

OPA/Gatekeeper 政策範例：

# 禁止容器以 root 執行
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowedUsers
metadata:
  name: require-non-root
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    runAsUser:
      rule: MustRunAsNonRoot

---

Cloud Native 安全工具推薦

映像掃描：Trivy、Snyk

Trivy（CNCF 專案）

# 掃描容器映像
trivy image my-app:v1.0.0

# 掃描 Kubernetes 配置
trivy config .

# 掃描 IaC（Terraform）
trivy config --tf-vars terraform.tfvars .

Snyk

# 掃描依賴項
snyk test

# 掃描容器
snyk container test my-app:v1.0.0

# 掃描 IaC
snyk iac test

執行時期防護：Falco

Falco 是 CNCF 專案，用於偵測容器和 K8s 的異常行為。

偵測能力：

• 容器內執行 shell
• 敏感檔案存取
• 異常網路連線
• K8s API 異常呼叫

政策引擎：OPA、Kyverno

OPA（Open Policy Agent）

• 通用政策引擎
• 使用 Rego 語言
• 可用於 K8s Admission Control

Kyverno

• K8s 原生政策引擎
• 使用 YAML 定義政策
• 學習曲線較低

密鑰管理：HashiCorp Vault

Vault 是業界標準的機密管理工具。

功能：

• 機密儲存和存取控制
• 動態機密生成
• 機密輪換
• 加密即服務

# 儲存機密
vault kv put secret/myapp/db password=s3cr3t

# 讀取機密
vault kv get secret/myapp/db

K8s 整合： 使用 Vault Agent Injector 自動注入機密到 Pod。

---

FAQ

Q1: Cloud Native 安全和傳統網路安全有什麼差別？

傳統安全聚焦在網路邊界（防火牆），假設內網可信任。Cloud Native 安全採用零信任模型，每個服務都要驗證，不假設任何內部信任。

Q2: 4C 模型應該從哪一層開始？

建議從外到內。Cloud 層的安全是基礎，如果雲端配置有問題，內層再怎麼防護也沒用。但實務上，四層要同時關注。

Q3: 小團隊應該優先處理哪些安全議題？

建議優先處理：(1) 映像漏洞掃描 (2) 機密管理（不要把密碼寫在程式碼） (3) 基本的 RBAC 設定。這三項成本低但效益高。

Q4: Service Mesh 是必要的嗎？

不一定。如果服務數量不多、對 mTLS 沒有強需求，可以先用其他方式（API Gateway、手動設定 TLS）。Service Mesh 增加複雜度，要評估效益。

Q5: 如何說服管理層投資資安？

用數字說話。統計資安事件的平均成本（Ponemon Institute 報告），對比預防措施的投資。另外強調合規需求（ISO 27001、SOC 2）。

---

下一步

Cloud Native 安全是持續的過程，不是一次性的任務。建議：

1. 先用 CIS Benchmark 檢查現有配置
2. 導入映像掃描，納入 CI/CD
3. 建立基本的 RBAC 和 Network Policy
4. 逐步導入更進階的防護措施

延伸閱讀：

• 回到核心概念：Cloud Native 完整指南
• 了解架構原則：12 Factor App 完整解析
• 深入 Kubernetes：Cloud Native 技術棧入門

資安做得夠嗎？與其事後補救，不如事前預防。預約資安評估，讓專業團隊幫你找出盲點，建立完整的安全防護。

---

參考資料

• Kubernetes Security Best Practices
• OWASP Cloud Native Application Security Top 10
• CIS Kubernetes Benchmark
• CNCF Cloud Native Security Whitepaper
• Trivy Documentation
• Falco Documentation