MySQL-wachtwoord beschermen bij het ontwikkelen in Python?

Kort antwoord

Dat kan niet.

Als het wachtwoord is opgeslagen in het artefact dat naar de eindgebruiker wordt verzonden, moet u moeten beschouw het als gecompromitteerd! Zelfs als het artefact een gecompileerd binair bestand is, zijn er altijd (min of meer gecompliceerde) manieren om bij het wachtwoord te komen.

De enige manier om uw resources te beschermen, is door slechts een beperkte API beschikbaar te stellen aan de eindgebruiker. Bouw ofwel een programmatische API (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) of stel bepaalde functionaliteiten in uw DB alleen bloot via SPROC's (zie hieronder).

Eerst een paar dingen...

De vraag zou hier niet moeten zijn hoe het wachtwoord te verbergen, maar hoe de database te beveiligen. Onthoud dat alleen wachtwoorden vaak een zeer zwakke bescherming zijn en niet moeten worden beschouwd als het enige mechanisme om de database te beschermen. Gebruik je SSL? Nee? Nou, dan zelfs als het lukt je om het wachtwoord in de applicatiecode te verbergen, het is nog steeds gemakkelijk om het op het netwerk te snuiven!

Je hebt meerdere opties. Allemaal met verschillende mate van beveiliging:

"Toepassingsrol"

Maak één database-gebruiker voor de applicatie. Autorisatie aanvragen voor deze rol. Een veel voorkomende opzet is om alleen CRUD-bewerkingen toe te staan.

Pluspunten

• heel eenvoudig in te stellen
• Voorkomt DROP queries (bijv. in SQL-injecties?)

Nadelen

• Iedereen die het wachtwoord ziet, heeft toegang tot alle gegevens in de database. Zelfs als die gegevens normaal gesproken verborgen zijn in de applicatie.
• Als het wachtwoord gecompromitteerd is, kan de gebruiker UPDATE . uitvoeren en DELETE zoekopdrachten zonder criteria (d.w.z.:een hele tabel in één keer verwijderen/bijwerken).

Atomic auth&auth

Creëer één databasegebruiker per applicatie-/eindgebruiker. Hierdoor kunt u atomaire toegangsrechten definiëren, zelfs per kolom. Bijvoorbeeld:Gebruiker X kan alleen kolommen far en baz van table foo selecteren. En niets anders. Maar gebruiker Y kan SELECT alles, maar geen updates, terwijl gebruiker Z volledige CRUD-toegang heeft (select, insert, update, delete).

Bij sommige databases kunt u de referenties op besturingssysteemniveau opnieuw gebruiken. Dit maakt authenticatie naar de gebruiker transparant (hoeft alleen maar in te loggen op het werkstation, die identiteit wordt dan doorgestuurd naar de DB). Dit werkt het gemakkelijkst in een volledige MS-stack (OS=Windows, Auth=ActiveDirectory, DB=MSSQL) maar is - voor zover ik weet - ook mogelijk in andere DB's.

Pluspunten

• Redelijk eenvoudig in te stellen.
• Zeer atomair autorisatieschema

Nadelen

• Kan vervelend zijn om alle toegangsrechten in de DB in te stellen.
• Gebruikers met UPDATE en DELETE rechten kunnen nog steeds per ongeluk (of opzettelijk?) zonder . verwijderen/bijwerken criteria. U loopt het risico alle gegevens in een tabel te verliezen.

Opgeslagen procedures met atomaire auth&auth

Schrijf nee SQL-query's in uw toepassing. Voer alles uit via SPROC's. Maak vervolgens voor elke gebruiker db-accounts aan en wijs alleen privileges toe aan de SPROC's .

Pluspunten

• Meest effectieve beschermingsmechanisme.
• SPROC's kunnen gebruikers dwingen criteria door te geven aan elke zoekopdracht (inclusief DELETE en UPDATE )

Nadelen

• ik weet niet zeker of dit werkt met MySQL (mijn kennis op dat gebied is gebrekkig).
• complexe ontwikkelcyclus:alles wat je wilt doen, moet eerst worden gedefinieerd in een SPROC.

Laatste gedachten

U mag nooit databasebeheertaken toestaan ​​aan de toepassing. Meestal zijn de enige bewerkingen die een toepassing nodig heeft SELECT , INSERT , DELETE en UPDATE . Als u deze richtlijn volgt, is er nauwelijks een risico dat gebruikers het wachtwoord ontdekken. Behalve de hierboven genoemde punten.

Bewaar in ieder geval back-ups. Ik neem aan dat je je database wilt projecteren tegen onbedoelde verwijderingen of updates. Maar ongelukken gebeuren... houd daar rekening mee;)