Skydda MySQL-lösenord när du utvecklar i Python?

Kort svar

Du kan inte.

Om lösenordet lagras i artefakten som skickas till slutanvändaren måste anser det äventyras! Även om artefakten är en kompilerad binär, finns det alltid (mer eller mindre komplicerade) sätt att komma åt lösenordet.

Det enda sättet att skydda dina resurser är genom att endast exponera ett begränsat API för slutanvändaren. Bygg antingen ett programmatiskt API (REST, WS+SOAP, RMI, JavaEE+Servlets, ...) eller exponera bara vissa funktioner i din DB via SPROC:er (se nedan).

Några saker först...

Frågan här bör inte vara hur man döljer lösenordet, utan hur man säkrar databasen. Kom ihåg att endast lösenord ofta är ett mycket svagt skydd och bör inte betraktas som den enda mekanismen för att skydda DB. Använder du SSL? Nej? Tja, till och med om du lyckas gömma lösenordet i applikationskoden är det fortfarande lätt att sniffa på det i nätverket!

Du har flera alternativ. Alla med olika grader av säkerhet:

"Applikationsroll"

Skapa en databasanvändare för applikationen. Ansök om behörighet för denna roll. En mycket vanlig inställning är att endast tillåta CRUD-operationer.

Proffs

• mycket lätt att ställa in
• Förhindrar DROP frågor (t.ex. i SQL-injektioner?)

Nackdelar

• Alla som ser lösenordet har tillgång till all data i databasen. Även om den informationen normalt är dold i programmet.
• Om lösenordet äventyras kan användaren köra UPDATE och DELETE frågor utan kriterier (dvs.:radera/uppdatera en hel tabell på en gång).

Atomic auth&auth

Skapa en databasanvändare per applikation-/slutanvändare. Detta gör att du kan definiera atomära åtkomsträttigheter även per kolumn. Till exempel:Användare X kan bara välja kolumner långt och baz från tabellen foo. Och ingenting annat. Men användare Y kan SELECT allt, men inga uppdateringar, medan användare Z har full CRUD-åtkomst (välj, infoga, uppdatera, radera).

Vissa databaser låter dig återanvända autentiseringsuppgifterna på OS-nivå. Detta gör autentiseringen för användaren transparent (behöver bara logga in på arbetsstationen, den identiteten vidarebefordras sedan till DB). Detta fungerar enklast i en full MS-stack (OS=Windows, Auth=ActiveDirectory, DB=MSSQL) men är - så vitt jag vet - även möjligt att uppnå i andra DB:er.

Proffs

• Ganska lätt att ställa in.
• Mycket atomärt auktoriseringsschema

Nackdelar

• Kan vara tråkigt att ställa in alla åtkomsträttigheter i DB.
• Användare med UPDATE och DELETE rättigheter kan fortfarande av misstag (eller avsiktligt?) radera/uppdatera utan kriterier. Du riskerar att förlora all data i en tabell.

Lagrade procedurer med atomic auth&auth

Skriv nej SQL-frågor i din applikation. Kör allt genom SPROC. Skapa sedan db-konton för varje användare och tilldela privilegier till SPROC:erna endast .

Proffs

• Den mest effektiva skyddsmekanismen.
• SPROC:er kan tvinga användare att skicka kriterier till varje fråga (inklusive DELETE och UPDATE )

Nackdelar

• inte säker på om detta fungerar med MySQL (min kunskap på det området är dålig).
• komplex utvecklingscykel:Allt du vill göra måste först definieras i en SPROC.

Sluta tankar

Du bör aldrig tillåta databasadministrativa uppgifter för programmet. För det mesta är de enda operationerna som ett program behöver SELECT , INSERT , DELETE och UPDATE . Om du följer denna riktlinje finns det knappast någon risk för att användare upptäcker lösenordet. Förutom punkterna som nämns ovan.

Behåll i alla fall säkerhetskopior. Jag antar att du vill projicera din databas mot oavsiktliga raderingar eller uppdateringar. Men det händer olyckor... tänk på det;)