이 페이지에는 Google Cloud Armor 보안 정책에 사용할 수 있는 선택 기능인 상세 로깅을 구성하는 방법에 대한 정보가 포함되어 있습니다.
로그에 기록되는 세부정보의 수준을 조정할 수 있습니다. 처음 정책을 만들거나, 정책을 변경하거나, 정책 문제를 해결할 때만 상세 로깅을 사용 설정하는 것이 좋습니다. 상세 로깅을 사용 설정하면 미리보기 모드의 규칙과 표준 작업 중의 활성(미리보기되지 않음) 규칙에 적용됩니다.
특정 요청에 의해 사전 구성된 WAF 규칙이 트리거된 이유를 알 수 없는 경우를 예로 들어보겠습니다. Google Cloud Armor의 기본 이벤트 로그에는 트리거된 규칙과 하위 서명이 포함됩니다. 그러나 문제 해결, 규칙 유효성 검사 또는 규칙 조정을 목적으로 규칙을 트리거한 수신 요청의 세부정보를 식별해야 할 수 있습니다. 이 예에서는 상세 로깅을 사용 설정하는 것이 좋습니다.
Google Cloud CLI의 --log-level 플래그를 사용하여 각 보안 정책에 더 자세한 로깅을 사용 설정하도록 Google Cloud Armor 로깅 수준을 구성할 수 있습니다.
기본적으로 이 옵션은 사용 중지되어 있습니다. 이 플래그의 문법은 다음과 같습니다.
--log-level=[NORMAL | VERBOSE]
이 플래그는 gcloud compute security-policies update 명령어를 사용해야만 사용할 수 있습니다. 파일에 보안 정책을 만들고 해당 파일을 가져오지 않는 한 이 옵션으로 새 보안 정책을 만들 수 없습니다. 자세한 내용은 보안 정책 가져오기를 참조하세요.
상세 로깅을 사용하면 Google Cloud Armor는 사전 구성된 특정 WAF 규칙을 트리거한 수신 요청의 요소 스니펫을 로깅합니다.
이러한 스니펫에는 요청 헤더, 요청 파라미터 또는 POST 본문의 요소가 포함될 수 있습니다. 요청 헤더 또는 본문에 있는 내용과 WAF 규칙을 트리거하는 항목에 따라 수신 요청의 민감한 정보(IP 주소 또는 기타 민감한 정보)가 스니펫에 포함될 수 있습니다.
상세 로깅을 사용 설정하면 Logging의 로그에 잠재적으로 민감한 정보가 누적될 위험이 있습니다. 규칙 생성 및 검증 중에 또는 문제 해결을 위해서만 상세 로깅을 사용 설정하는 것이 좋습니다. 일반 작업 중에는 상세 로깅을 사용 중지된 상태로 두는 것이 좋습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-31(UTC)"],[[["\u003cp\u003eVerbose logging in Google Cloud Armor provides detailed information about triggered security policy rules, aiding in troubleshooting, validation, and tuning.\u003c/p\u003e\n"],["\u003cp\u003eVerbose logging is configured via the \u003ccode\u003e--log-level\u003c/code\u003e flag in the \u003ccode\u003egcloud compute security-policies update\u003c/code\u003e command, with options for \u003ccode\u003eNORMAL\u003c/code\u003e or \u003ccode\u003eVERBOSE\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eWhen verbose logging is enabled, logs include additional fields like \u003ccode\u003ematchedFieldType\u003c/code\u003e, \u003ccode\u003ematchedFieldName\u003c/code\u003e, and \u003ccode\u003ematchedFieldValue\u003c/code\u003e to pinpoint the exact parts of the request that triggered a rule.\u003c/p\u003e\n"],["\u003cp\u003eVerbose logging should only be enabled temporarily during policy creation, modification, or troubleshooting due to the risk of logging potentially sensitive data from incoming requests.\u003c/p\u003e\n"],["\u003cp\u003eBy default verbose logging is disabled, and normal logs only show the rule and subsignature that were triggered, while verbose logging provides the details of the incoming request that triggered the rule.\u003c/p\u003e\n"]]],[],null,["# Verbose logging\n\nThis page contains information about configuring verbose logging, an optional\nfeature that you can use with your Cloud Armor security policies.\n\nYou can adjust the level of detail recorded in your logs. We recommend that you\nenable verbose logging only when you first create a policy, make\nchanges to a policy, or troubleshoot a policy. If you enable verbose\nlogging, it is in effect for rules in preview mode as well as active\n(non-previewed) rules during standard operations.\n\nConsider an example in which you can't tell why a preconfigured WAF\nrule is triggered by a particular request. Cloud Armor's default event\nlogs contain the rule that was triggered, as well as the subsignature. However,\nyou might need to identify the details from the incoming request that triggered\nthe rule for troubleshooting, rule validation, or rule tuning purposes. For this\nexample, we recommend that you enable verbose logging.\n\nYou can configure the Cloud Armor logging level to enable more detailed\nlogging for each security policy by using the `--log-level` flag in the\nGoogle Cloud CLI.\n\nBy default, this option is disabled. The syntax for the flag is as follows:\n\n`--log-level=[NORMAL | VERBOSE]`\n\nThe flag is available only by using the `gcloud compute security-policies update`\ncommand. You can't create a new security policy with this option unless you\ncreate a security policy in a file and then import that file. For more\ninformation, see\n[Import security policies](/armor/docs/configure-security-policies#importing-policies).\n\nFor example: \n\n```\n gcloud compute security-policies update ca-policy-1 \\\n --log-level=VERBOSE\n \n```\n\nWe recommend that you enable verbose logging when you first create a\npolicy, make changes to a policy, or troubleshoot a policy.\n\n### Values logged when verbose logging is enabled\n\nWhen verbose logging is enabled, additional information is logged to the\nload balancing request log that is sent to Cloud Logging. The\nfollowing additional fields appear in the request log when verbose logging is\nenabled:\n\n- `matchedFieldType` (string): this is the type of field causing the match.\n\n - `ARG_NAMES`\n - `ARG_VALUES`\n - `BODY`\n\n - When the `BODY` field is in the log, it means that the entire request body matches a rule.\n - `COOKIE_VALUES`\n\n - `COOKIE_NAMES`\n\n - `FILENAME`\n\n - `HEADER_VALUES`\n\n - `RAW_URI`\n\n - `REFERER`\n\n - `REQUEST_LINE`\n\n - `URI`\n\n - `USER_AGENT`\n\n - `HEADER_NAMES`\n\n - `ARGS_GET`\n\n - `X_FILENAME`\n\n - `ARG_NAME_COUNT`\n\n - `TRANSFER_ENCODING`\n\n - `REQUEST_METHOD`\n\n- `matchedFieldName` (string): if this matches the value part of a key-value pair,\n the key value is stored in this field. Otherwise, it is empty.\n\n- `matchedFieldValue` (string): a prefix of up to 16 bytes for the part of the field\n that causes the match.\n\n- `matchedFieldLength` (integer): the total length of the field.\n\n- `matchedOffset` (integer): the start offset inside the field that causes the match.\n\n- `matchedLength` (integer): the length of the match.\n\n- `inspectedBodySize` (integer): the configured inspection limit (number of\n bytes) for a request body that you set by using the\n `--request-body-inspection-size` flag. For more information about this\n limit, see [POST and PATCH body inspection limitation](/armor/docs/security-policy-overview#post-body).\n\nFor example, you might send the following request to a project where SQL injection WAF\nrules are enabled: \n\n```\ncurl http://IP_ADDR/?sql_table=abc%20pg_catalog%20xyz\n```\n\nThe entry in the **Logs Explorer** is similar to the following: \n\n```\nenforcedSecurityPolicy: {\n name: \"user-staging-sec-policy\"\n priority: 100\n configuredAction: \"DENY\"\n outcome: \"DENY\n inspectedBodySize: 65536\n preconfiguredExprIds: [\n 0: \"owasp-crs-v030001-id942140-sqli\"\n ]\nmatchedFieldType: \"ARG_VALUES\"\nmatchedFieldName: \"sql_table\"\nmatchedFieldValue: \"pg_catalog\"\nmatchedFieldLength: 18\nmatchedOffset: 4\nmatchedLength: 10\n}\n```\n\n### Maintaining privacy when verbose logging is turned on\n\nWhen you use verbose logging, Cloud Armor logs snippets of the elements\nfrom the incoming requests that triggered a particular preconfigured WAF rule.\nThese snippets might contain pieces of request headers, request parameters, or\nelements of the request body. A snippet can contain sensitive data\nsuch as an IP address or other sensitive data from the incoming request,\ndepending on what is in the request headers or body and what triggers the WAF\nrule.\n\nWhen you enable verbose logging, there is a risk of accumulating\npotentially sensitive data in your logs in Logging. We recommend\nthat you enable verbose logging only during rule creation and validation or for\ntroubleshooting. During normal operations, we recommend that you leave verbose\nlogging disabled.\n\nWhat's next\n-----------\n\n- [Configure Cloud Armor security policies](/armor/docs/configure-security-policies)\n- [Use request logging](/armor/docs/request-logging)"]]
