Condividi tramite

Usare gli endpoint servizio di rete virtuale e le regole per il database SQL di Azure

  • Articolo

Si applica a:Database SQL di AzureAzure Synapse Analytics

Le regole di rete virtuale rappresentano una funzionalità di sicurezza firewall che consente di definire se il server di database per i database e il pool elastico nel database SQL di Azure o per i database del pool SQL dedicato (in precedenza SQL DW) in Azure Synapse Analytics accetta le comunicazioni inviate da subnet specifiche nelle reti virtuali. Questo articolo spiega i motivi per cui la funzionalità relativa alle regole di rete virtuale rappresenti a volte la scelta ideale per consentire le comunicazioni con il database SQL e Azure Synapse Analytics in modo sicuro.

Nota

Questo articolo si applica sia a Database SQL che ad Azure Synapse Analytics. Per semplicità, il termine database fa riferimento a entrambi i database nel database SQL e in Azure Synapse Analytics. Analogamente, tutti i riferimenti a server indicano il server logico che ospita il database SQL e Azure Synapse Analytics.

Per creare una regola di rete virtuale, deve essere disponibile un endpoint servizio di rete virtuale al quale la regola possa fare riferimento.

Nota

Microsoft Entra ID era precedentemente conosciuto come Azure Active Directory (Azure AD).

Creare una regola di rete virtuale

Se si desidera solamente creare una regola di rete virtuale, è possibile procedere direttamente ai passaggi e alla spiegazione più avanti in questo articolo.

Dettagli sulle regole di rete virtuale

Questa sezione illustra alcuni dettagli sulle regole di rete virtuale.

Una sola area geografica

Ogni endpoint servizio di rete virtuale si applica a una sola area di Azure. L'endpoint non consente ad altre aree di accettare le comunicazioni dalla subnet.

Ogni regola di rete virtuale è limitata all'area a cui si applica il relativo endpoint sottostante.

A livello di server, non a livello di database

Ogni regola di rete virtuale si applica all'intero server, non solo a un determinato database nel server. In altre parole, la regola di rete virtuale si applica a livello di server, non a livello di database.

Al contrario, le regole IP possono essere applicate a qualsiasi livello.

Ruoli di amministrazione di sicurezza

I ruoli di sicurezza sono distinti nell'amministrazione degli endpoint servizio di rete virtuale. Ogni ruolo indicato di seguito deve svolgere determinate azioni:

  • Amministratore di rete (ruolo Collaboratore rete): attivare l'endpoint.
  • Amministratore di Database (ruolo Collaboratore SQL Server): aggiornare l'elenco di controllo di accesso (ACL) per aggiungere la subnet specificata al server.

Alternativa al controllo degli accessi in base al ruolo di Azure

I ruoli di amministratore di rete e amministratore di database hanno più funzionalità di quelle necessarie a gestire le regole di rete virtuale. È necessario solo un subset delle relative funzionalità.

È possibile scegliere di usare il controllo degli accessi in base al ruolo (RBAC) in Azure per creare un singolo ruolo personalizzato che contiene solo il subset necessario di funzionalità. La regola personalizzata dovrebbe essere usata per evitare di coinvolgere l’Amministratore di rete o di database. La superficie di attacco dell'esposizione a rischi per la sicurezza è ridotta se si aggiunge un utente a un ruolo personalizzato, anziché aggiungere l'utente agli altri due ruoli amministrativi principali.

Nota

In alcuni casi, il database SQL e la subnet della rete virtuale sono in sottoscrizioni diverse. In questi casi è necessario garantire le configurazioni seguenti:

  • Entrambe le sottoscrizioni devono trovarsi nello stesso tenant di Microsoft Entra.
  • L'utente ha le autorizzazioni necessarie per avviare le operazioni, ad esempio abilitare gli endpoint di servizio e aggiungere una subnet della rete virtuale al server specificato.
  • Entrambe le sottoscrizioni devono avere registrato il provider di Microsoft.Sql.

Limiti

Per il database SQL, la funzionalità delle regole di rete virtuale presenta le limitazioni seguenti:

  • Nel firewall per il database in database SQL ogni regola di rete virtuale fa riferimento a una subnet. Tutte queste subnet cui viene fatto riferimento devono essere ospitate nella stessa area geografica che ospita il database.
  • Ogni server può includere fino a 128 voci ACL per qualsiasi rete virtuale specificata.
  • Le regole di rete virtuale si applicano solo alle reti virtuali di Azure Resource Manager e non alle reti con un modello di distribuzione classica.
  • L'attivazione degli endpoint servizio di rete virtuale nel database SQL di Azure abilita anche gli endpoint per Database di Azure per MySQL e Database di Azure per PostgreSQL. Con gli endpoint impostati su ON, i tentativi di connessione dagli endpoint al Database di Azure per MySQL o alle istanze di Database di Azure per PostgreSQL potrebbero non riuscire.
    • La causa principale è che il Database di Azure per MySQL e il Database di Azure per PostgreSQL probabilmente non possiedono una regola di rete virtuale configurata. Configurare una regola di rete virtuale per Database di Azure per MySQL e Database di Azure per PostgreSQL.
    • Per definire le regole del firewall di rete virtuale in un server logico SQL già configurato con endpoint privati, impostare Nega l'accessoalla rete pubblica su No.
  • Nel firewall, gli intervalli di indirizzi IP si applicano ai seguenti elementi di rete, ma non le regole di rete virtuale:

Considerazioni quando si utilizzando endpoint del servizio

Quando si usano gli endpoint del servizio per il Database SQL, rivedere le considerazioni seguenti:

  • In uscita verso gli indirizzi IP pubblici del database SQL di Azure. I gruppi di sicurezza di rete (NSG) devono essere aperti verso gli indirizzi IP del database SQL per consentire la connettività. A tale scopo, è possibile usare i tag del servizio NSG per il database SQL.

ExpressRoute

Se si usa ExpressRoute dall'ambiente locale, per il peering pubblico o per il peering Microsoft, sarà necessario identificare gli indirizzi IP NAT usati. Per il peering pubblico, ogni circuito ExpressRoute usa per impostazione predefinita due indirizzi IP NAT applicati al traffico del servizio di Azure quando il traffico entra nel backbone della rete di Microsoft Azure. Per il peering Microsoft, gli indirizzi IP NAT usati vengono forniti dal cliente o dal provider di servizi. Per consentire l'accesso alle risorse del servizio è necessario autorizzare questi indirizzi IP pubblici nell'impostazione del firewall IP per le risorse. Per trovare gli indirizzi IP del circuito ExpressRoute per il peering pubblico, aprire un ticket di supporto con ExpressRoute tramite il portale di Azure. Per altre informazioni su NAT per il peering pubblico di ExpressRoute e Microsoft, vedere Requisiti NAT per il peering pubblico di Azure.

Per consentire la comunicazione tra il circuito e il database SQL, è necessario creare regole di rete IP per gli indirizzi IP pubblici di NAT.

Impatto dell'uso degli endpoint servizio di rete virtuale con Archiviazione di Azure

Archiviazione di Azure ha implementato la stessa funzionalità che consente di limitare la connettività all'account di archiviazione di Azure. Se si sceglie di usare questa funzionalità con un account di Archiviazione di Azure usato dal database SQL, possono verificarsi problemi. Di seguito sono riportati un elenco e una spiegazione delle funzionalità del database SQL di Azure Synapse Analytics interessate.

PolyBase e istruzione COPY di Azure Synapse Analytics

PolyBase e l'istruzione COPY vengono in genere usati per caricare i dati in Azure Synapse Analytics dagli account di archiviazione di Azure per inserimento dati a velocità effettiva elevata. 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, la connettività da PolyBase e l'istruzione COPY all'account verrà interrotta. Per poter usare sia scenari di importazione che di esportazione utilizzando PolyBase e COPY con Azure Synapse Analytics che si connette ad Archiviazione di Azure protetta con una rete virtuale, seguire la procedura illustrata in questa sezione.

Prerequisiti

  • Installare Azure PowerShell. Per altre informazioni, vedere Installare il modulo Azure Az PowerShell.
  • Se si dispone di un account per utilizzo generico v1 o Archiviazione BLOB di Azure, è prima necessario eseguire l'aggiornamento alla versione 2 per utilizzo generico seguendo i passaggi descritti in Eseguire l'aggiornamento a un account di archiviazione per utilizzo generico v2.
  • È necessario avere attivato l'opzione Consenti ai servizi Microsoft attendibili di accedere a questo account di archiviazione nel menu delle impostazioni Firewall e reti virtuali di tale account. L'abilitazione di questa configurazione consentirà a PolyBase e all'istruzione COPY di connettersi all'account di archiviazione usando l'autenticazione dettagliata in cui il traffico di rete rimane nel backbone di Azure. Per altre informazioni, vedere questa guida.

Importante

Il modulo Azure Resource Manager di PowerShell è ancora supportato da Database SQL di Azure, ma tutte le attività di sviluppo future sono incentrate sul modulo Az.Sql. Il modulo AzureRM continuerà a ricevere correzioni di bug almeno fino a dicembre 2020. Gli argomenti per i comandi nei moduli Az e AzureRm sono sostanzialmente identici. Per altre informazioni sulla compatibilità, vedere Introduzione del nuovo modulo Az di Azure PowerShell.

Passaggi

  1. Se si dispone di un pool SQL dedicato autonomo (in precedenza SQL Data Warehouse), registrare SQL Server con Microsoft Entra ID usando PowerShell:

    Connect-AzAccount
Select-AzSubscription -SubscriptionId <subscriptionId>
Set-AzSqlServer -ResourceGroupName your-database-server-resourceGroup -ServerName your-SQL-servername -AssignIdentity

    Questo passaggio non è necessario per i pool SQL dedicati situati all'interno di un'area di lavoro di Azure Synapse Analytics. L'identità gestita assegnata dal sistema (SA-MI) dell'area di lavoro è membro del ruolo di amministratore di Synapse dispone quindi di privilegi elevati per i pool SQL dedicati dell'area di lavoro.

  2. Creare un account di archiviazione generico v2 seguendo le istruzioni in Creare un account di archiviazione.

  3. Nella pagina dell'account di archiviazione selezionare Controllo di accesso (IAM).

  4. Selezionare Aggiungi>Aggiungi assegnazione di ruolo per aprire la pagina Aggiungi assegnazione di ruolo.

  5. Assegnare il ruolo seguente. Per la procedura dettagliata, vedere Assegnare ruoli di Azure usando il portale di Azure.

    Impostazione Valore
    Ruolo Collaboratore dati BLOB di archiviazione
    Assegna accesso a Utente, gruppo o entità servizio
    Membri Server o area di lavoro che ospita il pool SQL dedicato registrato con Microsoft Entra ID

    Screenshot che mostra la pagina Aggiungi un'assegnazione di ruolo nel portale di Azure.

    Nota

    Solo i membri con il privilegio di proprietario sull’account di archiviazione possono eseguire questo passaggio. Per i vari ruoli predefiniti di Azure, vedere Ruoli predefiniti di Azure.

  6. Per abilitare la connettività di Polybase all'account di archiviazione di Azure:

    1. Creare una chiave master del database, se non è stata creata in precedenza.

      CREATE MASTER KEY [ENCRYPTION BY PASSWORD = 'somepassword'];

    2. Creare credenziali con ambito database con IDENTITY = 'Identità del servizio gestita'.

      CREATE DATABASE SCOPED CREDENTIAL msi_cred WITH IDENTITY = 'Managed Service Identity';

      • Non è necessario specificare SECRET con la chiave di accesso ad Archiviazione di Azure perché questo meccanismo in pratica usa l'Identità gestita. Questo passaggio non è necessario per i pool SQL dedicati situati all'interno di un'area di lavoro di Azure Synapse Analytics. L'identità gestita assegnata dal sistema (SA-MI) dell'area di lavoro è membro del ruolo di amministratore di Synapse dispone quindi di privilegi elevati per i pool SQL dedicati dell'area di lavoro.

      • Il nome IDENTITY deve essere “Identità del servizio gestita” affinché la connettività di PolyBase funzioni con l'account di archiviazione di Azure protetto con la rete virtuale.

    3. Creare un'origine dati esterna con lo schema abfss:// per la connessione all'account di archiviazione per utilizzo generico v2 con PolyBase.

      CREATE EXTERNAL DATA SOURCE ext_datasource_with_abfss WITH (TYPE = hadoop, LOCATION = 'abfss://myfile@mystorageaccount.dfs.core.windows.net', CREDENTIAL = msi_cred);
      • Se sono già presenti tabelle esterne associate all'account di archiviazione BLOB o per utilizzo generico v1, è necessario prima rimuovere queste tabelle esterne. Eliminare quindi l'origine dati esterna corrispondente. Creare quindi un'origine dati esterna con lo schema abfss:// che si connette a un account di archiviazione per utilizzo generico v2, come illustrato in precedenza. Quindi ricreare tutte le tabelle esterne usando questa nuova origine dati esterna. Per comodità, è possibile usare la Procedura guidata genera e pubblica script per generare gli script di creazione per tutte le tabelle esterne.
      • Per altre informazioni sullo schema abfss://, vedere Usare l'URI di Azure Data Lake Storage Gen2.
      • Per altre informazioni sui comandi T-SQL, vedere CREARE ORIGINI DATI ESTERNE.

    4. Eseguire le query come di consueto usando le tabelle esterne.

Controllo BLOB del database SQL

Il controllo SQL di Azure può scrivere log di controllo SQL nel proprio account di archiviazione. Se questo account di archiviazione usa la funzionalità endpoint servizio di rete virtuale, vedere come scrivere il controllo in un account di archiviazione dietro rete virtuale e firewall.

Aggiungere una regola del firewall di rete virtuale al server

In passato, prima che questa funzionalità fosse migliorata, era necessario attivare gli endpoint servizio di rete virtuale prima di poter implementare una regola di rete virtuale attiva nel firewall. Gli endpoint correlati a una determinata subnet di rete virtuale a un database in database SQL. A partire da gennaio 2018 è invece possibile aggirare questo requisito impostando il flag IgnoreMissingVNetServiceEndpoint. A questo punto, è possibile aggiungere una regola del firewall di rete virtuale al server senza attivare gli endpoint servizio di rete virtuale.

La semplice impostazione di una regola del firewall non consente di proteggere il server. Per garantire la sicurezza, è anche necessario attivare gli endpoint servizio di rete virtuale. Quando si attivano gli endpoint servizio, la subnet della rete virtuale riscontra un periodo di inattività fino al termine della transizione dallo stato inattivo a quello attivo. Questo periodo di tempo inattivo è particolarmente vero nel contesto di reti virtuali di grandi dimensioni. È possibile usare il flag IgnoreMissingVNetServiceEndpoint per ridurre o eliminare il tempo di inattività durante la transizione.

È possibile impostare il flag IgnoreMissingVNetServiceEndpoint usando PowerShell. Per ulteriori informazioni, vedere Usare PowerShell per creare un endpoint servizio di rete virtuale e una regola per il database SQL.

Nota

Per istruzioni simili in Azure Synapse Analytics, vedere Regole del firewall IP di Azure Synapse Analytics

Usare il portale di Azure per creare una regola di rete virtuale

Questa sezione illustra come usare il portale di Azure per creare una regola di rete virtuale nel database all’interno di database SQL. La regola indica al database di accettare le comunicazioni da una subnet specifica contrassegnata come endpoint servizio di rete virtuale.

Nota

Se si intende aggiungere un endpoint di servizio alle regole del firewall della rete virtuale del server, verificare per prima cosa che gli endpoint di servizio siano attivati per la subnet.

Se gli endpoint di servizio non sono attivati per la subnet, nel portale verrà richiesto di abilitarli. Selezionare il pulsante Abilita nello stesso pannello in cui si aggiunge la regola.

Prerequisiti

È necessario avere già una subnet contrassegnata con lo specifico nome del tipo di endpoint servizio di rete virtuale pertinente per il database SQL.

Procedure del portale di Azure

  1. Accedere al portale di Azure.

  2. Cercare e selezionare SQL Server e quindi selezionare il server. In Sicurezza, selezionare Rete.

  3. Nella scheda Accesso pubblico verificare che l'accesso alla rete pubblica sia impostato su Seleziona reti. In caso contrario, le impostazioni delle Reti virtuali sono nascoste. Nella sezione Reti virtuali, selezionare il collegamento Aggiungi rete virtuale esistente.

    Screenshot che mostra le proprietà del server logico per Rete.

  4. Nel nuovo riquadro Crea/Aggiorna compilare le caselle con i nomi delle risorse di Azure.

    Suggerimento

    È necessario includere il prefisso dell'indirizzo corretto per la subnet. Il valore Prefisso dell’indirizzo è disponibile nel portale. Passare a Tutte le risorse>Tutti i tipi>Reti virtuali. Il filtro visualizza le reti virtuali. Selezionare la rete virtuale, quindi selezionare Subnet. La colonna INTERVALLO DI INDIRIZZI contiene il prefisso dell'indirizzo desiderato.

    Screenshot che mostra la compilazione di caselle per la nuova regola.

  5. Osservare la regola di rete virtuale risultante nel riquadro del Firewall.

    Screenshot che mostra la nuova regola nel riquadro Firewall.

  6. Impostare Consenti alle risorse e ai servizi di Azure di accedere a questo server su No.

    Importante

    Se si lascia Consenti ai servizi e alle risorse di Azure di accedere a questo server selezionato, il server accetta la comunicazione da qualsiasi subnet all'interno del limite di Azure. Ovvero la comunicazione che ha origine da uno degli indirizzi IP riconosciuti come quelli all'interno degli intervalli definiti per i data center di Azure. Lasciando il controllo abilitato, il numero di accessi potrebbe essere eccessivo dal punto di vista della sicurezza. La funzionalità di endpoint servizio di rete virtuale di Microsoft Azure, in sinergia con la funzionalità delle regole di rete virtuale del database SQL, consente di ridurre la superficie di attacco per la sicurezza.

  7. Fare clic sul pulsante OK nella parte inferiore del riquadro.

Nota

Le regole presentano gli stati seguenti:

  • Pronta: indica che l'operazione avviata è riuscita.
  • Non riuscita: indica che l'operazione avviata non è riuscita.
  • Eliminata: si applica solo alle operazioni Delete e indica che la regola è stata eliminata e non viene più applicata.
  • In corso: indica che l'operazione è in corso. Mentre l'operazione è in questo stato, viene applicata la regola precedente.

Usare PowerShell per creare una regola di rete virtuale

Uno script può anche creare regole di rete virtuale usando il cmdlet New-AzSqlServerVirtualNetworkRule di PowerShell o az network vnet create. Per ulteriori informazioni, vedere Usare PowerShell per creare un endpoint servizio di rete virtuale e una regola per il database SQL.

Usare l’API REST per creare una regola di rete virtuale

Internamente, i cmdlet di PowerShell per le azioni SQL sulle reti virtuali chiamano API REST. È possibile chiamare direttamente le API REST. Per altre informazioni, vedere Regole di rete virtuale: Operazioni.

Risolvere gli errori 40914 e 40615

L'errore di connessione 40914 è correlato alle regole di rete virtuale, come specificato nel riquadro Firewall nel portale di Azure.
L'errore 40615 è simile, ma è correlato alle regole degli indirizzi IP in Firewall.

Errore 40914

Testo del messaggio: “Impossibile aprire il server '[nome-server]' richiesto dall'accesso. Il client non è autorizzato ad accedere al server".

Descrizione dell'errore: il client si trova in una subnet che include endpoint server di rete virtuale. Tuttavia, il server non è associato ad alcuna regola di rete virtuale che concede alla subnet il diritto di comunicare con il database SQL.

Risoluzione dell'errore: nel riquadro Firewall del portale di Azure usare il controllo delle regole di rete virtuale per aggiungere una regola di rete virtuale per la subnet.

Errore 40615

Testo del messaggio: “Impossibile aprire il server '{0}' richiesto dall'accesso. Il client con indirizzo IP '{1}' non è autorizzato ad accedere al server".

Descrizione dell'errore: il client sta tentando di connettersi da un indirizzo IP che non è autorizzato a connettersi al server. Il firewall del server non contiene alcuna regola per gli indirizzi IP che consente a un client di comunicare dall'indirizzo IP specifico al database.

Risoluzione dell'errore: immettere l'indirizzo IP del client come regola IP. Usare il riquadro Firewall nel portale di Azure per completare questo passaggio.

Passaggi successivi