Softwareentwicklungs-Richtlinien – Secrets Management in Legacy Systemen

In Softwareprojekten werden oft sensible Daten verwendet, wie beispielsweise Zugangsdaten zu Servern, Datenbanken oder Cloud-Diensten. Um den Verlust von vertraulichen Informationen oder den Missbrauch durch Dritte zu verhindern, müssen diese Daten sicher aufbewahrt werden. Das richtige Secrets-Management ist daher ein wichtiger Bestandteil der IT-Sicherheit in Softwareprojekten. Es umfasst alle Maßnahmen, die zur sicheren Verwaltung von sensiblen Daten getroffen werden.

Besonders in den verteilten Systemen/in einem Microservices-Umfeld kann Secrets Management zu einer Herausforderung werden, denn im Vergleich zu relativ konstanten, nicht-verteilten Monolithen sind solche Systeme sehr dynamisch, es gibt viele Komponenten, die einen Secret benötigen und die Secrets ändern sich oft.

Eine ganz andere Herausforderung stellt Secrets Management für Legacy Systeme dar – weil sukzessive die Verbesserung eines unsicheren Standards eines laufenden Alt-Systems erfolgen muss, ohne dabei das System selbst zu stark zu ändern.

Viele Gründe sprechen für die Implementierung eines Secrets Managements, z. B.:

• Schutz von sensiblen Daten: Secrets Management hilft, sensible Daten vor unbefugtem Zugriff, Offenlegung oder Manipulation zu schützen.
• Verbesserte Compliance: Durch das richtige Secrets Management können Unternehmen die Einhaltung gesetzlicher Vorschriften, wie z. B. die DSGVO, gewährleisten.
• Erhöhte Sicherheit: Secrets Management trägt dazu bei, die Sicherheit von Softwareprojekten insgesamt zu erhöhen.

Die Vorteile sind:

• Reduzierung von Sicherheitsrisiken: Durch das richtige Secrets Management werden die Risiken von Datenverlust, Datenmissbrauch und Sicherheitsvorfällen reduziert.
• Verbesserte Effizienz: Secrets Management kann die Effizienz von Softwareprojekten erhöhen, indem es die manuelle Verwaltung von sensiblen Daten automatisiert.
• Senkung der Kosten: Secrets Management kann die Kosten für die IT-Sicherheit senken, indem es die Notwendigkeit für zusätzliche Sicherheitsmaßnahmen reduziert.

Die Vernachlässigung des Secrets Managements kann zu vielfältigen Gefahren und schwerwiegenden Folgen führen. Dazu zählen insbesondere:

• Datenmissbrauch: Unbefugter Zugriff auf sensible Daten kann auch deren Missbrauch nach sich ziehen. Dies kann zu Identitätsdiebstahl, Finanzbetrug oder sogar zu Unternehmensspionage führen.
• Sicherheitsvorfälle: Cyberangriffe und andere Sicherheitsvorfälle, können durch unbefugten Zugriff auf sensible Daten erleichtert werden. Auch eine Verschlüsselung der im Unternehmen vorhandenen Daten ist möglich. Dies kann zu erheblichen Schäden für Unternehmen führen, wie z. B. Produktionsausfällen, Reputationsschäden, Datenverlust, Betriebsunterbrechungen oder sogar zu (temporären) Betriebsschließungen.
• Die Folgen von vernachlässigtem Secrets Management können für Unternehmen sehr kostspielig sein. Schätzungen zufolge belaufen sich die weltweiten Kosten für Cyberangriffe auf jährlich auf mehrere Billionen US-Dollar.

Unter einem Secret versteht man folgende Daten:

• Zugangsdaten zu Servern, Datenbanken oder Cloud-Diensten
• API-Schlüssel
• Passwörter
• Private Schlüssel

Secrets werden in Softwareprojekten verwendet, um auf sensible Ressourcen zuzugreifen oder diese zu verwenden. Beispielsweise werden Zugangsdaten verwendet, um sich auf Servern oder in Datenbanken anzumelden. API-Schlüssel werden verwendet, um auf Cloud-Dienste zuzugreifen. Die Funktion von Passwörtern bedarf hier keiner Erläuterung.

Unter private Schlüssel versteht man in den asymmetrischen Kryptographie-Verfahren den Teil des Schlüssels, der für die Entschlüsselung von Daten (oder für das Erzeugen von digitalen Signaturen) benutzt wird, und der, im Vergleich zum öffentlichen Schlüssel (der öffentlich gemacht werden muss) nur dem Eigentümer des Schlüssels bekannt sein darf.

Bevor wir in die detaillierte Beschreibung von dem Aufbau von Secrets Management sprechen, gehen wir kurz über die verbreiteten “Antipatterns” und “Patterns” also wie Secrets Management falsch bzw. richtig gemacht wird:

• Don’t 1: Secrets im Plaintext in einem Version Control System (VCS) speichern – auch wenn die meisten VCS nur intern verfügbar sind, besteht trotzdem die Gefahr, dass Unbefugte auf die Secrets Zugriff bekommen. Außerdem gibt es bei den meisten VCS keine Möglichkeit, die Daten (Secrets) endgültig zu löschen, da, auch wenn dies in der aktuellen Version gemacht wird, die gespeicherten Secrets trotzdem in der Historie sichtbar bleiben.
• Do 1: Wenn man die Secrets in einem VCS speichern muss, sollte dies mithilfe von diversen Frameworks verschlüsselt erfolgen (siehe unten)
• Don’t 2: Die Secrets auf den Servern im Plaintext in den Textdateien (Applikation-Properties) speichern – auch wenn dies sicher erscheint, weil man sich, um auf den Secret Zugriff zu erlangen, anmelden muss (z. B. per SSH), bestehen hier immer noch folgende Gefahren:
  • Bei falsch eingestellten Berechtigungen können unbefugte Programme oder Benutzer, die sonst auf dem Server laufen, auf die Secrets Zugriff bekommen
  • Das Verwalten der Secrets (das Abspeichern auf dem Server) muss entweder manuell erfolgen (was den Wartungsaufwand erhöht, besonders bei den verteilten Systemen) oder mit “Home-Made”-Skripten, die aber die Secrets dann aus einer Quelle beziehen sollen.
• Do 2: Statt die Secrets auf den Servern im Plaintext in den Textdateien zu speichern, sollten die unten erwähnte Patterns/Frameworks genutzt werden.
• Don’t 3: Das Rad neu erfinden – wie bei fast allen sicherheitsrelevanten Problemstellungen, wie z. B. der Verschlüsselung, ist der Aufwand, alles alleine und richtig (und vor allem sicher) zu entwickeln viel zu groß. Im Zweifel ist der Aufwand viel größer, als existierende Tools zu nutzen.
• Do 3: Es gibt viele existierende Tools und Frameworks, viele davon OpenSource, die in eigenen Projekten benutzbar sind. Auch wenn viele von diesen Tools eine Lernkurve haben, und die Entwickler und OPS deren Handhabung erst erlernen müssen, ist dies für die Zukunft gut investierte Zeit und Geld.

Jetzt, da wir wissen, wieso richtiges Secrets Management wichtig ist, schauen wir auf die Möglichkeiten, die es gibt, um Secrets Management richtig aufzubauen.

Es gibt viele Frameworks, die helfen, Secrets zu verwalten. Die Frameworks können auch miteinander kombiniert werden, abhängig von den Projektanforderungen.

Einige dieser Frameworks können auch für das Konfiguration Management verwendet werden (siehe dazu unsere weiteren Blogbeiträge). Hier eine kleine Auswahl an Frameworks:

Spring Cloud Config

Spring Cloud Config ist wohl das einfachste Framework zum Management von Secrets, und eignet sich für kleinere Projekte und überschaubare Deployments. Dieses Framework, an sich selbst für das Konfiguration Management gedacht, kann aber rudimentär auch für Secrets Management genutzt werden:

• Secrets werden entweder mit einem symmetrischen oder einem asymmetrischen Schlüssel verschlüsselt. Dazu bietet Spring Cloud Config Server eine Schnittstelle.
• Verschlüsselte Secrets werden in einem Backend (z. B. GIT-Repository oder eine Datenbank) gespeichert.
• Die Applikationen, die das Secret verwenden wollen, greifen über HTTPS auf den Config Server zu
• Der Config Server lädt dann die angefragten Secrets aus dem Backend, entschlüsselt sie, und leitet die entschlüsselten Secrets an die Applikation weiter.

Ein Vorteil dabei ist, dass die Secrets selbst verschlüsselt gespeichert sind, und daher auch in einem unsicheren Medium wie bspw. ein VCS, gespeichert werden können. Ein weiterer Vorteil ist, dass die Secrets nur ein einer Stelle (Repository/Backend) abgelegt werden, und nicht manuell über alle Server verteilt werden müssen.

Ein zusätzlicher Vorteil von Spring Cloud Config ist, dass es parallel auch für das Konfiguration-Management (Siehe dazu unsere weiteren Blogartikel) eingesetzt werden kann.

Im Vergleich zu HashiCorp Vault (siehe unten) ist Spring Cloud Config einfacher zu verstehen und zu erlernen. Spring Cloud Config Server kann zudem auch in eine Spring Boot Applikation integriert werden.

Ein Nachteil von Spring Cloud Config ist, dass der symmetrische oder asymmetrische Schlüssel, mit dem die Secrets verschlüsselt sind, eine Schwachstelle darstellen kann. Bei Bekanntwerden dieses Schlüssels werden verschlüsselte Secrets für den potentiellen Angreifer sichtbar. Daher ist es ratsam, z. B. Key Rotation für den Schlüssel zu nutzen.

Weiterer Nachteil von dem Management von Secrets mit Spring Cloud Config ist, dass dieses Framework nur mit Java/Spring-Framework verwendet werden kann – werden andere Programmiersprachen und Frameworks eingesetzt, muss auf andere Tools für die Verwaltung von Secrets zugegriffen werden.

HashiCorp Vault

HashiCorp Vault ist ein (komplexeres) Framework für Secrets Management, das sich für größere Projekte und größere Infrastrukturen eignet.

Im Gegensatz zu Spring Cloud Config, ist Vault kein Konfiguration Management Tool, sondern ein Tool exklusiv für das Verwalten von Secrets.

Vault bietet eine Reihe von Funktionen, die es zu einer sicheren und flexiblen Lösung für die Secrets-Verwaltung machen. Dazu gehören:

• Identitätsbasierte Sicherheit: Vault verwendet Authentifizierungsmethoden wie Active Directory, LDAP oder OpenID Connect, um den Zugriff auf Secrets zu kontrollieren.
• Dynamische Geheimnisse: Vault kann Secrets dynamisch generieren, z. B. Passwörter für Anwendungen oder SSH-Keys für Server.
• Rotation von Secrets: Vault kann Secrets automatisch rotieren, um die Sicherheit zu erhöhen.
• Audit-Protokolle: Vault zeichnet alle Zugriffe auf Secrets auf, um die Sicherheit zu gewährleisten.

Ein Vorteil von Vault ist, dass es in einer heterogenen Infrastruktur eingesetzt werden kann. Es kann einfach mit unterschiedlichen Programmiersprachen und Frameworks integriert werden:

• SpringVault für die Integration mit SpringBoot/Java
• Vault C#-Client für die Integration mit .NET/C#
• HVAC für die Integration mit Python
• Node-Vault für die Integration mit Node.JS

Git-Crypt

Git Crypt (und ähnliche Projekte/Werkzeuge) ist an sich selbst kein Secrets-Management-Framework. Vielmehr handelt es sich lediglich um ein Tool, mit dem ein Git-Repository mit GPG verschlüsselt wird. Trotzdem kann es für einfache Infrastrukturen (z. B. keine Cloud, kein K8S, keine Microservices) eingesetzt werden, um Secrets verschlüsselt in einem Git-Repository speichern zu können.

Nachteil ist, dass dabei die Verwaltung von Secrets (Auschecken von Repository, Anbringen der Secrets in der jeweiligen Applikation) eigenständig implementiert werden muss.

Daher empfiehlt sich der Einsatz von Git-Crypt lediglich entweder für sehr kleine Projekte (nur eine Applikation, keine Cloud) oder für Proof-Of-Concept.

Größere Projekte sollten auf andere Frameworks setzen.

Kubernetes Secrets

Wenn das Projekt schon Kubernetes verwendet oder auf die Migration auf Kubernetes abzielt, kann auch das im Kubernetes vorhandene Secrets Management eingesetzt werden.

Kubernetes bietet folgende Möglichkeiten, um die Sicherheit von Secrets zu gewährleisten:

• Verschlüsselung: Alle Secrets werden in Kubernetes verschlüsselt gespeichert. Dies verhindert, dass unbefugte Personen den Inhalt des Secrets lesen können.
• Rollenbasierte Zugriffskontrolle (RBAC): RBAC kann verwendet werden, um den Zugriff auf Secrets zu steuern. Mit RBAC kann festgelegt werden, welche Benutzer oder Rollen auf bestimmte Secrets zugreifen können.
• Externe Secrets: Secrets können auch in einem externen Speicher, wie bspw. einem Keystore oder einem Cloud-basierten Secret-Manager, gespeichert werden. Dies kann die Sicherheit der Secrets erhöhen, da sie nicht im Kubernetes-Cluster abgelegt werden.

Cloudprovider-spezifisches Secrets-Management

Eine weitere Möglichkeit Secrets-Management aufzubauen, bietet der Einsatz von durch jeweilige Cloudanbieter zur Verfügung gestellte Frameworks, wie z. B. AWS Secrets Management oder Azure Key-Vault.

Vorteile vom Cloud-Spezifischen Secrets-Managements

• Transparente Integration mit den anderen Tools und Diensten des jeweiligen Cloudanbieters.
• Technischer Support durch jeweiligen Cloudanbieter.
• Einfachere und schnellere Umsetzung in der jeweiligen Cloud, ein PoC kann daher auch schnell aufgebaut werden.

Nachteile vom Cloud-Spezifischen Secrets-Management:

• Vendor Lock-In: will man den Cloudanbieter wechseln oder auf On-Premise umsteigen, muss das gesamte Secrets-Management neu aufgebaut werden
• Technischer Support kommt um seinen Preis – wie bei anderen Clouddiensten hat man üblicherweise nur ein bestimmtes Kontingent, das man kostenlos benutzen kann, danach muss man bezahlen, und die Preise können nicht gerade billig sein.

Leitfaden für den Aufbau von Secrets Management in Legacy Systemen

Jetzt, da wir wissen, was Secrets Management ist und wieso es wichtig ist, stellen sich viele Fragen: wie wird das richtige Secrets Management gebaut? Welche Schritte sind zu gehen? Welche Besonderheiten sind zu beachten, wenn man ein Secrets Management für ein Legacy System aufbauen möchte? Was gibt es allgemein zu berücksichtigen?

Die Antwort auf die Frage nach den technischen Schritten unterscheiden sich von Projekt zu Projekt. Allgemeine Schritte können aber wie folgt zusammengefasst werden:

• Folgende Informationen sollten zunächst eingeholt werden:
  • Wie groß ist das System? Besteht es aus Microservices, oder ist es ein Monolith?
  • Handelt es sich um ein Legacy-System, bei dem die Secrets bereits manuell z. B. auf dem Server angelegt sind, oder ist es ein „Green-Field-Projekt“?
  • Wird das System On-Premise deployt, oder bei einem Cloud-Anbieter gehostet? Wenn das System bei einem Cloud-Provider gehostet ist – wie wahrscheinlich ist es, dass der Cloud-Anbieter gewechselt wird?
  • Wird Kubernetes benutzt bzw. soll es auf Kubernetes migriert werden?
  • Welche Programmiersprachen / welche Frameworks werden benutzt?
• Im nächsten Schritt soll man den geplanten Aufbau und Architektur von dem Secrets-Management dokumentieren. Dafür bietet sich ARC42 / Dokumentation As Code (siehe dazu unsere weiteren Blogartikel). Dabei muss klar definiert werden, wo und wie genau das Secret-Management-Tool deployt wird, und wie es an die entsprechenden Applikationen angebunden wird.
• Zudem ist festzulegen und zu dokumentieren, welche Benutzer und welche Applikationen auf welche Secrets zugreifen dürfen (z. B. Entwickler sollen generell auf die Secrets für die Testumgebung zugreifen können, nicht aber auf die Secrets für die produktive Umgebung). Das gleiche gilt für die Applikation. Ein CRM muss Zugriff auf die Secrets für die CRM-Datenbank haben, nicht aber den Zugriff auf die Secrets für z. B. das Paymentsystem. Dies ist für jede Organisation unterschiedlich, und muss für jedes Projekt erarbeitet werden.
• Eine weitere Dokumentation ist erforderlich für die Festlegung, wie die Applikationen Secrets Management benutzen sollen.
• Die Entwickler und OPS sollten geschult und es sollten, Beispielprojekte erstellt werden.
• Die Secrets-Policy muss dokumentiert werden (z. B. Key-Rotation – wie oft werden die Secrets rotiert).
• Einen PoC (Proof-Of-Concept) aufbauen – in einer Testumgebung.
  • Ein Proof-Of-Concept (POC) demonstriert die prinzipielle Machbarkeit des Aufbaus von Secrets-Management, indem dieses erstmal nur für ein ausgewähltes Subsystem / eine ausgewählte Applikation aufgebaut wird.
• PoC auf Acceptance und Produktion ausweiten.
• Parallel zu den letzten zwei Schritten soll Secrets Management an das interne Monitoring und Tracing (siehe unsere weitere Blogartikel) angebunden werden, um vor allem unerlaubte Zugriffe feststellen zu können. (siehe hier auch unseren Blogbeitrag: “Monitoring und Obervability für ein Legacy System”)

Besonderheiten beim Aufbau von Secrets Management für ein Legacy-System

Beim Aufbau von Secrets Management für ein Legacy-System gibt es folgende Besonderheiten, die zu beachten sind:

• Höchstwahrscheinlich liegen die Secrets entweder manuell verwaltet auf einem Server oder im schlimmsten Fall unverschlüsselt in einem Git-Repository. In beiden Fällen müssen die produktive Secrets nach dem Einführen von Secrets Management neu generiert werden, da die alte Secrets schon kompromittiert sein können.
• Um existierende Applikationen anzupassen, empfiehlt es sich, zunächst einen Teil des Gesamtsystems auszuwählen und das Secrets Management als Proof of Concept zu implementieren.
  • Infolgedessen werden eine Zeit lang parallel zwei Secrets-Management-Systeme existieren – das neue “richtige” und das alte “falsche”. Das kann auf gewissen Widerstand seitens der Entwickler und OPS stoßen, weil es Mehraufwand für den Betrieb und die Entwicklung bedeutet, daher soll die Migration zügig und konsistent verlaufen.
• Es empfiehlt sich, einen Plan aufzubauen, welche Teile von dem System in welcher Reihenfolge angepasst werden sollen.

Fazit

Es gibt viele gute Gründe für die Einführung eines Secrets Managements. Ein effektives Secrets Management erfordert viel Zeit, Ressourcen, Lernen und Geduld. Besonders bei Legacy-Systemen kann dies eine große Herausforderung darstellen. Es gibt viele Fallstricke, die es zu vermeiden gilt. Diverse Tools und Frameworks, die wir Ihnen vorgestellt haben, stehen zur Verfügung. Anhand eines Leitfadens haben wir Ihnen vorgestellt, was eine sinnvolle Schritt-für-Schritt-Herangehensweise für die Implementierung ist. Hier gilt es, anhand der eigenen Anforderungen das richtige Tool auszuwählen und zu implementieren.

Wenn die Einführung von Secrets Management richtig durchgeführt wird, können Kosten gespart und die Sicherheit erhöht werden.

Möchten Sie mehr über die Einführung von Secrets Management erfahren?

Wenn Sie mehr erfahren möchten oder bereits über die Einführung eines Secrets Managements nachgedacht haben, unterstützen wir Sie gerne auf dem Weg zu einem sicheren und effizienten Secrets Management. Kommen Sie gerne auf uns zu!