Microsoft ha una serie di funzionalità di sicurezza in SQL Server 2017 che sono utili per scopi diversi, a seconda di cosa si sta tentando di proteggere e da quali minacce si sta tentando di proteggersi. Alcune di queste funzionalità di sicurezza possono avere implicazioni sulle prestazioni di cui dovresti essere a conoscenza quando decidi quali desideri implementare. Come introduzione, tratterò alcuni punti salienti di molte di queste funzionalità di sicurezza.
Crittografia database trasparente (TDE)
Transparent Data Encryption (TDE) è la forma di crittografia inattiva di SQL Server, il che significa che i file di dati, il file di registro, i file tempdb e i backup completi, differenziali e di registro di SQL Server verranno crittografati quando si abilita TDE su un database utente . Ciò protegge i tuoi dati dall'accesso a tali database o file di backup del database, a condizione che tale persona non abbia accesso anche ai certificati e alle chiavi di crittografia.
La scansione iniziale della crittografia TDE per un database utente utilizzerà un thread CPU in background per file di dati nel database (se i file di dati si trovano su unità logiche separate), per leggere lentamente l'intero contenuto del file di dati in memoria alla velocità di circa 52 MB/secondo per file di dati (se i file di dati si trovano su unità logiche separate).
I dati vengono quindi crittografati con l'algoritmo di crittografia scelto e quindi riscritti nel file di dati a circa 55 MB/secondo (per file di dati, se si trovano su unità logiche separate). Queste velocità di lettura e scrittura sequenziale sembrano essere volutamente limitate e sono coerenti nei miei test su più sistemi con vari tipi di storage.
Il processo di crittografia TDE iniziale avviene a livello di pagina, sotto SQL Server, quindi non causa il blocco o genera attività del registro delle transazioni come si vedrebbe con la ricostruzione di un indice. Puoi mettere in pausa una scansione di crittografia TDE abilitando TF 5004 globale e riattivarla disabilitando TF 5004 ed eseguendo nuovamente il comando ALTER DATABASE dbNAME SET ENCRYTION ON, senza perdita di avanzamento.
L'impatto della crittografia/decrittografia sulla CPU è notevolmente ridotto in SQL Server 2016 e versioni successive se si dispone di un processore che supporta le istruzioni hardware AES-NI. Nello spazio server, questi sono stati introdotti nella famiglia di prodotti Intel Xeon 5600 (Westmere-EP) per server a due socket e nella famiglia di prodotti Intel Xeon E7-4800/8800 (Westmere-EX) per server a quattro e otto socket. Qualsiasi nuova famiglia di prodotti Intel avrà anche il supporto AES-NI. Se hai dei dubbi sul fatto che il tuo processore supporti AES-NI, puoi cercare "AES" nel campo delle istruzioni emesso da CPU-Z, come vedi nella Figura 1.
Figura 1:uscita CPU-Z che mostra il supporto per le istruzioni AES
Dopo aver crittografato un database con TDE, l'impatto di runtime di TDE è difficile da quantificare in modo prevedibile perché dipende assolutamente dal carico di lavoro. Se, ad esempio, il carico di lavoro si adatta interamente al pool di buffer di SQL Server, non ci sarebbe essenzialmente un sovraccarico da TDE. Se invece il tuo carico di lavoro consistesse interamente in scansioni di tabelle in cui la pagina viene letta e poi svuotata quasi immediatamente, ciò imporrebbe la massima penalità. La penalità massima per un carico di lavoro volatile di I/O è in genere inferiore al 5% con hardware moderno e con SQL Server 2016 o versioni successive.
Il lavoro extra della decrittografia TDE si verifica quando si leggono i dati nel pool di buffer dall'archiviazione e il lavoro aggiuntivo della crittografia TDE si verifica quando si riscrivono i dati nell'archiviazione. Assicurarsi di non essere sotto pressione di memoria, disponendo di un pool di buffer sufficientemente grande ed eseguendo l'ottimizzazione dell'indice e delle query ridurrà ovviamente l'impatto sulle prestazioni di TDE. TDE non crittografa i dati FILESTREAM e un database crittografato TDE non utilizzerà l'inizializzazione dei file istantanea per i propri file di dati.
Prima di SQL Server 2016, TDE e la compressione di backup nativa non funzionavano bene insieme. Con SQL Server 2016 e versioni successive, è possibile utilizzare TDE e la compressione di backup nativa insieme, purché si specifichi un MAXTRANSFERSIZE maggiore di 64 KB nel comando di backup. È anche molto importante che tu sia aggiornato con gli aggiornamenti cumulativi, poiché ci sono stati più hotfix importanti relativi a TDE sia per SQL Server 2016 che per SQL Server 2017. Infine, TDE è ancora una funzionalità unica di Enterprise Edition, anche dopo SQL Server 2016 SP1 (che ha aggiunto molte funzionalità solo Enterprise all'edizione Standard).
Sicurezza a livello di riga (RLS)
Row-Level Security (RLS) limita l'accesso in lettura e la maggior parte dell'accesso a livello di scrittura in base agli attributi dell'utente. RLS utilizza il cosiddetto controllo dell'accesso basato su predicati. SQL Server applica le restrizioni di accesso nel livello del database e verranno applicate ogni volta che si tenta di accedere ai dati da qualsiasi livello.
RLS funziona creando una funzione di predicato che limita le righe a cui un utente può accedere e quindi utilizzando una politica di sicurezza e un predicato di sicurezza per applicare tale funzione a una tabella.
Esistono due tipi di predicati di sicurezza, che sono predicati di filtro e predicati di blocco. I predicati del filtro filtreranno automaticamente le righe disponibili per le operazioni di lettura (SELECT, UPDATE e DELETE), aggiungendo essenzialmente una clausola WHERE che impedisce la visualizzazione delle righe filtrate nel set di risultati. I predicati del filtro vengono applicati durante la lettura dei dati dalla tabella di base e l'utente o l'applicazione non sapranno che le righe vengono filtrate dai risultati. È importante, dal punto di vista delle prestazioni, disporre di un indice dell'archivio righe che copra il predicato del filtro RLS.
Predicati di blocco in modo esplicito, (con un messaggio di errore) operazioni di scrittura del blocco (AFTER INSERT, AFTER UPDATE, BEFORE UPDATE e BEFORE DELETE) che violerebbero il predicato di blocco.
I predicati di filtro e blocco vengono creati come funzioni inline con valori di tabella. Sarà inoltre necessario utilizzare l'istruzione CREATE SECURITY POLICY T-SQL per applicare e abilitare la funzione di filtro alla tabella di base pertinente
RLS è stato aggiunto in SQL Server 2016 ed è disponibile in tutte le edizioni di SQL Server 2016 e successive. RLS non funzionerà con Filestream, Polybase e viste indicizzate. RLS può compromettere le prestazioni della ricerca full-text e può costringere le query degli indici columnstore a utilizzare la modalità riga anziché la modalità batch. Questo post del blog Microsoft contiene ulteriori informazioni sull'impatto sulle prestazioni di RLS. Un buon esempio di come utilizzare Query Store per ottimizzare le prestazioni di RLS è qui.
Dynamic Data Masking (DDM)
Il Dynamic Data Masking (DDM) può aiutare a limitare l'esposizione dei dati sensibili mascherandoli agli utenti non privilegiati. DDM viene applicato a livello di tabella, quindi tutte le query sono interessate dal mascheramento dei dati, mentre le regole di mascheramento effettive vengono applicate nelle singole colonne della tabella.
Esistono quattro tipi di maschere di dati che puoi utilizzare, che includono predefinita, e-mail, stringa personalizzata e casuale. Una maschera predefinita fornisce una mascheratura predefinita completa dei dati a seconda del tipo di dati. Ad esempio, un tipo di dati stringa otterrebbe una maschera di "XXXX" invece dei dati effettivi. Una maschera e-mail restituirà la prima lettera dell'indirizzo e-mail effettivo, seguita da [email protected], indipendentemente dal suffisso del dominio effettivo. Una maschera di stringa personalizzata mostrerà la prima e l'ultima lettera della stringa, con un riempimento personalizzato nel mezzo. Infine, viene utilizzata una maschera casuale per mascherare i dati numerici e fornire un valore casuale in un intervallo definito. Le maschere di dati possono essere create in un'istruzione CREATE TABLE o con un'istruzione ALTER COLUMN.
Il mascheramento dinamico dei dati non fornisce alcun mascheramento per gli utenti con privilegi che possono comunque eseguire query direttamente sulle tabelle e visualizzare i dati non mascherati. Le regole di mascheramento non possono essere utilizzate con colonne crittografate (sempre crittografate), colonne calcolate o con dati Filestream. Se sono presenti indici su una colonna che vuoi mascherare, dovrai eliminare l'indice, creare la maschera sulla colonna e quindi ricreare l'indice. È anche possibile dedurre i valori per colonne di dati mascherati scrivendo query che consentono all'utente di indovinare eventualmente un valore per una colonna mascherata.
Il Dynamic Data Masking è stato introdotto in SQL Server 2016 ed è disponibile in tutte le edizioni di SQL Server. DDM non è pensato per essere una misura di sicurezza forte come la crittografia effettiva, ma d'altra parte, il suo impatto sulle prestazioni sembra essere abbastanza trascurabile.
