Teoria sulla suddivisione dei dati in diversi DBMS isolati (server fisici diversi) per ottenere sicurezza?

3

Supponiamo il seguente scenario:

1- Un'app Web (su WEBSERVER1) e il suo database (su DBMS1) con informazioni molto sensate distribuite nello stesso server fisico (diciamolo per semplificazione). Gli utenti interagiscono con l'app Web sotto l'ombrello di speciali misure di titoli, queste misure di sicurezza prendono in considerazione il fatto che gli utenti di app Web sono poche persone e che queste persone hanno una posizione di rete speciale rispetto a DMBS1 e WEBSERVER1. Ho detto questo per affermare che alcune delle misure di sicurezza applicate (applicate per proteggere i dati nel DBMS1 e l'accesso a WEBSERVER1) possono essere applicate solo agli utenti che soddisfano queste condizioni, chiamiamo questo insieme di utenti USERS1.

2- Altri utenti e applicazioni (tramite esposizione API) necessitano di dati di accesso (CRUD) anche nel DBMS1 (chiamiamoli USERS2), ma non possiamo applicare le stesse misure di sicurezza a USERS2 di quelle applicate a USERS1 a causa della loro posizione fisica, quantità di utenti e controllo su di essi. Inoltre, è molto importante che l'autorizzazione venga applicata agli UTENTI2, voglio dire, USERS2 può solo accedere ai dati del DBMS1 a cui erano autorizzati ad accedere.

Un collega suggerisce di aumentare la sicurezza con un DBMS2 diverso e un diverso WEBSERVER2 distribuito, isolato dal DBMS1 principale e WEBSERVER1, per consentire USERS2 CRUD sui dati. Per quanto posso vedere, questo implica un meccanismo per sincronizzare i dati da un DMBS a un altro. Firewall e credenziali possono essere impostati in modo tale da compromettere anche il server DBMS2 che l'intruso non può violare le politiche di autorizzazione e scrivere i dati su DBMS1. Per archiviare questo deve essere una mappa tra le impostazioni di autorizzazione USERS2 (specificate in DBMS1) e i dati replicati-sincronizzati tra DBMS1 e DBMS2 e il processo di replica dei dati deve essere avviato dal gruppo di server di DBMS1, avendo loro DMBS1 server le credenziali per accedere a DMBS2 mentre Il server DBMS2 non sa nulla su come accedere a DBMS1.

Penso che il valore di questo tipo di architettura consiste nell'avere contenuto isolato qualsiasi foro di sicurezza sfruttabile USERS2 potrebbe essere trovato nella distribuzione del DBMS e del WEBSERVER2 con cui stanno interagendo.

Voglio solo notare che la protezione delle credenziali di USERS2 e le misure di sicurezza sono al di fuori del dominio dell'organizzazione che gestisce DMBS1.

Le mie domande sono:

Esiste qualcosa di scritto su questo tipo di architettura? Che dire degli strumenti / procedure per automatizzare il processo di creazione e modifica DMBS2 a seconda delle politiche di autorizzazione?

Apprezzerei qualsiasi aiuto o orientamento, i critici su questa architettura.

Sto includendo un diagramma per supportare la spiegazione, la direzione della freccia è questione di chi inizia la comunicazione ... So che so, la grafica è terribile, ma spero di aggiungere qualche informazione.

ModificaÈevidenteilparallelodiquestaarchitetturaDBMS-Web_Serverconun DZM Dual firewall

    
posta gsi-frank 10.10.2013 - 15:25
fonte

1 risposta

1

Ho difficoltà a capire la tua domanda, ma lascia che provi una risposta. Sembra che tu abbia due gruppi di utenti:

  • Utenti di app Web interni
  • Utenti di API esterne

Sembra anche che questi utenti abbiano bisogno di diversi livelli di accesso allo stesso database.

Se quanto sopra è vero, suggerirei la seguente struttura:

  • Server Web che ospita l'app Web e l'API. Accessibile al mondo esterno, con l'app Web limitata a determinate persone.
  • Server di database accessibile solo dal server web. Utenti interni, utenti esterni, ecc. Non possono accedere direttamente. Tutto deve scorrere attraverso il server web.

Nel database in fase di accesso, imposta due schemi:

  • tutti
  • interno

Quindi ora il tuo database potrebbe avere 4 tabelle che assomigliano a questo:

internal.SuperSecretTable
internal.DarkCompanySecrets
external.WhoCares
external.HaveAtIt

Esistono anche due ruoli utente:  - dipendente  - apiUser

Il ruolo employee avrebbe accesso a entrambi gli schemi internal e external , mentre il ruolo apiUser avrebbe solo accesso allo schema external . Assegna a questi ruoli le autorizzazioni minime di cui hanno bisogno per funzionare.

Spero che questo aiuti!

    
risposta data 10.10.2013 - 22:21
fonte

Leggi altre domande sui tag