Password DB: più sicuro nei file di configurazione .ini di PHP o nelle variabili di ambiente di apache2?

Sono completamente d'accordo con la tua opinione che non è una buona idea avere phpinfo () scaricare le password del tuo DB. Un file ini sembra essere un po 'migliore, l'applicazione può recuperare le password quando necessario. Con gli attuali framework come Symfony questa è la strada da percorrere. Se si limita l'accesso alle macchine di produzione agli amministratori incaricati, si dispone di una cerchia limitata di persone che possono accedere ai file di configurazione. Ovviamente i file ini non dovrebbero essere memorizzati in un repository pubblico. Lo svantaggio è che l'applicazione stessa, l'utente del server web deve avere accesso al file e quindi qualsiasi script PHP può leggerlo e scaricarlo.

Ciò solleva la questione se sei disposto a compiere enormi sforzi per migliorare la sicurezza.

Nel mondo Java EE puoi applicare il seguente concetto. Si distribuisce un'applicazione enterprise su un server di applicazioni come GlassFish o JBoss. Nella configurazione JDBC concreta si imposta un segnaposto per la password. La password effettiva può essere memorizzata in un file di password crittografato per il quale l'amministratore deve immettere una password all'avvio del server. Naturalmente questo impedisce un avvio del server completamente automatico. Personalmente non posso assicurarti che questo è al 100% a prova di proiettile, ma rende più difficile per un aggressore.

Un'altra possibilità è quella di "esternalizzare" le tue password. È possibile utilizzare un servizio di password (google per "Cyber-Ark", penso che abbiano un API / SDK per connettere le proprie applicazioni al proprio deposito di password) che memorizza le password e controlla l'accesso. Ogni volta che l'applicazione richiede una password, deve essere recuperata dal servizio. Ovviamente, chiunque abbia accesso all'API e i dati di accesso al servizio di password potrebbero richiedere anche le password. Ma con un servizio separato hai almeno la possibilità di accedere al log per avere a disposizione un audit trail. Separazione dei compiti: se il servizio di password ha un altro amministratore, diventa difficile per una persona fare cose che non sono permesse, o almeno c'è la possibilità di tenere traccia di queste cose.

Se utilizzi php-fpm puoi impostare le variabili di ambiente per ciascun pool nel file di configurazione del pool . Questo è perfetto per alcuni motivi.

1. I file di configurazione del pool php-fpm dovrebbero essere rw-r----- e di proprietà di root:root . Pertanto, l'utente php-fpm non dovrebbe essere in grado di leggerli (si noti che il daemon genitore php-fpm può essere generato come root e quindi fork dei figli) .

2. Questi file di configurazione del pool php-fpm non possono essere scambiati accidentalmente con il codice sorgente dell'applicazione su GitHub o simili.

Ecco un esempio:

# in the php-fpm pool configuration file
env[MYSQL_PASSWORD] = somecrazylongpasswordhere

Pur avendo a che fare con i file delle password, dobbiamo vedere che solo quegli utenti possono accedere ai dettagli della password che devono "saperlo". Nel tuo caso, le persone che hanno accesso all'albero del codice, ovvero il file .ini, devono conoscere i dettagli del DB e le password perché potrebbero non avere accesso alla sezione dell'ambiente. Se hanno accesso all'albero del codice e all'ambiente, penso che tu abbia ragione e puoi lasciare quei dettagli nel file .ini ma assicurati che sia al di fuori della directory webcontent.

In questo momento posso solo pensare a questo.

Tutti - Sentiti libero di correggermi o aggiungere qualsiasi cosa mi sia sfuggita.