about News

Unified Audit 12.2 vs 12.1

Cet article fait suite à 12c : (Pure) Unified Auditing qui avait été écrit pour la 12.1, la 12.2 n’étant alors pas encore sortie. L’audit unifié était une nouveauté de cette release. Mais avec la version 12.2, Oracle a changé l’architecture de l’audit unifié. Sur le principe il reste unifié, c’est-à-dire qu’il regroupe tous les audits en une seule table comme écrit dans le précédent article; ce qui change c’est l’architecture de cette table et aussi son mode de collecte.

En 12.1 la table de l’audit trail se nomme AUDSYS.CLI_* (nom dépendent de la base), en 12.2 elle se nomme AUDSYS.AUD$UNIFIED. Mais la véritable différence est qu’en 12.1 les données de l’audit se trouvent dans un champs de type blob (colonne LOG_PIECE) alors que sur la 12.2 les données de d’audit se trouvent éclatées au niveau des colonnes de façon classique comme pour l’audit standard dans la table SYS.AUD$ en 11g et avant.

En 12.1, dans la table AUDSYS.CLI_*, une ligne semble correspondre aux audit trails pour une session (SID#,SERAIL#) entre 2 flush d’audit (FLUSH_SCN, MAX_SCN, MIN_SCN), voir extract ci-dessous. En effet, une nouveauté en 12.1, qui sur le papier semble une très bonne idée, et qu’il est possible de ne pas écrire en direct dans la table d’audit mais dans un buffer queue (paramètre d’init : unified_audit_sga_queue_size et activation/désactivation avec la procédure DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_PROPERTY). D’où on peut en déduire que chaque fois que le cache de l’audit unifié est plein, il descend alors à ce moment-là en base et qu’il est mis dans le champs de type blob : LOG_PIECE.

Lire la suite : Unified Audit 12.2 vs 12.1

News: Après la 12, la 18.

En janvier 2018 va sortir la version d’Oracle 18.1.0. Non ce n’est pas une erreur, ni un poisson de décembre. Cette version sera la suite de la version 12.2.0.1, et elle correspondra à la version 12.2.0.2. Il n’y aura donc jamais de version 13 ce qui aurait certainement porté malheur à Oracle. Plus sérieusement, Oracle change sa nomenclature des versions de base de données ainsi que le mode/rythme des mises à jour.

Oracle prévoit de sortir une release tous les ans, et cette release portera le nom de l’année de sortie d’où le 18 à la place de la 12.2.0.2 qui est prévu pour janvier 2018. Ensuite pour cette release, tous les trimestres sortira un RU (Release Update), qui est un peu l’équivalent du Proactive Bundle Patch, qui s’appliquera à une Release. Et chaque trimestre sortira un RUR (Release Update Revisions), l’équivalent d’un PSU (Patch Set Update), qui s’appliquera à un couple Release.RU. La frise chronologique ci-dessous permet mieux appréhender l’enchainement des sorties des Release, RU et RUR:

Extrait de la note Oracle: Release Update Introduction and FAQ (Doc ID 2285040.1)

 

Lire la suite : News: Après la 12, la 18.

News: H: suite et fin

J’avais publié le 22 novembre 2015, l'article News: Problème de sécurité sur les passwords 12c sur la facilité à casser les mots de passe de type H: dans sys.user$. Les mots de passes y étaient stockés en MD5 avec un secret. Et le 22 janvier 2016 dans l'article News: Le secret du H:, j’expliquais que ce secret été simple à trouver. Je proposais aussi de faire un update dans sys.user$ pour sortir (effacer) le stockage du mot de passe en MD5 de la base, mais alors cela provoquerait une perte de support d’Oracle, et qu’il valait mieux ouvrir un support à Oracle avant. Quelque temps plus tard, j’ai donc ouvert un support à Oracle faisant suite à ces deux articles, et cela c’était conclu de la part du support : il n’y avait de contournement possible et qu’effectivement le hash MD5 du mot de passe était faible.

Cette faiblesse de stockage de mot de passe a été corrigé dans le patch sécurité d’octobre 2016.  Mais attention le passage de ce patch ne corrige pas le problème sur les anciens comptes générés avant le patch, il y a une action manuelle à faire qui correspond, qui grossièrement correspond à faire un update dans sys.user$ mais en passant par une nouvelle procédure fournit par oracle. Tout ceci est expliqué dans le document 2194116.1 sous Oracle support. On y apprend que le mot de passe était stocké en MD5 pour permettre l’authentification avec XDB HTTP(S), et un peu sous forme de mea culpa, Oracle reconnait que ce n’est plus très bien de faire cela.

Lire la suite : News: H: suite et fin

News: Nouveautés TDE en 12cR2

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 :

 

Lire la suite : News: Nouveautés TDE en 12cR2

News: Oracle Key Vault 12.2

Oracle Key Vault est une appliance pour la gestion des clefs de chiffrement et des certificats pour Oracle Database et les Middleware Oracle, mais pas seulement. La première version, la 12.1 est sortie été 2014, une nouvelle version 12.2 vient de sortir il y a quelque mois (fin 2016).

Key Vault c’est un coffre-fort de clefs, de wallets, de keystores et de certificats. Il permet de stocker de façon centralisée :

  • Les « master keys » de TDE (TDE (Part I)). Avant Key Vault, la « master key » était contenue dans une wallet (un fichier) locale à la base de données ce qui, dans le cas de RAC, Dataguard ou GoldenGate posait des problèmes de propagation de clefs. Il fallait gérer manuellement la recopie des wallets (sans se tromper de sens !).Il y avait aussi la possibilité d’utiliser un HSM réseau pour éviter la recopie manuelle et sécurisé par un hardware la clef. Avec Key Vault les clefs sont partageables entre plusieurs instances directement accessibles sur le réseau en passant par l’appliance.
  • Les wallets Oracle. Les wallets Oracle contiennent des clefs, des mots de passe, des certificats… C’est compatible avec Oracle Database et tous les produits middleware d’Oracle.
  • Les Java keystores.
  • Des fichiers Credential comme par exemple les clefs SSH ou des fichiers de mot de passe
  • Les fichiers de certificat répondant à la norme X.509

Lire la suite : News: Oracle Key Vault 12.2