Quanto è sicuro un database PostgreSQL se il mio server è stato rubato?

Question

Se ho un server con un database dei dati top secret in PostgreSQL e la mia password è praticamente impossibile da indovinare (128 stringa di caratteri di tutti i tipi di caratteri strani, generato a mano). La password del server è anche praticamente inimmaginabile.

A parte una password indovinare, come è facile per ottenere i dati da questo database?

Ipotesi:

1. Solo il DB esiste sul server. Non v'è alcuna password in uno script PHP o qualcosa di simile
2. La persona che ha rubato il server è un / DB / hard-drive esperto di recupero server
3. non sto usando alcuna crittografia del disco rigido o qualcosa fuori dalla norma per la protezione
4. sto usando Ubuntu Hardy (ultima versione stabile)

Sto cercando di comprendere i rischi connessi con qualcuno l'accesso fisico ai dischi rigidi del mio server.

Answer 1

"Il pensiero standard è quando qualcuno si siede sul server, è compromessa, fine della storia. Le cose solo peggiorare se si afferrano il disco rigido e portarla ad un laboratorio per l'apertura e l'analisi."

Idem.

Una volta che l'attaccante ha accesso fisico permanente (vale a dire, ha camminato fuori del palazzo con il vostro disco rigido nella sua valigetta), la maschera è up - presumono che nel tempo verranno compromessi i dati. Da lì, lo scenario è il costo del ritardo rispetto tattica la capacità di rallentare l'attaccante.

E 'un po' diverso se l'attaccante è un insider, o ha avuto accesso solo temporanea. In questi casi, si potrebbe essere in grado di rallentare lui abbastanza, o forza la responsabilità in modo tale che l'attacco diventa fattibile verso il basso.

la crittografia del disco rigido è una manovra dilatoria - che vi darà una protezione che corrisponde la forza dell'algoritmo, la forza della chiave, e la forza del accesso di blocco password per la chiave (o la possibilità di inserire l'hardware con la chiave memorizzata separatamente ). Anche con la crittografia l'ipotesi è che si tratta di una manovra dilatoria. Prima o poi, l'attaccante otterrà attraverso lo spazio chiave e capire cosa chiave decifra il sistema.

manomissioni è un'altra opzione - trovare un modo per cancellare elettronicamente il disco rigido in certe condizioni (come rimuovere fisicamente dalla custodia).

La figura che una volta che l'accesso fisico è concesso, l'utente malintenzionato può aggirare le password - per quanto forte sono - senza ricorrere alla forza bruta. Il primo che viene in mente sta usando il "Correggere la password" tecniche che la maggior parte dei sistemi hanno costruito per gli amministratori di aiuto sys che sono bloccati fuori e password perdute.

Ogni e tutte le protezioni sono dotati di un prezzo - manomissioni è costoso, in quanto è necessario hardware di specialità. La crittografia può essere più conveniente, ma colpisce il tempo di avvio. Inoltre, ho visto alcune sorprese con quanto la crittografia gioca con le applicazioni -. Non sai mai fino a quando si tenta di utilizzarlo

Answer 2

Il pensiero standard è quando qualcuno si siede sul server, è compromessa, fine della storia. Le cose peggiorano solo se si afferrano il disco rigido e portarla ad un laboratorio per l'apertura e l'analisi.

Vorrei iniziare con la crittografia tutta-drive, così come la crittografia per-campo nel database. Si potrebbe guardarsi intorno per vedere se c'è un modo per avere un accesso biometrico-based per l'hardware del disco rigido installato sul server. Inoltre, si vuole scavare un imprenditore sicurezza fisica e ottenere le loro raccomandazioni per la configurazione; assumere anche guardie.

Voglio dire, se questo è uno scenario che potrebbe ragionevolmente accadere ...

modifica:

Se ho avuto un file Postgres DB volevo entrare e ho avuto le risorse (ad esempio, la spesa per alcune 4K Dells a buon mercato), vorrei utilizzare una configurazione Beowulf e di eseguire in parallelo forza bruta di cracking. Le cose peggiorano se inizio ad avere più soldi e possono configurare, per esempio, molti di questi dolci macchine NVidia supercomputer-on-desktop collegato a davvero iniziare bruta forzando una password.

Se il ladro è seriamente intenzionata a entrare in esso e non avere la sicurezza già previsto dal Giorno 0, il file di DB sta per essere aperto come una scatola di sardine.

Answer 3

Se non sei cifrare il disco / file system duro, sei praticamente fuori di fortuna, come Postgres non offre crittografia nativa. E la crittografia del disco rigido è l'unico vero metodo di protezione per un server rubato.

In sostanza, quello che si avrebbe bisogno di fare è crittografare il disco rigido o file system, e si dovrebbe inserire la password quando si monta l'unità, a mano, ogni volta che la macchina si avvia, prima di Postgres spara alto.

Answer 4

In questo articolo sembra essere particolarmente rilevante per la tua domanda:

la sicurezza totale in un database PostgreSQL
http://www.ibm.com/developerworks/opensource/library/os -postgresecurity /

Answer 5

Non credo che questo sia un problema di PostgreSQL, o di qualsiasi altro indirizzo di database. Anche se il database la sua auto è protetto da password tutti i dati sono in testo normale e questo è ciò che conta davvero. Nulla è fermare l'attaccante dal cat'ing file di database crudo e tubazioni, però stringhe. La soluzione migliore per questo tipo di attacco è quello di utilizzare un file system crittografato. Ciò richiederebbe di digitare una password per montare la partizione. Questo aumenta anche sovraccarico.

Answer 6

Per la specifica domanda ha registrato (e quello che ho venuto alla ricerca di una risposta a), PostgreSQL per memorizza i dati della tabella di default in chiaro. Guardandosi intorno nei file in ... / pgsql / 9.2 / dati / base / * Direi che queste tabelle di negozi in 1.1 pezzi gigabyte, e posso trovare con successo stringhe ASCII in questi file con grep. Dalla consultazione dei fascicoli sembra che i dati sono memorizzati in colonne.

Da queste informazioni credo che avrei potuto sperimentare e scrivere il codice di decodificare le tabelle per creare una copia sul server, che non ho la password per.

Quindi basandosi su una password di database forte da sola non soddisfa il vostro dovere di cura, se è necessario per proteggere contro il rischio dei supporti fisici vengono rubati.

PostgreSQL in linea docs fornire alcune opzioni per la crittografia dei dati a vari livelli, che per questo problema sembrano essere limitato a un modulo per la crittografia colonne specifiche o la crittografia dei supporti sottostanti, in qualche modo come gli altri intervistati hanno suggerito.

Answer 7

Un buon inizio è quello di abilitare la crittografia completa del disco. È inoltre possibile crittografare a livello di applicazione. (I dati per esempio cifrare prima di inviarlo al database, memorizzare la chiave non è accessibile dal server di database)