您只能在 IP 型許可清單的存取層級中，使用公開 IP CIDR 範圍。由於這個方法允許來自此 IP 範圍的所有受保護 API，因此這些 IP 背後的環境必須受到信任和控管。這份允許清單的典型用途是允許從內部部署網路存取周邊。下圖顯示 IP 位址許可清單如何封鎖及允許存取範圍：
在上圖中，有效身分嘗試存取周邊。如果存取嘗試來自任何網際網路 IP 位址，系統會拒絕。不過，如果存取要求來自公司公開 IP 位址，系統就會允許存取。
另一種情況是允許從部署在不同專案或機構的私人資源存取服務範圍。在本使用案例中，來源專案必須有 Cloud NAT 閘道。Cloud NAT 與私人 Google 存取權整合後，會自動在資源的子網路上啟用私人 Google 存取權，並將 Google API 和服務的流量保留在內部，而不是使用 Cloud NAT 閘道的外部 IP 位址將流量傳送到網際網路。由於流量是在 Google 內部網路中轉送，AuditLog 物件的 RequestMetadata.caller_ip 欄位會經過修訂，顯示為 gce-internal-ip。如要在這種情況下允許存取範圍，您需要設定輸入規則，根據專案或服務帳戶等其他屬性允許存取，而不是根據外部來源 IP 位址設定存取層級。
根據來電者身分授予存取權
如要實作以身分為依據的允許清單，請將服務帳戶和機構超級管理員新增至允許清單。這些身分可從任何 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-04 (世界標準時間)。"],[],[],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)."]]
