Impostazione della comunicazione tra database interno e server Web ospitato da terzi

0

Sto cercando di capire il modo migliore e più sicuro per farlo, se è possibile farlo in modo sicuro e protetto.

Piccola azienda. Abbiamo un server Web ospitato da una terza parte che serve la nostra app Web client con il minimo di dati nel database sul server. Vuoi iniziare a offrire più funzionalità attraverso il portale che richiederebbe di sviluppare l'app per accedere ai nostri dati più completi sul nostro database interno. L'azienda non vuole mettere i dati sul server di terze parti.

Penso che un modo per farlo sarebbe quello di aprire il server di terze parti sulla porta del database e consentire solo il traffico dall'IP dell'ufficio a quella porta. Sul server interno, aprire la porta per il database solo per il traffico dall'IP del server di terze parti.

1) Questa sarebbe considerata una configurazione ragionevolmente sicura?

Non sono né una rete né un ragazzo della sicurezza, quindi sto raccogliendo informazioni sulle migliori pratiche e ricevendo suggerimenti per l'installazione.

So che può esistere lo spoofing IP in cui un utente malintenzionato può rendere il proprio IP simile a quello di chiunque altro. Dovrebbero sapere in anticipo quale IP è esentato. Tuttavia, una chiave di autenticazione tra i server può essere configurata in modo che anche se l'IP fosse stato contraffatto, entrambe le estremità della connessione avrebbero bisogno della chiave.

2) Questo sarebbe solo un tasto SSH?

MODIFICA 1:

Per essere sinceri, no, in azienda è una vera comprensione per quanto riguarda la sicurezza. Non vogliamo i nostri dati sensibili su un server di terze parti perché pensano che sia solo in giro per chiunque nell'etere di afferrare. Fondamentalmente come googling 'Microsoft', o qualcosa del genere, qualcuno può essere solo come 'dati my_company' e ottenere i nostri dati. L'altra ragione è pratica. I dati devono essere immediatamente disponibili poiché lavoriamo costantemente con esso. Dovendo caricare e scaricare da un server remoto sarebbe lento e fastidioso molto veloce.

Inoltre, dovrei aggiungere che ciò implica informazioni sensibili che non dovrebbero essere rese pubbliche. Che cosa succede se un cliente desidera calcolare il 65 ° percentile per un determinato articolo, tale richiesta viene inviata dall'app Web del client in esecuzione sul terzo server di parti al database interno in cui i dati grezzi devono calcolare il percentile. Il risultato viene inviato nuovamente all'app Web del cliente e presentato lì. Non dovrebbero avere accesso ai dati direttamente perché sono riservati.

Detto questo, stavo leggendo un po 'le API REST. Una parte di quello che stavo leggendo stava dicendo che le API REST potrebbero non essere le migliori quando sono richieste informazioni sensibili, o l'autenticazione, e che SOAP dovrebbe essere usato.

    
posta sockpuppet 05.01.2017 - 06:13
fonte

2 risposte

3

Questa sarà considerata una configurazione ragionevolmente sicura? : No.

Il suggerimento qui è L'azienda non vuole mettere i dati sul server di terze parti . Presumo che ci siano buone ragioni per questo. Il problema è che se si autorizza direttamente il server Web sull'host remoto ad accedere direttamente al database locale, significa semplicemente che il server esterno ottiene un accesso diretto al server di database interno.

I server di database sono protetti onestamente, ma non sono pensati per essere direttamente sotto la minaccia di attacchi diretti. Quindi quando chiedi delle migliori pratiche, questo non è uno. Sicuramente.

Il modo corretto sarebbe di costruire un'applicazione web REST minima in una DMZ all'interno della rete interna. Dovrebbe essere accessibile dal server esterno che invierà richieste e questo relè avrà accesso diretto al database interno. Devi applicare le regole standard (SSL) per proteggere la comunicazione tra l'host remoto e il relè, installare il minimo sul relè (più software, il rischio maggiore) e consentire il minor numero possibile di utenti ad accedervi.

In questo modo, anche se un utente malintenzionato potrebbe assumere il controllo dell'host remoto, dovrà comunque passare il relay locale prima di poter direttamente attaccare il database. Ok le richieste potrebbero essere già dannose, ma IMHO molto meno che un accesso diretto.

    
risposta data 05.01.2017 - 08:56
fonte
0

Penso che dovresti separare questi due database in due diversi ambienti. Entrambi hanno diversi tipi di dati che si trovano in due diversi livelli di privilegio. non fidarti del traffico o dei dati nel database di terze parti. Quindi è necessario impedire il traffico dal DB di terze parti al proprio DB.

Eseguire il livello di base Harding sul tuo database locale aggiungendo firewall ecc. Ora hai 3 entità segregate (web server, DB di terze parti e il tuo DB). La prossima cosa è che dobbiamo considerare cosa può fare un utente malintenzionato i dati in transito. Possono intercettare ed eseguire l'alterazione dei dati. il modo più semplice per mitigarlo è abilitare SSL / TLS nel server Database.

Se l'attaccante ottiene un accesso di root / amministratore al server Web, la situazione cambia. SSL non può impedire nulla in questa situazione perché l'utente malintenzionato può leggere le voci di configurazione.

Non lasciare alcuna voce di configurazione in testo normale. (stringhe di connessione e password al DB). Prova a memorizzare in modo sicuro questi valori di configurazione utilizzando la crittografia e l'archiviazione sicura (ad esempio: un keystore se stai utilizzando Java nel tuo server Web)

    
risposta data 05.01.2017 - 06:55
fonte

Leggi altre domande sui tag