Discussion :

[dari68]

MERCI BCP.

@+

[ariesnojf]

Bonjour,

On cherche à mettre en oeuvre le TDE sur certaine de nos bases (protection contre les fichiers). Sur ces bases, on a des index Fulltext.

J'ai lu par ci par là, qu'il ne faut pas utiliser ce type d'index lors utilisation TDE, mais sans explication poussées.

Avez vous des explications (un peu plus poussées) concernant ce sujet.

Si on laisse ce type d'index avec TDE, quels en seraient les conséquences ? Si j'ai bien compris, les index seraient chiffrés aussi ?

Si effectivement, il ne faut pas les utiliser, quelles seraient la ou les parades pour remplacer l'index ?

Merci pour vos réponses.

[SQLpro]

On cherche à mettre en oeuvre le TDE sur certaine de nos bases (protection contre les fichiers). Sur ces bases, on a des index Fulltext.

J'ai lu par ci par là, qu'il ne faut pas utiliser ce type d'index lors utilisation TDE, mais sans explication poussées.

C'est du grand n'importe quoi ! Avez-vous des références précises ? Je ne voit pas en quoi TDE causerait le moindre problèmes aux index full-text ! [QUOTE]

A +

[elsuket]

Bonjour,

J'administre quelques bases cryptées par TDE et qui ont des index fulltext.
Nous n'avons jamais constaté de problème, et c'est en fait tout à fait normal : seules les données dans les fichiers de la base sont cryptées.

Les données qui sont dans le cache, donc en RAM, ne le sont pas. Or le moteur de base de données (ce n'est pas spécifique à SQL Server) réalise toutes ses opérations en RAM.
Ceci est simplement du au fait qu'un accès en RAM est 1000 fois plus rapide qu'un accès disque (HDD. C'est bien sûr plus petit avec des SSD).

D'ailleurs, il suffit de s'en remettre à la documentation sur le sujet :

À propos du chiffrement transparent des données

Le chiffrement du fichier de base de données est effectué au niveau de la page. Les pages d'une base de données chiffrée sont chiffrées avant d'être écrites sur le disque et déchiffrées lorsqu'elles sont lues en mémoire

@++

[ariesnojf]

Bonjour,

Merci pour vos réponses, qui j'avoue me rassure. J'ai visionné beaucoup (enfin c'est un bien grand mot) de vidéo de soi disant expert SQL via youtube, et certain d'entre eux préconisaient de ne pas utiliser ce type d'index sous peine de dégradation significative des perfs du système.

J'en profite, quel type de clé utilisez vous ? En AES (128 - 192 -ou 256) ou la 3DES. Je sais que la 3DES repose sur la DES (qui n'est plus utilisé ou du moins remplacé par l'AES).
Est ce que la 128 en AES est suffisant ?
Je suppose que cela impacte le temps de chiffrement tout cela ?

Dernière question : le certificat utilisé pour le protection de la DEK doit être sauvegardé, mais j'imagine pas au même endroit que les backups de la base ? ...

Merci encore pour vos réponses

[SQLpro]

J'en profite, quel type de clé utilisez vous ? En AES (128 - 192 -ou 256) ou la 3DES. Je sais que la 3DES repose sur la DES (qui n'est plus utilisé ou du moins remplacé par l'AES).
Est ce que la 128 en AES est suffisant ?

Pour quel usage ???

Je suppose que cela impacte le temps de chiffrement tout cela ?

Oui, mais faiblement

Dernière question : le certificat utilisé pour le protection de la DEK doit être sauvegardé, mais j'imagine pas au même endroit que les backups de la base ? ...

Surtout pas => CD ou DVD mis au coffre !

Merci encore pour vos réponses

A +

[ariesnojf]

Bonjour,

Pour quel usage ???

On met le TDE surtout pour se prémunir contre le vol de fichier (mdf/ldf) / backup.
Plus la clé est complexe, plus le chiffrement doit l'être. Mais ne connaît pas les seuils d'application de telle ou telle clé.

Noté pour la déportation sur disque externe du backup (bon cela me semblait cohérent).

Merci,

[elsuket]

Bonjour,

Nous utilisons l'AES 256, que ce soit avec des certificats ou avec un HSM.
Dans les deux cas, les bases utilisent des index fulltext

@++

[ariesnojf]

Bonjour,

Merci à vous deux, chiffrement selon AES_256 alors !

Merci encore pour votre temps !

Sujet clos pour moi (pour le moment qui sait )