Come fornire in modo sicuro i dati a un server Web utilizzando un data warehouse?

Naviga le tue risposte
2

Abbiamo un data warehouse che memorizza i prezzi per i nostri prodotti. Una volta ogni giorno lavorativo, vengono aggiunti nuovi punti dati che rappresentano il prezzo giornaliero per ciascun prodotto. Sul sito web, un utente vede queste informazioni su una pagina caricata. Ci sono attualmente 7 prodotti; l'analisi mostra che la quantità di caricamento della pagina è di circa 100 al giorno.

Il server del sito Web è un server esterno del nostro centro dati. Il server del data warehouse è interno al nostro centro dati e ha altri dati critici (in tabelle diverse) non correlati e non dovrebbe essere accessibile al sito web.

Sono stati considerati i seguenti approcci:

  1. Il data warehouse può spingere quotidianamente (SFTP) un file CSV contenente i dati giornalieri sul server web. Il server Web avrebbe un processo in esecuzione su un crontab ogni 15 minuti. Controllerebbe se il file fosse cambiato. In tal caso, aggiornerebbe il suo database con i dati. Quindi, al caricamento della pagina, il server Web interrogherà il suo database per ottenere i dati da visualizzare sulla pagina Web.

    Di solito, la spinta sarebbe solo una volta al giorno, ma più di una spinta potrebbe essere possibile per comunicare (poco frequenti) le correzioni dei prezzi. Anche nello scenario di correzione dei prezzi, tutti i dati verrebbero consegnati nel file. Il processo di polling raccoglierà la modifica e sovrascriverà i dati nel database.

  2. Il server Web potrebbe richiedere dati dal data warehouse usando JDBC o tecnologia di connessione SQL simile.

    Tuttavia, sono stati espressi problemi di sicurezza. La preoccupazione è che, consentendo al server Web di accedere al nostro data warehouse, l'attacco di SQL injection o qualche altro attacco esterno attraverso il sito Web possa compromettere il data warehouse. Misure potrebbero essere messe in atto per ridurre il rischio, ma l'approccio più semplice e più sicuro è stato suggerito semplicemente per non permettere a nessun sistema pubblico di accedere direttamente al data warehouse. In altre parole, il data warehouse può stabilire una comunicazione con altri server (diciamo a SFTP il file), ma nessun server può avviare una connessione con il data warehouse. Queste preoccupazioni sembrano ragionevoli e difficili da mitigare?

  3. È possibile creare un servizio Web e il server Web potrebbe chiamare il servizio Web ospitato nel nostro centro dati interno.

  4. Un processo ospitato nel nostro centro dati interno potrebbe chiamare il server Web quando sa che il data warehouse ha i dati disponibili. Se sì, come dovrebbe essere fatto? HTTPS con qualche modo per impedire ad altri client non autorizzati di effettuare la stessa chiamata?

Quale dei suddetti approcci è il migliore o esiste un approccio migliore rispetto a quelli sopra elencati? Quali sono i pro e i contro in un approccio?

    
posta James 10.01.2014 - 16:46
fonte

2 risposte

1

Dato che il tuo magazzino contiene dati aggiuntivi che non vuoi esporre a un nuovo vettore di attacco sembra che l'opzione migliore sia implementare un qualche tipo di livello di caching di base per questi dati sul server web che il magazzino può spingere a.

Avresti un qualche tipo di servizio in esecuzione nel tuo ambiente di magazzino sicuro, spingendo una rappresentazione serializzata dei tuoi dati necessari in un archivio di valori-chiave o simile (redis, memcached, qualunque cosa) in esecuzione sul tuo server web. Questo dovrebbe essere più semplice e potenzialmente più sicuro rispetto al dover gestire un file CSV. È solo una questione di servizio sul lato del data warehouse che sa quando e come distruggere la cache.

Come accennato, non vi è alcun motivo per cui non sia possibile connettersi al proprio server Web con una connessione HTTPS sicura per effettuare la push. In alternativa / in aggiunta è possibile implementare una crittografia di base per proteggere i dati mentre si è in transito, anche se sembra che i dati richiesti dal server Web non siano effettivamente dati sensibili, pertanto questo passaggio potrebbe essere eccessivo.

Anche in questo caso, poiché il data warehouse contiene dati sensibili, sconsigliamo di provare a creare una sorta di API che il server Web può interrogare. Non c'è nulla di intrinsecamente sbagliato nel farlo, ma certamente apre i vettori di attacco e rende il progetto molto più complicato che sembra debba essere così come non sembra che tu debba fare diversi tipi di query, hai solo bisogno di uno particolare quantità di dati. Il che rende davvero una "conversazione unidirezionale" in cui l'onere è nel magazzino per assicurarsi che i dati "pubblici" vengano espulsi.

Se in futuro è necessario eseguire una query, aggiornare o disporre in altro modo di una "conversazione bidirezionale" con il warehouse dal server Web, sarebbe opportuno silo quei dati lontano dai dati sensibili prima di distribuire essenzialmente "aperto" Endpoint (i) dell'API.

Buona fortuna!

    
risposta data 13.01.2014 - 20:15
fonte
0

Tra le tue opzioni, 3 - L'esposizione di un servizio Web sicuro è la migliore.

Evitando opzioni antiquate (opzione 1) e inutilmente pericolose (opzione 2), ci sono modi per proteggere i servizi web. Il NIST fa una buona lettura al link , e ti consiglio di è una lettura approfondita prima di iniziare.

È possibile fornire sia meccanismi di autenticazione che di autorizzazione nell'implementazione di questi servizi, solitamente con la suite WS-Security . (I nodi XML possono essere crittografati e firmati individualmente). Inoltre, ci sono molti tutorial e domande qui per garantire servizi.

Per quanto riguarda i cons (assicurarsi di leggere nel PDF sopra per "Problemi di sicurezza di WS-Security", che riguardano le insidie di una configurazione errata), il costo di sviluppo di un webservice correttamente protetto sarebbe relativamente alto rispetto alle altre opzioni, ma i vantaggi dell'autenticazione e dell'autorizzazione superano di gran lunga quelli.

    
risposta data 13.01.2014 - 20:37
fonte

Leggi altre domande sui tag

Cerca automaticamente Metasploit per exploit utilizzabili basati su vulnerabilità nel database Chat sicura - CTCP è una buona opzione?