In merito a questo mio articolo sulla cifratura dei dati in SQL Server 2005, ho ricevuto una mail in cui un lettore mi chiede "...nel caso si debbano criptare dei campi superiori agli 8000 caratteri, la funzione di cifratura dice che i dati saranno troncati. Ha già incontrato questa necessità trovandone la soluzione?"
In primo luogo il limite è leggermente inferiore dal momento che gli 8000 byte che il Books On Line riferisce come limite devono riferirsi non al campo da cifrare ma al risultato cifrato. Ne consegue che in funzione dell'algoritmo scelto per la cifratura dei dati varia la lunghezza massima del campo da cifrare e agli 8000 byte ne vanno in realtà sottratti un centinaio.

Campi di dimensioni superiori non sono pertanto cifrabili con le funzionalità native di SQL Server 2005 e per trovare un workaround è indispensabile fare un passo indietro chiedendosi le ragioni per le quali si ha necessità di cifrare dati del genere. In passato mi è stato presentato un quesito analogo e la ragione di ciò derivava da una scarsa (o sarebbe meglio dire inesistente) politica di controllo degli accessi e si voleva, con la cifratura dei dati, ovviare a questa grave lacuna.

Per il mio punto di vista, sicuramente condiviso da chi ha deciso di implementare l'infrastruttura PKI in SQL Server 2005, la cifratura dei dati non è una alternativa alla protezione dei dati per mezzo di permessi sugli oggetti ma deve rappresentare una ulteriore protezione limitata a quei dati più sensibili per cui le business rules (e/o disposizioni di legge) impongono un occhio di riguardo. Mi riferisco ai dati di una carta di credito, coordinate bancarie, dati sanitari, credenziali di accesso ad una applicazione, ecc.

Tutti gli altri casi possono essere risolti semplicemente negando i permessi su di una tabella e far utilizzare agli utenti e alle applicazioni solo viste, stored procedure e user defined functions.

Ogni altra esigenza particolare che suggerisce la cifratura dei dati (fermo restando che ciò non deve essere un palliativo di quanto indicato in precedenza) deve essere risolta lato applicazione o utilizzando soluzioni DRM.

Colgo l'occasione per segnalare il blog di Laurentiu Cristofor che si rivela sempre una fonte inesauribile di documentazione sulla cifratura dei dati ed in particolare questo post di pochi giorni fa il cui titolo, molto esplicativo, è "Who needs encriptions?"

Bye