My Awesome Project

Appearance

Managed Rules, Threat Intelligence & Named IP Lists ​

Why this matters in production ​

Ba file trước tập trung vào rule bạn viết và tune. Nhưng một phần lớn giá trị của Cloud Armor đến từ intelligence do Google duy trì và tự cập nhật — thứ bạn không thể tự xây và bảo trì ở quy mô đó: danh sách IP độc hại cập nhật liên tục, named IP list của các nhà cung cấp CDN/proxy, và managed DDoS protection tự thích ứng.

Điểm cốt lõi cần hiểu: các managed feature này khác về mô hình bảo trì so với rule tĩnh. Một rule IP allowlist bạn viết sẽ lỗi thời ngay khi bạn viết xong — IP thay đổi. Threat intelligence và named IP list được Google cập nhật tự động, nên rule dựa trên chúng vẫn đúng theo thời gian mà không cần bạn can thiệp. Không hiểu ranh giới "cái gì tự cập nhật vs cái gì bạn phải bảo trì", bạn hoặc tự viết lại thứ Google đã cung cấp, hoặc để rule tĩnh mục ruỗng.

Và phần lớn intelligence này nằm sau tier Enterprise — nên hiểu rõ tier là điều kiện để quyết định kiến trúc.

Internal model — cơ chế vận hành ​

Hai tier: Standard vs Enterprise ​

Cloud Armor có hai tier, khác nhau về cái gì được bao gồm và mô hình tính phí:

Cloud Armor Standard — pay-as-you-go, tính phí theo policy, rule, và request. Bao gồm:

  • Always-on L3/L4 DDoS defense (xem file 05).
  • Preconfigured WAF rules (OWASP CRS — file 02).
  • Custom rules, rate limiting cơ bản.

Cloud Armor Enterprise — có hai biến thể:

  • Enterprise Paygo: ~$200/tháng mỗi project + ~$200/tháng mỗi protected resource bổ sung, không cam kết. Bao gồm tất cả của Standard cộng WAF usage được bundled, Adaptive Protection, Google Threat Intelligence, advanced network DDoS protection, hierarchical security policies, address groups, network edge security policies.
  • Enterprise Annual: cam kết 12 tháng (~$3000/tháng mỗi billing account + ~$30/tháng mỗi protected resource sau 100 resource đầu). Có tất cả của Paygo cộng DDoS bill protection (bảo vệ hóa đơn khỏi chi phí do attack gây ra) và DDoS response team (đội hỗ trợ khi bị tấn công, kèm điều kiện eligibility).

Mental model về tier: Standard cho bạn công cụ tự làm (WAF, custom rule, rate limit, L3/L4 baseline). Enterprise thêm intelligence và tự động hóa do Google duy trì (threat intel, Adaptive Protection ML, address groups, DDoS bill protection). Nếu threat model của bạn nghiêm túc về L7 DDoS hoặc bot phức tạp, phần lớn công cụ đắt giá nhất nằm ở Enterprise. Con số giá có thể thay đổi — luôn kiểm tra trang pricing hiện hành.

Threat Intelligence: evaluateThreatIntelligence() ​

Threat Intelligence là danh sách IP/danh mục do Google duy trì và cập nhật liên tục, gọi qua function evaluateThreatIntelligence() trong match expression. Thay vì bạn tự thu thập và cập nhật danh sách IP độc hại (bất khả thi ở quy mô và độ tươi), bạn tham chiếu danh mục của Google:

evaluateThreatIntelligence('iplist-known-malicious-ips')

Các danh mục điển hình:

  • iplist-known-malicious-ips — IP có lịch sử độc hại đã biết.
  • iplist-tor-exit-nodes — các Tor exit node (traffic ẩn danh qua Tor).
  • iplist-vpn-providers — dải IP của nhà cung cấp VPN thương mại.
  • iplist-anon-proxies — anonymous proxy.
  • iplist-crawlers — crawler đã biết.
  • iplist-public-clouds — dải IP của các public cloud (traffic từ VM cloud, thường là bot/tool chứ không phải browser người dùng).
  • iplist-search-engines-crawlers — crawler của search engine hợp lệ (Googlebot, Bingbot…) — thường dùng để allow chứ không deny.

Cơ chế cập nhật: danh sách được Google refresh tự động ở backend. Rule evaluateThreatIntelligence('iplist-tor-exit-nodes') của bạn hôm nay và sáu tháng sau đều phản ánh danh sách Tor exit node hiện tại, dù danh sách đó thay đổi hàng ngày. Đây là khác biệt bản chất với một rule IP tĩnh — bạn tham chiếu một nguồn sống, không phải một snapshot.

Pattern quan trọng: kết hợp threat intel với action phù hợp ngữ cảnh. iplist-search-engines-crawlers thường dùng với allow ở priority thấp (để không rate-limit nhầm Googlebot). iplist-known-malicious-ips dùng với deny. iplist-public-clouds/iplist-tor-exit-nodes tùy app — chặn với site cho người dùng cuối, cho phép với API B2B.

Named IP Address Lists (bên thứ ba) ​

Đây là các preconfigured named IP list của nhà cung cấp bên thứ ba — ví dụ dải IP của các CDN/security provider (Fastly, Cloudflare, Imperva…). Nếu kiến trúc của bạn có một CDN bên thứ ba đứng trước Google load balancer, traffic hợp lệ sẽ đến từ dải IP của CDN đó. Named IP list cho phép bạn allowlist chính xác các dải này mà không phải tự tra cứu và cập nhật (các provider thay đổi dải IP theo thời gian).

Cơ chế giống threat intelligence: danh sách được duy trì và cập nhật, bạn chỉ tham chiếu tên. Điều này giải quyết một bài toán bảo trì thực tế: nếu bạn hardcode dải IP của Cloudflare hôm nay, một ngày nào đó Cloudflare thêm dải mới và traffic hợp lệ qua dải đó bị bạn chặn nhầm.

Address Groups (Enterprise) ​

Address groups là cơ chế quản lý danh sách IP của chính bạn tập trung, tham chiếu qua evaluateAddressGroup(). Thay vì nhét hàng trăm IP vào match expression của nhiều rule (khó bảo trì, đụng giới hạn độ dài), bạn định nghĩa address group một lần và tham chiếu nó:

evaluateAddressGroup('projects/PROJECT/locations/global/addressGroups/partner-ips')

Cập nhật address group ở một nơi → mọi rule tham chiếu nó tự cập nhật. Đây là DRY cho IP management — đặc biệt giá trị khi cùng một allowlist đối tác dùng ở nhiều policy.

Hierarchical security policies (Enterprise) ​

Cho phép định nghĩa policy ở cấp organization/folder và áp dụng xuống nhiều project — tương tự org policy. Một security team trung tâm có thể enforce baseline (ví dụ chặn Tor, chặn known-malicious) trên toàn tổ chức, trong khi team ứng dụng vẫn thêm rule riêng ở cấp project. Điều này giải quyết bài toán governance ở scale nhiều project.

Cơ chế đánh giá quan trọng: policy được tổ chức thành cây, và có khái niệm thứ tự đánh giá giữa các cấp. Rule ở policy cấp cao hơn (org/folder) được đánh giá cùng với rule cấp project theo một thứ tự xác định — không phải "cấp cao ghi đè hoàn toàn cấp thấp". Điều này cho phép mô hình: security team đặt các rule bắt buộc (deny known-malicious) mà application team không thể vô hiệu hóa, trong khi vẫn để application team tự do thêm rule đặc thù. Khi thiết kế hierarchical policy, phải reason về first-match-wins xuyên các cấp, không chỉ trong một policy — đây là mở rộng trực tiếp của mô hình evaluation ở file 01.

DDoS bill protection & response team (Enterprise Annual) ​

Hai tính năng của tier Annual đáng hiểu về mặt mô hình rủi ro tài chính, không chỉ kỹ thuật:

  • DDoS bill protection: khi bị tấn công, traffic tăng vọt có thể đẩy chi phí (LB, egress, request processing) lên rất cao — attacker gây thiệt hại qua hóa đơn chứ không chỉ qua downtime (gọi là "economic denial of service"). DDoS bill protection cấp credit bù cho các chi phí tăng đột biến do attack đã xác nhận gây ra, biến một rủi ro tài chính không giới hạn thành có giới hạn. Đây là lý do quan trọng khiến tổ chức có bề mặt tấn công lớn chọn Annual.
  • DDoS response team: quyền truy cập đội chuyên gia của Google trong lúc bị tấn công (kèm điều kiện eligibility). Giá trị nằm ở việc có người hiểu sâu hạ tầng edge hỗ trợ mitigate attack quy mô lớn theo thời gian thực, thay vì team bạn tự mò.

Mental model quyết định: nếu downtime/economic-DoS là rủi ro tồn vong với business (fintech, e-commerce lớn, media sự kiện trực tiếp), chi phí Annual + bill protection là bảo hiểm hợp lý. Với workload nhỏ hơn, Paygo (vẫn có Adaptive Protection + threat intel) thường đủ.

Mô hình cập nhật tự động: vì sao "managed" quan trọng ở scale ​

Sợi chỉ chung của threat intelligence, named IP list, và managed DDoS là mô hình cập nhật tự động phía Google. Điều này giải quyết một vấn đề cơ chế mà rule tĩnh không thể: độ tươi của dữ liệu ở quy mô toàn cầu. Danh sách Tor exit node thay đổi hàng giờ; dải IP của một CDN provider thay đổi theo tháng; IP độc hại mới xuất hiện liên tục. Không tổ chức đơn lẻ nào có thể thu thập và cập nhật các nguồn này với độ tươi và độ phủ như Google — vốn quan sát traffic của toàn bộ hạ tầng Google.

Hệ quả kiến trúc: khi bạn tham chiếu evaluateThreatIntelligence(...) hay một named list, bạn đang outsource việc bảo trì dữ liệu cho Google. Rule của bạn trở thành khai báo ý định ("chặn Tor") thay vì snapshot dữ liệu ("chặn các IP này") — và ý định vẫn đúng khi dữ liệu bên dưới thay đổi. Đây là khác biệt bản chất giữa "managed" và "self-managed", và là lý do cốt lõi để chọn tier có các tính năng này khi threat model đòi hỏi.

Constraints, trade-offs & failure modes ​

Phần lớn intelligence nằm sau Enterprise. Threat intelligence, address groups, Adaptive Protection, advanced network DDoS đều là Enterprise. Nếu chỉ dùng Standard, bạn có WAF + custom rule + rate limit + L3/L4 baseline — mạnh, nhưng thiếu lớp intelligence tự cập nhật. Quyết định tier là quyết định bạn tự bảo trì bao nhiêu.

Threat intel là xác suất, không tuyệt đối. iplist-known-malicious-ips không hoàn hảo — có false positive (IP từng độc hại nay đã sạch, dùng chung NAT) và false negative (IP mới chưa vào danh sách). Dùng nó như một tín hiệu trong tổ hợp, không phải phán quyết tuyệt đối. Cân nhắc preview mode trước khi deny cứng theo threat intel.

Chặn iplist-public-clouds/VPN có thể chặn user hợp lệ. Nhiều người dùng chính đáng dùng VPN vì lý do riêng tư; nhiều tích hợp B2B gọi từ VM cloud. Deny mù các danh mục này có thể cắt traffic hợp lệ. Quyết định theo bản chất audience của app, không mặc định chặn.

Failure mode — hardcode IP thay vì dùng named list/threat intel: team tự maintain một allowlist IP CDN hoặc denylist IP xấu bằng tay. Nó lỗi thời âm thầm: provider đổi dải IP → traffic hợp lệ bị chặn; hoặc denylist không theo kịp IP mới. Đây chính là bài toán mà named list và threat intel giải quyết bằng cập nhật tự động — tự làm lại là lãng phí và kém an toàn hơn.

Failure mode — allow search-engine crawler sai priority: muốn cho Googlebot qua nhưng đặt rule allow iplist-search-engines-crawlers ở priority cao hơn (số lớn hơn) một rule rate-limit → theo first-match-wins (file 01), rate-limit khớp trước và chặn nhầm crawler. Allow crawler phải ở priority thấp.

Production pattern: layered intelligence cho public web app ​

yaml
- priority: 200   # allow search engine crawler hợp lệ (trước mọi rate-limit)
  match: evaluateThreatIntelligence('iplist-search-engines-crawlers')
  action: allow
- priority: 300   # allow dải IP CDN đối tác (named list, tự cập nhật)
  match: evaluateAddressGroup('.../addressGroups/cdn-partner')
  action: allow
- priority: 800   # deny Tor exit node + known malicious (threat intel, tự cập nhật)
  match: evaluateThreatIntelligence('iplist-known-malicious-ips')
        || evaluateThreatIntelligence('iplist-tor-exit-nodes')
  action: deny(403)
- priority: 2000  # WAF...
- priority: 2147483647
  action: allow

Bài học cơ chế: các rule ở đây tham chiếu nguồn sống do Google duy trì, nên chúng đúng theo thời gian mà không cần bảo trì. Thứ tự priority phản ánh nguyên tắc allow ngoại lệ (crawler, partner) trước, deny nguồn xấu sau, WAF cuối — đúng với first-match-wins.

Official references ​