apps.firewall.ingressRules.list 메서드를 사용하고 matchingAddress 매개변수에 테스트할 IP 주소를 지정하면 방화벽 규칙을 테스트하고 우선순위와 작업이 예상대로 동작하는지 확인할 수 있습니다.
App Engine 방화벽 규칙 이해
App Engine 방화벽은 특정 IP 주소나 범위의 앱 액세스를 허용하거나 거부할 수 있는 정렬된 규칙 목록으로 구성됩니다. 이 규칙은 App Engine 애플리케이션의 모든 리소스에 적용됩니다.
방화벽 규칙 우선순위
방화벽 규칙은 중요도에 따라 정렬되며, 이는 각 규칙의 우선순위에 숫자 값으로 정의됩니다. 각 규칙에 고유한 우선순위 값을 지정해야 하는데, 이는 방화벽 내 다른 규칙들과 비교해 중요도가 정의되기 때문입니다. 규칙의 우선순위 값은 가장 중요한 1부터 가장 중요하지 않은 2147483647까지 가능합니다.
각 방화벽은 우선순위 2147483647로 자동 생성되며 앱의 전체 IP 범위에 적용되는 default 규칙을 포함합니다. default 규칙은 항상 방화벽의 다른 모든 규칙 이후에 평가되고 모든 IP 주소의 모든 요청에 적용됩니다.
방화벽은 우선순위가 가장 높은 규칙을 먼저 평가합니다.
방화벽의 나머지 모든 규칙은 해당 요청의 IP 범위와 일치하는 규칙이 나올 때까지 순차적으로 평가됩니다. 일치하는 규칙이 발견되면 연결이 허용되거나 거부되고 방화벽의 나머지 모든 규칙을 건너뜁니다. 방화벽에 수동으로 정의된 규칙 중 어떤 것도 요청과 일치하지 않으면 default 규칙이 평가됩니다.
예를 들어 우선순위가 1인 규칙을 만들면 이 규칙이 항상 먼저 평가됩니다. 들어오는 요청이 우선순위가 1인 규칙과 일치하면 해당 규칙만 평가되고 default 규칙을 포함한 방화벽의 다른 모든 규칙을 건너뜁니다.
한 회사에서 개발 중인 앱에 엔지니어링팀 및 사내 네트워크의 액세스 권한을 부여하기 위해 방화벽을 설정해야 한다는 예를 들어 보겠습니다. 이 회사의 방화벽 규칙은 늘어날 규칙에 대비해 각 우선순위 사이에 큰 간격을 두고 생성되었습니다.
우선순위
작업
IP 범위
설명
1000
거부
192.0.2.1
DoS 공격자의 액세스를 거부합니다.
2000
허용
198.51.100.2
위성 사무실에 있는 엔지니어의 액세스를 허용합니다.
3000
거부
198.51.100.0/24
엔지니어링과 관련되지 않은 모든 건물의 액세스를 거부합니다.
5000
허용
203.0.113.0/24
본관 네트워크의 액세스를 허용합니다.
2147483647
거부
*
기본 작업
방화벽을 만든 후에는 다음과 같은 요청이 샘플 앱에 전달된다고 가정하고 앱의 응답을 확인합니다.
198.51.100.2의 요청은 우선순위가 2000인 규칙과 일치하므로 허용됩니다.
198.51.100.100의 요청은 우선순위가 3000인 규칙과 일치하므로 거부됩니다.
203.0.113.54의 요청은 우선순위가 5000인 규칙과 일치하므로 허용됩니다.
45.123.35.242의 요청은 기본 규칙과 일치하므로 거부됩니다.
충돌하는 규칙 해결
회사 방화벽의 두 우선순위가 서로 바뀌었다고 가정해 보겠습니다. 우선순위 2000과 3000에 대한 규칙이 바뀐 경우 의도하지 않은 동작이 나타납니다.
우선순위
작업
IP 범위
설명
1000
거부
192.0.2.1
DoS 공격자의 액세스를 거부합니다.
2000
거부
198.51.100.0/24
엔지니어링과 관련되지 않은 모든 건물의 액세스를 거부합니다.
3000
허용
198.51.100.2
위성 사무실에 있는 엔지니어의 액세스를 허용합니다.
5000
허용
203.0.113.0/24
본관 네트워크의 액세스를 허용합니다.
2147483647
거부
*
기본 작업
규칙의 새 우선순위에 따라 해당 규칙은 평가가 될 수 없으므로 지국 엔지니어는 회사 앱에 액세스할 수 없습니다. 엔지니어의 IP 주소 198.51.100.2는 엔지니어의 IP 주소의 액세스를 허용하는 규칙 이전에 198.51.100.0/24 범위의 모든 비엔지니어를 거부하는 규칙과 일치합니다.
이 문제를 해결하려면 198.51.100.2에 액세스를 허용하는 규칙의 우선순위를 IP 범위 198.51.100.0/24에서 액세스를 거부하는 규칙보다 높게 설정해야 합니다.
다음 단계
앱을 안전하게 구성하고 적절한 액세스 수준을 설정했는지 확인하려면 애플리케이션 보안과 액세스 제어를 검토합니다.
[[["이해하기 쉬움","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-09-04(UTC)"],[[["\u003cp\u003eApp Engine firewalls utilize up to 1000 prioritized rules to allow or restrict access to applications based on IP addresses and subnets.\u003c/p\u003e\n"],["\u003cp\u003eFirewall rules are evaluated in order of priority, ranging from 1 (highest) to 2147483647 (lowest), with the \u003ccode\u003edefault\u003c/code\u003e rule having the lowest priority and applying to all IP addresses not matched by other rules.\u003c/p\u003e\n"],["\u003cp\u003eYou can create firewall rules in the Google Cloud console or via the \u003ccode\u003egcloud\u003c/code\u003e command-line tool, specifying priority, action (allow/deny), IP range in CIDR notation, and an optional description.\u003c/p\u003e\n"],["\u003cp\u003eEach rule can be tested via the Google Cloud Console or using \u003ccode\u003egcloud\u003c/code\u003e to ensure the priority and action provide the expected behavior by checking a specific IP against the rules.\u003c/p\u003e\n"],["\u003cp\u003eThe order of rule priorities is critical, as the first matching rule determines whether access is allowed or denied, and higher priority rules will be evaluated first, therefore, a conflicting lower priority rule will be skipped.\u003c/p\u003e\n"]]],[],null,["# Creating App Engine firewall rules\n\n\u003cbr /\u003e\n\n\u003cbr /\u003e\n\n\nIn App Engine, you can create a firewall with up to 1000 prioritized\nindividual rules that either allow or restrict a range of IP addresses and\nsubnets. Your app will only respond to requests that are allowed by the\nfirewall.\n\nTo learn how the App Engine firewall works, see\n[Understanding firewalls](/appengine/docs/standard/understanding-firewalls).\n\nBefore you begin\n----------------\n\nBefore you can create App Engine firewall rules for your app, you must\nhave one of the following [App Engine IAM\nroles](/appengine/docs/standard/access-control), which\ninclude the necessary privileges for creating or modifying firewall rules:\n\n- App Engine Admin\n- Editor\n- Owner\n\nCreating firewall rules\n-----------------------\n\nUse one of the following methods to create a firewall rule. Repeat\nthese steps for each additional rule:\nConsole\n\n\nUse the Firewall rules page in Google Cloud console to create a\nfirewall rule:\n\n1.\n Go to the Create a firewall rule page in Google Cloud console:\n\n\n [Go to the Create a firewall rule page](https://console.cloud.google.com/appengine/firewall/create)\n2.\n Specify the details of the firewall rule:\n\n 1. In **Priority** , enter an integer to specify the relative importance of the rule and define the order of when the rule is evaluated.\n\n\n Valid values are `1` to `2147483646`.\n Priority `1` is the first rule evaluated. Priority\n `2147483647` is the last rule evaluated and is\n reserved for the \\`default\\` rule.\n | **Important**: After a rule is created, you cannot edit the priority value. You must delete and then recreate a rule to change the value of a rule's priority.\n 2. In **Action on match** , specify whether to allow or deny access for requests that match the rule. Rules set to `allow` forward the request to the app. Rules set to `deny` respond to requests with a `403 Forbidden` error.\n 3. In **IP range** , define the range of IP addresses that apply to the rule. The IP address range must be defined in [CIDR notation](https://wikipedia.org/wiki/Classless_Inter-Domain_Routing), can include subnet masks, and support both IPv4 and IPv6.\n 4. Optional: In **Description**, include a description of the rule that is no longer than 100 characters.\n3. Click **Save** to create the rule.\n4. Test the rule to ensure that the priority and action provide the expected behavior:\n 1. Click **Test IP address**.\n 2. Enter the IP address that you want to validate and then click **Test** to ensure that the corresponding rule gets correctly evaluated.\ngcloud\n\n\nRun the following [`gcloud\napp firewall-rules`](/sdk/gcloud/reference/app/firewall-rules) commands to create a firewall rule:\n\n1.\n Run the following command to create a firewall rule:\n\n ```bash\n gcloud app firewall-rules create PRIORITY --action ALLOW_OR_DENY --source-range IP_RANGE --description DESCRIPTION\n ```\n where:\n - \u003cvar translate=\"no\"\u003ePRIORITY\u003c/var\u003e is an integer between `1` and `2147483646` that defines the rule's importance and order for which the rule is evaluated. Priority `1` is the first rule evaluated. Priority `2147483647` is the last rule evaluated and is reserved for the \\`default\\` rule. **Important**: After a rule is created, you cannot edit the priority value. You must delete and then recreate a rule to change the value of a rule's priority.\n - \u003cvar translate=\"no\"\u003eALLOW_OR_DENY\u003c/var\u003e specifies whether to allow or deny access for requests that match the rule. Valid values are `allow` or `deny`. Rules set to `allow` forward the request to the app. Rules set to `deny` respond to requests with a `403 Forbidden` error.\n - \u003cvar translate=\"no\"\u003eIP_RANGE\u003c/var\u003e defines the range of IP addresses that apply to the rule. The IP range must be defined in [CIDR notation](https://wikipedia.org/wiki/Classless_Inter-Domain_Routing), can include subnet masks, and support both IPv4 and IPv6.\n - \u003cvar translate=\"no\"\u003eDESCRIPTION\u003c/var\u003e is an optional description of the rule that is no longer than 100 characters.\n2. Run the following command to test your rule and ensure that the priority and action provide the expected behavior: \n\n ```bash\n gcloud app firewall-rules test-ip IP_ADDRESS\n ```\n where \u003cvar translate=\"no\"\u003eIP_ADDRESS\u003c/var\u003e is the IP address that you want to test against your firewall.\n3. Run the following command to view a list of the existing rules: \n\n ```bash\n gcloud app firewall-rules list\n ```\n4. Run the following command to delete an existing rule: \n\n ```bash\n gcloud app firewall-rules delete PRIORITY\n ```\n where \u003cvar translate=\"no\"\u003ePRIORITY\u003c/var\u003e is the priority value of the rule that you want to delete.\n\nExamples:\n:\n Use the following examples to help you create your firewall:\n\n -\n Add a rule that allows an IPv6 address and subnet mask, and then\n test that rule to ensure it gets evaluated prior to your other\n rules:\n\n ```bash\n gcloud app firewall-rules create 123 --source-range fe80::3636:3bff:fecc:8778/128 --action allow\n gcloud app firewall-rules test-ip fe80::3636:3bff:fecc:8778\n ```\n -\n Add a rule to deny an IPv4 address and subnet mask, and then\n test that rule to ensure that it gets appropriately evaluated:\n\n ```bash\n gcloud app firewall-rules create 123456 --source-range \"74.125.0.0/16\" --action deny\n gcloud app firewall-rules test-ip 74.125.0.8\n ```\n -\n Update and then test the default rule to ensure that it\n restricts all IP addresses that don't match any other rules:\n\n ```bash\n gcloud app firewall-rules update default --action deny\n gcloud app firewall-rules test-ip 123.456.7.89\n ```\n\nAPI\n\n\nTo programmatically create firewall rules for your App Engine\napp, you can use the [`apps.firewall.ingressRules`](/appengine/docs/admin-api/reference/rest/v1/apps.firewall.ingressRules) methods in the\nAdmin API.\n\n\nTo test a firewall rule and ensure that the priority and action\nprovide the expected behavior, you can use the [`apps.firewall.ingressRules.list`](/appengine/docs/admin-api/reference/rest/v1/apps.firewall.ingressRules/list) method and specify\nthe IP address that you want to test within the\n`matchingAddress` parameter.\n\nUnderstanding App Engine firewall rules\n---------------------------------------\n\nAn App Engine firewall consists of an ordered list of rules that can\nallow or deny access from the specified IP address or range to your app. The\nrule applies to all resources of the App Engine application.\n\n### Firewall rule priority\n\nThe firewall rules are ordered by importance, which you define as a numerical\nvalue in each rule's priority. You must specify a unique priority value for\neach rule as it defines the importance relative to the other rules in the\nfirewall. The values for a rule's priority scale from the most important value\nof `1` up to the least important at value `2147483647`.\n\nEach firewall includes a `default` rule that is automatically created with the\n`2147483647` priority and applies to the entire IP range of your app.\nThe `default` rule is always evaluated after all the other rules\nin the firewall and applied to all requests across all IP addresses.\n\nThe firewall evaluates the highest priority rule first.\nAll the remaining rules in the firewall are sequentially evaluated until a rule\nmatches the IP range of that request. When a matching rule is found, the\nconnection is either allowed or denied, and all the remaining rules in the\nfirewall are then skipped. If none of the manually defined rules in the firewall\nmatch the request, the `default` rule is evaluated.\n\nFor example, if you create a rule with priority `1` it is always evaluated\nfirst. If an incoming request matches the rule with priority `1`, only that\nrule is evaluated and all the other rules in the firewall are skipped, including\nthe `default` rule.\n\nThe [example firewall](#example_firewall) below shows how a rule's\npriority can change the behavior of your firewall.\n\nExample firewall\n----------------\n\nIn this example, a company has set up a firewall to grant access to the\nengineering team and internal corporate network to their in-development app. The\nfirewall rules have been created with large gaps between each priority to allow\nfor growth.\n\nAfter the firewall is created, assume that the following requests are directed\nat the sample app and note the app's response:\n\n- Request from 198.51.100.2 matches rule with priority 2000 and is allowed.\n- Request from 198.51.100.100 matches rule with priority 3000 and gets denied.\n- Request from 203.0.113.54 matches rule with priority 5000 and is allowed.\n- Request from 45.123.35.242 matches the default rule and gets denied.\n\n### Resolving conflicting rules\n\nFor example, assume that two of the priorities in the company's firewall are\nswapped. If the rules for priorities 2000 and 3000 are swapped, notice the\nunintended behavior.\n\nThe engineer in the satellite office will not be able to access the company's\napp as the rule's new priority means it will never be evaluated. The engineer's\nIP address `198.51.100.2` matches the rule that denies all non-engineers in the\nrange `198.51.100.0/24` before the rule that allows access to the engineer's\nIP address.\n\nTo fix this, you must set the priority of the rule that allows access to\n`198.51.100.2` to be higher than the rule that denies access for the IP range\n`198.51.100.0/24`.\n\nWhat's next\n-----------\n\nTo ensure that you've securely configured your app and set the appropriate\nlevels of access, review\n[Application Security](/appengine/docs/standard/application-security)\nas well as [Access Control](/appengine/docs/standard/access-control)."]]
