Questa pagina descrive le chiavi HMAC (Hash-based Message Authentication Code), che puoi utilizzare per autenticare le richieste all'API Cloud Storage XML. Le chiavi HMAC
sono utili quando vuoi spostare dati tra altri provider di spazio di spazio di archiviazione sul cloud
e Cloud Storage, perché ti consentono di
riutilizzare il codice esistente per accedere a Cloud Storage.
Panoramica
Una chiave HMAC è un tipo di credenziale associata a un account, in genere un
account di serviziot. Utilizzi una chiave HMAC per creare firme utilizzando l'algoritmo di firma HMAC-SHA256. Le firme che crei vengono poi incluse nelle richieste all'API Cloud Storage XML. Le firme mostrano che
una determinata richiesta è autorizzata dall'account associato alla chiave HMAC.
Le chiavi HMAC sono composte da due parti principali: un ID accesso e un secret.
ID accesso: una stringa alfanumerica collegata a un account specifico.
Se collegata a un account di servizio, la stringa è lunga 61 caratteri.
Se collegata a un account utente, la stringa è lunga 24 caratteri.
Secret: una stringa con codifica Base64 di 40 caratteri collegata a un ID accesso specifico. Un secret è una chiave precondivisa che solo tu e
Cloud Storage conoscete. Utilizzi il tuo segreto per creare firme
nell'ambito della procedura di autenticazione. Di seguito è riportato un esempio di secret:
bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ
Sia l'ID accesso che il secret identificano in modo univoco una chiave HMAC, ma il secret è
un'informazione molto più sensibile, perché viene utilizzato per creare firme.
Se vuoi, puoi attivare il vincolo restrictAuthTypes su una risorsa, che limita l'accesso per le richieste firmate con chiavi HMAC.
Archiviare i secret
Quando crei una chiave HMAC per un service account, ti viene fornito
il segreto della chiave una sola volta. Devi archiviare in modo sicuro il secret insieme all'ID accesso associato. Se perdi il secret, non potrai recuperarlo
o Google Cloude dovrai creare una nuova chiave HMAC per ilaccount di serviziot
per continuare ad autenticare le richieste.
Per creare una chiave HMAC per un account utente, devi accedere alla
consoleGoogle Cloud con l'account utente e andare alla scheda Interoperabilità
nel menu Impostazioni di Cloud Storage di un progetto per il quale
disponi dell'autorizzazione IAM resourcemanager.projects.get. Una volta
creata, puoi visualizzare il segreto della chiave dalla scheda Interoperabilità di qualsiasi
progetto per cui disponi dell'autorizzazione resourcemanager.projects.get.
Best practice per l'archiviazione dei secret
Non condividere il secret della chiave HMAC. Devi trattare i secret della chiave HMAC come
qualsiasi insieme di credenziali di accesso.
Come best practice di sicurezza, devi cambiare regolarmente le chiavi nell'ambito di
una rotazione della chiave.
Se ritieni che qualcun altro stia utilizzando le tue chiavi HMAC, devi
eliminarle immediatamente e crearne di nuove.
Quando modifichi le chiavi HMAC, devi aggiornare il codice con le nuove chiavi HMAC
prima di eliminare quelle precedenti. Quando elimini le chiavi HMAC, queste diventano
immediatamente non valide e non sono recuperabili.
Limitazioni
Le chiavi HMAC possono essere utilizzate solo per effettuare richieste all'API XML, non all'API JSON.
Puoi avere un massimo di 10 chiavi HMAC per ogni account di servizio. Le chiavi
eliminate non contano ai fini di questo limite.
Dopo la creazione, potrebbero essere necessari fino a 60 secondi prima che una chiave HMAC dell'account di servizio
diventi utilizzabile. Dopo l'eliminazione di un account di servizio, le chiavi HMAC
appartenenti a quest'ultimo potrebbero continuare a funzionare per un massimo di 5 minuti. Al contrario,
possono essere necessari fino a 5 minuti prima che le chiavi HMAC tornino a essere utilizzabili dopo
l'annullamento dell'eliminazione deaccount di serviziont che le possiede.
Se abiliti il vincolo restrictAuthTypes su una risorsa, non puoi più creare o attivare chiavi HMAC per il tipo di account specificato in quella risorsa.
Migrazione dalle chiavi HMAC dell'account utente
In generale, l'associazione delle chiavi HMAC agli account di servizio è un'opzione migliore rispetto
all'associazione agli account utente, in particolare per i workload di produzione:
Gli account di servizio consentono una migliore supervisione amministrativa ed eliminano le implicazioni per la sicurezza e la privacy degli account detenuti da singoli utenti.
Gli account di servizio riducono il rischio di interruzioni del servizio associate all'utilizzo
di account utente, ad esempio quando un account utente viene disattivato perché l'utente
lascia il progetto o l'azienda.
Se attualmente utilizzi le chiavi HMAC con gli account utente, ma vuoi eseguire la migrazione agli account di servizio, tieni presente quanto segue:
Al account di servizio devono essere concesse le autorizzazioni richieste per eseguire azioni in Cloud Storage.
L'autorizzazione generica per lavorare con gli oggetti è contenuta nel ruolo
Storage Object Admin, ma potresti voler disporre di service account separati per eseguire azioni diverse. Ad esempio, potresti volere un account di servizio per la lettura, che avrebbe il ruolo Storage Object Viewer, e un secondo account di servizio per la scrittura, che avrebbe il ruolo Storage Object Creator.
Prima di eseguire il push di qualsiasi aggiornamento in produzione, devi eseguire dei test per assicurarti che il account di servizio si comporti come previsto.
Dopo che il tuo lavoro di produzione passa alle chiavi HMAC del account di servizio, devi controllare la seguente metrica di Cloud Monitoring per verificare che le chiavi HMAC associate all'account utente non siano più in uso:
Metrica
Descrizione
storage.googleapis.com/authn/authentication_count
Il numero di volte in cui le chiavi HMAC sono state utilizzate per autenticare le richieste.
Puoi impostare le seguenti etichette per monitorare le chiavi degli account utente
ancora in uso durante l'avanzamento della migrazione:
access_id: identifica quale ID accesso ha effettuato la richiesta. Puoi anche
utilizzare access_id durante una rotazione della chiave per osservare il traffico che si sposta da una chiave
all'altra.
authentication_method: identifica se le chiavi sono chiavi dell'account utente o del service account.
Una volta verificato che le chiavi HMAC dell'account utente non vengono più utilizzate, devi eliminarle. In questo modo ridurrai il rischio di accesso ai dati inappropriato.
Se l'account utente non viene più utilizzato per accedere alle risorse Cloud Storage, revoca qualsiasi accesso a Cloud Storage.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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)."]]
