Secrets Management: Wer weiß was, wo und wann?

Um sich dem Thema Secrets Management zu nähern, bietet es sich zunächst an, die offensichtlichste Frage zu beantworten: 

Was ist ein Secret?

Ein Secret ist im Allgemeinen eine sensible Information, die zur Authentifizierung an einem geschützten System verwendet werden kann [1]. Unter diese Definition fallen dabei sowohl typische Elemente der User-Authentifizierung wie Usernamen, Passwörter oder private SSH-Schlüssel als auch API-Token oder verschiedene Formen von kryptografischem Schlüsselmaterial. 

Alle Informationen haben eines gemeinsam: Wenn sie den falschen Akteuren in die Hände fallen, kann dies katastrophale Folgen haben. Die Bandbreite der Szenarien reicht dabei vom Verlust sensibler Geschäftsdaten bis zu den aktuell weit verbreiteten Ransomware-Attacken. 

Vielen fällt im Zusammenhang mit dem Verlust sensibler Daten zunächst der Sicherheitsfaktor Mensch ein. Der Verlust von User Credentials ist für Angreifer wahrscheinlich wirklich oft der erste Fuß in der Tür. Nicht umsonst rangiert Phishing nach wie vor weit oben in der Liste der größten Gefahren für die IT-Sicherheit [2].

Schutzmaßnahmen 

Um das Risiko der Kompromittierung von User Credentials zu verringern, raten Experten daher zu den folgenden Maßnahmen [3]. 

1. Verwendung von:

Jede dieser Maßnahmen soll es Angreifern auf andere Art und Weise erschweren, Accounts zu übernehmen. Aber was, wenn dies doch einmal gelingt? Lassen sich die vorgeschlagenen Maßnahmen auf die dahinter liegenden Systeme übertragen? 

So viel wie nötig, so wenig wie möglich 

Neben der Erschwerung von Kompromittierungen, ist die Reduktion des entstandenen Schadens eines der Hauptprinzipien des sicheren Designs von IT-Systemen [4]. Zu den Schutzmaßnahmen aus diesem Bereich zählt unter anderem die Einhaltung des Least-Privileg-Prinzips. So sollten Nutzer und Systeme nach Möglichkeit nur die für ihre Arbeit unbedingt notwendigen Berechtigungen erhalten [5]. 

Vor allem bei Mitarbeitenden von IT-Unternehmen finden sich für einen Angreifer oft höchst interessante Daten für das weitere Vorgehen. Insbesondere bei Administrator:innen oder Entwickler:innen mit Zugriff auf Produktivsysteme lassen sich API-Token, Datenbankpasswörter oder andere sensible Informationen erbeuten. Die Strategie, wie sicher mit diesen Daten umgegangen werden soll, ist das Secrets-Management [6].

Wer suchet, der findet 

Die Übernahme von User-Accounts ist aber nicht die einzige Möglichkeit, an Secrets zu gelangen. Auch Quellcode oder Konfigurationsdateien auf Webservern sind ein lohnendes Ziel. Erlangt ein Angreifender Zugriff auf ein verwundbares System, findet er hier oft auch Zugangsdaten zu dahinter liegenden Services, z.B. die der verwendeten Datenbank. Dieser Fall ist weder selten noch ungefährlich, denn „Hard Coded Credentials“ sind als CWE-798 eine der häufigsten Software-Schwachstellen [7]. Im ungünstigen Fall wiederholen sich hier die Probleme der User-Authentifizierung: Wurden die Credentials zur Datenbank wiederverwendet? Hat der verwendete User mehr Rechte, als für die Applikation nötig gewesen wären? Eine Verkettung unglücklicher Umstände? Das mag schon sein, allerdings greift hier sinngemäß das Sprichwort: „Der Angreifer muss nur einmal gewinnen“. Man sollte es nicht darauf ankommen lassen. 

Mit der zunehmenden Adaption von Infrastructure-as-Code-Methoden ergibt sich für Angreifende durch die verwendeten Version Control Systeme (VCS) ein weiteres Ziel. Denn auch hier gelten „Hard Coded Credentials“ als eine der weit verbreiteten Schwachstellen [7][8]. Vor allem wenn, wie zum Beispiel bei Open-Source-Software, öffentlich erreichbare Repositories verwendet werden, ist die versehentliche Veröffentlichung von Secrets über diesen Weg keine Seltenheit [9]. Aber auch bei ausschließlicher Verwendung privater VCS, gibt es interessante Ziele auf Servern oder Entwicklungsmaschinen. In lokal ausgecheckten Repositories finden sich mitunter weitere Zugänge, versteckt in der Git-History. 

Die verschiedenen Szenarien der Verteilung von Secrets an unterschiedlichen Stellen und die damit einhergehende Vergrößerung der sich bietenden Angriffsfläche werden unter dem Stichwort „Secret Sprawl“ zusammengefasst [10].

Secret-Management-Systeme 

Eine der Möglichkeiten, dieser Klasse von Problemen zu begegnen, ist der Einsatz von Secret-Management-Systemen. Vertreter dieser Kategorie sind unter anderem Cyberark Conjour, Hashicorp Vault oder durch Cloud Provider angebotene Lösungen wie Azure Key Vault bzw. AWS Secret Manager. Wichtig ist hier aber die aktive Abgrenzung zur Gruppe der Passwort-Manager wie Bitwarden, LastPass oder 1Password, um nur ein paar Beispiele zu nennen. 

Das skizzierte Problem der in lokalen Dateien vorhandenen Secrets kann durch den Einsatz eines Secret-Management-Systems vermieden werden. Am Beispiel der Entwicklungsumgebung muss ein User sich nun zu Beginn seiner Arbeit am Secret-Server authentifizieren. Er erhält dadurch bei korrekter Einrichtung ausschließlich Zugriff auf die für seine Tätigkeit benötigten Secrets. Diese können z.B. über die Umgebungsvariablen seiner Applikation nach dem Konfigurations-Grundsatz der 12-Faktor App übergeben werden [11]. 

Dieses Muster lässt sich auch auf die Arbeit mit CI/CD-Pipelines übertragen. So ist es möglich, einer Applikation beim Build oder dem Deployment durch eine Pipeline je nach Umgebung stets die passenden Secrets bereitzustellen, ohne den Entwickler:innen direkten Zugriff auf diese zu ermöglichen. 

Durch die Konzentration der wichtigen Secrets auf ein zentrales System können Policies zu Komplexität und Rotationsdauer wesentlich effizienter eingehalten werden. Dazu lassen sich durch die zur Verfügung gestellten Audit-Logs weitere Einsichten gewinnen. Richtig konfiguriert kann so mit der besseren Erkennung möglicher Angriffe eine weitere Säule des sicheren Designs gestärkt werden [4]. Dass in diesem Bereich besondere Anforderungen an Absicherung und Verfügbarkeit des Services bestehen, versteht sich von selbst. 

Die Bereitstellung von Secrets für Machine-User wie z.B. den eingangs beschriebenen Webserver stellt eine eigene Herausforderung dar und wird allgemein als „Secret Zero Problem“ definiert [12][13]. Häufig lassen sich hier Identitätsmechanismen der verwendeten Plattform wie z.B. Kubernetes RBAC oder AWS IAM nutzen. In der Regel bieten Secret Management Systeme aber auch flexible Lösungen zur Einbindung bestehender Applikationen. Am Beispiel von HashiCorp Vault lassen sich hier z.B. die AppRole Authentifizierung [14][15] mit dem Vault-Agent [16] kombinieren. 

Fazit 

Lösungen in diesem Bereich müssen immer individuell an die eigene Umgebung angepasst werden. Viele Probleme sind dabei nicht technischer, sondern organisatorischer Natur. Eine umfassende Betrachtung der eigenen Anforderungen mit allen Beteiligten ist daher oft der erste wichtige Schritt. Effektive Verbesserungen lassen sich oft bereits mit einfachen Mitteln implementieren, es lohnt sich also einen genaueren Blick auf dieses spannende Thema zu werfen. 

References 

• [1] “Authentication secret,” CSRC Glossary. [Online].

• [2] M. Shacklett, “Top cybersecurity threats for 2023,” TechRepublic, 17-Nov-2022. [Online]. Available: https://www.techrepublic.com/article/top-cybersecurity-threats. [Accessed: 27-Nov-2022]. 
• [3] Iulia Ion, Rob Reeder, and Sunny Consolvo. 2015. „…​No one can hack my mind“: comparing expert and non-expert security practices. In Proceedings of the Eleventh USENIX Conference on Usable Privacy and Security (SOUPS ’15). USENIX Association, USA, 327–346. 
• [4] “Cyber Security Design principles,” NCSC. [Online].
• [5] “Least privilege,” CyberArk, 17-Jul-2020. [Online]. Available: https://www.cyberark.com/de/what-is/least-privilege/. [Accessed: 27-Nov-2022]. 
• [6] D. Bornkessel, “Modernes Secrets-Management,” INNOQ, 14-Nov-2019. [Online]. Available: https://www.innoq.com/de/articles/2019/11/modernes-secrets-management/#:~:text=Secrets%2DManagement%20beschreibt%20Strategien%2C%20wie,Verschl%C3%BCsseln%20von%20Daten%20genutzt%20werden. [Accessed: 27-Nov-2022]. ‌ 

• [7] “Common weakness enumeration,” CWE. [Online]. Available: https://cwe.mitre.org/data/definitions/798.html. [Accessed: 27-Nov-2022]. 
• [8] A. Rahman, C. Parnin and L. Williams, „The Seven Sins: Security Smells in Infrastructure as Code Scripts,“ 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE), 2019, pp. 164-175, doi: 10.1109/ICSE.2019.00033. 
• [9] M. Meli, M. R. McNiece, and B. Reaves, “How bad can it git? characterizing secret leakage in public github repositories,” Proceedings 2019 Network and Distributed System Security Symposium, 2019. 
• [10]“Secrets sprawl definition,” GitGuardian. [Online]. Available: https://www.gitguardian.com/glossary/secret-sprawl-definition. [Accessed: 27-Nov-2022]. 
• [11] A. Wiggins, The twelve-factor app. [Online]. Available: https://12factor.net/config. [Accessed: 28-Nov-2022]. 

• [12] J. Walsh, “Secret zero: Eliminating the ultimate secret,” Conjur, 28-Apr-2021. [Online]. Available: https://www.conjur.org/blog/secret-zero-eliminating-the-ultimate-secret/. [Accessed: 28-Nov-2022]. 
• [13]C. Huysmans, “Secret zero: Mitigating the risk of secret introduction with Vault,” HashiCorp, 24-Nov-2020. [Online]. Available: https://www.hashicorp.com/resources/secret-zero-mitigating-the-risk-of-secret-introduction-with-vault. [Accessed: 28-Nov-2022]. 
• [14] T. Sacilowski, “Delivering secret zero: Hashicorp Vault approle with HashiCorp Terraform and chef,” HashiCorp, 09-Mar-2018. [Online]. Available: https://www.hashicorp.com/resources/delivering-secret-zero-vault-approle-terraform-chef. [Accessed: 28-Nov-2022]. 
• [15] “Approle – AUTH methods,” HashiCorp Developer. [Online]. Available: https://developer.hashicorp.com/vault/docs/auth/approle. [Accessed: 28-Nov-2022]. 
• [16] “Vault agent,” HashiCorp Developer. [Online]. Available: https://developer.hashicorp.com/vault/docs/agent. [Accessed: 28-Nov-2022].