Come gestire la protezione dei dati in SQL Server: Le tre modalità di stato dei dati e le soluzioni di cifratura

Nel contesto della gestione dei dati sensibili, è fondamentale comprendere le tre possibili modalità di stato in cui un dato può trovarsi. Questi stati, sebbene semplici nella loro definizione, pongono sfide diverse in termini di sicurezza, necessitando approcci specifici per garantire la protezione. Il dato "a riposo" (data at rest), il dato "in transito" (data in transit) e il dato "in uso" (data in use) presentano infatti vulnerabilità differenti e, per ciascuna di queste situazioni, esistono soluzioni di cifratura diverse. L’obiettivo di queste tecniche è proteggere i dati da accessi non autorizzati, riducendo al minimo il rischio di esposizione.

Dati in transito (data in transit): Quando i dati vengono trasmessi tra diversi nodi, sia su una rete privata che su Internet, il rischio di intercettazione aumenta. I dati, pur essendo protetti attraverso protocolli di sicurezza come TLS (Transport Layer Security), possono essere vulnerabili durante la trasmissione. A questo riguardo, SQL Server implementa tecniche di cifratura come TLS per proteggere i dati mentre si trovano in transito, garantendo che i dati non possano essere letti o alterati durante il trasferimento.

Dati in uso (data in use): I dati che sono attivamente caricati nella memoria RAM o nella cache della CPU sono considerati dati in uso. Questa è la situazione più complessa dal punto di vista della protezione, poiché i dati sono temporaneamente decrittografati per poter essere elaborati. La cifratura dei dati in uso viene gestita da tecnologie come "Always Encrypted", che consente di mantenere la cifratura a livello di singoli oggetti, come colonne specifiche in una tabella. Questo approccio garantisce che i dati rimangano cifrati sia quando sono a riposo che durante il loro utilizzo, impedendo agli amministratori o ad altri utenti con privilegi di visualizzare informazioni sensibili.

Una delle caratteristiche chiave di SQL Server e Azure SQL è la capacità di implementare la cifratura a livello di oggetti attraverso la funzionalità "Always Encrypted". Con questa tecnica, le colonne specifiche (ad esempio, il numero di previdenza sociale o i numeri di carta di credito) vengono cifrate in modo tale che solo l'applicazione con la chiave di cifratura appropriata possa decrittografarle. In questo modo, anche gli amministratori del database non possono visualizzare i dati sensibili.

Un ulteriore strumento importante nella protezione dei dati è la configurazione delle regole di firewall a livello di server e database. In Azure SQL Database, i firewall possono essere configurati per limitare l'accesso alle risorse solo a indirizzi IP specifici, sia a livello di server che di singolo database. Questo tipo di protezione è essenziale per evitare attacchi da fonti esterne non autorizzate. Le regole del firewall possono essere configurate facilmente tramite il portale Azure, garantendo un controllo preciso su chi può accedere ai dati e da dove.

Quando si implementano misure di cifratura a livello di oggetti, come "Always Encrypted", è essenziale che l’amministratore comprenda le implicazioni di questa scelta. La cifratura a livello di oggetto non solo protegge i dati quando sono a riposo e in transito, ma evita anche che i dati vengano decrittografati o visualizzati in chiaro, garantendo che solo l'applicazione specifica con la chiave di cifratura possa accedervi.

È inoltre importante sapere che l'implementazione di Always Encrypted in SQL Server e Azure SQL Database prevede l’uso delle enclave sicure, che consentono di eseguire query su dati cifrati mantenendo un elevato livello di compatibilità. Le enclave sicure sono ambienti isolati che permettono l'esecuzione di operazioni sui dati senza comprometterne la sicurezza.

Per concludere, la protezione dei dati in un database SQL richiede una comprensione approfondita dei diversi stati in cui i dati si trovano e delle tecniche appropriate per ciascuno di essi. La cifratura è la principale misura di sicurezza per ciascuna di queste situazioni, ma la gestione delle chiavi, la configurazione dei firewall e l'uso di tecniche avanzate come Always Encrypted sono cruciali per garantire la riservatezza e l'integrità dei dati.

Come Configurare e Gestire un Server SQL su una VM di Azure: Una Guida Completa

Quando un sottoscrittore seleziona l’opzione "Inizia con una configurazione predefinita", il modello di Azure solitamente suggerisce una serie di raccomandazioni per l’hardware della macchina virtuale, basandosi sul tipo di carico di lavoro previsto, come mostrato nella Figura 1-5. Sebbene sia possibile modificare la configurazione hardware della macchina virtuale in qualsiasi momento, i modelli di Azure Marketplace offrono un valido aiuto per semplificare questo processo di configurazione iniziale.

Dopo aver scelto la configurazione hardware virtuale della macchina, appare una finestra di dialogo a schede, come evidenziato nella Figura 1-6, dove l'utente deve inserire alcuni parametri di base per la macchina virtuale, tra cui il nome della macchina, il gruppo di risorse, la rete virtuale e le credenziali per l'account amministrativo della VM. Le schede includono anche una vasta gamma di altre opzioni per la configurazione della macchina virtuale e di SQL Server. Il modello precompila i valori predefiniti per molte delle opzioni più comuni relative alla VM in base al piano selezionato.

Ulteriori opzioni includono la gestione della dimensione e delle prestazioni dei dati di SQL Server, la gestione delle istanze SQL, l'opzione di licenza di SQL Server (se l'utente possiede già una licenza), l'aggiornamento automatico e la possibilità di configurare backup automatici dei database SQL. È anche possibile abilitare SQL Server Machine Learning Services, offrendo l'accesso ad analisi avanzate su SQL Server.

Per coloro che utilizzano SQL Server come parte di una macchina virtuale, l'IaaS Agent di SQL Server offre molte funzionalità di gestione avanzate. Dopo che l'estensione dell'agent è stata registrata, Azure copia i file necessari sulla macchina virtuale, ma l’installazione dell’agente avviene solo quando l'utente abilita l'estensione corrispondente. L'agente consente di gestire SQL Server direttamente dal portale di Azure, offrendo una gestione centralizzata e una maggiore flessibilità di licenza, che permette di passare dal modello “Bring Your Own License” a quello pay-as-you-go.

L'estensione offre anche funzionalità avanzate come il backup automatico, la gestione degli aggiornamenti (con la possibilità di scegliere tra l’aggiornamento automatico o l'Azure Update Manager), e l'integrazione con Azure Key Vault per la gestione sicura delle chiavi di crittografia. È importante notare che Azure Update Manager e la funzione di aggiornamento automatico non sono compatibili tra loro; pertanto, è necessario abilitare solo uno dei due per evitare conflitti non intenzionati.

Un'altra funzionalità utile è la configurazione dello spazio di archiviazione temporaneo di SQL Server (tempdb), che può essere personalizzata in base alle esigenze del carico di lavoro, specificando il numero di file, la loro dimensione iniziale, la posizione e la dimensione di crescita automatica. Inoltre, grazie all'integrazione con il Defender for Cloud, è possibile monitorare la sicurezza del server SQL, ricevendo suggerimenti su come migliorarne la protezione.

Nel caso in cui vengano eseguite modifiche alla versione o all'edizione di SQL Server sulla macchina virtuale, l'utente deve procedere a una nuova registrazione dell'agente, ma potrà farlo direttamente dal portale di Azure o utilizzando gli strumenti come Azure CLI o PowerShell.

Microsoft Azure offre diverse opzioni per la creazione di nuove istanze di database SQL. Accedendo alla pagina dedicata all'Azure SQL, gli utenti possono visualizzare tutte le proprie istanze di database esistenti e creare nuove risorse SQL in base alle necessità specifiche. Questo approccio, unitamente all’accesso centralizzato alle funzioni di gestione, facilita notevolmente l'amministrazione e la manutenzione dei sistemi SQL su Azure.

Come Proteggere i Dati SQL Server: Soluzioni HA/DR e Strategie di Backup

Nel contesto della protezione dei dati e della continuità operativa, è fondamentale comprendere le soluzioni High Availability (HA) e Disaster Recovery (DR) offerte da Azure e SQL Server. Queste tecnologie non solo assicurano la protezione dei dati in tempo reale, ma consentono anche di minimizzare il rischio di perdita di informazioni a causa di guasti hardware o software. Oltre alle funzionalità integrate di HA/DR in SQL Server, Azure fornisce meccanismi indipendenti per le macchine virtuali, che contribuiscono a garantire una protezione robusta e scalabile.

Le Availability Zones sono un altro strumento fondamentale per garantire alta disponibilità. Ogni regione Azure è composta da più datacenter che vengono suddivisi in zone da 1 a 3. Distribuendo le proprie VM su zone differenti, gli utenti di Azure possono evitare che eventi catastrofici che colpiscono un datacenter compromettano tutti i servizi nella regione. In questo modo, anche in caso di disastri su larga scala, le macchine virtuali in altre zone restano operative, continuando a garantire l'accesso ai dati.

Un ulteriore strumento di protezione è Azure Site Recovery, che consente di replicare una VM da una regione a un'altra. In caso di disastro che rende inaccessibile un'intera regione, il recupero avviene da una seconda zona, garantendo la disponibilità continua del servizio. Tuttavia, è importante sottolineare che Azure Site Recovery opera solo a livello di VM e non tiene conto delle transazioni specifiche di SQL Server o di altri software in esecuzione sulla macchina virtuale.

Implementare una soluzione HA/DR non è sufficiente senza testarla per verificarne l'efficacia. Le tecnologie HA/DR devono essere messe alla prova per confermare che funzionino come previsto. Diverse modalità di test, come i test checklist, tabletop e simulation, offrono livelli diversi di realismo e coinvolgimento. La scelta della metodologia dipende dalle esigenze aziendali, ma l’obiettivo è garantire che il piano di recupero funzioni in scenari realistici, minimizzando il tempo di inattività e la perdita di dati.

La gestione dei backup è un'altra componente fondamentale della strategia HA/DR. Sebbene le tecnologie avanzate possano essere costose e complesse, il backup dei dati non è opzionale e deve essere pianificato in modo accurato. In un ambiente Azure, le soluzioni di backup si differenziano a seconda che si utilizzi una piattaforma IaaS o PaaS. Nel caso di IaaS, dove SQL Server è installato su una macchina virtuale, gli amministratori hanno a disposizione soluzioni di backup a più livelli, dal software SQL Server fino all’ambiente Azure stesso.

Nel caso delle soluzioni PaaS, come Azure SQL Database e Azure SQL Managed Instance, i backup vengono eseguiti automaticamente: un backup completo settimanale, un backup differenziale due volte al giorno e un backup del log delle transazioni ogni 10 minuti. Questi backup sono archiviati in Azure Blob Storage, con una ridondanza geografica che assicura che i dati siano protetti anche in caso di guasto del datacenter.

Per quanto riguarda il backup e il ripristino di un database SQL Server, gli amministratori possono utilizzare SQL Server Management Studio (SSMS) per eseguire operazioni di backup e ripristino. È possibile scegliere tra diversi tipi di backup, come completo, differenziale e del log delle transazioni, a seconda delle necessità. Inoltre, le opzioni di ripristino permettono di scegliere uno stato di Recovery che consente di applicare backup successivi, come quelli differenziali o del log delle transazioni, per garantire una ripresa continua e senza perdita di dati.

Quando si esegue un ripristino da un backup, SQL Server offre diverse opzioni per gestire i comportamenti di sovrascrittura e completamento delle transazioni non confermate. In particolare, il ripristino "con recovery" consente di rendere il database immediatamente disponibile, mentre l’opzione "con standby" permette di mantenere il database in uno stato di recupero, consentendo l'applicazione di ulteriori backup successivi.

In aggiunta a questi strumenti, è importante considerare le politiche di retention dei backup a lungo termine. Azure fornisce la possibilità di archiviare i backup per periodi prolungati, per garantire la possibilità di recupero anche in caso di necessità di risalire a punti molto precedenti nel tempo. Le politiche di backup e ripristino devono essere progettate tenendo conto delle esigenze aziendali specifiche, inclusi gli obblighi normativi e i vincoli di spazio di archiviazione.

Tutto ciò che è stato discusso fino ad ora riguarda soluzioni ad alta disponibilità e di recupero da disastri, ma ciò che rimane cruciale per qualsiasi strategia IT è l'automazione e la pianificazione continua. I sistemi di backup devono essere regolarmente monitorati e testati per assicurarsi che siano pronti a rispondere a qualsiasi imprevisto. La personalizzazione dei processi di backup, in base alla struttura dei dati e ai flussi di lavoro aziendali, è fondamentale per ottimizzare la gestione delle risorse e garantire la protezione continua dei dati.

Come scegliere l'offerta di database più appropriata in base ai requisiti specifici?

La piattaforma Azure offre una vasta gamma di prodotti SQL, ma spesso i sottoscrittori si trovano a dover fare una scelta complessa tra le diverse infrastrutture cloud, modelli di acquisto e livelli di servizio disponibili. Sebbene molte di queste opzioni siano adeguate per esigenze di database di base, la selezione di un'offerta deve sempre bilanciare il compromesso tra performance e prezzo.

IaaS vs PaaS

Al contrario, il modello PaaS offre un livello superiore di gestione, in cui il sottoscrittore non ha accesso diretto alla macchina virtuale che ospita il database SQL né agli elementi sottostanti dell'infrastruttura. Sebbene questa mancanza di accesso possa essere vista come uno svantaggio, offre anche il vantaggio di delegare la gestione dell'infrastruttura al provider cloud, consentendo agli utenti di concentrarsi sulla gestione del database SQL stesso. In altre parole, nel modello PaaS, il provider si occupa della gestione hardware e software di basso livello, lasciando al sottoscrittore la sola responsabilità della gestione e configurazione del database.

Le opzioni PaaS per SQL

Nel contesto di Azure, le opzioni PaaS per SQL Server sono più facili da implementare rispetto a IaaS, in quanto non richiedono la configurazione e la gestione diretta delle macchine virtuali. Le principali soluzioni offerte da Azure sono:

• Azure SQL Database: un database SQL virtualizzato, con bassa manutenzione, grande flessibilità e scalabilità.

• Azure SQL Managed Instance: un'istanza SQL completamente gestita, ideale per migrare le installazioni SQL locali verso il cloud.

• Azure SQL Edge: una soluzione ottimizzata per l'edge computing e i dispositivi IoT.

Una delle grandi potenzialità delle soluzioni SQL in Azure è la loro natura virtuale, che consente agli utenti di adattare facilmente le risorse del database in base alle necessità. È possibile scalare orizzontalmente creando più istanze o database, oppure scalare verticalmente aumentando lo storage, le risorse computazionali o cambiando i livelli di servizio. Inoltre, Azure consente la migrazione tra diverse soluzioni di database, come il passaggio da Azure SQL Database a SQL Managed Instance, quando le necessità evolvono.

Modelli di acquisto PaaS

Azure offre due modelli principali di acquisto per le soluzioni SQL PaaS: il modello basato su DTU (Database Transaction Unit) e quello basato su vCore.

• DTU: Il modello basato su DTU fornisce un'opzione semplificata con livelli di servizio preconfigurati. Una DTU è una misura combinata di cicli CPU, risorse di memoria, letture e scritture I/O allocate a un singolo database SQL. È un'opzione che funziona bene per applicazioni con requisiti di carico non particolarmente complessi. I sottoscrittori possono scegliere tra tre livelli di servizio: base, standard e premium, che offrono diverse capacità di calcolo, dimensioni massime del database e periodi di conservazione dei backup.

• vCore: Il modello basato su vCore, disponibile sia per Azure SQL Database che per Azure SQL Managed Instance, offre maggiore flessibilità e scalabilità. Questo modello consente di configurare e scalare in modo indipendente le risorse di calcolo, memoria e storage. Un vCore è una rappresentazione logica di una CPU, combinata con limitazioni di memoria e storage. Il modello vCore è utile per carichi di lavoro più complessi che richiedono risorse scalabili e configurabili in modo indipendente. I sottoscrittori possono scegliere tra tre livelli di servizio: General Purpose, che supporta carichi di lavoro tipici a prezzi contenuti; Business Critical, che offre performance I/O superiori con SSD locali e maggiore tolleranza ai guasti; e Hyperscale, che è pensato per carichi di lavoro altamente scalabili, con risorse di calcolo e storage indipendenti e limiti molto più elevati rispetto agli altri livelli.

Differenze tra DTU e vCore

Prezzi e fattori da considerare

Nel modello vCore, il prezzo dipende da vari fattori: il livello di servizio scelto, la configurazione hardware, il numero di vCore, la memoria, lo storage e il backup. Inoltre, Azure offre due opzioni per la gestione delle risorse di calcolo: Provisioned, che assegna continuamente risorse di calcolo al database, e Serverless, che permette a Azure di allocare dinamicamente le risorse in base all'attività del database, addebitando solo i periodi di utilizzo.

Considerazioni finali

Nel momento in cui si sceglie l'offerta SQL giusta su Azure, è fondamentale comprendere che l'infrastruttura virtualizzata consente una grande flessibilità e un'agevole adattabilità alle esigenze in evoluzione. Indipendentemente dalle dimensioni o dalla complessità delle necessità, Azure offre un’ampia varietà di soluzioni che possono essere scalate, modificate e adattate in qualsiasi momento.