it-swarm.com.de

Wie vermeide ich Skripte mit fest codiertem Passwort?

Ich habe einige Skripte auf einem Ubuntu Linux-Computer, die sich bei einem Datenbankserver anmelden, um täglich Wartungsarbeiten durchzuführen. Um mich bei der Datenbank anzumelden, benötige ich ein Passwort, das derzeit im Skript fest codiert ist.

Was sind bessere Möglichkeiten, um dieses Skript auszuführen, ohne das Kennwort fest zu codieren/offenzulegen?

21
KennyC

Sie können öffentliche/private Schlüsselpaare erstellen und das Kennwort verschlüsseln. Dies sollte das Passwort von zufälligen Passanten verschleiern, da ihnen nur der öffentliche Teil des Schlüssels bekannt wäre.

Sie sollten das Skript auch mit Verzeichnis- und Dateiberechtigungen schützen.

Darüber hinaus sollten Sie (abhängig von der Datenbank) in der Lage sein, ein Benutzerkonto für die Datenbank zu erstellen, das nur über Sicherungsrechte verfügt. Dies würde jemanden daran hindern, Tabellen zu erstellen, Tabellen zu sichern und Inhalte zu ersetzen. Sie können den Zugriff auf diesen Benutzer auf die Zeiten beschränken, zu denen die Sicherungen ausgeführt werden sollen.

Update

Dieser Beitrag auf Comodo erklärt die Tasten tatsächlich etwas besser . Da Sie befürchten, dass jemand Zugriff auf das ursprüngliche Kennwort erhält, das im Code vorhanden ist, muss der Angreifer auf den privaten Schlüssel des Benutzers warten, der das Skript auslöst (was über SSH auf einem Cron auf einem separaten [virtuellen] Computer geschehen kann). Maschine). Offensichtlich wäre es sinnlos, wenn Sie beide Schlüssel auf demselben System speichern würden, es sei denn, Sie speichern natürlich den privaten Schlüssel mit höheren Berechtigungen als den öffentlichen Schlüssel.

Beide Schlüssel zusammen = Passwort

Was die Berechtigungen betrifft, wenn jemand Zugriff auf Ihr System hat und es so wichtig ist, dass ein Kennwort in einem "lesbaren Format" auf der Box gespeichert wird, scheint es tiefere Probleme mit der Konfiguration der Berechtigungen für die Box selbst zu geben. Wenn jemand Sudo kann und Ihre eigenen Berechtigungen übertrifft (wie der Host, auf dem die Box ausgeführt wird), ist das Schlüssel-Hashing die einzige Option, um zu verhindern, dass der Administrator in die Datenbank gelangt.

Außerdem müssten Sie das Konto root in der Datenbank deaktivieren, da der Angreifer dadurch die Datenbanktabellen trotzdem lesen kann.

12
AbsoluteƵERØ

Wie in anderen Antworten erwähnt, sind Ihre Anmeldeinformationen für Ihr Skript zugänglich.

Aber ich würde sagen, dass es sich um eine separate Konfigurationsdatei handelt, die von Ihrem Skript gelesen wird.

Sie haben folgende Vorteile:

  • sie können dasselbe Skript für mehrere Systeme verwenden (mit unterschiedlichen Konfigurationsdateien).
  • sie können das Skript mit anderen teilen (oder es jemandem zeigen, ohne Ihre Anmeldeinformationen zu gefährden).
14
Matteo

Angesichts der Automatisierung des Skripts gibt es meines Erachtens keine bessere Möglichkeit, das Kennwort zu speichern, als es fest zu codieren.

Meine Empfehlung wäre, das Skript mit den richtigen Unix-Dateisystemberechtigungen zu sperren. Erstellen des Skripts -rwx------ und das Setzen des Besitzers und der Gruppe auf die entsprechenden Werte tragen wesentlich zur Sicherung des Passworts bei.

Verfügen Sie natürlich über geeignete Protokollierungsmaßnahmen, um festzustellen, ob das Skript kompromittiert wurde. Wenn dies der Fall ist, ändern Sie das Kennwort auf dem Datenbankserver sofort.

4
user10211

Ich mag die Antwort von @ absolute zum Verschlüsseln der Creds mit einem Schlüsselpaar. Ich werde auch hinzufügen, dass ich für Windows-basierte Lösungen manchmal nur C # anstelle eines Powershell-Skripts verwendet habe. Da beide auf .NET basieren, kann ich einfach meine Lösung kompilieren und die Creds hineinwerfen.

Vielleicht können Sie eine kompilierte ausführbare Datei erstellen, die das Skript aufruft und die Anmeldeinformationen als Parameter übergibt, oder sogar eine verschlüsselte Kopie der Anmeldeinformationen als Parameter, den Ihr Skript entschlüsseln kann.

Ja , mir ist bewusst das Die Creds können unter bestimmten Umständen immer noch von der Exe gepflückt werden. Dies gilt jedoch speziell für die OP-Situation, Klartext-Creds zu vermeiden.

3
MDMoore313

Vielleicht stellen Sie die falsche Frage. Es ist zwar richtig, sich über Skripte mit fest codierten Authentifizierungsdaten Gedanken zu machen, aber die eigentliche Frage ist, wie die von automatisierten Skripten verwendeten Authentifizierungsdaten verwaltet werden und was noch wichtiger ist, welche Bedrohungen oder Risiken mit dem System am höchsten sind. Unterschiedliche Systeme haben unterschiedliche Risiken. Sie müssen die für Ihre Situation relevantesten Risiken verstehen, um beurteilen zu können, welche Maßnahmen am besten geeignet sind. Allgemein

  • Keine fest codierten Authentifizierungsdaten. Legen Sie sie in einer separaten Datei/einem separaten Speicherort ab und lassen Sie Ihr Skript die Informationen verwenden. Dies hat den Vorteil, dass das Ändern Ihrer Kennwörter einfacher wird, da Sie Ihre Quellen nicht bearbeiten müssen und mehrere Skripte dieselbe Quelle verwenden können, sodass Sie Kennwörter an nur einer Stelle ändern können.

  • Lernen Sie Berechtigungen, Verwendungen und Gruppen kennen. Nutzen Sie die verfügbaren Einrichtungen, um den Zugriff einzuschränken.

  • Verwenden Sie die zusätzlichen Härtungsfunktionen Ihres Betriebssystems. Zum Beispiel verwendet Linux SELinux oder AppArmor (ich denke, Ubuntu basiert auf Apparmor). Definieren Sie geeignete Richtlinien, um den Zugriff nur auf das zu beschränken, was unbedingt erforderlich ist.

  • Verstehen und verwenden Sie die verfügbaren Tools - ssh, Sudo, chroot usw.

Wenn Sie wissen und verstehen, wo sich Ihre Bedrohungen befinden, bestimmen Sie, welche Techniken und Einrichtungen am besten geeignet sind und ob die Standardeinrichtungen ausreichen oder ob Sie die Dinge noch weiter verbessern und zusätzliche Vorsichtsmaßnahmen treffen müssen. Übersehen Sie nicht die Bedeutung der Überwachung und Protokollanalyse. Es ist eine Sache, Schutz zu schaffen. Es ist eine andere Sache zu wissen, wann Ihr Schutz versagt hat und Sie kompromittiert wurden. Es mag schlecht sein, Ihr System kompromittiert zu haben, aber es ist weitaus schlimmer, wenn es kompromittiert wird und es nicht weiß.

2
Tim X

Wenn Sie sich mit ssh beim Datenbankserver anmelden, können Sie die ~/.ssh/autorisierten_Tasten auf dem Datenbankserver so einrichten, dass sie die Dateien ~/.ssh/id_dsa.pub oder ~/.ssh/id_rsa.pub enthalten auf Ihrem Ubuntu-System. Sie können sich ohne Passwort anmelden.

Wenn Sie keine Datei in ~/.ssh/id_dsa.pub haben, schauen Sie nach, wie Sie eine mit ssh-keygen erstellen

1
Alan