Leggi in inglese

Condividi tramite

Procedure consigliate per la sicurezza di SQL Server

  • Articolo

Si applica a:SQL ServerDatabase SQL di AzureIstanza 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 a riposo 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 a livello di colonna a una tabella, vista o 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 (RLS) garantisce che gli utenti possano vedere solo i record che li riguardano. 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à RLS (sicurezza a livello di riga). La politica di sicurezza controlla anche i predicati FILTER e BLOCK associati alle tabelle contro le quali opera la sicurezza a livello di riga (RLS). 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.

Suggerimento

Usare la sicurezza a livello di riga (RLS) assieme ad Always Encrypted o Dynamic Data Masking (DDM) per ottimizzare la postura di sicurezza dell'organizzazione.

Crittografia di file

Transparent Data Encryption (TDE) protegge i dati a livello di file mediante crittografia dei dati a riposo ai file del 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 a riposo, backup e tempdb.

Revisione e reportistica

Per controllare SQL Server, creare criteri di controllo a livello di server o database. I criteri del server si applicano a tutti i database esistenti e a quelli appena creati sul 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. Prima di tutto, 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 contenuti del database autenticano le connessioni di SQL Server a livello di database. Un database contenuto è un database isolato da altri database e dall'istanza di SQL Server (e dal database master) che ospita il database. SQL Server supporta gli utenti di un database contenuto 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.
    • Le password dell'account gMSA si aggiornano automaticamente senza riavviare i servizi.
    • gMSA riduce il carico amministrativo 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 DENY, il ruolo di amministratore di sistema non rispetta .

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 come erano durante l'intero arco temporale dei record, per fornire una visione storica 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 dati SQL (SSMS) - È comune che gli amministratori di database gestiscano server e database e non siano a conoscenza della sensibilità 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 qualsiasi query sintatticamente valida che riceve.
  • Essere consapevoli degli attacchi side-channel, del malware e di 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 caratteri
    • --: Delimitatore di commento su singola riga.
    • /* ... */: 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 e pulire gli output degli errori per evitare che vengano esposti all'attaccante.

Rischi canale laterale

Per ridurre al minimo il rischio di un attacco side-channel, prendere in considerazione 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 spray - gli attaccanti provano una singola password attentamente selezionata per tutti gli account utente noti (una password per molti account). Se il primo tentativo di password spraying fallisce, riprovano utilizzando una password diversa e attentamente elaborata, aspettando normalmente 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'accesso SA è pertanto disabilitato e una password viene assegnata tramite l'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 con appartenenza a 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 utilizzare il login SA, abilitarlo 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 accesso ad 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