Leitfaden zum Secret Management

Wir alle haben Geheimnisse. Manchmal sind es heimliche Vergnügen, die wir zu verbergen versuchen, etwa kitschige Reality-TV-Sendungen zu schauen oder uns seltsames Comfort Food zu gönnen. Oft machen wir uns Sorgen:

„Wie halten wir das Geheimnis sicher?“

„Was könnte passieren, wenn jemand das Geheimnis herausfindet?“

„Wer hütet ein Geheimnis?“

„Was passiert, wenn wir ein Geheimnis verlieren?“

Bei Bazaarvoice beginnt unser Sicherheitsteam beim Secret Management mit denselben Fragen. Es interessiert sich weniger für belanglose Geheimnisse, etwa wer sein Geschirr im Büro in der Spüle stehen gelassen oder die Milch ausgetrunken hat. Stattdessen konzentriert es sich auf die Secrets, die in den Systemen verwendet werden, die ein breites Spektrum an Produkten der Organisation antreiben. Dazu gehören:

• API-Schlüssel und Token

• Datenbank-Verbindungszeichenfolgen, die Passwörter enthalten

• Verschlüsselungsschlüssel

• Passwörter

Bei Hunderten von Systemen und Komponenten, die bei Bazaarvoice auf Secrets angewiesen sind, kann es ohne richtungsweisende Standards zur Herausforderung werden, sie aufzulisten und die oben genannten Fragen schnell, konsistent und zuverlässig zu beantworten.

In diesem Beitrag geht es um Secret Management, und wir erklären, wie Bazaarvoice mit Open-Source-Software einen Secret Catalog umgesetzt hat. Der Beitrag liefert wiederverwendbare Beispiele und hilfreiche Tipps, um Risiken zu senken und die Compliance in Ihrem Unternehmen zu verbessern. Legen wir los!

Secrets-Katalog

Bazaarvoice ist ISO27001Wird in neuem Fenster geöffnet-konform und stellt sicher, dass seine Systeme branchenübliche Tools und Verfahren nutzen, um Secrets sicher zu speichern. Sie liegen jedoch nicht immer am selben Ort und können mit unterschiedlichen Tools gespeichert werden. Manchmal ist AWS Secret ManagerWird in neuem Fenster geöffnet sinnvoll, in anderen Fällen ist AWS KMSWird in neuem Fenster geöffnet für eine bestimmte Lösung die bessere Wahl. Vielleicht haben Sie sogar eine Multi-Cloud-Strategie, durch die Secrets noch weiter verstreut werden. Hier ist ein Secrets Catalog äußerst nützlich, denn er bietet eine einheitliche Übersicht über Secrets, die in verschiedenen Tools und bei verschiedenen Anbietern liegen.

Das mag etwas langweilig klingen, und die erfassten Informationen werden meistens nicht benötigt. Kommt es jedoch zu einem Vorfall, wird ein geheimer Katalog zu einer unschätzbaren Ressource, um die Zeit zu verkürzen, die Sie zur Lösung des Problems brauchen.

Bazaarvoice erkannte den Wert eines Secrets Catalog und entschied sich, ihn einzuführen. Das Security-Team einigte sich darauf, dass jeder Eintrag im Katalog die folgenden Kriterien erfüllen muss:

• Ein einzigartiger Name

• Eine gute Beschreibung seines Zwecks

• Klare Verantwortlichkeit

• Wo sie gespeichert sind

• Eine Liste abhängiger Systeme

• Verweise auf Dokumentation zur Behebung damit zusammenhängender Vorfälle, zum Beispiel dazu, wie ein API-Schlüssel rotiert wird

Entscheidend ist, dass der Wert des Secretsan seinem ursprünglichen, sicheren Speicherort außerhalb des Catalogs verbleiben muss, aber es ist unerlässlich zu wissen, wo das Secret gespeichert ist. So vermeiden Sie einen Single Point of Failure und beeinträchtigen keine Erfolgskriterien.

Zu wissen, wo Secrets gespeichert sind, hilft dabei, schlechte Praktiken zu erkennen. Eine SSH-Schlüsseldatei nur auf den Laptops von Teammitgliedern aufzubewahren, wäre beispielsweise ein erhebliches Risiko. Eine Person kann das Unternehmen verlassen, im Lotto gewinnen oder sogar ein Getränk über seinen Laptop kippen (wir kennen alle jemanden!). Die bereits im Katalog definierten Speicherorte helfen den Menschen bei der Entscheidung, wie ein neues Secret gespeichert wird, und weisen ihnen sichere, freigegebene Tools zu, die gegen menschliche Fehler resistent sind.

Zugegeben: Der erste Versuch, den Katalog bei Bazaarvoice einzuführen, verlief nicht ganz nach Plan. Die Teams begannen, die Kriterien zu erfüllen, aber es wurde schnell klar, dass jedes Team unterschiedliche Interpretationen erstellte, die an mehreren Orten und in mehreren Formaten gespeichert wurden. Die Security hätte keine einheitliche Sicht, wenn am Ende mehrere Secret-Kataloge existieren würden. Die Teams würden zusätzliche Anleitung und einen konkreten Standard brauchen, um erfolgreich zu sein.

Dafür haben wir bereits die perfekte Lösung!

Bazaarvoice liebt Kataloge. Nach unseren Kunden sind sie vielleicht unser Liebstes. Für jeden unserer mehr als zehntausend Kunden gibt es einen Produktkatalog, dazu einen Datenkatalog und, was hier am wichtigsten ist, einen Servicekatalog auf Basis von BackstageWird in neuem Fenster geöffnet.

„BackstageWird in neuem Fenster geöffnet vereint alle Ihre Infrastruktur-Tools, Services und Dokumentationen zu einer durchgängig reibungslosen Entwicklungsumgebung.“

Standardmäßig enthält es zentrale Entitäten, die eine leistungsstarke Modellierung von Ökosystemen ermöglichen:

https://backstage.io/docs/features/software-catalog/system-model#ecosystem-modeling

Wie das obige Diagramm zeigt, stehen im Zentrum des Backstage-Modells Systems, Components und Resources, die für das Secret Management relevantesten Entitäten. Detaillierte Beschreibungen der einzelnen Entitäten finden Sie in der Backstage-ModellierungsdokumentationWird in neuem Fenster geöffnet. Kurz gesagt, lassen sie sich wie folgt verstehen:

• System

  – Eine Sammlung untergeordneter Entitäten, darunter Components und Resources, die als Abstraktionsschicht dient.

• Komponente

  – Ein Stück Software. Es kann optional APIs bereitstellen oder nutzen.

• Ressource

  – Die Infrastruktur, die Components für den Betrieb benötigen.

Neue Ressourcentypen

ResourcesWird in neuem Fenster geöffnet sind eine der Backstage-Entitäten, mit denen Infrastruktur abgebildet wird. Sie sind gut geeignet, um Secrets darzustellen, sodass wir keine eigene Software für dieselbe Aufgabe schreiben mussten. Daher haben wir zwei neue Resource Types definiert: secret und secret-store.

Tipp: Legen Sie vorab die zulässigen Typen fest, um eine Vielzahl von Varianten wie „database“ und „db“ zu vermeiden, die Suche und Filterung beeinträchtigen können.

Da der Aufwand für die Modellierung des Bazaarvoice-Ökosystems bereits investiert war, war es für die Teams trivial, das nötige YAML zur Definition von Secrets und Secret Stores hinzuzufügen.

Minimales Beispiel für einen Secret Store:

apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
name: aws-secrets-manager
description: Resources of type 'secret' can depend on this Resource to indicate that it is stored in AWS Secrets Manager
spec:
type: secret-store
owner: team-x

Minimales Beispiel für ein Secret:

apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
name: system-a-top-secret-key
description: An example key stored in AWS Secrets Manager
links:
- url:https://internal-dev-handbook/docs/how-to-rotate-secrets
title: Rotation guide
spec:
type: secret
owner: team-1
system: system-a
dependsOn:
- resource:aws-secrets-manager

Um schließlich die Verbindung zu bestehenden Systems, Components und Resources herzustellen, fügen Sie ihren Definitionen einfach einen dependsOn-Abschnitt hinzu. Zum Beispiel:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: system-a-component
...
spec:
...
dependsOn:
- resource:system-a-top-secret-key

Wie sieht es aus?

In unseren Augen ist es fantastisch! Schauen wir uns das Bild oben genauer an.

Der Abschnitt „About“ erklärt das Secret, unter anderem, mit welchem System es verknüpft ist, wem es gehört und dass es derzeit in Produktion ist. Außerdem enthält er einen Link zum Quellcode und eine Möglichkeit, Probleme oder Fehler wie Tippfehler zu melden.

Der Abschnitt „Relations“, der von einem zusätzlichen PluginWird in neuem Fenster geöffnet unterstützt wird, bietet einen visuellen, interaktiven Graphen, der die mit dem Secret verbundenen Beziehungen darstellt. Mit diesem Graphen können sich Nutzer schnell ein Bild von den Ressourcen im Kontext ihrer Systeme, Eigentümer und Komponenten machen. Die Navigation durch diesen Graphen hat sich als wirksamer und effizienter Mechanismus erwiesen, um die mit dem Secret verbundenen Beziehungen zu verstehen.

Der Abschnitt „Links“ bietet eine einheitliche Stelle, um auf Dokumentation zur Verwaltung von Secrets zu verweisen.

Schließlich lässt sich das PluginWird in neuem Fenster geöffnet „PagerDuty“ in das Bereitschaftssystem integrieren, sodass bei Notfällen keine manuelle Ermittlung von Ansprechpartnern mehr nötig ist.

Der Wert von Backstage zeigt sich in der Leistungsfähigkeit der verfügbaren Plugins. Suchen und Filtern erleichtern die Auffindbarkeit, und die API eröffnet das Potenzial für weitere Integrationen in interne Systeme.

Immer frisch bleiben

Eine genaue und aktuelle Dokumentation zu pflegen, ist immer eine Herausforderung. Den Servicekatalog gemeinsam mit den zugehörigen Codebasen abzulegen, hilft, das Risiko zu vermeiden, dass er veraltet, und ist zu einem Gesichtspunkt bei der Prüfung und Genehmigung von Änderungen geworden.

Wir stehen mit diesem Ansatz für einen Secrets-Katalog noch am Anfang und möchten unsere schrittweisen Verbesserungen in weiteren Blogbeiträgen teilen, sobald wir vorankommen.

Über den Autor

John McCloskey ist Principal Software Engineer und lebt in Belfast, Nordirland. Er leitet die Entwicklungsteams, die für die Plattformen Catalog und Actionable Insights von Bazaarvoice verantwortlich sind. In seiner Freizeit läuft, wandert und entdeckt John McCloskey gerne neue Reiseziele.