AWS WAF 大規模控管

眾多擁有多個團隊開發及操作自己的 Web 應用程式或 API 的大型組織，紛紛採用工具與流程來提高跨團隊安全控制的一致性，以避免暴露保護薄弱或沒有保護的端點。AWS Firewall Manager 是組織可用於大規模管理 AWS WAF 及 Shield Advanced 部署的工具。

Firewall Manager 可讓您定義 AWS WAF 或 Shield Advanced 政策，這些政策會自動部署在公開資源 (例如 CloudFront 發行版、ALB 或 API 閘道) 之間。一項政策包括：

• 用於定義其適用方面的範圍：哪種類型的資源 (CloudFront、ALB 等)？包含或排除具有特定標籤的資源？包含或排除哪些帳戶或組織單位？
• 用於定義要套用哪些 WAF 規則群組的規則：是否要集中啟用記錄，以及是否新增 Shield Advanced 防護。
• 用於定義在政策範圍內找到資源時該如何處理的動作。例如，您可以自動執行政策規則，或直接回報。在初始的 Firewall Manager 部署，建議在不自動修復的情況啟動，以識別需要手動處理的資源，同時將對現有應用程式的影響降至最低。當達到更高的可信度時，您可以將 Firewall Manager 切換為自動修復。

若要使用 Firewall Manager，請先考慮其先決條件。請注意，AWS Config 是 Firewall Manager 的先決條件之一。若要最佳化 AWS Config 的成本，如果僅啟用 Firewall Manager，請將要記錄的資源類型設定限制為案例的相關資源 (例如 WAF、CloudFront Distribution、負載平衡器等等)。另請注意，政策是區域建構模組 (例如，您需要 CloudFront 的全域政策，以及您擁有區域資源 (例如 ALB 與 API 閘道) 的每個區域都需要區域政策)。考慮此 AWS 解決方案，以便在 AWS Organizations 部署 Firewall Manager 政策

當您建立 WAF 政策時，Firewall Manager 會使用策略範圍內 AWS 帳戶的策略 WAF 規則部署 WAF WebACL。在 WAF 政策，您可以定義兩種類型的規則群組，這些規則群組由 Firewall Manager 加入至已部署的 WebACL：

• 第一個規則群組，將在任何其他規則之前進行評估。
• 最後一個規則群組，該群組將在結束時進行評估。

這可讓中央安全性團隊管理整個組織的通用規則群組，同時可讓應用程式團隊在第一個及最後一個通用規則群組之間新增與其應用程式相關的自訂規則。由於 AWS WAF 的規則是按順序評估，因此會在任何其他規則之前先評估第一個通用規則群組，接著是應用程式團隊建立的規則，最後是最後一個通用規則群組。

您可以建置 CI/CD 管道，以更新管理 AWS 帳戶 AWS WAF 策略的常見 WAF 規則群組，然後在幾分鐘內由 Firewall Manager 在整個組織部署這些規則。請參閱此部落格，了解 OLX 如何使用 CI/CD 管道與中央記錄系統部署中央 WAF 政策。

Firewall Manager 是一種靈活的工具，可讓您根據組織的需求建立各種安全治理政策。在任何集中式安全性治理，您都需要在集中強制執行規則以提高保護層級的程度，與要處理由集中部署的通用規則引起的誤報程度之間進行權衡。

如果您有高度自主化的應用程式團隊，並且想要避免管理誤報，請建立一個解決重大威脅的單一中央 WAF 政策。例如，您可以根據具有高臨界值的費率限制，結合高可信度的惡意 IP 信譽清單，以及禁運國家的地理封鎖規則來建立 WAF 規則。您也可以啟用 Shield Advanced，並啟用自動應用程式層 DDoS 緩解。這些規則的誤報率往往非常低，但能有效防止 HTTP 洪水攻擊。此外，當發現嚴重及高影響的零日漏洞時，您可以使用部署的 WAF 通用規則群組集中套用緩解措施。

建議您為應用程式團隊建立內部 Wiki，並提供在 WebACL 新增與應用程式相關的自訂 WAF 規則的最佳做法指南。例如，如果他們的應用程式容易受到 SQLi 與 XSS 攻擊，請指導他們增加防護。

如果您想將中央安全覆蓋範圍擴大到更廣泛的威脅，請強化中央通用規則群組，但讓應用程式團隊能夠自主管理誤報。若要實作此 WAF 治理模式，請在計數模式將您的通用規則放入 WAF 政策的第一個規則群組。這些規則只會發出標籤，您可以在 WAF 政策的最後一個規則群組使用這些標籤來封鎖符合這些標籤的請求。

如果您的應用程式團隊遇到誤報，他們可以使用規則發出的標籤建立排除規則。為了透過範例來說明這一點，請考慮以下案例：用於防範 SQLi 的 Amazon Managed Rules (AMR) 以計數模式新增至第一個規則群組。在最後一個規則群組，規則會封鎖使用上述 AMR 發出的標籤 label_matched=”SQLi_BODY” 的請求。如果 AMR 在特定網址 (url=”/form1”) 的應用程式引入誤報，應用程式團隊可以在 WebACL 建立排除規則，以減少此誤報 (例如： IF url=”/form1” AND label_matched=”SQLi_BODY” then ALLOW)。允許規則動作正在終止，這代表 AWS WAF 將停止評估後續的封鎖規則。

若要在不影響現有應用程式的情況對此政策進行變更，請考慮建立此政策的複本，以供應用程式團隊在暫存環境使用。這兩個政策都需要具有相互排除的範圍。例如，生產政策適用於所有 CloudFront 發行版，但有暫存標記的除外，而暫存政策則則適用於所有有暫存標記的 CloudFront 發行版。對於大多數更新，您可以先將其推出至暫存政策，然後使用 SNS 主題通知所有應用程式團隊。一旦收到變更通知，應用程式團隊便會在其暫存環境測試新的政策版本 (可自動執行)，並在必要時管理誤報。然後，經同意的延遲後，中央團隊將變更傳播到生產政策。一週無法完成的重要更新 (例如針對 Log4j CVE 的防護) 可立即套用，但會暫時出現一些誤報，直到應用程式團隊處理異常。

如果您想要強制套用一致的安全基準，同時仍允許帳戶管理員進行某些自訂。本文概述設計和實作集中管理的安全基準政策的步驟。它還詳細說明了測試和部署政策的最佳實務。

如果您的要求與以前相同，但希望減少應用程式團隊強化應用程式安全性的認知負載，請考慮為組織存在的不同應用程式類型建立策略目錄。例如，您可以使用包含兩個政策的目錄：

• 第一個政策：建議保護基於 WordPress 的應用程式
• 第二個政策：建議使用 SQL 資料庫保護 PHP 應用程式。您可以建立此政策的兩個版本，並設定不同的封鎖敏感度等級。透過這種方式，應用程式團隊可以選擇符合其安全要求 (狂野等級) 的應用程式，以及管理誤報意願的方案。
  
  

每個政策的範圍由特定標籤定義 (例如，第一個政策為 wordpress，第二個政策為 LAMP_HIGH/LAMP_LOW)。應用程式團隊會查閱可用政策目錄，並將所需政策的標籤套用至其資源。Firewall Manager 會自動將 WAF WebACL 與其資源關聯。

請注意，使用此方法，您可以管理誤報，並以與前一節所述相同的方式進行變更。

在應用程式層級，您可以根據應用程式的預期，使用自訂訊號來識別異常行為。例如，您可能希望使用者按特定順序瀏覽您的應用程式，或者您不可能希望使用者根據其註冊地址從/到某些國家/地區訂購某些商品。使用此類訊號，您可以使用 AWS WAF 自動化回應，例如透過封鎖或挑戰使用來自具有可疑應用程式層級行為的 IP 的 CAPTCHA 要求。若要開始使用基於應用程式訊號的 WAF 自動化概念，請考慮此 AWS 解決方案的範例。

進階自動化包括：

• 使用 Cognito 在登入/註冊過程發出的高風險事件。
• 使用 Fraud Detector 識別的高風險事件。Fraud Detector 使用機器學習 (ML) 以及 Amazon Web Services (AWS) 與 Amazon.com 超過 20 年的詐騙偵測專業知識，自動識別人類和機器人即時執行的潛在詐騙模式。Fraud Detector 可分析應用程式層級的使用者行為，並使用您自己的歷史詐騙資料來訓練、測試及部署適合您使用案例的定制詐騙偵測機器學習模型，藉此偵測詐騙。

如果您希望將 WAF 管理從應用程式團隊完全卸載到中央安全團隊，請為每個應用程式團隊建立專屬政策，其範圍僅適用於其 AWS 帳戶。在這種情況下，您需要為初始設定建立流程，並在應用程式團隊與中央安全團隊之間建立溝通管道，以進行管理誤報等操作。

• 白皮書：實施 AWS WAF 白皮書指南的治理範例
• AWS re:Inforce 2024 講座：Twilio 如何大規模管理 AWS WAF 政策
• 尋找 AWS WAF 交付合作夥伴
• 部落格：AWS 中 Web 應用程式安全治理的作業模式