編輯

監視 PCI-DSS 3.2.1 AKS 基準叢集的作業（第 9 部分的第 7 部分）

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

本文說明執行工作負載以符合支付卡產業資料安全性標準（PCI-DSS 3.2.1）的 Azure Kubernetes Service （AKS） 叢集的考慮。

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

重要

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

GitHub logoGitHub：適用于受管制工作負載的 Azure Kubernetes Service （AKS） 基準叢集示範受管制的環境。 實作說明透過各種 Azure 監視器功能使用稽核線索。 它有叢集內網路測試點的範例，以及與叢集子網互動的資源。

定期監視及測試網路

需求 10 - 追蹤和監視網路資源和持卡人資料的所有存取

AKS 功能支援

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

AKS 提供多個層級的稽核記錄，有助於主動保護系統和資料。 活動記錄提供與帳戶和秘密管理相關的作業相關資訊;診斷設定管理;伺服器管理;和其他資源存取作業。 所有記錄都會記錄日期、時間、身分識別和其他詳細資訊。 您也可以存取對 AKS 叢集進行之所有 API 呼叫的所有時間記錄。 記錄包含呼叫者的相關資訊、進行呼叫的時間、起始呼叫的來源等等。 如需詳細資訊，請參閱 在 Azure Kubernetes Service （AKS） 中啟用及檢閱 Kubernetes 控制平面記錄。

RBAC（角色型存取控制）可用來管理資源存取原則，作為 Azure 上的標準做法。

所有記錄都應該儲存在客戶擁有的儲存體帳戶或 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 監視器 記錄，並設定保留和封存原則。

    Screenshot that shows the Azure Activity Log.

  • Azure 診斷設定 。 提供 Azure 資源的診斷和稽核資訊，以及套用設定的平臺。 建議您為系統中的 AKS 和其他元件啟用診斷設定，例如Azure Blob 儲存體和金鑰保存庫。 根據資源類型，您可以選擇要傳送至目的地的記錄和計量資料類型。 您的診斷目的地必須符合必要的保留期間。

    • AKS 的診斷設定。 從提供的 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 天。

    Screenshot that shows the AKS diagnostic setting.

  • 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 工作區記錄，以確保甚至會記錄稽核記錄的存取權。
  • 使用 Container Insights 啟用 syslog 集合，以擷取 Log Analytics 工作區中的 AKS 節點層級作業系統安全性和健康情況事件記錄。 這些記錄也應該內嵌至您的 SIEM。
  • 包含 OS 和使用量稽核記錄，以用於其他計算，例如組建代理程式和跳躍方塊。 將系統直接存取停用為根目錄。 確認所有動作都是在特定身分識別下執行。
  • 記錄失敗的存取嘗試。 這包括存取元件的要求，例如Azure 儲存體、Azure 金鑰保存庫、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 的診斷設定，從叢集取得稽核記錄。 記錄包含 get、list、create、update、delete、patch 和 post 事件的詳細資訊。 記錄檔包含 [需求] 下方清單中的資訊。 將記錄儲存在儲存體帳戶中，以便您可以查詢資訊。

例如，您想要執行此查詢來檢視 kube-audit-admin 事件的上述資訊集：

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

Screenshot that shows a diagnostic example.

結果集會將資訊顯示為 [log_s] 欄位的一部分。

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

如需主要記錄檔的相關資訊，請參閱 檢視控制平面元件記錄 。

需求 10.4

使用時間同步處理技術來同步處理所有重要的系統時鐘和時間，並確認已實作下列專案來取得、散發和儲存時間。

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

注意：時間同步處理技術的其中一個範例是網路時間通訊協定（NTP）。

您的責任

AKS 會使用來自基礎 Azure 主機的 NTP，而且不需要任何輸出網路流量額度來支援 NTP。 您新增至 CDE 的其他 VM 可能會使用外部 NTP 伺服器，例如 ntp.ubuntu.org 及其集區作為其時間同步處理來源。 您帶入 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 識別碼中的非預期變更。

需求 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 叢集。 在此架構中，Azure 應用程式閘道與整合式 WAF 可防止入侵。 使用防止 模式主動封鎖偵測到的入侵和攻擊。 不要只使用 偵測 模式。 如需詳細資訊，請參閱 Azure Kubernetes Service （AKS） 中網路連線和安全性的最佳做法。

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

另一個選項是啟用 Azure 監視器網路深入解析 ，其可讓您存取網路監視功能，例如連線監視器、網路安全性群組 （NSG） 和流量分析的流量記錄。

在套用至 CDE 的各種元件時啟用 Microsoft Defender 方案。 例如，如果使用 Azure SQL 來儲存 CHD，則 適用于 SQL 的 Microsoft Defender 會確定偵測到資料層入侵。

此外，將 NSG 流量記錄連線到集中式 SIEM 解決方案，例如 Microsoft Sentinel，以偵測流量模式中的異常狀況。 在此參考實作中，記錄處於僅限附加模式，可將稽核記錄的變更追蹤降到最低。 不過，針對長期儲存體傳送至外部接收的所有記錄，都不得修改。 他們必須遵循寫入一次/讀取多的方法。 請確定檔案完整性監視 （FIM） 解決方案涵蓋這些外部實體來偵測變更。

需求 11.5

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

您的責任

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

重要

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

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

讓解決方案能夠將記錄傳送至您的監視或 SIEM 解決方案，以便產生警示。 請注意記錄架構變更，或您可能會錯過重大警示。

CDE 中的任何其他計算都應該啟用變更追蹤。

需求 11.6

請確定安全性監視和測試的安全性原則和操作程式記載、使用中，以及所有受影響的合作物件都知道。

您的責任

請務必維護有關程式與原則的徹底檔。 維護有關強制執行原則的檔。 作為測試工作的一部分，包括檢閱頻率和檢閱準則。 請確定小組瞭解滲透測試的各個層面。 有記載的補救計畫可降低找到的風險。

對於從原則觀點而言，屬於核准程式一部分的人員而言，這很重要。

下一步

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

維護資訊安全性原則