Come proteggere mentre si accoppia liberamente un server db condiviso da 2 servizi diversi

0

Informazioni di background

Ho un database che verrà utilizzato da due diverse applicazioni web. La soluzione A (applicazione web guidata dall'utente) risiede sulla rete pubblica e scriverà / aggiornerà / cancellerà i record sul db. Soluzione / Servizio B (non utente ma guidato dal processo) risiede dietro l'FW e leggerà solo i dati dal db. Per scopi di discussione, diciamo solo che il server db verrà impostato in modo che sia accessibile sia dalla Soluzione A che dalla B.

Domanda

Sto cercando di analizzare quale sia il modo migliore per configurare il server di database in modo che entrambe le applicazioni A e B possano interagire in modo sicuro, ma anche essere il meno possibile accoppiate al server di database.

Opzioni

Finora, stavo pensando di creare 2 API web sul server del database. Si potrebbe esporre un'interfaccia di sola lettura per la Soluzione B. E l'altro dovrebbe essere letto in scrittura per la Soluzione A. Tuttavia, la domanda che viene in mente è come devo autenticare le richieste che arrivano nel server DB dalla Soluzione A? Se questo server db si trova sulla rete interna, dovrei preoccuparmi poiché "so" che gli utenti sarebbero stati autenticati quando hanno colpito il server pubblico? Se devo preoccuparmi, posso avere la soluzione A inoltrare il JWT al server interno db? Penso che avrei bisogno di interagire con il server di identità dal server DB ancora una volta per il JWT di qualsiasi valore, giusto?

Qualsiasi commento o suggerimento sarebbe apprezzato.

Grazie.

    
posta dot 03.12.2018 - 17:29
fonte

1 risposta

0

La creazione di due WebAPI e la loro distribuzione sul server di database su misura per ciascuna delle soluzioni, non le rende accoppiate liberamente al server di database.

A mio parere, il server di database dovrebbe disporre di un'API pulita ed espressiva esposta per le entità fidate con cui è possibile configurarlo per interagire.

Penso che dovresti implementare un'entità fidata come questa per essere un connettore / broker per le soluzioni A / B e gestirà le richieste, le autenticherà, applicherà le misure di sicurezza e le autorizzazioni come desideri e solo allora trasferirà come API uniforme chiama al server del database e restituisce la risposta (forse invocando la logica di business anche sulla risposta).

Applicando un'autenticazione rigorosa per qualsiasi richiesta se la soluzione A o B dipende dai tuoi requisiti, i dati risiedono nel database e più in generale nel tuo modello di minaccia.

    
risposta data 03.01.2019 - 14:08
fonte