{"id":10334,"date":"2023-11-29T12:10:03","date_gmt":"2023-11-29T11:10:03","guid":{"rendered":"https:\/\/blog.capdata.fr\/?p=10334"},"modified":"2023-12-06T17:28:44","modified_gmt":"2023-12-06T16:28:44","slug":"le-chiffrement-et-sql-server-episode-3-always-encrypted","status":"publish","type":"post","link":"https:\/\/blog.capdata.fr\/index.php\/le-chiffrement-et-sql-server-episode-3-always-encrypted\/","title":{"rendered":"Le chiffrement et SQL Server – Episode 3 : Always Encrypted"},"content":{"rendered":"\"twitter\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>

Comme nous l’avions vu dans le premier \u00e9pisode<\/a> de cette s\u00e9rie sur le chiffrement dans SQL Server, la solution la plus rigoureuse pour le chiffrement des donn\u00e9es reste Always Encrypted. Celle-ci peut s’appliquer en compl\u00e9ment de TDE<\/a> qui lui va s’occuper de prot\u00e9ger l’int\u00e9gralit\u00e9 des donn\u00e9es et notamment ces backups. Always Encrypted, lui, travaille sur par colonne par colonne et partage les \u00e9l\u00e9ments cryptographique avec le composant applicatif qui veut lire ou \u00e9crire les donn\u00e9es, de mani\u00e8re \u00e0 que SQL Server ne voit pas les donn\u00e9es en clair (ou presque : nous parlerons des Secure Enclaves plus loin)<\/p>\n

Les objets cryptographiques derri\u00e8re Always Encrypted :<\/h1>\n

La technologie derri\u00e8re Always Encrypted repose sur des cl\u00e9s de chiffrements.<\/p>\n

La premi\u00e8re est la Column Master Key (ou CMK). C’est une cl\u00e9 RSA de 2048 bits qui sert \u00e0 chiffr\u00e9 les cl\u00e9s de chiffrement de donn\u00e9es. C’est cette cl\u00e9 que l’on devra s\u00e9curiser et que l’on doit administrer avec pr\u00e9caution. C’est aussi celle-ci que le composant applicatif devra \u00eatre capable de lire pour chiffrer et d\u00e9chiffrer les donn\u00e9es. Cette cl\u00e9 peut-\u00eatre stock\u00e9e soit dans le magasin de certificat Windows, soit le magasin certificat Java si on d\u00e9veloppe avec le driver JDBC, soit dans un Azure Key Vault. Aucun autre support de gestion de cette cl\u00e9 n’est disponible pour le moment. Si notre composant applicatif est sous Linux on peut cependant utiliser un Azure Key Vault (par exemple, avec le driver PHP : https:\/\/learn.microsoft.com\/fr-fr\/sql\/connect\/php\/using-always-encrypted-php-drivers?view=sql-server-ver16<\/a> ) ou le driver JDBC (https:\/\/learn.microsoft.com\/fr-fr\/sql\/connect\/jdbc\/using-always-encrypted-with-the-jdbc-driver?view=sql-server-ver16<\/a> ).<\/p>\n

Dans cet article, nous nous concentrerons sur l’Azure Key Vault et le magasin de certificat Windows.<\/p>\n

La deuxi\u00e8me est la Column Encryption Key (CEK). Elle sert \u00e0 chiffrer les donn\u00e9es dans la colonne de notre base. Le chiffrement des donn\u00e9es se fait par un algorithme publique et reconnu : AEAD_AES_256_CBC_HMAC_SHA_256<\/strong> , qui est document\u00e9 par l’IETF. Cela veut dire qu’\u00e0 partir que si le stockage de la cl\u00e9 est s\u00e9curis\u00e9, on peut avoir confiance en ce chiffrement. Dans le cas o\u00f9 la CMK est stock\u00e9e dans l’Azure Key Vault, Microsoft (et donc le gouvernement am\u00e9ricain, m\u00eame si la zone Azure est en France, dans le cadre du Cloud Act<\/a> ) pourrait donc d\u00e9chiffrer nos donn\u00e9es, en th\u00e9orie.<\/p>\n

La CEK va donc chiffrer les donn\u00e9es par colonne et va affecter la taille de celles-ci. Avec l’algorithme AEAD_AES_256_CBC_HMAC_SHA_256, on obtient donc le tableau des tailles suivantes par type :<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Data Type<\/strong><\/td>\nLongueur en octet<\/strong><\/td>\n<\/tr>\n
bigint<\/td>\n65<\/td>\n<\/tr>\n
binary<\/td>\nVariable se r\u00e9f\u00e9rer \u00e0 la documentation de l’algo<\/td>\n<\/tr>\n
bit<\/td>\n65<\/td>\n<\/tr>\n
char<\/td>\nVariable se r\u00e9f\u00e9rer \u00e0 la documentation de l’algo<\/td>\n<\/tr>\n
date<\/td>\n65<\/td>\n<\/tr>\n
datetime<\/td>\n65<\/td>\n<\/tr>\n
datetime2<\/td>\n65<\/td>\n<\/tr>\n
datetimeoffset<\/td>\n65<\/td>\n<\/tr>\n
decimal<\/td>\n81<\/td>\n<\/tr>\n
float<\/td>\n65<\/td>\n<\/tr>\n
geography<\/td>\nnon support\u00e9<\/td>\n<\/tr>\n
geometry<\/td>\nnon support\u00e9<\/td>\n<\/tr>\n
hierarchyid<\/td>\nnon support\u00e9<\/td>\n<\/tr>\n
image<\/td>\nnon support\u00e9<\/td>\n<\/tr>\n
int<\/td>\n65<\/td>\n<\/tr>\n
money<\/td>\n65<\/td>\n<\/tr>\n
nchar<\/td>\nVariable se r\u00e9f\u00e9rer \u00e0 la documentation de l’algo<\/td>\n<\/tr>\n
ntext<\/td>\nnon support\u00e9<\/td>\n<\/tr>\n
numeric<\/td>\n81<\/td>\n<\/tr>\n
nvarchar<\/td>\nVariable se r\u00e9f\u00e9rer \u00e0 la documentation de l’algo<\/td>\n<\/tr>\n
real<\/td>\n65<\/td>\n<\/tr>\n
smalldatetime<\/td>\n65<\/td>\n<\/tr>\n
smallint<\/td>\n65<\/td>\n<\/tr>\n
smallmoney<\/td>\n65<\/td>\n<\/tr>\n
sql_variant<\/td>\nnon support\u00e9<\/td>\n<\/tr>\n
sysname<\/td>\nnon support\u00e9<\/td>\n<\/tr>\n
text<\/td>\nnon support\u00e9<\/td>\n<\/tr>\n
time<\/td>\n65<\/td>\n<\/tr>\n
timestamp
\n(rowversion)<\/td>\n		non support\u00e9<\/td>\n<\/tr>\n
tinyint<\/td>\n65<\/td>\n<\/tr>\n
uniqueidentifier<\/td>\n81<\/td>\n<\/tr>\n
varbinary<\/td>\nVariable se r\u00e9f\u00e9rer \u00e0 la documentation de l’algo<\/td>\n<\/tr>\n
varchar<\/td>\nVariable se r\u00e9f\u00e9rer \u00e0 la documentation de l’algo<\/td>\n<\/tr>\n
xml<\/td>\nnon support\u00e9<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

On comprend donc que le chiffrement implique forc\u00e9ment de consommer plus d’espace : un integer consomme 4 octets, mais une fois chiffr\u00e9 il en consomme 65.<\/strong><\/p>\n

Dans la documentation disponible ici<\/a>, on a la formule suivante qui nous permet de d\u00e9terminer la taille en octet d’un contenu :<\/p>\n

\r\n1 + 32 + 16 + (FLOOR(DATALENGTH(cell_data)\/16) + 1) * 16  \r\n<\/pre>\n
Ainsi par exemple avec une chaine de caract\u00e8re de 76 caract\u00e8res telle que “Par exemple du texte l\u00e0 qui peut \u00eatre assez long finalement si on est bavard”, dans SQL Server je fais le calcul suivant :<\/p>\n
\"\"<\/p>\n
On a doc 129 octets pour ce varchar(76). Si c’\u00e9tait du nvarchar(76), cela prendrait 209 octets chiffr\u00e9s au lieu de 152. L’impact est donc non-n\u00e9gligeable d\u00e8s que l’on arrive sur des grosses volum\u00e9tries.<\/p>\n
 <\/p>\n
Usage et limitation :<\/h1>\n
Le chiffrement par Always Encrypted doit \u00eatre consid\u00e9r\u00e9 uniquement pour des colonnes stockant des informations tr\u00e8s sensibles. Si les informations tr\u00e8s sensibles n’ont pas \u00e9t\u00e9 tr\u00e8s bien identifi\u00e9es par le m\u00e9tier, Microsoft propose de l’outillage et de la m\u00e9thodologie afin de les identifier. cela peut se faire soit dans le Portail Azure, soit dans SSMS (https:\/\/learn.microsoft.com\/en-us\/sql\/relational-databases\/security\/sql-data-discovery-and-classification?view=sql-server-ver16&tabs=t-sql<\/a> ).<\/p>\n
Une fois les colonnes identifi\u00e9es, il faut \u00e9galement comprendre que leur chiffrement va impacteur leur usage. Dans le meilleur des cas (avec un chiffrement d\u00e9terministe), on ne pourra faire que des recherches d’\u00e9galit\u00e9 dans nos requ\u00eates ( SELECT =\u00a0 \/ IN\u00a0 \/ GROUP BY \/ DISTINCT). On ne peut pas non plus comparer les valeurs non-chiffr\u00e9es et chiffr\u00e9es directement. Il faut imp\u00e9rativement utiliser la param\u00e9trisation<\/a>.<\/p>\n
La liste des limitations \u00e9tant longue, il vaut mieux se reporter \u00e0 la documentation pour v\u00e9rifier si l’usage envisag\u00e9 est compatible :\u00a0 https:\/\/learn.microsoft.com\/en-us\/sql\/relational-databases\/security\/encryption\/always-encrypted-database-engine?view=sql-server-ver16&source=docs#limitations<\/a><\/p>\n
S\u00e9paration des r\u00f4les lors de la mise en \u0153uvre :<\/h1>\n
Le but du chiffrement Always Encrypted est d\u00e9porter les activit\u00e9s de chiffrements et de d\u00e9chiffrements au driver SQL. Cela implique donc une responsabilit\u00e9 sur la d\u00e9tention de la paire de cl\u00e9s (CEK) : qui doit les poss\u00e9der ? les mettre en oeuvre ? Microsoft r\u00e9pond \u00e0 cela en consid\u00e9rant qu’il y a deux fonctions diff\u00e9rentes :<\/p>\n
Le DBA<\/strong> qui g\u00e8re les m\u00e9tadonn\u00e9es des cl\u00e9s dans la base de donn\u00e9es : c’est \u00e0 dire qu’il va voir des informations dans certaines DMV relatives \u00e0 la gestion de ces cl\u00e9s, y compris l’emplacement de ces cl\u00e9s (magasin de certificat ou bien URL Azure Key Vault), mais il ne verra pas la CMK directement.<\/p>\n
Le “Security Administrator<\/strong>” aura pour r\u00f4le de g\u00e9n\u00e9rer la CMK et de les placer dans le magasin de certificat ou l’Azure Key Vault, mais il n’aura pas forc\u00e9ment besoin d’un acc\u00e8s direct \u00e0 la base de donn\u00e9es. Il aura aussi potentiellement \u00e0 appliquer une rotation des cl\u00e9s si cela fait partie de la strat\u00e9gie d’entreprise ou bien si une risque de vol de la CMK a eu lieu.<\/p>\n
Cette s\u00e9paration n’est pas indispensable, mais elle repr\u00e9sente l’aboutissement du besoin de cacher les donn\u00e9es \u00e0 des utilisateurs non-autoris\u00e9s, surtout si le r\u00f4le de DBA est d\u00e9l\u00e9gu\u00e9 \u00e0 un prestataire ou \u00e0 un op\u00e9rateur de cloud par exemple.<\/p>\n
Mise en oeuvre d’Always Encrypted :<\/h1>\n
Always Encrypted peut \u00eatre mis en \u0153uvre par deux outils\u00a0 :<\/p>\n