Was ist ein Secret?

Im Kontext der Anwendungssicherheit ist ein Secret jede Information, mit der sich während der Authentifizierung und Autorisierung nachweisen lässt, dass der Besitzer tatsächlich die Person oder Entität ist, für die er sich ausgibt. Gelangen böswillige Akteure an Secrets, erhalten sie unbefugten Zugriff auf Ihre Systeme. Diesen können sie für verschiedene Zwecke nutzen, etwa um Geschäftsgeheimnisse und Kundendaten zu stehlen oder Ihre Daten als Druckmittel für Lösegeldforderungen einzusetzen.

Ein klassisches Beispiel sind der Benutzername und das Passwort, mit denen eine Anwendung auf ihre Datenbank zugreifen kann. Zu den Secrets können jedoch unter anderem auch API-Schlüssel, Anmeldedaten, Zertifikate und private Schlüssel gehören. Da Secrets dazu dienen, den Zugriff auf die Ressourcen eines Unternehmens zu kontrollieren, ist ihre sichere Speicherung und ihr Schutz entscheidend, um das Risiko einer Kompromittierung des Unternehmens zu verringern.

Was ist Secrets Management?

Secrets Management ist der Prozess, den ein Unternehmen für folgende Zwecke einsetzt:

• Sensible Daten identifizieren
• Daten klassifizieren
• Kennzeichnen Sie die Daten
• Die Daten sicher speichern
• Geheimnisse verteilen
• Secrets regelmäßig rotieren (ersetzen)

Wenn Unternehmen von monolithischen Architekturen zu Microservices-Architekturen wechseln, steigt die Anzahl unabhängiger Anwendungs- und Infrastrukturkomponenten – jede mit eigenen Zugangsdaten –, sodass wesentlich mehr Secrets verwaltet werden müssen.

Möglichkeiten zur Speicherung von Secrets

Sehen wir uns zwei Möglichkeiten zur sicheren Speicherung von Geheimnissen genauer an:

Vault

Beim Vault-Ansatz wird ein Drittanbieter-Tool zur Verwaltung von Geheimnissen installiert. Die Vault-Lösung verschlüsselt jedes Geheimnis, um unbefugte Zugriffe zu verhindern. Der Vault stellt eine API bereit, über die Benutzer gemäß festgelegten Richtlinien auf Geheimnisse zugreifen können. Wenn sich Benutzer bei der API authentifizieren, können sie nur auf die Geheimnisse zugreifen, für die sie autorisiert wurden.

Nachteile:

• Sie müssen die Lösung und die Zugangsdaten selbst verwalten.
• Erfordert den Aufbau einer entsprechenden Infrastruktur, da Teams sonst nur schwer eigenständig damit arbeiten können

Vorteile:

• Branchenweite Vertrautheit (die meisten Entwickler wissen, wie man solche Tools verwendet)
• Lässt sich problemlos in andere vom Vault-Anbieter bereitgestellte Tools integrieren
• Einige Vaults sind kostenlos verfügbar

Auf dem Markt gibt es zahlreiche Tools, mit denen Entwickler verschlüsselte Geheimnisse speichern und verwalten können. Ein Beispiel für die Verwendung eines zentral automatisierten Tools zur Verwaltung von Geheimnissen finden Sie in unserem Blogbeitrag „Schutz privater SSL-Schlüssel in NGINX mit HashiCorp Vault“.

Cloud-Anbieter

Ein weiterer Ansatz besteht darin, einen Cloud-Anbieter für Secrets Management as a Service zu nutzen. Ein Vorteil ist, dass sich das Secrets-Management-Tool in der Regel eng in andere Cloud-Dienste wie verwaltete Datenbanken integrieren lässt. Die Dienste von Cloud-Anbietern bieten möglicherweise auch Funktionen wie die automatische Rotation. Ob diese Option jedoch zu Ausfallzeiten führt, muss noch untersucht werden.

Nachteil:

• In der Regel nicht kostenlos

Vorteile:

• Zugriff und Benutzeroberfläche werden vom Cloud-Anbieter eingerichtet und verwaltet.
• Lässt sich nahtlos in andere Dienste des Cloud-Anbieters integrieren
• Kann mit einem Infrastructure-as-Code-Tool verwaltet werden

Wo Geheimnisse nicht gespeichert werden sollten

Geheimnisse müssen sorgfältig verwaltet werden, damit es beim Entsperren und Abrufen nicht zu Störungen der Anwendung kommt. Es hat sich bewährt, Geheimnisse niemals in ein Versionsverwaltungssystem einzuchecken. Werden Geheimnisse dort gespeichert, kann dies für ein Unternehmen schwerwiegende Folgen haben, wenn sie versehentlich offengelegt oder kompromittiert werden, während ein Team oder eine Einzelperson den Code oder die Anwendung aktualisiert. Daher muss ein Geheimnis, das auch nur kurzzeitig in die Versionsverwaltung eingecheckt wurde, als kompromittiert betrachtet werden. Die sensiblen Daten müssen aus dem Repository entfernt und aus dem Verlauf des Versionsverwaltungssystems gelöscht werden.