Utente AD utente vs Utente SQL per l'autenticazione di SQL Server

Idealmente, l'utente o l'applicazione che accede a SQL Server deve utilizzare l'insieme di credenziali che li identifica correttamente e che è stato assegnato il livello appropriato di accesso a SQL Server e / o ai database secondo necessità per eseguire azioni che devono eseguire.

L'autenticazione SQL è un meccanismo di autenticazione legacy che in un ambiente correttamente configurato non dovrebbe essere abilitato affatto. Microsoft non lo consiglia e la dissociazione tra l'identità di l'utente o l'applicazione dal contesto di autenticazione è solo negativo, dal punto di vista della sicurezza.

Stabilito che sei certamente corretto che un'applicazione non deve accedere a un database nel contesto di un account di amministratore di dominio o server. L'applicazione web deve essere eseguita con un account che disponga delle autorizzazioni necessarie per eseguire le funzioni dell'applicazione Web (incluso l'accesso appropriato ai database necessari per funzionare) e non più.

In definitiva, questa non è una questione dell'autenticazione di AC vs SQL, ma dell'uso (o della sua mancanza) di account ad uso limitato o della violazione del principio di privilegio minimo. Il fatto che non stiano utilizzando l'autenticazione SQL non è un problema, ed è in effetti il design corretto. Il fatto che gli account AD abbiano privilegi eccessivi, d'altra parte, è come hai notato, un problema serio e uno che dovrebbe essere affrontato.

L'utilizzo di Active Directory per SQL Server presenta numerosi vantaggi, il che lo rende l'approccio consigliato. Gli amministratori di database SQL spesso desiderano avere il database solo in modalità di autenticazione integrata di Windows (WIA) (anziché "modalità mista" in cui è supportata anche l'autenticazione SQL) a causa di questo:

• Quando si utilizza AD, l'autenticazione dell'account è centralizzata. Hai una panoramica di tutti gli account che esistono nell'ambiente. Se un account è compromesso, è necessario revocarlo solo una volta: in AD. Con l'autenticazione SQL, dovrai accedere a ogni server SQL e rimuoverlo.
• Quando si utilizza AD, la rotazione della password (se necessario) è centralizzata. Con l'autenticazione SQL, dovrai accedere e modificare la password su ogni target (il che spesso significa che non lo farai).
• Quando si utilizza AD, le password vengono archiviate in un unico repository centrale. Con l'autenticazione SQL, sono memorizzati nel database SQL stesso. L'Hardening AD è in genere molto più semplice di un hardening di SQL Server poiché il vettore di attacco verso i server SQL è generalmente più grande (sì, questo è specifico del caso).
• Quando si utilizza AD, l'autenticazione viene eseguita in modo più sicuro (utilizzando Kerberos). Ciò rende più difficile per qualsiasi avversario tentare di catturare la password, ed è molto meno incline agli attacchi Man In The Middle (MITM). Inoltre, diversamente dalle password, i ticket Kerberos non possono essere riutilizzati rispetto ad altri servizi: ogni ticket è specifico per un servizio (in questo caso, per un singolo servizio SQL Server). L'autenticazione con un altro servizio richiede l'ottenimento di un nuovo ticket.
• Quando si utilizza WIA, la gestione degli account per accedere a un server SQL in genere richiede solo la concessione delle autorizzazioni a un account di runtime (servizio) (l'account con cui è in esecuzione un server delle applicazioni). Non è necessario creare account aggiuntivi come si farebbe con l'autenticazione SQL. Ciò centralizza anche l'analisi dell'impatto: se un server IIS viene compromesso, è necessario revocare l'account del servizio IIS per attenuare il rischio. Con l'autenticazione SQL, è necessario cercare nella configurazione l'account di autenticazione SQL utilizzato da quel server IIS.
• Quando si utilizza WIA, i server delle applicazioni non devono memorizzare l'ID utente e la password per le loro connessioni. Di nuovo, questo riduce l'impatto di un sistema compromesso.
• Quando si utilizza WIA, è possibile disabilitare gli accessi remoti. Questo non è possibile con gli account con autenticazione SQL.

Quando si concede a un utente l'accesso a un database, ci sono alcune considerazioni da fare con vantaggi e svantaggi in termini di usabilità e sicurezza. Qui abbiamo due opzioni per l'autenticazione e la concessione dell'autorizzazione agli utenti. Il primo è dare a tutti l'accesso all'account di sa (amministratore di sistema) e quindi limitare manualmente le autorizzazioni mantenendo un elenco degli utenti in cui è possibile concedere o negare le autorizzazioni in base alle esigenze. Questo è anche noto come metodo di autenticazione SQL. Ci sono grossi difetti di sicurezza in questo metodo, come elencato di seguito. La seconda e migliore opzione consiste nel disporre di Active Directory (AD) per gestire tutte le autorizzazioni e le autorizzazioni necessarie, note anche come autenticazione di Windows. Una volta che l'utente si collega al proprio computer, l'applicazione si connetterà al database utilizzando quelle credenziali di accesso di Windows sul sistema operativo.

Il principale problema di sicurezza con l'utilizzo dell'opzione SQL è che viola il principio di privilegio minimo (POLP) che è quello di fornire all'utente le autorizzazioni assolutamente necessarie di cui hanno bisogno e non di più. Usando l'account sa si presentano seri problemi di sicurezza. Il POLP viene violato perché quando l'applicazione utilizza l'account sa ha accesso all'intero server del database. L'autenticazione di Windows d'altra parte segue il POLP semplicemente concedendo l'accesso a un database sul server.

Il secondo problema è che non è necessario che ogni istanza dell'applicazione abbia la password di amministratore. Ciò significa che qualsiasi applicazione è un potenziale punto di attacco per l'intero server. Windows utilizza solo le credenziali di Windows per accedere a SQL Server. Le password di Windows sono archiviate in un repository rispetto all'istanza del database SQL stesso e l'autenticazione avviene internamente a Windows senza dover memorizzare le password sull'applicazione.

Un terzo problema di sicurezza si presenta utilizzando il metodo SQL che coinvolge le password. Come presentato sul sito Web di Microsoft e su vari forum di sicurezza, il metodo SQL non "applica la modifica della password o la crittografia, ma viene inviato come testo in chiaro sulla rete. E il metodo SQL non si blocca dopo i tentativi falliti, consentendo in tal modo un prolungato tentativo di intromissione. Tuttavia, Active Directory utilizza il protocollo Kerberos per crittografare le password mentre impiega anche un sistema di modifica della password e blocco dopo tentativi falliti.

Vi sono anche svantaggi di efficienza. Dal momento che dovrai richiedere all'utente di inserire le credenziali ogni volta che vogliono accedere al database, gli utenti potrebbero dimenticare le loro credenziali.

Se un utente viene rimosso dovresti rimuovere le sue credenziali da ogni istanza dell'applicazione. Se è necessario aggiornare la password di amministratore sa, è necessario aggiornare ogni istanza del server SQL. Ciò è dispendioso in termini di tempo e pericoloso, lascia aperta la possibilità che un utente licenziato conservi l'accesso a SQL Server. Con il metodo Windows nessuno di questi problemi sorge. Tutto è centralizzato e gestito dall'AD.

Gli unici vantaggi dell'utilizzo del metodo SQL risiedono nella sua flessibilità. Puoi accedervi da qualsiasi sistema operativo e rete, anche da remoto. Alcuni vecchi sistemi legacy e alcune applicazioni basate sul web possono supportare solo un accesso sa.

Il metodo AD offre anche strumenti per risparmiare tempo come i gruppi per facilitare l'aggiunta e la rimozione degli utenti e la capacità di tracciamento degli utenti.

Anche se riesci a correggere questi difetti di sicurezza nel metodo SQL, dovresti reinventare la ruota. Quando si considerano i vantaggi di sicurezza forniti dall'autenticazione di Windows, comprese le politiche di password e seguendo il POLP, è una scelta molto migliore rispetto all'autenticazione SQL. Pertanto si consiglia vivamente di utilizzare l'opzione di autenticazione di Windows.