But:

Oracle Transparent Data Encryption permet de chiffrer et déchiffrer à la volée les données en base. Les données sont chiffrées au niveau des datafiles. Seuls les utilisateurs authentifiés en base ont accès aux données en clair. Principe:

Le chiffrage repose sur l'utilisation d'un portefeuille (wallet) de mot(s) de passe. Contrairement à l'utilisation de packages comme DBMS_CRYPTO, cette solution de cryptage est transparente pour l'utilisateur authentifié, et ne nécessite donc pas de modification du code client, ce qui constitue un avantage financier non négligeable. Il est possible de chiffrer des colonnes spécifiques d'une table, ou bien des tablespaces entiers.

Mise en place:

Création du wallet:

Le wallet est positionné par défaut dans le répertoire $ORA_ADM/$SID/wallet.

Il suffit alors de créer le répertoire:

mkdir $ORA_ADM/$SID/wallet

Il est également possible de spécifier le lieu de stockage du wallet dans le fichier sqlnet.ora, de la façon suivante:

ENCRYPTION_WALLET_LOCATION =
(SOURCE=
(METHOD=file)
(METHOD_DATA=
(DIRECTORY=/u01/app/oracle/MON_REPERTOIRE_A_WALLETS)))

Il faut ensuite créer le mot de passe de chiffrage:

ALTER SYSTEM SET ENCRYPTION KEY AUTHENTICATED BY "M0n#m0T$dE_Pa55E";

Puis ouvrir le wallet sur chacune des instances de la base:

ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "M0n#m0T$dE_Pa55E";

/! L'ouverture du wallet doit se faire à chaque redémarrage de la base, ainsi que sur l'ensemble des instances d'un RAC.

Cas particulier du wallet sur un RAC:

Le wallet doit être préférentiellement stocké sur un filesystem partagé comme ACFS (ce qui est notre cas). De plus, il faut initialiser les paramètres système et BDD ORACLE_UNQNAME.

ex:

export ORACLE_UNQNAME=MONINST
srvctl setenv database -d MONINST -T "ORACLE_UNQNAME=MONINST"

De même, il faut indiquer le lieu de stockage du wallet en utilisant la variable $ORACLE_UNQNAME dans sqlnet.ora du user oracle, puis redémarrer le listener (avec le user grid).

ENCRYPTION_WALLET_LOCATION =
(SOURCE=
(METHOD=file)
(METHOD_DATA=
(DIRECTORY=/u01/app/oracle/acfsmounts/orabase1/admin/$ORACLE_UNQNAME/wallet/)))

Sinon, le wallet ne peut être ouvert que sur une seule instance à la fois.

Vérification:

select * from gv$encryption_wallet;
INST_ID WRL_TYPE             WRL_PARAMETER                                                          STATUS
---------- -------------------- ---------------------------------------------------------------------- ------------------
1 file                 /u01/app/oracle/acfsmounts/orabase1/admin/$ORACLE_UNQNAME/wallet/      OPEN
2 file                 /u01/app/oracle/acfsmounts/orabase1/admin/$ORACLE_UNQNAME/wallet/      OPEN

Les deux wallets doivent être en état "OPEN"

Chiffrage d'un tablespace:

Le chiffrage d'un tablespace se fait à la création de celui-ci. Il n'est (pour l'instant?) pas possible de chiffrer un tablespace existant.

create tablespace ts_encrypted datafile size 10M autoextend on next 10M encryption using 'AES256' default storage(ENCRYPT);

Il suffit alors de déplacer les données vers ce nouveau tablespace chiffré. L'avantage d'un tablespace chiffré par rapoort au chiffrage de colonnes d'une table est essentiellement dans l'absence de limitations sur l'utilisation des eindexes dans le cas de l'opérateur LIKE, et dans le chiffrage simple des blobs. Le désavantage essentiel est l'impossibilité de l'effectuer en ligne.

Chiffrage d'une colonne d'une table:

On peut chiffrer les colonnes d'une table à l'aide d'une simple commande ALTER TABLE.

ex:

alter table SCOTT.EMPLOYEE modify (ID RAW(32) ENCRYPT);

Dans le cas où la colonne est indexée, il faut désactiver l'option SALT:

ex:

alter table SCOTT.EMPLOYEE modify (DATE_EMBAUCHE DATE ENCRYPT NO SALT);

L'encodage par défaut est AES192 sous Oracle 11gR2.

A noter que les tables ne contenant aucune colonne cryptée seront toujours accessibles, même si le wallet n'est pas ouvert.
Une table contenant une seule colonne chiffrée sera totalement inaccessible si le wallet n'est pas ouvert.

Retour arrière:

Le retour arrière se fait toujours à l'aide d'une simple commande ALTER TABLE.

ex:

alter table SCOTT.EMPLOYEE modify (DATE_EMBAUCHE DECRYPT);

Chiffrage des colonnes LOB d'une table:

Il faut chiffrer les lobsegments en utilisant l'option de stockage SECUREFILE lors de la création du LOB.

Il est possible de chiffrer une colonne LOB en ligne en utilisant le package DBMS_REDIFINITION.

Chiffrage des backups Datapump:

Il est possible d'exporter les données sous forme non chiffrée, avec les options standard de DataPump L'alerte suivante est alors levée dans les logs de l'export:

ORA-39173: Des données cryptées ont été stockées décryptées dans un ensemble de fichiers de vidage.

Dans ce cas, il est toujours possible de lire des données en clair dans le fichier de dump, à l'aide de l'utilitaire strings par exemple.

Afin d'exporter des données chiffrées, il faut ajouter l'option encryption_password à la commande DataPump

ex:

expdp TOTO/TATA directory=EXP_DIR schemas=TITI encryption_password=M0n#m0T$dE_Pa55E dumpfile=dump_titi.dmp logfile=dump_titi.log

De même, il faut spécifier le mot de passe de chiffrage lors de l'import.

ex:

impdp TOTO/TATA directory=EXP_DIR encryption_password=M0n#m0T$dE_Pa55E dumpfile=dump_titi.dmp logfile=impdp_titi.log

Références:

http://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_securing_data.htm#CHDCGGBH
http://www.oracle.com/technetwork/database/focus-areas/security/twp-transparent-data-encryption-bes-130696.pdf
http://docs.oracle.com/cd/B28359_01/network.111/b28530/asotrans.htm
http://docs.oracle.com/cd/B19306_01/network.102/b14268/asotrans.htm
http://docs.oracle.com/cd/B28359_01/appdev.111/b28393/adlob_smart.htm#BABDIEGE
http://oracleflash.com/26/Oracle-10g-Transparent-Data-Encryption-examples.html