My Awesome Project

Appearance

Chapter 60: Cấu Hình Cloud Armor WAF Nâng Cao ​

Giới Thiệu ​

Cloud Armor thường bị hiểu nhầm là "một cái WAF của Google" — bật lên, gắn OWASP ruleset vào là xong. Cách hiểu đó bỏ sót toàn bộ phần quan trọng: Cloud Armor không phải một appliance đứng trước backend của bạn, mà là một lớp policy được thực thi ngay trên Google Front End (GFE) — cùng lớp hạ tầng terminate TLS và load balancing toàn cầu của Google. Hiểu sai vị trí thực thi này dẫn tới hàng loạt quyết định sai: đặt rule sai thứ tự, kỳ vọng rate limit chính xác tuyệt đối, tin rằng verbose logging là miễn phí về mặt bảo mật, hoặc nghĩ rằng bật OWASP CRS ở sensitivity cao là "an toàn hơn".

Tài liệu này tập trung vào internal model — Cloud Armor thực sự vận hành thế nào bên dưới lớp abstraction:

  • Vị trí thực thi (enforcement point): policy chạy ở GFE tại các Point of Presence (PoP) gần nguồn traffic, trước khi request tới backend. Điều này quyết định cái gì Cloud Armor thấy được, cái gì không, và vì sao một số action (redirect, reCAPTCHA) khả thi còn body inspection thì bị giới hạn 8 KB/64 KB.
  • Evaluation pipeline: rule được duyệt theo priority (số nhỏ = ưu tiên cao), first-match-wins, default rule ở 2147483647. Đây là nơi hầu hết lỗi cấu hình sinh ra — không phải ở nội dung rule mà ở thứ tự rule.
  • WAF không phải là "chặn tấn công", mà là signature matching trên ModSecurity CRS với các sensitivity level tương ứng paranoia level. Hiểu sai bản chất này là gốc rễ của mọi false positive.
  • Rate limiting là xấp xỉ và per-region, per-GFE — không phải bộ đếm toàn cục chính xác. Kỳ vọng sai về tính chính xác dẫn tới threshold vô dụng.
  • Adaptive Protection là ML baseline per-backend-service, không phải rule tĩnh — nó phát hiện độ lệch so với hành vi bình thường, nên chỉ có giá trị khi backend có đủ traffic để học baseline.

Trọng tâm: ~70% tài liệu dành cho cơ chế và mental model. Pattern, ví dụ, anti-pattern chỉ xuất hiện khi chúng soi sáng một điểm cơ chế cụ thể.

Điều Kiện Tiên Quyết ​

Bạn nên đã quen thuộc với:

  • Chapter 20 — Cloud Load Balancing, Google Front End, kiến trúc global LB (nền tảng để hiểu enforcement point của Cloud Armor)
  • Chapter 27 — Network security foundation, các lớp phòng thủ, firewall
  • Kiến thức nền về HTTP, TLS, OWASP Top 10, và mô hình tấn công web (SQLi, XSS, LFI/RFI, RCE)
  • Khái niệm DDoS L3/L4 vs L7

Cấu Trúc Tài Liệu ​

Phần 1: Kiến Thức Cốt Lõi — Cơ Chế Nội Tại ​

  1. Security Policy Internal Model & Evaluation Pipeline — Vị trí thực thi ở GFE, các loại policy (backend / edge / network edge / internal), cấu trúc rule, priority và thứ tự duyệt, các action (allow/deny/throttle/rate-based-ban/redirect/reCAPTCHA), preview mode, giới hạn body inspection, cách policy attach vào backend service.

  2. Preconfigured WAF Rules: OWASP ModSecurity CRS — ModSecurity Core Rule Set (CRS 4.22), cơ chế signature matching, sensitivity level (0–4) và quan hệ với paranoia level, evaluatePreconfiguredWaf(), opt-in/opt-out signature, request field exclusion, và triết lý tuning để giảm false positive.

  3. Custom Rules Match Language (CEL) — Ngôn ngữ match dựa trên CEL, các attribute (origin.ip, origin.region_code, origin.asn, request.headers, JA3/JA4 fingerprint), operator và function (inIpRange(), .matches() RE2, has()), evaluateThreatIntelligence(), evaluateAddressGroup(), giới hạn 5 subexpression.

Phần 2: Kiểm Soát Volumetric & L7 Abuse ​

  1. Rate Limiting: Throttle & Rate-Based Ban — Cơ chế bộ đếm token per-key, throttle vs rate_based_ban, enforce_on_key (IP, HTTP-HEADER, HTTP-COOKIE, XFF-IP, REGION-CODE, JA4…), threshold, ban_duration_sec, và vì sao rate limit là xấp xỉ và per-region.

  2. Adaptive Protection & Always-On DDoS Defense — ML baseline per-backend-service, cấu trúc alert (confidence, headerSignatures, suggestedRule), manual vs evaluateAdaptiveProtectionAutoDeploy(), always-on L3/L4 DDoS ở lớp edge, network edge security policy.

Phần 3: Managed Intelligence & Edge Operations ​

  1. Managed Rules, Threat Intelligence & Named IP Lists — Cloud Armor Standard vs Enterprise (Paygo/Annual), automatic-updating managed protection, evaluateThreatIntelligence() categories, named IP address lists (nhà cung cấp bên thứ ba), address groups, và mô hình cập nhật tự động.

  2. Logging, Field Masking & Signed Cookies — Cấu trúc request log (enforcedSecurityPolicy, previewSecurityPolicy), verbose logging và rủi ro rò rỉ dữ liệu nhạy cảm (matchedFieldValue prefix 16 byte), chiến lược bảo vệ dữ liệu trong log, và signed cookies/signed URLs cho edge access trên custom domain.

Mục Tiêu Học Tập ​

Sau khi đọc chapter này, bạn có thể:

  1. Reason chính xác về evaluation order — dự đoán được request nào khớp rule nào, vì sao, và debug được "vì sao rule của tôi không có tác dụng".
  2. Tune WAF để giảm false positive mà không mở lỗ hổng — hiểu sensitivity, exclusion, opt-out ở mức bản chất chứ không phải thử-sai.
  3. Thiết kế rate limiting phù hợp với bản chất xấp xỉ, per-region của bộ đếm, chọn đúng enforce_on_key.
  4. Vận hành Adaptive Protection đúng cách: biết khi nào nó vô dụng (traffic thấp), biết đọc alert, và quyết định auto-deploy hay không.
  5. Đưa ra quyết định tier (Standard vs Enterprise) dựa trên nhu cầu thật, và cấu hình logging an toàn về mặt dữ liệu nhạy cảm.

Điều Không Nằm Trong Scope ​

  • reCAPTCHA Enterprise internals — Cloud Armor tích hợp qua action redirect(GOOGLE_RECAPTCHA), nhưng cơ chế scoring của reCAPTCHA là chủ đề riêng.
  • Cloud CDN caching mechanics — chỉ đề cập signed cookies ở góc độ edge access control.
  • Load balancer setup chi tiết — xem Chapter 20.
  • VPC firewall / hierarchical firewall policy — xem Chapter 27; Cloud Armor hoạt động ở L7 edge, khác lớp với VPC firewall.

Tham Khảo Chính Thức ​