本页面简要介绍了访问权限审批。
Access Approval 是 Google 对透明度、用户信任和客户对其数据的所有权所作出的长期承诺的一部分。Access Transparency 可帮助您了解 Google 人员访问客户数据的时间,而 Access Approval 可让您授权此类访问请求。此外,它还提供了更精细的控制功能,可控制 Google 何时可以访问客户数据。对于使用使用客户管理的加密密钥 (CMEK) 签名的访问权限审批的客户,Google 还通过密钥访问权限证明为用户提供对密钥访问权限请求的公开透明和控制功能。
这些产品各有千秋,提供的访问权限管理功能可让您控制对客户数据的管理请求,并为这些请求提供背景信息。
概览
Access Approval 可确保 Cloud Customer Care 和工程团队每次在需要访问您的客户数据时均需要您的明确批准。每个审批请求都会经过加密签名和验证,以确保其完整性。我们可能会随时撤消有效的访问权限审批请求。
Access Approval 在 Access Transparency 日志提供的透明度之上还提供了一层控制。Access Transparency 会提供有关 Google 员工在访问您的客户数据时所采取的操作的日志。“访问权限审批”还会显示已批准、已拒绝、已撤消或已过期的所有请求的历史记录。
如果您希望能够直接管理 Google 员工对您客户数据的访问权限,我们建议您使用 Access Approval。如需详细了解 Google 员工可能需要访问客户数据的原因以及Google Cloud的特权访问原则,请参阅 Google Cloud中的特权访问。
Access Approval 的工作方式
Access Approval 的运作方式是,要求 Google 管理员在访问客户数据之前,先向授权的客户管理员请求并获得批准。系统会使用预配置的电子邮件或 Pub/Sub 消息通知客户有待批准的请求。
您可以使用消息中的信息,在 Google Cloud 控制台内或通过使用 Access Approval API 批准或拒绝 Access Approval 请求。只有在访问权限审批请求获得批准后,我们才会授予访问权限。访问权限审批会使用加密密钥对访问权限请求进行签名,其签名用于验证请求的完整性。您可以使用 Google 管理的签名密钥,也可以自带签名密钥。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-18。"],[[["\u003cp\u003eAccess Approval requires Google personnel to obtain explicit customer approval before accessing Customer Data, enhancing control and transparency.\u003c/p\u003e\n"],["\u003cp\u003eIt works by sending approval requests to authorized customer administrators, who can approve or deny them via the Google Cloud console or API, ensuring that access is only granted post-approval.\u003c/p\u003e\n"],["\u003cp\u003eAccess Approval provides an additional control layer over Access Transparency by logging all access requests (approved, denied, revoked, or expired) and by allowing for revocation of active access.\u003c/p\u003e\n"],["\u003cp\u003eCustomers can use either a Google-managed key or a custom-managed encryption key for signing access requests, with the option to use Key Access Justifications for externally managed keys.\u003c/p\u003e\n"],["\u003cp\u003eAccess Approval can be enabled for all supported Google Cloud services automatically or limited to only services in the GA launch stage, or individually selecting the specific services.\u003c/p\u003e\n"]]],[],null,["# Overview of Access Approval\n===========================\n\nThis page provides an overview of Access Approval.\nAccess Approval is a part of Google's long-term commitment to\ntransparency, user trust, and customer ownership of their data.\n[Access Transparency](/assured-workloads/access-transparency/docs/overview) helps you\nto discover information about when Google personnel access\n[Customer Data](/terms/data-processing-addendum), and Access Approval\nlets you authorize such access requests. In addition, it provides enhanced\nlevels of granular control over when Google may access Customer Data. For\ncustomers who use access approvals that are signed with a customer-managed\nencryption key (CMEK), Google also provides users with visibility and control to\nkey access requests through\n[Key Access Justifications](/assured-workloads/key-access-justifications/docs/overview).\n\nTogether, each of these products provide access management capabilities that\ngive you control over and context for administrative requests to access Customer\nData.\n\nOverview\n--------\n\nAccess Approval ensures that Cloud Customer Care and engineering teams\nrequire your explicit approval whenever they need to access your Customer Data.\nEach approval request is cryptographically signed and verified to ensure its\nintegrity. Active access approval requests may be revoked at any time.\n\nAccess Approval provides an additional layer of control on top of the\ntransparency that Access Transparency logs provide. Access Transparency provides logs that\ncapture the actions Google personnel take when accessing your Customer Data.\nAccess Approval also provides a historical view of all requests that\nwere approved, dismissed, revoked, or expired.\n\nIf you want the ability to directly manage Google personnel's access to your\nCustomer Data, we recommend using Access Approval. For more information\nabout why Google personnel might need to access Customer Data and about\nGoogle Cloud's privileged access principles, see\n[Privileged access at Google Cloud](/assured-workloads/access-transparency/docs/privileged-access).\n\nHow Access Approval works\n-------------------------\n\nAccess Approval works by requiring Google Administrators to request and\nreceive an approval from an authorized customer administrator prior to accessing\nCustomer Data. Customers are notified of a pending approval request using a\npreconfigured email or a Pub/Sub message.\n\nUsing the information in the message, the Access Approval request may\nbe approved or denied within the Google Cloud console or by using the\n[Access Approval API](/assured-workloads/access-approval/docs/reference/rest).\nAccess is granted only after the Access Approval request is approved.\nAccess Approval uses a cryptographic key to sign the access request,\nand its signature is used to verify the integrity of the request. You can either\nuse a Google-managed signing key or bring your own signing key.\n\nHow Access Approval works with Assured Workloads\n------------------------------------------------\n\nWhen using Access Approval with an Assured Workloads\ncompliance boundary, the Assured Workloads personnel access assurances\napply before Access Approval is evaluated. The Access Approval\naccess request may contain non-compliant parameters (such as the `global`\nlocation); however, these conditions are secondary to the\nAssured Workloads workload configuration.\n\nFor example, if a Canada Protected B folder owner is sent an\nAccess Approval request for the `global` location, this request is\nfirst applied Canada Protected B restrictions-and those personnel are not\napplied further Access Approval regional restrictions.\n\n[Using a Google-managed signing key](/assured-workloads/access-approval/docs/review-approve-access-requests-google-keys)\nis the default option. If you want to use your own signing key, you can create\none using Cloud KMS, or bring an externally-managed key using\nCloud EKM. For more information about getting started with using a\ncustom signing key, see\n[Set up Access Approval using a custom signing key](/assured-workloads/access-approval/docs/review-approve-access-requests-custom-keys).\n| **Note:** The support response time increases by the duration that Customer Care spends waiting for your approval. We recommend being cautious when enabling Access Approval for projects and services where you might require high service availability and rapid response by Customer Care.\n\nGoogle services that support Access Approval\n--------------------------------------------\n\nAccess Approval lets you select the Google Cloud services you want to\nenroll in Access Approval. Access Approval requests your\nconsent only for access requests to Customer Data stored in the services you\nselect.\n\nYou have the following options for enrolling services in\nAccess Approval:\n\n- Automatically enable Access Approval for all supported services, regardless of its [product launch stage](/products#product-launch-stages) (such as Preview or General Availability (GA)). Selecting this option also automatically enrolls all the services that Access Approval supports in the future. This is the default option.\n- Only enable Access Approval for services in the GA launch stage. Selecting this option also automatically enrolls all the GA services that Access Approval supports in the future.\n- Choose the specific services you want to enroll in Access Approval.\n\nSee\n[Supported services](/assured-workloads/access-approval/docs/supported-services)\nfor a complete list of services that Access Approval supports.\n\nAccess Approval exclusions\n--------------------------\n\n[Access Transparency's exclusions](/assured-workloads/access-transparency/docs/exclusions)\nare also applicable to Access Approval.\n\nIn addition to these exclusions, the approval request may be automatically\napproved without the customer's action to address time-sensitive outages. Such\nauto-approved Access Approval requests are logged in an\n`auto approved` state.\n\nAuto-approval is automatically disabled for all workloads deployed with\nAssured Workloads Sovereign Controls or\n[Sovereign Controls by Partners](/sovereign-controls-by-partners/docs).\n\nCustomers seeking to ensure that administrative access requests can only be\nprocessed when the approvals are signed with a customer-managed key may\nconfigure Access Approval with a customer-managed key and use\nKey Access Justifications.\n\nRequirements for using Access Approval\n--------------------------------------\n\nYou can enable Access Approval for a\n[Google Cloud project](/resource-manager/docs/cloud-platform-resource-hierarchy#projects),\n[folder](/resource-manager/docs/cloud-platform-resource-hierarchy#folders), or\n[organization](/resource-manager/docs/cloud-platform-resource-hierarchy#organizations).\nBefore enabling Access Approval, you must\n[enable Access Transparency](/assured-workloads/access-transparency/docs/enable) for\nyour organization.\n\nAfter enabling Access Transparency, you can use the Google Cloud console to enable\nAccess Approval. To learn how to set up Access Approval, see\nthe [quickstarts](/assured-workloads/access-approval/docs/quickstart).\n\n### Requirements for a custom signing key\n\nUsing the default Google-managed signing key doesn't require any additional\nconfiguration. To use your own signing key, you can either create an asymmetric\nsigning key using [Cloud Key Management Service](/kms/docs) or use [Cloud External Key Manager](/kms/docs/ekm)\nto host an externally-managed signing key. For the limitations related to\nasymmetric signing keys supported by Cloud EKM, see\n[Restrictions for asymmetric signing keys](/kms/docs/ekm#restrictions-asymmetric).\n\nIf you want to use an externally-managed signing key, we recommend that you\nenable Cloud EKM. For more information about using Cloud EKM for\nmanaging keys that aren't stored in Google Cloud, see\n[Cloud EKM overview](/kms/docs/ekm#overview).\n| **Note:** Access Approval aims to provide a justification for every request to access your Customer Data stored on Google Cloud. Similarly, Key Access Justifications aims to provide a justification for every request to access your externally-managed keys. Cloud EKM brings your externally-managed keys into Google Cloud for signing access requests. If you want to be notified about the reason for every access to your externally-managed signing keys, you can use Key Access Justifications. For more information about Key Access Justifications, see [Overview of Key Access Justifications](/assured-workloads/key-access-justifications/docs/overview).\n\nWhat's next\n-----------\n\n- See the [quickstarts](/assured-workloads/access-approval/docs/quickstart) to set up Access Approval.\n- Learn how to [use Terraform to set up Access Approval](/assured-workloads/access-approval/docs/using-terraform).\n- Learn how to [approve access requests](/assured-workloads/access-approval/docs/approve-requests).\n- Learn about [Access Approval pricing](/assured-workloads/access-approval/pricing).\n- See the list of [Google Cloud services that Access Approval supports](/assured-workloads/access-approval/docs/supported-services)."]]