Funzionalità e attività di sicurezza
SQL Server e i servizi SQL di Azure sono noti per l'importanza che attribuiscono alla sicurezza, in particolare per quanto riguarda la classe aziendale. In questa unità verranno fornite informazioni sulle varie funzionalità di sicurezza correlate alla sicurezza di rete e alla gestione degli accessi. Nelle unità successive si otterrà un'esperienza pratica con alcune di queste funzionalità.
Sicurezza di rete
Il primo livello di sicurezza riguarda la rete. Le funzionalità e le attività di rete sono diverse tra il database SQL di Azure e l'Istanza gestita di SQL di Azure. Per informazioni sulle funzionalità di rete dell'Istanza gestita di SQL di Azure, vedere Architettura della connettività dell'Istanza gestita di SQL di Azure.
Sicurezza di rete del database SQL di Azure
Quando si protegge la rete per il database SQL di Azure, sono disponibili quattro opzioni principali:
- Consentire l'accesso ai servizi di Azure
- Usare regole del firewall
- Usare regole della rete virtuale
- Usare il collegamento privato di Azure
Oltre a queste opzioni principali, è possibile bloccare tutto l'accesso pubblico (solo con collegamento privato di Azure) e forzare una versione minima di Transport Layer Security (TLS). Il modo meno sicuro, ma il più semplice da configurare, consiste nel consentire l'accesso ai servizi di Azure. Il modo più sicuro prevede l'uso del collegamento privato. Nelle sezioni seguenti vengono descritte le funzionalità di ogni opzione, nonché come configurare e gestire ogni opzione.
Consentire l'accesso ai servizi di Azure
Durante la distribuzione database SQL di Azure, è possibile impostare Consenti l'accesso a servizi e risorse di Azure a questo server su Sì. Se si sceglie questa opzione, si consente a tutte le risorse di qualsiasi area o sottoscrizione di accedere alla risorsa. Questa opzione semplifica l'esecuzione e la connessione del database SQL di Azure ad altri servizi, ad esempio macchine virtuali di Azure o Servizio app di Azure (o anche Azure Cloud Shell), perché si consente a qualsiasi elemento che passa attraverso Azure di potersi connettere.
L'opzione Consentire l'accesso ai Servizi di Azure, tuttavia, non consente l'accesso a qualsiasi elemento esterno ad Azure (ad esempio l'ambiente locale).
La configurazione più sicura consiste nell'impostare Consenti ai servizi e alle risorse di Azure l'accesso a questo server su No, che blocca tutte le connessioni e le reti a parte quelle aggiunte in modo esplicito con le varie opzioni che seguono nelle sezioni successive.
Regole del firewall
L'opzione successiva prevede l'applicazione delle regole del firewall. I risultati potrebbero essere simili a quelli di Consenti l'accesso ai servizi e alle risorse di Azure a questo server , ad eccezione del fatto che, per ogni servizio (nell'immagine seguente, una macchina virtuale) è necessario aggiungere una regola del firewall univoca per consentire la connessione. Le regole del firewall consentono anche all'ambiente locale di connettersi alla risorsa database SQL di Azure, perché è possibile aggiungere le regole per computer e applicazioni nell'ambiente locale.
Per ottenere la connettività in Azure, è possibile anche consentire l'accesso ai servizi di Azure e quindi aggiungere regole del firewall solo per la connettività locale. Come indicato in precedenza, Consenti ai servizi e alle risorse di Azure l'accesso a questo server non è un'opzione sicura, perché consente tutto il traffico di Azure. È consigliabile usare le regole del firewall in modo esclusivo.
Si prenda l'esempio precedente con le regole del firewall configurate. Da uno strumento che supporta Transact-SQL (T-SQL) come SQL Server Management Studio (SSMS), è possibile eseguire la query seguente dalla macchina virtuale di Azure nella rete virtuale SQLDBVNET-EUS:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Il risultato sarebbe 174.17.218.16. Si tratta dell'indirizzo IP pubblico della macchina virtuale di Azure. Anche se si usano regole del firewall, tutte le connessioni stabilite sono pubbliche.
Regole della rete virtuale
Se si desidera usare solo le regole del firewall, può essere complicato configurarlo. L'uso solo delle regole del firewall significa che è necessario specificare un intervallo di indirizzi IP per tutte le connessioni, che a volte possono avere indirizzi IP dinamici. Un'alternativa molto più semplice consiste nell'usare regole di rete virtuale per stabilire e gestire l'accesso da reti specifiche che contengono macchine virtuali o altri servizi che devono accedere ai dati.
Se si configura l'accesso da una rete virtuale con una regola della rete virtuale, tutte le risorse nella rete virtuale potranno accedere al server logico del database SQL di Azure, semplificando l'operazione di configurazione dell'accesso a tutti gli indirizzi IP (statici e dinamici) che devono accedere ai dati. Con le regole della rete virtuale è possibile specificare una o più reti virtuali, incluse tutte le risorse al suo interno, nonché iniziare ad applicare le tecnologie delle reti virtuali per connettere reti tra aree di Azure e locali.
In questo esempio, è possibile eseguire la stessa query della sezione precedente dalla macchina virtuale di Azure nella rete virtuale SQLDBVNET-EUS:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Il risultato sarebbe ora 10.0.0.2, ovvero l'indirizzo IP privato della macchina virtuale di Azure. In questo modo ci si avvicina ancora di più alla creazione di connessioni private al server logico del database SQL di Azure, dal momento che ora le risorse si connettono attraverso la rete virtuale.
Un'altra strategia comune per l'analisi della connessione è esaminare la gerarchia DNS (Domain Name System). Nella stessa macchina virtuale di Azure, in un prompt dei comandi è possibile eseguire il comando seguente:
nslookup aw-server.database.windows.net
Questo comando consente di comprendere i dettagli relativi all'infrastruttura DNS. I risultati saranno simili ai seguenti:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: cr2.eastus1-a.control.database.windows.net
Address: 174.17.218.16
Aliases: aw-server.database.windows.net
dataslice2.eastus.database.windows.net
Sotto la risposta non autorevole, ci sono alcuni aspetti importanti da esaminare:
- Nome: L'endpoint che inizia con
cr2fa parte della gerarchia DNS pubblica. Senza approfondire troppo la gerarchia, è possibile osservare comecr2sia l'anello di controllo 2 e al di sotto siano presenti più sezioni di dati. - Indirizzo: L'indirizzo IP restituito deve corrispondere all'indirizzo IP pubblico della macchina virtuale di Azure. Anche se uno strumento come l'hop finale di SSMS potrebbe essere tramite l'indirizzo IP privato della macchina virtuale, l'indirizzo IP pubblico della macchina virtuale viene ancora usato per connettersi in una certa capacità.
- Alias: gli alias sono diversi punti all'interno della gerarchia DNS. In questo caso, i dati specifici "slice" e l'endpoint a cui ci si connette.
Nota
Nel blocco di output precedente, Address: 168.63.129.16 è un indirizzo IP pubblico virtuale usato per facilitare un canale di comunicazione alle risorse della piattaforma Azure. Si verifica per tutte le aree e per tutti i cloud nazionali e non cambierà.
Anche se la connessione tramite SSMS passa attraverso l'indirizzo IP privato della macchina virtuale di Azure, si sta ancora connettendo tramite un endpoint pubblico.
Collegamento privato per un database SQL di Azure
È stato illustrato come configurare la rete più sicura usando il proprio database presente nel database SQL di Azure con l'endpoint pubblico. Questo metodo di protezione di un database nel database SQL di Azure è stato usato per anni. Tuttavia, nel 2019, Azure ha iniziato predisporre un concetto di collegamento privato, che è più simile al modo in cui viene distribuita l'Istanza gestita di SQL di Azure. Con collegamento privato di Azure è possibile connettersi al database in database SQL e a diverse altre offerte PaaS (Platform-as-a-Service) usando un endpoint privato. Questo significa che dispone di un indirizzo IP privato all'interno di una rete virtuale specifica.
Nell'esempio precedente è possibile osservare come, sebbene l'infrastruttura di rete generale non sia cambiata, è comunque possibile sfruttare le strategie di connettività della rete virtuale dalle regole di rete virtuale. Non sarà tuttavia necessario creare regole della rete virtuale. Le risorse che devono connettersi al server di database devono semplicemente avere accesso alla rete virtuale in cui risiede l'endpoint. Nell'esempio l'endpoint è SQLDBVNet-EUS. Solo le connessioni che passano attraverso l'endpoint privato avranno accesso, mentre tutte le altre connessioni (ad esempio da Internet) verranno negate.
Continuando con questo esempio, nella macchina virtuale di Azure presente nella rete virtuale SQLDBVNet-EUS è possibile eseguire nuovamente il comando T-SQL seguente:
SELECT client_net_address FROM sys.dm_exec_connections WHERE session_id=@@SPID;
Il risultato sarà 10.0.0.2ora , ovvero l'indirizzo IP privato della macchina virtuale di Azure in questo esempio. Aggiungendo l'accesso dalla rete virtuale, le connessioni a database SQL di Azure dalla macchina virtuale verranno visualizzate tramite l'indirizzo IP privato della macchina virtuale. Si tratta dello stesso risultato osservato con le regole della rete virtuale.
Se invece si vuole usare il prompt dei comandi per esaminare la gerarchia DNS, è possibile ricorrere al comando seguente:
nslookup aw-server.database.windows.net
In questo caso, i risultati saranno leggermente diversi dall'endpoint privato configurato:
Server: Unknown
Address: 168.63.129.16
Non-authoritative answer:
Name: aw-server.privatelink.database.windows.net
Address: 10.0.0.5
Aliases: aw-server.database.windows.net
Sotto la risposta non autorevole, ci sono alcuni aspetti importanti da esaminare:
- Nome: Si noti che non si sta più puntando alla gerarchia DNS pubblica, ma solo al DNS del collegamento privato. Questo significa che vengono rivelate meno informazioni sul server di database.
- Indirizzi: per le regole di rete virtuale, l'indirizzo restituito è l'indirizzo IP pubblico della macchina virtuale, ma dovrebbe ora essere uno o più indirizzi IP privati all'interno della gerarchia di collegamento privato (uno è l'endpoint privato del database SQL di Azure).
- Alias: Come nel campo Nome, non vengono visualizzati elementi correlati alla gerarchia DNS, ad eccezione del fatto che è ancora possibile connettersi al nome del server (ad esempio,
aw-server.database.windows.net).
Un aspetto che si potrebbe chiedere se ci si connette all'endpoint privato è perché si sta ancora usando lo stesso nome del server? Nel back-end, quando si usa solo il metodo collegamento privato di connessione a database SQL di Azure (ovvero nessun firewall o regole di rete virtuale), le informazioni vengono elaborate come segue:
aw-server.database.windows.net- Risolte dal servizio a
aw-server.privatelink.database.net- Risolte dal servizio a
10.0.0.5(l'indirizzo IP dell'endpoint privato)
- Risolte dal servizio a
- Risolte dal servizio a
Il servizio, inoltre, bloccherà qualunque connessione diretta, ad eccezione di quelle provenienti da aw-server.database.windows.net.
Gestione degli accessi
Una volta definito l'accesso alla rete, il livello successivo da considerare è la gestione degli accessi.
Controllo degli accessi in base al ruolo
Tutti i tipi di operazioni di Azure del database SQL di Azure sono controllati tramite il controllo degli accessi in base al ruolo. Il controllo degli accessi in base al ruolo è attualmente separato dalla sicurezza di Azure SQL, ma è possibile considerarlo come privilegi di sicurezza al di fuori del proprio database presente nel database SQL, con un ambito che include sottoscrizione, gruppo di risorse e risorsa. Questi privilegi si applicano alle operazioni nel portale di Azure, nell'interfaccia della riga di comando di Azure e in Azure PowerShell. Il controllo degli accessi in base al ruolo consente la separazione dei compiti tra distribuzione, gestione e utilizzo.
Sono disponibili ruoli predefiniti per ridurre la necessità di ruoli del controllo degli accessi in base al ruolo di livello superiore, ad esempio Proprietario o Collaboratore. In effetti, è possibile usare questi ruoli per consentire a determinati utenti di distribuire le risorse di Azure SQL (o di gestire i criteri di sicurezza), ma concedere ad altri utenti l'accesso effettivo all'utente o la gestione del database. Ad esempio, un Collaboratore di SQL Server potrebbe distribuire un server e assegnare un utente come amministratore del server e dei database. I ruoli predefiniti del database SQL di Azure includono:
- Collaboratore Database SQL: può creare e gestire database, ma non accedere al database (ad esempio, non può connettersi e leggere i dati)
- Gestore Sicurezza SQL: può gestire i criteri di sicurezza per i database e le istanze (ad esempio il controllo), ma non accedervi
- Collaboratore SQL Server: può gestire server e database, ma non accedervi.
Autenticazione
Durante una distribuzione di database SQL di Azure server logico, è possibile specificare il metodo di autenticazione seguente:
- Usare solo l'autenticazione basata su Microsoft Entra
- Usare sia l'autenticazione SQL che quella basata su Microsoft Entra
- Usare l'autenticazione SQL
L'amministratore del server deve essere impostato durante la distribuzione. Per i database nel database SQL di Azure, l'amministratore del server è un'entità di livello server per il server logico del database SQL di Azure.
Se si esegue la migrazione di un carico di lavoro che richiede l'autenticazione di Windows o l'organizzazione usa Microsoft Entra ID, è possibile usare Microsoft Entra ID. È possibile assegnare un amministratore del server Microsoft Entra usando il portale o gli strumenti delle riga di comando.
L'autenticazione basata solo su Microsoft Entra costituisce l'opzione predefinita quando si configura un nuovo server. Gli account di accesso al server sono stati introdotti per consentire l'accesso alle entità di sicurezza del server di Microsoft Entra, ovvero gli accessi al database master virtuale di un database SQL. È possibile creare account di accesso microsoft Entra da utenti, gruppi e entità servizio di Microsoft Entra. Quando si usa l'autenticazione solo Microsoft Entra-only, è possibile creare account di accesso con autenticazione SQL e gli account di accesso esistenti rimarranno. Tuttavia, solo gli account di accesso e gli utenti con autenticazione basata solo su Microsoft Entra possono connettersi al server logico. Per altre informazioni sull'autenticazione solo Microsoft Entra-only, vedere Autenticazione solo Entra-only di Microsoft con Azure SQL.
A seconda del modo in cui l'organizzazione ha configurato l'istanza di Microsoft Entra, esistono tre metodi di connessione (ad esempio, in SSMS):
Microsoft Entra ID - Integrato: Metodo non interattivo che è possibile usare se è stato eseguito l'accesso a Windows con le credenziali di Microsoft Entra da un dominio federato.
Microsoft Entra ID - Password: Metodo non interattivo che consente di connettersi con un nome dell'entità di sicurezza di Microsoft Entra usando il dominio gestito da Microsoft Entra ID. Dalla documentazione:
Tale metodo può essere applicato agli utenti nativi o federati di Microsoft Entra. Un utente nativo viene creato in modo esplicito in Microsoft Entra ID ed è autenticato con nome utente e password, mentre un utente federato è un utente Windows il cui dominio è federato con Microsoft Entra ID. Quest'ultimo metodo (usando il nome utente e la password) può essere usato quando un utente vuole usare le credenziali di Windows, ma il computer locale non viene aggiunto al dominio , ad esempio usando un accesso remoto. In questo caso, un utente di Windows può indicare il proprio account di dominio e la relativa password e può eseguire l'autenticazione al database SQL o ad Azure Synapse Analytics (in precedenza, SQL DW) usando credenziali federate.
Microsoft Entra ID - Universale con autenticazione a più fattori (MFA): Metodo interattivo che consente di proteggere l'accesso ai dati, soddisfacendo al contempo la richiesta di un processo Single Sign-In con l'autenticazione a più fattori di Microsoft Entra.
Per il database SQL di Azure sono presenti alcune sfumature. È possibile disporre di accessi esistenti nel database mastervirtuale, di utenti del database e persino di utenti del database contenuto per gli account Microsoft Entra (consigliato). Sebbene l'amministratore del server per il database SQL di Azure disponga essenzialmente di diritti sysadmin, è possibile creare amministratori più limitati usando ruoli a livello di server o di database. Per il database SQL sono disponibili due ruoli a livello di database che esistono solo nel database master virtuale:
- loginmanager: ruolo a livello di database che consente ai membri di creare account di accesso per il server di database
- dbmanager: ruolo a livello di database che consente ai membri di creare ed eliminare database per il server di database
Di seguito è riportato un elenco di ruoli a livello di server nel database SQL di Azure:
- ##MS_DatabaseConnector##
- ##MS_DatabaseManager##
- ##MS_DefinitionReader##
- ##MS_LoginManager##
- ##MS_SecurityDefinitionReader##
- ##MS_ServerStateReader##
- ##MS_ServerStateManager##
In conclusione, quando si impostano e si configurano l'autenticazione e l'autorizzazione, è necessario seguire quattro linee guida:
- Eseguire la distribuzione con un amministratore del server
- Creare altri amministratori secondo necessità
- Gli amministratori possono creare utenti
- Concedere l'accesso come di consueto in SQL Server
Altre funzionalità
Una volta apprese alcune funzionalità di rete e di autenticazione, più avanti nel modulo si esamineranno altre funzionalità (e le attività correlate) per la protezione dei dati, il monitoraggio, la registrazione e il controllo.