Version imprimable
Bonjour,
J'ai une BDD qui existe depuis au moins 10 ans avec un site web attaché. Une nouvelle contrainte vient de m'etre donnée et de taille. Il faut que toutes les donnees soit cryptées. Pour les moteurs de recherche de mon site cela risque de poser probleme avec les wild card (*), les likes.... Comment gerer tout cela afin de garder un maximum de fonctionnalité vis a vis de mon site.
Avez vous deja eu ce cas la ?
Merci
C'est du grand n'importe quoi.
Encore une idée à la con tout droite sortie du chef d'un ignare qui s'improvise génie de l'informatique.
Le cryptage ne doit pas se faire au niveau de la DB.
Essayez de convaincre quelqu'un d'influent que ce n'est pas une chose à faire.
Sinon, comme vous vous en rendez compte, vous pouvez soit faire une croix sur les LIKE avec un cryptage pertinent soit continuer à faire du LIKe avec un cryptage ridicule (genre chaque lettre devient lettre + 1) XD
Ca dépend ce qu'on entend par "cryptage des données"... SQL Server propose un mécanisme appelé TDE (pour Transparent Data Encryption) qui permet de crypter la base, et donc les données.
Tu trouveras une foule d'information ici : SQL Server Encryption, et quelques scripts ici : SQL SERVER – Introduction to SQL Server Encryption and Symmetric Key Encryption Tutorial with Script.
Cependant je comprends la réaction de Sergejack, j'avais compris la même chose en lisant ton post et si effectivement l'idée c'est juste de crypter les données et de les décrypter à la volée, c'est assez débile comme idée et ça va coûter cher en resources :aie:
[EDIT] : En complément, voir ce lien : SQL Server Encryption Options où sont exposées les différentes alternatives concernant l'encryption. Cependant ce lien ne précise pas les différences de coût entre les différentes solutions donc attention à bien tester avant de faire un choix définitif...
Effectivement, le cryptage de toutes les données revient au niveau peerformance à utiliser des fichiers COBOL sur un antique IBM 370 avec 16 Ko de RAM !Citation:
Envoyé par topolino
Toutes les requêtes nécessite un scan et un décryptage colonne par colonne avent de pourvoir retrouver la moindre info.
Même les jointures ne peuvent plus se faire. En effet le cryptage de données claires identiques ne donne pas le même résultat.
Démonstration :
je dirais la même chose que Sergejack, ton chef est con !Code:
2
mais effectivement la solution est certainement le TDE qui pompe finalement très peu de ressources....
Je l'associerait en outre au cryptage en SSL de la connexion
A +
Je suis tout à fait d'accord. Crypter une colonne de mots de passe est une pratique courante et logique puisqu'on peut développer l'outil de faire le cryptage des textes en entrée afin de comparer le même type de données.
Cependant, crypter toute une base de données n'est pas logique.
Par contre, vous pourriez envisager de travailler qu'en données encryptées avec un mot de passe. Comme ceci :
Cependant, les impactes vont surement être diverses et variées.Code:
2
Un exemple d'impacte que j'envisage tout de suite : imaginez un calcul mathématique simple: des données encryptées par EncryptByPassPhrase sont stockées en format VARBINARY. Additionner des données en VARBINARY n'est pas du tout la même chose qu'additionner des données de type INTEGER.
Vous pouvez peut-être y arriver avec des cast/convert partout mais vous auriez un sacré sac à nouilles à administrer par la suite.