[ASE12.5.4] cryptage des colonnes [Résolu]

[dngaya]

Bonjour, Je viens de migrer mon dataserver 12.5.3 vers 12.5.4 afin d'implémenter le cryptage des colonnes sur certaines tables.
La MOA vient de m'envoyer les colonnes des tables à crypter. Je me rends compte que sur certaines tables, il y a plusieurs colonnes à crypter et que parfois la table à une clé primaire, par exemple:

TABLE EMPLOI


clé primaire : idemploi char(14) IDENTIFIANT EMPLOI

clé décomposée :

idRPP char(6) IDENTIFIANT RPP
date_debut char(8) DATE DE DEBUT CONVERTIE ENCARACTERES

description :

idRPP char(6) IDENTIFIANT RPP
code_emploi char(4) CODE EMPLOI
anciennete_empl float DATE FIN EMPLOI
filiere char(3) CODE FILIERE
metier char(3) CODE METIER
emploi_ind varchar(40) EMPLOI INDIVIDUALISE
corporate_title varchar(40) CORPORATE TITLE
cat_rem char(3) CODE CATEGORIE DE REMUNERATION
cat_soc_prof char(3) CODE CATEGORIE SOCIO-PROFESS



Pour cette table, toutes les colonnes sont à crypter. Ma question est de savoir s'il est necessaire de tout crypter puisqu'on pouvait le faire qu'en considerant le cryptage sur la colonne de la clé primaire et quelles sont les conséquences, du point de vue performance, en cryptant plusieurs colonnes d'une table ?

Merci de vos conseils et suggestions.

Cordialement.

[mpeppler]

Je n'ai pas beaucoup d'expérience avec l'encryption, mais j'ai quand même quelques opinions

Premièrement, chaque colonne encryptée ajoute une surcharge au niveau CPU, donc il faut à priori éviter d'encrypter des choses pour les quelles cela n'est pas nécessaire.

Ensuite, on peut encrypter des colonnes qui sont indexées, mais il y a un certain nombre de limites, comme par example que l'encryptage n'utilise pas un vecteur d'initialisation, ou un padding. En plus l'index ne peut être utilisé que pour les tests d'égalité/inégalité. Pour tout autre test l'index est inutilisable.

Donc pour moi il faut éviter d'encrypter les clés primaires, et encrypter les clés des autres indexes avec parsimonie.

Michael

[dngaya]

Merci de votre reponse, ce qui est vrai, je n'ai pas aussi beaucoup d'expérience sur le cryptage mais pouvez-vous m'eclaircir, s.v.p, pourquoi il n'est pas bon de crypter une colonne ayant une clé étrangère ?

Merci

[mpeppler]

Je pense que si une colonne participant à une jointure est cryptée de la même façon des deux côté de la jointure alors cela ne pose pas de problème particulier (puisque l'indexe peut être utilisé tel quel).

Mais il ne faut pas oublier les limitations sur l'utilisation des indexes qui est mentionnée dans la doc:

You can create an index on an encrypted column if the column’s encryption key
does not specify the use of an initialization vector or random padding. Using
an initialization vector or random padding results in identical data encrypting
to different patterns of ciphertext, which prevents the index from enforcing
uniqueness.
Indexes on encrypted data are useful for equality and nonequality matching of
data but not for data ordering, range searches, or finding minimum and
maximum values. If Adaptive Server is performing an order-dependent search
on an encrypted column, it cannot execute an indexed lookup on encrypted
data. Instead, the encrypted column in each row must be decrypted and then
searched. This slows data processing.

(je n'ai pas ce document en français, malheureusement)

Michael

[arona]

Mickael comme tu es rédacteur tu pourrais quand même traduire ... ;-) LOL
Je déconne ...
merci pour ce petit extrait.
cdlt