Der beste Weg, ein Datenbankkennwort in einem Startskript/einer Konfigurationsdatei zu speichern?

Question

Daher müssen unsere Webserver-Apps eine Verbindung zur Datenbank herstellen, und einige andere Apps verfügen über Startskripte, die beim Booten ausgeführt werden.

Was ist die beste Möglichkeit, den Namen/das Passwort für diese Anwendungen zu speichern?

• Sicherheit, z.B.Vielleicht möchten wir nicht, dass Systemadministratoren das Datenbankkennwort kennen
• Wartbarkeit, z.B.Dadurch lässt sich die Konfiguration einfach ändern, wenn sich das Passwort ändert usw.

Sowohl Windows- als auch Linux-Lösungen werden geschätzt!

Answer 1

Der beste Weg, Ihr Passwort zu schützen, besteht darin, es nicht mehr zu verwenden.Verwenden Sie eine vertrauenswürdige Verbindung:Wie man:Stellen Sie mithilfe der Windows-Authentifizierung in ASP.NET 2.0 eine Verbindung zu SQL Server her.Dann haben Sie nichts zu verbergen – veröffentlichen Sie Ihre web.config und Quelle der Welt, sie können immer noch nicht auf Ihre Datenbank zugreifen.

Wenn das bei Ihnen nicht funktioniert, verwenden Sie die integrierte Funktion Konfigurationsverschlüsselungssystem in ASP.NET.

Answer 2

PostgreSQL bietet a schöne Lösung für diese Art von Situation in ihrer Dokumentation.Im Wesentlichen verwenden Sie SSH, um einen Port auf Ihrem Computer mit dem PostgreSQL-Server-Port auf dem Remote-Computer zu verbinden.Dies umfasst drei Stufen der Authentifizierung:

1. Beschränken Sie den Zugriff auf den lokalen Port, indem Sie beispielsweise nur einem bestimmten Benutzer erlauben, sich damit zu verbinden.
2. Richten Sie eine passwortlose Verbindung zum PostgreSQL-Host mit ssh als bestimmtem Benutzer ein.
3. Erlauben Sie dem Benutzer, SSH-Verbindungen herzustellen, um lokalen Zugriff auf PostgreSQL ohne Passwort zu haben.

Dies verringert die Sicherheit dahingehend, ob Ihre Benutzerkonten gesichert sind und Ihre SSH-Konfiguration korrekt ist und Sie kein Passwort irgendwo speichern müssen.

Bearbeiten:Ich sollte hinzufügen, dass dies mit jeder Datenbank funktioniert, die auf einen TCP/IP-Port lauscht.Es wird zufällig in PostgreSQL beschrieben.Und Sie möchten, dass iptables (oder das Äquivalent unter Linux) die Portbeschränkungen übernimmt.Sehen Das.

Answer 3

Ich stimme lomaxx zu:Wenn jemand bereits auf dem Server ist oder weitreichenden Zugriff darauf hat (z. B. ein Systemadministrator), ist das Spiel so gut wie vorbei.Die Idee wäre also, einen Server zu verwenden, von dem Sie überzeugt sind, dass er in dem von Ihnen gewünschten Maße sicher ist.Speziell:

• Sie müssen den Systemadministratoren vertrauen
• Sie müssen jedem anderen vertrauen, der Code auf demselben Server ausführt (aus diesem Grund ist Shared Hosting für mich ein absolutes Tabu).

Darüber hinaus scheinen Umgebungsvariablen eine beliebte Wahl zum Speichern dieser Art von Anmeldeinformationen zu sein, da dies bedeutet, dass der Zugriff auf die Quelle (z. B. durch Gefährdung der Entwicklungsbox) diese nicht direkt offenlegt und sie außerdem gut lokalisiert werden kann Jeder Server (Entwicklung, Test usw.).

Answer 4

Klartext?Wenn sie sich auf Ihrem Server befinden, hoffe ich, dass der Server sicher genug ist, um keinen unbefugten Zugriff zu ermöglichen.Wenn Leute auf dem Server auf Ihre Konfigurationsdateien zugreifen können, ist schon viel früher etwas schief gelaufen.

Answer 5

Klärung:in Bezug auf Sicherheit, Wartbarkeit (z.B.Wenn sich das Login ändern muss, kann ich es später finden usw.)

@lomax:Vielleicht möchte ich nicht, dass jeder Zugriff auf den physischen Server hat (z. B.sysadmins), um das Passwort anzuzeigen.

Danke!

Answer 6

In den meisten Fällen reicht es meines Erachtens aus, das Passwort in einer Klartextdatei (z. B.mit base64).Sie können ein gespeichertes Passwort nicht vollständig vor einem entschlossenen Systemadministrator mit Root-Zugriff schützen, es besteht also eigentlich kein Grund, es zu versuchen.Eine einfache Verschleierung schützt jedoch davor, dass das Passwort versehentlich einem Schultersurfer preisgegeben wird.

Eine komplexere Alternative besteht darin, einen dedizierten sicheren Passwortserver einzurichten, der entweder:

• bietet einen Passwort-Entschlüsselungsdienst
• speichert die Passwörter tatsächlich zur Verwendung durch andere, weniger sichere Server

Abhängig von den verwendeten Netzwerkprotokollen bietet dies möglicherweise keinen Schutz vor einem betrügerischen Systemadministrator mit tcpdump.Und es schützt wahrscheinlich auch nicht vor einem entschlossenen Systemadministrator mit einem Debugger.An diesem Punkt könnte es an der Zeit sein, sich mit Kerberos-Tickets zu befassen.

Answer 7

Sie können einen symmetrischen Verschlüsselungsschlüssel in Ihre Binärdatei einbacken und diese Binärdatei beim Start einen verschlüsselten Benutzernamen/ein verschlüsseltes Passwort aus einer Datei auf der Festplatte lesen lassen.

Dies ist jedoch nicht viel mehr als eine Verschleierung, da Ihr Code wahrscheinlich irgendwo in einem Quell-Repository gespeichert ist.

Ich würde vorschlagen, dass Sie den Zugriff auf Ihre Server sowohl physisch als auch über das Netzwerk mithilfe einer Firewall und einer privaten Netzwerkblase besser kontrollieren und die Passwörter im Klartext (oder Base-64-codiert) auf der Festplatte mit gesperrten Berechtigungen speichern an den ausführenden Benutzer für Ihre Web-App.

Sie können den Datenbankserver auch sperren, um nur Verbindungen von Ihren Web-App-Maschinen per IP zu akzeptieren.

Letztendlich besteht Ihr Problem darin, dass der Schlüssel (Ihr DB-Benutzername/Passwort-Paar) für die programmgesteuerte, unbeaufsichtigte Nutzung durch Ihre Web-Apps verfügbar sein muss.