이 페이지에서는 Cloud Storage XML API에 대한 요청을 인증하는 데 사용할 수 있는 해시 기반 메시지 인증 코드(HMAC) 키를 설명합니다. HMAC 키는 다른 클라우드 스토리지 제공업체와 Cloud Storage 간에 데이터를 이동하려는 경우에 유용합니다. HMAC 키를 사용하면 Cloud Storage에 액세스할 때 기존 코드를 재사용할 수 있기 때문입니다.
개요
HMAC 키는 계정(일반적으로 서비스 계정)과 연결된 사용자 인증 정보의 유형 중 하나입니다. HMAC 키를 사용하면 HMAC-SHA256 서명 알고리즘을 사용해서 서명을 만들 수 있습니다. 이렇게 만든 서명은 Cloud Storage XML API에 대한 요청에 포함됩니다. 서명은 HMAC 키와 연결된 계정이 지정된 요청을 승인했음을 나타냅니다.
서비스 계정의 HMAC 키를 만들 때 키에 대한 보안 비밀은 한 번만 제공됩니다. 보안 비밀과 연결된 액세스 ID는 안전하게 저장해야 합니다. 보안 비밀을 분실한 경우에는 사용자 또는 Google Cloud누구도 이를 복구할 수 없으며, 요청을 계속 인증하기 위해서는 서비스 계정에 대해 새 HMAC 키를 만들어야 합니다.
사용자 계정의 HMAC 키를 만들려면 사용자 계정으로Google Cloud 콘솔에 로그인하고 resourcemanager.projects.get IAM 권한이 있는 프로젝트의 Cloud Storage 설정 메뉴에 있는 상호 운용성 탭으로 이동합니다. 키를 만든 후에는 resourcemanager.projects.get 권한이 있는 프로젝트의 상호 운용성 탭에서 키의 보안 비밀을 볼 수 있습니다.
보안 비밀 저장을 위한 권장사항
HMAC 키 보안 비밀을 공유하지 마세요. HMAC 키 보안 비밀은 다른 액세스 사용자 인증 정보와 마찬가지로 취급해야 합니다.
보안 권장사항으로 키 순환 과정에서 키를 정기적으로 변경해야 합니다.
HMAC 키를 다른 사람이 사용하고 있다고 생각되면 영향을 받는 HMAC 키를 즉시 삭제하여 새로운 키를 만들어야 합니다.
HMAC 키를 변경할 때는 이전 키를 삭제하기 전에 코드를 새 HMAC 키로 업데이트해야 합니다. HMAC 키를 삭제하면 키가 즉시 무효화되며 복구할 수 없습니다.
제한사항
HMAC 키는 JSON API가 아닌 XML API에 대한 요청을 수행하는 경우에만 사용할 수 있습니다.
서비스 계정별로 최대 10개의 HMAC 키가 있을 수 있습니다. 삭제된 키는 이 한도에 포함되지 않습니다.
생성 후 서비스 계정 HMAC 키를 사용할 수 있게 될 때까지 최대 60가 걸릴 수 있습니다. 서비스 계정을 삭제한 후에도 해당 계정에 속한 HMAC 키는 최대 5분 동안 계속 작동할 수 있습니다. 반대로 키가 속하는 서비스 계정을 삭제 취소한 후 HMAC 키가 다시 사용할 수 있을 때까지 최대 5분 정도 걸릴 수 있습니다.
리소스에 restrictAuthTypes 제약조건을 사용 설정하면 해당 리소스에 지정된 계정 유형의 HMAC 키를 더 이상 만들거나 활성화할 수 없습니다.
사용자 계정 HMAC 키에서 마이그레이션
특히 프로덕션 워크로드의 경우에는 일반적으로 HMAC 키와 사용자 계정을 연결하는 것보다 HMAC 키와 서비스 계정을 연결하는 것이 더 적합합니다.
서비스 계정은 더 효율적인 관리 감독 기능을 제공하므로 개별 사용자가 보유한 계정에 대한 보안 및 개인정보 보호 관련 사항을 삭제할 수 있습니다.
서비스 계정은 사용자의 프로젝트 참여 중단이나 퇴사로 인해 사용자 계정 사용이 중지되는 경우와 같이 사용자 계정 사용과 관련된 서비스 중단의 위험을 줄여줍니다.
현재 사용자 계정에서 HMAC 키를 사용 중이지만 서비스 계정으로 마이그레이션하려는 경우 다음 사항에 유의하세요.
서비스 계정은 Cloud Storage에서 작업을 수행하는 데 필요한 필수 권한을 부여받아야 합니다.
객체 작업에 필요한 광범위한 권한은 Storage Object Admin 역할에 포함되어 있지만 다른 작업을 수행하기 위해서는 별도의 서비스 계정이 필요할 수 있습니다. 예를 들어 읽기에 Storage Object Viewer 역할이 포함된 서비스 계정 1개, 쓰기에는 Storage Object Creator 역할이 포함된 다른 서비스 계정이 필요할 수 있습니다.
업데이트를 프로덕션에 푸시하기 전에 서비스 계정이 예상대로 작동하는지 테스트해야 합니다.
프로덕션 작업을 서비스 계정 HMAC 키로 전환한 후 다음 Cloud Monitoring 측정항목에서 사용자 계정과 연결된 HMAC 키가 더 이상 사용되지 않는지 확인해야 합니다.
측정항목
설명
storage.googleapis.com/authn/authentication_count
요청 인증을 위해 HMAC 키가 사용된 횟수입니다.
마이그레이션 진행 중에 계속 사용되는 사용자 계정 키를 추적하도록 다음 라벨을 설정할 수 있습니다.
access_id: 요청을 수행한 액세스 ID를 식별합니다. 또한 키 순환 중 access_id를 사용하여 한 키에서 다른 키로의 트래픽 이동을 감시할 수 있습니다.
authentication_method: 키가 사용자 계정 또는 서비스 계정 키인지 확인합니다.
사용자 계정 HMAC 키가 더 이상 사용되지 않는 것을 확인했으면 해당 HMAC 키를 삭제해야 합니다. 이렇게 하면 데이터에 대한 부적절한 액세스의 위험이 줄어듭니다.
사용자 계정이 Cloud Storage 리소스에 액세스하는 용도로 더 이상 사용되지 않으면 이 계정에 포함된 Cloud Storage에 대한 액세스 권한을 취소합니다.
[[["이해하기 쉬움","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-05(UTC)"],[],[],null,["# HMAC keys\n\n[Setup](/storage/docs/authentication/managing-hmackeys)\n\nThis page discusses hash-based message authentication code (HMAC) keys, which\nyou can use to authenticate requests to the [Cloud Storage XML API](/storage/docs/xml-api/overview). HMAC\nkeys are useful when you want to move data between other cloud storage providers\nand Cloud Storage, because HMAC keys allow you to\n[reuse your existing code](/storage/docs/aws-simple-migration) to access Cloud Storage.\n\nOverview\n--------\n\nAn HMAC key is a type of *credential* associated with an account, typically a\nservice account. You use an HMAC key to create [*signatures*](/storage/docs/authentication/signatures) using the\nHMAC-SHA256 [*signing algorithm*](/storage/docs/authentication/signatures#signing-process). The signatures you create are then\nincluded in requests to the Cloud Storage XML API. Signatures show that\na given request is authorized by the account associated with the HMAC key.\n| **Note:** HMAC keys are separate from the normal service account keys used by Google Cloud, which are RSA keys. HMAC keys cannot be used to generate OAuth 2.0 tokens; however, RSA keys can be used to generate both OAuth 2.0 tokens and Cloud Storage XML API signatures.\n\nHMAC keys have two primary pieces, an *access ID* and a *secret*.\n\n- **Access ID**: An alphanumeric string linked to a specific account.\n\n - When linked to a service account, the string is 61 characters in length.\n\n - When linked to a user account, the string is 24 characters in length.\n\n The following shows an example of an access ID:\n\n `GOOGTS7C7FUP3AIRVJTE2BCDKINBTES3HC2GY5CBFJDCQ2SYHV6A6XXVTJFSA`\n- **Secret**: A 40-character Base-64 encoded string that is linked to a specific\n access ID. A secret is a pre-shared key that only you and\n Cloud Storage know. You use your secret to create signatures as\n part of the authentication process. The following shows an example of a secret:\n\n `bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ`\n\nBoth the access ID and secret uniquely identify an HMAC key, but the secret is\nmuch more sensitive information, because it's used to create signatures.\n\nYou can optionally enable the [`restrictAuthTypes` constraint](/storage/docs/org-policy-constraints#restrict-auth-types) on a\nresource, which restricts access for requests signed by HMAC keys.\n| **Caution:** When you delete an account, any HMAC keys associated with the account are also deleted. To protect against outages, [disable an account](/iam/docs/service-accounts-disable-enable#disabling) and confirm that your traffic is unaffected prior to deleting the account.\n\n### Storing secrets\n\nWhen you [create an HMAC key for a service account](/storage/docs/authentication/managing-hmackeys#create), you are given\nthe secret for the key once. You must securely store the secret, along with the\nassociated *access ID*. If you lose the secret, it cannot be retrieved by you\nor Google Cloud, and you must create a new HMAC key for the service account\nto continue authenticating requests.\n\nTo create an HMAC key for a user account, you must be logged into the\nGoogle Cloud console with the user account and go to the **Interoperability**\ntab in the Cloud Storage **Settings** menu of a project for which you\nhave the `resourcemanager.projects.get` IAM permission. Once\ncreated, you can view the key's secret from the **Interoperability** tab of any\nproject for which you have the `resourcemanager.projects.get` permission.\n\n#### Best practices for storing secrets\n\n- Do not share your HMAC key secret. You should treat HMAC key secrets as you\n would any set of access credentials.\n\n- As a security best practice, you should regularly change your keys as part of\n a key rotation.\n\n- If you think someone else is using your HMAC keys, you should immediately\n delete the affected HMAC keys and create new ones.\n\n- When changing HMAC keys, you should update your code with the new HMAC keys\n before you delete the old keys. When you delete HMAC keys, they become\n immediately invalid, and they are not recoverable.\n\n### Restrictions\n\n- HMAC keys can only be used to make requests to the XML API, not the JSON API.\n\n- You can have a maximum of 10 HMAC keys per service account. Deleted\n keys do not count towards this limit.\n\n- After creation, it can take up to 60 seconds for a service account HMAC key\n to become useable. After [deleting](/iam/docs/service-accounts-delete-undelete) a service account, the HMAC keys\n that belong to it might continue to work for up to 5 minutes. Conversely,\n it can take up to 5 minutes for HMAC keys to become usable again after\n [undeleting](/iam/docs/service-accounts-delete-undelete) the service account that owns them.\n\n- If you enable the `restrictAuthTypes` constraint on a resource, you can no\n longer create or activate HMAC keys for the specified account\n type in that resource.\n\nMigration from user account HMAC keys\n-------------------------------------\n\nGenerally, associating HMAC keys with service accounts are a better option than\ndoing so with user accounts, particularly for production workloads:\n\n- Service accounts allow for better administrative oversight, and they\n eliminate the security and privacy implications of accounts held by\n individual users.\n\n- Service accounts reduce the risk of service outages associated with relying\n on user accounts, such as when a user account is disabled because the user\n leaves the project or company.\n\nIf you currently use HMAC keys with user accounts but want to migrate to\nservice accounts, keep the following in mind:\n\n- Your project must [have a service account](/iam/docs/creating-managing-service-accounts#creating_a_service_account) and [have an HMAC key](/storage/docs/authentication/managing-hmackeys#create)\n associated with it.\n\n- The service account must be granted the [required permissions](/storage/docs/access-control/iam-permissions) to perform\n actions in Cloud Storage.\n\n Broad permission to work with objects is contained in the\n `Storage Object Admin` role, but you may want to have separate service\n accounts for performing different actions. For example, you may want one\n service account for reading, which would have the `Storage Object Viewer`\n role and a second service account for writing, which would have the\n `Storage Object Creator` role.\n- You should test to make certain the service account behaves as expected\n before pushing any update out to production.\n\n- After your production work transitions to service account HMAC keys, you\n should check the following [Cloud Monitoring metric](/monitoring/api/metrics_gcp_p_z#gcp-storage) to verify that\n the HMAC keys associated with the user account are no longer in use:\n\n You can set the following labels to track user account keys that\n are still in use during the migration progress:\n - `access_id`: identifies which access ID made the request. You can also\n use `access_id` during a key rotation to watch traffic move from one key\n to another.\n\n - `authentication_method`: identifies if keys are user account or service\n account keys.\n\n- Once you've verified the user account HMAC keys are no longer used, you\n should delete those HMAC keys. Doing so reduces the risk of inappropriate\n data access.\n\n- If the user account is no longer used to access Cloud Storage\n resources, revoke any access to Cloud Storage that it has.\n\n- You can optionally [enable the `restrictAuthTypes` constraint](/resource-manager/docs/organization-policy/creating-managing-policies#creating_and_editing_policies)\n on user account HMAC keys for an extra layer of security.\n\nWhat's next\n-----------\n\n- [Create HMAC keys for your service accounts](/storage/docs/authentication/managing-hmackeys#create).\n- [Use an HMAC key in an authenticated request](/storage/docs/aws-simple-migration#authentication)."]]
