Nella maggior parte delle applicazioni web che si occupano di un database, è necessario inserire i crediti DB in un file di configurazione o configurazione, come DATABASES variabile in settings.py in Django . Qual è la prassi generale per garantire i crediti in modo tale che solo pochi selezionati nel team conoscono i crediti e anche se non sono in grado di connettersi al DB con gli stessi cred (anche dalla stessa macchina su cui viene eseguita l'applicazione)?
Ottieni il database per interfacciarlo direttamente con il sistema di autenticazione dei server. cioè MSSQL può usare l'utente windows il processo viene eseguito come l'utente di accesso db
Inserisci le impostazioni del db di produzione nel sistema di distribuzione. quindi solo il team ops ha accesso.
Cripta le impostazioni e inserisci la chiave di decrittografia nella casella di produzione.
Ma se vuoi davvero essere sicuro, devi essere disciplinato.
Informa gli sviluppatori che non sono autorizzati a conoscere le password e che, se le individuano, devono segnalarle in modo che possano essere modificate.
Controlla i registri di autenticazione e assicurati che gli utenti del servizio stiano semplicemente effettuando l'accesso da caselle di servizio.
Dare agli utenti un nome utente / password che possono essere attivati e utilizzati in modo corretto quando è necessario un intervento manuale. Non costringerli a infrangere le regole per far funzionare le cose.
Questo non è generalmente possibile. Poiché il codice scritto dagli sviluppatori deve essere in grado di eseguire azioni sul database per conto degli utenti, gli sviluppatori necessitano indirettamente di un accesso completo al database. Devi fidarti dei tuoi sviluppatori e amministratori che usano il loro accesso privilegiato in modo responsabile.
Per i sistemi molto sensibili, ci sono alcune pratiche di sicurezza che puoi implementare:
L'amministrazione dei sistemi di produzione e l'implementazione in produzione sono limitate dalla regola di due uomini : per accedere al sistema, è necessario che due persone autorizzate si colleghino insieme. Tuttavia, l'implementazione di questo può essere non banale.
La tua applicazione è scomposta in servizi separati che possono essere eseguiti in contesti isolati, ad es. contenitori separati. Le credenziali sensibili sono vincolate a un singolo servizio. Mentre i microservizi sono popolari, tendono anche a rendere il tuo sistema molto più complicato. Tieni presente che gli amministratori e chiunque possa decidere quale versione di un servizio viene distribuita avranno comunque accesso completo a tutti i contenitori.
Per una singola squadra, entrambi questi approcci sembrano sproporzionatamente costosi.
Le credenziali sono una questione di fiducia. Se non ti fidi dei tuoi sviluppatori per una ragione qualsiasi, tienili alla larga dalle macchine corrispondenti. Se questa è una buona idea non è l'argomento di questo post.
Non c'è bisogno di credenziali di produzione di hard code in un file django settings.py .
1) Una possibile soluzione è avere un global_settings.py dove puoi canonicamente definire i valori predefiniti per tutto. E gli sviluppatori usano il loro settings.py personalizzato che ha un'importazione globale di queste impostazioni e sovrascrive queste impostazioni predefinite con le credenziali degli sviluppatori sulle loro macchine.
global_settings.py è controllato dalla versione mentre settings.py non lo è. Per semplificarti la vita, potresti fornire un settings.py.example per fare saggi suggerimenti sulla configurazione predefinita. Il global_settings.py potrebbe contenere solo SQLite -Supporto, dove come settings.py.example potresti fornire una possibile configurazione per Postgres senza credenziali.
Lo stesso vale per gli OP, che a loro volta hanno il proprio settings.py per la produzione.
2) Un'altra possibilità sarebbe usare environment variables dove sono definite le credenziali.
3) Esistono sistemi più complessi come Hashicorps Vault .
Il modo in cui scegli dipende da te.
Leggi altre domande sui tag design-patterns security web-applications code-security