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 una revisione completa 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 macchine virtuali di Azure.

Panoramica

Una metodologia di sicurezza a più livelli fornisce una soluzione di difesa avanzata usando più funzionalità di sicurezza destinate a ambiti di sicurezza diversi. Le funzionalità di sicurezza rese disponibili in SQL Server 2016 e migliorate nelle versioni successive aiutano a contrastare le minacce alla sicurezza e forniscono applicazioni di database ben 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 relativi a clienti, dipendenti, segreti commerciali, dati di prodotto, assistenza sanitaria, finanziaria e altri dati sensibili vengono spesso archiviati nei database di SQL Server. Le colonne sensibili includono spesso numeri di identificazione/previdenza sociale, numeri di telefono cellulare, nome, nome della famiglia, identificazione del conto finanziario e altri dati che potrebbero essere considerati dati personali.

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

Usare Always Encrypted per crittografare i dati inattivi e in transito. I dati crittografati vengono decrittografati solo dalle librerie client a livello di client dell'applicazione. Usare la crittografia casuale su deterministica laddove possibile. Always Encrypted con enclave sicuri può migliorare le prestazioni per le operazioni di confronto, ad esempio BETW edizione Enterprise N, IN, LIKE, DISTINCT, Join e altro ancora per scenari di crittografia casuale.

Usare Dynamic Data Masking (DDM) per offuscare i dati a livello di colonna quando Always Encrypted non è un'opzione disponibile. Dynamic Data Masking (DDM) non è compatibile con Always Encrypted. Usare Always Encrypted tramite maschera dati dinamica, quando possibile.

È anche possibile concedere autorizzazioni a livello di colonna a una tabella, una vista o una funzione con valori di tabella. Si consideri quanto segue: - È possibile concedere solo SELECTle autorizzazioni , REFERENCESe UPDATE in una colonna. - Un livello DENY di tabella non ha la precedenza su un livello GRANTdi colonna.

Protezione a livello di riga

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

La logica di business viene 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 FILTER predicati e BLOCK associati alle tabelle rispetto alla 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 edizione Standard SSION_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 ottenere prestazioni ottimali e gestibilità, seguire le procedure consigliate per la sicurezza a livello di riga.

Suggerimento

Usare la sicurezza a livello di riga insieme a Always Encrypted o Dynamic Data Masking (DDM) per ottimizzare il comportamento di sicurezza dell'organizzazione.

Crittografia 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 non possano essere allegati e tempdb letti senza certificati appropriati che decrittografino i file di database. Senza Transparent Data Encryption (TDE), è possibile che un utente malintenzionato prenda i supporti fisici (unità o nastri di backup) e ripristina o collega il database per leggere il contenuto. Transparent Data Encryption (TDE) è supportato per funzionare con tutte le altre funzionalità di sicurezza in SQL Server. Transparent Data Encryption (TDE) fornisce la crittografia E/O in tempo reale e la decrittografia dei file di dati e di log. La crittografia TDE usa una chiave di crittografia del database (DEK) archiviata nel database utente. La chiave di crittografia del database può essere protetta anche tramite un certificato, protetto dalla chiave master del master database.

Usare TDE per proteggere i dati inattivi, i backup e tempdb.

Controllo e creazione di report

Per controllare SQL Server, creare un criterio di controllo a livello di server o database. I criteri del server si applicano a tutti i database esistenti e appena creati nel 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.

Controlla tabelle e colonne con dati sensibili a cui sono applicate misure di sicurezza. Se una tabella o una colonna è sufficientemente importante da richiedere la protezione da una funzionalità di sicurezza, deve essere considerata sufficientemente importante da controllare. È particolarmente importante controllare e rivedere regolarmente le tabelle che contengono informazioni riservate, ma in cui non è possibile applicare le misure di sicurezza desiderate a causa di un certo tipo di applicazione o di limitazione dell'architettura.

Identità e autenticazione

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

Gli account di accesso sono separati dagli utenti del database. Prima di tutto, eseguire il mapping degli account di accesso o dei gruppi di Windows agli utenti o ai ruoli del database separatamente. Concedere quindi le autorizzazioni agli utenti, ai ruoli del server e/o ai ruoli del database per accedere agli oggetti di database.

SQL Server supporta i tipi di account di accesso seguenti:

  • Un account utente di Windows locale o un account di dominio Active Directory: SQL Server si basa su Windows per autenticare gli 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 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 master database.
  • Gli utenti del database indipendente autenticano le connessioni di SQL Server a livello di database. Un database indipendente è un database isolato da altri database e dall'istanza di SQL Server (e dal master database) che ospita il database. SQL Server supporta gli utenti del database indipendente per l'autenticazione di Windows e SQL Server.

Le raccomandazioni e le procedure consigliate seguenti consentono di proteggere le identità e i metodi di autenticazione:

  • Usare strategie di sicurezza basate sui ruoli con privilegi minimi per migliorare la gestione della sicurezza.

    • È standard posizionare gli utenti di Active Directory nei gruppi di Active Directory, i gruppi di Active Directory 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

  • Scegliere Active Directory sull'autenticazione di SQL Server quando possibile e, in particolare, scegliere Active Directory per archiviare la sicurezza a livello di applicazione o database.

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

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

  • Richiedere password complesse 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 del servizio gestito dal gruppo forniscono la gestione automatica delle password, la gestione semplificata del nome dell'entità servizio (SPN) e delegare la gestione ad altri amministratori.

    • Con l'account del servizio gestito del gruppo, il sistema operativo Windows gestisce le password per l'account invece di affidarsi all'amministratore per gestire la password.
    • gMSA aggiorna automaticamente le password dell'account senza riavviare i servizi.
    • gMSA riduce il livello di superficie amministrativa e migliora la separazione dei compiti.

  • Ridurre al minimo i diritti concessi all'account active directory 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à.

  • Provare a rimuovere gli account DBA dal ruolo sysadmin e concedere CONTROL edizione Standard RVER agli account DBA anziché renderli membri del ruolo sysadmin. Il ruolo di amministratore di sistema non rispetta DENY mentre CONTROL edizione Standard RVER.

Derivazione dei dati e integrità dei dati

Mantenere i record cronologici delle modifiche ai dati nel tempo può essere utile per risolvere le modifiche accidentali ai dati. Può anche essere utile per il controllo delle modifiche delle applicazioni e può ripristinare gli elementi di dati quando un attore non valido introduce modifiche ai dati non autorizzate.

  • Usare le tabelle temporali per mantenere le versioni dei record nel tempo e visualizzare i dati nel corso dell'intervallo di vita del record per fornire una visualizzazione cronologica dei dati dell'applicazione.
  • Le tabelle temporali possono essere usate per fornire una versione della tabella corrente in qualsiasi momento.

Strumenti di valutazione della sicurezza e valutazione

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

  • Configurazione superficie di attacco: è consigliabile abilitare solo le funzionalità richieste dall'ambiente, per ridurre al minimo il numero di funzionalità che possono essere attaccate da un utente malintenzionato.
  • Valutazione della vulnerabilità per SQL Server (SSMS): la valutazione della vulnerabilità di SQL è uno strumento in SSMS v17.4+ che consente di individuare, tenere traccia e correggere potenziali vulnerabilità del database. La valutazione della vulnerabilità è uno strumento prezioso per migliorare la sicurezza del database e viene eseguita a livello di database, per ogni database.
  • Individuazione e classificazione dei dati SQL ( SSMS): è comune per gli amministratori di database gestire server e database e non tenere conto della riservatezza dei dati contenuti nel database. Individuazione e 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 SQL comuni

È utile sapere quali sono alcune minacce comuni che rischiano SQL Server:

  • SQL injection: SQL injection è un tipo di attacco in cui il codice dannoso viene inserito in stringhe passate a un'istanza di SQL Server per l'esecuzione.
    • Il processo di inserimento funziona terminando una stringa di testo e aggiungendo un nuovo comando. Poiché il comando inserito potrebbe avere più stringhe accodate prima dell'esecuzione, l'utente malintenzionato termina la stringa inserita con un segno --di commento .
    • SQL Server esegue qualsiasi query sintatticamente valida ricevuta.
  • Tenere presente gli attacchi side-channel, il malware e altre minacce.

Rischi sql injection

Per ridurre al minimo il rischio di un attacco SQL injection, considerare gli elementi seguenti:

  • Esaminare qualsiasi processo SQL che costruisca istruzioni SQL per individuare le vulnerabilità di inserimento.
  • Costruire istruzioni SQL generate in modo dinamico in modo con parametri.
  • Gli sviluppatori e gli amministratori della sicurezza devono esaminare tutto il codice che chiama EXECUTE, EXECo sp_executesql.
  • Non consentire i caratteri di input seguenti:
    • ;: delimitatore di query
    • ': delimitatore stringa di dati di tipo carattere
    • --: delimitatore di commento a riga singola.
    • /* ... */: delimitatori di commento.
    • xp_: stored procedure estese dal 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 rischi xp_cmdshell che possono introdurre.
  • Convalidare sempre gli input dell'utente e eliminare gli output degli errori dalla perdita e dall'esposizione all'utente malintenzionato.

Rischi sul canale laterale

Per ridurre al minimo il rischio di un attacco sul canale laterale, considerare quanto segue:

  • Verificare che siano applicate le patch più recenti dell'applicazione e del sistema operativo.
  • Per i carichi di lavoro ibridi, assicurarsi che vengano applicate le patch del firmware più recenti per qualsiasi 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 la serie DC e Macchine virtuali che usano processori AMD EPYC di terza generazione.

Minacce all'infrastruttura

Considerare le minacce comuni dell'infrastruttura seguenti:

  • Accesso di forza bruta: l'utente malintenzionato tenta di eseguire l'autenticazione con più password in account diversi fino a quando non viene trovata una password corretta.
  • Password cracking/ password spray : gli utenti malintenzionati provano una singola password accuratamente creata su tutti gli account utente noti (una password a molti account). Se lo spraying password iniziale ha esito negativo, riprova, utilizzando una password diversa creata con attenzione, in genere in attesa di un determinato periodo di tempo tra i tentativi di evitare il rilevamento.
  • Gli attacchi ransomware sono un tipo di attacco mirato in cui il malware viene usato per crittografare dati e file, impedendo l'accesso a contenuti importanti. Gli utenti malintenzionati tentano quindi di estorcere denaro dalle vittime, di solito sotto forma di criptovalute, in cambio della chiave di decrittografia. La maggior parte delle infezioni ransomware inizia con messaggi di posta elettronica con allegati che tentano di installare ransomware, o siti Web che ospitano kit di exploit che tentano di usare vulnerabilità nei Web browser e altro software per installare ransomware.

Rischi per le password

Poiché non si vuole che gli utenti malintenzionati indovinano 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 Amministrazione istrator.
  • 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 disporre di 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 abilita l'autenticazione SQL durante il provisioning, è necessario modificare manualmente la modalità di autenticazione in SQL Server e modalità di autenticazione di Windows. Per altre informazioni, vedere Modificare la modalità di autenticazione del server.

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

Rischi ransomware

Considerare quanto segue per ridurre al minimo i rischi ransomware:

  • La strategia migliore per proteggersi dal ransomware è prestare particolare attenzione alle vulnerabilità RDP e SSH. Considerare anche le raccomandazioni seguenti:
    • Usare firewall e bloccare le porte
    • Verificare che vengano applicati gli aggiornamenti più recenti del sistema operativo e della sicurezza delle applicazioni
    • Usare gli account del servizio gestito del gruppo (gMSA)
    • Limitare l'accesso alle macchine virtuali
    • Richiedere l'accesso JIT (Just-In-Time) e Azure Bastion
    • Migliorare la sicurezza di Surface Area evitando l'installazione di strumenti, tra cui sysinternals e SSMS nel computer locale
    • Evitare di installare funzionalità di Windows, ruoli e abilitazione di servizi non necessari
    • Inoltre, è necessario pianificare un normale backup completo protetto separatamente da un account amministratore comune in modo che non possa eliminare copie dei database.

Contenuto correlato