Configurare e gestire la sicurezza dei database SQL di Azure per il ripristino geografico o il failover

  • Articolo

Si applica a:database SQL di Azure

Questo articolo descrive i requisiti di autenticazione per configurare e controllare la replica geografica attiva e i gruppi di failover automatico. Fornisce inoltre i passaggi necessari per configurare l’accesso utente al database secondario. Infine, descrive anche come abilitare l’accesso al database ripristinato dopo il ripristino geografico. Per altre informazioni sulle opzioni di ripristino, vedere Continuità aziendale del database SQL di Azure.

Ripristino di emergenza con utenti indipendenti

A differenza degli utenti tradizionali per i quali deve essere eseguito il mapping agli account di accesso nel database master, un utente indipendente viene gestito completamente dal database stesso. Questo approccio presenta due vantaggi. Nello scenario di ripristino di emergenza, gli utenti possono continuare a connettersi al nuovo database primario o al database ripristinato con il ripristino geografico senza alcuna configurazione aggiuntiva, perché il database gestisce gli utenti. Dal punto di vista dell’accesso, questa configurazione offre anche vantaggi a livello di scalabilità e prestazioni. Per altre informazioni, vedere Utenti di database indipendente: rendere portabile un database.

Il compromesso principale è rappresentato dal fatto che il processo di ripristino di emergenza su vasta scala è più complesso da gestire. Quando si dispone di più database che usano lo stesso account di accesso, la gestione delle credenziali usate dagli utenti indipendenti in più database può annullare il vantaggio rappresentato dagli utenti indipendenti. Ad esempio, i criteri di rotazione delle password richiedono l’applicazione coerente delle modifiche in più database anziché la modifica singola della password per l’accesso nel database master. Per questo motivo, l’uso degli utenti indipendenti non è consigliato in presenza di molti database che usano lo stesso nome utente e la stessa password.

Come configurare gli account di accesso e gli utenti

Se si usano account di accesso e utenti tradizionali, invece di utenti indipendenti, è necessario eseguire altri passaggi per assicurare che nel database master siano presenti gli stessi account di accesso. Le sezioni seguenti illustrano i passaggi da eseguire, oltre a considerazioni aggiuntive.

Nota

È anche possibile usare gli account di accesso creati da Microsoft Entra ID (in precedenza, Azure Active Directory) per gestire i database. Per altre informazioni, vedere Accessi e utenti di SQL di Azure.

Impostare l’accesso utente a un database secondario o ripristinato

Per fare in modo che il database secondario sia utilizzabile come database secondario di sola lettura e per garantire l’accesso appropriato al nuovo database primario o al database ripristinato con il ripristino geografico, è necessario che nel database master del server di destinazione sia presente la configurazione di sicurezza appropriata prima del ripristino.

Le autorizzazioni specifiche per ogni passaggio sono descritte più avanti in questo argomento.

La preparazione dell’accesso utente a un database secondario con replica geografica deve essere eseguita durante la configurazione della replica geografica. La preparazione dell’accesso utente ai database ripristinati con il ripristino geografico deve essere eseguita in qualsiasi momento quando il server originale è online, ad esempio nel contesto dell’analisi del ripristino di emergenza.

Nota

Se si esegue il failover o il ripristino geografico in un server che non presenta account di accesso configurati adeguatamente, l’accesso sarà limitato all’account amministratore del server.

La configurazione degli account di accesso nel server di destinazione prevede i tre passaggi seguenti:

1. Determinare gli account di accesso che possono accedere al database primario

Il primo passaggio della procedura consiste nel determinare quali account di accesso devono essere duplicati nel server di destinazione. A questo scopo, è necessario usare una coppia di istruzioni SELECT, una nel database master logico nel server di origine e una nel database primario stesso.

Solo l’amministratore del server o un membro del ruolo del server LoginManager può determinare gli account di accesso nel server di origine con l’istruzione SELECT seguente.

SELECT [name], [sid]
FROM [sys].[sql_logins]
WHERE [type_desc] = 'SQL_Login'

Solo un membro del ruolo del database db_owner, l’utente dbo o l’amministratore del server può determinare tutte le entità utente nel database primario.

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

2. Trovare il SID degli account di accesso individuati nel passaggio 1

Confrontando l’output delle query illustrate nella sezione precedente e trovando una corrispondenza per i SID, è possibile eseguire il mapping dell’account di accesso del server all’utente del database. Gli account di accesso che hanno un utente del database con un SID corrispondente hanno anche l’accesso utente a quel database come entità utente.

La query seguente può essere usata per visualizzare tutte le entità utente e i relativi SID in un database. Questa query può essere eseguita solo da un membro del ruolo del database db_owner o dall’amministratore del server.

SELECT [name], [sid]
FROM [sys].[database_principals]
WHERE [type_desc] = 'SQL_USER'

Nota

Gli utenti INFORMATION_SCHEMA e sys avranno SID NULL, mentre il SID guest è 0x00. Il SID dbo può iniziare con 0x01060000000001648000000000048454 se il database è stato creato dall’amministratore del server invece che da un membro di DbManager.

3. Creare gli account di accesso nel server di destinazione

L’ultimo passaggio consiste nel generare gli account di accesso con i SID appropriati nel server o nei server di destinazione. La sintassi di base è la seguente.

CREATE LOGIN [<login name>]
WITH PASSWORD = '<login password>',
SID = 0x1234 /*replace 0x1234 with the desired login SID*/

Non creare un nuovo account di accesso con il SID amministratore del server dall’origine nel server di destinazione. Rendere invece l’amministratore del server di destinazione un’entità di database nel database, ad esempio db_owner o utente.

Nota

Se si vuole concedere l’accesso utente al database secondario, ma non al database primario, è possibile modificare l’account di accesso utente nel server primario usando la sintassi seguente.

ALTER LOGIN [<login name>] DISABLE

DISABLE non modifica la password, pertanto è sempre possibile abilitare l’accesso, se necessario.

Passaggi successivi