Procedure consigliate per la sicurezza di SQL Server

Si applica a: SQL Server Database SQL di Azure Istanza gestita di SQL di Azure

Questo articolo fornisce informazioni sulle procedure consigliate e sulle linee guida che consentono di stabilire la sicurezza per SQL Server. Per un esame completo delle funzionalità di sicurezza di SQL Server, vedere Protezione di SQL Server.

Per procedure consigliate specifiche per la sicurezza dei prodotti, vedere Database SQL di Azure e Istanza gestita di SQL e SQL Server in VM di Azure.

Panoramica

Una metodologia di sicurezza a più livelli fornisce una soluzione di difesa avanzata usando più funzionalità di sicurezza destinate ad ambiti di protezione diversi. Le funzionalità di sicurezza rese disponibili in SQL Server 2016 e migliorate nelle versioni successive contribuiscono a contrastare le minacce alla sicurezza e forniscono applicazioni di database adeguatamente protette.

Azure è conforme a molteplici normative e standard di settore che possono favorire la compilazione di una soluzione compatibile con SQL Server in esecuzione in una macchina virtuale. Per informazioni sulla conformità alle normative con Azure, vedere il Centro protezione di Azure.

Protezione a livello di colonna

Le organizzazioni spesso devono proteggere i dati a livello di colonna come dati riguardanti clienti, dipendenti, segreti commerciali, dati di prodotti, dati sanitari, dati finanziari e altri dati sensibili vengono spesso archiviati nei database di SQL Server. Le colonne sensibili includono spesso numeri identificativi/codici fiscali, numeri di cellulare, nomi e cognomi, identificativi di conti finanziari e altri dati che potrebbero essere considerati dati personali.

I metodi e le funzionalità citati in questa sezione aumentano il livello di protezione a livello di colonna con un sovraccarico minimo e senza necessità di modifiche estese al codice dell'applicazione.

Usare Always Encrypted per crittografare dati inattivi e in transito. I dati crittografati vengono decrittografati solo dalle librerie client a livello di client dell'applicazione. Dove possibile, usare la crittografia casuale invece di quella deterministica. Always Encrypted con enclavi sicure può migliorare le prestazioni per le operazioni di confronto, ad esempio BETWEEN, IN, LIKE, DISTINCT, join e altro, per scenari di crittografia casuale.

Quando Always Encrypted non è un'opzione disponibile, usare Dynamic Data Masking (DDM) per offuscare i dati a livello di colonna. Dynamic Data Masking (DDM) non è compatibile con Always Encrypted. Quando possibile, usare Always Encrypted invece di Dynamic Data Masking (DDM).

È possibile anche concedere autorizzazioni tramite l’istruzione GRANT a livello di colonna a una tabella, una vista o una funzione con valori di tabella. Valutare quanto indicato di seguito: - Per una colonna è possibile solo concedere autorizzazioni SELECT, REFERENCES, e UPDATE. - Un'istruzione DENY a livello di tabella non ha la precedenza rispetto a un'istruzione GRANT a livello di colonna.

Protezione a livello di riga

La sicurezza a livello di riga (RLS) consente di usare il contesto di esecuzione dell’utente per controllare l'accesso alle righe in una tabella di database. La sicurezza a livello di riga consente agli utenti di visualizzare solo il record che li riguarda. Ciò garantisce la sicurezza a livello di record dell'applicazione senza neessità di apportare modifiche significative all'applicazione.

La logica di business è incapsulata all'interno di funzioni con valori di tabella controllate da criteri di sicurezza che attivano e disattivano la funzionalità di sicurezza a livello di riga. I criteri di sicurezza controllano anche i predicati FILTER e BLOCK associati alle tabelle con sicurezza a livello di riga. Usare la sicurezza a livello di riga (RLS) per limitare i record restituiti all'utente che effettua la chiamata. Usare SESSION_CONTEXT (T-SQL) per gli utenti che si connettono al database tramite un'applicazione di livello intermedio in cui gli utenti dell'applicazione condividono lo stesso account utente di SQL Server. Per ottimizzare le prestazioni e la gestibilità, seguire le Procedure consigliate per la sicurezza a livello di riga.

Crittografia di file

Transparent Data Encryption (TDE) protegge i dati a livello di file fornendo la crittografia dei dati inattivi ai file di database. Transparent Data Encryption (TDE) garantisce che i file di database, i file di backup e i file tempdb non possano essere collegati e letti senza certificati appropriati per la decrittografia dei file di database. Senza Transparent Data Encryption (TDE), è possibile che un utente malintenzionato acquisisca i supporti fisici (unità o nastri di backup) e ripristini o colleghi il database per leggere il contenuto. Transparent Data Encryption (TDE) è supportato per l’uso con tutte le altre funzionalità di sicurezza in SQL Server. Transparent Data Encryption (TDE) esegue la crittografia e la decrittografia I/O in tempo reale dei file di dati e log. La crittografia TDE usa una chiave di crittografia del database (DEK) archiviata nel database utente. È anche possibile proteggere la chiave di crittografia del database usando un certificato protetto dalla chiave master del database master.

Usare TDE per proteggere dati inattivi, backup e tempdb.

Controllo e creazione di report

Per controllare SQL Server, creare criteri di controllo a livello di server o database. A tutti i database esistenti e a quelli appena creati sul server si applicano criteri server. Per semplicità, abilitare il controllo a livello di server e consentire al controllo a livello di database di ereditare la proprietà a livello di server per tutti i database.

Controllare tabelle e colonne con dati sensibili a cui sono applicate misure di sicurezza. Se l’importanza di una tabella o una colonna è sufficiente da richiedere la protezione tramite una funzionalità di sicurezza, anche il relativo controllo deve essere considerato sufficientemente importante. È particolarmente importante controllare e rivedere regolarmente le tabelle contenenti informazioni riservate ma in cui non è possibile applicare le misure di sicurezza desiderate a causa di un determinato tipo di applicazione o limitazione dell'architettura.

Identità e autenticazione

SQL Server supporta due modalità di autenticazione: la modalità di autenticazione di Windows e la modalità di autenticazione di SQL Server e Windows (modalità mista).

Gli account di accesso sono distinti dagli utenti del database. È necessario eseguire separatamente il mapping degli account di accesso o dei gruppi di Windows a utenti o ruoli del database. Concedere, quindi, le autorizzazioni agli utenti, ai ruoli del server e/o ai ruoli del database per l’accesso agli oggetti del database.

In SQL Server sono supportati i seguenti tipi di account di accesso:

• Un account utente di Windows locale o un account di dominio Active Directory: SQL Server si basa su Windows per l’autenticazione degli account utente di Windows.
• Gruppo di Windows: la concessione dell'accesso a un gruppo di Windows concede l'accesso a tutti gli account di accesso utente di Windows che sono membri del gruppo. La rimozione di un utente da un gruppo rimuove i diritti dall'utente proveniente dal gruppo. L'appartenenza al gruppo è la strategia preferita.
• Account di accesso di SQL Server: SQL Server archivia il nome utente e un hash della password nel database master.
• Gli utenti di un database indipendente eseguono l’autenticazione di connessioni di SQL Server a livello di database. Un database indipendente è isolato da altri database e dall'istanza di SQL Server (e del database master) che ospita il database. SQL Server supporta gli utenti di un database indipendente per l'autenticazione di Windows e SQL Server.

I seguenti consigli e procedure consigliate consentono di proteggere le identità e i metodi di autenticazione:

• Per migliorare la gestione della sicurezza, usare strategie di sicurezza basate su ruoli con privilegi minimi.

  • È tipico collocare gli utenti di Active Directory in gruppi AD, che devono esistere nei ruoli di SQL Server, e ai ruoli di SQL Server devono essere concesse le autorizzazioni minime richieste dall’applicazione.

• In Azure, usare la sicurezza con privilegi minimi usando i controlli degli accessi in base al ruolo (RBAC)

• Quando possibile, scegliere l’autenticazione di Active Directory invece di SQL Server; in particolare, scegliere Active Directory invece dell’archiviazione della sicurezza a livello di applicazione o database.

  • Se un utente lascia l'azienda, è facile disabilitare l'account.
  • È facile anche rimuovere gli utenti dai gruppi quando gli utenti modificano i ruoli o lasciano l'organizzazione. La sicurezza dei gruppi è considerata una procedura consigliata.

• Usare Autenticazione a più fattori per gli account con accesso a livello di computer, inclusi gli account che usano RDP per l’accesso al computer. In questo modo è più semplice proteggersi dal furto o dalla perdita delle credenziali, poiché l'autenticazione basata su password a fattore singolo è una forma più debole di autenticazione con credenziali a rischio di compromissione o perdita accidentale.

• Richiedere password sicure e complesse che non possono essere facilmente indovinate e non vengono usate per altri account o scopi. Aggiornare regolarmente le password e applicare i criteri di Active Directory.

• Gli account gMSA (group-Managed Service Accounts) consentono la gestione automatica delle password, la gestione semplificata del nome dell'entità servizio (SPN) e la possibilità di delegare la gestione ad altri amministratori.

  • Con l’account gMSA, il sistema operativo Windows gestisce la password dell’account anziché affidare la gestione della password a un amministratore.
  • L’account gMSA aggiorna automaticamente le password dell'account senza riavviare i servizi.
  • L’account gMSA riduce il livello di superficie amministrativa e migliora la separazione dei compiti.

• Ridurre al minimo i diritti concessi all'account AD dell'amministratore di database: si consideri una separazione dei compiti che limitano l'accesso alla macchina virtuale, la possibilità di accedere al sistema operativo, la possibilità di modificare i log di errore e di controllo e la possibilità di installare applicazioni e/o funzionalità.

• Considerare la rimozione degli account DBA dal ruolo sysadmin e la concessione dell’autorizzazione CONTROL SERVER agli account DBA anziché renderli membri del ruolo sysadmin. A differenza di CONTROL SERVER, il ruolo di amministratore di sistema non rispetta DENY.

Derivazione dei dati e integrità dei dati

La conservazione dei record cronologici delle modifiche ai dati nel tempo può essere utile per gestire modifiche accidentali ai dati. Può essere utile anche per il controllo delle modifiche delle applicazioni e può recuperare di elementi di dati quando un attore non valido introduce modifiche ai dati non autorizzate.

• Usare le tabelle temporali per preservare le versioni dei record nel tempo e visualizzare i dati mano a mano che la vita dei record termina per fornire una visualizzazione cronologica dei dati dell'applicazione.
• Le tabelle temporali possono essere usate per fornire una versione della tabella corrente in qualunque momento.

Strumenti di valutazione della sicurezza e valutazione

Gli strumenti di configurazione e valutazione seguenti gestiscono la sicurezza della superficie di attacco, identificare le opportunità di protezione dei dati e fornire una valutazione consigliata della sicurezza dell'ambiente di SQL Server a livello di istanza.

• Configurazione della superficie di attacco: per ridurre al minimo il numero di funzionalità che possono essere attaccate da un utente malintenzionato, è consigliabile abilitare solo le funzionalità richieste dall'ambiente.
• Valutazione della vulnerabilità per SQL Server (SSMS): la valutazione della vulnerabilità di SQL è uno strumento in SSMS v17.4+ che facilita il rilevamento, il tracciamento e l’eliminazione delle potenziali vulnerabilità del database. La valutazione della vulnerabilità è uno strumento utile per migliorare la sicurezza del database e viene eseguita a livello di database, per ogni database.
• Individuazione e classificazione dei dati di SQL (SSMS): è comune per gli amministratori di database gestire server e database e non tenere conto della riservatezza dei dati contenuti nel database. L’individuazione e la classificazione dei dati aggiunge la possibilità di individuare, classificare, etichettare e segnalare il livello di riservatezza dei dati. L'individuazione e la classificazione dei dati sono supportate a partire da SSMS 17.5.

Minacce comuni per SQL

È utile sapere quali sono alcune minacce comuni che mettono a rischio SQL Server:

• Attacco SQL injection: un attacco SQL injection è un tipo di attacco in cui viene inserito codice dannoso in stringhe che vengono passate a un'istanza di SQL Server per l'esecuzione.
  • Il processo injection avviene terminando una stringa di testo e accodando un nuovo comando. Poiché al comando inserito potrebbero essere aggiunte altre stringhe prima dell'esecuzione, l'utente malintenzionato termina la stringa inserita con un segno di commento --.
  • SQL Server esegue qualunque query sintatticamente valida ricevuta.
• Tenere presente gli attacchi side-channel, il malware e altre minacce.

Rischi di SQL injection

Per ridurre al minimo il rischio di SQL injection, considerare i seguenti elementi:

• Esaminare qualunque processo SQL che costruisca istruzioni SQL per individuare vulnerabilità di tipo injection.
• Costruire istruzioni SQL generate in modo dinamico in maniera parametrizzata.
• Gli sviluppatori e gli amministratori della sicurezza devono esaminare tutto il codice che chiama EXECUTE, EXEC, o sp_executesql.
• Non consentire i caratteri di input seguenti:
  • ;: Delimitatore di query
  • ': Delimitatore di stringhe di dati di tipo carattere
  • --: Delimitatore di riga singola.
  • /* ... */: Delimitatori di commento.
  • xp_: Stored procedure estese del catalogo, ad esempio xp_cmdshell.
    • Non è consigliabile usare xp_cmdshell in qualsiasi ambiente DI SQL Server. Usare, invece, SQLCLR o cercare altre alternative a causa dei possibili rischi introdotti con xp_cmdshell.
• Convalidare sempre gli input dell'utente ed eseguire lo scrubbing degli output degli errori dalla perdita e dall'esposizione all'utente malintenzionato.

Rischi side-channel

Per ridurre al minimo il rischio di attacco side-channel, considerare quanto segue:

• Accertarsi che siano applicate le patch più recenti dell'applicazione e del sistema operativo.
• Per i carichi di lavoro ibridi, accertarsi che vengano applicate le patch del firmware più recenti per tutto l’hardware locale.
• In Azure, per applicazioni e carichi di lavoro estremamente sensibili, è possibile aggiungere ulteriore protezione dagli attacchi side-channel con macchine virtuali isolate, host dedicati o usando macchine virtuali Confidential Compute, ad esempio serie DC e macchine virtuali che usano processori AMD EPYC di terza generazione.

Minacce per l'infrastruttura

Considerare le seguenti minacce comuni per l'infrastruttura:

• Accesso di forza bruta: l'utente malintenzionato tenta di eseguire l'autenticazione con più password in account diversi fino a quando viene trovata una password corretta.
• Password cracking/password spraying: gli utenti malintenzionati provano una singola password costruita accuratamente per tutti gli account utente noti (una sola password per molti account). Se l’attacco password spraying iniziale non riesce, viene riprovato usando una password diversa costruita accuratamente, attendendo, in genere, un determinato periodo di tempo tra i tentativi per evitare il rilevamento.
• Gli attacchi ransomware sono tipi di attacchi mirati in cui il malware viene usato per crittografare dati e file, impedendo l'accesso a contenuti importanti. Gli utenti malintenzionati, quindi, provano a estorcere denaro alle vittime, generalmente in forma di criptovalute, in cambio della chiave di decrittazione. La maggior parte delle infezioni ransomware inizia con messaggi email con allegati che tentano di installare ransomware o siti Web che ospitano kit di exploit che provano a usare vulnerabilità nei Web browser e altro software per installare ransomware.

Rischi delle password

Per evitare che gli utenti malintenzionati indovinino facilmente i nomi degli account o le password, i passaggi seguenti consentono di ridurre il rischio di individuazione delle password:

• Creare un account amministratore locale univoco non denominato Amministratore.
• Usare password complesse per tutti gli account. Per altre informazioni sulla creazione di password complesse, vedere l'articolo Crea una password complessa.
• Per impostazione predefinita, in Azure viene selezionata l'autenticazione di Windows durante l'installazione della macchina virtuale di SQL Server. L'account di accesso SA è pertanto disabilitato e viene assegnata una password tramite il programma di installazione. È consigliabile non usare o abilitare l'account di accesso SA. Se è necessario avere un account di accesso SQL, usare una delle strategie seguenti:

  • Creare un account SQL con un nome univoco che abbia appartenenza sysadmin. È possibile creare questo account dal portale attivando Autenticazione di SQL Server durante il provisioning.

    Suggerimento

    Se non si attiva l'autenticazione di SQL Server durante il provisioning, è necessario modificare manualmente la modalità di autenticazione in Autenticazione di SQL Server e di Windows. Per altre informazioni, vedere Modifica della modalità di autenticazione del server.

  • Se è necessario usare l'account di accesso SA, attivarlo dopo il provisioning e assegnare una nuova password complessa.

Rischi del ransomware

Considerare quanto segue per ridurre al minimo i rischi del ransomware:

• La strategia migliore per proteggersi dal ransomware consiste nella particolare attenzione da dedicare alle vulnerabilità RDP e SSH. Inoltre, prendere in considerazione le seguenti raccomandazioni:
  • Usare i firewall e bloccare le porte
  • Accertarsi che siano applicati gli aggiornamenti della sicurezza più recenti del sistema operativo e delle applicazioni
  • Usare account gMSA (group Managed Service Accounts)
  • Limitare l'accesso alle macchine virtuali
  • Richiedere accesso just-in-time (JIT) e Azure Bastion
  • Migliorare la sicurezza della superficie di attacco evitando l'installazione di strumenti come sysinternals e SSMS nel computer locale
  • Evitare l’installazione di funzionalità di Windows, ruoli e abilitazione di servizi non necessari
  • È necessario, inoltre, pianificare un backup completo regolare protetto separatamente da un account amministratore comune in modo che non possa eliminare copie dei database.

Contenuto correlato

• Sicurezza di SQL Server
• Database SQL di Azure e Istanza gestita di SQL di Azure
• SQL Server in macchine virtuali di Azure