Crittografia dell'infrastruttura di sistema

0

I requisiti sono di crittografare i dati nei nostri server "a riposo" e il "database", in breve l'intera infrastruttura.

Modello di minaccia - per proteggere una possibile violazione dei dati da parte di un avversario (o da un'entità non autorizzata), dal furto fisico (o per lo smaltimento sicuro) e per la duplicazione sicura (per backup sicuri).

Problema - Siamo un "SaaS" e si occupa di tonnellate di utenti che richiedono i dati avanti e indietro (dai nostri server) - pertanto, i dati che pianifichiamo di crittografare dovrebbero rimanere altamente accessibili (utente file, messaggi ecc.) e crittografati allo stesso tempo - senza avere uno schema Keys pubblico / privato dal lato utente , che stabilisce la seguente nozione.

  • I dati dovrebbero essere crittografati non appena entrano nel server (utilizzando qualsiasi meccanismo di crittografia simmetrica) e rimangono disponibili per gli utenti quando lo chiedono | Un po 'di ricerca ha mostrato meccanismi di crittografia dell'intero disco (ad esempio LUKS, lib-crypt o PGP) che non sono sicuro faranno il lavoro o meno.

  • Se la crittografia dell'intero disco è la risposta alla nostra ricerca, il secondo problema è avere la chiave di crittografia (disponibile sullo stesso server) che non affronterà il nostro modello di minaccia (come per un utente malintenzionato che ha ottenuto il server l'accesso non richiederà molto tempo per ottenere anche la chiave di crittografia). In secondo luogo, richiederà che qualcuno inserisca fisicamente la password (crittografica) su ogni riavvio del server (cosa non possibile, poiché la maggior parte del nostro team lavora in remoto e preferisce l'automazione).

Preoccupazione precisa: quale schema di crittografia farà il lavoro in modo efficiente restando (robustamente) disponibile mentre copre il citato modello di minaccia - e quale sarà l'architettura di sistema preferita per gestire efficacemente tali operazioni?

L'obiettivo è proteggere i dati che vengono archiviati dalla nostra parte in ogni modo possibile senza compromettere le prestazioni generali.

Apprezzerò molto la tua illuminazione in questo senso.

    
posta MSalman 05.01.2016 - 18:27
fonte

1 risposta

3

Sono lo specialista della sicurezza presso una società SaaS e stavamo esaminando lo stesso identico problema lo scorso anno.

Il problema principale in cui ti imbatterai è il costo. Se vuoi che il tuo database sia prontamente disponibile, ma criptato "a riposo", in pratica hai bisogno di un mostro di un server che non faccia altro che gestire il processo di crittografia / decrittografia. Come decodificare i dati che hai bisogno di leggere ti darà un problema di prestazioni, anche con una bestia di una scatola, avrai ancora almeno 1 o 2 millisecondi di ritardo aggiunti alle tue query.

Abbiamo esaminato ProtectDB di SafeNet, ma poiché attualmente non stiamo adottando una conformità PCI o HIPPA, abbiamo ritenuto che il costo dell'investimento di ~ $ 50k + non valesse il beneficio limitato.

EDIT: ProtectDB è fondamentalmente un server separato che contiene tutte le chiavi di crittografia e fa una scansione del tuo database per vedere dove sono i dati. Quando si esegue una query Database, la casella ProtectDB riceve invece il traffico e crea una connessione crittografata al database, decrittografa la colonna / tabella e restituisce i dati. Così facendo in modo che i tuoi sviluppatori / utenti non si colleghino più direttamente al database, invece ti stai connettendo alla casella ProtectDB.

In realtà, hai solo due vantaggi: impedire a qualcuno di entrare nel tuo centro dati / sito DR e rubare la scatola fisica, e questo è ciò che le guardie di sicurezza e i blocchi fisici sono lì per prevenire. Oppure, se ottieni una grave violazione della rete esterna e qualcuno riesce a ottenere il tuo database. In entrambi i casi, stai solo aggiungendo del tempo al tempo necessario per interrompere comunque.

Raccomando sinceramente di investire quei soldi in un WAF (se non ne hai già uno), come invece Incapsula.

    
risposta data 05.01.2016 - 22:52
fonte