Collegamento privato di Azure per database SQL di Azure e Azure Synapse Analytics
Si applica a: 
Database SQL di Azure Azure Synapse Analytics (solo pool SQL dedicati)
collegamento privato di Azure consente di connettersi a vari servizi PaaS in Azure tramite un endpoint privato. Per un elenco dei servizi PaaS che supportano la funzionalità Collegamento privato, visitare la pagina Documentazione di Collegamento privato. Un endpoint privato è un indirizzo IP privato all'interno di una rete virtuale e una subnet specifiche.
Importante
Questo articolo si applica sia a database SQL di Azure sia a pool SQL dedicato (in precedenza SQL DW) in Azure Synapse Analytics. Queste impostazioni si applicano a tutti i database SQL e pool SQL dedicati (in precedenza SQL DW) associati al server. Per semplicità, il termine 'database' fa riferimento a entrambi i database nel database SQL di Azure e in Azure Synapse Analytics. Analogamente, tutti i riferimenti a 'server' indicano il server logico che ospita il database SQL di Azure e i pool SQL dedicati (in precedenza SQL DW) in Azure Synapse Analytics. Questo articolo non si applica a Istanza gestita di SQL di Azure o ai pool SQL dedicati nelle aree di lavoro Azure Synapse Analytics.
Come configurare un collegamento privato
Processo di creazione
È possibile creare endpoint privati usando il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure:
Processo di approvazione
Dopo che l'amministratore di rete ha creato l'endpoint privato, l'amministratore di SQL può gestire la connessione dell'endpoint privato al database SQL.
Nel portale di Azure, passare alla risorsa del server.
Passare alla pagina di approvazione dell'endpoint privato:
- Nella risorsa SQL server, in Sicurezza, selezionare Rete. Selezionare la scheda Accesso privato.
- Nell'area di lavoro di Synapse, in Sicurezza nel menu delle risorse selezionare Connessioni endpoint privati.
La pagina mostra quanto segue:
- Un elenco di tutte le connessioni di endpoint privato
- Endpoint privati creati
Se non sono presenti endpoint privati, crearne uno usando il pulsante Crea un endpoint privato. Altrimenti, scegliere una singola connessione di endpoint privato dall'elenco.
L'amministratore di SQL può scegliere di approvare o rifiutare una connessione di endpoint privato e, facoltativamente, di aggiungere una breve risposta di testo.
Dopo l'approvazione o il rifiuto, l'elenco indicherà lo stato appropriato insieme al testo della risposta.
Infine, selezionare il nome dell'endpoint privato
Verrà visualizzata la pagina di panoramica dell'endpoint privato. Selezionare il collegamento Interfacce di rete per ottenere i dettagli dell'interfaccia di rete per la connessione all'endpoint privato.
La pagina Interfaccia di rete mostra l'indirizzo IP privato per la connessione all'endpoint privato.
Importante
Quando si aggiunge una connessione all'endpoint privato, il routing pubblico al server logico non è bloccato per impostazione predefinita. Nel riquadro Firewall e reti virtuali, l'impostazione Nega l'accesso alla rete pubblica non è selezionata per impostazione predefinita. Per disabilitare l’accesso alla rete pubblica, assicurarsi di selezionare Nega accesso alla rete pubblica.
Disabilitare l'accesso pubblico al server logico
Nel server SQL logico del database SQL di Azure, supponiamo di voler disabilitare tutti gli accessi pubblici al server logico e consentire le connessioni solo dalla rete virtuale.
Innanzitutto, assicurarsi che le connessioni dell'endpoint privato siano abilitate e configurate. Quindi, per disabilitare l'accesso pubblico al server logico:
Andare alla pagina Rete del server logico.
Selezionare la casella di spunta Nega accesso alla rete pubblica.
Testare la connettività al database SQL da una macchina virtuale di Azure nella stessa rete virtuale
Per questo scenario, supponiamo di aver creato una macchina virtuale (VM) di Azure che esegue una versione recente di Windows nella stessa rete virtuale dell'endpoint privato.
Avviare una sessione di Desktop remoto (RDP) e connettersi alla macchina virtuale.
È quindi possibile eseguire alcuni controlli di connettività di base per assicurarsi che la macchina virtuale si connetta al database SQL tramite l'endpoint privato usando gli strumenti seguenti:
- Telnet
- PsPing
- Nmap
- SQL Server Management Studio (SSMS)
Verificare la connettività con Telnet
Telnet Client è una funzionalità di Windows che può essere usata per testare la connettività. A seconda della versione del sistema operativo Windows, può essere necessario abilitare questa funzionalità in modo esplicito.
Aprire una finestra del prompt dei comandi dopo aver installato Telnet. Eseguire il comando Telnet e specificare l'indirizzo IP e l'endpoint privato del database nel database SQL.
telnet 10.9.0.4 1433
Se Telnet si connette correttamente, nella finestra di comando verrà visualizzata una schermata vuota, come mostrato nell'immagine seguente:
Usare il comando PowerShell per controllare la connettività:
Test-NetConnection -computer myserver.database.windows.net -port 1433
Verificare la connettività con PsPing
PsPing può essere usato come indicato di seguito per verificare che la connessione dell'endpoint privato sia in ascolto delle connessioni sulla porta 1433.
Eseguire PsPing nel modo seguente specificando il nome di dominio completo del server SQL logico e la porta 1433:
PsPing.exe mysqldbsrvr.database.windows.net:1433
Questo è un esempio dell'output previsto:
TCP connect to 10.9.0.4:1433:
5 iterations (warmup 1) ping test:
Connecting to 10.9.0.4:1433 (warmup): from 10.6.0.4:49953: 2.83ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49954: 1.26ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49955: 1.98ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49956: 1.43ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49958: 2.28ms
L'output mostra che Psping è riuscito a eseguire il ping dell'indirizzo IP privato associato alla connessione dell'endpoint privato.
Verificare la connettività con Nmap
Nmap (Network Mapper) è uno strumento gratuito e open source usato per l'individuazione della rete e il controllo di sicurezza. Per altre informazioni e per il collegamento di download, visitare: https://Nmap.org. È possibile usare questo strumento per assicurarsi che l'endpoint privato sia in ascolto delle connessioni sulla porta 1433.
Eseguire Nmap come indicato di seguito, specificando l'intervallo di indirizzi della subnet che ospita l'endpoint privato.
Nmap -n -sP 10.9.0.0/24
Questo è un esempio dell'output previsto:
Nmap scan report for 10.9.0.4
Host is up (0.00s latency).
Nmap done: 256 IP addresses (1 host up) scanned in 207.00 seconds
Il risultato mostra che un indirizzo IP è attivo, ossia quello corrispondente all'indirizzo IP dell'endpoint privato.
Verificare la connettività con SQL Server Management Studio (SSMS)
Nota
Usare il nome di dominio completo (FQDN) del server nelle stringhe di connessione per i client (<server>.database.windows.net). Eventuali tentativi di accesso effettuati direttamente all'indirizzo IP o tramite l'FQDN del collegamento privato (<server>.privatelink.database.windows.net) non riusciranno. Questo comportamento è da progettazione, perché l'endpoint privato instrada il traffico al gateway SQL nell'area ed è necessario specificare il nome di dominio completo corretto affinché gli accessi riescano.
Seguire questa procedura per usare SSMS per connettersi al database SQL. Dopo aver stabilito la connessione al Database SQL tramite SSMS, la seguente query deve riflettere client_net_address che corrisponde con l'indirizzo IP privato della VM di Azure da cui si effettua la connessione:
SELECT client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
Usare Criteri di connessione di reindirizzamento” con gli endpoint privati
È consigliabile che i clienti usino il collegamento privato con i Criteri di connessione di reindirizzamento per ridurre la latenza e migliorare la velocità effettiva. Affinché le connessioni usino questa modalità, i client devono soddisfare i prerequisiti seguenti:
Consentire la comunicazione in entrata alla rete virtuale che ospita l'endpoint privato all'intervallo di porte compreso tra 1433 e 65535.
Consentire la comunicazione in uscita dalla rete virtuale che ospita il client all'intervallo di porte compreso tra 1433 e 65535.
Usare l'ultima versione dei driver con supporto per il reindirizzamento integrato. Il supporto per il reindirizzamento è incluso nei driver ODBC, OLEDB, NET SqlClient provider di dati, Core .NET SqlClient Data Provider e JDBC (versione 9.4 o successiva). Le connessioni originate da tutti gli altri driver vengono inoltrate tramite proxy.
Dopo aver soddisfatto i prerequisiti, i client devono esplicitamentescegliere Reindirizza i criteri di connessione.
Se non è possibile modificare le impostazioni del firewall per consentire l'accesso in uscita nell'intervallo di porte 1433-65535, una soluzione alternativa consiste nel modificare i criteri di connessione in Proxy.
Gli endpoint privati esistenti che usano i criteri di connessione predefiniti useranno i criteri di connessione proxy con la porta 1433. Il motivo di questa operazione è evitare che le interruzioni del traffico del client raggiungano il Database SQL perché intervalli di porte necessari per il reindirizzamento non sono aperti.
Nota
Per i pool SQL dedicati, i criteri di connessione quando si usano endpoint privati sono sempre Proxy. La modifica dell'impostazione non influisce sui pool SQL dedicati quando si usano endpoint privati.
Connettività locale tramite peering privato
Quando gli utenti si connettono all'endpoint pubblico da computer locali, il loro indirizzo IP deve essere aggiunto al firewall basato su IP mediante una regola del firewall a livello di server. Questo modello è adatto per consentire l'accesso ai singoli computer per i carichi di lavoro di sviluppo o test, ma è difficile da gestire in un ambiente di produzione.
Con Collegamento privato, gli utenti possono abilitare l'accesso cross-premise all'endpoint privato tramite ExpressRoute, il peering privato o il tunneling VPN. Possono quindi disabilitare tutti gli accessi tramite l'endpoint pubblico e non usare il firewall basato su IP per accettare gli indirizzi IP.
Casi d'uso di Collegamento privato per il database SQL di Azure
I client possono connettersi all'endpoint privato dalla stessa rete virtuale, dalla rete virtuale con peering nella stessa area o tramite la connessione da rete virtuale a rete virtuale tra aree diverse. Inoltre, i client possono connettersi dall'ambiente locale tramite ExpressRoute, peering privato o tunneling VPN. Il seguente diagramma semplificato illustra i casi d'uso comuni.
Inoltre, i servizi che non sono in esecuzione direttamente nella rete virtuale ma sono integrati con essa, (ad esempio le app Web del servizio app o le Funzionalità) possono ottenere la connettività privata al database. Per altre informazioni su questo caso d'uso specifico, vedere lo scenario di architettura App web con connettività privata al database SQL di Azure.
Connettersi da una macchina virtuale di Azure in Rete virtuale con peering
Configurare il peering della rete virtuale per stabilire la connettività al database SQL da una macchina virtuale di Azure in una rete virtuale con peering.
Connettersi da una macchina virtuale di Azure nell'ambiente da rete virtuale a rete virtuale
Configurare la connessione gateway VPN da rete virtuale a rete virtuale per stabilire la connettività a un database nel database SQL da una macchina virtuale di Azure in un'area o in una sottoscrizione diversa.
Connettersi da un ambiente locale tramite VPN
Per stabilire la connettività da un ambiente locale al database nel database SQL, scegliere e implementare una delle opzioni seguenti:
Considerare anche scenari di configurazione DNS, poiché il FQDN del servizio può risolvere l'indirizzo IP pubblico.
Connettersi da Azure Synapse Analytics ad Archiviazione di Azure tramite PolyBase e l'istruzione COPY
PolyBase e l'istruzione COPY vengono in genere usati per caricare i dati in Azure Synapse Analytics dagli account di archiviazione di Azure. Se l'account di archiviazione di Azure da cui si caricano i dati limita l'accesso solo a un set di subnet della rete virtuale tramite endpoint privati, endpoint servizio o firewall basati su IP, la connettività da PolyBase e l'istruzione COPY all'account verrà interrotta. Per poter usare sia scenari di importazione che di esportazione con Azure Synapse Analytics che si connette ad Archiviazione di Azure protetta con una rete virtuale, seguire la procedura illustrata qui.
Prevenzione dell'esfiltrazione di dati
L'esfiltrazione di dati nel database SQL di Azure si verifica quando un utente, ad esempio un amministratore di database, è in grado di estrarre i dati da un sistema e spostarli in un'altra posizione o in un altro sistema all'esterno dell'organizzazione. Ad esempio, l'utente sposta i dati in un account di archiviazione di proprietà non di Microsoft.
Si consideri uno scenario in cui un utente esegue SQL Server Management Studio (SSMS) all'interno di una macchina virtuale di Azure che si connette a un database nel database SQL. Questo database si trova nel data center dell'area Stati Uniti occidentali. Il seguente esempio illustra come limitare l'accesso con gli endpoint pubblici nel database SQL tramite i controlli di accesso alla rete.
- Disabilitare tutto il traffico dei servizi di Azure verso il database SQL tramite l'endpoint pubblico disattivando l'opzione Consenti ai servizi di Azure di accedere al server. Verificare che non siano consentiti indirizzi IP nelle regole del firewall a livello di server e database. Per altre informazioni, vedere Controllo di accesso alla rete del database SQL di Azure e Azure Synapse Analytics.
- Consentire solo il traffico al database del database SQL tramite l'indirizzo IP privato della macchina virtuale. Per altre informazioni, vedere gli articoli sull'endpoint servizio e le regole del firewall della rete virtuale.
- Nella macchina virtuale di Azure limitare l'ambito della connessione in uscita usando i gruppi di sicurezza di rete (NSG) e i tag del servizio come indicato di seguito.
- Specificare una regola NSG per consentire il traffico per il tag di servizio = SQL.WestUs, che accetta solo le connessioni al database SQL negli Stati Uniti occidentali.
- Specificare una regola NSG (con una priorità più alta) per negare il traffico per il tag di servizio = SQL, che rifiuta le connessioni al database SQL in tutte le aree.
Al termine di questa configurazione, la macchina virtuale di Azure può connettersi solo a un database nel database SQL nell'area Stati Uniti occidentali. Tuttavia, la connettività non è limitata a un database singolo nel database SQL. La macchina virtuale può comunque connettersi a qualsiasi database nell'area Stati Uniti occidentali, inclusi i database che non fanno parte della sottoscrizione. Sebbene l'ambito di esfiltrazione dei dati nello scenario precedente sia stato ridotto a un'area specifica, non è stato eliminato completamente.
Con Collegamento privato i clienti possono ora configurare controlli di accesso alla rete come gruppi di sicurezza di rete per limitare l'accesso all'endpoint privato. Viene quindi eseguito il mapping delle singole risorse PaaS di Azure a endpoint privati specifici. Un utente interno malintenzionato può accedere solo alla risorsa PaaS mappata, ad esempio un database nel database SQL, e a nessun'altra risorsa.