Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Secret Manager ist ein Dienst zum Verwalten von Secrets und Anmeldedaten, mit dem Sie sensible Daten wie API-Schlüssel, Nutzernamen, Passwörter und Zertifikate speichern und verwalten können.
Ein Secret ist eine globale Ressource, die eine Sammlung von Metadaten und Secret-Versionen enthält. Die Metadaten können Labels, Anmerkungen und Berechtigungen enthalten.
In einer Secret-Version werden die eigentlichen Secret-Daten wie API-Schlüssel, Passwörter oder Zertifikate gespeichert. Jede Version wird durch eine eindeutige ID oder einen eindeutigen Zeitstempel identifiziert.
Mit Secret Manager haben Sie folgende Möglichkeiten:
Rollback, Wiederherstellung und Prüfung mit Versionen verwalten: Mit Versionen können Sie schrittweise Roll-outs und Notfall-Rollbacks verwalten. Wenn ein Secret versehentlich geändert oder manipuliert wird, können Sie zu einer vorherigen, fehlerfreien Version zurückkehren. So werden potenzielle Ausfallzeiten und Sicherheitsverstöße minimiert. Mit der Versionierung wird ein Verlauf der Änderungen an einem Secret verwaltet, einschließlich der Informationen, wer die Änderungen vorgenommen hat und wann. Sie können damit geheime Daten prüfen und alle Versuche von unbefugten Zugriffen nachverfolgen. Sie können Secret-Versionen an bestimmte Arbeitslasten anpinnen und Aliasse hinzufügen, um den Zugriff auf Secret-Daten zu vereinfachen. Sie können nicht benötigte Secret-Versionen auch deaktivieren oder löschen.
Geheimdaten während der Übertragung und in inaktivem Zustand verschlüsseln: Alle Geheimnisse werden standardmäßig verschlüsselt, sowohl während der Übertragung mit TLS als auch in inaktivem Zustand mit AES-256-Bit-Verschlüsselungsschlüsseln. Wenn Sie eine detailliertere Kontrolle benötigen, können Sie Ihre vertraulichen Daten mit vom Kunden verwalteten Verschlüsselungsschlüsseln (CMEK) verschlüsseln. Mit CMEK können Sie neue Verschlüsselungsschlüssel generieren oder vorhandene importieren, um Ihre spezifischen Anforderungen zu erfüllen.
Zugriff auf Secrets mithilfe von detaillierten IAM-Rollen und -Bedingungen verwalten: Mit IAM-Rollen und ‑Berechtigungen können Sie detaillierten Zugriff auf bestimmte Secret Manager-Ressourcen gewähren. Sie können die Zuständigkeiten für den Zugriff, die Verwaltung, die Prüfung und die Rotation von Secrets trennen.
Hochverfügbarkeit und Notfallwiederherstellung mit der Replikation von Geheimnissen sicherstellen: Sie können Ihre Geheimnisse in mehreren Regionen replizieren, um unabhängig vom geografischen Standort eine hohe Verfügbarkeit und Notfallwiederherstellung für Ihre Anwendungen zu gewährleisten. Sie können zwischen den folgenden Replikationsrichtlinien wählen:
Automatische Replikation: Google entscheidet anhand von Verfügbarkeit und Latenz, in welchen Regionen die Daten repliziert werden. Ihnen wird nur ein Standort in Rechnung gestellt.
Vom Nutzer verwaltete Replikation: Sie können je nach Ihren Anforderungen eine benutzerdefinierte Gruppe von Regionen auswählen. Die Abrechnung erfolgt pro Standort.
Secrets automatisch rotieren, um Sicherheits- und Compliance-Anforderungen zu erfüllen: Mit dem Rotieren von Secrets werden Sie vor unbefugtem Zugriff und Datenpannen geschützt. Wenn Sie Ihre Secrets regelmäßig ändern, verringern Sie das Risiko veralteter oder vergessener Secrets und sorgen für die Einhaltung vieler regulatorischer Rahmenbedingungen, die eine regelmäßige Rotation sensibler Anmeldedaten erfordern.
Datenhoheit mithilfe regionaler Geheimnisse erzwingen: Gemäß dem Datenhoheitsprinzip müssen bestimmte Arten von Daten, die oft bestimmten Personen oder Organisationen gehören, an einem bestimmten geografischen Standort gespeichert werden. Sie können regionale Geheimnisse erstellen und Ihre vertraulichen Daten an einem bestimmten Standort speichern, um die Gesetze und Bestimmungen zur Datensouveränität einzuhalten.
Betriebsparameter für Ihre Anwendungen mit dem Parameter-Manager verwalten:
Der Parameter-Manager ist eine Erweiterung des Secret Manager-Dienstes, mit der Sie Anwendungskonfigurationen wie Datenbankverbindungsstrings, Feature-Flags, Umgebungsnamen, Portnummern, auf denen gelauscht werden soll, und Einstellungen für Anwendungsfunktionen speichern und verwalten können. Sie können auch in Ihren Parameterkonfigurationen auf im Secret Manager gespeicherte Secrets verweisen. Wenn Sie den Parametermanager verwenden möchten, müssen Sie die Parametermanager API aktivieren und Ihren Nutzern die erforderlichen IAM-Rollen zuweisen.
Unterschied zwischen Secrets-Verwaltung und Schlüsselverwaltung
Die Secrets-Verwaltung und die Schlüsselverwaltung sind beide wichtige Komponenten der Datensicherheit, haben aber unterschiedliche Zwecke und verarbeiten verschiedene Arten vertraulicher Informationen.
Die Wahl zwischen Secrets-Verwaltung und Schlüsselverwaltung hängt von Ihren spezifischen Anforderungen ab.
Wenn Sie vertrauliche Daten sicher speichern und verwalten möchten, ist ein Secret-Management-System das richtige Tool. Wenn Sie Verschlüsselungsschlüssel verwalten und kryptografische Vorgänge ausführen möchten, ist ein Schlüsselverwaltungssystem die bessere Wahl.
In der folgenden Tabelle finden Sie die wichtigsten Unterschiede zwischen Secret Manager und einem Schlüsselverwaltungssystem wie dem Cloud Key Management Service(Cloud KMS).
Funktion
Secret Manager
Cloud KMS
Hauptfunktion
Secrets als binäre Blobs oder Textstrings speichern, verwalten und darauf zugreifen
Kryptografische Schlüssel verwalten und zum Verschlüsseln oder Entschlüsseln von Daten verwenden
Gespeicherte Daten
Tatsächliche Secret-Werte. Mit den entsprechenden Berechtigungen können Sie den Inhalt des Secrets aufrufen.
Kryptografische Schlüssel Die tatsächlichen kryptografischen Geheimnisse (die Bits und Bytes), die für Verschlüsselungs- und Entschlüsselungsvorgänge verwendet werden, können nicht angezeigt, extrahiert oder exportiert werden.
Verschlüsselung
Verschlüsselt ruhende und übertragene Geheimnisse mit Google-owned and managed keys oder vom Kunden verwalteten Schlüsseln.
Bietet Verschlüsselungs- und Entschlüsselungsmöglichkeiten für andere Dienste.
Typische Anwendungsfälle
Konfigurationsinformationen wie Datenbankpasswörter, API-Schlüssel oder TLS-Zertifikate speichern, die von einer Anwendung zur Laufzeit benötigt werden.
Verarbeiten großer Verschlüsselungsarbeitslasten, z. B. zum Verschlüsseln von Zeilen in einer Datenbank oder zum Verschlüsseln von Binärdaten wie Bildern und Dateien. Sie können Cloud KMS auch für andere kryptografische Vorgänge wie das Signieren und Verifizieren verwenden.
Verschlüsselung von Secrets
Secret Manager verschlüsselt Ihre Secret-Daten immer, bevor sie auf dem Laufwerk gespeichert werden. Weitere Informationen zu den Google Cloud Verschlüsselungsoptionen finden Sie unter Verschlüsselung inaktiver Daten.
Die serverseitigen Verschlüsselungsschlüssel werden in Store Manager für Sie verwaltet. Wir verwenden dabei dieselben erprobten Schlüsselverwaltungssysteme wie für unsere eigenen verschlüsselten Daten, einschließlich strenger Schlüsselzugriffskontrollen und Prüfprozesse. Secret Manager verschlüsselt inaktive Nutzerdaten mit AES-256. Diese Art der Verschlüsselung erfordert Ihrerseits keinerlei Einrichtung oder Konfiguration. Sie können dennoch wie gewohnt auf den Dienst zugreifen. Auch die Leistung bleibt erhalten. Ihre Secret-Daten werden automatisch und transparent entschlüsselt, wenn ein autorisierter Nutzer darauf zugreift.
Die Secret Manager API kommuniziert immer über eine sichere HTTP(S)-Verbindung.
Wenn Sie eine zusätzliche Schutzebene benötigen, können Sie CMEK aktivieren und Ihre eigenen im Cloud Key Management Service gespeicherten Verschlüsselungsschlüssel verwenden, um die im Secret Manager gespeicherten Secrets zu schützen. In der Dokumentation zu CMEK finden Sie weitere Informationen zum Konfigurieren und Verwenden von vom Kunden verwalteten Verschlüsselungsschlüsseln.
[[["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,["# Secret Manager overview\n\nSecret Manager is a secrets and credential management service\nthat lets you store and manage sensitive data such as API keys, usernames, passwords,\ncertificates, and more.\n\nA [*secret*](/secret-manager/docs/creating-and-accessing-secrets)\nis a global resource that contains a collection of metadata and secret versions. The metadata can include\nlabels, annotations, and permissions.\n\nA [*secret version*](/secret-manager/docs/add-secret-version)\nstores the actual secret data, such as API keys, passwords, or certificates. Each version is\nidentified by a unique ID or timestamp.\n\nUsing Secret Manager, you can do the following:\n\n- **Manage rollback, recovery, and auditing using versions** : Versions help you\n manage gradual rollouts and emergency rollback, If a secret is accidentally changed\n or compromised, you can revert to a previous, known-good version. This minimizes\n potential downtime and security breaches. Versioning maintains a historical record\n of changes made to a secret, including who made the changes and when. It helps you\n audit secret data and track any unauthorized access attempts. You can pin secret\n versions to specific workloads and add\n [aliases](/secret-manager/docs/assign-alias-to-secret-version) for\n easier access to secret data. You can also\n [disable](/secret-manager/docs/disable-secret-version) or\n [destroy](/secret-manager/docs/destroy-secret-version) secret\n versions that you don't require.\n\n- **Encrypt your secret data in transit and at rest** : All secrets are\n encrypted by default, both in transit using TLS and at rest with AES-256-bit encryption\n keys. For those requiring more granular control, you can encrypt your secret data\n with [Customer-Managed\n Encryption Keys (CMEK)](/secret-manager/docs/cmek). Using CMEK, you can generate new encryption keys or import existing ones\n to meet your specific requirements.\n\n- **Manage access to secrets using fine-grained Identity and Access Management (IAM) roles and conditions** :\n With [IAM roles and permissions](/secret-manager/docs/access-control),\n you can [provide granular access](/secret-manager/docs/manage-access-to-secrets)\n to specific Secret Manager resources. You can segregate responsibilities for accessing,\n managing, auditing, and rotating secrets.\n\n- **Ensure high availability and disaster recovery with secret replication** : You\n can [replicate your secrets](/secret-manager/docs/choosing-replication)\n across multiple regions to ensure high availability and disaster recovery for your applications\n regardless of their geographic location. You can choose between the following replication policies:\n\n - [Automatic replication](/secret-manager/docs/choosing-replication#automatic): Google decides\n the regions considering availability and latency. You are only charged for one location.\n\n - [User managed replication](/secret-manager/docs/choosing-replication#user-managed): You can\n select a custom set of regions depending on your requirements. You are charged per location.\n\n- **Rotate secrets automatically to meet your security and compliance requirements** :\n [Rotating your secrets](/secret-manager/docs/rotation-recommendations)\n protects against unauthorized access and data breaches. Regularly changing your secrets reduces the risk\n of stale or forgotten secrets and ensures compliance with many regulatory frameworks\n that require periodic rotation of sensitive credentials.\n\n- **Enforce data residency using regional secrets** :\n [Data residency](/architecture/framework/security/meet-regulatory-compliance-and-privacy-needs#control_data_residency)\n requires that certain types of data, often belonging to specific individuals or\n organizations, be stored within a defined geographic location. You can create\n [regional secrets](/secret-manager/docs/create-regional-secrets)\n and store your sensitive data within a specific location to comply with data sovereignty laws\n and regulations.\n\n- **Manage operational parameters for your applications using\n Parameter Manager** :\n [Parameter Manager](/secret-manager/parameter-manager/docs/overview)\n is an extension to the Secret Manager service that you can use to store and manage\n application configurations such as database connection strings, feature flags, environment names,\n port numbers to listen on, and settings for application features. You can also\n [reference secrets](/secret-manager/parameter-manager/docs/reference-secrets-in-parameter)\n stored in Secret Manager within your parameter configurations. To use Parameter Manager,\n you must enable the Parameter Manager API and grant your users the\n [required IAM roles](/secret-manager/parameter-manager/docs/access-control).\n\nDifference between secrets management and key management\n--------------------------------------------------------\n\n- Secrets management and key management are both critical components of data security, but they serve distinct purposes and handle different types of sensitive information. The choice between secrets management and key management depends on your specific needs. If you want to securely store and manage confidential data, a secrets management system is the right tool. If you want to manage encryption keys and perform cryptographic operations, a key management system is the better choice.\n- You can use the following table to understand the key differences between Secret Manager and a key management system, such as [Cloud Key Management Service(Cloud KMS)](/kms/docs).\n\nEncryption of secrets\n---------------------\n\n- Secret Manager always encrypts your secret data before it is persisted to disk. To learn more about Google Cloud encryption options, refer to [Encryption at rest](/docs/security/encryption/default-encryption).\n- Secret Manager manages server-side encryption keys on your behalf using the same hardened key management systems that we use for our own encrypted data, including strict key access controls and auditing. Secret Manager encrypts user data at rest using AES-256. There is no setup or configuration required, no need to modify the way you access the service, and no visible performance impact. Your secret data is automatically and transparently decrypted when accessed by an authorized user.\n- The Secret Manager API always communicates over a secure HTTP(S) connection.\n- Those who require an extra layer of protection can enable CMEK and use their own encryption keys stored in Cloud Key Management Service to protect the secrets stored in Secret Manager. See the [CMEK documentation](/secret-manager/docs/cmek) for details on how to configure and use customer-managed encryption keys.\n\nWhat's next\n-----------\n\n - Learn how to [create a secret](/secret-manager/docs/creating-and-accessing-secrets).\n - Learn how to [add a secret version](/secret-manager/docs/add-secret-version).\n - Learn how to [edit a secret](/secret-manager/docs/edit-secrets).\n - Learn about [quotas and limitations](/secret-manager/quotas).\n - Learn about [best practices](/secret-manager/docs/best-practices)."]]
