about News
12c : (Pure) Unified Auditing
- Détails
- Catégorie : News
- Publié le lundi 16 mai 2016 19:31
- Écrit par Administrator
- Affichages : 63643
[EDIT 13/06/2018: cet article s'applique pleinement à la version 12.1 non patchée 22782757. Des changements d'architecture de la table de l'audit trail ont eu lieu en 12.2 ou avec le patch 22782757 de la 12.1. Cela est décrit dans l'article: Unified Audit 12.2 vs 12.1 ]
Une nouveauté de la 12c est l’audit unifié (Unified Audit Data Trail). Cette nouveauté n’a pas été très mise en avant par rapport à de nombreuses autres fonctionnalités, et pourtant elle est vraiment intéressante pour qui s’intéresse à la sécurité. Mais avant de parler de l’audit unifié, un petit rappel sur l’audit traditionnel peut être lu ici : Activation, Configuration et Lecture de l'Audit Standard et Fin . En résumé en version 11gR2 et antérieure, il n’existait pas d’audit global. Il y avait plusieurs types d’audit avec chacun leur règle d’implémentation et chaque type d’audit avait son stockage spécifique comme décrit dans le schéma ci-dessous :
L’audit unifié introduit en 12c change donc cela :
Unified Audit
L’audit unifié capture les informations d’audit de plusieurs sources pour les mettre au même endroit dans une table en read-only dans le nouveau schéma AUDSYS. L’audit est alors accessible par la nouvelle vue UNIFIED_AUDIT_TRAIL. Dans cette vue on peut retrouver les audits provenant de :
- Les audits équivalent au Standard Audit en incluant les Audit SYS et compte administratif. Rappel: Activation, Configuration et Lecture de l'Audit Standard et Fin
- Les audits du l’audit fin qui sont configurable avec les package DBMS_FGA<rappel>
- Les audits de Oracle Database Real Application Security
- Les audits de RMAN (Recovery Manager)
- Les audits de Oracle Database Vault
- Les audits de OLS (Oracle Label Security)
- Les audits de ODM (Oracle Data Mining)
- Les audits de Data Pump
- Les audits de SQL*Loader
Remarque :
L’audit unifié permet d’auditer donc SYS et les sessions administratives, très bien… mais si la base n’est pas open, les audits ne peuvent pas s’écrire dans la base, ils s’écrivent où alors ?... Ils s’écrivent dans un nouveau format de fichier binaire dans le répertoire $ORACLE_BASE/audit/$ORACLE_SID, ils sont nommés ora_audit_*.bin.
Il y a 2 nouveaux rôles : AUDIT_ADMIN et AUDIT_VIEWER. Comme leur nom l’indique AUDIT_ADMIN permet d’administrer l’audit unifié à travers le package DMBS_AUDIT_MGMT, et AUDIT_VIEWER pour pouvoir lire les audits
Le nom de la table où sont stockés les audits peut être obtenue comme ceci :
SQL> select TABLE_NAME from dba_tables where owner='AUDSYS';
TABLE_NAME
-----------------------------------------------
CLI_SWP$738c7e70$1$1
Son nom change sur chaque base de données. Mais il est impossible de lire directement dedans même avec le rôle AUDIT_ADMIN.
Les avantages de l’audit unifié par rapport à l’audit traditionnel sont :
- Les audits sont unifiés dans le même repository (la même table), il n’est plus nécessaire donc de croiser les informations de plusieurs vues.
- Il est possible de créer des policies sur toutes les provenances citées ci-dessus. Il est possible pour chaque type de provenance de créer des règles de condition et d’exclusion un peu comme dans le fine-grained audit (règle sur les IP, le type de connexion…)
- L’audit des comptes administratifs et SYS sont eux aussi dans l’audit unifié, plus la peine d’aller lire des fichiers texte *.aud (lecture native sous sqlplus).
- Les performances sont améliorées. Les audits sont mis en queue dans le SGA puis écris en batch dans la table d’audit unifié du schéma AUDSYS. Remarque c’est le mode par défaut (Queued write mode) mais il peut y avoir une perte d’audit en cas de crash de la base, pour éviter cela il y a le mode Immediate write mode mais on perd alors en performance (performance identique à l’audit traditionnel)
- La sécurité est renforcée en plusieurs points. Par exemple dans les versions précédentes, tous les users pouvaient changer la configuration de l’audit sur leurs objets, maintenant ce n’est plus le cas, il faut avoir le rôle AUDIT_ADMIN pour modifier la configuration de l’audit.
Pure Unified Audit
Par défaut sur une base 12c, le mode traditionnel et le mode unifié cohabite. Mais par défaut le mode traditionnel n’audit rien, il n’est pas préconfiguré comme dans la version 11g. Quand les deux modes cohabitent on dit que la base est en mode mixte (Mixed mode auditing). Pour activer uniquement le mode unifié (Pure unified auditing), le noyau oracle a besoin d’être recompilé avec le flag uniaud_on et donc cela nécessite un arrêt des bases rattachées à ce noyau.
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk uniaud_on ioracle ORACLE_HOME=$ORACLE_HOME
Il est à noter que l’audit de SYS et des rôles administratifs (SYSDBA, SYSOPER, SYSKM…) dans les nouveaux fichiers ora_audit_*.bin quand la base est en read-only, ne fonctionne que si le mode "pure unified" est activé.
Si le mode unifié pure n’est pas activé par défaut à l’installation du moteur oracle c’est pour pouvoir migrer les bases de données 11g en 12c, pour permettre une transition en douceur pour le basculement l’audit traditionnel vers l’audit unifié.
Il est à noter aussi qu’en architecture multitenant, chaque pluggable database, y compris la base root a son propre audit unifié.
En résumé, l’audit unifié est une refonte de l’audit Oracle. Il est plus sécurisé : il y a enfin une séparation des rôles (manager/viewer), la table repository n’est pas modifiable en DML ou DDL. Il est plus étendu, il peut couvrir de nouveau domaine : RMAN, Dapapump, Vault (en natif). Il est plus performant ou plutôt moins pénalisant (question d’angle de vue) … Cette nouveauté (de 2013 quand même) est une vraie feature pas comme la superbe feature --> 12c : recover table l'usine à gaz 