MySQL-Passwort beim Entwickeln in Python schützen?

Kurze Antwort

Das kannst du nicht.

Wenn das Passwort in dem Artefakt gespeichert ist, das an den Endbenutzer geliefert wird, müssen Sie es müssen Betrachten Sie es als kompromittiert! Selbst wenn das Artefakt eine kompilierte Binärdatei ist, gibt es immer (mehr oder weniger komplizierte) Wege, an das Passwort zu kommen.

Die einzige Möglichkeit, Ihre Ressourcen zu schützen, besteht darin, dem Endbenutzer nur eine begrenzte API zur Verfügung zu stellen. Erstellen Sie entweder eine programmatische API (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) oder stellen Sie nur bestimmte Funktionalitäten in Ihrer DB über SPROCs bereit (siehe unten).

Einige Dinge zuerst...

Die Frage sollte hier nicht sein, wie man das Passwort versteckt, sondern wie man die Datenbank sichert. Denken Sie daran, dass Passwörter oft nur einen sehr schwachen Schutz darstellen und nicht als einziger Mechanismus zum Schutz der DB betrachtet werden sollten. Verwenden Sie SSL? Nein? Na, dann auch wenn Sie schaffen es, das Passwort im Anwendungscode zu verstecken, es ist immer noch einfach, es im Netzwerk zu erschnüffeln!

Sie haben mehrere Möglichkeiten. Alle mit unterschiedlichem Sicherheitsgrad:

"Anwendungsrolle"

Erstellen Sie einen Datenbankbenutzer für die Anwendung. Beantragen Sie die Berechtigung für diese Rolle. Eine sehr häufige Einrichtung besteht darin, nur CRUD-Operationen zuzulassen.

Vorteile

• sehr einfach einzurichten
• Verhindert DROP Abfragen (zB in SQL-Injections?)

Nachteile

• Jeder, der das Passwort sieht, hat Zugriff auf alle Daten in der Datenbank. Auch wenn diese Daten normalerweise in der Anwendung verborgen sind.
• Wenn das Passwort kompromittiert ist, kann der Benutzer UPDATE ausführen und DELETE Abfragen ohne Kriterien (d.h.:eine ganze Tabelle auf einmal löschen/aktualisieren).

Atomic auth&auth

Erstellen Sie einen Datenbankbenutzer pro Anwendungs-/Endbenutzer. Auf diese Weise können Sie atomare Zugriffsrechte sogar pro Spalte definieren. Beispiel:Benutzer X kann nur die Spalten far und baz aus der Tabelle foo auswählen. Und sonst nichts. Aber Benutzer Y kann SELECT alles, aber keine Updates, während Benutzer Z vollen CRUD-Zugriff (auswählen, einfügen, aktualisieren, löschen) hat.

Bei einigen Datenbanken können Sie die Anmeldeinformationen auf Betriebssystemebene wiederverwenden. Dies macht die Authentifizierung für den Benutzer transparent (er muss sich nur an der Arbeitsstation anmelden, diese Identität wird dann an die DB weitergeleitet). Dies funktioniert am einfachsten in einem vollständigen MS-Stack (OS=Windows, Auth=ActiveDirectory, DB=MSSQL), ist aber - soweit mir bekannt ist - auch in anderen DBs möglich.

Vorteile

• Ziemlich einfach einzurichten.
• Sehr atomares Autorisierungsschema

Nachteile

• Kann mühsam sein, alle Zugriffsrechte in der DB einzurichten.
• Benutzer mit UPDATE und DELETE Rechte können immer noch versehentlich (oder absichtlich?) löschen/aktualisieren ohne Kriterien. Sie riskieren den Verlust aller Daten in einer Tabelle.

Gespeicherte Prozeduren mit atomarer Authentifizierung&Authentifizierung

Schreiben Sie nein SQL-Abfragen in Ihrer Anwendung. Führen Sie alles aus durch SPROCs. Erstellen Sie dann db-Konten für jeden Benutzer und weisen Sie Berechtigungen nur den SPROCs zu .

Vorteile

• Wirksamster Schutzmechanismus.
• SPROCs können Benutzer zwingen, Kriterien an jede Abfrage zu übergeben (einschließlich DELETE und UPDATE )

Nachteile

• Ich bin mir nicht sicher, ob das mit MySQL funktioniert (mein Wissen auf diesem Gebiet ist lückenhaft).
• komplexer Entwicklungszyklus:Alles, was Sie tun möchten, muss zuerst in einem SPROC definiert werden.

Abschließende Gedanken

Sie sollten der Anwendung niemals Datenbankverwaltungsaufgaben zulassen. Meistens sind die einzigen Operationen, die eine Anwendung benötigt, SELECT , INSERT , DELETE und UPDATE . Wenn Sie sich an diese Richtlinie halten, besteht kaum ein Risiko, dass Benutzer das Passwort entdecken. Außer den oben genannten Punkten.

Bewahren Sie in jedem Fall Backups auf. Ich nehme an, Sie möchten Ihre Datenbank gegen versehentliches Löschen oder Aktualisieren schützen. Aber Unfälle passieren... behalte das im Hinterkopf;)