So wie ich es sehe, ist es eine Konvention , keine Passwörter in Git (oder einer anderen Versionskontrolle) zu speichern. Ich nehme an, man könnte sich entscheiden, es nicht mit verschiedenen Ergebnissen durchzusetzen, aber hier ist der Grund, warum dies allgemein verpönt ist:

1. Git macht es schmerzhaft, Passwörter aus dem Quellcode-Verlauf zu entfernen, was dazu führen kann, dass Leute falsch liegen Idee, dass das Kennwort bereits in der aktuellen Version entfernt wurde.
2. Wenn Sie das Kennwort in die Quellcodeverwaltung einfügen, entscheiden Sie sich grundsätzlich, das Kennwort für alle Personen freizugeben, die Zugriff auf das Repository haben, einschließlich zukünftiger Benutzer. Dies erschwert das Einrichten von Rollen innerhalb eines Entwicklerteams, die möglicherweise unterschiedliche Berechtigungen haben.
3. Quellcodeverwaltungssoftware wird häufig ziemlich kompliziert, insbesondere "All-in-One" -Systeme. Dies bedeutet, dass das Risiko besteht, dass dieses System irgendwann kompromittiert wird, was zu einem Kennwortverlust führt.
4. Andere Entwickler wissen möglicherweise nicht, dass das Kennwort gespeichert ist, und können das Repository falsch handhaben. Wenn Schlüssel in der Quelle vorhanden sind, ist besondere Sorgfalt erforderlich müsste beim Teilen des Codes berücksichtigt werden (auch innerhalb des Unternehmens; dies könnte zu einem Bedarf an verschlüsselten Kanälen führen).
ol>

Ich kann nicht sagen, dass jedes mit infosec verbundene Muster gut ist, aber bevor Sie sie brechen, ist es immer eine gute Idee, Ihr Bedrohungsmodell und Ihre Angriffsmethoden zu berücksichtigen. Wenn dieses bestimmte Passwort durchgesickert ist, wie schwierig wäre es für einen Angreifer, es zu verwenden, um dem Unternehmen Schaden zuzufügen?

Zunächst der nicht sicherheitsrelevante Grund:

Workflow zur Kennwortänderung

Kennwörter ändern sich unabhängig von einem Softwareanwendungscode. Wenn ein DBA ein Datenbankkennwort ändert, ist es für Entwickler sinnvoll, den Code zu aktualisieren, einen neuen Build und eine neue Version für die Produktion zu erhalten und zu versuchen, alles zeitlich zu steuern? Kennwörter sind ein Laufzeitkonfigurationsartefakt und kein Entwicklungsartefakt. Sie sollten über Konfigurationsdateien, Umgebungsvariablen oder das von Ihnen verwendete Konfigurationsparadigma eingefügt werden.

Autorisierungsbereich

Im Allgemeinen bieten Versionskontrollsysteme eine Autorisierungskontrolle Daher können nur autorisierte Benutzer darauf zugreifen. Innerhalb eines Repositorys sind Berechtigungen jedoch im Allgemeinen entweder schreibgeschützt oder schreibgeschützt oder möglicherweise ein Schnickschnack, wie er von GitHub bereitgestellt wird. Es ist unwahrscheinlich, dass Sie Sicherheitsbeschränkungen finden, mit denen Entwickler Quellcode abrufen können, jedoch keine Kennwörter. Wenn Sie ein Repo klonen können, können Sie ein Repo klonen. Zeitraum. In vielen Umgebungen haben Entwickler keinen vollständigen Zugriff auf die Produktion. Manchmal haben sie schreibgeschützten Zugriff auf Produktionsdatenbanken, manchmal keinen Zugriff. Was ist, wenn Entwickler im Allgemeinen Zugriff haben, Sie aber nicht möchten, dass alle Praktikanten, Neueinstellungen usw. Zugriff haben?

Umgebungen

Was ist, wenn Sie mehrere Umgebungen haben, z. B. eine Entwicklungsumgebung, eine QS-Umgebung, Staging und Produktion? Würden Sie alle ihre Passwörter in der Versionskontrolle speichern? Wie würde die App wissen, welche zu verwenden ist? Die App müsste eine Möglichkeit haben, die Umgebung zu kennen, was letztendlich eine Konfigurationseinstellung sein würde. Wenn Sie den Umgebungsnamen als Konfigurationseinstellung festlegen können, können Sie das Datenbankkennwort als Konfigurationseinstellung festlegen (zusammen mit der Verbindungszeichenfolge, dem Benutzernamen usw.).

Verlauf

Wie bereits erwähnt, dient die Versionskontrolle dazu, den Verlauf zu erhalten. Ältere Passwörter können also weiterhin abgerufen werden, was möglicherweise nicht das Beste ist.

Kompromiss

Wie oft haben wir in den Nachrichten Schlagzeilen über Quellcode für ein Produkt gesehen, das in die Welt gelangt ist? Der Quellcode ist alles, was in der Versionskontrolle enthalten ist. Dies ist wahrscheinlich der Hauptgrund, Passwörter nicht in die Versionskontrolle aufzunehmen!

Allerdings ...

Allerdings müssen Passwörter gespeichert werden irgendwo . Die oben genannten Bedenken deuten nicht unbedingt darauf hin, dass sie überhaupt nicht in der Versionskontrolle gespeichert werden sollten, sondern dass sie in der Versionskontrolle nicht im Quellcode-Repository des Produkts gespeichert werden sollten. Ein separates Repo für Konfigurationsverwaltung, Operationen usw. ist sehr vernünftig. Der Schlüssel besteht darin, Vorgänge von der Entwicklung zu trennen, wenn es um Sicherheitsanmeldeinformationen geht, und nicht unbedingt die Versionskontrolle insgesamt zu vermeiden.

Außerdem habe ich in Umgebungen außerhalb der Produktion Kennwörter und API-Schlüssel für externe Systeme in gespeichert Konfigurationsdateien im Produktquellcode als Standard. Warum? Um es schmerzlos zu machen, wenn ein Entwickler den Code auscheckt, kann er ihn einfach erstellen und ausführen und muss keine zusätzlichen Konfigurationsdateien abrufen. Dies sind Anmeldeinformationen, die sich selten ändern und zu keinen Geschäftsgeheimnissen führen. Aber ich würde dies niemals mit Produktionsgeheimnissen tun.

Das Endergebnis ist also ... es kommt darauf an.

Es ist immer wichtig zu bedenken, dass Vorschläge auf Ihren Anwendungsfall zugeschnitten sein müssen. Sicherheitsvorkehrungen, die beispielsweise von der NSA getroffen werden, um alle Zero-Days zu schützen, die sie an einem regnerischen Tag aufbewahren, sollten viel strenger sein als Sicherheitsvorkehrungen, die zum Schutz von Up-Votes auf einer Website für Katzenbilder getroffen werden. In einem Extremfall kann ich mir ein Beispiel vorstellen, bei dem das Speichern von Passwörtern / Token / usw. in einem privaten Git-Repository sinnvoll sein könnte:

Wenn auf dieses Repository nur eine Person zugreift und die Anwendung keine speichert Informationen von beliebigem Wert.

In diesem Fall gehen Sie in die Stadt! Denken Sie daran, was @ d33tah in seiner Antwort gesagt hat - das Entfernen von Dingen aus einem Git-Repository kann überraschend schwierig sein (der springende Punkt ist schließlich, eine Geschichte von allem für immer zu führen). Wenn Sie sich also später entscheiden, möchten Sie es Arbeiten Sie mit mehr Menschen zusammen, aber möchten Sie nicht, dass sie vollen Zugriff auf alle Ihre Systeme erhalten. Dann haben Sie ein bisschen Kopfschmerzen.

Das ist es, worauf es wirklich ankommt zu. Ihr Code-Repository ist in gewisser Weise "öffentlich", auch wenn es nur für Mitarbeiter freigegeben ist. Nur weil Sie mit jemandem zusammenarbeiten möchten, heißt das nicht, dass Sie ihm vollen Zugriff auf Ihre Infrastruktur gewähren möchten (was effektiv passiert, wenn Sie Kennwörter / Token in Ihr Code-Repository einfügen). Es ist leicht zu denken, "Ja, aber ich vertraue den Leuten, mit denen ich zusammenarbeite!", Aber das ist aus mehreren Gründen einfach die falsche Sichtweise auf das Szenario:

1. In der Praxis beginnt ein großer Teil der Datenlecks bei internen Akteuren (Mitarbeiter, Mitarbeiter). In einer Studie begannen etwa 43% der Datenverletzungen mit einem internen Akteur. Die Hälfte davon war beabsichtigt und die andere Hälfte zufällig
2. Dieser letzte Punkt ist wichtig und warum es nicht nur um Vertrauen geht. Ungefähr 20% der Datenverletzungen sind versehentlich und werden von internen Personen verursacht. Ich bin klug genug zu wissen, dass ich nicht klug genug bin, um immer alles richtig zu machen. Was ist, wenn ich mein Repository öffentlich mache, um Platz für ein unterhaltsames Integrationstool zu schaffen, und vergesse, dass ich Anmeldeinformationen darin habe? Was ist, wenn ich eine Backup-Festplatte habe, die ich vergessen habe zu verschlüsseln, und die mein Büro verlässt? Was passiert, wenn eines meiner Passwörter durchgesickert ist und jemand es verwendet, um das Passwort für das Konto in meinem Git-Repository zu erraten ( Husten Gentoo Github-Repository Husten )? Es gibt eine beliebige Anzahl von versehentlichen Fehlern, die ich machen kann und die dazu führen können, dass mein Git-Repository verfügbar gemacht wird. In diesem Fall und habe ich und die Person, die sie findet, weiß, was sie sehen, ich könnte sehr gut abgespritzt werden. Das klingt nach vielen und , aber in Wirklichkeit passieren so Verstöße.
3. Selbst wenn ich jemandem vertraue, heißt das nicht, dass ich geben muss ihnen uneingeschränkten Zugriff auf alles [Fügen Sie ein kitschiges Zitat darüber ein, wie Strom korrumpiert]. Das Einfügen von Anmeldeinformationen in ein Git-Repository bedeutet wiederum, dass ich möglicherweise allen meinen Mitarbeitern vollen Zugriff auf meine gesamte Infrastruktur gewähren kann. Es besteht immer die Möglichkeit, dass Sie diese Person nicht so gut kennen, wie Sie denken, und sie sich möglicherweise dazu entschließen, etwas zu tun, das sie nicht tun sollten. Selbst wenn Sie persönlich jeden Ihrer Mitarbeiter in Ihrem Leben kennen und ihm anvertrauen, bedeutet dies nicht, dass er einige der oben genannten Fehler (oder eine der endlosen Optionen, die ich nicht erwähnt habe) nicht macht, um Ihr Leben versehentlich freizugeben Code.
ol>

Kurz gesagt, bei guter Sicherheit geht es darum, eine mehrschichtige Verteidigung zu haben. Die meisten Hacks finden statt, weil Hacker in einem Bereich Schwachstellen finden, die es ihnen ermöglichen, Schwachstellen in einem anderen Bereich auszunutzen, was zu einem anderen Ort führt und sie schließlich zur großen Auszahlung führt. Wenn Sie so viele Sicherheitsvorkehrungen treffen, wie es für Ihre Situation sinnvoll ist, ist das Ganze sicher. Auf diese Weise müssen Sie nicht fragen: "War dies ein gezielter Angriff und muss ich jetzt jeden einzelnen Berechtigungsnachweis ändern, den ich überall habe, weil eine Festplatte aus Ihrem Büro kommt und Sie feststellen, dass sie nicht verschlüsselt war?" waren sie alle im Git-Repository auf diesem Backup-Laufwerk? ". Abhängig von Ihrer Situation trifft dies möglicherweise nicht auf Sie zu, aber hoffentlich hilft dies zu erklären, in welchen Szenarien dies von Bedeutung sein könnte.

Wenn Sie Geheimnisse (Kennwörter, Zertifikate, Schlüssel) vom Quellcode trennen, können Sie Quelle und Geheimnisse gemäß verschiedenen Richtlinien verwalten. Wie alle Ingenieure den Quellcode lesen können, können nur die Personen, die direkt für Produktionsserver verantwortlich sind, auf die Geheimnisse zugreifen.

Dies erleichtert Entwicklern das Leben, da sie nicht an die strengen Sicherheitsrichtlinien gebunden sind werden benötigt, um die Geheimnisse zu schützen. Richtlinien zur Quellcodeverwaltung können für sie wesentlich komfortabler gestaltet werden.

Diese Konvention ist wie viele andere "Best Practices" für die Sicherheit ein praktischer Weg, um sicherzustellen, dass aufgrund schlechter Gewohnheiten oder Routine nichts schief geht.

Wenn Sie erinnern sich immer daran, dass sich Ihre vertraulichen Kennwörter in Ihrem Versionskontrollsystem befinden und wenn Sie niemals jemandem, der keinen Kennwortzugriff haben sollte, Zugriff auf das Repository gewähren und wenn Ihr Repository gespeichert ist So sicher wie diese Geheimnisse es erfordern und wenn Ihr Bereitstellungsprozess ebenfalls sicher und vor unbefugten Personen geschützt ist und wenn Sie sicher sein können, dass alle Sicherungen und Kopien Ihres Repositorys vorhanden sind sind und ... Sie können wahrscheinlich ein paar weitere "Wenn" hinzufügen, die für Ihren Kontext spezifisch sind.

... dann können Sie Ihre Passwörter gut in Ihrem Versionskontrollsystem speichern.

In den meisten Fällen entspricht mindestens eines dieser "Wenn" entweder nicht Ihren Bedingungen oder liegt außerhalb Ihrer Kontrolle.

In vielen Einstellungen sollten Ihre Entwickler beispielsweise keinen Zugriff auf die Produktionsdatenbank haben. Oder das Backup-System wird an eine andere Abteilung ausgelagert. Oder Ihr Erstellungsprozess wird in die Cloud ausgelagert.

Aus diesem Grund ist im Allgemeinen das Nicht-Speichern Ihrer Kennwörter in Ihrem Versionskontrollsystem eine bewährte Methode, um sicherzustellen, dass Sie dies nicht tun Fallen Sie in eine dieser Fallen, weil Sie nicht an sie gedacht haben. "Keine Passwörter in Git" ist leichter zu merken als eine lange Liste von Bedingungen, die Sie erfüllen müssen, um Passwörter sicher unter Versionskontrolle zu speichern.

Andere Antworten sind großartig, berücksichtigen aber auch das Problem der Sicherungen. Sie haben viel mehr Flexibilität, wo, wie und wie lange Sie Ihre Code-Repository-Sicherungen speichern, wenn diese keine vertraulichen Informationen zum Zugriff auf Ihre Server- oder Administratorkonten enthalten.

Von einem anderen Sicherheits- Fokussierter Blickwinkel, nur Ihre Codesicherung könnte ein interessantes Ziel für unethische Konkurrenten in Ihrem Unternehmen sein. Abhängig von Ihrem Unternehmen würden die meisten Wettbewerber in einem Land der Rechtsstaatlichkeit es sowieso nicht anfassen. Eine Codesicherung mit Passwörtern ist ein Ziel für jede kriminelle Organisation, die an den Daten Ihrer Benutzer interessiert ist oder Ihr Unternehmen erpressen möchte.

Der Schaden durch einen Verstoß gegen das Code-Repository wäre aus ähnlichen Gründen mit den Passwörtern größer. Möchten Sie lieber Ihren Quellcode stehlen und veröffentlichen lassen oder alle Ihre Benutzer einem Identitätsdiebstahl aussetzen, mit einer möglichen Klage oder sogar einem Strafverfahren gegen Sie, weil Sie ihre privaten Daten nicht gesichert haben (denken Sie an GDPR)?

"Warum ist es eigentlich so schlimm, Ihre Schlüssel direkt in Ihre Haupttür zu stecken, wenn wir weit weg von der Zivilisation leben?"

Weil Leute, die schlechte Dinge tun wollen, es leicht machen und das tun Die Kosten, hart für sie zu tun, sind nicht zu hoch. Bewahren Sie Ihre Schlüssel nicht neben der Tür auf. Gesunder Menschenverstand.

Privates Repo? Wie viele Personen haben Zugriff auf den Download? Und wie viele Personen sind mit den Computern verbunden? Und dann ... Sind sie alle frei von Gefahren?

Dies hängt auch vom Quellcodeverwaltungssystem ab.

Git hat die Einstellung, dass das Quellcodeverwaltungssystem Ihnen einen zuverlässigen Verlauf des Projekts liefern sollte. Welches ist keine schlechte Einstellung zu haben. Wenn Sie ein Kennwort in git eingecheckt haben, ist es jedoch sehr schwierig, es aus Ihrem Repository zu entfernen.

Perforce hat zu diesem Zweck den Befehl "Auslöschen". Wenn Sie ein Passwort eingecheckt haben oder jemand eine unkomprimierte 8-Gigabyte-Videodatei eingecheckt hat oder jemand einen Code eines Drittanbieters eingecheckt hat, der das Urheberrecht einer Person verletzt und niemals hätte eingecheckt werden dürfen, oder jemand, der gefeuert wurde, hat viele Pornos eingecheckt An ihrem letzten Arbeitstag können Sie ihn "auslöschen". Es ist komplett aus dem Repository und aus der Geschichte verschwunden.