Migliori pratiche per conservare le password negli script Shell/Perl?

Question

Recentemente ho dovuto rispolverare le mie capacità di scripting in Perl e Shell per aiutare alcuni colleghi.Ai colleghi in questione è stato assegnato il compito di fornire alcuni report da un'applicazione interna con un grande database Oracle backend e semplicemente non hanno le competenze per farlo.Anche se alcuni potrebbero chiedersi se anch'io possiedo queste capacità (sorride), a quanto pare un numero sufficiente di persone pensa che le possieda, il che significa che non posso tirarmene fuori.

Quindi, alla mia domanda: per estrarre i report dal database, il mio script deve ovviamente connettersi ed eseguire query.Finora non sono riuscito a trovare una buona soluzione su dove archiviare il nome utente e la password per il database, quindi è attualmente archiviato come testo normale nello script.

Esiste una buona soluzione per questo che qualcun altro ha già scritto, magari come modulo CPAN?Oppure c'è qualcos'altro che è meglio fare, come mantenere la combinazione utente/password in un file completamente separato nascosto da qualche altra parte nel filesystem?O dovrei mantenerli banalmente crittografati per evitare che vengano estratti dai miei script con un grep a livello di sistema?

Modificare:Il database Oracle si trova su un server HP-UX.
Il server delle applicazioni (che esegue gli script della shell) è Solaris.
Impostare gli script in modo che siano di proprietà solo di me è impossibile, devono essere di proprietà di un account di servizio a cui hanno accesso più membri del personale di supporto.
Gli script sono destinati ad essere eseguiti come processi cron.
Mi piacerebbe utilizzare l'autenticazione a chiave pubblica, ma non sono a conoscenza dei metodi per farlo funzionare con Oracle - se esiste un metodo del genere - illuminami!

Answer 1

La migliore pratica, IMHO, sarebbe quella di NON conservare alcuna password in uno script Shell/Perl.Ecco a cosa serve l'autenticazione con chiave pubblica.

Answer 2

Se lo script è in esecuzione in remoto dal server.

1. Rendi visibili i tuoi rapporti
2. Concedi all'utente a cui stai accedendo SOLO l'accesso per selezionare le visualizzazioni del report
3. Basta memorizzare la password.

In questo modo, tutto ciò che l'utente può fare è selezionare i dati per il suo report.Anche se qualcuno riuscisse a ottenere la password, sarebbe limitato su cosa potrebbe farne.

Answer 3

Personalmente conservo le password nei file di configurazione che vengono poi distribuiti indipendentemente dall'applicazione e possono essere modificati in base alla macchina/ambiente specifico.Negli script di shell puoi reperirli all'interno dello script principale.

Tuttavia, in Perl esistono diversi approcci.Potresti voler indagare Getopt::Lungo per le opzioni della riga di comando (e inoltre Getopt::ArgvFile per memorizzarli in un semplice file di configurazione), o guardare qualcosa di simile Configurazione::IniFiles per qualcosa con un po' più di potere alle spalle.Questi sono i due tipi che generalmente utilizzo, ma sono disponibili altri moduli di file di configurazione.

Answer 4

Non esiste una buona soluzione.Puoi offuscare un po' le password, ma non puoi proteggerle.

Se hai il controllo sulla configurazione del tuo DB, potresti provare a connetterti tramite una pipe denominata (almeno mysql lo supporta) senza password e lasciare che sia il sistema operativo a gestire le autorizzazioni.

Potresti anche memorizzare le credenziali in un file con autorizzazioni restrittive.

Answer 5

Dato che hai taggato ksh & bash, presumo Linux.

La maggior parte del problema è che se l'utente può leggere lo script e individuare il metodo utilizzato per nascondere/crittografare il file, sarà anche in grado di fare la stessa cosa manualmente.

Un modo migliore potrebbe essere quello di procedere come segue:

1. Crea il tuo script in modo che possa essere visto/letto/aperto solo da te.chmod 700 esso.Le password vengono codificate via.
2. Avere uno script "launcher" che sia eseguibile dall'utente e che esegua un comando sudo .

In questo modo l'utente può vedere il tuo script di avvio, esaminarlo per vedere che ha solo la singola riga di comando.Possono eseguirlo e funziona, ma non hanno le autorizzazioni per leggere l'origine dello script sudo.

Answer 6

Non sono sicuro della versione di Oracle in esecuzione.Sulla versione precedente di Oracle (precedente a 9i Advanced Security) alcuni DBA lo farebbero CREATE USER OPS$SCOTT IDENTIFIED BY EXTERNALLY e impostare REMOTE_OS_AUTHENT a vero.

Ciò significherebbe che la tua macchina Sun remota potrebbe autenticarti come SCOTT e quindi il tuo DB Oracle accetterebbe tale autenticazione.

Questa è una cattiva idea.

Come puoi immaginare, qualsiasi Windows XP con un utente locale di SCOTT potrebbe quindi accedere al tuo DB senza password.

Sfortunatamente è l'unica opzione che conosco dei DB Oracle 9i per non memorizzare nome utente/password nello script o altrove accessibile dal computer client.

Qualunque sia la tua soluzione, vale la pena dare un'occhiata a Oracle Blocco del progetto prima di impegnarsi.

Answer 7

Per memorizzare le password è possibile eseguire una routine di crittografia in due passaggi, prima con una chiave codificata nello script stesso e facoltativamente una seconda volta con una chiave memorizzata in un file (che viene impostata utilizzando le autorizzazioni del file per avere accesso limitato).

In una determinata situazione è quindi possibile utilizzare un file chiave (+ chiave dallo script) oppure, se i requisiti della situazione non sono eccezionali, è possibile semplicemente utilizzare la crittografia utilizzando la chiave codificata nello script.In entrambi i casi la password verrebbe crittografata nel file di configurazione.

Non esiste una soluzione perfetta perché in qualche modo devi essere in grado di decrittografare e ottenere la password in chiaro... e se puoi farlo anche qualcun altro può farlo se ha le informazioni giuste.

Soprattutto nella situazione in cui diamo loro uno script Perl (vs.un exe) possono facilmente vedere come esegui la crittografia (e la chiave codificata)... motivo per cui dovresti consentire l'opzione di utilizzare anche un file di chiavi (che può essere protetto dalle autorizzazioni del filesystem).

Alcuni esempi pratici su come implementarlo sono Qui

Answer 8

In UNIX, creo sempre questi script setuid e memorizzo le informazioni su utente e password in un file fortemente protetto (l'intero albero delle directory non è leggibile/ricercabile dagli utenti normali e il file stesso è leggibile solo dal proprietario dello script) .

Answer 9

Conservali in un file separato, banalmente crittografato e crea un utente separato nel database con accesso di sola lettura alle tabelle necessarie.Se ritieni che il file sia stato letto, puoi disattivare l'accesso solo a quell'utente.

Se vuoi essere fantasioso, un programma SUID potrebbe controllare /proc//exe e cmdline (in Linux) e solo allora rilasciare il nome utente.

Answer 10

Ho/ho avuto un problema simile con gli sviluppatori che distribuivano codice SQL su MSSQL (in effetti su qualsiasi database su quel server MSSQL, quindi il ruolo doveva essere SysAdmin) utilizzando ANT da un server Solaris.Ancora una volta non volevo memorizzare nome utente e password nei file ANT build.xml quindi la mia soluzione, che so non essere l'ideale, è la seguente:

1. Memorizza le coppie nome/valore per nome utente e password in un file di testo semplice
2. Crittografa il file (su Solaris) e utilizza una passphrase nota solo a determinati amministratori
3. Lasciare solo il file crittografato sul sistema Solaris
4. ANT build.xml esegue un sudo decrypt e richiede la passphrase, che viene inserita dall'amministratore
5. Le origini ANT hanno decrittografato il file caricando nome utente e password come variabili per la stringa SQL
6. ANT ha immediatamente eliminato il file di testo in chiaro
7. ANT distribuisce il codice ed esce

Tutto ciò avviene in pochi secondi e il nome utente e la password SQL non sono mai visibilmente accessibili sul server.Poiché il codice viene distribuito dagli amministratori autorizzati in produzione, gli sviluppatori non hanno mai bisogno di includerlo nel proprio codice.

Sono sicuro che potrebbe essere migliore, ma...

JB

Answer 11

E' un peccato non aver mai visto questo thread prima: sembra molto interessante.Aggiungerò i miei due centesimi per chiunque si imbatterà nel thread in futuro.

Consiglierei di utilizzare l'autenticazione del sistema operativo sul server database stesso: REMOTE_OS_AUTHENT è ancora FALSE.

Se stai richiamando lo script da un altro computer, imposta una chiave SSH senza frasi e utilizza SSH per arrivarci.È quindi possibile reindirizzare i risultati SQL alla macchina chiamante e quest'ultima può elaborare ulteriormente queste informazioni.

In questo modo si evita di dover codificare una password ovunque.Naturalmente, se un amministratore malintenzionato dovesse prendere il controllo della chiave senza frasi e utilizzarla, potrebbe anche accedere all'account utente sull'host DB e quindi eseguire qualsiasi operazione consentita dall'utente DB autenticato dal sistema operativo.Per mitigare questo problema potresti ridurre al minimo indispensabile le autorizzazioni del database per quell'utente del sistema operativo: diciamo "sola lettura".

Ingo

Answer 12

Su Windows creare una cartella e un file al suo interno contenente le password in chiaro.Imposta l'utente che eseguirà il lavoro pianificato (script o batch) come unica persona con accesso in lettura/scrittura a questa cartella e file.(rimuovere anche l'amministratore).A tutti gli altri script, aggiungi il codice per leggere la password in chiaro da questo file limitato.

Questo dovrebbe bastare a pochi.

Parole chiave:HardCoding della password

Answer 13

Esistono soluzioni commerciali o più avanzate come cyberark AIM può farlo meglio, ma facendolo gratuitamente e immediatamente, sono stato sulle spalle la chiave pubblica/privata SSH perché, per prima cosa, le coppie di chiavi SSH molto probabilmente sono già state create conformi al politica di sicurezza;in secondo luogo, le coppie di chiavi SSH dispongono già di una serie di protocolli standard per proteggere le chiavi tramite l'autorizzazione del file, il rafforzamento continuo del sistema (come tripwire) o la rotazione della chiave.

Ecco come l'ho fatto:

1. Se non ancora, genera le coppie di chiavi ssh.Le coppie di chiavi e la directory saranno protette dal protocollo/permesso di sistema predefinito.ssh-keygen –t rsa –b 2048

2. Usa la chiave pubblica SSH per crittografare la stringa e memorizzata nella stessa directory .SSH $ Echo "Secretword" | OpenSSL RSAUTL -Crypt -Inkey ~/.SSH/ID_RSA.PUB -Pubin -out ~/.SSH/secret.dat

3. utilizzare la chiave privata ssh per decrittografare la chiave e passare i parametri agli script/AP in tempo reale.Lo script/programma per includere la riga da decrittografare in tempo reale:stringa=openssl rsautl -decrypt -inkey ~/.ssh/id_rsa -in ~/.ssh/secret.dat

PS: ho sperimentato la soluzione agentless CYBERARK AIM.è una specie di problema che richiede modifiche significative/modifiche API per l'API/script.ti terrò informato su come andrà.