Sollten Server-/Datenbank-Konfigurationsdateien, einschließlich Kennwörter, in der Quellcodeverwaltung gespeichert werden?

Ich bin auf der Suche nach Best Practices …

Angenommen, eine Webanwendung, die mit einigen verschiedenen Produktionsservern (Datenbanken usw.) interagiert, sollten die Konfigurationsdateien, die Datenbankkennwörter enthalten, in der Quellcodeverwaltung (z. B. git, svn) gespeichert werden?

Wenn nicht, was ist der beste Weg, um Passwörter für Serverdatenbanken (oder andere verwandte) Passwörter zu verfolgen, auf die Ihre Anwendung Zugriff benötigt?

Bearbeiten: eine Prämie hinzugefügt, um mehr Diskussionen anzuregen und zu hören, was mehr Menschen als Best Practice betrachten.

Hier gibt es keine Patentrezept-Antwort, und alles hängt stark von den Details ab.

Zunächst halte ich es für die beste Vorgehensweise, den gesamten Quellcode von der Konfiguration in einem separaten Repository zu trennen. Quellcode bleibt also Quellcode, aber seine Installation oder Bereitstellung (mit Konfiguration, Passwörtern usw.) ist das andere. Auf diese Weise trennen Sie die Aufgaben der Entwickler strikt von den Aufgaben der Systemadministratoren und können letztendlich zwei unterschiedliche Teams aufbauen, die das tun, worin sie gut sind.

Wenn Sie über ein separates Quellcode-Repository und ein Bereitstellungs-Repository verfügen, sollten Sie als Nächstes Bereitstellungsoptionen in Betracht ziehen. Der beste Weg, den ich hier sehe, ist die Verwendung von Bereitstellungsverfahren, die für ein ausgewähltes Betriebssystem typisch sind (dh das Erstellen autonomer Pakete für ein ausgewähltes Betriebssystem, wie es die Betreuer des Betriebssystems tun).

Zum Beispiel bedeuten Red Hat- oder Debian-Paketierungsprozeduren normalerweise, einen Software-Tarball von einer externen Site (das wäre der Export von Quellen aus Ihrem Quellcode-VCS) zu greifen, ihn zu entpacken, Pakete zu kompilieren und bereit für die Bereitstellung vorzubereiten. Die Bereitstellung selbst sollte im Idealfall bedeuten, dass Sie einfach einen schnellen und einfachen Befehl ausführen, mit dem die Pakete installiert werden, z rpm -U package.rpm, dpkg --install package.deb oder apt-get dist-upgrade (vorausgesetzt, dass Ihre gebauten Pakete in ein Repository gehen, wo apt-get sie finden könnte).

Damit es auf diese Weise funktioniert, müssen Sie natürlich alle Konfigurationsdateien für alle Komponenten eines Systems in einem voll funktionsfähigen Zustand bereitstellen, einschließlich aller Adressen und Anmeldeinformationen.

Betrachten wir zur Präzisierung eine typische „kleine Dienst“-Situation: eine PHP-Anwendung, die überall bereitgestellt wird n Anwendungsserver mit Apache / mod_php, Zugriff m MySQL-Server. Alle diese Server (oder virtuelle Container, das spielt keine Rolle) befinden sich in einem geschützten privaten Netzwerk. Um dieses Beispiel zu vereinfachen, nehmen wir an, dass jeder echten Internetverbindung ein Cluster von vorangestellt ist k HTTP-Beschleuniger / Reverse-Proxys (wie nginx / lighttpd / apache), die sehr einfach zu konfigurieren sind (nur interne IPs zum Weiterleiten).

Was brauchen wir, damit sie verbunden und voll funktionsfähig sind?

• MySQL-Server: Einrichten von IPs/Hostnamen, Einrichten von Datenbanken, Bereitstellen von Logins und Passwörtern
• PHP-Anwendung: Richten Sie IPs/Hostnamen ein, erstellen Sie eine Konfigurationsdatei, die MySQL-Server-IPs, Logins, Passwörter und Datenbanken enthält

Beachten Sie, dass es hier zwei verschiedene “Arten” von Informationen gibt: IPs/Hostnamen sind etwas Festes, Sie möchten sie wahrscheinlich ein für alle Mal zuweisen. Logins und Passwörter (und sogar Datenbanknamen) hingegen dienen hier nur Verbindungszwecken – um sicherzustellen, dass MySQL wirklich unsere PHP-Anwendung damit verbindet. Meine Empfehlungen hier wären also, diese 2 “Typen” aufzuteilen:

• “Permanente” Informationen wie IPs sollten in einigen VCS gespeichert werden (anders als Quellcode-VCS)
• „Vorübergehende“ Informationen, wie z. B. Kennwörter zwischen zwei Anwendungen, sollten niemals gespeichert, sondern während der Generierung von Bereitstellungspaketen generiert werden.

Hier bleibt die letzte und schwierigste Frage: Wie erstellt man Bereitstellungspakete? Es stehen mehrere Techniken zur Verfügung, zwei Hauptwege sind:

• Exportierter Quellcode von VCS1 + “permanente” Konfiguration von VCS2 + Erstellungsskript von VCS3 = Pakete
• Quellcode ist in VCS1; VCS2 ist eine verteilte Versionskontrolle (wie git oder hg), die im Wesentlichen “Forks” von VCS1 + Konfigurationsinformationen + Erstellungsskripts enthält, die . Mir persönlich gefällt dieser Ansatz besser, er ist viel kürzer und letztendlich einfacher zu verwenden, aber die Lernkurve kann etwas steiler sein, besonders für Administratoren, die dafür git oder hg beherrschen müssen.

Für ein Beispiel oben würde ich Pakete erstellen wie:

• my-application-php – die von mod_php, Apache abhängen und generierte Dateien wie enthalten würden /etc/my-php-application/config.inc.php Dazu gehören MySQL-Datenbank-IPs / Hostnamen und Login / Passwort, die als generiert werden md5(current source code revision + salt). Dieses Paket würde auf jedem installiert werden n Anwendungsserver. Idealerweise sollte es in der Lage sein, auf einem sauber installierten Betriebssystem zu installieren und ohne manuelle Aktivität einen voll funktionsfähigen Anwendungsclusterknoten zu erstellen.
• my-application-mysql – was vom MySQL-Server abhängen würde und ein Post-Install-Skript enthalten würde, das:
  • startet den MySQL-Server und stellt sicher, dass er beim Start des Betriebssystems automatisch gestartet wird
  • verbindet sich mit dem MySQL-Server
  • prüft, ob die erforderliche Datenbank vorhanden ist
  • wenn nein – erstellt die Datenbank, bootet sie mit Inhalten und erstellt Login mit Passwort (die gleichen Logins und Passwörter wie generiert in /etc/my-php-application/config.inc.phpmit MD5-Algorithmus)
  • wenn ja – stellt eine Verbindung zur Datenbank her, wendet Migrationen an, um sie auf die neue Version zu bringen, tötet alle älteren Logins / Passwörter und erstellt das neue Login / Passwort-Paar neu (erneut generiert mit der Methode md5 (Revision + Salt))

Letztendlich sollte es den Vorteil bringen, dass Sie Ihre Bereitstellung mit einem einzigen Befehl wie aktualisieren generate-packages && ssh-all apt-get dist-upgrade. Außerdem speichern Sie anwendungsübergreifende Kennwörter nirgendwo und sie werden bei jedem Update neu generiert.

Dieses ziemlich einfache Beispiel veranschaulicht viele Methoden, die Sie hier anwenden können – aber letztendlich liegt es an Ihnen, zu entscheiden, welche Lösung hier besser und welche übertrieben ist. Wenn Sie hier oder als separate Frage weitere Details angeben, versuche ich gerne, auf Details einzugehen.

Abgesehen davon, dass Passwörter niemals im Klartext gespeichert werden sollten irgendwo (mit Ausnahme des Schädels von jemandem oder eines verschlossenen Tresors, auf den nur der CEO, der CFO und der CIO zugreifen können (und der alle drei Schlüssel gleichzeitig benötigt)), sollten Sie alles, was dazu erforderlich ist, in der Quellcodeverwaltung speichern bauen Ihr Produkt.

Das bedeutet nicht nur Ihre Quelle, sondern sogar die Spezifikationen für die Build-Maschinen, Compiler-Optionen, die Compiler selbst und so weiter.

Wenn wir einen Weg finden könnten, die physische Hardware einzuchecken, würden wir das auch tun 🙂

Alles, was durch den Build-Prozess selbst reproduziert werden kann, oder irgendetwas für Laufen Anstatt die Software (z. B. Ihre Passwörter) zu erstellen, gehört sie im Allgemeinen nicht unter die Quellcodeverwaltung, aber einige Shops tun dies für ihre ausführbaren Dateien, generierten Dokumente usw., nur damit sie schnell eine bestimmte Version zur Installation herausbringen können.

Kennwörter sollten nicht in der Quellcodeverwaltung gespeichert werden. Überhaupt. Je. Sehen Wie man Geheimnisse geheim hält

Kennwörter, Servernamen usw. sind Teil der Bereitstellungskonfiguration, die vom Serveradministrator durchgeführt wird. Es ist wichtig, dieses Verfahren zu dokumentieren und das dokumentierte Verfahren unter Kontrolle zu bringen.

Alternativ könnte die Bereitstellungskonfiguration durch ein Skript durchgeführt werden, das der Systemadministrator ausführen würde, um die Konfiguration durchzuführen, und während der Skriptausführung würde es den Systemadministrator auffordern, die erforderlichen Informationen bereitzustellen. Auch dieses Skript muss in der Versionskontrolle gehalten werden.

Alles andere, abgesehen von der Serverkonfiguration Muss in Quellcodeverwaltung sein.

Das Speichern der Serverkonfiguration in der Quellcodeverwaltung ist im Allgemeinen eine schlechte Idee, da sie Bereitstellungen im Wege steht und kleine Katastrophen verursachen kann (z. B. wenn jemand nicht erkennt, dass seine von der Quellcodeverwaltung bereitgestellte Testversion mit einem Live-Dienst kommuniziert).

Bewahren Sie diese Konfigurationsdateien immer außerhalb des Webroots auf.

Vertrauenswürdige Verbindungen können eine Option sein, die es bekannten IP-Adressen ermöglicht, eine Verbindung zu Diensten herzustellen, indem dieser Dienst konfiguriert wird.

• Verwenden Sie bei der Ausführung unter Windows die integrierte Authentifizierung. Beziehen auf Sichern des Datenzugriffs
• MySQL konfigurieren, um Verbindungen von localhost zuzulassen und kein Passwort zu verlangen. Sehen Schritt 7: Sichern eines MySQL-Servers unter Windows
• PostgreSQL können Sie verwenden ~/.pgpass.

Im Allgemeinen stimme ich paxdiablo zu: Stellen Sie alles, was Sie können, unter Quellcodeverwaltung. Dazu gehören Produktionskonfigurationsdateien mit Datenbankanmeldeinformationen.

Denken Sie an die Situation, in der Ihr Server abstürzt, die Backups sich als schlecht herausstellen und Sie diesen Server wieder in Betrieb nehmen müssen. Ich denke, Sie und Ihr Kunde (oder Chef) würden definitiv zustimmen, dass es ein großes Plus ist, alles zu haben, was zum Bereitstellen der Website in der Quellcodeverwaltung erforderlich ist.

Wenn Sie mithilfe von kontinuierlicher Integration (eine weitere bewährte Methode) einfach bereitzustellende Pakete aus Ihren Quellen erstellen möchten, müssen Sie die Konfigurationsdateien der Quellcodeverwaltung unterstellen.

Bedenken Sie auch, dass die Entwickler, die Zugriff auf die Quellcodeverwaltung haben, in den meisten Fällen nicht direkt auf den Produktionsdatenbankserver zugreifen können. Die Produktionskennwörter sind für sie nutzlos.

Wenn die falschen Personen Zugriff auf Ihre Quellen erhalten haben, müssen sie sich dennoch Zugriff auf den Produktionsserver verschaffen, um mit den Passwörtern Schaden anzurichten. Wenn Ihre Produktionsumgebung also ordnungsgemäß geschützt ist, sind die Sicherheitsrisiken von Kennwörtern in der Quellcodeverwaltung sehr begrenzt.

Ich denke, bei dieser Frage geht es mehr um Informationsbesitz, Vertrauen und Organisation. Sie sollten sich fragen, welchem ​​Teil Ihres Unternehmens Sie vertrauen würden, dass er Ihre Systemkennwörter vor Offenlegung und Missbrauch schützt?

Ich war in Organisationen, in denen sie von den für das Geschäft verantwortlichen Personen aufbewahrt wurden. In anderen wurden sie an das Betriebsteam delegiert, das auch für die Prozesse rund um die Erstellung und Nutzung usw. verantwortlich war.

Das Wichtigste ist, dass in Ihrer Organisation klar definiert ist, wer Zugriff auf Systemkennwörter haben soll. Danach können Sie sich für geeignete technische Lösungen zum Schutz der Passwörter entscheiden.

Nein. Das Produktionskennwort sollte direkt auf dem Server konfiguriert werden. Sie sollten eine Bereitstellungsanweisung für das Bereitstellungsteam/die Bereitstellungsperson erstellen, um die richtige Eigenschaftendatei während der Bereitstellung zu ändern.

In meinen Subversion-Repositorys für PHP werden Konfigurationsdateien, die Passwörter enthalten, als eingecheckt config.php.sample mit Hinweisen darauf, was bereitgestellt werden muss, und Skripten, die sich auf erfordern a config.php am selben Ort anwesend sein.

Das Repository ist so konfiguriert, dass es ignoriert wird config.php für dieses Verzeichnis, um “versehentliche” Hinzufügungen oder Eincheckvorgänge zu vermeiden.