TDE (Part III) : Les clefs du chiffrages

Détails

Catégorie : Sécurité

Publié le samedi 8 février 2014 21:44

Écrit par Administrator

Affichages : 8434

Dans l’article TDE (Part I) nous avions vu qu’il fallait créer une clef nommée master key (MK). Que cette clef se stockait dans un portefeuille (wallet) protégé par un mot de passe, voir un badge en plus du mot de passe si il y a un HSM. Mais à quoi sert cette master key ? A chiffrer-déchiffrer ? Et si on veut changer le chiffrage il faut régénérer une clef ? Elle peut servir aussi pour chiffrer les backups ? Et si je perds le porte-clefs je fais quoi ?

C’est ce que nous allons voir dans cet article.

KEYS

Master Key

La master key (MK) ou clef principale est utilisée pour chiffrer les autres clefs.

Tablespace Key

La MK  permet de chiffrer-déchiffrer les clefs de chiffrement des tablespaces. Chaque tablespace a sa propre clef de chiffrement (TBSK : tablespace key). Chaque TBSK est stocké dans le(s) controlfile(s).

La requête ci-dessous permet de visualiser les clefs de chiffrage des tablesapces, mais elle apparait chiffré (évidement) :

SQL> select TS#,ENCRYPTIONALG,ENCRYTPEDKEY,MASTERKEYID from v$encrypted_tablespaces;

TS#        ENCRYPT     ENCRYTPEDKEY                                                                                               MASTERKEYID
----------     -------        ----------------------------------------------------------------                                                       --------------------------------
6            AES256      64E7B8448F7F3135CE0BF772DAF2E2D59533A1112A2D43B3DD9C22F22CED2BA6     983FEE144EBA4F4CBF06A1D69C61658F

Table Key

La MK permet de chiffrer-déchiffrer les clefs de chiffrement des colonnes (ou table key : TK). Il y a une clef par table contenant au moins une colonne chiffrée. Les TK sont stockées dans le dictionnaire de données (tablespace SYSTEM)

 La requête ci-dessous permet visualiser les TK de chaque table chiffrée:

 select u.name owner, o.name table_name, c.name column_name, decode(bitand(c.property, 536870912), 0, 'YES', 'NO') "SALT?",
                  case e.ENCALG when 1 then '3 Key Triple DES 168 bits key'
                                               when 2 then 'AES 128 bits key'
                                               when 3 then 'AES 192 bits key'
                                               when 4 then 'AES 256 bits key'
                                               else 'Internal Err'
                  end algo,
                e.COLKLC Table_key
from user$ u, obj$ o, col$ c, enc$ e
where e.obj#=o.obj# and o.owner#=u.user# and bitand(flags, 128)=0 and
e.obj#=c.obj# and bitand(c.property, 67108864) = 67108864;

OWNER                  TABLE_NAME                   COLUMN_NAME                SALT?   ALGO
---------- --------------- --------------- ----- -----------------------------
MKEYID
----------------------------------------------------------------
TABLE_KEY
--------------------------------------------------------------------------------
SYSTEM                  COL_CRYPT                   DATA_CRYPT                    NO      AES 192 bits key
AZg/7hROuk9Mvwah1pxhZY8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
417741414141414141414141414141414141414141414176494836557A4C4C6E684A38477431694F
544F6E687068682F4B736974372F4D4B6D417A332B547A7937583958773076496E387650476A7262
4A2F566F5046343D

SYSTEM                  COL_SALT_CRYPT           DATA_CRYPT                   YES      AES 192 bits key
AZg/7hROuk9Mvwah1pxhZY8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
417741414141414141414141414141414141414141414134395A49636B6B7035552B6C652B476342
70795357475A76304573667230336A4D42677766504F75766D4250734A504277673536534A62704B
514538567A47513D

La colonne Table_key est la clef de chiffrement de la table (pour la/les colonne(s)). Cette clef n’est évidemment pas en claire, elle est chiffrée par la master key.

Dans le résultat ci-dessus, il y a 2 tables COL_CRYPT et COL_SALT_CRYPT qui ont une colonne nommée DATA_CRYPT chiffrée avec le mêmealgorithme AES192 bit, mais une WITHOUT SALT et l’autre SALT. Elles ont toutes les 2 la même master key.

REKEY

Rekey Master Key

Il peut arriver qu’il faille renouveler (rekey) la master  key car, soit elle a été compromise, soit la police de sécurité du système impose de la renouveler à intervalle régulier.

Son renouvellement ne modifie en rien le chiffrage des données, il ne modifie que le chiffrage de toutes les autres clefs de chiffrage : table key et tablespace key.

La commande pour la réaliser est simple :

SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "MotDePasse";

La nouvelle master key est alors ajouté dans le wallet. D’ailleurs si on fait un ls sur le wallet avant et après on peut le voir grossir :

Avant le rekey:

[oracle@racdb1 wallet]$ ls -ltr
total 4
-rw-------. 1 oracle asmadmin 1573 Oct 16 21:33 ewallet.p12

Après le rekey:

[oracle@racdb1 wallet]$ ls -ltr
total 4
-rw-------. 1 oracle asmadmin 1837 Oct 20 17:28 ewallet.p12

Nous pouvons aussi visualiser ce changement de chiffrage dans v$encrypted_tablespaces ou bien enc$ (voir requête ci-dessous):

OWNER                  TABLE_NAME                   COLUMN_NAME                SALT?   ALGO
---------- --------------- --------------- ----- -----------------------------
MKEYID
----------------------------------------------------------------
TABLE_KEY
--------------------------------------------------------------------------------
SYSTEM                  COL_CRYPT                      DATA_CRYPT                  NO        AES 192 bits key
AUHJJdF1aU+4v5CYpWcQRLsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
41774141414141414141414141414141414141414141434D78375A696773416F774C505967357371
53456365467362375A744A4C355250707A4B75556634386161683774496137796B68377135615A56
6C4144704B4B593D

SYSTEM                  COL_SALT_CRYPT             DATA_CRYPT                YES         AES 192 bits key
AUHJJdF1aU+4v5CYpWcQRLsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
417741414141414141414141414141414141414141414357695471457947507333384D444E764274
574F7751697034646B37386462506F496178446373664D36577A3152684674354F4E3641306D4975
307732304562453D


TS#        ENCRYPT     ENCRYTPEDKEY                                                                                               MASTERKEYID
----------     -------        ----------------------------------------------------------------                                                       --------------------------------
6             AES256    6CF722BE9631CD86BFA5CB2412D3C27D4CDED29994D5773E7244C2E8F2CCBD73      41C925D175694FB8BF9098A5671044BB

Si nous comparons les clefs de chiffrage pour les tablespaces ou les tables, elles semblent avoir changées mais en fait non, c’est le chiffrage des clefs qui a changé, elles nous  apparaissent donc chiffré différemment.

Attention, après un rekey de la MK il faut bien penser à sauver le wallet !

Attention bis, après un rekey de la MK dans une configuration RAC, si la wallet n’est pas sur un stockage partagé (HSM réseau, file system partagé) il faut répliquer la wallet sur les autres nœuds et si possible sans se tromper de sens ! Pas le droit d'écraser le wallet avec l'ancien.

Rekey Table Key

Changer la clef de chiffrement d’une table revient à changer le chiffrage (physique) de la table. Cette action n’est pas aussi transparente que le rekey de la MK. Toutes les colonnes chiffrées de la table en question, vont être déchiffrées à la volé pour être rechiffrées sur disque.

OWNER                  TABLE_NAME                   COLUMN_NAME                SALT?   ALGO
---------- --------------- --------------- ----- -----------------------------
MKEYID
----------------------------------------------------------------
TABLE_KEY
--------------------------------------------------------------------------------
SYSTEM                  COL_CRYPT                      DATA_CRYPT                  NO        AES 192 bits key
AUHJJdF1aU+4v5CYpWcQRLsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
41774141414141414141414141414141414141414141434D78375A696773416F774C505967357371
53456365467362375A744A4C355250707A4B75556634386161683774496137796B68377135615A56
6C4144704B4B593D

SQL> select count(*) from col_crypt;

  COUNT(*)
----------
    920001

SQL> set timing on
SQL> ALTER TABLE col_crypt REKEY;

Table altered.

Elapsed: 00:04:23.15

OWNER                  TABLE_NAME                   COLUMN_NAME                SALT?   ALGO
---------- --------------- --------------- ----- -----------------------------
MKEYID
----------------------------------------------------------------
TABLE_KEY
--------------------------------------------------------------------------------
SYSTEM       COL_CRYPT       DATA_CRYPT       NO     AES 192 bits key
AUHJJdF1aU+4v5CYpWcQRLsAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
41774141414141414141414141414141414141414141415576705836756273416D356C4536704274
326E70577638436B5377674847436C41632F7A775946707458652F2B2B715A767047487833715661
767370394338453D

Nous voyons bien que la MK reste la même (colonne MKETID) avant et après le rekey, mais la TK pour la table COL_CRYPT à changer suite au rekey de la table.

Rekey Tablespace Key

Cette clef ne peut pas être renouvelée. La seule solution est de créer un nouveau tablespace et de déplacer les données du premier tablespace chiffré sur le nouveau tablespace chiffré.

Chiffrage des backups

Il faut savoir qu’il existe 3 méthodes de chiffrages avec RMAN :

-          Le backup « Transparent Encryption »  qui utilise la clef contenu dans le wallet. C’est ce backup qui va nous intéresser ici.

-          Le backup chiffré par mot de passe (Password Encryption), qui comme son nom l’indique utilise un mot de passe passé en entré du backup pour chiffrer le dit backup.

-          Le backup double mode de chiffrage (Dual Mode Encryption) qui utilise les 2 méthodes de chiffrage : Transparent Encryption et Password Encryption.

La clef stockée dans le wallet permet donc de chiffrer les backups avec RMAN (Transparent Encryption). Evidement pour l’utilisation  de cette fonctionnalité il faut avoir acheté l’option Advanced Security (ASO) ; sauf dans un cas, si vous chiffré directement sur tape (pas sur disque) et avec l’outil de backup OSB (Oracle Secure Backup). OSB est payant mais peut revenir moins cher qu’une licence ASO. Mais revenons à nos moutons.

La clef contenue dans le wallet va servir non pas à directement chiffrer le backup, mais à générer une clef de chiffrage par backuppiece (fichier de backup). Chaque clef est alors stockée dans le backuppiece associé. Au restaure la clef du wallet servira à déchiffrer chaque clef contenue dans les backuppieces qui a leurs tours déchiffrernt les backuppieces.

Et si la base de données est déjà chiffrée? Alors bien sûr le backup sera chiffré, mais si la source est une colonne chiffrée alors il y aura un double chiffrage (chiffrage de la colonne déjà chiffrée) en revanche si c’est un tablespace chiffré, il sera transmis chiffré dans le backup mais sans rechiffrage. Encore un avantage du tablespace chiffré par rapport à la colonne au niveau des performances.

Pour synthétiser tous les cas, un petit tableau fera l’affaire :

Et concrètement comment on fait pour chiffrer le backup?

Ce n’est pas bien compliqué.

Sous RMAN, faites un show configuration comme ci-dessous pour vérifier si la configuration d’encryption est mise en place:

$ export ORACLE_SID=ARKONA1
$ rman target/
RMAN> show encryption for database;

RMAN configuration parameters for database with db_unique_name ARKONA are:
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default

RMAN> show encryption for tablespace;

RMAN configuration parameters for database with db_unique_name ARKONA are:
RMAN configuration has no stored or default parameters

RMAN> show ENCRYPTION ALGORITHM ;

RMAN configuration parameters for database with db_unique_name ARKONA are:
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default

Nous pouvons voir que l’encryption de la database est à OFF

Si l’on veut chiffrer toute la base alors :

RMAN> configure encryption for database on ;

Sinon on peut définir au niveau tablespace par exemple le tablespace SYSTEM (choix du tablespace SYSTEM complètement idiot):

RMAN> configure encryption for tablespace system on ;

Et voilà c’est fini, c’est configuré, il ne reste plus qu’à faire un backup classique. Il faut cependant penser à ce que le wallet soit ouvert sinon au moment de backuper la base ou le/les tablespace(s) à chiffré(s) vous obtiendrez l’erreur :

ORA-19914: unable to encrypt backup
ORA-28365: wallet is not open

Le chiffrage est alors totalement transparent au niveau des traces de RMAN, dans l’exemple ci-dessous l’encryption a été mis sur le tablespace system:

RMAN>  backup tablespace system,sysaux;

Starting backup at 02-FEB-14
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=+DATA1/arkona/datafile/system.259.806278461
channel ORA_DISK_1: starting piece 1 at 02-FEB-14
channel ORA_DISK_1: finished piece 1 at 02-FEB-14
piece handle=+FRA/arkona/backupset/2014_02_02/nnndf0_tag20140202t212607_0.621.838502769 tag=TAG20140202T212607 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:26
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00002 name=+DATA1/arkona/datafile/sysaux.260.806278481
channel ORA_DISK_1: starting piece 1 at 02-FEB-14
channel ORA_DISK_1: finished piece 1 at 02-FEB-14
piece handle=+FRA/arkona/backupset/2014_02_02/nnndf0_tag20140202t212607_0.622.838502793 tag=TAG20140202T212607 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:07
Finished backup at 02-FEB-14

Starting Control File and SPFILE Autobackup at 02-FEB-14
piece handle=+FRA/arkona/autobackup/2014_02_02/s_838502801.623.838502803 comment=NONE
Finished Control File and SPFILE Autobackup at 02-FEB-14

… transparent niveau trace/log mais attention pas forcement transparent niveau utilisation CPU!!!

Perdre le porte-clefs

Et si je ne veux plus de chiffrage sur ma base… ou pire si j’ai perdu mon porte-clefs avec toutes les clefs dessus.

En cas de perte définitive du wallet, il faut garder son sang-froid et ne surtout pas fermer la base, sinon c’est mort toutes les données chiffrées sont perdues…définitivement.

En premier il faut déplacer les données dans des « endroits » non chiffrées : les objets (table/index) des tablespaces chiffrés vers des tablespaces non chiffrés, les colonnes chiffrées vers des colonnes non chiffrées. Une fois le déplacement effectué, il faut droper les objets chiffrés : table, index, tablespace, colonne. Mais ce n’est pas fini car en cas de crash de la base elle aura peut-être besoin de lire les redolog au redémarrage donc il faut les purgés : alter system switch logfile autant de fois que nécessaire pour faire une rotation complète. Puis pour finir faire un backup full de la base.

{jcomments on}

• < Précédent
• Suivant >