Best Practices für Secret Manager

In dieser Anleitung werden einige Best Practices für die Verwendung von Secret Manager vorgestellt. Der Leitfaden ist nicht als abschließende Liste von Empfehlungen zu betrachten. Wir empfehlen Ihnen, die Plattformübersicht zum Verständnis der allgemeinen Google Cloud-Landschaft sowie die Secret Manager-Übersicht zu lesen, bevor Sie diesen Leitfaden lesen.

Zugriffssteuerung

Der Zugriff auf die Secret Manager API ist durch IAM geschützt. Beachten Sie beim Gewähren von Berechtigungen für Secrets das Prinzip der geringsten Berechtigung.

Für die Authentifizierung bei der Secret Manager API sind Anmeldedaten erforderlich. Die Clientbibliotheken verfolgen alle eine ähnliche Strategie, um nach Anmeldedaten zu suchen, die als Standardanmeldedaten für Anwendungen bezeichnet werden.

  • Verwenden Sie für eine lokale Entwicklung gcloud auth application-default login. Dadurch wird eine Datei mit Anmeldedaten erstellt, die automatisch von Clientbibliotheken übernommen werden.

  • In Compute Engine und anderen Google Cloud-Computing-Plattformen wie Cloud Run-Funktionen erhalten die Clientbibliotheken Anmeldedaten über den Instanzmetadatenserver.

  • In GKE stellt Workload Identity auch Anmeldedaten über einen Metadatendienst bereit.

  • Auf anderen Plattformen wie Amazon Web Services oder Microsoft Azure sollten Sie die Workload Identity-Föderation einrichten, die vorhandene Identitätsmechanismen verwendet, um sich bei Google Cloud APIs zu authentifizieren.

Alle diese Methoden werden dem Export von Anmeldedaten für Dienstkonten vorgezogen, da sie keine sichere Speicherung und den Zugriff auf ein zusätzliches Secret außerhalb der Secret Manager API erfordern.

Programmierpraktiken

Übergeben Sie keine Secrets über das Dateisystem oder über Umgebungsvariablen an Ihre Anwendung. Im Folgenden finden Sie einige Gründe für die Verwendung anderer Methoden zum Umgang mit Geheimnissen:

  • Wenn im Dateisystem auf ein Secret zugegriffen werden kann, können Sicherheitslücken in Anwendungen durch Directory-Traversal-Angriffe einen höheren Schweregrad bekommen, da der Angreifer möglicherweise das Secret-Material lesen kann.

  • Wenn ein Secret über Umgebungsvariablen genutzt wird, können Fehlkonfigurationen wie das Aktivieren von Debug-Endpunkten oder das Einbeziehen von Abhängigkeiten, die Logprozess-Umgebungsdetails protokollieren, Secrets offenlegen.

  • Berücksichtigen Sie beim Synchronisieren von Secret-Material mit einem anderen Datenspeicher (z. B. Kubernetes Secrets) die Zugriffssteuerungen dieses Datenspeichers. Berücksichtige Folgendes:

    • Erweitert der Datenspeicher den Zugriff des Secrets?

    • Ist es möglich, den Zugriff des Secrets zu prüfen?

    • Entspricht der Datenspeicher Ihren Anforderungen hinsichtlich der Verschlüsselung ruhender Daten und der Regionalisierung?

Wir empfehlen, die Secret Manager API direkt mit einer der bereitgestellten Clientbibliotheken zu verwenden oder der REST- oder GRPC-Dokumentation zu folgen.

Verwaltung

Verweisen Sie auf Secrets über ihre Versionsnummer, anstatt den neuesten Alias zu verwenden. Stellen Sie mithilfe der vorhandenen Releaseprozesse Aktualisierungen von Versionsnummern bereit. Dies bedeutet in der Regel, dass Sie Ihre Anwendung mit einer bestimmten Secret-Version konfigurieren, die beim Start gelesen wird. Die Verwendung des neuesten Alias kann zwar praktisch sein, aber wenn ein Problem mit der neuen Version des Secrets auftritt, kann die Arbeitslast möglicherweise nicht die Secret-Version verwenden. Durch das Anpinnen an eine Versionsnummer kann die Konfiguration validiert und mit den vorhandenen Releaseprozessen ein Rollback durchgeführt werden.

Deaktivieren Sie Secret-Versionen, bevor Sie sie löschen oder Secrets löschen. Dadurch werden Ausfälle verhindert, indem das Secret in einen Zustand versetzt wird, der genauso wie ein Löschen erscheint, aber umkehrbar ist. Das heißt, Sie können es deaktivieren und eine Woche lang warten, damit Sie sicher sind, dass keine Abhängigkeiten bestehen, bevor Sie Daten endgültig löschen.

Legen Sie keine Ablaufzeit für Produktions-Secrets fest, es sei denn, Sie sind sicher, dass sie unwiderruflich gelöscht werden sollen. Das Ablauffeature eignet sich am besten für die automatische Bereinigung temporärer Umgebungen. Als Alternative zu ablaufenden Secrets sollten Sie zeitbasierte IAM-Bedingungen in Betracht ziehen.

Rotieren Sie Ihre Secrets regelmäßig, um Folgendes zu erreichen:

  • Auswirkungen im Fall eines gehackten Secrets begrenzen

  • Sicherstellen, dass Personen, die keinen Zugriff mehr auf ein Secret benötigen, ein zuvor aufgerufenes Secret nicht mehr verwenden können

  • Die Wahrscheinlichkeit eines Ausfalls verringern.

Überwachen Sie Secrets in Ihrer Organisation mithilfe von Cloud Asset Inventory aus folgenden Gründen:

  • Secrets in Ihrer Organisation identifizieren

  • Nichtkonformität mit Organisationsanforderungen wie Rotation, Verschlüsselungskonfiguration und Standort identifizieren

Aktivieren Sie Datenzugriffslogs, um AccessSecretVersion-Anfrageinformationen abzurufen und zu analysieren. Aktivieren Sie diese Option auf Ordner- oder Organisationsebene, um das Logging zu erzwingen, ohne sie für jedes Secret oder Projekt konfigurieren zu müssen.

Zusätzlich zu IAM-Steuerungen können Sie den Zugriff auf die Secret Manager API mit netzwerkbasierten Steuerungen beschränken, indem Sie einen VPC Service Controls-Perimeter für Ihre Organisation einrichten.

Mit der Organisationsrichtlinie constraints/iam.allowedPolicyMemberDomains können Sie die Identitäten begrenzen, die den IAM-Richtlinien für Secrets hinzugefügt werden können.

Berechnen Sie die maximale Nutzung von Secrets (berücksichtigen Sie dabei eine Thundering Herd von Anfragen aufgrund von gleichzeitigen Bereitstellungen von Anwendungen oder des Autoscaling Ihres Dienstes) und stellen Sie sicher, dass Ihr Projekt ein ausreichendes Kontingent zur Verarbeitung eines solchen Ereignisses hat. Fordern Sie ggf. eine Erhöhung des Kontingents an.

Einhaltung der Anforderungen an den Datenstandort

Wählen Sie regionale Secrets aus, wenn Sie strenge Anforderungen an den Datenstandort und die Datensouveränität haben. Mit regionalen Secrets können Sie sensible Daten an einem bestimmten geografischen Standort speichern. Sie erhalten vollständige Garantien für ruhende, verwendete und übertragene Daten und können so rechtliche, behördliche oder organisatorische Anforderungen in Bezug auf den Datenstandort erfüllen.