![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>Le chiffrement sous SQL Server n’est pas nouveau et il existe sous plusieurs formes, selon les versions. Les deux principales impl\u00e9mentations sont TDE (Transparent Data Encryption, qui est un chiffrement “at rest”) et Always Encrypted (chiffrement par colonne).<\/p>\n
La premi\u00e8re impl\u00e9mentation du chiffrement est arriv\u00e9 en 2008 est TDE. C’est une solution assez simple \u00e0 mettre en oeuvre et qui a le m\u00e9rite de proposer un \u00e9l\u00e9ment de r\u00e9ponse aux consid\u00e9rations RGPD.<\/p>\n
Always Encrypted est une solution plus complexe \u00e0 d\u00e9ployer qui n\u00e9cessitera une \u00e9valuation des donn\u00e9es \u00e0 risque, table par table, colonne par colonne. L’architecture applicative devra \u00e9galement \u00eatre consid\u00e9r\u00e9e.<\/p>\n
TDE est apparu avec SQL Server 2008 et uniquement en \u00e9dition Enterprise, ce qui \u00e9tait un frein \u00e0 son d\u00e9ploiement pour beaucoup d’entreprise. Depuis SQL Server 2019, cette fonctionnalit\u00e9 est disponible d\u00e8s l’\u00e9dition Standard. Dans Azure avec SQL Database, tous les niveaux de service propose le chiffrement TDE et il est m\u00eame activ\u00e9 par d\u00e9faut.<\/p>\n
L’id\u00e9e avec TDE est d’appliquer un chiffrement, base de donn\u00e9es par base de donn\u00e9es, sur les fichiers de donn\u00e9es et de log transactionnel. Si un backup de la base est r\u00e9alis\u00e9, celui-ci ne sera qu’une retranscription des fichiers de la base de donn\u00e9es et donc sera \u00e9galement chiffr\u00e9.<\/p>\n
Le chiffrement est bas\u00e9 soit sur un certificat ou une paire de cl\u00e9s asym\u00e9triques g\u00e9n\u00e9r\u00e9 par SQL Server, soit par le module EKM. Dans les deux cas, une attention tr\u00e8s importante devra \u00eatre apport\u00e9e \u00e0 la s\u00e9curisation des cl\u00e9s de chiffrements. En effet, imaginons la destruction du serveur SQL pour une raison quelconque. Si on veut restaurer une sauvegarde d’une base de donn\u00e9es sur un autre serveur, il faudra poss\u00e9der la cl\u00e9 de chiffrement et la d\u00e9ployer sur ce nouveau serveur. En l’absence de cette cl\u00e9, l’utilisation du backup sera impossible.<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/10\/TDE-254x300.png\")
<\/p>\n
<\/p>\n
Par ailleurs, dans le cas d’une configuration en mirroring ou en AlwaysOn, il faudra copier la cl\u00e9 de chiffrement sur tous les r\u00e9plicas afin que SQL Server puisse manipuler les donn\u00e9es chiffr\u00e9es.<\/p>\n
En cons\u00e9quence, on comprend bien que TDE a pour objectif de prot\u00e9ger les donn\u00e9e contre un vol des fichiers de SQL Server : .mdf, .ndf, .ldf et les backups de ces bases de donn\u00e9es.<\/p>\n
L’acc\u00e8s dans le moteur de SQL Server \u00e9tant “transparent” comme son nom l’indique, si l’attaque se fait \u00e0 travers l’applicatif ou le moteur de SQL Server (parce qu’un compte sur le serveur ou dans le r\u00e9seau a des privil\u00e8ges suffisants de connexion \u00e0 la base), cela n’apportera pas de s\u00e9curit\u00e9 suppl\u00e9mentaire.<\/p>\n
En contrepartie de cette fonctionnalit\u00e9, SQL Server va consommer un peu plus de ressource CPU<\/strong> pour manipuler ces donn\u00e9es. Si vous comptez d\u00e9ployer TDE sur un serveur qui connait d\u00e9j\u00e0 une forte charge CPU : attention, donc !<\/p>\n Avant SQL Server 2016, la compression des backups est \u00e9galement probl\u00e9matique.<\/strong> En effet, la compression apporte un caract\u00e8re al\u00e9atoire aux donn\u00e9es dans les pages et donc diminue les r\u00e9p\u00e9titions de valeurs qui permettent \u00e0 la compression d’apporter du gain. Ainsi donc, la compression des backups n’apportera quasiment aucun gain d’espace disque tout en consommant des cycles de CPU. Pour peu que vous ayez pris l’habitude de sauvegarder votre backup \u00e0 un endroit avec un espace assez limit\u00e9, l’activation de TDE va saturer ce volume et faire \u00e9chouer vos backups.<\/p>\n A partir de SQL Server 2016, si on ajoute l’option MAXTRANSFERSIZE = 65536 (ou sup\u00e9rieur) \u00e0 la commande de backup, l’algorithme de backup et chiffrement sera diff\u00e9rent, permettant de gagner de l’espace disque.<\/p>\n A partir de SQL Server 2019 CU5, il n’y a plus besoin d’ajouter le param\u00e8tre MAXTRANSFERSIZE, du moment qu’il y a l’option COMPRESS d’activ\u00e9, cela mettra la valeur \u00e0 128K et permettra automatiquement de gagner l’espace li\u00e9 \u00e0 la compression.<\/p>\n <\/p>\n L’activation de TDE est relativement souple : elle va se faire en fond de t\u00e2che avec une consommation mod\u00e9r\u00e9e de ressources, surtout depuis SQL 2016 o\u00f9 ce travail est d\u00e9volu au processeur par un acc\u00e9l\u00e9rateur d\u00e9di\u00e9 (Intel AES-NI). Mais si votre serveur est d\u00e9j\u00e0 assez charg\u00e9 niveau CPU, peut-\u00eatre que cela peut valoir le coup de cr\u00e9er une base de test avec une copie d’une table et lancez le TDE uniquement sur cette base pour en voir l’impact.<\/p>\n Enfin, pensez bien \u00e0 sauvegarder votre certificat TDE ou votre cl\u00e9 asym\u00e9trique de d\u00e9chiffrement et mettez la \u00e0 un voir deux endroits s\u00e9curis\u00e9s. Peut-\u00eatre une cl\u00e9 USB dans une coffre-fort ? Un NAS avec une solution de chiffrement tierce ? Dans tous les cas, il faut bien comprendre que si vous perdez cette cl\u00e9 et que vous rencontrez un probl\u00e8me sur votre serveur chiffr\u00e9 par TDE , vos donn\u00e9es sont en grave p\u00e9ril.<\/p>\n <\/p>\n La solution Always Encrypted est plus r\u00e9cente que TDE et est arriv\u00e9 avec SQL Server 2016. Il n’est pas n\u00e9cessaire d’\u00eatre en \u00e9dition Enterprise : c’est accessible d\u00e8s l’\u00e9dition Standard.<\/p>\n Contrairement \u00e0 TDE qui va chiffrer l’int\u00e9gralit\u00e9 de la base de donn\u00e9es, Always Encrypted est une option qui s’active colonne par colonne, table par table. Le chiffrement\/d\u00e9chiffrement n’est pas non plus “interne” au serveur SQL, mais g\u00e9r\u00e9 par l’application. Le but est de proposer que l’administrateur de l’infrastructure (l’administrateur syst\u00e8me ou de base de donn\u00e9es) ne soit pas en mesure de voir ces donn\u00e9es. Seul l’applicatif sera capable de d\u00e9chiffrer les donn\u00e9es.<\/p>\n En effet : la philosophie de cette technologie est vraiment dans son nom “Always Encrypted” : toujours chiffr\u00e9.<\/p>\n <\/p>\n <\/p>\n Dans ce sch\u00e9ma, on voit TDE entre la base et le stockage & backup : cela ne veut pas dire qu’AlwaysOn n\u00e9cessite TDE. Mais l’addition de ces deux technologies permet un chiffrement exhaustif.<\/p>\n On voit \u00e9galement que le chiffrement se fait entre la base de donn\u00e9es et l’appli. Cela veut dire qu’il faut penser au driver SQL qui sera utilis\u00e9 pour se connecter \u00e0 la base. Si \u00e0 sa sortie Always Encrypted exigeait un driver ADO .Net , on peut d\u00e9sormais avoir recours \u00e0 plus d’options. On peut ainsi utiliser Always Encrypted avec des drivers pour :<\/p>\n Les pages de documentations pour l’utilisation de ces drivers dans le cadre Always Encrypted est disponible \u00e0 partir d’ici : https:\/\/learn.microsoft.com\/en-us\/sql\/relational-databases\/security\/encryption\/always-encrypted-client-development?view=sql-server-ver16 <\/a><\/p>\n Always Encrypted va n\u00e9cessiter la g\u00e9n\u00e9ration de deux type de cl\u00e9s : les Column Encryption Keys (qui vont servir \u00e0 chiffrer les donn\u00e9es des colonnes) et les Column Master Keys (qui prot\u00e8ge les Column Encryption Keys). Comme avec TDE on peut utiliser le magasin de certificat de Windows, Azure Key Vault, ou bien un HSM pour les stocker. Cependant, le but est de sortir cette Column Master Key du serveur SQL pour bien s\u00e9parer les r\u00f4les : SQL Server stock de la donn\u00e9e chiffr\u00e9e, et le driver compatible Always Encrypted se charge de chiffrer\/d\u00e9chiffrer les donn\u00e9es.<\/p>\n Une Column Encryption Key peut chiffrer une ou plusieurs colonnes. Une base de donn\u00e9es peut g\u00e9rer plusieurs Column Encryptions Keys pour g\u00e9rer des cas m\u00e9tiers avec diff\u00e9rents profils d’utilisateurs par exemple. L’algorithme utilis\u00e9 est un AES-256.<\/p>\n Il y aura donc deux t\u00e2ches qui devront \u00eatre consid\u00e9r\u00e9 sp\u00e9cifiquement : le provisionnements des cl\u00e9s dans un key store appropri\u00e9 (avec le Magasin de Certificats Windows ou Azure Key Vault dans la plupart des cas), et la rotation des cl\u00e9s (parce qu’elles ont \u00e9t\u00e9 compromises ou bien parce que le certificat est arriv\u00e9 \u00e0 expiration apr\u00e8s une certaine date). On peut r\u00e9aliser ces t\u00e2ches avec SSMS ou en PowerShell.<\/p>\n La bonne pratique est de g\u00e9n\u00e9rer ces cl\u00e9s sur une autre machine, comme par exemple le serveur d’application qui a de toute fa\u00e7on vocation \u00e0 les avoir pour chiffrer\/d\u00e9chiffrer les donn\u00e9es.<\/p>\n SQL Server lui ne poss\u00e9dera que les m\u00e9ta-donn\u00e9es de ces cl\u00e9s, qui lui serviront \u00e0 identifier les colonnes comme recevant ce chiffrement.<\/p>\n Une fois les cl\u00e9s g\u00e9n\u00e9r\u00e9es, on peut proc\u00e9der au chiffrement des colonnes. Cependant, il y a un choix \u00e0 faire : le chiffrement peut-\u00eatre d\u00e9terministe ou bien al\u00e9atoire.<\/p>\n Un chiffrement d\u00e9terministe renvoie la m\u00eame valeur chiffr\u00e9e pour la m\u00eame donn\u00e9e en entr\u00e9e. Cela peut permettre de deviner certaines informations, mais cela permet aussi de r\u00e9aliser des op\u00e9rations comme une recherche d’\u00e9galit\u00e9 ( “ma_colonne = ma valeur” et donc jointures), des agr\u00e9gats et des indexations.<\/p>\n Un chiffrement al\u00e9atoire ne renvoie pas les m\u00eames valeurs pour des donn\u00e9es identiques en entr\u00e9es. C’est plus s\u00e9curis\u00e9 mais toutes ces op\u00e9rations deviennent impossibles.<\/p>\n Quand cette d\u00e9claration est faite dans le mod\u00e8le de donn\u00e9es, et pour peu que l’on est acc\u00e8s \u00e0 la Column Master Key ainsi que bien s\u00fbr un acc\u00e8s \u00e0 la base, on peut lire et \u00e9crire des donn\u00e9es chiffr\u00e9es. Il faut \u00e9galement sp\u00e9cifier dans la chaine de connexion qu’Always Encrypted est activ\u00e9 (en ADO. Net : Column Encryption Setting=enabled<\/em> , en JDBC : encrypt=true<\/em> …).<\/p>\n Il existe quelques limitations \u00e0 l’usage d’Always Encrypted. On notera parmi celles-ci les suivantes :<\/p>\n <\/p>\n Nous reviendrons prochainement sur la mise en oeuvre technique de TDE et d’Always Encrypted ! Et n’h\u00e9sitez pas \u00e0 poser vos questions dans les commentaires.<\/p>\n Le chiffrement sous SQL Server n’est pas nouveau et il existe sous plusieurs formes, selon les versions. Les deux principales impl\u00e9mentations sont TDE (Transparent Data Encryption, qui est un chiffrement “at rest”) et Always Encrypted (chiffrement par colonne). La premi\u00e8re… Continuer la lecture SQL Server Always Encrypted – le chiffrement de bout en bout, par colonne :<\/h1>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/09\/always-encrypted-300x105.jpg\")
<\/p>\n\n
\n
\n\n
\n <\/td>\n Always Encrypted<\/td>\n TDE<\/td>\n<\/tr>\n \n Version<\/td>\n A partir de 2016 + Azure SQL Database<\/td>\n A partir de 2008 + Azure SQL Database<\/td>\n<\/tr>\n \n Edition<\/td>\n Standard<\/td>\n Enterprise avant 2019<\/td>\n<\/tr>\n \n Chiffrement des donn\u00e9es “at rest”<\/td>\n Oui<\/td>\n Oui<\/td>\n<\/tr>\n \n Chiffrement des donn\u00e9es en utilisation<\/td>\n Oui<\/td>\n Non<\/td>\n<\/tr>\n \n Donn\u00e9es visibles par le DBA ?<\/td>\n Non<\/td>\n Oui<\/td>\n<\/tr>\n \n Donn\u00e9es chiffr\u00e9es par<\/td>\n C\u00f4t\u00e9 client (driver de l’applicatif)<\/td>\n SQL Server<\/td>\n<\/tr>\n \n Fonctionne niveau :<\/td>\n Colonne<\/td>\n Base de donn\u00e9es<\/td>\n<\/tr>\n \n Impact applicatif<\/td>\n Oui (limitations sur colonne chiffr\u00e9e)<\/td>\n Non<\/td>\n<\/tr>\n \n Prot\u00e8ge les cl\u00e9s de chiffrement<\/td>\n Oui<\/td>\n Non<\/td>\n<\/tr>\n \n N\u00e9cessite un driver adapt\u00e9<\/td>\n Oui<\/td>\n Non<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n <\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"