編輯

共用方式為

監視適用於 PCI-DSS 3.2.1 的 AKS 基準叢集作業 (第 7 部分，共 9 部分)

Azure Kubernetes Service (AKS)
適用於雲端的 Microsoft Defender
Azure 監視器

本文說明 Azure Kubernetes Service (AKS) 叢集的考量事項，該叢集執行符合支付卡產業資料安全標準 (PCI-DSS 3.2.1) 的工作負載。

本文是系列文章的一部分。 閱讀簡介。

重要

指引和隨附的實作建置於 AKS 基準架構上。 該架構是以中樞和輪輻拓撲為基礎。 中樞虛擬網路包含用來控制輸出流量的防火牆、來自內部部署網路的閘道流量，以及用於維護的第三個網路。 輪輻虛擬網路包含用來提供持卡人資料環境 (CDE)，並裝載 PCI DSS 工作負載的 AKS 叢集。

GitHub 標誌 GitHub：適用於受管制工作負載的 Azure Kubernetes 服務 (AKS) 基準叢集提供了受管制環境的示範。 實作部分示範了如何透過各種 Azure 監視器功能來使用稽核線索。 當中包含叢集內網路測試點的範例，以及與叢集子網互動的資源。

定期監視和測試網路

需求 10—追蹤及監視對網路資源和持卡人資料進行的所有存取

AKS 功能支援

Azure 提供可用來監視容器 (包括 AKS 叢集) 的 Container Insights 功能。 如需詳細資訊，請參閱容器深入解析概觀。

AKS 提供多個層級的稽核記錄，對於主動保護系統和資料來說十分有用。 活動記錄提供了與帳戶和秘密管理、診斷設定管理、伺服器管理以及其他資源存取作業相關的資訊。 所有記錄皆包含日期、時間、身分識別和其他詳細資訊。 您還可以存取對 AKS 叢集進行之所有 API 呼叫的所有時間順序記錄。 這些記錄包含有關呼叫者、呼叫時間及呼叫來源的資訊。 如需詳細資訊，請參閱 AKS 控制平面/資源記錄。

在 Azure 上，RBAC (角色型存取控制) 是管理資源存取原則的標準做法。

所有記錄皆應儲存在客戶擁有的儲存體帳戶或 Azure 監視器記錄中。 這樣，您就能從大量資料中快速產生深入解析。 所有記錄都會在同一個區域中至少保留三份複本。 您可以啟用跨區域備份或複寫，以保留更多複本。 所有記錄項目都只能透過安全的 HTTP (s) 通道取得。

Azure 的警示架構可讓您設定警示，以偵測可疑的存取行為。 您可以設定需要觸發的警示，以及對應的事件。 使用者還可以使用 Log Analytics 來手動檢視完整記錄，並根據活動類型、活動內容或活動呼叫者進行篩選。

您的責任

需求 責任
需求 10.1 實作稽核線索，將系統元件的所有存取連結到每位個別使用者。
需求 10.2 為所有系統元件實作自動化的稽核線索，以重建下列事件：
需求 10.3 針對每個事件，為所有系統元件記錄至少下列稽核線索項目：
需求 10.4 使用時間同步技術，讓所有重要的系統時鐘和時間保持同步，並確保已實施下列時間擷取、發布和儲存措施。
需求 10.5 保護稽核線索，使其無法變更。
需求 10.6 檢閱所有系統元件的記錄和安全性事件，以識別異常或可疑活動。
需求 10.7 稽核線索歷程記錄需至少保留一年，其中至少三個月的記錄可立即用於分析 (例如線上、已封存或可從備份還原)。
需求 10.8 僅適用於服務提供者的附加需求：及時回應任何重要安全性控制項的失敗。 回應安全性控制項失敗的流程必須包含
需求 10.9 確保用於監視所有網路資源和持卡者資料存取的安全性原則和作業程序留有記錄、正在使用，並為所有受影響方知悉。

需求 11 — 定期測試安全性系統和流程

AKS 功能支援

AKS 已與 Azure 監視服務整合：

  • 適用於容器的 Microsoft Defender 提供多項安全性掃描功能。 例如，適用於容器的 Defender 會掃描已提取、推送及匯入至容器登錄的映像，並提供建議。 如需詳細資訊，請參閱弱點評估。

  • 您可以使用 Azure 監視器根據事件類型設定警示，以保護系統完整性和安全性。 當 AKS 節點上發生任何預期的系統失敗時，AKS 會及時自動修復資源，確保不影響系統處理流程。

AKS 叢集受到具有 Web 應用程式防火牆 (WAF) 的 Azure 應用程式閘道保護，並且可以設定為偵測模式，以記錄警示和威脅。 建議最好使用預防模式，主動封鎖偵測到的入侵和攻擊。 如需詳細資料，請參閱 Azure Kubernetes Service (AKS) 中的網路連線和安全性最佳做法。

您的責任

需求 責任
需求 11.1 實施流程，測試是否存在無線存取點 (802.11)，並每季偵測及識別所有授權及未經授權的無線存取點。
需求 11.2 至少每季和網路發生任何重大變化之後 (例如新的系統元件安裝、網路拓撲的變更、防火牆規則修改、產品升級) 執行一次內部和外部網路弱點掃描。
需求 11.3 實作滲透測試方法，包括：
需求 11.4 使用入侵偵測和/或入侵預防技術，偵測和/或防止網路入侵。
需求 11.5 部署變更偵測機制 (例如檔案完整性監視工具)，以提醒人員留意重大系統檔案、組態檔案或內容檔案是否遭到未經授權的修改 (包括變更、新增及刪除)，並將軟體設定為每週至少執行一次重要檔案比較。
需求 11.6 確保用於監視和測試安全性的安全性原則和作業程序留有記錄、正在使用，並為所有受影響方所知悉。

需求 10.1

實作稽核線索，將系統元件的所有存取連結到每位個別使用者。

您的責任

建議使用下列方法，稽核在每個元件上執行的作業：

  • Azure 監視器活動記錄。 活動記錄提供有關 Azure 資源作業類型和時間的資訊。 此外，它也會記錄啟動作業的身分識別。 活動記錄會預設啟用，並會在資源作業完成後立即收集資訊。 稽核線索無法變更，且無法刪除。

    資料會保留 90 天。 如需時間更長的資料保留選項，請考慮將活動記錄項目傳送至 Azure 監視器記錄，並設定保留和封存原則。

    Azure 活動記錄的螢幕擷取畫面。

  • Azure 診斷設定。 診斷設定會提供診斷和稽核資訊，範圍涵蓋 Azure 資源以及適用的平台。 建議您為 AKS 和系統中的其他元件 (例如 Azure Blob 儲存體和 Key Vault) 啟用診斷設定。 您可以根據資源類型，選擇要將哪些類型的記錄和計量資料傳送至目的地。 您的診斷目的地必須遵守規定的資料保留期限。

    • 透過系統提供的 AKS 類別，啟用 Kubernetes 稽核記錄。 診斷設定包括 kube-audit 或 kube-audit-admin 以及 guard。

      啟用 kube-audit-admin 以查看可能修改叢集狀態的記錄型 API 伺服器呼叫。 如果需要所有 API 伺服器互動的稽核線索 (包括讀取要求等非修改事件)，請改為啟用 kube-audit。 這些事件可能會大量產生、形成雜訊，並增加您的使用量成本。 這些記錄包含用於提出要求之存取權和身分識別名稱的相關資訊。

      啟用 guard 記錄，以追蹤受控 Microsoft Entra ID 和 Azure 角色型存取控制 (RBAC) 稽核。

    • 除了基於使用者的記錄外，也請考慮追蹤來自 Kubernetes 控制平面的記錄，包括 kube-apiserver 和 kube-controller-manager。 這些記錄通常與使用者無關，但有助於連結至使用者所做的系統變更。

      如需更多資訊，請參閱查看控制平面元件記錄。

    此參考實作會啟用 cluster-autoscaler、kube-controller-manager、kube-audit-admin和 guard 記錄，並轉送至 Log Analytics 工作區。 工作區保留期間設定為 90 天。

    AKS 診斷設定的螢幕擷取畫面。

  • Azure Kubernetes Service (AKS) 診斷有助於偵測和解決叢集相關問題，例如節點失敗。 它還能提供特定網路的診斷資料，且不會產生額外費用。 這些資料通常不會連結至使用者活動，但可幫助您了解使用者進行的系統變更所產生的影響。 如需相關資訊，請參閱 Azure Kubernetes Service 診斷。

上述稽核線索機制應於部署資源時實作。 此外，Azure 原則應保持作用中狀態，以確保這些組態不會在 CDE 中無意或惡意遭到停用。

需求 10.2

為所有系統元件實作自動化的稽核線索，以重建下列事件：

  • 10.2.1 所有個人使用者對持卡人資料的存取
  • 10.2.2 具有根或系統管理權限之任何個人所採取的所有動作
  • 10.2.3 對所有稽核線索的存取
  • 10.2.4 無效邏輯存取嘗試
  • 10.2.5 身分識別及驗證機制的使用和變更 - 包括但不限於建立新帳戶及提高權限 - 以及具有根或系統管理權限之帳戶的所有變更、新增或刪除
  • 10.2.6 稽核線索的初始化、停止或暫停
  • 10.2.7 建立及刪除系統層級物件

您的責任

AKS 提供多個層級的稽核記錄，如需求 10.1 中所述。 以下列出一些重點：

  • 根據預設，活動記錄會提供重要 Azure 資源作業的相關資訊。 所有記錄皆包含狀態、時間和啟動作業的身分識別。
  • 啟用診斷設定，以存取所有對 AKS 叢集進行的 API 呼叫記錄。 記錄包含有關要求者、時間戳記、要求來源和要求內容的詳細資料。 將記錄儲存在設有適當保留期間的 Log Analytics 工作區中。 啟用 Log Analytics 工作區記錄功能，以確保一併記錄對稽核線索進行的存取。
  • 啟用使用容器深入解析收集 syslog，以擷取 Log Analytics 工作區中的 AKS 節點層級作業系統安全性和健康狀態事件記錄。 這些記錄也應提取至您的 SIEM 中。
  • 納入其他計算資源 (例如組建代理程式和跳躍箱) 的 OS 和使用量稽核記錄。 停用以 root 身分直接存取系統的權限。 確保所有操作均以特定身分識別執行。
  • 記錄不成功的存取嘗試。 包括對 Azure 儲存體、Azure Key Vault、AKS API 伺服器等元件的存取要求，以及其他系統上的任何 RDP/SSH 存取。
  • 使用第三方安全性代理程式提供的功能，協助分析 AKS 叢集內部的使用者模式。 這些功能對使用者存取稽核資料可能十分有用。

需求 10.3

針對每個事件，為所有系統元件記錄至少下列稽核線索項目：

  • 10.3.1 使用者識別
  • 10.3.2 事件類型
  • 10.3.3 日期與時間
  • 10.3.4 成功或失敗指示
  • 10.3.5 事件的來源
  • 10.3.6 受影響的資料、系統元件或資源的識別或名稱。

您的責任

如需求 10.2 中所述，您可以透過啟用 AKS 的診斷設定，從叢集中取得稽核記錄。 這些記錄包含取得、列出、建立、更新、刪除、修補和發布事件的詳細資訊。 這些記錄包含需求中指定的資訊。 將記錄儲存在儲存體帳戶中，以便於查詢資訊。

例如，您可以透過執行以下查詢，檢視 kube-audit-admin 事件的上述資訊集：

AzureDiagnostics
| where Category == 'kube-audit-admin'
| project TimeGenerated, ResourceId, log_s,  pod_s
| top 200 by TimeGenerated desc

診斷範例的螢幕擷取畫面。

結果集會在 log_s 欄位中顯示資訊。

必要資訊 結構描述
使用者識別 SourceIPs
事件類型 動詞
日期和時間 requestReceivedTimestamp
成功或失敗指示 responseStatus
事件的來源 使用者
受影響的資料、系統元件或資源的識別或名稱 objectRef

如需有關控制平面記錄的資訊，請參閱 AKS 控制平面/資源記錄。

需求 10.4

使用時間同步技術，讓所有重要的系統時鐘和時間保持同步，並確認已實施下列時間擷取、發布和儲存措施。

  • 10.4.1 關鍵系統的時間正確且一致。
  • 10.4.2 時間資料受到保護。
  • 10.4.3 已從業界公認的時間來源接收時間設定。

注意：網路時間通訊協定 (NTP) 是時間同步技術的一個例子。

您的責任

AKS 會使用基礎 Azure 主機的 NTP，而且不需要允許任何輸出網路流量，即可支援 NTP。 您新增至 CDE 的其他 VM 可能會使用 ntp.ubuntu.org 等外部 NTP 伺服器 (及其集區) 做為時間同步處理來源。 您導入 CDE 的其他計算資源應明確使用您選擇的 NTP 來源，並加以記錄。

需求 10.5

僅限有工作相關需求的人可以檢視稽核線索。

  • 10.5.1 僅限有工作相關需求的人可以檢視稽核線索。
  • 10.5.2 保護稽核線索檔案不受未經授權的修改。
  • 10.5.3 儘快將稽核線索檔案備份到難以變更的集中式記錄伺服器或媒體。
  • 10.5.4 將面向外部技術的記錄寫入安全、集中式的內部記錄伺服器或媒體裝置。
  • 10.5.5 針對記錄使用檔案完整性監視或變更偵測軟體，以確保在未產生警示的情況下，無法變更現有的記錄資料 (儘管新增的資料不應造成警示)。

您的責任

擁有多個記錄接收器，會增加保護、檢閱、分析和查詢稽核線索資料的負擔。 妥善規劃您的稽核線索拓撲，以便在完整稽核線索的隔離需求與管理考量事項之間取得平衡。

盡可能整合記錄。 這樣做的好處是可以提高檢閱、分析和查詢資料的效率。 Azure 提供多種技術選項。 您可以使用 Azure 監視器容器深入解析，將記錄寫入 Log Analytics 工作區。 另一個選項是將資料整合至安全性資訊和事件管理 (SIEM) 解決方案中，例如 Microsoft Sentinel。 其他常見的第三方選項包括 Splunk、QRadar 和 ArcSight。 適用於雲端的 Microsoft Defender和 Azure 監視器皆支援上述所有解決方案。 這些解決方案是僅限附加的資料接收器，可確保線索不會遭到變更。

適用於雲端的 Defender 可依照設定的時間間隔匯出結果。 如需更多資訊，請參閱連續匯出。

所有記錄都會在同一個區域中至少保留三份複本。 做為備份策略，您可以啟用跨區域備份或複寫，以保留更多複本。 所有記錄項目都只能透過安全的 HTTP (s) 通道取得。

Log Analytics 和 Microsoft Sentinel 支援各種可用來管理稽核線索存取權的角色型存取控制項。 請確保這些角色與組織的角色和責任相對應。

確保 Log Analytics 工作區同時滿足作業和合規性需求。 請考慮為您的範圍內叢集設置專用的工作區，並將資料轉送至 SIEM 解決方案。

AKS 中的大部分記錄將來自 stdout/stderr，並將由 Azure 監視器容器深入解析收集。 如果您有其他手動建立的記錄，請考慮以傳送至受信任的轉送串流、而且不會遭到竄改的方式釋出這些資料。

需求 10.6

檢閱所有系統元件的記錄和安全性事件，以識別異常或可疑活動。

  • 10.6.1 每天至少檢閱一次以下項目：
    • 所有安全性事件
    • 用來儲存、處理或傳輸 CHD 和/或 SAD 之所有系統元件的記錄
    • 所有關鍵系統元件的記錄
    • 執行安全性功能 (例如防火牆、入侵偵測系統/入侵預防系統 (IDS/IPS)、驗證伺服器、電子商務重新導向伺服器等) 之所有伺服器和系統元件的記錄。
  • 10.6.2 根據組織的原則與風險管理策略 (由組織的年度風險評估所決定)，定期審查所有其他系統元件的記錄。
  • 10.6.3 追蹤審查期間發現的例外狀況及異常。

您的責任

Azure 監視服務、Azure 監視器和適用於雲端的 Microsoft Defender 可以在偵測到異常活動時，產生通知或警示。 這些警示包含嚴重性、狀態和活動時間等脈絡資訊。

有警示產生時，請制定補救策略和審查程序。 其中一種方法是追蹤適用於雲端的 Microsoft Defender 中的安全性分數，並與歷來結果進行比較。

使用 SIEM 解決方案 (例如 Microsoft Sentinel)，將資料集中為單一檢視。 整合這些資料，有助於提供豐富的警示脈絡資訊。

或者也可以手動檢查儲存體中的完整記錄。 例如，在 Azure 監視器記錄中，您可以根據活動類型、活動內容或活動呼叫者進行篩選。

制定組織原則，以定期檢視警示和事件，並規劃具有具體改善目標的計畫。 使用 Log Analytics 中的自訂查詢儲存功能，記錄預定的記錄查詢，並簡化查詢過程。 這可確保團隊得知與 10.6 相關的重要審查事項，並確保此流程中涉及的所有手動作業皆遵循一致的工作流程。

需求 10.7

稽核線索歷程記錄需至少保留一年，其中至少三個月的記錄可立即用於分析 (例如線上、已封存或可從備份還原)。

您的責任

根據預設，記錄不會無限期保留。 務必設定您的 Azure 活動記錄和診斷設定保留方式，使其可供查詢。 為資源啟用診斷設定時，請指定三個月的保留期間。 Azure 監視器記錄支援長期封存，因此適用於稽核或離線分析。 實作長期封存解決方案，以符合一次寫入、多次讀取原則。

需求 10.8

10.8.1 僅適用於服務提供者的附加需求：及時回應任何重要安全性控制項的失敗。 回應安全性控制項失敗的流程必須包含：

  • 還原安全性功能
  • 識別並記錄安全性失敗的持續時間 (從開始到結束的日期和時間)
  • 識別並記錄失敗原因 (包括根本原因)，並記錄解決根本原因所需的補救措施
  • 識別並解決失敗期間浮現的任何安全性問題
  • 執行風險評估，以確定是否因安全性失敗而需要採取進一步行動
  • 實作用來防止失敗原因再次發生的控制項
  • 恢復對安全性控制項的監控

您的責任

如果可行，請設置警示，以指出關鍵安全性控制項是否存在。 否則，請確保稽核流程能夠及時偵測到缺少預期的安全性控制項。 考慮採取控制措施，例如在 AKS 叢集中執行的安全性代理程式，以及 Azure 資源上的存取控制 (IAM 和網路)。 加入用來檢查 AKS 叢集是否為私人叢集、透過網路安全性群組 (NSG) 規則檢查網路暴露點，或是否存在非預期公用 IP 的設定。 此外，也請檢查 DNS、網絡路由、防火牆和 Microsoft Entra ID 的非預期變更。

需求 10.9

確保用於監視所有網路資源和持卡者資料存取的安全性原則和作業程序留有記錄、正在使用，並為所有受影響方知悉。

您的責任

請務必保留有關流程與原則的完整文件。 維護有關強制執行原則的文件。 參與監視工作的人員必須接受有關啟用和檢視稽核記錄，以及識別和補救常見風險的訓練。 從原則觀點而言，這點對於參與核准流程的人員來說至關重要。

需求 11.1

實施流程，測試是否存在無線存取點 (802.11)，並每季偵測及識別所有授權及未經授權的無線存取點。

外部網路超出本文件的範圍，因此需要單獨評估。

您的責任

此架構和實作並非設計用來透過無線連線，支援內部部署或公司網路至雲端的交易。 相關考量事項請參閱官方 PCI-DSS 3.2.1 標準中的指引。

需求 11.2

至少每季和網路發生任何重大變化之後，執行一次內部和外部網路弱點掃描。重大網路變更的例子包括：

  • 安裝新的系統元件
  • 網路拓撲變更
  • 防火牆規則修改
  • 產品升級

如需詳細資訊，請參閱適用於核准掃描廠商的支付卡產業 (PCI) 資料安全性標準。

您的責任

建立一個流程，用來檢查 AKS 叢集、網路組態、容器登錄以及其他架構元件的變更。

網路發生變更時，該流程應評估是否需要執行掃描。 例如，叢集目前是否已向公用網際網路公開？ 新的防火牆規則是否過於寬鬆？ 在叢集內，Pod 之間的流量是否存在安全性缺口？

對基礎結構的重大變更做出所有人一致同意的明確定義。 一些範例包括：

  • NSG 或 Azure 防火牆規則的組態
  • 虛擬網路對等互連
  • DNS 設定
  • Azure Private Link 組態
  • 其他網路元件

適用於 11.2.1

每季的弱點掃描需由精通 Azure 網路和 Kubernetes 網路概念的專業人員執行。 將結果對應至 需求 6.1 中的嚴重性層級，並解決高優先順序項目。 如有重大變更，請在排定的每季掃描之前執行掃描。 這可以幫助您偵測新的弱點，進而主動修正問題。

此掃描也必須涵蓋叢集內 (Pod 到 Pod) 網路。

適用於 11.2.2

選擇在 Azure 網路和 Kubernetes 方面擁有豐富經驗的核准掃描廠商 (ASV)。 這可以讓建議的補救措施更加深入且具體。

需求 11.3

實作滲透測試方法，包括：

  • 基於業界公認的滲透測試方法 (例如 NIST SP800-115)
  • 將整個 CDE 週邊和關鍵系統納入涵蓋範圍
  • 加入從網路內部及外部進行的測試
  • 加入用於驗證任何分割和範圍縮減控制項的測試
  • 定義應用層滲透測試，其中至少包括需求 6.5 中所列的弱點
  • 定義網路層滲透測試，以包含支援網路功能和作業系統的元件
  • 包含過去 12 個月內遇到的威脅與弱點之審查及考慮
  • 指定滲透測試結果和補救活動結果的保留期間。

您的責任

執行滲透測試，藉由收集資訊、分析弱點和製作報表來找出安全性缺口。 建議您遵循滲透測試執行標準 (PTES) 中的業界指導方針處理常見案例，並執行建立基準所需的活動。

滲透測試實作人員應對內部部署和 Azure 網路有深入的了解，以確保全面涵蓋每年的分割測試。 將測試方法延伸至叢集內網路。 實作人員需精通 Kubernetes 網路概念。

測試必須涵蓋在 CDE 中執行的應用程式和資料層。

在滲透測試期間，實作人員可能需要存取整個組織的敏感資料。 請遵守參與規則，以避免存取權和存取意圖遭到濫用。 如需有關規劃及執行模擬攻擊的指引，請參閱滲透測試參與規則。

需求 11.4

使用入侵偵測和/或入侵預防技術，偵測和/或防止網路入侵。 監視持卡人資料環境周邊和持卡人資料環境關鍵點上的所有流量。 提醒相關人員注意可疑的外洩情況。

您的責任

使用 Web 應用程式防火牆 (WAF) 檢查輸入流量，以保護 AKS 叢集。 在此架構中，已整合 WAF 的 Azure 應用程式閘道可防止入侵。 使用預防模式主動封鎖偵測到的入侵和攻擊。 請勿只使用偵測模式。 如需更多資訊，請參閱 Azure Kubernetes Service (AKS) 中的網路連線和安全性最佳做法。

另一種選擇是使用 Azure 防火牆進階版中的入侵偵測和/或入侵預防功能。 如需詳細資訊，請參閱 IDPS。

另一個選項是啟用 Azure 監視器網路深入解析，此功能提供對網路監視功能 (如連接監視器、網路安全群組 (NSG) 流量記錄和流量分析) 的存取權。

啟用適用於各種 CDE 元件的 Microsoft Defender 方案。 舉例來說，如果使用 Azure SQL 來儲存 CHD，則 適用於 SQL 的 Microsoft Defender 將能確保偵測到資料層入侵。

此外，還可以將 NSG 流量記錄連接至集中式 SIEM 解決方案 (例如 Microsoft Sentinel)，以偵測流量模式的異常狀況。 在此參考實作中，記錄處於僅限附加模式，以盡可能減少稽核記錄的變更追蹤。 然而，為了長期儲存而傳送至外部接收器的所有記錄一律不得修改。 這些記錄必須遵循一次寫入/多次讀取方法。 為了偵測變更，請確保檔案完整性監視 (FIM) 解決方案涵蓋這些外部實體。

需求 11.5

部署變更追蹤解決方案 (例如檔案完整性監視解決方案)，以便在關鍵系統檔案、組態檔案或內容檔案遭到未經授權的修改時警示相關人員。 將產品設定為每週至少執行一次重要檔案比較。

您的責任

在叢集中同時執行檔案完整性監視 (FIM) 解決方案與 Kubernetes 感知安全性代理程式，以偵測可能導致節點層級變更的檔案和系統層級存取。 選擇 FIM 解決方案時，需清楚了解其功能和偵測深度。 請考慮使用信譽良好的廠商所開發的軟體。

重要

參考實作提供了一個預留位置 DaemonSet 部署，用於執行 FIM 解決方案反惡意程式碼軟體代理程式。 代理程式將在叢集中的每個節點 VM 上執行。 將您選擇的反惡意程式碼軟體置於此部署中。

檢查 FIM 工具的所有預設設定，以確保這些值能夠偵測您想要涵蓋的案例，並適當地調整這些設定。

確保解決方案能夠將記錄傳送至您的監視或 SIEM 解決方案，以便產生警示。 請留意記錄結構描述變更，以免錯過重大警示。

CDE 中的所有其他計算資源皆應啟用變更追蹤。

需求 11.6

確保用於監視和測試安全性的安全性原則和作業程序留有記錄、正在使用，並為所有受影響方所知悉。

您的責任

請務必保留有關流程與原則的完整文件。 維護有關強制執行原則的文件。 納入審查頻率和審查準則，做為測試流程的一環。 確保團隊了解滲透測試的各個層面。 制定書面補救計畫有助於減輕已發現的風險。

從原則觀點而言，這點對於參與核准流程的人員來說至關重要。

下一步

維護可解決所有人員資訊安全性問題的原則。

維護資訊安全性原則