Come evitare script con password hardcoded? [duplicare]

Puoi creare chiave pubblica / privata coppie e crittografare la password. Questo dovrebbe offuscare la password dei passanti casuali, in quanto avrebbero solo la parte pubblica della chiave a loro nota.

Devi anche proteggere lo script usando le autorizzazioni di directory e file.

Inoltre, (a seconda del database) dovresti essere in grado di creare un account utente per il database che ha solo i privilegi di backup. Ciò impedirebbe a qualcuno di creare tabelle, scaricare tabelle e sostituire i contenuti. Puoi limitare l'accesso a questo utente ai tempi previsti per l'esecuzione dei backup.

Aggiorna

Questo post su Comodo in realtà spiega i tasti un po 'meglio . Dato che sei preoccupato per qualcuno che ha accesso alla password originale che esiste nel codice, l'utente malintenzionato dovrebbe ascoltare la chiave privata dell'utente che attiva lo script (che potrebbe accadere tramite SSH su un cron su un separato [virtuale] macchina). Ovviamente non ci sarebbe alcun motivo se stessimo memorizzando entrambe le chiavi sullo stesso sistema a meno che ovviamente non stiate memorizzando la chiave privata con privilegi più elevati rispetto alla chiave pubblica.

Entrambe le chiavi insieme = password

Informazioni sulle autorizzazioni, se qualcuno ha accesso al tuo sistema ed è questo il motivo per cui una password deve essere memorizzata sulla scatola in un "formato leggibile" sembra che ci siano problemi più profondi con la configurazione delle autorizzazioni sul scatola stessa. Inoltre, se qualcuno può sudo e superare i propri privilegi (come l'host che esegue la casella), l'hashing della chiave è in realtà l'unica opzione per impedire all'utente di accedere al database.

Inoltre, dovresti disabilitare l'account root sul database poiché ciò consentirebbe all'utente malintenzionato di leggere comunque le tabelle del database.

Come menzionato in altre risposte, le tue credenziali saranno da qualche parte accessibili al tuo script.

Ma li metterei è un file di configurazione separato che verrà letto dal tuo script.

Avrai i seguenti vantaggi:

• puoi usare lo stesso script per diversi sistemi (con diversi file di configurazione)
• sarai in grado di condividere lo script con altri (o mostrarlo a qualcuno senza compromettere le tue credenziali)

Considerando la natura automatizzata dello script, non penso che esista un modo migliore per archiviare la password oltre a codificarla.

La mia raccomandazione sarebbe bloccare lo script con le autorizzazioni del filesystem unix appropriate. Rendere lo script -rwx------ e impostare il proprietario e il gruppo su valori appropriati farà molto per garantire la password.

Naturalmente, sono disponibili misure di registrazione adeguate per rilevare se lo script è stato compromesso. In tal caso, modificare immediatamente la password sul server di database.

Mi piace la risposta di @ absolute sulla crittografia dei cred con una coppia di chiavi, aggiungerò anche che per le soluzioni basate su Windows, ho usato C # al posto di uno script di PowerShell a volte; dal momento che entrambi sono basati su .NET, posso semplicemente compilare la mia soluzione e lanciare i crediti lì.

Quindi, forse puoi creare un eseguibile compilato che chiama lo script e passa le credenziali come parametro, o anche una copia crittografata delle credenziali come parametro che il tuo script può decodificare.

Sì , sono consapevole che i crediti possono ancora essere strappati dall'exe in determinate circostanze, ma questo è specifico per Situazione OP di evitare credenziali di testo chiaro.

Forse stai facendo la domanda sbagliata. Sebbene sia giusto preoccuparsi degli script con credenziali di autenticazione codificate, la vera questione è come gestire le credenziali di autenticazione utilizzate dagli script automatici e, cosa più importante, quali sono le minacce oi rischi più elevati associati al sistema. Sistemi diversi hanno rischi diversi. Devi capire i rischi più rilevanti per la tua situazione per valutare quali azioni sono più adatte. In generale

• Non credenziali di autenticazione con codifica rigida. Inseriscili in un file / percorso separato e chiedi al tuo script di utilizzare le informazioni. Questo ha il vantaggio di semplificare la modifica delle password in quanto non è necessario modificare le origini e si può fare in modo che più script utilizzino la stessa fonte, consentendo di modificare le password in un'unica posizione.

• Scopri le autorizzazioni, gli usi e i gruppi. Utilizzare le strutture disponibili per limitare l'accesso.

• Usa le funzioni di hardening aggiuntive del tuo sistema operativo. Ad esempio, Linux usa SELinux o AppArmor (penso che Ubuntu sia basato su apparmor). Definire politiche appropriate per limitare l'accesso solo a ciò che è assolutamente necessario.

• Comprendi e utilizza gli strumenti disponibili: ssh, sudo, chroot, ecc.

Conoscendo e capendo dove sono le tue minacce determinerai quali tecniche e strutture sono le più adatte e se le strutture predefinite sono sufficienti o se è necessario modificare le cose e installare precauzioni aggiuntive. non trascurare l'importanza dell'auditing e dell'analisi dei log. Una cosa è mettere la protezione sul posto. È un altro sapere quando la tua protezione è fallita e sei stato compromesso. Potrebbe essere un male avere il tuo sistema compromesso, ma è molto peggio per essere compromesso e non saperlo.

Se si sta utilizzando ssh per accedere al server database, è possibile impostare ~ / .ssh / authorized_keys sul server database per includere ~ / .ssh / id_dsa.pub o ~ / .ssh / id_rsa .pub file sul tuo sistema ubuntu. Sarai in grado di accedere senza password.

Se non hai un file in ~ / .ssh / id_dsa.pub guarda come crearne uno con ssh-keygen