News: Nouveautés TDE en 12cR2
- Détails
- Catégorie : News
- Publié le lundi 8 mai 2017 15:18
- Écrit par Administrator
- Affichages : 52695
La release 2 de la 12c est téléchargeable depuis fin mars. Elle apporte quelques nouveautés à TDE (Transparent Data Encryption), 5 pour être très précis. Nous allons les détailler dans cet article.
Mais avant, pour rappel, la grande nouveauté de la version 12.1 était un management unifié pour la gestion des clefs et des keystores (anciennement appelé wallet en 11g). La nouvelle commande d’administration est ADMINISTER KEY MANAGEMENT, elle remplace alors l’utilitaire orapki et mkstore ainsi que Oracle Wallet Manager (la GUI) et les commandes ALTER SYSTEM de gestion de wallet/clef. La deuxième autre grande nouveauté était le nouveau privilège system SYSKM qui permet à celui qui le possède de pouvoir manager les clefs et keystore sans avoir nécessairement des privilèges trop fort (alter system, sysdba…), très utile, voire obligatoire dans un environnement à forte ségrégation des rôles.
La 12.2 apporte donc 5 nouvelles features, que voici :
- La possibilité d’encrypter un tablespace existant. Avant la 12.2, on ne pouvait qu’encrypter un tablespace à sa création. Maintenant il est possible de chiffrer un tablespace existant à tout moment, en ONLINE (mais génération de nouveaux datafiles) ou en OFFLINE (encryption dans les datafiles existants). Il est même possible de chiffrer les tablespaces « interne » oracle comme SYSTEM ou SYSAUX. Il est aussi possible de rendre la création des tablespaces automatiquement chiffré.
- Chiffrement OFFLINE:
ALTER TABLESPACE users OFFLINE NORMAL;
ALTER TABLESPACE users ENCRYPTION OFFLINE ENCRYPT;
Les datafiles existant du tablespace USERS sont alors chiffrés.
- Chiffrement ONLINE:
ALTER TABLESPACE users ENCRYPTION ONLINE USING 'AES256' ENCRYPT FILE_NAME_CONVERT= ('users01.dbf', 'users_enc01.dbf', 'users02.dbf', 'users_enc02.dbf');
Les datafiles du tablespaces USERS sont alors chiffrés dans des nouveaux datafiles et l’opération est ONLINE c’est-à-dire qu’il n’y a pas de coupure de service.
- Il y a 3 nouveaux algorithmes : ARIA, GOST et SEED en plus des 2 précédemment existants AES et DES.
CREATE TABLESPACE ts_encrypt DATAFILE '+DATA/TESTORA/ts_encrypt01.dbf' SIZE 100M ENCRYPTION USING 'GOST256' ENCRYPT;
- On peut forcer une opération de maintenance de clef ou de keystore en incluant FORCE KEYSTORE dans la commande de management. Cette commande de « forçage » est utile, par exemple, dans le cas où l’autologin est mis en place, on n'a plus alors besoin de fermer le keystore pour le ré-ouvrir en mode manuel afin de pouvoir faire un rekey. Car fermer temporaire le keystore signifie: coupure de service des applications accédant aux tablespaces chiffrées.
Dans l’exemple ci-dessous, la commande permet d’ouvrir le keystore, qu’il soit fermé (le force n’est alors pas utile) ou qu’il soit déjà ouvert par un autologin mais dans ce cas il se retrouve ouvert en manuel sans à avoir à la passer en close avant :
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN FORCE KEYSTORE IDENTIFIED BY EXTERNAL STORE;
- La possibilité d’utiliser un external store : software ou hardware, pour stocker le mot de passe du software keystore (qui contient lui, la master key). Cela permet si l’on veut pas mettre l’autologin en place, de pouvoir faire des scripts de maintenance qui ne contiennent pas en dur le mot de passe du keystore. Cela correspond un peu aux magasins de mot de passe (mkstore)
- Lors de la mise en place de Oracle Key Vault (Générer une Master Key TDE avec Key Vault) comme keystore, on peut (il faut ?) préciser dans le sqlnet.ora du serveur base de données que la méthode utilisé est OKV contrairement aux versions antérieures ou il fallait mettre HSM. Cela ne ressemble pas à une nouvelle feature mais Oracle le vend comme cela. Peut-être qu’en indiquant à la base de données qu’elle a affaire un OKV et pas un HSM classique de nouvelles fonctions/possibilité sont activés (je ne l’ai, pour l’instant, pas personnellement testé, à creuser).