È più sicuro passare attraverso un terzo database per connettere due database utilizzando lo stesso login?

Abbiamo la seguente configurazione:

• Database di produzione multipla contenente dati privati ​​utilizzati dal software desktop
• Un database Web per un sito Web pubblico che necessita di alcuni dati dai database privati
• Un database intermedio che contiene alcune viste e procedure memorizzate che estraggono i dati dai database privati

Attualmente il sito Web accede al database Web e il database Web si collega al database intermedio per estrarre i dati o eseguire le procedure memorizzate sui database di produzione. Tutti i database si trovano sulla stessa istanza SQL e l'intero processo utilizza lo stesso account utente.

L'account utente ha pieno accesso al database Web e al database intermediario, ma può accedere solo a viste specifiche e stored procedure di e database privato

È davvero più sicuro del semplice collegamento del database pubblico direttamente a quelli privati?

Sembra che il database intermedio sia lì solo per complicare le cose poiché lo stesso login viene utilizzato per accedere ai dati in tutti i database, ed è già limitato alle sole viste / SP di cui ha bisogno nei database privati. Spero di rimuoverlo.

Una cosa salta qui:

L'intero processo utilizza lo stesso set di credenziali di accesso

Problema

Quindi l'ipotetico userX (sia che alcuni meatsack utilizzino Excel o IIS AppPool Identity) può vedere alcune viste e codice. Non importa in quale database si trovano queste viste e codice perché userX è comunque configurato in 3 database.

Tuttavia, si perde il concatenamento in questo modo.

Diciamo WebDB.dbo.SomeProcchiamatePrivateDB.dbo.SomeTable . UserX richiede autorizzazioni per entrambi gli oggetti. Se questo stava OneDB.WebGUI.SomeProcusando, OneDB.dbo.SomeTablesolo le OneDB.WebGUI.SomeProcautorizzazioni necessarie. Le autorizzazioni per gli oggetti referenziati con lo stesso proprietario non vengono verificate.

Nota: non ho approfondito troppo il database incrociato concatenamento della proprietà . So solo pianura vecchio "concatenamento della proprietà" bene

Ora, come da commenti, hai davvero 2 database che possono essere combinati. Non 3, che inizialmente era implicito. Tuttavia, l'intermedio e il web possono essere combinati.

Gli altri database "privati" possono forse essere combinati, ma questo sarà un problema separato. Vedi il link in basso per una discussione più completa di "uno o più database"

Soluzione?

Se i database extra sono solo contenitori di codice, allora gli schemi sono un'idea migliore.

Sembra che tu abbia usato "Database" dove dovresti usare "Schema" (nel senso di SQL Server, non di MySQL). Avrei uno schema WebGUI, uno schema Helper o Common (per sostituire il database intermedio) e uno schema desktop. In questo modo si separano le autorizzazioni in base ai client e si dispone di un solo database

Con un database (oltre al "concatenamento della proprietà") puoi anche iniziare a considerare le viste indicizzate, SCHEMABINDING (lo uso sempre) e tali che non possono essere fatte con database separati

Per ulteriori informazioni sugli schemi, vedi queste domande:

• Progettazione dello schema: migliori pratiche?
• Uso eccessivo / uso corretto degli schemi?

Infine, non appare alcun motivo per disporre di database separati basati su "integrità transazionale non richiesta". Vedere questa domanda per spiegare questo: criteri di decisione su quando utilizzare uno schema non dbo rispetto a un nuovo database

La risposta è, dipende. Se non si accede al database privato dall'esterno della LAN interna (o solo attraverso una VPN), questo schema aggiunge sicurezza in quanto qualcuno che utilizza le credenziali del sito Web avrebbe solo un accesso limitato a quel DB Server privato (e avrà un po 'più di lavoro per ottenere nella tua rete interna - tempo che può essere utile per scoprire l'intrusione e chiudere il buco).

In caso contrario, non credo che aggiunga nulla tranne la complessità.

MODIFICARE:

Sembra che ho letto male la tua domanda, quindi vediamo se ho capito bene ora: IntermDb è un database vuoto solo per connettersi a PrivateDB OPPURE è un DB che ha viste / procedure proprie che si collega al PrivateDB per recuperare i dati ?

Nel primo caso, WTF? Strappalo. È inutile, a meno che qualcuno non voglia verificarlo per profilare l'accesso al PrivateDB in modo più pigro (e facendo lavorare di più gli sviluppatori di WebApp). SQL Profiler può filtrare utilizzando DB_ID ...

Nel secondo caso, sostengo la mia risposta precedente.

MODIFICARE: "Non vedo ancora come sia più sicuro che connettere il db privato direttamente al db pubblico poiché tutti e 3 i database sulla stessa istanza SQL e il login utilizzato per tutti e 3 i database è lo stesso e possono accedere solo viste specifiche e procedure memorizzate nel db privato comunque ".

Avere l'intermediario significa che l'invasore dovrebbe scavare nel tuo codice per conoscere l'esistenza di un IntermDB - e deve scavare il tuo codice su di esso per sapere che esiste un PrivateDB.

Se si inserisce il proprio PrivateDB su un altro server interno alla propria LAN / WAN dell'organizzazione (se possibile), si può dedicare abbastanza tempo all'amministratore per rilevare e bloccare il tentativo di invasione. Se usi sinonimi, questa mossa è fluida in quanto tutto ciò che hai è ricostruirli nel codice esistente e andare nel posto giusto.

Inoltre ottieni altri vantaggi: poiché tutto il codice deve passare attraverso IntermDB per accedere ai dati in PrivateDB, nessuno sviluppatore sarebbe tentato di provare a bypassarlo - e quel tentativo può essere facilmente individuato su SQL Server Profiler come DB_ID della richiesta di dati PrivateDb sarebbe WebAppDb.