© 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 zen...

Exklusives Abo-Special

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang