![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a><\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/03\/key_tde.png\")
<\/p>\n
<\/p>\n
Suite au premier article publi\u00e9 ce mois ci concernant “native network encryption<\/a>” , je vous propose, pour ce sujet chiffrement et s\u00e9curit\u00e9, de d\u00e9couvrir le fonctionnement de Transparent Data Encryption (TDE) pour Oracle.<\/p>\n Le sujet TDE a plusieurs fois \u00e9t\u00e9 abord\u00e9 au sein de notre blog, pour la partie PostgreSQL sur cet article<\/a>, mais \u00e9galement sur une instance de bases de donn\u00e9es SQL Server sur ce lien<\/a>.<\/p>\n Je vous invite donc \u00e0 lire, ou relire, les pr\u00e9sentations faites pour ces SGBD en question.<\/p>\n Pour le moment, int\u00e9ressons nous \u00e0 ce que propose Oracle.<\/p>\n <\/p>\n <\/p>\n Oracle TDE permet de chiffrer des donn\u00e9es sensibles dans une base de donn\u00e9es Oracle (multitenant ou pas) de fa\u00e7on la plus transparente possible pour l\u2019application. En outre, l\u2019application n\u2019a pas besoin d\u2019embarquer de strat\u00e9gie de chiffrement puisque celle-ci est int\u00e9gralement g\u00e9r\u00e9e cot\u00e9 serveur Oracle.<\/p>\n Les donn\u00e9es, dans les colonnes, sont chiffr\u00e9es une fois inscrites dans les datafiles. Il ne sera donc pas possible de les r\u00e9cup\u00e9rer (via ALTER SYSTEM DUMP DATAFILE) sans avoir la cl\u00e9. <\/p>\n Oracle TDE utilise, pour son processus, un m\u00e9canisme de cl\u00e9s (master key et cl\u00e9 de cryptage) afin de valider l\u2019ouverture du “wallet”, et du chiffrement de la donn\u00e9e.<\/p>\n \u00c0 partir d\u2019Oracle 10gr2, Oracle TDE a la possibilit\u00e9 de traiter l\u2019algorithme de chiffrement sur une colonne de table (un champs adresse ou RIB par exemple). Mais avant d’aller plus loin sur le fonctionnement de TDE, et comme nous sommes sur Oracle, il convient d’aller v\u00e9rifier, point de vu licensing, ce que nous devons choisir comme version, pour configurer cette fonctionnalit\u00e9 et \u00eatre en “r\u00e8gle” avec Oracle.<\/p>\n Cette fois ci, nous serons bien oblig\u00e9s de nous tourner vers la version Enterprise Edition Oracle, avec en plus, l’option payante “Advanced Security”.<\/p>\n <\/p>\n Extrait du site Oracle -> lien<\/a><\/p>\n 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\u00fbt” pour une version Enterprise Edition On prem.<\/p>\n <\/p>\n <\/p>\n Voici la liste des algorithmes utilis\u00e9s par Oracle pour TDE, et ce, avec une instance de bases de donn\u00e9es Oracle 19c<\/p>\n <\/p>\n Oracle TDE travaille par d\u00e9faut, avec l\u2019algorithme Advanced Encryption Standard sur 192 bits, soit AES192 si vous souhaitez chiffrer une colonne. Pour un tablespace, c’est le m\u00eame algorithme, mais en 128 bits.<\/p>\n D’autres algorithmes comme ARIA ou GOST pourront \u00eatre choisis \u00e9galement.<\/p>\n Pour le chiffrement sur colonne, Oracle TDE utilisera par d\u00e9faut SALT pour renforcer la s\u00e9curit\u00e9 des donn\u00e9es. Le proc\u00e9d\u00e9 suivant est r\u00e9alis\u00e9 ; une chaine sera ajout\u00e9e de fa\u00e7on al\u00e9atoire dans la donn\u00e9e avant d\u2019\u00eatre chiffr\u00e9e. Cela emp\u00eachera de trouver facilement la valeur d\u2019un caract\u00e8re \u00e0 partir d\u2019un motif de cryptage.<\/p>\n C’est lors de l’appel \u00e0 la clause “ENCRYPT” que vous pouvez choisir un autre algorithme pour la colonne ou le tablespace.<\/p>\n <\/p>\n <\/p>\n Oracle TDE se charge du chiffrement d\u2019une donn\u00e9e dans une colonne de table applicative en utilisant\u00a0 un fonctionnement de type ESM (External Security Module) ce qui permet de g\u00e9n\u00e9rer des cl\u00e9s de chiffrement qui servent lors des op\u00e9rations de cryptage et decryptage.<\/p>\n Ces cl\u00e9s de chiffrement sont stock\u00e9es en interne dans la base de donn\u00e9es. Une cl\u00e9 de chiffrement peut g\u00e9rer une ou plusieurs colonnes de tables applicatives.<\/p>\n Ces m\u00eames cl\u00e9s de chiffrement sont stock\u00e9es en interne dans une colonne du dictionnaire de donn\u00e9es (vues v$encryption\u2026) . On peut repr\u00e9senter le m\u00e9canisme via le graphique suivant afin de comprendre le cheminement du processus Oracle TDE :<\/p>\n <\/p>\n Dans tous les cas, il nous faut disposer d\u2019un r\u00f4le DBA<\/strong> (ou bien du r\u00f4le SYSKM<\/strong> depuis la version Oracle 12c), afin de manipuler cette \u00ab\u00a0master key<\/strong>\u00a0\u00bb. <\/p>\n <\/p>\n Pour mettre en place Oracle TDE,\u00a0 nous devons cr\u00e9er un wallet. Pour notre instance CAPDATADB<\/p>\n <\/p>\n Depuis la version Oracle 12c, il est maintenant possible de stocker le wallet (keystore) sur ASM.<\/p>\n La master key communique alors en base directement afin de pouvoir utiliser la cl\u00e9 de cryptage \/ d\u00e9cryptage. <\/p>\n <\/p>\n Afin de pouvoir cr\u00e9er et administrer un wallet, on parle maintenant de keystore en 12c, nous utilisons 2 m\u00e9thodes; Depuis la version 19c, il y a eu quelques modifications quant \u00e0 la prise en charge du wallet Oracle. Nous disposons de 2 nouvelles variables qui sont<\/p>\n – “WALLET_ROOT<\/strong>“, r\u00e9pertoire par d\u00e9faut d\u00e9di\u00e9 au wallet Oracle. Il est possible de d\u00e9finir ces variables, soit dans le SPFILE.ORA de l’instance, soit au niveau du SQLNET.ORA du ORACLE_HOME.<\/p>\n Pour notre cas d’\u00e9tude, nous choisissons de placer ces param\u00e8tres directement dans le spfile. <\/p>\n <\/p>\n <\/p>\n <\/p>\n Red\u00e9marrer l’instance pour une prise en compte imm\u00e9diate du param\u00e8tre “WALLET_ROOT<\/strong>‘.<\/p>\n Une fois la base red\u00e9marrer, configurer la variable “TDE_CONFIGURATION<\/strong>” qui nous sert \u00e0 sp\u00e9cifier le type de stockage de la cl\u00e9. <\/p>\n <\/p>\n <\/p>\n <\/p>\n V\u00e9rifier via “show parameters” que ces 2 variables sont prises en compte<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Pour la cr\u00e9ation de la \u2018master key<\/strong>\u2019, Oracle TDE\u00a0 s\u2019appuie sur le format Public Key Cryptography Standards (PKCS), soit un fichier PKCS#12 sous une extension *.p12. Le r\u00e9pertoire choisi pour le stockage de la ‘master key’<\/strong> est ainsi g\u00e9r\u00e9 automatiquement avec d’une part “WALLET_ROOT<\/strong>” et d’autre part le\u00a0 “TDE_CONFIGURATION<\/strong>“.<\/p>\n Nous pouvons le v\u00e9rifier sur cette base en interrogeant la vue “v$encryption_wallet”.<\/p>\n <\/p>\n <\/p>\n On cr\u00e9e le keystore en utilisant comme password celui de SYS par exemple<\/p>\n <\/p>\n On peut voir imm\u00e9diatement, dans le r\u00e9pertoire repr\u00e9sent\u00e9 par la variable “WALLET_ROOT<\/strong>“, un nouveau r\u00e9pertoire nomm\u00e9 “tde” .<\/p>\n <\/p>\n Dans ce r\u00e9pertoire “tde”, nous avons bien un fichier *.p12\u00a0 cr\u00e9\u00e9.<\/p>\n <\/p>\n <\/p>\n A partir de la, on peut d\u00e9clarer notre master key dans la base de donn\u00e9es. Celui-ci est pour le moment marqu\u00e9e CLOSED<\/p>\n <\/p>\n <\/p>\n Nous l’ouvrons via la commande<\/p>\n <\/p>\n <\/p>\n Le wallet est ouvert, mais notre cl\u00e9 n\u2019est toujours pas pr\u00e9sente, \u00ab\u00a0OPEN_NO_MASTER_KEY\u00a0<\/strong>\u00bb<\/p>\n <\/p>\n <\/p>\n Cette premi\u00e8re \u00e9tape est primordiale pour la mise en place de TDE dans une base de donn\u00e9es.<\/p>\n Afin d\u2019\u00e9viter d\u2019avoir \u00e0 faire cette manipulation \u00e0 chaque red\u00e9marrage de la base, nous avons le choix d’utiliser le mode AUTO LOGIN pour le keystore.<\/p>\n TDE utilisera le \u00ab\u00a0Single Sign-On<\/strong>\u00a0\u00bb afin de valider l\u2019ouverture du keystore pour cette base de donn\u00e9es. <\/p>\n <\/p>\n V\u00e9rifier la pr\u00e9sence du fichier sso dans le dossier “tde”<\/p>\n <\/p>\n <\/p>\n La master key est stock\u00e9e dans le keystore pr\u00e9alablement cr\u00e9\u00e9. <\/p>\n <\/p>\n Pour valider la creation de la master key, on contr\u00f4le les vues \u00ab v$encryption_wallet<\/strong> \u00bb et \u00ab v$encryption_keys<\/strong> \u00bb.<\/p>\n La premi\u00e8re vue indiquera le status OPEN du keystore, ainsi que le type SINGLE SIGN ON pour ce key store.<\/p>\n <\/p>\n La seconde requ\u00eate donne les infos sur la master key, son ID, son type et surtout sa date d\u2019activation. On voit ici que la master key est donc active depuis le 13 mars 2024 \u00e0 17h49:<\/p>\n <\/p>\n <\/p>\n A noter \u00e9galement que la master key est g\u00e9r\u00e9 en locale (champs ORIGIN=LOCAL), nous verrons par la suite dans quelle mesure ce champs peut avoir une autre valeur.<\/p>\n <\/p>\n <\/p>\n <\/p>\n Depuis Oracle 10gr2, nous pouvons utiliser Oracle TDE pour chiffrer une colonne (en choisissant l\u2019algo de chiffrement si besoin).<\/p>\n On cr\u00e9e une table pour tester le chiffrement. Nous utilisons l’algorithme AES256.<\/p>\n <\/p>\n <\/p>\n <\/p>\n <\/p>\n Il s’agit ensuite de v\u00e9rifier les colonnes chiffr\u00e9es avec leurs algorithmes utilis\u00e9s. Le check d\u2019int\u00e9grit\u00e9 (checksum) est effectu\u00e9 via SHA-1.<\/p>\n <\/p>\n <\/p>\n <\/p>\n Il est possible de modifier une table en ajoutant un chiffrement \u00e0 une colonne,\u00a0 ajouter une colonne chiffr\u00e9e ou m\u00eame d\u00e9chiffr\u00e9e une colonne existante. <\/p>\n <\/p>\n Depuis la version 11gr1, il est possible d\u2019utiliser TDE sur un tablespace entier. Nous utilisons toujours le m\u00eame algorihme.<\/p>\n <\/p>\n La vue “v$encrypted_tablespace” nous confirme la prise en charge de ce tablespace<\/p>\n <\/p>\n <\/p>\n Comme nous sommes sur un keystore en mode AUTO_LOGIN, un red\u00e9marrage de base ne va pas n\u00e9cessiter une saisie du password du keystore pour l’ouverture.<\/p>\n <\/p>\n <\/p>\n <\/p>\n Prenons l’exemple d’une table non chiffr\u00e9e, que nous appelons “infos_societe”, dans laquelle nous ajoutons un ligne exemple.<\/p>\n <\/p>\n <\/p>\n Ici, nous n’utilisons pas de chiffrement. Il nous est donc possible potentiellement d’aller lire la donn\u00e9e directement dans le block Oracle via un “dump”.<\/p>\n Tout d’abord, on rep\u00e8re le ROW_ID de notre ligne ins\u00e9r\u00e9e<\/p>\n <\/p>\n <\/p>\n <\/p>\n Puis on cherche le num\u00e9ro de block dans lequel notre ligne est \u00e9crite.<\/p>\n Ainsi que le FILE_ID du tablespace<\/p>\n <\/p>\n <\/p>\n <\/p>\n Il nous reste donc \u00e0 effectuer le dump du block en question<\/p>\n <\/p>\n <\/p>\n Puis v\u00e9rifier la trace g\u00e9n\u00e9r\u00e9<\/p>\n <\/p>\n <\/p>\n <\/p>\n Et si l’\u00e9dite la trace, nous avons les informations lisibles des donn\u00e9es de la ligne<\/p>\n <\/p>\n <\/p>\n Reprenons maintenant notre table avec le chiffrement activ\u00e9 \u00e0 savoir la table “infos_employes”<\/p>\n <\/p>\n <\/p>\n <\/p>\n Rappelons que les colonnes adresse et code postal sont chiffr\u00e9es.<\/p>\n <\/p>\n <\/p>\n <\/p>\n Le tablespace est le m\u00eame que la table “infos_societes”. Nous pouvons lancer le dump du block de donn\u00e9es.<\/p>\n <\/p>\n <\/p>\n <\/p>\n Et lors d’une tentative de lecture sur la trace g\u00e9n\u00e9r\u00e9e<\/p>\n <\/p>\n <\/p>\n <\/p>\n Nous r\u00e9cup\u00e9rons le nom et pr\u00e9nom , mais les informations adresse et code postal ne sont pas lisibles directement.<\/p>\n <\/p>\n <\/p>\n Oracle TDE comporte \u00e9galement certaines restrictions, ne pouvant fonctionner sous les conditions suivantes.<\/p>\n Il ne sera pas possible d\u2019utiliser le chiffrage sur une table du sch\u00e9ma SYS, ni m\u00eame chiffrer une colonne avec des type LONG ou LOB.<\/p>\n Pour les colonnes cl\u00e9s primaires ou cl\u00e9s \u00e9trang\u00e8res, il ne sera pas possible d\u2019utiliser le m\u00e9canisme SALT. L\u2019option NO SALT sera alors utiliser. Une erreur sera rencontr\u00e9e si tel est le cas<\/p>\n <\/p>\n <\/p>\n Pour chaque donn\u00e9e chiffr\u00e9e sur une colonne, il faudra prendre en compte le fait que celle-ci utilise 20 bytes de plus en raison de l\u2019utilisation du check d\u2019int\u00e9grit\u00e9 (checksum via SHA-1).<\/p>\n <\/p>\n L\u2019utilisation de Oracle TDE n’est r\u00e9serv\u00e9 qu\u2019aux index de type balanc\u00e9 (B-TREE), de plus, comme le stockage de la donn\u00e9e est chiffr\u00e9e, l\u2019index ne peut trouver de correspondance logique, en outre, il ne sera pas possible d\u2019effectuer du \u00ab range scan \u00bb dans la clause WHERE d\u2019une op\u00e9ration SQL (pas de WHERE T > 1000). Le seul moyen de faire du range scan sur un index est de chiffr\u00e9 le tablespace et que cet index y soit inclus.<\/p>\n TDE ne g\u00e8re pas non plus les tablespaces de type transportables.<\/p>\n Pour faire un export des donn\u00e9es chiffr\u00e9es , il est indispensable d\u2019utiliser DataPump en passant alors dans la commande expdp le password de la master key :<\/p>\n <\/p>\n <\/p>\n Attention \u00e9galement aux performances, les benchmarks que l\u2019on peut trouver concernant TDE indiquent en moyenne des valeurs sup\u00e9rieures de 10 \u00e0 35% en terme de consommation CPU.<\/p>\n <\/p>\n <\/p>\n Afin de pouvoir g\u00e9rer une solution de s\u00e9curit\u00e9 globale, Oracle a cr\u00e9\u00e9 une appliance nomm\u00e9e Oracle Key Vault (OKV). <\/p>\n Oracle Key vault fournit donc une plateforme de s\u00e9curit\u00e9 ou l’on peut centraliser un ensemble de strat\u00e9gies Oracle TDE au sein d\u2019une entreprise. L\u2019appliance Oracle Key Vault communique avec diff\u00e9rents composants. <\/p>\n N’h\u00e9sitez pas \u00e0 laisser un commentaire.<\/p>\n <\/p>\n \ud83d\ude42<\/p>\n Suite au premier article publi\u00e9 ce mois ci concernant “native network encryption” , je vous propose, pour ce sujet chiffrement et s\u00e9curit\u00e9, de d\u00e9couvrir le fonctionnement de Transparent Data Encryption (TDE) pour Oracle. Le sujet TDE a plusieurs… Continuer la lecture Pr\u00e9sentation<\/h2>\n
\nLes syntaxes SQL utilis\u00e9es par l\u2019application restent inchang\u00e9es puisque celles-ci sont directement envoy\u00e9es depuis l\u2019application cliente et chiffr\u00e9es sur le serveur base de donn\u00e9es locale (encryption at rest).<\/p>\n
\nC\u2019est \u00e0 partir de la version Oracle 11gr1 qu\u2019Oracle TDE peut travailler sur le chiffrement d\u2019un tablespace entier. Ceci a l\u2019avantage de traiter davantage d\u2019objets en m\u00eame temps.<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/03\/licence.png\")
<\/p>\nLes algorithmes de chiffrement<\/h3>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/03\/algo_tde.png\")
<\/p>\nLe fonctionnement<\/h2>\n
\nC\u2019est la cl\u00e9 que l\u2019on appelle \u00ab master key<\/strong> \u00bb qui permet de crypter\/decrypter la colonne du dictionnaire de donn\u00e9es afin d\u2019utiliser ces cl\u00e9s de chiffrement de donn\u00e9es aux personnes autoris\u00e9es.<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/03\/tde_process_colonne.png\")
<\/p>\n
\nCette cl\u00e9 est stock\u00e9e hors de la base de donn\u00e9es, c\u2019est un r\u00e9pertoire de l\u2019OS (ou ASM depuis la version Oracle 12c) qui portera cette cl\u00e9.
\nAfin de la s\u00e9curiser encore plus, on utilisera un wallet.<\/p>\nPr\u00e9requis \u00e0 la mise en place d\u2019un wallet (keystore)<\/h2>\n
\nCelui-ci sera cr\u00e9er par d\u00e9faut sous \u00ab $ORACLE_BASE\/admin\/$ORACLE_SID\/wallet \u00bb ou bien dans un autre r\u00e9pertoire que nous pourrons sp\u00e9cifier.<\/p>\n[oracle@ip-172-44-2-141 admin]$ ls -lrt \/opt\/app\/oracle\/admin\/CAPDATADB\/\r\ntotal 20\r\ndrwxr-x---. 2 oracle dba 4096 Jun 3 2021 scripts\r\ndrwxr-x---. 2 oracle dba 44 Jun 3 2021 xdb_wallet\r\ndrwxr-x---. 2 oracle dba 20 Jun 3 2021 dpdump\r\ndrwxr-x---. 2 oracle dba 34 Jun 3 2021 pfile\r\ndrwxr-x---. 2 oracle dba 12288 Mar 13 16:08 adump\r\ndrwxr-xr-x. 2 oracle dba 6 Mar 13 16:10 wallet<\/pre>\n
\nOn peut sch\u00e9matiser de la fa\u00e7on suivante (attention c’est un vue obsol\u00e8te depuis Oracle 19c) :<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2024\/03\/master_key.png\")
<\/p>\n
\n– soit l\u2019utilisation de l\u2019outil Oracle Wallet Manager fourni par Oracle,
\n– soit passer les commandes directement en base via les syntaxes \u00ab ADMINISTER KEY MANAGEMENT \u00bb.<\/p>\n
\nLa variable “ENCRYPTION_WALLET_LOCATION<\/strong>” n’est plus utilis\u00e9e pour d\u00e9finir l’emplacement du r\u00e9pertoire d\u00e9di\u00e9 au wallet.<\/p>\n
\n– “TDE_CONFIGURATION<\/strong>“, le type d’emplacement pour TDE. Ce param\u00e8tre s’appuie sur le param\u00e8tre “KEYSTORE_CONFIGURATION<\/strong>“.<\/p>\n
\nEn effet, cela a pour avantage de pouvoir activer TDE uniquement pour notre base, et non pas les autres bases du m\u00eame ORACLE_HOME avec l’option SQLNET.ORA.<\/p>\nSQL> ALTER SYSTEM SET WALLET_ROOT = '\/opt\/app\/oracle\/admin\/CAPDATADB\/wallet' scope=spfile;\r\n\r\nSystem altered.<\/pre>\n
\nDans notre exemple, ce sera un fichier.<\/p>\nSQL> ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE" scope=both;\r\n\r\nSystem altered.<\/pre>\n
SQL> show parameters wallet_root\r\n\r\nNAME TYPE VALUE\r\n------------------------------------ ----------- ------------------------------\r\nwallet_root string \/opt\/app\/oracle\/admin\/CAPDATADB\/wallet\r\n\r\n\r\nSQL> show parameters tde_configuration\r\n\r\nNAME TYPE VALUE\r\n------------------------------------ ----------- ------------------------------\r\ntde_configuration string KEYSTORE_CONFIGURATION=FILE<\/pre>\n
Cr\u00e9ation d\u2019un keystore<\/h3>\n
\nOn se connecte au serveur de bases de donn\u00e9es sous notre environnement Oracle 19c Enterprise Edition.<\/p>\nSQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE,WALLET_ORDER,FULLY_BACKED_UP from v$encryption_wallet;\r\n\r\nWRL_TYPE WRL_PARAMETER STATUS WALLET_TYPE WALLET_OR FULLY_BAC\r\n-------------------- -------------------------------------------------- ------------------------------ -------------------- --------- ---------\r\nFILE \/opt\/app\/oracle\/admin\/CAPDATADB\/wallet\/tde\/ NOT_AVAILABLE UNKNOWN SINGLE UNDEFINED<\/pre>\n
G\u00e9rer le keystore<\/h3>\n
SQL> ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY **********;\r\n\r\nkeystore altered.<\/pre>\n
[oracle@ip-172-44-2-141 admin]$ ls -l \/opt\/app\/oracle\/admin\/CAPDATADB\/wallet\r\ntotal 0\r\ndrwxr-x---. 2 oracle dba 25 Mar 13 17:35 tde<\/pre>\n
[oracle@ip-172-44-2-141 admin]$ ls -lrt \/opt\/app\/oracle\/admin\/CAPDATADB\/wallet\/tde\r\ntotal 4\r\n-rw-------. 1 oracle dba 2555 Mar 13 17:35 ewallet.p12<\/pre>\n
\nLa premi\u00e8re \u00e9tape consiste \u00e0 ouvrir ce nouveau keystore avant de cr\u00e9er la master key.<\/p>\nSQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;\r\n\r\nWRL_TYPE WRL_PARAMETER STATUS WALLET_TYPE\r\n-------------------- -------------------------------------------------- ------------------------------ --------------------\r\nFILE \/opt\/app\/oracle\/admin\/CAPDATADB\/wallet\/tde\/ CLOSED UNKNOWN<\/pre>\n
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY *******;\r\n\r\nkeystore altered.<\/pre>\n
SQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE from v$encryption_wallet;\r\n\r\nWRL_TYPE WRL_PARAMETER STATUS WALLET_TYPE\r\n-------------------- -------------------------------------------------- ------------------------------ --------------------\r\nFILE \/opt\/app\/oracle\/admin\/CAPDATADB\/wallet\/tde\/ OPEN_NO_MASTER_KEY PASSWORD<\/pre>\n
\nEn outre, un fichier comportant l\u2019extension .SSO sera alors cr\u00e9\u00e9 \u00e0 cet effet dans le r\u00e9pertoire<\/p>\nSQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE IDENTIFIED BY *********;\r\n\r\nkeystore altered.<\/pre>\n
[oracle@ip-172-44-2-141 admin]$ ls -lrt \/opt\/app\/oracle\/admin\/CAPDATADB\/wallet\/tde\r\ntotal 8\r\n-rw-------. 1 oracle dba 2555 Mar 13 17:35 ewallet.p12\r\n-rw-------. 1 oracle dba 2600 Mar 13 17:46 cwallet.sso<\/pre>\n
La master key<\/h3>\n
\nUne fois ouvert, le keystore peut accueillir la nouvelle ‘master key<\/strong>‘.<\/p>\nSQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY ***** WITH BACKUP;\r\n\r\nkeystore altered.<\/pre>\n
SQL> select WRL_TYPE,WRL_PARAMETER,STATUS,WALLET_TYPE,WALLET_ORDER,FULLY_BACKED_UP from v$encryption_wallet;\r\n\r\nWRL_TYPE WRL_PARAMETER STATUS WALLET_TYPE WALLET_OR FULLY_BAC\r\n-------------------- -------------------------------------------------- ------------------------------ -------------------- ---------------- ----------------\r\nFILE \/opt\/app\/oracle\/admin\/CAPDATADB\/wallet\/tde\/ OPEN PASSWORD SINGLE NO<\/pre>\n
SQL> select KEY_ID,KEYSTORE_TYPE,CREATOR_DBNAME,ACTIVATION_TIME,KEY_USE,ORIGIN from v$encryption_keys;\r\n\r\n\r\nKEY_ID KEYSTORE_TYPE\r\n------------------------------------------------------------------------------ -----------------\r\nCREATOR_DBNAME\r\n--------------------------------------------------------------------------------------------------------------------------------\r\nACTIVATION_TIME KEY_USE ORIGIN\r\n--------------------------------------------------------------------------- ---------- -----------------------------------------\r\nAVFKfh8jPk\/Rv1rHHavj4rsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA SOFTWARE KEYSTORE\r\nCAPDATADB\r\n13-MAR-24 05.49.58.737772 PM +00:00 TDE LOCAL<\/pre>\n
Cas d’utilisation de TDE<\/h2>\n
Chiffrement d’une colonne<\/h4>\n
SQL> connect manu\r\nSQL> create table infos_employes (prenom varchar2(40), nom varchar2(40),\r\n adresse varchar2(40) encrypt using 'AES256',\r\n code_postal number(6) encrypt using 'AES256'); \r\n\r\nTable created.<\/pre>\n
SQL> insert into infos_employes values ('Emmanuel','Rami','19 rue Crebillon Nantes','44000');\r\n\r\n1 row created.<\/pre>\nSQL> select * from dba_encrypted_columns;\r\n\r\nOWNER TABLE_NAME COLUMN_NAME ENCRYPTION_ALG SAL INTEGRITY_AL\r\n--------------- -------------------- -------------------- ----------------------------- --- ------------\r\nMANU INFOS_EMPLOYES ADRESSE AES 256 bits key YES SHA-1\r\nMANU INFOS_EMPLOYES CODE_POSTAL AES 256 bits key YES SHA-1<\/pre>\n
\nOn peut \u00e9galement changer l\u2019algo de chiffrement sur une colonne.<\/p>\nChiffrement d’un tablespace<\/h4>\n
SQL> create tablespace CAPDATA_TBS datafile '\/data\/oradata\/CAPDATADB\/capdata_tbs01.dbf' size 100M\r\n encryption using 'AES256'\r\n default storage (ENCRYPT);\r\n\r\nTablespace created.<\/pre>\n
SQL> select T.name,E.ENCRYPTIONALG,E.ENCRYPTEDTS,E.MASTERKEYID,E.BLOCKS_ENCRYPTED,E.BLOCKS_DECRYPTED,E.STATUS \r\n from v$tablespace t inner join v$encrypted_tablespaces e on (t.ts# = e.tS#);\r\n\r\nNAME ENCRYPT ENC MASTERKEYID BLOCKS_ENCRYPTED BLOCKS_DECRYPTED STATUS\r\n------------------------------ ------- --- -------------------------------- ---------------- ---------------- ----------\r\nCAPDATA_TBS AES256 YES 514A7E1F233E4FD1BF5AC71DABE3E2BB 126 0 NORMAL<\/pre>\n
SQL> shutdown immediate\r\nDatabase closed.\r\nDatabase dismounted.\r\nORACLE instance shut down.\r\nSQL> startup\r\nORACLE instance started.\r\n\r\nTotal System Global Area 2147481648 bytes\r\nFixed Size 8898608 bytes\r\nVariable Size 436207616 bytes\r\nDatabase Buffers 1694498816 bytes\r\nRedo Buffers 7876608 bytes\r\nDatabase mounted.\r\nDatabase opened.\r\nSQL> select * from manu.infos_employes;\r\n\r\nPRENOM NOM ADRESSE CODE_POSTAL\r\n---------------------------------------- ---------------------------------------- ---------------------------------------- -----------\r\nEmmanuel Rami 19 rue Crebillon Nantes 44000\r\n<\/pre>\n
Validation du chiffrement et tests de s\u00e9curit\u00e9<\/h3>\n
SQL> create table infos_societes (nom varchar2(40),\r\n raison varchar2(40),\r\n adresse varchar2(40),\r\n code_postal number(6) ); \r\n\r\nTable created.\r\n\r\nSQL> insert into infos_societes values ('Capdata','SA','9 rue de la porte de Buc Versailles','78000');\r\n\r\n1 row created.<\/pre>\nSQL> select rowid from manu.infos_societes where NOM='Capdata';\r\n\r\nROWID\r\n------------------\r\nAAASEqAAHAAAAF0AAA<\/pre>\n
<\/pre>\n
SQL> select DBMS_ROWID.ROWID_BLOCK_NUMBER('AAASEqAAHAAAAF0AAA') "Block number" from DUAL;\r\n\r\nBlock number\r\n------------\r\n372<\/pre>\n<\/pre>\n
SQL> select SEGMENT_NAME,SEGMENT_TYPE,TABLESPACE_NAME,EXTENT_ID,FILE_ID from dba_extents where SEGMENT_NAME='INFOS_SOCIETES';\r\n\r\nSEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID FILE_ID\r\n-------------------- ------------------ ------------------------------ ---------- ----------\r\nINFOS_SOCIETES TABLE USERS 0 7<\/pre>\n
SQL> alter system dump datafile 7 block 372;\r\n\r\nSystem altered.<\/pre>\n
[oracle@ip-172-44-2-141 trace]$ ls -rtl\r\n.....\r\n-rw-r-----. 1 oracle dba 964 Mar 14 16:56 CAPDATADB_ora_3063.trm\r\n-rw-r-----. 1 oracle dba 13073 Mar 14 16:56 CAPDATADB_ora_3063.trc<\/pre>\n
[bach][oracle@ip-172-44-2-141 trace]$ vi CAPDATADB_ora_3063.trc\r\n.......\r\nBlock dump from disk:\r\nbuffer tsn: 4 rdba: 0x01c00174 (7\/372)\r\nscn: 0x2d6b05 seq: 0x01 flg: 0x06 tail: 0x6b050601\r\nfrmt: 0x02 chkval: 0x6336 type: 0x06=trans data\r\nHex dump of block: st=0, typ_found=1\r\nDump of memory from 0x00007F5EAFC45000 to 0x00007F5EAFC47000\r\n7F5EAFC45000 0000A206 01C00174 002D6B05 06010000 [....t....k-.....]\r\n7F5EAFC45010 00006336 00000001 0001212A 002D6B04 [6c......*!...k-.]\r\n7F5EAFC45020 00008000 00320002 01C00170 001A0007 [......2.p.......]\r\n7F5EAFC45030 000003DA 010007DD 003700CA 00002001 [..........7.. ..]\r\n7F5EAFC45040 002D6B05 00000000 00000000 00000000 [.k-.............]\r\n7F5EAFC45050 00000000 00000000 00000000 00000000 [................]\r\n7F5EAFC45060 00000000 00010100 0014FFFF 1F4E1F62 [............b.N.]\r\n7F5EAFC45070 00001F4E 1F620001 00000000 00000000 [N.....b.........]\r\n7F5EAFC45080 00000000 00000000 00000000 00000000 [................]\r\nRepeat 499 times\r\n7F5EAFC46FC0 00000000 012C0000 61430704 74616470 [......,...Capdat]\r\n7F5EAFC46FD0 41530261 72203923 64206575 616C2065 [a.SA#9 rue de la]\r\n7F5EAFC46FE0 726F7020 64206574 75422065 65562063 [ porte de Buc Ve]\r\n7F5EAFC46FF0 69617372 73656C6C 5108C303 6B050601 [rsailles...Q...k]\r\nBlock header dump: 0x01c00174\r\nend_of_block_dump\r\nEnd dump data blocks tsn: 4 file#: 7 minblk 372 maxblk 372[\/bash]\r\n\r\n<\/pre>\n
SQL> select rowid from manu.infos_employes where NOM='Rami';\r\n\r\nROWID\r\n------------------\r\nAAASEcAAHAAAAFsAAA<\/pre>\n
SQL> select DBMS_ROWID.ROWID_BLOCK_NUMBER('AAASEcAAHAAAAFsAAA') "Block number" from DUAL;\r\n\r\nBlock number\r\n------------\r\n364<\/pre>\nSQL> alter system dump datafile 7 block 364;\r\n\r\nSystem altered.<\/pre>\n
[oracle@ip-172-44-2-141 trace]$ vi CAPDATADB_ora_3131.trc\r\n.....\r\nBlock dump from disk:\r\nbuffer tsn: 4 rdba: 0x01c0016c (7\/364)\r\nscn: 0x2d5c3b seq: 0x01 flg: 0x06 tail: 0x5c3b0601\r\nfrmt: 0x02 chkval: 0xc56d type: 0x06=trans data\r\nHex dump of block: st=0, typ_found=1\r\nDump of memory from 0x00007FC2BF1F4000 to 0x00007FC2BF1F6000\r\n7FC2BF1F4000 0000A206 01C0016C 002D5C3B 06010000 [....l...;\\-.....]\r\n7FC2BF1F4010 0000C56D 00000001 0001211C 002D5BD0 [m........!...[-.]\r\n7FC2BF1F4020 00008000 00320002 01C00168 00110005 [......2.h.......]\r\n7FC2BF1F4030 0000042C 0100019D 000A014D 00002002 [,.......M.... ..]\r\n7FC2BF1F4040 002D5C3B 00000000 00000000 00000000 [;\\-.............]\r\n7FC2BF1F4050 00000000 00000000 00000000 00000000 [................]\r\n7FC2BF1F4060 00000000 00020100 0016FFFF 1E6A1E80 [..............j.]\r\n7FC2BF1F4070 00001E6A 1F0D0002 00001E80 00000000 [j...............]\r\n7FC2BF1F4080 00000000 00000000 00000000 00000000 [................]\r\nRepeat 485 times\r\n7FC2BF1F5F60 8EC02273 4486D297 E07C4F05 9C90F57B [s".....D.O|.{...]\r\n7FC2BF1F5F70 04012C44 6D6D4508 65756E61 6152046C [D,...Emmanuel.Ra]\r\n7FC2BF1F5F80 8844696D 7068CF63 36DD3BAB 98AD8A29 [miD.c.hp.;.6)...]\r\n7FC2BF1F5F90 09A57855 59F7EC5E 18DDCBC6 22B4D7D7 [Ux..^..Y......."]\r\n7FC2BF1F5FA0 46B26F31 45302B6F F053AA6D 81ECCB82 [1o.Fo+0Em.S.....]\r\n7FC2BF1F5FB0 F74A0CC2 5735C61A 58C03130 C2BA128F [..J...5W01.X....]\r\n7FC2BF1F5FC0 6193530D 34C00E2B F231A006 9EB73BA2 [.S.a+..4..1..;..]\r\n7FC2BF1F5FD0 DE7291C6 2B5EBC99 02CEA21C E627E11B [..r...^+......'.]\r\n7FC2BF1F5FE0 0620CDFA 810E446B A5D64062 955C5360 [.. .kD..b@..`S\\.]\r\n7FC2BF1F5FF0 0092AA85 8215A721 844747EB 5C3B0601 [....!....GG...;\\]\r\nBlock header dump: 0x01c0016c\r\n 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\r\n31 d3 10 ba 21 19 8e a3 fe 4d 6b 0d c8 52 a9 7e a5 08 c1 b2 fd 65 a2 ce 87\r\n03 b1 b9 df 03 58 93 e3 32 2c a6 63 19 47 1e ae ff 52\r\ncol 3: [52]\r\nab d0 54 ec ca 0a 6c 64 d5 42 a9 68 ed 3e cb 53 db 11 33 0b 27 38 9b 08 39\r\n50 de 4e a5 9f 39 ea 86 02 f8 73 22 c0 8e 97 d2 86 44 05 4f 7c e0 7b f5 90\r\n9c 44\r\nend_of_block_dump\r\nEnd dump data blocks tsn: 4 file#: 7 minblk 364 maxblk 364<\/pre>\nLes restrictions<\/h2>\n
ORA-28338: cannot encrypt indexed column(s) with salt<\/span><\/pre>\n
\nSeuls les pr\u00e9dicats d\u2019\u00e9galit\u00e9 sur une valeur sont possibles (WHERE T=1).<\/p>\n$ expdp \u00ab\u00a0\u2018\/ as sysdba\u2019\u00a0\u00bb DIRECTORY=<DIR>\u00a0 ENCRYPTION_PASSWORD=*******<\/span><\/pre>\nPour aller plus loin …<\/h2>\n
\nCet outil permet de stocker et centraliser des informations relatives \u00e0 la s\u00e9curit\u00e9 d\u2019un parc informatique, celles-ci pouvant correspondre \u00e0 des wallets mais aussi des keystores java (JKS), des fichiers de type credential ou keystore JCE (java cryptography extension).<\/p>\n
\nCette appliance centralise l\u2019ensemble des wallets des serveurs d\u2019une entreprise.
\nLes informations de connexions ainsi que les requ\u00eates de cryptage\/decryptage transitent via le r\u00e9seau entre le Oracle Key Vault et les serveurs bases de donn\u00e9es.<\/p>\n
\nCeux-ci pouvant se caract\u00e9riser par\u00a0:<\/p>\n\n
<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"