Sicurezza trasporto per il mirroring del database e i gruppi di disponibilità AlwaysOn (SQL Server)

Articolo
06/25/2013

La sicurezza del trasporto in SQL Server 2005 e versioni successive implica l'utilizzo dell'autenticazione e, facoltativamente, della crittografia dei messaggi scambiati tra i database. Per il mirroring del database e Gruppi di disponibilità AlwaysOn, l'autenticazione e la crittografia devono essere configurate nell'endpoint del mirroring del database. Per un'introduzione agli endpoint del mirroring di database, vedere Endpoint del mirroring del database (SQL Server).

Contenuto dell'argomento:

Autenticazione
Crittografia dei dati
Attività correlate

Autenticazione

L'autenticazione è il processo di verifica che un utente sia effettivamente colui che dichiara di essere. Per le connessioni tra endpoint del mirroring del database è necessaria l'autenticazione. Le richieste di connessione da parte del partner o del server di controllo del mirroring devono essere autenticate.

Il tipo di autenticazione utilizzata da un'istanza del server per il mirroring del database o Gruppi di disponibilità AlwaysOn è una proprietà dell'endpoint del mirroring del database. Per gli endpoint del mirroring del database sono disponibili due tipi di sicurezza del trasporto, ovvero l'autenticazione di Windows (Security Support Provider Interface) e l'autenticazione basata sul certificato.

Autenticazione di Windows

Con l'autenticazione di Windows, ogni istanza del server accede all'altra parte utilizzando le credenziali di Windows dell'account utente di Windows in cui è in esecuzione il processo. L'autenticazione di Windows potrebbe richiedere una configurazione manuale degli account di accesso, ad esempio:

Se le istanze di SQL Server è in esecuzione come servizi con lo sotto lo stesso account di dominio, non è richiesta alcuna configurazione aggiuntiva.
Se l'istanza di SQL Server è in esecuzione come servizi con diversi account di dominio, (in domini uguali o sicuri), è necessario creare l'accesso a ogni account in master in ognuna delle altre istanze del server e a quell'account di accesso devono essere garantite le autorizzazioni CONNECT sull'endpoint.
Se l'istanza di SQL Server è in esecuzione come account del servizio di rete, l'account di accesso di ogni account del computer (DomainName**\**ComputerName$) deve essere creato in master in ognuno degli altri server e a quell'account di accesso devono essere garantite le autorizzazioni CONNECT sull'endpoint. Ciò avviene in quanto un'istanza del server che è in esecuzione con l'account del servizio di rete esegue l'autenticazione utilizzando l'account di dominio del computer host.

[!NOTA]

Per un esempio di configurazione di una sessione di mirroring del database tramite l'autenticazione di Windows, vedere Esempio: Impostazione del mirroring del database tramite l'autenticazione di Windows (Transact-SQL).

Certificati

In alcuni casi, ad esempio quando le istanze del server non si trovano in domini di tipo trusted oppure quando SQL Server è in esecuzione come servizio locale, l'autenticazione di Windows non è disponibile. In tali casi al posto delle credenziali utente per l'autenticazione delle richieste di connessione sono necessari certificati. L'endpoint del mirroring di ogni istanza del server deve essere configurato con il proprio certificato creato localmente.

Il metodo di crittografia viene stabilito al momento della creazione del certificato. Per ulteriori informazioni, vedere Impostazione dell'endpoint del mirroring del database per l'utilizzo di certificati per le connessioni in uscita (Transact-SQL). Prestare attenzione nella gestione dei certificati utilizzati.

In un'istanza del server viene utilizzata la chiave privata del proprio certificato per stabilire la propria identità durante la configurazione di una connessione. Nell'istanza del server che riceve la richiesta di connessione viene utilizzata la chiave pubblica del certificato del mittente per autenticare l'identità del mittente. Considerare, ad esempio, due istanze del server, Server_A e Server_B. In Server_A viene utilizzata la propria chiave privata per crittografare l'intestazione di connessione prima di inviare una richiesta di connessione a Server_B. Server_B utilizza la chiave pubblica del certificato di Server_A per decrittografare l'intestazione di connessione. Se l'intestazione decrittografata è corretta, Server_B sa che l'intestazione è stata crittografata da Server_A e la connessione viene autenticata. Se l'intestazione decrittografata non è corretta, Server_B sa che la richiesta di connessione non è autentica e rifiuta la connessione.

Crittografia dei dati

Per impostazione predefinita, un endpoint del mirroring del database richiede la codifica dei dati inviati in connessioni per il mirroring. In questo caso, l'endpoint può connettersi solo a endpoint che utilizzano la crittografia. A meno che non si sia assolutamente certi della sicurezza della rete, per le connessioni per il mirroring del database è consigliabile richiedere la crittografia. È tuttavia possibile disabilitare la crittografia oppure fare in modo che sia supportata ma non necessaria. Se la crittografia viene disabilitata, i dati non vengono mai crittografati e l'endpoint non può connettersi ad altri endpoint che la richiedono. Se la crittografia è supportata, i dati vengono crittografati solo se l'endpoint opposto supporta o richiede la crittografia.

[!NOTA]

Gli endpoint del mirroring creati da SQL Server Management Studio vengono creati con la crittografia impostata come richiesta o disabilitata. Per impostare il valore SUPPORTED per la crittografia, utilizzare l'istruzione Transact-SQL ALTER ENDPOINT. Per ulteriori informazioni, vedere ALTER ENDPOINT (Transact-SQL).

Facoltativamente, è possibile controllare gli algoritmi di crittografia che possono essere utilizzati da un endpoint specificando uno dei valori seguenti per l'opzione ALGORITHM in un'istruzione CREATE ENDPOINT o ALTER ENDPOINT:

Valore di ALGORITHM	Descrizione
RC4	Specifica che l'endpoint deve utilizzare l'algoritmo RC4. Questa è l'impostazione predefinita. [!NOTA] L'algoritmo RC4 è deprecato. Questa funzionalità verrà rimossa a partire da una delle prossime versioni di Microsoft SQL Server. Non utilizzare questa funzionalità in un nuovo progetto di sviluppo e modificare non appena possibile le applicazioni in cui è attualmente implementata. È consigliabile utilizzare AES.
AES	Specifica che l'endpoint deve utilizzare l'algoritmo AES.
AES RC4	Specifica che due endpoint eseguiranno la negoziazione di un algoritmo di crittografia con l'endpoint corrente, dando la priorità all'algoritmo AES.
RC4 AES	Specifica che due endpoint eseguiranno la negoziazione di un algoritmo di crittografia con l'endpoint corrente, dando la priorità all'algoritmo RC4.

Se gli endpoint che stabiliscono la connessione specificano entrambi gli algoritmi ma in ordine diverso, avrà la priorità l'endpoint che accetta la connessione.

[!NOTA]

L'algoritmo RC4 è supportato solo per motivi di compatibilità con le versioni precedenti. È possibile crittografare il nuovo materiale utilizzando RC4 o RC4_128 solo quando il livello di compatibilità del database è 90 o 100. (Non consigliato.) Utilizzare un algoritmo più recente, ad esempio uno degli algoritmi AES. In SQL Server 2012 il materiale crittografato utilizzando RC4 o RC4_128 può essere decrittografato in qualsiasi livello di compatibilità.

Sebbene notevolmente più veloce rispetto all'algoritmo AES, RC4 è relativamente vulnerabile, mentre AES è relativamente avanzato. È quindi consigliabile utilizzare l'algoritmo AES.

Per informazioni sulla sintassi Transact-SQL per la definizione della crittografia, vedere CREATE ENDPOINT (Transact-SQL).