Zugangsdaten externer Systeme sicher speichern

[OnDemand]

Hallo zusammen,

ich beschäftige mich aktuell damit wie man Zugangsdaten für externe Systeme speichern könnte, ohne sie im Code zu haben. Derzeit hab ich die als .properties file mit Jasypt verschlüsselt, suche noch andere Möglichkeiten, die vielleicht weniger umfangreich sind (entwickeln bald zu zweit, da will ich so viel Komplexität wie nötig rausnehmen). Jasypt macht auch irgendwie keine Fortschritte in der Entwicklung

Zur Info, es geht hier nicht um Logindaten von Usern für das Programm, sondern um Zugangsdaten zur Authentifizierung an fremden Systemen, API, Mail Server usw.

Spontan fällt mir ein:
Properties file auslagern und irgendwo im Dateisystem speichern:
api.user=hans
api.password=123454

Diese könnte man ja bequem einlesen, aber da sind die Zugangsdaten ja im Klartext auf dem Server. Wenn jemand mit root Rechten da drauf kommt, kann er das ja auch einsehen.

Selbiges gilt für Umgebungsvariablen.

Diese beiden Varianten werden immer mal wieder irgendwo in Foren als "Best practise" genannt. Was macht diese Vorgehensweise sicher? Das Setzen von Dateirechten, sodass nur bestimmte Systemuser die Datei lesen dürfen (mit dem auch die Software ausgeführt wird)?

Freue mich auf euren Input!

 

[Ullenboom]

Wenn du mit Kanonen schießen möchtest, dann https://www.vaultproject.io/.
Das passt zusammen mit https://spring.io/projects/spring-vault.

 

[Oneixee5]

Es kommt darauf an in welcher Umgebung du unterwegs bist. Für Container gibt es z.B. Docker Secrets, gleiches Prinzip gibt es auch in Kubernetes Umgebungen.

 

[Robert Zenz]

Diese könnte man ja bequem einlesen, aber da sind die Zugangsdaten ja im Klartext auf dem Server. Wenn jemand mit root Rechten da drauf kommt, kann er das ja auch einsehen.

Das kann der Angreifer so oder so, weil wenn der Angreifer root-Rechte hat, oder auch nur die Rechte deiner Applikation, kann dieser ja die Geheimnisse alle lesen weil die Applikation das ja auch kann. Du kannst es in dem Fall erschweren, aber komplett verhindern kannst du das nicht weil es ja dein Anwendungsszenario ist dass diese Geheimnisse gelesen werden koennen von diesem Benutzer/Programm.

Du kannst es natuerlich erschweren, und du kannst verhindern dass ein Angreifer an Zugangsdaten kommt welche auf diesem System nicht verfuegbar sein sollten.

 

[LimDul]

Das Problem ist, diese Daten müssen für die Anwendung im Klartext verfügbar sein. Dementsprechend ist eine 100% Sicherheit nicht möglich. Und wie Robert schrieb, sobald der Root Zugriff da ist, sind diese Daten als kompromittiert anzusehen. Im Endeffekt gibt es aus meiner Sicht folgende Varianten:

• Die Zugangsdaten liegen im Klartext vor - möglichst so, dass der Zugriff weites gehend eingeschränkt ist (Also z.B. Umgebungsvariablen).
• Die Zugangsdaten liegen verschlüsselt vor - nur dass Passwort zum entschlüsseln liegt im Klartext vor

Variante 2 hat den Vorteil, dass das Passwort zum entschlüsseln weniger sensibel ist, als die eigentlichen Zugangsdaten.

 

[Robert Zenz]

Variante 2 hat den Vorteil, dass das Passwort zum entschlüsseln weniger sensibel ist, als die eigentlichen Zugangsdaten.

Das ist fuer den Angreifer aber nur ein Zwischenschritt mehr.

 

[LimDul]

Das ist fuer den Angreifer aber nur ein Zwischenschritt mehr.

Ja und nein.

Also, wenn er entsprechenden Zugriff hat - dann es es nur ein Zwischenschritt mehr. Aber wenn die Daten in einem Vault liegen und dem Angreifer fallen - z.B. aus einem ungesicherten Backup - nur die Schlüssel in die Finger, kann er damit ohne Zugriff auf den Vault nichts anfangen.

Risiko an der Sache ist natürlich - wenn einem Angreifer der entschlüsselte Vault in die Hände fällt (weil da Sicherheitslücke etc.) - dann hat er gleich alles auf einmal und zwar für sämtliche Systeme.

 

[Oneixee5]

Das Speichern der Zugangsdaten ist nur ein Teil eines Sicherheitskonzeptes. Wenn man z.B. einen Mailserver von der Anwendung X verwenden will, dann würde ich den Mailserver selbst so konfigurieren, dass die speziellen Zugangsdaten der Anwendung X nur von diesem einem System (Host des Systems X) aus verwendet werden können. So können selbst gestohlene Zugangsdaten nur sehr schwer weiterverwendet werden.
Weiterhin würde man Intrusion Detection Systeme (IDS) einsetzen. Möglicherweise können die nicht verhindern, dass ein Host feindlich übernommen wird aber das kompromittierte System würde isoliert und von den gekoppelten Firewalls blockiert werden. Es können dann keine Daten abfließen. Lokale Manipulationen können über Backups oder andere Integritätsmechanismen erkannt oder verhindert werden.
Es ist also nicht so entscheidend, ob jedes einzelne Passwort wirklich perfekt geschützt ist. Passworte sind sowieso ein eigentlich überholtes Konzept. Ein Gesamtkonzept muss sicherstellen, dass Schaden begrenzt oder komplett vermieden wird. Es muss für jeden klar und transparent sein, was in einem Verdachts- oder Schadensfall zu tun ist - und das bevor so ein Ereignis eintritt. Im Idealfall sollten alle Systeme automatisch reagieren, da Menschen unter Stress Fehler machen.

 

[LimDul]

Ansonsten kann man sich auch mal mit dem Thema Zero-Trust Architektur beschäftigen. Wo es darum geht, dass eigentlich kein System einem anderen vertraut und grundsätzliche jede Kommunikation erstmal als potentiell gefährdet anzusehen ist. Und man nur in soweit Rechte & Zugriffe vergibt, wie unbedingt notwendig. Damit minimiert man in Schadensfall die Auswirkungen.