Amazon Inspector 抑制規則在 AWS Organizations 中的最佳實踐

漏洞管理是網路、應用程式和基礎設施安全的重要部分，其目標是保護組織免於敏感資料和基礎設施的意外存取和暴露。作為漏洞管理的一部分，組織通常會進行風險評估，以確定哪些漏洞構成最大風險，評估其對業務目標和整體策略的影響，並評估相關的法規要求。

在這篇文章中，我們解釋如何使用機制在 AWS Organizations 中適當地優先處理您的帳戶中的漏洞。我們討論如何將標籤應用於資源，以便您可以在環境中使用基於風險的 Amazon Inspector 發現優先級，並討論一些在大規模使用抑制規則以抑制不太重要的 Amazon Inspector 發現的最佳實踐。我們還強調建立持續漏洞管理文化的做法。

使用 Amazon Inspector 進行漏洞管理

Amazon Inspector 是一項漏洞管理服務，持續掃描您的 Amazon Web Services (AWS) 工作負載中的軟體漏洞和意外的網路暴露。Amazon Inspector 自動發現並掃描正在運行的 Amazon Elastic Compute Cloud (Amazon EC2) 實例、Amazon Elastic Container Registry (Amazon ECR) 中的容器映像和 AWS Lambda 函數。

當 Amazon Inspector 發現軟體漏洞或意外的網路暴露時，會創建一個發現。發現描述了漏洞，識別受影響的資源，評估漏洞的嚴重性，並提供修復指導。您可以在 Amazon Inspector 中創建抑制規則，以抑制不太重要的發現，從而專注於更高優先級的發現。

AWS Organizations 中漏洞管理的最佳實踐

我們建議您使用本節中討論的最佳實踐，以簡化在 AWS Organizations 中解決數千個漏洞發現的任務。

最佳實踐 #1：設置委派管理員

您可以使用 Amazon Inspector 管理組織中多個 AWS 帳戶的漏洞掃描。為此，AWS Organizations 管理帳戶需要指定一個帳戶作為 Amazon Inspector 的委派管理員帳戶。委派管理員帳戶對 Amazon Inspector 部署具有集中控制權，這使得跨 AWS Organizations 的多個帳戶更高效和有效地管理安全監控任務。這些任務包括為成員帳戶啟用或停用掃描，按 AWS 區域聚合發現，查看整個組織的聚合發現數據，以及創建和管理抑制規則。

Amazon Inspector 是一項區域性服務，這意味著您必須在每個您想使用 Amazon Inspector 的 AWS 區域中指定委派管理員、添加成員帳戶並啟用掃描類型。在設置委派管理員帳戶時，請注意以下因素：

委派管理員可以為組織中的帳戶創建和管理 Internet 安全中心 (CIS) 掃描配置，但成員帳戶創建的任何掃描配置除外。
在多帳戶設置中，只有委派管理員能夠為整個組織設置掃描模式配置。
您可以使用 Amazon Inspector 對組織中的 Amazon EC2 實例進行按需和針對性評估，以符合操作系統級別的 CIS 配置基準。

最佳實踐 #2：使用抑制規則大規模管理發現

在您的帳戶中可能有數千個特定的常見漏洞和暴露 (CVEs) 或 Amazon 資源名稱 (ARNs)，因此使用適當的抑制規則大規模管理這些發現將引導您實現成功的漏洞管理。

抑制規則是一組由篩選屬性和值組成的條件，用於通過自動存檔符合指定條件的新發現來篩選發現。您可以創建抑制規則以排除您不打算處理的漏洞，以便優先處理最重要的發現。抑制規則不會影響發現本身，也不會阻止 Amazon Inspector 生成發現。抑制規則僅用於篩選您的發現列表，使您更容易導航和優先處理它們。

一些有用的篩選器可以在抑制規則中使用，包括資源標籤、資源類型、嚴重性、漏洞 ID 和 Amazon Inspector 分數。例如，您可以根據嚴重性級別（關鍵、高、中、低、信息和未分類）對發現進行分類。要了解 Amazon Inspector 如何為每個發現確定嚴重性評級，請參閱了解您的 Amazon Inspector 發現的嚴重性級別。

您可以根據不同的類別（如漏洞、帳戶或實例）瀏覽 Amazon Inspector 中的發現。在 Amazon Inspector 的所有發現頁面上，如果您選擇一個 CVE ID，您可以查看受影響資源的詳細信息和個別 AWS 帳戶 ID，如圖 1 所示。這可以幫助您選擇在抑制規則中使用的篩選條件。

圖 1：Amazon Inspector 發現和嚴重性級別

您在組織層級管理抑制規則，規則適用於所有成員帳戶。如果 Amazon Inspector 生成的新發現符合抑制規則，服務會自動將發現的狀態設置為已抑制。符合抑制規則條件的發現不會出現在發現列表中，默認情況下。因此，已抑制的發現不會影響您的服務配額。成員帳戶繼承委派管理員的抑制規則。委派管理員帳戶限制為 500 條規則（每個區域），這是一個硬性限制。

請記住，組織中的成員帳戶無法創建或管理抑制規則。只有獨立帳戶和 Amazon Inspector 委派管理員可以創建和管理抑制規則。因此，如果組織中的某個成員帳戶需要獨立管理其自己的抑制規則，則帳戶所有者需要在其帳戶中單獨啟用 Amazon Inspector。

最佳實踐 #3：根據 Amazon Inspector 分數抑制發現

由於您的時間有限，尤其是在較大的組織中，安全漏洞發現的數量可能很大，因此您需要能夠快速識別和響應對組織構成最大風險的漏洞。

抑制發現的一種快速方法是使用 Amazon Inspector 分數。Amazon Inspector 檢查構成國家漏洞數據庫 (NVD) 常見漏洞評分系統 (CVSS) 基本分數的安全指標，根據您的計算環境進行調整，然後生成一個從 1 到 10 的數字分數，反映漏洞的嚴重性。

NVD/CVSS 分數是安全指標的組合，例如威脅複雜性、漏洞代碼成熟度和所需特權，但它不是風險的衡量標準。

注意不要過度抑制您的發現。過度抑制發現可能會無意中使應用程式和系統暴露於未緩解的安全風險。應在應用抑制規則時保持謹慎和適度的方法。保持對每個發現的真實風險概況的可見性對於主動、全面的漏洞管理至關重要。

最佳實踐 #4：使用標籤啟用基於風險的優先級

對於可擴展的漏洞管理解決方案，重要的是要有一個策略來在您的帳戶中適當地標記資源。

要優先處理漏洞，首先您需要了解和評估每個資源的風險級別，以便正確標記它。正確的標籤使您能夠使用基於風險的優先級。這意味著當您評估發現時，您會查看資源的風險級別、漏洞的嚴重性以及漏洞對組織環境的影響等因素，以便您可以首先專注於關鍵漏洞。這似乎是一個顯而易見的建議，但其重要性不能被低估。在雲端中，您必須了解並保護您構建的所有內容。資產映射必須包括關係映射，以了解潛在安全事件的影響和風險路徑。

修復雲資源問題的優先級取決於資源的暴露程度。公共子網中的資源通常應優先於私人子網中的資源。運行在生產環境中的資源應優先於開發和測試環境中的資源。

優先級還取決於防火牆規則、AWS 身份和訪問管理 (IAM) 策略、服務控制策略和安全組等因素。通過各種端口和協議具有更多開放互聯網訪問的資源比具有嚴格訪問限制的資源更容易出現拒絕服務 (DoS)、分佈式拒絕服務 (DDoS)、欺騙、惡意軟體和勒索軟體等問題。

最佳實踐 #5：基於適當的資源標籤設置抑制規則

在複雜的多帳戶環境中，使用資源 ID、子網 ID 或 VPC ID 集中管理抑制規則可能具有挑戰性，因為這些值是特定於個別帳戶的，並且隨著新部署或修改而隨時間變化。這使得保持抑制規則的更新變得困難。在這裡，我們回顧如何利用基於風險的優先級（最佳實踐 #4）以及 Amazon Inspector 分數來有效管理、優先處理和跟踪您的發現。

以下示例提供了一個建議的標籤策略，您可以在組織中的 AWS 雲資源中使用該策略來進行漏洞管理：

EnvironmentName, RiskExposureScore

通過這種標籤策略，您可以通過在整個環境中抑制規則來創建優先級，並忽略需要推遲或忽略的發現，以便專注於高價值的發現。您還可以為具有不同風險因素的不同環境創建不同的規則。例如，您可能希望抑制風險暴露級別較低、位於非生產環境中的資源的發現，並且這些資源的嚴重性級別為：信息、未分類、低或中。您還可以在創建或導出報告時利用資源標籤字段，以過濾掉預期的發現。

在下表中，我們提供了一個 AWS 雲環境的示例，其中有三個主要的帳戶分區：Prod、Dev 和 Sandbox。我們根據可能的風險、暴露級別以及工作負載的關鍵性抑制了不同嚴重性級別的規則。在我們的示例中，我們使用了 1、2 和 3 的 RiskExposureScore 分數，分別對應於低、中和高。換句話說，RiskExposureScore 1 用於不太敏感或幾乎沒有互聯網暴露的工作負載，而 RiskExposureScore 3 用於敏感或關鍵工作負載，這些工作負載具有互聯網暴露、保護較少或由於其配置或不良網絡衛生而具有更高的潛在安全風險。

EnvironmentName
RiskExposureScore
Severity
Suppressed

Prod
1
Medium, Low, Informational, Untriaged
Yes

Prod
2
Low, Informational, Untriaged
Yes

Prod
3
Informational, Untriaged
Yes

Dev
1,2
Medium, Low, Informational, Untriaged
Yes

Dev
3
Low, Informational, Untriaged
Yes

Sandbox
1,2
Critical, High, Medium, Low, Informational, Untriaged
Yes

Sandbox
3
High, Medium, Low, Informational, Untriaged
Yes

在這個特定的示例中，我們希望保留 Prod 和 Dev 帳戶中具有高或關鍵嚴重性的漏洞發現，但根據其他資源的風險暴露級別定義不同的抑制規則。我們還希望抑制 Sandbox 帳戶中的大多數漏洞發現，因為這些帳戶中沒有任何關鍵工作負載。您可以將此示例作為配置環境中抑制規則的模型，以根據您的需求優先處理漏洞發現。還請注意，您可以在進行修復時更改、修改或重新評估您的抑制規則，並且這是一個持續過程的最佳實踐。

最佳實踐 #6：將 Amazon Inspector 與 AWS Security Hub 整合

您可以將 Amazon Inspector 與 AWS Security Hub 整合，以將 Amazon Inspector 的發現發送到 Security Hub，Security Hub 可以將這些發現納入其對您的安全狀態的分析中。符合抑制規則的 Amazon Inspector 發現會自動被抑制，並且不會出現在 Security Hub 控制台中。

最佳實踐 #7：定期重新評估您的抑制規則

保持最新的安全狀態和健康的雲環境的關鍵是隨著威脅形勢的變化維持和調整您的漏洞管理方法。在這裡，我們強調了一些需要關注的做法：

定期重新訪問和重新評估您的抑制漏洞檢測規則。漏洞和威脅不斷演變，因此您之前抑制的內容可能需要重新啟用。
將漏洞管理視為一個持續的、迭代的過程，而不是靜態的程序。定期評估、更新和調整安全控制，以實時應對新興風險。
強調持續監控和響應的重要性，而不僅僅是初步修復。漏洞需要在整個生命周期中全面解決。
在整個組織中培養安全意識和響應文化。每個人都應該參與持續識別和緩解漏洞。
確保您的漏洞管理計劃符合相關的合規或法規要求（例如，PCI-DSS、HIPAA 或 NIST CSF）。

結論

在這篇文章中，我們介紹了如何通過使用抑制規則和應用基於風險的優先級，在整個組織的 AWS 基礎設施中有效地優先處理 Amazon Inspector 的發現。我們還討論了如何使用資源標籤作為優先處理 Amazon Inspector 發現修復的有效策略。欲了解更多與 Amazon Inspector 相關的博客文章，請參閱 AWS 安全博客。

如果您對本文有任何反饋，請在下方的評論區提交評論。