Discussion :

[Arnard]

Bonjour,

mon boss demande que la DB de notre nouveau projet soit chiffré. Je suis sceptique sur ce type de mise en œuvre, mais soit. Notre base devrait entre autre posséder des données personnelles (Nom-Prénom, Adresse, ptete numéro carte d'identité/passeport, photo)

Je pense qu'un accès à SQL Server avec les droits nécessaires est suffisant, mais sinon, quelles sont les recommandations/bonnes pratiques ?

Merci

[SQLpro]

Vous pouvez utiliser le chiffrement TDE de la base qui permet de crypter le support de stockage : fichiers de données, journal de transactions, base tempdb, sauvegardes...
Vous pouvez aussi chiffrer les colonnes que vous voulez, mais dans ce cas les recherches directes ne seront plus supportées et les performances vont chuter dramatiquement... En général on ne chiffre que certaines données très critiques, comme les n° de carte bancaire....

A +

[Arnard]

Merci pour le retour
TDE est compatible avec une réplication par journal et/ou réplication par trigger ?

[SQLpro]

Merci pour le retour
TDE est compatible avec une réplication par journal et/ou réplication par trigger ?

TDE n'a aucune influence sur les fonctionnalités de SQL Server qu'elles quelles soient.
Seul le stockage est chiffré au juste avant d'écrire sur le disque et juste après avoir lu le disque.

La seule incidence, est que si vous faites des sauvegardes, mieux vaut ne pas les compresser sinon, elle seront plus grandes et plus longues.

A +

[StringBuilder]

J'ai plusieurs questions concernant le chiffrement, car notamment la RGPD (mais aussi ISO-27001) parlent de sécurisation du stockage des données (avec sous-entendu "tout mettre en œuvre dans la mesure du possible") et donc le cryptage des données personnelle semble être plus ou moins obligatoire.

1/ Toutes les éditions de SQL Server proposent-elles l'encryption des bases, ou est-ce réservé à l'édition Entreprise ou Standard ?
2/ Si je met en place "du jour au lendemain" cette encryption, puis-je m'attendre à des effets de bord indésirables (mise à par la taille des sauvegardes / compression) ? Notamment si je n'ai pas écrit le programme qui accède à la base, il m'est impossible d'adapter ce dernier le cas échéant.
3/ Les données sont cryptées (MDF et LDF). Qu'en est-il des sauvegardes ? Le cryptage est-il spécifique à la machine ou un mot de passe (compte Windows ? compte SQL Server ?) : en gros, si mon instance crash, puisque remonter les MDF et LDF sur une autre instance qui n'est pas sur la même machine ni le même domaine ?
4/ Quel impact sur les performances ? Taille des bases ? Charge CPU ?
5/ Enfin, j'ai l'impression qu'un fichier MDF n'est pas lisible, de toute façon (si j'insère une ligne en VARCHAR "TOTO" dans une table, que je passe la base offline, je ne retrouve pas "TOTO" dans le fichier). Donc quelle est la réelle utilité de crypter mise à part si j'ai un espion Russe aux fesses qui tente de récupérer les codes d'accès de La Maison Blanche ? On parle ici en effet de données personnelles ayant une valeur toute relative, donc aucun risque d'intrusion de la part d'une personne particulièrement bien équipée.

[Arnard]

Merci pour le retour @SQLPro

@StringBuilder, concernant TDE c'est la version Entreprise, voir le tableau ici : https://docs.microsoft.com/en-us/sql...ql-server-2016 (cherchez "crypt" pour passer en revue les différentes features relatives). Sinon oui je prévois de stocker les codes d'accès de la Maison Blanche et du kremlin

[Invité]

5/ Enfin, j'ai l'impression qu'un fichier MDF n'est pas lisible, de toute façon (si j'insère une ligne en VARCHAR "TOTO" dans une table, que je passe la base offline, je ne retrouve pas "TOTO" dans le fichier). Donc quelle est la réelle utilité de crypter mise à part si j'ai un espion Russe aux fesses qui tente de récupérer les codes d'accès de La Maison Blanche ? On parle ici en effet de données personnelles ayant une valeur toute relative, donc aucun risque d'intrusion de la part d'une personne particulièrement bien équipée.

Donne moi un fichier mdf non crypté et je vais te remonter la bd sans problème avec accès à tous ce qui est dedans...

[SQLpro]

Vous devez distinguer le chiffrement des données, c'est à dire que les données initiales sont transformées en binaire non compréhensible, et le chiffrement du support de stockage (les fichiers).

1/ Toutes les éditions de SQL Server proposent-elles l'encryption des bases, ou est-ce réservé à l'édition Entreprise ou Standard ?

Le chiffrement des données est supporté dans toutes les éditions. Le chiffrement du stockage (support) n'est supporté que dans la version Enterprise.

2/ Si je met en place "du jour au lendemain" cette encryption, puis-je m'attendre à des effets de bord indésirables (mise à par la taille des sauvegardes / compression) ? Notamment si je n'ai pas écrit le programme qui accède à la base, il m'est impossible d'adapter ce dernier le cas échéant.

La mise en place du chiffrement des données modifie les données. Vous devez donc déchiffrer avant d'exploiter de quelque manière que ce soit les données. Ce qui suppose de récrire la majorité des requêtes applicatives.

3/ Les données sont cryptées (MDF et LDF). Qu'en est-il des sauvegardes ? Le cryptage est-il spécifique à la machine ou un mot de passe (compte Windows ? compte SQL Server ?) : en gros, si mon instance crash, puisque remonter les MDF et LDF sur une autre instance qui n'est pas sur la même machine ni le même domaine ?

Si vous chiffrez les données, les zones des données chiffrées figurant dans les fichiers sont cryptées. Pour TDE, les fichiers étant intégralement cryptés, les sauvegardes le sauront du fait qu'une sauvegarde copie les pages et les transactions, donc que des données chiffrées.
Le chiffrement peut être assuré par deux mécanismes différents :
1) par SQL Server qui est sa propre autorité de certification et permet de générer des clefs et les conserve de manière interne (les clefs ne peuvent être sauvegardées pour des raisons de sécurité...)
2) par le biais d'un HSM (Hardware Security Module) c'est à dire un boitier électronique inviolable générant et stockant les clefs. On indique alors à SQL Server un EKM (External Key Manager) qui se substitue à la génération native des clefs. Avantage, c'est encore plus sécurisé... Seul inconvénient c'est extrêmement cher... Comptez environ 30 000 € et il en faut au moins 3
https://www.thalesesecurity.com/prod...shield-connect

4/ Quel impact sur les performances ? Taille des bases ? Charge CPU ?

Pour TDE : une surcharge de CPU à peine visible. Pour le chiffrement des données, des performances potentiellement catastrophique que l'on peut améliorer par le biais d'ajout d'information particulières tels que du hachage (ce qui signifie qu'il faut modifier encore l'applicatif).

5/ Enfin, j'ai l'impression qu'un fichier MDF n'est pas lisible, de toute façon (si j'insère une ligne en VARCHAR "TOTO" dans une table, que je passe la base offline, je ne retrouve pas "TOTO" dans le fichier). Donc quelle est la réelle utilité de crypter mise à part si j'ai un espion Russe aux fesses qui tente de récupérer les codes d'accès de La Maison Blanche ? On parle ici en effet de données personnelles ayant une valeur toute relative, donc aucun risque d'intrusion de la part d'une personne particulièrement bien équipée.

Non, les fichiers MDF sont parfaitement lisible, mais c'est par ce que vous n'en connaissez pas l'organisation que vous n'arrivez pas a en retrouver les morceaux qui vous intéressent...
De plus on peut rattacher un MDF sans le reste et récupérer l'intégralité des données qui y sont stockées...

A +