Come posso evitare che il mio database venga compromesso se la mia app CakePHP è compromessa?

Question

Come posso evitare che il mio database venga compromesso se la mia app CakePHP è compromessa?

#1 da (3 voti)
#2 da (1 voti)
#3 da (0 voti)

2

Ho un app server che ospita un'applicazione CakePHP e un server di database che ospita i database. I server sono fisicamente separati. I database contengono informazioni sensibili crittografate. Le chiavi di crittografia per i dati crittografati sono anche memorizzate nel database (che sono a loro volta crittografate). Le chiavi vengono decodificate dall'app per l'uso nella decrittografia delle informazioni del database.

Ho l'impressione che se qualcuno dovesse compromettere il server del database e rubare i database non sarebbe in grado di decodificare i dati poiché l'app (che si trova su un server diverso) ha la chiave di crittografia. Il problema si verifica se qualcuno è in grado di compromettere il server dell'app. Se il server dell'app viene compromesso, le informazioni sulla connessione al database vengono memorizzate direttamente nell'app CakePHP come segue:

public $default = array(

  'datasource' => 'Database/Mysql',
  'persistent' => false,
  'host' => 'xxx.xxx.xxx.xxx',
  'login' => 'login',
  'password' => 'password',
  'database' => 'database',
  'prefix' => '',
  //'encoding' => 'utf8',

);

C'è un modo per archiviare queste informazioni di connessione in modo più sicuro o è solo questione di sapere che se l'app è compromessa, anche il database è compromesso? Ci sono cose che posso fare per mitigare le possibilità di questo tipo di compromesso a cui potrei non aver pensato? Grazie in anticipo!

web-application databases

posta JadedCore 05.02.2014 - 20:38

fonte

3 risposte

1

Utilizza le variabili ambientali. È possibile memorizzare le credenziali del database come variabili ambientali nel server, ad esempio nella configurazione di apache o nginx per l'applicazione. In tal caso, se il tuo codice è compromesso, l'autore dell'attacco dovrebbe anche violare i file di configurazione del server web che è un altro livello di sicurezza. Ci sono plugin per fare questo lavoro in CakePHP, per esempio dare un'occhiata a questo modello di applicazione:

link

Nell'esempio si consiglia di impostare le variabili env all'interno di un file, ma io consiglio di farlo direttamente sul server web.

risposta data 05.02.2014 - 23:22

fonte

0

In questo caso è meglio usare le variabili d'ambiente. Li uso tutto il tempo nello sviluppo di Django. Con le autorizzazioni corrette impostate sul server stesso, è possibile attenuare un compromesso diretto del database.

link

risposta data 05.02.2014 - 23:24

fonte

Leggi altre domande sui tag web-application databases

Supporto di lettura-scrittura contemporaneamente al volume TrueCrypt nascosto + normale? Quali opzioni sono disponibili per l'implementazione di DLP? [chiuso]

score 3 · Accepted Answer

Se l'applicazione è compromessa, il database viene compromesso anche se è possibile nascondere le credenziali. Le credenziali del DB dovrebbero essere valide solo dall'indirizzo IP del server dell'applicazione e se hanno compromesso il server delle applicazioni, possono semplicemente modificare il codice dell'applicazione per fare quello che vogliono se in qualche modo si è riusciti a proteggere le credenziali.

La cosa fondamentale è assicurarsi che le credenziali funzionino solo dal server e che l'utente che l'applicazione utilizza possa avere un impatto sull'applicazione stessa solo nei modi in cui l'applicazione deve interagire con il DB.

In realtà, è molto difficile nascondere le credenziali in ogni caso. È possibile utilizzare qualcosa come un TPM, ma l'applicazione richiede un modo per accedere al TPM. A meno che tu non dia l'autorizzazione dell'applicazione senza che l'utente fornisca le credenziali per il DB stesso, allora devi memorizzarle.

A seconda di come si accede ai dati sensibili, si può anche essere in grado di utilizzare la crittografia basata sull'utente. Con la crittografia basata sull'utente, si utilizza la password dell'utente per derivare una chiave che viene utilizzata per crittografare una chiave sicura. Tale chiave sicura viene quindi utilizzata per sbloccare un portachiavi che contiene le chiavi per accedere a qualsiasi record a cui l'utente ha accesso. Poiché il keyring dell'utente è accessibile solo quando l'utente ha effettuato l'accesso, riduce la minaccia di un compromesso non in linea in cui sia il server applicazioni che il server DB sono compromessi.

Questo pone dei limiti a ciò che può essere fatto mentre l'utente non ha effettuato l'accesso, sebbene sia possibile avere un sproc che abbia accesso a fare alcune operazioni di decrittografia usando un key key master che è disponibile solo nel server DB, ma dovresti stare molto attento a bloccare quelle funzionalità per impedirne l'abuso. (Valutare i limiti su sproc personalizzati per ogni tipo di query necessaria per i dati protetti, ad esempio.)