Come posso proteggere il mio DB MS-SQL dai miei utenti e tuttavia accedervi comunque tramite ODBC?

Question

Ho un'applicazione ms-access che accede a ms-sql db tramite una connessione ODBC.Sto cercando di costringere i miei utenti ad aggiornare i dati soltanto tramite la porzione applicativa, ma non mi interessa se leggono i dati direttamente o tramite il proprio db ms-access personalizzato (lo usano per creare report ad hoc).

Quello che sto cercando è un modo per rendere i dati modificabili solo se utilizzano il file .mde compilato che distribuisco loro.So di poter rendere i dati letti solo per la popolazione generale e modificabili per utenti selezionati.

Esiste un modo per ottenere che ms-sql renda i dati modificabili solo se accedono tramite il mio mde predefinito?

Pensiero, esiste un modo per ottenere l'accesso ms per accedere al database come utente diverso (o modificare l'accesso una volta connesso)?

---

@Jake,
Sì, utilizza i moduli.Quello che sto cercando di fare è semplicemente far cambiare utente una volta quando viene visualizzato il modulo del launchpad/menu principale.

@Peter,
Questa è davvero la direzione in cui sto andando.Ciò che non ho determinato è come passare a quel secondo ID.Non sono così preoccupato che la password venga sniffata, gli utenti sono tutti interni e su una LAN interna.Se riescono a fiutare quella password, possono sicuramente fiutare quella del mio ID privilegiato.

@nessuno in generale,
In questo momento la sua sicurezza è data dall'oscurità.Ho fornito agli utenti uno speciale .mdb per eseguire report che consentirà loro di leggere i dati, ma non di aggiornarli.Non sanno come ricollegarsi alle tabelle tramite la connessione ODBC.Un utente leggermente più esperto di MS-Access/DB potrebbe ignorare ciò che ho fatto in pochi secondi - e ce ne sono alcuni che immaginano di essere DBA, quindi alla fine lo capiranno.

Answer 1

Esiste un modo per farlo che è efficace con gli utenti interni, ma può essere violato.Crei due ID per ciascun utente.Uno è un ID reporting con accesso di sola lettura.Questo è l'ID di cui l'utente è a conoscenza:Fred / la mia password

Il secondo è un ID che può eseguire aggiornamenti.L'ID è Fred_app / mypassword_mangled.Accedono alla tua app con Fred.Quando la tua applicazione accede ai dati, utilizza l'ID dell'applicazione.

Questo può essere annusato, ma per molte applicazioni è sufficiente.

Answer 2

L'app consente gli aggiornamenti delle tabelle collegate o passa attraverso moduli?Sembra che la tua idea di utilizzare un utente centralizzato con ruoli distinti sia la strada da percorrere.Sì, potresti cambiare utente, ma io potrei introdurre più codifica e una volta che inizi ad aggiungere sempre più codice, altre soluzioni (procedure memorizzate, ecc.) potrebbero sembrare più invitanti.