請按照這些操作說明，排解 Google Cloud Armor 安全性政策的問題。
一般問題
本節說明使用 Cloud Armor 時常見的問題。
偵錯安全性政策
如要進一步瞭解哪些特定事件會觸發預先設定的規則，請參閱「使用要求記錄功能」，然後啟用詳細記錄功能。Cloud Logging 會在記錄中記錄更詳細的資訊，可用於分析及偵錯政策和規則。
找出記錄中遭封鎖的要求並建立關聯
當 Cloud Armor 封鎖全域外部應用程式負載平衡器或傳統版應用程式負載平衡器上的要求時，您可以設定使用 {cloud_trace_id} 變數的自訂回應標頭，將不重複的追蹤 ID 傳回用戶端。接著，您可以使用這個追蹤記錄 ID 在 Logging 中尋找記錄項目，並判斷要求遭到封鎖的原因。
如要在 Logging 中公開追蹤 ID 並找出遭封鎖的要求，請按照下列步驟操作：
在後端服務上，使用
{cloud_trace_id}變數設定自訂回應標頭。舉例來說，下列指令會將X-Cloud-Trace-Id回應標頭新增至後端服務BACKEND_SERVICE_NAME：gcloud compute backend-services update BACKEND_SERVICE_NAME \ --global \ --custom-response-header='X-Cloud-Trace-Id:{cloud_trace_id}'將
BACKEND_SERVICE_NAME替換為後端服務名稱。詳情請參閱「設定自訂回應標頭」。
當 Cloud Armor 安全性政策拒絕要求時，請檢查傳回用戶端的 HTTP 回應標頭，取得
X-Cloud-Trace-Id標頭的 32 個字元十六進位值。在「Logs Explorer」頁面中，使用回應標頭中的追蹤記錄 ID 查詢
trace欄位，找出相符的記錄項目：resource.type="http_load_balancer" trace="projects/PROJECT_ID/traces/TRACE_ID"
更改下列內容：
PROJECT_ID：負載平衡器轉送規則和網址對應所在專案的 IDTRACE_ID：自訂回應標頭中傳回的 32 個字元十六進位追蹤 ID
Cloud Armor 安全性政策中設有拒絕規則，但流量仍獲准通過
如要修正這個問題，請按照下列步驟操作：
請確認 Cloud Armor 安全性政策已附加至目標後端服務。例如，下列指令會說明與後端服務
BACKEND相關聯的所有資料。傳回的結果必須包含與這個後端服務相關聯的 Cloud Armor 安全性政策名稱。gcloud compute backend-services describe BACKEND
將
BACKEND替換為後端服務名稱。查看 HTTP(S) 記錄，判斷流量符合哪些政策和規則，以及相關聯的動作。如要查看記錄，請使用 Logging。
以下是允許要求的記錄範例，其中醒目顯示了相關欄位。檢查下列欄位，確認與您設定的流量拒絕規則相符：
configuredAction必須與規則中設定的動作相符。name必須與附加至這項後端服務的 Cloud Armor 安全性政策名稱相符。outcome必須與configuredAction相符。priority必須與規則的優先順序編號相符。
httpRequest: remoteIp: 104.133.0.95 requestMethod: GET requestSize: '801' requestUrl: http://74.125.67.38/ responseSize: '246' serverIp: 10.132.0.4 status: 200 userAgent: curl/7.35.0 insertId: ajvis5ev4i60 internalId: projectNumber: '895280006100' jsonPayload: '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry enforcedSecurityPolicy: configuredAction: ACCEPT name: mydev-policy-log-test1 outcome: ACCEPT priority: 2147483647 statusDetails: response_sent_by_backend logName: projects/mydev-staging/logs/requests resource: labels: backend_service_name: BACKEND_SERVICE_NAME forwarding_rule_name: FORWARDING_RULE_NAME project_id: PROJECT_ID target_proxy_name: TARGET_HTTP_PROXY_NAME url_map_name: URL_MAP_NAME zone: global type: http_load_balancer severity: INFO timestamp: '2017-04-18T18:57:05.845960288Z'這項輸出內容包含下列值：
BACKEND_SERVICE_NAME：後端服務名稱FORWARDING_RULE_NAME：轉送規則的名稱PROJECT_ID：專案 IDTARGET_HTTP_PROXY_NAME：目標 HTTP Proxy 的名稱URL_MAP_NAME：網址對應的名稱
請檢查規則階層，確保比對到正確的規則。優先順序較高且含有允許動作的規則，可能與您的流量相符。在 Google Cloud CLI 中，對
security-policies使用describe指令，查看 Cloud Armor 安全性政策的內容。舉例來說，下列範例顯示優先順序較高的允許規則 (優先順序 100) 如何比對來自 1.2.3.4 IP 位址的流量，防止優先順序較低的拒絕規則 (優先順序 200) 觸發並封鎖流量。
gcloud compute security-policies describe POLICY_NAME
將
POLICY_NAME替換為安全性政策名稱。輸出結果會與下列內容相似：
creationTimestamp: '2017-04-18T14:47:58.045-07:00 description: '' fingerprint: Yu5spBjdoC0= id: '2560355463394441057' kind: compute#securityPolicy name: POLICY_NAME rules: -action: allow description: allow high priority rule kind: compute#securityPolicyRule match: srcIpRanges: -'1.2.3.4/32' preview: false priority: 100 -action: deny description: deny lower priority rule kind: compute#securityPolicyRule match: srcIpRanges: -'1.2.3.0/24 preview: false priority: 200 -action: deny description: default rule kind: compute#securityPolicyRule match: srcIpRanges: -'*' preview: false priority: 2147483647 selfLink: http://www.googleapis.com/compute/v1/projects/bigclustertestdev0-devconsole/global/securityPolicies/sp
預先設定的規則傳回偽陽性結果
XSS 和 SQLi 偵測功能會根據 HTTP 要求標頭和其他第 7 層參數，進行靜態簽章比對。這些規則運算式模式容易出現偽陽性。您可以在預覽模式中使用預先設定的規則，偵測 XSS 和 SQLi，然後檢查記錄檔是否有任何偽陽性。
如果發現偽陽性，可以將流量內容與 OWASP CRS 規則進行比較。如果您是從舊版 CRS 遷移，請參閱「WAF 規則版本比較」，查看規則變更和重新命名的清單。如果規則無效或不相關，請使用 evaluatePreconfiguredWaf 運算式停用規則，並在 exclude ID list 引數中指定規則 ID。
查看記錄並移除所有偽陽性後，請停用預覽模式。
如要在預先發布版模式中新增預先設定的規則，請按照下列步驟操作：
在預覽模式中，使用預先設定的運算式建立安全性政策：
gcloud compute security-policies rules create 1000 --security-policy POLICY_NAME --expression "evaluatePreconfiguredWaf('xss-stable')" --action deny-403 --preview將
POLICY_NAME替換為安全性政策名稱。查看 HTTP(S) 記錄中的 HTTP 要求欄位，例如
url和cookie。舉例來說，requestUrl與 OWASP CRS 規則 ID 941180 相比，結果為正：httpRequest: remoteIp: 104.133.0.95 requestMethod: GET requestSize: '801' requestUrl: http://74.125.67.38/foo?document.cookie=1010" responseSize: '246' serverIp: 10.132.0.4 status: 200 userAgent: curl/7.35.0 insertId: ajvis5ev4i60 internalId: projectNumber: '895280006100' jsonPayload: '@type': type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry enforcedSecurityPolicy: configuredAction: ACCEPT name: POLICY_NAME outcome: ACCEPT priority: 2147483647 preconfiguredExprIds: [ 'owasp-crs-v042200-id941180-xss' ] statusDetails: response_sent_by_backend logName: projects/mydev-staging/logs/requests resource: labels: backend_service_name: BACKEND_SERVICE forwarding_rule_name: mydev-forwarding-rule project_id: mydev-staging target_proxy_name: mydev-target-http-proxy url_map_name: mydev-url-map zone: global type: http_load_balancer severity: INFO timestamp: '2017-04-18T18:57:05.845960288Z'
這份記錄包含下列值：
POLICY_NAME：安全性政策名稱BACKEND_SERVICE：後端服務名稱
更新 Cloud Armor 安全性政策中的規則，排除 OWASP CRS 規則 ID 941180：
gcloud compute security-policies rules update 1000 \ --security-policy POLICY_NAME \ --expression "evaluatePreconfiguredWaf('xss-v422-stable', ['owasp-crs-v042200-id941180-xss'])" \ --action deny-403 \ --preview將
POLICY_NAME替換為安全性政策名稱。再次查看記錄，然後停用預覽模式，即可實施規則。
系統不會封鎖或拒絕簽章遭拒的用戶端
如果您將 Cloud Armor 與 Cloud CDN 搭配使用，系統只會針對動態內容、快取失敗，或其他目標為 CDN 原始伺服器的要求，強制執行安全性政策。即使下游 Cloud Armor 安全性政策可防止要求到達 CDN 原始伺服器，系統仍會提供快取命中。
要求主體檢查問題
Cloud Armor 會在收到資料時逐步評估，直到達到設定的檢查限制，因此規則可能會根據不完整的主體資料進行評估。為避免可能出現偽陽性或不完整的結果，請編寫規則來比對資料是否存在，而非資料是否不存在。詳情請參閱「要求主體檢查限制」。
在記錄中查看相符的子運算式
排解規則問題時，您可以將 --log-level 旗標設為 VERBOSE，啟用詳細記錄功能，並使用 Logging 查看規則中哪些子運算式相符。如果規則包含多個子運算式，Cloud Armor 只會記錄最近比對成功的子運算式詳細資料。
以下範例運算式包含兩個子運算式：
request.url.contains('__') && request.body.contains('abc')
如果您將主體為 abc 的 POST 要求傳送至網址 example.com/etc/pass__word，運算式就會相符。由於子運算式是由左至右評估，因此 request.body.contains('abc') 子運算式會最後評估。下列記錄摘錄顯示相符的 request.body 子運算式詳細資料：
jsonPayload: {
[...]
enforcedSecurityPolicy: {
[...]
matchedFieldType: "request.body",
matchedFieldName: "request.body",
matchedFieldValue: "abc",
matchedFieldLength: 3,
matchedOffset: 0,
matchedLength: 3,
}
[..*]
}
已命名 IP 位址清單的問題
本節提供具名 IP 位址清單問題的解決方法。
已命名 IP 位址清單中的 IP 位址
清單中的 IP 位址一律與 Cloud Armor 命名 IP 位址清單指南中列出的供應商網站 IP 位址相符。如果對清單有任何疑問，請與 Cloud 支援團隊聯絡。
Cloud Armor 中已命名 IP 位址清單內的 IP 位址已過時
Cloud Armor 每天都會與 IP 位址清單供應商同步處理清單。資料可能會有過時的情況，比供應商的資料落後幾小時或一天。不過，如果您認為過時資料的延遲時間超過預期 (例如超過一週)，請與 Cloud 支援團隊聯絡。
難以建立參照具名 IP 位址清單的安全政策
您可能會嘗試使用下列指令，建立參照命名 IP 位址清單的安全性政策：
gcloud compute security-policies rules create 750 \
--security-policy my \
--expression "evaluatePreconfiguredWaf('sourceiplist-example')" \
--action "allow"
如果指令失敗，您會看到類似下方的錯誤：
ERROR: (gcloud.compute.security-policies.rules.create) Could not fetch resource:
- Invalid value for field 'resource.match.expr': '{ "expression": "evaluatePreconfiguredWaf(\u0027sourceiplist-example\u0027)"}'.
Error parsing Cloud Armor rule matcher expression: sourceiplist-example
isn't a valid preconfigured expression set.
請確認系統支援特定供應商，且 IP 位址清單名稱正確無誤。您可以使用下列 gcloud 指令列出目前的預先設定運算式組合，藉此檢查這項資訊：
gcloud compute security-policies list-preconfigured-expression-sets
流量遭到封鎖，即使已預先設定具名 IP 位址許可清單規則
您可能會發現，來自具名 IP 位址清單中 IP 位址的流量遭到封鎖：
確認流量來自具名 IP 位址許可清單中的 IP 位址。
請檢查是否有其他優先順序較高的安全性規則，可能會封鎖流量。如果問題仍未解決，請與 Cloud 支援團隊聯絡。
確認安全性政策已附加至正確的後端服務：
gcloud compute backend-services describe BACKEND_SERVICE
檢查安全性政策中的規則。例如：
gcloud compute security-policies describe POLICY_NAME
指令會傳回類似下列的資訊：
--- … name: POLICY_NAME rules: -action: allow description: allow fastly ip addresses kind: compute#securityPolicyRule match: expr: expression: evaluatePreconfiguredWaf('sourceiplist-fastly') preview: false priority: 100 -action: deny(403) description: Default rule, higher priority overrides it kind: compute#securityPolicyRule match: config: srcIpRanges: -'*' versionedExpr: SRC_IPS_V1 preview: false priority: 2147483647 -action: deny(404) description: deny altostrat referer kind: compute#securityPolicyRule match: expr: expression: request.headers['Referer'].contains('altostrat') preview: false priority: 50 …上述安全性政策包含三項規則：預設拒絕規則、Fastly IP 位址的允許規則，以及包含
altostrat的參照網址拒絕規則。此外，也會列出各自的優先順序。查看記錄，判斷哪些規則與流量和相關聯動作相符。如要瞭解記錄功能，請參閱「使用記錄檔探索工具」。
以下是記錄範例：
httpRequest: { referer: "http://www.altostrat.com/" remoteIp: "23.230.32.10" requestMethod: "HEAD" requestSize: "79" requestUrl: "http://www.example.com/" responseSize: "258" status: 404 userAgent: "Mozilla/5.0" } … jsonPayload: { @type: "type.googleapis.com/google.cloud.loadbalancing.type.LoadBalancerLogEntry" enforcedSecurityPolicy: { configuredAction: "DENY" name: "POLICY_NAME" outcome: "DENY" priority: 50 } statusDetails: "denied_by_security_policy" } …從上述記錄中，要求來自
23.230.32.10，這在 Fastly 的公開 IP 位址清單涵蓋範圍內。不過，這項要求與優先順序較高 (50) 的拒絕規則相符。與安全性政策中的內容相比，這項規則對應到參照網址包含altostrat的拒絕規則。由於要求的參照網址為http://www.altostrat.com/，因此安全性規則強制執行功能正常運作。
Security Command Center 發現項目問題
本節說明 Security Command Center 發現項目的問題。
Cloud Armor 資訊卡未顯示在 Security Command Center
在 Security Command Center 介面中啟用 Cloud Armor 發現項目。
Cloud Armor 的發現項目未顯示在 Security Command Center
如果 Security Command Center 未顯示 Cloud Armor 的發現項目，可能是因為後端服務的流量不符合提出發現項目的條件。
如對後端流量有疑問，請在 Cloud Monitoring 資訊主頁的「Network Security Policies」(網路安全性政策) 下方查看要求統計資料。
發現項目過多
如需協助解決這個問題，請與 Cloud 支援團隊聯絡。
Google Cloud Armor Adaptive Protection 相關問題
請按照下列操作說明解決 Adaptive Protection 的問題。
已為安全性政策啟用 Adaptive Protection，但 Logging 中沒有記錄
Adaptive Protection 記錄與 Cloud Armor 要求記錄分開產生，並顯示在 Logging 的不同資源下。Adaptive Protection 記錄和事件位於 Logging 的「Network Security Policy」(網路安全政策) 資源下方。在安全性政策中啟用 Adaptive Protection 後，系統會進行至少一小時的訓練，然後才會開始針對疑似攻擊產生警示。在訓練日期範圍期間，Adaptive Protection 會從傳入的要求流量中學習，並為受該安全性政策保護的每個後端服務，制定不同的基準。Adaptive Protection 隨後就能識別可疑活動。
如果您為安全性政策啟用 Adaptive Protection，且在一小時的訓練日期範圍後未看到任何警告，表示系統未偵測到任何可能惡意攻擊與該安全性政策相關聯後端服務的活動。
如果潛在攻擊或異常流量持續較長時間 (超過數小時)，Adaptive Protection 就會開始將該行為視為基準行為，並停止針對類似的流量模式發出快訊。潛在攻擊平息且流量模式恢復原始基準後 (可能是因為攻擊結束，或您已使用適當的 Cloud Armor 規則封鎖攻擊)，Adaptive Protection 會針對未來偏離基準的流量行為發出警示。
Adaptive Protection 會分析 Cloud Armor 安全性政策允許通過的流量。如果將預設規則設為拒絕存取，並限制流量許可清單，Adaptive Protection 只會偵測通過許可清單評估的流量，找出惡意活動。
Adaptive Protection 在 Logging 中產生過多警告或記錄
Adaptive Protection 警告會提供可信度分數，指出 Adaptive Protection 模型將偵測到的活動判定為異常和潛在攻擊的可能性。您可以透過 Logging 篩選記錄的特定項目，只顯示 (或轉送至下游) 可信度分數高於特定門檻的警告。
Adaptive Protection 提供將警告回報為偽陽性的機制，詳情請參閱「監控、意見回饋和回報事件錯誤」一節。請注意，回報偽陽性可能不會立即變更 Adaptive Protection 的警告內容。一段時間後，Adaptive Protection 模型會瞭解這類流量模式正常且可接受，並停止針對這些模式發出警示。
如果安全性政策中，某部分後端服務的 Adaptive Protection 警告過於頻繁，可能表示這些後端服務的正常流量有大幅波動，Adaptive Protection 一直將其視為異常行為。您可以建立未啟用 Adaptive Protection 的獨立安全性政策，並將這些後端服務與新的安全性政策建立關聯。
Adaptive Protection 回報的特定事件是誤判或不相關
Adaptive Protection 提供回報偽陽性警示的機制。請按照「監控、意見回饋和回報事件錯誤」一節所述的程序操作。請注意，回報偽陽性可能不會立即變更 Adaptive Protection 的警告內容。一段時間後，Adaptive Protection 模型會瞭解這類流量模式正常且可接受，並停止針對這些模式發出警示。
如何確認邊緣安全性政策是否已強制執行？
您可以查看監控資訊主頁、監控指標或每項要求的記錄，瞭解邊緣安全性政策採取的動作。
Monitoring 資訊主頁
您可以在「Monitoring」下方的「Network Security Policies」(網路安全性政策) 頁面使用 Cloud Monitoring。您可以根據頁面上的安全性政策細目，評估設定的邊緣安全性政策允許和拒絕的要求數量。您也可以依後端服務查看細目，對特定後端服務進行偵錯。如要進一步瞭解 Cloud Monitoring 資訊主頁，請參閱「監控 Cloud Armor 安全性政策」。
監控指標
邊緣安全性政策提供原始指標，可評估允許和拒絕的要求。詳情請參閱「監控安全性政策的指標」。
記錄個別要求
邊緣安全性政策裁決會記錄在 enforcedEdgeSecurityPolicy 下方的負載平衡要求記錄中。這與 enforcedSecurityPolicy 不同，後者會擷取後端安全性政策裁決。
機器人管理
本節說明如何排解機器人管理問題。
使用者未如預期獲得豁免
您可能已設定安全性政策規則，並針對 reCAPTCHA 評估採取重新導向動作，但發現某些您認為合法的使用者並未如預期豁免。請按照下列步驟進行疑難排解。
首先，請查看每項要求的記錄，確認是否有優先順序較高且符合流量的安全性政策規則，且該規則的操作不同。請特別留意 configured_action 和 outcome 欄位。請注意，如要豁免使用者，至少需要提出兩項要求。初始要求不含豁免 Cookie，如果使用者通過 reCAPTCHA 評估，後續要求就會包含豁免 Cookie。因此，預期至少會有兩個記錄項目。
- 如果設定的動作顯示為
GOOGLE_RECAPTCHA，結果顯示為REDIRECT，表示要求已重新導向至 reCAPTCHA 評估。 - 如果設定的動作顯示為
GOOGLE_RECAPTCHA，結果顯示為ACCEPT，表示要求已豁免，不會重新導向至 reCAPTCHA 評估。 - 如果上述欄位顯示不同的值，表示系統比對到具有不同動作的規則。在這種情況下，使用者不會重新導向或豁免。
第二，使用者必須符合幾項條件，才能免於重新導向至 reCAPTCHA 評估。
- 使用者必須使用瀏覽器。
- 瀏覽器必須啟用 JavaScript，才能正確載入內嵌 reCAPTCHA JavaScript 的重新導向頁面。
- 瀏覽器必須啟用 Cookie，才能設定及自動附加豁免 Cookie。
- 使用者必須通過 reCAPTCHA 評估，例如解決對話方塊驗證問題 (如有)。
如果使用者不符合上述任何一項規定，即使符合 reCAPTCHA 評估重新導向動作的規則，也不會獲得豁免。
第三，只有在轉譯嵌入 reCAPTCHA JavaScript 的重新導向頁面時，才會執行 reCAPTCHA 評估。因此，只有在要求預期會收到導致完整頁面轉譯的回應時，才適用重新導向至 reCAPTCHA 評估。其他要求 (例如在網頁中載入素材資源，或來自嵌入指令碼、不預期會顯示回應的要求) 則不應取得 reCAPTCHA 評估。因此，建議您對符合這項條件的網址路徑，套用這項動作和比對條件。
舉例來說，假設您的網頁包含圖片、其他網頁的連結和指令碼等嵌入元素。如果網址路徑託管圖片，或應由指令碼存取，且不預期會完整轉譯網頁，請勿對 reCAPTCHA 評估套用重新導向動作。請改為對託管網頁的網址路徑 (例如主要網頁或其他連結網頁) 套用 reCAPTCHA 評估的重新導向動作。
最後，如果重新導向頁面成功算繪，請在瀏覽器提供的開發人員工具中，查看是否已設定豁免 Cookie，以及是否附加在相同網站的後續要求中。如需進一步協助，請與 Cloud 支援團隊聯絡。
頻率限制問題
本節說明如何排解頻率限制的常見問題。
流量未如預期受到限制
您可能會發現，用戶端 IP 位址傳送至應用程式的流量過高，超過您設定的門檻，但流量並未如預期受到限制。請按照下列步驟調查問題。
首先，請確認是否有優先順序較高的規則允許來自該 IP 位址的流量。檢查記錄，確認是否為該 IP 位址觸發 ALLOW 規則。這可以是單獨的 ALLOW 規則，也可以是另一個 THROTTLE 或 RATE_BASED_BAN 規則。
如果找到優先順序較高的規則，請執行下列任一操作：
- 變更優先順序，為頻率限制規則指派「較低」的數值，確保該規則的優先順序較高。
- 在優先順序較高的規則中，從相符運算式排除該 IP 位址。
也可能是門檻設定有誤。在這種情況下，系統會準確比對要求，但會觸發符合動作。請查看記錄，確認是否為這種情況，然後降低規則中的門檻。
最後，IP 位址可能不符合調節或依頻率禁止規則。如要修正這個問題，請檢查比對條件是否有誤，然後將規則的比對條件變更為正確的值。