Configurare la sicurezza per SQL Server log shipping

Articolo
06/20/2023

Questo articolo descrive come configurare la sicurezza per SQL Server log shipping e fornisce informazioni sul problema che può verificarsi durante la configurazione della sicurezza per SQL Server log shipping.

Versione originale del prodotto: SQL Server
Numero KB originale: 321247

Riepilogo

Questo articolo fornisce informazioni su come configurare la sicurezza per il log shipping. Esistono diversi problemi da considerare quando si configura la sicurezza per SQL Server log shipping che vanno dall'account di avvio per SQL Server condividere le autorizzazioni per la condivisione di rete in cui si trovano i backup del log delle transazioni. Questi problemi sono descritti in questo articolo.

Account di dominio

Se è stato inserito SQL Server in un dominio, Microsoft consiglia di usare un account di dominio per avviare SQL Server servizi. È consigliabile usare un account di dominio se si intende configurare SQL Server per l'esecuzione come server virtuale in Clustering Windows. Un account di dominio offre il vantaggio di una manutenzione minima in caso di modifiche delle password. Tuttavia, potrebbe non essere possibile avviare SQL con un account di dominio se SQL Server risiede in un server che si trova in un gruppo di lavoro.

Account di rete locale

È possibile usare SQL Server per iniziare con un account di rete creato in locale. Nella situazione in cui è richiesto l'accesso alla rete da un processo di SQL Server, come nel caso in cui sia stato configurato SQL Server per l'uso del log shipping, è possibile usare la sicurezza pass-through di rete. Con la sicurezza pass-through, tutti i computer a cui si accederà da SQL Server devono avere lo stesso account di rete con la stessa password e le autorizzazioni appropriate, configurate in locale. Inoltre, quando il processo di SQL Server richiede risorse dal secondo computer, la sicurezza di rete tradizionale viene ignorata se lo stesso account (con cui viene avviato il servizio SQL Server richiedente) esiste con la stessa password. Finché l'account nel secondo computer è configurato con l'autorizzazione sufficiente per eseguire l'attività richiesta chiamando SQL Server, l'attività avrà esito positivo.

Account di sistema locale

È anche possibile configurare SQL Server per l'avvio con l'account di sistema locale. La modifica della password per l'account LocalSystem può causare l'errore di alcuni servizi critici per la stabilità del sistema. Questo account è locale per il computer in cui si trova, il che significa che il contesto di sicurezza usato da SQL Server servizi è locale. Come indicato nella sezione Account di rete locale, non è possibile usare la sicurezza pass-through di rete quando si avvia SQL Server con l'account LocalSystem perché le password per l'account LocalSystem in computer diversi sono diverse. L'avvio di SQL Server in questo account quando è richiesto l'accesso alle risorse di rete comporterà molto probabilmente il completamento delle attività non riuscito.

Per informazioni sui diritti minimi necessari per avviare ed eseguire correttamente un account di rete SQL Server e i servizi SQL Server Agent, vedere Configurazione degli account del servizio Windows.

Informazioni sul modello di sicurezza SQL Server

Per comprendere completamente le implicazioni per la sicurezza, è importante comprendere il modello di sicurezza implementato da Microsoft in SQL Server 2000. Quando si crea un account di accesso, viene aggiunto alla syslogins tabella nel database MASTER. Per ogni database a cui viene fornito l'accesso appena aggiunto, viene aggiunto alla sysusers tabella del database. Il mapping tra syslogins tabella e sysusers tabella si trova nel campo SID.

Se un database utente viene spostato in un server diverso, i valori SID vengono trasferiti dal server precedente. La sicurezza del database si interrompe quando gli account di accesso nel secondo server non vengono creati con gli stessi valori SID o se la sicurezza non è configurata in modo corretto a causa di valori SID non corrispondenti.

Per altre informazioni, vedere Come risolvere i problemi di autorizzazione quando si sposta un database tra server che eseguono SQL Server.

Requisiti di protezione

Condivisione di backup

Configurare la condivisione di rete configurata per contenere i backup del log delle transazioni in modo che dispongano delle autorizzazioni di lettura/modifica per l'account con cui vengono avviati i servizi SQL Server (nel server secondario configurato per il log shipping).

La condivisione di rete configurata per contenere i backup del log delle transazioni deve essere configurata per avere autorizzazioni di lettura/modifica per l'account con cui vengono avviati i servizi SQL Server nel server secondario configurato per il log shipping. Questa condivisione è accessibile dal processo di copia nel server secondario per copiare i backup del log delle transazioni nella cartella locale nel rispettivo server secondario. Il processo di caricamento carica quindi questi backup dalla cartella locale.
Cross Domain Log Shipping

Se i computer che eseguono SQL Server vengono inseriti in un ambiente multidominio, Microsoft consiglia di configurare trust bidirezionali tra tutti i domini coinvolti nel log shipping. Tuttavia, se non è possibile stabilire trust tra domini, è possibile usare la sicurezza pass-through di rete per il log shipping. Fare riferimento alla sezione di questo articolo che illustra l'opzione di avvio dell'account di rete LocalSystem per i servizi correlati SQL Server.
Selezione della modalità di autenticazione per connettersi al server di monitoraggio

È possibile selezionare autenticazione di Windows o l'autenticazione SQL (da server primari e secondari) per connettersi al server di monitoraggio e aggiornare le tabelle di monitoraggio. È possibile selezionarlo durante la configurazione del log shipping o dopo aver configurato il log shipping ed è funzionale. Per impostazione predefinita, SQL Server usa autenticazione di Windows. Tuttavia, se si seleziona l'autenticazione SQL, viene creato un nuovo log_shipping_monitor_probe di accesso SQL nei server primario, secondario e di monitoraggio, se non esiste. Se si seleziona l'autenticazione SQL a questo scopo, configurare SQL Server per l'uso dell'opzione SQL e autenticazione di Windows.

Configurazione della sicurezza nel server secondario per i database standby

Se si configura il database secondario in modalità standby, è possibile accedere a questo database in sola lettura. Ripristinando il database secondario in questa modalità, questo può fornire un modo per eseguire i report offline, scaricando così parte del lavoro dal sistema di produzione. Tuttavia, per consentire al database di standby di supportare la funzionalità di sola lettura, potrebbe essere necessario applicare le stesse impostazioni di sicurezza nel server secondario. Poiché il database è in stato di standby, non è nemmeno possibile apportare modifiche ai fini della configurazione della sicurezza. In questo caso, è necessario creare tutti gli account di accesso SQL Server con gli stessi valori SID nel server secondario. Gli account di accesso di Windows mantengono automaticamente gli stessi SID perché il GUID di Windows è univoco a livello globale, anche quando si usano più domini.

Per altre informazioni su come creare account di accesso SQL con lo stesso SID in server diversi, vedere Come concedere l'accesso agli account di accesso SQL in un database di standby quando il guest è disabilitato in SQL Server.

Configurazione della sicurezza durante l'esecuzione della modifica del ruolo

La procedura di modifica del ruolo per il log shipping prevede la promozione di un server secondario come server primario. È possibile eseguire questa operazione con o senza che il server primario sia online. Come parte della modifica del ruolo, vengono eseguite fino a quattro stored procedure. Una di queste stored procedure, sp_resolve_logins , consente di correggere i valori SID per gli account di accesso che risiedono nel database di standby poco prima che vengano resi disponibili per l'uso come database primario.

Come parte di questa stored procedure, un .bcp file della syslogins tabella del server primario precedente viene caricato in una tabella temporanea. Ogni account di accesso presente in questa tabella temporanea viene quindi confrontato con la syslogins tabella nel database MASTER del server secondario e con la sysusers tabella del database secondario. Per ogni account di accesso nella tabella temporanea con un account di accesso con lo stesso nome nella syslogins tabella e lo stesso SID di quello nella sysusers tabella del database secondario, il SID viene corretto (nel database secondario) usando sp_change_users_login per trovare la corrispondenza con quello presente nella syslogins tabella.

La configurazione della sicurezza tramite questa stored procedure richiede quanto segue:

Gli account di accesso SQL devono essere già creati nel server secondario. A tale scopo, usare l'attività DTS Trasferisci account di accesso illustrata nell'argomento SQL Server Documentazione online: Come configurare ed eseguire la modifica del ruolo di log shipping.
È necessario fornire un .bcp file della syslogins tabella dal server primario. Questo file deve essere corrente perché un file non aggiornato potrebbe causare un errore di sp_resolve_logins correzione degli account di accesso.

Prima di poter correggere gli account di accesso nel database secondario, è necessario soddisfare le tre condizioni sp_resolve_logins seguenti:

Il nome dell'account di accesso dal .bcp file della syslogins tabella deve corrispondere al nome nella syslogins tabella dal server primario.
Il valore SID deve corrispondere tra l'account di accesso del .bcp file e la sysusers tabella nel database secondario.
Il valore SID del database secondario deve essere diverso dal valore SID nella syslogins tabella nel database MASTER nel server secondario.

Se si creano account di accesso SQL Server come descritto in Q303722, non è necessario eseguire questa stored procedure perché tutti gli account di accesso sono già stati presentati con lo stesso valore SID nella syslogins tabella (nel database MASTER nel server secondario) e nella sysusers tabella (nel database secondario).

Domande frequenti

Domanda: Il log shipping propaga automaticamente le modifiche correlate alla sicurezza a un server secondario?

Risposta: sì. Poiché tutte le modifiche apportate alle tabelle di sistema sono operazioni registrate, queste vengono propagate automaticamente al server secondario (o ai server).
Domanda: È possibile avere due account di accesso nel server secondario con lo stesso SID? È necessario perché si usa lo stesso computer SQL Server per gestire più database di standby da più server.

Risposta: No. SQL Server modello di sicurezza non consente di avere due account di accesso con lo stesso SID. Se si verifica un conflitto nel SID durante l'uso del log shipping con più server, l'unico modo per correggere questo problema consiste nell'eliminare l'account di accesso in conflitto nel server primario e quindi crearlo con un SID che non esiste nel server secondario.