Auf dieser Seite werden HMAC-Schlüssel (Hash-basierter Message Authentication Code) beschrieben, mit denen Sie Anfragen an die Cloud Storage XML API authentifizieren können. HMAC-Schlüssel sind nützlich, wenn Sie Daten zwischen anderen Cloud Storage-Anbietern und Cloud Storage verschieben möchten, da Sie mit HMAC-Schlüsseln Ihren vorhandenen Code wiederverwenden können, um auf Cloud Storage zuzugreifen.
Übersicht
Ein HMAC-Schlüssel ist eine Art von Anmeldedaten, die mit einem Konto, in der Regel einem Dienstkonto, verknüpft sind. Mit einem HMAC-Schlüssel können Sie Signaturen mit dem Signaturalgorithmus HMAC-SHA256 erstellen. Die von Ihnen erstellten Signaturen werden dann in Anfragen an die Cloud Storage XML API aufgenommen. Signaturen zeigen, dass eine bestimmte Anfrage vom Konto autorisiert wurde, das mit dem HMAC-Schlüssel verknüpft ist.
HMAC-Schlüssel bestehen aus zwei Hauptteilen: einer Zugriffs-ID und einem Secret.
Zugriffs-ID: Ein alphanumerischer String, der mit einem bestimmten Konto verknüpft ist.
Wenn der String mit einem Dienstkonto verknüpft ist, beträgt der String 61 Zeichen.
Wenn der String mit einem Nutzerkonto verknüpft ist, hat er 24 Zeichen.
Secret: Ein Base-64-codierter String mit 40 Zeichen, der mit einer bestimmten Zugriffs-ID verknüpft ist. Ein Secret ist ein gemeinsamer geheimer Schlüssel, den nur Sie und Cloud Storage kennen. Sie verwenden Ihr Secret als Teil des Authentifizierungsprozesses, um Signaturen zu erstellen. Hier sehen Sie ein Beispiel für ein Secret:
bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ
Sowohl die Zugriffs-ID als auch das Secret dienen zur Identifizierung eines HMAC-Schlüssels. Secrets sind jedoch wesentlich vertraulichere Informationen, da sie zum Erstellen von Signaturen verwendet werden.
Sie können optional die Einschränkung restrictAuthTypes für eine Ressource aktivieren, die den Zugriff für Anfragen beschränkt, die von HMAC-Schlüsseln signiert wurden.
Secrets speichern
Beim Erstellen eines HMAC-Schlüssels für ein Dienstkonto erhalten Sie das Secret für den Schlüssel ein einziges Mal. Sie müssen das Secret zusammen mit der zugehörigen Zugriffs-ID sicher aufbewahren. Wenn Sie das Secret verlieren, kann es weder von Ihnen noch von Google Cloudabgerufen werden. Sie müssen dann einen neuen HMAC-Schlüssel für das Dienstkonto erstellen, um Anfragen weiterhin authentifizieren zu können.
Um einen HMAC-Schlüssel für ein Nutzerkonto zu erstellen, müssen Sie mit dem Nutzerkonto in derGoogle Cloud -Konsole angemeldet sein und zum Tab Interoperabilität im Menü Cloud Storage-Einstellungen eines Projekts gehen, für das Sie die IAM-Berechtigung resourcemanager.projects.get haben. Nachdem Sie den Schlüssel erstellt haben, können Sie das zugehörige Secret auf dem Tab Interoperabilität eines beliebigen Projekts aufrufen, für das Sie die Berechtigung resourcemanager.projects.get haben.
Best Practices zum Speichern von Secrets
Geben Sie das HMAC-Schlüssel-Secret nicht weiter. Sie sollten mit HMAC-Schlüssel-Secrets wie mit allen anderen Arten von Anmeldedaten umgehen.
Als bewährte Sicherheitsmethode sollten Sie Ihre Schlüssel im Rahmen einer Schlüsselrotation regelmäßig ändern.
Wenn Sie den Verdacht haben, dass eine andere Person Ihre HMAC-Schlüssel verwendet, sollten Sie die betroffenen HMAC-Schlüssel sofort löschen und neue erstellen.
Wenn Sie HMAC-Schlüssel ändern, sollten Sie Ihren Code mit den neuen HMAC-Schlüsseln aktualisieren, bevor Sie die alten Schlüssel löschen. Wenn Sie HMAC-Schlüssel löschen, werden diese sofort ungültig und können nicht wiederhergestellt werden.
Beschränkungen
Mit HMAC-Schlüsseln können nur Anfragen an die XML API gesendet werden, nicht jedoch an die JSON API.
Pro Dienstkonto können maximal 10 HMAC-Schlüssel verwendet werden. Gelöschte Schlüssel werden nicht auf dieses Limit angerechnet.
Nach der Erstellung kann es bis zu 60 Sekunden dauern, bis der HMAC-Schlüssel eines Dienstkontos verwendet werden kann. Nach dem Löschen eines Dienstkontos funktionieren die zugehörigen HMAC-Schlüssel möglicherweise noch bis zu fünf Minuten lang. Umgekehrt kann es bis zu fünf Minuten dauern, bis die HMAC-Schlüssel wieder verwendet werden können, nachdem das Dienstkonto, zu dem sie gehören, wiederhergestellt wurde.
Wenn Sie die Einschränkung restrictAuthTypes für eine Ressource aktivieren, können Sie für den angegebenen Kontotyp in dieser Ressource keine HMAC-Schlüssel mehr erstellen oder aktivieren.
Migration von HMAC-Schlüsseln für Nutzerkonten
Im Allgemeinen ist die Verknüpfung von HMAC-Schlüsseln mit Dienstkonten eine bessere Option als die Verknüpfung mit Nutzerkonten, insbesondere bei Produktionsarbeitslasten:
Dienstkonten ermöglichen eine bessere Verwaltungsaufsicht und verhindern Datenschutz- und Sicherheitsrisiken für Konten einzelner Nutzer.
Sie verringern außerdem das Risiko von Dienstausfällen, die mit der Verwendung von Nutzerkonten verbunden sind, z. B. wenn ein Nutzerkonto deaktiviert wird, weil der Nutzer aus dem Projekt aussteigt oder das Unternehmen verlässt.
Wenn Sie derzeit HMAC-Schlüssel mit Nutzerkonten verwenden, aber zu Dienstkonten migrieren möchten, beachten Sie Folgendes:
Ihr Projekt muss ein Dienstkonto haben und dieses Dienstkonto muss mit einem HMAC-Schlüssel verknüpft sein.
Umfassende Berechtigungen zum Arbeiten mit Objekten sind in der Rolle Storage Object Admin enthalten. Sie können jedoch separate Konten für die Ausführung verschiedener Aktionen haben. Beispiel: Sie haben ein Dienstkonto zum Lesen mit der Rolle Storage Object Viewer und ein zweites Dienstkonto zum Schreiben mit der Rolle Storage Object Creator.
Testen Sie die ordnungsgemäße Ausführung des Dienstkontos, bevor Sie ein Update in die Produktionsphase übertragen.
Nachdem Ihre Produktionsarbeit zu HMAC-Schlüsseln für Dienstkonten übergegangen ist, sollten Sie anhand des folgenden Cloud Monitoring-Messwerts prüfen, ob die mit dem Nutzerkonto verknüpften HMAC-Schlüssel nicht mehr verwendet werden:
Messwert
Beschreibung
storage.googleapis.com/authn/authentication_count
Die Häufigkeit, mit der HMAC-Schlüssel zur Authentifizierung von Anfragen verwendet wurden.
Sie können die folgenden Labels festlegen, um während des Fortschritts der Migration die Nutzerkontoschlüssel zu erfassen, die weiterhin verwendet werden:
access_id: gibt an, welche Zugriffs-ID die Anfrage gestellt hat. Sie können access_id auch während einer Schlüsselrotation verwenden, um im Blick zu behalten, wie sich der Traffic von einem Schlüssel zum anderen bewegt.
authentication_method: gibt an, ob es sich bei Schlüsseln um Schlüssel von Nutzerkonten oder Dienstkonten handelt.
Nachdem Sie bestätigt haben, dass die HMAC-Schlüssel des Nutzerkontos nicht mehr verwendet werden, löschen Sie die HMAC-Schlüssel. Dadurch verringert sich das Risiko eines unangemessenen Datenzugriffs.
Wenn das Nutzerkonto nicht mehr für den Zugriff auf Cloud Storage-Ressourcen verwendet wird, widerrufen Sie jeglichen Zugriff dieses Kontos auf Cloud Storage.
Optional können Sie für zusätzliche Sicherheit die Einschränkung restrictAuthTypes für HMAC-Schlüssel von Nutzerkonten aktivieren.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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)."]]
