Halaman ini membahas kunci message authentication code berbasis hash (HMAC), yang dapat Anda gunakan untuk mengautentikasi permintaan ke Cloud Storage XML API. Kunci HMAC berguna saat Anda ingin memindahkan data antara penyedia penyimpanan cloud lainnya dan Cloud Storage, karena kunci HMAC memungkinkan Anda menggunakan kembali kode yang ada untuk mengakses Cloud Storage.
Ringkasan
Kunci HMAC adalah jenis kredensial yang dikaitkan dengan akun, biasanya
akun layanan. Anda menggunakan kunci HMAC untuk membuat tanda tangan menggunakan
algoritma penandatanganan HMAC-SHA256. Tanda tangan yang Anda buat kemudian disertakan dalam permintaan ke Cloud Storage XML API. Tanda tangan menunjukkan bahwa permintaan tertentu diberi otorisasi oleh akun yang terkait dengan kunci HMAC.
Kunci HMAC memiliki dua bagian utama, ID akses dan secret.
ID Akses: String alfanumerik yang ditautkan ke akun tertentu.
Jika ditautkan ke akun layanan, panjang string adalah 61 karakter.
Jika ditautkan ke akun pengguna, panjang string tersebut adalah 24 karakter.
Secret: String berenkode Base-64 berisi 40 karakter yang ditautkan ke ID akses
tertentu. Secret adalah kunci yang dibagikan sebelumnya, yang hanya diketahui oleh Anda dan Cloud Storage. Anda menggunakan secret untuk membuat tanda tangan
sebagai bagian dari proses autentikasi. Berikut ini contoh secret:
bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ
ID akses dan secret mengidentifikasi kunci HMAC secara unik, tetapi secret adalah informasi yang jauh lebih sensitif, karena digunakan untuk membuat tanda tangan.
Secara opsional, Anda dapat mengaktifkan batasan restrictAuthTypes pada
resource, yang membatasi akses untuk permintaan yang ditandatangani oleh kunci HMAC.
Menyimpan rahasia
Saat membuat kunci HMAC untuk akun layanan, Anda akan diberi secret ntuk kunci tersebut satu kali. Anda harus menyimpan secret dengan aman, beserta
ID akses terkait. Jika Anda kehilangan secret tersebut, secret tersebut tidak dapat diambil oleh Anda atau Google Cloud, dan Anda harus membuat kunci HMAC baru untuk akun layanan agar dapat terus mengautentikasi permintaan.
Untuk membuat kunci HMAC untuk akun pengguna, Anda harus login ke
Google Cloud konsol dengan akun pengguna tersebut dan membuka tab Interoperabilitas
di menu Setelan Cloud Storage dari proyek yang Anda miliki
izin IAM resourcemanager.projects.get-nya. Setelah dibuat, Anda dapat melihat secret kunci tersebut dari tab Interoperabilitas di project apa pun yang izin resourcemanager.projects.get-nya Anda miliki.
Praktik terbaik untuk menyimpan secret
Jangan bagikan secret kunci HMAC Anda. Anda harus memperlakukan secret kunci HMAC seperti set kredensial akses.
Sebagai praktik terbaik keamanan, Anda harus mengubah kunci secara rutin sebagai bagian dari
rotasi kunci.
Jika menurut Anda orang lain menggunakan kunci HMAC Anda, Anda harus segera menghapus kunci HMAC yang terpengaruh dan membuat yang baru.
Saat mengubah kunci HMAC, Anda harus memperbarui kode dengan kunci HMAC baru sebelum Anda menghapus kunci lama. Saat Anda menghapus kunci HMAC, kunci tersebut langsung menjadi tidak valid dan tidak dapat dipulihkan.
Pembatasan
Kunci HMAC hanya dapat digunakan untuk membuat permintaan ke XML API, bukan JSON API.
Anda dapat memiliki maksimal 10 kunci HMAC per akun layanan. Kunci yang dihapus tidak dihitung terhadap batas ini.
Setelah dibuat, perlu waktu hingga 60 detik agar kunci HMAC akun layanan dapat digunakan. Setelah menghapus akun layanan, kunci HMAC
yang menjadi miliknya mungkin terus berfungsi hingga 5 menit. Sebaliknya,
perlu waktu hingga 5 menit agar kunci HMAC dapat digunakan kembali setelah
membatalkan penghapusan akun layanan yang memilikinya.
Jika mengaktifkan batasan restrictAuthTypes pada resource, Anda tidak dapat lagi membuat atau mengaktifkan kunci HMAC untuk jenis akun yang ditentukan di resource tersebut.
Migrasi dari kunci HMAC akun pengguna
Secara umum, mengaitkan kunci HMAC dengan akun layanan adalah opsi yang lebih baik daripada melakukannya dengan akun pengguna, terutama untuk beban kerja produksi:
Akun layanan memungkinkan pengawasan administratif yang lebih baik, serta menghilangkan implikasi keamanan dan privasi dari akun yang dimiliki oleh pengguna perorangan.
Akun layanan mengurangi risiko pemadaman layanan yang terkait dengan ketergantungan
akun pengguna, seperti saat akun pengguna dinonaktifkan karena pengguna
keluar dari project atau perusahaan.
Jika saat ini Anda menggunakan kunci HMAC dengan akun pengguna tetapi ingin bermigrasi ke akun layanan, perhatikan hal berikut:
Akun layanan harus diberi izin yang diperlukan untuk melakukan tindakan di Cloud Storage.
Izin yang luas untuk bekerja dengan objek dimuat dalam
peran Storage Object Admin, tetapi Anda mungkin ingin memiliki akun layanan
terpisah untuk melakukan berbagai tindakan. Misalnya, Anda mungkin menginginkan satu
akun layanan untuk membaca, yang akan memiliki peran Storage Object Viewer
dan akun layanan kedua untuk menulis, yang akan memiliki
peran Storage Object Creator.
Anda harus melakukan pengujian untuk memastikan akun layanan berperilaku seperti yang diharapkan sebelum menerapkan update apa pun ke produksi.
Setelah transisi tugas produksi ke kunci HMAC akun layanan, Anda harus memeriksa metrik Cloud Monitoring berikut untuk memverifikasi bahwa kunci HMAC yang terkait dengan akun pengguna tidak lagi digunakan:
Metrik
Deskripsi
storage.googleapis.com/authn/authentication_count
Berapa kali kunci HMAC digunakan untuk mengautentikasi permintaan.
Anda dapat menetapkan label berikut untuk melacak kunci akun pengguna yang
masih digunakan selama progres migrasi:
access_id: mengidentifikasi ID akses yang membuat permintaan. Anda juga dapat menggunakan access_id selama rotasi kunci untuk melihat traffic berpindah dari satu kunci ke kunci lainnya.
authentication_method: mengidentifikasi apakah kunci adalah kunci akun pengguna atau
akun layanan.
Setelah Anda memverifikasi bahwa kunci HMAC akun pengguna tidak lagi digunakan, Anda harus menghapus kunci HMAC tersebut. Tindakan ini akan mengurangi risiko akses data yang tidak pantas.
Jika akun pengguna tidak lagi digunakan untuk mengakses resource Cloud Storage, cabut semua akses ke Cloud Storage yang dimilikinya.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-18 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)."]]
