Recentemente è stata introdotta una serie di nuove e più efficaci misure di sicurezza per controllare e monitorare l’accesso ai database SQL di Azure. Queste includono Auditing, Dynamic Data Maskin, Row-level Security e Transparent Data Encryption. In questa prima parte darò la mia valutazione sulle prime due e sulla probabilità che io le utilizzi.
Azure SQL Auditing è disponibile al pubblico da novembre, ma le altre misure di sicurezza che recensirò sono ancora in fase di anteprima e sono disponibili solo con le versioni V12 del database SQL di Azure.
La mia conclusione: Auditing fornisce un metodo a basso impatto ed economicamente vantaggioso per le attività di auditing che riguardano il database e raccomanderei di attivarlo per quei database nei quali la sicurezza e la compliance siano particolarmente importanti.
Auditing per i database Azure SQL è stato messo a disposizione del grande pubblico recentemente e fornisce il metodo più semplice per tracciare le attività del vostro database. L’unico costo aggiuntivo è la tabella di archiviazione Azure per registrare le attività tracciate.
Abilitare e configurare Auditing dal portale di gestione di Azure è piuttosto semplice. L’unica vera decisione riguarda i tipi di attività da mettere sotto controllo, qui elencate: accesso ai dati, cambiamenti di schema, cambiamenti di dati, incidenti di sicurezza, o garantisci/revoca autorizzazioni. Come potete vedere, queste opzioni sono piuttosto rozze e non c’è modo di applicare filtri prima che vengano registrate, perciò ci penserei due volte prima di selezionare “Accesso ai Dati”, in particolar modo. È utile sapere che si tratta di opzioni che possono essere riconfigurate in qualunque momento e che le impostazioni avranno effetto immediato a ogni nuova connessione. Per archiviare i registri di audit, potete scegliere uno storage account di Azure, che creerà un’unica tabella chiamata “SQLDBAuditLogs20140928”. All’inizio l’estensione temporale della tabella mi ha confuso, ma la prospettiva è che Auditing creerà regolarmente nuove tabelle con la data corrente. Il fatto che le attività vengano solo registrate in una tabella di Azure rafforza il posizionamento che Microsoft ha pensato per Auditing: fornire un tool per consultare lo storico delle attività, più che per monitorare le attività in corso o per mettere in guardia da potenziali problemi.
Il portale Azure fornisce un link per scaricare un workbook Excel che può essere utilizzato per interrogare e analizzare i dati contenuti nei registri audit. Questo avviene tramite un set prestabilito di grafici e tabelle pivot basato su un modello di dati Power Pivot e una query Power Query, con funzione di ricerca estesa fino ai dati grezzi. Questo mi è parso molto utile per testare il mio set-up di Auditing e non escluderei una maggiore personalizzazione, nonché il deploy su un sito Power BI, anche se nutro ancora dei dubbi sul modo migliore di utilizzarre e visualizzare i dati di audit. Qui sono descritti il formato e la struttura dei registri di audit.
Un ultimo punto da sottolineare è che Auditing può soltanto registrare attività legate alle connessioni al database che utilizzano stringhe di connessione con protezione di sicurezza. Di default, l’accesso con protezione di sicurezza è opzionale, cosa che è utile per finalità di test, ma che probabilmente ostacolerebbe l’intenzione di abilitare l’auditing a meno che non fosse richiesto per un database di produzione. Sarete sempre in grado di riconoscere una connessione con protezione di sicurezza, perché il nome del server SQL di Azure avrà il suffisso “database.secure.windows.net”.
La mia conclusione: Dynamic Data Masking potrebbe essere utilizzato per fornire a colonne individuali che contengano informazioni particolarmente sensibili un metodo semplice per rafforzare il controllo dell’accesso ai dati, ma sarebbe uno strumento piuttosto scarso. Il risultato sarebbe che o un login dispone di accesso illimitato a tutti i dati o avrà restrizioni nell’accesso ai dati mascherati. Personalmente non riesco a considerare l’idea di includere questo prodotto nella progettazione di un database.
Come per l’auditing, anche il mascheramento dinamico dei dati si basa su una connessione con protezione di sicurezza, perciò dovreste adottarla come prerequisito.
Una volta attivato il mascheramento dinamico dei dati dal Portale di Gestione di Azure, vengono mostrate le seguenti opzioni di configurazione:
Anche con il mascheramento dati attivato, l’accesso ai dati è illimitato per tutti gli utenti, finché non vengono definiti uno o più data mask. Un data mask può essere applicato ad una colonna in una tabella o a un alias di colonna in una query. Usare un alias come un elemento mascherato naturalmente non imporrà una restrizione categorica alla serie di dati sottostanti, ma questa opzione è da preferire quando la sorgente della serie di dati sottostanti non può essere legata ad una colonna individuale di tabella.
Esiste tutta una serie predefinita di funzioni per il mascheramento dei dati: mascheramenti parziali per le carte di credito, sicurezza sociale e numeri email, numeri random per valori numerici, mascheramenti parziali per dati di stringa, o valori sostitutivi con default specifici a seconda dei tipi di dati. Avrei preferito vedere un’impostazione più flessibile per poter creare modelli personalizzati di mascheramento dati.
Un’altra preoccupazione che nutro è la configurazione di login privilegiati e i vari data mask come liste statiche nel portale di gestione di Azure. Sono entrambi degli elementi potenzialmente dinamici dei metadati dell’applicazione, con login che devono tenere conto delle connessioni all’applicazione, così come degli utenti individuali e i data mask che devono tenere conto dei cambiamenti della struttura del database. Non so da quale altra parte potrebbero essere queste informazioni, ma temo nel posto sbagliato.
Per finire, non c’era una descrizione dettagliata sulla funzionalità dell’opzione “Use Extended Restrictions”, ma, dalle prove fatte, sembra che impedisca la connessione al database da parte di utenti non privilegiati che utilizzano SQL Management Objects (SMO) o equivalenti precedenti. Questo spiega perché Microsoft avverte che questa opzione potrebbe compromettere la funzionalità dell’applicativo.