Wie kann ich ein Passwort in Shell-Skripten verbergen? Es gibt eine Reihe von Skripten, die auf die Datenbank zugreifen. Wenn wir das Skript öffnen, wissen andere auch den Benutzernamen und das Passwort. Wenn also jemand weiß, wie man sich versteckt, lass es mich bitte wissen.
Ich habe eine Möglichkeit:Platzieren Sie das Passwort in einer Datei und machen Sie die Datei versteckt und niemand wird auf die Datei zugreifen (ändern Sie die Berechtigungen und verwenden Sie die Datei im Skript, während Sie auf die Datenbank zugreifen).
Akzeptierte Antwort:
Zuerst , wie mehrere Leute bereits gesagt haben, ist es wichtig, die Anmeldeinformationen vom Skript getrennt zu halten. (Neben erhöhter Sicherheit bedeutet dies auch, dass Sie dasselbe Skript für mehrere Systeme mit unterschiedlichen Anmeldeinformationen wiederverwenden können.)
Zweiter , sollten Sie nicht nur die Sicherheit der Anmeldeinformationen berücksichtigen, sondern auch die Auswirkungen, falls/wenn diese Anmeldeinformationen kompromittiert werden. Sie sollten nicht nur ein Passwort für den gesamten Zugriff auf die Datenbank haben, Sie sollten unterschiedliche Anmeldeinformationen mit unterschiedlichen Zugriffsebenen haben. Sie könnten beispielsweise einen DB-Benutzer haben, der die Möglichkeit hat, eine Suche in der Datenbank durchzuführen – dieser Benutzer sollte nur Lesezugriff haben. Ein anderer Benutzer hat möglicherweise die Berechtigung, neue Datensätze einzufügen, aber nicht, sie zu löschen. Ein dritter kann die Erlaubnis haben, Datensätze zu löschen.
Zusätzlich zur Einschränkung der Berechtigungen für jedes Konto sollten Sie auch einschränken, wo jedes Konto verwendet werden kann. Beispielsweise sollte es dem von Ihrem Webserver verwendeten Konto nicht erlaubt sein, sich von einer anderen IP-Adresse als der des Webservers zu verbinden. Ein Konto mit vollen Root-Berechtigungen für die Datenbank sollte in der Tat sehr eingeschränkt sein in Bezug darauf, von wo aus es eine Verbindung herstellen kann, und sollte niemals anders als interaktiv verwendet werden. Ziehen Sie auch in Betracht, gespeicherte Prozeduren in der Datenbank zu verwenden, um genau einzuschränken, was von jedem Konto getan werden kann.
Diese Einschränkungen müssen auf der DB-Server-Seite des Systems implementiert werden, sodass die Einschränkungen selbst dann nicht geändert werden können, wenn die Client-Seite kompromittiert wird. (Und natürlich muss der DB-Server zusätzlich zur DB-Konfiguration mit Firewalls usw. geschützt werden…)
Bei einem DB-Konto, dem nur eingeschränkter Lesezugriff und nur von einer bestimmten IP-Adresse aus gestattet ist, benötigen Sie möglicherweise keine weiteren Anmeldeinformationen, je nach Sensibilität der Daten und der Sicherheit des Hosts des Skripts davon wird geflohen. Ein Beispiel kann ein Suchformular auf Ihrer Website sein, das mit einem Benutzer ausgeführt werden kann, der nur eine gespeicherte Prozedur verwenden darf, die nur die Informationen extrahiert, die auf der Webseite präsentiert werden. In diesem Fall bietet das Hinzufügen eines Passworts keine zusätzliche Sicherheit, da diese Informationen bereits öffentlich sein sollen und der Benutzer nicht auf andere sensiblere Daten zugreifen kann.
Stellen Sie außerdem sicher, dass die Verbindung zur Datenbank über TLS hergestellt wird, da sonst jeder, der das Netzwerk überwacht, Ihre Anmeldeinformationen abrufen kann.
Dritter , überlegen Sie, welche Art von Anmeldeinformationen verwendet werden sollen. Passwörter sind nur eine Form und nicht die sicherste. Sie könnten stattdessen eine Art öffentliches/privates Schlüsselpaar oder AD/PAM oder ähnliches verwenden.
Vierter , berücksichtigen Sie die Bedingungen, unter denen das Skript ausgeführt wird:
Verwandte:Quellcode von netstat?Wenn es interaktiv ausgeführt wird, dann sollten Sie beim Ausführen das Passwort bzw. das Passwort zum privaten Schlüssel oder den privaten Schlüssel eingeben oder mit einem gültigen Kerberos-Ticket angemeldet sein – mit anderen Worten, das Skript sollte es bekommen Zugangsdaten direkt von Ihnen zum Zeitpunkt der Ausführung, anstatt sie aus einer Datei zu lesen.
Wenn es von einem Webserver ausgeführt wird, sollten Sie die Anmeldeinformationen zum Zeitpunkt des Starts des Webservers einrichten. Ein gutes Beispiel sind hier SSL-Zertifikate – sie haben ein öffentliches Zertifikat und einen privaten Schlüssel, und der private Schlüssel hat ein Passwort. Sie können den privaten Schlüssel auf dem Webserver speichern, aber Sie müssen trotzdem das Passwort eingeben, wenn Sie Apache starten. Sie könnten die Anmeldeinformationen auch auf einer Art Hardware haben, z. B. einer physischen Karte oder einem HSM, die entfernt oder gesperrt werden können, sobald der Server gestartet ist. (Der Nachteil dieser Methode ist natürlich, dass der Server nicht von alleine neu starten kann, wenn etwas passiert. Ich würde dies dem Risiko vorziehen, dass mein System kompromittiert wird, aber Ihre Laufleistung kann variieren …)
Wenn das Skript von Cron ausgeführt wird, ist dies der schwierige Teil. Sie möchten nicht, dass die Anmeldeinformationen irgendwo auf Ihrem System herumliegen, wo jemand darauf zugreifen kann – aber Sie möchten sie herumliegen haben, damit Ihr Skript darauf zugreifen kann, richtig? Naja, nicht ganz richtig. Überlegen Sie genau, was das Skript tut. Welche Berechtigungen benötigt es für die Datenbank? Kann es eingeschränkt werden, sodass es keine Rolle spielt, ob sich die falsche Person mit diesen Berechtigungen verbindet? Können Sie das Skript stattdessen direkt auf dem DB-Server ausführen, auf den sonst niemand Zugriff hat, anstatt auf dem Server, der andere Benutzer hat? Wenn Sie aus irgendeinem Grund, den ich mir nicht vorstellen kann, unbedingt müssen Lassen Sie das Skript auf einem unsicheren Server laufen und es muss in der Lage sein, etwas Gefährliches/Destruktives zu tun … jetzt ist ein guter Zeitpunkt, um Ihre Architektur zu überdenken.
Fünfter , wenn Sie Wert auf die Sicherheit Ihrer Datenbank legen, sollten Sie diese Skripte nicht auf Servern ausführen, auf die andere Personen Zugriff haben. Wenn jemand auf Ihrem System angemeldet ist, dann wird haben Sie die Möglichkeit, an Ihre Anmeldeinformationen zu kommen. Beispielsweise besteht bei einem Webserver mit SSL-Zertifikat zumindest die theoretische Möglichkeit, dass jemand root werden und auf den Speicherbereich des httpd-Prozesses zugreifen und die Anmeldeinformationen extrahieren kann. In letzter Zeit gab es mindestens einen Exploit, bei dem dies über SSL erfolgen konnte, ohne dass der Angreifer angemeldet sein musste.
Erwägen Sie auch die Verwendung von SELinux oder AppArmor oder was auch immer für Ihr System verfügbar ist, um einzuschränken, welche Benutzer was tun können. Sie ermöglichen es Ihnen, Benutzern nicht einmal den Versuch zu gestatten, sich mit der Datenbank zu verbinden, selbst wenn sie Zugriff auf die Anmeldeinformationen erhalten.
Falls das alles für dich nach Overkill klingt , und Sie können es sich nicht leisten oder haben keine Zeit dafür – dann sollten Sie meiner (arroganten und elitären) Meinung nach nichts Wichtiges oder Sensibles in Ihrer Datenbank speichern. Und wenn Sie nichts Wichtiges oder Sensibles speichern, ist es auch nicht wichtig, wo Sie Ihre Anmeldeinformationen speichern – warum sollten Sie in diesem Fall überhaupt ein Passwort verwenden?
Verwandte:Vier zufällige Wörter aus einer Liste für XKCD-ähnliche Passwörter generieren?Zuletzt , wenn Sie es absolut nicht vermeiden können, irgendeine Art von Zugangsdaten zu speichern, könnten Sie die Zugangsdaten schreibgeschützt und im Besitz von root haben und root könnte den Besitz auf einer äußerst vorübergehenden Basis gewähren, wenn Sie von einem Skript dazu aufgefordert werden (weil Ihr Skript nicht als root ausgeführt werden, es sei denn, dies ist unbedingt erforderlich, und die Verbindung zu einer Datenbank macht dies nicht erforderlich). Aber es ist immer noch keine gute Idee.