Cette page traite des clés HMAC (Hash-based Message Authentification Code, code d'authentification des messages basé sur un hachage), qui vous permettent d'authentifier les requêtes adressées à l'API XML de Cloud Storage. Les clés HMAC sont utiles lorsque vous souhaitez déplacer des données entre d'autres fournisseurs de stockage cloud et Cloud Storage, car elles vous permettent de réutiliser votre code existant pour accéder à Cloud Storage.
Présentation
Une clé HMAC est un type d'identifiant associé à un compte, généralement un compte de service. Utilisez une clé HMAC pour créer des signatures à l'aide de l'algorithme de signature HMAC-SHA256. Les signatures que vous créez sont ensuite incluses dans les requêtes adressées à l'API XML de Cloud Storage. Les signatures indiquent qu'une requête donnée est autorisée par le compte associé à la clé HMAC.
Les clés HMAC comportent deux éléments principaux : un ID d'accès et un secret.
ID d'accès : chaîne alphanumérique associée à un compte spécifique.
Lorsqu'elle est associée à un compte de service, la chaîne comporte 61 caractères.
Lorsqu'elle est associée à un compte utilisateur, la chaîne comporte 24 caractères.
Secret : chaîne de 40 caractères encodée en base64 qui est associée à un ID d'accès spécifique. Un secret est une clé prépartagée que seuls vous et Cloud Storage connaissez. Vous l'utilisez pour créer des signatures dans le cadre du processus d'authentification. Voici un exemple de secret :
bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ
L'ID d'accès et le secret identifient de manière unique une clé HMAC, mais le secret est un élément d'information beaucoup plus sensible, car il sert à créer des signatures.
Vous pouvez éventuellement activer la contrainte restrictAuthTypes sur une ressource, ce qui limite l'accès aux requêtes signées par des clés HMAC.
Stocker des secrets
Lorsque vous créez une clé HMAC pour un compte de service, vous recevez le secret une seule fois. Vous devez le stocker de manière sécurisée, tout comme l'ID d'accès associé. Si vous perdez le secret, ni vous, ni Google Cloudne pouvez le récupérer. Vous devez créer une clé HMAC pour que le compte de service puisse continuer à authentifier les requêtes.
Pour créer une clé HMAC pour un compte utilisateur, vous devez être connecté à la consoleGoogle Cloud avec le compte utilisateur et accéder à l'onglet Interopérabilité dans le menu Paramètres Cloud Storage d'un projet pour lequel vous disposez de l'autorisation IAM resourcemanager.projects.get. Une fois la clé créée, vous pouvez afficher son secret à partir de l'onglet Interopérabilité d'un projet pour lequel vous disposez de l'autorisation resourcemanager.projects.get.
Bonnes pratiques pour le stockage des secrets
Ne partagez pas le secret de votre clé HMAC. Vous devez traiter les secrets de clés HMAC comme n'importe quel ensemble d'identifiants d'accès.
Une bonne pratique de sécurité consiste à modifier régulièrement vos clés dans le cadre d'une rotation de clés.
Si vous pensez qu'un autre utilisateur utilise vos clés HMAC, vous devez immédiatement supprimer les clés HMAC concernées pour en créer d'autres.
Lorsque vous modifiez vos clés HMAC, nous vous recommandons de mettre à jour votre code en spécifiant les nouvelles clés HMAC avant de supprimer les anciennes. Lorsque vous supprimez des clés HMAC, celles-ci deviennent immédiatement non valides et ne peuvent plus être récupérées.
Restrictions
Les clés HMAC ne peuvent être utilisées que pour envoyer des requêtes à l'API XML, et non à l'API JSON.
Vous pouvez utiliser au maximum 10 clés HMAC par compte de service. Les clés supprimées ne sont pas comptabilisées dans ce quota.
Après la création, un délai de 60 secondes peut être nécessaire pour qu'une clé HMAC de compte de service soit utilisable. Après la suppression d'un compte de service, les clés HMAC qui lui appartiennent peuvent continuer à fonctionner pendant cinq minutes au maximum. À l'inverse, un délai de cinq minutes peut être nécessaire pour que les clés HMAC soient à nouveau utilisables après l'annulation de la suppression du compte de service qui en est le propriétaire.
Si vous activez la contrainte restrictAuthTypes sur une ressource, vous ne pouvez plus créer ni activer les clés HMAC pour le type de compte spécifié dans cette ressource.
Migrer depuis des clés HMAC de compte utilisateur
En règle générale, il est préférable d'associer des clés HMAC à des comptes de service plutôt qu'à des comptes utilisateur, en particulier pour les charges de travail de production :
Les comptes de service permettent une meilleure surveillance administrative, et solutionne les problèmes de sécurité et de confidentialité inhérents des comptes détenus par des utilisateurs individuels.
Les comptes de service réduisent le risque d'interruptions de service liées aux comptes utilisateur, par exemple lorsqu'un compte utilisateur est désactivé, car l'utilisateur quitte le projet ou l'entreprise.
Si vous utilisez actuellement des clés HMAC associées à des comptes utilisateur, mais que vous souhaitez migrer vers des comptes de service, gardez à l'esprit les points suivants :
Le compte de service doit disposer des autorisations requises pour effectuer des actions dans Cloud Storage.
L'autorisation étendue permettant d'utiliser des objets est contenue dans le rôle Storage Object Admin, mais vous pouvez disposer de comptes de service distincts pour effectuer différentes actions. Par exemple, vous pouvez choisir un compte de service pour la lecture, qui aurait le rôle Storage Object Viewer, et un second compte de service pour l'écriture qui aurait le rôle Storage Object Creator.
Avant d'envoyer une mise à jour en production, vous devez vérifier que le compte de service se comporte comme prévu.
Une fois que vos tâches de production ont migré vers des clés HMAC de compte de service, vous devez vérifier que les clés HMAC associées au compte utilisateur ne sont plus utilisées à l'aide de la métrique Cloud Monitoring ci-dessous.
Métrique
Description
storage.googleapis.com/authn/authentication_count
Nombre de fois où des clés HMAC ont servi à authentifier des requêtes.
Vous pouvez définir les libellés suivants pour effectuer le suivi des clés du compte utilisateur qui sont toujours utilisées lors la migration :
access_id : identifie l'ID d'accès à l'origine de la requête. Vous pouvez également définir le libellé access_id lors d'une rotation de clés pour surveiller le transfert du trafic d'une clé à une autre.
authentication_method : détermine si les clés sont associées à un compte utilisateur ou à un compte de service.
Lorsque vous avez confirmé que les clés HMAC de compte utilisateur ne sont plus utilisées, nous vous recommandons de les supprimer. Cela réduit le risque d'accès inapproprié aux données.
Si le compte utilisateur n'est plus utilisé pour accéder aux ressources Cloud Storage, révoquez tout accès à Cloud Storage dont il dispose.
Vous pouvez éventuellement activer la contrainte restrictAuthTypes sur les clés HMAC de compte utilisateur pour ajouter une couche de sécurité supplémentaire.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/05 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)."]]
