Procedure consigliate per la sicurezza della replica

Si applica a:SQL ServerIstanza gestita di Azure SQL

La replica implica lo spostamento di dati in ambienti distribuiti che includono reti Intranet in un singolo dominio, applicazioni che accedono a dati tra domini non attendibili e Internet. È importante individuare l'approccio migliore per la protezione delle connessioni di replica in queste diverse circostanze.

Le informazioni seguenti sono applicabili alla replica in qualsiasi ambiente:

• Crittografare le connessioni tra computer in una topologia di replica usando un metodo standard, ad esempio le reti private virtuali (VPN, Virtual Private Network), TLS (Transport Layer Security), noto in precedenza come SSL (Secure Sockets Layer) o lo standard di sicurezza IP (IPSec). Per altre informazioni, vedere Abilitare connessioni crittografate al motore di database (Gestione configurazione SQL Server). Per informazioni sull'uso di VPN e TLS per la replica dei dati tramite Internet, vedere Protezione della replica su Internet.

  Se si usa TLS 1.2 per proteggere le connessioni tra computer in una topologia di replica, specificare il valore 1 o 2 per il parametro -EncryptionLevel di ogni agente di replica (è consigliabile usare il valore 2 ). Il valore 1 specifica che viene usata la crittografia, ma l'agente non verifica che il certificato del server TLS/SSL sia firmato da un'autorità di certificazione attendibile; Il valore 2 specifica che il certificato viene verificato. Istanza gestita di SQL di Azure supporta TLS 1.3 per le connessioni tra istanze specificando il valore 3 e le connessioni a SQL Server da Istanza gestita di SQL di Azure specificando il valore 4.

  Per informazioni sul lavoro con gli agenti, consultare:

  • Visualizzare e modificare i parametri del prompt dei comandi dell'agente di replica (SQL Server Management Studio)

  • Usare i profili dell'Agente di Replicazione

  • Concetti sugli eseguibili dell'agente di replica

• Eseguire ogni agente di replica con un diverso account di Windows e utilizzare l'autenticazione di Windows per tutte le connessioni agli agenti di replica. Per altre informazioni sulla specifica degli account, vedere Controllo di identità e accesso per la replica.

• Concedere agli agenti solo le autorizzazioni necessarie. Per altre informazioni, vedere la sezione "Autorizzazioni richieste dagli agenti" del modello di sicurezza dell'agente di replica.

• Verificare che tutti gli account degli agenti di merge e di distribuzione siano inclusi nell'elenco di accesso alla pubblicazione. Per ulteriori informazioni, vedere Proteggere l'editore.

• Attenersi al principio dei privilegi minimi, concedendo agli account nell'elenco di accesso alla pubblicazione solo le autorizzazioni necessarie per eseguire le attività di replica. Non aggiungere gli account di accesso ad alcun ruolo predefinito del server che non sia necessario per la replica.

• Configurare la condivisione snapshot in modo da consentire l'accesso in lettura a tutti gli agenti di merge e di distribuzione. Se vengono utilizzati snapshot per pubblicazioni con filtri con parametri, verificare che ogni cartella sia configurata per l'accesso in lettura solo per gli account degli agenti di merge appropriati.

• Configurare la condivisione snapshot per consentire l'accesso in scrittura all'agente snapshot.

• Se si utilizzano sottoscrizioni pull, inserire la cartella snapshot in una condivisione di rete anziché in un percorso locale.

Se nella topologia di replica sono inclusi computer di domini diversi o di domini che non hanno relazioni di trust, è possibile utilizzare l'autenticazione di Windows o l'autenticazione di SQL Server per le connessioni eseguite dagli agenti. Per ulteriori informazioni sui domini, vedere la documentazione di Windows. È consigliabile, dal punto di vista della sicurezza, utilizzare l'autenticazione di Windows.

• Per utilizzare l'autenticazione di Windows:

  • Aggiungere un account di Windows locale (non un account di dominio) per ogni agente nei nodi appropriati, utilizzando lo stesso nome e password per ogni nodo. Ad esempio, l'agente di distribuzione per una sottoscrizione push viene eseguito nel server di distribuzione e stabilisce connessioni al server di distribuzione e al Sottoscrittore. L'account di Windows per l'agente di distribuzione deve essere aggiunto al server di distribuzione e al Sottoscrittore.

  • Verificare che un determinato agente, ad esempio l'agente di distribuzione per una sottoscrizione, venga eseguito con lo stesso account in ogni computer.

• Per utilizzare autenticazione di SQL Server:

  • Aggiungere un account di SQL Server per ogni agente nei nodi appropriati, utilizzando lo stesso nome e password per ogni nodo. Ad esempio, l'agente di distribuzione per una sottoscrizione push viene eseguito nel server di distribuzione e stabilisce connessioni al server di distribuzione e al Sottoscrittore. L'account di SQL Server per l'agente di distribuzione deve essere aggiunto al server di distribuzione e al Sottoscrittore.

  • Verificare che un determinato agente, ad esempio l'agente di distribuzione per una sottoscrizione, stabilisca connessioni utilizzando lo stesso account in ogni computer.

  • Nei casi in cui è necessaria l'autenticazione di SQL Server, l'accesso alle condivisioni snapshot UNC spesso non è disponibile, ad esempio, può essere bloccato da un firewall. In tal caso, è possibile trasferire lo snapshot ai Sottoscrittori tramite FTP. Per altre informazioni, vedere Trasferire snapshot tramite FTP.

Migliorare la postura di sicurezza con la chiave maestra del database

Quando si usa l'autenticazione di SQL Server per la replica, i segreti forniti quando si configura la replica vengono archiviati all'interno di SQL Server, in particolare nel database di distribuzione e, per le sottoscrizioni pull, anche nel database sottoscrittore.

Per migliorare il comportamento di sicurezza per la replica, prima di iniziare a configurare la replica:

• Creare una chiave master del database (DMK) nel database di distribuzione del server che ospita il Distributore.
• Per le sottoscrizioni pull, creare anche una DMK nel database dell'abbonato.

Se la replica è stata creata prima di DMK, creare prima DMK e quindi aggiornare i segreti di replica aggiornando le password per i processi di replica. È possibile aggiornare il processo con la stessa password oppure usare una nuova password.

Per aggiornare i segreti di replica, usare una delle stored procedure pertinenti seguenti per aggiornare le password per i processi di replica:

• sp_changelogreader_agent
• sp_changesubscriber
• sp_changedistpublisher
• sp_changepublication_snapshot

La configurazione della replica transazionale senza DMK può generare un avviso 14130 di SQL Server in:

• Istanza SQL gestita di Azure
• SQL Server 2022 CU18 e versioni successive
• SQL Server 2019 CU31 e versioni successive

Contenuto correlato

• Abilitare connessioni crittografate al motore di database (Gestione configurazione SQL Server)
• Replica su Internet
• Proteggere il Sottoscrittore
• Proteggere il server di distribuzione
• Proteggere il server di pubblicazione
• Visualizzare e modificare le impostazioni di sicurezza della replica