Come posso nascondere una password negli script della shell? Esistono numerosi script che accedono al database. Se apriamo lo script anche altri conoscono il nome utente e la password. Quindi, se qualcuno sa come nascondersi, per favore me lo faccia sapere.
Ho un modo:inserire la password in un file e rendere il file nascosto e nessuno accederà al file (modifica i permessi e usa il file nello script mentre accedi al database).
Risposta accettata:
Prima , come hanno già detto diverse persone, è essenziale mantenere le credenziali separate dallo script. (Oltre a una maggiore sicurezza, significa anche che puoi riutilizzare lo stesso script per più sistemi con credenziali diverse.)
Secondo , dovresti considerare non solo la sicurezza delle credenziali, ma anche l'impatto se/quando tali credenziali vengono compromesse. Non dovresti avere una sola password per tutti gli accessi al database, dovresti avere credenziali diverse con diversi livelli di accesso. Ad esempio, potresti avere un utente DB che ha la capacità di eseguire una ricerca nel database:quell'utente dovrebbe avere accesso di sola lettura. Un altro utente potrebbe avere l'autorizzazione per inserire nuovi record, ma non per eliminarli. Un terzo potrebbe avere l'autorizzazione per eliminare i record.
Oltre a limitare le autorizzazioni per ciascun account, dovresti anche avere restrizioni su dove ciascun account può essere utilizzato. Ad esempio, l'account utilizzato dal tuo server web non dovrebbe essere autorizzato a connettersi da un indirizzo IP diverso da quello del server web. Un account con permessi di root completi per il database dovrebbe essere davvero molto limitato in termini di dove può connettersi e non dovrebbe mai essere usato se non in modo interattivo. Inoltre, considera l'utilizzo di stored procedure nel database per limitare esattamente ciò che può essere fatto da ciascun account.
Queste restrizioni devono essere implementate sul lato server DB del sistema in modo che, anche se il lato client è compromesso, le restrizioni non possono essere modificate da esso. (E, ovviamente, il server DB deve essere protetto con firewall ecc. oltre alla configurazione del DB…)
Nel caso di un account DB a cui è consentito solo un accesso limitato in sola lettura e solo da un particolare indirizzo IP, potrebbero non essere necessarie ulteriori credenziali, a seconda della sensibilità dei dati e della sicurezza dell'host lo script viene eseguito da. Un esempio potrebbe essere un modulo di ricerca sul tuo sito web, che può essere eseguito con un utente che può utilizzare solo una procedura memorizzata che estrae solo le informazioni che verranno presentate nella pagina web. In questo caso, l'aggiunta di una password non conferisce alcuna sicurezza aggiuntiva, poiché tali informazioni sono già destinate a essere pubbliche e l'utente non può accedere a nessun altro dato che sarebbe più sensibile.
Inoltre, assicurati che la connessione al database venga effettuata tramite TLS, altrimenti chiunque sia in ascolto sulla rete possa ottenere le tue credenziali.
Terzo , considera il tipo di credenziali da utilizzare. Le password sono solo una forma e non la più sicura. Potresti invece usare una qualche forma di coppia di chiavi pubblica/privata, o AD/PAM o simili.
Quarto , considera le condizioni in cui verrà eseguito lo script:
Correlati:codice sorgente di netstat?Se viene eseguito in modo interattivo, quando lo esegui dovresti inserire la password, o la password per la chiave privata, o la chiave privata, o essere loggato con un ticket Kerberos valido, in altre parole, lo script dovrebbe ottenere il suo credenziali direttamente da te nel momento in cui lo esegui, invece di leggerle da qualche file.
Se viene eseguito da un server web, prendere in considerazione l'impostazione delle credenziali al momento dell'avvio del server web. Un buon esempio qui sono i certificati SSL:hanno un certificato pubblico e una chiave privata e la chiave privata ha una password. Puoi memorizzare la chiave privata sul server web, ma devi comunque inserire la password quando avvii Apache. Potresti anche avere le credenziali su qualche tipo di hardware, come una scheda fisica o un HSM, che può essere rimosso o bloccato una volta avviato il server. (Ovviamente, lo svantaggio di questo metodo è che il server non può riavviarsi da solo se succede qualcosa. Preferirei questo al rischio che il mio sistema venga compromesso, ma il tuo chilometraggio potrebbe variare...)
Se lo script viene eseguito da cron, questa è la parte difficile. Non vuoi che le credenziali siano in giro per il tuo sistema in cui qualcuno può accedervi, ma vuoi che siano in giro in modo che il tuo script possa accedervi, giusto? Beh, non del tutto giusto. Considera esattamente cosa sta facendo lo script. Di quali autorizzazioni ha bisogno sul database? Può essere limitato in modo che non importi se la persona sbagliata si connette con tali autorizzazioni? Puoi invece eseguire lo script direttamente sul server DB a cui nessun altro ha accesso, invece che dal server che ha altri utenti? Se, per qualche motivo a cui non riesco a pensare, devi assolutamente devi avere lo script in esecuzione su un server non sicuro e deve essere in grado di fare qualcosa di pericoloso/distruttivo... ora è un buon momento per ripensare la tua architettura.
Quinto , se apprezzi la sicurezza del tuo database, non dovresti eseguire questi script su server a cui altre persone hanno accesso. Se qualcuno ha effettuato l'accesso al tuo sistema, lo farà avere la possibilità di ottenere le proprie credenziali. Ad esempio, nel caso di un server web con certificato SSL, esiste almeno una possibilità teorica che qualcuno possa ottenere il root e accedere all'area di memoria del processo httpd ed estrarre le credenziali. C'è stato almeno un exploit negli ultimi tempi in cui ciò potrebbe essere fatto su SSL, senza nemmeno richiedere l'accesso all'attaccante.
Inoltre, considera l'utilizzo di SELinux o AppArmor o qualsiasi altra cosa disponibile per il tuo sistema per limitare quali utenti possono fare cosa. Ti permetteranno di impedire agli utenti anche di provare a connettersi al database, anche se riescono ad accedere alle credenziali.
Se tutto questo ti sembra eccessivo , e non puoi permetterti o non hai il tempo per farlo – quindi, secondo la mia opinione (arrogante ed elitaria), non dovresti archiviare nulla di importante o sensibile nel tuo database. E se non stai archiviando nulla di importante o sensibile, anche il luogo in cui memorizzi le tue credenziali non è importante:in tal caso, perché usare una password?
Correlati:generare quattro parole casuali da un elenco per password simili a XKCD?Infine , se non puoi assolutamente evitare di memorizzare un qualche tipo di credenziali, potresti avere le credenziali di sola lettura e il possesso di root e root potrebbe concedere la proprietà su base estremamente temporanea quando richiesto da uno script (perché il tuo script dovrebbe non essere eseguito come root a meno che non sia assolutamente necessario e la connessione a un database non lo rende necessario). Ma non è ancora una buona idea.