이 페이지에서는 키 액세스 근거를 간략하게 설명합니다. 주요 액세스 사유는 투명성, 사용자 신뢰, 고객의 데이터 소유권에 대한 Google의 장기적인 노력의 일환입니다. 키 액세스 이유를 사용하면 등록된 Cloud Key Management Service(Cloud KMS) 키와 관련된 각 암호화 작업에 대한 액세스 이유 코드를 Google 시스템에서 생성하도록 지시할 수 있습니다.
키 액세스 근거는 다음과 같이 액세스 승인 및 액세스 투명성과 함께 작동합니다. 액세스 승인을 사용하면 Google 직원의 고객 데이터 액세스 요청을 승인할 수 있고, 액세스 투명성을 사용하면 고객 데이터에 액세스하는 시점에 관한 정보를 확인할 수 있으며, 키 액세스 근거는 고객이 관리하는 키로 암호화된 비활성 상태의 고객 데이터와의 모든 상호작용에 대한 키 액세스 제어를 제공합니다. 이러한 제품은 함께 고객 데이터에 대한 관리 액세스 요청을 제어하고 컨텍스트를 제공하는 액세스 관리 기능을 제공합니다.
개요
키 액세스 근거를 사용하면 Cloud Key Management Service (Cloud KMS) 키에 대한 정책을 설정하여 제공된 근거 코드에 따라 키 액세스 요청을 보고 승인하고 거부할 수 있습니다.
일부 외부 키 관리 파트너의 경우 Cloud KMS가 아닌 외부 키 관리자가 독점적으로 시행하도록 Google Cloud 외부에 키 액세스 근거 정책을 구성할 수 있습니다.
Google Cloud 저장 데이터 암호화는 데이터가 저장된 서비스 외부에 있는 암호화 키로Google Cloud 에 저장된 데이터를 암호화하는 방식으로 작동합니다. 예를 들어 Cloud Storage에서 데이터를 암호화하면 서비스는 저장된 암호화 정보만 저장하는 반면 키는 Cloud KMS(고객 관리 암호화 키(CMEK)를 사용하는 경우) 또는 외부 키 관리자(Cloud EKM을 사용하는 경우)에 저장된 데이터를 암호화하는 데 사용됩니다.
Google Cloud 서비스를 사용하는 경우 설명된 대로 애플리케이션이 계속 작동해야 하며 이렇게 하려면 데이터를 복호화해야 합니다.
예를 들어 BigQuery를 사용하여 쿼리를 실행하는 경우 BigQuery 서비스에서 데이터를 분석하려면 데이터를 복호화해야 합니다. BigQuery는 필요한 데이터를 가져오도록 키 관리자에게 복호화 요청을 보내 이를 수행합니다.
내 키에 액세스하는 이유
암호화 키는 Google Cloud에서 자체 요청과 워크로드를 처리하는 동안 자동화된 시스템에서 가장 자주 액세스됩니다.
고객이 시작한 액세스 및 자동화된 시스템 액세스 외에도 Google 직원은 다음과 같은 이유로 암호화 키를 사용하는 작업을 시작해야 할 수 있습니다.
데이터 백업: 재해 복구를 위해 데이터를 백업하기 위해 Google에서 암호화 키에 액세스해야 할 수 있습니다.
지원 요청 해결: Google 직원은 지원 제공에 대한 계약상 의무를 이행하기 위해 데이터를 복호화해야 할 수 있습니다.
시스템 관리 및 문제 해결: Google 직원은 복잡한 지원 요청 또는 조사에 필요한 기술적 디버깅을 수행하기 위해 암호화 키를 사용하는 작업을 시작할 수 있습니다. 스토리지 장애 또는 데이터 손상을 해결하기 위해 액세스가 필요할 수도 있습니다.
데이터 무결성 및 규정 준수를 보장하고 사기 및 악용으로부터 보호: 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"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eKey Access Justifications provides control over access to at-rest Customer Data encrypted by customer-managed keys, allowing you to view, approve, or deny key access requests based on provided justification codes.\u003c/p\u003e\n"],["\u003cp\u003eGoogle personnel may require access to encryption keys for reasons such as data backup, support request resolution, system troubleshooting, ensuring data integrity, compliance, and maintaining system reliability.\u003c/p\u003e\n"],["\u003cp\u003eKey Access Justifications works with Cloud EKM, Cloud HSM, and Cloud KMS software keys and provides a reason each time these keys are accessed, for both service-based access and direct API access.\u003c/p\u003e\n"],["\u003cp\u003eKey Access Justifications is enabled by default when you create a new Assured Workloads folder with a control package that includes it, but can take up to 24 hours to enable with external key managers.\u003c/p\u003e\n"],["\u003cp\u003eKey Access Justifications applies to operations on encrypted data and the transition from data-at-rest to data-in-use, and it integrates with Access Approval, ensuring that key access is justified and authorized for signed access approval requests.\u003c/p\u003e\n"]]],[],null,["# Overview of Key Access Justifications\n=====================================\n\nThis page provides an overview of Key Access Justifications. Key Access Justifications is a part of\nGoogle's long-term commitment to transparency, user trust, and customer\nownership of their data. Key Access Justifications directs Google systems to generate access\n[justification codes](/assured-workloads/key-access-justifications/docs/justification-codes)\nfor each cryptographic operation involving enrolled Cloud Key Management Service\n(Cloud KMS) keys.\n\nKey Access Justifications works alongside\n[Access Approval](/assured-workloads/access-approval/docs/overview)\nand [Access Transparency](/assured-workloads/access-transparency/docs/overview) in the\nfollowing way: Access Approval lets you authorize requests from Google\npersonnel to access [Customer Data](/terms/data-processing-addendum),\nAccess Transparency helps you discover information about when Customer Data is\naccessed, and Key Access Justifications provides key access control for all interactions with\nat-rest Customer Data that is encrypted by a customer-managed key. Together,\neach of these products provide access management capabilities that give you\ncontrol over and context for administrative requests to access Customer Data.\n\nOverview\n--------\n\nKey Access Justifications lets you set a policy on Cloud Key Management Service (Cloud KMS) keys to\nview, approve, and deny key access requests depending on the provided\n[justification code](/assured-workloads/key-access-justifications/docs/justification-codes).\nFor select external key management partners, you can configure Key Access Justifications\npolicies outside of Google Cloud to be exclusively enforced by the external key\nmanager rather than by Cloud KMS.\n\nDepending on the\n[Assured Workloads control package](/assured-workloads/docs/control-packages)\nyou choose, the following Key Access Justifications features are available:\n\n- For select [regional control packages](/assured-workloads/docs/control-packages#regional-controls), *Key Access Transparency* logs these justification codes in your Cloud KMS [audit logs](/kms/docs/audit-logging).\n- For select regional, [regulatory](/assured-workloads/docs/control-packages#regulatory-controls), or [sovereign](/assured-workloads/docs/control-packages#sovereign-controls) control packages, Key Access Justifications lets you set a policy on your keys to approve or deny key access requests depending on the provided justification code. Some regional data boundaries provide this feature in addition to Key Access Transparency.\n- For select sovereign control packages, you can use a supported external key management partners to configure Key Access Justifications policies outside of Google Cloud. These policies are exclusively enforced by the external key manager rather than by Cloud KMS.\n\nIn addition to these features, the Assured Workloads control package\nyou choose will also determine which of the following Cloud KMS key\ntypes are available:\n\n- [Cloud EKM keys](/kms/docs/ekm#overview)\n- [Cloud HSM keys](/assured-workloads/key-access-justifications/docs/configure-kaj)\n- [Cloud KMS software keys](/assured-workloads/key-access-justifications/docs/configure-kaj)\n\nHow encryption at rest works\n----------------------------\n\nGoogle Cloud encryption at rest works by encrypting your data stored on\nGoogle Cloud with an encryption key that lives outside the service where the\ndata is stored. For example, if you encrypt data in Cloud Storage, the\nservice only stores the encrypted information you have stored, whereas the key\nused to encrypt that data is stored in Cloud KMS (if you are using\ncustomer-managed encryption keys (CMEK)) or in your external key manager (if you\nare using Cloud EKM).\n\nWhen you use a Google Cloud service, you want your applications to\ncontinue working as described, and this will require your data to be decrypted.\nFor example, if you run a query using BigQuery, the BigQuery\nservice needs to decrypt your data to be able to analyze it. BigQuery\naccomplishes this by making a decryption request to the key manager to get the\nrequired data.\n\nWhy would my keys be accessed?\n------------------------------\n\nYour encryption keys are most often accessed by automated systems while\nservicing your own requests and workloads on Google Cloud.\n\nIn addition to customer-initiated accesses and automated system accesses, a\nGoogle employee might need to initiate operations which use your encryption keys\nfor the following reasons:\n\n- **Back up your data**: Google might need to access your encryption keys to\n back up your data for disaster recovery reasons.\n\n- **Resolve a support request**: A Google employee might need to decrypt your\n data to fulfill the contractual obligation of providing support.\n\n- **Manage and troubleshoot systems**: Google personnel can initiate operations\n which use your encryption keys to perform technical debugging needed for a\n complex support request or investigation. Access might also be needed to\n remediate storage failure or data corruption.\n\n- **Ensure data integrity and compliance, and protect against fraud and abuse**:\n Google might need to decrypt data for the following reasons:\n\n - To ensure the safety and security of your data and accounts.\n - To make sure that you are using Google services in compliance with the [Google Cloud Terms of Service](/terms).\n - To investigate complaints by other users and customers, or other signals of abusive activity.\n - To verify that Google Cloud services are being used in accordance with applicable regulatory requirements, such as anti-money laundering regulations.\n- **Maintain system reliability**: Google personnel can request access to\n investigate that a suspected service outage doesn't affect you. Also, access\n might be requested to ensure backup and recovery from outages or system\n failures.\n\nFor the list of justification codes, see\n[justification reason codes for Key Access Justifications](/assured-workloads/key-access-justifications/docs/justification-codes).\n\nManaging access to your keys\n----------------------------\n\nKey Access Justifications provides a reason every time your Cloud KMS-managed keys\nor externally managed keys are accessed. When your key is used for any\ncryptographic operation, you receive a justification for both service-based\naccess (for supported services) and direct API access.\n\nAfter your key projects are enrolled in Key Access Justifications, you immediately begin\nreceiving justifications for every key access for new keys. For previously\nexisting keys, you will begin receiving justifications for every key access\nwithin 24 hours.\n\nEnabling Key Access Justifications\n----------------------------------\n\nKey Access Justifications can only be used with Assured Workloads, and is enabled by\ndefault when you create a new Assured Workloads folder configured for\na control package that includes Key Access Justifications. See the\n[Assured Workloads overview](/assured-workloads/docs/overview) for more\ninformation.\n| **Note:** It can take up to 24 hours to enable Key Access Justifications with external key managers after you've created your Assured Workloads folder. Therefore, we recommend that you don't reject key access requests in production environments during this time. There is no delay when using non-external Cloud KMS keys.\n\nKey Access Justifications exclusions\n------------------------------------\n\nKey Access Justifications only applies to the following situations:\n\n- **Operations on encrypted data**: For the fields within a given service that are encrypted by a customer-managed key, refer to the service's documentation.\n- **The transition from data-at-rest to data-in-use**: While Google continues to apply protections to your data-in-use, Key Access Justifications only governs the transition from data-at-rest to data-in-use.\n\nThe following Compute Engine and Persistent Disk features are exempted when used\nwith CMEK:\n\n- [Local SSDs](/compute/docs/disks#localssds)\n- [Automatic restart](/compute/docs/instances/setting-vm-host-options)\n- [Machine image operations](/compute/docs/machine-images/create-machine-images)\n\nKey Access Justifications with Access Approval\n----------------------------------------------\n\nFor workloads with Access Approval enabled with a custom signing key,\nKey Access Justifications will also apply to processing signed access approval requests.\nAccess Approval requests can only be processed if the associated\njustification for the key access associated is also permitted by the key's\nKey Access Justifications policy. When a customer signs an Access Approval request,\nthe associated justification is reflected in the signing request for the\napproval.\n\nAll Customer Data accesses that occur from an approved, signed access approval\nrequest will appear in Access Transparency logs linked to the approval request.\n\nWhat's next\n-----------\n\n- See [which services](/assured-workloads/docs/supported-products) are supported by Assured Workloads for [Sovereign Controls for EU](/assured-workloads/docs/control-packages#eu-sovereignty-controls) and the [list of additional KAJ-supported services](/assured-workloads/key-access-justifications/docs/supported-services).\n- Read how to [view and act on justifications](/assured-workloads/key-access-justifications/docs/view-justifications).\n- Read where you can [get support for Key Access Justifications](/assured-workloads/key-access-justifications/docs/getting-support).\n- Learn [what an Access Approval request looks like](/assured-workloads/access-approval/docs/approval-request-details).\n- Learn about the [core principles upon which controls that prevent unauthorized administrative access are based](/assured-workloads/cloud-provider-access-management/docs/administrative-access)."]]
