Kubernetes安全攻防：超越 RBAC 的策略管理

– 17 分鐘閱讀

RBAC 是 Kubernetes 中許可權管理的基礎，但現代雲原生環境的策略需求遠不止於此。通用策略引擎提供了一種定義和執行各種策略的通用方法，而不是將特定型別的策略硬編碼到 Kubernetes 中。

這些策略引擎利用 Kubernetes 的擴充套件機制，可以實施從安全合規到資源配額，再到網路控制的各種策略。在下一篇文章中，我們將探討這些通用策略引擎，包括 Open Policy Agent (OPA)、Kyverno 和 Gatekeeper 等。

RBAC 是 Kubernetes 安全的根本，透過自動化生成角色定義、視覺化複雜的許可權關係，以及遵循安全最佳實踐，我們可以建立更安全、更可管理的 Kubernetes 環境。這些工具和技術不僅提高了安全性，還減輕了管理員的負擔，使他們能夠專注於更高價值的任務。

隨著雲原生技術的不斷發展，許可權管理和策略執行的重要性只會增加。掌握這些技術不僅是安全的需要，也是確保系統穩定性和合規性的關鍵。

Open Policy Agent：統一政策執行的新標準

在現代雲原生環境中，隨著系統規模擴大，政策管理變得越來越複雜。當我們面對分散式系統時，如何確保各個元件都遵循相同的安全規範與業務規則？這正是 Open Policy Agent (OPA) 要解決的核心問題。

OPA 作為 CNCF 的畢業專案，提供了一種通用的政策引擎，能夠統一各種系統中的政策執行邏輯。我認為 OPA 最大的價值在於它將政策決策從應用程式邏輯中分離出來，讓開發者能夠專注於業務功能，同時確保安全與合規性。

政策即程式碼：OPA 的核心理念

OPA 的核心理念是「政策即程式碼」(Policy as Code)，它使用一種名為 Rego 的高階宣告式語言來表達政策。這種方式具有幾個關鍵優勢：

  1. 將決策邏輯外部化，從應用程式中抽離
  2. 提供統一的政策表達方式，適用於不同系統
  3. 透過 API 實作政策查詢與執行

在實際運作中，OPA 的架構相當直觀：當應用程式需要做出政策決策時，會透過 API 向 OPA 服務傳送查詢。OPA 會接收當前請求資料（JSON 格式）以及政策定義（Rego 格式），然後計算出決策結果。

值得注意的是，OPA 的決策結果不僅限於「允許/拒絕」的二元答案，而是完全取決於提供的規則和資料，以確定性方式運算得出。這種靈活性讓 OPA 能夠應用在各種複雜的場景中。

Rego：OPA 的政策語言

Rego 是 OPA 的政策語言，它允許我們以宣告式方式定義政策規則。雖然 Rego 看起來可能與常見的程式語言不太相同，但它的設計目的是為了簡化政策表達。

實際案例：資源標籤驗證

讓我們看一個具體例子：假設我們希望確保每個資源都有一個以 cccode- 開頭的 costcenter 標籤，如果不符合要求，則拒絕該操作並向使用者顯示錯誤訊息。

在 Rego 中，這條規則可以這樣表達：

package prod.k8s.acme.org

deny[msg] {
  not input.request.object.metadata.labels.costcenter
  msg := "Every resource must have a costcenter label"
}

deny[msg] {
  value := input.request.object.metadata.labels.costcenter
  not startswith(value, "cccode-")
  msg := sprintf("Costcenter code must start with `cccode-`; found `%v`", [value])
}

這段 Rego 程式碼定義了兩個拒絕規則：

  1. 第一個規則檢查資源是否具有 costcenter 標籤。not 關鍵字在這裡的作用是，如果 costcenter 標籤不存在，則此規則為真，從而產生錯誤訊息。
  2. 第二個規則檢查 costcenter 標籤的值是否以 cccode- 開頭。如果不是，則生成包含實際值的詳細錯誤訊息。

這兩個規則共同確保了資源標籤符合組織的命名規範，這對於成本追蹤和資源管理至關重要。

OPA 如何與 Kubernetes 整合

現在，假設有人執行 kubectl apply 命令嘗試建立一個沒有所需標籤的 Pod。此時，Kubernetes API 伺服器會生成一個 AdmissionReview 資源（JSON 格式）並傳送給 OPA 進行評估：

{
  "kind": "AdmissionReview",
  "request": {
    "kind": {
      "kind": "Pod",
      "version": "v1"
    },
    "object": {
      "metadata": {
        "name": "myapp"
      },
      "spec": {
        "containers": [
          {
            "image": "nginx",
            "name": "nginx-frontend"
          },
          {
            "image": "mysql",
            "name": "mysql-backend"
          }
        ]
      }
    }
  }
}

這個 JSON 檔案代表 Kubernetes API 伺服器傳送給 OPA 的請求資料。它包含了要建立的 Pod 的完整規格，包括名稱（myapp）和兩個容器的定義（nginx-frontend 和 mysql-backend）。重要的是，這個 Pod 定義中沒有包含任何標籤，這將觸發我們的第一條 deny 規則。

OPA 引擎評估這個輸入後，會產生以下輸出：

{
  "deny": [
    "Every resource must have a costcenter label"
  ]
}

這個輸出會被 API 伺服器回傳給 kubectl，並顯示給使用者，告知他們需要增加 costcenter 標籤。

要解決這個問題，使用者需要在資源定義中增加正確的標籤：

"metadata": {
  "name": "myapp",
  "labels": {
    "costcenter": "cccode-HQ"
  }
}

這種方式確保了所有資源都遵循組織的標籤規範，從而實作了一致的資源管理策略。

直接使用 OPA

OPA 作為一個獨立的工具，可以在命令列中直接使用，這對於測試和開發政策非常有用。

命令列評估政策

首先，我們需要安裝 OPA。由於它是用 Go 語言編寫的，安裝過程相當簡單，只需下載一個獨立的二進位檔案即可。

假設我們已經將前面的 AdmissionReview 資源儲存在 input.json 檔案中，並將 Rego 規則儲存在 cc-policy.rego 檔案中，我們可以使用以下命令來評估政策：

$ opa eval \
  --input input.json \
  --data cc-policy.rego \
  --package prod.k8s.acme.org \
  --format pretty 'deny'

執行結果會顯示：

[
  "Every resource must have a costcenter label"
]

這個命令的各個部分含義如下：

  • --input input.json：指定 OPA 應該使用的輸入資料
  • --data cc-policy.rego：指定要使用的 Rego 規則檔案
  • --package prod.k8s.acme.org：設定評估上下文（與 Rego 檔案中的 package 宣告相對應）
  • --format pretty 'deny'：指定輸出格式和要評估的查詢

這種命令列方式非常適合快速測試和驗證政策，尤其是在開發階段。

IDE 支援

對於政策開發者來說，好訊息是 OPA/Rego 已經有了豐富的 IDE 支援，從 VSCode 到 vim 等多種編輯器都有相應的外掛。這些外掛通常提供語法高亮、程式碼補全和即時錯誤檢查等功能，大提高了政策開發的效率。

在管理大規模叢集的 OPA 政策時，可能需要考慮使用 Styra 的 Declarative Authorization Service (DAS)，這是一個企業級 OPA 解決方案，提供集中式政策管理、日誌記錄和影響分析等實用功能。

政策型別檢查

OPA 支援使用 JSON Schema 對 Rego 政策進行型別檢查，這增加了一層驗證，可以幫助政策開發者捕捉錯誤。我在實際應用中發現，這個功能對於維護複雜政策特別有用，可以在早期發現潛在問題。

Gatekeeper：Kubernetes 原生的 OPA 整合

雖然 Rego 是一個強大的 DSL，但它確實有一定的學習曲線。許多 Kubernetes 使用者可能會想知道是否有更「Kubernetes 原生」的方式來使用 OPA。Gatekeeper 專案正是為此而生。

Gatekeeper 的核心概念

Gatekeeper 本質上引入了關注點分離：範本（Templates）代表政策（編碼為 Rego），而作為終端使用者，你會透過使用這些範本的 CRD 進行互動。設定在 API 伺服器中的准入控制器（Admission Controller）負責執行這些政策。

這種方式讓 Kubernetes 管理員可以使用熟悉的 YAML 格式和 kubectl 命令來管理政策，而不需要直接編寫 Rego 程式碼。

使用 Gatekeeper 實作標籤驗證

讓我們看如何使用 Gatekeeper 實作前面提到的 costcenter 標籤驗證。假設我們已經安裝了 Gatekeeper。

首先，我們需要定義一個範本，建立一個名為 K8sCostcenterLabels 的新 CRD。將以下內容儲存到 costcenter_template.yaml 檔案中：

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: costcenterlabels
spec:
  crd:
    spec:
      names:
        kind: K8sCostcenterLabels
      validation:
        openAPIV3Schema:
          properties:
            labels:
              type: array
              items: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package prod.k8s.acme.org
        deny[msg] {
          not input.request.object.metadata.labels.costcenter
          msg := "Every resource must have a costcenter label"
        }
        deny[msg] {
          value := input.request.object.metadata.labels.costcenter
          not startswith(value, "cccode-")
          msg := sprintf("Costcenter code must start with `cccode-`; found `%v`", [value])
        }

這個 YAML 檔案定義了一個 Gatekeeper 約束範本：

  • apiVersion 和 kind 指定這是一個 Gatekeeper 約束範本
  • metadata.name 定義了範本的名稱
  • spec.crd 部分定義了將建立的自定義資源定義 (CRD) 的規格
  • spec.crd.spec.names.kind 指定了 CRD 的型別名稱為 K8sCostcenterLabels
  • spec.crd.spec.validation 定義了 CRD 的引數驗證架構
  • spec.targets 部分包含了實際的 Rego 政策，與我們之前看到的政策相同

接下來，我們可以使用以下命令安裝這個範本：

$ kubectl apply -f costcenter_template.yaml

要使用這個範本，我們需要定義一個具體的例項（自定義資源，簡稱 CR）。將以下內容儲存到 req_cc.yaml 檔案中：

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sCostcenterLabels
metadata:
  name: ns-must-have-cc
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]

這個 YAML 檔案定義了一個具體的約束例項：

  • apiVersion 和 kind 指定這是一個 K8sCostcenterLabels 型別的約束
  • metadata.name 給這個約束一個名稱 ns-must-have-cc
  • spec.match 部分指定這個約束應該應用於哪些資源
  • 在這個例子中，約束將應用於核心 API 組（空字元串表示）中的 Namespace 資源

然後使用以下命令建立這個約束：

$ kubectl apply -f req_cc.yaml

執行此命令後，Gatekeeper 控制器將知道這個政策，並開始在 Kubernetes 叢集中執行它。從此以後，任何嘗試建立不帶有正確 costcenter 標籤的名稱空間的操作都將被拒絕。

OPA 與 Gatekeeper：選擇

在決定是直接使用 OPA 還是透過 Gatekeeper 使用時，需要考慮幾個因素：

直接使用 OPA 的優勢

  1. 更大的靈活性和可定製性
  2. 可以在 Kubernetes 之外的系統中使用相同的政策引擎
  3. 完全控制政策評估和執行流程

使用 Gatekeeper 的優勢

  1. 更加 Kubernetes 原生的體驗
  2. 使用熟悉的 YAML 和 kubectl 命令
  3. 內建的准入控制器整合
  4. 更容易在團隊中推廣和採用

我的建議是：如果你主要在 Kubernetes 環境中工作，並且希望有一個更加原生的體驗，Gatekeeper 是一個很好的選擇。如果你需要在多種環境中使用統一的政策引擎，或者需要更高階的自定義功能，直接使用 OPA 可能更合適。

政策測試與最佳實踐

無論選擇哪種方式，測試政策在佈署前是非常重要的。以下是我總結的幾點最佳實踐：

  1. 漸進式採用：從非關鍵系統開始，逐步擴充套件到更重要的系統
  2. 政策測試：建立自動化測試流程，確保政策更改不會導致意外後果
  3. 檔案化：清晰記錄政策的意圖和行為，幫助團隊理解
  4. 版本控制：將政策程式碼納入版本控制系統，跟蹤更改並支援回復
  5. 監控和稽核：實施監控和稽核機制，瞭解政策如何影響系統

結合 CI/CD 的政策執行

將 OPA 或 Gatekeeper 與 CI/CD 流程整合可以提前發現問題，避免在生產環境中出現政策違規。我建議在 CI 流程中增加政策驗證步驟，確保所有提交的資源定義都符合組織的政策要求。

在我的實踐中，這種「左移」的政策驗證方法可以大減少佈署失敗的情況，提高團隊的效率和信心。

政策即程式碼的方法為組織提供了一種強大的方式來確保合規性和安全性，同時不會阻礙開發速度。OPA 和 Gatekeeper 作為這一領域的領先解決方案，為雲原生應用提供了關鍵的保護層，確保系統在快速發展的同時保持穩定和安全。透過將政策決策從應用邏輯中分離出來，我們可以更容易地管理、更新和擴充套件政策，同時確保一致的執行。隨著雲原生態系統的不斷發展，這種統一的政策執行方法將變得越來越重要。

Kubernetes 政策引擎實戰：從 Gatekeeper 到 Kyverno

在 Kubernetes 環境中實施有效的安全控制與治理策略是維護叢集健康的關鍵。在前面的文章中，玄貓介紹瞭如何使用 Gatekeeper 來實作政策控制，現在讓我們進一步探討如何驗證這些政策的有效性，並介紹另一個強大的替代方案：CNCF Kyverno 專案。

驗證 Gatekeeper 政策有效性

要確認我們之前設定的標籤強制政策是否正常運作，可以嘗試建立一個不包含所需標籤的名稱空間。例如，當你使用 kubectl apply 嘗試建立一個缺少必要標籤的名稱空間時，系統會回傳錯誤訊息，內容包含「Every resource must have a costcenter label」，並拒絕資源建立請求。

這種即時的政策驗證機制確保了組織的規範能夠在資源建立時就得到強制執行，而不是事後補救。這正是政策即程式碼（Policy as Code）的核心價值所在。

Kyverno：Kubernetes 原生政策管理

除了 Gatekeeper 外，CNCF 孵化的 Kyverno 專案提供了另一種實作政策管理和強制執行的方式。這個由 Nirmata 公司發起的專案在概念上與 Gatekeeper 類別似，但實作方式有所不同。

Kyverno 的運作原理

Kyverno 作為一個動態准入控制器執行，同時支援驗證型（validating）和變更型（mutating）准入 webhook。其核心架構如下：

  1. 當 API 伺服器收到請求時，會呼叫 Kyverno webhook
  2. Kyverno 根據定義的政策評估請求
  3. 根據評估結果，請求可能被允許、拒絕或修改

Kyverno 與 Gatekeeper 的主要區別

Kyverno 最大的特點是不需要學習特定的政策語言（如 Rego）。它使用原生 Kubernetes YAML 格式來定義政策，這對於已熟悉 Kubernetes 資源定義的團隊來說，大降低了學習門檻。

以下是使用 Kyverno 實作前面提到的名稱空間標籤需求的例子：

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: costcenterlabels
spec:
  validationFailureAction: enforce
  rules:
  - name: check-for-labels
    match:
      resources:
        kinds:
        - Namespace
    validate:
      message: "label 'app.kubernetes.io/name' is required"
      pattern:
        metadata:
          labels:
            app.kubernetes.io/name: "?cccode-*"

這段 Kyverno 政策定義了以下關鍵元素：

  • match 部分指定了政策的目標資源型別，此例中為名稱空間（Namespace）
  • validate 部分定義了期望的模式（pattern），若資源不符合此模式，將回傳指定的錯誤訊息
  • app.kubernetes.io/name: "?cccode-*" 表示標籤值必須符合 “cccode-” 開頭的模式，問號表示此為必需項

對比前面的 Gatekeeper 政策，Kyverno 的語法更接近標準 Kubernetes 資源定義，不需要學習 Rego 語言，這使得政策的編寫和維護變得更加直觀。

Kyverno 與 Gatekeeper 的共同特性

兩種工具都有一些共同的行為特徵：

  1. Fail Open 機制：兩者在政策引擎服務不可用時都會採用「開放失敗」機制，即當 API 伺服器無法透過 webhook 驗證變更時，將允許未經驗證的變更繼續進行。這樣設計是為了防止政策引擎故障導致整個叢集被拒絕服務（DOS）或控制平面完全癱瘓。

  2. 稽核功能：兩者都提供稽核功能和掃描模式，用於監控和報告不符合政策的現有資源。

  3. 動態准入控制：都透過 Kubernetes 的動態准入控制機制實作政策執行。

如何選擇適合的政策引擎

選擇 Gatekeeper 還是 Kyverno 取決於團隊的具體需求和技術背景：

  1. 如果團隊已熟悉 Rego 語言：Gatekeeper 可能更適合，特別是當組織已經在使用 OPA 進行其他政策管理時。

  2. 如果希望降低學習曲線：Kyverno 的 YAML 原生格式對 Kubernetes 管理員更加友好，不需要學習新的語言。

  3. 政策複雜度：對於非常複雜的政策邏輯，Rego 的表達能力可能更強；而對於大多數常見的 Kubernetes 政策需求，Kyverno 已經足夠。

  4. 整合需求：考慮與現有工具鏈的整合性，以及社群支援和更新頻率。

玄貓建議在做決策前，先嘗試兩種工具的基本功能，評估哪一個更符合團隊的工作流程和技術能力。

其他政策管理解決方案

除了 Gatekeeper 和 Kyverno 外，還有許多其他政策管理工具和解決方案值得考慮。特別是在混合雲或多雲環境中，可能需要結合使用多種政策工具來滿足不同層面的需求。

開放原始碼政策工具

  1. OSO：這是一個用於在應用程式中建立授權機制的函式庫。它根據名為 Polar 的宣告式政策語言，提供 API 集合、CLI/REPL 以及除錯工具。OSO 可以表達如「這類別使用者可以檢視這類別資訊」的政策，並在應用程式中實作角色基礎存取控制。

  2. Cilium 和 Calico 網路政策：這些工具擴充套件了 Kubernetes 原生網路政策的功能，提供更細粒度的網路流量控制和安全規則。

雲端服務提供商的政策解決方案

各大雲端服務提供商也提供了與其平台整合的政策管理工具：

  1. AWS Identity and Access Management (IAM)：提供從身份型到資源型再到組織級別的各種政策。在 Amazon EKS 環境中，還可以為 Pod 定義安全群組。

  2. Google Identity and Access Management (IAM)：擁有豐富與強大的政策模型，與 Kubernetes 類別似。

  3. Azure Policy：允許定義業務層級政策，並提供 Azure RBAC 用於存取控制。

跨平台政策工具

  1. Pulumi CrossGuard：被描述為「政策即程式碼」的解決方案，提供跨雲端服務提供商的防護機制定義和實施。

這些工具可以單獨使用，也可以與 Gatekeeper 或 Kyverno 結合使用，以構建更全面的政策管理架構。

政策管理的最佳實踐

在實施 Kubernetes 政策管理時，玄貓建議遵循以下最佳實踐：

1. 團隊對映與角色設計

仔細思考如何將團隊對映到適當的群組和角色。特別注意那些允許傳遞存取其他服務帳號的角色，因為它們可能提供許可權提升的途徑。

2. 憑證安全

在威脅建模時，考慮憑證被盜用的影響。對於人類使用者，始終使用雙因素認證（2FA）。

3. 自動化政策測試

儘可能自動化政策測試和驗證過程。這不僅可以減少人為錯誤，還能確保政策在佈署到生產環境前得到充分測試。

4. 政策監控與稽核

定期稽核政策執行情況，監控政策違規事件，並建立適當的警示機制。

5. 循序漸進的實施

首先在非生產環境中以警告模式佈署政策，收集違規資料並調整政策，然後再在生產環境中強制執行。

6. 檔案與培訓

確保政策的目的、範圍和例外情況都有清晰的檔案，並為團隊提供必要的培訓。

政策管理的未來發展

Kubernetes 和更廣泛的 CNCF 生態系統已經提供了豐富的開放原始碼解決方案。現在的挑戰往往不是找不到工具，而是在眾多可用工具中選擇最適合的，並確保它在未來仍然得到支援。

隨著雲原生技術的不斷發展，政策管理工具也在不斷演進。未來的發展趨勢可能包括：

  1. 更緊密的開發流程整合：政策檢查將更深入地整合到 CI/CD 流程中
  2. AI 輔助政策生成與最佳化：利用機器學習技術自動生成和最佳化政策
  3. 跨叢集與跨雲政策統一管理：實作多環境下的一致政策執行

入侵檢測：下一道防線

即使有了完善的政策控制，仍然需要考慮萬一攻擊者突破這些控制後的情況。這就引出了下一個重要的安全主題：入侵檢測系統（IDS）。

入侵檢測系統能夠識別系統中的異常活動，就像運動感測器檢測移動一樣。當攻擊者已經存取了系統，甚至可能已經查看了機密訊息時，IDS 會實時檢查系統中的異常行為並觀察或阻止它。

在容器環境中，入侵檢測系統可以利用新的低階 eBPF 介面運作，檢查檔案、網路和內核的讀寫操作，並根據允許列表或拒絕列表進行驗證或阻止。

容器入侵檢測的特點包括：

  1. 行為基線：建立容器程式的正常行為基線
  2. 系統呼叫監控：檢測新的或不允許的系統呼叫
  3. 網路活動分析：識別異常的網路連線和資料傳輸
  4. 檔案系統監控：檢測意外的檔案存取和修改
  5. 使用者身份變更監控：識別身份設定的變更

入侵檢測是深度防禦策略的重要組成部分，它提供了當其他安全控制失效時的最後一道防線。

在現代雲原生環境中，政策管理和入侵檢測系統共同構成了一個全面的安全架構，能夠在不同層面上保護系統免受各種威脅。

無論選擇哪種政策工具，重要的是要建立一個符合組織需求、易於維護與能夠隨著環境變化而調整的政策框架。透過結合政策管理和入侵檢測，可以建立一個強大的多層次防禦系統，最大限度地保護 Kubernetes 環境的安全。

在下一篇文章中，玄貓將探討容器入侵檢測的具體實作方法和最佳實踐，敬請期待！

入侵偵測系統的核心機制與演進

在現代資安環境中，入侵偵測系統(IDS)扮演著至關重要的角色。這些系統的核心功能在於識別潛在的威脅活動，同時避免對合法行為產生誤報。實務上，我們通常透過預先設定的規則與簽章，或在非生產環境中的行為學習，來授權系統辨識正常行為。

預先授權與行為設定的重要性

入侵偵測系統要發揮效用，首先需要明確定義什麼是「正常行為」。這種定義可透過兩種主要方式實作：

  1. 預先設定的規則集：根據已知威脅模式和安全最佳實踐建立的規則
  2. 行為學習：在受控環境中觀察應用程式的正常運作模式

這種預先設定的機制確保了系統能夠準確區分合法活動與可疑行為，大幅降低了誤報率，同時提高了真正威脅的檢測能力。

傳統入侵偵測系統的分類別與限制

在探討雲原生入侵偵測之前，值得回顧傳統IDS的架構與功能，這有助於理解現代解決方案的創新之處。

網路型與主機型IDS的設計差異

傳統入侵偵測系統主要分為兩類別：

網路型入侵偵測系統(NIDS)

網路型IDS專注於監控網路流量，檢測可疑的通訊模式。這類別系統通常佈署在網路關鍵點，如：

  • 網路邊界處監控進出流量
  • 內部網段間的交界點
  • 關鍵伺服器前端

代表性工具包括Suricata、Snort和Zeek，這些工具透過規則引擎和指令碼機制檢查網路流量。由於資源需求較高，它們經常佈署在專用硬體上。然而，這類別系統面臨加密流量和隱寫術(steganography)的挑戰，難以檢測這些隱蔽的威脅。

主機型入侵偵測系統(HIDS)

主機型IDS則直接安裝在需保護的系統上，監控系統呼叫、檔案變更和程式活動。Linux內建的auditd就是一個典型例子，但它存在幾個明顯的侷限性：

  • 生成大量日誌，系統開銷較大
  • 難以在分散式系統中關聯跨節點活動
  • 對Linux名稱空間的識別能力有限，無法有效區分容器化環境中的程式

針對檔案完整性監控，Tripwire等工具雖然歷史悠久但仍然有效，它專注於檢測主機上檔案的未授權變更。

傳統IDS的檢測機制分析

無論是網路型還是主機型，傳統IDS主要採用兩種檢測方法：

簽章式檢測(Signature-based Detection)

簽章式檢測依賴於預先定義的威脅特徵函式庫：

  • 網路簽章：識別可疑的網路流量模式和掃描行為
  • 惡意軟體簽章：辨識已知惡意程式的二進位特徵
  • 記憶體簽章：檢測記憶體使用的異常模式

當系統識別出符合簽章的模式時，就會觸發警示。例如，在SUNBURST事件中，FireEye釋出了用於檢測其指令控制伺服器通訊的IDS設定，支援Snort、Yara、IOC和ClamAV等多種工具。

簽章式檢測的主要優勢在於資源消耗較少與誤報率較低，但它無法檢測零日攻擊(zero-day)和新型威脅。攻擊者可以在自己的測試系統中研究防禦工具，找出繞過檢測的方法。

異常行為檢測(Anomaly-based Detection)

異常行為檢測根據應用程式的「已知良好狀態」，透過觀察偏離正常行為的模式來識別潛在威脅。這種方法的優勢在於：

  • 能夠自主應對新型威脅
  • 不依賴於預定義的簽章函式庫
  • 對未知威脅有更好的檢測能力

然而，這種方法通常需要更多的系統資源，可能影響被保護系統的效能。此外，定義「正常行為」的過程將安全責任從工具轉移到了防禦者身上，要求他們確保應用程式的正確性。

實務上，熟練的攻擊者可能會欺騙、繞過甚至停用這兩種檢測機制，因此不應完全依賴單一控制措施。

VirusTotal與安全生態系統

在討論傳統IDS時，值得一提的是VirusTotal這一重要的惡意檔案函式庫。當防禦者發現攻擊時，他們會上載取得的惡意檔案，這有助於：

  • 研究人員關聯不同目標間的攻擊技術
  • 防禦者理解他們的對手和使用的攻擊手法
  • 反病毒廠商確保其產品能識別VirusTotal上的所有惡意檔案

然而，攻擊者同樣使用這些工具來確保其攻擊載荷能繞過反病毒和惡意軟體簽章掃描器。紅隊(Red Team)在攻擊活動被發現後，有時會將其工具和簽章洩露到VirusTotal上，這也成為了安全生態系統中的一部分。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。