Forum: PC Hard- und Software Wie Credentialstore aufbauen


von Credhannes (Gast)


Lesenswert?

Moin,

ich betreibe eine Webapplikation in denen Workflows an Drittsystemen 
automatisiert werden können.
Beispiel: Installiere Update auf Linux-Server
Der Prozess an sich ist fix aber die Credentials und der Ziel-Server 
ändern sich und wiederholen sich im zeitlichen Abstand.

Diese Website ist aktuell nur über 2FA Login aufrufbar. Ich selber bin 
Entwickler und würde in dieser Applikation gerne einen Credentialstore 
einbauen, damit ich nicht jedes Mal für wiederkehrende Aufgaben die 
Credentials fürs z.B. Automationsscript hinterlegen muss.
Aber auch um z.B. Credentials zu Servern global zu speichern und mit 
meinem Team zu teilen.

Wie macht man dies sicher und vor allen Dingen von der Architektur am 
sinnvollsten?

Theoretisch besteht ja die Möglichkeit eine Sicherheitslücke in der 
Applikation zu finden und irgendwie ins System einzubrechen. Mein erster 
Ansatz wäre also die Credentials verschlüsselt zu speichern, kennt die 
Applikation allerdings den Schlüssel und jemand findet eine Lücke in der 
Applikation ist die Verschlüsselung vermutlich nutzlos.
Wenn der einloggte User den Schlüssel übergibt kann vermutlich die 
gefundene Sicherheitslücke einfach bei der Übergabe des Passworts 
mitlesen und hat spätestens dann die Login-Daten geknackt.

Irgendeinen tot wird man sterben müssen, aber welchen sollte man 
sterben?
Wo speichert ihr Credentials für Systeme, die ihr im Team teilt und die 
Scripte zu Automationszwecken nutzen sollen?

VG und Danke für eure Anregungen

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Naja, 100% security wirst Du never hinkriegen. Wenn irgendwer Deine epic 
App so h4xx0rt, daß er den source code modden kann, dann kann er auch 
alles mitlesen, was your users eingeben. Der kann danach mit der Seite 
quasi alles machen, was Du auch machen kannst (inside job), folglich ist 
Schutz ab dem Punkt difficult.

Ansonsten no idea wie Deine Infrastruktur aufgebaut ist und an welchen 
Interfaces Du really auf andere Server musst. Und ob Du zwischen den 
Servern auch 2FA brauchst - macht meiner Meinung nach wenig Sinn weils 
egal ist ob sich ein Server einmal oder x-mal authen muß. Das Problem 
ist immer das gleiche, bricht man es einmal, bricht man es x-mal.

Wenn ich Seiten mit automated Scripten wie z.B. Cronjobs schreibe, dann 
brauchen die keinen Login und verwerten keine parameters von außen. 
Means jeder kann die starten wenn er den entsprechenden Aufruf kennt, 
den Rest macht das Script alleine, also auch den Check ob es tatsächlich 
executen soll or not. Wenn man das so weit protecten will, daß keine 
credentials zu irgendwelchen big fat databases im sourcecode stehen, 
könnte man die aus einem file loaden, das nicht aus dem big bad internet 
erreichbar ist.

von vmodellxp (Gast)


Lesenswert?

Schau dir doch an, wie es etablierte Projekte in dem Bereich machen: 
Puppet (Bolt), Chef, Ansible, usw. müssen ja alle das selbe Problem 
lösen.

von Sheeva P. (sheevaplug)


Lesenswert?

Credhannes schrieb:
> Der Prozess an sich ist fix aber die Credentials und der Ziel-Server
> ändern sich und wiederholen sich im zeitlichen Abstand.
> [...]
> Wo speichert ihr Credentials für Systeme, die ihr im Team teilt und die
> Scripte zu Automationszwecken nutzen sollen?

In meinem Team gibt es ein Git-Repo mit Dateien, welche mit GnuPG für 
mehrere Empfänger verschlüsselt sind. Das bietet zumindest einen recht 
guten Schutz, zumal wir angehalten sind, private Schlüssel für SSH und 
GnuPG mit Paßworten zu schützen.

Trotzdem gefällt mir die Sache schon seit Jahren nicht mehr so richtig, 
und ich denke schon länger darüber nach, ein sicheres Webinterface dafür 
zu entwickeln. Vielleicht wird's ja was, mal schauen -- im Moment sammle 
ich noch Ideen...

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.