© Enkel/Shutterstock.com
Sichere Speicherung sensibler Properties in der Konfiguration

Konfiguration schützen


Nicht nur die Twelve-Factor-App empfiehlt die Trennung von Code und Konfiguration. Bereits die Minimallösung – Properties außerhalb des generierten Artefakts – exponiert kritische Zugangsdaten noch einfacher als die im Classpath verborgene Variante. Die nächste Ausbaustufe, ein zentraler Konfigurationsserver, erhöht die Angriffsfläche nochmals, ermöglicht dieser doch den Zugriff auf alle Konfigurationsdateien aller dort angesiedelter Anwendungen. Höchste Zeit also, auch sensible Daten in Konfigurationsdateien richtig zu schützen.

In den letzten Jahren hat sich der Trend zu möglichst sicher entwickelten Webanwendungen weiter verstärkt. Sicherheit rückt immer stärker in den Fokus. Zwangsläufig betrifft dies neben dem Entwicklungsprozess, dem eigentlichen Code und vielem anderen mehr auch die Konfiguration der Webanwendungen. Klartextpasswörter zu weiteren Systemen, etwa Datenbanken, LDAP-Verzeichnisse oder Web Services, können und sollen darin nicht mehr länger toleriert werden. Durch verteilte Systeme, speziell in der maximalen Ausprägung Micro- oder Nanoservices, wurde dieses Sicherheitsproblem weiter verschärft und gleichzeitig dessen Lösung erschwert. Wo früher zwei bis drei Passwörter auf einem einzigen Server in einer einzigen Konfigurationsdatei im Klartext hinterlegt waren (und das war schon schlimm genug), sind es jetzt zigfach mehr Zugangsdaten zu zigfach mehr Systemen auf zigfach mehr Servern. Mit der üblichen Herangehensweise müssten alle Anwendungen selbst für die Sicherheit ihrer Passwörter sorgen, was schon bei wenigen Webanwendungen leicht zu einem entwicklungstechnischen und administrativen Albtraum werden kann. Zeit für bessere Lösungen, von denen zwei in diesem Artikel vorgestellt werden sollen. Die hierfür genutzte Webanwendung ist auf GitHub samt Dokumentation verfügbar [1].

Spring Cloud Config

Mit Spring Cloud Config [2] und dem Spring-Cloud-Config-Server steht für Spring-Anwendungen eine zentrale Stelle zum Ablegen und Verteilen der Konfiguration zur Verfügung. Config-Server-Funktionalität wird bereits in zahlreichen Webanwendungen genutzt. Eine Spring-Webanwendung besitzt dabei kaum mehr eigene Konfiguration, sondern lediglich einen Verweis per bootstrap.yml auf den zu verwendenden Config-Server.

spring: cloud: config: uri: [Config-Server-Host] application: name: config-client

Ob nun Properties- oder YAML-Dateien, Passwörter sind damit zunächst aus dieser Webanwendung vollständig entfernt. Dafür fristen sie jetzt ihr Dasein im zentralen Config-Server. Üblicherweise liegen die Konfigurationsdateien dabei in einem Git Repository und können von einer Versionierung profitieren. Passend zu obiger Webanwendung mit dem Namen config-client befindet sich im konfigurierten Repository daher eine Datei mit dem Namen config-client.yml (optional für weitere Spring-Profile in der Form config-client-{profile}.yml).

spring: datasource: name: client-db username: client-user password: client-password h2: console: enabled: true logging: level: warn

Benutzername und Passwort, in diesem Fall zu einer H2-Datenbank, liegen damit weiterhin im Klartext vor. Da ein Config-Server üblicherweise von mehreren Spring-Webanwendungen genutzt wird, existieren in der Regel zahlreiche Konfigurationsdateien mit allen Zugangsdaten zu den unterschiedlichsten Systemen an einem zentralen Ort, zugänglich für alle mit Kenntnis des Config-Server-URLs und dem jeweiligen Anwendungsnamen. Per GET Request an einen standardisierten URL, etwa https://[Config-Server-Host]/config-client/default, liefert der Config-Server die Konfiguration als JSON an die aufrufende Webanwendung aus, aber eben auch an einen Angreifer.

Zentrale Konfiguration für alle

Eine zentrale Konfiguration ist für Angreifer naturgemäß sehr viel verlockender, lassen sich hier doch nicht nur ein einziges Passwort, sondern meist gleich mehrere abgreifen. Zwei Anpassungen sind daher unmittelbar notwendig. Einerseits die Verschlüsselung der Passwörter in den Konfigurationsdateien, sodass ein einfaches Auslesen nicht mehr möglich ist. Andererseits die Absicherung des Config-Servers selbst, sodass nur noch berechtigte Anwendungen darauf zugreifen können.

Für die erste Anforderung verfügt der Config-Server über die Möglichkeit, Passwörter mittels symmetrischer oder asymmetrischer Verschlüsselung verschlüsselt zu speichern – unabhängig davon, ob die Konfiguration in einem Git oder SVN Repo oder im Dateisystem abgelegt wird. Dazu ist in der bootstrap.yml des Config-Servers etwas Konfigurationsarbeit notwendig. Im Fall einer symmetrischen Verschlüsselung genügt dazu eine einzige Angabe:

encrypt: key: This1sABigSecret

Mit diesem Key lassen sich die sensiblen Daten in der Konfiguration verschlüsseln. Zur Entschlüsselung wird entsprechend der symmetrischen Kryptografie dasselbe Passwort verwendet. Bei der asymmetrischen Verschlüsselung muss dagegen ein Java Keystore (oder alternativ eine PEM-Datei) samt der weiteren Daten Keystore-Passwort, Key-Alias und Key-Passwort konfiguriert werden:

encrypt: key-store: location: classpath:server.jks password: secret alias: configserver secret: secret

Der Keystore muss dem Config-Server zur Verfügung gestellt werden. Hier lässt sich entweder ein Pfad im Dateisystem angeben oder aber der Classpath verwenden. Für beide Varianten, symmetrisch und asymmetrisch, müssen bei älteren Java-Versionen zusätzlich die Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files installiert werden. Seit Java 1.8 Update 161 gehören diese endlich ohne weitere Installation und Konfiguration zum Standard.

Unabhängig von symmetrischer oder asymmetrischer Variante steht damit a...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang