Die beste Methode, um ein Datenbankkennwort in einer Startskript/Konfigurationsdatei zu speichern?

Question

So müssen unsere Webserver-Anwendungen eine Verbindung zur Datenbank herstellen, und einige andere Anwendungen haben Startskripte, die beim Booten ausgeführt werden.

Was ist der beste Weg, den Namen/Passwort für diese Anwendungen zu speichern, in Bezug auf

• Sicherheit, z.B. vielleicht wollen wir nicht, dass Systemadministratoren das Datenbankpasswort kennen
• Wartbarkeit, z. Die Konfiguration kann leicht geändert werden, wenn sich das Passwort ändert usw.

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

Answer 1

Der beste Weg, um Ihr Passwort zu sichern, ist es, eines zu stoppen. Verwenden Sie eine gesicherte Verbindung: How To: Connect to SQL Server Using Windows Authentication in ASP.NET 2.0. Dann haben Sie nichts zu verbergen - veröffentlichen Sie Ihre web.config und Quelle in die Welt, sie können immer noch nicht Ihre Datenbank schlagen.

Wenn das nicht für Sie funktioniert, verwenden Sie das eingebaute configuration encryption system in ASP.NET.

Answer 2

Nur Text? Wenn sie auf Ihrem Server sind, würde ich hoffen, dass der Server sicher genug ist, um nicht autorisierten Zugriff zu erlauben. Wenn Leute auf Ihre Konfigurationsdateien auf dem Server zugreifen können, ist etwas viel früher falsch gelaufen.

Answer 3

Klarstellung: in Bezug auf Sicherheit, Wartbarkeit (zB wenn die Anmeldung ändern muss, kann ich es finden später, etc.)

@lomax: vielleicht könnte ich nicht möchte, dass jeder mit Zugriff auf den physischen Server (zB sysadmins), um das Passwort zu sehen.

Danke!

Answer 4

Sie können einen symmetrischen Verschlüsselungsschlüssel in Ihre Binärdatei brennen und diese Binärdatei einen verschlüsselten Benutzernamen/ein verschlüsseltes Kennwort aus einer Datei auf der Festplatte lesen lassen, wenn sie gestartet wird.

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

Ich würde vorschlagen, dass Sie besser bedient werden, um den Zugriff auf Ihre Server physisch und über das Netzwerk mit einer Firewall und einem privaten Netzwerk Blase zu kontrollieren, und speichern Sie die Kennwörter in der freien (oder Base-64-codiert) auf der Festplatte mit Berechtigungen, die für den Run-User für Ihre Web-App gesperrt sind.

Sie können den Datenbankserver auch so sperren, dass nur Verbindungen von Ihren Web-App-Rechnern per IP akzeptiert werden.

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

Answer 5

Ich stimme lomaxx zu: Wenn jemand bereits auf dem Server ist oder einen weitreichenden Zugriff darauf hat (wie ein Systemadministrator), ist das Spiel ziemlich vorbei. Die Idee wäre also, einen Server zu verwenden, dem Sie vertrauen, dass er so sicher ist, wie Sie es sich wünschen. Im Einzelnen:

• Sie müssen die Systemadministratoren vertrauen
• Sie müssen jemand anderen vertrauen, die auf demselben Server ausgeführt wird Code (aus diesem Grund Shared-Hosting eine große no-no für mich)

Darüber hinaus scheinen Umgebungsvariablen eine beliebte Wahl für die Speicherung dieser Arten von Anmeldeinformationen zu sein, da dies bedeutet, dass der Zugriff auf die Quelle (z. B. durch Kompromittieren der Dev-Box) es nicht direkt offen legt und auch schön sein kann lokalisiert für jeden Server (Entwickler, Test, usw.).

Answer 6

In den meisten Fällen glaube ich, dass es ausreicht, das Passwort in einer einfachen Textdatei zu verschleiern (z. B.mit base64). Sie können ein gespeichertes Passwort nicht vollständig gegen einen bestimmten Sysadmin mit Root-Zugriff schützen. Es ist also nicht unbedingt notwendig, es zu versuchen. Einfache Verschleierung schützt jedoch vor versehentlichem Aufdecken des Passworts für einen Schulter-Surfer.

Eine komplexere Alternative ist einen speziellen sicheren Passwort-Server einrichten, das entweder:

• ein Entschlüsselungs Service-Passwort bietet
• tatsächlich die Passwörter für die Verwendung speichert, die durch anderen, weniger sicheren Server

Abhängig von den verwendeten Netzwerkprotokollen schützt dies möglicherweise nicht vor einem Rogue-Systemadministrator mit tcpdump. Und es wird wahrscheinlich auch nicht gegen einen bestimmten Sysadmin mit einem Debugger schützen. An diesem Punkt könnte es an der Zeit sein, etwas wie Kerberos-Tickets zu betrachten.

Answer 7

PostgreSQL bietet eine nice solution für diese Art von Situation in ihrer Dokumentation. Im Wesentlichen verwenden Sie ssh, um einen Port auf Ihrem Computer mit dem PostgreSQL-Serverport auf dem Remotecomputer zu verbinden. Dies hat drei Stufen der Authentifizierung:

Beschränken Sie den Zugriff auf den lokalen Port, so dass nur ein bestimmter Benutzer eine Verbindung zu ihm herstellen kann.

Richten Sie eine kennwortlose Verbindung zum PostgreSQL-Host mit ssh als einem bestimmten Benutzer ein.

Erlauben Sie dem Benutzer ssh verbindet als lokalen Zugriff auf PostgreSQL ohne ein Passwort.

Dies reduziert die Sicherheit, ob Ihre Benutzerkonten gesichert sind und Ihre ssh-Konfiguration solide ist, und Sie kein Passwort irgendwo gespeichert brauchen.

Bearbeiten: Ich sollte hinzufügen, dass dies mit jeder Datenbank funktioniert, die einen TCP/IP-Port überwacht. Es wird zufällig in PostgreSQL beschrieben. Und Sie werden Iptables (oder das Äquivalent von Linux) wollen, um die Portbeschränkungen zu machen. Siehe this.