En esta página se describen las claves de código de autenticación de mensajes basado en hash (HMAC), que puedes usar para autenticar solicitudes a la API XML de Cloud Storage. Las claves HMAC son útiles cuando quieres mover datos entre otros proveedores de almacenamiento en la nube y Cloud Storage, ya que te permiten reutilizar tu código para acceder a Cloud Storage.
Información general
Una clave HMAC es un tipo de credencial asociada a una cuenta, normalmente una cuenta de servicio. Utilizas una clave HMAC para crear firmas con el algoritmo de firma HMAC-SHA256. Las firmas que crees se incluirán en las solicitudes a la API XML de Cloud Storage. Las firmas muestran que una solicitud determinada está autorizada por la cuenta asociada a la clave HMAC.
Las claves HMAC tienen dos partes principales: un ID de acceso y un secreto.
ID de acceso: cadena alfanumérica vinculada a una cuenta específica.
Cuando se vincula a una cuenta de servicio, la cadena tiene una longitud de 61 caracteres.
Cuando se vincula a una cuenta de usuario, la cadena tiene una longitud de 24 caracteres.
A continuación, se muestra un ejemplo de ID de acceso:
Secreto: una cadena de 40 caracteres codificada en Base64 que está vinculada a un ID de acceso específico. Un secreto es una clave precompartida que solo tú y Cloud Storage conocéis. Usas tu secreto para crear firmas como parte del proceso de autenticación. A continuación, se muestra un ejemplo de un secreto:
bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ
Tanto el ID de acceso como el secreto identifican de forma única una clave HMAC, pero el secreto es información mucho más sensible, ya que se usa para crear firmas.
También puedes habilitar la restricción restrictAuthTypes en un recurso, lo que restringe el acceso a las solicitudes firmadas con claves HMAC.
Almacenar secretos
Cuando crea una clave HMAC para una cuenta de servicio, se le proporciona
el secreto de la clave una sola vez. Debes almacenar el secreto de forma segura junto con el ID de acceso asociado. Si pierdes el secreto, ni tú ni Google Cloudpodréis recuperarlo, por lo que tendrás que crear una nueva clave HMAC para la cuenta de servicio si quieres seguir autenticando solicitudes.
Para crear una clave HMAC de una cuenta de usuario, debes iniciar sesión en la consolaGoogle Cloud con la cuenta de usuario y acceder a la pestaña Interoperabilidad del menú Configuración de Cloud Storage de un proyecto para el que tengas el permiso de gestión de identidades y accesos resourcemanager.projects.get. Una vez creada, puedes ver el secreto de la clave en la pestaña Interoperabilidad de cualquier proyecto para el que tengas el permiso resourcemanager.projects.get.
Prácticas recomendadas para almacenar secretos
No compartas el secreto de tu clave HMAC. Debes tratar los secretos de claves HMAC como cualquier conjunto de credenciales de acceso.
Como medida de seguridad recomendada, debes cambiar tus claves periódicamente como parte de una rotación de claves.
Si crees que otra persona está usando tus claves HMAC, debes eliminar inmediatamente las claves afectadas y crear otras nuevas.
Cuando cambie las claves HMAC, debe actualizar su código con las nuevas claves HMAC antes de eliminar las antiguas. Cuando eliminas claves HMAC, dejan de ser válidas inmediatamente y no se pueden recuperar.
Restricciones
Las claves HMAC solo se pueden usar para hacer solicitudes a la API XML, no a la API JSON.
Puedes tener un máximo de 10 claves HMAC por cuenta de servicio. Las claves eliminadas no se tienen en cuenta en este límite.
Una vez creada, una clave HMAC de cuenta de servicio puede tardar hasta 60 segundos en poder usarse. Después de eliminar una cuenta de servicio, las claves HMAC que le pertenezcan pueden seguir funcionando durante un máximo de 5 minutos. Por el contrario, las claves HMAC pueden tardar hasta 5 minutos en volver a estar disponibles después de restaurar la cuenta de servicio a la que pertenecen.
Si habilitas la restricción restrictAuthTypes en un recurso, ya no podrás crear ni activar claves HMAC para el tipo de cuenta especificado en ese recurso.
Migración desde claves HMAC de cuentas de usuario
Por lo general, es mejor asociar claves HMAC a cuentas de servicio que a cuentas de usuario, sobre todo en el caso de las cargas de trabajo de producción:
Las cuentas de servicio permiten supervisar mejor la administración y eliminan las implicaciones de seguridad y privacidad de las cuentas de usuarios individuales.
Las cuentas de servicio reducen el riesgo de interrupciones del servicio asociadas a las cuentas de usuario, como cuando se inhabilita una cuenta de usuario porque el usuario abandona el proyecto o la empresa.
Si actualmente usas claves HMAC con cuentas de usuario, pero quieres migrar a cuentas de servicio, ten en cuenta lo siguiente:
Se deben conceder a la cuenta de servicio los permisos necesarios para realizar acciones en Cloud Storage.
El rol Storage Object Admin incluye permisos amplios para trabajar con objetos, pero puede que quieras tener cuentas de servicio independientes para realizar diferentes acciones. Por ejemplo, puedes usar una cuenta de servicio para leer, que tendría el rol Storage Object Viewer, y otra para escribir, que tendría el rol Storage Object Creator.
Debes hacer pruebas para asegurarte de que la cuenta de servicio se comporta como esperas
antes de lanzar ninguna actualización en producción.
Una vez que tu trabajo de producción pase a usar claves HMAC de cuentas de servicio, debes consultar la siguiente métrica de Cloud Monitoring para verificar que las claves HMAC asociadas a la cuenta de usuario ya no se estén usando:
Métrica
Descripción
storage.googleapis.com/authn/authentication_count
Número de veces que se han usado claves HMAC para autenticar solicitudes.
Puedes definir las siguientes etiquetas para monitorizar las claves de cuentas de usuario que
se siguen usando durante el proceso de migración:
access_id: identifica el ID de acceso que ha realizado la solicitud. También puedes usar access_id durante una rotación de claves para ver cómo se mueve el tráfico de una clave a otra.
authentication_method: identifica si las claves son de cuentas de usuario o de cuentas de servicio.
Una vez que hayas verificado que las claves HMAC de la cuenta de usuario ya no se usan, debes eliminarlas. De este modo, se reduce el riesgo de que se produzca un acceso inadecuado a los datos.
Si la cuenta de usuario ya no se usa para acceder a recursos de Cloud Storage, revoca cualquier acceso a Cloud Storage que tenga.
[[["Es fácil de entender","easyToUnderstand","thumb-up"],["Me ofreció una solución al problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Es difícil de entender","hardToUnderstand","thumb-down"],["La información o el código de muestra no son correctos","incorrectInformationOrSampleCode","thumb-down"],["Me faltan las muestras o la información que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-11 (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)."]]
