Comprendre Transparent Data Encryption (TDE)

Comprendre Transparent Data Encryption (TDE)
Mouhamadou Diaw, Senior Oracle Consultant, dbi services ltd.
Introduction
Les fichiers d’une base de données étant stockés localement sur le serveur tout utilisateur qui a accès
physiquement à ces fichiers peut constituer un danger potentiel si les données sont sensibles.
Bien que les fichiers soient binaires, il reste toujours possible de tirer quelques informations, ne seraitce qu’avec la commande basique strings (Listing 1)
[oracle@stand2 ~]$ strings users01_me.dbf
1umS
Rififi
37429155622
1umS
L'avventura
37429156025
1umS
Playtime
37429155820
1umS
…
Listing 1
Une solution entre autre serait tout simplement de crypter les données dans les fichiers physiques.
Cette approche peut se faire de 3 façons
•
Par l’application : utilisation par exemple de DBMS_CRYPTO
DBMS_CRYPTO est un package PL/SQL qui permet de crypter et de décrypter sélectivement des
données dans la base. Par exemple ce package peut nous permettre de crypter des numéros de
comptes bancaire ou des numéros de carte avant de les stocker sur le serveur. Evidemment ici le
développeur est responsable du schéma de cryptage.
Figure 1
•
Par le stockage : Le cryptage est fait en utilisant les fonctionnalités du stockage.
Mouhamadou Diaw, dbi services
Comprendre Transparent Data Encryption (TDE)
Figure 2
•
Par la base de données (TDE) : Utilisation des fonctionnalités Oracle Advanced Security
C’est la méthode la plus facile à mettre en œuvre, vu que tout le travail est fait par oracle et tout est
transparent pour l’utilisateur et les applications, d’où le nom TDE.
Figure 3
Dans ce qui suit, nous présenterons quelques exemples de cette dernière méthode de cryptage par
oracle.
Mouhamadou Diaw, dbi services
Comprendre Transparent Data Encryption (TDE)
Transparent Data Encryption : Niveau colonnes
TDE a été introduit à partir de la version 10g et a beaucoup été amélioré dans la version 11g.
Comme son nom l’indique, TDE permet de faire une encryption de manière transparente. C’est-à-dire
qu’une fois mise en place, oracle s’occupe de tout. Par contre il faut la licence Oracle Advanced
Security
Le principe est le suivant, une clé principale (Master Key) est créée dans le wallet. Et au niveau de la
base de données, une clé sera créée pour chaque colonne ou tablespace que l’on voudra crypter. Ces
clés seront stockées dans le dictionnaire de données et seront protégées par la clé principale.
Figure 4
TDE sur les colonnes (seule option disponible sur la 10g) se fait assez facilement.
Création du wallet pour y stocker la clé principale
Il faut d’abord créer un répertoire qui servira à stocker la clé principale. On a la possibilité de partager
les wallets déjà existants pour les autres composantes. Mais il est fortement recommandé d’utiliser un
wallet spécifique pour TDE. Pour cela il suffit juste d’ajouter dans le fichier sqlnet.ora le paramètre
ENCRYPTION_WALLET_LOCATION pointant vers le répertoire dédié (Listing 2)
[oracle@stand2 admin]$ cat sqlnet.ora
ENCRYPTION_WALLET_LOCATION=
(SOURCE=
(METHOD=FILE)
(METHOD_DATA=
(DIRECTORY=/u01/app/oracle/staff/wallet_tde)))
Listing 2
Mouhamadou Diaw, dbi services
Comprendre Transparent Data Encryption (TDE)
Création de la clé principale dans le wallet
Une fois le sqlnet.ora mis à jour, il faut créer la clé principale qui va être stockée dans le wallet
(Listing 3)
SQL> alter system set encryption key identified by "hollyw00d";
System altered.
SQL>
Listing 3
Nous pouvons vérifier que la clé principale est créée dans le répertoire wallet_tde Il faut juste noter
l’extension .pl2 qui vient tout simplement du standard PKCS#12 utilisé pour le stockage des clés
(Listing 4).
[oracle@stand2 admin]$ ls -l /u01/app/oracle/staff/wallet_tde/*
-rw-r--r--. 1 oracle oinstall 2845 Apr 29 09:38
/u01/app/oracle/staff/wallet_tde/ewallet.p12
Listing 4
Crypter les colonnes concernées
La syntaxe ALTER TABLE est utilisée pour le cryptage des colonnes. SALT qui est la valeur par défaut
ajoute des valeurs aléatoires avant d’encrypter les données, ce qui augmente l’efficacité du cryptage
(Listing 5).
SQL> alter table BONUS
modify (ENAME encrypt no salt);
Table altered.
SQL> alter table BONUS
modify (SAL encrypt salt);
Table altered.
Listing 5
Chaque colonne cryptée possède une clé de cryptage qui est stockée dans le dictionnaire de données
et cette clé de colonne est à son tour protégée par la clé principale dans le wallet (Figure 4).
On peut vérifier l’encryption en faisant un simple DESC de la table (Listing 6)
SQL> desc BONUS
Name
Null?
----------------------------------------- --------ENAME
JOB
SAL
COMM
Listing 6
Mouhamadou Diaw, dbi services
Comprendre Transparent Data Encryption (TDE)
Type
-------------------------VARCHAR2(10) ENCRYPT
VARCHAR2(9)
NUMBER ENCRYPT
NUMBER
Pour plus d’informations sur les colonnes encryptées, on peut interroger la table
USER_ENCRYPTED_COLUMNS.
Le cryptage des colonnes peut aussi se faire lors de la création de la table. Par défaut AES192 est
utilisé, mais d’autres algorithmes sont disponibles.
La question qu’on se pose souvent est la suivante : Est-ce qu’il y’a un coût si on utilise TDE ? La
réponse est clairement oui. Oracle décrypte les données quand on fait un SELECT et encrypte les
données quand on fait un UPDATE/INSERT, ce qui aura pour effet d’allonger la durée des traitements.
D’une manière générale il faut compter en moyenne 5% pour chaque colonne concernée.
Une autre problématique est aussi le stockage, eh oui une colonne encryptée occupera plus d’espace
qu’une colonne non encryptée. Par contre la seule façon de voir cette problématique d’espace utilisée
est d’aller directement sur le disque physiquement. TDE maintient la transparence au niveau de la base
de données de telle sorte que l’utilisation des fonctions telle VSIZE ne retournera aucune différence
comme le montre petite démonstration (Listing 7) et (Listing 8))
SQL> alter table EMP
modify (SAL encrypt
salt);
Table altered.
SQL>
select vsize(SAL) from emp where empno=7902;
VSIZE(SAL)
---------2
Listing 7
SQL> alter table EMP
modify (SAL decrypt
);
Table altered.
SQL>
select vsize(SAL) from emp where empno=7902;
VSIZE(SAL)
---------2
Listing 8
L’utilisation de TDE au niveau des colonnes présente quelques limitations:
•
•
•
On ne peut pas l’utiliser sur les clés étrangères
On ne peut pas utiliser l’option SALT avec les colonnes indexées
Seuls les index B-tree sont supportés
Si on est dans un de ces cas, il faut passer à l’option TDE au niveau tablespace.
Mouhamadou Diaw, dbi services
Comprendre Transparent Data Encryption (TDE)
Transparent Data Encryption : Niveau tablespaces
Cette fonctionnalité existe seulement depuis la version 11g. Les étapes sont les suivantes.
Création de la clé principale
Comme dans le cas de l’encryption des colonnes, il faut d’abord créer la clé principale. (Listing 9)
SQL> alter system set encryption key identified by "hollyw00d";
System altered.
SQL>
Listing 9
Encryption du tablespace
L’encryption d’un tablespace se lors de sa création en spécifiant le mot clé encryption (Listing 10)
SQL> create tablespace cryptta datafile '/u01/oradata/SOUGSEC/cryptta01.dbf'
size 10M encryption USING 'AES256' default storage(ENCRYPT);
Tablespace created.
Listing 10
Créons maintenant une table sur ce tablespace (Listing 11)
SQL> SQL> create table scott.salgradecrypt tablespace cryptta
from scott.salgrade ;
as select *
Table created.
Listing 11
On peut vérifier par strings que le fichier cryptta01.dbf est crypté sur le disque (Listing 12)
[oracle@stand2 SOUGSEC]$ strings cryptta01.dbf
}|{z
SOUGSEC
vLD6
CRYPT_TA
vLD6
18l]
"jND
tops
6Z;:
m;je
FJx>g
Listing 12
Redémarrons notre base et faisons maintenant un SELECT sur la table cryptée (Listing 13)
SQL> conn scott/tiger
Connected.
SQL> select * from scott.salgradecrypt;
select * from scott.salgradecrypt
*
ERROR at line 1:
ORA-28365: wallet is not open
Listing 13
Mouhamadou Diaw, dbi services
Comprendre Transparent Data Encryption (TDE)
On voit que le wallet doit être ouvert avant toute opération sur les données cryptées (Listing 14) et
(Listing 15)
SQL> alter system set encryption wallet open identified by "hollyw00d";
System altered.
Listing 14
SQL> conn scott/tiger
Connected.
SQL> select * from salgradecrypt;
GRADE
LOSAL
HISAL
---------- ---------- ---------1
700
1200
2
1201
1400
3
1401
2000
4
2001
3000
5
3001
9999
Listing 15
Gestion des clés principales
Dans ce qui précède, nous retiendrons que pour accéder aux données cryptées, le wallet doit être
ouvert. Il est possible de créer un auto login wallet avec l’utilisation des PKI. Il suffit de générer un
certificat et d’utiliser ce dernier dans la création de la clé principale (Listing 16)
SQL> alter system set encryption key <certificate id here> identified by
"hollyw00d";
Listing 16
Il faudra à chaque moment être sûr que l’on a une sauvegarde de la clé principale.
Dans certains cas, une ségrégation des tâches peut être mise en place en attribuant la gestion de la clé
principale à une autre personne différente du DBA.
Si on veut changer de mot de passe du wallet, il faudra faire comme suit
 Décrypter toutes les données cryptées
 Fermer le wallet
 Sauvegarder le wallet
 Régénérer la clé principale
Une règle d’or est de toujours garder les anciennes clés, on peut avoir besoin de restaurer par exemple
un backup RMAN encrypté avec l’ancienne clé.
Mouhamadou Diaw, dbi services
Comprendre Transparent Data Encryption (TDE)
Conclusion
Dans cet article nous avons voulu présenter les possibilités qui s’offrent à nous pour protéger nos
données au niveau du serveur. Nous avons ainsi vu qu’oracle offrait des possibilités avec TDE. Il faut
juste noter que l’option Oracle Advanced Security est requise.
Références:
 How to secure Oracle 10g and 11g by Ron B Natan CRC Press
https://www.crcpress.com/HOWTO-Secure-and-Audit-Oracle-10g-and11g/BenNatan/9781420084122
 Oracle official documentation
 Oracle-base.com
Contact :
Mouhamadou Diaw
Senior Oracle Consultant
[email protected]
Mouhamadou Diaw, dbi services
Comprendre Transparent Data Encryption (TDE)