Wie gehe ich mit Passwörtern bei der automatischen Bereitstellung um?

Question

Als verantwortliche Administratoren kennen wir häufige Schwachstellen wie

• CWE-260: Passwort in der Konfigurationsdateihttp://cwe.mitre.org/data/definitions/260.html
• CWE-522: Unzureichend geschützte Anmeldeinformationenhttp://cwe.mitre.org/data/definitions/522.html
• CWE-257: Speichern von Passwörtern in einem wiederherstellbaren Formathttp://cwe.mitre.org/data/definitions/557.html

Doch wie gehen wir in der Praxis damit um?

Natürlich ist es mit Technologien wie der passwortlosen Authentifizierung über SSH und Tools wie sudo möglich, an wichtigen Stellen gespeicherte Anmeldeinformationen zu löschen, was bei der automatischen Bereitstellung von Linux-Servern eine große Hilfe ist.

Doch sobald Sie das Betriebssystem verlassen und Anwendungen installieren, stehen Sie wahrscheinlich vor der Frage, wo Sie die Passwörter sicher speichern können.

Wenn Sie beispielsweise einen Datenbankserver installieren, müssen Sie das Kennwort höchstwahrscheinlich im Klartext in einer Konfigurationsdatei Ihrer Webanwendung speichern.

Anschließend sollten Sie die Konfigurationsdatei sichern, sodass nur der Administrator die Anmeldeinformationen anzeigen kann, und Sie sollten die Zugriffsberechtigungen des Datenbankbenutzers beschränken, um die möglichen Auswirkungen auf die Sicherheit zu begrenzen.

Aber wie geht man mit dem Hauptadministrations-Datenbankkonto um? Zumindest Ihre DBAs sollten es kennen (also brauchen Sie irgendwo den Klartext) und als OS-Administrator sollten Sienichtkennen die Anmeldeinformationen. Oder die Bereitstellung wird von DevOps durchgeführt und sie sollten nicht wissenbeliebigder Anmeldeinformationen auf Produktionsservern.

Mögliche Lösungen

Nach längerem Nachdenken komme ich zu drei möglichen Lösungen, die allerdings alle ihre Schwächen haben:

1. Generieren Sie während der Bereitstellung zufällige Anmeldeinformationen und speichern Sie diese in einer Datenbank, sodass sie nur einmal geschrieben werden können. Und z. B. haben Datenbankadministratoren einen anderen Benutzer, der nur Datenbankanmeldeinformationen lesen kann. Aber wie geht man mit Klartextkennwörtern in Konfigurationsdateien von z. B. Webanwendungen um? Ein Root-Benutzer könnte sie lesen. Auch der Root-Benutzer der Kennwortdatenbank könnte möglicherweise lesenalleKennwortanmeldeinformationen.

2. Akzeptieren Sie Klartext-Passwörter und Standardanmeldeinformationen während der Bereitstellung und fügen Sie ein Postscript hinzu, das sich ändertalle und jedesPasswörter. Möglicherweise sogar interaktiv, sodass autorisierte Personen die Anmeldeinformationen während der Laufzeit des Skripts eingeben müssen.

3. Verschlüsseln Sie das Passwort asymmetrisch mit dem Schlüssel eines vertrauenswürdigen Dritten. Wenn das Passwort abgefragt wird,muss seinnachträglich geändert.

Was meinen Sie? Sehen Sie hier Best Practices?

Answer 1

1. Sie sollten über eine sichere, verschlüsselte Datenbank mit allen Ihren Anmeldeinformationen verfügen
2. Ein Server sollte während der Bereitstellung durch Firewalls von außen völlig unzugänglich sein
3. Es ist in Ordnung, ein Skript einen zufälligen Pass generieren zu lassen und ihn Ihnen per E-Mail zuzusenden
4. Es ist auch in Ordnung, dieses Passwort zu ändern, nachdem der Server bereitgestellt wurde, BEVOR Sie den öffentlichen Zugriff zugelassen haben
5. Es ist in Ordnung, sich das Passwort per E-Mail zuzusenden, solange dies über Ihren internen Mailserver erfolgt und nicht über SMTP öffentlich weitergeleitet wird (bei SMTPS verhält es sich anders).

Sie können E-Mail durch praktisch jedes Protokoll ersetzen. Sie können das Passwort per SFTP irgendwohin übertragen, eine einmalige Nachricht mithilfe der API „onetimesecret“ erstellen, sie mithilfe von https in einen privaten Gist hochladen oder alles andere tun, was Ihnen einfällt.

Ich denke, das deckt ungefähr alles ab.