Activation, Configuration et Lecture de l'Audit Standard et Fin
- Détails
- Catégorie : Sécurité
- Publié le dimanche 15 mai 2016 13:21
- Écrit par Administrator
- Affichages : 19079
Cet article a pour but d’expliquer ce qu’est l’audit sous notre SGBD préféré. Il s’applique donc aux bases Oracle de la version 10g à 11gR2 et à la 12cR1 dans le cas de la non activation de la nouveauté : audit unifié.
Il est important de comprendre comment l’audit s’active, et surtout comment on peut le configurer pour obtenir ce que l’on souhaite auditer. Bien souvent la mise en place de l’audit est un prérequis demandé par un client, par un projet mais bien souvent personne ne sait vraiment ce que l’on peut obtenir et ce que l’on veut obtenir. L’erreur serait d’ouvrir toute les vannes, d’activer l’audit tout azimut, cela génèrerait un flux important d’audit qui noierait l’information pertinente, générerait aussi peut être des problèmes de volumétrie d’audit, voire de performance. Il faut donc définir une stratégie d’audit avant le mettre en place et pour cela comprendre comment s’articule l’audit.
Remarque : Cet article ne traite que de l’audit dit Standard et Fin, c’est-à-dire celui fournit de base dans Oracle et expliqué dans la documentation Oracle Security. Il ne traite pas de l’audit provenant d’option Oracle : Oracle Database Vault, Oracle Label Security…
Audit SYS et rôles administratifs
Par défaut en 11g et version antérieure, le compte SYS est audité mais uniquement sur l’action LOGON. Ce compte est le super utilisateur d’Oracle, il peut faire tout ce qu’il veut… sauf si Vault Database est installé et configuré. C’est donc un compte à auditer, il n’y a pas de question à se poser. Il est donc conseillé de mettre en place son audit en activant l’audit des comptes administratifs.
Mais en réalité cet audit n’audite pas particulièrement SYS comme souvent on le pense, il audite en fait les connexions sous rôle administratif c’est à dire en SYSDBA et SYSOPER pour les versions d’Oracle 11gR2 et précédentes, et aussi SYSBACKUP, SYSDG et SYSKM en 12c.
Sa mise en place est simple il suffit de passer le paramètre audit_sys_operations à TRUE. Les fichiers d’audit alors se trouverons obligatoirement en dehors de la base de données dans le répertoire correspondant au paramètre audit_file_dest. En fait ils se trouvent en dehors car cela permet de tracer les actions de SYSDBA par exemple même quand la base n’est pas OPEN et quand il est impossible d’écrire dans la base.
Cet audit n’est pas customisable. C’est du ON/OFF. Dès qu’il est activé toutes les actions des connexions SYS* sont auditées.
Pour l’activer il faut mettre audit_sys_operation à TRUE (remarque : En 12c elle est à TRUE par défaut). Cette variable n’est pas modifiable à chaud, il faut prévoir un redémarrage de la base.
SQL> show parameter audit
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
audit_file_dest string /oracle/oraBase/admin/TESTORA/adump
audit_sys_operations boolean FALSE
audit_syslog_level string
audit_trail string DB
SQL> alter system set audit_sys_operations=TRUE scope=spfile;
SQL> shutdown immediate
SQL> startup
Maintenant toutes les connexions et opérations en SYSDBA par exemple, sont loggés dans audit_file_dest (ici /oracle/oraBase/admin/TESTORA/adump) :
[oracle@oradbm1 adump]$ tail -f TESTORA_ora_3180_1.aud
Mon Apr 25 17:08:27 2016 +02:00
LENGTH : '157'
ACTION :[6] 'COMMIT'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/1'
STATUS:[1] '0'
DBID:[9] '630020041'
Mon Apr 25 17:08:43 2016 +02:00
LENGTH : '170'
ACTION :[18] 'select * from dual'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/1'
STATUS:[1] '0'
DBID:[9] '630020041'
Mon Apr 25 17:09:08 2016 +02:00
LENGTH : '172'
ACTION :[17] 'grant dba to toto'
DATABASE USER:[1] '/'
PRIVILEGE :[6] 'SYSDBA'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/1'
STATUS:[4] '1917'
DBID:[9] '630020041'
Mais aussi les connexions en SYSOPER :
Mon Apr 25 17:13:49 2016 +02:00
LENGTH : '162'
ACTION :[7] 'CONNECT'
DATABASE USER:[4] 'toto'
PRIVILEGE :[7] 'SYSOPER'
CLIENT USER:[6] 'oracle'
CLIENT TERMINAL:[5] 'pts/1'
STATUS:[1] '0'
DBID:[9] '630020041'
Et aussi SYSBACKUP, SYSDG et SYSKM.
Il est possible de générer l’audit au format XML, il faut pour cela que le paramètre audit_trail soit égal à XML ou XML, EXTENDED. Mais ce paramètre influe aussi sur l’audit trail standard comme nous allons le voir ci-après.
Audit Standard
Activation
L’audit standard permet d’auditer toutes les sessions hormis les sessions avec le privilège SYSDBA et SYSOPER en 11g et SYSBACKUP, SYSDG et SYSKM en plus en 12c.
Pour que cet audit soit activé il suffit que le paramètre audit_trail ne soit pas à NONE. Ce paramètre peut prendre comme valeur :
NONE : l’audit standard est désactivé
DB : L’audit standard est activé et il s’écrit dans la base de données dans la table SYS.AUD$. DB est la valeur par défaut. Aucun utilisateur ne peut lire SYS.AUD$ hormis ceux qui ont le privilège SELECT ANY DICTIONARY. Le privilège SELECT ANY TABLE ne permet pas de lire SYS.AUD$, ni aucune table SYS.*$ mais cela est vrai uniquement si la paramètre 07_DICTIONARY_ACCESSIBILITY est à FALSE (défaut).
DB, EXTENDED : Exactement comme DB, mais ce paramètre rajoute dans l’audit, donc dans la table SYS.AUD$, la requête , qui a déclenché l’audit, en entier (tout le DML pas juste le type de requête) et la valeur des binds variables s’il y en a.
OS : L’audit standard est activé et il s’écrit dans des fichiers texte (*.aud) sur l’operating systeme. Les informations stockées sont alors du même niveau que DB, EXTENDED c’est-à-dire toute la requête. Oracle recommande cette activation pour les bases les plus sensibles au niveau sécurité. Les fichiers alors générés iront dans le répertoire définit par la variable audit_file_dest vu dans la paragraphe précédent «Audit SYS et rôle administratif », à moins que vous n’activiez l’écriture dans la SYSLOG du système (UNIX/Linux environement seulement) avec la variable audit_syslog_level qui prend alors le dessus sur audit_file_dest.
XML : L’audit standard est activé et il s’écrit sur dans des fichiers au format XML sur l’operating systeme. Hormis le fait que les fichiers soient aux formats XML, la différence avec OS est qu’en plus l’audit standard reste consultable à partir de la base par requêtage sql, en effet les fichiers sont vus comme des tables externe et consultable entre autre par la vue SYS.V$XML_AUDIT_TRAIL, mais aussi DBA_COMMON_AUDIT_TRAIL (qui agrège AUD$, les XML et l’audit fine grain) . Comme pour OS, audit_file_dest détermine l’emplacement des fichiers XML.
XML, EXTENDED : Comme XML mais rajoute la requête, qui a déclenché l’audit, en entier et la valeur des bind variables s’il y en a.
Remarque :
Si audit_trail est égal à OS alors un autre paramètre d’initialisation peut être activé : audit_syslog_level. Ce paramètre permet de rediriger l’audit vers une SYSLOG et donc par la même occasion rendre encore moins accessible l’audit car à priori seul root y a accès.
Configuration
OK, mais une fois activée, tout est loggé ? Non et heureusement, surtout pour une base avec beaucoup de sessions actives. En général quand un client demande l’audit sur une base, il ne sait pas ce qu’il veut, alors il demande tout mais cela ne sert à rien de générer un audit pour chaque action. Est-ce important de tracer les un million de SELECT d’un compte utilisé uniquement par une application ? Non, il vaut mieux logger les connexions avec ce compte et s’assurer que toutes les connexions proviennent de serveur clairement identifié avec la couche applicative attendue. En fait le plus important est de savoir analyser le résultat. Mais ce n’est pas l’objet de ce paragraphe. Ici nous allons voir les différents niveaux de l’audit standard.
L’audit standard permet de logger des actions/instructions que l’on peut définir à plusieurs niveaux :
- Audit système :
- Au niveau de l’utilisation de privilège système (connect, select any table…)
- Au niveau d’une instruction spécifique (alter table…)
- Au niveau d’un compte utilisateur.
- Audit objet :
- Au niveau d’instructions accédant à un objet spécifique.
Mais il ne permet pas de logger des accès sur des colonnes particulières, c’est l’audit fin (Fine Grain Audit) qui le permet et on le verra plus loin.
Quand on active l’audit standard c’est-à-dire en mettant autre chose que NONE à la variable d’initialisation audit_trail, une configuration par défaut s’active. Cette configuration par défaut n’audite pas tous les actions produites sur la base de données et heureusement, on va dire que c’est le minimum au niveau sécurité qui s’active.
Audit système
Pour visualiser ce qui est actuellement audité par l’audit standard au niveau audit système, cela peut se faire en interrogeant les vues dba_priv_audit_opts et dba_stmt_audit_opts.
Ci-dessous le résultat sur une base 11g avec l’audit standard par défaut sans modification :
SQL> select USER_NAME,PRIVILEGE,SUCCESS,FAILURE from dba_priv_audit_opts order by 1,2 ;
USER_NAME PRIVILEGE SUCCESS FAILURE
------------------------------ ---------------------------------------- ---------- ----------
ALTER ANY PROCEDURE BY ACCESS BY ACCESS
ALTER ANY TABLE BY ACCESS BY ACCESS
ALTER DATABASE BY ACCESS BY ACCESS
ALTER PROFILE BY ACCESS BY ACCESS
ALTER SYSTEM BY ACCESS BY ACCESS
ALTER USER BY ACCESS BY ACCESS
AUDIT SYSTEM BY ACCESS BY ACCESS
CREATE ANY JOB BY ACCESS BY ACCESS
CREATE ANY LIBRARY BY ACCESS BY ACCESS
CREATE ANY PROCEDURE BY ACCESS BY ACCESS
CREATE ANY TABLE BY ACCESS BY ACCESS
CREATE EXTERNAL JOB BY ACCESS BY ACCESS
CREATE PUBLIC DATABASE LINK BY ACCESS BY ACCESS
CREATE SESSION BY ACCESS BY ACCESS
CREATE USER BY ACCESS BY ACCESS
DROP ANY PROCEDURE BY ACCESS BY ACCESS
DROP ANY TABLE BY ACCESS BY ACCESS
DROP PROFILE BY ACCESS BY ACCESS
DROP USER BY ACCESS BY ACCESS
EXEMPT ACCESS POLICY BY ACCESS BY ACCESS
GRANT ANY OBJECT PRIVILEGE BY ACCESS BY ACCESS
GRANT ANY PRIVILEGE BY ACCESS BY ACCESS
GRANT ANY ROLE BY ACCESS BY ACCESS
23 rows selected.
SQL> select USER_NAME,AUDIT_OPTION,SUCCESS,FAILURE from dba_stmt_audit_opts order by 1,2 ;
USER_NAME AUDIT_OPTION SUCCESS FAILURE
------------------------------ ---------------------------------------- ---------- ----------
ALTER ANY PROCEDURE BY ACCESS BY ACCESS
ALTER ANY TABLE BY ACCESS BY ACCESS
ALTER DATABASE BY ACCESS BY ACCESS
ALTER PROFILE BY ACCESS BY ACCESS
ALTER SYSTEM BY ACCESS BY ACCESS
ALTER USER BY ACCESS BY ACCESS
CREATE ANY JOB BY ACCESS BY ACCESS
CREATE ANY LIBRARY BY ACCESS BY ACCESS
CREATE ANY PROCEDURE BY ACCESS BY ACCESS
CREATE ANY TABLE BY ACCESS BY ACCESS
CREATE EXTERNAL JOB BY ACCESS BY ACCESS
CREATE PUBLIC DATABASE LINK BY ACCESS BY ACCESS
CREATE SESSION BY ACCESS BY ACCESS
CREATE USER BY ACCESS BY ACCESS
DATABASE LINK BY ACCESS BY ACCESS
DROP ANY PROCEDURE BY ACCESS BY ACCESS
DROP ANY TABLE BY ACCESS BY ACCESS
DROP PROFILE BY ACCESS BY ACCESS
DROP USER BY ACCESS BY ACCESS
EXEMPT ACCESS POLICY BY ACCESS BY ACCESS
GRANT ANY OBJECT PRIVILEGE BY ACCESS BY ACCESS
GRANT ANY PRIVILEGE BY ACCESS BY ACCESS
GRANT ANY ROLE BY ACCESS BY ACCESS
PROFILE BY ACCESS BY ACCESS
PUBLIC SYNONYM BY ACCESS BY ACCESS
ROLE BY ACCESS BY ACCESS
SYSTEM AUDIT BY ACCESS BY ACCESS
SYSTEM GRANT BY ACCESS BY ACCESS
28 rows selected.
Ci-dessous le résultat sur une base 12c avec l’audit standard par défaut sans modification :
SQL> select USER_NAME,PRIVILEGE,SUCCESS,FAILURE from dba_priv_audit_opts;
no rows selected
SQL> select USER_NAME,AUDIT_OPTION,SUCCESS,FAILURE from dba_stmt_audit_opts;
no rows selected
En 12c, il n’y a pas de configuration par défaut d’activer. En fait ce n’est pas entièrement vrai. Si on fait un select dans AUD$ il n’y aura aucune ligne d’audit mais en revanche dans UNIFIED_AUDIT_TRAIL il y aura des lignes :
SQL> select count(*) from dba_audit_trail;
COUNT(*)
----------
0
SQL> select count(*) from UNIFIED_AUDIT_TRAIL;
COUNT(*)
----------
10
Oracle a introduit avec la 12c la notion d’audit unifié que l’on verra dans un prochain article. Mais juste pour explication notre base 12c n’est pas en audit unifié pur (pure unified audit mode) mais en mode audit unifié mixte (mixted unified audit mode) :
SQL> select * from v$option where parameter like '%Unif%';
PARAMETER
----------------------------------------------------------------
VALUE CON_ID
---------------------------------------------------------------- ----------
Unified Auditing
FALSE 0
Et quand la base n’est pas en audit unifié pur (comme dans le cas ci-dessus), alors quand on active l’audit standard, par défaut l’audit Standard et Fin n’audite rien, et l’audit unifié (le nouveau) audite quelque action. Dans la documentation 12c cet ancien audit est nommé : Traditional Auditing.
Revenons donc à l’audit tradicitonnel. La vue dba_priv_audit_opts donne la liste des privilèges systèmes qui sont audités, et la vue dba_stmt_audit_opts donne la liste des instructions qui sont audités. Il y a des recoupements comme par exemple le privilège CREATE SESSION et l’instruction CREATE SESSION. La subtilité est que l’audit d’un privilège système se déclenche si on passe par ce privilège, l’audit d’une instruction se déclenche quand on exécute cette instruction.
Comme on peut le voir dans le résultat précédent des requêtes portant sur dba_priv_audit_opts et dba_stmt_audit_opts, la colonne user_name est vide, cela signifie que quel que soit la session qui exécute ou utilise un privilège de la liste, la session déclenchera un évènement dans l’audit standard.
Pour rajouter des nouvelles options d’audit ou en enlever, cela se fait avec la commande AUDIT/NOAUDIT. Et avec la commande AUDIT on peut aussi spécifier un compte particulier pour lequel on voudrait rajouter des audits.
Exemple : On veut auditer tous les updates du compte USERTEST :
SQL> AUDIT UPDATE TABLE BY USERTEST;
Audit succeeded.
SQL> select USER_NAME,AUDIT_OPTION,SUCCESS,FAILURE from dba_stmt_audit_opts order by 1,2 ;
USER_NAME AUDIT_OPTION SUCCESS FAILURE
------------------------------ ---------------------------------------- ---------- ----------
USERTEST UPDATE TABLE BY SESSION BY SESSION
ALTER ANY PROCEDURE BY ACCESS BY ACCESS
ALTER ANY TABLE BY ACCESS BY ACCESS
[...]
SYSTEM AUDIT BY ACCESS BY ACCESS
SYSTEM GRANT BY ACCESS BY ACCESS
29 rows selected.
La syntaxe de la commande audit en simplifé pour les cas les plus courant :
AUDIT privilege/statement [ ,privilege/statement ]
[ BY username [ , username] ]
[ BY < SESSION|ACCESS> ]
[ WHENEVER [NOT] SUCCESSFUL ]
BY SESSION : il n’y aura qu’un enregistrement dans l’audit pour les requêtes ou opérations identiques dans une même session, sauf pour les instructions DDL qui généreront autant de lignes que des fois que celles-ci seront exécutées.
BY ACCESS : il y aura un enregistrement à chaque déclenchement.
WHENEVER SUCCESSFUL : le déclenchement aura lieu uniquement si la requête ou l’opération se finit avec succès
WHENEVER NOT SUCCESSFUL : le déclenchement aura lieu uniquement si la requête ou l’opération se termine en erreur ou échec.
Mais alors si je veux l’écriture d’un audit que la requête soit en succès ou en échec ? Je mets quoi ? Et bien je ne mets rien, je ne mets pas [ WHENEVER [NOT] SUCCESSFUL ].
Pour la syntaxe de la commande AUDIT en détail voici les liens pour la 11gR2 et la 12c : syntaxe_audit_11g et syntaxe_audit_12c.
Audit objet
Pour l’audit des objets c’est la vue dba_obj_audit_opts qui donne la liste des objets qui sont audités et sur quelles instructions ils le sont.
SQL> select * from dba_obj_audit_opts ;
no rows selected
…rien dans cette base 11g fraîchement installée.
Pour mettre en place l’audit d’un objet, c’est aussi la commande AUDIT comme pour l’audit système mais avec une syntaxe un peu différente.
Ci-dessous la syntaxe résumé/simplifié :
AUDIT statement [ ,statement ]
ON < [schema.]object | DEFAULT>
[ BY < SESSION|ACCESS> ]
[ WHENEVER [NOT] SUCCESSFUL ]
Comme précédemment pour la syntaxe complète : syntaxe_audit_11g et syntaxe_audit_12c.
Un exemple : mise en place de l’audit sur la table MATABLE pour toutes les opérations UPDATE, INSERT et DELETE.
SQL> audit update, insert, delete on USERTEST.MATABLE by ACCESS ;
Audit succeeded.
Maintenant si sur cette base de données nous interrogeons dba_obj_audit_opts :
select * from dba_obj_audit_opts ;
OWNER OBJECT_NAME OBJECT_TYPE ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE CRE REA WRI FBK
---------- --------------- ------------ --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
USERTEST MATABLE TABLE -/- -/- -/- A/A -/- -/- A/A -/- -/- -/- A/A -/- -/- -/- -/- -/- -/-
Il y a bien un enregistrement maintenant et les colonnes DEL pour DELETE, INS pour INSERT et UPD pour UPDATE contiennent A/A. Et cela se lit comme cela :
Audit_sur_succès / Audit_sur_échec
avec
- pour absence de d’audit
A pour audit sur ACCESS
S pour audit sur SESSION
Donc ici A/A dans la colonne DEL signifie que la table MATABLE du schéma USERTEST déclenche un audit à chaque tentative de DELETE sur elle et ce quel que soit le résultat de la commande DELETE : échec ou succès.
Et s’il y avait -/S dans la colonne DEL cela aurait signifié alors qu’il n’y aurait pas d’audit sur les DELETE qui réussiraient mais en revanche un audit pour ceux qui échoueraient. Et si dans une même session plusieurs DELETE échouaient, il n’y aurait qu’une ligne de générée dans l’audit car S de SESSION.
Remarque :
On peut définir un défaut d’audit d’objet pour que tout nouvel objet crée soit audité sur certaines opérations sans à avoir à exécuter la commande AUDIT après sa création. La vue all_def_audit_opts permet de visualiser ce "par défaut".
SQL> select * from all_def_audit_opts;
ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE FBK REA
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
-/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/-
SQL> AUDIT ALTER ON DEFAULT BY ACCESS ;
Audit succeeded.
SQL> select * from all_def_audit_opts;
ALT AUD COM DEL GRA IND INS LOC REN SEL UPD REF EXE FBK REA
--- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
A/A -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/- -/-
Maintenant tout nouvel objet créé déclenchera un enregistrement dans l’audit standard si un ALTER est fait dessus qu’il réussisse ou échoue.
Audit Fin
Audit Fin ou Fine Grained Audit en Anglais, pour une fois c’est plus court en Français 
. Plus sérieusement, l’audit fin permet de définir des conditions d’audit en fonction des données accédées, ce que ne permet pas l’audit standard. On peut même rajouter des conditions à son déclenchement qui n’ont rien à voir avec les données accédées comme par exemple l’horaire, la plage d’adresse IP, l’OS username… Et on peut aussi déclencher des actions comme par exemple l’envoi de mails. En revanche l’audit fin n’est disponible que dans la version Entreprise mais ne demande pas d’ "Extra Cost Option".
Le fine grained audit est un peu plus complexe à mettre en œuvre par rapport au standard audit. Il faut utiliser le package DBMS_FGA qui permet de créer/gérer des POLICY (politique de management).
Comme pour l’audit standard, le stockage de l’audit fin peut se faire en base ou sur fichier XML, mais en revanche pas dans les fichiers texte : *.aud. Ce paramétrage n’est pas dépendant du fichier d’initialisation de la base comme pour l’audit standard, il se fait dans la déclaration de la POLICY.
Un exemple vaut plus qu’un grand discourt, alors voici un bien concret :
Une table contenant des informations sur des clients :
create table crm.clients (id number, nom varchar2(50), prenom varchar2(50), ville varchar2(50), telephone varchar2(50), adresse varchar2(50)) tablespace users;
Un compte d’administration de l’audit fin (dba n'est pas obligatoire, il faut alors affiner les droits):
grant create session, dba to sysadmin_fga identified by oracle;
grant select on crm.clients to sysadmin_fga;
grant execute on dbms_fga to sysadmin_fga;
grant select on sys.fga_log$ to sysadmin_fga;
Et une POLICY sur la table CLIENTS :
connect sysadmin_fga/oracle
BEGIN
dbms_fga.add_policy(
object_schema => 'CRM',
object_name => 'CLIENTS',
policy_name => 'AUDIT_CLIENTS',
audit_condition => ' SYS_CONTEXT(''USERENV'',''OS_USER'') = ''oracle'' OR SYS_CONTEXT(''USERENV'',''IP_ADDRESS'') != ''10.10.0.61'' ',
audit_column => 'NOM, TELEPHONE',
enable => TRUE,
statement_types => 'SELECT, DELETE',
audit_trail => dbms_fga.db + dbms_fga.extended,
audit_column_opts => dbms_fga.all_columns
);
END;
/
Cette POCLIY nommé AUDIT_CIENTS (policy_name => 'AUDIT_CLIENTS') permet de déclencher un enregistrement d’audit fin quand :
- Une requête de SELECT ou de DELETE (statement_types => 'SELECT, DELETE') est faite
- Sur la table CLIENTS (object_name => 'CLIENTS') du schéma CRM (object_schema => 'CRM')
- A la condition que l’OS user soit oracle ou bien que l’adresse IP soit différente de 10.10.0.61 (audit_condition => ‘la condition’)
- Et que la requête utilise toutes les colonnes (audit_column_opts => dbms_fga.all_columns) suivante: NOM et TELEPHONE (audit_column => 'NOM, TELEPHONE').
- Alors cet enregistrement sera stocké dans la base (audit_trail => dbms_fga.db + dbms_fga.extended) dans la table SYS.FGA_LOG$.
- Et en plus cet enregistrement contiendra la requête en entier et pas juste le type de requête (audit_trail => dbms_fga.db + dbms_fga.extended)
Pour visualiser les POLICY de fine grained audit configurées sur la base de données, les vues dba_audit_policies et dba_audit_policy_columns peuvent être interrogées :
SQL> Select * from dba_audit_policy_columns
OBJECT_SCHEMA OBJECT_NAME POLICY_NAME POLICY_COLUMN
------------------------------ ------------------------------ --------------------------
CRM CLIENTS AUDIT_CLIENTS NOM
CRM CLIENTS AUDIT_CLIENTS TELEPHONE
SQL> select OBJECT_SCHEMA,OBJECT_NAME,POLICY_OWNER,POLICY_NAME,ENABLED,SEL,INS,UPD,DEL,AUDIT_TRAIL,POLICY_COLUMN_OPTIONS,POLICY_COLUMN,POLICY_TEXT from dba_audit_policies;
OBJEC OBJECT_NAM POLICY_OWNER POLICY_NAME ENA SEL INS UPD DEL AUDIT_TRAIL POLICY_COLU POLICY_COLUMN
----- ---------- --------------- -------------------- --- --- --- --- --- ------------ ----------- ------------------------------
POLICY_TEXT
----------------------------------------------------------------------------------------------------
CRM CLIENTS SYSADMIN_FGA AUDIT_CLIENTS YES YES NO NO YES DB+EXTENDED ALL_COLUMNS NOM
SYS_CONTEXT('USERENV','OS_USER') = 'oracle' OR SYS_CONTEXT('USERENV','IP_ADDRESS') != '10.10.0.61'
Pour supprimer cette POLICY :
BEGIN
dbms_fga.drop_policy(
object_schema => 'CRM',
object_name => 'CLIENTS',
policy_name => 'AUDIT_CLIENTS');
END;
/
Lecture des audits
C’est bien beau de configurer les audits standard et fin mais faut-il aussi savoir les visualiser, sinon cela ne sert à rien. Le dessin ci-dessous, fait la synthèse des différentes sources.
Les différents audits se trouvent donc dans des tables ou bien des fichiers (voir une SYSLOG, non représenté dans le schéma) suivant le paramétrage expliqué dans le paragraphe activation pour l’audit.
Pour les tables AUD$ (audit standard) et FGA_LOG$ (audit fin) il est plus simple et convivial d’interroger leur vue respective DBA_AUDIT_TRAIL et DBA_FGA_AUDIT_TRAIL car elles font des jointures avec des tables de références, il est plus agréable d’avoir l’action (ex : UPDATE, ALTER SYSTEM) que le code action ( ex 6, 49…).
Si l’audit standard et/ou l’audit fin sont stockés dans des fichiers XML ils sont consultables dans la vue V$XML_AUDIT_TRAIL. Attention les performances de consultation peuvent être pauvre s’il y a de nombreux fichier XML.
Pour l’audit standard en mode OS, c’est-à-dire dans des fichiers textes *.aud, ainsi que pour l’audit SYS, la consultation n’est pas aisée, il est conseillé d’avoir un collecteur pour pouvoir browser dans les logs d’audit comme SPLUNK, LogLogic, Oracle Audit Vault (à ne pas confondre avec Vault Database)….
La vue DBA_COMMON_AUDIT_TRAIL permet, elle, d’ "unifié" en une seule vue les audits standard et fin sauf si le standard est de type OS ( fichier *.aud).
Et maintenant un exemple de ce que l’on peut trouver en lisant l’audit standard et audit fin et se servant de la vue DBA_COMMON_AUDIT_TRAIL.
SQL> select AUDIT_TYPE,SESSION_ID,to_char(EXTENDED_TIMESTAMP,'DD-MON-YY HH24:MI:SS'),DB_USER, OS_USER, USERHOST, COMMENT_TEXT,STATEMENT_TYPE, OBJECT_SCHEMA, OBJECT_NAME,RETURNCODE,SQL_TEXT from dba_common_audit_trail where EXTENDED_TIMESTAMP > trunc(sysdate) order by EXTENDED_TIMESTAMP ;
Standard Audit 330120 13-MAY-16 22:14:33 SYSTEM winroc client.localdomain
Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.0.100)(PORT=54311)) LOGON 0
Fine Grained Audit 330120 13-MAY-16 22:23:17 SYSTEM winroc client.localdomain
SELECT CRM CLIENTS
select NOM,TELEPHONE from crm.clients where VILLE='PANAMA'
Standard Audit 330120 13-MAY-16 22:36:24 SYSTEM winroc client.localdomain
DELETE SYS AUD$ 0
Standard Audit 330120 13-MAY-16 22:37:41 SYSTEM winroc client.localdomain
LOGOFF 0
Standard Audit 330121 13-MAY-16 22:37:57 USERTEST winroc client.localdomain
Authenticated by: DATABASE; Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.0.100)(PORT=54312)) LOGON 0
Standard Audit 330121 13-MAY-16 22:38:32 USERTEST winroc client.localdomain
DELETE SYS AUD$ 2004
Dans cet extrait on peut voir 2 choses intéressantes
- que la session 330121 a tenté de faire un delete dans AUD$ et a eu en retour l’erreur ORA-2004, cela a été logé grâce à l’audit standard. Et on peut voir aussi que cette session provient de l’OS user winroc du serveur client.localdomain avec l’adresse IP 10.10.0.100 et il s’est connecté avec le compte oracle USERTEST.
- que la session 330120 s’est intéressée au nom et numéro de téléphone de la ville Panama, voulait-il faire un listing pour le publier et en faire un LEAKS ? . Toujours est-il que la session venait de l’OS user winroc du serveur client.localdomain avec l’adresse IP 10.10.0.100 et il s’est connecté avec le compte oracle SYSTEM.
Voilà nous avons fait le tour de de l’audit traditionnel (standard et fi) : activation, configuration et lecture. Il resterait à voir la purge mais cela sera peut-être dans un prochain article.