주소 그룹에는 여러 IP 주소, CIDR 형식의 IP 주소 범위 또는 둘 다 포함됩니다. 각 주소 그룹은 Cloud NGFW 방화벽 정책의 규칙이나 Google Cloud Armor 보안 정책의 규칙과 같은 여러 리소스에서 사용할 수 있습니다.
주소 그룹에 대한 업데이트는 주소 그룹을 참조하는 리소스에 자동으로 전파됩니다. 예를 들어 신뢰할 수 있는 IP 주소 집합이 포함된 주소 그룹을 만들 수 있습니다. 신뢰할 수 있는 IP 주소 집합을 변경하려면 주소 그룹을 업데이트하세요. 주소 그룹에 대한 업데이트는 연결된 각 리소스에 자동으로 반영됩니다.
사양
주소 그룹 리소스는 다음과 같은 특징을 갖습니다.
각 주소 그룹은 다음 요소가 있는 URL로 고유하게 식별됩니다.
컨테이너 유형: 주소 그룹 유형(organization 또는 project)을 결정합니다.
컨테이너 ID: 조직 또는 프로젝트의 ID입니다.
위치: 주소 그룹이 global인지 또는 리전별 리소스(예: europe-west)인지 지정합니다.
각 주소 그룹에는 IPv4 또는 IPv6인 1개의 연결된 유형이 있을 수 있지만 둘 다 있을 수는 없습니다. 주소 그룹 유형은 나중에 변경할 수 없습니다.
주소 그룹의 각 IP 주소 또는 IP 범위를 항목이라고 합니다.
주소 그룹에 추가할 수 있는 항목 수는 주소 그룹의 용량에 따라 다릅니다. 주소 그룹을 만드는 동안 항목 용량을 정의할 수 있습니다. 이 용량은 나중에 변경할 수 없습니다. 주소 그룹에 구성할 수 있는 최대 용량은 주소 그룹을 사용하는 제품에 따라 다릅니다.
주소 그룹을 만들 때 용량과 유형을 지정해야 합니다. 또한 Google Cloud Armor를 사용하는 경우 purpose필드를 CLOUD_ARMOR로 설정해야 합니다.
CLOUD_ARMOR가 아닌 용도로 주소 그룹을 만드는 경우 주소 그룹의 최대 IP 주소 용량은 1,000개입니다.
주소 그룹 유형
주소 그룹은 범위에 따라 분류됩니다. 범위는 리소스 계층 구조에서 주소 그룹을 적용할 수 있는 수준을 식별합니다.
주소 그룹은 다음 유형으로 분류됩니다.
변경되는 IP 주소 목록을 차단하거나 허용하기 위해 프로젝트 또는 네트워크 내에서 사용할 IP 주소 목록을 정의하려는 경우 프로젝트 범위 주소 그룹을 사용합니다. 예를 들어 자체 위협 인텔리전스 목록을 정의하여 규칙에 추가하려면 필요한 IP 주소로 주소 그룹을 만듭니다.
프로젝트 범위 주소 그룹의 컨테이너 유형은 항상 project로 설정됩니다. 프로젝트 범위 주소 그룹을 만들고 수정하는 방법에 대한 자세한 내용은 프로젝트 범위 주소 그룹 사용을 참조하세요.
조직 범위 주소 그룹
개별 네트워크 및 프로젝트 소유자가 신뢰할 수 있는 서비스 및 내부 IP 주소와 같은 공통 목록을 유지관리하도록 전체 조직에 대한 일관된 제어를 제공하고 오버헤드를 줄이기 위해 대략적인 규칙에 사용할 수 있는 중앙 IP 주소 목록을 정의하려면 조직 범위 주소 그룹을 사용합니다.
조직 범위 주소 그룹의 컨테이너 유형은 항상 organization으로 설정됩니다. 조직 범위 주소 그룹을 만들고 수정하는 방법에 대한 자세한 내용은 조직 범위 주소 그룹 사용을 참조하세요.
보안 정책에서 주소 그룹 작동 방식
여러 보안 정책에서 각 IP 주소 목록을 공유할 수 있기 때문에 주소 그룹은 보안 정책의 구성 및 유지보수를 간소화합니다.
보안 정책과 함께 주소 그룹을 사용할 때는 다음과 같은 추가 사양을 고려하세요.
조직 범위 주소 그룹은 서비스 수준 보안 정책과 계층적 보안 정책 모두에 사용할 수 있습니다.
주소 그룹의 용량이 주소 그룹이 사용되는 보안 정책의 총 속성 수에 추가됩니다. 사용 사례에 따라 용량을 적절한 값으로 설정해야 합니다.
주소 그룹을 사용하려면 프로젝트가 Cloud Armor Enterprise에 등록되어 있어야 합니다.
표준 결제로 다운그레이드하면 새 주소 그룹을 만들거나 기존 주소 그룹을 수정할 수 없습니다.
또한 기존 주소 그룹을 참조하는 규칙을 만들 수 없으며 주소 그룹을 참조하는 보안 정책은 동결됩니다. 즉, 주소 그룹은 여전히 활성 상태이지만, 주소 그룹을 참조하는 모든 규칙을 삭제할 때까지는 수정할 수는 없습니다.
백엔드 보안 정책에 조직 범위 주소 그룹을 구성하는 것 외에도 계층적 보안 정책에 조직 범위 주소 그룹을 구성할 수 있습니다. 프로젝트 범위 주소 그룹은 해당 그룹이 있는 프로젝트 외부의 보안 정책에서 사용할 수 없지만, 조직 범위 주소 그룹은 조직 전체의 보안 정책과 공유할 수 있습니다. 따라서 계층적 보안 정책과 함께 사용하는 경우 보안 정책이 있는 조직 범위 주소 그룹이 특히 유용합니다. 계층적 보안 정책에 대한 자세한 내용은 계층적 보안 정책 개요를 참고하세요.
예시
다음 예에서는 주소 그룹을 사용하여 보안 정책을 구성하는 방법을 보여줍니다.
각각 보안 정책이 하나씩 있는 백엔드 서비스가 3개인 네트워크 구성이 있다고 가정해 보겠습니다. 또한 악성으로 알려진 IP 주소 목록이 있다고 합시다. 각 보안 정책에서 deny 규칙을 만들 때 각 보안 정책에 IP 주소 목록을 추가하는 대신 하나의 주소 그룹을 만들어 세 가지 보안 정책 모두에 사용할 수 있습니다. 그런 다음 새 보안 정책을 만들 때마다 주소 그룹을 다시 사용하여 새 규칙을 만들 수 있습니다.
조직에 폴더로 그룹화된 프로젝트가 많이 있고, 각 폴더에만 액세스해야 하는 IP 주소 목록이 3개 있다고 가정해 보겠습니다. IP 주소 목록별로 조직 범위 주소 그룹을 3개 만든 다음 계층적 보안 정책을 3개 만들 수 있습니다. 계층적 보안 정책에 세 가지 주소 그룹 중 하나와 일치하는 allow 규칙을 부여한 다음 허용된 IP 주소 그룹이 액세스해야 하는 각 폴더와 계층식 보안 정책을 연결할 수 있습니다.
[[["이해하기 쉬움","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-08(UTC)"],[[["\u003cp\u003eAddress groups contain multiple IP addresses or IP ranges, and can be referenced by multiple resources like Cloud NGFW firewall policies or Google Cloud Armor security policies.\u003c/p\u003e\n"],["\u003cp\u003eUpdates made to an address group are automatically applied to all resources that reference it, ensuring consistency across security policies.\u003c/p\u003e\n"],["\u003cp\u003eEach address group is uniquely identified by a URL containing the container type, container ID, location, and the address group's name, and they can be project or organization scoped.\u003c/p\u003e\n"],["\u003cp\u003eAddress groups have a type (IPv4 or IPv6) and capacity, which must be set upon creation and cannot be changed later, with capacity limits varying by the product using the address group.\u003c/p\u003e\n"],["\u003cp\u003eUsing address groups with security policies simplifies configuration by allowing the same list of IP addresses to be shared across multiple policies, but it requires enrollment in Cloud Armor Enterprise.\u003c/p\u003e\n"]]],[],null,["# Address groups overview\n\nAn *address group* contains multiple IP addresses, IP address ranges in CIDR\nformat, or both. Each address group can be used by multiple resources, such as\nrules in Cloud NGFW firewall policies or rules in\nCloud Armor security policies.\n\nUpdates to an address group are automatically propagated to the resources that\nreference the address group. For example, you can create an address group\ncontaining a set of trusted IP addresses. To change the set of trusted IP\naddresses, you update the address group. Your updates to the address group are\nreflected in each associated resource automatically.\n\nSpecifications\n--------------\n\nAddress group resources have the following characteristics:\n\n- Each address group is uniquely identified by a URL with the following elements:\n - **Container type:** Determines the address group type---`organization` or `project`.\n - **Container ID:** ID of the organization or the project.\n - **Location:** Specifies if the address group is a `global` or regional resource (such as `europe-west`).\n - **Name:** The address group name with the following format:\n - A string 1-63 characters long\n - Includes only alphanumeric characters\n - Must not start with a number\n- You can construct a unique URL identifier for an address group in the\n following format:\n\n \u003ccontainerType\u003e/\u003ccontainerId\u003e/locations/\u003clocation\u003e/addressGroups/\u003caddress-group-name\u003e\n\n For example, a `global` address group `example-address-group` in project\n `myproject`has the following unique 4-tuple identifier: \n\n projects/myproject/locations/global/addressGroups/example-address-group\n\n- Each address group has an associated type that can be either IPv4 or IPv6,\n but not both. The address group type cannot be changed later.\n\n- Each IP address or IP range in an address group is referred to as an *item*.\n The number of items that you can add to an address group depends on the\n address group's capacity. You can define the item capacity during address\n group creation. This capacity cannot be changed later. The maximum capacity\n that you can configure for an address group varies depending on the product\n with which you use the address group.\n\n- You must specify the capacity and type when you create an address group. In\n addition, when you use Cloud Armor, you must set the `purpose`\n field to `CLOUD_ARMOR`.\n\n- When you create an address group with a purpose that is *not*\n `CLOUD_ARMOR`, the address group has a maximum capacity of 1,000 IP\n addresses.\n\nTypes of address groups\n-----------------------\n\nAddress groups are classified based on their scope. The scope identifies the level\nat which the address group is applicable in the\n[resource hierarchy](/resource-manager/docs/cloud-platform-resource-hierarchy).\nAddress groups are categorized into the following types:\n\n- [Project-scoped address groups](#project-scoped-address-group)\n- [Organization-scoped address groups](#organization-scoped-address-group)\n\nAn address group can be either project-scoped or organization-scoped, but not\nboth.\n\n### Project-scoped address groups\n\nUse project-scoped address groups when you want to define your own list of IP\naddresses to be used within a project or a network to block or allow a list of\nchanging IP addresses. For example, if you want to define your own threat\nintelligence list and add it to a rule, create an address group with the\nrequired IP addresses.\nThe container type for project-scoped address groups is always set to `project`. For more information about how to create and modify project-scoped address groups, see [Use project-scoped address groups](/armor/docs/address-groups-using#project-scoped-address-group).\n\n### Organization-scoped address groups\n\n|\n| **Preview**\n|\n|\n| This product or feature is subject to the \"Pre-GA Offerings Terms\" in the General Service Terms section\n| of the [Service Specific Terms](/terms/service-terms#1).\n|\n| Pre-GA products and features are available \"as is\" and might have limited support.\n|\n| For more information, see the\n| [launch stage descriptions](/products#product-launch-stages).\nUse organization-scoped address groups when you want to define a central list of IP addresses that can be used in high-level rules to provide consistent control for the entire organization and reduce the overhead for individual network and project owners to maintain common lists, such as trusted services and internal IP addresses.\n\n\u003cbr /\u003e\n\nThe container type for organization-scoped address groups is always set to\n`organization`. For more information about how to create and modify\norganization-scoped address groups, see\n[Use organization-scoped address groups](/armor/docs/address-groups-using#organization-scoped-address-group).\n\n\nHow address groups work with security policies\n----------------------------------------------\n\nAddress groups simplify the configuration and maintenance of security policies\nbecause you can share each list of IP addresses across many security policies.\nConsider the following additional specifications when you use address groups\nwith security policies:\n\n- Address groups are only available for globally scoped [backend security policies](/armor/docs/security-policy-overview#backend-policies).\n- Organization-scoped address groups are available for both service-level security policies and hierarchical security policies.\n- The capacity of an address group is added to the total attribute count of the security policy where the address group is used. Make sure that you set the capacity to an appropriate value based on your use case.\n- To use address groups, your project must be enrolled in [Cloud Armor Enterprise](/armor/docs/armor-enterprise-overview). If you downgrade to standard billing, you can't create new address groups or modify existing address groups. You also can't create rules that reference an exsisting address group, and your security policies that reference address groups are frozen. This means that they are still active, but that you can't modify them until you delete all of the rules that reference an address group.\n\nWe recommend that you view the [quotas](/armor/quotas#address-group-quotas)\nand [limits](/armor/quotas#address-group-limits) for address groups.\n\nIn addition to configuring organization-scoped address groups for your backend\nsecurity policies, you can configure organization-scoped address groups for your\nhierarchical security policies. You can't use project-scoped address groups in any\nsecurity policies outside of the project in which they exist, but you can share\norganization-scoped address groups with security policies across your entire\norganization; this makes organization-scoped address groups with security\npolicies especially helpful when you use them with hierarchical security policies. For\nmore information about hierarchical security policies, see the\n[Hierarchical security policies overview](/armor/docs/hierarchical-policies-overview).\n\n### Examples\n\nThe following examples demonstrate how you might use address groups to help\nyou configure security policies:\n\n- Imagine that you have a network configuration in which you have three backend services, each of which has one security policy. In addition, you have a list of IP addresses that you know are malicious. When you create a `deny` rule in each security policy, you can create one address group and use it with all three security policies instead of adding the list of IP addresses to each security policy. Then, whenever you create a new security policy, you can use the address group again to make new rules.\n- Imagine that you have an organization with many projects that are grouped into folders, and you have three lists of IP addresses that each need access to only some of these folders. You can create three organization-scoped address groups, one for each list of IP addresses, and then create three hierarchical security policies. You can give each hierarchical security policy an `allow` rule that matches on one of the three address groups, then associate the hierarchical security policy with each folder that the allowed IP address group needs to access.\n\nWhat's next\n-----------\n\n- [Configure address groups](/armor/docs/address-groups-using)."]]
