Crypter des données dans une table

Bonjour,

je sais pas si le terme "Crypter" est le bon. Mais j'aimerai savoir s'il est possible de stocker dans une table des informations assez sensibles de façon à ce qu'elles n’apparaissent pas clairement par un simple select.

L'idée est qu'il ne soit possible de les lire qu'a travers un select possédant une sorte de clé de décryptage.

J'ai besoin d'une sorte de cryptage réversible mais pas facilement. Car ces données seront exploitées dans une application dont j'ai la charge de développement.

Ces données seraient aussi mise à jour.

Je suis sous Oracle 10G.

Merci à vous

Oui c'est possible ...
Maintenant du coup c'est moins simple à indexer et le modèle est difficile à concevoir.

En effet si on connait la taille du champ non crypté on ne connait pas forcément sa taille après cryptage difficile alors de tailler correctement le conteneur.

D'autre part la charge réseau va augmenter aussi.

Il y a aussi des options oracle qui permettent ces manipulations (advanced security/ db vault) mais ne protège pas contre le select simple, en effet l'utilisateur propriétaire des tables a accès à leur contenu par select. par contre l'avantage est que l'indexation reste valable.

Une autre solution serait de crypter les données directement dans la table et d'utiliser la clé de décryptage uniquement quand tu le souhaite dans ton application.

c'est à dire. il est possible d'avoir des tables avec des colonnes déjà cryptées ?

je complète ma réflexion , il s'agira d'écran spécifique englobé dans une application client / serveur utilisant le même utilisateur "Oracle".

une autre solution : les VPD et l'implémentation des policies

regarde dans la doc tout ce qui concerne le package DBMS_RLS

je crois comprendre que cela s'appuie sur le "User" Oracle.
en fonction du user on voit tel ou tel information.

est ce bien cela ?

Je suis l'auteur de l'article sur DBMS_CRYPTO d'Oracle.

Ce que celà vaut ?
- c'est du cryptage AES128 (Advanced Encryptions Standard 128 bits) couplé à une fonction de chiffrement par bloc (CHAIN_CBC) + fonction de padding (PAD_PKCS5) , autant dire que si on perd la clé de cryptage, les infos sensibles sont perdues à jamais avec.

je l'utilise pour le stockage de mots de passe (données interrogées par des Select) donc rarement mis à jour.

L'avantage, la donnée est protégée quelque soit l'utilisateur (admin, user finaux, prestataire--> dump par exp etc.)

Combien de colonnes devez vous protéger ?
quel type de données ? (financières, mot de passe, commentaires, ...)

Portabilité --> votre projet est uniquement basé sur de la bdd Oracle?

DROE

Bonjour,

Je risque fortement de devoir crypter des données de type texte ou date qui seront avant tout utilisées en lecture dans le cadre de création de liste pour du mailling.

Ces données seront certainement mise à jour mais de façon occasionnelles. La plus part du temps il s'agira d'enrichir ces données par de nouvelles entrées dans la table donc de l'insert.

Je n'ai pas encore de vision sur la volumétrie des données et le nombre de colonnes à crypter , je n'ai pas encore tous les éléments de mon cahier des charges.

Dans l'hypothèse ou je dois par exemple remonter 380 entrées sur cette table qui possède 20 de colonnes cryptée, un simple select peut prendre combien de temps ?

Sinon je n'ai pas de soucis coté portabilité je suis et reste sous Oracle en espérant que si je monte de version d'Oracle le principe reste le même.

Au passage, l'article est très bien , n'ayant pas de grosse compétance en administration Oracle , j'ai pu sans soucis mettre en place le cryptage.

Merci à vous