Accesso sicuro ai dati
Per scrivere codice ADO.NET protetto, è necessario comprendere i meccanismi di sicurezza disponibili nell'archivio dati o nel database sottostante. Considerare inoltre le implicazioni di sicurezza di altre funzionalità o componenti eventualmente inclusi nell'applicazione.
Autenticazione e autorizzazioni
Quando ci si connette a Microsoft SQL Server, è possibile usare la sicurezza di Windows, nota anche come sicurezza integrata, che si basa sull'identità dell'utente attivo corrente di Windows anziché sull'immissione di un ID utente e una password. L'uso dell'autenticazione di Windows è consigliato per i database in locale perché le credenziali dell'utente non vengono esposte nella stringa di connessione. Se non è possibile usare l'autenticazione di Windows per connettersi a SQL Server, si può pensare a creare stringhe di connessione in fase di esecuzione tramite SqlConnectionStringBuilder.
Importante
Microsoft consiglia di usare il flusso di autenticazione più sicuro disponibile. Se ci si connette ad Azure SQL, le Identità gestite per le risorse Azure sono il metodo di autenticazione consigliato.
Le credenziali usate per l'autenticazione devono essere gestite in modo diverso a seconda del tipo di applicazione. Ad esempio, in un'applicazione Windows Form all'utente può essere richiesto di fornire le informazioni di autenticazione oppure possono essere usate le credenziali di Windows dell'utente. Tuttavia, in un'applicazione Web in genere l'accesso ai dati viene eseguito tramite le credenziali fornite dall'applicazione stessa invece che dall'utente.
Dopo l'autenticazione degli utenti, l'ambito delle loro azioni dipende dalle autorizzazioni che gli sono state concesse. Attenersi sempre al principio dei privilegi minimi e concedere solo le autorizzazioni strettamente necessarie.
Per altre informazioni, consultare le risorse seguenti.
| Risorsa | Descrizione |
|---|---|
| Protezione delle informazioni di connessione | Vengono descritte le procedure consigliate e le tecniche in materia di sicurezza per la protezione delle informazioni di connessione, ad esempio l'uso della configurazione protetta per crittografare le stringhe di connessione. |
| Generatori di stringhe di connessione | Viene descritto come compilare stringhe di esecuzione dall'input dell'utente in fase di esecuzione. |
| Sicurezza per il motore di Database di SQL Server e il Database SQL di Azure | Fornisce collegamenti utili per individuare informazioni sulla sicurezza e la protezione nel motore di database di SQL Server e nel database SQL di Azure. |
Comandi con parametri e SQL injection
L'uso di comandi con parametri consente di salvaguardarsi da attacchi SQL injection, un cui un utente non autorizzato inserisce in un'istruzione SQL un comando che compromette la sicurezza del server. I comandi con parametri consentono di evitare attacchi SQL injection garantendo che i valori ricevuti da un'origine esterna verranno passati come semplici valori e non come parte di un'istruzione Transact-SQL. Pertanto, i comandi Transact-SQL inseriti in un valore non verranno eseguiti sull'origine dati. Verranno invece valutati unicamente come un valore del parametro. Oltre ai vantaggi in termini di sicurezza, i comandi con parametri rappresentano un metodo pratico per organizzare i valori passati con un'istruzione Transact-SQL o a una stored procedure.
Per altre informazioni sull'uso dei comandi con parametri, vedere le risorse seguenti.
| Risorsa | Descrizione |
|---|---|
| Parametri DataAdapter | Viene descritto come usare parametri con DataAdapter. |
| Modifica di dati con stored procedure | Viene descritto come specificare i parametri e ottenere un valore restituito. |
| Stored procedure (Motore di database) | Descrive i vantaggi dell'uso di stored procedure e i diversi tipi di stored procedure. |
Attacchi di tipo probe
Gli utenti non autorizzati usano spesso informazioni provenienti da un'eccezione, quale un nome di server, database o tabella, per eseguire un tentativo di attacco al sistema. Dal momento che le eccezioni possono presentare informazioni specifiche sull'applicazione o sull'origine dati, è possibile migliorarne la protezione esponendo al client solo le informazioni necessarie.
Per altre informazioni, consultare le risorse seguenti.
| Risorsa | Descrizione |
|---|---|
| Gestione e generazione di eccezioni in .NET | Vengono descritte le forme di base di gestione delle eccezioni strutturata di tipo try/catch/finally |
| Procedure consigliate per le eccezioni | Vengono descritte le procedure consigliate per la gestione delle eccezioni. |
Proteggere le origini dati di Microsoft Access ed Excel
Se i requisiti di sicurezza sono minimi o non esistenti, Microsoft Access e Microsoft Excel possono fungere da archivio dati per un'applicazione ADO.NET. Le funzionalità di sicurezza di queste applicazioni sono efficaci per la prevenzione, ma non devono essere considerate affidabili se non per scoraggiare le intrusioni di utenti non informati. I file di dati fisici per Access ed Excel si trovano nel file system e devono essere accessibili a tutti gli utenti. Questo li rende vulnerabili ad attacchi che possono comportare il furto o la perdita di dati, in quando i file possono essere facilmente copiati o modificati. Se è necessaria una soluzione di sicurezza più affidabile, usare SQL Server o un altro database basato su server in cui i file di dati non sono leggibili dal file system.
Servizi aziendali
In COM+ è incluso un modello di sicurezza che si basa sugli account di Windows e sulla rappresentazione di processi/thread. Lo spazio dei nomi System.EnterpriseServices fornisce dei wrapper che consentono alle applicazioni .NET di integrare codice non gestito con i servizi di sicurezza COM+ tramite la classe ServicedComponent.
Interoperabilità con codice non gestito
.NET Framework rende disponibile l'interazione con codice non gestito, inclusi componenti COM, servizi COM+, librerie dei tipi esterni e tanti servizi del sistema operativo. L'uso di codice non gestito implica l'allontanamento del perimetro di sicurezza disponibile per il codice gestito. Sia il codice sia il codice da cui viene chiamato devono disporre dell'autorizzazione SecurityPermission per codice non gestito con il flag UnmanagedCode specificato. Il codice non gestito può introdurre vulnerabilità di sicurezza impreviste nell'applicazione. Pertanto, è necessario evitare di interoperare con codice non gestito a meno che non sia assolutamente necessario.
Per altre informazioni, vedere Interoperabilità con codice non gestito.