Accesso alle stringhe di connessione tramite un servizio Web

Question

L'idea di archiviare le stringhe di connessione in un database è un'idea perversa, ma per prima cosa ascoltatemi. Sappiamo tutti che è meglio crittografare le stringhe di connessione nel file web.config, ma cosa succede se saltiamo completamente il file web.config?

Un paio di mesi fa mi è stato chiesto di spostare i database da un server a un altro. Ciò significava dover aggiornare le stringhe di connessione in ogni programma che accede a questi vari database. Questa è la terza volta in 2 anni che ho dovuto spostare i database da un server all'altro. Così ho pensato di memorizzare stringhe di connessione in un database e assegnare a ciascun GUID l'accesso tramite un servizio web. Invece di posizionare stringhe di connessione in un web.config, è sufficiente memorizzare il GUID della stringa di connessione nel web.config e fare riferimento al servizio Web della stringa di connessione in modo da poter richiedere quella stringa di connessione. La crittografia può essere eseguita a livello di applicazione e le stringhe di connessione vengono semplicemente memorizzate nel database.

Ho creato un proof of concept e funziona perfettamente (è solo su una intranet locale e non è esposto a Internet).

Il vantaggio è ovvio per me; come essere in grado di aggiornare rapidamente le stringhe di connessione senza dover toccare l'applicazione web. Ciò significa che è possibile creare un'applicazione Web solo per modificare la stringa di connessione nel database, che un DBA potrebbe utilizzare in proprio, quindi non devono mai disturbare un programmatore quando si spostano i database.

Ma il vantaggio non è quello che mi interessa. Mi interessa quello che tutti qui pensano di fare qualcosa del genere?

Answer 1

Estrarre le stringhe di connessione dal web.config principale e inserirle in un file di configurazione separato. Questo file sarà lo stesso per tutte le tue app, quindi se devono cambiarti devi solo copiare e incollare lo stesso file in tutte le cartelle dell'app, invece di modificare ciascuna configurazione separatamente.

Answer 2

E quando il tuo webservice cambia posizione? Quindi dovresti aggiornare comunque tutti i web.configs.

Le tue applicazioni si trovano sullo stesso server o sono distribuite su pochi server? È possibile modificare la macchina web.configs per includere le stringhe della connessione DB per risparmiare un sacco di ripetizioni.

Answer 3

Tendo a fare una delle due cose. Memorizzerò le connessioni in Machine.Config, o creerò un nuovo nome host che si riferisce solo al server DB. Ho quindi inserito un record nel file hosts.

Il vantaggio di questo è che non devo mai modificare un file di configurazione quando mi sposto dalla mia casella locale, per svuotare qa o ambienti di produzione.

Answer 4

Gli svantaggi principali che posso vedere sono l'evidente penalità delle prestazioni (e se si memorizza nella cache la stringa di connessione) e il single point of failure è probabile che si introduca a tutte le applicazioni (a meno che non si voglia caricare il bilanciamento servizio, che sembrerebbe un po 'eccessivo)

Answer 5

Domanda molto interessante. L'ho trovato perché ho avuto la stessa idea.

Sembra molto simile a UDDI per me e offre un altro livello di riferimento indiretto con possibili miglioramenti della sicurezza & manutenibilità migliorata (eccetto per singolo punto di errore che è comunque possibile risolvere).

Ovviamente c'è un DNS che risolverebbe il problema dei nomi host, ma con tale servizio web si hanno possibilità incredibili come restituire stringhe di connessione diverse in base a chi chiede (a seconda diCert SSL o user/pass o token, servizi di directory come AD, LDAP, ruolo utente, ecc. - il cielo è il limite :)

Inoltre, tutte le stringhe di connessione sarebbero adeguatamente protette e inaccessibili per occhi indiscreti di utenti curiosi.

All'inizio questa idea sembra perversa, ma più ci penso e più sono convinto che un'azienda di livello Enterprise potrebbe trarre grandi benefici dall'introdurre tale soluzione.

Answer 6

Vedo che non sono l'unico che ha avuto questa idea. Solo di recente ho iniziato a meditare dopo una riflessione sull'assortimento di applicazioni personalizzate e siti Intranet (non importa i numerosi database e server). Mi sembra che il servizio WCF possa o debba essere scritto in modo da restituire le informazioni sulla connessione al database in vari modi: stringa di connessione, una connessione effettiva o solo il nome del server e del database. Inoltre, il servizio stesso dovrebbe probabilmente ottenere le sue informazioni da un database ausiliario centrale e da una tabella che può essere utilizzata per gestire i vari punti di connessione. Per esempio: Datemi la connessione al database di contabilità, produzione o sviluppo, ecc.