Quando si distribuiscono applicazioni Web (.net) in un ambiente di produzione, è meglio utilizzare la sicurezza integrata o è importante?
Mi sembra che se un hacker rompe il server Web, non importa davvero in quanto possono facilmente impersonare la macchina.
Pensieri?
Risposte:
Direi che ci sono solo due validi motivi per usare l'autenticazione SQL:
Per lo scenario che stai proponendo (l'host del web server è completamente compromesso) nulla può proteggerti. L'hacker può fare almeno sul server DB tutto ciò che il web server può fare . E direi che la difesa in profondità può insegnarti a ridurre al minimo la perdita in tal caso: ridurre i diritti DB dell'account utilizzato dal tuo server web al minimo indispensabile e nient'altro. In secondo luogo, assicurarsi che se l'host del server Web è compromesso, non può essere utilizzato per elevare i privilegi più alti dell'account del server Web (vale a dire, non esiste nessun altro servizio sull'host WWW che utilizza credenziali con privilegi più elevati sul DB rispetto all'account WWW). Questi sono principi di sicurezza di base e non hanno nulla a che fare con lo schema di autenticazione utilizzato.
Mentre sql auth vs windows auth non offre né un chiaro vantaggio nel tuo scenario, ci sono altri problemi da considerare:
Un'ultima nota: il protocollo TDS espone la password sql auth in chiaro sul traffico, ma di solito viene mitigata richiedendo la crittografia SSL del traffico.
Quindi perché vedi ancora host WWW sql auth che memorizzano la password in chiaro in web.config? Questi sono i cattivi sviluppatori / amministratori, non essere uno di loro.
msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx
technet.microsoft.com/en-us/library/ms189067.aspx
Se non usi SSPI, stai codificando il nome utente e la password nei file di origine.
Se stai codificando il nome utente e la password nei file di origine, tutti i tuoi dipendenti possono accedervi.
Questo è relativamente insicuro. Un ex dipendente scontento potrebbe utilizzare le informazioni in modo dannoso. Un visitatore potrebbe vedere il codice su uno schermo da qualche parte. Oppure il codice sorgente potrebbe accidentalmente uscire allo stato selvatico.
Il vantaggio di SSPI è che la password non viene mai archiviata da nessuna parte in chiaro.
Le altre risposte finora sono state buone, ma ne aggiungerò un'altra: la gestione.
Prima o poi, probabilmente finirai con più server SQL. La gestione dell'autenticazione SQL tra l'app e più server SQL diventa un po 'dolorosa, soprattutto quando si verificano problemi di sicurezza. Se si modifica una password di autenticazione di Windows una volta, cambia immediatamente su tutti i server. Se devi ruotare le password di autenticazione SQL, è più doloroso, al punto che probabilmente non lo farai affatto. Questo è un rischio per la sicurezza.
Non sono sicuro al 100% qui, ma penso che il punto principale sia che l'autenticazione SQL non sia sicura, quindi è meglio usare l'autenticazione di Windows. A seconda della configurazione dell'app, puoi anche archiviare le credenziali appropriate in un formato crittografato sul computer utilizzando l'autenticazione di Windows. Non credo sia davvero possibile con l'autenticazione SQL. Puoi offuscarlo, ma alla fine deve essere in chiaro.
Inoltre, solo perché un hacker può entrare in un server non significa che il gioco sia finito. Un hacker potrebbe ottenere il controllo di un processo senza privilegi, ma non fare nient'altro sul server. Ecco perché è importante non eseguire tutto come amministratore o sistema, ma invece utilizzare account di servizio con privilegi minimi.
La cosa migliore da fare è limitare ciò che possono fare se / quando entrano nel server web. Ciò significa garantire solo i diritti SQL richiesti per il funzionamento dell'applicazione. È molto più semplice assegnare i diritti DBO all'applicazione, ma rende il DB molto più vulnerabile in caso di attacco riuscito al server web.
Premetto tutto questo dicendo che sto assumendo che stai parlando di un web server interno sulla rete privata interna.
Cominciamo con l'imitazione della macchina. Se l'identità del pool di applicazioni è Network Service e non vi è alcuna rappresentazione nell'applicazione .NET, quindi sì, l'applicazione Web si connetterà al back-end SQL Server utilizzando l'account del computer della macchina. Ciò significherebbe che hai concesso l'accesso a detto account macchina. Microsoft CRM funziona in questo modo.
Tuttavia, se hai specificato un'identità, quell'account utente dovrà accedere a SQL Server. Sebbene tu abbia ragione nel dire che se un utente malintenzionato ha compromesso il server Web, hanno effettivamente lo stesso accesso dell'account identità, la verità è che l'utilizzo di un accesso a SQL Server non cambia nulla qui. Una volta che ho accesso, posso modificare l'applicazione Web per fare ciò che voglio e lo farà, al massimo le tue autorizzazioni di sicurezza sul back-end SQL Server.
Ora perché usare SSPI. Innanzitutto, non si utilizza un accesso basato su SQL Server. Ciò significa che Active Directory è l'unica fonte di sicurezza. Ciò significa che hai i normali mezzi di controllo per determinare l'accesso non valido. In secondo luogo, significa che a meno che non vi siano altre app che lo richiedono, è possibile lasciare il proprio SQL Server in modalità di autenticazione Windows. Ciò significa che non sono consentiti accessi a SQL Server. Ciò significa che qualsiasi attacco contro sa viene interrotto prima ancora che inizi. E infine, semplifica il recupero. Se si utilizza un accesso basato su SQL Server, sarà necessario estrarre l'accesso con SID e password crittografata. Se si utilizza un account utente basato su Windows come "account di servizio", quando si accede a un nuovo SQL Server, creando l'accesso,
La domanda è: "meglio"? A cui è difficile rispondere poiché si basa sul contesto, i valori e le priorità dell'interrogatore.
Personalmente, mi piace l'autenticazione SQL.
Ultimo punto: codifichi la tua classe di gestione connessione per provare ogni stringa di connessione, in questo modo puoi cambiare la password sulla prima in config, spingere la modifica fuori e passerà alla seconda connessione, quindi aggiorni la password su MSQL e il primo verrà usato di nuovo. È necessaria una modifica della configurazione finale per impostare la seconda password come la prima, pronta per la prossima volta.
Se gli utenti non modificheranno direttamente il database (tramite altri strumenti client come SQL Server Management Studio), in genere creerò un unico login SQL per l'applicazione e gli garantirò l'accesso necessario. A quel punto l'utente è limitato a ciò che può fare come consentito dall'interfaccia dell'app Web.