Nous y voila, cette semaine intense se termine.
Mes collègues repartent dés ce matin avec le groupe de clients français que nous avons accompagné tout au long de ce séjour et avec lequel nous avons partagé des moments très conviviaux. Je me rends donc seul au centre de conférence Moscone et pendant que Mark Hurd donne son avis sur les données non structurées et leur analyse (voir ici) je vais suivre mes dernières sessions techniques.

La première des sessions s’intitule « Oracle database 12c Global Data Services »  , l’acronyme GDS que j’ai utilisé hier et qui avait attiré mon attention. De quoi s’agit-il ? C’est un  produit complètement nouveau qui va venir s’interfacer entre vos connexions Oracle Net et votre listener (comme un super listener). Il concerne les architectures avec une définition de nombreux services s’appuyant sur des instances RAC et/ou Dataguard pour la haute disponibilité.
Dans ce type d’infrastructure on définit un (ou des) service(s) correspondant à nos besoins,  on choisit une politique de placement pour ce service (node(s) préférée(s), node(s) de basculement, cardinalité) , le service doit aussi pouvoir devenir actif en cas de switchover ou de failover sur la base de secours. Toute cette configuration et le fait de devoir être certain que le service est bien démarré au bon endroit peut s’avérer complexe et c’est là que le produit montre son utilité.
Il se présente comme une couche d’abstraction supplémentaire entre le client Oracle Net,  majoritairement un pool de connexion jdbc,  et des bases de données répliquées (Active Dataguard, Golden Gate actif/actif, RAC) :

• Le client fait une demande de connexion au listener GDS ( la chaine de connexion contient uniquement le port , le nom du serveur ou se trouve se processus et le nom du service);
• Celui-ci détermine, en fonction de sa configuration,  à quel endroit le service est actif et renvoi la connexion vers le listener local concerné, ceci en fonction de la charge des différents serveurs, de la latence réseau, voir du décalage (lag) pour les bases de secours;
• En cas de perte d’un service, le processus GDS le redémarre automatiquement sur un des serveurs planifiés, de manière à maintenir la cardinalité définie;  les clients sont avertis par FAN et les connexions sont automatiquement redirigées;
• Encore plus fort, si le processus GDS s’aperçoit qu’un des serveurs sur lequel tourne le service est surchargé,  il est capable de redistribuer les connexions pour que le SLA soit maintenu ;
• Une notion de région est introduite pour maintenir une certaine affinité des connexions avec un groupe de serveurs (nouveau paramètre dans la chaîne de connexion Oracle Net interprété par le listener GDS).

Pour faire tout cela, il faut installer ce produit sur un serveur externe à l’infrastructure , c’est là que tournera le (ou les si le besoin s’en fait sentir, les)  processus GDS, listener d’écoute amélioré. Comme tout bon produit Oracle,  celui-ci utilise un schéma dans une base de données pour stocker son référentiel et les états associés, ce sera peut-être un frein pour certain.
Le produit a été testé et éprouvé par la société PAYPAL qui nous a présenté ses résultats et pour qui il n’y a aucun doute il répond parfaitement à leur besoin. A envisager donc pour simplifier la gestion de vos services et leur disponibilité.
Dernière session que je veux vous faire partager (et dernière pour moi à cet Open World) , celle de l’excellent Thomas Kyte, si ce n’est pas le plus pointu dans le code interne d’Oracle c’est en tout cas quelqu’un qui en connait toutes les subtilités particulièrement pour des développements efficaces, c’est en plus un pédagogue d’une grande clarté. Je ne résiste pas au plaisir de vous mettre son slide de présentation et sa photo:


Son sujet était les nouveautés de la version 12c du moteur de la base de données concernant la sécurité, les voici :

• Analyse des privilèges associés à une opération :  dans l’idée de pouvoir restreindre les droits au minimum, c’est un outillage qui va permettre de déterminer pour une opération ou une suite d’opérations la liste des privilèges utilisés pour réaliser cette action. Accessible depuis la console EM12c ou avec le nouveau package dbms_privilege_capture();
• Oracle Data Redaction : déja abordé précédemment c’est la possibilité de masquer (filtrer) des données sensibles directement sur le retour des requêtes SQL. Un utilisateur n’ayant pas les droits ne verra pas le code d’une carte de crédit en sélectionnant la table correspondante, mais uniquement une suite de ‘#’  par exemple. Le filtrage est modulaire, il peut être complet sur tous les caractères du champ, partiel, utiliser une règle syntaxique de type regex ou bien aléatoire. Le package dbms_redact() permet d’ajouter une fonction de filtrage sur une colonne;
• Unification de l’audit et de sa destination : que ce soit pour l’installation de la base, la gestion de database vault, de label security, de RMAN, de datapump ou de SQLLOADER, l’audit est géré de la même manière. Pas de détail spécifique pour cela, il va falloir regarder nous mêmes.  La table d’audit dans la base doit maintenant être présente dans un tablespace dédié pour lequel seul le droit d’insertion est présent (finit le tablespace SYSTEM qui explose) . Seul le package dbms_audit_mgmt() peut être utilisé pour en faire la gestion. Deux nouveaux rôles existent pour utilisé l’audit, un rôle d’administrateur pour créer et implémenter les règles et un rôle utilisateur pour visionner les informations;
• Des nouveautés spécifiques pour l’option « Transparent Data Encrytion » comme de nouveaux attributs sur les clés de cryptage (date d’expiration, date de regénération etc…),  de nouvelles vues du dictionnaire pour visualiser les informations sur les clés de cryptage,  de nouvelles commandes SQL pour consolider les actions à réaliser sur les clés de cryptage, des possibilités d’import d’export et de merge des clés dans les portefeuiles (induit par les bases de données pluggables) ,  nouvelle sauvegarde automatique des portefeuille, stockage possible maintenant du portefeuille dans un disque groupe ASM et nouvelle interface centralisée dans la console EM12c pour la gestion des clés de cryptage et de leur stockage. Enfin création d’un rôle spécifique nommé SYSKM uniquement dédié à la gestion des clés de cryptage;
• Contrôle d’accès au code:  on peut maintenant définir un rôle spécifique pour du code PLSQL, ce rôle n’étant actif qu’ a l’exécution du code concerné. Ainsi pour qu’un utilisateur puisse utiliser la portion de code , il faut donner des droits spécifiques à cette portion de code. Il ne suffit plus que le propriétaire de la procédure possède les bons droits pour que celle-ci puisse se dérouler correctement;
• Droits sur invocation d’une procédure : par défaut lors de l’exécution d’une procédure celle-ci prend les droits associés au schéma avec laquelle elle est exécutée, ainsi si c’est le DBA qui l’exécute une procédure peut tout faire. Pour éviter cela, il apparait deux nouveaux privilèges : « INHERIT PRIVILEGES » et « INHERIT ANY PRIVILEGES » si le second est à utiliser avec parcimonie le premier est donné par défaut au compte PUBLIC pour tout nouveau compte,  il peut être intéressant pour la sécurité d’oter ce privilège du compte public par une commande de type « revoke inherit privileges on user <nom de l’utilisateur> from public;
• Séparation des taches :  actuellement nous avons les deux rôles SYSDBA et SYSOPER qui existent, en 12c ajout des taches suivantes:SYSBACKUP :  démarrage/arrêt, juste assez de privilège pour réaliser la sauvegarde
  SYSDG:  démarrage/arrêt , juste assez de privilège pour administrer une configuration Dataguard
  SYSKM: gestion des clés de cryptage uniquement

Et ce fut tout, cela termine six jours d’informations à ingérer, disséquer, synthétiser et rediffuser. Il faut maintenant attendre d’avoir les présentations disponibles sous format électronique et disposer d’un peu de temps pour continuer les tests de la version 12c. Version qui rappelons le est toujours en béta et pour laquelle toutes les informations diffusées sont susceptibles de modification avant la sortie définitive du produit.
Il est temps de faire comme Oracle, de ranger tout le matériel et de revenir de l’autre coté de l’atlantique pour aller vers de nouvelles aventures techniques.

Au revoir et merci de votre attention pendant ces quelques jours.