이 문서에서는 액세스 수준 구현을 설명하고 허용 목록을 기준으로 서비스 경계 적용을 시작하기 위한 권장사항을 제공합니다.
워크로드의 테스트 실행 실행을 완료하면 허용 목록에 추가해야 하는 IP 주소와 ID의 목록이 표시됩니다. 일부 워크로드에는 기기 기반의 허용 목록이 필요할 수도 있습니다. 보호되는 Google Cloud 리소스에 대해 액세스 권한을 부여하려면 VPC 서비스 제어 액세스 수준을 사용하면 됩니다. 액세스 수준을 구현할 수 있는 실용적인 방법은 IP 주소, ID 또는 기기를 기반으로 합니다.
IP 기반 허용 목록의 액세스 수준에서는 공개 IP CIDR 범위만 사용할 수 있습니다. 이 메서드는 이 IP 범위에서 보호되는 모든 API를 허용하므로 이러한 IP를 지원하는 환경은 신뢰 및 제어가 가능해야 합니다. 이 허용 목록에 대한 일반적인 사용 방법은 온프레미스 네트워크에서 경계 액세스를 허용하는 것입니다. 다음 다이어그램은 IP 기반 허용 목록이 경계 액세스를 차단하고 허용하는 방법을 보여줍니다.
앞의 다이어그램에서 유효한 ID는 경계에 액세스를 시도합니다.
액세스 시도는 액세스 시도가 인터넷 IP 주소에서 시작되면 거부됩니다. 단, 회사의 공개 IP 주소에서 시작되는 경우 액세스가 허용됩니다.
이 시나리오의 변형은 다른 프로젝트 또는 조직에 배포된 비공개 리소스에서 경계 액세스를 허용하는 경우입니다. 이 사용 사례에서는 소스 프로젝트에 Cloud NAT 게이트웨이가 필요합니다.
Cloud NAT는 비공개 Google 액세스와 통합되어 리소스의 서브넷에서 비공개 Google 액세스를 자동으로 사용 설정하고 Cloud NAT 게이트웨이 외부 IP 주소를 사용하여 트래픽을 인터넷으로 라우팅하는 대신 Google API 및 서비스로의 트래픽을 내부로 유지합니다.
트래픽이 내부 Google 네트워크 내에서 라우팅되므로 AuditLog 객체의 RequestMetadata.caller_ip 필드가 gce-internal-ip로 수정됩니다. 이 경우 경계 액세스를 허용하려면 외부 소스 IP 주소를 기반으로 액세스 수준을 구성하는 대신 프로젝트 또는 서비스 계정과 같은 다른 속성을 기반으로 액세스를 허용하도록 인그레스 규칙을 구성해야 합니다.
호출자 ID에 따라 액세스 권한 부여
ID 기반 허용 목록을 구현하려면 허용 목록에 서비스 계정과 조직 최고 관리자를 추가합니다. 모든 IP 주소에서 이 ID에 대한 경계가 열려 있으므로 ID가 올바르게 보호되도록 해야 합니다. 또한 허용 목록에 추가한 서비스 계정에 키를 발급하지 않도록 해야 합니다. 경계에서 사용자 ID를 허용 목록 (허용 목록에 추가할 수 없는 경우)에 추가하는 것은 드문 일입니다.
경계 내의 리소스는 경계 내의 VM, 신뢰할 수 있는 온프레미스 네트워크 또는 신뢰할 수 있는 기기를 통해 액세스할 수 있습니다. VPC 서비스 제어는 Cloud Shell을 지원하지 않으므로 경계 내의 리소스에 액세스하려면 Cloud Workstations를 사용하는 것이 좋습니다.
호출자 기기 속성에 따른 액세스 자격 부여
신뢰할 수 있는 엔드포인트라고도 하는 기기 트러스트는 Chrome 브라우저 또는 Chromebook에 로그인한 유효한 조직 사용자가 필요합니다. 트러스트는 OS 로그인 세션에 적용됩니다. 예를 들어 Chrome 세션에 로그인되어 있고 Windows 세션을 실행하는 Windows 사용자는 보호된 경계 API에서 gcloud CLI 명령어를 성공적으로 호출할 수 있습니다.
그러나 동일한 머신의 다른 Windows 사용자 세션은 보호된 경계 API에서 명령어를 호출할 수 없습니다.
다음은 기기 트러스트 설정에 도움이 되는 기기 조건입니다.
확인된 Chrome OS는 유효한 조직 사용자가 안전하게 부팅된 Chromebook에 로그인했음을 나타내는, 매우 안전하고 암호화로 확인된 조건입니다. 권장 Tier 1 트러스트 조건입니다.
기기 액세스에 관리자 승인 필요는 액세스 권한이 부여되기 전에 Cloud ID 관리자가 승인하는 것을 허용합니다. 기본적으로 유효한 조직 사용자가 로그인된 기기는 자동으로 승인됩니다. 하지만 자동 승인 옵션은 해제하는 것이 좋습니다.
기업 소유 기기 필요는 일반적으로 BIOS에서 제공하는 OS의 일련번호를 검색하는 Chrome 에이전트를 사용합니다. 이 번호는 Cloud ID에 입력한 기존 일련번호와 일치해야 합니다.
Chrome OS가 아닌 기기에서는 일련번호를 승인할 수 없으므로(관리자 권한이 높은 사용자가 일련번호를 스푸핑할 수 있음) 이 조건은 Tier 2 확인 용도로만 사용하는 것이 좋습니다.
[[["이해하기 쉬움","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)"],[],[],null,["# Design access levels\n\nThis document describes access-level implementations and provides\nrecommendations for initiating service perimeter enforcement based on\nallowlists.\n\nWhen you complete a dry-run execution of workloads, you identify a list of IP\naddresses and identities that you need to add to an allowlist. You might also\nfind that some workloads need a device-based allowlist. To grant controlled\naccess to protected Google Cloud resources, you can use\nVPC Service Controls access levels. Some practical ways that you can\nimplement access levels are based on IP address, identity, or device.\n\nFor more information, see [Context-aware access with ingress rules](/vpc-service-controls/docs/context-aware-access).\n\n### Granting access based on source IP\n\nYou can only use\n[public IP CIDR ranges](/access-context-manager/docs/access-level-attributes#ip-subnetworks)\nin the access levels for IP-based allowlists. Since this method allows all\nprotected APIs from this IP range, the environment behind these IPs must be\ntrusted and controlled. A typical usage scenario for this allowlist is to allow\nperimeter access from on-premises networks. The following diagram shows how an\nIP-based allowlist blocks and allows perimeter access:\n\nIn the preceding diagram, a valid identity attempts to access the perimeter.\nThe access attempts are rejected when they originate from any internet IP\naddresses. However, access is allowed when it is sourced from the corporate\npublic IP addresses.\n\nA variation on this scenario is when you allow perimeter access from\nprivate resources deployed in a different project or organization. In this use\ncase, a Cloud NAT gateway is required in the source project.\n[Cloud NAT](/nat/docs/nat-product-interactions#interaction-pga)\nhas an integration with [Private Google Access](/vpc/docs/configure-private-google-access)\nthat automatically enables Private Google Access on the resource's subnet,\nand keeps the traffic to Google APIs and services internal, instead of routing\nit to the internet using the Cloud NAT gateway external IP address.\nAs the traffic is routed within the internal Google network, the\n`RequestMetadata.caller_ip` field of the `AuditLog` object is redacted to\n`gce-internal-ip`. To allow perimeter access in this case, you need to\nconfigure an ingress rule to allow access based on other attributes such as\nthe project or service account, instead of configuring an access level based\non the external source IP address.\n\n### Granting access based on caller identity\n\nTo implement an identity-based allowlist, you add service accounts and\n[organization super administrators](/resource-manager/docs/super-admin-best-practices)\nto an allowlist. The perimeter is open for these identities from any IP address,\nso you need to make sure that the identities are well-guarded. You also need to\nmake sure that you avoid minting keys for service accounts that you have added\nto an allowlist. It is uncommon to add user identities to an allowlist (groups\ncan't be added to an allowlist) on a perimeter.\n\nResources within the perimeter can be accessed through VMs within the\nperimeter, from trusted on-premises networks, or from trusted devices. We\nrecommend using [Cloud Workstations](/workstations/docs/overview) to access\nresources within perimeters because VPC Service Controls doesn't support\n[Cloud Shell](/vpc-service-controls/docs/supported-products#shell).\n| **Note:** You can only implement an identity-based allowlist using access levels by using the [gcloud CLI](/access-context-manager/docs/create-basic-access-level#members-example). You can use the Google Cloud console to configure ingress rules that implement identity-based access levels.\n\n### Qualifying access based on the caller device attributes\n\nDevice trust, also called *trusted endpoint*, relies on having a valid\norganization user signed in to a Chrome browser or to a Chromebook. The trust\napplies to the OS signed-in session. For example, a Windows user that is signed\nin and running a Chrome session (the browser doesn't need to be open) can\nsuccessfully call gcloud CLI commands on protected perimeter APIs.\nHowever, a different Windows user session on the same machine can't call\ncommands on the protected perimeter APIs.\n| **Note:** Caller device attributes are available only if you are using Chrome Enterprise Premium.\n\nThe following device conditions are useful to establish device trust:\n\n- [**Verified Chrome OS**](https://developers.google.com/chrome/verified-access/developer-guide)\n is a highly secure, cryptographically verified condition that indicates that\n a valid organization user is signed in to a securely booted Chromebook. This\n is a recommended tier 1 trust condition.\n\n- [**Require admin approval for device access**](https://support.google.com/cloudidentity/answer/7508418)\n allows Cloud Identity administrators to approve each device before any\n access is granted. By default, devices are auto-approved if they have a\n valid organization user signed in. However, we recommend turning off the\n auto-approval option.\n\n- **Require corp owned device** relies on the Chrome agent retrieving the\n serial number from the OS, which usually comes from the BIOS. This number\n must match existing serial numbers that you have\n [entered into Cloud Identity](https://support.google.com/cloudidentity/answer/7129612).\n\n Because the serial number isn't authoritative in non-Chrome OS devices, a\n user with elevated administrator privileges might be able to spoof the\n serial number. We recommend using this condition only as a tier 2 check.\n\n| **Note:** For trust to apply, the user and device must be in the same organization as the Google Cloud resources.\n\nFor a sample tracker for granting controlled access based on the conditions\ndiscussed in the preceding list, see\n[VPC Service Controls onboarding template - allowlist (PDF)](/static/solutions/vpc-service-controls-enterprise-best-practices-use-cases-template.pdf).\n\n### Initiate enforcement\n\nAfter you design the allowlist and update access levels, we recommend that you\nexecute the workloads again to confirm that there aren't any violations. If the\nworkloads execute without violations, you can initiate VPC Service Controls\nenforcement without impacting the applications.\n\nWhen you plan for enforcement, include the following:\n\n- Choose an enforcement date and communicate that date to all related teams.\n- Ensure that the security operations and incident response teams are aware of the deployment. Additionally, make sure that individuals with appropriate permissions inspect logs and approve additional allowlists, if necessary.\n- Ensure that the situation response team can open a Google Cloud support case, if any questions or issues arise.\n- Create or modify perimeter and access levels using automation tools like [Terraform](https://registry.terraform.io/modules/terraform-google-modules/vpc-service-controls/google/0.1.0/submodules/regular_service_perimeter). We recommend against performing these tasks manually.\n\nWhen you initiate enforcement, start by moving projects that are associated\nwith a single workload from the dry run perimeter to the live perimeter. Make\nsure to allow time for the application to run correctly while you observe the\nviolation logs. Repeat the process for remaining workloads one at a time.\n\nTo surface blocked violations, [configure an aggregated logging sink](/logging/docs/export/aggregated_sinks) that sends audit logs for all projects in the perimeter to BigQuery. Then, run the following query: \n\n SELECT\n receiveTimestamp, #time of violation\n Resource.labels.service, #protected Google Cloud service being blocked\n protopayload_auditlog.methodName, #method name being called\n resource.labels.project_id as PROJECT, #protected project blocking the call\n protopayload_auditlog.authenticationInfo.principalEmail, #caller identity\n protopayload_auditlog.requestMetadata.callerIp, #caller IP\n JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') as DRYRUN, #dry-run indicator\n JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.violationReason') as REASON, #reason for violation\n protopayload_auditlog.metadataJson, #raw violation entry\n FROM `BQ_DATASOURCE_NAME.cloudaudit_googleapis_com_policy_*`\n WHERE JSON_EXTRACT(protopayload_auditlog.metadataJson, '$.dryRun') is null #exclude logs from a dry-run perimeter\n\nWhat's next\n-----------\n\n- Learn how to [allow access to protected resources from outside the perimeter](/vpc-service-controls/docs/use-access-levels).\n- Learn how to [list, update, and delete service perimeters](/vpc-service-controls/docs/manage-service-perimeters)."]]
