È sicuro inserire istruzioni SQL nella mia applicazione C #?

La linea "noi non abbiamo le risorse" è una bandiera rossa per me.

O pagherete per farlo bene o dovrete pagare per aver sbagliato. So che sceglierei.

Sebbene il tuo caso d'uso sia abbastanza ampio, il che rende difficile fornirti una risposta semplice, ti consiglio vivamente di non assegnare direttamente i diritti di ogni applicazione al database. Un approccio migliore sarebbe quello di creare un server API (eventualmente ospitato anche su Azure) che funge da intermediario e espone solo le funzioni necessarie anziché aprire query SQL.

Se ciò è ancora troppo, allora raccomanderei una soluzione basata su autenticazione di Windows in cui sono stati definiti esplicitamente gli utenti e i ruoli di Windows in SQL Server e li si bloccano al minimo insieme di diritti richiesti. Non è un ottimo approccio, ma probabilmente il meglio che puoi fare senza un'architettura adeguata.

Dovrai anche assicurarti di crittografare i tuoi dati a riposo e in volo e di ruotare regolarmente chiavi e password. Probabilmente non hai risorse per gestire e monitorare realmente questa roba, il che significa che quando tieni hackerato non ne hai idea e non puoi rispondere se lo fai.

Buona fortuna.

In genere non è sicuro connettersi direttamente a un server SQL se l'applicazione è in esecuzione sul computer del cliente.

Se il client ha una stringa di connessione SQL, possono eseguire qualsiasi SQL che l'utente abbia il permesso di eseguire. E in genere le autorizzazioni SQL non sono abbastanza dettagliate per avere il tipo di controllo desiderato per un'applicazione.

La solita soluzione è aggiungere un livello API tra la tua app e il database, poiché altri hanno notato che questo è molto più economico rispetto all'esecuzione del database, quindi non dovrebbe essere un problema di risorse.

Se vuoi davvero connetterti direttamente, potresti usare le stored procedure per implementare un livello API.

Inizierò dicendo che sono d'accordo sul fatto che la sicurezza è generalmente gestita meglio da un intermediazione tra client e database. Questo aiuto ti dà "sicurezza in profondità".

Tuttavia non sono d'accordo con alcune delle risposte precedenti. È è possibile limitare o limitare le autorizzazioni e i privilegi che gli utenti hanno a livello di database.

Oltre alla concessione di selezionare, inserire, aggiornare, eliminare i privilegi, la tua app potrebbe utilizzare diversi schemi e amp; viste o proc memorizzati preferibilmente per limitare o limitare ciò che possono fare. Se la tua app può utilizzare solo quelle funzioni, sei meno esposto. Il concetto è di concedere i minimi privilegi necessari. NON dai privilegi SA o DBO a un'applicazione o a un servizio di assistenza. Mai.

Il bit difficile sarà che Azure richiede un login / password SQL. Se gli utenti condividono lo stesso accesso SQL, ciò limiterà la possibilità di cambiare le password e l'applicazione dovrà gestire gli utenti che possono eseguire funzioni specifiche. Se si desidera che gli utenti abbiano accessi e password separati a livello SQL, ciò diventerà un sovraccarico di manutenzione per l'utente.

Non sono un esperto di Azure, ma puoi anche limitare / escludere connessioni per indirizzo / intervallo IP. Se i tuoi siti client possono essere identificati dall'IP che potrebbe darti un ulteriore livello di sicurezza.

Ma la triste realtà è che gli utenti possono portare un server DB al suo ginocchio con nient'altro che una query selezionata. Quindi non vuoi che i tuoi utenti sappiano mai cos'è il login / password SQL, perché se possono connettersi, possono selezionare.

In un ambiente aziendale questo potrebbe essere accettabile, ma nel selvaggio web selvaggio ... questa è la notizia dell'hacker che aspetta di accadere.

Ti consiglio caldamente di andare in sicurezza, di costruire una specie di middle tier / broker e di tenere gli utenti a debita distanza dal tuo db.

Fondamentalmente se si sta fornendo un accesso raw si sta solo chiedendo iniezioni SQL - il numero uno dei problemi di sicurezza online. Quindi, in pratica, fermati qui o semplicemente non fingere di avere alcuna sicurezza.

Per quanto riguarda il fatto che un DB di test provi un file system basato su uno come HSQL, allora puoi semplicemente avere la cosa sulla tua macchina per scopi di sviluppo e test. Come altri qui hanno sottolineato, hai davvero bisogno di un'API che definisca azioni valide dopo di ciò, sanitizzando gli input grezzi, codificandoli in azioni valide solo dopo aver effettivamente eseguito l'azione.

Dai un'occhiata al link per ulteriori informazioni su tutti i vari problemi di sicurezza che si potrebbero prendere in considerazione per qualsiasi applicazione.

L'utilizzo del database come server non è il modo corretto di proteggere i dati, oltre ad accoppiare strettamente il progetto con questa implementazione del database.

in genere uno strato del servizio applicativo utilizza le chiamate al database (preferibilmente come stored procedure) e implementa la logica di business a quel livello. Poi arriva un livello di presentazione (preferibilmente un livello API) in cui separerebbe i client dal motore di business dietro di esso.

in genere questo livello API utilizza un servizio di autenticazione, per garantire che questo client sia stato autenticato ed è autorizzato a visualizzare queste informazioni che stanno cercando (utilizzando questa API)

di nuovo all'architettura del database client > originale, con SQL incorporato nei client, questo non va bene per i seguenti motivi:

1. i tuoi clienti possono essere utilizzati per compromettere il tuo database e ottenere l'accesso a tutti i dati
2. non è possibile modificare gli oggetti del database senza apportare modifiche a tutti i client
3. se hai una piccola correzione alla tua query, devi distribuirla a tutti i client

conclusione:

• mantieni il tuo database
• crea stored procedure con l'accesso alla tabella
• crea un livello applicazione per consumare il livello di stored procedure
• crea un livello API per consumare il livello applicazione
• crea / usa un servizio di autenticazione
Il livello API utilizzerà i servizi di autenticazione
• le tue applicazioni client accedono solo a questo livello API