Suite au premier article publié ce mois ci concernant “native network encryption” , je vous propose, pour ce sujet chiffrement et sécurité, de découvrir le fonctionnement de Transparent Data Encryption (TDE) pour Oracle.
Le sujet TDE a plusieurs fois été abordé au sein de notre blog, pour la partie PostgreSQL sur cet article, mais également sur une instance de bases de données SQL Server sur ce lien.
Je vous invite donc à lire, ou relire, les présentations faites pour ces SGBD en question.
Pour le moment, intéressons nous à ce que propose Oracle.
Présentation
Oracle TDE permet de chiffrer des données sensibles dans une base de données Oracle (multitenant ou pas) de façon la plus transparente possible pour l’application. En outre, l’application n’a pas besoin d’embarquer de stratégie de chiffrement puisque celle-ci est intégralement gérée coté serveur Oracle.
Les données, dans les colonnes, sont chiffrées une fois inscrites dans les datafiles. Il ne sera donc pas possible de les récupérer (via ALTER SYSTEM DUMP DATAFILE) sans avoir la clé.
Les syntaxes SQL utilisées par l’application restent inchangées puisque celles-ci sont directement envoyées depuis l’application cliente et chiffrées sur le serveur base de données locale (encryption at rest).
Oracle TDE utilise, pour son processus, un mécanisme de clés (master key et clé de cryptage) afin de valider l’ouverture du “wallet”, et du chiffrement de la donnée.
À partir d’Oracle 10gr2, Oracle TDE a la possibilité de traiter l’algorithme de chiffrement sur une colonne de table (un champs adresse ou RIB par exemple).
C’est à partir de la version Oracle 11gr1 qu’Oracle TDE peut travailler sur le chiffrement d’un tablespace entier. Ceci a l’avantage de traiter davantage d’objets en même temps.
Mais avant d’aller plus loin sur le fonctionnement de TDE, et comme nous sommes sur Oracle, il convient d’aller vérifier, point de vu licensing, ce que nous devons choisir comme version, pour configurer cette fonctionnalité et être en “règle” avec Oracle.
Cette fois ci, nous serons bien obligés de nous tourner vers la version Enterprise Edition Oracle, avec en plus, l’option payante “Advanced Security”.
Extrait du site Oracle -> lien
Pour une version Oracle 19c, nous choisirons donc de prendre une licence Enterprise Edition. A noter que l’option “Advanced Security” est incluse dans la version Personnal Edition On prem, alors qu’elle est en “extra coût” pour une version Enterprise Edition On prem.
Les algorithmes de chiffrement
Voici la liste des algorithmes utilisés par Oracle pour TDE, et ce, avec une instance de bases de données Oracle 19c
Oracle TDE travaille par défaut, avec l’algorithme Advanced Encryption Standard sur 192 bits, soit AES192 si vous souhaitez chiffrer une colonne. Pour un tablespace, c’est le même algorithme, mais en 128 bits.
D’autres algorithmes comme ARIA ou GOST pourront être choisis également.
Pour le chiffrement sur colonne, Oracle TDE utilisera par défaut SALT pour renforcer la sécurité des données. Le procédé suivant est réalisé ; une chaine sera ajoutée de façon aléatoire dans la donnée avant d’être chiffrée. Cela empêchera de trouver facilement la valeur d’un caractère à partir d’un motif de cryptage.
C’est lors de l’appel à la clause “ENCRYPT” que vous pouvez choisir un autre algorithme pour la colonne ou le tablespace.
Le fonctionnement
Oracle TDE se charge du chiffrement d’une donnée dans une colonne de table applicative en utilisant un fonctionnement de type ESM (External Security Module) ce qui permet de générer des clés de chiffrement qui servent lors des opérations de cryptage et decryptage.
Ces clés de chiffrement sont stockées en interne dans la base de données. Une clé de chiffrement peut gérer une ou plusieurs colonnes de tables applicatives.
Ces mêmes clés de chiffrement sont stockées en interne dans une colonne du dictionnaire de données (vues v$encryption…) .
C’est la clé que l’on appelle « master key » qui permet de crypter/decrypter la colonne du dictionnaire de données afin d’utiliser ces clés de chiffrement de données aux personnes autorisées.
On peut représenter le mécanisme via le graphique suivant afin de comprendre le cheminement du processus Oracle TDE :
Dans tous les cas, il nous faut disposer d’un rôle DBA (ou bien du rôle SYSKM depuis la version Oracle 12c), afin de manipuler cette « master key ».
Cette clé est stockée hors de la base de données, c’est un répertoire de l’OS (ou ASM depuis la version Oracle 12c) qui portera cette clé.
Afin de la sécuriser encore plus, on utilisera un wallet.
Prérequis à la mise en place d’un wallet (keystore)
Pour mettre en place Oracle TDE, nous devons créer un wallet.
Celui-ci sera créer par défaut sous « $ORACLE_BASE/admin/$ORACLE_SID/wallet » ou bien dans un autre répertoire que nous pourrons spécifier.
Pour notre instance CAPDATADB
[oracle@ip-172-44-2-141 admin]$ ls -lrt /opt/app/oracle/admin/CAPDATADB/ total 20 drwxr-x---. 2 oracle dba 4096 Jun 3 2021 scripts drwxr-x---. 2 oracle dba 44 Jun 3 2021 xdb_wallet drwxr-x---. 2 oracle dba 20 Jun 3 2021 dpdump drwxr-x---. 2 oracle dba 34 Jun 3 2021 pfile drwxr-x---. 2 oracle dba 12288 Mar 13 16:08 adump drwxr-xr-x. 2 oracle dba 6 Mar 13 16:10 wallet
Depuis la version Oracle 12c, il est maintenant possible de stocker le wallet (keystore) sur ASM.
La master key communique alors en base directement afin de pouvoir utiliser la clé de cryptage / décryptage.
On peut schématiser de la façon suivante (attention c’est un vue obsolète depuis Oracle 19c) :
Afin de pouvoir créer et administrer un wallet, on parle maintenant de keystore en 12c, nous utilisons 2 méthodes;
– soit l’utilisation de l’outil Oracle Wallet Manager fourni par Oracle,
– soit passer les commandes directement en base via les syntaxes « ADMINISTER KEY MANAGEMENT ».
Depuis la version 19c, il y a eu quelques modifications quant à la prise en charge du wallet Oracle.
La variable “ENCRYPTION_WALLET_LOCATION” n’est plus utilisée pour définir l’emplacement du répertoire dédié au wallet.
Nous disposons de 2 nouvelles variables qui sont
– “WALLET_ROOT“, répertoire par défaut dédié au wallet Oracle.
– “TDE_CONFIGURATION“, le type d’emplacement pour TDE. Ce paramètre s’appuie sur le paramètre “KEYSTORE_CONFIGURATION“.
Il est possible de définir ces variables, soit dans le SPFILE.ORA de l’instance, soit au niveau du SQLNET.ORA du ORACLE_HOME.
Pour notre cas d’étude, nous choisissons de placer ces paramètres directement dans le spfile.
En effet, cela a pour avantage de pouvoir activer TDE uniquement pour notre base, et non pas les autres bases du même ORACLE_HOME avec l’option SQLNET.ORA.
SQL> ALTER SYSTEM SET WALLET_ROOT = '/opt/app/oracle/admin/CAPDATADB/wallet' scope=spfile; System altered.
Redémarrer l’instance pour une prise en compte immédiate du paramètre “WALLET_ROOT‘.
Une fois la base redémarrer, configurer la variable “TDE_CONFIGURATION” qui nous sert à spécifier le type de stockage de la clé.
Dans notre exemple, ce sera un fichier.
SQL> ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE" scope=both; System altered.
Vérifier via “show parameters” que ces 2 variables sont prises en compte
SQL> show parameters wallet_root NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ wallet_root string /opt/app/oracle/admin/CAPDATADB/wallet SQL> show parameters tde_configuration NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ tde_configuration string KEYSTORE_CONFIGURATION=FILE
Création d’un keystore
Pour la création de la ‘master key’, Oracle TDE s’appuie sur le format Public Key Cryptography Standards (PKCS), soit un fichier PKCS#12 sous une extension *.p12.
On se connecte au serveur de bases de données sous notre environnement Oracle 19c Enterprise Edition.
Le répertoire choisi pour le stockage de la ‘master key’ est ainsi géré automatiquement avec d’une part “WALLET_ROOT” et d’autre part le “TDE_CONFIGURATION“.
Nous pouvons le vérifier sur cette base en interrogeant la vue “v$encryption_wallet”.
SQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE,WALLET_ORDER,FULLY_BACKED_UP from v$encryption_wallet; WRL_TYPE WRL_PARAMETER STATUS WALLET_TYPE WALLET_OR FULLY_BAC -------------------- -------------------------------------------------- ------------------------------ -------------------- --------- --------- FILE /opt/app/oracle/admin/CAPDATADB/wallet/tde/ NOT_AVAILABLE UNKNOWN SINGLE UNDEFINED
Gérer le keystore
On crée le keystore en utilisant comme password celui de SYS par exemple
SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY **********; keystore altered.
On peut voir immédiatement, dans le répertoire représenté par la variable “WALLET_ROOT“, un nouveau répertoire nommé “tde” .
[oracle@ip-172-44-2-141 admin]$ ls -l /opt/app/oracle/admin/CAPDATADB/wallet total 0 drwxr-x---. 2 oracle dba 25 Mar 13 17:35 tde
Dans ce répertoire “tde”, nous avons bien un fichier *.p12 créé.
[oracle@ip-172-44-2-141 admin]$ ls -lrt /opt/app/oracle/admin/CAPDATADB/wallet/tde total 4 -rw-------. 1 oracle dba 2555 Mar 13 17:35 ewallet.p12
A partir de la, on peut déclarer notre master key dans la base de données.
La première étape consiste à ouvrir ce nouveau keystore avant de créer la master key.
Celui-ci est pour le moment marquée CLOSED
SQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet; WRL_TYPE WRL_PARAMETER STATUS WALLET_TYPE -------------------- -------------------------------------------------- ------------------------------ -------------------- FILE /opt/app/oracle/admin/CAPDATADB/wallet/tde/ CLOSED UNKNOWN
Nous l’ouvrons via la commande
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY *******; keystore altered.
Le wallet est ouvert, mais notre clé n’est toujours pas présente, « OPEN_NO_MASTER_KEY »
SQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet; WRL_TYPE WRL_PARAMETER STATUS WALLET_TYPE -------------------- -------------------------------------------------- ------------------------------ -------------------- FILE /opt/app/oracle/admin/CAPDATADB/wallet/tde/ OPEN_NO_MASTER_KEY PASSWORD
Cette première étape est primordiale pour la mise en place de TDE dans une base de données.
Afin d’éviter d’avoir à faire cette manipulation à chaque redémarrage de la base, nous avons le choix d’utiliser le mode AUTO LOGIN pour le keystore.
TDE utilisera le « Single Sign-On » afin de valider l’ouverture du keystore pour cette base de données.
En outre, un fichier comportant l’extension .SSO sera alors créé à cet effet dans le répertoire
SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE IDENTIFIED BY *********; keystore altered.
Vérifier la présence du fichier sso dans le dossier “tde”
[oracle@ip-172-44-2-141 admin]$ ls -lrt /opt/app/oracle/admin/CAPDATADB/wallet/tde total 8 -rw-------. 1 oracle dba 2555 Mar 13 17:35 ewallet.p12 -rw-------. 1 oracle dba 2600 Mar 13 17:46 cwallet.sso
La master key
La master key est stockée dans le keystore préalablement créé.
Une fois ouvert, le keystore peut accueillir la nouvelle ‘master key‘.
SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY ***** WITH BACKUP; keystore altered.
Pour valider la creation de la master key, on contrôle les vues « v$encryption_wallet » et « v$encryption_keys ».
La première vue indiquera le status OPEN du keystore, ainsi que le type SINGLE SIGN ON pour ce key store.
SQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE,WALLET_ORDER,FULLY_BACKED_UP from v$encryption_wallet; WRL_TYPE WRL_PARAMETER STATUS WALLET_TYPE WALLET_OR FULLY_BAC -------------------- -------------------------------------------------- ------------------------------ -------------------- ---------------- ---------------- FILE /opt/app/oracle/admin/CAPDATADB/wallet/tde/ OPEN PASSWORD SINGLE NO
La seconde requête donne les infos sur la master key, son ID, son type et surtout sa date d’activation. On voit ici que la master key est donc active depuis le 13 mars 2024 à 17h49:
SQL> select KEY_ID,KEYSTORE_TYPE,CREATOR_DBNAME,ACTIVATION_TIME,KEY_USE,ORIGIN from v$encryption_keys; KEY_ID KEYSTORE_TYPE ------------------------------------------------------------------------------ ----------------- CREATOR_DBNAME -------------------------------------------------------------------------------------------------------------------------------- ACTIVATION_TIME KEY_USE ORIGIN --------------------------------------------------------------------------- ---------- ----------------------------------------- AVFKfh8jPk/Rv1rHHavj4rsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA SOFTWARE KEYSTORE CAPDATADB 13-MAR-24 05.49.58.737772 PM +00:00 TDE LOCAL
A noter également que la master key est géré en locale (champs ORIGIN=LOCAL), nous verrons par la suite dans quelle mesure ce champs peut avoir une autre valeur.
Cas d’utilisation de TDE
Chiffrement d’une colonne
Depuis Oracle 10gr2, nous pouvons utiliser Oracle TDE pour chiffrer une colonne (en choisissant l’algo de chiffrement si besoin).
On crée une table pour tester le chiffrement. Nous utilisons l’algorithme AES256.
SQL> connect manu SQL> create table infos_employes (prenom varchar2(40), nom varchar2(40), adresse varchar2(40) encrypt using 'AES256', code_postal number(6) encrypt using 'AES256'); Table created.
SQL> insert into infos_employes values ('Emmanuel','Rami','19 rue Crebillon Nantes','44000');
1 row created.
Il s’agit ensuite de vérifier les colonnes chiffrées avec leurs algorithmes utilisés. Le check d’intégrité (checksum) est effectué via SHA-1.
SQL> select * from dba_encrypted_columns; OWNER TABLE_NAME COLUMN_NAME ENCRYPTION_ALG SAL INTEGRITY_AL --------------- -------------------- -------------------- ----------------------------- --- ------------ MANU INFOS_EMPLOYES ADRESSE AES 256 bits key YES SHA-1 MANU INFOS_EMPLOYES CODE_POSTAL AES 256 bits key YES SHA-1
Il est possible de modifier une table en ajoutant un chiffrement à une colonne, ajouter une colonne chiffrée ou même déchiffrée une colonne existante.
On peut également changer l’algo de chiffrement sur une colonne.
Chiffrement d’un tablespace
Depuis la version 11gr1, il est possible d’utiliser TDE sur un tablespace entier. Nous utilisons toujours le même algorihme.
SQL> create tablespace CAPDATA_TBS datafile '/data/oradata/CAPDATADB/capdata_tbs01.dbf' size 100M encryption using 'AES256' default storage (ENCRYPT); Tablespace created.
La vue “v$encrypted_tablespace” nous confirme la prise en charge de ce tablespace
SQL> select T.name,E.ENCRYPTIONALG,E.ENCRYPTEDTS,E.MASTERKEYID,E.BLOCKS_ENCRYPTED,E.BLOCKS_DECRYPTED,E.STATUS
from v$tablespace t inner join v$encrypted_tablespaces e on (t.ts# = e.tS#);
NAME ENCRYPT ENC MASTERKEYID BLOCKS_ENCRYPTED BLOCKS_DECRYPTED STATUS
------------------------------ ------- --- -------------------------------- ---------------- ---------------- ----------
CAPDATA_TBS AES256 YES 514A7E1F233E4FD1BF5AC71DABE3E2BB 126 0 NORMAL
Comme nous sommes sur un keystore en mode AUTO_LOGIN, un redémarrage de base ne va pas nécessiter une saisie du password du keystore pour l’ouverture.
SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup ORACLE instance started. Total System Global Area 2147481648 bytes Fixed Size 8898608 bytes Variable Size 436207616 bytes Database Buffers 1694498816 bytes Redo Buffers 7876608 bytes Database mounted. Database opened. SQL> select * from manu.infos_employes; PRENOM NOM ADRESSE CODE_POSTAL ---------------------------------------- ---------------------------------------- ---------------------------------------- ----------- Emmanuel Rami 19 rue Crebillon Nantes 44000
Validation du chiffrement et tests de sécurité
Prenons l’exemple d’une table non chiffrée, que nous appelons “infos_societe”, dans laquelle nous ajoutons un ligne exemple.
SQL> create table infos_societes (nom varchar2(40),
raison varchar2(40),
adresse varchar2(40),
code_postal number(6) );
Table created.
SQL> insert into infos_societes values ('Capdata','SA','9 rue de la porte de Buc Versailles','78000');
1 row created.
Ici, nous n’utilisons pas de chiffrement. Il nous est donc possible potentiellement d’aller lire la donnée directement dans le block Oracle via un “dump”.
Tout d’abord, on repère le ROW_ID de notre ligne insérée
SQL> select rowid from manu.infos_societes where NOM='Capdata'; ROWID ------------------ AAASEqAAHAAAAF0AAA
Puis on cherche le numéro de block dans lequel notre ligne est écrite.
SQL> select DBMS_ROWID.ROWID_BLOCK_NUMBER('AAASEqAAHAAAAF0AAA') "Block number" from DUAL;
Block number
------------
372Ainsi que le FILE_ID du tablespace
SQL> select SEGMENT_NAME,SEGMENT_TYPE,TABLESPACE_NAME,EXTENT_ID,FILE_ID from dba_extents where SEGMENT_NAME='INFOS_SOCIETES'; SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID FILE_ID -------------------- ------------------ ------------------------------ ---------- ---------- INFOS_SOCIETES TABLE USERS 0 7
Il nous reste donc à effectuer le dump du block en question
SQL> alter system dump datafile 7 block 372; System altered.
Puis vérifier la trace généré
[oracle@ip-172-44-2-141 trace]$ ls -rtl ..... -rw-r-----. 1 oracle dba 964 Mar 14 16:56 CAPDATADB_ora_3063.trm -rw-r-----. 1 oracle dba 13073 Mar 14 16:56 CAPDATADB_ora_3063.trc
Et si l’édite la trace, nous avons les informations lisibles des données de la ligne
[bach][oracle@ip-172-44-2-141 trace]$ vi CAPDATADB_ora_3063.trc ....... Block dump from disk: buffer tsn: 4 rdba: 0x01c00174 (7/372) scn: 0x2d6b05 seq: 0x01 flg: 0x06 tail: 0x6b050601 frmt: 0x02 chkval: 0x6336 type: 0x06=trans data Hex dump of block: st=0, typ_found=1 Dump of memory from 0x00007F5EAFC45000 to 0x00007F5EAFC47000 7F5EAFC45000 0000A206 01C00174 002D6B05 06010000 [....t....k-.....] 7F5EAFC45010 00006336 00000001 0001212A 002D6B04 [6c......*!...k-.] 7F5EAFC45020 00008000 00320002 01C00170 001A0007 [......2.p.......] 7F5EAFC45030 000003DA 010007DD 003700CA 00002001 [..........7.. ..] 7F5EAFC45040 002D6B05 00000000 00000000 00000000 [.k-.............] 7F5EAFC45050 00000000 00000000 00000000 00000000 [................] 7F5EAFC45060 00000000 00010100 0014FFFF 1F4E1F62 [............b.N.] 7F5EAFC45070 00001F4E 1F620001 00000000 00000000 [N.....b.........] 7F5EAFC45080 00000000 00000000 00000000 00000000 [................] Repeat 499 times 7F5EAFC46FC0 00000000 012C0000 61430704 74616470 [......,...Capdat] 7F5EAFC46FD0 41530261 72203923 64206575 616C2065 [a.SA#9 rue de la] 7F5EAFC46FE0 726F7020 64206574 75422065 65562063 [ porte de Buc Ve] 7F5EAFC46FF0 69617372 73656C6C 5108C303 6B050601 [rsailles...Q...k] Block header dump: 0x01c00174 end_of_block_dump End dump data blocks tsn: 4 file#: 7 minblk 372 maxblk 372[/bash]
Reprenons maintenant notre table avec le chiffrement activé à savoir la table “infos_employes”
SQL> select rowid from manu.infos_employes where NOM='Rami'; ROWID ------------------ AAASEcAAHAAAAFsAAA
Rappelons que les colonnes adresse et code postal sont chiffrées.
SQL> select DBMS_ROWID.ROWID_BLOCK_NUMBER('AAASEcAAHAAAAFsAAA') "Block number" from DUAL;
Block number
------------
364
Le tablespace est le même que la table “infos_societes”. Nous pouvons lancer le dump du block de données.
SQL> alter system dump datafile 7 block 364; System altered.
Et lors d’une tentative de lecture sur la trace générée
[oracle@ip-172-44-2-141 trace]$ vi CAPDATADB_ora_3131.trc
.....
Block dump from disk:
buffer tsn: 4 rdba: 0x01c0016c (7/364)
scn: 0x2d5c3b seq: 0x01 flg: 0x06 tail: 0x5c3b0601
frmt: 0x02 chkval: 0xc56d type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00007FC2BF1F4000 to 0x00007FC2BF1F6000
7FC2BF1F4000 0000A206 01C0016C 002D5C3B 06010000 [....l...;\-.....]
7FC2BF1F4010 0000C56D 00000001 0001211C 002D5BD0 [m........!...[-.]
7FC2BF1F4020 00008000 00320002 01C00168 00110005 [......2.h.......]
7FC2BF1F4030 0000042C 0100019D 000A014D 00002002 [,.......M.... ..]
7FC2BF1F4040 002D5C3B 00000000 00000000 00000000 [;\-.............]
7FC2BF1F4050 00000000 00000000 00000000 00000000 [................]
7FC2BF1F4060 00000000 00020100 0016FFFF 1E6A1E80 [..............j.]
7FC2BF1F4070 00001E6A 1F0D0002 00001E80 00000000 [j...............]
7FC2BF1F4080 00000000 00000000 00000000 00000000 [................]
Repeat 485 times
7FC2BF1F5F60 8EC02273 4486D297 E07C4F05 9C90F57B [s".....D.O|.{...]
7FC2BF1F5F70 04012C44 6D6D4508 65756E61 6152046C [D,...Emmanuel.Ra]
7FC2BF1F5F80 8844696D 7068CF63 36DD3BAB 98AD8A29 [miD.c.hp.;.6)...]
7FC2BF1F5F90 09A57855 59F7EC5E 18DDCBC6 22B4D7D7 [Ux..^..Y......."]
7FC2BF1F5FA0 46B26F31 45302B6F F053AA6D 81ECCB82 [1o.Fo+0Em.S.....]
7FC2BF1F5FB0 F74A0CC2 5735C61A 58C03130 C2BA128F [..J...5W01.X....]
7FC2BF1F5FC0 6193530D 34C00E2B F231A006 9EB73BA2 [.S.a+..4..1..;..]
7FC2BF1F5FD0 DE7291C6 2B5EBC99 02CEA21C E627E11B [..r...^+......'.]
7FC2BF1F5FE0 0620CDFA 810E446B A5D64062 955C5360 [.. .kD..b@..`S\.]
7FC2BF1F5FF0 0092AA85 8215A721 844747EB 5C3B0601 [....!....GG...;\]
Block header dump: 0x01c0016c
50 67 87 7b f4 69 c8 de e0 a1 49 ad 7e 2e f6 c6 78 e9 56 09 10 ef 78 bd a0
31 d3 10 ba 21 19 8e a3 fe 4d 6b 0d c8 52 a9 7e a5 08 c1 b2 fd 65 a2 ce 87
03 b1 b9 df 03 58 93 e3 32 2c a6 63 19 47 1e ae ff 52
col 3: [52]
ab d0 54 ec ca 0a 6c 64 d5 42 a9 68 ed 3e cb 53 db 11 33 0b 27 38 9b 08 39
50 de 4e a5 9f 39 ea 86 02 f8 73 22 c0 8e 97 d2 86 44 05 4f 7c e0 7b f5 90
9c 44
end_of_block_dump
End dump data blocks tsn: 4 file#: 7 minblk 364 maxblk 364
Nous récupérons le nom et prénom , mais les informations adresse et code postal ne sont pas lisibles directement.
Les restrictions
Oracle TDE comporte également certaines restrictions, ne pouvant fonctionner sous les conditions suivantes.
Il ne sera pas possible d’utiliser le chiffrage sur une table du schéma SYS, ni même chiffrer une colonne avec des type LONG ou LOB.
Pour les colonnes clés primaires ou clés étrangères, il ne sera pas possible d’utiliser le mécanisme SALT. L’option NO SALT sera alors utiliser. Une erreur sera rencontrée si tel est le cas
ORA-28338: cannot encrypt indexed column(s) with salt
Pour chaque donnée chiffrée sur une colonne, il faudra prendre en compte le fait que celle-ci utilise 20 bytes de plus en raison de l’utilisation du check d’intégrité (checksum via SHA-1).
L’utilisation de Oracle TDE n’est réservé qu’aux index de type balancé (B-TREE), de plus, comme le stockage de la donnée est chiffrée, l’index ne peut trouver de correspondance logique, en outre, il ne sera pas possible d’effectuer du « range scan » dans la clause WHERE d’une opération SQL (pas de WHERE T > 1000).
Seuls les prédicats d’égalité sur une valeur sont possibles (WHERE T=1).
Le seul moyen de faire du range scan sur un index est de chiffré le tablespace et que cet index y soit inclus.
TDE ne gère pas non plus les tablespaces de type transportables.
Pour faire un export des données chiffrées , il est indispensable d’utiliser DataPump en passant alors dans la commande expdp le password de la master key :
$ expdp « ‘/ as sysdba’ » DIRECTORY=<DIR> ENCRYPTION_PASSWORD=*******
Attention également aux performances, les benchmarks que l’on peut trouver concernant TDE indiquent en moyenne des valeurs supérieures de 10 à 35% en terme de consommation CPU.
Pour aller plus loin …
Afin de pouvoir gérer une solution de sécurité globale, Oracle a créé une appliance nommée Oracle Key Vault (OKV).
Cet outil permet de stocker et centraliser des informations relatives à la sécurité d’un parc informatique, celles-ci pouvant correspondre à des wallets mais aussi des keystores java (JKS), des fichiers de type credential ou keystore JCE (java cryptography extension).
Oracle Key vault fournit donc une plateforme de sécurité ou l’on peut centraliser un ensemble de stratégies Oracle TDE au sein d’une entreprise.
Cette appliance centralise l’ensemble des wallets des serveurs d’une entreprise.
Les informations de connexions ainsi que les requêtes de cryptage/decryptage transitent via le réseau entre le Oracle Key Vault et les serveurs bases de données.
L’appliance Oracle Key Vault communique avec différents composants.
Ceux-ci pouvant se caractériser par :
- Des composants Oracle TDE (colonnes ou tablespaces cryptée)
- Des keystores files , ou JCEKS
- La management console, qui servira à l’administration de OKV
- Une appliance backup pour les besoins de sauvegarde de OKV
- Les wallets de connexion et Java keystores
N’hésitez pas à laisser un commentaire.
🙂
Continuez votre lecture sur le blog :
- Le chiffrement Oracle : native network encryption (Emmanuel RAMI) [Oracle]
- Oracle 19c : Les partitions hybrides (Emmanuel RAMI) [Oracle]
- Le chiffrement et SQL Server – Episode 1 : Transparent Data Encryption (TDE) vs Always Encrypted (Capdata team) [SQL Server]
- Le chiffrement et SQL Server – Episode 2 : Mise en oeuvre de TDE (Capdata team) [SQL Server]
- Oracle Text pour DBA Oracle : Partie 1 (Capdata team) [Oracle]