Google Cloud Armor 是一個提供 Web 應用程式防火牆 （web-application firewall, WAF）和分散式阻斷服務攻擊防護（DDoS mitigation）功能的服務。它可以在 Google Cloud 環境中保護 Web 應用程式和服務免受各種潛在威脅的侵害。基本功能除可以提供自動 L3 和 L4 DDoS 防護，還能夠提供 L7 防護。前者是每個主要雲端供應商和網路託管平台都具備的通用功能。但後者有不少創新的功能，像是速率限制、機器人管理和自我適應保護。
透過 Cloud Armor，算是 可以提前制定「主動」的安全策略，事前就對潛在的威脅進行預防，而不是在受到攻擊後才被動制定阻擋規則。此外，「強化資訊安全」，網路上的攻擊手法多種多樣，因為它提供了針對 Open Web Application Security Project（OWASP）的十大 Web 應用程式安全風險的預設保護，包括防止 SQL 資料隱碼攻擊（SQLi）、跨網站指令碼 （XSS, Cross-site scripting）和遠程程式碼執行（RCE）等攻擊，對於非資安專長的我或一般人，這種還是交給專家比起自己亂摸有效率些，以應對未來可能發生的各種攻擊，並減少應對攻擊事件的反應時間，而即時可見度和監控更是整合好 Cloud Looging 排查上也十分方便！
Google Cloud Armor 具有多種功能，本篇會先實作其中的 CUSTOM RULES，撰寫正規化表達式，來阻擋攻擊
案例一：設定 Google Cloud Armor 以阻擋某些國家的 IP
動手實作
Step0. 前置作業
- 環境準備：設定上須有 Load Balance 並在其 Backend Service 後面的應用程序上準備好 Instance Group 作為搭配 和，才能使用 Cloud Armor。
- 模擬封鎖的國別，可以使用 Compute Engine 來模擬，可以先開最小規格，結束後在自行移除！
Step1. 建立政策（Policy）
- 取名：這裡選擇一個合適的名稱（這是最困難的部分），因為名稱之後無法更改或甚至是一些需求增加會作政策的拆分，這只能自己多多實戰累積經驗值。本次實作暫取名為
allow-tw-deny-ru-hk，國家代碼資訊參考《ISO 3166–2》，都是兩碼開頭還滿好記憶的！ - 預設（default action）：如果是公共的應用程式，只想阻止幾個 IP 或國家與地區話，常可以把「允許」設為預設值。對於私有應用程式，則預設可以選擇「拒絕」，他將幫您阻止所有流量進入，接續可以在規則（rules）設定高優先級允許規則，來讓白名單進入。
Step2. 建立規則（Rules）
動作（Action）、回應碼（Response Code）、優先順序（Priority）
- 阻擋規則： 使用 CEL 語法
origin.region_code == <country_code>並在優先順序設定200。
# || 就是 OR 的意思，記得要加，不加會有邏輯上的錯誤
origin.region_code == 'HK' ||
origin.region_code == 'RU' - 允許規則：還記得建立政策當下的預設值嗎？ default rule action 我們設為 Allow，代表流量都會套用 default rule，但也可以先設定一定要允許的流量的規則，這邊我們在設定讓
TW的流量都可以訪問，優先順序 （Priority） 設定為 100，數字越小越優先喔！
- 目標選定：選用 Cloud Armor 要套用的目標，選定好 Load Balancer 的 Backend Service
最後可以得到以下的結果
在進階模式中，可以使用邏輯運算子、基於標頭值的篩選器或引用 WAF 規則來建立更複雜的規則 XD。文檔中有很多例子，熟悉之後還可以使用邏輯運算子透過在單一規則中包含多個條件來降低一些成本（規則跟政策是要錢的啊），例如以下：
'[CN,KP,LT,UA,RU,AF,DZ,MM,CU,EG,GN,IR,IQ,LR,LY,NE,SL,SO,SS,SD,SY,UA,YE]'.contains(origin.region_code)
# instead of
origin.region_code=='CN'||origin.region_code=='SL'Step3. 測試 Cloud Armor 效果
1. 登入事先準備好的香港主機，並查詢 IP 是否確實是在香港
2. 確認原本是看到 Hello World，現在碰到 403 Forbidden 錯誤訊息
用法大概就是這樣，你也也可以允許或封鎖 IP 範圍。如果我只想允許我的 IP，我會將預設規則設定為「拒絕」並只建立一條規則以允許我的 IP 位址（您可以透過 curl ifconfig.me 呼叫 來取得 IP）
Step4. 看一下計價方式，在評估看有否要刪除剛實作完的政策與規則
如果只是實驗性質，建議先都移除，剛剛的設定每月計價下來也是要 $7 USD（1 policy + 2 Rules）
resource.type="https_load_balancer"
jsonPayload.enforcedSecurityPolicy.outcome="DENY"
resource.type:(http_load_balancer) AND jsonPayload.enforcedSecurityPolicy.name:(allow-tw-deny-hk-eu-us)
resource.type="http_load_balancer"
resource.type:(http_load_balancer) AND jsonPayload.enforcedSecurityPolicy.outcome: "DENY"
案例二：有了上面的經驗後，設定白名單、黑名單在 Cloud Armor 也不是件難事！
- 白名單：建立政策後，選擇「拒絕」預設規則（預設阻擋流量進入），在規則這邊在加開允許的白名單設定即可！
- 黑名單：建立政策後，選擇「接受」預設規則（預設接受流量進入），在規則這邊在加開拒絕的黑名單設定即可！
案例三：L7 應用層的保護功能上，外掛節流或根據頻率封鎖對方流量
這個也是非常有用的 L7 外掛的保護功能，Action 可以選擇是節流（Throttle）或是根據頻率封鎖（rate-based-ban），規則上會計算行你訂定的 IP 位置的發送請求數量。
- 節流（Throttle）
當請求數量再次低於時間間隔允許的限制時，用戶可以繼續發出新的請求並得到回應，設定畫面如下
訪問太多次則會發生 Throttle 的狀況！
範例程式碼參考
gcloud compute security-policies rules update 99 --project=project-id \
--action=throttle --security-policy= armor-demo\
--expression=origin.region_code==\'TW\'
--description=TW\ \限\速- 根據頻率封鎖（rate-based-ban）
如果在最近的 60 秒內（rate-limit-threshold-interval-sec）訪問的數量超過了 100 次（rate-limit-threshold-count），則以下請求將被拒絕並返回 404 的狀態碼（exceed-action），還可以在一定時間內（ban-duration-sec），例如 300 秒內阻止對方發出新的請求過來。
提供以下 sample 寫法
gcloud beta compute security-policies rules create 700 \
--security-policy my-security-policy \
--src-ip-ranges="100.0.0.0/24" \
--action=throttle \
--rate-limit-threshold-count=100 \
--rate-limit-threshold-interval-sec=60 \
--conform-action=allow \
--exceed-action=deny-404 \
--enforce-on-key=IP其他功能還包含了
- 預定義規則種類（Preconfigured Rules）
預定義規則用於應對常見的網路攻擊和漏洞，這些規則由經驗豐富的安全專家創建並由 Google Cloud 提供，目的在捕獲和阻止特定類型的攻擊，像是用於檢測和阻止諸如 SQL注入、跨站腳本攻擊（XSS）、拒絕服務攻擊（DDoS）等常見攻擊類型，都可以直接使用，不需要您自己編寫正規表示式或其他自訂規則。 - 機器人管理與 reCAPTCHA Enterprise 整合
您可以使用機器人管理透過向非人類訪客提供 reCAPTCHA 挑戰來阻止他們。如果您懷疑您的網站可能受到網頁抓取（常見情況包括電子商務、新聞網站、招聘網站等），這非常有用，使用場景請點這裡。 - 自我適應保護（Adaptive-Protection）
使用機器學習模型自動偵測大量第 7 層 DDoS 攻擊，這些模型可偵測異常活動並發出警報，產生簽章以記錄潛在攻擊，並產生自訂 Google Cloud Armor WAF 規則，使用場景請點這裡
Google Cloud Armor 算是透過自定義（ Custom Rules）的安全策略與資安專提供的預定義規則種類（Preconfigured Rules）達到資安保護的概念，很多時候因不熟悉攻擊行為以致於無法寫出適合的防守規則，可以根據您的特定需求來選擇使用預訂規則、自訂規則，或二者結合，來增加對應用程式和服務的安全保護，儘量在第一時間就先堆好保壘防禦未來的攻擊行為，因為 Hacker 永遠都會在。
