Protezione dei dati sensibili in SQL Server 2005
a cura di Luca Bianchi (requisiti: conoscenza intermedia di SQL Server)

Premessa
Attenzione: le informazioni e gli esempi contenuti in questo articolo si riferiscono alla build 9.00.1187 di SQL Server 2005 nota anche come IDW15 o June CTP.

La protezione e la riservatezza dei dati sono, da sempre, una delle attività di un database administrator ed il patrimonio informativo di ciascuna azienda ha un valore che va al di là di ogni quantificazione economica visto che l'indisponibilità delle informazioni può mettere a repentaglio la sopravvivenza stessa dell'azienda.

Agli obblighi di tipo morale e professionale che da sempre hanno caratterizzato l'esigenza di proteggere alcune informazioni, si aggiungono ora dei precisi adempimenti legislativi la cui inosservanza può avere risvolti anche in campo penale.
La pianificazione di una attenta politica di controllo degli accessi e di auditing degli account pone il database server ad un livello di sicurezza molto elevato. Tuttavia, per un sottoinsieme di informazioni che le disposizioni di legge o l'organizzazione aziendale reputano più sensibili, potrebbe essere richiesto un innalzamento del grado di protezione.

In questo articolo, illustrerò le funzionalità relative alla protezione dei dati sensibili presenti in SQL Server 2005.

Come si faceva prima e come si può fare ora
Nelle versioni recenti di SQL Server era già possibile cifrare i dati utilizzando alcune funzioni non documentate (ENCRYPT e PWDENCRYPT) messe a disposizione dal T-SQL. Tuttavia, a dispetto del loro nome, sarebbe più congruo definirle delle funzioni di hash che non delle vere e proprie funzioni di criptazione dal momento che con esse è impossibile risalire al valore originario partendo dal valore cifrato e non sono noti gli algoritmi di cifratura.

SQL Server 2005 introduce delle nuove funzionalità volte alla cifratura dei dati che contribuiscono al rafforzamento della protezione a salvaguardia delle informazioni più sensibili.
La criptazione e la decriptazione dei dati in SQL Server 2005 può avvenire attraverso

La sicurezza aggiuntiva che possiamo ottenere cifrando una parte delle informazioni ha ovviamente un costo. La creazione, l'archiviazione e la gestione delle chiavi e dei certificati è un onere amministrativo che bisogna assumersi e l'overhead a carico del sistema, dipendente dalle attività di cifratura, può assumere livelli significativi.

Cifratura con funzioni T-SQL
Prima di procedere con degli esempi di cifratura dei dati, creiamo nella nostra istanza di SQL Server 2005 un database, denominato CryptoDB, all'interno del quale definiamo una tabella che contiene i dati identificativi di una carta di credito 

  USE master;

  IF EXISTS (SELECT 1 FROM sys.databases WHERE name = 'CryptoDB')
      DROP DATABASE CryptoDB;

  CREATE DATABASE CryptoDB;

  USE CryptoDB;

  CREATE TABLE dbo.CreditCard (
      ID SMALLINT IDENTITY (1, 1) NOT NULL,
      Nome VARCHAR(20) NOT NULL,
      Tipo VARCHAR(20) NOT NULL,
      Numero VARBINARY(128) NOT NULL,
      Note VARCHAR(255) NULL
  );
  GO

Uno dei metodi a nostra disposizione per cifrare i dati è quello di utilizzare le funzioni T-SQL EncryptByPassPhrase() e DecryptByPassPhrase(). La protezione dei dati eseguita per mezzo di queste funzioni si basa sull'utilizzo di una password che deve essere a conoscenza sia di chi esegue la cifratura che di chi intende leggere i dati. Un esempio di come è possibile implementare questo metodo è riportato nel codice che segue 

  INSERT dbo.CreditCard VALUES (
      'Alessandro',
      'Visa',
      EncryptByPassPhrase('Fj!58;<è§a2$X ç(#2', '1234-5678-9012-3456'),
      'Cifrato con EncryptByPassPhrase');

  SELECT Nome,
      Tipo,
      CONVERT(varchar, DecryptByPassPhrase('Fj!58;<è§a2$X ç(#2', Numero)),
      Note
  FROM dbo.CreditCard;
  GO

Infrastruttura di protezione di SQL Server 2005
Un livello più elevato di protezione può essere raggiunto affidandosi all'infrastruttura offerta nativamente da SQL Server 2005 che può gestire per nostro conto la generazione e l'archiviazione di chiavi e certificati. L'illustrazione che segue schematizza il modo in cui SQL Server ci aiuta a proteggere le informazioni sensibili.

Al livello gerarchico più elevato troviamo la Service Master Key (SMK), l'origine di tutte le chiavi e certificati in SQL Server. La SMK è una chiave di tipo simmetrico che viene creata in occasione del primo avvio del servizio e che viene criptata (con l'algoritmo 3DES) utilizzando le Data Protection API (DPAPI) del sistema operativo e l'account del servizio SQL Server.
La SMK protegge direttamente la Database Master Key (MK), anch'essa criptata con l'algoritmo 3DES. La MK non viene creata automaticamente, ma deve essere generata con gli opportuni comandi DDL in quei database dove si vuole implementare una infrastruttura di protezione basata su chiavi e certificati gestita da SQL Server.
Un certificato, una chiave simmetrica od una asimmetrica possono proteggere direttamente i dati oppure un'altra chiave di tipo simmetrico e sia un certificato che una chiave asimmetrica possono essere importate da un file. Questa funzionalità è molto utile se, ad esempio, vogliamo utilizzare un certificato rilasciato da una certification authority esterna.
Tutte le chiavi e tutti i certificati, siano essi generati da SQL Server oppure importati da file esterni, sono oggetti di SQL Server ed in quanto tali vengono memorizzati nel database in cui sono definiti. Le normali attività di backup sono quindi in grado di salvare anche le informazioni relative all'infrastruttura di criptazione dei dati.

Una chiave di tipo simmetrico utilizza, sia per la codifica che per la decodifica, la medesima chiave (da qui la definizione di simmetria) mentre una chiave di tipo asimmetrico fa uso di una coppia di chiavi (anche dette chiave pubblica e chiave privata) ognuna delle quali è in grado di decifrare i dati cifrati dall'altra, ma una stessa chiave non può cifrare e decifrare gli stessi valori. La diretta conseguenza di ciò è che una chiave asimmetrica rappresenta una protezione più forte rispetto a quella offerta da una chiave simmetrica ma, allo stesso tempo, è richiesto per il sistema un overhead maggiore a carico della CPU. Per questo motivo se ne sconsiglia l'utilizzo quando si devono cifrare una grande quantità di dati o quando questi sono oggetto di continui accessi.

Chiave simmetrica protetta da password
L'utilizzo di una chiave simmetrica è in grado di assicurare un livello di protezione più elevato rispetto a quello implementato con le funzioni T-SQL. Per questo esempio utilizzeremo una chiave di tipo simmetrico protetta da password, quindi indipendente da qualunque altro oggetto in SQL Server, che può essere creata con l'istruzione 

  CREATE SYMMETRIC KEY SymKeyWithPWD
    WITH ALGORITHM = TRIPLE_DES
    ENCRYPTION BY PASSWORD = 'ComPLeXP@ssw0rd';

Questa chiave, pur non essendo subordinata a nessuna altra chiave o certificato, è comunque archiviata nel database. Le informazioni relative a tutte le chiavi simmetriche di un database possono essere visualizzate accedendo alla vista di catalogo sys.symmetric_keys 

  SELECT * FROM sys.symmetric_keys;

Affinché possa essere utilizzata, una chiave simmetrica deve essere aperta con un apposito comando DML. Il codice per aprire la chiave ed inserire un record nella tabella è 

  OPEN SYMMETRIC KEY SymKeyWithPWD
      DECRYPTION BY PASSWORD = 'ComPLeXP@ssw0rd';
  INSERT dbo.CreditCard VALUES (
      'Daniele',
      'MasterCard',
      EncryptByKey(Key_GUID('SymKeyWithPWD'), '4321-9876-6789-1234'),
      'Cifrato con SymKeyWithPWD');

La funzione EncryptByKey() richiede come primo argomento l'identificativo della chiave utilizzata (che nell'esempio viene ricavato con la funzione Key_GUID) e come secondo argomento il campo da cifrare. La funzione complementare, vale a dire quella per eseguire la decodifica, non richiede invece alcun riferimento alla chiave utilizzata 

  SELECT Nome,
      Tipo,
      CONVERT(varchar, DecryptByKey(Numero)),
      Note
  FROM dbo.CreditCard;

L'apertura di una chiave è a livello di connessione. Ogni connessione può tenere aperte più chiavi e diverse connessioni possono utilizzare contemporaneamente la medesima chiave aprendone ciascuna una propria istanza. Possiamo in ogni momento verificare la presenza di chiavi aperte nella sessione corrente attraverso l'istruzione 

  SELECT * FROM sys.openkeys;

Il comando per chiudere la chiave aperta in precedenza è 

  CLOSE SYMMETRIC KEY SymKeyWithPWD;

oppure, se abbiamo aperto più chiavi e vogliamo chiuderle tutte insieme, possiamo farlo con il comando 

  CLOSE ALL SYMMETRIC KEYS;

Sia la cifratura eseguita con la funzione EncryptByPassPhrase() che quella eseguita utilizzando una chiave protetta da password espongono ancora i dati ad un certo margine di rischio legato al fatto che l'unica protezione è rappresentata dalla complessità della chiave di cifratura utilizzata. Sebbene tali metodi possano essere ritenuti adeguati per molti ambienti, un hacker sufficientemente motivato e che sia in qualche modo entrato in possesso dei dati (ad esempio perché dispone di un backup degli stessi), potrebbe implementare una routine in grado di eseguire un "brute force attack" e riuscire, nel giro di minuti, ore o giorni, a seconda della complessità e della lunghezza della chiave, ad individuare la password utilizzata per la cifratura. Inoltre l'implementazione di una strategia simile in una applicazione di accesso ai dati diventa esso stesso un fattore di rischio in quanto la password andrebbe incapsulata all'interno del codice (quindi nota al team di sviluppo) o, comunque, potrebbe essere carpita da altri in maniera fraudolenta nel momento in cui il legittimo utilizzatore la immette in una textbox.

Chiavi asimmetriche
Un metodo più efficace per la protezione di una chiave consiste nel proteggerla con un'altra chiave ed è possibile fondere le peculiarità di una chiave asimmetrica (elevata protezione) con quelle di una chiave simmetrica (minore overhead) creando una chiave di tipo asimmetrico che protegga una chiave di tipo simmetrico ed utilizzare quest'ultima per la cifratura dei dati. Questo è lo scenario che andremo a realizzare nel prossimo esempio ed il relativo schema di protezione è riportato nella figura che segue.

Poiché non l'abbiamo fatto in precedenza, il primo passo sarà quello di definire la Database Master Key che è possibile creare con l'istruzione 

  CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'Sc7\n>qp*X€0?@';

A questo punto possiamo creare una chiave di tipo asimmetrico (dipendente dalla DMK), ed una di tipo simmetrico protetta a sua volta dalla precedente 

  CREATE ASYMMETRIC KEY AsymKey
      WITH ALGORITHM = RSA_1024;
  CREATE SYMMETRIC KEY SymFromAsym
      WITH ALGORITHM = AES_256
      ENCRYPTION BY ASYMMETRIC KEY AsymKey;

Adesso siamo pronti per utilizzare le chiavi appena create per cifrare, con ciascuna di esse, altrettanti record nella tabella dbo.CreditCard 

  INSERT dbo.CreditCard VALUES (
      'Andrea' ,
      'Eurocard' ,
      EncryptByAsymKey(AsymKey_ID('AsymKey'), '1234-3456-5678-7890') ,
      'Cifrato con AsymKey');
  OPEN SYMMETRIC KEY SymFromAsym
      DECRYPTION BY ASYMMETRIC KEY AsymKey;
  INSERT dbo.CreditCard VALUES (
      'Lorenzo' ,
      'Amex' ,
      EncryptByKey(Key_GUID('SymFromAsym'), '9876-543210-12345') ,
      'Cifrato con SymFromAsym');

E' importante notare che per utilizzare una chiave asimmetrica, questa non deve essere aperta come è invece necessario per una chiave di tipo simmetrico.
Fintanto che la chiave simmetrica è aperta possiamo decifrare i valori inseriti ricorrendo alla funzione DecryptByKey() già utilizzata in precedenza. Per tutti i dati cifrati con chiavi asimmetriche, oppure con chiavi simmetriche chiuse, il risultato della funzione di decodifica sarà NULL. Se apriamo anche la chiave SymKeyWithPWD creata in precedenza, possiamo vedere in chiaro anche i record inseriti con quest'ultima 

  OPEN SYMMETRIC KEY SymKeyWithPWD
      DECRYPTION BY PASSWORD = 'ComPLeXP@ssw0rd';
  SELECT Nome,
      Tipo,
      CONVERT(varchar, DecryptByKey(Numero)),
      Note
  FROM dbo.CreditCard;

Negli esempi riportati sono stati cifrati i dati di una stessa tabella utilizzando due diverse chiavi simmetriche che utilizzano differenti algoritmi di cifratura; nonostante questo la funzione di decodifica è comunque in grado di decifrare entrambi i record con un unico comando a patto che le chiavi siano state aperte. Attraverso la funzione DecryptByAsymKey (e recuperando l'identificativo della chiave con la funzione AsymKey_ID), saremo in grado di decodificare i dati immessi con la chiave asimmetrica 

  SELECT Nome,
      Tipo,
      CONVERT(varchar, DecryptByAsymKey(AsymKey_ID('AsymKey'), Numero)),
      Note
  FROM dbo.CreditCard;

Certificati digitali
I certificati generati da SQL Server sono conformi allo standard X.509 ed è importante ricordare che è possibile importare in SQL Server un certificato rilasciato da una Certification Authority esterna (ad esempio un certificato emesso da Verisign).
La figura che segue mostra la rappresentazione grafica di ciò che ci prepariamo ad implementare.

Avendo già creato in precedenza la DMK, ci sarà sufficiente creare il certificato 

  CREATE CERTIFICATE FirstCert
      WITH SUBJECT = 'Test Cert SQL2K5 - LB',
      START_DATE = '20050701',
      EXPIRY_DATE = '20070630';

Per default la validità di un certificato è di un anno dalla data di emissione, ma possiamo definire una diversa validità facendo uso dei parametri start_date e expiry_date come nell'esempio riportato e le informazioni relative ai certificati sono esposte dalla vista di catalogo sys.certificates.
Inseriamo quindi un altro record nella nostra tabella cifrando il numero della carta di credito con il certificato appena creato: 

  INSERT dbo.CreditCard VALUES (
      'Ester' ,
      'Visa' ,
      EncryptByCert(Cert_ID('FirstCert'), '1111-2222-3333-4444') ,
      'Cifrato con Certificato digitale');

Come è facile intuire, la funzione per decifrare il record, complementare a quella appena utilizzata, è DecryptByCert() 

  SELECT Nome,
      Tipo,
      CONVERT(varchar, DecryptByCert(Cert_ID('FirstCert'), Numero)),
      Note
  FROM dbo.CreditCard;

Permissions
Fino a questo momento non ci siamo preoccupati di definire utenti e ruoli, come invece è buona norma fare in un ambiente reale. Tutti i comandi sono stati eseguiti con un account di tipo db_owner, ma è quanto mai opportuno, in un ambiente reale, utilizzare sempre degli utenti che abbiano i permessi minimi di cui necessitano e, in ogni caso, non eseguire mai e per nessuna ragione delle attività proprie di un utente tramite account di tipo amministrativo. Gli oggetti di database a supporto della cifratura dei dati sono a tutti gli effetti dei "securables" su cui possono essere concessi, revocati o negati dei permessi.
Facciamo quindi un ulteriore passo avanti e definiamo un utente privo di privilegi amministrativi a cui assegneremo i permessi per utilizzare una parte dell'infrastruttura realizzata. Con lo script che segue definiamo un login, lo rendiamo membro di un database role in CryptoDB, e concediamo al ruolo alcuni permessi per operare sulla tabella dbo.CreditCard 

  USE master;
  CREATE LOGIN Luca WITH PASSWORD = 'Luca';
  USE CryptoDB;
  CREATE USER Luca FROM LOGIN Luca;
  CREATE ROLE CryptoRole;
  EXEC sp_addrolemember 'CryptoRole', 'Luca';
  GRANT SELECT ON dbo.CreditCard TO CryptoRole;
  GO

Se vogliamo consentire all'utente appena creato di utilizzare la chiave simmetrica SymFromAsym dobbiamo concedere i necessari permessi non solo sulla chiave utilizzata per la cifratura ma anche agli eventuali "parent" (ad eccezione della MK il cui utilizzo è concesso, per default, al ruolo Public) 

  GRANT VIEW DEFINITION ON SYMMETRIC KEY :: SymFromAsym TO CryptoRole;
  GRANT CONTROL ON ASYMMETRIC KEY :: AsymKey TO CryptoRole;
  GO
  EXECUTE AS USER = 'Luca';
  OPEN SYMMETRIC KEY SymFromAsym
      DECRYPTION BY ASYMMETRIC KEY AsymKey;
  SELECT Nome,
      Tipo,
      CONVERT(varchar, DecryptByKey(Numero)),
      Note
  FROM dbo.CreditCard;
  REVERT
  GO

Si noti, in questa porzione di codice, l'utilizzo dell'istruzione EXECUTE AS. Si tratta di un nuovo comando (che equivale nelle funzionalità al SETUSER della versione precedente di SQL Server) utilizzabile per impersonare un account differente (e di cui dobbiamo disporre del permesso di "impersonate"); con la successiva istruzione REVERT viene restituita la propria identità al titolare della connessione.

DecryptByAuto* functions
Giunti a questo punto si è appurato che è possibile cifrare i dati di una tabella utilizzando diversi metodi e diversi algoritmi di cifratura ed abbiamo anche visto che il permesso di utilizzo di una chiave o di un certificato può essere assegnato ad un utente o ad un ruolo del database e che, quindi, diversi ruoli possono utilizzare diverse chiavi.

Si immagini ora uno scenario in cui diversi gruppi di lavoro debbano essere messi in grado di cifrare i dati di propria competenza senza che gli stessi dati possano essere acceduti in chiaro dagli altri gruppi. Fin qui l'esigenza può essere risolta creando diversi database roles, altrettante chiavi, ed assegnando i relativi permessi su ciascuna chiave al ruolo appropriato.
Qualora ci sia una figura di supervisore che deve avere la possibilità di visualizzare le informazioni cifrate da tutti i gruppi, si potrebbe attribuire a tale responsabile (o meglio al database role dei responsabili) il permesso di servirsi di tutte le chiavi e l'esigenza potrebbe dirsi risolta. Ciò renderebbe tuttavia necessario aprire un numero imprecisato di chiavi simmetriche ogni volta che un utente di questo gruppo debba accedere alle informazioni.
Fortunatamente, però, esiste una scorciatoia rappresentata dalle funzioni DecryptByKeyAutoCert () e DecryptByKeyAutoAsymKey(). Con queste funzioni possiamo decodificare con un unico comando (e senza aprire in maniera esplicita le chiavi simmetriche) tutti i dati che sono stati cifrati con tutte le chiavi simmetriche protette da un determinato certificato o da una specifica chiave asimmetrica.
Creiamo quindi una ulteriore chiave protetta dalla chiave asimmetrica AsymKey ed inseriamo un nuovo record nella tabella: 

  CREATE SYMMETRIC KEY SymFromAsym_bis
      WITH ALGORITHM = TRIPLE_DES
      ENCRYPTION BY ASYMMETRIC KEY AsymKey;
  OPEN SYMMETRIC KEY SymFromAsym_bis
      DECRYPTION BY ASYMMETRIC KEY AsymKey;
  INSERT dbo.CreditCard VALUES (
      'Luca',
      'Amex',
      EncryptByKey(Key_GUID('SymFromAsym_bis'), '0000-0000-0000-0000'),
      'Cifrato con SymFromAsym_bis');
  CLOSE ALL SYMMETRIC KEYS;
  GO

A questo punto definiamo una vista in grado di decifrare tutti i dati che sono stati criptati utilizzando una qualunque delle chiavi derivate dalla chiave asimmetrica AsymKey: 

  CREATE VIEW dbo.vw_FromAsymKey
  AS
  SELECT Nome,
      Tipo,
      CONVERT(varchar, DecryptByKeyAutoAsymKey(AsymKey_ID('AsymKey'), NULL, Numero)) AS Numero,
      Note
  FROM dbo.CreditCard;
  GO
  SELECT * FROM dbo.vw_FromAsymKey;

Accordando i necessari privilegi sulla vista soltanto al database role dei supervisori raggiungiamo lo scopo prefissato.

Recovery
La presenza di una catena di oggetti rappresenta una primitiva forma di protezione per tutti gli oggetti gerarchicamente superiori. Negli esempi che sono stati realizzati, la presenza delle chiavi SymFromAsym e SymFromAsym_bis impediscono la cancellazione della chiave AsymKey ed il tentativo di eseguire il comando DROP su un oggetto che presenta delle dipendenze produce il messaggio 

  Msg 15572, Level 16, State 1, Line 2
  The asymmetric key cannot be dropped because one or more entities are either signed or encrypted
  using it.

Si faccia attenzione che la sola presenza di dati cifrati per mezzo di una chiave (o di un certificato) non impedisce la cancellazione della stessa ed anche qualora la chiave venga ricreata con gli stessi attributi, essa non sarà in alcun modo utilizzabile per decifrare i dati criptati con la precedente. Nel caso in cui si sia rimossa per errore una chiave od un certificato utilizzato per proteggere delle informazioni, l'unica attività in grado di restituire la leggibilità dei dati cifrati è quella di ripristinare un backup del database in cui sia presente l'oggetto andato perso.

Particolare attenzione è necessaria nel caso in cui si debba ripristinare il backup di un database su un server differente oppure qualora si modifichi l'account del servizio con cui viene eseguito SQL Server.
E' stato fatto cenno al fatto che la radice di tutta l'infrastruttura di codifica dei dati è la Service Master Key e che la stessa è criptata utilizzando le DPAPI e l'account del servizio SQL Server. A sua volta la SMK protegge le MK che sono state create nei rispettivi database e che sono memorizzate, oltre che nel database stesso, anche nel database master. Spostando il database su un server differente, oppure su una istanza differente dello stesso server, viene rotto il legame tra la MK e la sua SMK.
Ciò non inibisce l'utilizzo delle chiavi e certificati dipendenti dalla MK, ma si rende necessario aprire quest'ultima (ricordiamo che la MK è una chiave simmetrica) utilizzando il comando 

  OPEN MASTER KEY DECRYPTION BY PASSWORD = 'Sc7\n>qp*X€0?@';

Per evitare l'apertura esplicita della MK ogni volta si renda necessario il suo utilizzo, occorre associare la MK con la sua nuova SMK, il che può essere fatto con l'istruzione 

  ALTER MASTER KEY
      REGENERATE
      WITH ENCRYPTION BY PASSWORD = 'Sc7\n>qp*X€0?@';

Dal momento che la SMK viene cifrata utilizzando le credenziali dell'account del servizio SQL Server, anche la modifica dello stesso implica alcune attività amministrative. A seguito di tale variazione, l'utilizzo di una chiave o di un certificato dipendente dall'infrastruttura di SQL Server produce il messaggio di errore: 

  Msg 15466, Level 16, State 1, Line 1
  An error occurred during decryption.

In questo caso è possibile intervenire in due modi.
Il primo metodo consiste nel forzare la generazione di una nuova SMK utilizzando le credenziali del precedente account: 

  ALTER SERVICE MASTER KEY
      WITH OLD_ACCOUNT = 'dominio\serviceaccount',
      OLD_PASSWORD = 'password';

ma questa soluzione non è percorribile nel caso in cui il servizio veniva eseguito nel contesto di sicurezza di un account di sistema (ad esempio LocalSystem o LocalService).
Il secondo metodo, ed anche quello da preferire, è il ripristino di una SMK da un backup della stessa. E' possibile eseguire il backup della SMK utilizzando il comando 

  BACKUP SERVICE MASTER KEY TO FILE = 'D:\SMK.dat'
      ENCRYPTION BY PASSWORD = 'K&Qni §<_2+!L4%;oJ';

In queste poche decine di byte si racchiude tutto il baluardo di sicurezza che questa nuova funzionalità di SQL Server è in grado di assicurare ed è quindi opportuno proteggere tale informazione con una password il più complessa possibile e, soprattutto, custodirla in luogo sicuro. Disponendo di una copia di backup diventa possibile forzare la rigenerazione di una SMK utilizzando l'istruzione 

  RESTORE SERVICE MASTER KEY FROM FILE = 'D:\SMK.dat'
      DECRYPTION BY PASSWORD = 'K&Qni §<_2+!L4%;oJ'
      FORCE;

La generazione di una nuova chiave a livello di servizio o a livello di database comporta implicitamente la decodifica di tutte le informazioni criptate e la successiva cifratura utilizzando la nuova chiave. Per queste ragioni è consigliabile eseguire l'attività con le dovute cautele e nei momenti di bassa attività del database server.

Conclusioni
In fase di pianificazione di una infrastruttura di criptazione è indispensabile prestare attenzione agli algoritmi di cifratura che si intende utilizzare. A seconda del sistema operativo su cui è installato SQL Server possono non essere presenti alcuni degli algoritmi supportati. Ad esempio Windows XP non supporta l'algoritmo AES_256 e qualora venga ipotizzato l'utilizzo del database su questo sistema operativo, ad esempio per l'ambiente di sviluppo, occorre tenere presente questo vincolo.

La possibilità di criptare i dati non deve essere considerata come una alternativa alla protezione basata sul controllo degli accessi ma deve essere vista come un innalzamento del muro costruito per proteggere le informazioni più critiche. Una attenta politica di gestione degli account e di controllo degli accessi rappresenta la prima e più efficace arma a protezione dei dati.
La sicurezza è un aspetto che deve essere considerato nell'ambito di una politica aziendale a 360° ed in cui gli aspetti direttamente legati al database server (controllo degli accessi e criptazione dei dati) devono essere complementari ad una politica di protezione del server a livello di sistema operativo e dell'intera infrastruttura di rete senza peraltro trascurare la protezione fisica dei server e dei supporti di backup.
L'anello più debole di tutta la catena è quello che più facilmente si presta ad essere attaccato.

L'Autore
Luca Bianchi ha ricevuto da Microsoft l'MVP award negli anni 2003, 2004 e 2005 per la sua attività su SQL Server. Lavora come Database Administrator presso la SACE SpA, è certificato MCDBA ed MCSE e presta la propria collaborazione come speaker in occasione di eventi e conferenze dedicati a SQL Server. Può essere contattato all'indirizzo luca@sql-server.it.