Le migliori pratiche per la connessione da ASP.NET a SQL Server? [chiuso]

Naviga le tue risposte
7

Esistono diversi modi per connettersi a SQL Server da un'applicazione ASP.NET. Sto lavorando alla ricostruzione di un ambiente ASP.NET / SQL Server in questo momento e sto cercando di capire quale metodo dovrei andare. Ecco le opzioni come le vedo io:

  • Connessione tramite SQL Server ID che è memorizzata in web.config. Pro: semplice. Contro: password in web.config; devi configurare in modo specifico l'ID di SQL Server.
  • Connessione tramite ID utente NT tramite rappresentazione di ASP.NET. Pro: nessuna password in web.config; controllo della sicurezza per utente a grana fine Contro: sovraccarico amministrativo della configurazione degli account utente in SQL Server; Il monitoraggio dell'applicazione SQL Server è distribuito su molti account.
  • Eseguire ASP.NET come ID NT personalizzato e disporre di tale ID NT configurato in SQL Server. Pro: connessione a SQL Server come un unico ID: semplice; nessuna password in web.config. Contro: complicato dal punto di vista della sicurezza. Configurare SPN personalizzati in Active Directory per l'autenticazione Kerberos .

Ci sono altre opzioni che mi mancano? Quale di queste opzioni sono utilizzate in quali situazioni? Quali sono più standard? Ci sono pro e contro che non sto pensando?

Si noti che il mio presupposto è che gli utenti si autenticano con ASP.NET tramite l'autenticazione integrata di Windows; questo è per un'applicazione intranet.

    
posta RationalGeek 23.02.2011 - 17:33
fonte

4 risposte

4

La prima opzione ha un'altra opzione, che è davvero molto buona:

  • Connessione tramite ID SQL Server crittografato e archiviato in web.config

Vedi questo per maggiori informazioni: link

    
risposta data 23.02.2011 - 18:36
fonte
1

Penso che tu abbia un errore nel terzo punto: puoi sicuramente permettere agli utenti di autenticarsi contro l'app e lasciare che l'app si autentichi contro il server DB e non devi mai configurare keberos o qualcosa di più complesso di un utente con nome account e pool di app personalizzate. Questo è davvero il modo di far volare IMHO in quanto non ci sono password e non ci sono problemi di crittografia o di gestione delle chiavi.

    
risposta data 23.02.2011 - 19:47
fonte
1

Mi è venuta l'idea di mettere le stringhe di connessione nel file machine.config in precedenza. Questo ha alcuni ovvi requisiti di sicurezza (es. Richiede che tu abbia fiducia in ogni singola app in esecuzione sul server - ma nel mio ambiente, lo facciamo).

In questo modo, puoi eliminarli completamente da web.config. Solo le persone con accesso amministrativo al server Web sarebbero in grado di accedere a quel file e visualizzare la stringa di connessione.

Il motivo principale per cui abbiamo voluto farlo, tuttavia, è stato per comodità: ci avrebbe impedito di mantenere due copie di web.config (debug + release) e ci consentirà di ruotare le password di SQL Server senza dover tocca ogni singola applicazione.

Tuttavia, in realtà non l'ho ancora fatto, quindi non posso parlare della sua redditività. Ma è sicuramente un'opzione.

    
risposta data 29.07.2011 - 03:01
fonte
-1

web.config 

<?xml version="1.0"?>
<configuration>
  <connectionStrings>
    <add name="SQLDbConnection"
         connectionString="Server=servername; Database=pubs; User Id=username; password=password"
         providerName="System.Data.SqlClient" />
  </connectionStrings>
</configuration>

Codice C # 

string connectionString = ConfigurationManager.ConnectionStrings["SQLDbConnection"].ToString();
SqlConnection connection = new SqlConnection(connectionString);
connection.Open();
Label1.Text = "Connected to Database Server !!";
connection.Close();

Sorgente completa ..... Asp.net Sql Connection

Naimer

    
risposta data 30.04.2014 - 07:59
fonte

Leggi altre domande sui tag

Devo caricare un cliente per gli errori che ho fatto? [duplicare] Buone pratiche per il collaudo di unità con apparecchi di grandi dimensioni o complessi?