Accesso protetto ai dati (ADO.NET)

Articolo
05/20/2011

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 che potrebbero essere inclusi nell'applicazione.

Autenticazione e autorizzazioni

Quando ci si connette a Microsoft SQL Server, è possibile utilizzare 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'utilizzo dell'autenticazione di Windows è consigliato perché le credenziali dell'utente non vengono esposte nella stringa di connessione. Se non è possibile utilizzare l'autenticazione di Windows per connettersi a SQL Server, creare stringhe di connessione in fase di esecuzione tramite SqlConnectionStringBuilder.

Le credenziali utilizzate 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 utilizzate 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 ulteriori informazioni, vedere le seguenti risorse.

Risorsa	Descrizione
Protezione delle informazioni di connessione (ADO.NET)	Vengono descritte le procedure consigliate e le tecniche in materia di sicurezza per la protezione delle informazioni di connessione, ad esempio l'utilizzo della configurazione protetta per crittografare le stringhe di connessione.
Consigli sulle strategie di accesso ai dati	Vengono forniti suggerimenti per l'accesso ai dati e l'esecuzione di operazioni di database.
Compilatori di stringhe di connessione (ADO.NET)	Viene descritto come compilare stringhe di esecuzione dall'input dell'utente in fase di esecuzione.
Panoramica della sicurezza di SQL Server (ADO.NET)	Viene descritta l'architettura di sicurezza di SQL Server.

Comandi con parametri e SQL injection

L'utilizzo 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 ulteriori informazioni sull'utilizzo dei comandi con parametri, vedere le seguenti risorse.

Risorsa	Descrizione
Parametri di DataAdapter (ADO.NET)	Viene descritto come utilizzare parametri con DataAdapter.
Modifica di dati con le stored procedure (ADO.NET)	Viene descritto come specificare i parametri e ottenere un valore restituito.
Gestione delle autorizzazioni con le stored procedure in SQL Server (ADO.NET)	Viene descritto come utilizzare le stored procedure di SQL Server per incapsulare l'accesso ai dati.

Attacchi tramite script

Gli attacchi tramite script sono un altro tipo di intrusione in cui vengono inseriti caratteri dannosi in una pagina Web. I caratteri inseriti non vengono convalidati nel browser e verranno elaborati come parte della pagina.

Per ulteriori informazioni, vedere le seguenti risorse.

Risorsa	Descrizione
Cenni preliminari sugli attacchi tramite script	Viene descritto come salvaguardarsi da attacchi tramite script e istruzioni SQL.

Attacchi di tipo probe

Gli utenti non autorizzati utilizzano 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 ulteriori informazioni, vedere le seguenti risorse.

Risorsa	Descrizione
Nozioni fondamentali sulla gestione delle eccezioni	Vengono descritte le forme di base di gestione delle eccezioni strutturata di tipo try/catch/finally
Suggerimenti per gestire le eccezioni	Vengono descritte le procedure consigliate per la gestione delle eccezioni.

Protezione delle 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, utilizzare SQL Server o un altro database basato su server in cui i file di dati non sono leggibili dal file system.

Per ulteriori informazioni sulla protezione dei dati di Access ed Excel, vedere le seguenti risorse.

Risorsa	Descrizione
Security Considerations and Guidance for Access 2007 (informazioni in lingua inglese)	Vengono descritte le tecniche di sicurezza disponibili per Access 2007, ad esempio crittografia dei file, amministrazione delle password, conversione dei database nei nuovi formati ACCDB e ACCDE e utilizzo di altre opzioni di sicurezza.
Overview of Security and Protection in Excel (informazioni in lingua inglese)	Viene descritto come controllare gli utenti che possono accedere e modificare i dati di Excel 2007.
Proteggere un database di Access e i relativi oggetti con la protezione a livello utente (MDB)	Per Access 2003, vengono fornite le istruzioni per implementare la sicurezza dei dati a livello di utente.
Understanding the Role of Workgroup Information Files in Access Security (informazioni in lingua inglese)	Vengono illustrati il ruolo e la relazione del file di informazioni sul gruppo di lavoro nella sicurezza di Access 2003.
Domande frequenti sulla sicurezza di Microsoft Access disponibili nell'area download	Versione scaricabile delle domande frequenti sulla sicurezza di Microsoft Access.
Risolvere i problemi relativi a sicurezza e protezione	Vengono fornite soluzioni a problemi comuni relativi alla sicurezza di Excel 2003.

Servizi aziendali

In COM+ è incluso un modello di sicurezza che si basa sugli account di Windows NT e sulla rappresentazione di processi e 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.

Per ulteriori informazioni, vedere le seguenti risorse.

Risorsa	Descrizione
COM+ Role-Based Security and the .NET Framework	Viene illustrato come integrare codice gestito con i servizi di sicurezza COM+.
Writing Serviced Components	Viene illustrato come utilizzare le classi nello spazio dei nomi EnterpriseServices per creare componenti serviti.

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 numerosi servizi del sistema operativo. L'utilizzo 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 ulteriori informazioni, vedere le seguenti risorse.

Risorsa	Descrizione
Interoperabilità con codice non gestito	Contiene argomenti in cui viene descritto come esporre componenti COM a .NET Framework e componenti .NET Framework a COM.
Interoperabilità COM avanzata	Contiene componenti avanzati relativi, ad esempio, ad assembly di interoperabilità primari, threading e marshaling personalizzato.