Nichts Passendes dabei? Stellen Sie ein, welche Inhalte Sie auf aleri.de sehen möchten:
Bei Aleri bauen wir für unsere Kunden u.a. Enterprise CMS- und eCommerce-Lösungen und benötigen häufig Komponenten, um Backends und Unternehmens-IT zu integrieren - gerne auch Microservices. Jede Anwendung benötigt Konfiguration, sowohl die eher monolithischen Standardsysteme wie auch die kleineren Komponenten, da sie mit anderen Microservices, Datenbanken und Systemen wie CRM oder PIM kommunizieren müssen. Dabei sind natürlich auch Secrets wie z. B. Benutzername und Passwort, Tokens oder X.509-Zertifikate zu finden.
Konfiguration kann auf verschiedene Arten in die Applikation kommen, z. B. 12-Factor-like über Environment-Variablen oder wie in vielen Fällen über eine Konfigurationsdatei. Letztlich müssen sich Einträge für Environmentvariablen auch aus einer Quelle wie einem Startskript speisen, wobei in vielen solcher Fälle wieder Dateien zum Einsatz kommen. Weil die Verteilung von Dateien auf viele Server, möglichst noch in verschiedenen Verzeichnissen oder Arten (z. B. Einpacken in ein Java Archive) aufwändig ist, übernimmt das ganze ein Konfigurationsmanagement-Werkzeug wie z. B. Ansible.
Durch die Brille der IT-Sicherheit ist die Verteilung von sensitiven Daten über Konfiguration nicht ganz unproblematisch. Dateien mit sensitiven Inhalten wie Passwörtern oder privaten Schlüsseln müssen ausreichend geschützt werden. Wenn es einem Eindringling gelingt, über den Einbruchspfad einer Applikation diese Dateien auslesen zu können, kann er Daten manipulieren oder zusätzliche Daten erbeuten, mit denen er seinen Einbruch ausweiten kann.
Eine weitere Herausforderung ergibt sich über die Prozesse des Konfigurationsmanagements: Wenn ein Werkzeug wie z. B. Ansible eine Konfigurationsdatei mit Passwörtern irgendwo ablegen soll, muss es sich die Datei auch besorgen können, z. B. aus einem Git-Repository. Also liegen die kritischen Informationen gleich an mehreren Stellen ab und werden mehrfach weitergereicht. “Encryption in transit” ist kein Problem mehr, für “Encryption at rest” im Zusammenhang mit Repositories und Continuous Integration bzw -Delivery-Werkzeugen gab und gibt es vereinzelte Ansätze, die aber im Einsatz auch aufwändig sind.
Zu guter Letzt: Wenn ein Angreifer z. B. ein Datenbankkennwort erbeutet und dieses Kennwort praktisch nie gewechselt wird (“password rotation”), hat der Angreifer - solange er unentdeckt bleibt - ungestörten Zugriff, vielleicht kann er auch Monate später wiederkommen. Genug Gründe, etwas dagegen zu tun.
Das Ziel sollte sein, die Speicherung und Verarbeitung von Secrets möglichst sicher zu gestalten. Dazu gehören neben Encryption-in-transit und Encryption-at-rest auch das regelmäßige, möglichst automatische und transparente Rotieren von Passwörtern, und die automatische Verwaltung von Zertifikaten und Tokens mit möglichst kurzer Laufzeit. Denn wenn die Prozesse dahinter vollautomatisch ablaufen spricht nichts dagegen, Kennwörter, Token und Zertifikate wirklich kurzlebig zu gestalten um die Auswirkung im Fall eines Leaks gering zu halten. Für Nutzer von Service-Meshes wird das nichts neues sein. Es geht aber auch für Zugriffstokens, Datenbankkennwörter und einiges mehr.
Modernes Secrets Management kann dazu führen, dass Konfigurationsdateien nicht mehr benötigt werden. Hier herrscht anstelle des Push-Prinzips (von Dateien) das Pull-Prinzip: Erst wenn ein Secret benötigt wird, wird es von einer vertrauenswürdigen Komponente angefragt, ggf. auch erst dann erstellt und kurzlebig verwendet. Wie funktioniert das nun genau? Im folgenden ein kurzer Überblick über die beiden Cloudprovider Amazon Web Services und Microsoft Azure - und welche Möglichkeiten sich für On-Premise Installation ergeben.
Bei Cloudprovidern gibt es gute Ansätze für Secret Management natürlich “as-a-Service”. Das bedeutet, dass die Erzeugung, Speicherung, Abfrage und teilweise auch die Verwendung von Schlüsseln an einen Service auslagert wird. Dank des integrierten Rollen- und Rechtekonzepts wird über Richtlinien gesteuert, welche Instanzen, Services oder Benutzer sich an diese Services wenden dürfen. Wie sieht das konkret aus?
Bei Microsoft Azure sind hier die beiden Services Azure Key Vault und Azure App Configuration zu nennen. Mit dem Key Vault lassen sich kryptografische Schlüssel, X.509-Zertifikate und (allgemein) Secrets verwalten. Praktisch funktioniert es z. B. für Secrets so, dass eine Provisionierungskomponente ein Secret, wie ein Datenbankpasswort erzeugt und in einem “Key Vault” unter einem Namen ablegt. Die Applikation, die das Kennwort benötigt, kennt nur den Namen des Vault und des Secrets und benötigt die Berechtigung, das Secret abzufragen. Bei Programmstart fragt die Aplikation das Secret ab, verwendet es, speichert es aber nie ab. Es bleibt damit nur im Hauptspeicher und vor Diebstahl zumindest in der einfachen Variante geschützt.
Der Key Vault Service ist dafür verantwortlich, das Secret sicher abzuspeichern - z. B. verschlüsselt mit einem Master-Kennwort und geschützt durch ein Hardware Security Module (HSM). Letzteres ist auch eine häufige (gute) Antwort auf Fragen in einer Sicherheitszertifizierung. Über den Key Vault erfolgt ganz praktisch eine FIPS 140-2 Level 2 konforme Speicherung von Schlüsselmaterial. Bei FIPS-140 Level 2 lassen sich Einbrüche oder Manipulationsversuche an HSMs nachweisen.
Ein anderer nützlicher Dienst ist die Azure App Configuration. Im Prinzip ist das die Konfigurationsdatei auf Cloud-Art. Anstatt Key/Value-Paare in Konfigurationsdateien zu legen, werden sie nun in einem Service verwaltet. App Configuration lässt sich mit Key Vault kombinieren, sodass die Applikationskonfiguration sicher abgelegt werden kann.
Rotation von Passwörtern ist ebenfalls über die Nutzung des Azure Event Grid möglich. Wenn ein Secret sich seiner definierten Lebenszeit nähert, wird eine Function aktiv, die z. B. in einer Datenbank das Passwort ändert, und eine neue Version des Secrets erzeugt.
Bei Amazon Web Services sind sehr ähnliche Dienste verfügbar. Der Key Management Service, kurz KMS ist für die sichere Verwaltung von Schlüsselmaterial (symmetrische und asymmetrische Schlüssel) zuständig. Nachdem ein Schlüssel erzeugt wurde, kann eine Applikation ihn abfragen oder mit ihm direkt innerhalb KMS Verschlüsselungen und Entschlüsselungen durchführen - wenn auch nur für kleine Datenmengen. Die Verwendung von Schlüsselmaterial lässt sich auditieren.
Der AWS Parameter Store kann eine komplette Anwendungskonfiguration verwalten - praktisch das Pendant zur Konfigurationsdatei. Hierbei lassen sich auch Secrets verwalten, die dann mit Hilfe des KMS sicher abgelegt werden. Richtig interessant wird es bim AWS Secrets Manager. Hier werden Secrets ähnlich wie im Parameter Store nicht nur sicher abgelegt und abfragbar gemacht, sondern in Zusammenhang mit anderen AWS-Diensten wie Datenbanken auch automatisch und transparent rotiert.
Bei OnPremise IT-Infrastruktur, die unter der eigenen Verwaltung steht, hat man diese Möglichkeiten erst einmal nicht - keine Cloud, keine Mehrwerte durch Services in dieser Richtung. Es gibt allerdings Abhilfe in Form von Anwendungen, die im Prinzip genau dieselben Funktionen erfüllen. Neben der kompletten Eigenentwicklung kann auf Dritthersteller zurückgegriffen werden - auch aus dem Open Source-Bereich.
Eines dieser Werkzeuge ist Vault von HashiCorp. Vault unterstützt verschiedene Anwendungsfälle, darunter Secrets Management ähnlich wie bei den Cloud-Diensten, aber auch Encryption-as-a-Service und Identitätsmanagement. Es eignet sich - nicht nur, aber vor allem - für Low- und Zero-Trust Networks, d. h. Netzwerke mit geteilter IT-Infrastruktur, wo klassische Perimetersicherheit nicht mehr gegeben ist.
Vault läuft als Anwendung auf Servern mit Linux, Windows, Mac, BSDs oder Solaris. Typischerweise wird ein Vault-Cluster aus 3 oder 5 Instanzen betrieben, um Ausfallsicherheit zu haben. Alle Daten, die bei Vault gespeichert werden, landen verschlüsselt auf einem modularen Storage - im einfachsten Fall ein Filesystem (seit Version 1.4 auch ausfallsicher durch die Vault-interne Clusterreplikation auf Basis Raft), es ist aber auch möglich, in Datenbanken (MySQL, PostgreSQL, MSSQL, …), Etcd, AWS S3 oder Azure Storage zu speichern. Vault kann in diesem Zusammenhang auch mit HashiCorp's Consul als Storage-Backend laufen.
Im Kern ist Vault ein hochverschlüsselter, verteilter Key/Value-Store, mit dem Konfigurationsdaten sicher abgelegt und über Policies zugreifbar gemacht werden. Interessant wird Vault aber durch verschiedene Abstraktionsschichten (genannt Engines), die den reinen Key/Value-Zugriff auf Anwendungsfälle abbilden. So lässt sich Vault z. B. als CA für die Ausgabe von X.509-Zertifikaten einsetzen, für die Verwaltung von SSH-Schlüsseln, für das automatische Erstellen von Datenbank-Usern in Datenbanken wie PostgreSQL, MongoDB, ElasticSearch und anderen, für die Verwaltung von Zugriffsschlüsseln in Clouds und mehr.
Als zusätzliches Merkmal lässt sich anführen, dass Vault Encryption-as-a-service unterstützt. Das bedeutet symmetrische und asymmetrische Schlüssel werden nicht nur gespeichert, sondern auch kryptografische Operationen wie Ver-/Entschlüsseln, Signieren und Verifizieren sind durchführbar. Damit kann Krypto-Code aus der eigenen Applikation herauswandern und durch Vault realisiert werden.
Ein moderner Umgang mit Secrets und sensitiven Applikationsdaten ist auch ohne Konfigurationsdateien möglich, sowohl mit Services aus der Cloud- als auch in OnPremise-Umgebungen. Dieser Post diente dazu, einen ersten Einblick in die prinzipiellen Möglichkeiten zu geben. Wir wollen in Folgeposts erkunden, wie das genauer funktioniert.
Wir freuen uns über Ihre Nachricht und melden uns schnellstmöglich bei Ihnen.